Le code est prêt, la recette est validée, le client a donné son feu vert. Et pourtant, c’est souvent à ce moment précis — dans les minutes qui suivent la bascule — que les problèmes surgissent : un plugin de cache qui sert encore une page 503, un formulaire qui n’envoie plus d’e-mail parce que le SMTP pointait vers l’environnement de recette, ou pire, un site resté invisible aux moteurs de recherche pendant trois semaines parce que la case « Décourager les moteurs de recherche » n’a jamais été décochée.
Nous tenons une checklist depuis plusieurs projets ratés à petite échelle. Elle n’a rien d’extraordinaire, mais elle a le mérite d’être suivie dans le même ordre à chaque fois, ce qui évite d’oublier une étape sous la pression du jour J. La voici, telle que nous l’utilisons.
Avant la bascule : ce qui se prépare la veille
Une mise en production réussie se prépare la veille, pas le matin même. Trois choses doivent être actées avant de toucher au DNS ou au serveur de production :
- La liste des redirections d’URL, si la nouvelle arborescence diffère de l’ancienne (changement de structure de permaliens, fusion de pages, refonte de la navigation) ;
- La liste des comptes utilisateurs à créer ou à désactiver, en particulier les comptes de test qui traînent depuis la recette ;
- Le créneau de bascule, communiqué au client avec une marge de sécurité d’au moins deux heures avant toute échéance externe (campagne e-mail, communiqué de presse).
La sauvegarde initiale, avant toute action
Avant de toucher quoi que ce soit sur l’environnement de production, on prend un instantané. Même si le site est tout neuf, même si rien n’existe encore côté contenu : cette sauvegarde sert de point zéro auquel revenir si l’import se passe mal.
wp db export backup-jour-j-$(date +%Y%m%d-%H%M).sql
wp eval 'echo ABSPATH;' # vérifier qu'on est bien sur le bon environnement avant de lancer quoi que ce soit
Indexation et visibilité pour les moteurs
C’est le piège le plus classique et le plus coûteux : un site de recette copié tel quel en production, avec le réglage Visibilité par les moteurs de recherche toujours coché sur « Décourager les moteurs de recherche ». Le champ correspond à l’option blog_public en base. On la vérifie en ligne de commande plutôt qu’à l’œil :
wp option get blog_public
# doit renvoyer 1 en production, jamais 0
wp option update blog_public 1
On vérifie aussi le contenu du fichier robots.txt généré dynamiquement par WordPress via le filtre robots_txt, et on s’assure que le sitemap XML natif (actif depuis WordPress 5.5) répond correctement sur /wp-sitemap.xml.
Caches à tous les étages
Un site fraîchement basculé traîne souvent des caches obsolètes à plusieurs niveaux : cache objet (Redis ou Memcached), cache de page (plugin ou reverse proxy comme Varnish), cache serveur (OPcache) et cache navigateur côté CDN. On les vide dans cet ordre précis, du plus proche du code au plus proche de l’utilisateur, pour éviter de re-cacher une page générée avec de vieilles données :
- Purge de l’OPcache PHP (redémarrage du pool PHP-FPM si nécessaire) ;
- Purge du cache objet, avec
wp cache flushsi un backend persistant est configuré ; - Purge du cache de page (plugin dédié ou commande du reverse proxy) ;
- Purge du cache CDN, en dernier, une fois qu’on est sûr que les pages régénérées sont correctes.
Emails, crons et tâches de fond
Les e-mails transactionnels (confirmation de commande, réinitialisation de mot de passe, notifications de formulaire) sont souvent le point mort le plus discret d’une mise en production : tout fonctionne visuellement, mais rien n’arrive en boîte de réception parce que le service SMTP configuré pointait encore vers un environnement de test, ou parce que le domaine n’a pas encore ses enregistrements SPF et DKIM en production.
On vérifie aussi que le pseudo-cron WordPress tourne réellement, particulièrement si l’hébergeur utilise un vrai cron système avec DISABLE_WP_CRON défini à true dans wp-config.php :
wp cron event list
wp cron test
Sur un lancement, on envoie systématiquement un e-mail de test via le formulaire de contact réel du site, pas via un outil de diagnostic SMTP. C’est le seul moyen de vérifier la chaîne complète, du plugin de formulaire jusqu’à la boîte du destinataire.
Monitoring et dernière vérification visuelle
Une fois la bascule faite, on active immédiatement un monitoring d’uptime basique (ping HTTP toutes les cinq minutes suffit pour commencer) et on parcourt à la main les parcours critiques : page d’accueil, un article, un formulaire, le tunnel de commande si le site est un site e-commerce. On vérifie aussi le certificat TLS, souvent oublié quand le domaine change de serveur.
| Vérification | Outil | Fréquence |
|---|---|---|
| Statut HTTP de la page d’accueil | Sonde externe | Toutes les 5 min |
| Expiration du certificat TLS | Alerte 30 jours avant | Une fois posée |
| Erreurs PHP en production | Log applicatif | Les 24 premières heures |
En résumé
Aucune de ces étapes n’est spectaculaire prise isolément. C’est leur oubli cumulé qui transforme une mise en production tranquille en après-midi de rattrapage. Garder la checklist visible, dans l’ordre, et la cocher devant le client donne aussi une image rassurante : le lancement n’est pas un saut dans le vide, c’est une procédure maîtrisée.
