Peut-on faire confiance à la documentation automatisée ?

L'archéologie d'un dépôt peut reconstituer une quantité étonnante de documentation, mais lire davantage de fichiers ne suffit pas à retrouver une intention. Une carte des modules, un graphe d'appels statique, un modèle de données possible et une grande partie du graphe des dépendances batch sont des résultats étayés par des preuves. Les libellés comme "client", les affirmations sur les conditions de redémarrage sans risque d'un traitement et les explications sur la raison d'une branche restent des hypothèses tant qu'une autre source ne les confirme pas.

Cette limite compte, car la documentation générée paraît tout aussi assurée des deux côtés. J'ai vu des équipes accepter un diagramme impeccable, organiser une réécriture autour de lui, puis découvrir tardivement qu'une règle de l'ordonnanceur ou un programme choisi dynamiquement portait le comportement décisif. Il ne faut pas pour autant rejeter l'automatisation. Il faut associer à chaque affirmation générée ses preuves, sa méthode et ses angles morts connus.

Un dépôt prouve une structure, pas une finalité

La documentation automatisée d'un dépôt est fiable lorsqu'elle décrit une structure observable et précise comment elle a été observée. Fichiers, déclarations, imports, cibles de compilation, références SQL, instructions JCL et clés de configuration littérales laissent tous des traces vérifiables. Un outil peut les recenser, les relier et pointer vers les lignes qui justifient chaque relation.

La finalité est une autre question. Une table appelée ACCT_MST peut contenir des comptes clients, des comptes de grand livre internes ou un état temporaire de rapprochement. Son nom suggère une interprétation, mais n'en prouve aucune. Une routine appelée VALIDATE peut refuser une entrée incorrecte, appliquer une règle d'autorisation ou seulement contrôler la largeur des champs. Les commentaires peuvent aider, mais un commentaire périmé reste un contenu du dépôt, pas une vérité privilégiée.

J'utilise trois classes de confiance dans la documentation générée :

• Observé signifie que le dépôt contient une preuve directe, comme un import, un EXEC PGM ou la déclaration d'une clé étrangère.
• Déduit signifie que plusieurs observations appuient une conclusion, par exemple le regroupement de programmes dans un module de facturation parce qu'ils partagent des tables et des points d'entrée.
• Non résolu signifie que le dépôt ne permet pas de trancher, même si une interprétation semble probable.

Chaque nœud et chaque arête doit aussi citer son origine sous la forme d'un chemin et d'une ligne ou d'une plage d'instructions. Sans provenance, les relecteurs ne peuvent pas distinguer le résultat d'un analyseur d'une supposition du modèle. Une phrase générée telle que "INVOICE écrit dans AR_LEDGER" n'est utile que si le lecteur peut inspecter l'INSERT, l'appel de procédure stockée ou l'écriture d'enregistrement qui la justifie.

Cette distinction évite aussi une confusion fréquente : l'exhaustivité et l'exactitude ne sont pas la même chose. Un analyseur peut trouver correctement chaque appel direct dans les fichiers qu'il comprend tout en manquant les appels pilotés par la configuration. Son résultat est exact dans un périmètre déclaré, mais incomplet pour le système en fonctionnement. La documentation doit rendre compte des deux dimensions au lieu de les fondre dans un indice de confiance vague.

La carte des modules exige plusieurs types de relations

Une carte des modules crédible combine la structure des répertoires avec les preuves de dépendance et d'accès aux données. Considérer les dossiers de premier niveau comme des modules ne fonctionne que dans des dépôts particulièrement disciplinés. Les anciennes arborescences regroupent souvent les fichiers par lot de déploiement, habitude d'un auteur, emplacement de copybook ou migration interrompue à mi-chemin.

Commencez par les unités déclarées : projets, paquets, bibliothèques, programmes, formulaires, procédures stockées, traitements batch et cibles de compilation. Recueillez ensuite des relations typées entre ces unités. Les types utiles comprennent imports, calls, includes, compiles_into, reads, writes, submits et generates. Conservez le type. Une table partagée constitue une preuve moins forte d'une limite de module qu'une cible de compilation, et une inclusion textuelle n'est pas la même relation qu'un appel à l'exécution.

Le premier artefact doit être un inventaire lisible par une machine, et non une image. Par exemple :

{"unit":"billing/post_invoice.cbl","kind":"cobol_program","declares":["POSTINV"],"includes":["ARREC"],"reads":["CUSTOMER"],"writes":["AR_LEDGER"],"evidence":["billing/post_invoice.cbl:18-146"]}

Produisez les diagrammes et le texte à partir de cet inventaire. Les modifications deviennent ainsi contrôlables : lorsqu'un programme est déplacé ou qu'un analyseur progresse, l'enregistrement source change en premier et toutes les vues suivent. L'équipe peut aussi interroger la documentation au lieu de contempler un graphe qui occupe tout un mur.

Le regroupement exige de la retenue. Les composantes connexes, déclarations de paquets, préfixes de noms, fichiers de responsabilité et unités de déploiement peuvent proposer des limites. Ils ne doivent pas les inventer en silence. Si les programmes AR* partagent des enregistrements et sont déployés ensemble, qualifiez cet ensemble de groupe de facturation déduit et indiquez la règle qui l'a créé. Une personne pourra ensuite l'accepter, le scinder ou le renommer.

Le texte généré pour un module doit répondre à des questions pratiques : qu'est-ce qui entre dans cette unité ? Que peut-elle appeler ? Quelles données possède-t-elle et lesquelles ne fait-elle que toucher ? Comment est-elle compilée et déployée ? Quelle autre unité cesserait de fonctionner si son interface changeait ? Un rectangle coloré qui ne répond à aucune de ces questions est décoratif.

Les graphes d'appels statiques sont utiles et inévitablement incomplets

Un graphe d'appels statique peut saisir avec fiabilité les appels dont la source permet de résoudre directement la cible. Il peut aussi fournir les relations inverses, souvent plus utiles pour préparer une modification : au lieu de demander ce qu'une fonction appelle, les ingénieurs demandent qui peut atteindre la fonction qu'ils veulent remplacer.

Le manuel de GNU cflow établit précisément cette différence entre graphe direct et graphe inverse pour le C. Il propose aussi des réglages pour filtrer les symboles et contrôler le prétraitement. Cette réserve est importante. Un graphe dépend de l'analyseur du langage, de la configuration du préprocesseur, des options de compilation et des points d'entrée choisis. Lancer un analyseur avec ses réglages par défaut sur tous les fichiers ne revient pas à analyser le programme réellement compilé en production.

La répartition dynamique crée la première grande lacune. Les pointeurs de fonctions, la réflexion, l'injection de dépendances, la répartition COM, les mandataires générés, le CALL dynamique de COBOL et les noms de programmes composés à partir de données peuvent masquer la cible. Un analyseur de source peut enregistrer le point de répartition et l'expression qui choisit la cible, mais il doit créer une relation non résolue plutôt que deviner une destination.

L'exécution externe crée une autre lacune. Les commandes d'interpréteur, les API de soumission de traitements, les déclencheurs de base de données, les consommateurs de messages et les fichiers surveillés par un autre processus franchissent des limites qu'un graphe propre à un langage voit rarement. Le dépôt peut contenir les deux extrémités sans contenir de relation directe entre symboles.

Pour chaque relation, enregistrez le mode de résolution :

• static lorsque la syntaxe et la résolution des symboles identifient la cible.
• configured lorsqu'un manifeste ou un réglage nomme la cible.
• observed lorsqu'une trace d'exécution enregistre la cible.
• possible lorsque l'analyse de la répartition produit un ensemble limité.
• unknown lorsque le point d'appel existe mais que sa destination ne peut pas être résolue.

Ne supprimez pas les relations inconnues pour rendre le dessin plus propre. Ce sont souvent les éléments les plus utiles du document, car ils indiquent où la migration exige une trace ou un entretien avec l'exploitation. Un graphe qui prétend avoir résolu tous les appels dans un système fondé sur la réflexion ou la configuration expose généralement sa propre cécité.

Le modèle de données a trois versions concurrentes

Le dépôt peut produire un schéma déclaré, un schéma utilisé et un modèle métier implicite. Ils se recouvrent, mais les problèmes commencent lorsque la documentation les présente comme une seule réalité.

Le schéma déclaré provient des DDL, fichiers de migration, correspondances ORM, définitions d'enregistrements, copybooks, règles de validation et instantanés des métadonnées de base conservés dans l'arborescence. Il peut identifier les tables, colonnes, types, index, clés déclarées, possibilités de valeur nulle et contraintes. PostgreSQL décrit information_schema.columns comme une vue portable des informations de colonnes tout en précisant que les types propres à PostgreSQL résident finalement dans pg_catalog. C'est un avertissement utile : même les métadonnées d'une base possèdent une couche portable et une couche propre au fournisseur.

Le schéma utilisé vient du code. Les chaînes SQL, constructeurs de requêtes, entrées et sorties de fichiers, classes d'accès aux données, liaisons d'écrans et définitions de rapports montrent les champs que chaque programme lit ou écrit. Cette vue révèle des tables sans clés étrangères déclarées mais reliées de façon régulière, ainsi que des colonnes présentes dans les DDL qui n'apparaissent plus dans le code du dépôt.

Le modèle métier implicite ajoute le sens : un compte appartient à un client, un état C signifie fermé, ou une paire de dates d'effet représente une période de contrat. L'automatisation peut proposer ces relations à partir des noms, jointures, contrôles et transformations répétées. Elle ne peut pas les transformer en faits sans glossaire, test, confirmation d'un opérateur ou données observées.

Une extraction utile laisse les désaccords visibles :

SELECT table_schema, table_name, column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name, ordinal_position;

Comparez cette sortie aux références du dépôt au lieu de choisir arbitrairement une autorité. Si le code sélectionne legacy_code, mais que le schéma capturé ne le contient pas, l'instantané peut être périmé, le SQL conditionnel ou le schéma de production différent. Si les DDL déclarent une clé étrangère qu'aucun code ne suit, la contrainte compte tout de même. L'écart est un constat, pas un désagrément à faire disparaître par fusion.

La filiation au niveau du champ demande la même prudence. Les affectations directes et les transformations nommées peuvent justifier une relation de filiation. Une procédure stockée appelée par une passerelle générique, une macro de tableur ou un export modifié par un opérateur rompent la chaîne. Marquez cette rupture. Ne tracez pas une flèche continue à travers des preuves manquantes.

Les dépendances batch dépassent le JCL

Un dépôt permet de déduire une grande partie d'un graphe batch, mais le JCL ou les scripts seuls contiennent rarement l'ordonnancement de production. Ils montrent les programmes, étapes, procédures, jeux de données, branches sur codes retour et soumissions explicites. Les calendriers, règles de précédence, ressources, substitutions et actions de reprise résident souvent dans la base de l'ordonnanceur ou dans la configuration d'exploitation.

La documentation IBM de Workload Scheduler décrit les prédécesseurs et successeurs d'un traitement, y compris les conditions fondées sur son état ou son code retour. Sa documentation sur le dépôt JCL précise aussi que l'ordonnanceur garde une copie du JCL des traitements soumis dans le plan courant. Ces faits montrent une limite importante : le JCL soumis est un artefact d'exécution, tandis que le plan courant porte l'état d'orchestration. Un dépôt Git qui n'en contient qu'un côté ne peut pas prouver tout le graphe de dépendances.

