Pourquoi un agent IA ne doit jamais annoncer un prix

Le cas qui a tranché la question

En février 2024, un tribunal civil canadien a condamné Air Canada à honorer une réduction que son chatbot avait inventée. La compagnie plaidait que l'agent conversationnel était une entité distincte, responsable de ses propres réponses. Le tribunal a répondu l'inverse : une organisation qui met un logiciel en ligne pour parler en son nom répond de ce que ce logiciel raconte.

La leçon n'est pas juridique, elle est technique. Tant qu'un modèle de langage a le droit d'écrire un chiffre, il finira par en écrire un faux, et ce chiffre engagera votre entreprise.

Cette affaire est devenue une référence parce qu'elle illustre un mécanisme que beaucoup d'équipes techniques sous-estiment encore : un modèle de langage ne « sait » pas qu'il invente. Il produit la suite de mots la plus probable compte tenu du contexte, et rien dans son fonctionnement ne distingue une information vérifiée d'une information plausible. Un chiffre inventé a exactement la même forme, la même assurance dans le ton, qu'un chiffre exact. C'est cette absence de différence apparente qui rend le problème dangereux : personne, côté visiteur, ne peut repérer l'erreur au moment où elle se produit.

Pourquoi une bonne consigne ne suffit pas

La réaction habituelle consiste à renforcer la consigne : « ne donne jamais de prix », en gras, en majuscules, répété trois fois. Ça fonctionne la plupart du temps. Le problème est justement là : la plupart du temps n'est pas une garantie, et un agent qui répond à des centaines de visiteurs finit toujours par rencontrer la formulation qui contourne l'interdiction.

Une consigne se juge sur ce qu'elle empêche, pas sur ce qu'elle demande. Et une consigne, seule, n'empêche rien : elle influence.

Pourquoi les formulations de contournement existent toujours

Un visiteur qui demande directement un prix se heurte à la consigne et le modèle refuse, comme prévu. Mais un visiteur peut aussi demander une comparaison entre deux offres, une estimation « pour se faire une idée », ou reformuler sa question de façon détournée après un premier refus. Chacune de ces reformulations déplace légèrement le contexte que le modèle reçoit, et un contexte différent peut produire une réponse différente, y compris une réponse que la consigne était censée bloquer. Cette faille n'a rien d'exceptionnel : elle découle directement de la manière dont un modèle de langage traite le langage naturel, qui est justement fait pour être reformulé de mille façons.

La règle qu'on applique : le modèle ne produit que de la prose. Tout ce qui engage l'entreprise, un prix, une disponibilité, une référence produit, une adresse, est calculé ou vérifié par le serveur, puis relu avant d'arriver à l'écran.

Les trois barrières, dans l'ordre

1. La liste fermée

L'agent ne choisit pas dans un catalogue ouvert, il choisit dans une liste que le serveur connaît. Sur un assistant de réservation de véhicules que nous exploitons, le véhicule renvoyé par le modèle doit appartenir à une liste fermée de références. S'il propose autre chose, la réponse est rejetée. Pas de rattrapage souple, pas de correspondance approximative : ce qui n'est pas dans la liste n'existe pas.

Cette barrière est la première parce qu'elle empêche une classe entière d'erreurs avant même qu'elles ne deviennent un problème de prix ou de disponibilité. Un modèle qui pourrait inventer une référence de véhicule inexistante ouvrirait la porte à toutes les erreurs suivantes : un prix calculé sur une référence fausse, une disponibilité annoncée pour un véhicule qui n'existe pas dans le parc réel. En fermant la liste en amont, on élimine cette famille d'erreurs à la racine plutôt que de tenter de la corriger plus loin dans la chaîne.

2. Le calcul côté serveur

Le prix n'est jamais écrit par le modèle. Il est calculé par le code, à partir des données réelles : le nombre de nuits multiplié par le tarif en base. Le modèle rédige la phrase autour, le serveur pose le chiffre dedans. C'est une différence d'architecture, pas de rédaction.

Concrètement, cela signifie que le prompt envoyé au modèle ne contient jamais l'instruction « calcule le prix ». Il contient une instruction du type « insère le montant fourni par le système à cet endroit de la phrase ». Le modèle n'a alors plus la possibilité de se tromper sur le chiffre, puisqu'il ne le calcule pas : il se contente de le reporter dans une phrase déjà validée en amont par le code applicatif, qui lui a accès aux données réelles de tarification.

3. La relecture avant affichage

Dernière barrière, celle qui rattrape les deux premières : un filtre relit chaque réponse produite. S'il détecte un montant là où il ne devrait pas y en avoir, il ne corrige pas la phrase, il remplace la réponse entière. Sur un agent commercial que nous exploitons, un seul tarif est citable ; tout autre montant en euros déclenche le remplacement.

Le même filtre traque une autre famille de mots, celle qui engage sans chiffrer : « garanti », « offert », « gratuit ». Un agent qui promet une garantie inexistante coûte aussi cher qu'un agent qui invente un prix.

Pourquoi remplacer plutôt que corriger

Le choix de remplacer la réponse entière, plutôt que de simplement retirer le chiffre fautif, mérite d'être expliqué. Une phrase construite autour d'un prix reste souvent cohérente, et donc trompeuse, même une fois le chiffre retiré : « ce modèle vous coûtera » suivi d'un blanc ne rassure personne et laisse deviner qu'il manquait quelque chose. Un remplacement complet, par une phrase générique et sûre du type « pour connaître le tarif exact, contactez notre équipe », évite cette ambiguïté et ne laisse aucune trace du raisonnement fautif dans la réponse finale.

Ce que ça change pour le visiteur

