Un audit de code legacy qui vaut son prix

Un audit de code legacy ne vaut son prix que si une autre équipe compétente peut agir sans acheter une seconde mission de découverte. Il doit expliquer ce qui existe, ce qui s'exécute encore, quels processus métier peuvent échouer et combien coûtera chaque unité de changement raisonnable. Si le document s'arrête à des schémas d'architecture, des scores de qualité et une recommandation de modernisation, vous avez acheté un document commercial.

J'ai examiné des audits qui semblaient coûteux parce qu'ils étaient longs. Les utiles étaient souvent plus difficiles à produire et plus faciles à lire. Chaque affirmation renvoyait au code, à une preuve d'exécution, à un entretien avec un responsable ou à une hypothèse explicite. Chaque phase avait une limite, un test de réception, des dépendances et un prix. Cette traçabilité fait la différence.

L'audit doit définir la frontière du système avant de le juger

Un audit crédible précise d'abord ce qui a été inspecté et ce qui ne l'a pas été. Les systèmes anciens tiennent rarement dans un dépôt. Une application COBOL peut dépendre de JCL, de définitions d'ordonnanceur, de copybooks, d'objets DB2, de transferts de fichiers et d'un classeur Excel géré par la finance. Une application de bureau peut écrire directement dans une base partagée tandis qu'un script nocturne corrige les enregistrements impossibles à réparer dans l'interface. Omettre ces bords fragilise toutes les conclusions.

Le registre de périmètre doit recenser dépôts, branches, versions déployées, fichiers de build, schémas de données, jobs, interfaces, configurations, rapports et procédures opératoires. Pour chaque élément, l'auditeur doit noter la source de preuve et la version ou date d'observation. Le nom d'un dépôt sans identifiant de commit ne prouve pas ce qui a été analysé. Un schéma exporté du développement ne prouve pas ce que la production utilise.

Il faut aussi une liste d'exclusions. Le progiciel d'un fournisseur peut être inaccessible, les journaux ne couvrir que sept jours ou l'ancien compilateur ne plus démarrer. Ce ne sont pas des notes de bas de page. Chaque exclusion doit indiquer sa conséquence, par exemple: "L'accessibilité du batch reste incertaine faute d'historique de l'ordonnanceur."

Demandez un tableau avec quatre colonnes: actif, preuve inspectée, confiance et lacune. La confiance reflète la qualité des preuves, pas l'intuition. Code, sortie de build et traces de production inspirent plus confiance qu'un entretien seul. Sans frontière ni lacunes visibles, l'analyse ne peut être reproduite et son prix se défend mal.

Une carte des modules doit montrer comportement, données et propriétaires

Une bonne carte est un inventaire relié à des preuves de dépendance, pas une page de boîtes colorées. En sélectionnant un module, un ingénieur doit savoir qui l'appelle, ce qu'il appelle, quelles données il lit ou modifie et quel processus en dépend. Graphe, tableau ou les deux conviennent, à condition d'avoir des identifiants stables et des arêtes traçables.

Chaque nœud doit au minimum porter chemin du dépôt, langage, déployable ou job, points d'entrée, données persistantes touchées, interfaces externes, déclencheur ou horaire et propriétaire connu. Chaque arête doit expliquer sa preuve. Résolution statique, analyse des imports, parsing SQL, configuration de l'ordonnanceur, métadonnées des messages et trafic observé ne sont pas équivalents. Les fusionner sans étiquette masque l'incertitude.

Les dépendances legacy sont désordonnées. Appels dynamiques, noms générés, réflexion, tables partagées, fichiers temporaires et enregistrements de contrôle peuvent tromper un parseur simple. Le rapport doit conserver les arêtes non résolues. Un nœud "cible calculée à l'exécution" est utile; un beau schéma qui omet l'appel est dangereux. Les cycles doivent rester visibles car ils déterminent souvent l'ordre d'extraction.

La carte exige aussi une couche métier. "ARUPD07 appelle DATECNV" aide l'ingénieur. "La clôture de l'affectation des encaissements dépend d'ARUPD07 et de l'import bancaire" aide à choisir l'ordre. Les deux vues doivent partager le même modèle et leurs preuves. Si un atelier doit recréer cette relation après livraison, le livrable est incomplet.

Exigez les données sources, pas seulement les schémas rendus. Un fichier d'arêtes suffit:

