Un hébergement se choisit rarement deux fois dans la vie d'un site. On finit pourtant par en changer : le serveur sature aux heures de pointe, le prestataire ne répond plus, la facture a doublé au renouvellement, ou un audit a montré que le temps de réponse serveur pénalise l'ensemble des pages. La décision se prend alors sur des critères vérifiables, pas sur une page commerciale et un tarif d'appel.
J'accompagne des TPE et des PME sur ces bascules depuis 2012, et le schéma se répète : la partie purement technique se passe généralement bien, ce sont les oublis périphériques qui coûtent des jours de visibilité. Un enregistrement DNS resté en arrière, une boîte e-mail non migrée, un certificat qui n'a pas suivi, un export de base incomplet. Voici ce que je vérifie avant de signer chez un nouvel hébergeur, puis la méthode de bascule que j'applique pour que le référencement ne bouge pas.
Ce que recouvre réellement une migration
Migrer, ce n'est pas « copier un dossier ». Le périmètre réel tient en six blocs, et chacun doit avoir un responsable identifié avant le jour J :
- les fichiers du site (code, thème, extensions, médias) ;
- la ou les bases de données, avec leurs jeux de caractères et leurs collations ;
- les comptes e-mail, leurs alias et leur historique — le poste le plus souvent oublié, et celui qui génère le plus d'appels le lendemain ;
- les tâches planifiées (cron), les traitements automatiques, les connexions à des services tiers ;
- les certificats TLS et la configuration du serveur web ;
- la zone DNS complète, y compris les enregistrements MX, SPF, DKIM et DMARC.
Si un seul de ces blocs n'est pas cartographié, la migration se fera quand même — mais vous découvrirez le manque en production, au pire moment.
Les critères techniques à vérifier avant de signer
Les ressources réelles, pas les ressources annoncées
Sur un mutualisé, « illimité » ne désigne jamais la puissance de calcul. Demandez par écrit les valeurs qui vous concernent : mémoire allouée à PHP, durée maximale d'exécution d'un script, nombre de processus PHP simultanés, quotas d'entrées-sorties disque, nombre d'entrées dans la base de données. Un site vitrine s'en moque ; un catalogue de plusieurs milliers de références, non. Si le support ne sait pas répondre, considérez que la réponse est « peu ».
La version de PHP et le rythme de mise à jour
C'est l'indicateur le plus simple de la fraîcheur d'une infrastructure. D'après le calendrier officiel des versions supportées de PHP (consulté le 11 septembre 2026), PHP 8.2 n'est plus qu'en support de sécurité jusqu'au 31 décembre 2026, PHP 8.3 jusqu'au 31 décembre 2027, PHP 8.4 jusqu'au 31 décembre 2028 et PHP 8.5 jusqu'au 31 décembre 2029. Les branches antérieures, PHP 8.1 comprise, ne figurent plus dans la liste : elles ne reçoivent plus aucun correctif. Un hébergeur qui ne propose pas encore les deux dernières branches en production, ou qui facture le changement de version, a un train de retard qu'il ne rattrapera pas pendant votre contrat.
HTTP/3, TLS et gestion des certificats
HTTP/3 n'est plus une curiosité : W3Techs le relevait sur 40,7 % des sites de son panel en septembre 2026 (relevé W3Techs, périmètre : sites recensés par l'éditeur, mesure quotidienne). Le gain est surtout sensible sur les connexions mobiles instables, là où la reprise après perte de paquets coûte cher. Demandez si le protocole est actif par défaut ou sur demande.
Sur les certificats, la contrainte a changé de nature. Le CA/Browser Forum a adopté un calendrier de réduction de la durée de vie maximale des certificats TLS publics : 200 jours depuis le 15 mars 2026, 100 jours à partir du 15 mars 2027, 47 jours à partir du 15 mars 2029 (ballot SC-081v3 du CA/Browser Forum, détail du calendrier confirmé par DigiCert). Autrement dit, le renouvellement manuel est mort. Exigez un renouvellement automatisé, inclus, et vérifiez qu'il fonctionne aussi sur les sous-domaines et les alias.
Sauvegardes, restauration et plan de reprise
La bonne question n'est pas « faites-vous des sauvegardes ? » mais « en combien de temps restaurez-vous, qui déclenche l'opération, et l'ai-je déjà testé ? ». Trois paramètres à faire écrire noir sur blanc : la fréquence, la rétention en jours, et l'emplacement des copies — une sauvegarde stockée sur le même serveur que le site ne protège de rien. Vérifiez aussi que vous pouvez restaurer vous-même, depuis l'espace client, sans ouvrir un ticket. Et gardez, indépendamment de l'hébergeur, une sauvegarde complète sous votre propre contrôle avant la bascule.
Les critères juridiques, souvent négligés
Un contrat d'hébergement est un contrat de sous-traitance au sens du RGPD dès que le serveur traite des données personnelles — et un simple formulaire de contact suffit. La CNIL rappelle que le sous-traitant est l'organisme qui traite des données pour le compte d'un autre, et que ses obligations (sécurité, traçabilité, notification des violations, assistance au responsable de traitement) doivent figurer au contrat, conformément à l'article 28 du règlement.
| Point à vérifier | Question à poser au fournisseur | Risque si on l'ignore |
|---|---|---|
| Localisation des données | Dans quels pays sont hébergées les données, y compris les sauvegardes et les journaux ? | Transfert hors UE non encadré, à documenter dans votre registre |
| Chaîne de sous-traitance | Quels sous-traitants ultérieurs interviennent, et comment suis-je informé d'un changement ? | Contrat article 28 incomplet, responsabilité non couverte |
| Réversibilité | Sous quel format et dans quel délai récupère-t-on fichiers, bases et configurations à la résiliation ? | Sortie impossible ou facturée au prix fort |
| Nom de domaine | Qui est le titulaire déclaré au registre, et qui détient le code de transfert ? | Perte de contrôle du domaine en cas de litige |
La réversibilité mérite un mot de plus. Le règlement européen sur les données (Data Act, règlement (UE) 2023/2854) est applicable depuis le 12 septembre 2025 et encadre précisément la faculté, pour un client, de changer effectivement de fournisseur de services de traitement de données. Le texte joue en votre faveur, mais il ne remplace pas une clause de sortie claire dans votre contrat : faites préciser les formats d'export et les délais.
Sur le nom de domaine, la règle est simple et sans exception : le titulaire déclaré doit être votre entreprise, avec une adresse e-mail de contact qui vous appartient. Si votre domaine est enregistré au nom d'une agence ou d'un ancien prestataire, réglez ce point avant la migration, pas pendant.
Migrer sans perdre son référencement : la méthode
Un changement d'hébergeur sans changement d'URL est, pour Google, le scénario le plus favorable. Encore faut-il en suivre la séquence.
J-7 : abaisser le TTL des enregistrements DNS
Google recommande explicitement de réduire la valeur TTL des enregistrements DNS au moins une semaine avant la bascule, pour que les nouveaux paramètres se propagent plus vite chez les fournisseurs d'accès (documentation Google Search Central sur le déménagement de site sans changement d'URL). Passez de 86 400 à 300 secondes, et remontez le TTL une fois la bascule stabilisée. C'est ce qui transforme une propagation de 48 heures en propagation de quelques minutes.
J-5 : recette complète sur le nouveau serveur
Copiez le site sur la nouvelle infrastructure et testez-le derrière un nom d'hôte temporaire, protégé par une balise noindex ou une authentification, pour éviter toute indexation parasite. Vérifiez le rendu, les formulaires, les paiements, les e-mails transactionnels, les tâches planifiées. Vérifiez surtout que le pare-feu du nouvel hébergeur ne bloque pas Googlebot : c'est une cause classique de chute post-migration. Profitez-en pour relever l'état des lieux de départ — positions, pages indexées, temps de réponse — c'est la base de comparaison qui rendra le diagnostic possible ensuite. Un audit SEO réalisé avant la bascule tient très bien ce rôle.
J-1 : gel des contenus
Plus aucune publication, aucune commande de test, aucune modification de fiche produit entre l'export final et la bascule. Tout ce qui est écrit sur l'ancien serveur après l'export sera perdu. Prévenez l'équipe éditoriale et, pour un site marchand, choisissez un créneau de faible activité.
Jour J : bascule, redirections, vérifications
Retirez les blocages temporaires (robots.txt, noindex) puis basculez les enregistrements DNS. Laissez l'ancien serveur en ligne et opérationnel plusieurs jours : pendant la propagation, une partie des visiteurs et des robots continue d'y arriver, et un ancien serveur éteint trop tôt produit des erreurs qui, elles, se voient dans l'index. Si la migration s'accompagne d'un changement d'URL — nouvelle structure, passage en HTTPS, fusion de domaines — chaque ancienne adresse doit recevoir une redirection 301 vers son équivalent exact, et les redirections en chaîne doivent être aplaties. C'est le cas de figure d'une refonte WordPress, à traiter comme un projet distinct de la migration d'hébergement.
J+1 à J+30 : surveillance
Surveillez les journaux du serveur et l'état d'indexation dans la Search Console. Google précise qu'une baisse temporaire du rythme d'exploration par Googlebot juste après la bascule est normale : ce n'est pas un signal d'alerte en soi, il devient anormal s'il persiste au-delà de quelques semaines. Contrôlez ensuite les codes de réponse, les temps de réponse serveur et le trafic organique. Un tableau de bord dans Data Studio (ex-Looker Studio), alimenté par la Search Console et votre outil de mesure, suffit à voir en un coup d'œil si la courbe reprend sa pente ; c'est le genre de suivi que je mets en place dans une mission de pilotage webmarketing.
Une semaine après, ce que je repasse en revue
Les e-mails partent-ils toujours, et n'atterrissent-ils pas en indésirables faute d'enregistrements SPF et DKIM mis à jour ? Le certificat couvre-t-il bien toutes les variantes du domaine, avec renouvellement automatique confirmé ? Les tâches planifiées s'exécutent-elles à l'heure prévue ? Les sauvegardes du nouvel hébergeur tournent-elles réellement, et avez-vous testé une restauration ? L'ancien contrat est-il résilié, après récupération de la dernière sauvegarde ? Tant que ces cinq réponses ne sont pas « oui », la migration n'est pas terminée.
Questions fréquentes
Changer d'hébergeur fait-il perdre des positions dans Google ?
Non, pas en soi : tant que les URL restent identiques et que les pages répondent normalement, Google traite l'opération comme un simple déménagement d'infrastructure. Les pertes observées viennent presque toujours d'erreurs périphériques : pages en erreur pendant la propagation, robots bloqués par le pare-feu du nouveau serveur, balise noindex de recette oubliée en production. Une baisse temporaire du rythme d'exploration juste après la bascule est en revanche normale.
Combien de temps dure la propagation DNS ?
Elle dépend du TTL configuré sur vos enregistrements DNS, c'est-à-dire de la durée pendant laquelle les serveurs intermédiaires conservent l'ancienne réponse en cache. Avec un TTL laissé à 24 heures, comptez jusqu'à deux jours ; en l'abaissant à cinq minutes une semaine avant la bascule, la propagation se compte en minutes. On remonte le TTL à sa valeur habituelle une fois la migration stabilisée.
Faut-il couper l'ancien hébergement tout de suite ?
Non. Gardez l'ancien serveur en ligne et fonctionnel pendant plusieurs jours après la bascule : tant que la propagation n'est pas terminée, une partie des visiteurs et des robots continue d'y arriver. On l'arrête seulement lorsque les journaux montrent que le trafic vers l'ancienne infrastructure est retombé à zéro, et après avoir récupéré une sauvegarde complète.
Mes données doivent-elles obligatoirement être hébergées en France ?
Le RGPD n'impose pas un hébergement en France ni même dans l'Union européenne, mais il encadre strictement les transferts hors UE, qui doivent reposer sur un mécanisme juridique valide et être documentés. Un hébergement dans l'Union simplifie donc nettement votre conformité et votre registre des traitements. Pensez à vérifier la localisation des sauvegardes et des journaux, pas seulement celle du serveur principal.
Que doit contenir le contrat avec un hébergeur au regard du RGPD ?
Dès qu'un serveur traite des données personnelles, l'hébergeur est sous-traitant au sens de l'article 28 du RGPD, et un simple formulaire de contact suffit à déclencher ce statut. Le contrat doit décrire les mesures de sécurité, la traçabilité des traitements, l'information en cas de recours à d'autres sous-traitants, la procédure de notification des violations de données et le sort des données à la fin du contrat.
Qui doit être propriétaire du nom de domaine ?
Le titulaire déclaré au registre doit être votre entreprise, avec une adresse e-mail de contact qui vous appartient et que vous consultez. Si le domaine est enregistré au nom d'une agence, d'un ancien salarié ou d'un prestataire, vous dépendez de lui pour tout transfert et vous risquez de perdre le contrôle du site en cas de litige. Ce point se régularise avant d'engager une migration, pas pendant.
Quelle version de PHP faut-il exiger chez un nouvel hébergeur ?
Visez une branche encore en support actif, et fuyez toute offre qui ne dépasse pas PHP 8.1, désormais sans aucun correctif de sécurité. Vérifiez aussi que le changement de version se fait en autonomie depuis l'espace client, sans surcoût : c'est un bon indicateur de la fraîcheur de l'infrastructure. Testez votre site sur la nouvelle version avant la bascule, certaines extensions anciennes ne suivent pas.