Depuis quelques mois, impossible d’ouvrir LinkedIn sans tomber sur les mots « agent IA », « IA agentique » ou « multi-agents ». Le vocabulaire s’empile plus vite que les cas d’usage réels. Entre le fantasme d’une IA totalement autonome, capable d’enchaîner des tâches complexes sans supervision, et ce qu’on peut réellement construire aujourd’hui, il existe un écart important. Avant de parler de plateformes, de frameworks ou de cas d’usage, il faut donc commencer par clarifier les concepts : qu’est-ce qui distingue réellement un chatbot, un workflow agentique et un agent ?
Chatbots, workflows et agents : ne pas tout mélanger
Depuis novembre 2022 et l’arrivée de ChatGPT, tout le monde a une intuition assez juste de ce qu’est un LLM utilisé en mode conversationnel : on pose une question, on reçoit une réponse en langage naturel, et la boucle s’arrête là. Cette intuition sert malheureusement de base à beaucoup de raccourcis marketing dès que le mot « agent » apparaît.
Un usage « chat » de l’IA, c’est une conversation : vous posez une question ou donnez une instruction, le modèle répond, et c’est vous qui décidez de la suite. Le modèle ne sort jamais de la fenêtre de conversation, il ne vérifie rien, n’exécute rien, ne modifie rien ailleurs. Un Custom GPT chez OpenAI ou un Gem chez Gemini restent dans cette catégorie, même si la présentation commerciale laisse parfois entendre autre chose. Dans les deux cas, on prédéfinit un comportement et une base de connaissance, puis on interroge cette version personnalisée comme on interrogerait le modèle standard. C’est un chatbot mieux briefé, pas un système qui planifie, agit sur des outils externes, et vérifie le résultat de ses propres actions.
Entre ce chat enrichi et l’agent pleinement autonome, il existe une zone intermédiaire qu’on oublie trop souvent : les workflows agentiques. Ce sont des systèmes qui utilisent bien un LLM et des outils, mais où le chemin d’exécution reste défini dans le code plutôt que décidé dynamiquement par le modèle. Un enchaînement de prompts où chaque étape traite le résultat de la précédente, un routage qui dirige une demande vers un traitement spécialisé selon sa nature, ou un orchestrateur qui répartit des sous-tâches entre plusieurs appels : ce sont des systèmes utiles, souvent plus prévisibles et moins coûteux qu’un agent pleinement autonome. En pratique, une bonne partie de ce qu’on déploie aujourd’hui avec succès en entreprise se situe dans cette zone intermédiaire, pas dans l’autonomie totale.
L’agent, enfin, se distingue par une chose précise : le modèle reçoit un objectif, pas seulement une question, et c’est lui qui dirige dynamiquement son propre déroulement. Il a accès à des outils, recherche web, base de données, système de fichiers, terminal, et entre dans une boucle qu’on appelle généralement le « reasoning-action loop » : il observe le contexte, décide d’une action, l’exécute, observe le résultat, puis décide de l’action suivante. Cette boucle continue jusqu’à ce que l’objectif soit atteint, ou jusqu’à ce qu’un point de contrôle humain soit nécessaire.
Claude illustre bien pourquoi cette distinction ne se joue jamais au niveau du modèle. Utilisé dans l’interface de chat classique, Claude fonctionne exactement comme n’importe quel LLM conversationnel : pas d’agent. Mais le même modèle, déployé dans un environnement comme Cursor ou dans Claude Code, l’outil en ligne de commande d’Anthropic pensé pour le développement, devient un véritable agent : accès à un système de fichiers, à un terminal, à l’exécution de code, planification de ses propres actions, exécution, observation du résultat, correction si besoin, sur des dizaines de minutes sans intervention humaine à chaque étape. C’est le même modèle, mais un habillage totalement différent autour. Ce n’est jamais le modèle qui fait la différence, c’est l’architecture qu’on construit autour de lui.
Ce qui transforme un modèle en agent
Au-delà des outils commerciaux, il existe une définition plus rigoureuse, héritée directement de la recherche en intelligence artificielle classique, bien avant l’arrivée des LLM. Dans cette tradition, un agent rationnel est un système qui perçoit son environnement et agit sur cet environnement pour atteindre un objectif, en ajustant son comportement selon ce qu’il perçoit.
Concrètement, un agent repose au minimum sur un modèle qui dirige l’exécution, des outils qui lui permettent d’observer ou de modifier son environnement, et des instructions qui encadrent son comportement. À partir d’un objectif, le modèle choisit une action, utilise un outil, observe le résultat, et décide de la suite. C’est la définition minimale, et elle suffit à qualifier un système d’agent.
Pour les tâches longues ou les usages en production, d’autres briques deviennent rapidement importantes : une gestion explicite de l’état, de la mémoire, et une exécution persistante capable de reprendre après une interruption. Elles ne définissent pas à elles seules ce qu’est un agent, mais elles déterminent souvent s’il peut fonctionner de manière fiable au-delà d’une démonstration. C’est exactement la ligne de démarcation entre un agent qui impressionne en démo et un agent qui tient en production.
Outils, instructions, mémoire et persistance
C’est le sujet le moins visible dans les démonstrations marketing, et pourtant c’est celui qui détermine si un agent tient la route en production ou pas.
La gestion des tâches longues suppose que l’agent puisse décomposer un objectif en étapes, garder une trace explicite de ce qui est fait et de ce qui reste à faire, et savoir s’arrêter pour demander une validation avant une action sensible. Sans cette planification explicite, un agent qui enchaîne des actions sur plusieurs dizaines de minutes finit presque toujours par perdre le fil ou par dériver de l’objectif initial.
La reprise de tâche est encore plus critique en environnement de production : que se passe-t-il si le processus qui fait tourner l’agent crash au milieu d’une tâche de vingt minutes ? Les frameworks sérieux comme LangGraph résolvent ce problème par une exécution « durable », c’est-à-dire que l’état de l’agent est persisté à chaque étape, ce qui permet de reprendre exactement là où l’exécution s’est arrêtée plutôt que de tout relancer depuis le début.
La mémoire, enfin, se décline en plusieurs niveaux qu’on confond souvent. Il y a la mémoire de la conversation en cours, qui tient dans la fenêtre de contexte du modèle. Il y a la mémoire de session, qui permet de reprendre une conversation après une interruption. Et il y a la mémoire long terme, qui permet à un agent de se souvenir de préférences ou de faits au-delà d’une seule session, typiquement stockée dans un système externe et récupérée par recherche sémantique au moment où elle devient pertinente. Chaque plateforme facture d’ailleurs de plus en plus cette brique séparément, parce qu’elle coûte cher en stockage et en calcul, ce qui devrait alerter toute organisation qui budgète un déploiement d’agents sans avoir anticipé ce poste.
Connectors, skills et plugins
Chez Claude, ces briques (outils, mémoire, instructions) prennent une forme concrète à travers trois éléments qu’on confond souvent parce qu’ils se ressemblent en surface.
Les connectors sont les intégrations à des services externes : Google Drive, Slack, Notion, GitHub, un CRM interne. Techniquement, ce sont des serveurs qui parlent le Model Context Protocol, ou MCP, un standard ouvert désormais porté par la Linux Foundation et adopté aussi par OpenAI et Google DeepMind. Le connector, c’est la tuyauterie : il donne à Claude un accès réel à vos données et vos outils.
Les skills sont des instructions réutilisables, écrites dans un format ouvert (SKILL.md), qui expliquent à Claude comment procéder pour un type de tâche précis. Une skill ne connecte rien, elle apprend à Claude un savoir-faire. Le connector donne accès, la skill donne une méthode.
Les plugins, enfin, packagent tout ça ensemble, un ou plusieurs connectors, une ou plusieurs skills, parfois des commandes prêtes à l’emploi, dans un seul module installable. C’est la solution la plus simple pour qui veut un cas d’usage complet sans assembler les briques soi-même.
Plateforme ou framework : commencer simplement
Une fois le cadre posé, la question devient concrète : comment construire, ou choisir, un agent. Deux voies s’ouvrent, plateforme prête à l’emploi ou framework sur mesure, et une règle vaut pour les deux : la complexité ne devrait s’ajouter que si elle apporte un gain démontrable. Beaucoup de cas d’usage se résolvent très bien avec un simple appel direct à l’API du modèle, enrichi de quelques outils, sans plateforme ni framework du tout.
Côté plateformes, trois noms reviennent systématiquement dans le paysage entreprise : Dust, Gemini Enterprise et Amazon Q. Dust construit des agents ancrés dans les données de l’entreprise et connectés via MCP, avec un choix de modèles sous-jacents ; sa limite tient au plafond de connecteurs et de volume de données sur les offres standard. Gemini Enterprise combine une couche packagée par siège et une couche technique facturée à l’usage pour qui veut construire sur mesure ; son bénéfice est l’intégration à l’écosystème Google, sa limite la lisibilité du coût total tant qu’on n’a pas dimensionné l’usage. Amazon Q se décline en un assistant d’entreprise et un agent de développement, tous deux profondément intégrés à AWS ; hors de cet écosystème, l’intérêt s’amenuise nettement. Dans tous les cas, le modèle de prix suit le même schéma : un tarif par siège avec paliers, puis une bascule vers une facturation à l’usage au-delà d’un certain volume, qui peut faire grimper la note si elle n’a pas été anticipée.
Côté frameworks, une hiérarchie se dessine. LangChain reste le plus adopté pour prototyper rapidement, avec un catalogue d’intégrations considérable. Il s’appuie sur LangGraph, la couche d’orchestration bas niveau qui gère l’état, les boucles et l’exécution reprenable. Par-dessus, Deep Agents ajoute une planification explicite, l’agent tient une liste de tâches visible, la délégation à des sous-agents, et la gestion de la mémoire sur des sessions longues. Ces trois briques ne sont pas concurrentes, elles s’empilent : on démarre avec Deep Agents pour aller vite, on redescend vers LangGraph quand on a besoin d’un contrôle plus fin. Mastra occupe une place différente, un framework TypeScript-first qui réunit agents, workflows, mémoire et observabilité dans un même package, pertinent pour les équipes déjà installées sur cette stack.
La question à se poser n’est donc pas « est-ce que c’est un agent ou pas », la réponse est presque toujours oui au sens large, mais avec un degré d’autonomie différent. La vraie question est : est-ce que l’option packagée correspond à mon cas d’usage réel, ou ai-je besoin de descendre au niveau du framework pour construire du sur mesure.
Tester avant d’accorder de l’autonomie
Que vous choisissiez une plateforme packagée ou que vous construisiez sur un framework, un principe reste non négociable, et c’est celui sur lequel j’insiste le plus auprès de mes équipes, parce que c’est celui qu’on saute le plus facilement quand on est pressé de montrer un résultat. Utiliser une skill Claude bien écrite ou brancher un agent packagé donne un résultat qui a l’air convaincant en démonstration. Mais un résultat convaincant en démonstration n’est pas un résultat fiable en production.
La différence se joue sur trois plans. D’abord, le choix du modèle sous-jacent : deux modèles de la même génération peuvent avoir des comportements très différents sur des tâches agentiques, notamment sur leur capacité à suivre des instructions sur de longues séquences d’actions sans dériver. Ensuite, le benchmark sur des cas réels et représentatifs de votre contexte, pas sur des cas génériques publiés par le fournisseur. Enfin, la vérification systématique de la réponse, qu’on appelle evals dans l’écosystème : une grille de critères objectifs, humains ou automatisés, pour juger si la sortie de l’agent est correcte, avant de la laisser agir sans supervision sur un cas similaire.
C’est exactement la différence entre brancher un agent en confiance aveugle, et le faire en ingénieur : on mesure, on compare, on documente les limites, et seulement après on élargit le périmètre d’autonomie qu’on lui accorde.
Ce qui a réellement basculé avec l’arrivée des agents, ce n’est pas la capacité brute des modèles, c’est le périmètre de ce qu’on peut leur déléguer sans supervision constante. La question qui compte, pour un tech leader, n’est donc plus « est-ce que l’IA peut m’aider », elle est devenue « à quel endroit précis de mon architecture je délègue de l’autonomie, avec quel niveau de supervision, et avec quelles preuves que ça fonctionne de façon fiable ». C’est ce travail de cadrage, plus que la démonstration technique elle-même, qui fait la différence entre un pilote qui reste un pilote et un système qui tient dans le temps.
Pour aller plus loin
Cet article s’appuie notamment sur les définitions et cadres suivants, si vous voulez creuser par vous-même :
- Anthropic, Building Effective Agents — la distinction entre workflows (chemins de code prédéfinis) et agents (LLM qui dirige dynamiquement son propre processus), décembre 2024.
- OpenAI, A Practical Guide to Building Agents — guide opérationnel pour les équipes produit et engineering : définition, quand construire un agent, composants de design, patterns d’orchestration et garde-fous.
- Google, Agents (whitepaper Kaggle) — par Julia Wiesinger, Patrick Marlow et Vladimir Vuskovic, publié dans le cadre du 5-Day Gen AI Intensive.
- MIT Sloan Management Review, What is agentic AI? — synthèse accessible, avec référence à l’étude MIT Sloan / BCG sur l’adoption de l’IA agentique en entreprise.
- Aldridge et al., Agentic Artificial Intelligence in Finance: A Comprehensive Survey — spécifique à la finance, mais la partie définitionnelle en début de papier est généraliste et bien sourcée académiquement.