Dans le dépôt, extrayez au moins quatre classes de relations : ordre des étapes, exécution de programme, flux de données et condition explicite. Une relation producteur-consommateur déduite du fait qu'un traitement écrit un jeu de données et qu'un autre le lit doit rester marquée comme déduction. Les noms de jeux de données peuvent être générationnels, symboliques, remplacés à la soumission ou partagés pour des raisons sans rapport avec l'ordre.

Représentez le résultat sous une forme qui accepte les sources manquantes :

job: CLOSE_AR
steps:
  - exec: EXTRACT_AR
    writes: [AR.CLOSE.GDG(+1)]
  - exec: POST_AR
    when: EXTRACT_AR.RC <= 4
external_predecessors:
  - name: LOAD_RATES
    source: scheduler_export
unresolved:
  - "Symbolic HLQ is supplied by the submission profile"

Le dernier champ fait partie de la documentation, ce n'est pas un aveu gênant. Il indique à l'équipe de migration quel artefact demander ensuite.

Les cartes de contrôle et les sorties de l'ordonnanceur demandent une attention particulière. Une seule ligne d'étape JCL peut alimenter des centaines de lignes de paramètres depuis un jeu de données entretenu hors du contrôle de versions. Une sortie d'ordonnanceur peut réécrire des variables ou choisir une bibliothèque de procédures. Traitez les données de contrôle référencées mais absentes comme une dépendance externe, avec un responsable et une tâche de récupération.

Les preuves d'exécution changent la réponse

L'extraction statique décrit ce que le dépôt autorise. Les preuves d'exécution montrent ce que certaines exécutions ont effectivement fait. Aucune vue ne doit se faire passer pour l'autre.

Les traces enregistrées, journaux d'instructions de base, historiques de traitements, métadonnées de messages, catalogues de fichiers et trafic de production peuvent confirmer des cibles dynamiques et classer les chemins par priorité. Ils peuvent montrer qu'un répartiteur configurable a choisi trois programmes parmi vingt pendant la période observée. Ils ne peuvent pas prouver que les dix-sept autres sont morts. L'absence dans une trace signifie "non observé dans cet échantillon", et non "inaccessible".

La meilleure documentation stocke séparément les relations statiques et observées, puis présente leur intersection et leurs différences. Prenons un point d'appel dont la liste de cibles configurée contient RATEA, RATEB et RATEC. Une trace de clôture mensuelle voit RATEA et RATEC. L'enregistrement correct garde les trois cibles possibles, marque les deux cibles observées et indique la période et l'environnement de capture. Retirer RATEB du graphe transformerait une preuve limitée en fausse affirmation.

Le trafic de production aide aussi à vérifier le comportement pendant une réécriture. Les entrées et sorties peuvent devenir des cas de parité, à condition que la capture supprime ou protège les données sensibles et conserve les variables qui pilotent le comportement. La réussite d'un cas de parité prouve l'accord pour ce cas. Elle n'établit pas une équivalence générale. La documentation doit donc indiquer la couverture par point d'entrée, branche, forme de données et classe d'erreur lorsque ces mesures existent.

L'analyse du dépôt devient ici plus qu'un index mieux présenté. Un graphe statique indique où placer des sondes. Les traces montrent quelles relations non résolues méritent de l'attention. Les écarts entre anciennes et nouvelles exécutions révèlent un comportement non documenté, et ces constats peuvent revenir dans le registre de preuves.

Ne laissez jamais une couche d'exécution effacer la base statique. Les traitements trimestriels silencieux, gestionnaires d'erreurs, extractions réglementaires et procédures de secours peuvent ne pas apparaître pendant une capture ordinaire. Les équipes les déclarent souvent morts parce que la trace normale reste silencieuse, puis découvrent leur fonction lors de l'unique événement où ils s'exécutent.

Le texte généré a besoin de citations et d'expiration

Le texte généré devient fiable lorsqu'un relecteur peut contester chaque affirmation matérielle sans devoir comprendre le générateur à rebours. Placez les références à côté des affirmations et ajoutez la révision d'extraction, la version de l'outil, la configuration et l'heure de génération aux métadonnées du document.

