Qu'est-ce qu'un agent IA ?

Définition : qu'est-ce qu'un agent IA ?

Un agent IA (AI agent) est un système logiciel reposant sur un (grand) modèle de langage, qui poursuit de manière autonome un objectif donné : il perçoit son environnement, planifie en plusieurs étapes, choisit et utilise de lui-même des outils externes (tools, API, sources de données), observe les résultats et ajuste son plan de manière itérative jusqu'à ce que l'objectif soit atteint ou que la tâche soit interrompue.

Cette définition correspond aux descriptions de référence des principaux fournisseurs. Anthropic distingue sur le plan architectural les agents (le LLM pilote dynamiquement le parcours et l'utilisation des outils) et les workflows (chemins de code prédéfinis). OpenAI décrit les agents comme des « systems that independently accomplish tasks on behalf of users ». IBM met l'accent sur l'exécution autonome de tâches via la conception de workflows avec des outils, et Microsoft ajoute la dimension de « context awareness ».

Les quatre propriétés indispensables

Un système n'est un véritable agent que s'il remplit les quatre propriétés suivantes. S'il en manque une, il s'agit d'un chatbot, d'un workflow ou d'un assistant :

1. Pilotage par le LLM : c'est le modèle de langage qui prend les décisions de pilotage, et non un code déterministe en tant qu'instance de contrôle principale.
2. Planification en plusieurs étapes : le déroulement suit le schéma Perceive → Reason → Act → Observe, souvent sur plusieurs itérations.
3. Utilisation d'outils : l'agent utilise de lui-même des fonctions externes, des API ou des bases de données.
4. Autonomie orientée objectif : l'agent poursuit un objectif de manière autonome, mais dans le cadre de garde-fous définis.

C'est précisément ce point qui alimente en pratique l'« agent washing » : beaucoup de produits vendus comme « agents » ne sont en réalité que des chatbots avec un seul appel d'outil ou des scripts RPA classiques.

Distinctions : agent vs chatbot vs RPA vs workflow vs assistant

La matrice suivante montre en quoi un agent se distingue des concepts voisins. Chaque colonne décrit le comportement typique ; dans la pratique, les frontières sont floues.

La ligne de partage la plus importante : un workflow ou un bot RPA suit un chemin prédéfini, tandis qu'un agent décide dynamiquement de l'ordre des étapes et du choix des outils. Un chatbot réagit principalement par du texte ; un agent agit en plusieurs étapes et de manière autonome.

Les 5 composants d'un agent IA

Sur le plan technique, un agent se compose de cinq composants principaux qui interagissent :

1. Cœur LLM : le moteur de raisonnement. Il choisit l'étape suivante et pilote le function calling. C'est là que se décide si un outil est utilisé et, le cas échéant, lequel.
2. Mémoire : ce dont l'agent se souvient. La mémoire à court terme correspond au contexte de conversation de l'exécution en cours ; la mémoire à long terme est mise en œuvre via des bases de données vectorielles, le RAG (Retrieval-Augmented Generation) ou des fichiers.
3. Outils : les mains de l'agent. Il s'agit notamment d'appels de fonctions, d'API, de serveurs MCP, de navigateurs ou de sandboxes de code.
4. Planificateur : décompose l'objectif en sous-étapes. La planification peut se dérouler implicitement dans le LLM ou être modélisée explicitement sous forme de graphe.
5. Exécuteur : exécute les appels d'outils, gère chaque tour ainsi que les limites de boucle et fait respecter les garde-fous.

La boucle de raisonnement : Perceive → Reason → Act → Observe

Le cœur de tout agent est un mécanisme de boucle itératif. Sur le plan conceptuel, il remonte au modèle ReAct (Yao et al. 2022), qui associe raisonnement (reasoning) et action (acting) :

1. Perceive : l'agent perçoit l'entrée et l'objectif, le contexte actuel et sa mémoire.
2. Reason : le LLM planifie : quel outil ou quelle étape est pertinent ensuite ?
3. Act : l'agent exécute l'action (appel d'outil, appel d'API, exécution de code).
4. Observe : l'agent lit le résultat et l'enregistre dans sa mémoire.

Ensuite, l'agent vérifie : l'objectif est-il atteint ? Si ce n'est pas le cas, la boucle recommence à Perceive. C'est précisément cette répétition dynamique, et non un déroulement figé dans le code, qui fait la différence avec l'automatisation classique. Des mécanismes de sécurité comme les limites de boucle, les budgets de tokens et les points de contrôle human-in-the-loop évitent les boucles sans fin et les actions erronées irréversibles.

Niveaux de maturité : de L1 à L5

Tous les systèmes automatisés ou basés sur l'IA ne sont pas autonomes au même degré. Un modèle de maturité utile distingue cinq niveaux. Ce n'est qu'à partir de L4 qu'un système remplit les quatre propriétés indispensables de la définition ci-dessus ; les niveaux L1 à L3 sont des stades préliminaires :

• L1 (agent réflexe) : basé sur des règles, sans véritable raisonnement (p. ex. un bot de FAQ).
• L2 (LLM augmenté) : un LLM avec un seul appel d'outil, purement réactif.
• L3 (agent de workflow) : le LLM agit au sein d'un pipeline déterministe (prompt chaining, routage). Le chemin est en grande partie prédéfini.
• L4 (agent autonome) : le LLM pilote dynamiquement l'ordre des étapes et le choix des outils, et parcourt la boucle complète (p. ex. des agents de code comme Claude Code ou des systèmes de deep research).
• L5 (système multi-agents) : plusieurs agents autonomes se coordonnent, par exemple via des protocoles A2A (Agent-to-Agent), avec un orchestrateur et des agents spécialisés.

Pour la plupart des applications B2B en production, le « sweet spot » se situe aujourd'hui entre L3 et L4. Les systèmes L5 sont puissants, mais sujets aux erreurs en cascade : de petites erreurs d'agents individuels qui s'amplifient tout au long de la chaîne.

Panorama des frameworks

Pour la construction d'agents, un écosystème varié et indépendant des éditeurs s'est imposé. La sélection suivante couvre les options les plus courantes :

• LangGraph : approche par graphe ou machine à états, adaptée aux workflows complexes et contrôlés.
• CrewAI : orienté vers les systèmes multi-agents avec des rôles définis.
• OpenAI Agents SDK : minimaliste, avec outils, handoffs, garde-fous et tracing.
• Anthropic Claude Agent SDK : boîte à outils pour construire des agents basés sur les modèles Claude.
• Microsoft Agent Framework : réunit AutoGen et Semantic Kernel, avec une prise en charge native de MCP et A2A.
• n8n : plateforme low-code, particulièrement répandue parmi les PME de la région DACH (Allemagne, Autriche, Suisse).
• Pydantic AI : mise sur la sûreté du typage pour des agents robustes et faciles à tester.

Important : le choix du framework doit intervenir après la clarification du cas d'usage, pas avant.

Les agents IA dans la région DACH : conformité et souveraineté

Si tu déploies des agents en production dans la région DACH, prévois tôt plusieurs cadres réglementaires :

• Règlement européen sur l'IA, art. 50 (transparence) : l'obligation d'information envers les utilisateurs (p. ex. le fait qu'ils interagissent avec un système d'IA) s'applique depuis le 02.08.2026.
• Haut risque (annexe III et annexe I) : avec l'omnibus numérique relatif au règlement sur l'IA (règlement (UE) 2026/1744, en vigueur depuis le 27.07.2026), les obligations applicables aux systèmes à haut risque s'appliquent à partir du 02.12.2027 pour les systèmes relevant de l'annexe III, et à partir du 02.08.2028 pour les systèmes intégrés à des produits réglementés relevant de l'annexe I.
• Règlement européen sur l'IA, art. 4 (maîtrise de l'IA) : les fournisseurs et les déployeurs doivent prendre des mesures pour favoriser la maîtrise de l'IA de leur personnel. L'obligation s'applique depuis le 02.02.2025 ; depuis l'omnibus, l'art. 4 n'exige plus un niveau de compétence déterminé.
• RGPD, art. 22 : en cas de décisions individuelles automatisées, un humain doit pouvoir reprendre la main et annuler la décision.
• RGPD, art. 28 : un contrat de sous-traitance est nécessaire avec les fournisseurs de LLM.
• RGPD, art. 35 : si le traitement est susceptible d'engendrer un risque élevé, par exemple en raison de nouvelles technologies ou d'une évaluation systématique de personnes, une analyse d'impact relative à la protection des données (AIPD) est obligatoire. C'est généralement le cas pour les agents qui traitent des données personnelles.
• Codétermination : en Allemagne, c'est le §87 al. 1 n° 6 du BetrVG qui s'applique ; en Autriche, le §96 de l'ArbVG. Il faut donc associer le comité d'entreprise dès le début.

