Changer de prestataire de site internet : la checklist de reprise

1. Faut-il déplacer votre site ou le refaire ?

Ce guide concerne un site vitrine professionnel, qui présente votre activité et reçoit des demandes. Une boutique, un espace client ou une application avec des données qui changent en permanence demandent un plan supplémentaire pour les commandes, les comptes et les données.

Avant de demander une refonte, nommez le problème : manque de suivi, contenus obsolètes, site difficile à modifier, formulaires défaillants ou besoin commercial mal couvert. La réponse peut être une reprise de maintenance, quelques améliorations ou un nouveau site.

Par exemple, Wix indique qu’un site construit avec sa technologie doit fonctionner sur ses serveurs. Quitter Wix peut donc nécessiter une reconstruction ; changer la personne qui travaille sur votre site Wix est une autre décision.³

Recommandation : gardez votre domaine et vos adresses de pages lorsque rien ne justifie de les changer. Si une refonte est nécessaire, demandez au repreneur de distinguer le travail de transition des améliorations prévues. Vous pourrez vérifier chacun séparément.

Vous pouvez commencer par l’inventaire de reprise, puis utiliser la checklist avant la bascule.

2. Vérifiez le contrat avant de fixer la date de départ

Rassemblez le bon de commande, le contrat, les conditions applicables à sa signature et les éventuels avenants. Relevez le préavis, la date limite de notification, la date de fin effective et les services qui s’arrêteront. Respectez le mode de notification prévu et demandez une confirmation écrite de la date retenue.

La fin de la prestation web ne dit pas forcément ce qui arrive au domaine, aux boîtes mail ou à leurs sauvegardes. Faites préciser ces points, service par service, ainsi que les coûts de remise des fichiers ou d’assistance au départ.

Pour les créations protégées par le droit d’auteur, vérifiez la cession ou l’autorisation qui permet au repreneur de les utiliser et de les modifier. L’article L131-3 encadre notamment l’identification des droits cédés et leur périmètre. Une facture et un accès administrateur ne constituent pas, à eux seuls, une description de ces droits.²

Demandez aussi les conditions d’utilisation des photos, polices, thèmes et extensions : lesquels restent utilisables, lesquels nécessitent une licence à votre nom ? Recevoir les fichiers ne suffit pas à prouver que le nouveau prestataire pourra tout exploiter.

3. Constituez votre inventaire de reprise

Voici le dossier à compléter avec les deux prestataires. Copiez le tableau dans votre document de travail et ajoutez à chaque ligne : responsable, date attendue, statut « à obtenir / reçu / vérifié » et emplacement de la preuve. Vous pouvez aussi imprimer le guide. Un élément absent reste « à obtenir », pas « sans objet » par défaut.

Un CMS est l’outil qui permet de gérer les contenus, comme WordPress. Si vous reprenez un site existant, faites confirmer ce dont le repreneur a besoin pour l’installer et le maintenir. Un export de textes peut convenir à une reconstruction ; il ne remplace pas une sauvegarde complète d’un site à déplacer.

Accordez les accès via des comptes individuels ou un partage sécurisé. Évitez les mots de passe dans ce tableau. Pour les comptes essentiels, vérifiez aussi que l’entreprise maîtrise les moyens de récupération et la double authentification.

4. Conservez le domaine et protégez les emails

Votre bureau d’enregistrement gère l’enregistrement du domaine ; votre hébergeur web sert le site. Votre messagerie peut être chez un troisième fournisseur. Même si une facture regroupe ces services, ils n’ont pas nécessairement à déménager ensemble.

Le transfert du domaine est-il nécessaire ?

Pour un domaine en .fr, vérifiez le titulaire dans le Whois de l’Afnic et dans le compte de gestion. Des coordonnées peuvent être masquées : demandez alors une confirmation au bureau d’enregistrement. Si vous changez de bureau, le titulaire obtient le code auth-info, à transmettre au nouveau bureau. Vérifiez ses conditions et ses frais ; les règles des autres extensions peuvent différer.¹

Si vous gardez un compte de domaine que vous contrôlez, il peut suffire de modifier les réglages qui dirigent vers le site. Demandez néanmoins ce qui subsistera après la résiliation de l’ancien contrat : enregistrement, gestion DNS et messagerie.

Les DNS associent votre domaine à ses services. Les enregistrements du site, ceux de réception des emails (MX) et les réglages de sécurité ou de validation sont distincts. Un changement de serveurs DNS peut donc toucher davantage que le site.⁴

Avant toute modification, faites conserver une copie des réglages, puis vérifier ceux qui doivent être repris. Le prestataire doit aussi anticiper leur durée de cache, appelée TTL : revenir aux anciens réglages n’est pas nécessairement instantané.⁴