Le commit du dépôt est la date d'effet du document. Si la branche principale change, le document généré est périmé même si son texte semble encore plausible. Régénérez-le dans l'intégration continue ou indiquez clairement le commit qu'il décrit. Je préfère faire échouer un contrôle de fraîcheur plutôt que présenter silencieusement un mélange d'anciens diagrammes et de nouveau code.

Les affirmations exigent des formes de citation différentes. Une affirmation structurelle peut citer des lignes de source. Une affirmation d'exécution doit citer un ensemble de traces ou un export d'historique avec sa fenêtre d'observation. Une définition métier doit citer un glossaire approuvé, une règle, un test ou un relecteur nommé. Sans citation, présentez l'énoncé comme une question ou une déduction.

Utilisez un petit registre de revue au lieu de cacher l'incertitude dans le texte :

ID       CLAIM                                  CLASS       EVIDENCE
DOC-041  POSTINV writes AR_LEDGER               observed    post_invoice.cbl:88
DOC-042  AR_LEDGER is the accounting system     inferred    table name, 6 writers
DOC-043  CLOSE_AR may be safely restarted       unresolved  no recovery rule found

La forme de sortie compte, car elle modifie le comportement des relecteurs. Si les trois affirmations deviennent des paragraphes fluides, les lecteurs ont tendance à les accepter ensemble. Le registre oblige l'affirmation faible à rester faible.

L'expiration doit être sélective. Un inventaire de modules peut être régénéré à chaque fusion. Un sens métier approuvé par un opérateur doit persister jusqu'au changement de sa preuve, et le système doit conserver l'approbation et la source. Une affirmation d'exécution expire lorsque sa fenêtre d'observation ne représente plus l'usage actuel. Une seule estampille "dernière mise à jour" ne peut pas exprimer ces différences.

Les dépôts multilingues exigent un modèle de preuves commun

Aucun analyseur unique ne peut documenter un système qui mêle COBOL, JCL, PL/SQL, scripts, Java et macros de tableur. Chaque langage exige un composant qui comprend ses déclarations et ses règles de résolution, tandis que le résultat combiné exige un vocabulaire commun pour les unités, points d'entrée, ressources de données et relations.

La recherche textuelle garde un rôle, mais elle doit trouver des candidats plutôt qu'affirmer des relations. Chercher un nom de table peut trouver du SQL incorporé, des commentaires, des définitions copiées, des données de test et des champs sans rapport portant le même nom. Un extracteur sensible au langage peut classer certains résultats. Une passe ultérieure de résolution peut relier un appel à une déclaration dans la bonne configuration de compilation.

Normalisez les identités sans effacer les noms d'origine. POSTINV, un nom de fichier source, un nom de module chargé et une opération de l'ordonnanceur peuvent désigner le même exécutable à différentes étapes. Conservez chaque identifiant et ajoutez une relation d'alias étayée. Si l'alias provient seulement d'une convention de nommage, marquez-le comme déduit. Fusionner trop tôt les identités produit de fausses relations difficiles à démêler ensuite.

Les connexions entre langages apparaissent généralement dans les protocoles et les artefacts plutôt que dans les symboles. Un traitement COBOL écrit un fichier plat lu par un script Perl. Un client VB6 appelle une interface COM mise en œuvre en Delphi. Une procédure stockée écrit dans une table de file surveillée par un service. Modélisez le fichier, l'interface, la table ou le message comme un nœud à part entière. Relier directement les deux programmes masquerait le contrat qui les couple vraiment.

Le code généré exige deux enregistrements : l'entrée du générateur et l'artefact produit que la compilation utilise. Analyser seulement les modèles manque le comportement produit. Analyser seulement les fichiers produits rend la responsabilité et la régénération obscures. La documentation doit montrer quel fichier peut être modifié et lequel sera écrasé.

