Introduction
La plupart des entreprises qui testent l’IA pour leur service client se heurtent au même obstacle. Le système fonctionne bien pendant quelques semaines. Puis il donne à un client une réponse assurée, mais complètement erronée. Peut-être au sujet d’un délai de remboursement. Peut-être au sujet d’une politique qui a changé au trimestre dernier. Un responsable s’en rend compte et le déploiement, qui était censé couvrir la majeure partie de la file d’attente, s’arrête discrètement avant d’avoir atteint qu’une fraction de celle-ci.
Les données du secteur confirment à quel point ce schéma est courant. Le rapport « 2025 World Quality Report » publié par OpenText, Capgemini et Sogeti a révélé que les préoccupations liées à la fiabilité et aux erreurs étaient le principal obstacle à l’adoption de l’IA pour 60 % des organisations interrogées. Une étude distincte menée par Gong a montré que 58 % des entreprises avaient mis en veilleuse leurs projets d’IA et que près de la moitié des investissements prévus dans ce domaine étaient freinés par des problèmes de confiance plutôt que par des contraintes budgétaires. Les outils sont performants. C’est la confiance en eux qui fait défaut.
Le calcul derrière une mauvaise réponse
Le travail d’assistance est asymétrique, dans la mesure où il pénalise la précision moyenne en tant qu’indicateur. Une réponse correcte fait gagner quelques minutes. Une réponse erronée peut approuver un remboursement qui n’aurait jamais dû être effectué, inventer une politique qui n’a jamais existé ou prendre un engagement que personne n’a autorisé. Lorsque les inconvénients d’une seule erreur l’emportent sur les avantages d’une centaine de réponses correctes, l’optimisation pour le cas moyen est un objectif totalement erroné.
Il existe également un coût moins visible. Un responsable du support qui constate une seule fois que l’IA s’est trompée commence dès lors à tout revérifier, ce qui annule la majeure partie du gain de temps escompté. La confiance ne se mesure pas à chaque conversation. Elle se construit ou s’effondre, et une fois qu’elle s’effondre, les équipes cessent de faire confiance au système même lorsqu’il a raison la plupart du temps.
Les hallucinations ne disparaissent pas, elles sont gérées
Même les modèles linguistiques les plus performants inventent des informations dans certaines conditions, et les chiffres réels sont plus élevés que ce que la plupart des gens imaginent. En matière de synthèse ancrée – une tâche qui revient essentiellement à répondre à partir de vos propres documents d’aide –, le classement des hallucinations établi par Vectara place les meilleurs modèles autour de 3 % et montre que des modèles phares bien connus se situent entre 6 % et 15 %. Certains modèles faisant largement appel au raisonnement dépassent les 20 % sur cette même tâche, car un raisonnement plus approfondi leur laisse davantage de marge pour introduire des affirmations que le texte source n’a jamais formulées. Si l’on soumet un modèle à des questions ouvertes sans aucun point de référence, les chiffres se détériorent considérablement. Des chercheurs de Stanford ont constaté que les modèles de pointe produisaient des hallucinations sur une grande majorité de questions juridiques spécifiques lorsqu’aucun document source n’était fourni.
Cela ne signifie en aucun cas qu’un modèle particulier soit mauvais. Cela signifie simplement qu’aucun modèle, utilisé seul, n’est suffisamment fiable pour être proposé à des clients payants sans qu’un système ne le supervise.
Intelligence et contrôle tirent dans des directions opposées
Il existe une raison structurelle pour laquelle un modèle unique ne peut pas résoudre ce problème à lui seul. À mesure qu’un système s’améliore dans le traitement de cas ambigus ou inconnus, il devient également plus difficile à prévoir dans son intégralité, car le même raisonnement qui lui permet de traiter un cas pour lequel aucun scénario n’a été prévu est celui qui le conduit parfois là où il ne devrait pas aller. Un modèle plus performant n’est pas automatiquement plus sûr. Ce compromis explique pourquoi la fiabilité doit être conçue comme une couche entourant le modèle plutôt que d’être attendue du modèle lui-même.
Aissist aborde cette question à l’aide de quatre techniques superposées plutôt que d’une seule. L’ingénierie des prompts définit les règles de base que chaque tâche doit respecter, ce qui revêt une importance particulière dans un système agentique où une seule demande client peut se décomposer en plus d’une douzaine de sous-tâches qui doivent toutes respecter les mêmes garde-fous. Une étape de « booster » exécute les décisions incertaines plusieurs fois et retient la réponse sur laquelle la plupart des agents s’accordent, au prix d’une charge de calcul supplémentaire. Une étape d’auto-inspection consiste à faire examiner au système sa propre sortie, ou à la transmettre à un deuxième modèle jouant un rôle différent, avant que quoi que ce soit n’atteigne le client. Et une couche de gouvernance superposée vient couronner le tout, vérifiant si une sortie ou une action est conforme à la politique avant sa diffusion, fonctionnant moins comme un filtre que comme un superviseur de l’ensemble du système.
C’est grâce à cette combinaison que la plateforme maintient son taux d’erreur d’IA en dessous de 1 %, un chiffre qui mérite d’être souligné, principalement parce que très peu de fournisseurs dans ce domaine publient un tel chiffre.
Savoir quand ne pas répondre
Le comportement le plus précieux chez un agent du service client n’est pas de répondre correctement à davantage de questions. C’est de reconnaître celles auxquelles il ne doit pas tenter de répondre seul. Un système qui transmet rapidement un litige de facturation délicat, accompagné de tout le contexte, cause bien moins de dégâts qu’un système qui persiste et se contente de deviner. C’est également ce qui distingue un agent qui décrit une solution de celui qui l’applique réellement, en récupérant la commande, en effectuant la modification et en la confirmant au client.
La fiabilité doit être entretenue, pas seulement mise en place
Un système précis le jour de son lancement ne le restera pas sans surveillance. Les produits évoluent, les politiques sont mises à jour, et les questions posées par les clients changent en conséquence. Une mesure continue permet de détecter ces changements sous forme de données plutôt que sous forme d’une vague de réclamations, et un cycle rigoureux d’évaluation, de test et de mise en production comble progressivement les lacunes identifiées, un humain devant toujours valider avant que tout ne soit réellement modifié.
Ce qu’il faut réellement vérifier avant de faire confiance à un fournisseur
Tout fournisseur affirmant que son IA ne se trompe jamais doit être considéré avec méfiance, car cela signifie généralement que personne ne mesure les performances de manière suffisamment précise pour affirmer le contraire. Ceux qui méritent d’être pris au sérieux publient un taux d’erreur, expliquent exactement comment ils détectent les erreurs avant que les clients ne les remarquent, et indiquent clairement à quel moment le système passe le relais à un humain plutôt que de se contenter de deviner. C’est un argumentaire très différent de « faites confiance à l’IA », et c’est celui qui tient réellement la route lorsque le volume réel de tickets atteint son seuil critique.
