Comment piloter la maturité DevSecOps de vos équipes

En 2026, aucun Comex ne finance plus « la sécurité » sans métrique. NIS2, DORA, cyber-assurance, due diligence M&A : tous exigent désormais une mesure objective du niveau de maturité.

Le RSSI qui arrive devant son Board avec une slide « nous avons un SAST et un DAST » a perdu la conversation avant de commencer. Celui qui arrive avec un score de maturité chiffré, un benchmark par BU et une trajectoire sur 12 mois a gagné la sienne.

Trois frameworks font référence pour mesurer la maturité DevSecOps. Ils ne sont pas interchangeables : chacun répond à un besoin différent.

OWASP SAMM

Software Assurance Maturity Model. Cadre généraliste, couvre 5 fonctions (Gouvernance, Design, Implémentation, Vérification, Opérations) et 15 pratiques de sécurité. Recommandé pour une lecture « programme sécurité » de haut niveau.

DSOMM

DevSecOps Maturity Model (OWASP également). Plus opérationnel et plus orienté pipeline CI/CD que SAMM. Idéal pour une ETI tech qui veut mesurer la maturité au niveau de ses pipelines de livraison.

BSIMM

Building Security In Maturity Model. Cadre descriptif basé sur l'observation de centaines de programmes. Utile pour benchmarker son organisation par rapport à son secteur, moins pour piloter au quotidien.

La méthode historique de mesure SAMM repose sur des questionnaires annuels. Un responsable par équipe répond à 30–50 questions sur ses pratiques. Le score est calculé à partir de ces réponses.

Cette méthode a trois problèmes structurels.

1. 1Biais d'auto-évaluation : personne ne coche « niveau 1 » pour sa propre équipe. La moyenne des réponses est toujours tirée vers le haut.
2. 2Donnée froide : un questionnaire annuel ne reflète pas l'état réel du pipeline au moment de l'audit. Entre deux questionnaires, rien n'est tracé.
3. 3Pas actionnable : un score SAMM en PDF ne dit pas quelle vulnérabilité traiter demain matin. Il ne se branche sur aucun outil.

« Nous faisions un questionnaire SAMM tous les ans. Le score montait chaque année. Les incidents aussi. J'ai arrêté le questionnaire. »

La révolution de ces dernières années, c'est la capacité à calculer la maturité à partir de données réelles plutôt que de déclarations. Concrètement, au lieu de demander « faites-vous du SAST ? », on constate directement dans les pipelines CI/CD si un SAST tourne, à quelle fréquence, sur combien de repos, avec quel taux de triage des findings.

Ce qui change

• Le score devient continu et pas annuel.
• Il reflète la réalité et pas la perception.
• Il est actionnable : on peut cliquer sur un écart pour voir exactement quel pipeline ne respecte pas la pratique.
• Il est comparable d'une équipe à l'autre, parce qu'il est calculé avec la même méthode.

Un score de maturité utile se calcule sur 5 dimensions, qui correspondent aux 5 fonctions SAMM. Chacune doit être instrumentée avec des signaux objectifs issus des outils existants.

1. 1Gouvernance — existence et application d'une politique sécurité, formation des équipes, rôles et responsabilités.
2. 2Design — threat modeling, revue d'architecture sécurité, exigences de sécurité dans les user stories.
3. 3Implémentation — usage des outils SAST/SCA, gestion des secrets, sécurité des dépendances, sécurité du build.
4. 4Vérification — tests dynamiques, pentests, bug bounty, revues de code sécurité.
5. 5Opérations — gestion des vulnérabilités en production, monitoring, réponse aux incidents, patch management.

Voici la méthodologie que Cyber Coach applique pour calculer un score de maturité objectif par équipe.

1. 1Collecter les signaux — connexion API aux outils de sécurité, CI/CD et ticketing déjà en place.
2. 2Normaliser — mapper chaque signal à une pratique SAMM/DSOMM. Exemple : « SAST exécuté sur main à chaque push » = signal Implémentation-1 positif.
3. 3Calculer le score par pratique — pour chaque pratique, calculer un score 0–100 basé sur plusieurs signaux pondérés.
4. 4Agréger par dimension — moyenner les pratiques d'une dimension pour obtenir le score de dimension.
5. 5Agréger par équipe — score global d'équipe sur les 5 dimensions, projetable sur un radar.
6. 6Agréger par BU — moyenne pondérée des équipes d'une BU, utilisable en reporting Board.

Le benchmark interne est souvent plus puissant que le benchmark sectoriel. Il met en évidence les écarts entre équipes d'une même organisation et crée une dynamique de progrès.

Trois usages concrets du benchmark interne :

• Identifier les équipes leaders et les instituer comme référentes pour les autres.
• Cibler les équipes en retard et leur affecter des ressources de coaching.
• Créer un classement mensuel visible par le management opérationnel — à condition d'en faire un outil de progrès et pas de sanction.

Le Board ne lit pas les PDFs de 40 pages. Pour qu'un reporting DevSecOps passe devant un Comex, il faut trois graphiques et pas un de plus.

1. 1Le radar 5 dimensions — visualise la maturité actuelle de l'organisation, projetée sur les 5 fonctions SAMM. Lisible en 10 secondes.
2. 2La trajectoire 12 mois — courbe d'évolution du score global. Montre le sens de la marche. Plus important que le niveau absolu.
3. 3Le top 3 des écarts critiques — liste courte et actionnable des 3 points à corriger en priorité, avec l'impact business associé.