- Description
- Un porte-conteneurs en pleine mer, vu de l'avant, laissant un large sillage.
- Source
- The U.S. National Archives · page d’origine
- Licence
- PD Domaine public
Livraison et mise en production (LIV)
Un projet n'a de valeur qu'une fois livré et exploité. La mise en production est le moment où l'incertitude se réalise : plus elle est rare et volumineuse, plus elle est risquée. Ce thème…
Niveau : 🟢→🔴 · Code : LIV · Matrice : PI
Pourquoi ce thème#
Un projet n'a de valeur qu'une fois livré et exploité. La mise en production est le moment où l'incertitude se réalise : plus elle est rare et volumineuse, plus elle est risquée. Ce thème regarde la livraison du point de vue du pilotage : rythme, préparation, décision de go, retour arrière, communication, stabilisation. L'automatisation technique (pipeline, intégration continue) est dans la matrice Développement logiciel et son déploiement.
Ce que mesure le thème#
- Axe : de la livraison à risque, manuelle et rare, à la livraison fréquente, sans événement.
- Indicateur clé : fréquence de livraison, taux d'échec des livraisons, durée de la fenêtre d'indisponibilité, temps de retour arrière (métriques de la littérature DORA : fréquence de déploiement, délai de mise en œuvre, taux d'échec, temps de rétablissement).
- Unité : livraisons par mois ; % d'échecs ; minutes d'arrêt ; minutes pour revenir en arrière.
Les cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Livraison risquée | La mise en production est un événement stressant, faite à la main par une ou deux personnes. | 1 à 2 par an ; échecs > 30 % |
| 2 | Procédure écrite | Une procédure décrit la livraison ; elle peut être exécutée par une autre personne que l'auteur. | Quelques fois par an ; échecs 15 à 30 % |
| 3 | Rythme régulier | Les livraisons ont un rythme prévisible, une décision de go, un retour arrière documenté et des utilisateurs prévenus. | Mensuel à trimestriel ; échecs 5 à 15 % |
| 4 | Livraison mesurée | La fréquence, le taux d'échec et le temps de rétablissement sont mesurés et s'améliorent ; la livraison est scriptée. | Hebdomadaire à mensuel ; échecs < 5 % ; retour arrière < 1 h |
| 5 | Livraison sans événement | Livrer est banal : fréquent, automatisé, réversible, sans fenêtre d'indisponibilité ; la valeur arrive en continu. | Plusieurs par semaine ; échecs < 2 % ; retour < 15 min |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| PI-LIV-1.1 | Les livraisons sont datées et versionnées. | Liste des versions livrées avec dates. |
| PI-LIV-1.2 | Une personne identifiée exécute la livraison. | Nom noté dans le journal. |
| PI-LIV-1.3 | Les utilisateurs sont prévenus d'une livraison en cours si elle les affecte. | Message d'avertissement. |
| PI-LIV-2.1 | Une procédure de livraison écrite existe (étapes, prérequis, vérifications). | Document à jour, lu par un tiers. |
| PI-LIV-2.2 | Un tiers a déjà exécuté la procédure seul avec succès. | Journal d'une exécution par une autre personne. |
| PI-LIV-2.3 | Une vérification de bon fonctionnement après livraison est définie. | Liste de contrôles post-livraison. |
| PI-LIV-3.1 | Un calendrier de livraisons est publié (rythme prévisible). | Calendrier sur 6 mois. |
| PI-LIV-3.2 | Une décision de go/no-go est tracée avec critères (recette, risques ouverts, disponibilité de l'exploitation). | Comptes rendus de go/no-go. |
| PI-LIV-3.3 | Un plan de retour arrière existe pour chaque livraison et a été testé au moins une fois. | Procédure ; trace d'un test. |
| PI-LIV-3.4 | Des notes de version destinées aux utilisateurs sont publiées à chaque livraison. | Notes sur les 3 dernières versions. |
| PI-LIV-3.5 | La livraison respecte une règle de séparation des environnements (essais, préproduction, production). | Description des environnements ; traces de passage. |
| PI-LIV-4.1 | La fréquence de livraison et le taux d'échec sont mesurés par version. | Série sur ≥ 8 livraisons. |
| PI-LIV-4.2 | Le temps de rétablissement après échec est mesuré. | Durées consignées par incident. |
| PI-LIV-4.3 | Les étapes de livraison sont scriptées (pas de commande retapée à la main). | Scripts versionnés ; exécution sans intervention manuelle libre. |
| PI-LIV-4.4 | Les échecs de livraison font l'objet d'une analyse et d'une action. | Rapports d'incident, actions closes. |
| PI-LIV-4.5 | Les migrations de données et de schéma sont rejouables (idempotentes) et testées sur une copie. | Procédure de test sur copie ; rejeu sans effet de bord. |
| PI-LIV-5.1 | La livraison est automatisée de bout en bout, déclenchée à la demande. | Pipeline déclenché sans intervention hors approbation. |
| PI-LIV-5.2 | Les livraisons ne nécessitent pas d'interruption de service pour les utilisateurs. | Mesure d'indisponibilité ≈ 0 sur 6 mois. |
| PI-LIV-5.3 | Le retour arrière est automatisé et exercé régulièrement. | Exercice périodique tracé. |
| PI-LIV-5.4 | Les fonctions nouvelles peuvent être activées ou désactivées indépendamment de la livraison. | Mécanisme d'activation par paramètre ; exemple d'usage. |
Lecture détaillée par niveau#
Niveau 1. Signes : le vendredi soir, un week-end de livraison, un gros nombre d'étapes manuelles en mémoire. Gain : maîtrise individuelle. Ne garantit pas la reproductibilité. Difficulté : 1/5. Effort : 1/5.
Niveau 2. Signes : une procédure existe et a servi à autre chose qu'à décorer. Gain : transmissibilité. Ne garantit pas la rapidité ni l'absence d'échec. Difficulté : 2/5. Effort : 2/5.
Niveau 3. Signes : calendrier de versions, go/no-go, notes de version, retour arrière testé. Gain : confiance du métier, prévisibilité. Ne garantit pas la fréquence. Difficulté : 3/5. Effort : 3/5.
Niveau 4. Signes : scripts, chiffres de fréquence et d'échec, analyses d'incident. Gain : amélioration continue visible. Ne garantit pas la fluidité de bout en bout. Difficulté : 4/5. Effort : 4/5.
Niveau 5. Signes : livraison sans événement, indisponibilité nulle, activation indépendante. Gain : valeur livrée en continu, pression de fin de cycle disparue. Ne garantit pas que ce que l'on livre soit utile. Difficulté : 5/5. Effort : 5/5. Pour un datamart avec kits d'installation, un 5 complet est rarement atteignable (migrations de schéma, fenêtres de traitement) : viser un 4 solide.
Atteinte partielle et notation#
Règle commune : voir README.
- 0,5 : go/no-go pratiqué mais non tracé ; retour arrière documenté mais jamais testé.
- 1 : un audit sur les 3 dernières livraisons le confirme.
- Un 5 partiel : livraison scriptée et rejouée sur copie, retour arrière en moins de 30 minutes, fréquence mensuelle ; l'automatisation de bout en bout manque. Score ≈ 4,1.
Datamart livré en kits d'installation : un kit complet réinstallé sur une copie de la base la veille, puis rejoué en production avec retour arrière par restauration (durée mesurée : 25 minutes). Chaque kit est vérifiable à la sortie par un script de contrôle. C'est la démarche de niveau 3 à 4 sans avoir un pipeline de déploiement continu.
Retour arrière théorique. Symptôme : le plan existe, la restauration n'a jamais été jouée ; en incident, elle prend 6 h au lieu de 30 minutes. Cause : un plan non testé est une hypothèse. Remède : exercice de retour arrière à chaque trimestre.
Goodhart : si la fréquence de livraison devient l'objectif, on livre des versions vides ou on découpe artificiellement. Toujours lire la fréquence avec le taux d'échec et la valeur livrée.
Une migration de schéma ou de données irréversible (suppression de colonne, fusion de tables) se livre en deux temps : ajout compatible, bascule, puis nettoyage différé (modèle expand/contract). Cela transforme un retour arrière impossible en retour arrière trivial. Voir aussi Déploiement et exploitation (DL).
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : rédiger la procédure en la faisant exécuter par quelqu'un d'autre.
- 2 → 3 : calendrier de livraisons, checklist de go/no-go, test du retour arrière, notes de version ; voir Comparatif des méthodes et CI/CD.
- 3 → 4 : scripts versionnés, mesure DORA-like, analyse d'incident ; voir CI/CD pour la data et Azure DevOps / TFS.
- 4 → 5 : pipeline de bout en bout, activation par paramètre, retour arrière automatisé.
Peut rédiger des notes de version à partir des tickets, relire un script de déploiement, générer une checklist de contrôle ; ne doit pas décider seule d'un go ni exécuter en production sans validation humaine tracée.
Voir aussi#
- Thèmes voisins : 08 Qualité et recette · 05 Risques · 07 Parties prenantes · 10 Amélioration continue.
- Autres matrices : Intégration et livraison continues (DL) · Déploiement et exploitation (DL) · DataOps (data) · Versionnement des rapports (BI).
- Pratique : CI/CD · CI/CD pour la data · Stratégies de branches · Glossaire.
✻ Rédigé par Claude Sonnet 5.5
