Une agence qui gère vingt sites WordPress se retrouve vite face à une question d’organisation qui semble anodine mais qui pèse lourd sur la durée : faut-il un dépôt Git par site, ou un seul grand dépôt qui contient tout ? La question revient à chaque nouvelle recrue, à chaque audit de code, et généralement personne n’a de réponse tranchée parce que les deux options fonctionnent, avec des compromis différents.
Nous avons accompagné une agence qui gérait ses thèmes clients dans des dépôts séparés pendant quatre ans, avant de migrer vers un monorepo partiel pour son socle commun. L’expérience nous a appris que la bonne réponse dépend moins du nombre de sites que du volume de code réellement partagé entre eux.
Le dépôt par projet : simplicité et isolation
Un dépôt Git par site client reste l’option par défaut, et pour de bonnes raisons. Chaque client a son propre historique, ses propres accès (utile quand un client externe ou un sous-traitant doit intervenir sans voir le code des autres), et son propre cycle de déploiement indépendant. Un bug corrigé sur un site ne casse jamais un autre projet par accident.
L’inconvénient apparaît quand le thème maison, le plugin utilitaire ou la configuration de build sont dupliqués d’un dépôt à l’autre. Corriger un bug dans le module de formulaire commun implique alors de le répliquer manuellement dans quinze dépôts, avec un risque réel de désynchronisation : certains sites reçoivent le correctif, d’autres l’oublient.
Le monorepo : un socle commun versionné une seule fois
Un monorepo regroupe plusieurs projets — thème parent partagé, plugins maison, configuration de build — dans un seul dépôt Git, avec des sous-dossiers par composant. Le gain le plus concret : un correctif sur le plugin commun se propage à tous les sites qui l’utilisent dès qu’ils tirent la branche principale, sans copier-coller.
agence-monorepo/
├── packages/
│ ├── theme-parent/ # thème parent partagé, hérité par chaque site
│ ├── plugin-formulaires/ # plugin maison utilisé par tous les clients
│ └── build-config/ # configuration @wordpress/scripts commune
├── sites/
│ ├── client-boulangerie/
│ ├── client-cabinet-avocats/
│ └── client-association/
└── package.json # workspaces npm référençant packages/*
Ce que le monorepo facilite vraiment
- Une seule pull request pour corriger un bug transverse, relue une seule fois ;
- Des workspaces npm ou pnpm qui référencent les paquets internes sans passer par un registre privé ;
- Une CI unique qui sait quels sous-dossiers ont changé et ne rejoue que les tests concernés.
Ce que le monorepo coûte en pratique
Le monorepo n’est pas gratuit. Il faut mettre en place un outillage capable de détecter les changements par dossier (sinon chaque commit relance la CI complète sur tous les sites, ce qui devient très lent passé une dizaine de projets). Il faut aussi gérer finement les accès Git si un client externe doit contribuer : un accès en lecture-écriture sur le dépôt entier expose le code de tous les autres clients, ce qui est rarement acceptable contractuellement.
Le poids du dépôt grossit également avec le temps, en particulier si des médias ou des exports de base de données sont versionnés par erreur — un problème qui se voit davantage dans un monorepo, où le dépôt entier grossit d’un coup, que dans des petits dépôts isolés.
Le choix pratique : dépendances par sous-dossier
Notre recommandation, après plusieurs migrations dans un sens et dans l’autre : le monorepo se justifie à partir du moment où au moins trois ou quatre projets partagent un socle de code identique et évolutif (thème parent, bibliothèque de blocs, plugin de fonctions communes). En dessous de ce seuil, la duplication reste gérable et le dépôt par projet évite la complexité d’outillage.
Quand on hésite, on regarde le journal Git des six derniers mois : si un même correctif a dû être recopié à la main dans plus de deux dépôts, c’est le signal qu’un monorepo partiel — juste pour le socle commun, pas pour tout — ferait gagner du temps.
Une option intermédiaire : les sous-modules Git
Entre les deux extrêmes, les sous-modules Git (git submodule) permettent de référencer un dépôt de socle commun depuis chaque dépôt de site, à une révision figée. Le socle reste versionné une seule fois, mais chaque site choisit quand il met à jour sa référence. C’est plus souple qu’un monorepo strict, au prix d’une commande Git réputée peu intuitive et d’un oubli fréquent de mise à jour des sous-modules après un clone.
Notre verdict
Il n’existe pas de bonne réponse universelle, seulement un seuil de partage de code à partir duquel la duplication devient plus coûteuse que l’outillage d’un monorepo. Pour une agence qui démarre avec quelques sites indépendants, le dépôt par projet reste le choix le plus simple. Pour une agence qui a identifié un socle commun stable et partagé par plusieurs clients, un monorepo partiel — limité à ce socle — offre le meilleur compromis entre partage de code et isolation des projets.
