Personne ne fait analyser son COBOL sans raison.
Il y a toujours un événement déclencheur : quelqu'un part, une équipe reprend, un texte change, un incident revient. Voici les six situations dans lesquelles un diagnostic paie pour lui-même, et ce qu'il apporte concrètement dans chacune.
La personne qui savait s'en va dans six mois.
Le risque n'est pas de perdre un développeur : c'est de perdre la seule personne capable d'expliquer pourquoi un traitement fonctionne comme il fonctionne. Un diagnostic transforme ce savoir en document avant le départ, pendant qu'il est encore possible de poser des questions.
Le transfert de connaissances est planifié, mais il consiste surtout en réunions. L'expert explique ce à quoi il pense ; personne ne sait quoi lui demander d'autre, parce que personne ne connaît la carte.
La liste des questions à lui poser, établie à partir du code : les zones opaques, les constantes en dur sans explication, les dépendances non résolues. L'entretien porte alors sur ce que le code ne dit pas, au lieu de répéter ce qu'il dit déjà.
Le registre des dépendances humaines : pour chaque règle métier, qui peut la confirmer aujourd'hui — et ce qui n'a plus personne.
À déclencher au moment de l'annonce du départ, pas dans les dernières semaines.
Une nouvelle équipe hérite d'une application qu'elle n'a pas écrite.
Changement de prestataire, internalisation, réorganisation : une équipe se retrouve responsable d'un patrimoine dont elle ne connaît ni la structure ni les pièges. Les premiers mois se passent en exploration, et les premières modifications se font à l'aveugle.
La documentation transmise est partielle ou périmée. Les nouveaux arrivants ouvrent les programmes un par un, sans savoir lesquels comptent, ni ce qui dépend de quoi.
Un point d'entrée : quels traitements composent le flux, quelles données circulent, quels programmes sont partagés et donc sensibles. L'équipe commence par la carte plutôt que par un fichier au hasard.
La carte des dépendances du flux, et l'écart entre la documentation reçue et ce que le code fait réellement.
Souvent commandé par une ESN pour accélérer sa phase de découverte, y compris en marque blanche.
Il faut changer un taux, un champ, une règle — et personne ne sait ce que ça touche.
Un changement réglementaire ou métier arrive avec une échéance. La modification elle-même prend une heure. Ce qui prend des semaines, c'est de déterminer ce qui casse ailleurs.
Un COPYBOOK est partagé par un nombre inconnu de programmes. Un champ est utilisé dans des traitements que personne n'a en tête. Le périmètre de test est décidé à l'intuition, donc soit trop large, soit incomplet.
La liste des programmes, fichiers et tables reliés à l'élément modifié, chacun avec l'emplacement exact de la dépendance. Le périmètre de test devient une conséquence de la carte plutôt qu'un pari.
Ce n'est pas une garantie d'exhaustivité. Ce qui n'a pas pu être résolu — un appel dynamique, un COPYBOOK absent — est listé explicitement, pour que la décision se prenne en connaissance des angles morts.
Format adapté : Diagnostic Express si la question porte sur un programme, Diagnostic de flux si elle traverse un traitement.
Le même incident revient, et l'explication change à chaque fois.
Un batch échoue périodiquement, un écart de calcul réapparaît, une donnée se dégrade sans coupable identifié. Chaque occurrence est corrigée localement, sans que la cause soit établie.
Le diagnostic se fait sous pression, dans l'urgence, par la personne disponible. On regarde le programme qui a planté, rarement la chaîne qui l'a amené là.
La reconstitution à froid du chemin des données : qui écrit ce fichier, qui le lit ensuite, quels contrôles existent et lesquels manquent, quels codes retour sont vérifiés et lesquels sont ignorés.
La carte des données lues et modifiées le long du flux, et la liste des points où une erreur passerait sans être détectée.
On vous demande d'expliquer un traitement par écrit.
Un auditeur interne, un contrôleur ou un régulateur demande comment un calcul est effectué et sur quelles données. La réponse existe dans le code, mais pas sous une forme présentable ni vérifiable par un tiers.
Les équipes savent expliquer oralement. Mettre par écrit, avec la preuve à l'appui et dans un délai contraint, mobilise des jours d'expert qui manquent ailleurs.
Un catalogue de règles métier où chaque règle cite le programme, le paragraphe et la ligne qui la produisent. Un tiers peut vérifier sans lire le code entier.
Un diagnostic ne rend conforme à aucun référentiel. Il fournit des éléments de traçabilité exploitables dans un dossier d'audit — c'est utile, mais ce n'est pas une attestation.
Avant de décider quoi migrer, il faut savoir ce qu'on a.
Les projets de modernisation dérapent rarement sur la technique de migration. Ils dérapent parce que le périmètre réel a été découvert en cours de route, une fois le budget voté.
Le chiffrage repose sur un inventaire déclaratif : un nombre de programmes, une estimation de lignes. Ni les dépendances croisées, ni les règles métier non documentées, ni les zones dont plus personne n'a la clé n'y figurent.
Un état des lieux vérifiable avant l'engagement : ce qui est compris, ce qui ne l'est pas, et où se concentre le risque. De quoi découper le projet par ordre de risque plutôt que par ordre alphabétique.
La mesure de continuité des connaissances sur sept axes observables, et le plan d'action priorisé à 30, 60 et 90 jours.
Le diagnostic ne migre rien. Il sert à décider ce qui doit l'être, dans quel ordre, et à quel niveau de risque.
Dans les six cas, ce qui est acheté est le même.
Une réduction d'incertitude avant une décision coûteuse. Le rapport n'est pas la finalité : c'est le support qui permet de trancher, de chiffrer ou de défendre un arbitrage avec des preuves plutôt qu'avec des souvenirs.
Lequel de ces six est en train de se produire chez vous ?
Un échange de 30 minutes suffit pour identifier le bon périmètre et le bon format. Sans transfert de code à cette étape.
