Niveau 3 : Expert DevSecOps et spécialisations

Ce niveau 3 s'adresse aux ingénieurs qui ont déjà pratiqué le DevSecOps en production et qui veulent devenir expert DevSecOps : gouverner une plateforme, définir des standards, piloter la maturité d'une organisation ou se spécialiser sur un domaine précis. Vous y apprendrez à mesurer objectivement une transformation avec le DSOMM (DevSecOps Maturity Model) et les métriques DORA (les 5 indicateurs de référence sur la performance de livraison logicielle), à construire un Internal Developer Platform (IDP), à sécuriser Kubernetes en profondeur et à appliquer du policy as code. La page se termine sur 7 spécialisations métiers reconnues sur le marché.

Durée estimée : 100 à 150 heures selon la spécialisation choisie.

Ce que vous allez apprendre

Piloter un audit de maturité DevSecOps (DSOMM) et en déduire une roadmap priorisée
Concevoir et opérer un Internal Developer Platform (IDP) pour les équipes de développement
Configurer et auditer la sécurité d'un cluster Kubernetes (RBAC, Network Policies, admission controllers)
Implémenter du policy as code avec OPA/Gatekeeper ou Kyverno
Définir des standards d'architecture et des patterns réutilisables à l'échelle d'une organisation
Choisir et vous préparer à une spécialisation parmi les 7 profils métiers du niveau 3

Bloc 1 : Implémentation organisationnelle

L'expertise DevSecOps n'est pas que technique. Elle implique de comprendre comment structurer les équipes, mesurer les progrès et faire monter le niveau collectif. Le DSOMM (DevSecOps Maturity Model, un référentiel maintenu par l'OWASP) sert de socle pour objectiver où en est réellement une organisation. Team Topologies, dont la seconde édition est parue en 2025 et place la charge cognitive au centre du modèle, donne le vocabulaire pour organiser les équipes autour du flux de valeur plutôt que des silos techniques.

L'audit de maturité DSOMM donne le point de départ chiffré, et la roadmap de maturité le transforme en plan sur 12 à 24 mois. Côté organisation, Team Topologies présente les quatre types d'équipes et leurs modes d'interaction, et le guide rôles et Team Topologies place chaque rôle DevSecOps dans ce modèle. Pour faire monter le niveau collectif, un réseau de Security Champions relaie la sécurité dans chaque équipe, et un programme de formation remplace la sensibilisation annuelle par de la pratique continue.

Bloc 2 : KPIs, métriques et monitoring sécurité

Sans mesure, la sécurité reste une affaire d'opinion. Ce bloc couvre comment piloter objectivement la progression et démontrer la valeur du DevSecOps. Le rapport DORA (DevOps Research and Assessment, publié chaque année par Google Cloud) a été renommé en 2025 State of AI-assisted Software Development : il conserve les 4 métriques historiques (fréquence de déploiement, lead time, taux d'échec de changement, temps de restauration, déjà rebaptisé Failed Deployment Recovery Time en 2023 pour ne compter que les incidents causés par un déploiement) et y a ajouté un cinquième indicateur dès 2024, le Rework Rate, qui mesure la part de déploiements non planifiés destinés à corriger un défaut. Connaître cette évolution évite de piloter avec un tableau de bord daté.

Les KPIs sécurité mesurent ce que l'équipe sécurité doit piloter : délai de correction, taux de faux positifs, dette de vulnérabilités, couverture. La mise en place des métriques DORA montre comment collecter les cinq indicateurs sans fausser le comportement des équipes, et les SLO, SLI et error budgets relient la fiabilité aux décisions de déploiement.

Bloc 3 : Platform Engineering

Le Platform Engineering est la réponse structurelle au problème de la scalabilité DevSecOps. Plutôt que de former chaque équipe sur chaque outil, on construit une plateforme interne (IDP, pour Internal Developer Platform) qui rend les bonnes pratiques faciles par défaut. Ce mouvement s'est généralisé : Gartner estimait dès 2022 que 80 % des grandes organisations d'ingénierie logicielle disposeraient d'une équipe plateforme dédiée d'ici 2026, et la pratique a basculé vers le platform-as-product (traiter la plateforme comme un produit avec des utilisateurs internes à satisfaire) plutôt qu'une simple couche d'infrastructure.

