Comment Cartographier Automatiquement 15 Ans de Code Legacy
C'était vendredi, 14h, quand le CTO de notre client m'a appelé. Ils venaient d'acquérir une startup avec une codebase VB.NET de 2009, deux millions de lignes de code, aucune documentation, et un seul dev qui partait en retraite mercredi.
"Patrice, on a trois jours pour comprendre ce code avant de commencer la refonte."
Voilà comment est née GitNexus-RS.
Le Problème : Le Chaos Legacy
Les codebases legacy posent trois défis critiques :
- Zéro documentation — le code EST la documentation, et il parle en dialecte disparu
- Dépendances invisibles — appels cross-module, couplage caché, pas de dépendance graph
- Temps d'onboarding infini — 3-6 mois pour qu'un nouveau dev maîtrise le système
Chez ce client, ça s'ajoutait à :
- Stack VB.NET + Oracle en couches fermement couplées
- 47 projets Visual Studio imbriqués
- Zéro tests, zéro CI/CD
- Une architecture qui avait "grandi" sans plan
Résultat : les estimés explosaient. Chaque changement prenait trois fois plus longtemps parce qu'on passait 50% du temps à comprendre ce qui toucherait quoi.
La Solution : Cartographier Automatiquement le Codebase
GitNexus-RS fait trois choses :
1. Analyse Statique Complète
On parse le code source (VB.NET, C#, Java, Python, TypeScript) et on extrait :
- Chaque classe, interface, fonction, variable
- Chaque appel de fonction inter-fichier
- Chaque dépendance externe
- Patterns de code (services, repositories, controllers)
Pour le client VB.NET, ça a donné :
- 2M lignes → 12,400 fichiers → 47,000 définitions → 189,000 relations
2. Détection de Clusters (Domaines Métier)
Le graphe de dépendance brut, c'est du bruit. On utilise un algorithme de clustering pour identifier les domaines métier naturels :
- Module Facturation (234 fichiers, fortement couplés ensemble, faiblement liés au reste)
- Module Commandes (189 fichiers)
- Module Reporting (121 fichiers)
- Module Authentification (45 fichiers, très réutilisé)
Cette découpe révèle la vraie architecture du système — pas celle de l'organigramme, la vraie.
3. Génération de Cartographies Visuelles Interactives
On transforme le graphe en une cartographie web interactive où tu peux :
- Zoomer du système entier jusqu'à une fonction spécifique
- Voir toutes les dépendances entrantes/sortantes d'un module
- Identifier les points de couplage critiques (les fichiers que tout le monde appelle)
- Tracer un chemin d'exécution de bout en bout
Exemple : le client VB.NET avait un fichier "Utilities.vb" appelé par 437 autres fichiers. C'était un goulot d'étranglement critique pour la refonte.
L'Impact : Chiffres Réels
Sur ce client spécifique (2M lignes de VB.NET legacy) :
|----------|------|-----------------|------|
| Temps pour comprendre l'archi | 6 semaines | 3 heures | **97% réduction** |
|---|---|---|---|
| Risque lors d'une refactorisation | "Aucune idée" | Graph complet | Éliminé |
| Durée de planning de refonte | 4 semaines | 3 jours | 93% réduction |
Temps de Migration Épargné
Avant refonte : 18 mois, 8 devs, risque maximal.
Après cartographie : 6 mois, 4 devs, risque maîtrisé.
12 mois × 8 devs × 120k€/an = 11.5M€ d'économie sur une seule refonte.
Ce n'est pas hypothétique. C'est le client qu'on a fait.
Pourquoi C'est Difficile (Et Pourquoi Nous l'Avons Construit)
Parser du code legacy, c'est compliqué :
- VB.NET ? Syntaxe unique, peu de parsers open-source corrects
- Macro Magic ? Des appels dynamiques invisibles au static analysis
- Dépendances Externes ? Oracle, SOAP, webservices enfouis dans du XML
GitNexus utilise :
- Parsers AST complets pour chaque langage (pas de regex)
- Résolution de symboles pour suivre les appels indirects
- Heuristiques métier pour identifier les patterns (DI containers, ORM queries, etc.)
- Post-processing intelligent pour nettoyer les faux positifs
Cas d'Usage
Tu l'utilises quand tu as besoin de cartographier rapidement :
- Avant une refonte majeure — budgétisation réaliste + planification de domaines
- Intégration après achat — comprendre ce qu'on vient d'acheter
- Migration technologique — Java → Go, VB.NET → .NET Core
- Repartement d'équipes — qui doit travailler avec qui ?
- Audit de qualité — où sont les points critiques et dégradés?
Conclusion
La cartographie n'est pas une fin en soi. C'est le fondement pour une stratégie de modernisation sans panique.
