Le monorepo expliqué : bénéfices, défis et bonnes pratiques

Vous travaillez sur un projet. Le frontend est dans un dépôt, le backend dans un autre, et les bibliothèques partagées dans un troisième. Vous jonglez entre les dépôts en espérant que les versions ne dérivent pas.

Maintenant, imaginez tout au même endroit. Un seul dépôt pour tous vos projets, un code partagé mis à jour instantanément, et des modifications propagées en un seul commit. 

Les monorepos rendent cela possible. C’est pourquoi de nombreuses grandes entreprises tech les utilisent, par exemple : 

• Google a conçu Piper avec une automatisation à grande échelle
• Meta a fait passer Mercurial à l’échelle
• Microsoft fait tourner Windows dans un monorepo Git avec VFS for Git
• Uber est même passé de mono > multi > retour à mono une fois l’outillage au niveau

Dans ce guide, vous découvrirez ce qu’est un monorepo, comment il se compare aux polyrepos, ainsi que les principaux bénéfices, défis et bonnes pratiques à connaître. 

Qu’est-ce qu’un monorepo ?

Un monorepo (dépôt monolithique) signifie un dépôt unique. Dans un monorepo, tous vos projets résident au même endroit, au lieu d’être répartis dans des dépôts distincts. 

Même côte à côte, les projets restent indépendants. Vous pouvez donc les construire, tester et déployer séparément, tout en bénéficiant du fait que tout soit regroupé en un seul espace.

À noter : une application monolithique et un monorepo ne sont pas la même chose :  

• Une application monolithique (monolithe) est une application logicielle construite et exécutée comme un bloc unique, souvent sur la même base de données. Elle peut vivre dans un monorepo (comme un projet parmi d’autres).
• Le monorepo stocke et gère le code de façon à ce que de nombreux projets coexistent dans le même dépôt tout en restant indépendants les uns des autres. 

Un monorepo n’est pas une application monolithique. En réalité, les monorepos fonctionnent très bien avec les microservices, car chaque service peut vivre dans le même dépôt tout en restant isolé.

Le concept de monorepo n’a rien de nouveau. 

Au début des années 2000, de grands acteurs de la tech ont adopté une approche « base de code partagée ». L’idée était simple : au lieu d’éparpiller le code dans de multiples dépôts, tout centraliser pour faciliter la collaboration.

Depuis, de grandes entreprises comme Google, Meta, Microsoft, Airbnb, Twitter (X), Uber et Pinterest ont adopté des monorepos pour gérer des bases de code volumineuses et évolutives.

Monorepo vs polyrepo

L’opposé d’un monorepo est un polyrepo (multirepo). Voyons la différence.  

Polyrepo

Un polyrepo, aussi appelé multirepo, signifie que chaque projet possède son propre dépôt distinct. 

Par exemple, le code du frontend peut être dans un dépôt, le backend dans un autre, et les bibliothèques partagées à part. Chaque dépôt est géré indépendamment avec ses propres dépendances et workflows.

Monorepo vs polyrepo. Image de l’auteur.

Coup d’œil sur les principales différences 

Voyons les différences clés entre monorepos et polyrepos : 

Bénéfices d’un monorepo

Les monorepos offrent de nombreux avantages. En voici quelques-uns : 

Meilleure collaboration et visibilité

Quand tout le code est au même endroit, chacun voit ce qui se passe. Vous pouvez consulter d’autres projets, en tirer des enseignements ou prêter main-forte si besoin. 

Le travail d’équipe s’en trouve fluidifié, la collaboration interéquipes s’améliore et les silos se réduisent.

Gestion des dépendances simplifiée 

Si plusieurs projets utilisent les mêmes bibliothèques mais conservent leurs propres versions, cela devient vite ingérable. 

Par exemple, un projet utilise une version plus ancienne quand un autre est déjà passé à la suivante. Le code devient plus difficile à exécuter, et vous passez du temps à corriger la même anomalie en plusieurs endroits.