Le guide Platform Engineering couvre ce qu'est un IDP, les outils comme Backstage et Crossplane, et les golden paths qui rendent la bonne pratique plus simple que la mauvaise. La collaboration Dev-Sec montre comment intégrer les contrôles de sécurité dans ce self-service sans en refaire un guichet.

Bloc 4 : Kubernetes security

Kubernetes est l'infrastructure cible de la majorité des déploiements Cloud Native, ce qui en fait une cible prioritaire pour un attaquant. Sa sécurisation couvre le RBAC (Role-Based Access Control, qui limite les droits par rôle plutôt que par compte), les Network Policies (un pare-feu interne au cluster qui filtre les flux pod à pod) et les admission controllers, qui valident ou rejettent une ressource avant sa création. Le programme de la certification CKS (Certified Kubernetes Security Specialist) a été refondu par la CNCF le 15 octobre 2024, aligné sur Kubernetes 1.31, puis mis à jour à chaque version : la v1.34 date du 30 octobre 2025.

La vue d'ensemble de la sécurité Kubernetes parcourt la surface d'attaque d'un cluster et les contrôles qui la réduisent. La sécurité des conteneurs descend d'un cran : images minimales, scan de vulnérabilités, sécurité à l'exécution. Pour comprendre ce qu'un conteneur isole vraiment, les cgroups et les autres primitives du noyau restent la référence.

Bloc 5 : Infrastructure as Code et policy as code

L'IaC (Infrastructure as Code) non sécurisé est une porte d'entrée comme une autre : un module Terraform mal écrit peut ouvrir un accès public aussi sûrement qu'une mauvaise configuration manuelle. Le policy as code consiste à écrire les règles de conformité et de sécurité sous forme de code versionné, testé et appliqué automatiquement, avec des outils comme OPA/Gatekeeper ou Kyverno pour les admission controllers Kubernetes. Ce bloc couvre comment choisir, structurer et sécuriser son IaC avant de l'industrialiser à l'échelle d'une organisation.

La section Infrastructure as Code aide à choisir entre Terraform, Ansible et Pulumi, puis à structurer et sécuriser le code d'infrastructure. Le principe à retenir : une règle de sécurité qui n'est pas écrite en code finit par n'être appliquée que par ceux qui s'en souviennent. Côté Kubernetes, le comparatif VAP, Kyverno ou Gatekeeper aide à choisir le moteur d'admission ; côté Terraform, le guide policy as code applique la même logique avant le déploiement.

Bloc 6 : Sécurisation avancée du pipeline et de la supply chain

La supply chain logicielle (l'ensemble des dépendances, outils et étapes qui transforment du code source en artefact déployé) est devenue une cible de choix : compromettre un seul maillon permet d'atteindre des milliers de victimes en aval, comme l'ont montré plusieurs incidents majeurs sur des paquets npm ou PyPI ces dernières années. À ce niveau, on dépasse le scan de vulnérabilités basique pour viser les niveaux SLSA (Supply-chain Levels for Software Artifacts) Build L2 et L3, les plus élevés du volet build depuis la version 1.0, la signature systématique avec Sigstore en production, et un workflow de gestion des CVE outillé : triage, SLA, exceptions documentées avec VEX.

Le guide supply chain security détaille les niveaux SLSA Build L2 et L3, Sigstore en production, in-toto et la politique de vérification. La gestion des vulnérabilités outille le triage et les exceptions, et la section sécurité de la supply chain met en pratique Grype, Syft, Cosign et Rekor.

Bloc 7 : Identité, secrets et accès

L'identité de charge de travail (workload identity, l'identité cryptographique attribuée à un service plutôt qu'à un humain) est devenue la nouvelle frontière de la sécurité applicative. SPIFFE/SPIRE (Secure Production Identity Framework For Everyone, et son implémentation de référence SPIRE) est le standard ouvert qui distribue ces identités automatiquement entre workloads, sans mot de passe partagé à gérer. Le zero trust (ne jamais faire confiance par défaut, même à l'intérieur du réseau) et une gestion avancée des secrets complètent ce bloc sur les architectures de confiance modernes.

