À vingt-deux heures trente, l'assistant IA d'une autre entreprise a écrit sur le WhatsApp d'un client dont l'un de nos bots s'occupe. Ils se sont salués. Ils se sont dit au revoir. Cinq minutes plus tard, notre bot s'est de nouveau présenté, et ça a continué toute la nuit : un échange toutes les 21 secondes, neuf heures et demie sans interruption.
En moins de trois heures, ils ont consommé neuf millions de jetons et épuisé le solde chez le fournisseur du modèle. À partir de ce moment-là, le bot n'a pu générer une seule phrase, pour personne, pendant près de sept heures. La vérification de santé est restée au vert tout ce temps. Nous l'avons coupé à la main le matin.
En argent, c'était peu : un peu plus de neuf dollars. Aucun prospect n'a été perdu, et c'était de la chance, pas de la conception. C'était tôt le mercredi matin. La même panne un mardi en milieu de matinée aurait laissé chaque personne qui écrivait recevoir un message d'erreur, sans qu'aucune alerte ne nous prévienne.
Avant de corriger quoi que ce soit, nous avons séparé la cause de ce qui l'a aggravée. Il y avait une seule cause : aucun plafond par contact n'existait. Un seul numéro pouvait consommer tout le budget sans rencontrer de limite.
Le reste, ce sont des amplificateurs. Le message d'erreur demandait « pouvez-vous répéter votre message? », ce qui, avec une personne, est une bonne attention, et avec un autre bot, une machine à mouvement perpétuel : il a été envoyé plus de mille fois. La mémoire du bot avait une limite qui effaçait ses propres salutations de départ, alors il s'est présenté de nouveau 44 fois. Et la fermeture de la conversation dépendait du jugement du modèle, qui ne l'a jamais appliqué parce que l'autre bot était d'une politesse irréprochable.
Nous avons corrigé chaque faille avec sa propre couche. Un plafond de tours par contact, qui coupe le son sans bloquer. Un relais réel entre fournisseurs, cette fois sur le chemin que le bot emprunte vraiment. Un test toutes les quelques minutes qui demande au modèle une réponse de la taille d'un vrai tour, parce que la panne venait du solde et qu'un test bon marché serait passé sans rien remarquer. La vérification de santé dépend maintenant de ce test. Un détecteur de conversations qui n'avancent plus. Un message d'erreur qui n'invite plus à répéter. Et les alertes techniques arrivent maintenant sur notre propre canal, pas sur celui du client.
Chaque couche échoue de façon ouverte : si un contrôle tombe, il laisse passer le trafic. Nous acceptons ce risque parce qu'un contrôle en panne ne devrait jamais faire taire un client légitime.
En vérifiant la correction, nous avons trouvé quelque chose que personne ne cherchait. La transcription des notes vocales était brisée depuis trois mois et demi. Personne ne l'avait remarqué, parce que le bot, avec toute sa politesse, demandait simplement aux gens d'écrire.
C'est de là qu'est venue une règle que nous appliquons maintenant à tout ce que nous construisons. Concevoir un système pour qu'il ne casse pas devant l'utilisateur reste la bonne approche, mais chaque réponse polie à une erreur doit laisser un compte persistant du nombre de fois où c'est arrivé. La vérification de santé teste la fonction, pas l'infrastructure. Et aucun message d'erreur n'invite à réessayer quand, de l'autre côté, il peut y avoir une machine.