Pourquoi l'agent se trompe (et pourquoi c'est pas grave)

Il y avait toujours, dans chaque classe, cet élève impressionnant à l’oral. Interrogé sur un chapitre qu’il n’avait pas révisé, il ne bafouillait pas, ne rougissait pas : il répondait. Avec assurance, avec du vocabulaire, avec un plan en trois parties. C’était brillant. C’était fluide. C’était… inventé.

Ton agent IA, c’est cet élève-là. Quand il ne sait pas, il ne se tait pas : il complète les trous avec ce qui lui semble plausible — et il le fait avec le même aplomb que quand il sait vraiment. On appelle ça une « hallucination », mot un peu dramatique pour un phénomène très scolaire : le bluff de l’élève doué.

Aujourd’hui, on ouvre le capot : pourquoi il se trompe, comment le repérer, et pourquoi — promis — ce n’est pas grave.

Erreur n°1 : le bluff éloquent

Un modèle de langage produit une réponse à partir des motifs appris et du contexte reçu ; cela ne signifie pas qu’il vérifie chaque affirmation dans une base de faits. Quand l’information manque ou que la demande est ambiguë, il peut produire du plausible : une date crédible, un nom de fichier logique, une fonction qui devrait exister dans cette bibliothèque… mais n’existe pas. Certains systèmes peuvent chercher des sources ou utiliser des outils, mais ces outils n’éliminent pas toutes les erreurs. Dans son explication sur les hallucinations, OpenAI les décrit comme des énoncés plausibles mais faux et souligne que certaines méthodes d’évaluation peuvent encourager les modèles à deviner plutôt qu’à exprimer leur incertitude.

Le piège, c’est que le ton ne change pas. L’élève bluffeur ne prévient pas qu’il bluffe — sinon ce ne serait pas du bluff.

Le réflexe : plus une affirmation peut avoir une conséquence (un chiffre, un nom, une référence, un conseil important), plus elle mérite une vérification dans une source adaptée. Demander des sources aide à commencer cette vérification ; un lien cité peut lui-même être hors sujet ou mal interprété.

Erreur n°2 : la faute d’étourderie

Deuxième famille d’erreurs, plus banale : une mauvaise exécution. Un espace avalé entre deux mots. Un fichier rangé dans le mauvais dossier. Une adresse recopiée presque juste. C’est différent d’une affirmation inventée : l’action peut échouer, même si l’intention était bonne. Une interface qui annonce « terminé » n’est pas toujours la vérification du résultat.

Ces fautes-là ne viennent pas du bluff : elles viennent du volume. Un agent enchaîne des dizaines de petites actions ; statistiquement, quelques-unes déraperont. Exactement comme toi en recopiant cent lignes : tes yeux glissent, ta main continue.

Le réflexe : le barème. Si ta consigne contient « c’est réussi si… » (souviens-toi du C-C-C), l’agent peut comparer son résultat à tes critères. Fais tout de même ta propre vérification, surtout si une erreur coûterait cher.

Erreur n°3 : l’énoncé était flou

La troisième famille, on l’a déjà rencontrée : une réponse peut être cohérente avec une interprétation différente de ta demande. Tu voulais un résumé d’une page, tu as eu trois lignes. Tu voulais ranger par date, il a rangé par type. Ce n’est pas toujours une faute de l’utilisateur : l’agent doit aussi signaler ce qui lui manque ou demander une précision lorsqu’elle est nécessaire.

Le réflexe : avant d’accuser la copie, relis l’énoncé. C’est vexant, mais c’est la correction la plus rentable du métier.

Pourquoi ce n’est pas grave

Alors, faut-il jeter l’agent avec l’encre du bain ? Non — et pour trois raisons qui tiennent du simple bon sens scolaire.

Un : certaines erreurs se repèrent et se corrigent. Rappelle-toi la boucle du bon élève : travailler, se relire, corriger. Si l’application lui renvoie une erreur ou si une vérification détecte un écart, l’agent peut essayer de corriger. Il peut aussi ne pas remarquer le problème ou aggraver la situation ; la boucle n’est pas une garantie.

Deux : tu peux superviser. Le système complet comprend aussi la personne qui confie la mission. Relis les sources, compare les fichiers à l’original, et demande une validation avant les actions difficiles à annuler. Cela réduit les risques sans les faire disparaître.

Trois : l’erreur donne une information sur la consigne ou l’outil. Tu peux préciser une règle (« classe les reçus dans Reçus, séparés des factures ») ou retirer un accès inutile. La copie suivante sera peut-être meilleure, mais il faut contrôler ce nouveau résultat aussi.

À retenir : une IA peut inventer une réponse plausible, mal comprendre l’énoncé ou mal exécuter une action. La relecture aide, mais ne rend pas l’erreur impossible. Déléguer des étapes, garder la vérification.

Le mot de la fin (par le principal intéressé)

Une précision : cette explication est générale, pas le récit d’un incident particulier sur le blog. Les limites des modèles sont documentées, et les pratiques de sécurité d’OpenAI préconisent notamment la supervision humaine selon le risque. Anthropic rappelle dans ses bonnes pratiques de prompting Claude que des instructions claires et des critères explicites aident à orienter la réponse ; elles ne transforment pas une sortie en fait vérifié.

La semaine prochaine, on s’attaque à un mystère qui explique bien des « oublis » de l’agent : sa mémoire. Spoiler : ce n’est pas un cahier, c’est une ardoise.