C'est quoi un agent IA ? Chatbot, workflow ou agent
Résumé
Un agent IA reçoit un objectif, choisit ses étapes, appelle des outils et vérifie le résultat avant de s'arrêter. Un chatbot répond, un workflow suit un script fixe, un agent décide à l'exécution. Pour les équipes ops, le risque passe de la réponse fausse à l'action fausse : commence en lecture seule, plafonne les boucles, journalise chaque appel d'outil et garde un humain sur les actions irréversibles.
C'est quoi un agent IA ? C'est un logiciel qui reçoit un objectif, choisit ses propres étapes, utilise des outils pour les exécuter, puis vérifie le résultat avant de s'arrêter. Cette définition suffit. Si un système se contente de répondre à un prompt, c'est un chatbot. S'il suit un script fixe, c'est un workflow. S'il décide de la prochaine action puis l'exécute, c'est un agent. Voici comment les distinguer dans ta stack ops et quand chacun mérite sa place.
C'est quoi un agent IA, en une boucle ?
Briefing 30 secondes. Un agent tourne en boucle : il lit la situation, décide de la prochaine action, appelle un outil, lit le résultat, puis recommence jusqu'à atteindre l'objectif ou une limite.
Le guide de Zapier le décrit comme un logiciel qui agit de façon autonome pour atteindre un objectif. Il capte des informations dans son environnement, décide, puis agit. Pour un agent basé sur un LLM (grand modèle de langage), le modèle prend les décisions et les outils jouent le rôle des mains : recherche web, consultation d'un CRM (gestion de la relation client), écriture dans un fichier, message Slack.
Trois éléments comptent en pratique.
Le modèle. Il lit le contexte et choisit la prochaine étape.
Les outils. Chacun est une capacité étroite avec une entrée et une sortie claires : « cherche ce compte dans le CRM », « crée une issue Linear », « envoie ce brouillon dans ce canal ».
La règle d'arrêt. Une vérification de l'objectif, un plafond d'itérations ou une approbation humaine. Sans règle d'arrêt, pas d'usage en production.
Retire l'un des trois et ce n'est plus un agent. Un modèle sans outils, c'est un chatbot. Des outils sans modèle qui décide, c'est un script. Une boucle sans règle d'arrêt, c'est un incident qui attend ton lundi matin.
Agent, chatbot, workflow : où passe la ligne ?
Beaucoup de confusion vient de vendeurs qui appellent tout « agent ». La découpe la plus nette vient de l'équipe ingénierie d'Anthropic, dans Building effective agents. Les workflows sont des systèmes où les LLM et les outils sont orchestrés par des chemins de code prédéfinis. Les agents sont des systèmes où les LLM dirigent eux-mêmes leurs processus et leur usage des outils.
Traduit pour un responsable ops :
Chatbot. Tu décides de chaque étape suivante. Échec typique : une réponse fausse ou floue. Bon pour la rédaction, les questions-réponses et les résumés.
Workflow. Ton design décide, figé à l'avance. Échec typique : il casse quand la forme de l'entrée change. Bon pour les tâches répétables aux étapes connues.
Agent. Le modèle décide au moment de l'exécution. Échec typique : une mauvaise action dans un système en production. Bon pour les tâches ouvertes dont on ne connaît pas le nombre d'étapes.
Les modes de défaillance sont la partie à relire deux fois. Un chatbot qui se trompe te coûte une minute de relecture. Un agent qui se trompe peut envoyer la mauvaise liste de contacts ou écraser un champ CRM. L'autonomie déplace le risque de la réponse vers l'action.
La plupart des « agents » vendus aux équipes ops en 2026 sont des workflows avec un modèle à l'intérieur d'une ou deux étapes. C'est très bien, et c'est souvent le meilleur produit. Tarife-le et teste-le comme un workflow, pas comme un collègue autonome.
Comment fonctionnent vraiment les agents IA ?
Sans le discours marketing, la boucle d'un agent tient en cinq gestes.
Recevoir l'objectif. « Prépare le brief de renouvellement d'Acme avant le call de jeudi. »
Planifier. Le modèle découpe l'objectif en étapes. Les bons agents replanifient quand une étape échoue.
Agir. Le modèle appelle un outil avec des arguments structurés.
Observer. La sortie de l'outil revient dans le contexte du modèle.
Décider. Objectif atteint, on continue, ou on s'arrête pour demander à un humain.
Les étapes 3 à 5 se répètent. Chaque passage coûte des tokens et du temps. Anthropic le dit clairement : les systèmes agentiques échangent souvent latence et coût contre une meilleure performance. Une requête unique avec le bon contexte répond à beaucoup de questions ops en quelques secondes, pour un coût minime. Un agent prend nettement plus de temps et d'appels d'outils pour arriver au même résultat.
La mémoire mérite une ligne. Un agent garde une mémoire courte dans sa fenêtre de contexte et, dans certains produits, une mémoire longue de faits sur tes comptes ou tes préférences. La mémoire longue est utile, mais c'est aussi là que des faits périmés ou faux s'installent. Relis ce que ton agent retient comme tu relirais un champ CRM : quelqu'un en est responsable, quelqu'un l'audite.
Quels types d'agents existent, et lesquels comptent pour l'ops ?
Les manuels listent les agents réflexes, à modèle, à but, à utilité et apprenants. Ces étiquettes servent aux examens. Pour une équipe ops, trois catégories pratiques couvrent presque tout ce que tu vas acheter ou construire.
Agents LLM qui utilisent des outils. Le modèle appelle des API : CRM, agenda, ticketing, email. C'est le gros des agents ops utiles. Ils sont fiables parce que les actions sont structurées et journalisables.
Agents « computer use ». Le modèle pilote un écran, clique et tape comme une personne le ferait dans l'interface. Utile quand un outil n'a pas d'API. Plus lent et plus fragile, parce qu'un changement de mise en page peut casser une exécution. À garder en dernier recours.
Systèmes multi-agents. Un orchestrateur confie des sous-tâches à des agents spécialisés. Ça impressionne en démo. En production, chaque agent en plus multiplie ta surface de logs et de débogage. Attends qu'un agent unique avec de bons outils ait clairement atteint son plafond.
Que fait un agent IA dans une équipe GTM ou CS ?
Les exemples qui tiennent la route en équipe réelle ont un profil commun : objectif clair, peu d'outils, et un humain qui vérifie la sortie en moins d'une minute.
Recherche de compte avant un call. Récupérer la fiche CRM, les emails récents, l'actualité publique et les tickets ouverts, puis rendre un brief d'une page. Un humain le lit. Rien n'est envoyé.
Tri des leads et des tickets entrants. Lire un nouveau lead ou ticket, le classer, joindre le contexte, le router vers la bonne file. L'agent propose ; une règle décide s'il peut agir seul sur les classes à faible risque.
Suivi de réunion. Transformer une transcription en mises à jour CRM et en brouillon de compte rendu, mis en file pour approbation.
Hygiène des données. Repérer les comptes en double, les champs manquants et les propriétaires périmés, puis ouvrir une tâche par lot.
Remarque ce qui manque : rien qui envoie de l'argent, supprime des enregistrements ou écrit à des clients sans relecture. Ce n'est pas de la frilosité. C'est la différence entre un agent que tu gardes et un agent que tu coupes après une mauvaise semaine.
Le gain de temps dépend de ton volume et de ta base de départ. Chronomètre dix exécutions manuelles, puis dix exécutions assistées par agent, relecture comprise, et compare. Si la relecture mange tout le gain, la tâche n'est pas encore faite pour un agent.
Quand sauter l'agent ?
Anthropic le dit sans détour : trouve la solution la plus simple possible, et n'ajoute de la complexité que si c'est nécessaire. Pour beaucoup de tâches, optimiser des appels LLM simples avec de la récupération de documents et des exemples en contexte suffit.
Saute l'agent quand :
Les étapes sont connues. Si tu peux écrire le process en liste numérotée, construis un workflow. Il coûtera moins cher, ira plus vite et se débogue plus facilement.
La tâche est une transformation unique. Résume ceci, réécris cela, extrais ces champs. Un seul prompt suffit.
Une mauvaise action coûte cher. Changements de facturation, modifications de contrat, emailings de masse. Garde un humain sur le déclencheur.
Tu ne peux pas vérifier la sortie. Si personne ne peut contrôler le résultat vite, tu as créé un problème de confiance, pas un gain de temps.
C'est là que les commandes slash rendent service. Une commande comme /research suivie du nom d'un compte lance le même prompt, avec le même contexte, à chaque fois. Une chaîne de trois commandes, /research puis /summarize puis /draft-email, couvre une bonne part de ce qu'on appelle « agentique », avec un humain qui appuie sur Entrée entre chaque étape. CommanderGPT est construit autour de ce modèle : commandes sauvegardées, un Workflow Builder pour les enchaîner, et des Team Playbooks pour les partager. La limite est réelle. Une chaîne de commandes ne replanifie pas quand l'étape deux renvoie un résultat inattendu. Un agent le peut. Choisis selon la variabilité de tes entrées.
Quels outils donnent aujourd'hui un comportement d'agent ?
Les noms changent chaque trimestre, alors juge sur le motif plutôt que sur le logo. Tu cherches un modèle qui sait appeler des outils, un moyen de voir chaque étape qu'il a faite, et un moyen de l'arrêter.
Claude est le modèle que beaucoup d'équipes placent derrière des agents qui appellent des outils, grâce à un bon suivi des instructions et à un long contexte. Il existe en interface de chat et comme moteur d'agent piloté par API.
ChatGPT reste la référence par son ubiquité. Les GPTs personnalisés et ses outils intégrés couvrent un comportement d'agent léger pour un usage individuel. Le partage à l'échelle d'une équipe de playbooks testés est là où tu sentiras le plus de friction.
Lindy est un builder sans code pour des agents de tâches connectés à l'email, à l'agenda et au CRM. Il convient quand la tâche est claire et que tu veux la mettre en service dans l'après-midi. Lis le journal d'actions avant de lui confier des messages sortants.
Raycast place l'IA derrière une palette de commandes, ce qui convient aux tâches rapides et ponctuelles sur ta propre machine. C'est plus une couche de commandes qu'un agent autonome, et c'est souvent ce qu'un contributeur individuel veut.
Que vérifier avant qu'un agent touche aux données live ?
Passe cette liste avant d'accorder un accès en écriture à un agent. Ça prend trente minutes et ça évite la plupart des mauvaises semaines.
Commence en lecture seule. Laisse l'agent chercher et rédiger pendant deux semaines avant qu'il écrive quoi que ce soit.
Plafonne la boucle. Fixe un nombre maximal d'itérations et un budget maximal par exécution. Anthropic recommande des conditions d'arrêt, par exemple un nombre maximal d'itérations.
Journalise chaque appel d'outil. Il te faut l'entrée, la sortie et l'horodatage. Si un outil ne peut pas être journalisé, ne le donne pas à un agent.
Verrouille l'irréversible. Envois, suppressions, paiements et changements de permissions exigent un clic d'approbation humain.
Teste dans un bac à sable. Utilise une copie du CRM ou un espace de test avec du désordre réaliste.
Suis deux chiffres. À quelle fréquence l'exécution aboutit sans aide, et à quelle fréquence un humain corrige la sortie. Les deux bougeront quand tes données changeront.
Désigne un responsable. Une personne relit les logs chaque semaine. Un agent sans responsable dérive.
Ta prochaine commande
Choisis une tâche que ton équipe répète au moins dix fois par semaine, dont la sortie se contrôle en moins d'une minute. La recherche de compte est le choix habituel. Écris-la d'abord comme commande sauvegardée et fais-la tourner pendant deux semaines. Si les entrées varient tellement que la commande casse sans arrêt, c'est le signe que la tâche est peut-être faite pour un agent. Si elle tourne proprement à chaque fois, tu viens d'économiser une facture d'agent et une habitude de débogage.
Ensuite, décide avec les données de tes propres exécutions. Fork un playbook, chronomètre les runs, lis les logs.