Monorepo vs polyrepo

La manière dont vous organisez votre code en dépôts ressemble à une décision de plomberie, mais elle conditionne discrètement la façon dont votre équipe collabore, livre et raisonne sur le système. Un monorepo regroupe tout dans un seul dépôt ; un polyrepo donne à chaque service ou application le sien. Aucune des deux approches n'est universellement juste, et les opinions les plus tranchées que l'on trouve en ligne ignorent généralement votre stade réel et la taille de votre équipe. Voici comment aborder la question avec lucidité.

Ce qu'un monorepo vous apporte

Un monorepo réunit votre application web, votre application mobile, votre backend et vos bibliothèques partagées sous un même toit. Les avantages sont concrets, surtout pour les petites équipes :

• Des changements atomiques. Mettez à jour un type partagé et tous ses consommateurs dans la même pull request. Fini la danse de coordination entre dépôts.
• Une source de vérité unique pour l'outillage. Une seule configuration de lint, de formatage et de CI, au lieu d'une dérive progressive sur une dizaine de dépôts.
• Le partage de code sans friction. Les packages TypeScript partagés sont de simples imports, pas des versions publiées qu'il faut incrémenter et réinstaller partout.
• Un refactoring facilité. Vous pouvez retrouver et corriger chaque appel d'une fonction parce que tout est sous vos yeux.

Des outils comme Turborepo et Nx rendent cela viable en mettant les builds en cache et en n'exécutant du travail que pour les parties qui ont réellement changé.

Ce qu'un monorepo vous coûte

Les compromis apparaissent à mesure que vous grandissez. Les temps de build et de CI peuvent exploser sans un cache intelligent. Le contrôle d'accès est moins granulaire : difficile de donner à un prestataire l'accès à un seul service sans lui ouvrir toute la codebase. Et une configuration naïve recompile et teste tout à chaque changement, ce qui devient vite lent. Un bon outillage atténue tout cela, mais il faut y investir délibérément.

Ce qu'un polyrepo vous apporte

Des dépôts séparés offrent à chaque service des frontières nettes. Une équipe possède son dépôt de bout en bout, déploie selon son propre calendrier et ne peut pas s'aventurer accidentellement dans les rouages d'une autre équipe. Le contrôle d'accès est naturellement granulaire, la CI de chaque dépôt est légère et rapide, et l'impact d'un changement problématique reste contenu.

Le coût, c'est la coordination. Un changement qui touche plusieurs services devient plusieurs pull requests sur plusieurs dépôts qui doivent être mergées dans le bon ordre. Le code partagé doit être publié sous forme de packages versionnés, et la dérive de versions entre dépôts devient une vraie source de bugs. Maintenir un outillage cohérent sur de nombreux dépôts demande un effort constant.

Comment décider concrètement

La réponse honnête est que la taille de l'équipe et le couplage comptent davantage que l'idéologie :

1. Phase de démarrage ou équipe sur un seul produit ? Optez pour un monorepo. Les gains en coordination sont considérables quand tout le monde touche à tout, et c'est le point de départ le plus simple.
2. Plusieurs équipes indépendantes avec des services genuinement distincts et des cadences de livraison séparées ? Les frontières du polyrepo réduisent les frictions et permettent aux équipes d'avancer de façon autonome.
3. Quelque part entre les deux ? Commencez avec un monorepo, et n'extrayez un service dans son propre dépôt que lorsque sa propriété et son cycle de livraison divergent vraiment du reste.

Le choix pragmatique par défaut

Pour la plupart des startups avec lesquelles nous travaillons, un monorepo avec un bon cache de build est le choix qui s'impose. Il correspond au fonctionnement des petites équipes — tout le monde dans le même code, qui livre ensemble — et repousse la complexité de coordination du polyrepo au moment où vous aurez réellement la structure d'équipe qui en bénéficie. Vous pouvez toujours scinder plus tard ; fusionner à nouveau des dépôts est bien plus douloureux que d'en extraire un seul.

Si vous mettez en place une codebase autour de laquelle vous allez faire grandir une équipe, parlez-nous-en.