Monorepo

Stratégie de gestion du code où plusieurs projets, bibliothèques ou services cohabitent dans un même dépôt de versions, plutôt que dans des dépôts séparés.

En clair

Un monorepo est un dépôt de code unique qui héberge plusieurs projets : services, bibliothèques, applications front et back, parfois outils internes. Cela ne veut pas dire qu'ils sont fusionnés en un seul programme : ils restent distincts, mais partagent le même historique de versions, la même configuration de base et souvent le même outillage. C'est une décision d'organisation du code, indépendante de l'architecture applicative déployée. Le terme s'oppose au polyrepo, où chaque projet possède son propre dépôt, son propre cycle de versions et, fréquemment, son propre outillage à maintenir séparément.

Pourquoi c'est utilisé

Un dépôt unique facilite le partage de code entre projets, garantit une vue cohérente à un instant donné, et simplifie les changements transverses (une modification touchant plusieurs projets se fait en une seule fois, atomiquement). Il standardise l'outillage et les conventions, et rend la navigation plus simple, tout étant au même endroit. Mettre à jour une bibliothèque interne et tous ses consommateurs dans un seul commit évite la valse de versions et de publications qu'imposeraient des dépôts séparés. La revue de code y gagne aussi en contexte, puisque l'ensemble des changements liés apparaît dans une même demande.

En mission / dans la pratique

Le consultant qui rejoint une équipe en monorepo doit comprendre son outillage spécifique : gestion des dépendances internes, builds incrémentaux ne reconstruisant que ce qui a changé, et exécution ciblée des tests. Chez un grand compte hébergeant des centaines de projets, ces optimisations sont indispensables pour que le pipeline reste rapide malgré la taille du dépôt. Le quotidien implique de travailler sur un sous-ensemble du dépôt tout en respectant les frontières entre projets. À l'inverse, certains clients préfèrent des dépôts séparés (polyrepo), souvent pour donner plus d'autonomie à chaque équipe.

Pièges & bonnes pratiques

Sans outillage adapté, un monorepo devient lent : prévoyez des builds et des tests incrémentaux qui ne rejouent que ce qui dépend des fichiers modifiés. Maintenez des frontières claires entre projets pour éviter un couplage anarchique sous prétexte que « tout est accessible » : la proximité physique du code ne doit pas dispenser de dépendances explicites. Gérez finement les droits et la propriété par dossier, par exemple via un fichier de propriétaires de code. Le monorepo n'est ni meilleur ni pire que le polyrepo : c'est un compromis à choisir selon le contexte et la maturité de l'outillage.

À ne pas confondre

Le monorepo concerne l'organisation du code, pas le déploiement : on peut très bien y développer des microservices comme un monolithe. Il s'intègre dans la CI/CD, à qui il impose une exécution sélective des étapes.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté