atelier d'auteur · bruxelles · mmxxvi
Dt fig. I no. 01 - intitulé de département bruxelles · mmxxvi

Département des Harnais

atelier d'auteur · harnais d'agents ia
section des harnais · texte-comme-image
l'atelier · essai t0 section des essais 2026-05-20

Un harness, ses sections

Contraindre le modèle, ou ne pas être un harness. Où vit l'agentivité opérationnelle dans un système d'agents qui travaille — et ce que le mot harness redevient quand on l'admet.

Un agent IA est un Large Language Model auquel on donne des outils, une boucle, et l'autonomie de décider quels outils appeler, dans quel ordre, et quand s'arrêter. Ce qui le distingue d'un simple workflow est précisément que le modèle dirige lui-même son propre processus, plutôt que de suivre un chemin de code prédéfini.

Du vieux français harnois attesté autour de 1300, emprunté à l'ancien scandinave hernest « provisions pour l'armée », le harnais désigne l'équipement du soldat ou le réseau de sangles qui route la force du cheval. Dans les deux cas : une structure de contrainte qui convertit une force brute en travail dirigé.

Le harness, dans ce cadre, est l'enveloppe qui donne au modèle ce qu'il faut pour agir — « the system that turns a model into something that can take actions », écrit MindStudio ; « an agent harness wraps around a model to manage long-running tasks », écrit Aakash Gupta ; « Think of the model as an engine. The harness is the car », écrit-il encore dans la même note. Anthropic, dans une publication d'ingénierie de novembre 2025 (Effective Harnesses for Long-Running Agents), parle du Claude Agent SDK comme d'« a powerful, general-purpose agent harness ».

L'inversion : où vit la décision

Dans les systèmes d'agents qui travaillent en production, et je dis bien qui travaillent, pas qui démontrent, ce qui décide quoi faire ensuite n'est presque jamais le modèle. C'est du code, une fonction qui regarde une entrée, vérifie des conditions, et tranche.

Le modèle, dans ces systèmes, fait une chose tout aussi essentielle : il infère. Il lit un texte ambigu, il en extrait un sens, il propose une formulation, il évalue une qualité, il reformule... C'est un classifieur sophistiqué, parfois un rédacteur, parfois un évaluateur. Mais la décision opérationnelle d'appeler tel outil avec tels arguments à tel moment, est prise par du code procédural qui consomme la sortie du modèle. Et quand le harnais évalue ce que le modèle a produit, le verdict — "recevable", "à reprendre", "bloqué" — ne sort pas du modèle non plus : il sort de tests déterministes qui parsent sa sortie. Le modèle fournit la matière ; le test rend le verdict.

L'autonomie attribuée au modèle est donc, dans les systèmes qui travaillent, une métaphore. Le système tourne parce que du code a décidé ce qu'il devait faire de la sortie du modèle. C'est ici que le mot harnais reprend tout son sens. Si l'agentivité opérationnelle vit dans le code, alors le harness, au sens premier, est exactement ce dispositif de code : ce qui tient le modèle dans son rôle de lecteur, et qui route sa sortie vers un travail dirigé.

Cette intuition n'est pas neuve. Léon Bottou, dès 2011 (From Machine Learning to Machine Reasoning), anticipait que la composition algébrique des modules produit du raisonnement que les modules seuls n'ont pas. Très récemment, elle a cristallisé comme discipline sous le nom de harness engineering — Mitchell Hashimoto, dans My AI Adoption Journey (5 février 2026), pose le terme. Ryan Lopopolo, six jours plus tard, le reprend dans un texte d'OpenAI (Harness Engineering, 11 février). Birgitta Böckeler en propose une grille analytique (Harness engineering for coding agent users), le 2 avril 2026, en deux dimensions : guides qui orientent l'agent avant qu'il agisse et sensors qui mesurent ce qu'il a produit, chacun pouvant être computationnel — dont les résultats, écrit-elle, sont « reliable » — ou inférentiel — qui reste « more non-deterministic ». La grille est utile et sa diffusion rapide dans l'industrie en témoigne. Mais elle reste descriptive : elle dit ce qu'un harnais contient, sans trancher où l'agentivité opérationnelle doit vivre.

La position adjacente, le code décide, le modèle infère, a, en parallèle, été tenue publiquement par plusieurs équipes. Nathan Sportsman, chez Praetorian, pose, le même jour que Mitchell Hashimoto, la formule : « We transform the LLM from a "creative assistant" into a deterministic component of the software supply chain. » Microsoft, avec son framework Conductor publié le 14 mai 2026, prend la même direction : le routage entre agents y est défini en YAML et reste déterministe, « the orchestration layer consumes zero tokens ». Bhattarai et Vu, dans un papier arXiv de février 2026 (Trustworthy Agentic AI Requires Deterministic Architectural Boundaries), articulent une thèse adjacente : la fiabilité d'un système agentique ne procède pas de l'entraînement à la sûreté des modèles mais de l'enforcement architectural des limites. Cao et al., dans le papier ESAA (février 2026), formalisent l'idée dans des termes presque identiques : « strict separation between the Cognitive Blueprint… and the Runtime Engine. ». Et en amont, l'article The Plausibility Trap (janvier 2026) propose une Deterministic-Probabilistic Decision Matrix pour décider, à chaque embranchement, quand convoquer un modèle et quand ne pas le faire.

