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 | 10 min | 6 pages métier |
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.
-
Évaluez votre niveau sur les 5 dimensions du modèle OWASP DSOMM (DevSecOps Maturity Model, un référentiel de maturité) : Build & Deployment, Culture & Organization, Implementation, Information Gathering, Test & Verification. Identifiez vos forces et vos lacunes dimension par dimension.
-
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.
-
Les 4 types d'équipes et les 3 modes d'interaction. Comment passer de la théorie à la pratique, sans réorganisation big-bang.
-
Où placer le SRE, le Platform Engineer, le Security Champion selon le contexte et la taille de l'organisation.
-
Construire une plateforme interne (IDP) traitée comme un produit, avec des Golden Paths qui réduisent la charge cognitive des équipes stream-aligned.
-
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.
-
Créer un réseau d'ambassadeurs sécurité dans chaque équipe. Recrutement, formation, animation, mesure de l'impact.
-
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é en 2024 : 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.
-
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.
-
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.
-
Du code à la production. Architecture de pipeline, security gates, stratégies de déploiement continu.
-
Git comme source de vérité. ArgoCD, Flux, réconciliation automatique de l'état désiré.
-
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.
Les métiers de l'écosystème DevOps et DevSecOps ont chacun leur page sur ce site : leurs responsabilités, les missions qui en découlent, les compétences attendues avec leur niveau, et les formations qui les enseignent. Le catalogue des métiers les présente tous.
Chaque page détaille un poste : l'ingénieur fiabilité (SRE) pour la fiabilité, l'ingénieur plateforme pour la plateforme interne, l'ingénieur DevSecOps pour la sécurité intégrée, l'ingénieur CI/CD pour la livraison, l'ingénieur cloud pour l'infrastructure et l'administrateur Linux pour le socle système. Release Manager, Architecte DevOps et FinOps n'ont pas de page métier, faute de formation qui les couvre : la matrice rôles et Team Topologies les situe tout de même dans une organisation.
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 sont passées en 2024 à 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 6 pages métier de l'annexe décrivent six rôles (SRE, ingénieur plateforme, ingénieur DevSecOps...), et la matrice rôles et Team Topologies les place dans une organisation.
- Le tableau Par où commencer évite de lire les 5 parties dans l'ordre quand une urgence précise (ROI, collaboration, nouveau projet) prime.