- Description
- Le lancement d'un navire
- Source
- auteur non indiqué · page d’origine
- Licence
- PD Domaine public
Déploiement et exploitation
Ce thème mesure la sûreté de la mise en production et de l'exploitation courante : durée et réversibilité d'un déploiement, taux d'échec des changements, autonomie de l'exploitation…
En bref
Ce thème mesure la sûreté de la mise en production et de l'exploitation courante : durée et réversibilité d'un déploiement, taux d'échec des changements, autonomie de l'exploitation, maîtrise des environnements et de la configuration. Il prolonge la chaîne vue en 05 (produire l'artefact) par la chaîne « le mettre en service et le tenir ».
Sur cette page
Niveau : 🟢→🔴 · Code thème : DEP (matrice DL)
Pourquoi ce thème#
Un déploiement est le moment où la valeur rencontre le risque. Un déploiement manuel, nocturne, de plusieurs heures, sans retour arrière préparé, produit des incidents qui s'inscrivent dans la mémoire collective et finissent par freiner toute livraison (« on ne touche à rien avant la fin du trimestre »). Un déploiement banalisé — court, répétable, réversible — rend la livraison ennuyeuse, ce qui est exactement le but.
Deux particularités de notre contexte : (1) la base de données ne se déploie pas comme un binaire : elle porte un état, et une migration est souvent irréversible (suppression de colonne, transformation de données) ; (2) quand le produit est livré chez le client par kits d'installation, c'est le client qui exécute le déploiement : la promesse devient « un kit s'installe sans surprise, quelle que soit la version de départ ». Voir CI/CD pour la data et le thème BI 07.
Ce que mesure le thème#
- Axe : de « intervention héroïque » à « événement banal, réversible et mesuré ».
- Indicateurs clés : durée d'indisponibilité par déploiement ; taux de changements en échec ; temps de rétablissement ; part des déploiements sans intervention manuelle.
- Unité : minutes ; % ; heures.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Héroïque | La mise en production réussit si les bonnes personnes sont là et disponibles. | Déploiement de plusieurs heures ; échecs fréquents (> 30 %) |
| 2 | Procédurée | Un déploiement suit une procédure écrite et laisse une trace. | Procédure ; retour arrière par restauration ; échec ≈ 20-30 % |
| 3 | Répétable | Un déploiement est le même geste partout, en moins d'une heure, avec un retour arrière testé. | Scripté ; retour arrière testé ; échec < 15 % |
| 4 | Sans interruption | Le service reste disponible pendant le déploiement et un défaut touche peu d'utilisateurs avant d'être contenu. | Indispo ≈ 0 ; déploiement progressif ; rétablissement < 1 h |
| 5 | Autonome | Le système se déploie, se vérifie et se corrige lui-même ; la mise en production est un non-événement. | Échec < 5 % ; retour arrière automatique ; rétablissement en minutes |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-DEP-1.1 | La liste des environnements et de leur rôle existe | Page à jour |
| DL-DEP-1.2 | Les déploiements sont consignés (qui, quand, quelle version) | Journal consultable |
| DL-DEP-1.3 | Les sauvegardes avant déploiement existent | Preuve de sauvegarde par déploiement |
| DL-DEP-2.1 | Une procédure de déploiement et une procédure de retour arrière sont écrites | Documents datés |
| DL-DEP-2.2 | Les paramètres par environnement sont répertoriés (pas de valeur « magique » dans le code) | Inventaire de configuration |
| DL-DEP-2.3 | Les droits de déploiement sont séparés des droits de développement | Revue des rôles |
| DL-DEP-2.4 | Le déploiement est annoncé et fenêtré | Calendrier de changements |
| DL-DEP-3.1 | Le déploiement est scripté de bout en bout, sans étape manuelle | Exécution par un tiers réussie |
| DL-DEP-3.2 | Le retour arrière est testé, au moins une fois par trimestre | Exercice daté |
| DL-DEP-3.3 | Les migrations de base sont versionnées, idempotentes et rejouables (relancer ne casse pas) | Double exécution réussie |
| DL-DEP-3.4 | Les environnements sont décrits en code (ou reconstructibles) et dérivent peu | Contrôle de dérive périodique |
| DL-DEP-3.5 | Un test de fumée automatique vérifie chaque déploiement | Résultat journalisé |
| DL-DEP-4.1 | Un déploiement ne provoque aucune indisponibilité (bleu/vert, rolling, fenêtre de compatibilité) | Mesure d'indisponibilité ≈ 0 |
| DL-DEP-4.2 | Les nouvelles fonctions sont activables par bascule, indépendamment du déploiement | Au moins 3 bascules utilisées |
| DL-DEP-4.3 | Un déploiement progressif (canari, cercles) limite l'exposition d'un défaut | Pourcentage d'exposition paramétrable |
| DL-DEP-4.4 | Les migrations de données sont découplées (expand/contract) et compatibles N-1 | Procédure testée |
| DL-DEP-4.5 | Le taux d'échec des changements est mesuré et < 15 % | Rapport trimestriel |
| DL-DEP-5.1 | Le retour arrière est automatique sur dépassement de seuil de santé | Test provoquant un retour arrière |
| DL-DEP-5.2 | Les changements sont analysés après chaque échec (analyse sans reproche) et les actions sont suivies | Rapports d'incident clos |
| DL-DEP-5.3 | Des exercices de panne (reprise après sinistre, perte d'un environnement) sont menés au moins annuellement | Compte rendu d'exercice |
| DL-DEP-5.4 | Le coût d'exploitation par déploiement et par environnement est connu et optimisé | Tableau de coût |
Lecture détaillée par niveau#
🟢 Niveau 1 — Héroïque#
- Signes : déploiements nocturnes, copie de fichiers à la main, chaque version est un événement, les incidents se règlent « à chaud » par la seule personne qui sait.
- Gain : maîtrise individuelle.
- Ne garantit pas : ni répétabilité, ni disponibilité des personnes clés.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Procédurée#
- Signes : une checklist, un journal, des sauvegardes. Les déploiements sont plus lents mais moins hasardeux.
- Gain : la connaissance est écrite.
- Ne garantit pas : que la procédure soit suivie à la lettre — le facteur humain demeure.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Répétable#
- Signes : on déploie par script ; le retour arrière est testé (un retour arrière jamais rejoué est une hypothèse). Les migrations de base sont idempotentes : relancer le script deux fois laisse le même état, ce qui permet de reprendre après une panne à mi-chemin.
- Gain : déploiements réguliers et ennuyeux ; baisse des incidents de mise en production.
- Ne garantit pas : la disponibilité continue — une indisponibilité brève subsiste.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Sans interruption#
- Signes : déploiement sans arrêt de service, bascules de fonctionnalité, exposition progressive. La migration de schéma se fait en deux temps : on ajoute (expand), on migre, puis on retire (contract) une fois que plus aucun consommateur n'utilise l'ancien.
- Gain : le déploiement cesse d'être corrélé au risque métier.
- Ne garantit pas : l'absence d'incident ; il le limite et le contient.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Autonome#
- Signes : retour arrière automatique sur dégradation d'un indicateur de santé ; analyse sans reproche ; exercices de panne réguliers.
- Gain : résilience prouvée, pas supposée.
- Ne garantit pas : la rentabilité — l'automatisation poussée a un coût de conception qui n'a de sens qu'au-delà d'un certain volume de changements.
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-DEP-3.2 : retour arrière testé une fois, il y a plus d'un an.
- 0,5 sur DL-DEP-3.3 : migrations idempotentes pour la moitié des objets (les autres échouent au second passage).
- Un 5 partiel : retour arrière automatique pour l'application, manuel pour la base.
Retour arrière illusoire. Symptôme : « on restaurera la sauvegarde » — mais depuis le déploiement, des utilisateurs ont saisi des données. Cause : confondre restauration et retour arrière. Remède : changements compatibles N-1 pour que revenir au code précédent ne nécessite pas de restaurer les données.
Dérive d'environnement. Symptôme : « ça ne s'installe pas chez ce client ». Cause : changements manuels. Remède : décrire en code et vérifier la dérive.
Testez votre procédure d'installation sur un environnement vierge et sur un environnement à la version précédente : ce sont deux chemins différents ; ne tester que l'un fait manquer l'autre.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : checklist, journal des déploiements, sauvegarde obligatoire avant.
- 2 → 3 : script unique, test de fumée, migrations idempotentes, exercice de retour arrière.
- 3 → 4 : bleu/vert ou déploiement progressif, bascules, migrations en deux temps.
- 4 → 5 : surveillance de santé liée au retour arrière automatique ; exercices de panne.
Une migration supprime une colonne utilisée par deux rapports. Niveau 2 : suppression directe, les rapports cassent le lundi matin. Niveau 4 : (1) ajout de la nouvelle colonne, (2) migration des consommateurs sur 2 versions, (3) retrait de l'ancienne à la version suivante, avec une vue de compatibilité entre-temps.
Un objectif « zéro incident de déploiement » pousse à déclarer des incidents comme des « changements normaux ». Mesurez aussi les déploiements retardés ou évités par peur.
Voir aussi#
- Voisins : 05 CI · 07 Sécurité · 08 Observabilité et fiabilité · 09 Dette technique.
- Autres matrices : Projet — livraison et mise en production · Data — exploitation et support · BI — exploitation, supervision et capacité.
- Pratique : CI/CD · CI/CD pour la data · Azure DevOps / TFS · GDS et données SQL/BI.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
