Une migration de site doit être approuvée au regard de contrôles convenus, avec une personne désignée pour les risques non résolus. Voir le nouveau design fonctionner en démonstration ne suffit pas. Je veux savoir ce que deviennent les pages existantes, comment les parcours importants ont été testés et qui peut agir en cas de problème.

Le mot « migration » peut recouvrir des projets très différents. Un changement de domaine, un autre système de publication et la réécriture d'un catalogue de services n'affectent pas le site de la même façon. Les combiner rend la mise en ligne plus difficile à évaluer, car plusieurs changements peuvent modifier une même page simultanément.

Ma première demande serait donc une description simple de ce qui change. Elle doit être assez précise pour permettre à l'équipe de signaler tout ce qui reste incertain.

Accordez-vous sur l'objectif avant d'approuver le remplacement

Une migration a besoin d'une raison commerciale capable de guider les arbitrages. Le système existant empêche peut-être des mises à jour importantes, l'entreprise regroupe ses marques ou le site ne permet pas un parcours client nécessaire. Cette raison doit rester visible pendant tout le projet.

Supposons qu'une entreprise fictive de services professionnels remplace son site parce que les modifications sont devenues laborieuses. Pendant la conception, ses pages de services détaillées sont regroupées en une présentation générale attrayante. Le problème d'édition peut être résolu, mais le projet modifie aussi la manière dont les clients découvrent chaque service.

Je demanderais que cette seconde décision soit évaluée séparément. La migration ne doit pas devenir un prétexte commode pour retirer des précisions simplement parce que la nouvelle mise en page leur laisse moins de place.

C'est aussi une façon utile de maîtriser le périmètre. Une amélioration proposée peut avoir de la valeur sans devoir figurer dans la même livraison. Séparer les décisions donne plus de sens à la validation et permet de mieux conserver la trace de l'objectif de chaque changement.

Attribuez une destination validée à chaque page importante

Avant la mise en ligne, je voudrais un inventaire des pages existantes qui comptent commercialement ou répondent à un besoin utilisateur important. Chacune doit avoir une destination explicite ou une raison documentée justifiant son retrait.

La destination doit répondre, autant que possible, au même besoin fondamental. Un ancien guide d'installation et une nouvelle page d'accueil de service ne sont pas interchangeables simplement parce qu'ils mentionnent le même produit. La personne qui suit l'ancien lien a toujours besoin d'informations d'installation.

Les recommandations de Google sur les migrations préconisent de faire correspondre les anciennes URL à leurs nouveaux équivalents, d'utiliser des redirections permanentes appropriées et d'éviter les destinations sans pertinence. Elles abordent aussi les réponses d'erreur correctes lorsque le contenu est supprimé sans remplacement adapté. Lorsque la relation n'est pas évidente, la décision doit se prendre page par page.

Je confierais les décisions de contenu à une personne qui comprend l'offre. Les développeurs peuvent mettre en œuvre un plan de correspondance validé, mais ils ne devraient pas avoir à deviner si un ancien service est abandonné, renommé ou simplement absent du design.

Faites du contenu manquant une décision, pas un accident

Une page peut conserver son adresse tout en perdant les informations qui la rendaient utile. La comparaison doit donc porter sur le contenu et les fonctionnalités, pas seulement sur les URL.

Imaginons un fournisseur fictif d'équipements dont le nouveau modèle de page produit omet les informations de compatibilité. La page s'ouvre, les images sont correctes et le bouton de contact fonctionne. Pourtant, le client ne peut plus déterminer si le produit convient à sa situation. Une validation visuelle pourrait ne pas repérer cette perte si le besoin n'a pas été consigné.

Je demanderais à chaque responsable métier d'identifier les informations dont ses clients ont besoin pour avancer. Il peut s'agir de caractéristiques, d'exclusions, de téléchargements ou de la distinction entre des services proches. Ces exigences doivent guider les contrôles sur des pages représentatives.

L'objectif n'est pas de tout conserver sans discernement. Un ancien contenu peut être faux, redondant ou inutile. Je veux que sa suppression soit intentionnelle et accompagnée d'une explication acceptée par une personne responsable.

Définissez ce qui empêcherait la mise en ligne

Un problème non résolu ne doit pas devenir acceptable simplement parce que le lancement approche. Avant que cette pression s'installe, convenez des défaillances qui bloqueraient la mise en ligne et de celles qui peuvent faire l'objet d'un suivi clairement attribué.

À mes yeux, une page de service importante inaccessible mérite une réponse différente d'une petite incohérence d'espacement. Les catégories doivent refléter les risques réels du site pour l'entreprise, plutôt qu'une liste de contrôle générique copiée d'un autre projet.

Google avertit explicitement que les restrictions de développement, notamment les règles noindex, doivent être examinées avant la mise en ligne. Il recommande aussi de tester le nouveau site et de surveiller la migration. Je transformerais ces principes en contrôles de validation identifiés, avec des éléments montrant ce qui a été testé et où.

L'équipe doit savoir qui est autorisé à reporter la mise en ligne. Si chacun suppose qu'une autre personne peut prendre cette décision, le processus de validation reste incomplet, même lorsque la liste de contrôles techniques semble exhaustive.

Intégrez la réponse après lancement au plan

Les personnes capables de réparer le site doivent être disponibles au moment de sa mise en ligne. Une organisation qui se termine par la remise d'un mot de passe laisse trop de questions ouvertes.

Je préciserais où signaler les problèmes, qui fixe leur priorité et qui confirme qu'une correction fonctionne sur le site public. L'équipe marketing doit aussi pouvoir distinguer un parcours défaillant d'un problème de mesure. Sinon, un rapport manquant peut être pris pour une absence de visiteurs, ou un formulaire défectueux peut passer inaperçu derrière un trafic apparemment normal.

Un plan de rétablissement doit décrire les options concrètes si le nouveau site échoue à un contrôle critique. Revenir à la version précédente n'est pas toujours simple, surtout si de nouveaux envois de formulaires ou des transactions ont déjà été enregistrés. L'équipe technique doit expliquer ces limites avant que l'entreprise considère le retour arrière comme une assurance.

Gardez les décisions visibles pendant le rétablissement. Modifier discrètement plusieurs éléments en même temps peut compliquer l'identification de ce qui a résolu le problème ou d'un autre défaut éventuellement introduit.

Validez la mise en ligne en laissant les incertitudes visibles

Google indique que les positions peuvent fluctuer pendant le traitement d'une migration importante. Cette possibilité doit être expliquée sans servir d'excuse générale à des défauts évitables. Un délai de traitement et une destination défectueuse sont deux choses différentes.

Je validerais une migration avec un état clair de ce qui a réussi les contrôles, de ce qui reste ouvert et des personnes responsables du travail restant. C'est plus utile qu'une déclaration selon laquelle le nouveau site est « prêt pour le SEO ».

L'entreprise n'a pas besoin d'inspecter elle-même chaque détail technique. Elle a besoin de suffisamment d'éléments pour comprendre la décision qu'elle prend. Lorsque les destinations, les responsabilités sur les contenus, les conditions de lancement et l'organisation de la réponse sont définies, la validation devient une décision de mise en ligne réfléchie, plutôt qu'une échéance que personne n'ose remettre en question.