Les boîtes mail restent-elles chez le même fournisseur ?

Si la messagerie reste en place, faites maintenir son abonnement, ses accès et les réglages DNS utiles. Google Workspace, par exemple, reçoit les messages grâce aux MX du domaine ; un nouveau site ne nécessite pas à lui seul de remplacer ces MX.⁵

Si vous changez de messagerie, demandez un chantier identifié : création des boîtes et alias, copie des messages, traitement des contacts et calendriers, réglage des appareils et synchronisation finale. Faites préciser ce qui sera copié et ce qui ne le sera pas. Le changement des MX dirige les messages entrants ; ce n’est pas une copie de votre historique.⁵

Prévoyez un essai d’envoi et de réception avec une adresse extérieure, puis un contrôle des messages reçus pendant la transition. Vérifiez également l’envoi depuis les formulaires. Maintenez l’accès à l’ancienne messagerie jusqu’à validation du transfert et de la dernière récupération de données.

5. Préparez les pages à conserver et les redirections

Le référencement naturel, ou SEO, correspond à la visibilité dans les résultats de recherche. Même si votre domaine reste identique, supprimer une page utile ou modifier son adresse peut affecter cette visibilité. Google signale que les classements peuvent fluctuer après une migration importante : personne ne peut garantir de conserver chaque position.⁶

Demandez la liste des adresses actuelles, y compris les PDF utiles et les anciennes redirections. Pour choisir les priorités, croisez les exports Search Console, les données d’audience disponibles, les liens entrants et votre connaissance des demandes commerciales. Sans historique fiable, notez cette limite et vérifiez les pages de services et de contact plutôt que d’inventer un classement.

Un exemple de plan à adapter

Exemple fictif, pour une entreprise qui garde le même domaine et refond son site. Les chemins ci-dessous représentent la partie de l’adresse après le domaine ; ce n’est pas le compte rendu d’une migration client.

Le code 200 indique une réponse réussie. Les 301 et 308 signalent un déplacement permanent ; 404 ou 410, un contenu absent ou supprimé. Google recommande les redirections permanentes côté serveur pour les déplacements définitifs.⁷⁶

Pour votre propre plan, ajoutez une ligne par ancienne adresse, le motif de la décision, le responsable et le résultat du test. Demandez une destination finale pertinente, sans chaîne inutile. Google déconseille de renvoyer toutes les pages vers l’accueil et recommande de maintenir les redirections aussi longtemps que possible, généralement au moins un an.⁶

Si les adresses restent identiques, il n’y a pas de redirection à créer du seul fait du changement de prestataire. Les pages qui doivent rester accessibles doivent cependant être présentes sur le nouveau site.

Faut-il déclarer un changement d’adresse à Google ?

L’outil Changement d’adresse de Search Console concerne un passage vers un autre domaine ou sous-domaine. Il ne sert pas à un simple changement d’hébergeur, à déplacer des pages dans le même domaine, à passer en HTTPS ou à basculer entre une adresse avec et sans www. Pour un changement de domaine, le responsable doit vérifier les propriétés concernées et utiliser l’outil après les redirections.⁸

6. Utilisez un calendrier fondé sur les dépendances

J est le jour de la bascule publique. Le calendrier ci-dessous est une proposition d’organisation pour un petit site vitrine, pas un délai standard ni un engagement de prestataire. Un préavis long, un accès manquant ou une messagerie à migrer peuvent imposer de commencer bien plus tôt. Le feu vert dépend des vérifications, pas du nombre de jours écoulés.

Fixez une plage de faible activité pendant laquelle les personnes capables d’intervenir sont disponibles. Un week-end sans assistance n’est pas automatiquement un bon choix.

Si des demandes ou des contenus peuvent encore être enregistrés sur l’ancien site, convenez d’une courte pause des modifications ou d’une synchronisation finale. Désignez la personne qui récupère les demandes arrivées sur chacun des systèmes pendant la transition.

Préparez le retour arrière : qui le décide, pour quels incidents, vers quelle version et comment préserver les données reçues entre-temps ? Les caches DNS rendent son effet progressif ; une sauvegarde seule n’est pas un plan d’intervention.⁴

7. La checklist avant la bascule

Cochez une case quand vous disposez de la preuve. Les cases servent à votre lecture ; elles ne remplacent pas le dossier de travail partagé. Les saisies ne sont ni envoyées ni conservées par cette checklist. Imprimez-la ou reportez l’état dans votre document pour le garder.

