Agentic AI : au-delà du chatbot, l’IA autonome

Un modèle de langage auquel on demande de résumer un document se contente de répondre. Si on lui confie en revanche l’objectif « trouve les meilleurs fournisseurs pour ce cahier des charges, compare leurs offres, rédige une recommandation », il faudrait qu’il cherche, lise, compare, argumente et livre un résultat final sans qu’on le guide étape par étape. C’est exactement le saut que franchit l’agentic AI : une architecture dans laquelle l’IA ne se contente plus de répondre, elle planifie, agit et s’adapte de manière autonome.

Architecture d’un agent IA : du perroquet statistique au moteur cognitif

Les architectures de type transformeur, à la base des grands modèles de langage, ont été conçues pour traiter des séquences de données, principalement du langage. Les premières générations (GPT-2, par exemple) produisaient du texte impressionnant de fluidité, mais leur comportement restait fondamentalement passif : elles prédisaient le mot suivant sans véritable compréhension, sans mémoire et sans orientation vers un objectif ^[1].

C’est le passage à l’échelle, c’est-à-dire l’entraînement sur des volumes massifs de données avec des architectures de plus en plus paramétriques, qui a tout changé. Ce scaling a débloqué chez les modèles de langage des capacités qui n’existaient pas auparavant ^[1] :

• le raisonnement multi-étapes (décomposer un problème complexe en sous-problèmes gérables) ;
• l’usage d’outils (appeler des API, interroger des bases de données, effectuer des recherches web) ;
• la mémoire (retenir le contexte d’une session, voire de sessions antérieures) ;
• la généralisation (s’adapter à des instructions et des utilisateurs variés).

Aucune de ces propriétés n’existait dans les petits modèles passifs. Il a fallu un effort de scaling délibéré et coûteux pour transformer les modèles de langage de simples reconnaisseurs de motifs en quelque chose qui s’apparente à des moteurs cognitifs ^[1]. Et c’est précisément cette transformation qui les rend suffisamment puissants pour servir de fondation à des systèmes autonomes orientés vers des objectifs.

Le calendrier des avancées le confirme. En 2022, le Chain-of-Thought prompting (inciter le modèle à « penser à voix haute ») a ouvert la voie au raisonnement structuré. En 2023, le projet Toolformer de Meta AI a montré qu’un modèle pouvait apprendre, de façon autonome, quand et comment utiliser des outils ^[1]. La même année ont émergé les premiers frameworks d’orchestration, LlamaIndex, LangGraph, CrewAI, qui organisent la planification, l’exécution, la réflexion et la mémoire : autant de marqueurs distinctifs de l’agentic AI ^[1].

Le passage du transformeur au moteur cognitif n’est pas un glissement marketing : c’est un changement de nature, rendu possible par des avancées concrètes en scaling, en entraînement et en architecture.

Anatomie d’un agent : trois organes, une unité déployable

Un agent n’est pas un chatbot amélioré. C’est un système qui combine trois éléments fonctionnels distincts ^[2] :

1. Le LLM, ou « cerveau » : le modèle de langage qui interprète les requêtes, raisonne, planifie et génère des décisions.
2. La boîte à outils, ou « membres » : l’ensemble des capacités d’action sur le monde extérieur, appels d’API, requêtes en base de données, recherche web, calculs, interactions avec des fichiers.
3. Le cadre d’exécution : la logique qui orchestre le tout, décomposant les tâches en étapes, gérant l’ordre d’appel des outils, supervisant les résultats et décidant de la suite.

Ensemble, ces trois organes forment une unité déployable. L’agent est empaqueté comme un composant autonome, regroupant son modèle, ses outils et sa logique d’exécution. Cet empaquetage permet de le déployer, le mettre à l’échelle et le mettre à jour indépendamment ^[2].

Le framework CrewAI illustre concrètement cette architecture. Il organise les systèmes agentic autour de quatre concepts fondamentaux ^[1] :

Concept	Rôle	Analogie technique
Agent	Unité autonome dotée d’un rôle, d’un objectif et d’une personnalité	Un microservice avec sa fiche de poste
Task	Contrat d’entrée et de sortie pour une unité de travail	Un contrat d’API
Tool	Capacité externe accessible à l’agent (API, BDD, calcul)	Une intégration externe
Crew	Orchestrateur qui coordonne agents et tâches	Un gestionnaire de services

