Beaucoup d’entreprises restent avec un prestataire qui ne leur convient plus par peur de tout casser en partant. C’est un frein réel, et il est en grande partie infondé : changer d’agence web ou d’hébergeur est un exercice balisé, dont le risque se concentre sur trois points seulement. Mieux : ces trois points se traitent avant même d’avoir prévenu qui que ce soit. Voici la méthode, dans l’ordre où nous l’appliquons quand nous reprenons un site existant.
Avant tout : de quoi êtes-vous réellement propriétaire
Avant de parler de migration, il faut savoir ce qui vous appartient. Cinq actifs, à vérifier un par un :
- Le nom de domaine et son titulaire déclaré. C’est le point le plus important de tout cet article. Un domaine déposé au nom du prestataire est la situation la plus bloquante qui soit : sans lui, vous ne pouvez ni transférer, ni modifier la zone, ni même récupérer votre messagerie. Le titulaire se vérifie auprès de votre bureau d’enregistrement ou via les annuaires publics (Afnic, gérer son nom de domaine).
- L’hébergement et le titulaire du compte. Un hébergement facturé au prestataire, sur son propre compte, signifie que vous êtes locataire d’un espace dont vous ne pouvez pas ouvrir la porte.
- Le code et les licences des extensions. Une extension premium achetée par l’agence sur sa licence développeur cesse de recevoir des mises à jour le jour de votre départ. Faites la liste, elle est souvent longue, et exigez un dépôt de code dont vous êtes propriétaire.
- Les contenus et les droits sur les photographies. Une banque d’images sous licence de l’agence n’est pas transférable avec le site.
- Les comptes tiers : mesure d’audience, console de recherche, messagerie professionnelle, module de paiement. Vous devez y figurer comme propriétaire, pas comme utilisateur invité.
Un mot sur les délais, souvent ignoré : sur les extensions génériques comme le .com, un transfert récent ou un changement de titulaire verrouille le domaine pendant soixante jours. Vérifiez donc la propriété avant d’annoncer votre départ, pas après.
Récupérer ses accès sans conflit
La demande vague, « merci de nous transférer le site », ne produit jamais rien d’exploitable. Demandez par écrit une liste précise, ce qui rend le refus visible et la relance facile :
- Un compte administrateur du site à votre nom, et la confirmation qu’il n’existe pas d’autres comptes actifs.
- L’accès au panneau d’hébergement, aux comptes SFTP et à la base de données.
- L’accès au compte chez le bureau d’enregistrement du domaine, ou le code de transfert. Ce code doit vous être remis, sous quelques jours au maximum, dès lors que vous êtes titulaire.
- Le dépôt de code s’il existe, et la documentation de déploiement.
- Les droits de propriétaire sur les outils de mesure et la console de recherche.
- Un export complet et daté : fichiers, base de données, médias.
Un prestataire correct facilite le départ, parce qu’il sait qu’une séparation propre laisse une bonne réputation. À l’inverse, la difficulté à obtenir des accès est en soi une réponse sur la qualité de la relation. Restez factuel, écrit et daté : c’est ce qui donne du poids à une mise en demeure si l’on doit en arriver là. Nous ne donnons pas de conseil juridique, mais nous constatons qu’une demande écrite précise règle la situation dans la grande majorité des cas.
Les trois risques réels d’une migration
Tout le reste est de la logistique. Ces trois-là méritent votre attention.
Perdre des adresses de pages
Le risque numéro un. Toute adresse qui change sans redirection permanente emporte avec elle le référencement accumulé, et transforme chaque lien externe pointant vers vous en page introuvable. La parade est un inventaire complet avant la bascule : exploration du site existant, plan de site, adresses connues de la console de recherche, journaux du serveur pour retrouver les pages oubliées. On obtient une liste, puis un tableau de correspondance ancienne adresse vers nouvelle adresse, ligne par ligne.
Perdre des données récentes
Entre la copie et la bascule, la vie continue : commandes passées, messages envoyés, comptes créés. Ces données existent sur l’ancien environnement et pas sur le nouveau. La parade est un gel d’écriture court, souvent une à deux heures en pleine nuit, avec une copie différentielle juste avant le basculement, puis une reprise manuelle du reliquat.
Couper la messagerie
Le piège classique. Quand on change de zone DNS, on recrée les enregistrements du site et on oublie ceux du courrier. Relevez la zone complète avant toute modification, recréez chaque enregistrement à l’identique, et ne supprimez rien tant que le nouvel environnement n’est pas validé. Une entreprise supporte deux heures sans site ; elle ne supporte pas deux heures sans courriel.
La check-list de bascule
Dans l’ordre, avec la conséquence si l’on saute une étape.
- Inventaire des adresses existantes. Sauté : des pages disparaissent sans que personne ne s’en aperçoive avant des mois.
- Copie complète sur le nouvel environnement, fichiers et base, plus une sauvegarde complète avant toute bascule, stockée hors serveur. Sauté : aucun retour arrière possible.
- Tests fonctionnels sur une adresse privée non indexée, protégée par mot de passe. Sauté : la copie de test se retrouve indexée et se met à concurrencer le vrai site.
- Plan de redirections écrit et testé avant la bascule, en redirections permanentes. Sauté : c’est la principale cause de chute de trafic après migration.
- Réduction de la durée de vie des enregistrements DNS vingt-quatre à quarante-huit heures avant. Sauté : la propagation traîne, et une partie des visiteurs continue d’être envoyée vers l’ancien serveur.
- Fenêtre de bascule en creux d’activité. Sauté : vous découvrez les défauts en même temps que vos clients.
- Conservation de l’ancien environnement en lecture pendant plusieurs semaines. Sauté : la donnée manquante que vous découvrez trois jours plus tard est définitivement perdue.
- Vérification des certificats sur le nouvel hébergement, avant et après la bascule. Sauté : un avertissement de sécurité s’affiche à vos visiteurs.
- Soumission du nouveau plan de site et, en cas de changement de domaine, déclaration du déménagement dans la console de recherche (documentation Google sur le déplacement d’un site).
- Surveillance des erreurs et du trafic pendant un mois. Sauté : les problèmes se voient au trimestre suivant, quand il est trop tard pour les relier à la migration.
Un point de calendrier : Google recommande de conserver les redirections au moins un an. Ne planifiez pas la fermeture de l’ancien domaine trois mois après la bascule.
Les trente jours qui suivent
La migration ne s’arrête pas au moment où le site s’affiche. Cinq contrôles, à tenir pendant un mois : la liste des pages introuvables dans la console de recherche, qui doit tendre vers zéro ; le trafic comparé par groupe de pages et non globalement, car une baisse moyenne de 5 % peut cacher un effondrement sur une rubrique ; l’indexation des pages importantes ; le bon fonctionnement des formulaires et des paiements, testés pour de vrai avec une commande réelle ; et les retours des clients, qui repèrent toujours ce que les outils ne voient pas.
Une baisse limitée pendant deux à trois semaines est normale, et Google le documente : la visibilité fluctue le temps que les nouvelles adresses soient traitées. Une baisse qui persiste au-delà d’un mois n’est pas normale et signale presque toujours un problème de redirection ou d’indexation, pas une fatalité.
Reprendre un site mal construit : jusqu’où aller
Le cas est très fréquent et rarement traité honnêtement : le nouveau prestataire ouvre le capot et découvre un site fragile. Trois options seulement, et le choix se fait sur des critères observables.
| Ce que vous constatez | Décision raisonnable |
|---|---|
| Thème standard, extensions à jour, structure claire | Reprendre en l’état et documenter |
| Extensions redondantes, quelques ajustements dans le thème, PHP en retard | Assainir progressivement, par lots |
| Thème modifié directement sans thème enfant, extensions abandonnées, aucune documentation | Reconstruire en conservant contenus et adresses |
Le critère décisif est le thème modifié directement : chaque mise à jour écrase le travail, donc plus personne ne met à jour, donc le site vieillit jusqu’à devenir vulnérable. Quand ce point est réuni avec une dette d’extensions et une version de PHP dépassée, l’assainissement coûte plus cher que la reconstruction. Les signaux à surveiller sont détaillés dans les signes qu’une refonte s’impose.
La procédure de migration sans coupure que nous appliquons est détaillée sur la page hébergement de site internet à Pau.
Notre position : les six questions à poser au prestataire suivant
Nous ne pensons pas qu’un client doive faire confiance : nous pensons qu’il doit pouvoir vérifier. Six questions, à poser avant de signer, dont les réponses tiennent en une page :
- Qui sera titulaire du nom de domaine et du compte d’hébergement ? La seule bonne réponse est : vous.
- Où sera hébergé le code, et y aurai-je accès en lecture à tout moment ?
- Quelle est la politique de sauvegarde, à quelle fréquence, où sont-elles stockées, et quand une restauration a-t-elle été testée pour la dernière fois ?
- Comment les demandes sont-elles suivies, et sous quel délai de prise en charge ?
- Que se passe-t-il si nous partons ? Un prestataire qui n’a pas de réponse claire à cette question en a une, mais elle ne vous plaira pas.
- Que couvre exactement le suivi mensuel, et qu’est-ce qui est facturé en plus ?
C’est la logique de nos formules avec hébergement et suivi inclus, à partir de 59 €/mois auxquels s’ajoutent des frais d’inscription (TVA non applicable, art. 293 B du CGI) : domaine et hébergement au nom du client, accès complets remis dès le premier jour, et aucun verrou technique au départ. Avant tout engagement, nous commençons par un audit de reprise et migration accompagnée qui dresse l’inventaire de ce que vous possédez réellement. Pour comparer plusieurs prestataires, notre guide sur comment choisir son agence web complète cette liste.
Conclusion
On ne quitte pas un prestataire : on récupère son site. Une fois la question de la propriété réglée, le reste est une opération technique balisée, dont chaque étape a une conséquence connue si on la saute. Commencez par le seul point qui puisse vraiment vous bloquer : vérifiez aujourd’hui qui est le titulaire déclaré de votre nom de domaine.
Faire auditer la reprise de mon site Parler de mon site actuel
