TL;DR
L’agentic AI désigne une classe de systèmes capables d’enchaîner du raisonnement, des appels d’outils et de la mémoire pour poursuivre un objectif sur plusieurs étapes. En 2026, en France, les déploiements crédibles couvrent le support client de niveau deux, le triage RGPD, l’extraction documentaire et la recherche augmentée. Les usages à risque élevé (décisions financières, modifications de production) restent à proscrire ou à fortement encadrer. Les risques cyber spécifiques tiennent à la prompt injection en chaîne, à la fuite de données par tool use et à l’escalade de privilèges via API. La gouvernance minimale d’un projet agentic combine sandbox, observabilité, validation humaine sur les actions sensibles, rate limits et kill switch.
Agentic AI : la définition courte
Un agent IA est un système qui combine quatre briques : un modèle de langage de grande taille (LLM), un ensemble d’outils invocables (recherche, calcul, API, exécution de code), une mémoire (session ou persistante), et un orchestrateur qui décide quelle étape exécuter à chaque tour. La différence avec un chatbot LLM est donc fonctionnelle, pas seulement quantitative. Un chatbot produit du texte. Un agent peut poser des actions dans des systèmes tiers, lire un fichier, interroger une base, déclencher un workflow.
Le NIST AI Risk Management Framework, comme l’ENISA dans ses publications sur la sécurité des systèmes IA, retient ces quatre éléments comme constitutifs d’une approche agentique [1][2]. Le règlement (UE) 2024/1689 ne définit pas spécifiquement le terme « agentic AI », mais ses obligations s’appliquent à tout système IA, quelle que soit son architecture, dès lors qu’il relève d’un usage classé à risque [3].
La capacité d’exécution outillée est le saut majeur. Un agent qui peut envoyer un email, modifier une ligne dans un CRM ou interroger un service de paiement déplace la frontière de responsabilité : l’erreur n’est plus seulement informationnelle, elle est opérationnelle.
Les trois architectures usuelles
Trois patterns se sont stabilisés dans la littérature et dans les frameworks de référence.
ReAct (reason-then-act) alterne explicitement des étapes de raisonnement et des appels d’outils. À chaque tour, l’agent verbalise une pensée, choisit un outil, observe la réponse, puis recommence. Cette approche a l’avantage de la transparence : la chaîne d’inférence est lisible, donc auditable. Elle est aujourd’hui la plus déployée pour les agents internes en entreprise.
Plan-and-execute sépare deux phases. Un planificateur décompose la tâche en sous-objectifs ordonnés, puis un exécuteur (souvent un autre appel LLM, parfois plus petit) déroule chaque étape. Cette architecture convient aux tâches longues, type rédaction d’un rapport en plusieurs sections ou traitement d’un dossier client multi-pièces. Le risque est qu’un plan initial mal posé entraîne une dérive sur plusieurs étapes.
Multi-agent distribue le travail entre plusieurs agents spécialisés qui communiquent. Un agent rédige, un autre vérifie, un troisième cite les sources, un quatrième valide. Les frameworks CrewAI et AutoGen orientent fortement ce pattern. Le multi-agent introduit toutefois une complexité opérationnelle (coordination, conflits, coûts cumulés) qui ne se justifie qu’à partir d’un certain volume ou d’une diversité de compétences difficile à concentrer dans un seul agent.
Cas d’usage qui marchent en 2026
Plusieurs cas d’usage sont aujourd’hui suffisamment matures pour être déployés en production sous contrôle.
Support client niveau deux et trois. L’agent reçoit la demande, identifie la catégorie, interroge la base de connaissances interne, vérifie le statut du compte client, propose une réponse ou un workflow de résolution. La supervision humaine intervient pour les cas non résolus ou sensibles. Le gain documenté tient à la résolution autonome d’environ trente à cinquante pour cent des tickets de niveau deux selon les organisations, avec un transfert vers l’humain dans les autres cas.
Triage RGPD et DSAR. Une demande d’accès, d’effacement ou de portabilité arrive par formulaire ou par email. L’agent identifie le demandeur, vérifie son périmètre (client, salarié, prospect), localise les données concernées dans les systèmes inventoriés et prépare un dossier de réponse pour le DPO. La CNIL recommande dans ce cas une validation humaine systématique avant envoi au demandeur [4]. L’agent reste un assistant de productivité, pas un décideur.
Extraction de données structurées. Documents juridiques, factures fournisseurs, contrats, rapports d’audit : l’agent lit, identifie les champs pertinents, les normalise, alimente un système structuré (ERP, GED, base SQL). Le couplage avec un schéma de validation strict (JSON Schema, Pydantic) limite les sorties incohérentes.
Recherche documentaire augmentée. L’agent interroge des bases internes (Confluence, SharePoint, GED), externes (sites publics, presse spécialisée), corrèle, cite les sources et rédige une synthèse. Le cadre RAG (retrieval-augmented generation) sert ici de socle, augmenté d’une capacité de planification.
Cas d’usage qui ne marchent pas (encore)
Plusieurs périmètres demeurent inadaptés à un déploiement agentic non supervisé.
Décisions financières non supervisées. Octroi de crédit, allocation d’actifs, validation de paiements au-dessus d’un seuil bas : l’AI Act classe ces usages en haut risque dès lors qu’ils produisent un effet juridique sur une personne physique, et l’ACPR, comme la Banque de France, considère qu’une décision automatisée sans intervention humaine sur le crédit aux particuliers reste contraire à l’esprit du RGPD article 22.
Modifications de configuration en production. Un agent qui peut redémarrer un service, modifier une règle pare-feu, ajuster un index de base, ou déployer du code, expose l’organisation à des actions irréversibles sur incident IA. L’ANSSI recommande dans ses guides sur l’IA et l’administration d’infrastructure de cantonner l’agent à des environnements de test ou à des opérations de lecture seule, ou à défaut d’imposer une validation humaine sur toute action mutative [5].
Conseils médicaux, juridiques ou financiers personnalisés sans encadrement. Ces périmètres relèvent du haut risque AI Act et exigent au minimum la supervision humaine, la traçabilité et la documentation prévues par le règlement.
Frameworks dominants
Plusieurs frameworks structurent le paysage agentic en 2026. Aucun ne s’impose comme standard universel ; le choix dépend du contexte technique et de la maturité de l’équipe.
LangChain et LangGraph. LangChain propose une abstraction d’orchestration d’agents et d’outils. LangGraph, du même éditeur, introduit une représentation explicite sous forme de graphe d’états, utile pour les workflows complexes et auditables [6]. La couche LangSmith fournit l’observabilité.
CrewAI. Framework orienté multi-agent, structuré autour de la notion de « crew » (équipe d’agents ayant chacun un rôle et des outils dédiés). L’approche favorise la lisibilité métier mais demande une discipline de conception pour éviter les conflits inter-agents [7].
AutoGen. Issu de Microsoft Research, AutoGen propose un modèle conversationnel multi-agent, où les agents échangent en langage naturel pour résoudre une tâche [8].
Semantic Kernel. Toujours chez Microsoft, Semantic Kernel cible une intégration native dans des stacks .NET et Python, avec une approche orientée plugins, mémoire et planificateurs [9].
D’autres briques se positionnent à la marge (Haystack côté RAG, DSPy côté optimisation de prompts), sans constituer aujourd’hui des frameworks d’agents au sens strict.
Les risques cyber spécifiques
L’agentic AI introduit trois familles de risques nouveaux par rapport aux chatbots LLM classiques.
Prompt injection en chaîne. Un contenu externe ingéré par l’agent (page web, document PDF, email entrant) peut contenir des instructions cachées qui détournent l’objectif. L’attaque devient particulièrement efficace lorsque l’agent dispose d’outils sensibles : un document malveillant peut tenter de déclencher un envoi d’email, une requête API ou la divulgation d’un secret stocké en mémoire. L’ENISA documente ce vecteur sous le terme d’« indirect prompt injection » et le considère comme l’un des risques majeurs des systèmes agentiques [2].
Fuite de données via tool use. L’agent peut transmettre, lors d’un appel d’outil légitime, des informations sensibles qui n’auraient pas dû quitter le système. Exemple typique : l’agent appelle un service externe de traduction et lui transmet un extrait de contrat client confidentiel. La fuite ne résulte pas d’une faille classique, mais d’un défaut de cloisonnement des outils par sensibilité de données.
Escalade de privilèges via API. Si l’agent dispose d’un jeton API à privilèges larges, une seule injection réussie peut suffire à déclencher des actions au-delà du périmètre autorisé. La parade classique consiste à dédier un compte de service par outil, avec le moins de privilèges possible et un scope strictement limité.
D’autres risques classiques restent pertinents : hallucination conduisant à une action erronée, dépendance excessive à un fournisseur LLM externe, manque de chiffrement des traces stockant des données personnelles.
Gouvernance : sandbox, observabilité, contrôle humain
La gouvernance d’un projet agentic repose sur cinq invariants minimum.
Sandbox d’exécution. Toute action posée par l’agent doit s’exécuter dans un environnement isolé, sans accès réseau par défaut, et avec une liste blanche d’outils et de destinations. L’élargissement du périmètre se fait étape par étape, après validation.
Observabilité fine. Chaque appel LLM, chaque appel d’outil, chaque décision intermédiaire doivent être journalisés, horodatés et reliés à un identifiant de session. Le journal doit permettre de répondre, après incident, à trois questions : quel prompt a été envoyé, quelle action a été exécutée, quelle donnée a été lue ou modifiée.
Validation humaine sur les actions sensibles. Toute action irréversible (envoi externe, modification de production, transaction, suppression) passe par un point de contrôle humain. Le coût opérationnel est réel, mais c’est la contrepartie de la confiance.
Rate limits. Plafonner le nombre d’appels d’outils par session, par utilisateur et par heure permet de contenir un comportement déviant ou une boucle infinie.
Kill switch. Un dispositif simple et documenté pour interrompre toute exécution d’un agent en cours. Le kill switch n’est utile que si son déclenchement est testé régulièrement et que sa portée est connue (interruption immédiate, persistance des actions déjà engagées).
À ces invariants s’ajoutent deux pratiques fréquemment observées sur les déploiements matures. La première consiste à séparer strictement l’environnement de raisonnement (le LLM, sa mémoire) et l’environnement d’exécution (les outils, les API). Cette séparation, défendue par les guides OWASP applicables aux applications IA, limite la surface offerte à une compromission via prompt injection. La seconde consiste à versionner les prompts système, les listes d’outils autorisés et les politiques d’arrêt, comme on versionne du code, afin de pouvoir auditer rétrospectivement le comportement d’un agent à une date donnée.
Articulation avec l’AI Act
Le règlement (UE) 2024/1689 (AI Act) s’applique à tout système IA déployé dans l’Union européenne, y compris agentique. La classification s’opère par usage final, pas par architecture [3]. Un agent qui aide à rédiger un compte rendu de réunion relève du risque limité, avec une obligation principale de transparence vis-à-vis de l’utilisateur. Un agent qui contribue à une décision RH, à l’octroi d’un crédit ou à la sélection d’un candidat bascule en haut risque et entraîne les obligations de gestion des risques, de documentation, de supervision humaine et de journalisation déjà décrites dans notre analyse des obligations AI Act pour DSI et RSSI.
Le calendrier d’application progressive est utile à intégrer dans la planification : interdictions effectives depuis le 2 février 2025, obligations GPAI depuis le 2 août 2025, obligations haut risque applicables à partir du 2 août 2026, application intégrale au 2 août 2027.
Le réflexe d’un RSSI face à une demande agentic
Lorsqu’un projet agentic remonte vers la sécurité, six questions structurent une première instruction sans avoir à entrer dans le détail technique du modèle.
- Quel est l’usage final, et quel niveau de risque AI Act lui correspond ?
- Quels outils l’agent peut-il appeler, et avec quels privilèges ?
- Quelles données sont susceptibles d’être lues, transmises ou écrites par l’agent ?
- Quel est le périmètre exact de la mémoire (session, persistance, partage entre utilisateurs) ?
- Quel est le dispositif de validation humaine sur les actions sensibles, et comment est-il tracé ?
- Quelle est la procédure d’arrêt en cas d’incident, et a-t-elle été testée ?
Ces six questions, posées en amont, suffisent à différer un projet immature ou à l’orienter vers un périmètre plus restreint avant déploiement.
À retenir
L’agentic AI n’est ni un effet de mode ni une rupture technique radicale : c’est l’extension du LLM par des outils, une mémoire et un orchestrateur. Les cas d’usage validés en 2026 sont concrets et bornés. Les risques cyber spécifiques (prompt injection en chaîne, fuite par tool use, escalade par API) demandent une gouvernance dédiée. L’AI Act fournit le cadre, mais l’essentiel de la sécurité se joue dans la conception : sandbox, observabilité, validation humaine, rate limits, kill switch. Le RSSI dispose de six questions pour instruire toute demande agentique sans devoir entrer dans le code du modèle.
Sources et références
[1] NIST, AI Risk Management Framework, version 1.0, 2023, mises à jour 2024-2025, https://www.nist.gov/itl/ai-risk-management-framework
[2] ENISA, publications sur la sécurité des systèmes d’intelligence artificielle, https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence
[3] Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 (AI Act), EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R1689
[4] CNIL, dossier intelligence artificielle, https://www.cnil.fr/fr/intelligence-artificielle
[5] ANSSI, publications sur l’IA et la sécurité des systèmes d’information, https://cyber.gouv.fr/
[6] LangChain et LangGraph, documentation éditeur, https://www.langchain.com/
[7] CrewAI, documentation éditeur, https://www.crewai.com/
[8] AutoGen, projet Microsoft Research, https://github.com/microsoft/autogen
[9] Semantic Kernel, documentation Microsoft, https://learn.microsoft.com/semantic-kernel/