> ## Documentation Index > Fetch the complete documentation index at: https://docs.replit.com/llms.txt > Use this file to discover all available pages before exploring further. # Plusieurs artefacts vs. projets séparés > Découvrez quand combiner des artefacts dans un même projet et quand créer des projets séparés sur Replit. Un [projet](/references/projects-and-artifacts/projects) est le conteneur de tout ce que vous créez sur Replit. Un projet contient vos designs, applications, diaporamas, données et tous les résultats que vous produisez. Les [artefacts](/references/projects-and-artifacts/artifacts) sont les sorties publiables à l'intérieur d'un projet : applications web, applications mobiles, jeux de diapositives et vidéos. Lorsque vous créez plusieurs choses, vous avez deux options : * ajouter plusieurs artefacts à un seul projet, * ou créer des projets séparés. Le bon choix dépend de si vos applications partagent des données, de la logique et un cycle de vie de déploiement. Ce guide explique quand conserver des artefacts dans un seul projet et quand en créer des séparés. ## Ce que les artefacts partagent dans un projet Lorsque des [artefacts](/references/projects-and-artifacts/artifacts) se trouvent dans le même [projet](/references/projects-and-artifacts/projects), ils partagent automatiquement : * **Base de données** : Un artefact écrit des données, les autres les lisent instantanément * **Back-end et API** : Logique serveur partagée, pas de code dupliqué * **Stockage de fichiers** : Images, documents et téléchargements accessibles à tous les artefacts * **Déploiement** : La publication déploie tout ensemble de manière synchronisée Cela signifie que vous n'avez pas besoin de configurer des connexions ni de dupliquer du code entre les artefacts. Mais cela signifie également que vous ne pouvez pas publier un artefact sans publier les autres. ## Guide rapide Voici les scénarios clés à considérer pour décider d'ajouter des artefacts à un projet existant ou d'en créer un nouveau. | **Utiliser plusieurs artefacts dans un seul projet** | **Utiliser des projets séparés** | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | Les applications partagent les mêmes données et back-end | Les applications ne partagent pas de logique ou de données sous-jacentes | | Vous voulez que tout se déploie ensemble | Vous avez besoin de cycles de déploiement indépendants | | Elles sont complémentaires (comme une application client et un tableau de bord d'administration) | Ce sont des produits sans rapport ou pour des clients différents | | Vous voulez que les modifications d'un artefact se reflètent automatiquement dans les autres | Le projet est de courte durée, comme une page de destination pour une campagne ou un site d'événement | ## Exemples ### Même projet : Application web + application mobile pour un même produit Un restaurant crée une application web pour que les clients consultent le menu et une application mobile pour que le personnel gère les commandes. Les deux se connectent à la même base de données d'articles du menu, de commandes et d'informations clients. **Pourquoi un seul projet :** Les applications partagent les mêmes données et back-end. Lorsqu'un client passe une commande via l'application web, le personnel la voit immédiatement sur l'application mobile. ### **Même projet** : Application + tableau de bord d'administration + présentation pour investisseurs Une startup crée son produit principal, un panneau d'administration interne pour gérer le contenu, et un jeu de diapositives pour la levée de fonds — le tout dans un seul projet. **Pourquoi un seul projet :** Le tableau de bord d'administration gère les mêmes données que l'application affiche, et la présentation peut référencer des métriques en direct depuis le back-end partagé. ### **Projets séparés** : Deux applications client sans rapport Un freelance crée une boutique en ligne pour un client et un système de réservation pour un autre. **Pourquoi des projets séparés :** Les applications ne partagent pas de données ni de logique. Chaque client a besoin d'un déploiement indépendant et vous ne voulez pas que les modifications apportées à l'une affectent l'autre. ### **Projets séparés** : Page de destination de campagne à côté d'un produit principal Vous avez une application de production qui fonctionne toute l'année et une page de destination de courte durée pour une campagne marketing. **Pourquoi des projets séparés :** La page de campagne a son propre cycle de vie — vous la lancez, la faites tourner pendant quelques semaines, puis la retirez. La garder séparée évite d'encombrer votre produit principal et vous permet de la publier ou de la supprimer de manière indépendante. ## Foire aux questions Pas pour l'instant. Si vous devez séparer un artefact, créez un nouveau [projet](/references/projects-and-artifacts/projects) et demandez à Agent de le reconstruire là-bas. Un projet peut contenir un maximum de 7 artefacts. Cette limite existe car les artefacts supplémentaires consomment plus de mémoire, ce qui peut ralentir la prévisualisation. Si vous avez besoin de plus d'artefacts, commencez un autre [projet](/references/projects-and-artifacts/projects). Pas pour l'instant. La publication déploie tout ensemble. Si vous avez besoin d'un déploiement indépendant, utilisez des projets séparés.