Ce qui surprend souvent les nouveaux venus, c’est le rôle du backstory (contexte narratif) d’un agent CrewAI. Ce n’est pas du texte décoratif : il influence réellement le comportement. Un agent configuré comme un « chercheur médical prudent » va nuancer ses réponses et émettre des réserves, tandis qu’un « analyste de marché agressif » prendra des positions plus tranchées, même face à la même tâche ^[1].

L’essentiel à retenir : un agent agentic n’est pas un prompt sophistiqué, c’est un système logiciel à part entière, avec une architecture modulaire et des interfaces claires entre ses composants.

La boucle perception-action : le vrai moteur sous le capot

Ce qui distingue fondamentalement un agent d’une simple requête-réponse, c’est la boucle perception-action (perception-action loop). Ce cycle continu forme la colonne vertébrale de l’autonomie ^[1].

Concrètement, le fonctionnement est le suivant :

1. Percevoir : le système reçoit des informations de son environnement (entrées utilisateur, données d’API, résultats d’outils, contenu de documents).
2. Interpréter : le LLM analyse la situation, identifie ce qui est pertinent et détermine ce qu’il faut faire.
3. Décider et planifier : le cadre d’exécution décompose l’objectif en actions concrètes, dans un ordre logique.
4. Agir : les outils sont appelés, les calculs effectués, les requêtes envoyées.
5. Évaluer : le résultat de l’action est analysé, comparé à l’objectif. Si nécessaire, le plan est ajusté et la boucle recommence.

En robotique, cette boucle implique des capteurs visuels, sonores et tactiles. Dans les agents logiciels, elle passe par l’analyse de documents, l’invocation d’outils et l’interprétation des entrées utilisateur ^[1]. La différence avec un script classique, c’est que l’agent ne suit pas un chemin prédéterminé : il observe le résultat de chaque action et décide dynamiquement de la suivante.

La mémoire est ce qui donne à cette boucle sa puissance. Sans mémoire, un agent repart de zéro à chaque interaction. Avec elle, il accumule du contexte, apprend de ses erreurs et affine son raisonnement au fil du temps.

Deux types de mémoire coexistent ^[3] :

• Mémoire à court terme : le contexte de la conversation en cours, les résultats intermédiaires des actions, le plan d’exécution actuel. L’équivalent d’un bloc-notes de travail.
• Mémoire à long terme : les informations persistantes entre les sessions, les préférences utilisateur, les connaissances acquises lors d’interactions passées, les patterns récurrents.

Le système MemOS pousse cette logique plus loin en traitant la mémoire comme une ressource planifiable au même titre que le calcul ou le stockage. Dans cette approche, la mémoire n’est pas un simple réceptacle de données, mais le substrat continu de la perception, de la compréhension et de l’action du modèle ^[3]. Elle est recomposable, migrable, et soumise à des mécanismes de contrôle d’accès et de traçabilité.

Pour un praticien, l’enseignement est clair : la qualité de la mémoire (ce qu’on y stocke, comment on l’indexe, quand on la purge) détermine directement la fiabilité de l’agent. Un agent avec une mémoire mal gérée finira par accumuler du bruit, voire par être manipulé, ce que nous aborderons dans la section sur les risques.

L’échelle d’autonomie : du script à l’agent pleinement autonome

L’erreur la plus courante quand on découvre l’agentic AI est de penser qu’il faut toujours viser le niveau d’autonomie maximal. En réalité, le bon niveau dépend de deux axes : la complexité de la tâche et le degré de contrôle qu’on peut déléguer sans risque ^[1].

Le spectre complet se décompose en cinq niveaux ^[1] :

Niveau	Nom	Fonctionnement	Exemple concret
1	Scripts / RPA	Règles fixes, aucune capacité de raisonnement	Extraction automatisée de factures PDF
2	Copilotes	Le LLM suggère, l’humain valide et exécute	Assistance à la rédaction de code
3	Agents augmentés par outils	Le LLM sélectionne et appelle des outils dans un cadre borné	Recherche web puis synthèse de résultats
4	Orchestration multi-agents	Plusieurs agents spécialisés coordonnés par des politiques	CrewAI avec planificateur, exécuteur, évaluateur
5	Autonomie complète	Domaines restreints avec garde-fous forts, intervention humaine minimale	Trading haute fréquence, triage d’incidents réseau

