Que fait un agent IA quand il ne connaît pas la réponse (et que fait le tien aujourd'hui)
Un agent bien conçu fait trois choses, dans cet ordre : il détecte qu'il ne sait pas grâce à un signal mesurable, il s'abstient de répondre ou d'agir, et il transmet le cas à une personne avec le contexte déjà réuni. Un agent mal conçu n'en fait qu'une : il répond quand même. Vite, bien écrit et avec aplomb, ce qui est exactement ce qui rend la panne chère, parce que du coup personne ne la regarde deux fois.
D'où la thèse de ce guide, qui sonne exagérée et ne l'est pas : un agent qui ne doute jamais est le plus dangereux que tu puisses avoir. Un doute qui se voit — « ça je ne l'ai pas, je te passe quelqu'un » — coûte un transfert. Un doute qui ne se voit pas — une réponse plausible et fausse, un champ rempli au jugé, un remboursement validé sans base — coûte l'erreur plus le temps de la trouver, et le second terme est presque toujours plus gros que le premier. On ne juge donc pas un agent sur son meilleur cas : on le juge sur ce qu'il fait dans le pire.
Ce qui suit ne parle pas de régler le modèle. Faire baisser l'invention au niveau de la réponse — grounding, citations, une récupération correcte — c'est un autre chantier et il faut le faire : c'est réduire les hallucinations d'IA en production. Ce guide parle de ce qui entoure le moment du doute, qui se conçoit dans ton système et vaut pareil pour un agent de support, un qui lit des factures et un qui prépare un rapport. Les critères précis de passage à un humain dans un chatbot sont dans créer un chatbot IA ; ici, c'est la pièce générale.
Ton agent est entraîné à ne jamais se taire
Avant de concevoir quoi que ce soit, il faut accepter le point de départ, et il est inconfortable : le modèle en dessous arrive avec un biais d'usine contre le silence. Ce n'est pas un avis de consultant contrariant. Le travail de Kalai, Nachum, Vempala et Zhang le dit sans détour : les modèles de langage hallucinent parce que les procédures d'entraînement et d'évaluation récompensent le fait de deviner plutôt que de reconnaître l'incertitude, et le problème persiste à cause de la façon dont la plupart des évaluations sont notées — les modèles sont optimisés pour être de bons candidats à l'examen, et un bon candidat, quand il ne sait pas, répond quand même. Source : Why Language Models Hallucinate, Kalai, Nachum, Vempala et Zhang (OpenAI), 4 septembre 2025, consulté le 13 septembre 2026.
Le corollaire opérationnel est celui qui compte : l'abstention n'est pas un comportement latent qu'on réveille avec une phrase dans le prompt. « Si tu ne sais pas, dis-le » aide à la marge et lâche exactement là où ça fait mal, parce qu'on demande de la prudence à un système entraîné à l'inverse. Le doute, il faut le fabriquer en dehors du modèle : des signaux que le système calcule, des vérifications qui tournent avant d'agir, et une sortie vers une personne qui existe vraiment.
Il y a un second piège, encore plus populaire : demander au modèle à quel point il est sûr. Ça ne marche pas, et c'est mesuré. L'évaluation de Xiong et ses collègues sur l'élicitation de confiance montre que les modèles sont très surconfiants quand ils verbalisent leur confiance, avec des valeurs massivement concentrées entre 80 % et 100 %. Source : Can LLMs Express Their Uncertainty?, Xiong et al., ICLR 2024, consulté le 13 septembre 2026. Un chiffre qui dit presque toujours quatre-vingt-dix n'est pas un signal : c'est une décoration.
Les signaux de doute qui servent, et celui que tout le monde utilise
Le doute utile ne sort pas du modèle : il sort du système autour. Ce sont des signaux calculables, chacun avec son déclencheur, et aucun n'a besoin que le modèle soit sincère.
| Signal | D'où il sort | Ce qui le déclenche |
|---|---|---|
| Couverture de la source | L'étape de récupération, pas le modèle | Aucun passage au-dessus du seuil, ou celui qui remonte ne contient pas la donnée demandée |
| Désaccord avec lui-même | Deux passes sur la même entrée | Les deux réponses ne coïncident pas sur la donnée qui compte |
| Contrat de sortie cassé | La validation, avant que rien ne s'écrive | Un champ obligatoire manque, un montant n'est pas un nombre, une date n'existe pas |
| Règle dure du métier | Ta politique, pas le modèle | Montant au-dessus de la limite, client sans historique, donnée régulée, pays hors périmètre |
| Compteur d'échec | L'orchestrateur | N reprises ou N tours sans avancer |
| Demande explicite | La personne en face | « je veux parler à quelqu'un » |
Les trois premiers se montent dans la journée et attrapent le plus. Celui de la couverture est le plus rentable à l'euro investi : si l'agent répond sur tes documents et que la récupération n'a rien ramené de pertinent, tu sais déjà que la suite est de l'invention, sans avoir à la lire. Binaire, pas cher, et antérieur à la réponse.
Une nuance qui évite l'erreur de conception la plus fréquente : ces signaux ne s'additionnent pas en un nombre magique. Chacun appelle un traitement différent. La couverture vide se règle en disant « ça, je ne l'ai pas documenté » et en transmettant. Le contrat cassé, c'est une reprise bornée puis, si ça casse encore, la file. La règle dure ne négocie avec aucun autre signal : si le montant dépasse la limite, ça passe à une personne même si l'agent est archi-sûr. Un score global de confiance mélange des choses qui ne se ressemblent pas et finit par cacher les trois premiers.
Vérifier avant d'agir : douter d'une réponse n'est pas douter d'une action
L'abstention a deux versions et les confondre coûte cher. S'abstenir de répondre est bon marché : si on se tait de trop, quelqu'un répondra après. S'abstenir d'agir, c'est une autre catégorie, parce qu'une action mal faite laisse une trace dans un système et la défaire coûte plus cher que de la faire. La barre ne peut pas être la même aux deux endroits.
Le guide d'OpenAI pour construire des agents range ça par outil, pas par conversation : il recommande d'évaluer le risque de chaque outil de l'agent et de lui donner une note — faible, moyen ou élevé — selon lecture seule ou écriture, réversibilité de l'action, permissions exigées et impact financier ; puis d'utiliser cette note pour déclencher des actions automatiques, comme s'arrêter pour des contrôles avant d'exécuter des fonctions à haut risque, ou escalader vers une personne. Sur l'intervention humaine, il est tout aussi concret : les deux déclencheurs habituels sont le dépassement de seuils d'échec — limites de reprises, ou ne pas comprendre l'intention de l'utilisateur après plusieurs tentatives — et les actions à haut risque, sensibles, irréversibles ou à fort enjeu, comme annuler des commandes, autoriser de gros remboursements ou effectuer des paiements. Source : A practical guide to building agents, OpenAI, consulté le 13 septembre 2026.
- Vérifier avant d'écrire. Si l'agent va toucher un système, la donnée se vérifie contre la source qui fait foi — le référentiel, l'ERP, le contrat — et pas contre ce que le modèle se rappelle. Sur les actions, la vérification n'est pas une amélioration : c'est l'étape.
- Si ce n'est pas réversible, aucun seuil ne tient. Aucune mesure de confiance n'autorise une action qu'on ne peut pas défaire. Celle-là se confirme, toujours, même si l'agent enchaîne six mois sans faute.
- Si la vérification ne peut pas tourner, c'est déjà le doute. Le système qui devait confirmer est à terre, le document ne s'ouvre pas, l'identifiant n'existe pas. Ce n'est pas un cas rare qu'on résout par analogie : c'est un cas qui s'arrête.
Ça s'articule avec deux décisions qui se prennent à part et qu'il vaut mieux ne pas mélanger : ce que l'agent peut toucher est dans quelles permissions donner à un agent IA, et ce qu'il peut faire seul, dans les niveaux d'autonomie d'un agent. Le comportement du doute est le troisième pied : ce qui se passe quand, avec ces permissions et à cet échelon, le cas précis ne tient pas la route.
Où placer le seuil sans noyer l'équipe
Le seuil n'est pas un nombre qu'on choisit en lisant un article : c'est la conséquence de deux choses à toi, le coût de l'erreur et la capacité de la file. Si l'erreur est bon marché et visible, le seuil peut être lâche. Si elle est chère et silencieuse, on serre. Et si le nombre de cas envoyés en revue ne tient pas dans les heures de ton équipe, ce seuil n'est pas prudent : dans trois semaines il sera validé en bloc sans lecture, ce qui est pire que rien, parce qu'en plus ça produit un journal qui affirme que quelqu'un a regardé.
- Range les tâches de l'agent en trois seaux selon le coût de l'erreur : pas chère et visible, chère et visible, chère et invisible. C'est le troisième qui commande : là, le seuil se met où il faut même si ça pique.
- Démarre volontairement pessimiste. Il est plus facile de défendre un seuil qu'on desserre avec des données qu'un seuil qu'on resserre après un incident.
- Mesure deux semaines et regarde les abstentions, pas les réussites. Pour chaque cas parti en file, note si la personne l'a résolu autrement — l'abstention était juste — ou exactement comme l'agent l'aurait fait — c'était du bruit. C'est ce partage qui bouge le seuil, pas l'impression.
- Ajuste par segment, jamais en global : client nouveau contre client de dix ans, petit montant contre gros, langue où tu as de la documentation contre langue où tu n'en as pas.
- Mets la capacité en plafond dur. Si au bon seuil la file ne tient pas, la conclusion n'est pas de baisser le seuil : c'est que cette tâche ne devrait pas encore être en production sans plus de bras.
Quand le volume monte, ça cesse d'être un réglage et ça devient une fonction avec des créneaux, une couverture et ses propres métriques : c'est la supervision humaine de l'IA à grande échelle, et mieux vaut la monter avant d'en avoir besoin.
Ce qui doit voyager dans le transfert pour que la personne ne reparte pas de zéro
Un transfert sans contexte, c'est un doute bien détecté et mal résolu. L'agent a fait sa part — il s'est arrêté à temps — et le client raconte quand même son problème une deuxième fois, ce qui est exactement ce qui énerve dans un chatbot. Dans un transfert interne, la même chose se produit sans que personne ne râle : la personne reconstruit à la main ce que le système avait déjà.
La mécanique est réglée dans les deux guides de référence. Dans le patron décentralisé décrit par OpenAI, le transfert entre agents passe le contrôle et aussi le dernier état de la conversation ; et un agent, par définition, peut arrêter l'exécution et rendre le contrôle à l'utilisateur en cas d'échec. Anthropic le pose comme des points d'arrêt : les agents peuvent se mettre en pause pour une intervention humaine à des points de contrôle ou quand ils tombent sur un blocage, et il vaut mieux fixer des conditions d'arrêt — un maximum d'itérations — pour garder le contrôle. Sources : A practical guide to building agents, OpenAI, et Building effective agents, Anthropic, 19 décembre 2024 ; les deux consultées le 13 septembre 2026.
Ce que la documentation ne te donne pas, c'est le contenu du paquet. Voici les six champs qui font qu'un transfert fait gagner du temps au lieu d'en coûter :
- Ce que demandait le cas, en une ligne, avec les mots de celui qui a demandé.
- Ce qu'a fait l'agent avant de s'arrêter : ce qu'il a consulté, ce qu'il a trouvé, ce qu'il a écrit s'il a écrit quelque chose.
- Pourquoi il s'est arrêté : le signal précis qui s'est déclenché, pas « faible confiance ». « Aucun document ne couvre la question » et « le montant dépasse la limite » demandent deux choses différentes à la personne.
- Ce qu'il a déjà réuni : identifiants, pièces jointes, données vérifiées. Si la personne doit les redemander, le transfert a raté.
- Ce qu'il n'a PAS fait, quand ça compte : « rien n'a été envoyé au client », « la commande n'a pas été touchée ». Ça évite l'action en double, l'accident classique de l'escalade.
- Ce qu'on attend de la personne : décider, rédiger, autoriser. Un cas qui arrive sans verbe reste dans la file.
Et il manque le trajet retour, que presque personne ne monte : la décision de la personne doit revenir dans le journal avec son motif. Sans ça, chaque abstention est un cas perdu ; avec ça, la file de revue devient la batterie de cas avec laquelle on mesure l'agent le mois suivant. C'est la différence entre un système qui escalade et un système qui apprend aussi de ce qu'il escalade.
Comment mesurer un agent qui doute bien (et pourquoi ton éval le punit aujourd'hui)
Si ta seule métrique est le pourcentage de réussite, tu reproduis chez toi le problème décrit par Kalai et compagnie : quand « je ne sais pas » vaut autant qu'une réponse fausse, deviner est rationnel. Ils appellent ça une épidémie de pénalisation des réponses incertaines, et leur proposition n'est pas d'ajouter une éval d'hallucinations de plus, mais de changer la façon dont on note les évals déjà utilisées. Dans ton entreprise, c'est la même opération, et ça tient en trois nombres.
- Taux d'abstention. Quel pourcentage de cas l'agent arrête. Il n'y a pas de bonne valeur universelle : il y a une valeur attendue que tu fixes et une tendance que tu surveilles. Si elle baisse toute seule d'un mois à l'autre sans que tu aies rien touché, c'est que le signal a cassé.
- Précision de l'abstention. Sur ce qui est parti en file, quelle part la personne a résolue autrement que l'agent ne l'aurait fait. C'est la métrique qui distingue un agent prudent d'un agent peureux.
- Erreur avec aplomb. Les cas partis de travers sans que l'agent ne signale rien. C'est la seule des trois avec un objectif clair, et il vaut zéro. Chacun s'ouvre et se transforme en signal nouveau ou en règle dure.
Avec ces trois nombres, la conversation change de place : ce n'est plus « est-ce qu'il est bon ? » mais « sur quoi se trompe-t-il, et est-ce qu'il le sait ? ». C'est la seule version de la question à laquelle on peut répondre avec des données.
Nous, on monte ce comportement avant l'agent : signaux calculés, vérification obligatoire sur tout ce qu'il écrit, seuil attaché à la capacité réelle et un transfert avec les six champs. C'est ce qu'il y a sous le support IA 24/7 et sous n'importe quel agent qu'on laisse parler à un de tes clients, et ce qu'on surveille à volume dans la supervision humaine de l'IA à grande échelle. Le reste du montage — permissions, autonomie, mémoire, évals — est dans créer un agent IA qui tient en production.