Un même produit peut être réparti entre une application web, deux applications mobiles, plusieurs API, un back-office et des outils de traitement. Chaque composant possède son dépôt, ses dépendances et parfois sa propre manière d’être déployé. Lors d’une reprise, ouvrir les dépôts un par un ne suffit pas : il faut reconstruire la vision du système.
Constituer un inventaire fiable
Exportez la liste des projets depuis toutes les organisations Git connues, puis croisez-la avec les services réellement exécutés dans les environnements. Un dépôt récemment modifié n’est pas forcément en production ; un dépôt ancien peut encore porter une fonction critique.
Pour chaque dépôt, relevez :
- sa fonction métier ;
- son statut : actif, historique, expérimental ou inconnu ;
- sa technologie et sa version ;
- ses responsables passés et actuels ;
- les environnements où il est déployé ;
- les bases et services externes utilisés ;
- son pipeline de build et de livraison ;
- les autres composants qui en dépendent.
Ne supprimez rien pendant cette phase. Une branche ou un dépôt apparemment obsolète peut encore expliquer une version publiée.
Relier les dépôts aux parcours utilisateurs
Une cartographie purement technique devient vite illisible. Partez aussi des parcours : connexion, abonnement, création d’un dossier, notification ou synchronisation. Pour chaque parcours, suivez les composants traversés et les données échangées.
Cette approche révèle les dépendances réellement critiques. Elle montre aussi pourquoi une modification simple dans le mobile peut nécessiter une évolution de l’API et du back-office.
Identifier les contrats entre composants
Les API, événements et fichiers échangés constituent les contrats du système. Vérifiez s’ils sont documentés, versionnés et testés. Recherchez les hypothèses cachées : ordre des appels, valeurs obligatoires, format de date, délai de traitement ou comportement en cas d’échec.
Lorsque plusieurs versions coexistent, documentez quels clients utilisent quelle API. Une migration ne doit pas interrompre une ancienne application mobile encore installée.
Reproduire chaque chaîne de livraison
Pour chaque composant actif, la nouvelle équipe doit savoir :
- installer les dépendances ;
- exécuter les tests ;
- construire l’artefact ;
- déployer en préproduction ;
- observer son fonctionnement ;
- revenir à la version précédente.
Les différences de conventions entre dépôts sont une source de risque. Elles peuvent être harmonisées progressivement, mais la première priorité reste la reproductibilité.
Faut-il réunir tous les dépôts dans un monorepo ?
Pas nécessairement. Un monorepo peut simplifier les changements coordonnés et partager certaines règles, mais sa mise en place ne résout pas une architecture inconnue. Des dépôts séparés restent adaptés lorsque les composants ont des cycles de vie et des responsabilités indépendants.
La décision doit venir des besoins de livraison, pas d’une préférence. Pendant la reprise, déplacer tous les codes peut brouiller l’historique et ajouter un chantier sans valeur immédiate.
Construire une carte utile, pas parfaite
Une bonne cartographie tient sur une page pour la vue d’ensemble, complétée par des fiches courtes. Elle indique les composants, les flux, les données, les propriétaires et les points critiques. Elle doit être mise à jour lorsqu’un composant apparaît ou disparaît.
Ajoutez un registre des décisions d’architecture : contexte, choix retenu, alternatives et conséquences. Les nouveaux intervenants comprendront ainsi pourquoi le système existe sous cette forme.
Prioriser après la cartographie
Classez les composants selon leur valeur métier, leur fréquence de changement et leur risque opérationnel. Un service central sans tests ni responsable passe avant un outil interne stable. Cette classification alimente l’audit technique avant reprise et la roadmap.
La mission MyTwiga a commencé par la reprise de treize dépôts couvrant applications mobiles, API, web et infrastructure. Cette vision commune a permis d’ordonner les refontes et le DevOps. Consultez la réalisation MyTwiga.
Pour organiser l’ensemble de la transition, retrouvez notre méthode pour faire reprendre le développement d’une application existante.