Mise en production : la checklist qui évite les angles morts

Avant le déploiement : savoir ce qui part et où

Une mise en production fiable commence par une version identifiable, un environnement connu et une liste claire des dépendances. Les variables de configuration et les secrets doivent être séparés du code et accessibles uniquement aux rôles concernés.

Les changements de données méritent une attention spécifique : ordre d’exécution, compatibilité avec la version précédente et possibilité de revenir à un état stable.

• Version et changements identifiés.
• Environnements et dépendances confirmés.
• Accès et secrets vérifiés sans les exposer dans les journaux.
• Sauvegarde ou stratégie de retour adaptée au changement.

Pendant le déploiement : rendre le chemin vérifiable

Chaque étape importante doit produire un état compréhensible. Les vérifications automatiques réduisent les oublis, mais les critères d’arrêt et la responsabilité de la décision finale doivent rester explicites.

Lorsque plusieurs services évoluent ensemble, leur ordre et leur compatibilité temporaire doivent être décrits. Cette préparation évite qu’un déploiement partiellement terminé soit confondu avec une mise en ligne réussie.

Après le déploiement : observer les usages et les dépendances

Une vérification de disponibilité ne suffit pas toujours. Les premiers contrôles doivent couvrir les parcours essentiels, les échanges avec les dépendances et les erreurs qui empêchent réellement l’usage.

Les alertes sont utiles lorsqu’elles correspondent à une action. Leur message doit indiquer le service concerné, le signal observé et le premier contexte disponible.

• Tester les parcours essentiels après mise en ligne.
• Relier les signaux au changement déployé.
• Confirmer la réception des alertes par le rôle prévu.
• Documenter toute intervention réalisée pendant la stabilisation.

Terminer par une transmission exploitable

La livraison inclut les accès, les responsables, les repères d’observation et la façon de traiter un incident courant. Ces éléments doivent être accessibles sans dépendre de la mémoire de la personne qui a déployé.

La checklist n’est pas un document figé. Elle évolue à partir des changements réels, des incidents et des décisions prises pendant l’exploitation.