Toute entreprise qui travaille avec l'IA finit par connaître le même moment : le système répond d'un ton assuré, et la réponse est fausse.
Cela ne veut pas dire que le système est en panne. Les modèles de langage fonctionnent par probabilité ; quand l'information disponible ne suffit pas, ils peuvent former la phrase la plus plausible plutôt que se taire. Le vrai sujet n'est pas qu'une réponse puisse être fausse, mais qu'une réponse fausse arrive sur le même ton qu'une réponse juste.
Cet article explique pourquoi les réponses fausses apparaissent, quand elles comptent vraiment et où placer les contrôles pendant la mise en place.
🔍 À retenir : Faire entrer l'IA dans une entreprise ne consiste pas à faire comme si l'erreur n'existait pas, mais à décider d'avance où elle va tomber. Qu'une réponse aille au client, sur l'écran d'un collaborateur ou dans une case de validation se décide à la mise en place.
Pourquoi l'IA se trompe-t-elle de réponse ?
Il y a rarement une cause unique. Voici les quatre qui reviennent le plus souvent.
L'information manque ou date
Le modèle lit la source qu'on lui a donnée. Si la liste de prix n'a pas été tenue à jour, si un article retiré figure encore au catalogue ou si un changement de règle vit seulement dans la tête de quelqu'un, la réponse se construit sur cette information ancienne. Ce qui est en cause ici, c'est la source, pas le modèle.
La question est floue
Une question comme "que dois-je faire de cette commande ?" admet plusieurs réponses justes lorsqu'elle arrive sans contexte. Le modèle en choisit une et justifie son choix. Un collègue humain reposerait la question ; un système peut avancer sur une hypothèse.
Combler le vide
Si la source ne contient pas la réponse, le modèle peut en produire une d'après des schémas appris sur des textes voisins. Ce comportement est souvent appelé hallucination. La phrase obtenue est irréprochable sur la langue et inventée sur le fond. C'est l'erreur qui se cache.
Bonne source, mauvais contexte
L'information est exacte mais relève d'un autre cas. Une condition prévue pour un groupe de clients est annoncée à tout le monde, faute de distinction définie dans le système. Prises une à une, ces erreurs paraissent justes et peuvent donc se remarquer tard.
Toutes les erreurs ne pèsent pas pareil
Traiter toutes les erreurs avec la même gravité alourdit la mise en place, et ce poids, personne ne le porte. La distinction suit ce que l'erreur touche.
- Erreurs qui restent en interne : un collaborateur voit la mauvaise réponse, la corrige, le travail continue. Le coût est faible.
- Erreurs qui atteignent le client : l'information fausse sort de la maison. Ce n'est plus un sujet technique mais un sujet de confiance.
- Erreurs d'argent ou de droit : prix, remise, condition contractuelle, données personnelles. Dans ce groupe, mieux vaut que la réponse ne sorte pas directement.
Sans cette distinction, les mises en place finissent à l'un des deux extrêmes : soit chaque réponse attend une validation et le système ralentit, soit aucun poste de validation n'est prévu et la première erreur sérieuse se produit en public.
Où placer la validation humaine ?
La validation se place là où une erreur pourrait coûter cher, pas à chaque étape du système. Trois emplacements peuvent fonctionner en pratique.
Le poste de validation
Les réponses d'un type défini arrivent sur l'écran d'une personne avant l'envoi. Celle-ci valide, corrige ou refuse. Le poste ne joue que sur les flux choisis, le reste avance sans attendre.
S'arrêter en cas de doute
Un système peut être réglé pour transmettre une question au lieu d'y répondre lorsque la source n'a pas de correspondance. "Je transmets à un collègue" vaut mieux qu'une réponse inventée. Ce comportement s'écrit à la mise en place, il ne naît pas tout seul.
La limite du pouvoir d'agir
Ce que le système peut faire seul devrait être écrit : il peut renseigner et ouvrir un dossier, mais pas changer un prix ni valider un retour. Si la limite n'est pas écrite, il n'y a pas de limite.
Adosser la réponse à vos propres sources
La voie la plus directe contre les réponses fausses consiste à faire répondre le modèle depuis les documents de l'entreprise plutôt que depuis son savoir libre. Le système prend la question, trouve le document utile et adosse la réponse à ce document.
Deux bénéfices annexes peuvent en découler. D'abord, la source peut être affichée à côté de la réponse : on voit sur quel document elle repose et la vérification devient simple. Ensuite, la source reste dans l'entreprise. Où les données se trouvent et où elles vont est un autre sujet, traité dans où vont vos données.
Adosser la réponse à la source fait aussi de la source une responsabilité. Si le document date, la réponse date. C'est pourquoi on fixe tôt quel document fait foi et qui le tient à jour.
Que faire quand une réponse fausse apparaît ?
Les corriger une à une ne suffit pas ; il faut remonter à la cause pour que la même erreur ne revienne pas. L'ordre peut être le suivant :
- Le cas est conservé avec sa trace : ce qui a été demandé, la source utilisée, qui l'a vu.
- La cause est isolée : source qui date, question floue, ou vide comblé.
- Si la source date, le document est mis à jour et un responsable lui est désigné.
- Si la question était floue, le système est réglé pour reposer la question.
- Si des vides sont comblés, ce sujet passe au poste de validation ou à la transmission.
Sans ce cheminement écrit, les erreurs se discutent une à une et la même revient plusieurs fois. Là où les projets se bloquent est traité à part dans pourquoi les projets d'automatisation échouent.
Pourquoi la trace compte
Si le système ne se souvient pas de ce qu'il a dit, aucune leçon ne peut être tirée d'une erreur. Relue plus tard, la trace devrait répondre à ceci : quand la question est arrivée, ce qui a été répondu, sur quel document la réponse reposait, si elle est passée par la validation, qui a validé.
Cette trace est aussi une pièce justificative. Quand un client dit "votre système m'a dit autre chose", la conversation s'appuie sur l'enregistrement et non sur la mémoire.
Que dit-on au client ?
Savoir qu'on parle à un système n'abîme pas la confiance ; l'apprendre après, oui. Une phrase de présentation claire et un chemin vers un humain se placent au début de la conversation.
Quand une erreur sort malgré tout, la meilleure voie est de corriger sans délai et de dire simplement ce qui a dérapé. La construction des flux côté client est décrite dans l'automatisation du service client.
Questions à poser avant la mise en place
Si ces questions sont posées au départ d'un projet d'IA, une bonne part des débats suivants peut devenir inutile.
- À partir de quelle source le système construira-t-il ses réponses ?
- Qui met cette source à jour, et à quelle fréquence est-elle revue ?
- Quelles réponses peuvent sortir sans passer par une personne ?
- Que fait le système quand il doute ?
- Qui est prévenu lorsqu'une réponse fausse est repérée ?
- Où sont conservées les traces de conversation, et qui peut les consulter ?
Les réponses varient d'une entreprise à l'autre. Pour travailler la cartographie des processus de façon pratique, notre série de formations aborde ces sujets pas à pas.
Comment nous travaillons
Nous commençons par fixer la source à partir de laquelle les réponses seront construites. Ensuite nous écrivons ensemble quelles réponses passent par la validation et ce que fait le système en cas de doute.
Nous ne proposons pas une mise en place qui fait comme si l'erreur n'existait pas. Nous décidons plutôt où elle tombera, nous en gardons la trace et nous intégrons le chemin de correction à la mise en place elle-même.
Questions fréquentes
Comment repère-t-on que l'IA a mal répondu ?
Le repérer à la seule lecture est difficile, car une réponse fausse est écrite dans la même langue qu'une réponse juste. Trois choses aident en pratique : afficher la source sur laquelle repose la réponse, la validation humaine sur les sujets sensibles, et la lecture par échantillonnage des traces de conversation à intervalles réguliers. Les retours de clients du type "moi j'ai autre chose" devraient aussi être collectés comme un canal à part.
Faut-il qu'une personne valide chaque réponse ?
En général non, et faire passer toute réponse par une validation peut rendre le système inutilisable. La distinction suit le type de réponse : renseigner, ouvrir un dossier et orienter peuvent sortir directement dans la plupart des entreprises. Les réponses touchant au prix, à la remise, à une condition contractuelle, à un retour ou à des données personnelles peuvent aller au poste de validation. Cette liste s'écrit à la mise en place et se revoit avec le temps.
Le système peut-il apprendre à dire "je ne sais pas" ?
C'est moins une affaire d'apprentissage que de réglage. Quand la source n'a pas de correspondance, le système peut être construit pour transmettre le sujet à une personne plutôt que produire une réponse. La formulation de cette transmission, son destinataire et le délai sous lequel le client peut attendre un retour se fixent dans la même mise en place. Ce comportement n'est pas un réglage par défaut, il doit être écrit.
Qui répond du dommage causé par une réponse fausse ?
La responsabilité regarde la partie qui exploite le système et non le système lui-même, d'où l'intérêt d'inscrire les limites de la mise en place au contrat. Si l'on convient d'avance des réponses qui passent par une validation humaine, de la durée de conservation des traces et de la manière de signaler une erreur repérée, la discussion n'est pas reportée. Si votre secteur est réglementé, ces clauses devraient être rédigées avec votre conseil juridique.
Un système adossé à nos documents peut-il quand même mal répondre ?
Oui, mais le type d'erreur change. Dans un système adossé à des sources, les réponses inventées deviennent rares ; ce qui passe au premier plan, c'est le choix du mauvais document ou le transport d'un bon document dans un contexte qui ne lui convient pas. Ces erreurs se voient plus facilement, car le document qui porte la réponse se trouve à côté d'elle. Tenir la source à jour est donc une part permanente de la mise en place.
Fixons Ensemble d'Où Viennent Vos Réponses
Avant de proposer une mise en place, nous parlons de la source, des points de validation et du chemin suivi par le système en cas de doute.
💬 Demander un devis sur WhatsAppConclusion
Une IA qui répond à côté n'est pas une panne, c'est une conséquence de sa façon de travailler. La question d'une mise en place n'est donc pas "une erreur peut-elle survenir", mais où va-t-elle tomber.
Adosser les réponses aux sources de l'entreprise, envoyer les réponses sensibles au poste de validation, écrire que le système s'arrête en cas de doute et conserver la trace des conversations. Ces quatre éléments en place, l'erreur ne disparaît pas, mais elle devient visible et corrigible.