Monorepo vs Polyrepo : bien choisir sa structure

Le débat monorepo polyrepo surgit dès qu'un projet commence à grandir. Gardez-vous tout votre code dans un seul dépôt Git, ou découpez-vous chaque service, paquet ou application dans son propre dépôt ? Il n'existe pas de réponse universelle « faites toujours ceci » ; tout dépend de la taille de votre équipe, de votre modèle de déploiement et de votre outillage. Dans cet article, je compare les deux approches avec des exemples concrets et je vous montre comment décider laquelle fera le moins mal sur votre propre projet.

Les bases : qu'est-ce qu'un monorepo et un polyrepo ?

Un monorepo est un dépôt de gestion de versions unique qui contient plusieurs projets, paquets ou services. Le frontend, le backend, les bibliothèques partagées et les scripts d'infrastructure arrivent tous avec un seul git clone. Une organisation typique ressemble à ceci :

my-company/
├── apps/
│   ├── web/
│   └── admin/
├── packages/
│   ├── ui/
│   └── config/
└── services/
    └── api/

Un polyrepo (multi-dépôt) conserve un dépôt Git distinct pour chaque unité indépendante : company-web, company-api, company-ui-kit, etc. Chaque dépôt porte son propre versionnage, sa propre chaîne CI et ses propres droits d'accès. Les deux approches sont utilisées en production depuis des années ; la vraie question est de savoir laquelle convient à vos contraintes.

Là où le monorepo brille

Le principal attrait d'un monorepo est qu'il offre une source unique de vérité. Lorsque vous modifiez un composant partagé, vous pouvez mettre à jour toutes les applications qui l'utilisent dans le même commit. Cela signifie des changements atomiques :

• Dépendances cohérentes : tous les projets utilisent les mêmes versions de bibliothèques, ce qui réduit les problèmes du type « ça marchait chez moi ».
• Partage de code facile : vous importez directement un paquet ui commun, sans publier un nouveau dépôt.
• Refactorisations transversales : en renommant un champ d'API, vous corrigez le serveur et tous les clients dans une seule pull request.
• Visibilité : avec tout le code au même endroit, la recherche, la navigation et la définition de standards deviennent plus simples.

Pour des bases de code fortement couplées qui évoluent souvent ensemble, un monorepo crée généralement moins de friction.

Là où le polyrepo brille

Le polyrepo repose sur des frontières claires et l'indépendance. Chaque équipe possède son dépôt, son rythme de publication et son calendrier de déploiement. Les avantages sont :

• Surface plus réduite : un développeur ne clone que le dépôt qui l'intéresse, donc le checkout et l'indexation restent rapides.
• Versionnage indépendant : chaque service marque sa propre version sémantique ; la publication d'une équipe n'attend pas une autre.
• Accès à granularité fine : seules les personnes autorisées atteignent le dépôt d'un service sensible.
• CI simple : la chaîne de chaque dépôt ne construit que ce dépôt, sans logique supplémentaire pour deviner « ce qui a changé ».

Pour des services réellement indépendants, écrits dans des langages différents ou suivant des cycles de vie distincts, un polyrepo s'écoule naturellement.

Le passage à l'échelle et l'impact de l'outillage

Ce qui tranche le plus souvent la question, c'est l'outillage. À mesure qu'un monorepo grandit, les configurations naïves ralentissent : vous ne voulez pas tout reconstruire à chaque commit. C'est pourquoi les monorepos s'appuient généralement sur un orchestrateur de tâches. Dans l'écosystème JavaScript/TypeScript, turborepo, nx et les workspaces pnpm sont courants ; ils ne construisent que les paquets affectés et mettent les résultats en cache.

# définition d'un workspace pnpm
# pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

Dans un polyrepo, le problème se déplace : les builds restent simples, mais la gestion des dépendances devient plus difficile. Vous devez publier la bibliothèque partagée dans un registre de paquets (par exemple un registre npm privé, ou un dispositif Composer/Packagist pour PHP), puis monter la version dans chaque dépôt consommateur. Cela augmente le risque de divergence de versions : le dépôt A peut utiliser la bibliothèque 2.1 tandis que le dépôt B est encore en 1.8.

Lequel choisir ?

Un cadre de décision pratique :

• Préférez un monorepo si vous êtes une équipe petite à moyenne, si vos bases de code sont fortement couplées, si vous faites souvent des changements transversaux et si vous êtes prêt à investir dans un outil comme nx ou turborepo.
• Préférez un polyrepo si vous avez plusieurs équipes indépendantes, si vos services tournent dans des langages et des cycles de vie différents, si vous avez besoin d'une séparation stricte des accès et si vous voulez un couplage lâche via des contrats d'API clairs.

Il existe une troisième voie : un juste milieu progressif. Beaucoup d'équipes regroupent quelques services liés dans un seul monorepo tout en gardant à part des produits totalement distincts. Vous n'avez pas besoin d'être « pur » ; tracez la frontière selon la fréquence à laquelle le code évolue ensemble.

Questions fréquentes

Un monorepo ralentit-il Git ?

Cela peut arriver sur de très grands historiques, mais pour la plupart des projets c'est sans problème. Si le dépôt devient vraiment énorme, vous pouvez utiliser un clone partiel avec git clone --filter=blob:none ou le sparse-checkout pour ne récupérer que les dossiers nécessaires.

Si j'utilise des microservices, ai-je besoin d'un polyrepo ?

Non. L'architecture (microservices) et la structure de dépôt (mono/poly) sont des décisions indépendantes. De grandes équipes gardent des dizaines de microservices dans un seul monorepo ; le déploiement indépendant reste possible.

Puis-je migrer de l'un à l'autre plus tard ?

Oui. Avec git subtree ou git filter-repo, vous pouvez fusionner ou scinder des dépôts tout en conservant l'historique. La migration n'est pas gratuite, mais elle est faisable ; ne surchargez donc pas la décision initiale.

Définissons ensemble la bonne structure pour votre projet. Nous pouvons examiner vos dépôts existants, votre chaîne CI et le flux de votre équipe, puis mettre en place la disposition monorepo ou polyrepo qui vous convient. Contactez-moi et discutons de vos besoins.