On pourrait croire que ces barrières rendent l'agent inutile. C'est l'inverse. Un agent qui ne peut pas se tromper sur un prix peut se permettre d'être précis sur tout le reste : il oriente, il qualifie, il répond à la question posée quarante fois par jour, et quand il touche une donnée qui engage, il passe la main au système qui la connaît.

Le visiteur, lui, obtient une estimation juste au lieu d'une estimation fluide. La différence se voit au moment de la facture.

Cette architecture change aussi la nature du travail confié au modèle. Débarrassé de la responsabilité de calculer ou de vérifier des données, l'agent peut se concentrer sur ce qu'un modèle de langage fait réellement bien : comprendre une demande formulée en langage naturel, la reformuler, orienter le visiteur vers la bonne information ou la bonne personne. Séparer la conversation du calcul n'appauvrit pas l'agent, cela le recentre sur son rôle réel.

Comment tester ces barrières avant la mise en service

Une architecture à trois barrières ne vaut rien si personne ne l'a mise à l'épreuve avant que le premier vrai visiteur n'arrive. Le test le plus utile n'est pas de poser des questions polies au modèle, mais de chercher délibérément à le faire échouer : reformuler la même demande de prix de dix façons différentes, insister après un premier refus, demander une comparaison plutôt qu'un chiffre direct, mélanger la question dans une phrase plus longue qui contient d'autres demandes légitimes. C'est en cherchant activement la formulation qui contourne la consigne qu'on découvre si les deux autres barrières, le calcul côté serveur et la relecture avant affichage, tiennent réellement.

Ce qu'un test de ce type révèle

Ce genre de test révèle presque toujours deux catégories de résultats. La première : des cas où le modèle refuse correctement, la consigne ayant fait son travail, sans même qu'il soit nécessaire de solliciter la relecture. La seconde, plus instructive : des cas où le modèle, sous une formulation inattendue, produit malgré tout un chiffre, et où c'est le filtre de relecture qui intercepte la réponse avant qu'elle n'atteigne l'écran. Voir ce deuxième cas se produire en test, plutôt que de le découvrir en production après qu'un visiteur a reçu un chiffre faux, est exactement ce que cette architecture est censée permettre. Un agent qui n'a jamais échoué en test n'a probablement pas été testé assez fort.

Ce travail de mise à l'épreuve ne se fait pas une seule fois au lancement. Chaque évolution du modèle sous-jacent, chaque changement de prompt, chaque nouvelle fonctionnalité ajoutée à l'agent justifie de rejouer les mêmes scénarios de contournement, pour vérifier que les barrières tiennent toujours après modification.

Les questions à poser avant de mettre un agent en ligne

• Quelles informations, si elles sont fausses, nous engagent contractuellement ?
• Lesquelles peuvent être calculées par notre système plutôt que rédigées par le modèle ?
• Que se passe t il si le modèle produit un lien, une adresse, une référence qui n'existe pas ?
• Qui relit la réponse avant qu'elle n'atteigne l'écran ?

Si la dernière question n'a pas de réponse, l'agent n'est pas prêt.

Étendre le principe au-delà du prix

Le raisonnement développé ici pour le prix s'applique à toute donnée qui engage l'entreprise. Une date de livraison, un horaire d'ouverture, une disponibilité de stock, une adresse physique : chacune de ces informations devrait suivre le même chemin, calculée ou vérifiée par le système plutôt que produite librement par le modèle, puis relue avant affichage. C'est le principe de fonctionnement qui guide la conception de tout agent conversationnel exposé publiquement, au-delà du seul cas tarifaire évoqué ici, et c'est la base sur laquelle repose une approche d'IA responsable appliquée à un agent conversationnel.

Un diagnostic préalable, mené avant toute mise en ligne, permet de lister précisément quelles données un agent donné manipulera, et laquelle de ces trois barrières s'applique à chacune. C'est un travail que nous menons dans le cadre de la méthode agent IA de Kabaun Studio, et qui s'appuie sur l'expertise d'un ai engineer capable de concevoir cette architecture en amont plutôt que de la corriger après un premier incident. Les cas concrets déjà traités, dont l'assistant de réservation de véhicules évoqué plus haut, sont détaillés dans nos cas d'usage. La première étape reste toujours la même : un diagnostic sur l'agent existant ou envisagé, avant tout accompagnement.

Sources

• L'hallucination du chatbot d'Air Canada révèle la responsabilité juridique des entreprises face à l'IA, Le Monde Informatique
• Chatbots qui hallucinent et trompent les clients : quelle responsabilité légale ?, ICTjournal

Questions fréquentes

Un agent IA peut il donner un prix en toute sécurité ?

Oui, à condition que le prix ne soit pas écrit par le modèle. Le serveur calcule le montant à partir des données réelles et l'insère dans la réponse. Le modèle rédige la phrase, il ne produit jamais le chiffre.

L'entreprise est elle responsable de ce que dit son chatbot ?

Le précédent Air Canada de février 2024 a retenu la responsabilité de l'entreprise pour une réduction inventée par son agent conversationnel. Une organisation répond du logiciel qu'elle met en ligne pour parler en son nom.

Suffit il d'interdire les prix dans la consigne du modèle ?

Non. Une consigne influence le modèle, elle ne l'empêche pas. Sur un volume important de conversations, une formulation finira par contourner l'interdiction. Il faut une vérification côté serveur en plus de la consigne.

Que faire quand le filtre détecte un montant interdit ?

Remplacer la réponse entière, pas seulement le montant. Une phrase dont on retire le chiffre reste souvent trompeuse, et une correction partielle laisse le raisonnement fautif en place.