Ma position est tranchée : elle pose qu'un sensor qui rend un verdict doit être computationnel par défaut, parce que la décision opérationnelle n'admet pas d'être probabiliste sans renoncer à l'audit.

L'agentivité ne vit pas dans le modèle. Elle vit dans le code qui l'orchestre. Et l'admettre explicitement — la déplacer là où elle vit déjà de fait — n'est pas un compromis pragmatique sur un idéal d'autonomie. C'est récupérer le sens du mot qu'on emploie.

Pourquoi ce déplacement n'est pas verbal

On pourrait dire : bon, d'accord, c'est une question de mots. Que ce soit le code ou le modèle qui décide, le résultat est le même. Il ne l'est pas, et c'est ce point qui vaut la peine d'être établi, parce qu'il fait la différence entre une querelle de vocabulaire et une décision d'architecture.

Considérons une question concrète : peut-on auditer la décision qui vient d'être prise ?

Si la décision a été prise par un LLM, on peut rejouer le prompt, on peut examiner la sortie, on peut éventuellement obtenir des log-probs, mais on ne peut pas répondre proprement à la question pourquoi. Le modèle a généré des tokens parce que ce sont les tokens probables étant donné le prompt et son état interne. Il n'y a pas, en deçà, de raisonnement formalisable qu'on puisse extraire et opposer à un audit. On ne peut pas auditer une probabilité. Le modèle suppose. Il suppose bien, souvent, mais il suppose.

Si la décision a été prise par du code, alors l'audit consiste à lire ce code. Il y a un fichier, il y a une ligne, il y a une logique, il y a un test unitaire. La décision a une provenance qu'on peut nommer.

Ce n'est pas une différence de degré. C'est une différence de nature épistémique de la décision. Et cette différence, en 2026, n'est plus seulement esthétique : l'EU AI Act, bien que reporté pour partie, et pour partie seulement, et son article 11, couplé à l'annexe IV, exige un dossier technique de conformité qui décrit le système. Son article 12 demande un logging intégré au design, c'est-à-dire un logging dont la structure découle de l'architecture, pas un logging bolt-on qu'on ajoute après coup. Un système dans lequel les décisions opérationnelles vivent dans du code peut produire ce dossier en lisant son propre code. Un système dans lequel elles vivent dans le modèle ne le peut pas, sauf à enregistrer ses appels et à prier pour que l'enregistrement explique quoi que ce soit, ce qui ne marchera pas devant un régulateur informé.

Le harnais — et ce qu'il devient quand on l'admet

Si l'agentivité vit dans le code, le mot harness récupère son sens premier, et on appelle ce dispositif une architecture.

Concrètement, dans le harnais que je décris, quelques règles doivent se tenir d'elles-mêmes. Avant tout appel au modèle, tenter un routage déterministe. La règle, en première ligne du guide du contributeur : try_script() avant tout LLM. Cela empêche qu'une décision triviale emprunte un chemin probabiliste là où un chemin certain suffisait. Des collecteurs de contexte tournent en parallèle, déterministes, avant tout jeton d'inférence ; le modèle ne décide pas quel contexte est pertinent, il le reçoit. Le verdict d'un validateur ne sort pas du modèle mais des tests qui consomment sa sortie. APPROVE, REVISE, BLOCKED, STALL, ABSTAIN sont les valeurs produites par du code déterministe. Les permissions sont stratifiées : READ_ONLY, WRITE_SAFE, WRITE_DANGEROUS, IRREVERSIBLE. Et le seuil de confiance pour la dernière est posé à 1.0, c'est-à-dire à l'approbation humaine explicite. Une action sans retour ne se déclenche pas depuis un raisonnement. Les écritures d'état passent par un temp + rename : on écrit dans un fichier temporaire, on renomme atomiquement. Une coupure ne laisse plus un état partiel sur le disque ; un crash redevient un crash, et non une corruption.

Aucune de ces décisions n'est exotique. Toutes existent dans des systèmes industriels classiques, de longue date. Ce qui est nouveau, et qui mérite à mon sens d'être articulé comme position, c'est de les appliquer à un système d'agents en assumant qu'elles ne sont pas des contraintes posées sur l'autonomie d'un modèle, mais l'architecture de l'agentivité elle-même — c'est-à-dire, au pied de la lettre, ce que fait un harnais.

