Introduction : Pourquoi la gestion multi dépôt est un défi stratégique
Dans un monde où les applications sont de plus en plus modulaires, la gestion d’un projet multi dépôt Git devient un enjeu majeur pour les responsables d’équipes logicielles. Orchestrer plusieurs dépôts simultanément exige une organisation rigoureuse, des outils adaptés et une vision claire du cycle de vie logiciel.
Chez HexoTech, nous accompagnons des acteurs industriels et technologiques dans cette démarche, en combinant notre expertise sur le sujet et nos formations sur mesure.
Comprendre le concept de projet multi dépôt
Qu’est-ce qu’un multi dépôt ?
Un projet multi dépôt repose sur plusieurs dépôts Git distincts qui, ensemble, composent une application ou un système complet. Chaque dépôt peut correspondre à un module, une bibliothèque ou un service indépendant.
Cas typiques d’utilisation
- Architectures microservices
- Projets avec composants réutilisables entre équipes
- Développement collaboratif entre plusieurs équipes
Risques et difficultés courantes
- Gestion complexe des dépendances
- Synchronisation des versions
- Multiplication des branches et workflows divergents
Nos 3 solutions pour gérer des projets multi-dépôts
Solution 1 : Outils spécialisés
Présentation
La solution qui vient tout de suite en tête est très certainement celle des outils spécialisés. Nous pouvons par exemple citer :
- Git Submodule
- Git Subtree
- Google Repo
Ces outils reposes tous sur le même principe simple. Pour un dépôt donné, il faut lister les sous dépôt a gérer. Pour cela, nous avons besoin de minimum 3 informations :
- URL du sous dépôt : pour pouvoir le récupérer et ce synchroniser avec
- Dossier de destination : Chemin dans votre projet ou vous allez descendre le sous dépôt
- Version utilisée : le sha1, le tag ou encore la branche cible a récupérer pour le sous dépôt
Chaque outils aura sa méthode bien a lui de gérer ces 3 informations, mais globalement nous les retrouverons.
Avantages des solutions de type submodule
-
Permet de garder des
dépôts distincts mais liés
- Contrôle précis de la version intégrée
-
Idéal pour inclure une
lib ou un module externe spécifique à un commit
Inconvénients des solutions de type submodule
- Complexité de mise à jour
- Risque d’incohérences si mal synchronisé
Quand choisir des plugins git comme submodule
Parfait pour intégrer un projet externe ou un module partagé, tout en conservant l’historique séparé.
- Cycles de vie différents : composants mis à jour rarement et indépendamment (lib cryptographique, SDK).
- Cloisonnement & accès : équipes/partenaires n’ont pas les mêmes droits ou licences.
- Conformité/légal : licences différentes, audit séparé, historique distinct exigé.
- Binaire/asset lourd : gros artefacts mieux isolés pour éviter d’alourdir l’historique.
- Interop multi-org : dépôt partagé avec l’externe (open source) consommé par plusieurs produits internes.
Solution 2 : Le mono repo
Présentation
De plus en plus d’organisations, y compris des entreprises de premier plan comme Google ou Facebook, adoptent une stratégie appelée monorepo.
Contrairement à un simple dépôt unique, un monorepo est structuré en modules (un dossier par module), chacun disposant :
- de son propre numéro de version ;
- de sa liste de dépendances, gérée par des outils dédiés comme Bazel, Pip, yarn, etc.
Ce retour des mono-repo, s'explique par la complexité et la lourdeur qu'introduit des outils plus modulaires.
Avantages
- Centralisation des modules : facilite la réutilisation de composants entre projets.
- Développement transverse : possibilité de travailler simultanément sur plusieurs modules.
- Simplicité : un seul dépôt a récupérer et une cohérence des versions implicite.
Inconvénients
- Scalabilité limitée : risque accru de “sac de nœuds” dans un projet trop complexe.
-
Responsabilités à isoler : éviter les imports sauvages entre projets ou modules.
- Pas de cloisonnement strict : difficile d’appliquer des restrictions d’accès différentes au code.
- Problèmes de versions divergentes : inadapté lorsque des modules partagent une même bibliothèque mais pas la même version.
Quand choisir un monorepo
- Évolutions couplées : plusieurs modules changent souvent ensemble (ex. UI kit + app, schémas gRPC/GraphQL + services).
- Synchronisation atomique : commit unique qui garde l'ensemble du projet compatible, avec CI qui ne teste/build que ce qui a changé (Nx, Turborepo, Bazel, Pants).
- Réutilisation intensive : beaucoup de packages internes partagés, versionnés ensemble (ou via changesets/workspaces).
- DX & outillage commun : mêmes conventions, tooling et pipelines (lint, tests, release) appliqués partout.
- Releases coordonnées : tu publies/ déploies un ensemble cohérent plutôt que des briques isolées.
- Visibilité et refactors globaux : refactor “à l’échelle” (renommer une API, changer un contrat) dans un seul PR.
Solution 3 : L'approche modulaire ou package
Présentation
Dans cette méthode, chaque dépôt est totalement indépendant des autres. Le lien entre les projets se fait uniquement via un fichier de dépendance et un outil spécialisé comme par exemple: Bazel, Pip, Yarn, npm, Maven.
Très souvent, ces systèmes de dépendances utilisent les mêmes informations :
- le nom et la version du module courant ;
- la liste des modules externes nécessaires (avec nom et version).
L’outil se charge ensuite de télécharger et installer automatiquement les bons packages dans l’environnement du module, garantissant ainsi que les versions utilisées sont cohérentes.
C’est une approche très répandue, en particulier dans les écosystèmes Node.js (npm), Python (pip), Java (Maven/Gradle), ou encore dans des environnements multi langages avec Bazel.
Avantages
- Encapsulation et réutilisabilité : chaque dépôt est isolé et peut être réutilisé ailleurs.
- Versionnage clair : chaque module évolue à son propre rythme.
- Compatibilité universelle : fonctionne avec tous les gestionnaires de dépendances standards.
- Flexibilité des versions : permet à deux modules de partager une bibliothèque commune mais avec des versions différentes.
Inconvénients
- Gestion rigoureuse nécessaire : les mises à jour et publications doivent être bien organisées.
- Synchronisation plus lente : lorsqu’un module change, il faut publier puis mettre à jour les dépendances dans les autres dépôts.
Quand utiliser l'approche modulaire ?
- Les modules ont des cycles de vie différents et évoluent à des rythmes distincts.
- Les équipes travaillent de manière indépendante, sans besoin de commit synchronisé.
- Il est nécessaire de versionner et distribuer chaque module séparément (librairies réutilisables, SDK, APIs).
- Certains modules doivent gérer leurs dépendances différemment (versions distinctes d’une même bibliothèque).
- Les contraintes de sécurité ou de licence imposent un cloisonnement strict entre les dépôts.
Comment choisir la bonne approche multi dépôt ?
Bien identifier son besoin et ses contraintes
- Taille de l’équipe : Une équipe plutôt petite ou grande avec plusieurs sous équipes?
- Maturité du projet : MVP, petit projet ou gros projet full stack avec micro service?
- Contraintes techniques : performances, compatibilité CI/CD
- Contraintes de confidentialité : travail avec dessous traitants, partie du projet avec restriction de diffusion?
- Mutualisation du code : vous avez des libs a partager entre des projets?
La possibilité de changer de stratégie
Faire le choix d'une solution ne vous impose pas de rester sur cette dernière a tout jamais. Au contraire, il est possible et même conseillé de faire évoluer la solution a vos contraintes et besoins.
Par exemple, chez HexoTech, nous privilégions le monorepo dans les phase de prototypage ou de mise en place d'un projet. Nous divisons ensuite le monorepo pour passer a une autre solution plus adaptée a la réalité du projet. Cela nous permet d'être très rapide au début notamment sur des modification transverses.
L’accompagnement HexoTech sur vos projets multi dépôt
HexoTech accompagne ces clients sur la mise en place ou la reprise de la structure de leurs projets. Nous réalisons un audit et nous réalisons avec vous un plan de migration détaillé. Nous pouvons vous accompagner sur la mise en place de ce plan et enfin nous pouvons former vos équipes via nos formations sur mesure.
Conclusion : Sur la gestion de projet multi dépôts
La gestion d’un projet multi dépôt Git requiert une approche méthodique et des outils adaptés. Entre mono repo, submodule, subtree et gestion des dépendances, chaque choix doit être guidé par vos objectifs techniques et organisationnels.
Avec HexoTech, vous bénéficiez d’un accompagnement sur mesure et de formations certifiées pour optimiser vos workflows et rendre vos équipes autonomes.
📩 Contactez nous dès aujourd’hui pour transformer votre organisation Git et booster votre productivité.
FAQ – Gestion de projet multi dépôts
Quelle est la différence entre Submodule et Subtree ?
Submodule garde un lien externe, Subtree fusionne l’historique.
Faut-il toujours préférer un mono repo ?
Non, tout dépend de la taille du projet et du nombre d’équipes.
Peut-on mixer mono repo et multi dépôt ?
Oui, certaines architectures hybrides le permettent.
Quels outils pour gérer les dépendances ?
npm, yarn, pip, bazel, etc.
Comment éviter les conflits entre dépôts ?
Workflow clair, versioning strict, intégration continue.
HexoTech peut-il intervenir sur un projet existant ?
Oui, nous pouvons intervenir sur un projet existant, même complexe.
HexoTech peut elle nous accompagner dans la migration?
Oui, et nous pouvons en parallèle vous former. Contactez nous !
Comment se former à Git et GitLab ?
Vous pouvez faire une demande de formation Git HexoTech
