Workflow de chatbot : comment en concevoir un qui résout les tickets

Ce qu'est vraiment un workflow de chatbot

Dépouille un chatbot de tout le reste et il ne reste que deux choses : une interface conversationnelle, et la logique sous-jacente qui décide de ce qui se passe ensuite. Cette logique, c'est le workflow, et c'est le vrai moteur derrière toute IA de service client. Tidio le dit clairement dans son guide sur les organigrammes de conversation : les chatbots ne sont "guère plus que des diagrammes d'arbre de décision équipés d'une interface conversationnelle".

C'est vrai pour la forme d'un workflow, mais ce qui est intéressant, c'est ce qui remplit chaque nœud. Un workflow n'est pas juste "si l'utilisateur clique sur A, va en B". Un bon workflow doit comprendre un message qu'il n'a jamais vu, trouver la bonne réponse dans une base de connaissances, et connaître la différence entre une question qu'il peut clôturer sans risque et une qu'il ne devrait jamais toucher. La carte, c'est la partie facile. Le jugement à l'intérieur de chaque étape, c'est ce qui fait réussir ou échouer un workflow de chatbot.

Voici l'ensemble en un coup d'œil, puis je détaille chaque étape.

Les six étapes d'un workflow de chatbot de support

Presque tout workflow de chatbot de support, basé sur des règles ou sur l'IA, traverse les mêmes six étapes. Les nommer rend évident où le tien est faible.

1. Déclencheur. Quelque chose lance le workflow : un client ouvre la bulle de chat, envoie un e-mail, écrit sur WhatsApp, ou un nouveau ticket arrive dans le helpdesk. Le déclencheur apporte aussi le contexte dont tu auras besoin plus tard, comme le canal, l'historique de commandes du client, ou la page sur laquelle il se trouvait.
2. Comprendre l'intention. Le bot détermine ce que la personne veut vraiment. Un flux basé sur des règles fait cela avec des boutons et des mots-clés ; un workflow IA lit directement le texte libre, si bien que "mon colis n'est toujours pas arrivé" et "où est ma commande" tombent sur la même intention sans qu'aucune des deux formulations ait été scriptée.
3. Récupérer les connaissances. Le bot cherche la réponse dans un centre d'aide, d'anciens tickets, des documents internes, ou un système en direct comme une base de données de commandes. C'est l'étape que la plupart des démos sautent et sur laquelle la plupart des vrais workflows vivent ou meurent : un bot sans fondement invente tout simplement des choses.
4. Décider et bifurquer. Une fois l'intention et une réponse en main, le workflow choisit un chemin : répondre directement, poser une question de clarification, exécuter une action, ou escalader. C'est le cerveau du workflow, et c'est là que la vérification de confiance a sa place.
5. Exécuter une action. Pour des questions simples, l'"action" consiste juste à répondre. Pour de vraies résolutions, il faut faire quelque chose : consulter une commande, émettre un remboursement, étiqueter et acheminer le ticket, mettre à jour un champ. Un workflow qui ne peut que parler, jamais agir, plafonne à la déviation et n'atteint jamais la résolution.
6. Résoudre ou escalader. La conversation se termine de l'une des deux façons : le bot la résout, ou il la transfère proprement à un humain avec tout le contexte attaché. Un transfert qui déverse le client dans une nouvelle file pour qu'il réexplique tout n'est pas un transfert, c'est une punition.

Voici à quoi ressemblent les étapes 2 à 6 dans un vrai produit plutôt que sur un schéma : le client demande, l'agent répond à partir de connaissances connectées, et à l'instant où il ne peut plus aider, il propose un humain.

J'ai récemment observé exactement ce scénario se dérouler sur le chat en direct du site d'un outil SEO : le bot a répondu à deux questions pratiques tirées de la documentation, et à l'instant où l'utilisateur a tapé "puis-je parler à un humain ?", il a transféré sans hésiter. Cette déviation propre suivie d'un transfert, c'est à quoi ressemble un workflow sain dans la vraie vie, et c'est le schéma qui mérite d'être visé.

Workflows basés sur des règles vs workflows d'agent IA

La décision la plus importante que tu prendras n'est pas une étape, c'est quel type de workflow tu construis. Les deux se ressemblent sur un tableau blanc et se comportent de façon totalement différente en production.

