4. Livrer, observer, apprendre

Un commit validé n'est pas la fin du changement. La production ajoute du trafic, des données anciennes, des usages imprévus, des dépendances défaillantes et de vraies personnes. Livrer avec confiance signifie limiter l'exposition, savoir quoi regarder et pouvoir agir.

Une livraison est une expérience contrôlée

Séparez autant que possible : déployer le code, activer le comportement, étendre l'audience et nettoyer l'ancien chemin. Chaque étape doit avoir un signal de succès, un seuil d'arrêt et un moyen de revenir à une situation sûre.

Un flag n'est pas automatiquement une solution. Il doit avoir un propriétaire, un périmètre, une permission, une échéance de retrait et une stratégie si les deux chemins produisent des données différentes.

Observer les conséquences, pas seulement les machines

Suivez d'abord le résultat pour l'utilisateur : commande terminée, délai acceptable, droit correctement appliqué. Les métriques de CPU, de logs ou de requêtes sont ensuite utiles pour expliquer et localiser l'écart.

Une alerte est bonne lorsqu'une personne sait quelle décision prendre en la recevant. Une alerte sans action claire est du bruit qui affaiblit les vraies urgences.

Après l'incident

Stabiliser vient avant d'expliquer. Puis reconstruire les faits sans chercher un coupable : quelles protections ont manqué ? quelle information est arrivée trop tard ? quelle amélioration réduira vraiment la probabilité, l'impact ou le délai de réparation ?

Approfondir : livraison progressive, observabilité, réponse aux incidents et fiabilité.