Qu'est-ce qu'un monorepo ?

Un monorepo est un dépôt Git unique qui regroupe plusieurs projets ou services, parfois des dizaines, voire des centaines. Pensez au codebase interne de Google (qui pilote Android, Search, Cloud et bien d'autres), ou à celui de Meta, avec ses millions de lignes réparties sur des dizaines de produits. À l'opposé, on trouve l'approche multi-repos : chaque projet dispose de son propre dépôt.

Le terme paraît anodin, mais le choix entre les deux façonne tout votre workflow : la manière de faire vos revues de code, la rapidité de votre CI/CD, le contrôle des accès, et même la façon dont votre équipe collabore au quotidien.

Les vrais avantages d'un monorepo

Des changements atomiques entre projets

C'est l'atout majeur du monorepo : lorsque le service A doit modifier son API et que le service B doit consommer cette API en même temps, vous validez les deux changements dans une seule transaction atomique. Plus de course où B fusionne avant A. Plus de « on corrigera ça au prochain sprint ». Cela surpasse le monde du multi-repos, où coordonner un changement inter-services exige deux PR, deux fusions, et des humains vigilants qui surveillent l'horloge.

Exemple : votre API backend ajoute un nouveau champ à une réponse. Votre application web frontend et votre application mobile doivent toutes deux le consommer. Dans un monorepo, les trois changements arrivent ensemble. En multi-repos, vous espérez que la PR backend fusionne avant les PR frontend, sinon votre branche principale reste temporairement cassée.

Outillage et dépendances partagés

Un seul .eslintrc, un seul prettier.config, une seule configuration de tests à l'échelle du monorepo. Les développeurs ne débattent pas des versions d'outils dépôt par dépôt : ils héritent de la cohérence. Une mise à niveau de Jest ou de TypeScript se fait une fois et concerne tout le monde. Les correctifs de sécurité dans les bibliothèques partagées se déploient uniformément.

En multi-repos, chaque projet maintient son propre outillage, et les développeurs passent du temps en discussions « faut-il mettre à jour ? » dépôt par dépôt.

Un refactoring plus simple

Déplacer du code entre services, extraire une logique partagée, fusionner des utilitaires dupliqués : dans un monorepo, ce sont de simples commits. En multi-repos, cela devient un exercice de coordination multi-PR. Pour des codebases qui évoluent vite (startups, équipes qui avancent rapidement), ces frictions s'accumulent.

Un graphe de dépendances clair

Avec des outils comme Nx ou Turborepo, un monorepo cartographie exactement quel service dépend de quoi. Vous connaissez l'impact avant de pousser. Le multi-repos laisse les développeurs dans le flou.

Les vrais coûts d'un monorepo

Une CI/CD complexe et lente

La taille du monorepo devient son fardeau. Un changement d'un seul caractère dans un module rarement utilisé peut, naïvement, déclencher les tests de toute votre codebase. Un monorepo de 50 services qui teste tout à chaque push est lent et coûteux.

C'est surmontable (tests différentiels, mise en cache des builds avec Nx, Bazel ou Buck), mais cela demande un investissement. Les petites équipes sautent souvent cette étape et subissent des builds de plus de 20 minutes.

Une surcharge d'outillage

Les monorepos réclament un outillage spécialisé. Nx, Bazel, Turborepo, Lerna : ces outils sont puissants mais longs à apprendre et à maintenir. Une petite équipe de quatre personnes n'en a peut-être pas besoin ; une équipe de 40 en a absolument besoin. Ratez la fenêtre de l'investissement, et votre monorepo se transforme en un bourbier lent et confus.

Des casse-têtes de contrôle d'accès

En multi-repos, vous pouvez accorder à l'ingénieur X l'accès à l'application mobile mais pas au service de facturation. Dans un monorepo, il obtient en général l'ensemble de la codebase (ou rien du tout). Un accès fin nécessite des scripts personnalisés ou une deuxième couche de vérification des permissions dans la CI.

C'est crucial pour les équipes soucieuses de sécurité et pour les grandes organisations. Un développeur junior ayant accès au code de paiement en production, c'est un cauchemar de gouvernance.

Des conflits de fusion à grande échelle

Vingt développeurs qui commitent sur des dizaines de projets dans un même dépôt, cela signifie davantage de branches en vol. Plus de changements en parallèle, c'est plus de conflits, surtout dans les fichiers de configuration partagés ou les répertoires de versions. Le multi-repos réduit la surface de collision.

La checklist : que choisir ?

Optez pour le monorepo si :

  • Équipe petite à moyenne (2 à 30 personnes) avec un produit fortement couplé (une application web + un backend + une application mobile servant tous la même base d'utilisateurs).
  • Les changements inter-services fréquents sont la norme (par exemple, les modifications de l'API backend entraînent des mises à jour du frontend).
  • Une infrastructure ou des composants partagés sont au cœur de votre produit (design system, bibliothèque d'authentification, modèles de données).
  • Vous êtes prêt à investir dans l'outillage (même une configuration modeste avec Nx ou Turborepo).
  • Vous maîtrisez les accès (équipe interne ; exigences de sécurité légères).

Exemple concret : une startup de cinq personnes qui développe un produit SaaS (frontend React, backend Node, utilitaires partagés). Un seul monorepo avec Nx garde tout le monde aligné, des changements atomiques et un outillage cohérent.

Optez pour le multi-repos si :

  • Équipe large et distribuée (50 ingénieurs et plus) ou plusieurs équipes indépendantes aux priorités différentes.
  • Services faiblement couplés (par exemple, un service backend détenu par l'équipe A, un service d'analytics détenu par l'équipe B, sans grande dépendance mutuelle).
  • Vous avez des besoins de contrôle d'accès fin (les développeurs juniors ne devraient pas voir l'infrastructure de production ; les partenaires ont besoin d'un accès limité aux API publiques).
  • Les services ont des stacks techniques très différentes (un service en Python, un autre en Go, un autre en Node ; chaque équipe possède sa stack et son dépôt).
  • La maturité et l'isolation comptent plus que les changements atomiques (par exemple, vous gérez des microservices déployables et versionnés indépendamment).

Exemple concret : une fintech mature avec dix services (paiements, KYC, règlement, tableau de bord, mobile). Chaque équipe possède le dépôt de son service. La communication inter-services passe par des API. Casser le service de paiements n'oblige pas à retester le tableau de bord.

L'approche hybride : un monorepo de monorepos

Beaucoup d'organisations ne tranchent pas de façon absolue pour l'un ou l'autre. Elles adoptent plutôt un monorepo par équipe ou par domaine produit. Votre équipe frontend maintient un monorepo (web, mobile, composants partagés). Votre équipe backend en maintient un autre (service API, service worker, bibliothèques partagées). Les deux monorepos communiquent via des API ou des packages privés partagés.

Vous obtenez ainsi des changements atomiques et un outillage partagé au sein d'une équipe, tout en gardant les équipes découplées et en empêchant le chaos d'une équipe de contaminer une autre. Cela passe mieux l'échelle qu'un monorepo unique à plus de 500 ingénieurs, et c'est plus simple qu'un multi-repos strict si vous conservez de l'infrastructure partagée.

En résumé

Les monorepos ne sont intrinsèquement ni meilleurs ni pires : c'est un compromis. Ils vous offrent des changements atomiques, de la cohérence et un refactoring facilité, au prix d'une CI complexe et d'une surcharge d'outillage. Pour une petite équipe rapide qui construit un produit fortement intégré, c'est un gain de productivité. Pour une grande organisation avec des services indépendants et des frontières de sécurité, ils deviennent un handicap.

Partez de la taille de votre équipe et de la forme de votre produit. Posez-vous la question : « Allons-nous fréquemment modifier plusieurs services ensemble ? » Si oui, penchez pour le monorepo. Si les services sont réellement indépendants, le multi-repos garde les choses simples. Et si vous hésitez, une approche hybride (un monorepo par équipe) coupe la poire en deux et l'emporte souvent dans la pratique.

Le meilleur choix est celui qui permet à votre équipe d'avancer vite sans se battre contre ses outils.

À lire aussi : vous hésitez encore sur l'application elle-même ? Consultez Natif, web ou hybride : comment construire votre application.