Monorepo ou repos séparés : voilà un sujet qui divise les développeurs et que peu de clients savent qu’il existe. Pourtant, ce choix structure beaucoup la maintenabilité de votre projet sur la durée.
Voilà ce que je pratique en 2026, après plusieurs essais dans les deux sens.
Ce que ces termes désignent
Un repo Git, c’est un dépôt de code versionné (sur GitHub, GitLab, Bitbucket). Quand on a plusieurs morceaux de code (le frontend, le backend, l’app mobile, les outils internes), deux philosophies existent.
Repos séparés (multi-repo) : chaque morceau a son propre dépôt. Le frontend dans un repo, le backend dans un autre, l’app mobile dans un troisième. C’est l’approche historique.
Monorepo : tous les morceaux sont dans le même dépôt, organisés en sous-dossiers (souvent appelés packages). On peut travailler sur tout en même temps depuis un seul endroit.
Aucune approche n’est universellement supérieure. Le bon choix dépend de votre projet et de votre équipe.
Quand utiliser des repos séparés
Trois cas où repos séparés est le bon choix.
Cas 1 : équipes indépendantes. Si l’équipe frontend ne touche jamais au backend et inversement, repos séparés clarifie les responsabilités. Chaque équipe gère son cycle de release, ses dépendances, sa CI/CD.
Cas 2 : technologies très différentes. Si vous avez un backend Python, un frontend React, et une app mobile Swift, les outillages sont radicalement différents. Les forcer dans un même repo crée plus de complexité que de bénéfice.
Cas 3 : projets vraiment indépendants. Si les deux ne partagent rien (pas de types, pas de bibliothèques communes, pas de besoin de modifications synchrones), il n’y a aucun intérêt à les rassembler.
C’est l’approche que j’utilise sur des projets simples : un site WordPress et son backend ont chacun leur repo, parce que les deux sont gérés par des outils différents et déployés sur des serveurs différents.
Quand utiliser un monorepo
Quatre cas où le monorepo prend tout son sens.
Cas 1 : code partagé entre plusieurs apps. Si votre frontend web et votre app mobile partagent des types TypeScript, des fonctions de validation, des règles métier, un monorepo permet de mettre ce code dans un package partagé. Modification une fois, déploiement partout.
Cas 2 : déploiements coordonnés. Si vous avez besoin que le backend et le frontend soient déployés en même temps (parce qu’une feature change l’API), un monorepo simplifie les pull requests qui touchent les deux ensemble.
Cas 3 : équipe full-stack. Quand les développeurs touchent au backend, au frontend, parfois à l’app mobile, un monorepo facilite la vie : un seul clone, un seul setup, un seul système de build.
Cas 4 : produit en évolution rapide. Sur un SaaS qui grandit vite, où les frontières frontend/backend bougent souvent, un monorepo permet d’évoluer sans débats inutiles sur ça va dans quel repo.
C’est l’approche que j’utilise sur les projets Next.js modernes avec Supabase : le frontend, les fonctions edge, les types partagés, parfois une app mobile React Native, tout dans un monorepo.
Les outils en 2026
Pour gérer un monorepo JavaScript / TypeScript, plusieurs options matures.
Turborepo. Probablement le plus utilisé en 2026 pour des stacks Next.js et React. Géré par Vercel, gratuit, intégration excellente.
pnpm Workspaces. Plus léger, plus simple, parfait pour des monorepos de taille moyenne. Mon choix par défaut.
Nx. Plus puissant, plus complexe, plus orienté entreprise. Pertinent sur des très gros monorepos (Angular, Node.js, plusieurs apps).
Lerna. Historique, en perte de vitesse, mais encore utilisé sur certains projets existants.
Pour des stacks PHP / WordPress, le monorepo n’a pas vraiment de standard équivalent. C’est typiquement repos séparés.
Le piège du faux monorepo
Une erreur que j’ai vue plusieurs fois : un monorepo créé sans vraie raison, juste parce que c’était à la mode. Résultat : du code séparé en sous-dossiers, mais aucun partage réel, aucun outillage spécifique, aucun gain.
Le monorepo n’est utile que si vous l’exploitez. Si chaque sous-projet a ses propres dépendances, ses propres builds, ses propres déploiements, et qu’aucun code n’est partagé, vous avez juste compliqué votre vie sans bénéfice.
Mon arbre de décision
Trois questions, dans cet ordre.
Question 1 : avez-vous du code à partager entre plusieurs apps ? Types, validations, règles métier, composants UI ? Si oui, monorepo. Si non, monorepo n’apporte rien.
Question 2 : votre équipe développe-t-elle plusieurs apps en parallèle, avec besoin fréquent de modifications coordonnées ? Si oui, monorepo. Si chaque app est gérée indépendamment, repos séparés.
Question 3 : votre stack est-elle homogène (tout en JavaScript / TypeScript, par exemple) ? Si oui, monorepo est jouable. Si vous mélangez Python, Go, JavaScript, repos séparés sont plus adaptés.
Mon usage en 2026
Sur les projets que je prends en main actuellement à Lille et alentour.
Pour les sites WordPress simples : repos séparés (le code WordPress dans un repo, les automation scripts dans un autre). Aucun intérêt à un monorepo.
Pour les apps Next.js plus Supabase : monorepo via pnpm Workspaces. Le frontend, les types partagés, parfois des packages utilitaires.
Pour les projets full-stack avec app mobile React Native : monorepo via Turborepo. Le web, le mobile, les types, partagés efficacement.
Pour les projets multi-tech (frontend React plus backend Django, par exemple) : repos séparés. Pas le même outillage, pas le même cycle de release.
Le vrai critère
Le bon choix monorepo vs repos séparés, ce n’est pas une question de modernité ou de philosophie.
C’est une question de besoin concret. Si vous avez besoin de partager du code régulièrement et de coordonner les déploiements, le monorepo apporte de vrais gains. Si vous avez juste plusieurs projets indépendants, les repos séparés restent plus simples.
Comme souvent en architecture logicielle, la simplicité gagne par défaut. Le monorepo ne se justifie que si la complexité qu’il ajoute (outillage, build pipelines, gestion des dépendances) est compensée par les bénéfices de partage et de coordination.
Pour un client non-technique
Si vous n’êtes pas développeur, vous n’avez pas vraiment à trancher. Faites confiance à votre prestataire pour ce choix d’organisation.
Mais demandez-lui pourquoi il a fait ce choix. Si la réponse est « c’est plus moderne », méfiez-vous. Si la réponse est « votre projet partage du code entre tel et tel composant, donc on optimise la maintenance », c’est sérieux.
Le bon choix d’architecture, c’est celui qui se justifie par le projet, pas par la mode.