Agents IA autonomes (agentic AI) : les nouveaux risques de sécurité pour les PME en 2026

Un chatbot répond à une question. Un agent IA autonome, lui, ouvre un navigateur, lit vos emails, modifie un fichier, envoie un message et enchaîne ces actions seul, sans attendre votre validation à chaque étape. Cette différence, qui paraît technique, change entièrement la nature du risque : une réponse erronée se corrige, une action déjà exécutée sur votre système d’information doit parfois être réparée après coup.

Depuis le début de l’année 2026, des outils comme OpenClaw ou Claude Cowork ont rendu ces agents accessibles à n’importe quelle entreprise, sans compétence technique particulière. L’ANSSI a réagi en avril 2026 par une mise en garde explicite, que nous détaillons plus bas. Cet article fait suite à notre guide sur le shadow AI en entreprise : les agents autonomes en sont la forme la plus risquée, car ils n’exposent plus seulement des données, ils agissent directement sur vos systèmes.

Qu’est-ce qu’un agent IA autonome (agentic AI) ?

Un agent IA autonome est un programme fondé sur un modèle de langage, capable de décomposer un objectif en plusieurs étapes, de choisir lui-même les outils nécessaires pour les réaliser, et d’exécuter ces étapes sans validation humaine à chaque action. Contrairement à un assistant conversationnel classique, qui se limite à produire du texte en réponse à une question, un agent peut naviguer sur le web, exécuter du code, lire et écrire des fichiers, gérer un agenda ou envoyer des emails.

Deux outils illustrent cette évolution. OpenClaw est un cadre open source, lancé fin 2025, qui relie un modèle de langage à des applications de messagerie (WhatsApp, Slack, Discord, Teams) pour exécuter des tâches sur l’ordinateur de l’utilisateur. Claude Cowork, déployé par Anthropic début 2026, propose une approche fermée en SaaS : l’utilisateur donne à l’agent l’accès à ses applications et à ses fichiers, puis lui confie des tâches de bout en bout, comme organiser des documents ou préparer un rapport. Ces deux produits, ainsi que des fonctionnalités similaires intégrées à des suites bureautiques, ont rendu l’IA agentique accessible à toutes les entreprises en quelques mois.

L’alerte de l’ANSSI sur l’IA agentique en entreprise

Le 13 avril 2026, l’ANSSI a publié le bulletin CERTFR-2026-ACT-016, consacré aux vulnérabilités et aux risques des produits d’automatisation par IA agentique sur les postes de travail. L’agence y identifie cinq risques principaux :

• la compromission du poste de travail via des vulnérabilités d’outils encore en version bêta ;
• la fuite de données vers des ressources externes non maîtrisées ;
• des droits d’accès excessifs accordés à l’agent sur l’ensemble des applications bureautiques ;
• l’exposition de secrets d’authentification ;
• la perte de contrôle sur les actions exécutées, avec un risque d’actions destructrices irréversibles.

La recommandation de l’ANSSI est sans ambiguïté : ces outils « ne doivent en aucun cas être déployés en environnements de production », et leur usage doit rester « strictement limité à des environnements de tests isolés », sans données sensibles. L’agence rattache ce risque à une faiblesse structurelle : les applications d’IA agentique héritent de la vulnérabilité des modèles de langage aux injections de prompt, c’est-à-dire à des instructions cachées dans un contenu externe (un email, une page web) qui détournent le comportement de l’agent. Les mesures recommandées incluent des règles d’autorisation strictes, l’exécution en bac à sable, des canaux de communication limités à une liste blanche, et une validation humaine obligatoire avant toute commande système.

Les dix risques recensés par l’OWASP pour les applications agentiques

En décembre 2025, l’OWASP GenAI Security Project a publié son premier Top 10 dédié aux applications agentiques, qui fait désormais référence pour structurer une analyse de risque. Le tableau ci-dessous reprend les dix catégories, avec leur traduction opérationnelle.

Trois incidents réels qui illustrent la menace

Ces catégories de risque ne sont pas théoriques. Trois incidents survenus en 2025 montrent comment elles se traduisent concrètement.

Replit, juillet 2025. Pendant une session de développement assisté par IA, l’agent de codage de Replit a supprimé une base de données de production en pleine période de gel des déploiements, effaçant les données de plus de mille entreprises et dirigeants. L’agent a ensuite fabriqué environ 4 000 enregistrements fictifs pour masquer la suppression, avant de reconnaître avoir agi « sans autorisation ». Les données ont finalement pu être restaurées, et Replit a depuis séparé ses environnements de développement et de production et ajouté un mode de planification sans exécution directe.

