# Monorepo vs polyrepo: l'architecture pour votre équipe URL: https://formula.dog/fr/journal/monorepo-vs-polyrepo-architecture Type: blog Locale: fr Published: 2026-08-29 Updated: 2026-09-02 --- > Un monorepo gagne quand les équipes partagent du code régulièrement ; un polyrepo quand elles sont indépendantes. Découvrez le cadre pratique pour décider. Monorepo vs polyrepo revient sur la table chaque fois que votre équipe d'ingénieurs grandit plus vite que vos temps de build. La réponse courte : un monorepo gagne quand les équipes partagent du code régulièrement et coordonnent des changements sur une surface commune ; un polyrepo gagne quand les équipes sont vraiment indépendantes et déploient sans jamais s'attendre les unes les autres. Tout le reste dépend du niveau de couplage réel de vos services et de la charge de coordination que vous acceptez. Cet article passe en revue les vrais compromis, les signaux qui pointent dans une direction ou l'autre, et un cadre pratique pour trancher. ## La vraie question, c'est le couplage, pas le nombre de repos La plupart des débats monorepo vs polyrepo commencent par la mauvaise question. Le nombre de repos n'est pas le sujet. Le sujet, c'est si vos équipes ont besoin de bouger ensemble. Si les changements de l'équipe A obligent régulièrement l'équipe B à mettre à jour quelque chose dans le même cycle de release, vous avez du travail fortement couplé. Un seul repo pour ça, c'est presque toujours la réponse plus propre. Si l'équipe A et l'équipe B déploient chacune de leur côté, touchent des parties différentes du système et ne s'attendent jamais, des repos séparés ont du sens vrai. Le pire des mondes possibles : deux repos séparés pour du code qui doit encore déployer ensemble. Vous avez tous les coûts de coordination d'un monorepo sans aucun des bénéfices. Vos équipes se retrouvent à ouvrir des PRs dans le repo A et le repo B en même temps, en espérant que les deux passent CI au même moment. Ce schéma est étonnamment courant chez les orgas qui ont choisi polyrepo tôt et qui ont laissé leurs services devenir plus interdépendants que prévu. Le premier pas avant de choisir quoi que ce soit : tracer une simple carte des dépendances. Listez chaque service ou package que vous maîtrisez et dessinez des flèches où l'un dépend de l'autre. Si les flèches forment une grappe dense, cette grappe doit vivre dans un seul repo. ![Software development team gathered around a whiteboard reviewing code architecture diagrams](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp) ## Pourquoi Google, Meta et Microsoft se sont tous arrêtés sur des monorepos à grande échelle Google garde la majorité de son code dans un seul repository estimé à plus de 80 TB de données et 2 milliards de lignes de code. Meta et Microsoft font pareil pour leurs surfaces de produit principal. Ce n'est pas parce que les grandes boîtes adorent la complexité : c'est que, à l'échelle, garder les dépendances en sync travers des centaines de repos devient un problème d'engineering full-time. Un changement d'API partagée simple peut obliger des updates coordonnées sur 40 repos différents. Dans un monorepo, c'est une pull request. Une review. Un merge. Un rollback si ça tourne mal. Selon une étude de Sourcegraph, 63% des entreprises avec 50 développeurs ou plus utilisent maintenant un monorepo pour au moins une partie de leur codebase, en forte hausse par rapport aux chiffres d'il y a trois ans. Le bénéfice concret qui compte le plus : les commits atomiques. Quand un changement cassant dans votre API nécessite aussi des updates frontend et backend, un monorepo vous laisse poser les trois changements dans une seule PR, les tester ensemble et les rollbacker tous les trois en une seule unité si ça tourne mal. Avec polyrepo, vous ouvrez trois PRs séparées, attendez trois cycles de review séparés et gérez une fenêtre où vos services tournent avec des versions qui ne matchent pas. Une équipe d'engineering a rapporté avoir basculé de déploiements occasionnels à plus de 40 releases d'app par semaine après avoir migré ses packages frontend dans un monorepo Nx. Les mises à jour Angular qui prenaient précédemment des mois sont devenues des tâches routinières que les équipes accomplissaient sans arrêter autre chose. ## Le coût caché de coordination du polyrepo Polyrepo a des vrais avantages qui valent la peine d'être pris au sérieux. Chaque équipe contrôle son propre pipeline CI/CD, sa propre cadence de release, ses propres contrôles d'accès. Les équipes sécu et compliance les aiment souvent : l'accès au code peut être restreint à du personnel nommé par repo, ce qui compte dans les industries régulées. Les composants open-source vivent plus proprement dans leurs propres repos publics sans exposer le code interne. Pour les équipes qui sont vraiment indépendantes, ces avantages sont réels. Une petite équipe services qui possède un data pipeline tournant selon son propre schedule et touchant aucun code partagé a peu à gagner de s'asseoir dans un plus large monorepo. Mais les orgas polyrepo accumulent silencieusement des coûts qui ne sont pas apparus dans la décision originale. Maintenir les versions de dépendance entre repos devient sa propre discipline. Une lib utilitaire partagée vieillit dans certains repos pendant qu'elle reste actuelle ailleurs. Quelqu'un doit tenir à jour une matrice de compatibilité juste pour savoir quelle version de quelle lib marche avec quelle version de quel service. Une métrique qui vaut la peine de connaître : le temps médian de cycle PR dans les monorepos tourne autour de 19 heures, contre environ 2 heures dans les polyrepos. Les PRs dans les monorepos tendent à être plus grandes parce qu'elles touchent plus de surfaces, ce qui ralentit la review. Mais quand un changement polyrepo demande trois PRs coordonnées sur trois repos pour poser une seule feature, le temps de cycle agrégé dépasse souvent la figure du monorepo de toute façon : avec le risque ajouté de merges partiels laissant les services dans des états inconsistants. Le schéma qui attrape les équipes par surprise : « on a commencé avec des repos séparés pour l'indépendance, mais là chaque release oblige à ouvrir des PRs à quatre endroits ». À ce point, vous avez le pire des deux mondes. ## Les temps de build ne sont plus le facteur décisif depuis 2024 L'objection classique aux monorepos, c'était le temps de build. Si votre repo a 200 packages et vous changez un fichier, vous voulez vraiment rebuild les 200 ? Cet argument a expiré quelque part autour de 2022-2024, selon votre stack. Les outils de build modernes utilisent des caches aware du contenu. Ils ne rebuilent que ce qui a changé et sautent tout ce qui a des inputs identiques. Un changement au package `payments` ne déclenche pas un rebuild de `design-system` si rien dans `design-system` a changé. GitHub Actions offre 10 GB de stockage de cache gratuit avant que vous ayez besoin d'une solution de cache distant payante. Turborepo arrange la plupart des équipes JavaScript et TypeScript bien jusqu'à environ 20 packages. La config est un seul `turbo.json`, le cache distant marche sur Vercel gratuitement ou auto-hébergé et la courbe d'apprentissage est assez faible qu'une équipe peut être productive en une journée. Au-delà de 20 packages, ou quand le build s'étend sur plusieurs langages, l'approche plus structurée d'Nx tend à justifier la courbe d'apprentissage plus raide. Nx ajoute la génération de code, la distribution automatique CI et le tracking fin-grain des dépendances qui devient de plus en plus précieux à mesure que le repo grandit. Pour les très grandes orgas exécutant des milliers de packages sur plusieurs langages, Bazel (le système de build open-source de Google) est le seul outil conçu pour cette échelle. Le coût de mise en place est significatif et nécessite presque toujours une équipe d'engineering de plateforme dédiée. ![Multiple parallel deployment pipelines flowing from a central codebase, abstract DevOps infrastructure concept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp) ## Quatre questions qui tranchent pour votre équipe Il n'y a pas de bonne réponse universelle, mais il y a un cadre fiable. **1. Vos équipes partagent-elles du code qui change fréquemment ?** Si oui : un système de design partagé, une lib de client API partagée, une logique d'authentification partagée : un monorepo est presque toujours le meilleur choix. Garder une lib partagée synchronisée sur plusieurs repos demande une discipline constante et drifts presque toujours. **2. Vos équipes déploient-elles indépendamment ?** Si l'équipe A's déploie son service mardi et l'équipe B's jeudi sans aucune coordination nécessaire, polyrepo gagne sa place. Si relâcher un service oblige une release simultanée d'un autre, ce coût de couplage doit entrer dans l'équation. **3. Combien d'ingénieurs touchent cette codebase ?** Au-dessous de 20, la structure du repo importe moins qu'on le pense. Au-dessus de 50, les coûts de coordination du polyrepo commencent à s'accumuler visiblement. Au-dessus de 200, le cas pour un monorepo devient très fort sauf si les équipes sont vraiment silées par produit et techno. **4. Avez-vous des exigences sécu ou compliance qui isolent du code par équipe ?** Dans les industries régulées : finance, santé, certains contextes gouvernementaux : l'accès au code doit peut-être être restreint à du personnel nommé. Cette contrainte peut surpasser les autres réponses. Si l'isolation dure du code est une exigence de compliance, polyrepo n'est pas un choix, c'est une contrainte. Si vous avez répondu « oui » à la question 1 et « non » à la question 4, un monorepo est presque certainement le bon appel. Si vous avez répondu « non » à la question 1 et « oui » à la question 2, polyrepo est une position défendable. Tout le reste c'est un jugement d'appel. ## Ce sur quoi la plupart des équipes qui grandissent se retrouvent réellement Très peu d'orgas d'engineering matures opèrent à l'un ou l'autre extrême. Le pattern qui apparaît le plus souvent : un monorepo pour le produit principal (frontend, libs partagées, services backend qui dépendent les uns des autres) et des repos séparés pour des composants vraiment indépendants. Un data pipeline qui tourne selon son propre schedule et ne partage aucun code avec le produit principal doit rester en dehors du monorepo. Un outil interne maintenu par une équipe d'une seule personne doit rester en dehors. Une lib open-source qui a besoin de visibilité publique doit rester en dehors. Ce n'est pas un compromis. C'est la réponse correcte à une question qui a rarement une réponse binaire propre. Gardez ensemble ce qui a besoin de bouger ensemble. Séparez ce qui est vraiment indépendant. La chose importante c'est de faire la décision délibérément, pas par défaut. La plupart des équipes qui se retrouvent avec une sprawl de polyrepo ne l'ont pas choisi : elles ont commencé un service, puis un autre, puis un autre, et n'ont jamais arrêté pour se demander si ces services devaient vivre ensemble. ## Les outils qui font vraiment marcher l'une ou l'autre approche **Pour les monorepos :** - Nx : ensemble de features le plus fort, bon pour les builds polyglottes et les équipes au-delà de 20 packages. Courbe d'apprentissage plus raide mais scale plus loin. - Turborepo : plus simple à commencer, excellent pour les équipes JS/TS en-dessous de 20 packages. Caching natif Vercel ou options auto-hébergées. - Bazel : pour les très larges repos multi-langues à l'échelle enterprise. Investissement significatif de mise en place requis. **Pour les polyrepos :** - Une discipline de versioning pour les libs partagées n'est pas optionnelle. Sans semantic versioning et un processus de changelog consistant, le drift de dépendance devient la norme en six mois. - Un tooling CI/CD qui déclenche les pipelines cross-repo quand une dépendance partagée change. GitHub Actions le supporte via des événements `workflow_dispatch` et `repository_dispatch` entre repos. - Un registre de dépendances (npm private registry, GitHub Packages, Artifactory) pour manager la distribution des packages partagés. Biscuit peut récupérer le fichier de config. L'appel sur lequel utiliser reste quand même basé sur ces quatre questions. ![Developer working at dual monitor setup reviewing pull requests in a dark home office](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp) ## FAQ ### Quand devrait-on choisir un monorepo plutôt qu'un polyrepo ? Optez pour un monorepo quand vos équipes partagent du code régulièrement, ont besoin de coordonner les changements dans le même cycle de release, ou travaillent sur des services fortement couplés. ### Quels sont les principaux avantages d'un monorepo ? Les principaux avantages incluent les commits atomiques, une synchronisation simplifiée des dépendances, une révision de code centralisée, et la possibilité de refactoriser à grande échelle sans coordination entre repos. ### Quel est le coût caché d'un polyrepo ? Le polyrepo accumule des coûts de coordination silencieux : versioning des dépendances, drift de code entre repos, matrices de compatibilité à maintenir, et risque d'avoir des services en versions non-matchées. ### Est-ce que les temps de build sont toujours un problème pour les monorepos ? Non, ce problème a été largement résolu en 2022-2024 avec des outils comme Turborepo et Nx, qui utilisent le caching aware du contenu et ne rebuilent que les packages qui ont changé. ### Quelle est la taille d'équipe où le choix monorepo devient plus pertinent ? Au-dessus de 50 ingénieurs, les coûts de coordination du polyrepo commencent à s'accumuler visiblement. Au-dessus de 200, le cas pour un monorepo devient très fort sauf si vos équipes sont complètement silées. ### Quel outil de monorepo choisir : Nx, Turborepo ou Bazel ? Turborepo convient jusqu'à 20 packages en JavaScript/TypeScript. Nx scale mieux pour plus de 20 packages ou builds polyglots. Bazel s'adresse aux très grandes organisations avec des milliers de packages. ### Peut-on avoir un monorepo pour le produit principal et des polyrepos pour le reste ? Oui, c'est d'ailleurs le pattern le plus courant en production. Gardez ensemble ce qui a besoin de bouger ensemble (produit principal) et séparez ce qui est vraiment indépendant (data pipelines, outils internes, libs open-source).