Depuis l’entrée en application du RGPD en mai 2018, la question du lieu d’hébergement des données personnelles ne se limite plus à une préférence de principe : elle engage la responsabilité du responsable de traitement. Une agence qui héberge le site d’un client soumis à des exigences de conformité renforcées se retrouve régulièrement contrainte de rapatrier un site infogéré chez un fournisseur américain vers un hébergeur relevant pleinement du droit européen.
Le site en question tourne depuis plusieurs années sur une offre infogérée nord-américaine, avec son propre système de cache propriétaire et ses propres contraintes d’accès. Le migrer vers un hébergeur souverain européen suppose de reconstruire, une par une, chaque dépendance à la plateforme d’origine.
Étape 1 : cartographier les dépendances propriétaires
Avant tout export, il faut lister ce qui, dans la configuration actuelle, dépend spécifiquement de la plateforme d’origine : extensions de cache propriétaires, constantes définies automatiquement dans wp-config.php, règles de redirection gérées hors de WordPress via l’interface du fournisseur. Chacun de ces éléments devra être reconstruit manuellement chez le nouvel hébergeur.
wp plugin list --status=active --format=csv > extensions-actives.csv
Étape 2 : exporter proprement le contenu et les médias
L’export de la base et des médias se fait par WP-CLI, jamais par une extension tierce de migration en un clic qui masque les détails de ce qui est réellement transféré :
wp db export dump-migration.sql
rsync -avz wp-content/uploads/ ./uploads-export/
Étape 3 : reconstruire l’environnement chez le nouveau fournisseur
Chez le fournisseur souverain, l’environnement doit reproduire la version de PHP utilisée en production d’origine, pour éviter qu’une fonction dépréciée ne provoque une erreur fatale au premier chargement :
wp core version
php -v
L’import de la base se fait ensuite sur l’environnement cible, suivi immédiatement d’un remplacement d’URL testé à blanc avant exécution réelle :
wp db import dump-migration.sql
wp search-replace 'https://ancien-domaine.fr' 'https://nouveau-domaine.fr' --dry-run
Étape 4 : tester intégralement avant toute bascule DNS
Le nouvel environnement doit être testé dans ses moindres recoins avant que le domaine ne pointe dessus : formulaires de contact, paiement si applicable, emails transactionnels, et surtout les redirections héritées de l’ancien fournisseur, qui doivent être recréées explicitement via un fichier de règles ou une extension de redirection.
- Accès au site via le fichier
hostslocal, en pointant temporairement vers l’adresse IP du nouveau serveur ; - Vérification systématique de chaque formulaire présent sur le site ;
- Contrôle des certificats TLS générés côté nouveau fournisseur avant toute ouverture publique.
Étape 5 : réduire le TTL DNS avant la bascule
Quarante-huit heures avant la bascule effective, le TTL des enregistrements DNS du domaine doit être abaissé à une valeur courte, généralement 300 secondes, pour que le changement de destination se propage rapidement une fois la décision prise :
exemple.fr. 300 IN A 203.0.113.10
Étape 6 : basculer et surveiller
Une fois le DNS mis à jour vers l’adresse du nouveau fournisseur, une surveillance rapprochée pendant les premières heures permet de détecter tout comportement anormal : erreurs 500 imprévues, ralentissements liés à une configuration de cache non encore optimisée, ou emails transactionnels non délivrés faute de configuration SPF à jour.
Une règle qui a évité une interruption de service sur ce type de migration : ne jamais résilier l’ancien contrat avant d’avoir observé au moins une semaine complète de fonctionnement stable sur le nouveau fournisseur.
En résumé
Rapatrier un site infogéré vers un hébergeur souverain européen n’est jamais une opération d’un seul week-end : c’est une séquence d’étapes vérifiables, chacune testée avant la suivante, où le changement de DNS n’intervient qu’en toute dernière position, une fois que tout le reste a fait ses preuves.
