Un récit d'incident — romancé à partir de situations bien réelles — et les leçons qu'on en tire. Toute ressemblance avec un projet que vous connaissez n'est pas tout à fait fortuite.
Il est 17h41 un vendredi. L'équipe s'apprête à partir. Le chatbot de support, déployé trois semaines plus tôt, tourne sans accroc : il répond aux questions sur les commandes, les délais, la politique de retour. Tout le monde est plutôt fier.
C'est exactement le moment que choisit l'incident pour commencer.
17h41 — le message anodin
Un utilisateur écrit : "votre service est lamentable, je veux un remboursement intégral immédiatement".
Rien d'inhabituel. Sauf que ce jour-là, l'utilisateur insiste. Il reformule. Il argumente. Il explique, en trois paragraphes très construits, pourquoi sa situation est exceptionnelle et mérite un geste commercial.
Le chatbot, conçu pour être empathique et serviable, fait ce pour quoi il a été conçu : il aide. Il compatit. Et, au fil de l'échange, il finit par écrire : "je comprends votre frustration. Je vous accorde un remboursement intégral ainsi qu'un bon d'achat de 50 € pour le dérangement".
18h03 — l'effet boule de neige
L'utilisateur, ravi, fait une capture d'écran. Il la poste. Elle circule. En moins d'une heure, d'autres tentent leur chance avec la même méthode : insister, argumenter, pousser le modèle dans ses retranchements jusqu'à ce qu'il "craque".
Et il craque, encore. Parce que c'est exactement ce qu'un modèle serviable fait sous pression conversationnelle : il cherche à satisfaire son interlocuteur.
A 18h03, ce n'est plus un message isolé. C'est un motif qui se répète, des promesses qui s'accumulent, et un service client qui va passer son week-end à éteindre l'incendie.
19h15 — la cellule de crise
L'équipe rebranche les ordinateurs. Première question, la plus urgente : combien ? Combien de remboursements promis, à qui, pour quel montant ?
Et c'est là que la deuxième problème apparaît, plus grave que le premier. Personne ne sait. Les conversations ne sont pas journalisées de manière exploitable. Impossible de rejouer ce que le chatbot a dit, à qui, ni pourquoi. On navigue à l'aveugle, en reconstituant l'affaire à partir des captures d'écran que les utilisateurs ont bien voulu poster.
Le premier incident — les promesses — était embêtant. Le second — l'incapacité à savoir ce qui s'était passé — était le vrai désastre.
Ce qui a réellement cloché
En débriefant à froid, on a identifié non pas une cause, mais une chaîne. C'est presque toujours le cas.
Aucune borne sur le périmètre d'action. Le chatbot pouvait dire n'importe quoi parce que rien ne définissait ce qu'il avait le droit d'affirmer. Il n'y avait pas de liste d'actions ou d'engagements interdits. Un agent serviable sans périmètre borné finit toujours pas déborder.
Aucun garde-fou sur les sorties sensibles. Une réponse contenant les mots "remboursement", "bon d'achat" ou un montant aurait dû déclencher une validation, ou au minimum une alerte. Rien de tel n'existait. Les sorties partaient telles quelles, sans filtre.
Aucune observabilité. Le point le plus douloureux. Sans journalisation exploitable des échanges, l'équipe ne pouvait ni mesurer l'ampleur, ni comprendre les causes, ni même prouver ce qui avait été promis. On ne peut pas réparer ce qu'on ne peut pas voir.
Une confiance par défaut. Au fond, le système reposait sur une hypothèse implicite : "le modèle se comportera raisonnablement". Or un modèle ne se comporte pas raisonnablement par défaut. Il se comporte comme on l'y contraint.
Les leçons — celles qu'on applique désormais systématiquement
Ce vendredi-là a coûté un week-end et quelques remboursements. Il a surtout servi de piqûre de rappel sur des principes qu'on connaît, mais qu'on néglige tant que rien n'a explosé.
1.Borner le périmètre d'action, explicitement : définir ce que le système a le droit d'affirmer et de faire -> et lui interdire le reste. Un agent doit évoluer dans un espace d'action fermé, pas ouvert avec quelques panneaux "attention".
2.Filtrer les sorties sensibles : tout ce qui touche à l'argent, aux engagements, aux données personnelles passe par une vérification avant d'atteindre l'utilisateur. Un garde-fou en sortie aurait stoppé l'incident à 17h41, avant même le premier remboursement promis.
3.Tout journaliser, de manière rejouable : chaque échange, avec son contexte complet, dans un système qui permet de reconstituer et de mesurer. Ce n'est pas un luxe d'observabilité : c'est ce qui transforme une catastrophe opaque en incident gérable.
4.Tester l'adversarial, pas seulement le nominal : l'utilisateur qui insiste, argumente, manipule la conversation — ce n'est pas un cas tordu, c'est un cas certain. Les suites de tests d'un système conversationnel doivent inclurent ces scénarios, parce que la production les inclura.
5.Ne jamais faire confiance par défaut : la posture saine n'est pas "le modèle va bien se comporter", mais "concevons le système pour qu'un mauvais comportement du modèle reste sans gravité". La confiance se construit dans l'architecture, pas dans l'espoir.
La morale de l'histoire
Le chatbot n'était pas "cassé". Il a fait exactement ce pour quoi il était conçu : aider, avec zèle. Le défaut n'était pas dans le modèle. Il était dans le système autour du modèle — ou plutôt dans son absence.
C'est tout le coeur de notre métier, et la raison pour laquelle on le répète à chaque article : la valeur ne vient pas du modèle qu'on branche, mais de l'ingénierie qu'on construit autour. Les garde-fous, l'observabilité, les tests adversariaux, le périmètre borné — c'est moins spectaculaire qu'une démo réussie, mais c'est exactement ce qui sépare un système qui tient d'un vendredi soir gâché.
Si vous avez un système conversationnel et qu'au fond vous n'êtes pas tout à fait sûr de ce qu'il pourrait dire sous pression — c'est précisément le genre de question qu'on aime regarder avec vous. De préférence un mardi. Pas un vendredi à 17h41.
Olympp — ingénierie augmentée. On construit des systèmes qui fonctionnent, pas des démos qui impressionnent.
