Le prompt n'est pas une couche d'application pour les agents d'entreprise

De quoi s’agit-il ?

Le 9 juillet 2026, un preprint intitulé “From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents” a été publié sur arXiv (2607.08028). Il pose une question qui sous-tend la plupart des déploiements d’agents en entreprise : lorsqu’une application LLM démarre comme un prototype piloté par prompt, puis doit passer en production avec de vraies exigences — frontières de sources, routage d’entités, contrats de réponse, traces reproductibles — lesquelles de ces garanties peut-on réellement faire respecter en les écrivant dans le prompt, et lesquelles doivent être appliquées par du code autour du modèle ?

La réponse de l’article est sans détour. Les garanties qui ne vivent que dans les instructions du prompt fuient : les violations atteignent le lecteur. Les mêmes garanties, déplacées dans une couche d’application codée autour du modèle, tiennent. C’est un constat d’architecture, pas un exploit — mais il a des conséquences de sécurité directes pour toute équipe qui compte sur les prompts système pour garder un agent dans les clous.

Comment ça marche

Les auteurs décrivent un harnais : le comportement déterministe est extrait du prompt et déplacé dans du code — manifestes, schémas et artefacts de validation — organisé autour d’une frontière de composition, le point remplaçable où le LLM compose réellement une réponse. Les affirmations adossées à des sources restent l’autorité pour les réponses à l’exécution, mais les règles sur la façon dont une réponse peut être formée (ancrage, routage, formatage, langage autorisé) deviennent des contrats vérifiables par machine plutôt que de simples demandes polies dans un prompt.

Ils instancient cette approche sur une tranche de données publiques de cinq groupes (25 sociétés cotées) et testent cinq contrats : ancrage aux sources, routage d’entités, trace, hygiène de sortie et langage de recommandation. Un contrôle par injection de fautes casse délibérément chaque contrat pour confirmer que les validateurs se déclenchent bien, au lieu de tout laisser passer par défaut.

L’expérience centrale fixe le modèle et fait varier uniquement la couche d’application :

Couche d'application      Contrat fuite-de-trace / langage-de-recommandation
------------------------  ------------------------------------------------
Instructions de prompt    Les violations atteignent le lecteur
seules
Garde-fou externe ajouté  Bloque les violations, mais sur-refuse (utilité 88/120)
Harnais codé              Bloque les violations, utilité complète (120/120)

Aucun payload d’attaque n’est nécessaire pour établir le point, et aucun n’est reproduit ici. Le constat porte sur l’endroit où vit un contrôle, pas sur une chaîne astucieuse.

Pourquoi c’est important

Deux chiffres portent l’article. D’abord, à modèle fixe, les seules instructions du prompt laissent les violations de langage de recommandation et de fuite de trace interne atteindre le lecteur, tandis que le harnais codé les bloque entièrement. Pour un agent d’entreprise, une fuite de trace interne peut exposer un raisonnement, un contexte récupéré ou des détails système qu’un utilisateur n’aurait jamais dû voir, et un phrasé de « recommandation » interdit peut constituer un véritable problème de conformité en environnement réglementé. Aucun des deux ne se corrige en ajoutant du texte au prompt.

Ensuite, les contrats ont tenu lors de la substitution de modèle : sur trois modèles hébergés, les vérifications du harnais ont réussi sur les 270 exécutions à la frontière de composition, et lorsque le côté composé par le modèle échouait, les échecs étaient détectés et consignés plutôt que livrés silencieusement. Cette robustesse compte, car les équipes changent constamment de modèle de base, et une garantie qui dépend en douce du comportement d’un modèle n’est pas une garantie.

Le résultat de sur-refus est le contrepoids honnête. Un garde-fou externe ajouté a lui aussi bloqué les violations, mais il a fait tomber l’utilité à 88/120 là où le harnais conservait les 120/120 complets — la taxe familière d’un filtre trop large qui refuse trop. Seule une application codée et ciblée a préservé à la fois la sûreté et l’utilité.

Cela rejoint une leçon que le secteur réapprend sans cesse. L’équipe sécurité de Microsoft, écrivant en mai 2026, l’a dit clairement : un LLM n’est pas une frontière de sécurité, et tout paramètre d’outil que le modèle peut influencer doit être traité comme une entrée contrôlée par l’attaquant. La littérature sur les patrons de conception pour sécuriser les agents contre l’injection de prompt tient le même raisonnement structurel : placer des contrôles déterministes autour du modèle, ne pas demander au modèle de se surveiller lui-même.

Défenses

Points concrets pour les équipes qui déploient des agents LLM en entreprise :

1. Traitez les prompts comme un façonnage de comportement, pas comme une application. Toute garantie qui doit tenir — ancrage aux sources, absence de fuite de trace interne, format de sortie, langage autorisé — appartient au code : schémas et validateurs à la frontière de composition, pas des phrases dans un prompt système.

2. Placez une frontière validée entre la sortie du modèle et l’utilisateur. Vérifiez chaque réponse composée par le modèle contre des contrats vérifiables par machine avant sa diffusion, et échouez en position fermée en cas de violation.

3. Rendez l’application indépendante du modèle. Si changer de modèle de base modifie le respect d’un contrat, le contrat n’est pas réellement appliqué. Relancez vos vérifications de contrat à chaque substitution de modèle.

4. Préférez des vérifications codées et ciblées aux garde-fous externes larges. Les filtres externes achètent de la sûreté au prix du sur-refus. Des validateurs spécifiques à un contrat préservent l’utilité tout en bloquant la violation.

5. Versionnez et archivez vos artefacts de contrôle. Manifestes, schémas, validateurs et traces doivent être versionnés comme du code afin qu’un audit puisse reconstruire exactement pourquoi une réponse a été autorisée à atteindre un lecteur.

6. Ajoutez des tests par injection de fautes. Cassez délibérément chaque contrat dans un test et confirmez que le validateur le signale. Un garde-fou que vous n’avez jamais vu échouer est un garde-fou auquel vous ne pouvez pas vous fier.

Statut

Élément	Référence	Date	Notes
Preprint ingénierie de harnais	arXiv:2607.08028	2026-07-09	Contrats codés vs application par prompt seul
Test de substitution de modèle	Article	2026-07-09	270/270 exécutions à la frontière de composition réussies, 3 modèles hébergés
Application par prompt seul	Article	2026-07-09	Fuite de trace et langage de recommandation atteignent le lecteur
Harnais vs garde-fou externe	Article	2026-07-09	Harnais utilité complète (120/120) ; garde-fou ajouté sur-refuse (88/120)
Contexte industrie	Microsoft Security	2026-05-07	« Votre LLM n’est pas une frontière de sécurité »

Il s’agit d’une étude de cas unique sur une tranche de données financières publiques, avec une implémentation de référence et des artefacts d’évaluation archivés par les auteurs — elle attend une réplication indépendante plus large. Mais la direction mérite d’être intégrée dès maintenant : à mesure que les agents s’enfoncent dans les workflows réglementés de l’entreprise, les garanties qui survivent sont celles que vous pouvez montrer dans le code, pas celles que vous avez demandé au modèle de retenir.