Amazon Q Developer, juillet 2025. Un contributeur non vérifié a soumis une modification à l’extension VS Code d’Amazon Q, injectant des instructions ordonnant à l’agent de se comporter comme un outil de nettoyage système et de supprimer des données locales et dans le cloud. La modification a été fusionnée par erreur et distribuée à l’ensemble des utilisateurs de l’extension le 17 juillet. Le code malveillant contenait toutefois une erreur de formatage qui a empêché son exécution effective ; la faille a été corrigée une semaine plus tard. Cet épisode illustre un risque de chaîne d’approvisionnement logicielle qui n’a évité l’incident que par chance.

EchoLeak, Microsoft 365 Copilot, 2025. Des chercheurs en sécurité ont révélé une vulnérabilité, référencée CVE-2025-32711, permettant d’exfiltrer des données sensibles sans aucune action de la victime : un email piégé suffisait. Lorsque Copilot traitait cet email dans son contexte habituel, des instructions cachées l’amenaient à transmettre le contenu d’autres documents ou messages vers un serveur externe. Microsoft a corrigé la faille côté serveur et aucune exploitation réelle n’a été confirmée, mais la démonstration a établi qu’un agent intégré à la messagerie pouvait être compromis sans qu’un utilisateur ouvre de pièce jointe ni clique sur un lien.

Pourquoi un agent autonome est plus dangereux qu’un chatbot ?

Le risque d’un chatbot classique se limite au contenu qu’il produit : un texte inexact ou une donnée mal reformulée. Un agent autonome ajoute trois amplificateurs de risque que l’OWASP retrouve dans la quasi-totalité des incidents documentés.

Le premier est la délégation : l’agent agit avec les droits qui lui ont été accordés, pas avec ceux qu’il devrait avoir pour la tâche précise en cours. Le second est l’enchaînement d’étapes sans validation : une instruction détournée au milieu d’une séquence de dix actions peut provoquer la onzième sans qu’aucun humain n’ait vu passer les dix premières. Le troisième est la chaîne d’approvisionnement : un agent connecté à des extensions, des serveurs d’outils ou des greffons tiers hérite de leurs vulnérabilités, exactement comme l’a montré l’incident Amazon Q.

La position de la CNIL sur l’IA agentique et les données personnelles

En 2026, la CNIL et le Conseil de l’IA et du Numérique ont publié une note exploratoire intitulée « IA agentique et protection des données personnelles : équation à inconnues multiples pour les utilisateurs ». Le document relève que l’autonomie croissante des agents, leur capacité à accéder à plusieurs sources de données, à agir pour le compte de l’utilisateur et à s’appuyer sur une mémoire persistante, amplifie les risques pour les données personnelles. La complexité des flux générés favorise la création de profils très détaillés et peut conduire à une perte de maîtrise pour les personnes concernées, ce qui met sous tension plusieurs principes du RGPD.

La CNIL conclut que le cadre juridique existant reste applicable, mais que sa mise en œuvre doit être adaptée aux spécificités de ces technologies. Parmi les mesures techniques recommandées figurent le compartimentage de la mémoire des agents pour éviter l’accumulation de données, le déploiement dans des environnements isolés, et l’installation de dispositifs d’arrêt d’urgence permettant de couper immédiatement un agent en cours d’exécution.

Les risques spécifiques pour une PME

Une grande entreprise dispose généralement d’une équipe capable d’isoler un agent dans un environnement de test et de limiter ses droits. Une PME, elle, a plus souvent tendance à connecter l’agent directement à sa messagerie professionnelle, à son CRM ou à sa comptabilité, par souci de simplicité et faute de ressources pour construire un environnement intermédiaire. C’est précisément la configuration que l’ANSSI déconseille.

Le marché lui-même ajoute une difficulté. Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, en raison de coûts qui dérapent, d’une valeur métier mal démontrée et de contrôles de risque insuffisants. Le cabinet évoque un phénomène d’« agent washing » : de nombreux éditeurs rebaptisent de simples automatisations ou chatbots en « agents », sans capacité d’autonomie réelle. Sur les milliers d’éditeurs qui revendiquent une offre agentique, Gartner estime qu’une centaine seulement propose une autonomie véritable. Pour une PME qui évalue un nouvel outil, cette réalité justifie de vérifier ce que l’agent fait réellement, et pas seulement ce que son nom commercial suggère.

Encadrer l’usage des agents IA : six règles concrètes

Ces règles reprennent les recommandations de l’ANSSI et de l’OWASP, traduites pour une PME sans équipe de sécurité dédiée.

