Agent IA : ce que vous lui confiez sans le savoir
Les témoignages fleurissent partout. Une agence demandait 16 000 € pour un site web : Claude l’a produit en une journée. Un développeur coûtait cher et prenait des vacances : l’agent IA, lui, ne dort jamais. Ces récits ne sont pas faux. Les agents IA sont devenus des exécutants d’une puissance réelle, accessibles à des gens qui n’ont aucune formation technique.
Ce qu’on oublie de mentionner dans ces témoignages, c’est ce qu’on a donné à l’agent pour qu’il travaille.
Les risques liés aux agents IA se regroupent en trois catégories distinctes : ce qu’ils lisent, ce qu’ils exécutent, et ce qu’ils introduisent dans votre projet. Ces catégories ne se confondent pas, et les précautions utiles ne sont pas les mêmes pour chacune.
L’agent IA ne vole rien. Il explore ce que vous exposez.
Quand vous lancez un agent IA sur votre projet, il travaille dans un environnement. Cet environnement contient des choses que vous avez mises là consciemment, votre code, vos fichiers, vos instructions. Et des choses que vous avez oubliées.
Un projet web typique contient presque toujours un fichier .env. C’est là que vivent les clés API : Stripe, Google, votre hébergeur, votre base de données. Ce fichier est conçu pour ne jamais être publié. Mais un agent IA qui travaille dans votre dossier de projet peut y avoir accès, et selon l’outil utilisé, son mode de fonctionnement et sa configuration, ce contenu peut se retrouver dans le contexte envoyé au modèle pour traitement.
Ce n’est pas uniforme. Certains agents travaillent entièrement en local. D’autres combinent exploration locale et traitement distant. Les fournisseurs sérieux documentent des mécanismes pour borner ces accès, règles d’exclusion, modes de permission, répertoires de secrets isolés. Cela montre à la fois que le risque est réel et qu’il peut être techniquement borné. Mais borné ne veut pas dire borné par défaut.
Il y a un autre point que les témoignages ne mentionnent pas : un agent nouvelle génération n’attend pas qu’on lui pointe un fichier. Il peut explorer votre base de code par recherche sémantique pour trouver ce qui lui semble pertinent à la tâche. Ce qu’il lit ne se limite pas à ce que vous lui avez explicitement montré. Il lit ce que vous avez exposé à son périmètre de travail.
La même logique s’applique aux données de vos clients si elles sont dans des fichiers accessibles, aux accès serveur si vous travaillez dans un répertoire connecté, aux communications internes si vous avez branché l’agent sur vos outils métier.
L’agent ne juge pas ce qu’il lit. Il traite et ça s’arrête la.
L’agent agit avec vos permissions. Pas les siennes.
Un développeur humain a des réflexes. Il sait qu’on ne touche pas à la base de données de production pour tester quelque chose. Il sait qu’on vérifie une dépendance avant de l’installer. Il sait qu’une modification dans un mauvais dossier peut tout casser.
Un agent IA n’a pas ces réflexes. Il a vos permissions.
Si vous le lancez avec un accès administrateur sur votre machine, il agit en administrateur. S’il peut écrire dans votre répertoire de production, il peut y écrire. Et s’il installe une dépendance, il le fait avec la même efficacité qu’il met à tout le reste, sans vérification indépendante de ce qu’il installe.
C’est là que la chaîne se fragilise concrètement. Des travaux académiques publiés en 2024 ont mesuré que les LLM appliqués au code suggèrent des noms de packages fictifs dans une proportion significative de leurs réponses, des noms plausibles qui n’existent pas encore dans les registres. Par ailleurs, des campagnes ciblant la chaîne d’approvisionnement logicielle dans l’écosystème npm sont régulièrement documentées par des chercheurs en sécurité, certaines introduisant des dépendances piégées ou du code à comportement dangereux. Le 31 mars 2026, Google Threat Intelligence Group a documenté une attaque ciblant axios, l’une des bibliothèques JavaScript les plus utilisées pour les requêtes HTTP. Un acteur malveillant avait compromis le compte du mainteneur et introduit une dépendance piégée dans deux versions du package, une dépendance qui s’exécutait automatiquement à l’installation, via un hook postinstall, sans validation supplémentaire de l’utilisateur. Ces deux phénomènes, hallucination de noms et publication opportuniste, n’ont pas besoin de se coordonner pour créer un risque réel : ils se renforcent mécaniquement.
Si vous n’avez pas configuré votre outil pour demander une confirmation avant d’installer des dépendances, l’agent installe et votre système exécute sans que vous soyez dans la boucle. Claude Code, par exemple, soumet par défaut certaines actions à approbation explicite, précisément pour que l’humain reste dans la décision. D’autres outils majeurs proposent des mécanismes comparables. Ces garde-fous existent. Encore faut-il ne pas les désactiver pour aller plus vite.
Ce scénario ne suppose pas un agent défaillant. Il suppose un agent qui fait exactement ce qu’on lui a demandé, dans un périmètre qu’on n’a pas sécurisé.
Le problème n’est pas que l’agent soit malveillant. C’est qu’il est neutre. Il exécute ce qu’on lui demande, dans le périmètre qu’on lui a donné, sans distinguer ce qui est prudent de ce qui ne l’est pas.
Ce jugement-là, c’est le vôtre. Et si vous ne l’exercez pas avant de lancer l’agent, personne ne le fait à votre place.
Ce que vous devriez faire avant de déléguer à l’arrache
Ces réflexes ne demandent pas d’être ingénieur sécurité, mais ils demandent de NE PAS IMPROVISER.
- Délimitez le périmètre. Ne lancez pas votre agent depuis la racine de votre système ou depuis un dossier qui contient plus que ce dont il a besoin pour la tâche. Créez un dossier de travail dédié. Mettez-y uniquement ce qui est nécessaire.
- Sortez vos secrets du périmètre. Les clés API, les mots de passe, les tokens d’accès ne doivent pas traîner dans des fichiers texte au même endroit que votre projet. Des outils de gestion de secrets existent pour ça, certains sont gratuits et documentés.
- Ne désactivez pas les confirmations. Les outils sérieux demandent une validation humaine sur les actions sensibles, installation de dépendances, modification de fichiers, connexions externes. C’est une friction utile. La supprimer pour aller plus vite, c’est sortir de la boucle de décision.
- Ne travaillez jamais directement en production. Ce que l’agent casse en environnement de test se répare. Ce qu’il casse en production, parfois non.
Ce sujet va évoluer vite
Les agents IA gagnent en autonomie chaque mois. Les cas d’usage s’élargissent, les intégrations se multiplient, et les questions de sécurité qui les accompagnent aussi. Certains fournisseurs commencent à proposer des solutions pour encadrer techniquement ce périmètre, l’isolation réseau, la gestion fine des permissions par l’agent lui-même.
Cet article sera mis à jour au fil de ces évolutions. Ce qui ne changera pas : la responsabilité du périmètre reste la vôtre.
A propos de l'auteur : Mina
CoFondatrice de VPN Mon Ami
Chasseuse de bugs dans son quotidien, Mina teste tous les outils de cybersécurité, anciens et nouveaux, que nous vous faisons découvrir.
