L'argument de vente des agents IA est grisant : au lieu de demander une réponse à un chatbot puis de la recopier quelque part, vous confiez un objectif à un agent et il fait le travail — il lit votre boîte de réception, interroge la base de données, ouvre le ticket, envoie l'e-mail. Cette semaine, c'est tout le secteur qui s'est engouffré dans la brèche. Google a lancé ses Managed Agents dans son API, tandis que Microsoft et Nvidia ont dévoilé de nouvelles primitives de « confinement » sous Windows, pensées précisément pour que les agents puissent agir sur votre PC sans partir en vrille (Nvidia).
C'est dans cette dernière formule que tout se joue. Dès l'instant où une IA cesse de parler pour commencer à agir, elle n'est plus un chatbot astucieux : elle devient un nouveau type d'utilisateur sur votre réseau — un utilisateur qui peut être manipulé, sur-autorisé, ou tout simplement dans l'erreur. Si le concept est nouveau pour vous, notre article qui explique ce que sont réellement les agents IA est un bon point de départ. Ici, on s'attaque à ce que les démonstrations passent sous silence : la conversation sur la sécurité qu'il faut avoir avant de laisser un agent toucher à quoi que ce soit d'important.
Ce qui change vraiment : de la « réponse » à l'« action »
Un chatbot classique a un rayon d'action limité. Au pire, une mauvaise réponse vous induit en erreur, mais c'est toujours vous qui cliquez sur le bouton. Un agent, lui, est différent par conception : il dispose d'outils (il peut appeler des API, exécuter du code, naviguer sur le web), d'une mémoire (il se souvient d'une étape à l'autre) et d'une autonomie (il décide de la suite sans vous consulter à chaque fois).
Ces trois propriétés sont exactement ce qui rend les agents utiles — et exactement ce qui les rend risqués. L'OWASP GenAI Security Project, qui publie ce qui ressemble le plus à une liste de risques faisant consensus dans le secteur, a sorti un Top 10 2026 spécifique aux applications agentiques, justement parce que ces systèmes introduisent des modes de défaillance qui dépassent le simple « le modèle a dit une bêtise » — des choses comme le détournement d'outils, l'agentivité excessive, l'empoisonnement de la mémoire et l'injection de prompt (OWASP).
Penchons-nous sur les deux qui comptent le plus en pratique.
Le risque phare : l'injection de prompt
L'injection de prompt est le problème de sécurité qui ne disparaîtra pas en 2026, et il mérite qu'on s'y arrête car il fait voler en éclats une hypothèse confortable. Avec une application normale, on fait confiance au code et on se méfie des entrées de l'utilisateur. Avec un agent, les « instructions » et les « données » arrivent dans le même flux de texte — si bien que tout contenu lu par l'agent (une page web, un e-mail, un commentaire de code, un PDF) peut contenir des instructions, et le modèle est susceptible de les suivre.
Ce n'est pas de la théorie. Un exemple réel, désormais corrigé : le chercheur en sécurité Johann Rehberger a démontré la faille CVE-2025-53773, dans laquelle des instructions cachées placées dans des fichiers ouverts par un développeur pouvaient amener GitHub Copilot, dans Visual Studio Code, à modifier en silence le settings.json du projet pour activer le « mode YOLO » (chat.tools.autoApprove: true) — désactivant ainsi les invites d'approbation humaine et laissant l'agent exécuter des commandes shell. Microsoft a classé la faille à 7,8 (élevée) et déployé un correctif dans sa mise à jour d'août (Embrace The Red, NVD).
Le plus gênant : il n'existe aucun correctif complet connu contre l'injection de prompt — seulement de la défense en profondeur. La bonne grille de lecture n'est donc pas « puis-je bloquer l'attaque ? », mais « quand l'agent reçoit de mauvaises instructions, quel est le pire qu'il puisse faire ? » — ce qui mène droit au second risque.
Le risque silencieux : l'agentivité excessive
L'« agentivité excessive » est le terme employé par l'OWASP pour désigner l'autogoal le plus fréquent : donner à un agent plus de pouvoir que sa mission ne l'exige. Un agent disposant d'un accès en lecture/écriture à votre base de données de production, de l'autorisation d'envoyer des e-mails en votre nom et d'une carte bancaire d'entreprise enregistrée est un problème — qu'il soit détourné par un attaquant ou qu'il prenne simplement une mauvaise décision de lui-même.
La parade est le plus vieux principe de la sécurité, appliqué à un nouveau type d'acteur : le moindre privilège. L'OWASP en propose une version agentique, le moindre niveau d'agentivité — n'accorder que l'autonomie et les accès minimaux nécessaires à la tâche définie, rien de plus. Un agent qui résume des tickets de support n'a pas besoin d'un accès en écriture à la facturation. Un agent qui rédige des réponses n'a pas besoin de l'autorisation de les envoyer.
Là où les données des agents fuient réellement
Une fois le battage médiatique mis de côté, la plupart des incidents réels d'exposition de données par les agents se ramènent à une courte liste de schémas. Voici comment ils s'articulent avec les parades :
| Ce qui dérape | Pourquoi ça arrive | Le garde-fou concret |
|---|---|---|
| L'agent lit des données hors de sa mission | Les accès sont cadrés au niveau de l'application, pas de la couche de données | Imposez les permissions sur les données elles-mêmes ; donnez à l'agent sa propre identité cadrée, et non l'identité large d'un humain |
| Vol d'identifiants de l'agent | Des clés/jetons d'API à longue durée de vie traînent dans les fichiers de configuration | Des identifiants à courte durée de vie et cadrés ; rotation régulière ; ne jamais coder les clés en dur |
| Injection → exfiltration | L'agent est piégé pour divulguer des données qu'il peut lire | Limitez ce qu'il peut lire ; restreignez les appels sortants ; approbation humaine pour les actions sensibles |
| « Il a juste fait un truc » | Trop d'autonomie, aucune piste d'audit | Validation humaine (human-in-the-loop) pour les étapes à fort impact ; journalisez chaque appel d'outil |
Rien d'ésotérique là-dedans. C'est la même discipline d'identité, d'accès et de journalisation qui protège vos collaborateurs humains — appliquée à un travailleur non humain qui agit plus vite et ne se fatigue jamais. Si votre organisation n'a pas encore verrouillé les fondamentaux, commencez d'abord par notre guide des bases de la cybersécurité pour les petites entreprises ; les agents amplifient la posture de sécurité que vous avez déjà.
Une check-list avant déploiement
Avant qu'un agent ne passe en production avec un accès à de vrais systèmes, vous devriez pouvoir répondre « oui » à toutes ces questions :
- Identité cadrée ? L'agent dispose de ses propres identifiants, avec les permissions les plus étroites pour sa tâche — et non d'un compte admin emprunté.
- Agentivité minimale ? Il ne peut appeler que les outils précis dont il a besoin ; tout le reste est refusé par défaut.
- Validation humaine pour ce qui est dangereux ? Envoyer de l'argent, supprimer des données, écrire à des clients, modifier une configuration → exigez une approbation humaine.
- Entrées non fiables traitées comme telles ? Tout ce que l'agent lit sur le web, dans les e-mails ou les fichiers déposés par les utilisateurs est présumé susceptible de contenir des instructions injectées.
- Bac à sable ? L'exécution de code et l'accès aux fichiers/au système se déroulent dans un environnement confiné (précisément ce que Microsoft et Nvidia intègrent aujourd'hui à Windows).
- Journalisé et réversible ? Chaque appel d'outil est enregistré, et les actions à fort impact peuvent être revues ou annulées.
Si vous ne pouvez pas répondre oui, l'agent n'est pas prêt pour ce niveau d'accès — confiez-lui une tâche plus modeste.
L'argument économique, sans détour
La prudence en matière de sécurité n'est pas une posture anti-IA ; c'est elle qui maintient ces projets en vie. Gartner a prédit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, invoquant l'envolée des coûts, une valeur métier floue et des contrôles de risque inadéquats — et le cabinet a mis en garde contre l'« agent washing », estimant que seule une petite fraction des fournisseurs se disant agentiques le sont réellement (Gartner).
Le revers de la propre prévision de Gartner, c'est que les projets qui survivront seront bien réels : le cabinet table toujours sur une part significative des logiciels d'entreprise intégrant de l'IA agentique d'ici 2028. Les gagnants ne seront pas ceux qui déploient des agents le plus vite — mais ceux qui les déploient avec des garde-fous leur permettant de continuer à tourner après le premier incident.
En résumé
Les agents IA sont réellement utiles, et 2026 est l'année où ils passent de la démo au déploiement — voyez le Tech Pulse du jour pour mesurer la vitesse à laquelle les plateformes se livrent bataille ici. Mais « il peut agir pour vous » et « il peut agir pour un attaquant » sont une seule et même phrase. Traitez un agent comme un nouvel employé que vous n'avez jamais rencontré : accordez-lui le moins d'accès possible, surveillez ce qu'il fait et assurez-vous qu'un humain valide tout ce que vous pourriez regretter. À cette condition, les agents deviennent un coéquipier puissant plutôt que votre passif le plus sur-autorisé.
Nous renvoyons aux sources primaires (OWASP, NVD, Gartner) pour que vous puissiez vérifier, et nous signalons les affirmations et prévisions des entreprises pour ce qu'elles sont. Les conseils de sécurité présentés ici sont d'ordre général — adaptez-les à vos propres systèmes et à votre tolérance au risque.
