Et si l'IA dit n'importe quoi ? Comment on évite qu'un agent hallucine en production
TL;DR
Un modèle de langage répond toujours, même quand il ne sait pas. L'hallucination n'est pas une fatalité du modèle : c'est un problème de design. Avec cinq leviers concrets, ancrer dans vos données, autoriser le "je ne sais pas", fermer le périmètre, mettre un humain sur les cas à risque et tout journaliser, le risque passe de "n'importe quoi" à quelque chose de maîtrisé.
Un modèle de langage répond toujours. C'est exactement le piège. Il n'a pas de bouton interne qui dit "je ne sais pas". Si vous ne lui mettez pas de règles, il va inventer une réponse avec la même assurance que quand il en donne une juste.
C'est ce qu'on appelle une hallucination. Et presque chaque fois que je vois un agent halluciner en production, le problème n'est pas dans le modèle. Il est dans la façon dont on l'a conçu.
L'hallucination est un problème de design, pas une fatalité
L'idée que je veux que vous reteniez est simple : un agent qui invente est un agent mal délimité.
Le modèle ne sait pas ce que sait votre entreprise. Il sait ce qu'il a vu pendant son entraînement, mélangé, sans date, sans source. Si vous l'interrogez sur votre politique de retour et que vous ne la lui avez jamais donnée, il va produire quelque chose qui sonne comme une politique de retour. Plausible, bien rédigé, et faux.
C'est pour ça que je ne me bats pas contre le modèle. Je travaille l'environnement autour du modèle. Et là, oui, j'ai des leviers concrets.
Je vous les explique un par un. Aucun n'est magique. Ensemble, ils font passer le risque de "n'importe quoi" à quelque chose de gérable.
Levier 1 : ancrer l'agent dans VOS données, pas dans sa mémoire
La première règle : l'agent ne doit pas répondre de tête. Il doit répondre à partir de vos documents.
La technique s'appelle la recherche documentaire (en anglais, RAG). Le principe est simple à comprendre. Avant de répondre, l'agent cherche dans vos sources (votre base de connaissances, vos PDF, votre catalogue, vos procédures) les passages liés à la question. On transmet ces passages au modèle. Et on lui demande de répondre uniquement avec ça.
La différence est énorme. Sans ça, l'agent improvise avec sa mémoire floue. Avec ça, il lit votre texte et le résume.
Un avantage que les gens sous-estiment : vous pouvez lui demander de citer d'où il tient chaque chose. "D'après le document X, section Y." Quand un agent cite sa source, deux choses se produisent. L'utilisateur peut vérifier. Et vous repérez vite quand quelque chose ne colle pas.
Honnêtement : ça marche si vos données sont propres. Si votre base de connaissances est en désordre, contradictoire ou périmée, l'agent va récupérer du déchet et résumer du déchet. Le travail ennuyeux de mettre de l'ordre dans votre information, c'est la moitié du projet. Il n'y a pas de raccourci.
Levier 2 : lui donner le droit de dire "je ne sais pas"
Un modèle, par défaut, préfère inventer plutôt que se taire. Il faut reprogrammer ce réflexe.
Dans les instructions de l'agent, on écrit quelque chose d'explicite. Si la réponse n'est pas dans les sources récupérées, ne l'invente pas. Dis que tu n'as pas l'information. Et, si c'est pertinent, passe la conversation à un humain.
Ça paraît évident. Presque personne ne le fait bien du premier coup.
Parce qu'il faut le tester avec des questions pièges. Des choses hors de votre domaine, des données qui n'existent pas, des cas limites. Et vérifier que l'agent répond vraiment "je n'ai pas cette donnée" au lieu d'improviser. Un agent qui sait dire "je ne sais pas" vaut mieux qu'un agent qui a l'air de tout savoir.
Levier 3 : un périmètre fermé
Plus l'agent est large, plus il invente. C'est mathématique.
C'est pour ça que je définis un périmètre. L'agent répond sur ce qu'on l'autorise à traiter, et rien d'autre. Un agent de support pour votre produit ne donne pas son avis sur la concurrence, ne donne pas de conseils juridiques, et n'improvise pas sur des sujets qui ne sont pas les siens. Quand quelque chose sort du cadre, il le dit et redirige.
Ce n'est pas qu'une question de sécurité. C'est de la qualité. Un agent spécialisé sur trois choses les fait bien. Un agent qui prétend tout faire les fait toutes à moitié, et sur les bords, il hallucine.
Fermer le périmètre protège aussi des dérives. Les gens testent les agents. Ils leur demandent des recettes de cuisine, des opinions politiques, d'écrire un poème. Un agent bien délimité répond, gentiment, que ce n'est pas son sujet.
Levier 4 : un humain sur les cas à risque
Voici la question qui change tout le design : quel est le coût d'une erreur ?
Si votre agent suggère le mauvais article de blog, il ne se passe pas grand-chose. S'il confirme un remboursement qui ne devrait pas l'être, ou donne une indication sur un sujet sensible, le coût est réel.
Du coup, je cartographie les cas. Là où une erreur est peu coûteuse, l'agent agit seul. Là où une erreur coûte cher, l'agent prépare la réponse mais un humain valide avant qu'elle ne parte. Ou alors il passe directement le cas à une personne.
C'est ce qu'on appelle l'humain dans la boucle. Ce n'est pas admettre que l'IA échoue. C'est décider, en conscience, où l'automatisation totale a du sens et où elle n'en a pas. Un bon agent sait quand c'est à lui de s'effacer.
Levier 5 : tout journaliser et tester avant la production
Ce qui ne se mesure pas ne se contrôle pas.
Chaque conversation de l'agent est enregistrée. Question, sources récupérées, réponse. Comme ça, quand quelque chose tourne mal, on ne devine pas. On ouvre le journal, on voit exactement ce qu'il a récupéré et ce qu'il a répondu, et on comprend pourquoi.
Et avant de mettre quoi que ce soit en production, on teste avec des cas réels. Pas avec des questions de manuel, jolies et prévisibles. Avec les questions bizarres, mal écrites, ambiguës, que vos clients envoient pour de vrai. C'est là qu'un agent casse. Mieux vaut qu'il casse pendant votre test que devant un client.
C'est le travail le moins spectaculaire du projet. C'est aussi celui qui sépare un agent qui tient la route d'une démo qui s'écroule à la première question de la vraie vie.
Le risque zéro n'existe pas (et méfiez-vous de qui vous le promet)
Je vais être direct. Aucun de ces leviers ne ramène le risque à zéro.
Un agent bien conçu peut encore se tromper sur un cas rare. Le but n'est pas la perfection. Le but, c'est un risque maîtrisé : que les erreurs soient peu fréquentes, peu graves, détectables, et que l'agent sache dire "ça, je le passe à un humain" quand il doute.
Si quelqu'un vous promet une IA qui ne se trompe jamais, il vend, il ne construit pas.
Et là revient notre réflexe de toujours : ça dépend de votre usage. Le niveau de garde-fous doit aller avec ce qui est en jeu.
Un assistant qui répond aux questions fréquentes sur vos horaires a besoin de peu de garde-fous. S'il se trompe, vous donnez un mauvais horaire, vous corrigez, vous continuez. Un agent qui touche à l'argent, aux données personnelles ou à des décisions à conséquences a besoin de l'inverse : périmètre étroit, validation humaine, journalisation fine, tests musclés.
On ne met pas les mêmes garde-fous dans les deux cas. Ce serait trop cher dans l'un, trop dangereux dans l'autre. La bonne question n'est jamais "comment j'évite toute hallucination". C'est "que se passe-t-il si mon agent se trompe ici, et combien coûte cette erreur".
Cette réponse définit la quantité d'ingénierie de sécurité dont vous avez besoin. Et c'est une conversation qui vaut la peine d'être tenue avant de construire, pas après. Si vous voulez revoir votre cas avec nous, écrivez-nous. Mais la question de fond, celle qui décide de tout, est la vôtre : dans votre usage, combien coûte une erreur ?