Dans un monorepo, le code partagé vit à un seul endroit. Vous le mettez à jour une fois, et chaque projet bénéficie immédiatement du correctif. Fini la chasse aux décalages de versions ou aux conflits entre dépendances.

Commits atomiques et refactorings facilités 

Parfois, vous devez modifier un élément qui impacte plusieurs projets, par exemple une bibliothèque partagée. Avec un monorepo, vous mettez à jour ce code et appliquez les correctifs à tous les projets en un seul commit. 

Tous les projets restent ainsi synchronisés, sans risque de casser autre chose par inadvertance. 

Outillage et processus cohérents

Avec un seul dépôt, il n’y a qu’une manière de builder, tester et déployer. Inutile de mémoriser des configurations différentes selon les projets. Les nouveaux arrivants montent en vitesse plus sereinement. 

Itération plus rapide pour certains workflows

Si deux projets ou plus dépendent du même code (une bibliothèque ou un utilitaire partagé, par exemple), vous n’avez pas à mettre à jour chaque projet un par un dans des dépôts séparés. 

Avec un monorepo, vous mettez à jour une fois, et toutes les applications concernées reçoivent le changement immédiatement. Plutôt que de naviguer entre plusieurs dépôts, vous intervenez en un seul endroit et voyez l’impact partout à la fois.

Cela aide dans plusieurs situations courantes : 

• Lors d’un refactoring de code partagé, vous mettez à jour la bibliothèque et chaque service qui en dépend en bénéficie immédiatement. 
• Lors d’un déploiement de fonctionnalité transverse à plusieurs apps, vous pouvez tout livrer ensemble sans devoir coordonner plusieurs dépôts. 
• Même vos pipelines CI/CD gagnent en simplicité, car les builds et tests ciblent la même base de code au lieu d’être dupliqués.

Tout cela réduit les allers-retours, limite le changement de contexte et raccourcit les boucles de feedback. Résultat : des itérations plus rapides sans surcoût.

Défis d’un monorepo

Les monorepos apportent beaucoup, mais posent aussi des défis. Voici les principaux :

Problèmes de scalabilité et de performance 

À mesure que le dépôt grossit, les tâches quotidiennes comme le clonage, la recherche ou même l’ouverture dans l’éditeur ralentissent. Pourquoi ? Parce que Git n’a pas été pensé à l’origine pour des bases de code massives. Les grandes entreprises en ressentent vite les limites.

Des temps de build et de test plus longs

Comme tous les projets cohabitent, un petit changement peut déclencher beaucoup de travail supplémentaire sur votre pipeline CI/CD. Les développeurs se retrouvent à attendre la fin des builds ou des suites de tests avant de pouvoir merger ou publier leur code. 

Avec le temps, ces délais peuvent bloquer d’autres tâches et compliquer la livraison fréquente de petits changements.

Prenez Uber : quand leur monorepo Go a atteint des millions de lignes de code, certains ingénieurs attendaient des heures la fin des builds et validations avant de merger. 

Ils ont ensuite accéléré grâce à des outils comme Bazel et des files de builds personnalisées. Mais cela illustre à quelle vitesse la CI peut devenir un goulot d’étranglement quand tous les projets partagent un seul dépôt.

Risque de casser la branche principale 

La branche principale est la branche par défaut dans Git où vit la dernière version stable de votre code. Dans un monorepo, tout le monde travaille à partir de cette branche partagée ; si un changement la casse, toute l’équipe (voire l’entreprise) peut être bloquée jusqu’à la correction.

Prenons Airbnb. Ils pratiquaient un déploiement démocratique (tout ingénieur pouvait tester et mettre en production sans attendre un release manager). 

Au début, c’était rapide, mais avec la croissance, la gestion est devenue difficile car tout leur code se trouvait dans un unique monorepo volumineux. Les mises en production simultanées entraient en collision et compliquaient l’identification des causes.