Pour les organisations qui ont des exigences élevées en matière de souveraineté numérique, il existe des options basées dans l'UE, comme Aleph Alpha Pharia (sur STACKIT), Mistral, IONOS ou OVHcloud.

Erreurs typiques (pitfalls)

Dans la pratique, les projets d'agents échouent rarement à cause de la seule technique. Les pièges les plus fréquents :

• Agent washing : un chatbot ou un bot RPA est vendu comme « agent ».
• Choisir le framework avant d'avoir clarifié le cas d'usage : mène au « pilot purgatory » ; environ deux tiers des pilotes ne passent jamais à l'échelle.
• Préparation des données sous-estimée et AIPD escamotée.
• Codétermination ignorée (BetrVG / ArbVG).
• Explosion des coûts en tokens due à des boucles de raisonnement et d'outils incontrôlées.
• Traiter les agents comme déterministes, alors qu'ils fonctionnent de manière probabiliste.
• Manque d'observabilité et absence de piste d'audit.
• Dépendance à un fournisseur (vendor lock-in) et recours à un « agent » pour une simple recherche d'informations (retrieval), là où un workflow ou un assistant conviendrait mieux.
• Absence de human-in-the-loop pour les actions irréversibles et erreurs en cascade dans les systèmes multi-agents.

Les données du marché montrent que ces risques sont réels : selon Gartner (juin 2025), plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027. Parallèlement, selon Bitkom (2026), 33 % des entreprises font état de coûts plus élevés que prévu.

