Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 30 octobre 2026.

En bref

Corriger à la source consiste à modifier la donnée ou la règle responsable d’une erreur, puis à refaire les documents qui en dépendent. Pour une direction métier, la décision porte sur le périmètre des pièces à remplacer avant leur remise. La prépublication de Gibert, Despujols et Rochet déposée sur arXiv le 30 septembre 2026 décrit dans son annexe A une correction à l’étape d’origine suivie de la régénération de tous les documents. Nous recommandons de préparer cette opération en reliant chaque pièce aux informations et aux règles utilisées pour la produire. La procédure ci-dessous propose de délimiter le changement, de relancer les contrôles et de consigner la décision de remise.

1. Comment trouver l’étape responsable du défaut ?

Il faut remonter de l’erreur visible à l’opération qui l’a introduite. Dans l’annexe A de la prépublication TW3 du 30 septembre 2026, un échec se corrige à son étape d’origine, avant régénération et nouvelle revue. Cette règle donne le point de départ de l’analyse d’impact : rechercher les autres documents susceptibles de reprendre la même erreur.

Pour appliquer cette règle, ouvrir un relevé de défaut avec l’emplacement concerné, le contenu contesté et le motif de la correction. Retrouver ensuite l’entrée utilisée pour produire ce contenu. Le diagnostic proposé distingue une erreur dans la donnée, une erreur de calcul, une consigne de rédaction inadéquate et un défaut de mise en page. Le fichier où apparaît le symptôme sert à commencer l’enquête ; le composant à modifier dépend de ce qu’elle établit.

Le système décrit dans le corps de la prépublication utilise un registre de faits avec valeur, unité, période et provenance, auquel s’ajoutent les sources et les formules lorsqu’elles s’appliquent. Ce registre offre un point de comparaison entre l’information attendue et son expression dans le document.

Dans la procédure proposée, confronter successivement l’entrée, le calcul éventuel, le texte produit et son rendu. Consigner le premier endroit où le défaut apparaît et l’élément qui justifie ce diagnostic. Si le texte est correct mais devient illisible après mise en page, orienter la correction vers le rendu. Si l’entrée est erronée, partir de cette entrée pour établir le périmètre à reconstruire.

2. Quelles dépendances faut-il connaître ?

Il faut connaître les entrées et les règles dont dépend chaque sortie. Le manuel Ninja, daté de juillet 2025, décrit une relation explicite entre fichiers d’entrée, règle de construction et fichiers produits. Lorsque les entrées changent ou que les sorties manquent, Ninja exécute la règle pour régénérer ces sorties. Cette organisation fournit une analogie pour concevoir une chaîne documentaire.

Un graphe de dépendances désigne ici la carte des relations entre ce qui entre dans une étape et ce qui en sort. Pour l’analyse d’impact, nous proposons d’y relier les sources au registre des faits, puis les faits aux clauses rédigées, aux pages et aux fichiers remis. Ajouter les gabarits, c’est-à-dire les modèles de structure ou de présentation, ainsi que les consignes utilisées par les rôles de rédaction. Chaque relation doit permettre de retrouver la version effectivement utilisée.

Le manuel distingue aussi des dépendances implicites, dont les modifications provoquent une reconstruction comme celles des dépendances explicites. « Implicite » a ici un sens technique : la dépendance est déclarée ou découverte par le système, même si elle ne figure pas dans les arguments de la commande. Pour la méthode documentaire proposée, un fichier lu en arrière-plan doit donc entrer dans l’analyse d’impact.

Avant de fixer le périmètre, examiner les entrées réelles de chaque étape avec son responsable. Livrer une liste des documents concernés accompagnée du chemin qui les relie à la modification. Les dépendances encore incertaines deviennent des points à résoudre avant de décider d’une reconstruction ciblée.

3. Quand invalider les sorties existantes ?

Il est utile de suspendre la remise des sorties concernées dès que la correction de leur entrée est décidée. Le modèle PROV-DM du W3C, recommandation du 30 avril 2013, définit la révision comme une dérivation dont le résultat est une version révisée d’une entité d’origine. Cette relation permet de décrire le lien entre une version antérieure et sa correction.

Dans notre proposition de procédure, invalider une sortie signifie la retirer du lot admissible à la remise pendant son actualisation. Il s’agit d’un statut de travail propre à cette procédure. Conserver le fichier antérieur avec son identifiant et noter pourquoi il doit être remplacé. Donner un nouvel identifiant à la version corrigée, puis la relier à la précédente. La politique de conservation de l’organisation détermine les modalités d’archivage.

Pour chaque document affecté, enregistrer la version de l’entrée consommée et celle attendue après correction. Ce rapprochement permet au responsable du lot de suivre la transition sans se fier au seul nom du fichier. Une pièce reconstruite reste en attente de validation tant que les contrôles prévus pour sa nouvelle version ne sont pas terminés.

La décision attendue à cette étape est une liste de remplacement : documents suspendus, nouvelles versions attendues et responsable de leur validation. Prévoir également le traitement des copies déjà remises, selon le circuit de diffusion de l’organisation. Cette action relève de la clôture métier ; elle doit être attribuée à une personne capable de confirmer le remplacement auprès des destinataires concernés.

4. Faut-il tout régénérer ou seulement une partie ?

La chaîne documentaire d’origine prévoit la régénération de tous les documents. L’annexe A de la prépublication TW3 déposée sur arXiv le 30 septembre 2026 place cette opération après la correction à l’étape racine et avant la nouvelle revue. Une reconstruction partielle serait une autre option de conception, dont il faut établir les conditions.

