Un mandat d’hébergement se termine rarement par surprise : le client informe généralement plusieurs semaines à l’avance qu’il change de prestataire. Cette période de préavis est précieuse, car elle permet de préparer une restitution propre du serveur, plutôt que de couper les accès dans l’urgence le dernier jour. Ce billet ne traite pas des aspects contractuels de la résiliation, ni des clauses de préavis ou de pénalité : il se concentre sur les vérifications techniques à mener avant de rendre effectivement la main.
La liste qui suit vient de plusieurs restitutions menées sur des serveurs WordPress mutualisés ou dédiés, où l’absence de vérification a chaque fois causé un incident côté client dans les jours suivant le transfert, souvent invisible jusqu’à ce qu’une tâche planifiée cesse de s’exécuter ou qu’un email transactionnel ne parte plus.
Vérifications sur les sauvegardes et les données
- Contrôler que la dernière sauvegarde est restaurable, pas seulement présente. Une sauvegarde qui existe sur le disque mais qui échoue à la restauration ne vaut rien pour le nouveau prestataire.
- Exporter un dump complet de chaque base de données avec
mysqldump --single-transaction --routines --triggers, en vérifiant que les procédures stockées et déclencheurs éventuels sont bien inclus, un oubli fréquent avec un export minimal. - Vérifier la cohérence du répertoire médias par rapport à ce que référence la base de données, pour éviter de transmettre des fichiers orphelins ou, pire, des références cassées vers des médias absents.
Vérifications sur les automatisations invisibles
- Lister l’intégralité des tâches planifiées avec
crontab -lpour chaque compte système concerné, y compris les tâches système hors du compte applicatif principal. - Documenter les tâches déclenchées par
wp cron event list, en particulier celles qui dépendent d’un déclencheur externe (webhook, cron système) plutôt que du cron interne à WordPress. - Vérifier les scripts de purge ou de rotation de logs configurés en dehors de WordPress, souvent oubliés parce qu’ils tournent silencieusement depuis des années sans jamais générer d’alerte.
Vérifications sur les accès et la séparation des ressources
- Recenser tous les comptes ayant un accès SSH ou SFTP au serveur, y compris les comptes de service utilisés par des intégrations tierces, avant de préparer leur révocation à la date de bascule effective.
- Vérifier qu’aucune ressource du client ne dépend d’un composant partagé avec un autre client hébergé sur le même serveur : base de données commune, certificat TLS mutualisé, ou tâche cron définie au niveau système plutôt que par compte.
- Contrôler les clés API et secrets stockés en dur dans
wp-config.phpou dans les variables d’environnement du serveur, pour s’assurer qu’ils seront bien transmis et non oubliés dans un fichier de configuration jamais documenté.
Vérifications réseau et DNS
- Établir la liste exhaustive des enregistrements DNS liés au domaine, y compris les enregistrements de messagerie (MX, SPF, DKIM) qui sont souvent gérés séparément de l’hébergement web et faciles à oublier lors d’un transfert.
- Vérifier la configuration TLS, notamment si un certificat a été émis nominativement pour l’infrastructure actuelle et devra être régénéré chez le nouveau prestataire plutôt que simplement copié.
- Documenter les règles de pare-feu ou de blocage géographique spécifiques appliquées pour ce client, qui ne figurent généralement dans aucun fichier de configuration visible par le nouveau prestataire sans explication.
Ce que révèle cette liste
La majorité de ces points ne concernent pas WordPress lui-même mais tout ce qui gravite autour : automatisations système, secrets de configuration, dépendances partagées avec d’autres clients sur un même serveur mutualisé. C’est précisément cette partie invisible qui cause le plus d’incidents après une transition mal préparée, bien plus que le site WordPress lui-même, dont la migration reste en général bien documentée par les outils habituels.
Une restitution de serveur réussie se reconnaît à l’absence totale d’incident dans les deux semaines qui suivent, pas à la rapidité du transfert lui-même.
En résumé
Rendre un serveur à un client qui part vers un autre prestataire demande une rigueur différente de celle d’une simple migration technique : il faut penser à tout ce qui n’est pas explicitement documenté, des tâches planifiées oubliées aux ressources partagées avec d’autres comptes du même serveur mutualisé. Une liste de contrôle suivie systématiquement, point par point, évite l’essentiel des incidents qui surviennent typiquement dans les semaines suivant une transition mal préparée.
