C'était un vendredi à 14 heures quand le CTO de notre client industriel nous a appelés. Ils venaient de racheter une PME logicielle avec une codebase VB.NET de 2009, deux millions de lignes, aucune documentation, et un seul développeur capable de la maintenir — qui partait en retraite le mercredi suivant. « Patrice, on a trois jours ouvrés pour comprendre ce code avant de démarrer la planification d'intégration. » Voilà comment est né GitNexus-RS — notre outil interne de cartographie automatique de codebases legacy. En 2026, après dix-huit projets clients similaires, voici ce qu'il fait, comment il fonctionne sous le capot, et surtout les limites honnêtes que les démos commerciales oublient de mentionner.
Le problème : trois plaies des codebases legacy critiques
Les codebases legacy posent trois défis qui bloquent toute initiative de modernisation, et qu'aucune équipe ne peut résoudre par la lecture manuelle.
Plaie 1 — Zéro documentation à jour
Le code est la documentation. Sauf que ce code parle un dialecte qui n'est plus enseigné, avec des conventions internes que seul l'auteur original maîtrisait. Sur les 18 projets que nous avons traités, aucun n'avait de documentation représentative à jour. Au mieux, des commentaires vieux de 10 ans qui décrivent l'intention initiale, pas l'état actuel.
Plaie 2 — Dépendances invisibles
Un appel cross-module en VB.NET sans imports explicites, c'est invisible au grep. Les bindings dynamiques, les invocations par réflexion, les jobs SQL Server qui appellent des stored procedures — tout ça forme une toile de dépendances non-documentées que personne ne voit dans son ensemble.
Plaie 3 — Onboarding impossible
Un développeur senior met 3 à 6 mois pour devenir productif sur une codebase legacy non documentée. Pendant ces 6 mois, l'équipe entière passe son temps à répondre à ses questions. Quand le seul expert part à la retraite, vous avez statistiquement deux à trois ans d'inertie avant que l'équipe redevienne autonome.
Sur le client industriel évoqué en intro, le diagnostic à J0 était :
| Indicateur | Valeur initiale |
|---|---|
| Lignes de code production | 2 000 000 |
| Projets Visual Studio imbriqués | 47 |
| Documentation à jour | < 5 % |
| Tests automatisés | 0 |
| Devs maîtrisant la codebase | 1 (en retraite mercredi) |
| Estimation manuelle initiale d'un changement | × 3 vs effort réel |
C'est ce diagnostic, répété chez 18 clients, qui a justifié de construire un outil dédié au lieu de refaire le travail à la main à chaque projet.
Ce que GitNexus-RS fait : trois sorties exploitables
Voici les trois artéfacts produits par l'outil, dans l'ordre où ils sont consommés par les équipes.
┌─ Input ────────────────────────────┐
│ Code source (VB.NET, C#, Java…) │
│ Logs runtime (optionnel) │
└────────┬───────────────────────────┘
↓
┌─ Pipeline GitNexus-RS ─────────────┐
│ 1. Parsing AST par langage │
│ 2. Résolution de symboles │
│ 3. Construction du graphe │
│ 4. Clustering communautés │
│ 5. Détection patterns métier │
└────────┬───────────────────────────┘
↓
┌─ Outputs ──────────────────────────┐
│ A. Cartographie web interactive │
│ B. Rapport markdown des hot spots │
│ C. Export GraphML pour analyse │
└────────────────────────────────────┘| Output | Cible | Usage typique |
|---|---|---|
| Cartographie interactive | Devs, architectes | Exploration, onboarding |
| Rapport hot spots | Tech leads, PM | Priorisation refacto |
| Export GraphML | Data scientists | Analyse custom |
Comment ça marche sous le capot
L'architecture est volontairement classique — pas de magie LLM ici, du code statique solide.
Étape 1 — Parsing AST par langage
Pas de regex, pas de grep. Un parser AST complet par langage, basé sur tree-sitter quand disponible, ou sur des parsers maison pour les langages exotiques (VB.NET, COBOL, etc.). Pour chaque fichier, on extrait :
- Toutes les déclarations (classes, interfaces, fonctions, propriétés)
- Tous les appels et accès (incluant les appels via réflexion détectables)
- Tous les imports et dépendances externes
- Les annotations et attributs (DI, ORM, sécurité)
C'est l'étape la plus longue : 5 à 30 minutes pour 2 millions de lignes selon les langages présents. Sur le client industriel, ça a sorti 47 000 définitions distinctes sur 12 400 fichiers.
Étape 2 — Résolution de symboles
Le piège : un appel customer.GetById() ne pointe pas tout seul vers la bonne définition. Il y a peut-être 5 classes qui définissent GetById. Il faut résoudre le type effectif de customer au moment de l'appel. C'est ce que font les compilateurs ; on a réimplémenté un résolveur léger qui couvre 85-90 % des cas et marque le reste comme « ambigu ».
Les 10-15 % d'ambiguïté sont signalés explicitement dans la cartographie avec une icône. Mieux vaut un graphe partiellement complet et honnête qu'un graphe « complet » avec 15 % de fausses arêtes.
Étape 3 — Construction et clustering du graphe
Une fois les arêtes établies, on a un graphe brut de 50k à 500k nœuds. Inutilisable tel quel — il faut le structurer en domaines métier.
On applique un algorithme de détection de communautés (Louvain ou Leiden selon la taille) sur le graphe pondéré. Les nœuds fortement interconnectés émergent comme des clusters. Sur le projet ERP industriel, ça a sorti 14 clusters cohérents :
| Cluster | Nb fichiers | Nb relations internes | Nb relations externes |
|---|---|---|---|
| Facturation | 234 | 8 200 | 580 |
| Commandes | 189 | 6 400 | 720 |
| Reporting | 121 | 3 100 | 230 |
| Authentification | 45 | 410 | 2 800 |
| ... 10 autres | ... | ... | ... |
Le ratio relations internes / externes est l'indicateur clé de cohésion. Le cluster Authentification (45 fichiers, 2 800 appels externes) est typiquement très réutilisé partout — c'est un module à laisser pour la fin de la migration.
Étape 4 — Détection de patterns métier
Sur le graphe enrichi, on applique des heuristiques pour identifier les patterns récurrents : services, repositories, controllers, façades, value objects. Cette détection sert à proposer des noms parlants aux clusters et à orienter les choix d'architecture pour la migration.
C'est l'étape où l'apport est le plus subtil : pas un facteur 10, juste un gain de lisibilité qui transforme un graphe technique en carte métier.
Les chiffres réels : impact mesuré sur le projet ERP industriel
| Métrique | Avant GitNexus | Après GitNexus | Gain |
|---|---|---|---|
| Compréhension de l'architecture | 6 semaines | 3 heures | × 80 |
| Onboarding dev junior | 4 mois | 2 semaines | × 8 |
| Risque évalué pour un refactor | « Aucune idée » | Graphe complet | qualitatif |
| Durée du planning de refonte | 4 semaines | 3 jours | × 9 |
| Découverte de code mort (% du total) | Inconnu | 18 % | qualitatif |
L'économie sur la migration totale
Avec la cartographie : la migration du projet a été planifiée à 6 mois × 4 développeurs = 24 hommes-mois. Sans elle, l'estimation initiale partait sur 18 mois × 8 développeurs = 144 hommes-mois, avec un risque maximal et une probabilité d'échec de l'ordre de 40 % selon nos comparaisons avec des projets similaires.
Différence brute : 120 hommes-mois économisés × 12 000 €/mois (coût chargé d'un dev sénior) = 1,4 M€. Sur ce client précis. Le coût de la cartographie initiale ? 35 k€. ROI typique : × 30 à × 40 sur les projets de modernisation > 1 M€.
Limites honnêtes : où GitNexus-RS échoue
Limite 1 — Réflexion massive et binding dynamique
Une codebase qui utilise massivement la réflexion (Type.GetMethod(), Activator.CreateInstance(), eval-style) est partiellement aveugle au static analysis. Notre résolveur capture 60-70 % de ce trafic, le reste reste invisible. Mitigation : combiner avec des traces runtime (instrumentation par APM) pour compléter le graphe.
Limite 2 — Stacks vraiment exotiques
Pour les codebases en MUMPS, Forth, Cobol des années 80, ou les frameworks propriétaires des années 90, l'AST n'existe pas. Il faut écrire un parser maison — typiquement 2 à 4 semaines de tooling spécifique. Coût supplémentaire qui pèse sur les très gros projets, mais qui se rentabilise sur les codebases > 1 M lignes.
Limite 3 — Détection des dépendances cachées en SQL
Les batches SQL Server ou Oracle qui appellent des stored procedures, les triggers, les jobs cron en shell — tout ça vit en dehors du code applicatif. L'outil a un module spécifique d'analyse SQL et shell qui couvre 80 % des cas, mais il y a toujours des connexions invisibles. Recommandation : lancer la cartographie + un audit ciblé manuel des entrées système (cron, triggers, batches).
Limite 4 — Comprendre la sémantique métier
L'outil produit un graphe technique. Il ne dit pas pourquoi le module Facturation existe ni quelles sont ses règles métier. Cette compréhension reste humaine — la cartographie accélère le travail des humains, elle ne le remplace pas.
| Limite | Mitigation | Coût additionnel |
|---|---|---|
| Réflexion massive | Traces runtime APM | 2 sem. d'instrumentation |
| Stack exotique | Parser maison | 2–4 sem. |
| Dépendances SQL/cron | Audit manuel ciblé | 1 sem. |
| Sémantique métier | Workshops business | Jamais zéro |
Limite 5 — Les modules « God class » qui mentent au clustering
Certains fichiers utilitaires (Helper.vb, Common.cs) sont appelés par 200+ autres et appellent eux-mêmes 100+ services. Le clustering les rattache arbitrairement à un domaine alors qu'ils sont transversaux. Notre tooling les détecte et les marque comme « shared utilities » dans la cartographie, avec un avertissement explicite : ce sont les derniers modules à migrer, jamais les premiers.
Ce qu'il faut retenir
Trois règles, dans cet ordre :
- La cartographie automatique est le prérequis numéro 1 de toute modernisation legacy. Sans elle, vos équipes naviguent à l'aveugle.
- AST + clustering battent les regex et les meetings. La méthode déterministe scale ; la lecture manuelle plafonne à 100k lignes/sem./dev.
- L'outil ne remplace pas la connaissance métier. Il accélère le travail technique, pas la décision business.
Pour aller plus loin :
- Working Effectively with Legacy Code (Michael Feathers) — référence fondatrice
- Documentation tree-sitter — moteur de parsing utilisé pour les langages modernes
- Algorithme de Louvain pour la détection de communautés — base théorique du clustering
Conclusion
Le client industriel évoqué en intro a tenu son délai de trois jours. La cartographie GitNexus-RS a sorti la connaissance critique avant le départ en retraite du seul expert. Six mois plus tard, la migration vers .NET 9 démarrait sur des bases solides — graphe connu, hot spots identifiés, code mort supprimé. La modernisation legacy ne commence pas par écrire du nouveau code. Elle commence par cartographier l'ancien avec rigueur.
