Une migration de site internet est plus simple à piloter quand chaque vérification critique a un responsable, une condition d’acceptation et un résultat noté. Choisir la plateforme laisse encore des décisions ouvertes : les contenus, les demandes entrantes, l’accès aux comptes, et qui réagit si quelque chose ne va pas après le lancement.

Cet article est un modèle de planification de projet, pas le compte rendu d’une migration client en particulier. Les livrables, dates et accès réels figurent dans la proposition de projet.

1. Partir de ce qui doit continuer à fonctionner

« Il nous faut un nouveau site » n’est pas un brief complet. Listez les processus qui en dépendent : demandes de contact, rendez-vous, achats, demandes de support et notifications internes. Donnez à chacun un vrai test d’acceptation. Pour une entreprise de services, une demande test doit arriver chez la bonne personne avec les informations nécessaires.

Indiquez au prestataire les services qui comptent commercialement, les campagnes qui pointent vers des pages existantes et les moments où une interruption coûterait particulièrement cher. Le trafic n’est qu’un critère de priorité parmi d’autres : une page rarement visitée peut rester importante pour un partenaire ou un client existant.

Notez qui peut valider les changements. Des consignes contradictoires venant de plusieurs interlocuteurs sont un risque, même quand le travail technique est simple.

2. Nommer les responsables

Le décideur côté client valide les contenus, les offres et les processus métier. Il fournit les accès nécessaires et désigne qui reçoit les demandes de test. Il décide aussi quels problèmes ouverts peuvent attendre et lesquels bloquent le lancement.

Le prestataire web réalise le travail convenu, effectue les vérifications techniques et tient un registre des anomalies et des corrections. Le travail qui dépend d’un autre développeur ou d’un fournisseur de plateforme a besoin d’un coordinateur nommé.

Le responsable SEO et mesure vérifie les URL importantes et les événements convenus, enregistre une situation de référence et suit la transition. Dans une petite équipe, cela peut être la même personne que le développeur, mais la responsabilité doit être explicite.

Le responsable du support traite les problèmes après le lancement. Convenez d’un canal de contact, d’une disponibilité et de niveaux d’urgence avant la passation. « Prévenez-nous s’il y a un problème » laisse trop de questions ouvertes quand un formulaire n’envoie plus les demandes.

3. Construire une checklist de recette

Les recommandations de Google sur les migrations couvrent le test du nouveau site, la correspondance entre anciennes et nouvelles URL, la mise en place des redirections et le suivi du trafic. Elles expliquent aussi que les positions peuvent fluctuer pendant un déménagement. Un classement inchangé ne doit donc pas être promis comme résultat garanti. Source : Google Search Central.

Attribuez un responsable et un statut à chaque point :

Contenus : pages importantes, images, téléchargements, coordonnées et versions linguistiques vérifiés.
URL : la destination de chaque ancienne URL importante documentée. Testez une redirection permanente quand une page de remplacement pertinente existe, plutôt que d’envoyer toutes les pages supprimées vers l’accueil.
Accès des moteurs : paramètres d’indexation, URL canoniques et liens internes vérifiés pour les pages qui doivent être mises en ligne.
Formulaires : envois réussis et échoués, confirmation, destinataire et transmission interne testés.
E-commerce : commandes test, changements de statut et notifications vérifiés selon la procédure de test de paiement convenue.
Mesure : l’événement convenu arrive au bon endroit, n’est pas compté deux fois et se distingue de l’activité réelle des clients pendant les tests.
Retour arrière : conditions d’arrêt, décideur et procédure de restauration documentés. Une boutique doit aussi prévoir les commandes reçues après le changement.

Gardez les preuves avec la checklist : par exemple l’heure du test, la confirmation de la personne qui a reçu la demande et les anomalies restantes. Une case cochée sans explication est plus difficile à exploiter lors de la passation.

4. Définir ce que le client reçoit

Le nom de domaine, la plateforme, les outils de mesure et les contenus peuvent se trouver sur des comptes différents. La liste de passation doit nommer leurs administrateurs et les accès remis au client. Les identifiants passent par un canal sécurisé adapté, pas par un document de projet partagé.

Demandez la liste des abonnements, des coûts de renouvellement, des licences nécessaires et des exports disponibles. La remise du code source, l’export complet du site et la possibilité de changer de prestataire varient selon la plateforme et le contrat. Clarifiez ces points avant de choisir le système. Un accès aux comptes ne décrit pas à lui seul tous les droits contractuels ni tous les services inclus.

Le dossier de passation peut contenir un inventaire des comptes, des instructions d’édition, la checklist de recette validée et une explication des tâches récurrentes. Convenez de qui le tient à jour après la livraison.

5. Fixer une date pour le bilan après lancement

Une séquence utile : une vérification immédiate au lancement, des contrôles opérationnels les premiers jours, puis un bilan sur des périodes de comparaison équivalentes. Le rythme exact dépend du trafic du site et du risque opérationnel.

Les clics de la Search Console et les événements GA4 répondent à des questions différentes. Une demande qualifiée exige en plus une définition métier : la demande est-elle pertinente, le contact est-il joignable, est-ce une demande unique ? L’équipe qui reçoit les demandes ou le CRM doit généralement le confirmer. Plus d’événements de formulaire suivis ne signifient pas automatiquement plus de ventes.

Notez les anomalies connues, la correction promise et son responsable. La maintenance, les fonctionnalités supplémentaires et la gestion de campagnes peuvent nécessiter un périmètre à part. Accepter le site ne commande pas automatiquement ces services.

Questions fréquentes

Un nouveau site nécessite-t-il un nouveau nom de domaine ?

Pas forcément. Partez de la raison métier. Changer de design ou de plateforme et changer de domaine sont deux décisions distinctes.

Le choix de la plateforme règle-t-il la migration ?

Non. Les contenus, les intégrations, les tests et la passation des comptes ont toujours besoin de responsables, même avec une plateforme connue.

Qui valide le lancement ?

Le valideur désigné, à partir des retours notés du prestataire et des responsables des vérifications. Les problèmes ouverts doivent être visibles avant cette décision.

Peut-on garantir un trafic inchangé ?

Ce n’est pas une promesse sérieuse. La planification et les vérifications réduisent les erreurs évitables, mais le prestataire ne maîtrise pas tous les facteurs qui influencent le référencement.

Que faut-il apporter au premier échange ?

L’URL actuelle, les processus métier importants, les problèmes connus, la mesure disponible et la date de décision. Convenez à part des accès minimum nécessaires avant de les partager.

Découvrez notre offre de création de site internet et notre équipe et nos projets publics.

Migration de site internet : responsabilités, passation et checklist de lancement