Oui, en effet, on observe un décalage important. Aujourd’hui, le code généré par l’IA est devenu la norme : 84 % des développeurs utilisent désormais l’IA générative, selon la dernière étude du Stack Overflow Developer Survey (2025). Ce décalage entre la vitesse de l’innovation et la maturité de la sécurité n’est pas nouveau, mais l’IA l’amplifie massivement.
Trois facteurs clés l’expliquent :
De plus, nous faisons face à des modèles dits non déterministes, ce qui signifie qu’un même prompt peut générer un code sûr aujourd’hui et une faille critique demain. Cela rend le risque plus imprévisible et amplifie le volume de nouvelles vulnérabilités qui se glissent dans le code.
Pour accompagner cette transition, nous sommes convaincus qu’il doit y avoir une séparation saine entre les outils qui génèrent le code et ceux qui le sécurisent. On ne peut pas être à la fois juge et partie. Pour que l’innovation soit durable, la sécurité doit être un tiers de confiance indépendant, capable de suivre ce rythme effréné.
La différence est fondamentale : là où un assistant IA a pour rôle principal de suggérer du code au développeur, un agent IA agit de façon autonome. Il peut accéder à des dépôts Git, modifier des pipelines CI/CD ou interagir avec des bases de données et des API tierces. Souvent dotés de droits excessifs et déployés dans des environnements qui n’ont pas été conçus pour eux, ces agents deviennent une nouvelle surface d’attaque critique.
L’indirect prompt injection (injection de prompt indirecte) en est le parfait exemple. Il s’agit d’une attaque où l’agent IA ingère une donnée externe (comme un ticket Jira, un repo externe ou un document) contenant des instructions malveillantes cachées. L’agent lit cette donnée et exécute la commande de l’attaquant à l’insu de l’utilisateur, ce qui peut mener à l’exfiltration de données ou la compromission du système.
Concrètement, l’arrivée des agents modifie profondément le paradigme défensif et nous devons repenser l’architecture sécurité de nos systèmes. Et je ne pense pas que l’industrie dispose d’une solution parfaite à ce jour.
Nous pouvons néanmoins aborder cette réflexion à travers trois piliers fondamentaux :
À cela s’ajoute un autre défi majeur : aujourd’hui, les personnes qui créent et déploient ces agents ne sont plus nécessairement des développeurs formés au code sécurisé. Il est donc indispensable de mettre en place des garde-fous de sécurité adaptés aux différentes typologies d’utilisateur.
Les approches traditionnelles de la sécurité applicative, fondées sur des contrôles ponctuels avant la mise en production, ne sont plus suffisantes dans un contexte où l’IA accélère considérablement le rythme de développement. Lorsque le code est généré, modifié et déployé en continu, les analyses de sécurité doivent être intégrées directement aux workflows de développement.
La sécurité ne peut plus être une étape finale de validation : elle doit s’intégrer aux nouveaux outils utilisés par les développeurs et devenir un processus continu, capable d’accompagner les équipes à la même vitesse que l’innovation.
Oui. Avant de déployer des agents autonomes en production, il est préférable d’avoir des bases solides : des responsabilités clairement définies, une bonne gestion des accès, des audits logs, des tests et un suivi humain.
Le plus sûr est de commencer avec des cas d’usage limités, puis d’élargir progressivement leur périmètre à mesure que l’organisation gagne en expérience.
Si je devais donner quelques pistes pour démarrer, je pense qu’il faut y aller par étapes : d’abord, pour le code généré, l’un des premiers réflexes est d’instaurer une séparation claire des rôles. C’est la fameuse logique de ne pas être « juge et partie » : l’outil qui produit le code ne devrait pas être le seul à valider sa sécurité. Avoir un regard indépendant est une excellente base.
Ensuite, concernant les agents IA, avant de chercher à tout verrouiller de manière complexe, on peut commencer par poser un cadre de gouvernance de bon sens. Cela veut dire cartographier qui a le droit de créer ces agents, définir à quelles données ils ont accès (pour éviter les droits excessifs) et maintenir une supervision humaine sur les actions critiques.
Les équipes doivent aussi être formées, car créer un agent IA ne requiert plus nécessairement d’être un développeur chevronné.
Enfin, pour visualiser concrètement le risque, il y a une image très simple et pratique partagée par l’expert Simon Willison, qu’il appelle la « Lethal Trifecta ». Il explique que le vrai signal d’alarme s’allume quand un agent IA réunit trois conditions en même temps : il a accès à des données confidentielles, il lit des informations provenant de sources non vérifiées (ce qui ouvre la porte aux injections de prompts), et il a le droit de mener des actions autonomes (comme envoyer des emails ou modifier un fichier).
Lisa Bouam, Enterprise Account Director Europe du Sud, Snyk
Lisa Bouam est Enterprise Account Director Europe du Sud chez Snyk, entreprise spécialisée dans la sécurité applicative pour les développeurs. Forte de plusieurs années d’expérience dans l’accompagnement des entreprises sur leurs enjeux technologiques, elle travaille au quotidien avec des organisations de toutes tailles pour les aider à sécuriser leurs applications et leurs environnements de développement.
Développeur web à Toulouse