Comment migrer 80 sites clients vers une plateforme en marque blanche sans perdre ni positions ni clients ?
Un plan lot par lot pour les agences qui transfèrent des dizaines de sites clients sur une seule plateforme en marque blanche : inventaire, tri, communication avec les clients, reconstruction, redirections, bascule DNS et retour arrière, avec des tableaux à reprendre.
Migrez-les par petits lots, jamais tous à la fois. Commencez par l'inventaire de chaque site, classez les sites en « reconstruire », « déplacer tel quel » et « retirer », menez un pilote sur cinq sites à faible risque, puis migrez les autres dix à quinze à la fois avec la même liste de contrôle : reconstruire, faire correspondre chaque ancienne URL à une nouvelle avec des redirections permanentes, réduire la durée de vie (TTL) DNS la veille, basculer le domaine, et surveiller le trafic et les formulaires pendant deux semaines avant d'attaquer le lot suivant. Prévenez vos clients tôt, donnez une date à chacun et continuez à payer l'ancien hébergeur jusqu'à ce que le dernier lot soit stable. Les étapes ci-dessous en font un plan qu'une petite équipe peut mener en parallèle du travail client.
Pourquoi les agences se brûlent les doigts lors d'un changement de plateforme
Une migration de ce type échoue rarement parce que la nouvelle plateforme est mauvaise. Elle échoue sur les parties ennuyeuses :
- Un domaine enregistré il y a des années sur le compte personnel d'un client, et personne n'a l'identifiant.
- Un formulaire de contact qui envoyait discrètement les prospects dans la boîte d'un ancien employé, et qui désormais ne les envoie plus nulle part.
- D'anciennes URL bien positionnées depuis des années qui renvoient maintenant une erreur 404, et les appels du client chutent.
- Une messagerie cassée parce que quelqu'un a remplacé la zone DNS en oubliant les enregistrements de messagerie.
- Un client qui a appris le changement par l'un de ses propres clients, et non par vous.
Chaque étape ci-dessous existe pour éviter l'un de ces scénarios.
Étape 1 : dressez l'inventaire
Une ligne par site. Ne déplacez rien tant que toutes les colonnes ne sont pas remplies, car c'est dans les cases vides que se cachent les surprises.
| Colonne | Ce qu'il faut consigner |
|---|---|
| Client et contact | Qui valide les modifications, et comment il préfère être contacté |
| Domaine | Chaque domaine et sous-domaine qui pointe vers le site |
| Registraire et titulaire du compte | Où le domaine est enregistré et sur quel compte |
| Hébergeur DNS | Souvent différent du registraire ; notez qui le contrôle |
| Messagerie sur le domaine | Quel service de messagerie, pour que ses enregistrements survivent à la migration |
| Plateforme actuelle | WordPress, un autre créateur de sites, code fait main, etc. |
| Nombre de pages | D'après le plan du site ou une exploration, pas de mémoire |
| Formulaires et destination | Chaque formulaire, et la boîte ou l'outil qui reçoit les envois |
| Intégrations | Réservation, paiements, chat, analytique, gestionnaire de balises, pixels |
| Boutique ou espace membres | Produits, commandes, identifiants : ils demandent une planification supplémentaire |
| Valeur pour le référencement | Pages principales par clics d'après les données de recherche du client, si vous y avez accès |
| Contrat et date de renouvellement | Quand se termine l'engagement actuel du client avec vous, et le renouvellement de l'ancien hébergeur |
| Décision | Reconstruire, déplacer tel quel ou retirer |
Étape 2 : triez chaque site
Tous les sites ne méritent pas le même effort. Classez-les :
- Reconstruire : les sites vitrines d'environ 30 pages au plus avec des formulaires simples. C'est généralement l'essentiel du portefeuille d'une agence, et le gain le plus facile.
- Déplacer avec précaution : les sites avec une boutique, des comptes membres, des réservations ou un fort trafic de recherche. Traitez-les en dernier, un par un, une fois que votre équipe en a fait dix faciles.
- Laisser en place : les sites construits autour d'une extension ou d'un système sur mesure que la nouvelle plateforme ne peut pas remplacer. Les déplacer ne vaut pas le risque. Soyez honnête avec vous-même sur ceux qui en font partie.
- Retirer : les sites de clients qui ont cessé de payer ou d'entreprises qui ont fermé. Réglez-les en premier, avec le client, par écrit.
Étape 3 : réglez la propriété avant tout déplacement
Pour chaque domaine, vérifiez que vous ou le client pouvez vous connecter dès aujourd'hui au registraire et à l'hébergeur DNS. Si un domaine doit changer de registraire dans le cadre de la bascule, vérifiez le calendrier : selon la politique de transfert de l'ICANN, un registraire peut refuser un transfert dans les 60 jours suivant la création du domaine ou un précédent transfert, et il vous faudra le code AuthInfo (de transfert) du domaine auprès du registraire actuel. Un domaine n'a pas besoin de changer de registraire pour changer de plateforme de site. Modifier la destination de son DNS suffit, et c'est bien moins risqué.
C'est aussi le moment de convenir par écrit de qui possède le domaine et le site après la migration. Notre guide à qui appartient le site d'un client sur une plateforme en marque blanche aborde cette discussion.
Étape 4 : prévenez vos clients avant qu'ils ne s'en aperçoivent
Envoyez à chaque client une courte note au moins deux semaines avant son lot. Dites ce qui change pour lui (un nouvel identifiant, un éditeur plus agréable), ce qui ne change pas (son domaine, sa messagerie, son tarif, sauf s'il change), la date et qui appeler. Demandez-lui tout ce que lui seul peut fournir, comme un identifiant de registraire. Utilisez un modèle comme celui-ci :
| Partie | Exemple de formulation |
|---|---|
| Pourquoi | « Nous transférons les sites de tous nos clients vers une plateforme plus rapide pour pouvoir effectuer vos modifications plus vite. » |
| Ce qui ne change pas | « Votre adresse web, votre messagerie et votre tarif mensuel restent exactement les mêmes. » |
| Ce qui est nouveau | « Vous aurez un nouvel identifiant pour voir votre site et demander des modifications. » |
| Quand | « Nous basculerons votre site le [date]. Vous n'aurez rien à faire ce jour-là. » |
| Ce dont nous avons besoin | « Merci de confirmer d'ici le [date] que vous avez toujours accès à [registraire], ou laissez-nous vous aider à le récupérer. » |
Les clients sur le point de partir vous le diront souvent à ce moment-là. C'est utile : retirez leur site au lieu de le déplacer.
Étape 5 : menez un pilote sur cinq sites
Choisissez cinq sites simples dont les propriétaires sont bienveillants et le trafic modeste. Appliquez-leur toute la liste de contrôle, chronométrez chaque étape et notez chaque surprise. Ce sont ces notes qui rendent le deuxième lot plus rapide que le premier. N'attaquez pas le deuxième lot tant que les sites pilotes ne sont pas en ligne depuis deux semaines, avec des formulaires qui arrivent et un trafic stable.
Étape 6 : la liste de contrôle par site
- Explorez l'ancien site et exportez chaque URL, titre de page et méta-description.
- Reconstruisez sur la nouvelle plateforme. Gardez les titres de page et les titres principaux proches des anciens pour les pages bien positionnées ; ce n'est pas le moment de réécrire entièrement une page qui se classe.
- Faites correspondre les URL. Chaque ancienne URL reçoit une nouvelle destination, une pour une si possible. Les recommandations de Google pour les déménagements de site sont d'utiliser des redirections permanentes côté serveur (301 ou 308), d'envoyer chaque ancienne URL directement vers son adresse finale, et de conserver les redirections le plus longtemps possible, en général au moins un an.
- Reconstruisez les formulaires et envoyez depuis chacun un message de test vers la vraie boîte du client.
- Réinstallez les intégrations : analytique, widgets de réservation, pixels, chat.
- Réduisez le TTL DNS des enregistrements que vous allez modifier, la veille de la bascule, pour que le changement se propage vite et qu'un retour arrière soit rapide.
- Basculez le DNS pour les seuls enregistrements web. Laissez les enregistrements de messagerie exactement tels qu'ils étaient.
- Vérifiez le site sur le vrai domaine, le certificat HTTPS, dix des principales anciennes URL (elles doivent rediriger), chaque formulaire, et les e-mails envoyés vers et depuis le domaine.
- Soumettez le nouveau plan du site dans la Search Console du client, si vous la gérez.
- Surveillez pendant deux semaines : trafic, envois de formulaires, erreurs 404 et retours du client.
Étape 7 : prévoyez le retour arrière
Gardez l'ancien hébergeur actif et payé jusqu'à ce que le lot soit stable. Votre retour arrière consiste simplement à repointer le DNS, ce qui prend quelques minutes si vous avez réduit le TTL. Décidez à l'avance de ce qui le déclenche : des formulaires qui n'arrivent pas, une boutique qui ne prend plus de commandes, ou une nette baisse de trafic que vous ne parvenez pas à expliquer en quelques jours.
Un calendrier pour 80 sites
| Semaines | Travail |
|---|---|
| 1-2 | Inventaire, tri, régularisation de la propriété, notes aux clients du pilote |
| 3-4 | Pilote sur cinq sites, puis deux semaines de surveillance |
| 5-12 | Lots de 10-15 sites simples, un lot toutes les une à deux semaines |
| 13-16 | Boutiques, sites à espace membres et sites à fort trafic, un par un |
| 17+ | Résilier l'ancien hébergement une fois qu'il ne contient plus rien ; conserver les redirections |
Adaptez la taille des lots à votre équipe. Deux personnes peuvent généralement reconstruire et lancer plus de sites simples par semaine qu'elles ne peuvent en vérifier correctement : c'est la vérification qui donne le rythme.
Ce que la nouvelle plateforme doit simplifier
Un changement de plateforme ne vaut l'effort que si le travail quotidien devient ensuite plus simple. Quand vous en évaluez une, vérifiez qu'elle vous apporte ces éléments pour chaque client.
Un seul endroit pour tous les clients
Vous devez pouvoir voir chaque client, son forfait et son statut dans une seule liste, et ajouter le client suivant en une minute.
Une page de connexion à votre nom
Après la migration, vos clients se connectent sur votre marque, pas sur celle de la plateforme.
Leur propre domaine, connecté site par site
Une porte de sortie
La prochaine migration doit être plus facile que celle-ci. Dans We.Inc, le code de chaque site peut être téléchargé ou envoyé sur GitHub, et les pages publiées sont pré-rendues avec un plan du site généré et la prise en charge des redirections enregistrées, pour que les moteurs de recherche puissent les lire sans exécuter de scripts.
Si vous préparez une migration de ce type, réservez une démo et apportez votre tableau d'inventaire ; nous vous dirons franchement lesquels de vos sites conviennent et lesquels doivent rester où ils sont.
Sources
Dernière vérification le 2026-10-25.
- Google Search Central, Site moves with URL changes (redirections permanentes, à conserver au moins un an, nouveau plan du site).
- ICANN, Transfer Policy (restrictions de transfert de 60 jours, codes AuthInfo).
Questions fréquentes
Combien de sites clients une agence doit-elle migrer à la fois ?
Commencez par un pilote d'environ cinq sites simples, surveillez-les pendant deux semaines, puis migrez-en 10-15 à la fois. Migrez les boutiques, les sites à espace membres et les sites à fort trafic un par un, à la fin.
Migrer le site d'un client vers une nouvelle plateforme nuit-il à son référencement ?
Oui, si les anciennes URL cassent. Faites correspondre chaque ancienne URL à une nouvelle avec des redirections permanentes 301 ou 308, gardez des titres similaires pour les pages bien positionnées, conservez les redirections au moins un an comme le conseille Google, et soumettez le nouveau plan du site.
Le domaine doit-il changer de registraire quand le site change de plateforme ?
Non. Il suffit de modifier les enregistrements DNS qui font pointer le site. Ne touchez pas aux enregistrements de messagerie. Un transfert de registraire est une étape distincte, et les règles de l'ICANN peuvent le bloquer dans les 60 jours suivant l'enregistrement ou un précédent transfert.
Comment revenir en arrière après la migration d'un site ?
Gardez l'ancien hébergeur actif, réduisez le TTL DNS la veille de la bascule, et repointez les enregistrements web si les formulaires, les commandes ou le trafic défaillent.
Que dire aux clients avant de migrer leur site ?
Pourquoi vous migrez, ce qui ne change pas (domaine, messagerie, tarif), ce qui est nouveau, la date, et tout ce dont vous avez besoin de leur part, comme l'accès au registraire.
Commencer gratuitement · Sans carte bancaire
Voir aussi: Guides
- Rendre un site multilingue sans nuire au SEO
- Inventaire de contenu d'un site municipal
- Enregistrement MX
- NestJS vs Next.js
- Routes API Next.js
- Aide-mémoire Next.js App Router
- Authentification Next.js
- Variables d'environnement Next.js expliquées
Produit
Pour qui
- Pour les agences
- Pour les indépendants
- Pour les hébergeurs
- Pour les plateformes SaaS
- Pour les startups
- Services financiers
- Solutions pour la santé
Fonctionnalités
- Éditeur visuel
- SEO et analyses
- Image de marque personnalisée
- Tableau de bord client
- Facturation revendeur
Ressources
- Blog
- Centre d'aide
- Outils gratuits pour les entreprises
- Free UI Components
- Modèles
- Collections de modèles
- Exemples de sites
- Guides
- Comparatifs
- Alternatives
- Les meilleurs
- Avis
- Guides des tarifs
- Cas d'usage
- Glossaire et guides
- Intégrations
- Développeurs
- Benchmark
- Windows App