Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 11 novembre 2026.
En bref
Pour bloquer un nombre sans source, le contrôle doit refuser le document si ce nombre ne renvoie à aucune donnée validée. Une référence permet de retrouver cette donnée dans un registre, c’est-à-dire la liste des données validées pour le document. Le contrat proposé ici prévoit un brouillon contenant ces références, puis un document final affichant les valeurs correspondantes. Dans leur prépublication déposée sur arXiv le 30 septembre 2026, Gibert, Despujols et Rochet décrivent le principe de validation après génération. Notre proposition en précise les motifs de refus et l’étape à corriger. Pour une direction métier, l’enjeu est de conditionner l’acceptation du fichier à un contrôle explicite de ses nombres.
1. À quel moment contrôler les nombres ?
Dans le contrat proposé, le contrôle porte sur le brouillon contenant les références, puis sur leur restitution dans le document rendu. Selon la prépublication de Gibert, Despujols et Rochet du 30 septembre 2026, le système rejette les nombres non justifiés après génération. Il effectue aussi des vérifications après rendu, notamment sur la cohérence du registre et les contradictions narratives. Les auteurs distinguent explicitement ce contrôle du décodage contraint.
Le registre décrit par les auteurs associe aux faits leur valeur, leur unité, leur période et leur catégorie de provenance. Les sources et formules y sont enregistrées lorsqu’elles s’appliquent. Une clé désigne l’identifiant qui permet de retrouver un fait dans cet ensemble. Le contrôle des clés intervient donc après l’admission des données : son travail consiste à vérifier leur emploi dans la sortie.
Pour préciser cette interface, TW3 recommande de conserver ensemble le brouillon, la version du registre et le document rendu. Au stade du brouillon, le validateur cherche les références inconnues et les nombres écrits directement. Au stade du rendu, il compare les valeurs affichées à celles qu’autorise le registre.
Cette organisation constitue une proposition de conception. Elle suppose que le moteur de rendu conserve la correspondance entre chaque référence et son emplacement final. Une validation attachée au seul brouillon laisserait hors de son périmètre les transformations apportées lors de la mise en page. Le responsable du document doit pouvoir identifier exactement le fichier auquel s’applique le verdict.
2. Comment reconnaître une référence autorisée ?
Une référence autorisée doit respecter une syntaxe définie et retrouver exactement un fait admis dans la version attendue du registre. Dans le contrat proposé, la syntaxe précise les caractères permis et les délimiteurs qui séparent la clé du texte courant. La comparaison respecte ces règles ; une ressemblance entre identifiants ne suffit jamais à autoriser une substitution.
La documentation Jinja API de Pallets, sans date de publication indiquée fournit des mécanismes utiles pour une telle implémentation. Sa fonction find_undeclared_variables relève les variables qu’un modèle de document peut demander au contexte d’exécution. Elle couvre aussi les chemins conditionnels dont l’exécution reste inconnue au moment de l’analyse. La classe StrictUndefined provoque une erreur lorsqu’une variable indéfinie est notamment affichée ou comparée. Ce comportement exige sa sélection explicite dans la configuration.
Ces outils sont des appuis possibles à notre proposition, sans être attribués au système TW3 décrit dans la prépublication. Leur emploi demande encore une règle métier : quelles variables correspondent à des faits du registre et lesquelles servent seulement à organiser le document ?
Une clé orpheline désigne ici une référence qui ne retrouve aucun fait dans le registre retenu. Le diagnostic conserve la clé reçue et la version interrogée. Si la référence est inconnue, le champ « clé attendue » reste vide tant qu’aucune correspondance certaine n’est disponible. La reprise consiste à retrouver le fait admis ou à retirer l’énoncé qui en dépend.
3. Comment traiter un nombre écrit directement ?
Un nombre factuel écrit directement dans le brouillon doit déclencher un refus lorsqu’aucune référence admise ne le justifie. L’annexe A de la prépublication TW3 de septembre 2026 décrit le pipeline d’origine : un script vérifie les nombres cités contre un fichier de rapprochement et bloque le processus en cas d’échec. Il recherche notamment les nombres dépourvus de clé. Cette annexe expose une chaîne antérieure au système présenté dans la section consacrée à la génération.
Pour appliquer ce principe, notre proposition est de définir les formes numériques couvertes avant d’écrire le détecteur : entiers, décimales, signes, pourcentages, dates et nombres écrits en lettres. Le contrat doit aussi délimiter les zones inspectées, notamment le corps, les titres, les tableaux et les notes. Une forme ou une zone que l’outil ne sait pas analyser doit apparaître comme non contrôlée dans le diagnostic.
La pagination appelle une règle distincte. Une exception peut autoriser les numéros produits par le composant de mise en page dans la zone réservée à cet usage. Elle doit préciser son emplacement, son producteur et sa justification. Une règle qui dispenserait tous les nombres d’un pied de page serait trop large pour ce contrat.
Pour un indicateur calculé, le chemin proposé passe par l’admission du résultat dans le registre avant sa rédaction. Le contrôleur retrouve alors sa clé comme celle de tout autre fait. Il refuse l’ajout d’un calcul improvisé dans le texte. Chaque exception appliquée reste visible dans le rapport de validation afin que le lecteur du rapport connaisse le périmètre effectivement vérifié.
4. Comment comparer la valeur rendue au registre ?
La comparaison doit relier l’emplacement rendu, la clé d’origine et la règle de formatage applicable. Retrouver quelque part dans le registre une valeur identique ne suffit pas à établir cette correspondance. Dans l’interface proposée, le moteur de rendu transmet la clé utilisée pour chaque occurrence ; le validateur reconstitue ensuite la forme attendue à partir du fait et de la politique d’affichage.
La documentation Validators de Pydantic, sans date de publication indiquée explique comment fournir un contexte aux méthodes de validation. Les fonctions de contrôle peuvent y accéder par la propriété context. Cette possibilité permettrait de transmettre à un validateur le registre admis et la politique de formatage, sous réserve de programmer les vérifications correspondantes.
Pour notre contrat, une version absente ou incompatible entraîne un refus avant la comparaison des valeurs. Une référence résolue donne accès à une valeur attendue ; une transformation d’affichage autorisée détermine sa représentation. Tout écart restant est enregistré avec l’occurrence concernée. Le validateur ne choisit pas une nouvelle tolérance pour faire accepter le fichier.
Il faut également décider ce que devient une donnée manquante. La documentation Pydantic indique que les valeurs par défaut échappent à la validation si celle-ci n’est pas configurée pour elles. Dans cette conception, les champs portant une valeur factuelle suivent donc une politique explicite de validation, y compris lorsqu’ils reçoivent une valeur par défaut. Les arrondis et changements d’unité relèvent d’une politique distincte, référencée par le contrôle.
5. Quel diagnostic retourner à la fabrication ?
Le diagnostic doit permettre de localiser le défaut et de reprendre l’étape responsable sans accepter le fichier défectueux. La rubrique sur les erreurs de la documentation Pydantic, sans date de publication indiquée présente notamment ValueError et PydanticCustomError. La seconde permet de définir un type d’erreur et un message paramétré. Ces possibilités servent à construire un vocabulaire stable de refus.
Le tableau suivant propose les classes du contrat. Il ne reproduit pas une interface logicielle publiée par TW3.
| Classe d’erreur proposée | Condition de refus | Étape à reprendre |
|---|---|---|
| Référence mal formée | La référence ne respecte pas la syntaxe convenue | Production du brouillon |
| Clé orpheline | La clé reçue est absente du registre retenu | Liaison du brouillon aux faits |
| Nombre sans référence | Une occurrence factuelle ne porte aucune clé ni exception autorisée | Rédaction ou admission du fait |
| Écart de valeur | La valeur rendue diffère de la valeur attendue après formatage autorisé | Substitution ou rendu |
| Format non admis | Une transformation sort de la politique retenue | Configuration du formatage |
| Contrôle incomplet | Le registre manque, sa version est incompatible ou une zone prévue reste illisible | Préparation des entrées ou extraction |
Chaque entrée du rapport comporte le fichier concerné, l’emplacement du défaut et la classe d’erreur. Elle indique aussi la clé reçue, la clé attendue lorsqu’elle est déterminable, la règle enfreinte et l’étape à reprendre. Un repère dans le brouillon peut être un champ ou une cellule ; après rendu, il faut pouvoir retrouver le passage sur la page concernée.
Le fichier refusé et le rapport restent disponibles pour le diagnostic. Le circuit d’acceptation reste bloqué jusqu’à une nouvelle validation. Dans l’annexe A de septembre 2026, les défauts sont corrigés à leur étape d’origine, puis les documents sont régénérés avant la nouvelle revue. Cette règle évite de limiter la correction à une retouche du document final.
6. Quelles erreurs ce contrôle laisse-t-il ouvertes ?
Une clé existante et une valeur correctement rendue ne prouvent pas que la phrase exprime le bon fait. La prépublication de Gibert, Despujols et Rochet du 30 septembre 2026 distingue les vérifications de cohérence du registre des contrôles de contradictions narratives. Une phrase peut employer une donnée enregistrée tout en lui associant une période erronée ou une interprétation incompatible avec son périmètre.
Le contrat proposé réserve donc la validation du sens à un contrôle complémentaire. Il exige, pour le volet numérique, des entrées identifiées : brouillon, registre versionné, politique de formatage, exceptions autorisées et correspondance avec le rendu. Sa sortie comprend un verdict d’acceptation et un rapport localisé. Une erreur bloquante ou une inspection incomplète empêche l’acceptation. Toute correction qui modifie les entrées impose une nouvelle exécution.
Pour la recette, il est utile de vérifier chaque classe de refus, puis de contrôler qu’une correction à la source débloque les documents régénérés. Le responsable métier valide les exceptions admises ; l’équipe technique vérifie leur application dans les zones prévues.
Les auteurs précisent que leur étude ne mesure pas séparément l’effet de chacun des composants. Le bénéfice à demander au validateur est donc un comportement vérifiable sur un périmètre défini. Son acceptation atteste que les règles numériques programmées ont été satisfaites pour les entrées enregistrées.
FAQ
Comment bloquer un nombre non sourcé ?
Exigez une référence à un fait admis pour chaque occurrence factuelle du brouillon. Le contrôleur refuse le document lorsqu’il ne peut pas résoudre cette référence ou justifier une exception explicitement autorisée. Après rendu, il vérifie aussi la correspondance entre la clé et la valeur affichée, selon le contrat proposé ici.
Qu’est-ce qu’une clé orpheline ?
C’est une référence présente dans le document qui ne retrouve aucun fait dans le registre retenu. Le diagnostic doit conserver la clé reçue et identifier la version consultée. La correction demande de rétablir une liaison certaine avec un fait admis ou de retirer l’énoncé concerné avant de relancer la validation.
Le contrôle intervient-il pendant le décodage ?
Dans leur prépublication déposée sur arXiv le 30 septembre 2026, Gibert, Despujols et Rochet situent le rejet des nombres non justifiés après génération et le distinguent du décodage contraint. Le contrat proposé porte donc sur la vérification d’un texte déjà produit.
Un nombre référencé est-il forcément pertinent ?
Sa référence établit une liaison avec le registre utilisé. La pertinence de son emploi demande aussi de vérifier la période, le périmètre et le sens de la phrase. Le contrôle numérique et la revue des contradictions doivent conserver des verdicts distincts pour que le responsable sache quelles vérifications ont effectivement abouti.
Où corriger le défaut ?
La reprise doit viser l’étape qui a produit l’erreur : admission du fait, rédaction, substitution ou rendu, selon le diagnostic. L’annexe de la prépublication de Gibert, Despujols et Rochet du 30 septembre 2026 prévoit une correction à la racine et une régénération de tous les documents avant la nouvelle revue. Les sorties corrigées repassent ensuite par le circuit d’acceptation.
Pour aller plus loin
- Arrondis et décimales : définir une politique numérique avant de générer un rapport.
- Quand le titre contredit les chiffres : contrôler les affirmations de tendance.
- Décodage contraint ou validation après génération : où faire respecter les règles ?.
Sources
- Gibert, Despujols et Rochet, Better Deck or Different Judge? Evaluating Agentic Harness Gains in Corporate and Investment Banking, prépublication déposée sur arXiv le 30 septembre 2026, consulté le 9 octobre 2026. Texte intégral, sections sur la génération et les limites, annexe A.
- Pallets, Jinja API, sans date de publication indiquée, consulté le 9 octobre 2026.
- Pydantic, Validators, sans date de publication indiquée, consulté le 9 octobre 2026.