Ce parcours pose les bases conceptuelles et culturelles qui font la différence entre une équipe qui déploie des outils et une équipe qui transforme vraiment sa façon de travailler. Ici, pas de Jenkins, GitLab CI ou Kubernetes — uniquement les fondations qui donnent du sens à ces outils.
Pourquoi ces fondamentaux sont essentiels
Section intitulée « Pourquoi ces fondamentaux sont essentiels »Beaucoup d’équipes se lancent dans le DevOps en installant des outils. Puis elles découvrent que les déploiements restent stressants, les bugs arrivent toujours trop tard en production, et les failles de sécurité sont détectées au dernier moment.
Le problème n’est pas les outils. C’est l’absence de fondations solides.
| Symptôme courant | Ce qui manque |
|---|---|
| Équipes qui se rejettent la faute | Culture DevOps (Partie 1) |
| Livraisons risquées et stressantes | Maîtrise du flow (Partie 2) |
| Failles découvertes en production | Sécurité continue (Partie 3) |
| Incidents répétés sans amélioration | Pratiques SRE (Partie 4) |
| Impossible de prioriser les efforts | Vision d’ensemble (Partie 5) |
Sans ces concepts, vous reproduirez les mêmes erreurs avec des outils plus modernes. Avec ces fondations, vous saurez pourquoi chaque outil existe et quand l’utiliser.
Prérequis et compétences visées
Section intitulée « Prérequis et compétences visées »Ce que vous devez savoir avant de commencer
Section intitulée « Ce que vous devez savoir avant de commencer »Ce parcours est accessible si vous avez :
- Une expérience basique en développement ou administration système
- Une compréhension des concepts de base du versioning (Git)
- Une curiosité pour les pratiques collaboratives
Aucune expertise en sécurité ou SRE n’est requise.
Ce que vous saurez faire après
Section intitulée « Ce que vous saurez faire après »- Expliquer le DevOps et le DevSecOps à des non-techniciens
- Identifier les freins culturels dans une organisation
- Promouvoir une culture de responsabilité partagée
- Animer des postmortems sans blâme
- Concevoir des systèmes avec quality et security by design
- Construire des pipelines CI/CD avec security gates
- Intégrer SAST, DAST et SCA dans les workflows
- Générer et exploiter des SBOM
- Mesurer et améliorer les métriques DORA
- Définir des SLO/SLI pertinents
- Mettre en place l’observabilité (logs, métriques, traces)
- Évaluer la maturité DevSecOps d’une équipe
- Définir une roadmap d’amélioration continue
- Arbitrer entre sécurité, vélocité et coût
- Former des équipes aux pratiques DevSecOps
Structure du parcours
Section intitulée « Structure du parcours »Ce parcours suit une progression logique en 5 parties :
- Comprendre le contexte — D’où vient le DevOps ? Quels sont ses piliers ? Comment mesurer la performance ?
- Accélérer le flux — Comment livrer plus vite et plus souvent, avec moins de risque ?
- Sécuriser en continu — Comment intégrer la sécurité sans ralentir les équipes ?
- Fiabiliser les systèmes — Comment garantir la disponibilité et apprendre des incidents ?
- Passer à l’échelle — Comment industrialiser ces pratiques pour toute l’organisation ?
Partie 1 — Comprendre le contexte
Section intitulée « Partie 1 — Comprendre le contexte »Temps estimé : 3-4 heures
Avant de parler de pratiques, il faut définir le territoire. Le DevOps n’est pas une méthode à appliquer mécaniquement — c’est une transformation culturelle et organisationnelle qui s’appuie sur des principes éprouvés.
Cette première partie répond aux questions fondamentales : qu’est-ce que le DevOps, vraiment ? D’où vient-il ? En quoi diffère-t-il de l’Agile ou du SRE ? Comment mesurer objectivement si ça fonctionne ?
Vous y découvrirez :
- L’origine du mouvement DevOps et son écosystème
- Le modèle CALMS (Culture, Automation, Lean, Measurement, Sharing)
- Les Three Ways qui structurent la pensée DevOps
- Les métriques DORA, scientifiquement validées par 7 années de recherche
- Le positionnement par rapport à l’Agile et au SRE
Ce que vous saurez faire :
- Expliquer DevOps et DevSecOps sans mentionner un seul outil
- Appliquer les Three Ways (Flow, Feedback, Learning) à votre contexte
- Mesurer objectivement votre performance avec les métriques DORA
- Distinguer DevOps, Agile et SRE pour éviter les confusions
Partie 2 — Accélérer le flux
Section intitulée « Partie 2 — Accélérer le flux »Temps estimé : 3-4 heures
Le First Way du DevOps est le flow : accélérer le flux de travail du développement vers la production. Mais aller vite ne suffit pas — il faut aller vite en réduisant le risque.
Cette partie explique comment livrer plus souvent rend paradoxalement les déploiements moins risqués. Elle introduit les concepts de value stream, de feedback loops et de shift-left — des idées simples mais puissantes qui changent la façon de concevoir le delivery.
Vous y découvrirez :
- Le value stream mapping pour identifier les goulots d’étranglement
- Pourquoi les petits lots réduisent le risque (et les maths derrière)
- Les boucles de rétroaction qui accélèrent l’apprentissage
- Le shift-left : décaler les vérifications vers la gauche du pipeline
- Les stratégies de tests qui permettent de livrer sereinement
Ce que vous saurez faire :
- Cartographier un value stream et identifier où le travail stagne
- Expliquer pourquoi les petits lots réduisent le risque (à un non-technicien)
- Concevoir des boucles de feedback qui accélèrent l’apprentissage
- Construire une stratégie de tests équilibrée (pas 90% de tests E2E)
Partie 3 — Sécuriser en continu
Section intitulée « Partie 3 — Sécuriser en continu »Temps estimé : 5-6 heures
La sécurité est souvent perçue comme un frein. Les équipes sécurité arrivent en fin de cycle, trouvent des failles, et bloquent la mise en production. Résultat : frustration des deux côtés et failles qui passent quand même.
Le DevSecOps propose une autre approche : intégrer la sécurité dès le début et en continu, sans créer de friction. Cette partie pose d’abord le vocabulaire (menace, risque, vulnérabilité), explique pourquoi la sécurité échoue souvent, puis montre comment l’intégrer dans le pipeline.
Vous y découvrirez :
- Le vocabulaire essentiel : menace, risque, vulnérabilité, attaque
- Pourquoi certaines mesures de sécurité sont rejetées par les équipes
- Comment arbitrer entre sécurité, usabilité et productivité
- Le principe de Security by Design et le threat modeling
- Les tests de sécurité : SAST, DAST, SCA, secrets scanning
- La sécurisation du pipeline CI/CD lui-même
- La supply chain security : SBOM, signatures, provenance
Ce que vous saurez faire :
- Distinguer menace, risque, vulnérabilité et attaque
- Expliquer pourquoi certaines mesures de sécurité sont rejetées
- Arbitrer entre sécurité et productivité de façon éclairée
- Intégrer SAST, DAST et SCA dans vos pipelines CI/CD
- Générer et exploiter des SBOM pour la traçabilité
Partie 4 — Fiabiliser les systèmes
Section intitulée « Partie 4 — Fiabiliser les systèmes »Temps estimé : 4-5 heures
Livrer vite c’est bien. Livrer vite un système qui tient la charge, c’est mieux. Le Site Reliability Engineering (SRE) est né chez Google pour résoudre ce problème : comment garantir la fiabilité à grande échelle ?
Cette partie fait le pont entre delivery et exploitation. Elle introduit les concepts de SLO/SLI, d’error budgets, d’observabilité et de gestion des incidents — des pratiques qui permettent d’équilibrer vélocité et stabilité de façon mesurable.
Vous y découvrirez :
- Les principes SRE et leur origine chez Google
- SLO, SLI et error budgets : objectifs de fiabilité mesurables
- L’observabilité : logs, métriques et traces pour comprendre vos systèmes
- L’élimination du toil : automatiser le travail répétitif sans valeur
- La gestion des incidents et les postmortems sans blâme
- Les astreintes (on-call) : organisation et bonnes pratiques
Ce que vous saurez faire :
- Définir des SLO/SLI pertinents pour vos services
- Utiliser les error budgets pour arbitrer entre features et stabilité
- Identifier le toil et planifier son élimination
- Mener un postmortem sans blâme et en tirer des actions concrètes
- Organiser des astreintes soutenables pour l’équipe
Partie 5 — Passer à l’échelle
Section intitulée « Partie 5 — Passer à l’échelle »Temps estimé : 2-3 heures
Les pratiques DevOps fonctionnent bien dans une équipe motivée. Mais comment les étendre à toute une organisation ? Comment éviter que chaque équipe réinvente la roue ?
Cette partie aborde le Platform Engineering — construire des plateformes self-service qui réduisent la charge cognitive des équipes produit. Elle propose aussi un modèle de maturité pour savoir où vous en êtes et par quoi commencer.
Vous y découvrirez :
- L’évaluation de la maturité DevSecOps de votre organisation
- La construction d’une roadmap d’amélioration progressive
- Le choix des quick wins à fort impact
Ce que vous saurez faire :
- Expliquer le Platform Engineering et ses bénéfices
- Évaluer la maturité DevSecOps de votre équipe
- Identifier les quick wins à fort impact
- Construire une roadmap d’amélioration réaliste
Quel parcours selon votre profil ?
Section intitulée « Quel parcours selon votre profil ? »Ce parcours est conçu pour être suivi dans l’ordre, mais selon votre expérience, vous pouvez adapter :
Suivez le parcours dans l’ordre, de la Partie 1 à la Partie 5. Ne sautez pas les parties culturelles — elles sont la clé pour comprendre pourquoi les outils seuls ne suffisent pas.
Commencez par : Culture DevOps
Vous maîtrisez déjà Git, CI/CD et les tests ? Parcourez rapidement les Parties 1-2, puis concentrez-vous sur la Partie 3 (sécurité) et la Partie 4 (fiabilité).
Commencez par : Introduction au DevSecOps
Vous connaissez la sécurité mais pas le DevOps ? Les Parties 1-2 sont essentielles pour comprendre la culture et le flow. Ensuite, la Partie 3 fera le lien avec vos compétences.
Commencez par : Culture DevOps
Vous gérez déjà la production ? Validez la Partie 4 (vous y trouverez probablement des choses connues), puis explorez la Partie 3 pour intégrer la sécurité dans vos pratiques.
Commencez par : SLO, SLI et Error Budgets
Focalisez-vous sur les aspects stratégiques : Partie 1 (métriques DORA), Partie 3 (pourquoi la sécu échoue), Partie 4 (SLO/error budgets), et Partie 5 (maturité/roadmap).
Commencez par : Métriques DORA
Et après ce parcours ?
Section intitulée « Et après ce parcours ? »Une fois ces fondamentaux maîtrisés, vous êtes prêt pour les guides d’implémentation :
Ressources complémentaires
Section intitulée « Ressources complémentaires »Livres de référence
Section intitulée « Livres de référence »| Livre | Auteur | Focus |
|---|---|---|
| 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 | Les pratiques SRE originales | |
| 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 |