DevSecOps : l'ANSSI pointe les angles morts du marché AppSec en 2026

L'ANSSI vient de livrer son étude de marché S-SDLC/DevSecOps et le constat est plus dur qu'attendu : l'écosystème AppSec qui doit sécuriser la chaîne logicielle des entreprises européennes est, en 2026, encore largement inachevé. Pour les DPO et RSSI qui s'appuient sur ces outils pour étayer la conformité à l'article 32 du RGPD et à NIS 2, le message est clair : les solutions du marché ne suffisent pas, et la documentation des décisions devient critique.

Ce qui s'est passé

L'agence française a publié le 27 avril 2026 une analyse à deux étages : un état de la recherche académique et industrielle sur le DevSecOps, puis une cartographie du marché autour de douze catégories de solutions AppSec — du SAST au RASP, en passant par les SBOM (Software Bill of Materials), les scanners IaC, la gestion des secrets et l'ASPM (Application Security Posture Management).

Verdict : « la recherche académique et industrielle a une influence limitée » sur la pratique. Sur huit publications retenues — dont certaines non évaluées par les pairs — l'ANSSI relève une fragmentation des approches, un focus excessif sur des aspects techniques isolés (enrichissement des SBOM, automatisation CI/CD, supply chain logicielle) et l'absence de modèle holistique. Les tests en conditions réelles manquent. Côté marché, les entretiens menés avec 13 fournisseurs (dont 6 européens) et 9 organisations utilisatrices, via le référentiel de maturité OWASP DevSecOps, révèlent une tendance à la « plateformisation » mais des intégrations encore partielles, notamment entre gestion des SBOM et détection des vulnérabilités.

Et l'IA, présentée comme la solution miracle aux faux positifs du SAST ? L'ANSSI tranche : « insuffisante pour réduire significativement les faux positifs ou améliorer la priorisation après analyse ». Les organisations attendent que les fournisseurs basculent des LLM généralistes vers des modèles spécialisés. La remédiation reste complexe, en particulier sur les scanners de secrets et les analyses SCA, qui exigent parfois une restructuration importante du code.

Pourquoi c'est important

Cette étude n'est pas un rapport technique réservé aux développeurs. Elle s'inscrit dans une séquence de publications de l'ANSSI qui dessine, mois après mois, l'« état de l'art » que la CNIL invoquera demain pour qualifier la diligence d'une organisation au sens de l'article 32 du RGPD. Quand la feuille de route cyber de l'État jusqu'en 2030 impose authentification multifacteur, EDR/XDR et cryptographie post-quantique, elle suppose que la chaîne logicielle qui livre ces dispositifs soit elle-même sécurisée. Or l'ANSSI vient de dire que ce maillon-là reste fragile.

L'analyse rejoint celle du Future of Privacy Forum sur la gouvernance cyber face aux intégrations tierces et à l'IA : sans cartographie réelle des dépendances logicielles, sans questionnaires sécurité actualisés pour les sous-traitants, l'article 28 du RGPD et NIS 2 deviennent des coquilles vides. Et les avis successifs du CERT-FR — Stormshield, Atlassian, Splunk, Schneider Electric — montrent que les chaînes de remédiation imparfaites pointées par l'ANSSI ne sont pas théoriques : ce sont des incidents potentiels article 33.

Ce que ça change pour les organisations

Trois actions concrètes pour les DPO et RSSI cette semaine :

1. Auditer les outils AppSec déployés au regard des 12 catégories ANSSI. Si l'organisation ne couvre pas a minima SAST, SCA/SBOM, gestion des secrets et scan IaC, il y a une lacune documentée. Cette absence devra être justifiée dans le registre des traitements ou dans la documentation NIS 2.

2. Documenter les limites des fournisseurs AppSec. L'ANSSI reconnaît que l'IA des outils du marché ne réduit pas significativement les faux positifs. Cela signifie qu'une partie du tri reste humaine. Le DPO doit s'assurer que la chaîne de triage des vulnérabilités est tracée — y compris les vulnérabilités écartées comme faux positifs — pour démontrer la diligence en cas de contrôle.

3. Renforcer les questionnaires de sous-traitants éditeurs de logiciels. Demander explicitement la liste des solutions AppSec utilisées (SAST, DAST, SCA), la fréquence des scans, la politique de gestion des secrets et la maturité OWASP DevSecOps déclarée. Un éditeur incapable de répondre est un signal faible que l'organisation doit consigner — et qui pèsera dans l'analyse de risque imposée par l'article 32.

Ce que Leto pense de cette décision

L'étude de l'ANSSI a le mérite de dire tout haut ce que beaucoup de RSSI constatent en silence : le marché AppSec promet plus qu'il ne tient. Pour les DPO, c'est une opportunité — celle de sortir d'une posture de cocher-cases technique pour reprendre la main sur la documentation des choix. Une organisation qui démontre qu'elle a évalué les limites de ses outils et compensé par des contrôles humains tracés sera mieux protégée juridiquement qu'une organisation qui a empilé les solutions sans les questionner. La conformité, en 2026, se gagne autant dans la preuve documentée que dans la technologie déployée.

Sources : Silicon — Recherche, IA, intégrations… Les angles morts du DevSecOps · ANSSI — Étude de marché S-SDLC/DevSecOps (v1.0) · OWASP DevSecOps Maturity Model