This article is available in French.
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.
My progress
Sign in to track your progress and take notes. Sign in