Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 9 novembre 2026.
En bref
Un registre de faits rassemble les données retenues, leur signification et leur origine pour alimenter les calculs et les documents produits par un agent. Chaque donnée reçoit une clé, c’est-à-dire un identifiant que les documents peuvent reprendre. La direction peut ainsi demander quelle valeur a été utilisée et sur quelle base. La prépublication de Gibert, Despujols et Rochet déposée sur arXiv le 30 septembre 2026 décrit un tel registre. Le schéma proposé ici traduit ce principe en décisions de conception : identifier les faits, conserver leurs dépendances et organiser les corrections.
1. Qu’est-ce qui identifie un fait ?
Dans le schéma proposé, un fait s’identifie par une clé stable associée à une définition métier et à ses dimensions. Dans le système décrit par Gibert, Despujols et Rochet dans leur prépublication du 30 septembre 2026, un moteur construit un registre typé : chaque fait porte notamment une valeur, une unité, une période et une classe de provenance. Un registre typé désigne ici un ensemble de données dont la nature et les champs attendus sont explicités.
Pour passer de cette description à une interface utilisable, TW3 recommande de séparer la clé du libellé destiné au lecteur. Le libellé peut évoluer pour devenir plus compréhensible. La clé conserve le lien entre le fait et ses emplois. Les noms de champs ci-dessous constituent une proposition de conception du cabinet ; ils ne décrivent pas les champs du logiciel étudié.
| Champ proposé | Définition et contrainte |
|---|---|
registre_id, version_registre | Identifient l’ensemble de faits livré aux consommateurs et son état figé. |
fait_id, libelle, definition | Relient une clé stable à une désignation lisible et à un sens métier explicite. |
type_valeur, valeur | Définissent la nature de la donnée et son contenu lorsqu’il est disponible. |
unite, periode, perimetre | Décrivent comment interpréter la valeur et à quoi elle se rapporte. |
disponibilite, motif | Distinguent une donnée utilisable d’une donnée manquante ou en attente de validation. |
classe_provenance, sources | Indiquent comment le fait a été obtenu et où retrouver son appui. |
formule_ref, entrees | Relient un résultat à une règle de calcul versionnée et aux faits consommés. |
responsable, correction_de | Désignent le propriétaire métier et la version corrigée, le cas échéant. |
Dans cette proposition, la clé est unique à l’intérieur du registre. La référence complète combine l’identité du registre, sa version et la clé du fait. Une correction de valeur conserve la clé et crée une nouvelle version. Une modification de définition, d’unité, de période ou de périmètre crée un autre fait. Cette convention doit être arrêtée avant que plusieurs applications commencent à consommer les mêmes données.
2. Quels champs rendent la valeur interprétable ?
La valeur devient interprétable lorsque son unité, sa période et son périmètre sont explicités. Le tutoriel xBRL-JSON de XBRL International, publié le 11 août 2021, décrit un fait comme une valeur accompagnée de dimensions qui lui donnent son sens. Il distingue notamment le concept représenté, l’entité concernée, la période et l’unité. La période peut correspondre à un instant ou à une durée.
Cette distinction fournit un appui au schéma proposé. Définissez les dimensions exigées pour chaque famille de faits. Un champ periode doit préciser s’il représente une date d’observation ou un intervalle. Le perimetre doit désigner l’ensemble couvert par la valeur selon une nomenclature partagée. Une rédaction libre différente à chaque collecte rendrait les rapprochements ambigus.
L’état de disponibilité mérite une règle propre. Dans notre proposition, une valeur absente s’accompagne d’un motif et d’un responsable chargé de la compléter ou de trancher. Une donnée en attente de validation reste identifiable, mais son état empêche son utilisation dans un calcul destiné au document. Cette règle rend l’absence exploitable par le processus de production.
Séparez aussi la donnée de son affichage. L’unité appartient à la définition du fait ; le nombre de décimales affichées relève du rendu. Le tutoriel XBRL explique que les valeurs numériques y sont représentées par des chaînes de caractères pour préserver leur précision lors du traitement. Un registre peut reprendre cette convention à condition de prévoir la conversion vers le type de calcul retenu et d’en contrôler la validité. La vue destinée au lecteur applique ensuite une règle d’affichage explicite.
3. Comment séparer donnée observée et donnée calculée ?
La classe de provenance doit déterminer les pièces attendues pour accepter un fait. La prépublication de Gibert, Despujols et Rochet du 30 septembre 2026 indique que le registre conserve les sources et les formules lorsqu’elles s’appliquent. Elle représente les informations détenues par la banque qui restent indisponibles comme des manques nommés.
Pour le schéma de cet article, nous proposons les classes « observé » et « calculé ». Un fait observé conserve une référence vers sa source et un emplacement précis dans celle-ci. Un fait calculé conserve une référence de formule et les références complètes de ses entrées. Ces classes sont une convention de conception ; la disponibilité reste un champ distinct, car un calcul peut lui aussi attendre une entrée manquante.
La formule doit pointer vers une règle dont la version est conservée. Ses entrées doivent permettre de retrouver les valeurs effectivement consommées. Un résultat devient alors contrôlable depuis le registre : le relecteur peut demander la règle appliquée, les données utilisées et leur origine. La référence documentaire du résultat peut être obtenue en remontant ses dépendances, tout en conservant les sources directement associées à sa méthode.
Prévoyez une admission conditionnelle. Un fait observé sans source exploitable reste en attente. Un fait calculé dont une entrée manque reste indisponible. Une dépendance circulaire, dans laquelle un résultat dépend finalement de lui-même, doit déclencher un rejet. Ces règles doivent figurer dans le contrat de production du registre et dans les messages retournés au producteur des données.
4. Quelles contraintes protégeront l’identité du registre ?
La protection du registre exige de contrôler chaque fait puis les relations entre les faits. La documentation Object de JSON Schema, sans date de publication indiquée, distingue la définition des propriétés de leur présence obligatoire. Le mot-clé properties décrit les champs ; required impose leur présence. additionalProperties peut interdire les champs non prévus. propertyNames permet de contrôler les noms des propriétés indépendamment de leurs valeurs.
Cette dernière possibilité convient si les faits sont stockés dans un objet dont les propriétés sont leurs clés. Si fait_id est un champ dans une liste de faits, sa valeur doit recevoir sa propre règle de validation. Définir le format d’une clé ne règle toutefois pas la question de son unicité dans cette liste : prévoyez un contrôle dédié lors de l’admission du registre.
Organisez les contrôles autour des engagements du schéma. Pour chaque ligne, vérifiez le type de valeur, les dimensions exigées et les éléments requis par la classe de provenance. À l’échelle de l’ensemble, contrôlez les doublons, l’existence des faits référencés et la disponibilité des entrées de calcul. Vérifiez également que chaque source et chaque formule référencées peuvent être retrouvées dans la version livrée.
Un rejet doit indiquer la clé concernée, le champ en cause et la règle violée. Il doit distinguer une dimension absente d’une référence orpheline, c’est-à-dire une référence qui ne mène à aucun élément du registre. Le producteur sait ainsi où corriger. La conformité structurelle doit rester accompagnée d’une validation métier de la valeur et de son appui documentaire.
5. Comment fournir les faits au rédacteur et au moteur de rendu ?
Le rédacteur et le moteur de rendu doivent consommer des vues du même registre figé. Dans la prépublication de Gibert, Despujols et Rochet du 30 septembre 2026, la production narrative combine des phrases construites à partir du registre, des gabarits et des interventions conditionnelles du modèle. La validation intervient après la génération et rejette les nombres sans appui.
Pour mettre ce principe en œuvre, fournissez au rédacteur la liste des clés admises avec leur libellé, leur définition et leurs dimensions. Cette vue sert à choisir le fait pertinent et à construire une phrase compatible avec son sens. Les éléments indisponibles doivent y être reconnaissables afin que la rédaction puisse signaler un manque lorsque le document l’exige.
Le moteur de rendu reçoit la référence du registre, les clés employées et les règles de présentation. Il remplace chaque référence par la valeur correspondante. Une clé inconnue ou une version différente de celle attendue doit interrompre le rendu. Le document conserve la référence de la version consommée pour permettre une relecture ultérieure.
Prévoyez enfin une vue de contrôle, associant chaque emploi dans le document au fait et à sa provenance. Cette vue peut servir à la personne qui valide le livrable sans encombrer le texte destiné au lecteur. Les formats de sortie partagent ainsi les mêmes données tout en adaptant leur présentation. Le droit de modifier une valeur reste attaché au processus de correction du registre.
6. Comment gérer une correction du registre ?
Une correction doit produire une version identifiable et permettre de retrouver les documents concernés. L’annexe consacrée au pipeline d’origine dans la prépublication du 30 septembre 2026 décrit des sorties versionnées à chaque étape. Elle prévoit une correction à l’étape responsable de l’erreur, suivie de la régénération des documents et d’une nouvelle revue. Ce pipeline d’origine doit être distingué du système évalué décrit dans le corps du texte.
Le schéma proposé prolonge ce principe en attribuant un propriétaire métier à chaque famille de faits. Lorsqu’une correction est acceptée, conservez la version précédente, le motif du changement et la référence qui relie les versions. La nouvelle version entre dans le circuit de validation avant de devenir disponible pour la rédaction.
Les dépendances enregistrées servent alors à identifier les calculs à reprendre. Les références conservées par les documents permettent de signaler les sorties devenues anciennes. Une règle de diffusion doit préciser qui décide leur remplacement et à quel moment les documents régénérés peuvent circuler.
La livraison du registre comprend donc sa définition de champs, ses règles de validation et la convention de correction. Pour la direction métier, le point à trancher est la responsabilité d’admission des données. Pour la DSI, il s’agit de préserver les versions et de rendre les références vérifiables tout au long de la production.
FAQ
À quoi sert un registre de faits ?
Il fournit aux calculs et aux documents un ensemble identifié de données admises. Sa clé permet de retrouver la définition, les dimensions et l’origine d’un fait. Dans le schéma proposé, conserver la version utilisée rend aussi possible la relecture d’un document après une correction.
Une table de nombres suffit-elle ?
Elle peut servir de support si chaque ligne porte les informations nécessaires à son interprétation. Prévoyez une définition, les dimensions applicables, une provenance et un état de disponibilité. Une unité ou une période manquante doit être traitée selon les règles d’admission de la famille de faits concernée.
Comment articuler registre et recherche documentaire ?
Le composant décrit dans la prépublication est un registre structuré de faits. Dans notre proposition, la recherche documentaire intervient en amont pour alimenter la collecte. L’entrée des données dans le registre reste soumise à une validation avant leur utilisation dans les calculs et les documents.
Une formule doit-elle conserver ses entrées ?
Oui, dans le schéma proposé, chaque résultat calculé conserve les références de ses entrées et la version de sa formule. Cette exigence prolonge l’enregistrement des sources et des formules décrit dans la prépublication. Elle permet au relecteur de retrouver les éléments nécessaires pour vérifier le calcul.
Peut-on modifier une clé après génération ?
Une clé déjà consommée doit rester résoluble dans la version utilisée par le document. Pour corriger la valeur du même fait, créez une nouvelle version du registre. Si sa définition ou ses dimensions changent, attribuez une nouvelle clé et examinez les sorties concernées avant de les régénérer.
Pour aller plus loin
- Contrat de données d’un agent : fixer ce que la rédaction reçoit et peut utiliser
- Provenance des faits : relier une phrase à sa source avec le modèle W3C PROV
- Unités, périodes et périmètres : les dimensions qui donnent un sens aux chiffres
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, notice consultée le 9 octobre 2026 ; texte intégral consulté le 9 octobre 2026.
- JSON Schema, Object, sans date de publication indiquée, consulté le 9 octobre 2026.
- XBRL International, xBRL-JSON tutorial and examples, 11 août 2021, consulté le 9 octobre 2026.