source_id,target_id,edge_type,evidence,confidence,business_process
ARUPD07,DATECNV,static_call,src/ar/ARUPD07.cbl:418,high,cash_application
NIGHTLY_AR,ARUPD07,schedule,ops/sched/nightly.jcl:77,high,cash_application
ARUPD07,BANK_RATE,dynamic_call,production_trace:sample_042,medium,cash_application

L'équipe peut comparer ce fichier, l'interroger et le charger dans son outil de graphe. Une capture enfermée dans un PDF ne permet ni planification ni vérification ultérieure.

Le code mort est une mesure, pas un pourcentage de scanner

L'audit doit distinguer code inaccessible, non observé, dormant et structures de données inutilisées, car ces catégories conduisent à des décisions différentes. Les équipes les confondent puis suppriment un traitement annuel. L'analyse statique peut montrer qu'aucun point d'entrée connu n'atteint une procédure. L'observation montre seulement qu'elle n'a pas tourné pendant la fenêtre étudiée.

Le registre doit donner l'unité, la méthode, la fenêtre, les cycles couverts, les contre-preuves, la confiance et l'action recommandée. Un nombre de lignes seul est faible. Dix mille lignes générées peuvent être recréées sans risque, alors qu'une exception fiscale de vingt lignes porte un risque sérieux. Mesurez unité logique et comportement avant de calculer un pourcentage.

Utilisez plusieurs preuves: références de build, accessibilité statique, historique d'ordonnancement, traces, accès aux données, feature flags et entretiens opérateurs. Aucune ne suffit seule. L'historique rate les reprises manuelles, les traces les fins de trimestre, et les entretiens perpétuent parfois un folklore obsolète. L'accord de sources indépendantes augmente la confiance; leurs contradictions vont dans le rapport.

Une fiche défendable dirait: "CLAIMS_REPRINT n'a aucun appelant statique, aucune entrée d'ordonnanceur et aucune exécution sur deux cycles de facturation normaux. Les opérations indiquent que le support le lance après une panne d'imprimante. Classement: chemin de reprise dormant, pas mort. Action: conserver jusqu'à ce que le remplacement couvre la reprise." C'est plus utile qu'un tableau annonçant 18 % de code mort.

Demandez numérateur et dénominateur de chaque chiffre. "Inutilisé" désigne-t-il lignes, fonctions, programmes, tables, écrans ou étapes batch? Les commentaires et sources générées sont-ils exclus? La compilation conditionnelle et les appels dynamiques sont-ils couverts? Sans réponse, le pourcentage est une piste, pas une base de périmètre ou d'économie.

Les risques doivent viser processus métier et modes de panne

Une liste classée n'a de valeur que si chaque risque relie une condition technique à un événement métier, un mode de panne et un impact observable. "Fort couplage" n'est pas encore un risque. "Le job de facturation et le service de crédit mettent à jour la même table de soldes avec des règles différentes; une panne partielle peut libérer des commandes sur un solde périmé" est évaluable.

Chaque fiche doit inclure processus, déclencheur, cause, comportement de panne, détection, contrôle existant, étendue probable, preuve et correction. Le classement doit expliquer vraisemblance et impact. Des décimales ne rendent pas objectives des entrées subjectives; des échelles simples et définies sont souvent meilleures.

Ne classez pas la maintenabilité au-dessus du comportement de production parce qu'un scanner la compte facilement. Une procédure de 4 000 lignes peut être laide mais stable et rarement modifiée. Un rapprochement propre de 200 lignes peut perdre des lignes si un fichier arrive deux fois. Classez le second plus haut si les preuves le montrent. Exposition métier, fréquence de changement, récupération et délai de détection comptent davantage que l'esthétique.

Les risques ont besoin d'un propriétaire capable de corriger ou d'accepter l'exposition, pas forcément du développeur qui connaît le module. Si personne ne peut prendre le risque faute de propriétaire du processus, consignez ce défaut de gouvernance au lieu d'écrire "IT".

Mon test est direct: la personne qui exécute le processus reconnaît-elle la panne décrite? Si comptabilité clients, entrepôt ou conformité ne relient pas la fiche à un événement réel, l'auditeur a sans doute classé des odeurs de code plutôt que des risques opérationnels.

Les preuves d'exécution doivent couvrir le calendrier utile

