Qu’est-ce que l’AppSec agentique ?

L’AppSec agentique (sécurité agentique des applications) consiste à confier à une équipe d’agents de sécurité IA l’ensemble du programme de sécurité des applications d’une organisation : comprendre l’application, modéliser ses menaces, détecter les vulnérabilités importantes, déterminer lesquelles méritent d’être corrigées, générer et valider les corrections, et prouver qu’elles tiennent la route. Cette approche s’applique en continu au nouveau code comme au backlog existant.

On confond facilement ce terme avec la sécurité de l’IA agentique, mais les deux notions désignent des démarches opposées : la sécurité de l’IA agentique protège les agents IA contre les attaques, tandis que l’AppSec agentique met les agents IA au service de la sécurité. Le recours à des agents pour exécuter le programme répond à un enjeu de volume : les logiciels sont désormais livrés plus vite qu’un programme de sécurité piloté par des humains ne peut les traiter.

Pourquoi la sécurité des applications a-t-elle besoin d’un nouveau modèle opérationnel ?

La sécurité des applications a besoin d’un nouveau modèle opérationnel, car le rythme de développement du code a changé et un programme conçu pour l’ancien rythme ne peut pas absorber le nouveau.

Dans un programme traditionnel, les problèmes sont détectés puis transmis à des personnes. Celles-ci prennent alors en charge tout ce qui suit leur détection : le triage, la priorisation, la correction, le risque de régression et les échanges avec l’équipe de développement. Cette organisation fonctionnait tant que les humains écrivaient la majeure partie du code. Aujourd’hui, les agents de codage IA génèrent davantage de code que les processus de revue ne peuvent en traiter, et les failles qu’ils introduisent se concentrent dans la logique métier et les autorisations, des domaines où les analyses fondées sur des motifs n’ont rien à repérer.

Le backlog existant accentue la pression. Chaque organisation traîne des années de problèmes non résolus, et les attaquants automatisent désormais l’exploration de ce backlog et l’enchaînement de problèmes de faible gravité pour créer des exploits critiques. En juin 2026, Snyk constate l’introduction d’environ six nouvelles vulnérabilités pour chaque vulnérabilité corrigée.

Quand le flux entrant dépasse le flux sortant, un meilleur classement ne fait que produire une file d’attente de même taille, mais mieux ordonnée. Le principal obstacle n’est plus la détection des problèmes, mais leur résolution. Pour en traiter autant, il faut un modèle opérationnel différent, et non une version plus rapide du modèle actuel.

Que comprend le cycle AppSec ?

L’AppSec agentique répond à cette contrainte en confiant le cycle de sécurité des applications à une équipe d’agents. Chaque agent a une tâche et un déclencheur définis. Ensemble, ils travaillent en continu sur le nouveau code et sur tout ce qui a déjà été livré. Le cycle comprend six étapes, chacune reposant sur le résultat de la précédente :

1. Comprendre l’application. Modéliser son architecture, ses flux de données, la classification de ses données, ses limites de confiance et ce qui s’exécute réellement en production.

2. Modéliser ses menaces. S’appuyer sur ce modèle pour déterminer comment l’application peut être attaquée et quelles faiblesses peuvent avoir de véritables conséquences, puis maintenir le modèle de menaces à jour au fil des modifications du code.

3. Détecter les vulnérabilités importantes. Combiner l’analyse déterministe avec le raisonnement de l’IA, capable de repérer des catégories qu’aucune signature ne décrit, comme les failles de logique métier et d’autorisation.

4. Déterminer ce qui mérite d’être corrigé. Classer les problèmes par ordre de priorité et définir les critères d’une correction adéquate, en tenant compte de l’accessibilité, de l’exploitabilité et de l’historique des résultats de correction.

5. Générer et valider les corrections. Produire des modifications qui résolvent le problème, passent la revue et sont intégrées.

6. Prouver que les corrections tiennent la route. Confirmer chaque résultat au moyen d’un système différent de celui qui l’a produit, puis consigner la décision et son raisonnement.

Il s’agit d’un cycle, pas d’un pipeline : il s’exécute en continu, et non à un seul point de contrôle, et chaque étape s’appuie sur le modèle créé lors de la première. Les personnes responsables du programme cessent de gérer la file d’attente et supervisent désormais le système qui s’en charge.

À quelles conditions les agents peuvent-ils exécuter un programme de sécurité ?

Trois conditions doivent être réunies pour que les agents exécutent un programme de sécurité. La troisième distingue un programme opérationnel d’un programme simplement crédible en apparence.

• Les agents doivent s’appuyer sur des bases solides : Sans modèle de l’application, un agent peut formuler avec assurance des constats concernant une base de code qu’il a en partie imaginée. Le modèle partagé, construit à la première étape du cycle et appelé par Snyk « application-context graph », est consulté par chaque agent avant d’agir.

