Mesurer le ROI d'un programme DevSecOps

La sécurité a un problème structurel avec le ROI : on mesure ce qui ne s'est pas passé. Un programme DevSecOps réussi, c'est un incident qu'on n'a pas eu. Comment chiffrer un non-événement ?

La réponse classique du RSSI — « combien vaut une violation que nous avons évitée ? » — ne marche pas devant un Comex. Le DAF répond immédiatement : « vous n'avez aucune preuve que vous l'avez évitée, vous n'avez peut-être simplement pas été attaqués ». Et il a raison.

Il faut donc changer d'angle. Au lieu de chiffrer un non-événement, on chiffre trois choses mesurables : la réduction du risque (en probabilité × impact), la productivité récupérée (en heures), et les coûts de conformité évités (en euros d'audit et d'amendes potentielles).

1. 1Réduction du risque — quantifiée en ALE (Annualized Loss Expectancy). C'est le levier le plus abstrait mais le plus critique.
2. 2Productivité dev récupérée — quantifiée en heures économisées × taux horaire × nombre de devs. C'est le levier le plus concret et le plus facile à défendre.
3. 3Coûts de conformité évités — quantifiée en coûts d'audit économisés + amendes évitées. C'est le levier qui parle au DAF.

L'Annualized Loss Expectancy est la méthode standard de quantification du risque. Elle se calcule simplement : ALE = ARO × SLE, où ARO est la fréquence annuelle d'occurrence et SLE le coût d'un incident.

Exemple concret

Sans programme DevSecOps mature : fréquence d'incident critique = 1 tous les 3 ans (ARO = 0,33), coût moyen d'un incident = 4,17 M€ (source IBM CoDB France 2024). ALE = 0,33 × 4 170 000 = 1 376 000 € / an.

Avec un programme DevSecOps mature (réduction de 50% selon Forrester TEI) : ALE = 688 000 € / an. Gain annuel : 688 000 €.

C'est le levier le plus défendable devant un DAF, parce qu'il est mesurable et vérifiable. La formule :

Exemple concret — ETI 200 devs

Un dev passe en moyenne 2h par semaine sur du triage, du context-switching et de la compréhension de tickets sécurité mal formulés. Avec un programme DevSecOps mature (tickets contextualisés, sync bidirectionnelle, priorisation automatique), ce chiffre tombe à 0,5h. Gain = 1,5h par dev par semaine.

Près d'un million d'euros par an de productivité récupérée sur une ETI de 200 devs. Ce chiffre est plus facile à défendre que la réduction du risque, parce qu'il peut être mesuré avant/après via les outils de suivi temps.

Le troisième levier parle directement au DAF et au Comex, parce qu'il se chiffre en coûts réglementaires évités. Deux sous-leviers.

Coûts d'audit réduits

Un audit de sécurité annuel (SOC 2, ISO 27001, NIS2) coûte entre 30 000 et 100 000 € en honoraires externes et représente 2 à 4 semaines de mobilisation interne. Un programme DevSecOps mature, avec des preuves automatisées et une traçabilité continue, réduit typiquement ce coût de 30 à 50%.

Amendes évitées

NIS2 prévoit des amendes jusqu'à 10 M€ ou 2% du CA mondial. DORA, pour le secteur financier, va jusqu'à 1% du CA mondial quotidien. Le RGPD jusqu'à 4% du CA mondial. Ces chiffres ne se matérialisent qu'en cas d'incident — mais ils doivent être probabilisés dans le business case.

Pour un programme DevSecOps, le ROI se calcule ainsi :

Où le Gain annuel total = Réduction d'ALE + Productivité récupérée + Coûts de conformité évités.

Paramètres

• Taille : 200 développeurs
• Secteur : industrie, pas soumis à DORA mais concerné NIS2
• Maturité DevSecOps initiale : niveau 1 (initial)
• Maturité cible à 12 mois : niveau 3 (mesuré)
• Coût annuel du programme (plateforme ASPM + temps équipe platform) : 180 000 €

Gains annuels

Gain annuel total = 1 744 000 €. Coût = 180 000 €. ROI = (1 744 000 − 180 000) / 180 000 × 100 = 869%. Payback = 1,2 mois.

Beaucoup de RSSI présentent leur ROI en disant : « si on évite une seule violation à 4 M€, le programme est rentable ». C'est techniquement vrai mais opérationnellement piégeux.

Le Comex entend : « vous n'avez pas de vraie justification, donc vous agitez un chiffre de peur ». La discussion est perdue.

Utilisez toujours les trois leviers en même temps, et commencez par la productivité (la plus concrète), puis la conformité (la plus réglementaire), et finissez par le risque (la plus stratégique). Dans cet ordre.