Mise en production

: la check-list qui

évite les incidents

Avant : tout ce qui peut se vérifier la veille se vérifie la veille

Le jour de la livraison, votre attention est déjà prise. Tout ce qui peut être fait à froid doit l'être avant, parce qu'une vérification faite sous pression est une vérification qu'on croit avoir faite.

Vérifier un accès, ce n'est pas retrouver le mot de passe dans un gestionnaire : c'est se connecter. Beaucoup de mises en production s'arrêtent pendant vingt minutes sur un compte de registrar dont le second facteur est resté sur le téléphone d'une personne en congé.

• Une sauvegarde datée de la base et des fichiers, prise juste avant l'opération, et dont on a ouvert le contenu pour confirmer qu'elle n'est pas vide.
• La liste des variables d'environnement et des secrets de production, comparée ligne à ligne avec celle de la préproduction : les écarts sont la première cause de site blanc après un déploiement.
• Les accès réellement testés : serveur, zone DNS, registrar, fournisseur de paiement, service d'envoi de courriels.
• Le TTL des enregistrements DNS abaissé à l'avance si un changement est prévu, faute de quoi un retour en arrière mettra des heures à se propager.
• Les redirections de l'ancien site vers le nouveau, écrites et testées sur la préproduction, pas rédigées le jour même.
• Les balises noindex et le robots.txt de recette, repérés pour être retirés au bon moment.
• Une heure de gel : au-delà, plus rien n'est fusionné. Ce qui arrive après passe à la prochaine fois.

Le point que tout le monde saute : avoir déjà fait marche arrière

Tout le monde a un plan de retour. Presque personne ne l'a exécuté. Et un plan de retour non exécuté échoue toujours au même endroit : la sauvegarde de la base date d'avant la migration de schéma, et l'ancienne version du code ne sait pas lire la nouvelle base. Vous restaurez le code, le site reste cassé, et vous découvrez le problème au moment où vous aviez le moins de marge.

Le retour en arrière n'est pas une commande, c'est un scénario complet : le code, le schéma de base, les fichiers téléversés depuis la bascule, les caches, les files d'attente. Répétez-le une fois sur une copie, avant la mise en production réelle, et chronométrez-le. La question utile n'est pas « est-ce possible » mais « en combien de temps », parce que c'est ce nombre qui décide si vous revenez en arrière ou si vous tentez un correctif.

Écrivez le seuil de déclenchement avant, pendant que tout le monde est calme : si à telle heure tel parcours ne fonctionne toujours pas, on revient en arrière. Pris dans l'incident, on choisit toujours de tenter un correctif de plus — c'est ainsi qu'une panne d'une demi-heure devient une soirée.

Une partie de l'opération ne se défait pas : les courriels partis, les paiements encaissés, les notifications envoyées, les webhooks consommés par un tiers. Repérez ces points avant, et coupez-les pendant la bascule plutôt que d'espérer les rattraper après.

Le meilleur moyen de rendre le retour possible est de déployer des changements de schéma compatibles : ajouter une colonne, ne pas supprimer celle qu'on remplace, faire vivre les deux le temps d'une version. La suppression se fait au déploiement suivant, quand plus personne ne doute. C'est une contrainte d'écriture, pas une contrainte d'exploitation.

Pendant : l'ordre des opérations ne s'improvise pas

Une bascule se déroule toujours dans le même ordre, et chaque inversion a sa manière de faire mal.

• Prévenir ceux qui vont recevoir les appels : support, commerce, standard. Ils doivent savoir avant les clients.
• Arrêter tout ce qui écrit dans la base sans vous demander votre avis : tâches planifiées, traitements de fond, connecteurs. Un traitement nocturne qui démarre au milieu d'une migration écrit dans une base à moitié transformée.
• Prendre la sauvegarde finale, après l'arrêt des écritures. Une sauvegarde prise pendant que le site travaille n'est pas un point de reprise fiable.
• Appliquer la migration de schéma, dans sa version compatible, avant de déployer le code qui s'en sert.
• Déployer le code, puis vider les caches dans l'ordre : applicatif d'abord, puis la couche de diffusion. L'inverse remet en cache l'ancienne version pour la durée de son expiration.
• Réactiver les tâches planifiées, et vérifier qu'elles repartent une fois, pas deux.
• Retirer le noindex et remettre le robots.txt de production. C'est l'oubli le plus silencieux de la liste.