La règle pratique est la suivante ^[1] :

• Complexité faible, contrôle faible : restez sur des scripts ou des workflows déterministes, simples et fiables.
• Complexité croissante : ne sautez pas directement à l’autonomie, construisez d’abord des copilotes qui assistent tout en gardant un humain dans la boucle.
• Besoin d’outils structurés : passez à des agents augmentés par des outils, avec des vérifications de sécurité intégrées.
• Tâches multifactorielles et complexes : pensez en termes d’orchestration multi-agents, un système d’agents spécialisés coordonnés par des politiques.
• Domaine borné et bien compris, avec garde-fous robustes : seul dans ce cas, l’autonomie complète est envisageable.

Penser en termes de spectre plutôt qu’en termes de tout-ou-rien permet de calibrer la solution au bon niveau de risque et de coût. Une usine de fabrication, par exemple, ne déléguera pas la supervision qualité à un système de niveau 5 sans preuves solides de fiabilité, mais elle peut d’ores et déjà bénéficier d’agents de niveau 3 pour la maintenance prédictive ^[4].

Multi-agents : quand on passe d’un soliste à un orchestre

Au-delà du niveau 3, les tâches deviennent trop complexes pour un agent isolé. C’est là qu’entre en jeu l’orchestration multi-agents : un système où des agents spécialisés collaborent, chacun apportant une compétence distincte à un objectif commun ^[1].

Les frameworks d’orchestration

Le framework CrewAI organise cette collaboration autour de ses quatre concepts (Agents, Tasks, Tools, Crews), mais c’est au niveau du Crew que la coordination s’opère. Le Crew est l’orchestrateur : il définit la stratégie de coordination, décide de l’ordre d’exécution des tâches et gère les dépendances entre agents ^[1].

D’autres frameworks proposent des mécanismes d’orchestration différents. OpenAI Swarm introduit le concept de Routines & Handoffs : des séquences d’actions prédéfinies (routines) et des mécanismes de passation de relais (handoffs) permettant à un agent de transférer le contrôle à un autre agent spécialisé, de façon fluide et légère ^[5]. Ce framework est conçu pour la scalabilité et convient bien aux applications où les agents ont des rôles clairement définis. Sa limite : il se concentre sur des protocoles de type rôle centralisé ou décentralisé et n’est pas encore considéré comme prêt pour la production ^[5].

Le projet AgentCoord va plus loin dans la formalisation en proposant une représentation structurée des stratégies de coordination ^[5]. En trois étapes, il transforme un objectif général en stratégies exécutables, réduisant les interactions répétitives entre agents. Sa limite actuelle : il ne fonctionne qu’en environnement texte pur et ne supporte que des stratégies de coordination statiques ^[5].

Le protocole MCP (Model Context Protocol) étend les primitives de base des modèles de langage avec des capacités spécifiques à la coordination multi-agents : des primitives étendues et des patterns de coordination standardisés, réduisant la complexité d’implémentation tout en améliorant la fiabilité ^[6].

Des résultats concrets

Les systèmes multi-agents ne sont plus théoriques. Le framework SwarmAgentic intègre l’intelligence d’essaim (inspirée du comportement collectif des insectes sociaux) à la génération automatisée de systèmes agentic. À partir d’une simple description de tâche et d’une fonction objectif, il génère automatiquement la topologie du système multi-agents. Sur le benchmark TravelPlanner, SwarmAgentic obtient un gain relatif de 261,8 % par rapport au système ADAS, et surpasse tous les systèmes de référence sur la planification de voyages, la planification de réunions, la gestion d’agenda, l’écriture créative et le benchmark MGSM ^[7].

Applications en conditions réelles

Dans le domaine de la cybersécurité, des agents autonomes sont déployés pour l’automatisation des centres opérationnels de sécurité (SOC), la détection d’anomalies en continu, la gestion des vulnérabilités et la détection des menaces internes ^[8]. Côté offensif, des systèmes multi-agents participent aux simulations rouge-bleu, aux tests de pénétration autonomes et aux challenges Capture The Flag (CTF), soulevant des questions de double usage sur lesquelles la gouvernance doit se prononcer ^[8].

Dans la fabrication, Gartner prévoit que d’ici 2030, des agents semi-autonomes orchestreront 10 % des opérations clés de production (qualité et maintenance), soit une multiplication par cinq par rapport au chiffre actuel de 2 %, avec les plateformes d’IA en périphérie (edge AI) et les modèles préentraînés comme principaux accélérateurs d’infrastructure ^[4].

