Contrat de données d’un agent : fixer ce que la rédaction reçoit et peut utiliser

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

En bref

Le contrat de données d’un agent fixe les informations autorisées, les champs obligatoires et les conditions à remplir avant de commencer la rédaction. Il permet à la direction métier de décider quels manques imposent un retour à la collecte. Dans une prépublication déposée sur arXiv le 30 septembre 2026, Gibert, Despujols et Rochet décrivent un ensemble de données autonome et des règles qui fixent ce que les étapes suivantes ne doivent plus supposer. Le présent guide propose de traduire ce principe en règles de remise. Il distingue les données reçues, leur contrôle et la décision de les accepter. Les clauses proposées constituent une méthode de conception à adapter au livrable.

1. Que doit fixer le contrat avant toute rédaction ?

Le contrat doit définir le périmètre autorisé du document et les responsabilités de ceux qui fournissent, vérifient et utilisent les données. Un contrat de remise désigne ici la spécification qui permet de décider si un ensemble de données peut entrer en rédaction.

L’annexe A de la prépublication de Gibert, Despujols et Rochet, déposée le 30 septembre 2026, décrit le processus d’origine : la collecte aboutit à un bloc autonome assorti d’un contrat qui fixe ce que les étapes ultérieures ne doivent plus supposer. Le système décrit dans le corps de la prépublication prolonge ce processus et utilise un registre de faits. Le contrat proposé ici porte sur la remise des entrées ; l’organisation de ce registre constitue un sujet distinct.

Nous recommandons de commencer par une fiche de remise approuvée par le responsable métier. Elle précise le mandat, le destinataire du document, son périmètre et la date de référence. Elle nomme les sources admises et les champs attendus. Pour chaque exigence, elle indique qui peut la modifier et ce qui doit être revérifié après modification.

La répartition des rôles mérite une clause explicite. Le producteur rassemble les données et leurs références. Le responsable métier arbitre leur admissibilité pour la décision visée. L’équipe technique traduit ces arbitrages en contrôles. Le composant de rédaction reçoit le bloc accepté et ses limites. Toute correction du bloc revient au producteur désigné, puis repasse par la validation prévue. Cette organisation est une proposition du cabinet, à ajuster aux responsabilités de l’entreprise.

2. Comment décrire les champs obligatoires ?

Chaque champ doit avoir un sens métier, un type attendu et une règle de présence. Le schéma est la description formelle de cette structure, exploitable par un programme de contrôle.

Dans sa documentation Object, sans date de publication indiquée, JSON Schema distingue la définition des propriétés avec properties, leur présence obligatoire avec required et les propriétés supplémentaires avec additionalProperties. Déclarer un champ ne suffit donc pas à l’exiger. Une propriété présente avec la valeur null reste distincte d’une propriété absente.

Le tableau suivant propose une base de spécification, sans données remplies. Les obligations et les producteurs sont des choix de conception à faire approuver.

Précisez ensuite le nombre d’éléments permis dans chaque liste, appelé cardinalité. La documentation Array de JSON Schema, sans date indiquée, prévoit minItems et maxItems pour encadrer cette longueur. Dans la proposition ci-dessus, une liste de sources vide doit entraîner un retour au producteur.

Pour une donnée indisponible, conservez son identité et un état explicite. Le contrat doit dire si une valeur nulle est autorisée dans cet état. Il doit aussi choisir le traitement d’un champ inconnu : refus ou extension prévue. Un champ accepté doit avoir un sens connu du composant de rédaction.

3. Comment exprimer les dépendances entre champs ?

Les obligations conditionnelles doivent relier un déclencheur identifiable aux informations nécessaires pour traiter le livrable. Un sous-schéma désigne une partie du schéma qui porte un ensemble de règles.

La documentation Conditional schema validation de JSON Schema, sans date indiquée, propose plusieurs mécanismes. dependentRequired impose la présence de champs lorsqu’un autre est présent ; la dépendance inverse doit être déclarée séparément. dependentSchemas applique un sous-schéma supplémentaire lorsqu’une propriété donnée est présente. Les mots-clés if, then et else permettent de choisir les règles selon une condition.