• Le travail doit être délimité : Chaque tâche a un objectif, un déclencheur, une entrée et un résultat final clairement définis. Les agents qui savent où chercher en premier, parce que le modèle de menaces le leur indique, sont plus précis et moins coûteux à exécuter que ceux qui explorent sans ciblage.

• La validation doit être effectuée par un tiers : On ne peut pas confier à l’agent qui détecte une vulnérabilité la validation de sa propre correction. Un système qui évalue ses propres résultats reprend à son compte toutes les hypothèses de son analyse, et un modèle plus puissant ne fait que produire une réponse erronée plus convaincante. C’est pourquoi les moteurs déterministes sont d’autant plus importants dans un programme agentique : ils constituent les outils utilisés par les agents et vérifient leurs résultats de manière indépendante. Dans Snyk VulnBench JS 1.0, près de la moitié des constats issus uniquement d’un LLM n’apparaissaient que lors d’une seule des cinq exécutions identiques.

Quelle différence entre l’AppSec agentique et la sécurité de l’IA agentique ?

L’AppSec agentique utilise des agents IA pour sécuriser les logiciels, tandis que la sécurité de l’IA agentique protège les agents IA eux-mêmes. Les conditions décrites plus haut concernent les agents qui effectuent des tâches de sécurité. La protection des agents relève d’une discipline distincte, et une grande partie des contenus publiés sous des termes similaires porte plutôt sur ce sujet.

• La sécurité de l’IA agentique protège les agents IA. Un agent dispose d’une mémoire, appelle des outils, détient des identifiants et agit sans qu’une personne approuve chacune de ses actions. Cela crée des risques que la sécurité conventionnelle des applications n’a pas été conçue pour couvrir. L’injection de prompt, l’utilisation abusive des outils et les autorisations trop étendues des agents en font partie.

• L’AppSec agentique met les agents IA au service de la protection des logiciels. Les agents sont les praticiens ; le programme de sécurité des applications constitue leur travail.

Une organisation qui adopte le développement assisté par l’IA à grande échelle a besoin des deux. Ces approches nécessitent des contrôles, des responsables et des critères d’évaluation différents. Une équipe qui achète l’une en pensant qu’elle couvrira aussi l’autre laissera le second besoin sans réponse.

Qu’est-ce qui change pour les équipes ?

Confier le cycle aux agents change le rôle des personnes qui l’entourent, mais pas leurs responsabilités. Voici trois changements apportés par l’AppSec agentique :

1. Les développeurs passent de la création à l’approbation. Ils examinent des modifications qu’ils n’ont pas écrites, ce qui rend les éléments justificatifs associés à chaque modification plus importants qu’auparavant.

2. Les responsables AppSec passent de gardiens du processus à responsables du programme. Leur rôle n’est plus de trier une file d’attente qui grossit plus vite que quiconque ne peut la traiter, mais de définir les conditions permettant de faire confiance aux corrections et de prouver que le programme fonctionne.

3. La responsabilité reste la même. La personne responsable du programme le reste, d’où la nécessité de disposer d’une piste d’audit couvrant les décisions de l’agent, les éléments sur lesquels il a agi et les moyens de vérifier le résultat. La personne passe du rôle d’opérateur à celui d’auditeur ; la piste d’audit lui permet d’assumer ce rôle.

L’AppSec agentique en pratique

L’AppSec agentique répond à un problème de cadence : le code arrive désormais plus vite qu’un programme piloté par des humains ne peut le traiter. Des agents qui s’appuient sur un modèle de l’application, dont les tâches sont délimitées et dont les résultats sont vérifiés de manière indépendante permettent au programme de suivre le rythme, tandis que les équipes en définissent la conception et apportent les preuves de son efficacité.

L’approche de Snyk en matière d’AppSec agentique

Evo Agentic AppSec, qui fait partie de la Snyk AI Security Platform, met une équipe d’agents de sécurité aux côtés de chaque équipe d’ingénierie pour gérer l’ensemble du programme AppSec : comprendre, détecter, corriger et vérifier. Les agents exécutent les tâches, tandis que la couche d’intelligence de Snyk détermine ce qui constitue une bonne correction, en s’appuyant sur dix ans de données sur les résultats des corrections, ainsi que sur l’analyse de l’accessibilité, de l’exploitabilité et de la facilité de correction. Les moteurs déterministes de Snyk vérifient ensuite les résultats de manière indépendante. Comme Snyk s’intègre aux workflows de développement déjà utilisés par les équipes et ne dépend d’aucun fournisseur de modèles, la vérification reste distincte des modèles qui génèrent le code. Découvrez en avant-première Evo Agentic AppSec.

Vous souhaitez mettre une équipe d’agents de sécurité aux côtés de chaque ingénieur ? Contactez dès aujourd’hui votre responsable de compte Snyk.