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 ce cadre : 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.
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 des problèmes réels observés dans les équipes.
| 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 »- 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 parcours est accessible dès lors que vous avez une expérience basique en développement ou en administration système, et une curiosité pour les pratiques collaboratives. Aucune expertise en sécurité ou SRE n’est requise.
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.
Les 4 piliers du socle
Section intitulée « Les 4 piliers du socle »
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.
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é.
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 partagée, évaluer où on en est et choisir par quoi commencer.
Par où commencer selon votre profil
Section intitulée « Par où commencer selon votre profil »Suivez les 4 piliers dans l’ordre. Ne sautez pas la culture — c’est ce qui donne du sens à tout le reste.
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), puis explorez 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 — ils sont listés ci-dessous. Ce parcours construit le cadre mental qui rend ces outils utiles et ces choix éclairés.
Après ce socle, deux directions
Section intitulée « Après ce socle, deux directions »Mettre en œuvre
Section intitulée « Mettre en œuvre »Structurer et piloter
Section intitulée « Structurer et piloter »Ressources complémentaires
Section intitulée « Ressources complémentaires »Livres de référence
Section intitulée « Livres de référence »- 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 »| 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 DevOps Engineer | Avancé | SRE, SLO, observabilité |
| SANS SEC540 | Avancé | Cloud Native Security, Kubernetes |