Monter un bot sans écrire une ligne de code est devenu banal. Le difficile n'est pas de le construire, c'est de choisir ce qu'il doit faire et de savoir quand il doit s'arrêter.
Étape 1 : choisir un seul flux, et le plus ennuyeux
La tentation est de traiter d'abord la demande la plus visible. C'est presque toujours une erreur, parce que la demande visible est souvent celle qui exige le plus de jugement.
Le bon premier flux est répétitif, documenté, sans enjeu émotionnel, et mesurable. Le suivi de commande, les horaires d'ouverture, la procédure de retour, la réinitialisation d'un accès. Un flux unique, correctement traité, produit un résultat lisible en deux semaines. Cinq flux traités à moitié ne produisent qu'une impression d'échec.
Écrivez sur une feuille les dix formulations réelles que vos clients emploient pour cette demande. Pas les formulations que vous imaginez : allez les chercher dans vos courriels ou vos conversations passées. Elles serviront de matière au paramétrage et de jeu de test.
Étape 2 : écrire les réponses avant d'ouvrir l'outil
Un éditeur visuel accélère la construction, il n'écrit pas le contenu. Rédigez chaque réponse en texte simple, en respectant trois règles.
Une réponse tient en trois phrases au maximum, parce qu'un mur de texte dans une fenêtre de conversation n'est pas lu. Elle donne l'information, pas le contexte : l'utilisateur veut savoir où est son colis, pas comment fonctionne la logistique. Et elle se termine par une porte de sortie, une question ou une proposition, jamais par un point final qui laisse l'utilisateur devant un vide.
Rédigez aussi les réponses d'échec. Que dit le bot quand il n'a pas compris ? Quand il a compris mais ne peut pas répondre ? Ces deux phrases seront parmi les plus affichées de tout le parcours, et ce sont souvent les seules que personne n'a écrites.
Étape 3 : monter le parcours dans l'outil
Les plateformes visuelles fonctionnent toutes sur le même principe : des blocs reliés par des flèches, un bloc par prise de parole. Trois réglages méritent l'attention, les autres peuvent attendre.
Le point d'entrée : le bot se déclenche-t-il seul, après un délai, ou seulement si l'utilisateur clique ? L'ouverture automatique au bout de trois secondes est la cause la plus fréquente d'agacement. Laissez l'utilisateur ouvrir.
Le nombre d'incompréhensions tolérées : au bout de deux échecs consécutifs, le bot doit proposer autre chose, pas répéter sa question. Ce réglage existe dans tous les outils, il est rarement modifié.
La sortie vers un humain : elle doit être accessible à tout moment, sans avoir à décrire son problème une deuxième fois. Le contexte de la conversation doit suivre.
Étape 4 : dire ce que c'est
Depuis le 2 août 2026, le règlement européen sur l'intelligence artificielle est applicable dans l'ensemble de l'Union. Pour les systèmes conversationnels, il impose une obligation de transparence : la personne doit savoir qu'elle s'adresse à une machine. Les obligations de transparence prévues par le règlement ont fait l'objet de lignes directrices publiées par la Commission européenne le 20 juillet 2026.
En pratique, une phrase d'ouverture explicite suffit, à condition qu'elle soit visible sans défilement et qu'elle ne soit pas contredite par un prénom et une photo d'agent. Nommer son bot n'est pas interdit, le faire passer pour une personne l'est.
Étape 5 : tester avec des gens qui ne l'ont pas construit
Le test par l'équipe projet ne prouve rien : elle connaît les formulations attendues. Prenez cinq personnes qui ne savent rien du bot, donnez-leur un objectif et non une phrase, puis regardez sans intervenir.
Trois signaux annoncent un échec en production. L'utilisateur reformule plus de deux fois : le bot ne couvre pas les vraies formulations. L'utilisateur cherche le bouton pour joindre un humain dans les dix premières secondes : le bot s'est imposé au mauvais moment. L'utilisateur obtient une réponse juste mais reste sur la page sans agir : la réponse était correcte et inutile.
Corrigez, remettez en ligne, et gardez la trace des conversations pendant les premières semaines. Le contenu manquant se révèle dans les échanges ratés, pas dans les réunions.
Ce qu'il ne faut pas automatiser au premier essai
Trois familles de demandes paraissent simples et se révèlent coûteuses.
Les demandes à condition, où la réponse dépend du contrat, du pays ou de l'ancienneté du client. Le bot doit alors interroger un système, et vous quittez le sans-code. Traitez-les à la deuxième étape, une fois l'accès aux données réglé.
Les demandes à enjeu, où une réponse fausse coûte de l'argent ou de la confiance : facturation, résiliation, garantie. Le bot peut y orienter, il ne doit pas y trancher tant que ses réponses n'ont pas été relues sur plusieurs semaines.
Les demandes rares, qui représentent l'essentiel de la richesse d'un service client et une part minuscule du volume. Les automatiser demande autant de travail qu'un flux courant pour un gain dérisoire.
Les quinze premiers jours après la mise en ligne
Le travail utile commence à l'ouverture, pas avant. Trois habitudes en tirent la valeur.
Relire vingt conversations par jour, sans exception, la première semaine. C'est fastidieux et c'est le seul moyen de voir les formulations réelles, qui ne ressemblent jamais aux formulations prévues.
Tenir une liste des questions auxquelles le bot n'a pas su répondre, et la traiter comme une file de travail et non comme un rapport. Chaque entrée traitée est une réponse ajoutée.
Attendre trois semaines avant de juger. Les premiers jours sont pollués par la curiosité interne et par les utilisateurs qui testent les limites. La mesure devient lisible ensuite.
Commentaires
No comments yet