Un workflow basé sur des règles est un arbre de décision que tu dessines à la main. Il est prévisible et facile à raisonner, et pour un flux étroit et à fort volume ("vérifier le statut de ma commande" derrière trois boutons), il fonctionne vraiment bien. Le piège, c'est tout ce qui sort du script, et les mathématiques sont brutales : Tidio souligne qu'un arbre "simple" de seulement sept questions oui/non se ramifie déjà en 128 scénarios possibles, ce qui explique pourquoi leur propre règle est "un bot de décision, un sujet". Dépasse cette limite et le client tape quelque chose que tu n'avais pas anticipé, et le bot n'a nulle part où l'envoyer, l'impasse classique de l'organigramme. Tu finis par maintenir un arbre qui ne cesse de grossir, ajoutant une branche à chaque nouvelle formulation, et il ne parvient toujours pas à suivre le rythme de la façon dont les gens écrivent réellement.

Un workflow d'agent IA inverse l'effort. Au lieu que tu énumères chaque chemin, l'agent lit l'intention dans le texte libre, récupère la réponse dans tes connaissances, et décide quoi faire, y compris reconnaître quand il dépasse ses capacités. Tu ne dessines plus de branches ; tu poses des garde-fous.

Ce n'est pas un argument du type "les règles sont mortes". De nombreux bons workflows utilisent des règles pour les parties déterministes (heures d'ouverture, un numéro de commande requis) et confient la compréhension du langage floue à l'IA. Mais si tu construis un workflow de support en espérant traiter toute la variété de ce que les clients écrivent, un arbre de décision pur te posera problème indéfiniment. C'est la même raison pour laquelle les équipes abandonnent les bots scriptés au profit d'un vrai agent IA à mesure que le volume augmente.

Les deux points de décision qui comptent vraiment

Une fois qu'une IA gère la compréhension du langage, ton travail de conception se réduit à deux questions : quand le bot doit-il agir seul, et quand doit-il s'écarter ? Fais ça correctement et le reste du workflow se gère presque tout seul.

Router selon la confiance, pas les mots-clés

Le contrôle le plus demandé que j'entends de la part des équipes de support est le routage basé sur la confiance : laisser le bot ne traiter que ce dont il est sûr, et laisser le reste tranquille. Une responsable CX d'une marque de compléments alimentaires DTC, qui gère environ 7 000 tickets par mois sur Gorgias, a exprimé cette crainte mieux que je ne saurais le faire. L'IA ne répondra jamais à 100 % des questions, m'a-t-elle dit, et si elle répond simplement "désolé, je ne sais pas", elle ne peut pas retourner vérifier 7 000 tickets pour voir si ça a réellement aidé. Ce qu'elle voulait, c'était une IA qui "ne traite que les tickets qu'elle est confiante de traiter, et laisse tous les autres tranquilles".

C'est tout l'argument pour évaluer la confiance à l'étape de décision et de bifurcation. Un workflow qui répond à tout est un workflow qui se trompera avec assurance. Un workflow qui évalue sa propre certitude peut résoudre automatiquement les tickets faciles, rédiger une réponse pour un humain sur les cas intermédiaires, et ne jamais toucher ceux qu'il ne comprend pas.

C'est aussi ta meilleure défense contre les hallucinations. Au lieu d'espérer que le modèle se comporte bien, tu fixes un plancher : sous un seuil, le bot rédige au lieu d'envoyer, ou escalade au lieu de deviner. Le seuil de confiance d'intention est un vrai réglage dans les outils matures, pas une abstraction.

Concevoir l'escalade, pas la rajouter après coup

L'autre point de décision est le transfert vers un humain, et il mérite autant de conception que le chemin idéal. J'entends l'objectif formulé presque à l'identique lors des appels commerciaux : un responsable support d'un service de suivi de bus, qui gère 200 à 250 tickets Zendesk par mois, voulait un agent capable de "traiter 60 % des tickets Zendesk entrants et de savoir quand faire intervenir une vraie personne pour une meilleure analyse et résolution". La moitié "savoir quand faire intervenir une vraie personne" est la moitié importante.

Une bonne escalade transporte l'intégralité de la conversation, le contexte du client et la meilleure hypothèse du bot sur le problème directement vers le bon humain ou la bonne file, pour que personne n'ait à réexpliquer quoi que ce soit. C'est pourquoi les développeurs matures traitent le transfert comme une étape terminale avec une charge utile réelle attachée : dans le générateur d'agent IA de Zendesk, "transférer à l'agent" est une étape finale qui crée silencieusement un ticket contenant tout l'historique de la conversation que le client ne voit jamais. eesel fait la même chose en laissant une réponse rédigée et le contexte sous forme de note interne, ou en transférant au helpdesk, selon ta configuration.