Pour concevoir le contrat, partez des décisions attendues dans le document. Dans une hypothèse de rapport comparatif, la présence d’une comparaison pourrait rendre obligatoires les périodes comparées et leur périmètre respectif. Pour une donnée déclarée disponible, le contrat pourrait exiger une valeur et sa référence. Pour une donnée déclarée indisponible, il pourrait exiger un motif et le responsable du complément.

Écrivez ces règles en langage métier avant leur traduction technique. Une clause utile indique le déclencheur, les champs exigés et la réponse en cas d’échec. Elle permet au producteur de comprendre précisément ce qu’il doit remettre pour que le contrôle puisse aboutir.

Le champ qui sélectionne les règles doit lui-même être obligatoire. Testez également son absence : un document dont le type manque doit recevoir un motif exploitable. Cette précaution évite de laisser la rédaction choisir implicitement les exigences qui lui seraient applicables. Les critères d’acceptation restent ainsi lisibles pour l’équipe métier comme pour l’équipe de développement.

4. Quelles règles dépassent la structure du fichier ?

Les contrôles métier doivent vérifier les relations entre les valeurs et leur adéquation au mandat. Un fichier bien structuré peut encore réunir des informations incompatibles avec la comparaison demandée.

Dans sa documentation Validators, sans date de publication indiquée, Pydantic permet des validations personnalisées sur un champ ou sur l’ensemble des données du modèle. Il permet aussi de transmettre un contexte aux méthodes de validation. Ces capacités constituent des options d’implémentation ; leur présentation ici ne les attribue pas au système décrit par les chercheurs.

Pour le contrat proposé, le contexte devrait contenir le périmètre approuvé, les périodes admises et les références utilisables. Il est utile de l’identifier séparément du bloc reçu : le producteur des données ne devrait pas pouvoir modifier les règles de contrôle en remettant ses valeurs. Le responsable métier approuve ce contexte, dont la version accompagne la décision de validation.

Définissez ensuite des règles nommées. Une comparaison exige des périodes compatibles selon la convention choisie. Une référence associée à une valeur doit appartenir aux sources admises. Un état « disponible » accompagné d’une valeur vide appelle une correction. Chaque échec désigne le champ concerné, la règle violée et le responsable du traitement.

La même documentation précise que les valeurs par défaut ne sont validées que si la configuration le prévoit. Examinez donc leur usage : remplacer automatiquement une absence par une valeur par défaut pourrait contourner l’arbitrage prévu. Dans cette proposition, chaque transformation autorisée doit être déclarée et conservée avec la valeur reçue. La décision d’acceptation atteste uniquement les contrôles effectivement réalisés.

5. Que faire d’un bloc incomplet ou incompatible ?

La réponse au producteur doit distinguer l’impossibilité de traiter le bloc, le besoin de compléter les données et l’autorisation de poursuivre dans un périmètre défini.

L’annexe A de Gibert, Despujols et Rochet, datée du 30 septembre 2026, prévoit de corriger un échec à son étape d’origine. Dans le système décrit au corps du texte, les informations détenues par la banque mais indisponibles pour le système sont représentées par des manques nommés. Le protocole de réponse ci-dessous transpose ces principes en proposition de contrat de remise.

• Rejeté : la version est inconnue, le bloc est illisible ou une règle interdit son traitement. Le producteur reçoit le motif et, si la version est en cause, la version attendue ; la rédaction reste suspendue.
• À compléter : le bloc peut être interprété, mais une exigence nécessaire au livrable reste insatisfaite. La réponse désigne les champs à reprendre, leur producteur et la condition permettant une nouvelle validation.
• Accepté avec limites explicites : les exigences applicables sont satisfaites et les manques résiduels sont autorisés par le responsable métier. La réponse délimite les sections réalisables et les informations à signaler comme indisponibles. Un bloc complet peut recevoir ce statut avec une liste de limites vide.

Chaque réponse devrait reprendre l’identifiant de remise, la version du contrat, le statut, les règles en échec et les limites autorisées. Associez à chaque règle en échec un code stable, le champ concerné et la correction attendue. Le producteur doit pouvoir corriger le bloc sans interpréter un commentaire libre du rédacteur.

