Monorepo et multirepo : définitions sans faux raccourcis
| Critère | Monorepo | Multirepo |
|---|---|---|
| Changements transversaux | Un commit ou PR peut couvrir plusieurs projets | Souvent plusieurs dépôts, versions et PR |
| Dépendances | Centralisation et règles communes plus simples | Plus d'indépendance de versions |
| CI | Nécessite sélection par graphe, cache et montée en charge | Périmètre naturel plus petit par pipeline |
| Accès | Ownership des chemins via règles et revues | Isolation naturelle au niveau du dépôt |
| Outils | Davantage de standards communs | Plus de liberté par projet |
| Releases | Peuvent être indépendantes mais demandent orchestration | Pipelines naturellement séparés |
Un monorepo est un dépôt contenant plusieurs projets logiquement séparés : applications, services, bibliothèques ou outils. Le multirepo, aussi appelé polyrepo, place ces éléments dans des dépôts distincts. Les frontières de dépôt sont des frontières de gestion du code source, pas automatiquement des frontières de déploiement. [1][13][15]
Un monorepo peut donc contenir des dizaines de services déployés indépendamment, tandis qu'un multirepo peut contenir les modules d'un même grand système. Confondre stratégie de dépôt et monolithe ou microservices conduit à de mauvaises décisions d'architecture.
Ce que montre l'étude Google : les deux modèles ont de vrais avantages
L'étude Google menée auprès d'ingénieurs ayant travaillé avec les deux modèles identifie la visibilité de l'ensemble du code comme un avantage majeur du monorepo. Elle facilite la découverte d'API réutilisables, d'exemples d'utilisation et la mise à jour du code dépendant lors de migrations. La centralisation des dépendances est aussi appréciée. [1]
La même étude identifie des avantages du multirepo : plus de liberté dans le choix des outils, des frontières d'accès plus fortes et davantage de stabilité entre projets. Les auteurs soulignent aussi que la qualité de l'outillage influence fortement l'expérience de chaque modèle. [1]
Changements transversaux : l'avantage pratique le plus clair du monorepo
Lorsqu'une modification d'interface exige des changements coordonnés dans le backend, le frontend, les bibliothèques et les tests, un monorepo peut regrouper toute la migration dans un seul commit ou pull request. Google cite la mise à jour du code dépendant pendant les migrations d'API comme un bénéfice important. [1][2]
En multirepo, le même changement devient souvent une séquence : modifier le producteur, publier une version, mettre à jour les consommateurs et coordonner plusieurs pull requests. L'automatisation réduit cette friction, mais les frontières de dépôt restent des frontières du processus d'intégration.
Dépendances et versions : centralisation contre indépendance
Les monorepos facilitent l'alignement des versions communes et les références directes entre packages locaux. Yarn Workspaces relie les packages d'un même projet, tandis que Constraints peut imposer des règles de versions ou de `package.json` à l'échelle du workspace. [13][14]
Le multirepo laisse davantage de liberté sur les versions et le calendrier des mises à jour, mais les bibliothèques communes peuvent diverger entre dépôts. Ce modèle fonctionne bien avec des contrats stables et des artefacts publiés via des registries contrôlés.
CI en monorepo : tout reconstruire à chaque commit est une mauvaise stratégie
Un grand monorepo ne devrait pas exécuter tous les tests et builds après chaque changement. Nx `affected` utilise l'historique Git et le graphe des projets pour déterminer le plus petit ensemble affecté et ignorer le travail sans rapport. [4]
Le cache distant partage les résultats déjà calculés entre postes de développement et CI, tandis que l'exécution distribuée répartit les tâches restantes sur plusieurs machines. Bazel traite le même problème avec l'exécution distante et le cache des actions de build et de test. [5][7][8]
CI en multirepo : un périmètre plus petit ne supprime pas la coordination
En multirepo, un pipeline individuel voit naturellement moins de code, ce qui facilite la limitation du build et des tests à un projet. C'est un vrai avantage lorsque les services sont faiblement couplés et possédés par des équipes distinctes.
Le coût apparaît lorsqu'il existe des dépendances entre dépôts. Une modification d'une bibliothèque ou d'un contrat partagé peut exiger publication, mises à jour de plusieurs dépôts, compatibilité de versions et tests d'intégration. Google cite la stabilité comme avantage du multirepo, mais la visibilité et les migrations comme forces du monorepo. [1]
Frontières architecturales : un monorepo sans règles devient vite problématique
Un dépôt commun ne doit pas autoriser des imports libres entre tous les projets. Nx peut imposer des frontières de modules de manière déclarative avec des tags et des contraintes de dépendances, bloquant les imports non souhaités et le couplage imprévu. [6]
En multirepo, certaines frontières existent physiquement grâce aux dépôts séparés. Cela ne remplace pas l'architecture : les projets peuvent rester fortement couplés via API, bases de données, files de messages ou bibliothèques communes.
Accès et sécurité : le multirepo a souvent le modèle le plus simple
GitHub attribue rôles et permissions au niveau du dépôt. Des dépôts séparés correspondent donc naturellement aux situations où équipes ou prestataires doivent voir des bases de code différentes. Les rôles vont de Read à Admin. [11]
Dans un monorepo, CODEOWNERS et rulesets peuvent imposer des revues pour certains chemins et certaines équipes, mais ils servent à l'ownership et à l'approbation. Si une organisation exige une séparation stricte de la visibilité du code, des dépôts privés séparés correspondent généralement plus directement au modèle d'accès. [10][12]
Releases et déploiement : un dépôt ne signifie pas une release
Yarn décrit les workspaces comme plusieurs packages d'un projet et indique explicitement qu'ils peuvent être déployés indépendamment. Les multi-project builds de Gradle séparent aussi un système en sous-projets logiques avec leurs propres dépendances et tâches. [13][15]
Un monorepo peut donc avoir des pipelines et versions distincts pour applications, services et bibliothèques. Le multirepo offre cette séparation plus naturellement, mais nécessite davantage d'automatisation lorsque plusieurs releases doivent être coordonnées comme un seul changement produit.
Taille du dépôt et Git : les très grands monorepos demandent un outillage conscient
Google a décrit un monorepo interne contenant des milliards de lignes de code, tout en soulignant l'infrastructure personnalisée nécessaire. L'exemple prouve qu'un monorepo peut atteindre une très grande échelle, pas que cette échelle est gratuite ou adaptée à toutes les entreprises. [2]
Git actuel fournit `sparse-checkout` pour limiter le working tree à une partie des fichiers suivis. C'est un outil utile pour les grands dépôts, même si la documentation Git qualifie encore son comportement d'expérimental et susceptible d'évoluer. [9]
L'outillage de 2026 réduit le coût des deux approches
Dans l'écosystème JavaScript, les workspaces sont natifs et les graphes de projets, caches et CI sur les seuls projets affectés sont matures. Dans l'écosystème JVM, Gradle prend en charge les multi-project builds et les composite builds permettent de travailler sur plusieurs builds indépendants sans publier d'abord les artefacts. [13][15][16]
Ce dernier point compte aussi pour le multirepo : des dépôts séparés n'impliquent pas un environnement local complètement séparé. Les composite builds montrent comment conserver des frontières indépendantes tout en testant les projets ensemble. [16]
Les agents de code IA ajoutent un nouveau critère en 2026
La documentation Nx de 2026 avance que les agents de code profitent du contexte complet d'un monorepo, du graphe des projets, de vérifications rapides limitées aux éléments affectés et de frontières imposées. Nx étant un fournisseur d'outillage monorepo, il s'agit d'une perspective produit, pas d'une preuve indépendante. [3]
En pratique, le contexte partagé peut aider un agent à modifier un contrat et ses consommateurs dans une seule tâche. À l'inverse, le multirepo peut réduire le volume de code et les permissions disponibles dans une session d'agent. C'est un critère supplémentaire, pas un argument décisif à lui seul.
Quand choisir un monorepo
Le monorepo est particulièrement adapté lorsque applications et bibliothèques changent souvent ensemble, que de nombreuses équipes partagent des composants et que l'organisation a besoin de refactorings atomiques et d'un graphe de dépendances visible. L'étude Google soutient ces bénéfices par la visibilité, la découverte d'API, les exemples, les migrations et la centralisation des dépendances. [1]
Il faut en échange investir dans les frontières de modules, la CI sélective, le cache, l'ownership et l'automatisation. Sans ces contrôles, la croissance du dépôt ne fait que déplacer la complexité vers un pipeline géant. [4][5][6]
- Changements fréquents entre frontend, backend et bibliothèques.
- Beaucoup de code partagé et de standards communs.
- Besoin de refactorings atomiques.
- Toolchain unifiée ou compatible.
- Volonté d'investir dans graphe de dépendances, cache et CI sélective.
- Pas d'obligation forte de masquer la majorité du code aux autres équipes internes.
Quand choisir le multirepo
Le multirepo est un bon choix lorsque les domaines ont des frontières claires, que les équipes ont besoin de toolchains, cycles de vie et permissions indépendants et que les changements transversaux sont relativement rares. Google identifie la flexibilité des outils, le contrôle d'accès et la stabilité comme des avantages importants. [1]
Un autre signal fort est la présence de code à visibilité restreinte, d'exigences de conformité séparées ou de groupes de prestataires distincts. Le modèle de rôles de GitHub au niveau dépôt soutient directement cette séparation. [11]
- Forte autonomie des équipes et cycles de vie distincts.
- Langages, toolchains et processus de build différents.
- Exigences strictes d'accès ou de conformité.
- Peu de changements couvrant plusieurs projets.
- Contrats stables et gestion de versions mature.
- Les pipelines indépendants comptent plus qu'un graphe global de plateforme.
Modèle hybride et décision pratique en 2026
| Situation | Direction par défaut | Pourquoi |
|---|---|---|
| Changements fréquents sur plusieurs apps et bibliothèques | Monorepo | Refactorings atomiques et graphe de dépendances commun |
| Les équipes ne doivent pas voir tout le code | Multirepo | Les permissions de dépôt simplifient l'isolation |
| Toolchains et cycles de vie différents par équipe | Multirepo | Moins de standardisation centrale |
| Plateforme et bibliothèques fortement partagées | Monorepo | Meilleure visibilité et centralisation des dépendances |
| Beaucoup de petits services | Cela dépend | La fréquence des changements communs compte plus que le nombre de services |
| Exigences mixtes de domaine, accès et technologie | Hybride | Monorepos par domaine plus dépôts séparés sélectionnés |
Le choix n'a pas besoin d'être binaire. Une organisation peut conserver des monorepos par domaine pour les produits étroitement liés, des dépôts séparés pour des composants sensibles ou spécifiques à un client et des packages communs publiés via des registries. Les composite builds de Gradle illustrent même une façon de développer ensemble des builds indépendants. [16]
Avant une migration, mesurez la fréquence des changements transversaux, le nombre de dépendances partagées, la durée de CI, le nombre de dépôts touchés par une fonctionnalité typique, les exigences d'accès et le coût de coordination des releases. Ces données doivent guider la topologie.