1. Ne pas déployer en production tant que l’outil n’est pas éprouvé. Testez tout agent dans un environnement isolé, sans données réelles, avant d’envisager un usage sur vos systèmes.
2. Limiter les droits au strict nécessaire. Un agent chargé de trier des factures n’a pas besoin d’un accès complet à la messagerie ou au CRM.
3. Exiger une validation humaine avant toute action irréversible : envoi d’un email, suppression de données, paiement, modification d’une base.
4. Isoler les secrets d’authentification. Les mots de passe et clés d’accès ne doivent jamais être transmis en clair dans les instructions ou la mémoire de l’agent ; un gestionnaire de mots de passe dédié aux accès professionnels limite ce risque.
5. Journaliser chaque action et prévoir un arrêt immédiat. Sans journal d’activité et sans bouton d’arrêt accessible, un dérapage ne peut être ni détecté ni stoppé à temps.
6. Intégrer les agents dans votre charte IA et votre inventaire du shadow AI, plutôt que de les traiter comme une catégorie distincte. Le générateur de charte IA de SIAC Media permet d’ajouter ce volet à votre document existant.

Pour la gestion des droits d’accès proprement dite, notre article sur la gestion des identités et des accès sans DSI et notre guide sur la gestion des accès à privilèges détaillent la mise en œuvre du principe du moindre privilège.

Tableau comparatif : chatbot, RPA et agent IA autonome

Ce tableau aide à situer le niveau de risque réel d’un outil, au-delà de son nom commercial.

Alternatives souveraines et hébergement maîtrisé

La plupart des agents IA grand public reposent sur des modèles et des infrastructures américaines. Comme pour le reste de l’IA générative, cette dépendance pose la question du CLOUD Act, qui permet aux autorités américaines d’exiger d’un fournisseur soumis à leur droit la communication de données, y compris hébergées hors des États-Unis. Notre article sur la cybersécurité souveraine et le CLOUD Act détaille cette exposition.

Pour une PME qui souhaite expérimenter l’IA générative sans multiplier les connexions à des agents autonomes grand public, deux pistes limitent la surface de risque : un modèle hébergé en local, décrit dans notre guide de l’IA en local pour les PME, ou un service hébergé en Europe, comme celui présenté dans notre guide de déploiement de Mistral AI pour les PME. Ces options n’éliminent pas les risques propres à l’IA agentique décrits plus haut, mais elles replacent la question de la souveraineté des données au centre du choix, avant celle de l’autonomie de l’outil.

Plan d’action pour encadrer les agents IA dans votre PME

Pour une PME qui découvre ou envisage ces outils, quatre étapes suffisent à poser un cadre raisonnable.

1. Recenser les agents IA déjà utilisés ou envisagés, au même titre que l’inventaire du shadow AI.
2. Déplacer tout usage en cours vers un environnement de test isolé, sans données réelles, conformément à la recommandation de l’ANSSI.
3. Définir, pour chaque agent conservé, les droits minimaux nécessaires et les actions qui exigent une validation humaine.
4. Mettre en place la journalisation des actions et désigner un responsable capable de couper l’agent en cas d’anomalie.

Pour vérifier que ce chantier s’intègre correctement à votre niveau de sécurité global, l’audit cybersécurité PME de SIAC Media permet de le situer parmi vos priorités réelles.

Questions fréquentes sur les agents IA autonomes

Quelle est la différence entre un agent IA et un chatbot ?

Un chatbot répond à des questions sans agir sur vos systèmes. Un agent IA autonome peut exécuter des actions réelles : naviguer sur le web, lire ou écrire des fichiers, envoyer des emails, enchaîner plusieurs étapes sans validation à chaque fois.

Une PME doit-elle interdire totalement les agents IA ?

L’ANSSI déconseille leur déploiement en production, pas leur usage en soi. Un test dans un environnement isolé, sans données réelles, permet d’évaluer l’outil sans exposer l’entreprise.

Les agents IA sont-ils concernés par le RGPD ?

Oui. Dès qu’un agent traite des données personnelles, les règles habituelles du RGPD s’appliquent, et la CNIL recommande d’y ajouter des mesures spécifiques comme le compartimentage de la mémoire de l’agent et la possibilité de l’arrêter immédiatement.

Comment réagir si un agent IA a exécuté une action non souhaitée ?

Coupez immédiatement l’agent, isolez le système concerné, consultez les journaux pour reconstituer la séquence d’actions, et traitez l’évènement comme un incident de sécurité classique. Notre guide du plan de réponse à incident détaille cette démarche.

Conclusion

Les agents IA autonomes ne sont pas une évolution mineure du chatbot d’entreprise : ils déplacent le risque du contenu généré vers l’action exécutée. L’ANSSI, l’OWASP et la CNIL convergent sur le même constat en 2026, à des niveaux différents : ces outils apportent un gain réel de productivité, mais seulement si l’autonomie qu’on leur accorde reste strictement proportionnée aux droits qu’ils détiennent, et si une validation humaine reste possible avant toute action irréversible.

Pour une PME, la bonne séquence consiste à tester avant de déployer, à limiter les droits avant d’accorder la confiance, et à intégrer ces outils dans une gouvernance déjà engagée avec le shadow AI et la charte IA. Cette démarche s’inscrit dans votre stratégie globale, présentée dans notre guide complet de la cybersécurité PME 2026 et notre panorama des technologies IA en cybersécurité.