Conservez ensemble le bloc reçu et la décision. Lorsqu’un complément arrive, soumettez la nouvelle remise aux contrôles concernés avant de reprendre la rédaction. Le rédacteur utilise les limites acceptées dans le document ; toute donnée supplémentaire suit le circuit de collecte et de validation. Une acceptation de structure ne certifie pas la vérité des entrées.

6. Comment faire évoluer le contrat ?

Toute évolution doit préciser quels producteurs et quels composants de rédaction peuvent encore utiliser le contrat. La politique qui suit est une recommandation d’architecture du cabinet.

Attribuez un identifiant de version à la spécification et inscrivez-le dans chaque remise. Le dossier de version devrait réunir la définition des champs, les règles conditionnelles, les contrôles métier et les réponses d’erreur. Les équipes qui produisent et consomment les données disposent ainsi de la même référence pour préparer une modification.

Pour chaque changement, examinez les remises déjà possibles : ajout d’un champ obligatoire, changement de type, nouvel état de disponibilité ou modification du sens d’une valeur. Un renommage doit être traité explicitement, car le composant de rédaction doit savoir quel champ lire. La documentation Object de JSON Schema, sans date indiquée, rappelle notamment qu’additionalProperties ne reconnaît que les propriétés déclarées dans le même sous-schéma. Cette portée doit être prise en compte lors d’une extension.

Prévoyez une migration documentée lorsqu’une remise doit changer de version. Elle indique les champs déplacés, les transformations autorisées et les informations à redemander au producteur. Conservez la remise d’origine, sa version et la trace de migration, puis contrôlez le résultat selon la version cible.

La procédure de remise peut alors être approuvée sur des critères vérifiables : identification du contrat, dépôt du bloc, contrôle de structure, validation métier, décision adressée au producteur et ouverture de la rédaction. En cas de changement, rejouez les situations de refus et d’acceptation prévues dans la spécification. Le livrable attendu est ce protocole partagé, accompagné de ses règles et de ses responsabilités.

FAQ

À quoi sert le contrat de données ?
Il fixe les informations que la rédaction peut recevoir et les conditions de leur acceptation. Il donne aussi au producteur les motifs d’un refus et les corrections attendues. Dans la méthode proposée, le responsable métier arbitre les limites admissibles avant que le document soit rédigé.

Un champ nul équivaut-il à un champ absent ?
JSON Schema distingue une propriété absente d’une propriété présente portant la valeur null, comme l’indique sa documentation Object citée plus haut. Le contrat doit préciser leur sens métier et leur admissibilité. Un état de disponibilité explicite aide à transmettre cette décision à la rédaction.

Peut-on tolérer des champs supplémentaires ?
Oui, à condition de définir cette tolérance dans le schéma et dans les règles d’utilisation. JSON Schema permet d’autoriser, de contraindre ou de refuser ces propriétés. Pour le contrat proposé, l’équipe responsable doit préciser quels composants les comprennent et ce qui se passe lorsqu’ils sont inconnus.

Un schéma contrôle-t-il la cohérence métier ?
Les règles structurelles doivent être complétées par les contrôles nécessaires au mandat. Pydantic permet des validateurs personnalisés et la transmission d’un contexte, selon sa documentation citée dans le guide. L’équipe métier doit définir les règles à appliquer et approuver le contexte utilisé pour la remise.

Qui complète une donnée manquante ?
Dans l’organisation proposée, le producteur désigné reprend la collecte puis soumet une nouvelle remise. Le responsable métier décide si un manque résiduel peut être accepté et dans quel périmètre. Le rédacteur conserve cette limite dans le document, sans déduire silencieusement une valeur de remplacement.

Pour aller plus loin

• Collecter les données d’un document en deux passes : couvrir les champs puis résoudre les manques.
• Donnée manquante : apprendre à l’agent à signaler le manque dans le document.
• Registre de faits : concevoir la source de référence d’un document produit par agent.

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.
• JSON Schema, Object, sans date de publication indiquée, consulté le 9 octobre 2026.
• JSON Schema, Array, sans date de publication indiquée, consulté le 9 octobre 2026.
• JSON Schema, Conditional schema validation, sans date de publication indiquée, consulté le 9 octobre 2026.
• Pydantic, Validators, sans date de publication indiquée, consulté le 9 octobre 2026.