Dans le bot pour amoCRM, deux limites de dialogue ne fonctionnaient pas depuis le lancement : un ET à la place d’un OU et une branche défectueuse en cause

Imaginez : les valeurs sont affichées dans l’interface d’administration, le paramètre est enregistré et l’interface semble fonctionner comme prévu. En réalité, il ne fait absolument rien. C’est précisément ainsi que nous avons découvert, le 30 septembre, qu’aucune des deux limites de longueur des dialogues du bot Octery ne fonctionnait — et qu’elles n’avaient vraisemblablement jamais fonctionné depuis le lancement.

Octery répond aux prospects dans les chats amoCRM et transfère l’opportunité à un responsable. Il existe deux limites. Max Messages définit le nombre de réponses que le bot peut fournir avant de faire appel à un humain. Hard Stop Threshold détermine combien de messages dénués de sens consécutifs il tolère : « aaa », « test », « ??? », voire un texte destiné à un tout autre bot. Chacun de ces messages coûte un appel au modèle ; il n’y a donc aucune raison d’y répondre indéfiniment.

Deux erreurs qui se dissimulaient mutuellement

La décision de transfert était prise après la réponse du modèle, dans le pipeline de traitement. La condition réunissait trois vérifications, reliées par un ET. Or, d’après la logique des paramètres, les limites sont indépendantes : le transfert doit avoir lieu lorsque le compteur de réponses est épuisé ou lorsqu’une série de messages dénués de sens atteint le seuil. Avec un ET, le bot n’appelait un responsable que si le client avait simultanément épuisé la limite de messages et envoyé plusieurs messages absurdes d’affilée. Cela ne se produisait jamais.

La seconde erreur se trouvait dans la branche censée s’exécuter lorsque la condition était remplie. Elle remplaçait la réponse par « transfert à un responsable » et définissait l’intention sur manager. Mais les valeurs étaient écrites dans des champs dont les noms contenaient des expressions à la place des véritables identifiants : la valeur était insérée dans le champ du nom et y restait. De plus, l’envoi de la réponse et la journalisation lisaient les données non pas dans cette branche, mais directement dans le résultat de l’analyse de la réponse du modèle. Même si quelqu’un avait remplacé le ET par un OU, le client aurait reçu une réponse ordinaire et les journaux n’auraient montré aucune trace du transfert.

Chacune de ces erreurs aurait été détectée séparément dès le premier test manuel. Ensemble, elles ont rendu les limites invisibles.

Pourquoi personne ne l’a remarqué

La logique se trouvait dans la configuration du pipeline, et non dans le code. Impossible d’écrire simplement un test unitaire pour cette configuration ou de l’exécuter dans la CI ; lors d’une revue, la modification ressemble à « correction de la condition », sans diff lisible. Faire progresser manuellement une conversation réelle jusqu’à la limite prend du temps, si bien que les contrôles ordinaires ne l’atteignaient jamais. À la question « les limites fonctionnent-elles ? », il n’existait ni réponse positive ni réponse négative.

Ce qui a été fait

La décision a été déplacée dans l’API sous la forme d’une fonction pure distincte. Le pipeline lui transmet la réponse du modèle et deux compteurs issus de l’état du dialogue, tandis que la fonction récupère elle-même les limites dans les paramètres de l’entreprise, empêchant ainsi l’appelant d’en fournir d’autres. Elle renvoie une seule décision finale : le texte, l’intention et la raison du transfert. Toutes les étapes suivantes lisent exclusivement ce résultat.

Les formules comportent deux pièges de décalage d’une unité. Le compteur des réponses est évalué avant le message courant : le bot fournit exactement max_messages réponses, puis transfère. La série de messages dénués de sens est calculée en incluant le message courant, conformément à l’indication affichée dans l’interface. Si les deux conditions sont remplies, la limite de messages est enregistrée comme raison. Si le modèle de phrase est vide, la phrase par défaut est utilisée. Nous avons également supprimé un effet secondaire : l’ancienne branche attribuait au message la note « dénué de sens », ce qui faussait les analyses.

Des tests issus de la spécification

Le comportement a d’abord été décrit sous forme de scénarios, puis chacun est devenu un test, soit 16 au total. Leurs noms parlent d’eux-mêmes : « hands off on the Nth non-meaningful message in a row, counting the current one », « a meaningful message breaks the non-meaningful streak ». Le test « old AND case » a été conservé intentionnellement : l’unique situation dans laquelle l’ancienne condition se déclenchait est désormais un cas particulier de la nouvelle.

Risque de déploiement et conclusion

Le principal risque n’est pas technique. Les entreprises ayant défini de petites limites verront pour la première fois le bot se taire et appeler un responsable. Elles pourraient percevoir cela comme une nouvelle fonctionnalité plutôt que comme une correction. Elles sont donc prévenues avant l’activation ; cette étape figure séparément dans le plan de déploiement.

Conclusion pratique pour les équipes utilisant des pipelines no-code ou low-code : lorsqu’un nombre est visible par le client dans l’interface, son comportement doit être couvert par un test automatisé, dont le nom doit exprimer la promesse faite au client. Il vaut mieux déplacer de la configuration vers le code toute logique métier dont dépendent des revenus ou le transfert d’un client à un humain : elle pourra alors être examinée dans un diff et exécutée dans la CI.