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 4 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.

Audit de maturité DSOMM Évaluer objectivement la maturité DevSecOps d'une organisation avec DSOMM.

Team Topologies Les 4 types d'équipes, les 3 modes d'interaction, comment adapter votre organisation.

Mapper rôles et topologies Comment faire correspondre les rôles DevSecOps aux patterns Team Topologies.

Security Champions Mettre en place un programme Security Champions : sélection, formation, animation.

Formation des équipes Former les développeurs à la sécurité : curriculums, labs, CTF, sensibilisation.

Maturité et roadmap DevSecOps Construire et piloter une roadmap de transformation DevSecOps sur 12 à 24 mois.

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 ajoute un cinquième indicateur en 2025, 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é.

KPIs sécurité Indicateurs de pilotage : MTTR, taux de faux positifs, dette de vulnérabilités, couverture.

DORA : mesurer et implémenter Mettre en place les métriques DORA (dont le Rework Rate ajouté en 2025) dans votre organisation.

SLO, SLI et Error Budgets Définir des SLO et utiliser les error budgets pour piloter les 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, une projection que les études sectorielles publiées début 2026 confirment largement, avec un basculement net vers le platform-as-product (traiter la plateforme comme un produit avec des utilisateurs internes à satisfaire) plutôt qu'une simple couche d'infrastructure.

Platform Engineering Qu'est-ce qu'un IDP, Backstage, Crossplane, golden paths, self-service : fondamentaux et implémentation.

Collaboration Dev-Sec dans la plateforme Comment intégrer les contrôles de sécurité dans le self-service développeur.

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. La certification CKS (Certified Kubernetes Security Specialist) a été révisée en profondeur fin 2024 : les items obsolètes comme PodSecurityPolicy ont disparu au profit des pratiques réellement utilisées aujourd'hui, et l'examen suit désormais de près les versions récentes de Kubernetes.

Sécuriser Kubernetes : vue d'ensemble Surface d'attaque, RBAC, admission controllers, Network Policies, auditabilité.

Conteneurs : sécurité Images sécurisées, scan de vulnérabilités, Trivy, runtime security.

Internals conteneurs Linux cgroups, namespaces, capabilities : comprendre les primitives de sécurité.

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.

Infrastructure as Code Terraform, Ansible, Pulumi : choisir, structurer, sécuriser.

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, un référentiel de maturité en 4 niveaux) 2 à 4, la signature systématique avec Sigstore en production, et un workflow de gestion des CVE outillé : triage, SLA, exceptions documentées avec VEX.

Supply chain security avancée SLSA niveaux 2–4, Sigstore en production, in-toto, politique de vérification.

Gestion des vulnérabilités et CVE Workflow opérationnel : triage, SLA, exceptions, VEX, reporting.

Sécurité de la supply chain : outils Grype, Syft, Cosign, Rekor, SLSA Verifier : guide pratique.

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.

Secrets management avancé Vault Enterprise, rotation automatique, PKI dynamique, leases.

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.

SRE : concepts fondamentaux Revisiter SRE avec un regard expert : error budgets comme outil de décision, postmortems systémiques.

Observabilité avancée Distributed tracing, profiling continu, alerting sur symptômes vs causes.

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 et certifications de référence.

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)

Fiche métier DevSecOps Engineer Compétences requises, salaire, ressources, certifications.

Validation : quiz et projets

Projet fil rouge niveau 3 : ce projet de synthèse vous fait combiner tout ce que couvre ce niveau sur un cas concret, plutôt que de valider des connaissances isolées bloc par bloc. Déployez une application complète sur Kubernetes avec :

Pipeline CI/CD multi-environnements avec SLSA niveau 2
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 (revues en 2025 avec 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 et ses certifications 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.

Prochaines étapes

Retour au parcours complet Vue d'ensemble des 3 niveaux, certifications et passerelles.

Implémentation DevSecOps Team Topologies, Security Champions, KPIs, audit de maturité.

Sécuriser : guides pratiques Durcissement, Kubernetes, conteneurs, supply chain, secrets, réseaux.