L’analogie avec le manuel Ninja permet de formuler cette option : suivre les dépendances à partir de l’élément modifié et reconstruire les sorties atteintes. Pour une chaîne documentaire, cela suppose de représenter aussi les liens de contenu. Un changement de fait peut imposer la révision d’une phrase de conclusion ou d’un titre qui l’interprète. Dans la méthode proposée, ces interprétations font partie du périmètre à examiner.

Avant de retenir une reconstruction ciblée, demander une justification pour chaque pièce conservée : ses entrées et ses règles sont-elles inchangées ? Une étape intermédiaire qu’elle utilise a-t-elle été reconstruite ? Sa cohérence avec les autres documents doit-elle être revue ? Conserver les réponses avec la décision de périmètre.

Si ces relations restent incertaines, retenir la régénération intégrale comme choix de procédure. La sélection partielle reste une option à évaluer, sans gain de temps annoncé. Le livrable de cette étape est un ordre de reconstruction qui précise les versions d’entrée à employer et les sorties à produire. Éviter d’introduire une nouvelle modification pendant son exécution : ouvrir une correction distincte permet de garder un motif identifiable pour chaque changement.

5. Quels contrôles relancer après reconstruction ?

Il faut vérifier les documents reconstruits à partir de leurs nouvelles entrées, puis examiner leur rendu final. Dans le système décrit par TW3 dans la prépublication déposée sur arXiv le 30 septembre 2026, la vérification des fichiers rendus examine les défauts de mise en page et les contradictions narratives, ainsi que la cohérence du registre et la configuration du modèle. Dans la chaîne d’origine décrite en annexe, la revue reprend après régénération et un contrôle visuel bloquant accompagne la mise en page des documents admis.

La méthode proposée consiste à rattacher chaque contrôle à ce qu’il vérifie. Pour une donnée corrigée, contrôler ses reprises et les calculs qui en dépendent. Pour une formule modifiée, recalculer les résultats concernés et relire les conclusions associées. Pour un gabarit corrigé, examiner les pages qui l’emploient, y compris les débordements de texte ou les ruptures de présentation.

Enregistrer chaque résultat avec la version contrôlée et les références d’entrée correspondantes. Une validation antérieure reste attachée à son ancienne version. Prévoir également une revue du lot pour examiner les relations entre pièces : cohérence des formulations, concordance des références et présence des fichiers attendus.

Organiser enfin le retour en correction. Un échec doit retrouver son responsable et l’étape à reprendre ; la nouvelle tentative doit produire un résultat de contrôle identifiable. Pour clôturer cette étape, remettre la liste des vérifications réalisées, leur résultat et les éventuelles réserves à arbitrer. Le responsable métier peut alors décider de la remise sur la base du lot effectivement contrôlé.

6. Comment clôturer la correction ?

La correction se clôture par une décision documentée sur les versions à remettre. Le W3C, dans PROV-DM du 30 avril 2013, distingue le lien de révision et l’attribution d’une entité à un agent responsable. Ces notions servent ici à organiser la trace du remplacement et des responsabilités.

Pour le dossier de clôture proposé, réunir les éléments déjà produits au cours de la correction :

  • Le motif initial et l’emplacement du défaut observé.
  • L’entrée ou la règle modifiée, avec les versions avant et après correction.
  • Le périmètre retenu et les relations qui justifient ce choix.
  • Les fichiers reconstruits et les résultats des contrôles associés.
  • La décision métier, son responsable et la liste des versions remplacées.

Faire correspondre cette liste aux fichiers effectivement remis. Si des pièces ont été conservées sans reconstruction, joindre la justification de leur exclusion du périmètre. Si une réserve subsiste, lui attribuer un responsable et une décision attendue ; le statut du lot doit rester compréhensible pour la personne qui le reçoit.

Terminer par un retour sur la cause. L’annexe A de la prépublication TW3 du 30 septembre 2026 prévoit un registre des défauts qui traverse les exécutions et dont les erreurs récurrentes alimentent des règles de contrôle. Dans la procédure proposée, examiner à la clôture si le défaut corrigé justifie une vérification supplémentaire ou une dépendance mieux décrite. Le dossier obtenu doit permettre de comprendre ce qui a changé, de retrouver les pièces remplacées et de savoir sur quelle validation repose la remise.

FAQ

Pourquoi corriger à la source ?
La correction à l’étape d’origine permet de reprendre les documents qui partagent l’entrée ou la règle concernée, selon le principe décrit dans l’annexe A de la prépublication TW3 du 30 septembre 2026. La procédure proposée commence donc par rechercher cette dépendance commune et par définir les pièces à remplacer.

La chaîne d’origine reconstruit-elle tout ?
Oui. L’annexe A prévoit la régénération de tous les documents après correction à la racine, puis une nouvelle revue. Pour appliquer cette règle, il convient de fixer la composition du lot avant de relancer sa fabrication.

Une reconstruction partielle est-elle décrite ?
Cet article la propose comme option de conception fondée sur l’analogie avec Ninja. Sa mise en œuvre suppose de retrouver les dépendances, leurs versions et les raisons de conserver certaines pièces. Elle doit faire l’objet d’une décision explicite sur le périmètre à reconstruire.

Peut-on supprimer l’ancienne version ?
La politique de conservation de l’organisation doit guider cette décision. Pour la méthode proposée, préserver les éléments nécessaires à la relecture de la correction et au lien entre versions, puis distinguer clairement les archives des fichiers admis à la remise.

Rejouer garantit-il le même texte ?
La procédure proposée ne garantit pas un texte identique à chaque exécution. Le critère de clôture retenu porte sur la cohérence des nouvelles pièces avec les entrées corrigées et sur leur validation avant remise.

Pour aller plus loin

Sources