Je ne décris pas un système terminé, avec des règles posées d'un coup, a priori, comme une étoile sur tableau blanc. Le harnais, comme l'a noté Hashimoto, croît par accrétion : il décrit ce que le système a appris à ne plus faire, et pourquoi. Pour l'audit, c'est une propriété, et pas un sous-produit : la justification de chaque contrainte est, par construction, datable et opposable.

L'objection inverse, et son renversement

L'objection adverse est connue, elle se présente à peu près ainsi. Si vous mettez toute l'intelligence dans le code, vous perdez ce qui rend les LLM intéressants. Vous reconstruisez un système des années quatre-vingt, simplement avec des LLM en sous-routine.

C'est une objection sérieuse mais je crois qu'elle se trompe d'un cran. Les possibilités du modèle ne sont pas perdues, mais utilisées dans un système où le code décide. Le modèle est convoqué partout où il y a une décision qui exige de la lecture, extraction de sens, classification d'intention, reformulation, synthèse, évaluation qualitative. Ce sont des tâches difficiles, parfois irréductiblement difficiles, et le modèle les fait mieux que tout ce qu'on savait faire avant. Mais ces tâches ne sont pas la décision opérationnelle. Elles en sont la matière première. La stratification des permissions n'est pas une précaution accessoire ; elle est ce qui transforme cette rigidité en vertu. Un cas non prévu ne déclenche pas une action improvisée ; il déclenche un STALL, une ABSTAIN ou une escalade. Le système, devant l'inconnu, refuse au lieu de broder.

Une seconde objection circule, plus récente, et il vaut la peine d'y répondre brièvement. L'équipe de Ryan Lopopolo, chez OpenAI, a montré en février 2026 qu'un produit d'un million de lignes de code pouvait être bâti en cinq mois par trois ingénieurs, sans une ligne écrite à la main, dans un harnais qui repose massivement sur des guides et sensors inférentiels. Conclusion possible : le déterministe n'est pas nécessaire à l'échelle. Mais l'expérience Codex est, par construction, un travail interactif, avec humain dans la boucle à chaque pull request. C'est précisément le cas où l'agentivité peut, légitimement, glisser vers le modèle, parce qu'un humain en aval rend le verdict opérationnel. Ce n'est pas le cas long-running autonome dans lequel un système doit, sans supervision continue, écrire dans un état partagé, déclencher une action irréversible, ou rendre compte d'une décision à un régulateur. Ce sont deux régimes, et ce que je défends ici concerne le second.

L'erreur de la position adverse — dans les deux variantes — est de confondre capacité d'interprétation et capacité de décision. Un modèle qui lit bien un courriel n'a aucun titre, par cette compétence, à décider de le classer dans tel dossier, de vous convoquer à telle heure, ou d'envoyer telle réponse. Ce sont des décisions différentes, qui exigent une connaissance du système, de ses contraintes et de vos préférences, que le modèle n'a pas. Quelqu'un, du code en l'occurrence, doit articuler explicitement ces préférences et brancher la sortie du modèle dessus. Et il se trouve que ce quelqu'un, dans tous les systèmes qui marchent sans humain à chaque pas, est du code. La question n'est pas si on l'écrit ou non ; c'est si on l'écrit explicitement ou si on prétend qu'il n'existe pas.

Ce sont des décisions de goût

Construire un harnais comme celui que je décris exige, à chaque embranchement, des décisions qui ne sont pas réductibles à des optima techniques. Faut-il que l'enum Verdict ait cinq valeurs ou six ? Faut-il que le seuil de confiance pour les actions irréversibles soit 1.0 ou 0.95 ? Faut-il que l'écriture du journal soit synchrone ou différée ? Etc, etc. On peut argumenter chacune de ces questions, et on doit le faire, mais aucune ne tranche définitivement. Il y a, à la fin, une décision de goût, une cohérence de style architectural, qui détermine ce que le système est et ce qu'il n'est pas.

Ces décisions de goût ne peuvent pas être déléguées à un modèle. Elles peuvent être discutées avec un modèle ou mises à l'épreuve par un modèle, mais elles appartiennent à un humain qui tient un système dans le temps et qui répond, en première personne, des conséquences de ces choix. C'est exactement pour cela, je crois, que la métaphore de l'agent autonome est attrayante : elle promet de retirer cette charge. Elle ne la retire pas, parce qu'on ne la peut pas retirer, elle la cache. La position que je défends consiste, au minimum, à ne pas cacher cette charge, à la nommer, à la documenter et à la rendre auditable.

— Depuis Bruxelles, ville qui rédige l'AI Act, et qui depuis le XX° siècle, a fait de la forme administrative un outil critique. —

Sources

— John Linotte · Département des Harnais · Bruxelles · 2026-05-20