• Les dates de notification et de fin du contrat sont confirmées ; je sais quels services s’arrêtent à chacune.
• Le domaine est sous contrôle, son renouvellement prévu et les réglages DNS actuels sauvegardés.
• Les droits, licences, fichiers et dépendances nécessaires ont été acceptés par le repreneur.
• La sauvegarde a été restaurée ou les contenus repris ont été vérifiés sur le nouveau site.
• La décision de conserver ou migrer la messagerie est écrite ; boîtes, alias et données concernés sont identifiés.
• Les pages utiles, les téléchargements et les anciennes adresses ont été contrôlés ; les redirections prévues ont été testées.
• Un test de contact ou de rendez-vous arrive réellement au bon destinataire, et dans l’outil commercial s’il y en a un.
• Le site se lit et s’utilise sur téléphone ; les liens et les fonctions indispensables marchent.
• Le responsable technique a vérifié HTTPS, accès des moteurs, adresses canoniques, sitemap et retrait des blocages de recette sur les pages publiques.
• La mesure prévue fonctionne ; l’accès aux comptes et l’historique utile sont conservés.
• Le responsable de la bascule, les intervenants et les conditions du retour arrière sont confirmés.

Une adresse canonique indique aux moteurs la version de référence d’une page ; le sitemap liste les adresses à leur faire découvrir. Faites vérifier qu’ils désignent les adresses finales.⁶

Pendant la préparation, protégez la copie de travail contre l’accès non autorisé et son indexation. Le réglage noindex demande aux moteurs de ne pas indexer une page ; il ne ferme pas son accès. Un blocage dans robots.txt ne permet pas à lui seul de garantir qu’une adresse restera absente de Google.¹⁰

Un accès inconnu, une messagerie non préparée ou un formulaire qui ne transmet pas les demandes sont des raisons de reporter la bascule. Décidez séparément des petites améliorations qui peuvent attendre.

8. Quand pouvez-vous arrêter les anciens services ?

Après la bascule, refaites les essais depuis l’adresse publique : consultation sur téléphone et ordinateur, anciennes URL, téléchargements, formulaire et réception réelle du message. Pour les emails, contrôlez envoi, réception, historique et appareils concernés. Demandez que le compte rendu indique la date, le test, le résultat et le responsable.

Pour un changement d’hébergement à URL identiques, Google recommande de surveiller les anciens et nouveaux serveurs et d’attendre que l’ancien ne reçoive plus de trafic avant de le désactiver.⁹ Faites vérifier ces journaux par le prestataire ; une page qui fonctionne dans votre navigateur ne suffit pas à constater la fin de la transition.

Distinguez les services à fermer de ceux à garder. Si les redirections sont servies par le nouvel hébergement sur le même domaine, l’ancien hébergement peut devenir inutile. Si le domaine change, conservez l’ancien domaine et un service capable de répondre aux anciennes adresses ; le site complet n’a pas nécessairement à rester hébergé. Gardez également les sauvegardes nécessaires et toute messagerie encore utilisée.⁶

Pendant les premières semaines, surveillez les pages prioritaires, les erreurs inattendues et les demandes reçues. Un formulaire qui n’envoie plus ou une page essentielle inaccessible se corrige immédiatement. Pour le trafic, comparez des périodes cohérentes en tenant compte de la saison et des changements de mesure : une variation ne prouve pas à elle seule une perte de référencement. Le plan J+30 sert à lire les premiers signaux, pas à déclarer la visibilité définitivement stabilisée.

À la fin, retirez les accès devenus inutiles et vérifiez les moyens de récupération des comptes. Archivez le dossier de reprise et les décisions de fermeture.

9. Faites préciser le périmètre et le coût de la reprise

Demandez une proposition qui distingue la reprise, la refonte éventuelle et le suivi après lancement. Pour chaque poste, faites indiquer « inclus », le montant ou « à chiffrer », ainsi que le responsable :

• diagnostic, récupération et restauration des fichiers ;
• réutilisation ou reconstruction des contenus et fonctions ;
• plan de redirections, tests et corrections après bascule ;
• transfert de gestion du domaine, renouvellement et maintien d’un ancien domaine si nécessaire ;
• migration des boîtes mail, historique et réglage des appareils ;
• licences à reprendre et période de chevauchement des anciens et nouveaux services ;
• frais ou sommes restant dus au contrat sortant.

Il n’existe pas ici de forfait de migration universel : le périmètre dépend de ce que vous conservez et de ce que le repreneur peut réellement récupérer. Pour comparer le financement et les dépenses dans la durée, utilisez le guide abonnement ou achat et son simulateur.

Si le site fonctionne et que seule sa maintenance vous déçoit, un prestataire qui reprend sa technologie peut être le choix le plus proportionné. Une nouvelle création n’est utile que si elle répond mieux au besoin et justifie le travail de transition.