Un robot conversationnel lit. Il va chercher une réponse — dans un script, une base de connaissances, une série de réponses toutes faites — et vous la renvoie. Un agent IA lit et écrit : il peut mettre à jour une fiche, faire passer un billet au statut suivant, réserver un créneau dans un calendrier, envoyer un courriel de confirmation, puis vivre avec les conséquences de ce changement. C’est cette limite-là qui sépare vraiment les deux. Pas le vocabulaire. Pas la sophistication du modèle derrière. L’accès en écriture, et qui en répond.
Les fournisseurs le décrivent de la même façon une fois le marketing enlevé. Anthropic appelle cette distinction *workflows vs. agents* (flux de travail contre agents) : dans un flux de travail, « LLMs and tools are orchestrated through predefined code paths » (les modèles et les outils sont orchestrés selon des chemins de code prédéfinis), tandis que les agents sont des « systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks » (des systèmes où le modèle dirige lui-même son processus et l’usage des outils, en gardant le contrôle sur la façon d’accomplir la tâche). Microsoft trace la même frontière en langage grand public : le robot conversationnel utilise des « rule-based or scripted responses » (réponses scriptées, basées sur des règles), tandis qu’un agent IA est « autonomous, goal-driven, and capable of reasoning » (autonome, orienté vers un objectif, capable de raisonnement). Les deux descriptions pointent vers le même fait : un agent décide de la suite et agit selon cette décision. Un robot conversationnel ne décide rien — il ne fait que répondre. Si vous essayez encore de déterminer lequel il vous faut, commencez par comprendre ce que fait vraiment un robot conversationnel — la plupart des PME qui se demandent « ai-je besoin d’un agent IA » ont en fait besoin d’un robot conversationnel.
Pourquoi l’industrie vous vend l’« agent » de toute façon
Chaque définition que vous trouverez dans les résultats de recherche a été écrite par une entreprise qui vend un agent. Zendesk, Salesforce, Microsoft — le mot « agent » figure dans le nom même de leurs produits, alors forcément, chacune de leurs pages de glossaire vous pousse vers « vous avez besoin d’un agent ». Aucune ne mentionne ce qui devrait vous inquiéter bien plus que le choix des mots : un agent qui écrit dans vos systèmes peut aussi y écrire la mauvaise chose, à la vitesse d’une machine, sans demander la permission d’abord.
Ce qui doit déjà être vrai avant de laisser un logiciel écrire
Avant que l’« agent » ait du sens pour votre entreprise, trois choses doivent déjà être vraies — non pas construites par l’agent, mais vraies avant même son arrivée.
- Il existe un système où réside la vérité. Pas la mémoire d’une personne, pas un post-it, pas une feuille de calcul que trois personnes modifient chacune à sa façon. Un agent ne peut agir que sur ce qu’il peut lire de façon fiable, et il ne peut écrire que dans un endroit qui a des champs, pas dans un savoir informel qui circule dans l’équipe. Bien des PME roulent entièrement sur la mémoire du propriétaire et une boîte courriel partagée — ce n’est pas encore un système, c’est une habitude, et il n’y a rien là où un agent pourrait se brancher.
- Ce système doit accorder l’accès en écriture. L’accès en lecture est facile à donner ; presque tous les outils ont une API pour extraire des données. L’accès en écriture est une tout autre décision — cela veut dire que l’agent peut modifier une fiche client, fermer un dossier, ou envoyer un message en votre nom sans qu’une personne clique sur « envoyer ». La plupart des entreprises qui croient vouloir un agent n’ont pas vraiment décidé qu’elles étaient à l’aise avec ça.
- Quelqu’un doit assumer ce qui se passe quand l’écriture est fautive. Pas le fournisseur. Vous. Si l’agent réserve le mauvais créneau, met à jour le mauvais statut ou annonce le mauvais prix à un client, quelqu’un dans votre équipe doit corriger le tir — et cette personne doit savoir que c’est arrivé. Le pire échec d’un robot conversationnel, c’est une mauvaise réponse qu’on peut corriger dans la même conversation. Le pire échec d’un agent a déjà modifié une fiche avant que quiconque s’en aperçoive.
S’il manque une seule de ces trois conditions, l’« agent » est le mauvais outil — non pas parce que la technologie n’en est pas capable, mais parce qu’il n’y a encore rien sur quoi elle peut agir en toute sécurité. C’est généralement là qu’un robot conversationnel bien conçu, ou une automatisation plus simple basée sur des règles, fait mieux le travail et coûte moins cher en cas d’erreur.
Même les fournisseurs qui bâtissent des agents disent la même chose
Ce n’est pas nous qui sommes prudents envers une technologie qu’on ne vend pas — ce sont les entreprises qui bâtissent les cadres d’agents elles-mêmes. Le guide technique d’Anthropic nomme directement le mode d’échec : les agents apportent « higher costs, and the potential for compounding errors » (des coûts plus élevés et un risque d’erreurs qui s’accumulent), et exigent « extensive testing in sandboxed environments, along with the appropriate guardrails » (des tests poussés en environnement isolé, avec les garde-fous appropriés) avant qu’on leur confie quoi que ce soit d’important. Sa recommandation de base : « find the simplest solution possible, and only increasing complexity when needed » (trouver la solution la plus simple possible, et n’ajouter de la complexité que si nécessaire) — autrement dit, ne pas se tourner vers un agent quand un flux de travail scripté fait le travail.
Le guide d’OpenAI pour les équipes qui bâtissent des agents fait valoir un point semblable sans le dire aussi carrément : un agent devrait pouvoir arrêter ce qu’il fait et redonner le contrôle à une personne dès que quelque chose tourne mal, en restant à l’intérieur de garde-fous définis à l’avance plutôt qu’en improvisant au-delà. Lu franchement, c’est une exigence, pas un luxe — un logiciel qui peut agir seul doit avoir une sortie de secours intégrée, parce que « continuer et espérer que ça marche » cesse d’être une option dès qu’il peut écrire.
À quoi ça ressemble en pratique
Un endroit où l’on a vu cette limite tenir, c’est le suivi de chantiers pour un entrepreneur. Chaque demande qui arrive par courriel contient l’adresse d’un chantier. Cette adresse n’est pas tapée à la main dans une feuille de calcul — elle est lue automatiquement dans la boîte de réception, et une carte pour ce chantier apparaît dans le pipeline. À partir de là, c’est encore une personne qui déplace la carte d’un statut à l’autre ; la vue carte se contente de suivre le statut où se trouve déjà la carte, pour que l’équipe voie où sont réellement les chantiers du jour sans que personne ait à mettre à jour deux systèmes à la main. Lire une adresse dans un courriel et l’épingler sur une carte, c’est un travail à la mesure d’un agent — étroit, et bon marché à vérifier quand ça se trompe. Décider quel chantier reçoit l’équipe aujourd’hui, ça, c’est resté la décision d’une personne. Ce n’est pas une limite dont on s’excuse — c’est la frontière tracée par les trois questions plus haut, appliquée à un flux de travail au lieu d’en discuter dans l’abstrait.
En savoir plus sur le fonctionnement de ce suivi par carte.
Par où commencer
Si vous n’avez pas encore de système où réside la vérité de votre entreprise, c’est ça, le vrai projet — pas « aller chercher un agent ». Un robot conversationnel qui répond à partir de ce que vous avez déjà vous dira bien plus vite si l’accès en écriture vaut même la peine d’être visé, et ça coûte une fraction de ce que coûte à défaire une erreur à la mesure d’un agent. Nous avons détaillé ce que coûte réellement un robot conversationnel une fois qu’on dépasse les chiffres « à partir de » que publient les fournisseurs.
Vous ne savez pas trop de quel côté de cette limite se trouve votre entreprise ? Parlez-nous — c’est une conversation rapide, pas un argumentaire de vente.
