Retour aux ressources
// technique · structure

Monorepo ou multi-repo

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.

Technique21 juil. 2026~7 min · intermédiaire
monorepopnpmTurborepoworkspacesCI
01

Les deux modèles

monorepo

tout au même endroit.

code partagé sans publier de paquet
un changement transverse en un commit
refactor global atomique
multi-repo

un dépôt par service.

frontières et permissions nettes
CI plus simple par dépôt
déploiements indépendants
02

Quand le monorepo gagne

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.

arborescencecopier
# un monorepo type (pnpm workspaces + turborepo)
my-product/
apps/
web/ # le front Next.js
api/ # le backend
packages/
ui/ # composants partages
config/ # tsconfig, eslint communs
types/ # types partages front <-> back
turbo.json # orchestre build/test/lint entre les paquets
pnpm-workspace.yaml

Des outils comme Turborepo ne rebuild/retestent que ce qui a changé, avec un cache partagé : la CI d'un gros monorepo reste rapide.

03

Quand il devient un poids

01
Équipes cloisonnées

Des équipes qui ne partagent rien gagnent à des dépôts séparés, avec permissions et rythmes propres.

02
Techs très différentes

Un service Go, un front JS, un data pipeline Python : l'outillage commun devient un casse-tête.

03
CI qui rampe

Sans cache ni build incrémental, chaque push rebuild tout. Le monorepo devient lent.

04
Cycles de release

Des services qui doivent se déployer à des rythmes très différents vivent mieux séparés.

04

Comment je tranche

un seul produit, une équipe, du code partagé → monorepo, sans hésiter ;
des services indépendants, des équipes séparées → multi-repo ;
dans le doute, commence en monorepo : c'est plus facile de sortir un service que d'en fusionner deux ;
quel que soit le choix, garde un CLAUDE.md par dossier pour cadrer l'agent.
i

Le CLAUDE.md par sous-dossier, c'est exactement le point de les bases de Claude Code.

05

Sources & ressources

01pnpm — WorkspacesLa doc officielle du pnpm-workspace.yaml et du protocole workspace: pour lier les paquets internes.02Turborepo — Structuring a repositoryL'arborescence apps/ + packages/ décrite plus haut, telle que la recommande Turborepo.03Turborepo — Remote CachingLe cache partagé entre l'équipe et la CI : la réponse concrète au « monorepo = CI lente ».04Nx — Getting startedL'alternative à Turborepo : graphe de dépendances, tâches affectées, cache — monorepo comme polyrepo.05monorepo.toolsComparatif des outils de monorepo, fonctionnalité par fonctionnalité — utile pour trancher l'outillage.06Potvin & Levenberg — Why Google Stores Billions of Lines of Code in a Single Repository (CACM, 2016)Le monorepo à l'extrême : changements atomiques et refactors globaux, mais au prix d'un outillage maison.07GitHub Actions — Workflow syntax (paths / paths-ignore)Filtrer les workflows par chemin : le minimum vital pour qu'un monorepo ne rejoue pas toute la CI à chaque push.

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.