Dans beaucoup de chaînes de livraison, la partie visible est la CI : tests, build, image, statut vert. Pourtant, une chaîne peut rester fragile même si la CI fonctionne correctement.
La fragilité apparaît lorsque personne ne peut répondre rapidement à trois questions simples : quelle version a été validée ? quelle version a été promue ? quelle version est réellement servie ?
Le staging n’est pas seulement une deuxième URL
Un staging utile doit représenter un candidat identifiable. Si le staging contient une version et que la production reçoit ensuite un artefact reconstruit ou modifié, l’acceptation perd une partie de sa valeur : on ne valide plus exactement ce qui sera publié.
C’est pour cela que l’identité de version — commit, image ou artefact versionné — est un élément opérationnel, pas un détail de tooling.
La promotion production est une décision
Une validation technique réussie ne constitue pas automatiquement une autorisation de production. La promotion doit rester une étape explicite, liée à un candidat déjà identifié et accepté.
La boucle se ferme après le déploiement
Le déploiement n’est pas terminé au moment où les fichiers ou les conteneurs sont copiés. Il faut encore vérifier le service et, lorsque c’est possible, confirmer l’identité de la version publiée.
Cette vérification post-déploiement transforme la livraison en boucle contrôlée : on sait ce qui devait partir, ce qui est parti et ce qui répond réellement.
Le rollback commence avant l’incident
Penser au rollback uniquement lorsqu’un incident arrive est trop tard. La limite de retour arrière dépend de la façon dont les artefacts sont versionnés, de la compatibilité des changements et de la capacité à retrouver une version précédente connue.
Le modèle mental à retenir
- identifier le changement ;
- construire et valider un candidat ;
- déployer ce candidat en staging ;
- accepter explicitement ce candidat ;
- le promouvoir en production ;
- vérifier ce qui est effectivement servi ;
- connaître la frontière de retour arrière.
Si vous souhaitez aller au-delà du retour d’expérience et travailler les mécanismes en profondeur, les matières suivantes restent canoniques sur la plateforme pédagogique :
Voir la réalisation associée
La page de réalisation décrit le chemin Git → CI → image versionnée → registre privé → staging → acceptation → production → vérification tel qu’il est utilisé dans des environnements SORIA.
voir la réalisation DevOps