Principes de conception : ce qui tient en production et ce qui casse

Construire un agent qui fonctionne en démo est relativement simple. Le faire tenir en production, sous charge, face à des cas imprévus, sur la durée, c’est un défi d’ingénierie différent. Cinq piliers structurent les systèmes agentic qui survivent au contact du réel ^[9].

Scalabilité

L’agent doit pouvoir gérer des charges croissantes et des tâches diversifiées. Cela passe par des architectures distribuées, de l’infrastructure cloud et des algorithmes efficaces supportant le traitement parallèle ^[9]. L’exemple parlant : un agent de support client qui traite 10 tickets par minute peut s’effondrer ou se bloquer si le trafic passe à 1 000, à moins d’être soutenu par une infrastructure d’auto-scaling ^[9].

Modularité

Chaque composant de l’agent (module de raisonnement, connecteur d’outil, gestionnaire de mémoire) doit être indépendant et interchangeable, relié aux autres par des interfaces claires ^[9]. Si la mise à jour d’un outil casse l’ensemble du système, l’architecture n’est pas modulaire.

Apprentissage continu

Le système doit s’améliorer au fil du temps grâce au feedback, à la collecte de données d’interaction et à la réévaluation périodique des politiques de décision ^[9]. Un agent figé dans sa configuration initiale devient rapidement obsolète.

Résilience

Les pannes et les imprévus ne sont pas des exceptions, ils sont la norme. L’agent doit tolérer les erreurs de ses outils, les réponses inattendues de ses partenaires et les pertes temporaires de connectivité ^[9].

Future-proofing

La technologie évolue vite. L’agent doit être conçu pour intégrer de nouveaux modèles, de nouveaux outils et de nouveaux protocoles sans remise en cause complète de l’architecture ^[9].

L’évolution vers l’AgentOps

En pratique, ces principes appellent une évolution des pratiques opérationnelles. Les équipes qui géraient hier des pipelines DevOps (intégration et déploiement continus), puis MLOps (gestion des modèles et des données) et FMOps (fine-tuning des fondations de modèles), doivent désormais intégrer l’AgentOps : l’orchestration de prompts et la coordination multi-agents ^[10]. C’est un changement de paradigme opérationnel autant que technique, car les agents ne sont pas des modèles à déployer, mais des systèmes à coordonner.

Couche	Responsabilité	Exemple
DevOps	CI/CD, infrastructure	Pipelines de déploiement
MLOps	Données, entraînement de modèles	Pipelines de données, versioning de modèles
FMOps	Fine-tuning de fondations de modèles	Adaptation de LLMs à un domaine
AgentOps	Orchestration de prompts, coordination multi-agents	Gestion des agents, des mémoires et des tools en production

La surface d’attaque qu’on ouvre quand on délègue

Déléguer une action à un agent, c’est lui donner les moyens d’agir sur le monde. Et tout système qui agit sur le monde peut être détourné. L’agentic AI ouvre des risques spécifiques, différents de ceux du simple modèle de langage, et il faut les connaître avant de déployer.

L’empoisonnement mémoire

Les mémoires à long terme des agents (historiques de conversation, scratchpads, vecteurs stockés) sont des cibles de choix pour l’empoisonnement : des entrées malveillantes peuvent être rappelées ultérieurement pour biaiser les plans ou les actions de l’agent ^[11]. La confusion de rôle (perturber les délimiteurs entre instructions système, utilisateur et assistant) et les boucles de réflexion peuvent internaliser des directives d’attaquants sur plusieurs tours de conversation. Par exemple, demander à un agent de « résumer en mémoire » avec des instructions cachées peut créer des effets durables si les stockages ne sont pas assainis ^[11].

L’injection de prompt persistante intersession

Le papier de recherche « What If Prompt Injection Never Left? » identifie une vulnérabilité fondamentale des systèmes agentic : l’injection de prompt stockée intersession (cross-session stored prompt injection). Contrairement aux attaques classiques qui ciblent une seule conversation, cette menace exploite l’état persistant de l’agent. Le gestionnaire de contexte peut charger, lors de l’exécution, un état contaminé dans les contextes d’exécution en aval, permettant à des instructions adversariales de détourner le comportement de l’agent, de manipuler ses réponses ou d’influencer ses actions médiées par des outils, et ce sur plusieurs sessions ^[12].