Les grands dépôts posent un problème d'échelle, pas un autre problème de vérité. Analysez les fichiers par incréments, mettez en cache les résultats adressés par contenu et recalculez les relations touchées lorsque les déclarations ou la configuration changent. Ne réduisez pas le périmètre en échantillonnant des dossiers pour appeler ensuite le résultat une carte du système. Une arborescence d'un million de lignes peut être traitée en plusieurs parties, mais ses références transversales doivent encore être résolues contre l'inventaire entier.

Une vérification par échantillon peut rester approfondie

Une équipe peut tester la documentation générée sans relire manuellement tout le dépôt. La vérification doit échantillonner selon le risque et le type de relation, puis appliquer des invariants automatisés pour détecter de vastes catégories d'erreurs d'extraction.

Commencez par des cas de test pour l'analyseur. Donnez à l'extracteur de chaque langage de petits exemples d'appels directs, d'alias, de compilation conditionnelle, de répartition dynamique, d'inclusions, d'entrées mal formées et de commentaires ressemblant à du code. Vérifiez les relations qu'il doit émettre et les fausses relations tentantes qu'il doit rejeter. Conservez les défaillances réelles réduites comme tests de régression.

Exécutez ensuite des invariants sur tout le dépôt. Chaque fichier et chaque ligne cités doivent exister au commit analysé. Chaque cible d'appel résolue doit avoir une déclaration ou une identité externe explicite. Chaque membre d'un module doit exister dans l'inventaire. Chaque type de relation doit utiliser des types de source et de cible autorisés. Ces contrôles ne prouvent pas le sens, mais ils trouvent les jointures cassées et les emplacements périmés avant le relecteur.

Choisissez ensuite des échantillons inégaux. Inspectez toutes les relations inconnues sur les points d'entrée sensibles, toutes les écritures entre modules, toutes les conditions d'ordonnanceur et un échantillon aléatoire d'appels statiques ordinaires. Échantillonnez aussi l'espace négatif : choisissez des mécanismes dynamiques connus et confirmez que le document expose leur incertitude. Une exactitude mesurée uniquement sur les appels directs faciles récompense le mauvais système.

Un rapport d'acceptation compact peut fournir des nombres utiles sans les transformer en note de qualité :

Analyzed commit: 7c41e2f
Parsed files: 18,442 of 18,517 discovered
Skipped files: 75 (list attached to the evidence store)
Resolved call edges: 91,208
Unknown dispatch sites: 613
Broken citations: 0
Scheduler sources: repository JCL only; current-plan export absent

Ces nombres illustrent une forme de sortie, pas une référence de performance. Les lignes importantes sont le dénominateur, la liste des fichiers ignorés et la source d'ordonnancement absente. Annoncer "18 442 fichiers analysés" sans dire que 75 ont été ignorés laisse la panne d'un analyseur disparaître dans un grand total.

Les corrections de revue doivent modifier les règles ou les preuves, pas seulement le paragraphe affiché. Si un relecteur repère un faux alias, ajoutez une contrainte qui empêchera cette fusion la prochaine fois. Si un opérateur confirme une définition métier, enregistrez l'approbation comme une source distincte. Sinon, la régénération reproduira fidèlement chaque erreur déjà corrigée.

La confiance cesse aux frontières dynamiques et humaines

La documentation automatisée cesse d'être fiable lorsque le dépôt ne contient pas l'information qui décide. Les principales frontières sont la sélection dynamique, l'état externe, le code généré ou absent, l'intervention humaine, la configuration propre à un environnement et l'intention métier.

Cette affirmation peut devenir une liste de contrôle :

1. Résolvez chaque artefact référencé. Retrouvez les fichiers inclus, sources générées, bibliothèques de procédures, cartes de contrôle, schémas et manifestes de déploiement. Consignez chaque absence.
2. Comparez la compilation réelle à la disposition du dépôt. Capturez les options du compilateur, symboles conditionnels, étapes de génération de code et unités exactes de déploiement.
3. Superposez les preuves d'exécution sans les traiter comme exhaustives. Conservez la fenêtre d'échantillonnage et l'environnement près de chaque relation observée.
4. Interrogez l'exploitation sur les chemins de reprise, de clôture, de substitution et d'exception. Ces règles vivent souvent dans des procédures, des consoles d'ordonnancement ou la mémoire des personnes.
5. Exigez une source nommée pour les libellés métier. Le développement plausible d'un nom de champ de huit caractères reste une supposition.

