Quand le bot se trompe, qui répond ? La question qu'on évite avant la production.

Un LLM face au client se trompera. Pas par intention, mais parce qu’il produit du texte plausible à partir d’indices incomplets. Une réponse peut sembler sûre, tout en étant fausse, incomplète ou hors cadre. Le vrai sujet n’est donc pas la perfection du modèle. C’est la capacité de l’organisation à encadrer ses écarts.

Le scénario le plus risqué est toujours le même. Le bot est branché, quelques scénarios simples passent en recette, puis le canal s’ouvre. La première réponse litigieuse arrive avant que les rôles soient fixés. À ce stade, le problème n’est plus technique. Il devient contractuel, opérationnel et réputationnel.

Un bot client n’est acceptable que si son périmètre, ses traces et sa chaîne de responsabilité sont écrits avant le go-live. Sinon, chaque phrase publiée peut être relue comme une promesse, une information engageante ou un refus contestable.

Le périmètre doit être écrit avant le prompt

Un bot n’a pas le droit de tout dire. Il doit répondre dans un cadre borné, validé par métier, conformité et juridique. Sans ce cadre, la moindre variation de formulation peut devenir une affirmation opposable.

Le mécanisme est simple. Un LLM ne sait pas, par défaut, distinguer une réponse commerciale d’une réponse réglementée. Il complète les trous avec ce qui paraît cohérent, pas avec ce qui est autorisé. Si vous ne listez pas les cas permis, les refus obligatoires et les escalades, le modèle invente une continuité là où il faudrait une barrière.

Demandez à l’éditeur ou à l’intégrateur : « Quelles intentions exactes le bot peut-il traiter, avec exemples positifs et négatifs ? » Exigez aussi : « Quelles formulations sont interdites mot pour mot, et où sont-elles bloquées dans la chaîne ? » Vérifiez contractuellement qu’aucune réponse sur prix, délai, résiliation, couverture ou éligibilité ne peut être émise sans règle explicite et traçable.

Piège fréquent : le bot “comprend” une question sensible et répond avec un ton prudent, mais sans base autorisée. Le symptôme est clair : une réponse plausible, polie, et pourtant impossible à justifier ligne par ligne. Dans ce cas, le périmètre n’est pas un document de cadrage. C’est une illusion de contrôle.

Chaque réponse doit laisser une trace exploitable

La mémoire floue ne protège personne. Pour défendre une réponse, il faut reconstituer l’échange exact, la version du modèle, le contexte injecté, la règle appliquée et la source consultée. Sans cette chaîne, l’audit devient une discussion d’opinion.

Le bon critère n’est pas “nous avons des logs”. Le bon critère est : pour chaque interaction, peut-on produire la transcription exacte, l’horodatage, l’identifiant de version du modèle, les documents utilisés et la justification d’un refus éventuel ? Si la réponse est non, la traçabilité est décorative.

Demandez précisément : « Quel format de journalisation livrez-vous, et combien de temps conservez-vous chaque champ ? » Puis : « Pouvez-vous exporter une interaction complète sans reconstruction manuelle ni accès aux consoles internes ? » Exigez que les traces soient lisibles par un juriste, un auditeur et un exploitant, pas seulement par un ingénieur.

Piège classique : des logs techniques existent, mais ils ne disent pas pourquoi la réponse a été donnée. On voit des métriques de latence, des scores de confiance, parfois des IDs de requêtes, mais pas la règle d’autorisation. Le symptôme est immédiat : impossible de prouver pourquoi le bot a répondu oui, ou pourquoi il a refusé. Sans chaîne probante, la contestation gagne par défaut.

Sans transcription exacte et règle d’autorisation, il n’y a pas de preuve. Il n’y a qu’une conversation perdue.

La responsabilité doit être nommée avant le go-live

Quand un bot dit faux, quelqu’un répond. Pas “l’IA”. Pas “la plateforme”. Une entité juridique, un exploitant, un éditeur, ou un responsable métier porte la charge. Si ce point reste flou, le contrat ne protège que sur le papier.

Le mécanisme de risque est connu. Plus la chaîne est longue, plus chacun suppose que l’autre arbitre. En cas d’incident, cette dilution ralentit la correction, retarde la notification et complique la preuve de diligence. Le bot parle vite. L’organisation, elle, doit pouvoir réagir sans ambiguïté.

Demandez noir sur blanc : « Qui garantit quoi, sur quel périmètre, et avec quelle limite de responsabilité ? » Puis : « Qui instruit un signalement, qui bloque le service, et qui décide d’une notification client ? » Vérifiez la matrice RACI sur les réponses sensibles. Qui valide les contenus ? Qui arbitre les exceptions ? Qui suspend le canal si l’écart se répète ?

Piège précis : un contrat qui mentionne la “meilleure diligence” sans procédure de remédiation ni délai de réaction. Le symptôme, en exploitation, est une équipe qui ouvre des tickets sans pouvoir couper le service. La responsabilité diluée produit toujours le même résultat : tout le monde a un avis, personne n’assume la coupure.

Le mode de défaillance doit être prévu comme une fonction normale

Un bot fiable n’est pas un bot qui ne se trompe jamais. C’est un bot qui sait s’arrêter. Il doit reconnaître l’incertitude, refuser une réponse et transférer vers un humain quand la règle n’est pas nette.

Le vrai test ne porte pas sur les cas faciles. Il porte sur les zones grises : condition tarifaire ambiguë, clause contractuelle, donnée réglementée, exception de parcours. Si le bot improvise pour rester utile, il transforme une incertitude en affirmation. Le fallback doit donc être conçu comme un comportement natif, pas comme un correctif ajouté après coup.

Demandez : « Quels seuils de confiance déclenchent le refus ou l’escalade ? » Puis : « Quels messages de refus sont validés par conformité, et dans quels cas exacts le transfert humain s’active ? » Exigez aussi un critère vérifiable d’arrêt d’urgence : qui coupe quoi, en combien de temps, avec quelle preuve de coupure et quel journal d’incident.

Piège courant : forcer le bot à répondre pour “rester utile”. Le symptôme est une réponse qui comble le vide au lieu de l’indiquer. Dès qu’un système préfère inventer plutôt que s’arrêter, il dépasse le niveau de risque acceptable pour un canal client.

Le go-live n’est acceptable qu’avec une preuve de gouvernance

Le lancement n’est pas une victoire technique. C’est une décision de risque. Une démonstration fluide ou un taux de satisfaction flatteur ne suffisent pas à autoriser un LLM en production.

La gouvernance doit être prouvée, pas seulement déclarée. Il faut pouvoir montrer le périmètre autorisé, la traçabilité complète et la responsabilité contractuelle et opérationnelle. Sans ces trois pièces, le projet reste une expérimentation maquillée en service.

Demandez : « Pouvez-vous fournir un dossier de mise en production avec le périmètre, les journaux, les règles d’escalade et le responsable d’incident ? » Puis imposez un test de bout en bout sur une interaction sensible. Obtenez la réponse du bot, la règle qui l’a autorisée, la trace horodatée et le nom de la personne qui traite l’écart. Si une seule pièce manque, le feu vert est prématuré.

Piège concret : un go-live validé sur des scénarios simples, mais sans preuve sur les cas sensibles. Le symptôme apparaît dès le premier litige : personne ne sait expliquer chaque phrase sortie en production. Le bon critère n’est pas “le bot fonctionne”. C’est “nous pouvons défendre chaque réponse, ligne par ligne, devant un client, un auditeur ou un juge”.