1. Les trois voies du DevOps #
Le cadre de The Phoenix Project et du DevOps Handbook.
Flux, feedback, apprentissage #
| Voie | Objectif | Pratiques |
|---|---|---|
| 1. Le flux | Accélérer le passage du travail du développement à la production | petits lots, CI/CD, limitation du travail en cours, suppression des files d'attente |
| 2. Le feedback | Détecter et corriger les problèmes au plus tôt | tests automatisés, observabilité, alertes, revues rapides |
| 3. L'apprentissage continu | Expérimenter et apprendre des échecs | post-mortems sans blâme, temps dédié à l'amélioration, partage |
Le DevOps n'est ni un outil ni un poste : c'est une façon d'organiser le travail pour que livrer souvent soit à la fois rapide et sûr. Les outils (CI/CD, IaC) viennent servir ces trois voies.
2. Voir le flux de valeur #
On n'améliore que ce que l'on voit.
Value stream mapping #
La cartographie de la chaîne de valeur suit une demande de l'idée à l'utilisateur et mesure, à chaque étape, le temps de traitement et le temps d'attente. Dans la plupart des organisations, le travail effectif représente moins de 15 % du délai total : les gains viennent de la suppression des attentes (validations manuelles, environnements indisponibles, transmissions entre équipes).
Bonne Pratique : Animez l'atelier avec toutes les équipes concernées (dev, ops, sécurité, métier) et partez d'une demande réelle récente, pas du processus théorique.
Petits lots et travail en cours #
- Un lot plus petit traverse plus vite le système et ses défauts sont plus faciles à trouver.
- Limitez le travail en cours (WIP) : finir avant de commencer.
- Rendez le travail visible : tableau kanban partagé incluant les tâches d'exploitation et la dette technique.
3. Organiser les équipes #
Qui construit, qui exploite.
You build it, you run it #
Dans le modèle historique, les développeurs « jettent par-dessus le mur » ce que les opérations doivent faire tourner (voir le mur de la confusion). Le DevOps rapproche les deux : l'équipe qui construit un service est aussi responsable de son fonctionnement en production, astreinte comprise. Elle reçoit en échange l'autonomie et les outils pour déployer seule.
Anti-modèle : Renommer l'équipe d'exploitation « équipe DevOps » et lui confier tous les pipelines recrée un silo : le DevOps est une responsabilité partagée, pas une nouvelle équipe intermédiaire.
Team Topologies #
| Type | Rôle |
|---|---|
| Stream-aligned | livre de la valeur sur un flux métier, de bout en bout |
| Plateforme | fournit des services internes en libre-service (CI/CD, clusters, observabilité) |
| Facilitatrice (enabling) | aide temporairement les équipes à acquérir une compétence |
| Sous-système complexe | maîtrise un composant très spécialisé |
4. Une culture qui apprend #
Sécurité psychologique et post-mortems.
Post-mortem sans blâme #
Après un incident, l'objectif n'est pas de trouver un coupable mais de comprendre comment le système (outils, processus, informations disponibles) a rendu l'erreur possible. Une culture du blâme pousse à cacher les problèmes, ce qui les rend plus graves.
- Chronologie factuelle de l'incident (détection, actions, résolution).
- Impact : utilisateurs, durée, données.
- Facteurs contributifs, en cherchant plusieurs causes plutôt qu'une « cause racine » unique.
- Ce qui a bien fonctionné.
- Actions correctives avec responsable et échéance, suivies comme le reste du travail.
Le saviez-vous ? : Les études DORA montrent qu'une culture générative (confiance, partage de l'information, échecs vus comme des occasions d'apprendre) est un prédicteur de la performance de livraison.
