Un chatbot abandonné au bout de six mois a rarement mal fonctionné. Il a bien fonctionné sur un périmètre que personne n'avait choisi, avec des moyens que personne n'avait prévus.
Faux départ 1 : commencer sans propriétaire
Un chatbot appartient à quelqu'un ou il n'appartient à personne. Sans un responsable identifié, disposant de temps déclaré et pas seulement de bonne volonté, la maintenance s'arrête au bout de quelques semaines.
Le symptôme est reconnaissable : le bot fonctionne bien au lancement, se dégrade lentement, et personne ne sait dire quand la dernière correction a été faite. Le propriétaire n'a pas besoin d'être technique, il doit avoir la légitimité pour arbitrer ce que le bot dit.
Faux départ 2 : viser la couverture totale
Un périmètre ambitieux paraît plus rentable. Il produit un bot moyen sur tout, donc mauvais partout.
La couverture large disperse l'effort de contenu, multiplie les cas d'échec, et rend la mesure illisible : on ne sait plus si le problème vient du paramétrage, du contenu ou du choix des flux. Un flux unique bien traité produit un résultat mesurable et un argument pour la suite.
Faux départ 3 : partir d'une documentation qui n'existe pas
Un bot ne peut répondre que sur ce qui est écrit. Une entreprise dont les procédures vivent dans la mémoire de quelques personnes découvre ce manque au milieu du projet, au moment le plus coûteux.
Le test préalable tient en une question : pourriez-vous confier ce flux à un nouvel arrivant en lui donnant seulement des documents ? Si la réponse est non, le projet commence par un travail de rédaction, et il vaut mieux le savoir avant de signer une licence.
Faux départ 4 : ne pas prévenir les équipes
Un bot déployé sans préparation du service client produit une réaction prévisible : les agents le perçoivent comme une menace, ne le corrigent pas, et le contournent en invitant les clients à les contacter directement.
Les équipes support détiennent la matière première du projet, à savoir la connaissance des demandes réelles. Les associer tôt n'est pas une précaution sociale, c'est la condition d'un bon paramétrage.
Faux départ 5 : lancer sans jeu de test
Le test par l'équipe projet ne prouve rien : elle connaît les formulations attendues. Il faut un jeu de questions réelles, prises dans les conversations passées, et le rejouer après chaque modification.
Sans ce jeu, chaque correction risque d'en casser une autre, et personne ne s'en aperçoit avant les réclamations. Cinquante questions suffisent pour démarrer.
Faux départ 6 : ouvrir à tout le monde d'un coup
Une ouverture progressive donne le temps de découvrir les formulations réelles avec un volume gérable.
Commencer sur une seule page, un seul segment de clientèle ou une seule tranche horaire permet de corriger sans exposer l'ensemble des utilisateurs aux défauts de jeunesse. L'ouverture complète intervient quand le taux d'incompréhension s'est stabilisé, pas à une date fixée d'avance.
Faux départ 7 : ne rien mesurer avant
Sans point de comparaison, le débat sur l'utilité du bot devient une affaire d'opinion, et l'opinion la plus forte l'emporte.
Relevez avant l'ouverture le volume par flux, le temps de traitement et le délai de première réponse. Ces trois chiffres, pris sur quatre semaines complètes, transforment une discussion en constat.
Le signe qu'un projet est bien parti
Il tient en une phrase : quelqu'un peut dire, sans hésiter, quelle demande précise le bot doit traiter, où se trouve la réponse, qui la corrigera quand elle changera, et à quel chiffre on saura que cela a fonctionné.
Un projet qui ne sait pas répondre aux quatre questions n'est pas encore un projet. C'est une intention, et elle mérite deux semaines de cadrage avant le premier devis.
Le huitième faux départ : oublier la conformité jusqu'à la veille
Il mérite d'être cité à part, parce qu'il se découvre toujours au pire moment, quand tout le reste est prêt.
Trois questions doivent être tranchées avant l'ouverture et non après. Sur quelle base juridique les conversations sont-elles traitées ? Combien de temps sont-elles conservées, et la suppression fonctionne-t-elle réellement ? Les personnes sont-elles informées de la nature automatisée de leur interlocuteur, comme le prévoit le règlement européen sur l'intelligence artificielle applicable depuis le 2 août 2026 ?
La Commission nationale de l'informatique et des libertés publie des fiches pratiques consacrées à l'application du règlement général sur la protection des données au développement des systèmes d'intelligence artificielle, notamment sur la définition de la finalité et le choix de la base légale.
Ces questions prennent quelques heures quand elles sont posées au cadrage, et plusieurs semaines quand elles sont posées la veille de l'ouverture.
Reconnaître un projet qui dérive
Quatre signaux apparaissent avant l'échec, et chacun laisse le temps de corriger.
Le périmètre s'élargit sans que la date bouge. C'est le signal le plus précoce et le plus ignoré.
Les réunions portent sur la plateforme plutôt que sur les réponses. Quand la discussion technique domine la discussion de contenu, le contenu manque.
Personne ne sait dire combien de demandes le flux visé représente réellement. Le chiffre n'a jamais été mesuré, et le projet repose sur une impression.
La date de mise en ligne est fixée avant que le jeu de test existe. Le test devient alors une formalité, et les défauts se découvrent en production.
Reprendre un projet arrêté
Un bot abandonné se reprend, et souvent mieux qu'un projet neuf : les conversations passées constituent le meilleur jeu de test qui soit.
Commencez par lire deux cents conversations réelles, classées en trois piles : le bot a bien répondu, il a mal répondu, il n'a pas compris. La troisième pile donne le contenu manquant, la deuxième donne les corrections prioritaires, la première donne le périmètre à conserver.
Cette lecture prend une journée et remplace avantageusement un audit.
Commentaires
No comments yet