Un seul dépôt pour tout, ou un dépôt par service ? Le choix structure ton quotidien de dev pour des années. Voici quand le monorepo est un cadeau, quand il devient un poids, et comment je tranche.
Pour un produit unique avec front, back et code partagé — le cas d'un SaaS typique — le monorepo est presque toujours le bon choix. Le partage de types entre front et back, à lui seul, justifie souvent la structure.
Des outils comme Turborepo ne rebuild/retestent que ce qui a changé, avec un cache partagé : la CI d'un gros monorepo reste rapide.
Des équipes qui ne partagent rien gagnent à des dépôts séparés, avec permissions et rythmes propres.
Un service Go, un front JS, un data pipeline Python : l'outillage commun devient un casse-tête.
Sans cache ni build incrémental, chaque push rebuild tout. Le monorepo devient lent.
Des services qui doivent se déployer à des rythmes très différents vivent mieux séparés.
Le CLAUDE.md par sous-dossier, c'est exactement le point de les bases de Claude Code.
Il n'y a pas de vainqueur universel : le monorepo brille sur un produit unique à code partagé, le multi-repo sur des services vraiment indépendants. Dans le doute, commence groupé et extrais plus tard. Le pire choix, c'est de changer d'avis tous les six mois.
Turborepo docs ↗