Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 31 octobre 2026.
En bref
Le harnais agentique est le logiciel qui organise le travail de l’IA et les contrôles nécessaires pour fabriquer un document. Pour une direction, le décrire permet d’attribuer la responsabilité de chaque étape et de décider qui autorise la remise du livrable. La prépublication de Gibert, Despujols et Rochet, déposée sur arXiv le 30 septembre 2026, décrit cette séparation autour d’un registre de faits. Ce registre rassemble les valeurs et leur origine avant leur utilisation dans le texte. Le tableau proposé ici aide à examiner la répartition du travail entre les logiciels et les équipes. Elle distingue les contrôles logiciels de l’approbation du relecteur métier.
1. Que désigne le harnais dans une chaîne documentaire ?
Le harnais désigne l’application qui fait circuler les informations entre les composants chargés de fabriquer et de vérifier le document. Son périmètre commence aux entrées qu’elle accepte et se termine aux fichiers qu’elle remet, avec leur statut de validation.
Dans la prépublication de Gibert, Despujols et Rochet, déposée sur arXiv le 30 septembre 2026, le système reçoit des données collectées et un mandat. Un moteur déterministe, c’est-à-dire un programme exécutant des règles définies, construit le registre des faits. Des règles de composition déterminent le plan des pages. Le modèle formule une recommandation sous les contraintes des entrées ; la production du texte combine ensuite des formulations assemblées par le programme et des interventions conditionnelles du modèle. La mise en forme et le rendu produisent une présentation et un classeur de contrôles.
Cette description invite à séparer les fonctions dans la revue d’architecture. Le modèle reçoit une tâche et produit une réponse. Le harnais prépare cette tâche, choisit la suite du traitement et conserve les résultats utiles. La documentation Workflows and agents de LangChain, sans date de publication indiquée, distingue les chemins prédéfinis dans le code des agents qui définissent dynamiquement leur processus et leurs outils.
Pour tracer le périmètre, nous recommandons de nommer chaque composant, son entrée et le destinataire de sa sortie. La collecte et la relecture doivent apparaître aux frontières, même lorsqu’elles relèvent d’autres applications ou équipes. Cette carte rend explicite ce que l’équipe qui exploite le harnais prend en charge.
2. Quelles décisions peuvent rester dans le code ?
Les opérations dont la règle est définie peuvent être confiées au programme ; les décisions d’interprétation appellent un rôle distinct, attribué au modèle ou au métier. La matrice suivante constitue une proposition de conception du cabinet, inspirée de la séparation décrite dans la prépublication.
| Opération | Exécutant proposé | Entrée attendue | Sortie et responsabilité |
|---|---|---|---|
| Calculer une valeur | Moteur de calcul | Données admissibles et formule | Valeur reliée à ses entrées ; règle maintenue par l’équipe data |
| Retrouver un fait | Service du registre | Identifiant et version attendue | Fait ou erreur explicite ; interface maintenue par l’équipe applicative |
| Choisir un gabarit | Règle de routage | Type de document accepté | Gabarit identifié ; choix validé par le métier |
| Formuler une recommandation | Modèle dans un rôle délimité | Mandat, faits et contraintes | Proposition soumise au responsable métier |
| Fabriquer le fichier | Moteur de rendu | Brouillon structuré validé | Fichier et rapport de contrôles ; production suivie par l’exploitation |
La distinction dépend de la règle disponible. Une sélection de gabarit peut rester dans le code lorsque le type de document suffit à la déterminer. Si elle exige d’interpréter une demande ambiguë, prévoyez une étape de qualification avant la sélection. La carte doit alors montrer qui tranche cette ambiguïté et quelle décision est transmise au composant suivant.
Dans sa documentation Workflows and agents, sans date de publication indiquée, LangChain décrit l’enchaînement des appels comme un traitement où chaque appel au modèle utilise la sortie du précédent. Son exemple de chaîne comprend aussi une fonction de contrôle et des transitions conditionnelles. Pour une chaîne documentaire, il est utile de préciser quelles conditions relèvent d’une règle vérifiable et quelles appréciations doivent être remontées au relecteur.
Le choix du responsable doit porter sur la règle autant que sur son exécution. Le métier approuve le sens d’une formule ou les conditions d’emploi d’un gabarit ; l’équipe technique implémente le traitement et expose ses erreurs. Le nom du composant suffit rarement à établir cette répartition.
3. Quelles interfaces relient les composants ?
Chaque interface doit préciser ce que l’étape reçoit, ce qu’elle produit et les conditions de refus de cet échange. Un contrat de données désigne ici cette description exploitable par le programme.
La documentation Object de JSON Schema, sans date de publication indiquée, fournit des mécanismes pour exprimer une partie de ce contrat. Le mot-clé properties décrit les propriétés ; required impose la présence de celles qui y sont listées. Par défaut, les propriétés décrites restent facultatives et les propriétés supplémentaires sont autorisées. Le réglage additionalProperties permet de contrôler ces ajouts. Les noms de propriétés peuvent eux-mêmes suivre une règle avec propertyNames.
Pour la fabrication documentaire, la grille suivante est une proposition de conception. Les champs retenus doivent être adaptés au document et approuvés par ses responsables.
| Passage | Contenu obligatoire proposé | Version à transporter | Erreur à traiter |
|---|---|---|---|
| Mandat vers préparation | Objet, destinataire, périmètre autorisé | Mandat et contrat d’entrée | Périmètre absent ou incompatible |
| Registre vers composition | Faits, unités, périodes et origine | Registre utilisé | Fait introuvable ou incomplet |
| Plan vers rédaction | Sections attendues et références utiles | Plan et registre associé | Référence inconnue |
| Brouillon vers rendu | Blocs de contenu et gabarit retenu | Brouillon et gabarit | Structure non conforme |
| Fichier vers relecture | Fichier produit et résultats des contrôles | Fichier effectivement contrôlé | Contrôle bloquant ou sortie manquante |
Ce contrat doit aussi décrire la réponse à une erreur : arrêt, retour à l’étape productrice ou demande d’arbitrage. Par exemple, dans cette méthode, une référence inconnue entraîne un retour vers la composition du plan. L’erreur conserve l’identifiant concerné pour que son responsable sache quoi corriger.
La conformité structurelle et la vérification du contenu appellent des contrôles distincts. Exiger un champ de provenance permet d’en vérifier la présence ; le rapprochement avec la source doit rester une responsabilité explicite de la chaîne.
4. Où se trouve l’état de la fabrication ?
L’état de fabrication doit être conservé dans des données explicites que chaque étape peut lire et mettre à jour selon des règles connues. Pour la revue proposée ici, il comprend les références des entrées, les versions produites et le statut des contrôles.
L’annexe consacrée à la chaîne de traitement d’origine dans la prépublication de Gibert, Despujols et Rochet, déposée sur arXiv le 30 septembre 2026 décrit des sessions de modèle séparées, des fichiers d’entrée spécifiés et des sorties versionnées. Elle constitue un antécédent du système hybride présenté dans le corps du texte. Cette architecture antérieure fournit un appui pour réfléchir aux échanges entre étapes.
Dans la documentation Workflows and agents de LangChain, sans date de publication indiquée, l’exemple d’enchaînement utilise un état contenant les sorties successives. Pour le schéma avec un orchestrateur et des exécutants, chaque exécutant possède son propre état et écrit ses résultats dans une clé partagée accessible à l’orchestrateur. La méthode proposée reprend ce vocabulaire pour décrire les informations échangées entre composants.
Dans notre proposition, chaque étape enregistre précisément la version qu’elle consomme et celle qu’elle produit. Conservez à côté la configuration du traitement et la décision de poursuivre. Lorsqu’un fait change, les références permettent de retrouver le brouillon qui l’a utilisé et le fichier issu de ce brouillon.
Définissez aussi qui peut modifier l’état. Une correction apportée à l’entrée doit conduire à identifier les sorties à refaire. Le statut « validé » doit rester attaché au fichier contrôlé ; il faut décider explicitement de son devenir lorsqu’une étape le remplace. Cette discipline donne au relecteur un document dont le parcours de fabrication est consultable.
5. Qui autorise le passage à l’étape suivante ?
Le programme autorise une transition lorsque ses conditions sont satisfaites ; le responsable métier autorise l’usage du livrable dans son contexte. La carte des responsabilités doit représenter séparément ces décisions.
La prépublication de Gibert, Despujols et Rochet, déposée sur arXiv le 30 septembre 2026 situe un contrôle des valeurs numériques après génération. Après rendu, les vérifications portent notamment sur la cohérence du registre, les contradictions du récit et les défauts de mise en page. Elles déterminent si les fichiers passent la validation. La boucle de revue par le superviseur et le professionnel métier reste hors du périmètre évalué.
Pour transposer cette séparation, associez à chaque transition une condition formulable : une référence existe, un résultat respecte le contrat, le fichier attendu a été produit. Indiquez le composant qui exécute le contrôle et le responsable qui maintient sa règle. Un résultat doit préciser la version vérifiée et l’étape vers laquelle renvoyer le travail en cas de défaut.
L’approbation métier demande sa propre trace, liée au même fichier. Elle peut porter sur la pertinence de la recommandation, son périmètre d’emploi et les réserves à conserver. Une validation logicielle donne au relecteur des éléments contrôlés sur lesquels travailler. Dans cette méthode, le dossier de remise rassemble le fichier, ses références de fabrication et les décisions de contrôle ; le relecteur y ajoute sa décision d’usage.
6. Comment relire une architecture annoncée comme agentique ?
Relire cette architecture consiste à suivre le document depuis son mandat jusqu’à sa remise, en attribuant un propriétaire à chaque passage. TW3 recommande de parcourir la matrice avec les responsables métier, data et applicatifs avant de choisir les outils.
Pour chaque ligne, posez les questions suivantes :
- Quelle entrée exacte déclenche le traitement, et qui en répond ?
- Quelle règle ou quel jugement produit la sortie ?
- Quelle version permet de retrouver les faits utilisés ?
- Qui traite un refus, et à quelle étape reprend-on ?
- Qui autorise la remise du fichier au destinataire ?
Examinez ensuite les dépendances implicites. Une étape qui suppose un gabarit disponible doit en recevoir la référence. Une relecture qui s’appuie sur un registre doit pouvoir retrouver celui qui a servi à la rédaction. Dans la carte proposée, chaque dépendance devient une entrée nommée, accompagnée de sa condition d’acceptation.
Terminez la revue par les chemins d’échec. Le responsable de la correction doit recevoir assez d’informations pour reprendre le travail à son origine. La décision attendue est une répartition acceptée des responsabilités : quelles opérations sont prises en charge par le programme, quels jugements sont confiés au modèle et quelles validations restent au métier. La description publique sert d’ancrage à cette démarche ; elle ne mesure pas l’effet isolé de chacun des composants.
FAQ
Un harnais est-il un modèle ?
Le harnais est l’application qui prépare les entrées, organise les traitements et exploite les réponses du modèle. Son périmètre comprend aussi les échanges avec les composants de calcul, de rendu et de contrôle. Décrire ce périmètre permet d’attribuer la maintenance de chaque responsabilité.
Faut-il plusieurs modèles ?
Dans la méthode proposée, on peut envisager un même modèle appelé pour des tâches distinctes. Ce choix reste à examiner pour chaque tâche. En revue d’architecture, il est utile de documenter les entrées et les droits de chaque rôle indépendamment du choix du modèle.
Un prompt suffit-il à définir un contrat ?
Une consigne écrite doit être accompagnée de règles que le programme sait vérifier. La documentation Object de JSON Schema, sans date de publication indiquée, permet notamment d’exprimer les propriétés exigées et les règles de validation de leurs valeurs. Dans la méthode proposée, le contrat précise aussi le destinataire de l’erreur et la condition de reprise.
Le moteur doit-il rédiger toutes les phrases ?
Le système décrit par Gibert, Despujols et Rochet dans leur prépublication déposée sur arXiv le 30 septembre 2026 combine des formulations compilées depuis les faits, des gabarits de prose et des interventions conditionnelles du modèle. Certaines pages peuvent éviter l’appel de rédaction. La répartition retenue doit apparaître dans la carte, afin que chaque transformation du contenu ait un responsable.
Jusqu’où portent les contrôles du harnais ?
Ils portent sur les propriétés pour lesquelles une vérification est définie et exécutée. La prépublication de Gibert, Despujols et Rochet, déposée sur arXiv le 30 septembre 2026, situe la revue professionnelle hors du périmètre évalué. La remise doit donc identifier le fichier contrôlé et la décision du relecteur.
Pour aller plus loin
- Workflow fixe ou agent autonome : comment organiser la fabrication d’un document ?
- Contrat de données d’un agent : fixer ce que la rédaction reçoit et peut utiliser
- Contrôles bloquants : organiser les portes de validation d’une chaîne documentaire
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.
- LangChain, Workflows and agents, sans date de publication indiquée, consulté le 9 octobre 2026.
- JSON Schema, Object, sans date de publication indiquée, consulté le 9 octobre 2026.