Une trace de production n'est utile que si sa fenêtre correspond au calendrier métier. Trente jours ordinaires peuvent couvrir des milliers de requêtes et manquer clôture trimestrielle, renouvellement annuel, tarif saisonnier ou reprise rare. L'audit doit dire quels cycles sont couverts.

Établissez un calendrier des tâches quotidiennes, hebdomadaires, de fin de mois, trimestrielles, annuelles, événementielles et de reprise. Mappez-y les exécutions. Un chemin web très fréquent ne masquera plus un batch rare. Appuyez le calendrier sur configuration, procédures, transactions et entretiens, pas sur la mémoire seule.

Confidentialité et contraintes d'exploitation font partie de la méthode. L'auditeur peut utiliser formes de requêtes, hachages, comptes, échantillons ou journaux expurgés plutôt que les données brutes. Le rapport doit expliquer le traitement des champs sensibles et la fidélité perdue. Il ne doit jamais copier secrets ou données personnelles pour prouver le traçage.

Le livrable doit montrer identifiants, horodatages, entrées, état de sortie, composants appelés, tables ou fichiers touchés et rattachement métier. Les agrégats doivent pointer vers leurs observations. Sinon l'auditeur peut dire "actif" ou "inutilisé" sans justification.

Une télémétrie absente ne prouve pas que le code est mort. Elle change la recommandation: instrumentation, observation prolongée ou rejeu contrôlé avant suppression. L'incertitude est normale dans un vieux système. La cacher ne l'est pas.

Le plan par phases exige limites, preuves et prix

Une phase n'est achetable que si périmètre, dépendances, réception et prix sont explicites. "Fondation, transformation, optimisation" ne dit pas ce qui change après facturation. Une bonne phase nomme le segment métier ou la couture technique, les actifs modifiés, les interfaces stables et la preuve d'acceptation.

Chaque phase doit préciser cinq points:

1. Modules, données, interfaces et processus inclus.
2. Prérequis et décisions du client.
3. Livrables et environnement d'exécution.
4. Tests de réception, dont parité comportementale et contrôles d'exploitation.
5. Prix fixe ou fourchette bornée avec hypothèses de variation.

Un prix sans hypothèses est un appât. Les hypothèses peuvent couvrir outils de build, trafic représentatif, schémas de données, licences ou recette client. Chacune doit conduire à un mécanisme tarifé. Si une interface manquante ajoute du travail, le rapport doit expliquer comment phase et prix changent.

La séquence exige un argument. Commencer par un petit module isolé paraît sûr, mais ne prouve souvent qu'une conversion de syntaxe. Une meilleure première phase traverse une couture représentative et teste données, build, déploiement et parité tout en limitant l'exposition. L'audit doit expliquer quelle incertitude elle réduit.

Présentez les alternatives soutenues par les preuves. On peut extraire le service de prix ou stabiliser d'abord le contrat de la base partagée. Comparez coût, dépendance et risque. Une feuille de route unique peut déguiser la préférence du prestataire en nécessité technique.

Les estimations doivent se reconstruire depuis les preuves

Une estimation fiable montre à une autre équipe comment le périmètre devient prix. Nul besoin d'exposer salaires ou marge, mais unités, facteurs de complexité, exclusions, réserves et hypothèses doivent apparaître. Sinon le chiffre sert à négocier, pas à planifier.

Le modèle doit référencer les identifiants exacts des registres. Si une phase contient douze programmes, trois jobs, deux interfaces et une table partagée, elle doit les nommer. Les ajustements doivent citer leur cause: dispatch dynamique, build absent, format inconnu, conversion de données ou environnement de test indisponible. "Facteur de complexité legacy" ne suffit pas.

Une fourchette est raisonnable si le rapport dit comment la fermer. Si le bas suppose un build reproductible et le haut sa reconstruction, un test de build d'une journée peut produire un prix ferme. Une large plage sans règle transfère seulement le risque au client.

Demandez une fiche de phase inspectable:

Phase: cash application slice
Scope IDs: NIGHTLY_AR, ARUPD07, DATECNV, BANK_RATE
Base work: behavior capture, target implementation, data adapter, deployment
Risk allowances: dynamic call resolution; incomplete printer-recovery trace
Customer inputs: redacted traffic set; operations reviewer
Acceptance: replay parity; close totals match; recovery procedure demonstrated
Price: [amount or bounded range]
Range closes when: build and recovery-path tests complete

