Accélérer la remédiation sans ralentir les devs

Le Mean Time To Remediate est le KPI le plus important d'un programme DevSecOps — et le plus mal mesuré.

La plupart des organisations mesurent le MTTR comme le temps entre « ticket créé » et « ticket fermé ». C'est faux. Ce que ça mesure, c'est le temps entre la décision de prendre en charge et la clôture administrative. Pas le temps réel de résolution.

Le vrai MTTR se mesure entre « vulnérabilité détectée par l'outil de scan » et « fix mergé en main ». Cette définition inclut toutes les frictions du processus : triage, décision, affectation, compréhension, développement, revue, merge. C'est la seule métrique qui reflète la réalité opérationnelle.

Si vous êtes RSSI ou AppSec, vous connaissez le schéma : vous créez un ticket Jira à partir d'un finding SAST, vous l'affectez à une équipe, et rien ne se passe. Un mois plus tard, le ticket est toujours ouvert. Six mois plus tard, il est toujours ouvert.

Les devs ne sont pas de mauvaise foi. Vos tickets sont simplement ininterprétables. Voici ce qu'un ticket de sécurité typique contient :

• Un titre auto-généré du type « SQL Injection detected in UserRepository.java line 142 »
• Un lien vers le dashboard de l'outil SAST (que le dev n'a pas l'habitude d'ouvrir)
• Un CVSS score sans contexte
• Aucune indication du fix recommandé
• Aucune indication sur l'impact réel si on ne le corrige pas
• Aucune priorisation relative aux autres tickets que le dev a dans son sprint

« Quand je reçois un ticket comme ça, mon premier réflexe c'est de le mettre en « needs more info » et de le laisser dormir. Je n'ai pas le temps de devenir expert en sécurité pour comprendre. »

Un développeur en flow productif qui est interrompu par un ticket hors contexte met en moyenne 23 minutes à retrouver son niveau de concentration. C'est un chiffre mesuré par une étude de l'Université de Californie Irvine (Gloria Mark).

Multipliez ça par 20 tickets de sécurité mal formulés envoyés à une équipe dev par semaine, et vous avez mathématiquement anéanti une journée de développement productive — par équipe, par semaine. Le coût cumulé sur un an est considérable.

Entre la détection d'une vulnérabilité et le merge de son fix, il y a 7 étapes. Chaque étape est une source de friction.

1. 1Détection — l'outil de scan crée un finding.
2. 2Triage — quelqu'un décide s'il faut traiter ou ignorer.
3. 3Affectation — le finding est transformé en ticket et affecté à une équipe.
4. 4Compréhension — le dev doit comprendre le problème, souvent en se plongeant dans l'outil de scan qu'il ne connaît pas.
5. 5Décision — le dev évalue le fix et sa faisabilité.
6. 6Développement — le dev écrit le correctif.
7. 7Revue et merge — le correctif est relu et mergé.

Les étapes 1, 2, 3 et 4 peuvent être entièrement automatisées et contextualisées. Les étapes 5, 6 et 7 doivent rester humaines — mais peuvent être grandement accélérées par un contexte enrichi et une proposition de fix.

Un bon ticket de sécurité ne demande jamais au développeur d'ouvrir un autre outil. Toutes les informations dont il a besoin sont dans le ticket lui-même.

Ce qu'un ticket bien contextualisé contient

• Le fichier et la ligne exacte du code concerné, en lien cliquable vers le repo
• L'extrait de code vulnérable, directement inliné
• L'explication du problème en langage naturel, pas en jargon CVSS
• La recommandation de fix, avec un exemple de code corrigé
• L'impact business — exploité ou non, exposé à internet ou non, criticité de l'application
• La priorité relative par rapport aux autres tickets de sécurité de l'équipe
• Un lien vers l'outil qui a détecté le problème, pour les curieux — mais pas comme seule source d'information

La plupart des intégrations entre outils de sécurité et ticketing sont unidirectionnelles : la sécurité crée des tickets dans Jira, mais quand le dev ferme le ticket, l'outil de sécurité n'en sait rien.

Résultat : les dashboards sécurité restent pleins d'alertes déjà corrigées, et personne n'a confiance dans la donnée.

Une sync bidirectionnelle corrige ce problème. Quand le ticket est fermé côté dev, la vulnérabilité est automatiquement re-scannée pour vérifier qu'elle est effectivement corrigée, et le statut est remonté dans la plateforme de sécurité. Et inversement : si une vulnérabilité disparaît d'un scan, le ticket associé est fermé automatiquement.

Une politique de remédiation mature définit des SLAs différenciés par sévérité :

• Critique exploitée : 24h
• Critique non exploitée : 7 jours
• Haute : 30 jours
• Moyenne : 90 jours
• Faible : best effort

Ces SLAs doivent être tracés en temps réel — pas dans un Excel trimestriel. Et ils doivent être visibles par équipe, pour que les équipes qui tiennent leurs SLAs soient reconnues, et celles qui dérivent accompagnées.

L'état de l'art en 2026, c'est un agent IA qui lit le ticket, génère un correctif proposé, et ouvre une merge request que le développeur review et merge. Ce n'est pas de la science-fiction, ça tourne en production chez plusieurs organisations.

Ce que l'agent peut faire

• Comprendre le contexte du code autour de la vulnérabilité
• Proposer un fix cohérent avec les patterns du projet
• Ouvrir une MR avec description, tests et justification
• Réitérer sur les retours du code review

Ce que l'agent ne doit jamais faire

• Merger sans revue humaine
• Modifier du code critique (auth, paiement, crypto) sans validation explicite
• Décider seul de l'acceptabilité d'un risque résiduel