# Migrer un parc WordPress vers un hébergeur souverain européen : notre retour

> Un client impose désormais l'hébergement exclusif de ses données en Europe. Retour d'expérience sur la migration réelle d'un parc de douze sites et ses difficultés opérationnelles.

- Auteur : Clément Hadrot
- Publié le : 2026-02-09
- Mis à jour le : 2026-02-09
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/migrer-parc-wordpress-hebergeur-souverain-europeen-retour/

## L’essentiel

- Le CDN utilisé jusque-là posait plus de difficultés que l'hébergement lui-même
- Deux plugins tiers envoyaient des données vers des services hors Europe sans que personne ne le sache
- La migration a pris trois semaines de plus que prévu à cause de ces dépendances cachées

Un client du secteur public nous a notifié, suite à une nouvelle directive interne, que l'intégralité de ses données devait désormais être hébergée et traitée exclusivement sur le territoire de l'Union européenne — hébergement, CDN, service d'emails, et tout service tiers intégré au site. Douze sites WordPress étaient concernés par cette exigence.

Cet article ne revient pas sur le sujet de principe de la souveraineté numérique, déjà traité en 2023 de notre côté. Il détaille la migration réelle de ce parc, en particulier les difficultés opérationnelles rencontrées qui dépassaient largement le simple changement d'hébergeur.

## Le plus facile : changer d'hébergeur web

Contrairement à ce que l'on aurait pu craindre, le changement d'hébergeur proprement dit s'est avéré la partie la plus simple du projet. L'ancien prestataire, un hébergeur américain avec datacenter européen, a été remplacé par un hébergeur français, avec une migration classique par synchronisation de fichiers et export-import de base de données, sans incompatibilité technique notable sur les douze sites.

La difficulté réelle est apparue lors de l'audit préalable des dépendances externes de chaque site, une étape que le client n'avait pas anticipée mais que nous avons imposée avant toute migration, précisément parce qu'un hébergement européen ne garantit rien si les services tiers intégrés au site continuent, eux, de faire transiter des données hors de l'Union.

> L'essentiel à retenir : Le CDN utilisé jusque-là posait plus de difficultés que l'hébergement lui-même ; Deux plugins tiers envoyaient des données vers des services hors Europe sans que personne ne le sache ; La migration a pris trois semaines de plus que prévu à cause de ces dépendances cachées

## Le CDN, angle mort classique de ce type de projet

Le CDN utilisé jusque-là distribuait le contenu statique des douze sites depuis des points de présence répartis mondialement, dont plusieurs hors Union européenne, avec un routage automatique vers le point de présence le plus proche géographiquement du visiteur — un fonctionnement qui échappe largement au contrôle direct de l'hébergement choisi. Migrer vers une offre CDN européenne exclusivement a nécessité de vérifier explicitement, offre par offre, la localisation garantie contractuellement des points de présence utilisés, information rarement mise en avant sur les pages commerciales standards.

| Composant | Avant migration | Après migration |
| --- | --- | --- |
| Hébergement web | Hébergeur américain, datacenter UE | Hébergeur français |
| CDN | Réseau mondial, PoP hors UE inclus | Offre CDN garantie UE exclusivement |
| Messagerie transactionnelle | Service américain | Service européen |
| Analytics | Google Analytics | Solution auto-hébergée en UE |

## Les deux plugins qui envoyaient des données hors UE

L'audit préalable a révélé deux plugins tiers dont personne dans l'équipe cliente n'avait conscience du comportement réel : un plugin de vérification anti-spam sur les formulaires de contact, qui transmettait systématiquement l'adresse IP et le contenu des messages à un service de vérification hébergé aux États-Unis pour son analyse ; et un plugin d'optimisation d'images qui envoyait chaque image uploadée vers une API de compression externe, également hors Union européenne.

Le premier a été remplacé par une solution de protection anti-spam fonctionnant entièrement côté serveur, sans appel externe (validation par calcul simple côté client combinée à une limitation de taux). Le second a été remplacé par une bibliothèque de compression d'image exécutée localement sur le serveur, éliminant l'appel externe au prix d'une charge de traitement légèrement supérieure sur le serveur lors de l'upload.

- Auditer systématiquement les appels réseau sortants de chaque plugin actif, pas seulement leur description commerciale.
- Vérifier la localisation contractuelle réelle des CDN, pas uniquement leur siège social affiché.
- Ne pas se fier à la mention "conforme RGPD" d'un plugin sans vérifier concrètement où transitent les données.

> Un hébergement européen ne vaut que ce que valent les services tiers connectés au site. La souveraineté se joue autant dans les plugins actifs que dans le choix du serveur.

## Le délai réel, trois semaines de plus que prévu

Le projet avait été chiffré initialement sur la base d'une migration technique classique, estimée à une semaine pour l'ensemble du parc. L'audit des dépendances et le remplacement des deux plugins problématiques ont ajouté trois semaines supplémentaires, principalement consacrées aux tests de non-régression sur les formulaires de contact et le comportement d'upload d'image sur chacun des douze sites.

## Ce que nous en retenons

Sur un projet de migration vers un hébergement souverain, l'audit des dépendances tierces devrait systématiquement précéder le devis initial, pas s'y ajouter en cours de route. C'est désormais notre pratique standard pour ce type de demande, avec une grille d'audit reproductible d'un client à l'autre plutôt qu'une découverte au cas par cas comme cela a été le cas ici.