Une page de maintenance honnête, et un seul pilote

Si la coupure dure, servez une page de maintenance avec un code HTTP 503 et un en-tête Retry-After. Servie en 200, la même page dit aux moteurs de recherche que le contenu de votre site, c'est ce message d'excuse — et ils le retiennent.

Une mise en production a un pilote, un seul, et il est nommé avant de commencer. Deux personnes qui déploient en parallèle produisent exactement l'incident qu'elles voulaient éviter, avec en prime un état de la production que plus personne ne sait décrire.

Les autres ne sont pas spectateurs pour autant : quelqu'un lit les journaux pendant que le pilote agit. Celui qui exécute ne voit pas ce qu'il casse, il voit ce qu'il lance.

Choisir le créneau : le vendredi 17 h n'est pas un créneau

Le bon moment n'est pas celui où le trafic est le plus faible. C'est celui où les gens capables de corriger sont réveillés, disponibles et pas en train de partir en week-end. Un site déployé vendredi en fin de journée reste cassé jusqu'à lundi, non pas parce que le problème est difficile, mais parce que personne ne le regarde.

Un mardi matin laisse trois jours ouvrés devant soi pour traiter ce qui remonte. Un lundi matin vous fait basculer juste après un week-end où personne n'a rien suivi. Et une mise en production la veille d'un pont, d'un départ en congé ou d'une campagne qui démarre n'a pas besoin d'être discutée : elle se reporte.

Certains sites ont une activité qui interdit la journée. Dans ce cas, le créneau nocturne se choisit avec l'astreinte qui va avec : qui veille, jusqu'à quelle heure, et ce qu'il a le droit de décider seul à trois heures du matin. Une bascule de nuit sans astreinte organisée n'est pas une précaution, c'est un pari.

Après : la demi-heure qui décide si la livraison est terminée

Un déploiement n'est pas fini quand le code est en ligne. Il est fini quand un parcours complet a été refait à la main, sur la production, par quelqu'un qui regarde le résultat.

• Faire un vrai achat, un vrai devis ou un vrai envoi de formulaire, et attendre le courriel de confirmation dans une vraie boîte de réception.
• Ouvrir les journaux d'erreurs, serveur et applicatif, et les lire pendant quelques minutes au lieu de les consulter une fois.
• Vérifier le certificat, la redirection entre domaine nu et www, et qu'aucune ressource ne se charge encore en clair.
• Tester quelques anciennes adresses parmi les plus visitées et confirmer qu'elles renvoient bien une redirection permanente, pas une page d'erreur.
• Contrôler que le noindex a disparu et que le sitemap servi est celui du nouveau site.
• Ouvrir le site sur un vrai téléphone, en données mobiles, hors du réseau du bureau.

Le lendemain : ce qui ne se voit pas le jour même

Trois choses cassent après coup, sans bruit, et ne se remarquent qu'au pire moment.

La sauvegarde automatique de la nuit, d'abord : vérifiez qu'elle a tourné et qu'elle contient bien la nouvelle base. Une mise en production réussie qui casse la sauvegarde nocturne est une mise en production ratée dont vous ne l'apprendrez que le jour de la restauration.

Les courriels transactionnels ensuite. L'authentification du domaine expéditeur change avec l'hébergement, et rien dans une interface d'administration ne vous dira que vos messages arrivent en indésirables. Cela ne se voit pas dans vos journaux, cela se voit dans la boîte de vos clients — ou plutôt, cela ne s'y voit pas.

Les erreurs 404 apparues dans les journaux enfin : elles dessinent la carte des redirections que vous avez oubliées, et elles sont exploitables dès le lendemain. Attendre une baisse de visibilité pour les regarder, c'est attendre plusieurs semaines une information disponible tout de suite.

Une check-list tenue en tête n'est pas une check-list

Sous pression, la mémoire saute précisément les lignes qu'on croit connaître par cœur. La liste doit être écrite, tenir sur une page, suivre l'ordre d'exécution, et se cocher pendant l'opération — pas se relire après.

Elle porte un nom en face du feu vert : la personne qui décide qu'on y va, et qui décide qu'on revient en arrière. Une décision collective au milieu d'un incident n'est pas une décision, c'est une discussion.

Après chaque mise en production, ajoutez la ligne qui a manqué cette fois-ci. Une check-list utile n'est pas un modèle téléchargé : c'est la liste des incidents que le projet a déjà connus, et qu'il ne reproduira plus.