Entre un chatbot et un agent, la différence est la conséquence
On présente souvent la différence comme une question de sophistication, l’agent étant le chatbot en plus avancé, et cette présentation fait manquer ce qui compte. Un assistant conversationnel rend des mots. Une personne les lit, les juge, les utilise ou les ignore, et le pire résultat possible est une phrase fausse que quelqu’un aura remarquée. Un agent a déjà agi au moment où on le découvre. Il a envoyé, écrit, modifié, validé. Le pire résultat possible n’est plus une phrase mais un effet, et il n’existe aucune étape où une personne aurait pu l’intercepter. Toutes les conséquences pratiques découlent de là : le circuit d’approbation, la journalisation, l’attribution de la responsabilité et la façon dont les utilisateurs accordent leur confiance changent de nature, pas de degré. Le problème est que ce basculement se produit presque toujours sans décision explicite : on ajoute un outil à un assistant, puis un autre, et l’un d’eux finit par écrire quelque part.
Le basculement se fait sans qu’on le décide
Personne ne tient de réunion pour décider de transformer un assistant en agent. Le chemin est toujours le même et il est raisonnable à chaque étape. L’assistant répond bien, on lui donne accès à la documentation pour qu’il cite ses sources. Cela fonctionne, on lui donne accès aux dossiers clients pour qu’il réponde précisément. Cela fonctionne encore, et quelqu’un demande pourquoi il ne créerait pas directement le ticket.
À cet instant précis, le système a changé de nature, et rien dans l’organisation n’en a pris acte. Le circuit d’approbation est celui d’un outil de réponse. La journalisation conserve les conversations et non les actions. Et la question de savoir qui répond d’une erreur n’a jamais été posée.
La règle pratique est simple à énoncer et suffit à éviter l’essentiel : le premier outil qui écrit quelque part déclenche une revue. Pas une revue lourde, une revue qui pose trois questions, celles qui suivent.
Les trois questions à poser au basculement
Quelles actions sont irréversibles. Envoyer un message à un client, supprimer une donnée, déclencher un paiement, modifier un dossier consulté par d’autres. Ces actions demandent une confirmation humaine ; les autres, non, et exiger une confirmation partout rend le système inutilisable en trois semaines.
Que conserve-t-on. Pour un assistant, on garde ce qui a été dit. Pour un agent, il faut pouvoir reconstituer ce qui a été fait : quelle action, sur quel objet, avec quels droits, sur la base de quelle décision, et à quel moment. Cette trace se conçoit avant la mise en service, parce qu’elle ne se reconstitue pas après un incident.
Qui répond. Question désagréable et incontournable. Si l’agent envoie un message erroné à un client, la responsabilité appartient à l’organisation, et la question interne est de savoir quelle équipe traite l’incident. Sans réponse préalable, l’incident circule pendant deux jours.
La réversibilité plutôt que l’importance
La ligne qui sépare ce qui demande une confirmation de ce qui n’en demande pas passe par la réversibilité et non par l’importance ressentie, et cette distinction est contre-intuitive.
Créer un brouillon de contrat paraît important et se défait en une seconde. Supprimer une pièce jointe paraît anodin et ne se défait pas. L’intuition classe ces deux actions à l’envers, et un circuit d’approbation construit sur l’intuition protège le mauvais endroit.
L’exercice utile consiste à lister les actions disponibles et, pour chacune, à écrire combien de temps il faudrait pour revenir en arrière. Les actions dont la réponse dépasse quelques minutes forment la liste de celles qui demandent une confirmation. Cet exercice prend une demi-heure et remplace des discussions entières.
Ce qui ne change pas entre les deux
Une symétrie mérite d’être notée, parce qu’elle évite de surestimer la différence. La qualité du raisonnement, elle, ne change pas. Un agent n’est pas plus juste qu’un assistant fondé sur le même modèle, avec les mêmes données et les mêmes consignes. Il fait simplement quelque chose de sa réponse.
Il en découle que le jeu d’évaluation reste le même instrument dans les deux cas, et qu’il reste tout aussi indispensable. Une équipe qui passe à l’agent en espérant que la capacité supplémentaire compensera une justesse insuffisante se trompe de levier : elle vient d’augmenter la conséquence de chaque erreur sans en réduire le nombre.
L’ordre défendable est donc de faire fonctionner la version qui suggère, de mesurer sa qualité sur des cas réels, et de ne franchir le pas de l’action que lorsque cette mesure est satisfaisante. L’ordre inverse se rencontre souvent et produit des incidents que personne n’avait anticipés parce que personne n’avait mesuré.
La confiance ne se transfère pas
Un dernier point, souvent découvert trop tard, concerne les utilisateurs plutôt que la technique. Les gens accordent facilement leur attention à un système qui propose, parce qu’ils gardent la décision. Ils accordent beaucoup plus difficilement leur confiance à un système qui décide à leur place, même quand il a raison plus souvent qu’eux.
Ce n’est pas de la résistance au changement, c’est une évaluation correcte du risque : un système qui suggère fait perdre du temps quand il se trompe, un système qui agit crée un problème à réparer. La différence justifie une prudence supérieure.
La conséquence pour la conduite d’un projet est qu’un agent demande davantage de travail d’adoption qu’un assistant, alors même qu’il paraît plus séduisant à présenter. Choisir un agent là où une suggestion aurait suffi revient à acheter le problème d’adoption le plus difficile pour une capacité que personne n’avait réclamée.