L’analyse révèle que les risques de sécurité des systèmes agentic persistants ne proviennent pas uniquement des entrées malveillantes elles-mêmes, mais de la façon dont les architectures d’agents gèrent les écritures persistantes et la réincorporation ultérieure de l’état stocké dans le comportement d’exécution ^[12].

Le détournement d’objectif

Le goal hijacking survient quand un attaquant parvient à rediriger l’agent vers un objectif différent de celui qui lui a été assigné. Les préconditions incluent une interaction préalable avec le système ou l’ingestion de données persistantes conçues par l’attaquant. Les impacts touchent la sécurité, la confidentialité et la persistance du système ^[11].

La fuite financière

Les agents connectés à des services payants (API cloud, modèles tiers, calcul intensif) peuvent être manipulés pour générer des appels coûteux répétés, ou pour lancer des tâches externes longues (fonctions serverless, notebooks) qui persistent aux frais de la victime. Les préconditions : des APIs connectées et une confiance excessive de l’agent dans l’invocation d’outils ^[11].

Les mesures de protection non négociables

Face à ces risques, plusieurs mesures s’imposent ^[11][12] :

• Identifiants scopés : chaque agent ne dispose que des permissions minimales nécessaires à sa tâche. Jamais de droits d’administrateur par défaut. Des politiques d’usage strictes complètent le dispositif ^[11].
• Assainissement des stockages mémoire : toute entrée persistante doit être validée et sanitisée avant réincorporation dans le contexte d’exécution ^[12].
• Supervision humaine : maintenir un humain dans la boucle pour les actions à impact élevé (transactions financières, modifications de données, accès système).
• Garde-fous à granularité fine : les mécanismes de sécurité peuvent opérer au niveau du token, de la séquence ou de la session. Le niveau choisi a un impact direct sur l’utilité du système, et chaque granularité présente un arbitrage différent entre protection et fluidité ^[13].
• Surveillance en temps réel : Gartner prévoit que plus de 40 % des violations de données liées à l’IA d’ici 2027 proviendront de l’usage transfrontalier inapproprié de l’IA générative, 73 % des entreprises rapportant déjà des incidents de sécurité IA avec un coût moyen de 4,8 millions de dollars par incident ^[9].

Le message est limpide : l’agentic AI multiplie le pouvoir d’action, mais elle multiplie proportionnellement la surface d’attaque. Chaque capacité d’action ajoutée à un agent doit être accompagnée d’un garde-fou correspondant.

Sources

• [1] Agentic AI for Engineers · livre · Amazon
• [2] Agentic Mesh The GenAI-Powered Autonomous Agent Ecosystem · livre · Amazon
• [3] MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models · Zhiyu Li et al. · 2025 · preprint · arXiv:2505.22101
• [4] Context Engineering From Prompts to Corporate Multi-Agent Architecture · V.V.Vishnyakova, Ph.D. · 2026 · preprint · arXiv:2603.09619
• [5] Multi-Agent Collaboration Mechanisms: A Survey of LLMs · Khanh-Tung Tran et al. · 2025 · preprint · arXiv:2501.06322
• [6] paper_paper-advancing-multi-agent-systems-through-model-context-pr_2504.21030.pdf · livre · Amazon
• [7] SwarmAgentic: Towards Fully Automated Agentic System Generation via Swarm Intelligence · Yao Zhang et al. · 2025 · preprint · arXiv:2506.15672
• [8] A Survey of Agentic AI and Cybersecurity Challenges, Opportunities and Use-case Prototypes · Sahaya Jestus Lazer et al. · 2026 · preprint · arXiv:2601.05293
• [9] Building Applications with AI Agents Designing and Implementing Multiagent Systems · livre · Amazon
• [10] GenAI on Google Cloud Enterprise Generative AI Systems and Agents · livre · Amazon
• [11] SoK: The Attack Surface of Agentic AI — Tools, and Autonomy · Ali Dehghantanha et al. · 2026 · preprint · arXiv:2603.22928
• [12] paper_paper-what-if-prompt-injection-never-left-exploring-cross-se_2606.04425.pdf · livre · Amazon
• [13] paper_paper-sok-evaluating-jailbreak-guardrails-for-large-language_2506.10597.pdf · livre · Amazon