Contrôle d’accès et sécurité

Limiter l’accès dans un monorepo est complexe car le code, les fichiers de configuration, scripts de build et autres ressources sont regroupés. Par défaut, tout développeur ayant accès au dépôt peut souvent voir et modifier ces composants. 

C’est bien pour collaborer ouvertement, mais problématique lorsque certaines parties (clés de sécurité, scripts de déploiement, algorithmes propriétaires) exigent des droits plus stricts.

Par exemple, une entreprise peut conserver le code de son site web dans le même monorepo. Les développeurs du site n’ont pas forcément besoin d’accéder aux identifiants de prod, mais comme tout vit au même endroit, il peut être difficile d’empêcher l’accès accidentel à ces fichiers sensibles.

Courbe d’apprentissage pour les nouveaux développeurs 

Pour les nouveaux arrivants, un dépôt vaste et multi-projets peut être intimidant. Trop de fichiers et de dossiers rendent difficile l’identification des éléments pertinents pour leur travail. 

Ils doivent aussi apprendre la structure, les outils et les dépendances avant de builder ou de contribuer sereinement, ce qui peut ralentir leur montée en puissance.

Bonnes pratiques pour gérer un monorepo

Pour que le monorepo fonctionne sans accroc, voici ce qu’il convient de mettre en place :

• Maintenez une organisation claire. Regroupez les projets liés, utilisez des noms explicites et facilitez la recherche d’informations.
• Évitez les branches de longue durée. Privilégiez le trunk-based development, avec des merges fréquents vers la branche principale pour réduire les conflits. 
• Figez les dépendances sur des versions précises pour garder tout le monde aligné. Mettez-les à jour à l’échelle du dépôt pour éviter les écarts. 
• Utilisez des outils de build modernes comme Bazel, Buck, Nx, Pants, Rush ou Lerna pour accélérer les builds et maîtriser la complexité des gros dépôts. 
• Évitez de recompiler ou retester tout le dépôt si seule une petite partie a changé. Utilisez des builds différentielles et des tests ciblés pour gagner du temps et accélérer les feedbacks. 
• Configurez Git CODEOWNERS dans votre plateforme VCS (ex. GitHub/GitLab) pour protéger les zones sensibles (scripts de déploiement, fichiers de configuration) et imposer les bonnes revues.

Outils populaires pour gérer un monorepo

Un monorepo peut devenir complexe à mesure que les projets grandissent. Pour simplifier, de nombreux outils aident à gérer les builds, les dépendances et l’organisation.  

Voici les plus courants :

Bazel 

Bazel est un système de build open source créé chez Google pour gérer des bases de code très vastes et complexes. 

Voici quelques fonctionnalités clés :

• Builds rapides : ne recompile que ce qui a changé, grâce à un cache avancé, une analyse optimisée des dépendances et l’exécution parallèle.
• Multilingue : fonctionne sur différentes plateformes et langages (Java, C++, Go, Android, iOS) sous Windows, macOS et Linux.
• Passe à l’échelle : gère de gros monorepos comme des ensembles de dépôts, adapté à tout type d’organisation.
• Extensible : permet d’ajouter de nouveaux langages et plateformes via son système d’extensions, soutenu par une communauté croissante.

Bazel est utilisé par des entreprises comme Google, Stripe et Dropbox pour builder et tester des infrastructures et applications critiques.

Nx

Nx est une boîte à outils open source pour gérer des monorepos, particulièrement populaire en JavaScript et TypeScript, avec un excellent support de React, Angular, Vue et NestJS. Il aide à organiser plusieurs applications et bibliothèques au même endroit tout en gardant des builds et tests rapides. 

Ses atouts principaux : 

• Orchestrateur de tâches intelligent : comprend les dépendances internes pour n’exécuter que l’essentiel et éviter le travail inutile.
• Compatible avec l’existant : exécute vos scripts actuels (npm, Gradle, etc.), sans changer votre setup.
• Nx Cloud : accélère le cycle de développement avec cache distant, CI plus rapide et outils de détection/correction automatiques.
• Outils additionnels : Nx Console apporte l’autocomplétion, un graphe de projet visuel et une gestion facilitée des tâches.

