Beaucoup d'équipes pensent faire du DevOps parce qu'elles ont une CI, des conteneurs et des déploiements automatisés. Les mises en production restent pourtant risquées, la sécurité arrive trop tard, les incidents se répètent et les arbitrages se font à l'aveugle.
Le problème ne vient pas des outils. Il vient de l'absence d'un cadre mental commun.
Ce parcours pose les fondamentaux DevSecOps : comprendre le flow, intégrer la sécurité comme une contrainte de conception, piloter la fiabilité avec des objectifs mesurables. Pas de Jenkins, pas de Kubernetes ici, uniquement les fondations qui donnent du sens à ces outils et aux décisions qui les entourent.
Une fois ces fondations acquises, le référentiel Socle DevSecOps traduit cette sécurité en exigences concrètes et auditables, du code au cloud : 412 exigences réparties sur 16 domaines, pour passer de la culture aux preuves.
Ce que ce parcours résout
Section intitulée « Ce que ce parcours résout »Ce n'est pas un catalogue de notions à cocher. C'est un diagnostic qui part des symptômes que vivent les équipes au quotidien : stress au déploiement, failles découvertes trop tard, incidents qui se répètent. Le tableau ci-dessous relie chaque symptôme à sa cause profonde et au pilier qui la traite.
| Symptôme observé | Cause profonde | Réponse dans ce parcours |
|---|---|---|
| Déploiements stressants, équipes qui se rejettent la faute | Culture en silos, pas de responsabilité partagée | Pilier 1, Comprendre |
| Livraisons en gros lots, feedback tardif, tests insuffisants | Flow mal conçu, manque de shift-left | Pilier 2, Accélérer |
| Failles détectées trop tard, sécurité perçue comme un frein | Sécurité traitée comme un contrôle final, pas une contrainte de conception | Pilier 3, Sécuriser |
| Incidents répétitifs, on-call épuisant, pas d'amélioration | Fiabilité non pilotée par des objectifs mesurables | Pilier 4, Fiabiliser |
| Chaque équipe réinvente la roue, pratiques impossibles à propager | Pas de vision système ni de plateforme commune | Horizon, Industrialiser |
Ce que vous saurez faire après ce parcours
Section intitulée « Ce que vous saurez faire après ce parcours »Ce parcours vous permet d'acquérir trois compétences fondamentales : expliquer les enjeux DevOps à toutes les audiences, concevoir un delivery fiable et sécurisé, et piloter avec des métriques reconnues. Il est accessible dès lors que vous avez une expérience basique en développement ou en administration système, sans expertise préalable en sécurité ou en SRE.
- Expliquer DevOps, DevSecOps et SRE sans les confondre, y compris à des non-techniciens
- Concevoir un delivery plus fluide, plus sûr et plus observable
- Piloter avec des métriques DORA, des SLO/SLI et une roadmap de maturité
Ce qui distingue ce parcours
Section intitulée « Ce qui distingue ce parcours »La plupart des ressources traitent DevOps, sécurité et fiabilité comme trois sujets séparés. Ce parcours les relie délibérément.
- Delivery et sécurité ne sont pas opposés : la sécurité bien intégrée accélère, elle ne freine pas.
- La supply chain change la façon de penser les pipelines : signer, tracer, attester font partie du delivery moderne.
- La fiabilité se pilote, elle ne se subit pas : SLO, error budgets et observabilité sont des outils de vélocité autant que de stabilité.
- Les outils sans cadre mental ne règlent rien : ce parcours construit le cadre avant de pointer vers les outils.
- L'IA amplifie ce qui existe déjà : le rapport DORA 2025 le confirme, l'intelligence artificielle accélère une équipe mature et aggrave les faiblesses d'une équipe en difficulté, elle ne remplace pas le cadre.
Les 4 piliers du socle DevSecOps
Section intitulée « Les 4 piliers du socle DevSecOps »Ce parcours s'organise en quatre piliers progressifs, du plus conceptuel (comprendre) au plus opérationnel (fiabiliser). Chaque pilier s'appuie sur le précédent : impossible de bien sécuriser un flux qu'on n'a pas compris, ou de fiabiliser un système livré sans discipline. Le schéma ci-dessous résume cette progression et la durée indicative de chaque étape.
Pilier 1, Comprendre
Section intitulée « Pilier 1, Comprendre »3–4 heures
Le DevOps n'est pas une méthode à appliquer mécaniquement. Avant d'en choisir les outils, il faut comprendre pourquoi ce mouvement existe, ce qu'il mesure et en quoi il se distingue de l'Agile et du SRE. Le modèle DORA a d'ailleurs évolué depuis les quatre indicateurs historiques : un cinquième, le Deployment Rework Rate (la part des déploiements qui corrigent en réalité un bug introduit précédemment), a été ajouté en 2024 et est désormais benchmarké dans le rapport 2025, preuve que même les fondamentaux bougent.
Pilier 2, Accélérer
Section intitulée « Pilier 2, Accélérer »3–4 heures
Livrer plus souvent rend paradoxalement les déploiements moins risqués. Ce pilier explique pourquoi, et introduit les concepts de value stream, de feedback loops et de shift-left qui font la différence entre une équipe qui subit ses livraisons et une équipe qui les maîtrise.
Pilier 3, Sécuriser
Section intitulée « Pilier 3, Sécuriser »5–6 heures
La sécurité n'est pas un chapitre à part. C'est une contrainte de conception qui traverse le delivery, le pipeline et la supply chain. Ce pilier couvre le vocabulaire, les arbitrages, les tests automatisés et la traçabilité des artefacts, les fondements du DevSecOps appliqué. La refonte 2025 de l'OWASP Top 10 en est un bon révélateur : les erreurs de configuration et les défaillances de supply chain logicielle grimpent dans le classement, preuve que les risques évoluent aussi vite que les pratiques.
Pilier 4, Fiabiliser
Section intitulée « Pilier 4, Fiabiliser »4–5 heures
Livrer vite un système qui tombe, c'est encore livrer vite. Le SRE apporte les outils pour piloter la fiabilité : SLO/SLI, error budgets, observabilité, postmortems sans blâme. Ce pilier fait le pont entre le delivery et l'exploitation.
Horizon, Industrialiser à l'échelle
Section intitulée « Horizon, Industrialiser à l'échelle »Les quatre piliers fonctionnent bien dans une équipe. La vraie difficulté commence quand il faut les propager à l'organisation : éviter que chaque équipe réinvente la roue, construire une plateforme commune, évaluer sa maturité et choisir par quoi commencer. C'est l'objet du Platform Engineering, qui structure aujourd'hui la démarche d'industrialisation dans la majorité des organisations matures.
Par où commencer selon votre profil
Section intitulée « Par où commencer selon votre profil »Le bon point d'entrée dans ce parcours dépend de votre profil et de ce que vous maîtrisez déjà : un développeur expérimenté n'a pas les mêmes lacunes qu'un security engineer ou qu'un manager. Les cinq onglets ci-dessous indiquent un chemin d'entrée adapté, pour éviter de revoir des notions déjà acquises ou, à l'inverse, de sauter des bases indispensables.
Suivez les quatre piliers dans l'ordre, en commençant par le pilier Comprendre. Ne sautez pas la culture : c'est ce qui donne du sens à tout le reste, y compris aux outils que vous découvrirez plus tard.
Commencez par : Culture DevOps
Vous maîtrisez Git, CI/CD et les tests ? Parcourez rapidement le Pilier 1, puis concentrez-vous sur la sécurité (Pilier 3) et la fiabilité (Pilier 4).
Commencez par : Introduction au DevSecOps
Vous connaissez la sécurité mais pas le DevOps ? Les Piliers 1 et 2 sont essentiels pour comprendre la culture et le flow. Le Pilier 3 fera le lien avec vos compétences.
Commencez par : Culture DevOps
Validez le Pilier 4, vous y trouverez des repères connus : SLO, error budgets, postmortems. Explorez ensuite le Pilier 3 pour intégrer la sécurité dans vos pratiques d'exploitation.
Commencez par : SLO, SLI et Error Budgets
Focalisez-vous sur les aspects stratégiques : métriques DORA, pourquoi la sécurité échoue, SLO/error budgets, maturité et roadmap.
Commencez par : Métriques DORA
Ce que ce parcours ne fait pas
Section intitulée « Ce que ce parcours ne fait pas »Ce parcours n'est pas un tutoriel d'outil. Vous n'y trouverez pas de configuration Kubernetes, de pipeline GitLab CI ou de règles Trivy. Ces guides existent : vous les retrouverez plus loin, dans la section « Après ce socle, deux directions ». Ce parcours construit d'abord le cadre mental qui rend ces outils utiles et ces choix éclairés.
À retenir
Section intitulée « À retenir »Ce parcours construit un cadre mental commun avant d'aborder les outils. Voici les points essentiels à garder en tête avant de vous lancer dans les quatre piliers, ou avant de rejoindre le niveau 2, opérationnel.
- La culture précède les outils : sans responsabilité partagée entre Dev, Ops et Sec, aucun outil ne résout les silos.
- Le flow se pilote : réduire la taille des lots et raccourcir les boucles de feedback rend les déploiements moins risqués, pas plus.
- La sécurité est une contrainte de conception, pas un contrôle final : le shift-left et le security by design coûtent moins cher que la remédiation tardive.
- La supply chain fait partie du périmètre : signer, tracer et attester les artefacts sont désormais des pratiques de base, pas un luxe.
- La fiabilité se mesure : SLO, SLI et error budgets transforment un ressenti diffus en décision arbitrée.
- L'IA amplifie ce qui existe déjà : elle accélère une équipe mature et aggrave les dysfonctionnements d'une équipe en difficulté, selon le rapport DORA 2025.
- L'industrialisation est la prochaine étape : une fois les quatre piliers acquis, la vraie difficulté est de les propager à l'échelle de l'organisation.
Après ce socle, deux directions
Section intitulée « Après ce socle, deux directions »Une fois les fondations posées, deux chemins s'ouvrent selon votre priorité immédiate. Le premier passe par la mise en œuvre : pipeline CI/CD, sécurisation du code, supply chain. Le second structure et pilote la démarche dans la durée : observabilité, panorama d'outils, feuille de route de maturité.
Mettre en œuvre
Section intitulée « Mettre en œuvre »Ces guides passent du concept à la pratique : ils montrent comment configurer un pipeline, outiller l'analyse de code ou signer des artefacts avec des outils réels.
Structurer et piloter
Section intitulée « Structurer et piloter »Ces guides aident à faire vivre la démarche après le démarrage : mesurer, outiller et faire progresser la maturité de l'équipe dans la durée.
Ressources complémentaires
Section intitulée « Ressources complémentaires »Ces ressources ne sont pas indispensables pour suivre ce parcours, mais elles apportent un socle théorique solide pour qui veut aller plus loin : lectures de référence et certifications reconnues par le secteur.
Livres de référence
Section intitulée « Livres de référence »Ces ouvrages ont façonné la pensée DevOps et SRE modernes. Ils reviennent en permanence dans les conférences et les formations : mieux vaut les connaître, même sans les avoir tous lus en entier. La démarche scientifique d'Accelerate a d'ailleurs directement inspiré le rapport DORA 2025 cité plus haut.
- The Phoenix Project (Gene Kim), Introduction narrative au DevOps
- The DevOps Handbook (Gene Kim et al.), Guide pratique complet
- Accelerate (Nicole Forsgren), La science derrière les métriques DORA
- Site Reliability Engineering (Google), Les pratiques SRE
- Security Chaos Engineering (Aaron Rinehart), Approche proactive de la sécurité
Certifications alignées
Section intitulée « Certifications alignées »Ces certifications valident des compétences complémentaires à ce parcours, du niveau débutant à avancé. Elles ne remplacent pas la pratique mais structurent un plan de montée en compétence reconnu par les recruteurs.
| Certification | Niveau | Focus |
|---|---|---|
| DASA DevOps Fundamentals | Débutant | Culture DevOps, CALMS, Three Ways |
| Certified DevSecOps Professional (CDP) | Intermédiaire | Pipeline sécurisé, SAST/DAST/SCA |
| Google Cloud Professional Cloud DevOps Engineer | Avancé | SRE, SLO, observabilité |
| SANS SEC540 | Avancé | Cloud Native Security, Kubernetes, automatisation IA |