Vous avez compris la théorie DevSecOps : les Three Ways, le modèle CALMS, les métriques DORA. Reste la question qui bloque la plupart des équipes : comment passer à la pratique sans se perdre entre outils, rôles et priorités ? Ce guide répond avec un parcours structuré en cinq parties, des exemples concrets et des outils actionnables, pensé pour un responsable technique ou un lead qui doit lancer ou relancer une transformation DevSecOps.
Vue d'ensemble du parcours d'implémentation
Section intitulée « Vue d'ensemble du parcours d'implémentation »Le parcours suit une progression logique : évaluer où vous en êtes, organiser vos équipes, former vos collaborateurs, mesurer les résultats, puis livrer en continu. Chaque partie s'appuie sur la précédente : inutile d'automatiser un pipeline (partie 5) si personne n'a été formé (partie 3) ou si vous ignorez votre point de départ (partie 1).
| Partie | Objectif | Durée lecture | Chapitres |
|---|---|---|---|
| 1, Évaluer | Établir votre baseline | 30 min | 2 chapitres |
| 2, Organiser | Structurer vos équipes | 45 min | 4 chapitres |
| 3, Former | Développer les compétences | 30 min | 2 chapitres |
| 4, Mesurer | Piloter par les données | 30 min | 2 chapitres |
| 5, Livrer | Automatiser le delivery | 30 min | 3 chapitres |
| Annexe | Comprendre les rôles | 20 min | 8 fiches métiers |
Partie 1, Évaluer
Section intitulée « Partie 1, Évaluer »Objectif : savoir d'où vous partez pour prioriser vos actions.
Avant de lancer une transformation, vous devez mesurer votre maturité actuelle. Sans baseline, impossible de démontrer un progrès ni de justifier un investissement auprès de la direction. Cette partie donne les outils pour établir un diagnostic objectif plutôt qu'une impression subjective.
-
Audit de maturité DSOMM
Évaluez votre niveau sur les 5 dimensions du modèle OWASP DSOMM (DevSecOps Maturity Model) : Build & Deployment, Culture & Organization, Implementation, Information Gathering, Test & Verification. Identifiez vos forces et vos lacunes dimension par dimension.
-
Les 4 piliers qualité
Comprenez les 4 piliers d'un système de qualité (Sécurité, Fiabilité, Exploitabilité, Maintenabilité) et identifiez vos priorités concrètes.
Partie 2, Organiser
Section intitulée « Partie 2, Organiser »Objectif : structurer vos équipes pour maximiser le flux de valeur.
La structure de vos équipes détermine la qualité de vos logiciels (loi de Conway). Cette partie apprend à appliquer Team Topologies, le modèle d'organisation d'équipes formalisé par Matthew Skelton et Manuel Pais, à mapper les rôles, à construire une plateforme interne et à réduire la friction entre développement et sécurité. En 2026, ce cadre est devenu la référence commune de facto pour organiser les équipes de delivery : la plupart des organigrammes techniques s'y réfèrent explicitement ou convergent vers les mêmes structures sans le savoir.
-
Team Topologies
Les 4 types d'équipes et les 3 modes d'interaction. Comment passer de la théorie à la pratique, sans réorganisation big-bang.
-
Mapper rôles x topologies
Où placer le SRE, le Platform Engineer, le Security Champion selon le contexte et la taille de l'organisation.
-
Platform Engineering
Construire une plateforme interne (IDP) traitée comme un produit, avec des Golden Paths qui réduisent la charge cognitive des équipes stream-aligned.
-
Collaboration Dev-Sec
Boucles de feedback, culture blameless, réduction de la friction entre équipes.
Partie 3, Former
Section intitulée « Partie 3, Former »Objectif : développer les compétences sécurité dans toute l'organisation.
Les outils ne suffisent pas. Sans transformation culturelle, vous aurez une CI/CD techniquement parfaite et toujours autant de silos entre équipes. Cette partie apprend à former vos collaborateurs et à créer un réseau de Security Champions, des développeurs volontaires qui relaient les bonnes pratiques sécurité dans leur équipe.
-
Security Champions
Créer un réseau d'ambassadeurs sécurité dans chaque équipe. Recrutement, formation, animation, mesure de l'impact.
-
Formation des équipes
Parcours de formation, CTF (Capture The Flag), gamification, montée en compétences progressive.
Partie 4, Mesurer
Section intitulée « Partie 4, Mesurer »Objectif : piloter votre transformation par les données.
Ce qui ne se mesure pas ne s'améliore pas. Cette partie apprend à implémenter les métriques DORA et les KPIs sécurité pour démontrer la valeur de vos efforts et prioriser les actions plutôt que de deviner. Le référentiel DORA a évolué fin 2025 : aux 4 métriques historiques (Deployment Frequency, Lead Time, Change Failure Rate, Failed Deployment Recovery Time, ex-MTTR) s'ajoute désormais une cinquième mesure, le Rework Rate, qui suit la proportion de déploiements non planifiés. Le rapport annuel s'appelle depuis 2025 le State of AI-assisted Software Development, reflet de l'impact de l'IA générative sur le delivery logiciel.
-
Métriques DORA
Implémenter les 4 métriques historiques (Deployment Frequency, Lead Time, Change Failure Rate, Failed Deployment Recovery Time) et comprendre l'évolution récente du modèle.
-
KPIs Sécurité
Métriques sécurité : MTTD (délai moyen de détection d'une vulnérabilité), MTTR vulnérabilités (délai moyen de correction, à ne pas confondre avec l'ancien MTTR de DORA renommé Failed Deployment Recovery Time), couverture de scan, dette sécurité.
Partie 5, Livrer
Section intitulée « Partie 5, Livrer »Objectif : automatiser le delivery pour livrer de la valeur en continu.
C'est la mise en pratique technique du parcours. Cette partie couvre le CI/CD, le GitOps et les SLI/SLO (indicateurs et objectifs de niveau de service) pour livrer rapidement et de manière fiable, sans sacrifier la stabilité à la vitesse.
-
CI/CD
Du code à la production. Architecture de pipeline, security gates, stratégies de déploiement continu.
-
GitOps
Git comme source de vérité. ArgoCD, Flux, réconciliation automatique de l'état désiré.
-
SLI, SLO & Error Budgets
Définir et piloter la fiabilité avec des objectifs mesurables plutôt qu'une exigence de « zéro incident ».
Annexe, Carrières DevOps
Section intitulée « Annexe, Carrières DevOps »Objectif : comprendre les différents rôles et leurs responsabilités.
Cette annexe présente les fiches métiers de l'écosystème DevOps et DevSecOps. Pour chaque rôle : missions, compétences attendues, parcours d'évolution et fourchette de rémunération quand elle est documentée.
Par où commencer ?
Section intitulée « Par où commencer ? »Le tableau ci-dessous évite de lire les cinq parties dans l'ordre quand ce n'est pas nécessaire. Il associe une situation de départ courante à un parcours de lecture raccourci, pour que vous alliez directement au chapitre qui répond à votre urgence du moment.
| Votre situation | Parcours recommandé |
|---|---|
| Débutant complet | Lire d'abord les Fondamentaux, puis revenir ici |
| Nouveau projet | Partie 5 (CI/CD) puis Partie 1 (4 piliers) |
| Organisation existante | Partie 1 (Audit) puis Partie 2 (Team Topologies) |
| Problème de collaboration | Partie 2.4 (Collaboration) puis Partie 3 (Formation) |
| Besoin de justifier le ROI | Partie 4 (Métriques) puis Partie 1 (Audit) |
| Recruter ou évoluer | Annexe Carrières |
Liens avec les Fondamentaux
Section intitulée « Liens avec les Fondamentaux »Ce parcours d'implémentation s'appuie sur les concepts théoriques présentés dans les Fondamentaux. Le tableau suivant fait le pont explicite entre chaque notion et son application pratique dans ce parcours, pour éviter de relire la théorie si vous l'avez déjà assimilée.
| Concept (Fondamentaux) | Application (Implémentation) |
|---|---|
| Three Ways & CALMS | Structure des équipes (Partie 2) |
| Métriques DORA | Implémentation DORA (Partie 4) |
| Shift-Left | Pipeline sécurisé (Partie 5) |
| SLO, SLI & Error Budgets | SRE en pratique (Partie 5) |
À retenir
Section intitulée « À retenir »- Une transformation DevSecOps qui saute l'étape évaluer (audit DSOMM, 4 piliers qualité) avance à l'aveugle et ne peut pas démontrer de progrès.
- Team Topologies (4 types d'équipes, 3 modes d'interaction) est devenu en 2026 le vocabulaire commun pour organiser les équipes de delivery, avant même le choix des outils.
- Le Platform Engineering est la suite logique de Team Topologies : une plateforme interne traitée comme un produit réduit la charge cognitive des équipes stream-aligned.
- La culture (Security Champions, formation) compte autant que la technique : un pipeline parfait sur une organisation en silos ne transforme rien.
- Les métriques DORA ont évolué fin 2025 vers 5 indicateurs avec l'ajout du Rework Rate, en plus des 4 métriques historiques de vitesse et de stabilité.
- CI/CD, GitOps et SLO forment le socle technique du delivery continu : ils arrivent en dernier, une fois l'organisation et la culture posées.
- Les 8 fiches métiers de l'annexe aident à situer chaque rôle (SRE, Platform Engineer, DevSecOps Engineer...) dans une organisation Team Topologies.
- Le tableau Par où commencer évite de lire les 5 parties dans l'ordre quand une urgence précise (ROI, collaboration, nouveau projet) prime.