Lerna

Lerna est l’un des premiers et plus fiables outils pour gérer des monorepos JavaScript/TypeScript. Il facilite l’organisation de multiples packages dans un seul dépôt et aide à les builder, tester et publier.

De grands projets comme Create React App, Jest et NestJS ont utilisé Lerna pour gérer leurs packages. 

Parmi ses points forts : 

• Builds intelligents : évite les répétitions en réutilisant les résultats mis en cache au lieu de recompiler.
• Exécution rapide : exécute les tâches en parallèle tout en respectant l’ordre des dépendances.
• Cache distribué : partage des résultats de build entre développeurs et CI pour réduire les temps.
• Publication de packages : simplifie la publication sur npm avec versions partagées ou indépendantes.
• Passage à l’échelle : répartit les charges sur plusieurs machines sans configuration additionnelle.
• Visualisation : fournit des outils pour visualiser les liens entre projets et dépendances.
• Configuration légère : peu de réglages nécessaires, vous conservez vos scripts npm et les exécutez plus vite.

Pants

Pants est un système de build rapide et convivial, adapté aux monorepos de toutes tailles. Initialement centré sur Python, il supporte aussi Go, Java, Scala, Kotlin, Shell et Docker, avec d’autres langages en cours d’ajout. 

Il est donc largement utilisé et approuvé par des entreprises comme Coinbase, IBM, Slack, Salesforce et Orca Security, ainsi que par de nombreuses petites équipes.

Ses atouts principaux :

• Adoption facile : configuration minimale, infère automatiquement la plupart des métadonnées de build, donc moins de code passe-partout à maintenir.
• Builds sécurisées : prend en charge plusieurs résolutions de dépendances et lockfiles, pour des builds reproductibles et plus résistants aux attaques de la chaîne d’approvisionnement.
• Flexible : opère au niveau fichier, gère des graphes de dépendances complexes sans imposer une modularité stricte.
• Extensible : système de plugins en Python pour adapter l’outil à vos besoins.
• Conscient de Git : détecte les différences entre branches et n’exécute que les tests/builds affectés.

Rush 

Rush est un outil monorepo conçu pour les projets JavaScript qui doivent gérer plusieurs packages au sein d’un même dépôt.

Parmi ses fonctionnalités clés : 

• Conçu pour l’échelle : supports builds parallèles, incrémentaux et distribués pour garder l’efficacité, même sur d’énormes dépôts.

• Coordination d’équipe : maintient des versions de dépendances cohérentes, révise les nouveaux packages avant ajout, gère versions partagées ou indépendantes.
• Installations fiables : supporte pnpm (recommandé), npm et Yarn pour des installs prédictibles.
• Outil tout-en-un : gère installations, liens, builds, publication, versioning et changelogs au même endroit.

Rush est open source et éprouvé, utilisé par Azure SDK, HBO Max, OneDrive, SharePoint, Office 365 et Wix.

Turborepo

Turborepo est un système de build haute performance qui rend les monorepos JavaScript et TypeScript plus rapides et faciles à gérer. Il cible les problèmes d’échelle courants lorsque plusieurs apps et packages coexistent dans un même dépôt.

Fonctionnalités clés :

• Cache distant : sauvegarde les résultats de builds et tests pour éviter de refaire le même travail, réduisant le temps de CI.
• Ordonnancement des tâches : exécute les tâches dans le bon ordre et en parallèle sur tous les cœurs disponibles.
• Adoption incrémentale : s’ajoute en quelques minutes à n’importe quel dépôt, en réutilisant vos scripts package.json avec npm, Yarn ou PNPM.
• Clonage léger : permet aux développeurs de cloner uniquement les parties utiles du monorepo, réduisant le temps d’installation.
• Workflows optimisés : ne rebâtit que ce qui a changé, pour des boucles de feedback rapides.
• Expérience développeur familière : fonctionne avec les workflows Git standards, sans imposer de changer vos habitudes.