Un conseil répandu consiste à faire lire le dépôt par un modèle de langage afin qu'il rédige en une passe un manuel d'architecture complet. Ce conseil plaît parce que le premier résultat arrive vite et paraît cohérent. Il est erroné parce que cette cohérence efface les limites visibles entre les faits analysés, les interprétations et les omissions. Utilisez un modèle pour expliquer un graphe, regrouper les preuves et préparer des questions, mais gardez le graphe de preuves comme autorité.

Les limites de sécurité et d'accès peuvent créer un autre angle mort. Un analyseur qui ne peut pas lire les exports de l'ordonnanceur de production, la configuration chiffrée ou les catalogues de base doit l'annoncer en tête. L'absence d'accès ne doit pas devenir l'absence d'une dépendance.

Le test d'acceptation pratique est simple : choisissez des affirmations au hasard et suivez leurs citations. Si les relecteurs ne peuvent pas reproduire les affirmations structurelles, le système n'est pas prêt. S'ils peuvent les reproduire mais contestent le texte, corrigez la règle de déduction ou la formulation sans jeter les preuves extraites.

La documentation doit piloter le plan de réécriture

La documentation du dépôt justifie son coût lorsqu'elle modifie l'ordre, les tests et le périmètre. Une carte des modules doit identifier les unités remplaçables séparément et les nœuds de partage d'état. Un graphe d'appels inverse doit révéler les appelants qui exigent une couverture de compatibilité. Le modèle de données doit exposer les conflits de responsabilité et les couplages cachés. Le graphe batch doit montrer les clôtures et chemins de reprise qu'une réécriture en services doit préserver.

Pour préparer la migration, interrogez les preuves au lieu de les lire de bout en bout. Demandez quels points d'entrée atteignent un module candidat, quelles tables traversent la limite proposée, quels traitements batch l'invoquent et quelles relations restent non résolues. Une relation non résolue sur un chemin de règlement quotidien mérite une étude avant un utilitaire de rapports parfaitement cartographié, même si l'utilitaire contient davantage de lignes.

La modernisation de l'architecture exige aussi une référence de comportement. Traduire chaque ancien programme dans un nouveau langage conserve des limites accidentelles et donne aux diagrammes générés un air familier, mais la familiarité est un mauvais critère de conception. Utilisez les points d'entrée observés, contrats de données, effets de bord et contraintes d'ordre pour définir la compatibilité. Concevez ensuite les services cibles autour de responsabilités cohérentes.

CodeHero applique cette combinaison à la réécriture des systèmes anciens : sa plateforme lit toute l'arborescence multilingue et un banc de parité compare le remplacement au trafic de production enregistré. Cela ne transforme pas une finalité déduite en fait. L'extraction structurelle et les preuves de comportement ont des tâches séparées, ce qui impose la discipline nécessaire à une réécriture.

Avant d'approuver un document généré, exigez une réponse à une question concrète : quelles affirmations changeraient si l'export de l'ordonnanceur, la trace d'exécution ou l'entretien avec l'exploitation arrivait demain ? Si le document ne peut pas les identifier, il cache l'incertitude au lieu de la gérer. Un dépôt peut produire une excellente carte, mais ses zones blanches doivent rester visibles jusqu'à ce que les preuves les remplissent.

Conservez l'inventaire de preuves après la mise en production de la réécriture. Il devient un oracle de régression pour les changements de dépendances, une source de documentation d'exploitation et un contrôle contre les nouveaux couplages accidentels. Le texte peut vieillir, mais les faits reproductibles liés aux commits peuvent être régénérés à chaque évolution du système.