Tu veux aussi un contrôle sur ce que le bot est autorisé à toucher. Les équipes réelles le demandent constamment ("il y a certains tickets que je ne veux pas faire passer par l'IA"), et un workflow qui ne peut pas exclure un type de ticket, ou n'agir que lorsqu'il est explicitement invoqué, n'est pas prêt pour une file en production. L'escalade n'est pas un repli ; c'est une branche à part entière. Notre analyse complète des escalades d'agent IA approfondit la mécanique.

Erreurs courantes des workflows de chatbot

Les clients peuvent décrire un workflow cassé mieux que n'importe quelle spécification. Un fil r/automation a cerné les symptômes avec précision :

"the tells: loop you back to FAQ, ask you to rephrase (3 times), refuse to escalate. the fix isn't a smarter chatbot. it's a chatbot that knows when to hand off."

La plupart des workflows cassés échouent selon la même poignée de manières. Surveille ces points :

• Impasses. Le classique basé sur des règles. Chaque chemin devrait mener quelque part, même si ce "quelque part" est un humain. Si une branche peut piéger un client sans issue, c'est un bug.
• Sur-automatisation. Laisser le bot répondre à tout pour poursuivre un chiffre de déviation. C'est ainsi qu'on obtient des réponses erronées données avec assurance, à grande échelle. Limite le bot à ce dont il est sûr.
• Absence de fondement de connaissances. Un workflow avec un excellent arbre de décision mais rien où récupérer des informations va improviser, et des réponses de support improvisées, c'est le chemin vers une capture d'écran sur les réseaux sociaux. Ancre chaque réponse dans de vrais documents et d'anciens tickets.
• Escalade comme réflexion après coup. Transférer vers une file froide où le client réexplique tout. Transporte le contexte avec toi.
• Lancement à l'aveugle. Lâcher un workflow sur de vrais clients sans jamais l'avoir testé sur les messages qu'il recevra réellement. Ce qui nous amène à la dernière étape, et la plus souvent sautée.

Tester le workflow avant sa mise en production

Voici la partie que presque personne ne fait, et la raison pour laquelle je l'intègre à chaque déploiement : faire tourner le workflow sur tes vrais tickets historiques avant qu'il ne parle à un client. Je l'ai appris à mes dépens, en voyant un bot au ton assuré donner tranquillement de mauvaises réponses, donc désormais la première chose que fait tout nouvel agent est une simulation sur d'anciens tickets, pas une conversation en direct.

Une simulation rejoue des milliers de tes tickets clôturés à travers le workflow et te montre exactement ce qu'il aurait dit, quel pourcentage il aurait résolu, et sur quels sujets il est faible, le tout avant la mise en production. Tu trouves les lacunes, ajoutes les documents manquants, ajustes le seuil de confiance, et relances. Cela transforme le "on espère que ça marche" en un chiffre que tu peux pointer du doigt, ce qui fait à peu près la différence entre un workflow en qui tu as confiance et un autre qui te rend nerveux chaque matin.

Le retour d'un workflow testé se manifeste vite. Chez Gridwise, eesel a résolu 73 % des demandes de niveau 1 dès le premier mois, avec des résultats visibles pendant un essai de 7 jours. Smava fait tourner un agent entièrement automatisé sur plus de 100 000 tickets allemands par mois. Aucun de ces chiffres ne vient d'un prompt chanceux ; ils viennent d'un workflow testé sur de vrais tickets avant sa mise en ligne.

Essayer eesel pour ton workflow de chatbot

Si tu as lu jusqu'ici, tu vois le travail qu'exige un workflow de chatbot : cartographier les étapes, ancrer les réponses, ajuster la confiance, concevoir l'escalade, tout tester. eesel fait ce travail à ta place. Tu connectes ton helpdesk et tes documents, il construit le workflow à partir de tes anciens tickets et connaissances dès le premier jour, tu configures quand il intervient et comment il transfère en langage simple, et tu simules le tout sur des tickets historiques avant qu'un seul client ne le voie.

Il se connecte à Zendesk, Freshdesk, Gorgias, Slack, Shopify, Confluence et plus de 100 autres outils, fonctionne dans plus de 80 langues d'entrée de jeu, et est à l'usage à 0,40 $ par ticket sans frais par siège. Ce modèle tend à revenir moins cher que les effectifs une fois qu'on fait le calcul. Tu peux voir un workflow tourner en direct dans ton helpdesk :

Le moyen le plus rapide de voir si un workflow de chatbot convient à ta file est d'en faire tourner un sur tes propres tickets. C'est un essai gratuit, sans carte bancaire, et la simulation te donne ton vrai taux de résolution avant de t'engager sur quoi que ce soit.