Mise en production : la checklist qui évite de confondre “en ligne” et “vérifié”

# Mise en production : la checklist qui évite de confondre “en ligne” et “vérifié”

Une mise en production n'est pas terminée lorsqu'un lien répond. Elle est terminée lorsque l'équipe sait quel état est servi, comment il a été vérifié et quoi faire si le comportement observé ne correspond pas au changement attendu.

Cette distinction paraît technique. Elle est pourtant utile à toute PME qui dépend d'un site, d'un outil métier ou d'une automatisation : un écran accessible ne dit pas à lui seul quelle version travaille réellement ni si le parcours important fonctionne comme prévu.

Pourquoi “ça répond” ne suffit pas

Un code HTTP 200 peut continuer à être renvoyé alors qu'un déploiement attendu n'est pas celui qui est servi. Le contrôle pertinent porte donc sur l'état effectivement déployé, notamment l'identifiant du changement servi, et non sur la seule disponibilité apparente.

Ce principe évite deux décisions hâtives : annoncer un lancement trop tôt et chercher un incident au mauvais endroit. Il ne promet pas qu'un contrôle empêchera tout problème. Il permet simplement de relier une observation à un état précis.

Avant le lancement : écrire ce qui doit rester vrai

Commencez par un périmètre limité. Listez les parcours qui comptent au premier jour : une demande de contact, un accès d'équipe, une synchronisation ou une page essentielle. Pour chacun, notez :

• le résultat attendu ;
• la personne qui le vérifie ;
• le moment du contrôle ;
• la trace conservée ;
• la décision à prendre si le résultat ne correspond pas.

Cette liste ne remplace pas les tests techniques. Elle donne aux personnes métier et techniques le même point de départ. Une validation utile décrit ce qui est observé ; elle ne se limite pas à “tout semble fonctionner”.

Pendant le contrôle : suivre des signaux lisibles

En cas de doute, une discipline simple consiste à vérifier d’abord l’état réellement servi, rechercher ensuite les signaux horodatés disponibles, puis reproduire le comportement dans un périmètre contrôlé. Ces étapes sont volontairement séparées. Une erreur applicative et un déploiement incomplet ne se traitent pas de la même manière.

Pour une petite équipe, l'important est de désigner à l'avance où regarder et qui décide. Un tableau de suivi, un journal d'incident ou une capture horodatée peuvent suffire s'ils sont reliés au périmètre réel du lancement.

Préparer le retour arrière avant d'en avoir besoin

Le retour arrière n'est pas l'aveu d'un échec. C'est une option de continuité. Il faut distinguer le rollback DNS, utilisé pour un problème de domaine ou de certificat, du rollback applicatif vers un déploiement stable.

Avant le lancement, répondez donc à quatre questions : quelle version stable peut être restaurée, qui autorise cette décision, quels effets doivent être vérifiés après le repli, et quel chemin de rollback correspond au problème observé ? Si les réponses n'existent qu'au moment de l'incident, l'équipe perd du temps à les inventer.

Checklist de mise en production

• [ ] Les parcours prioritaires sont nommés et attribués.
• [ ] L'état réellement servi peut être identifié.
• [ ] Les vérifications métier et techniques sont distinguées.
• [ ] Les traces et l'heure des contrôles sont conservées.
• [ ] Une personne peut décider d'arrêter ou de revenir en arrière.
• [ ] Le chemin de rollback et ses effets attendus sont explicités.
• [ ] La conclusion est écrite : validé, à corriger ou reporté.

Une méthode de décision, pas une promesse

Cette checklist ne garantit ni l'absence d'incident ni la continuité d'un service. Elle aide à transformer une mise en production en décision relisible : ce qui a été changé, ce qui a été vérifié et ce qui reste à surveiller.

Pour cadrer un projet numérique avant son déploiement, découvrez les services AAIT.