Un client cesse son activité, fusionne avec une autre société, ou remplace tout simplement un ancien site par un nouveau hébergé ailleurs : dans tous ces cas, l’agence se retrouve à devoir éteindre un site WordPress dont l’hébergement continue de coûter de l’argent sans justification. La tentation est grande de simplement résilier l’abonnement chez l’hébergeur et de passer à autre chose. Cette précipitation cause pourtant des pertes évitables : historique perdu, référencement effacé, e-mails qui cessent brutalement de fonctionner.
Cette checklist commentée liste, dans l’ordre, les six étapes suivies par l’agence avant de résilier définitivement un hébergement WordPress. Chaque étape dépend de la précédente : les sauter dans le désordre expose à des pertes qu’aucune sauvegarde ne rattrape après coup.
1. Faire l’inventaire de ce qui doit survivre au site
Avant toute chose, lister ce qui a de la valeur indépendamment du site lui-même : les adresses e-mail encore actives sur le domaine, les enregistrements DNS utilisés par des services tiers (un enregistrement SPF pour un outil d’e-mailing, un sous-domaine pointant vers une application distincte), et les certificats ou clés d’API encore référencés ailleurs. Sur un projet archivé pour une association qui fusionnait avec une autre structure, cet inventaire a révélé un enregistrement MX encore utilisé par une boîte mail que personne n’avait pensé à migrer.
2. Produire une sauvegarde finale et la vérifier
Une sauvegarde d’archivage ne ressemble pas à une sauvegarde de routine : elle doit être complète, incluant la base de données, l’intégralité de wp-content, et idéalement une copie du wp-config.php nettoyée de ses secrets pour référence future.
wp db export archive-finale-$(date +%Y%m%d).sql --allow-root
tar czf archive-finale-$(date +%Y%m%d).tar.gz \
wp-content archive-finale-$(date +%Y%m%d).sql
# Vérification immédiate : l'archive doit être lisible
tar tzf archive-finale-$(date +%Y%m%d).tar.gz > /dev/null && echo "Archive lisible"
Cette archive part vers un stockage froid distinct de l’hébergement du site, par exemple un bucket S3 en classe Glacier, avec une durée de conservation définie contractuellement avec le client, généralement entre trois et cinq ans selon le secteur d’activité.
3. Décider du sort des redirections
Si le site avait un référencement établi, avec des pages indexées recevant du trafic organique, une coupure sèche transforme des années de travail SEO en pages d’erreur 404. La solution consiste à conserver le domaine actif, sans hébergement WordPress complet derrière, mais avec un service de redirection minimal qui renvoie les anciennes URL vers un nouveau site ou vers une page d’information sur la fermeture.
- Un fichier de redirections statique hébergé sur un service gratuit (Cloudflare Pages, Netlify) suffit largement pour ce cas d’usage résiduel.
- Les redirections 301 les plus consultées, identifiées via Google Search Console avant la coupure, méritent une redirection individuelle plutôt qu’un renvoi générique vers la page d’accueil.
- Un renvoi générique vers un domaine de remplacement convient pour le reste des URL, moins fréquentées.
4. Nettoyer les intégrations tierces
Un site WordPress vivant accumule des connexions à des services externes : un compte Google Analytics, une propriété Search Console, un webhook vers un CRM, une clé d’API de paiement. Chacune de ces intégrations mérite d’être révoquée ou désactivée explicitement, pas simplement laissée à l’abandon. Une clé d’API active sur un service tiers, associée à un site qui n’existe plus, reste une surface d’attaque inutile et une ligne de facturation qui continue parfois à courir.
Cas particulier des données personnelles
Si le site collectait des données personnelles, via un formulaire de contact ou un compte utilisateur, la fermeture du site ne dispense pas des obligations liées au RGPD. La suppression ou l’anonymisation de ces données, ou leur transfert vers l’entité qui reprend la relation avec les personnes concernées, doit être tranchée avec le client avant la coupure définitive, pas après.
5. Documenter la fermeture
Un document synthétique, remis au client et conservé en interne, récapitule la date de fermeture, l’emplacement de l’archive finale, la durée de conservation prévue, et les redirections mises en place. Ce document évite, des années plus tard, qu’un ancien collaborateur du client se demande où est passé « le site de 2019 » sans que personne ne puisse répondre.
Un site qui ferme mal laisse toujours une trace gênante : un mail qui rebondit, une redirection cassée, un client qui rappelle six mois plus tard pour retrouver un document qu’il croyait perdu.
6. Couper l’hébergement en dernier, jamais en premier
La résiliation de l’hébergement WordPress lui-même, la dernière étape, ne doit intervenir qu’une fois les cinq points précédents validés et la sauvegarde finale confirmée lisible. Couper l’hébergement avant d’avoir sécurisé une sauvegarde vérifiée revient à parier que rien ne se passera mal entre la demande de résiliation et sa prise en compte effective par l’hébergeur, un pari perdu plus souvent qu’on ne le pense face à des scripts de purge automatisés parfois trop rapides.
| Étape | Peut être annulée après coup |
|---|---|
| 1. Inventaire | Oui, mais coûteux à refaire |
| 2. Sauvegarde finale vérifiée | Non, doit être faite avant la suite |
| 3. Redirections | Oui, mais perte de trafic entre-temps |
| 4. Nettoyage des intégrations | Oui, à tout moment |
| 5. Documentation | Oui, mais perte de mémoire si tardif |
| 6. Résiliation hébergement | Non, irréversible |
Pour aller plus loin
Cette checklist concerne exclusivement la fin de vie d’un site devenu inutile. La démarche inverse, celle de la mise en production d’un nouveau site qui remplace l’ancien, avec sa propre liste de vérifications, mérite un traitement séparé et ne recoupe que partiellement celle-ci : les redirections notamment s’y retrouvent, mais dans le sens opposé.
