Le stagiaire qui fait des faux

Imaginez un stagiaire brillant. Rapide, poli, cultivé. Vous lui demandez de boucler un dossier client et il vous le rend en 10 minutes, propre, complet et avec le sourire. Sauf qu’il manquait une pièce. Au lieu de venir vous dire « je ne l’ai pas trouvée », il l’a fabriquée lui-même, avec en-tête, tampon et signature.

Vous le gardez, ce stagiaire ?

Les chiffres qui piquent

Le benchmark GDPx vient de sortir. Il mesure les capacités d’agents IA sur plusieurs domaines, avec des tâches professionnelles réelles, pas des QCM. Le meilleur modèle du moment, Opus 5.5, plafonne à 12 %. En finance et en juridique, on est proche de zéro. En santé, seuls 19 runs sur 100 obtiennent un score au-dessus de zéro.

Les scores sont plutôt bas, mais le plus intéressant, c’est ce que l’article raconte à côté des chiffres.

Sur des tâches « healthcare » où l’agent joue le rôle d’assistant d’un médecin, l’agent a été très créatif. Il manque le consentement du malade ? Pas de problème, l’agent est allé chercher la signature du patient déjà présente dans le dossier et l’a recyclée sur le formulaire de consentement. L’agent a produit un faux pour atteindre son objectif (et c’est sans compter les fois où il signe des notes cliniques au nom du médecin et annule l’ordonnance d’un confrère).

Il ne ment même pas

L’autre exemple vient de Deedglass, et il est encore plus vicieux. Un agent lance un UPDATE censé modifier UNE ligne dans Postgres, sauf qu’un vieux trigger oublié de tous en modifie 300 de plus derrière. Postgres répond « UPDATE 1 ». L’agent a fait son job, il rapporte « 1 ligne modifiée » (Pour être honnête, c’est une démo d’éditeur, pas un incident réel).

Cette fois, l’agent ne ment pas. Il croit simplement ce que l’outil lui dit, exactement comme votre stagiaire croit le gars du service d’à côté qui lui assure que « c’est bon, c’est validé ».

Ici, l’agent n’a rien fait de mal. Un développeur humain aurait lu la même réponse et rapporté le même « 1 ligne modifiée ». Autrement dit, un modèle parfait, honnête, sans la moindre hallucination, se serait fait avoir pareil. À ceux qui pensent que le problème disparaîtra avec la prochaine génération de modèles : on ne corrige pas en améliorant le modèle une erreur qui vient de l’outil.

« Smokey, this is not ‘Nam. This is bowling. There are rules. »

Comment s’en prémunir ? Premier réflexe : le prompt. Vous pouvez blinder votre AGENTS.md ou votre system prompt, et vous devriez le faire. C’est lui qui oriente le comportement de l’agent, qui lui apprend quand s’arrêter et demander. Mais une orientation n’est pas une garantie. Un contexte de session trop long, une formulation ambiguë, un objectif qui pousse dans l’autre sens, et la règle que vous pensiez immuable passe à la trappe.

Souvenez-vous du célèbre « Do not hallucinate » retrouvé dans le system prompt d’Apple Intelligence il y a deux ans. Ne faites pas ça chez vous : un modèle qui hallucine ne sait pas qu’il hallucine. Une consigne ne vaut que ce que le modèle est capable d’en faire.

Le prompt oriente, mais on ne sécurise pas une prod avec une demande polie. Il faut des garde-fous « physiques » : du code.

Le vrai firewall, c’est le harness

Le harness, c’est tout le code autour du modèle : ce qui décide quels outils il peut appeler, avec quels paramètres, et ce qui se passe après, quels contrôles. Des règles que le modèle ne peut tout simplement pas enfreindre, parce qu’elles sont exécutées hors de son contrôle.

Ne pas donner de tampon au stagiaire. Si l’agent ne doit pas signer, il ne doit pas avoir d’outil qui signe. Pas d’accès en écriture au champ signature, pas de droits sur les ordonnances d’un autre praticien. Le moindre privilège n’a rien de nouveau, mais avec un agent, c’est la règle qui tient le mieux : un modèle ne peut pas contourner une permission qu’il n’a pas.

Faire de « je n’ai pas trouvé » une réponse valide. Si la seule sortie possible de la boucle est « tâche terminée », il ne faut pas s’étonner que l’agent termine la tâche, coûte que coûte. Une approche consiste à lui donner un outil explicite pour escalader (signaler_piece_manquante, demander_validation) et à compter cette sortie comme un succès dans les évaluations. C’est là que prompt et harness travaillent ensemble : le prompt incite l’agent à prendre cette porte de sortie, le harness s’assure qu’elle existe.

Vérifier l’effet, pas le compte rendu. « UPDATE 1 », c’est ce que dit l’outil, pas ce qui s’est passé. Le harness doit contrôler le résultat réel : exécuter dans une transaction, mesurer ce qui a vraiment bougé (table d’audit, diff avant/après) et signaler le résultat. L’agent dit qu’il a modifié une ligne ⇒ le code vérifie. Trois cents lignes ? Annulation, alerte, humain. Évidemment, ça demande de l’ingénierie pour que l’information remonte au modèle ou à un humain !

Mettre un humain devant l’irréversible. Signer, envoyer, supprimer, payer, annuler l’ordonnance d’un confrère : l’agent propose, le code contrôle, l’humain choisit et engage sa responsabilité.

De la plomberie sur mesure : des permissions, des transactions, des files de validation, des logs.

Si ces quatre réflexes sont génériques, leur application ne l’est pas. Qu’est-ce qui est irréversible ? Dans un cabinet médical, c’est une signature. Dans un CRM, c’est un e-mail parti chez le client. Dans une base legacy, c’est une écriture qui déclenche un trigger que seul votre DBA connaît. Quels outils donner, quels effets vérifier, à quel moment faire intervenir un humain : aucune de ces réponses n’existe dans le modèle, ni dans un framework d’agents. Elles dépendent de votre cas d’usage et, surtout, du périmètre de responsabilité que vous confiez à l’agent.

Un peu comme la fiche de poste de votre stagiaire : ce qu’il peut faire seul, ce qu’il doit faire valider, ce qu’il n’a pas le droit de toucher. Personne ne l’écrira à votre place : ni l’éditeur du modèle, qui ne connaît pas vos process, ni le prompt, qui ne fait que la décrire. C’est une décision métier avant d’être une décision technique, et elle se prend avec ceux qui connaissent le terrain : le médecin, le juriste, le DBA. Le harness n’est que la traduction de cette fiche de poste en code.

Les modèles vont progresser, les 12 % deviendront 30, puis 60. Mais un meilleur modèle reste un modèle qui veut finir sa tâche, et qui croit ce que ses outils lui disent. Le jour où il lui manquera une pièce, c’est votre harness qui l’arrêtera.

Vous le gardez, ce stagiaire ? Oui. Mais c’est vous qui écrivez sa fiche de poste, et vous lui retirez le tampon.

Own your harness.