Quand un agent vaut-il la peine ?

La règle de décision centrale est la suivante : un agent ne vaut la peine que si le chemin vers la solution ne peut pas être planifié à l'avance et qu'une décision du LLM est nécessaire. Si le déroulement peut être entièrement modélisé à l'avance, une automatisation de workflows ou un copilote s'avèrent moins chers, plus rapides et plus robustes.

Voici une approche pragmatique pour démarrer :

• Choisis 1 à 3 cas d'usage avec un ROI clair et mesurable.
• Commence par un pilote à faible risque ou en lecture seule.
• Prévois un human-in-the-loop pour toutes les actions irréversibles.
• Intègre l'AIPD et le comité d'entreprise dès le jour 1.
• Mise sur une stack indépendante des fournisseurs pour éviter le lock-in.

La maturité du marché justifie cette prudence : selon le McKinsey State of AI 2025, seules 23 % des entreprises déploient à grande échelle au moins un cas d'usage agentique, et 39 % de plus sont en phase d'expérimentation, soit 62 % au total. Dans aucune fonction prise isolément, toutefois, la part d'agents déployés à grande échelle ne dépasse 10 %.

Perspectives

L'IA agentique passe rapidement de la phase d'expérimentation à celle de la standardisation. Deux protocoles font progresser l'interopérabilité : le Model Context Protocol (MCP) a été enrichi avec la version de spécification 2025-11-25 et donné en décembre 2025 à la Linux Foundation, plus précisément à l'Agentic AI Foundation ; il compte déjà plus de 10 000 serveurs MCP actifs. Le protocole A2A (Agent-to-Agent) est lui aussi hébergé par la Linux Foundation depuis juin 2025 et soutenu par plus de 150 organisations.

Cette standardisation abaisse les barrières pour les systèmes multi-agents et les architectures indépendantes des fournisseurs. Parallèlement, la maturité réglementaire augmente, en particulier en Europe avec le règlement européen sur l'IA et le RGPD. Pour les décideurs, cela signifie que démarrer dès aujourd'hui avec des pilotes clairement délimités et bien gouvernés pose les bases pour ne pas rester bloqué dans le « pilot purgatory » lors du prochain saut de maturité.