La méthode peut varier, pas la chaîne actif découvert, unité de travail, prix. Si elle reste secrète, impossible de savoir si le montant reflète votre système ou un objectif commercial.

Un vrai audit laisse des preuves contestables

Le paquet final doit inclure registres modifiables et exports lisibles par machine. Vos ingénieurs doivent pouvoir filtrer les modules dormants, suivre un risque jusqu'aux tables ou voir quelle phase possède une interface. Si l'auditeur garde le seul modèle utilisable, vous avez loué la compréhension.

Exigez des identifiants de preuve partout. Une arête cite une ligne source ou une trace; un risque cite arêtes, incidents et entretien; une phase cite risques réduits et actifs modifiés. Les ingénieurs peuvent ainsi contester une arête ou une hypothèse au lieu de débattre d'une conclusion.

Ajoutez les notes de reproduction: outils et versions, commandes, branches et commits, fenêtres de traces, filtres, limites des parseurs et corrections manuelles. Le but est de distinguer preuve générée et jugement humain, puis d'inspecter les deux.

Pendant la revue, choisissez un chemin de revenu, un batch, un module supposé mort et une phase chère. Remontez chaque piste depuis les artefacts livrés. Si elle casse, consignez ce qui manque avant réception. C'est plus révélateur qu'une présentation supplémentaire.

Le contrat doit aussi transférer registres, schémas, diagrammes, scripts spécifiques et exports utilisables des outils propriétaires. Les licences peuvent limiter le transfert d'un outil, mais votre modèle du système ne doit pas disparaître avec l'accès.

Un document commercial se trahit avant son argumentaire final

Il part d'une destination décidée et rassemble juste assez de preuves. Un vrai audit accepte que les faits changent la recommandation, y compris le maintien d'une partie du système. La proposition et la première revue suffisent souvent à les distinguer.

Méfiez-vous si:

• Les livrables promettent constats et recommandations sans définir champs ni sources.
• Le prix bas sera récupéré sur une mise en œuvre présumée.
• Les risques viennent d'un scanner générique sans lien métier.
• La feuille de route utilise de grandes étapes sans tests ni prix par phase.
• Le fournisseur montre son modèle mais ne livre pas les enregistrements.

Refusez la précision théâtrale. Un score de 2,7, une carte rouge ou un pourcentage exact peut cacher des pondérations arbitraires. Demandez quelle décision change avec le score. Sans réponse, il décore la vente.

Indépendance et neutralité diffèrent. Une société de réalisation peut faire un bon audit si elle sépare preuve et conseil, chiffre les alternatives et transfère les artefacts. Un cabinet sans capacité de livraison peut écrire un rapport vague. Jugez le produit du travail et les incitations commerciales.

Avant signature, inscrivez à la commande registres requis, champs minimaux, formats, liens de traçabilité, procédure de revue et délai de correction. "Rapport complet" n'est pas un livrable inspectable; un registre aux colonnes définies l'est.

L'audit doit permettre la première décision de livraison

L'audit finit quand la direction peut choisir une première phase bornée, comprendre le risque réduit, voir systèmes et personnes touchés et approuver un prix lié aux preuves. Un gros rapport conclu par "poursuivre la découverte" n'y arrive pas. Chaque inconnue restante doit avoir propriétaire, méthode de résolution et décision affectée.

Le relevé de décision final doit contenir phase choisie, alternatives rejetées, preuves, hypothèses ouvertes, tests, prix et conditions d'arrêt. Un build impossible à reproduire, un trafic contredisant la carte ou une interface contrôlée par un tiers peuvent arrêter le projet. Les nommer empêche de maintenir un devis après changement de prémisse.

Pour une réécriture, la méthode de parité appartient à cette décision. CodeHero lit toute la base de code et vérifie le comportement conservé avec le trafic de production enregistré. Exigez de tout fournisseur le comportement comparé, le trafic représentatif, le classement des écarts et leur responsable d'acceptation. "Fonctionnellement équivalent" sans harnais ni arbitrage reste un adjectif.

Payez un audit quand il transforme l'incertitude en choix traçables. Refusez-le quand il la transforme en diapositives. Donnez les artefacts à un ingénieur absent des ateliers et demandez périmètre, preuves, risque, test et prix de la phase un. Si tout est présent et relié, l'audit a fait son travail.