Moon

Moon est un outil rapide de gestion de monorepo, écrit en Rust. Il prend en charge JavaScript, TypeScript, Rust, Go et Ruby.

Fonctionnalités clés :

• Vitesse : utilise un cache intelligent et des builds incrémentales pour ne reconstruire que le code modifié.
• Collaboration : le cache distant partage les résultats entre les coéquipiers et la CI.
• Multiplateforme : fonctionne sous Linux, macOS et Windows.
• Graphe de projets : cartographie les dépendances pour organiser et faire évoluer de grands dépôts.

Lage

Lage est un exécuteur de tâches conçu pour les monorepos, axé sur la vitesse et l’efficacité. Il évite de rebâtir du travail déjà effectué.

Ses points forts :

• Évite le travail répété : réutilise les résultats localement ou depuis l’équipe, pour ne pas exécuter les builds deux fois.
• Mise en place rapide : configuration simple et fonctionnement cohérent selon les environnements.
• Mise en cache : cache local ou stockage externe pour accélérer les pipelines CI.
• Insights : inclut des outils de profilage des builds et de visualisation des graphes de dépendances.

Yarn workspaces

Yarn a introduit les workspaces pour faciliter la gestion de projets composés de nombreux packages dans un seul dépôt (un monorepo). 

Fonctionnalités clés :

• Pas d’installations dupliquées : les dépendances communes sont installées une seule fois à la racine, évitant des node_modules gonflés partout.
• Lien automatique : si un package dépend d’un autre dans le même dépôt, Yarn les relie automatiquement.
• Un seul lockfile : un unique yarn.lock pour tout le dépôt, garantissant des versions cohérentes.

Quand utiliser un monorepo

Voyons quelques scénarios fréquents où un monorepo vous sera utile : 

Équipes petites à moyennes avec code partagé

Si votre équipe est réduite et que beaucoup de code est réutilisé entre projets, un monorepo vous fera gagner du temps. Tout le monde travaille au même endroit et les bibliothèques partagées restent alignées sans effort supplémentaire : c’est tout bénéfice.  

Projets avec fortes interdépendances

Si vos projets dépendent étroitement les uns des autres, regroupez-les dans un dépôt. Les changements pourront ainsi se faire ensemble en un seul commit, sans jongler entre plusieurs repos.

Organisations visant un outillage et une visibilité unifiés

Avec un monorepo, vous pouvez mettre en place une configuration CI/CD unifiée. Cela ne signifie pas un unique pipeline pour tous, mais des pipelines optimisés pour n’exécuter que les builds et tests affectés par les derniers changements, ce qui économise du temps et des ressources.

Mais les monorepos ne conviennent pas à tous les cas. Si vos projets sont totalement indépendants, ou si vous avez besoin d’un contrôle d’accès strict (certaines équipes ne doivent pas voir certains codes), des polyrepos (dépôts multiples) seront sans doute plus adaptés.

Mettre en balance les pour et les contre

Voici un aperçu rapide des avantages et des inconvénients des monorepos :

En guise de conclusion

Un monorepo peut faciliter la collaboration, simplifier les dépendances et accélérer l’itération, mais il impose aussi de vrais défis de taille, performance et accès. L’adopter doit être un choix stratégique, selon l’organisation de vos équipes, le degré d’interdépendance de vos projets et votre capacité à investir dans le bon outillage.

Sans habitudes de collaboration solides et une responsabilité claire, même le meilleur setup monorepo peinera. Si vous explorez cette voie, commencez par consolider vos fondamentaux. Le cours Software Engineering Principles in Python est un excellent point de départ pour mettre en place les bonnes pratiques qui font la réussite d’un monorepo.