Les nouveaux risques de sécurité du cycle de développement agentique

À retenir

• Le cycle de développement agentique désigne le processus par lequel des agents d’IA planifient, créent, modifient, testent et livrent des logiciels en interagissant avec des outils, des bases de code et des environnements

• Le risque apparaît désormais avant que le code n’atteigne le dépôt. La question centrale de sécurité passe ainsi de « Ce code est-il sécurisé ? » à « Peut-on faire confiance au système qui l’a créé ? »

• Les agents introduisent des risques à trois niveaux : ce qu’ils utilisent, ce qu’ils font et ce qu’ils génèrent

• La sécurité applicative traditionnelle protège l’artefact, tandis que le développement agentique exige de sécuriser le processus qui le crée.

• Des contrôles continus intégrés aux workflows des agents offrent aux développeurs et aux agents des limites de confiance qui leur permettent d’avancer rapidement.

Pendant des années, la sécurité des applications s’est fondée sur une hypothèse simple : les logiciels suivent un cycle de vie, et la sécurité inspecte les artefacts au fil de leur progression du développement à la production. Les développeurs planifient, écrivent le code, le valident, le testent, l’analysent et le livrent. Tous les contrôles mis en place — revues de pull requests, étapes de validation CI/CD et analyses après commit — partaient du principe qu’une personne intervenait entre chaque étape pour prendre des décisions qu’un outil pourrait ensuite vérifier.

Les agents d’IA remettent cette hypothèse en cause : les logiciels ne sont plus simplement écrits par des humains puis vérifiés. Ils sont de plus en plus assemblés, modifiés et exécutés par des systèmes autonomes capables d’agir avant qu’un contrôle traditionnel puisse en examiner le résultat. Le « développeur » n’est pas toujours une personne. Parfois, c’est le système lui-même qui effectue le travail.

Cette évolution porte un nom qu’il est important de comprendre : le cycle de développement agentique. Elle change le point d’apparition des risques dans vos logiciels, et donc ce que vous devez sécuriser.

Qu’est-ce que le cycle de développement agentique ?

Le cycle de développement agentique désigne le processus par lequel des agents d’IA planifient, créent, modifient, testent et livrent des logiciels en interagissant avec des outils, des bases de code, des sources de données et des environnements de développement.

Le SDLC traditionnel est piloté par des humains, axé sur les artefacts et rythmé par des points de contrôle : le travail avance par étapes et la sécurité inspecte le résultat de chacune d’elles. Le cycle de développement agentique est différent : il est piloté par des agents, dynamique, continu et orienté vers l’action. Un agent peut interpréter un objectif, choisir un outil, modifier des fichiers, exécuter un script, appeler une API, ajouter une dépendance et générer du code prêt pour la production, souvent en une seule séquence ininterrompue.

Cela ne remplace pas le SDLC, mais vient s’y superposer et l’accélérer. Les agents produisent toujours du code, des dépendances, des configurations, des API et des modifications d’infrastructure. Ils le font simplement dans des workflows beaucoup plus difficiles à observer et à gouverner que lorsqu’un développeur écrit dans un IDE.

Pourquoi le développement agentique change le modèle de risque

La sécurité applicative traditionnelle part du principe que les risques résident dans les artefacts : code source, dépendances open source, conteneurs, infrastructure as code et API. C’est toujours vrai, mais le développement agentique étend la surface d’attaque au système qui produit ces artefacts. La question de sécurité passe de « Ce code est-il sécurisé ? » à « Peut-on faire confiance au système qui l’a créé ? » C’est une autre question, à laquelle la plupart des programmes de sécurité ne sont pas encore en mesure de répondre.

Les trois points de contrôle du cycle de développement agentique

Pour comprendre ce nouveau cycle, il est utile d’examiner les trois sources de risque introduites par les agents : les données et outils qu’ils utilisent, les actions qu’ils effectuent et les résultats qu’ils génèrent. Si le risque apparaît en continu, vous devez l’examiner à trois niveaux : ce que les agents utilisent, ce qu’ils font et ce qu’ils génèrent.

1. Ce que les agents utilisent

Les agents ne partent pas de zéro : ils s’appuient sur des serveurs MCP, des compétences, des API, des outils externes, des sources de données et des intégrations de développement pour accomplir leur travail. Ces éléments peuvent intégrer votre chaîne d’approvisionnement logicielle, même s’ils n’ont jamais été déclarés comme des dépendances traditionnelles. En outre, ils sont souvent sélectionnés et appelés à l’exécution, sans aucune vérification.

Parmi les risques : des serveurs MCP non approuvés, des compétences vulnérables ou malveillantes, des outils externes à la provenance incertaine et des outils d’IA que personne ne suit. Ce n’est pas une hypothèse : les recherches de Snyk ont identifié 76 compétences malveillantes confirmées parmi 3 984 analysées, et environ un tiers des serveurs MCP publics présentent des failles exploitables.