Le guide de gestion des secrets va jusqu'aux usages avancés : rotation automatique, PKI dynamique et baux (leases) qui font expirer un secret de lui-même. C'est le complément naturel de l'identité de charge de travail : un service qui prouve son identité n'a plus besoin de secret statique.

Bloc 8 : SRE avancé

Le Site Reliability Engineering (SRE) appliqué à un niveau expert dépasse la simple définition de SLO. Il s'agit de traiter les error budgets comme un outil de décision partagé avec le produit plutôt que comme une contrainte technique isolée, de mener des postmortems systémiques qui cherchent les causes organisationnelles plutôt que la faute individuelle, et de pousser l'observabilité au-delà des tableaux de bord vers le tracing distribué et le profiling continu pour distinguer un symptôme visible par l'utilisateur d'une cause technique interne.

Le guide SRE se relit à ce niveau avec un autre regard : l'error budget devient un outil de décision partagé, le postmortem cherche des causes systémiques. La section observabilité couvre le tracing distribué, le profiling continu et l'alerting sur symptômes.

Spécialisations au niveau 3

À ce niveau, vous pouvez vous orienter vers l'une des 7 spécialisations. Chaque spécialisation correspond à un profil métier réel sur le marché, avec ses propres compétences clés, ses certifications de référence et les évolutions qu'il ouvre.

Focus : Intégrer la sécurité dans tout le SDLC, de la conception au monitoring en production.

Compétences clés : Threat modeling, tests de sécurité automatisés, pipeline sécurisé, supply chain, gestion des secrets, Kubernetes security, pilotage des Security Champions.

Certifications conseillées :

Certified DevSecOps Professional (Practical DevSecOps)
CKS (Certified Kubernetes Security Specialist)

Évolutions : vers l'architecture de sécurité (Security Architect), l'offensif (pentest, Red Team), la gouvernance (responsable de la sécurité des systèmes d'information) ou le produit (Security Product Manager).

La page métier Ingénieur DevSecOps détaille ses responsabilités, ses missions et les compétences attendues, formation par formation.

Valider le niveau 3 : le projet fil rouge

Le niveau 3 se valide par un projet de synthèse, pas par une série de questions : c'est le capstone de la formation, qui fait combiner sur un cas concret tout ce que couvre ce niveau. Les leçons de la formation portent chacune leur quiz pour contrôler les notions au fil de l'eau.

Projet fil rouge niveau 3 : déployez une application complète sur Kubernetes avec :

Pipeline CI/CD multi-environnements avec SLSA Build L2
RBAC Kubernetes + Network Policies + Pod Security Standards
Vault pour la gestion des secrets
SLO définis et alertes basées sur les symptômes
Audit de maturité DSOMM initial + roadmap des actions prioritaires

Référence : Projets fil rouge DevSecOps

À retenir

L'expert DevSecOps ne fait pas tout lui-même : il crée les conditions pour que les équipes fassent bien.
La maturité se mesure, se pilote et se démontre avec des données concrètes, pas avec des impressions.
Le DSOMM et les métriques DORA (complétées en 2024 par un cinquième indicateur, le Rework Rate) donnent un langage commun pour piloter une transformation sans y injecter d'opinions personnelles.
Le Platform Engineering ne remplace pas la sécurité : bien conçu, il l'intègre au chemin de moindre résistance pour les développeurs.
La sécurité Kubernetes (RBAC, Network Policies, admission controllers) et le policy as code sont désormais des compétences attendues, pas des options.
Les 7 spécialisations du niveau 3 correspondent à des profils métiers réels sur le marché, chacune avec son périmètre, ses certifications et ses évolutions propres.
Aucune certification ne remplace l'expérience de production : elle valide un socle de connaissances, pas les incidents réellement vécus.
La spécialisation se fait toujours à partir d'une maîtrise des niveaux 1 et 2 : les experts qui ont sauté des étapes ont des angles morts qu'ils ne voient pas.