Le bouton « Déployer » est vert. Le chef de projet annonce la mise en ligne à quatorze heures. À quatorze heures vingt, le site répond — mais les e-mails transactionnels partent encore de l'ancien serveur, le certificat couvre le mauvais domaine, et personne n'a prévenu le support qu'un nouveau flux de tickets arrive. À dix-huit heures, la direction demande un retour arrière que personne ne sait exécuter en moins de deux heures.
Passer en production est un événement organisationnel, pas un envoi de code. Cette checklist relie ce que la technique exécute et ce que le métier doit comprendre — sans jargon inutile, sans oublier les pièces qui font mal : DNS, enregistrements MX, cookies, facturation.
Avant le jour J : alignement métier
Une réunion de trente minutes suffit si elle produit un document partagé d'une page. Chaque ligne doit avoir une réponse écrite : la fenêtre de maintenance (date, heure, fuseau, qui reste disponible quatre heures), trois critères de succès mesurables (connexion OK, paiement test OK, taux d'erreur serveur inférieur à un pour cent), le décideur et la procédure de retour arrière, le plan de communication (e-mail clients, page de statut, brief support), et les contraintes sur les données (migration de base, gel des écritures).
Si le métier ne peut pas expliquer le retour arrière en une phrase, vous n'êtes pas prêts.
Ce document n'est pas une formalité : c'est ce qui évite qu'un directeur annonce « tout est en ligne » pendant que les e-mails de confirmation ne partent toujours pas.
Checklist technique : infrastructure et DNS
Côté infrastructure, vérifiez qu'une sauvegarde de production récente existe et qu'une restauration a été testée dans les sept derniers jours. L'environnement de production doit correspondre au staging (versions PHP, extensions, tâches planifiées). Les secrets de production doivent être distincts — jamais copiés depuis un fichier de développement. Le monitoring doit alerter sur les erreurs serveur, l'espace disque et l'expiration des certificats. Les journaux doivent être centralisés ou accessibles sans fouiller trois serveurs.
Côté DNS et certificats, abaissez le TTL vingt-quatre à quarante-huit heures avant la bascule. Documentez les enregistrements A, AAAA et CNAME avec un plan de retour vers l'ancienne adresse IP. Si l'e-mail change de serveur, vérifiez MX, SPF, DKIM et DMARC. Le certificat TLS doit couvrir tous les noms d'hôte (www et domaine racine).
Côté application, appliquez les migrations de base avec un script de retour arrière en cas d'échec. Videz ou préchauffez le cache selon la stratégie choisie. Utilisez des drapeaux de fonctionnalité pour activer progressivement. Exposez un point de contrôle de santé (/health) pour le répartiteur de charge.
Jour J : séquence et rôles
Soixante minutes avant la bascule : gel du contenu, sauvegarde finale, équipe d'astreinte confirmée. À l'heure H : bascule DNS ou commutation de trafic ; surveillez la propagation avec des outils externes, pas seulement depuis votre bureau. Quinze minutes après : tests automatisés et parcours métier manuel (commande, inscription). Une heure après : revue des métriques et décision de continuer ou de revenir en arrière. Vingt-quatre heures après : remontez le TTL DNS et tenez un post-mortem court, même en cas de succès.
Nommez les rôles : commandant d'incident (décide du retour arrière), responsable technique, communication, validateur métier. Sans noms, tout le monde attend que quelqu'un d'autre décide.
Ce que le non-technique doit entendre
Expliquez sans infantiliser : « Nous changeons où le site vit sur Internet — pas seulement le design. » « La propagation DNS peut prendre jusqu'à X heures malgré un TTL bas. » « Le retour arrière ramène l'ancien site, pas une version intermédiaire. » « La première heure, c'est une surveillance renforcée — pas une panne garantie. »
Ces phrases évitent les malentendus du type « le site est en ligne donc tout fonctionne » alors que le parcours paiement ou e-mail est encore cassé.
Le sommet : go-live réussi = personne ne remarque — go-live raté = tout le monde
Le marketing compte les confettis. L'exploitation compte les parcours complets : inscription, paiement, e-mail, administration, API partenaire.
Décider et avancer sans angle mort
Rédigez un document d'une page pour le métier et une checklist technique signée par l'équipe. Testez le retour arrière sur staging en le chronométrant — si cela prend plus d'une heure, corrigez avant le jour J. Briefez le support avec les incidents probables et les réponses types. Préparez un plan de communication si la dégradation dépasse trente minutes. Tenez un post-mortem quarante-huit heures après : trois points à conserver, trois à améliorer.
Voir déploiement blue-green et contrôle de santé applicatif. Comparez les hébergeurs via l'annuaire.
Questions fréquentes
Quelle est la différence entre staging et production ?
Production sert les utilisateurs réels avec un engagement de disponibilité, des sauvegardes testées, un monitoring qui alerte, et une procédure de retour arrière documentée. Staging reproduit la configuration — pas la charge réelle ni toujours des données anonymisées correctement.
Combien de temps avant le go-live faut-il baisser le TTL DNS ?
Vingt-quatre à quarante-huit heures avant la bascule, passez le TTL à 300 secondes. Remontez-le après stabilisation pour réduire la charge sur les serveurs DNS.
Que doit comprendre un chef de projet non technique ?
La fenêtre de maintenance, le risque résiduel, qui décide du retour arrière, le canal de communication en cas d'incident, et des critères de succès mesurables — pas un simple « ça a l'air correct ».
Faut-il un runbook rollback écrit ?
Oui — étapes numérotées, responsables nommés, durée estimée, et test au moins une fois sur staging. Un retour arrière improvisé coûte plus cher que l'incident initial.
La production commence quand le parcours client complet tient — pas quand le pipeline d'intégration continue affiche vert.