Si vous ne savez pas ce que les agents utilisent, vous ne pouvez pas savoir quels risques s’introduisent dans le workflow de développement.

2. Ce que font les agents

Les agents ne se contentent pas de suggérer une modification et d’attendre : ils exécutent des scripts, interrogent des systèmes internes, modifient des fichiers et appellent des API à la vitesse d’une machine.

Cela crée des risques liés à l’exécution de commandes dangereuses, à l’accès non autorisé à des systèmes ou à des données, à l’exposition de données via des appels d’outils, à l’injection de prompt dans les workflows de développement et à des enchaînements d’actions imprévisibles. Un exemple concret : un agent de programmation qui a ignoré plusieurs consignes de « gel », supprimé une base de données de production, puis fabriqué des enregistrements pour masquer son erreur. L’agent a poursuivi son raisonnement à partir d’un petit obstacle, avec les autorisations dont il disposait.

Le comportement des agents doit être gouverné en temps réel, car leurs actions peuvent se produire plus vite qu’une intervention humaine.

3. Ce que les agents génèrent

Les agents génèrent du code et des dépendances qui intègrent vos logiciels. Même si le résultat semble fonctionnel, le code généré par l’IA peut comporter des vulnérabilités, des pratiques non sécurisées ou des erreurs de configuration par défaut.

La sécurité applicative traditionnelle part du principe que le code peut être vérifié après sa rédaction. Mais dans le développement agentique, les résultats sont créés à la vitesse d’une machine et peuvent passer de la suggestion au commit avant que la sécurité sache ce qui a changé ou pourquoi. Le risque ne tient pas seulement au fait que le code généré par l’IA puisse être non sécurisé. Il tient aussi au fait qu’un résultat non sécurisé peut être introduit plus tôt, répliqué plus rapidement et livré avant que les points de contrôle traditionnels ne puissent intervenir.

L’analyse après commit ne suffit plus : la sécurité doit valider les résultats générés par les agents dès leur création.

Pourquoi les points de contrôle traditionnels de sécurité applicative ne suffisent pas

Cela ne signifie pas que la sécurité applicative traditionnelle n’a plus d’importance. Vous devez toujours analyser le code, les dépendances, les conteneurs et l’infrastructure. Ces fondations sont plus importantes que jamais, car l’IA ne remplace pas votre chaîne d’approvisionnement logicielle : elle l’accélère.

Mais les points de contrôle traditionnels ont été conçus pour un monde où les humains prenaient la plupart des décisions de développement, où le code était le principal artefact à inspecter et où les risques pouvaient souvent être détectés au moment du commit, de la compilation ou du déploiement. La sécurité ne peut plus s’appuyer uniquement sur des contrôles en aval : elle doit s’intégrer au workflow agentique. La sécurité applicative traditionnelle protège l’artefact. Agentic Development Security protège le processus qui le crée.

Ce qu’exige la sécurisation du cycle de développement agentique

Sécuriser ce cycle ne signifie pas ralentir les développeurs en ajoutant une nouvelle étape de revue ni interdire les outils d’IA. Il s’agit de donner aux agents des limites de confiance afin que les équipes puissent les adopter en toute sécurité. Concrètement, cela nécessite des contrôles intégrés aux workflows dans lesquels les agents agissent.

Les équipes de sécurité doivent découvrir quels agents, outils, compétences et serveurs MCP sont utilisés ; vérifier si ces éléments sont fiables ; gouverner les accès et les actions autorisés des agents ; appliquer les politiques pendant leurs workflows ; valider en temps réel le code et les dépendances générés ; et conserver une piste d’audit de l’activité de développement pilotée par les agents.

L’idée centrale est d’assurer une supervision continue, en plaçant la sécurité suffisamment près de l’agent pour évaluer les risques avant qu’ils ne deviennent un artefact validé, une action exécutée ou une vulnérabilité déployée.

Le cycle a changé. La sécurité doit évoluer avec lui.

Le cycle de développement agentique n’est pas simplement un SDLC plus rapide. C’est une autre façon de créer des logiciels, dans laquelle des systèmes autonomes peuvent utiliser des outils, agir et générer des résultats en continu. Cette évolution soulève des questions de sécurité auxquelles les contrôles fondés sur des points de vérification n’ont jamais été conçus pour répondre seuls.

Pour déployer le développement assisté par l’IA à grande échelle en toute sécurité, les équipes ont besoin de visibilité et de contrôle sur l’ensemble du cycle : ce que les agents utilisent, ce qu’ils font et ce qu’ils génèrent. L’objectif n’est pas de freiner l’adoption de l’IA, mais de donner aux développeurs et aux agents des limites de confiance qui leur permettent d’avancer rapidement, tandis que la sécurité opère en continu en arrière-plan.

Vous souhaitez approfondir la façon dont les agents d’IA dépassent les contrôles traditionnels ? Téléchargez dès aujourd’hui la fiche pratique.