Contrôle de parité avant migration

Les pertes liées à une migration se jouent avant la mise en ligne et se diagnostiquent des semaines après, quand l'ancien site n'existe plus et que la comparaison qui aurait expliqué la chute est devenue impossible. Un audit après coup relève de la récupération, pas de la prévention. Celui-ci se mène pendant que les deux versions coexistent, et il débouche sur une décision de lancer ou non, pas sur une liste d'améliorations pour plus tard.

Le fichier de compétence

---
name: pre-launch-migration-parity-check
description: À utiliser lorsqu'un changement de plateforme, une refonte ou un changement de domaine est à quelques semaines de la mise en ligne et que l'environnement de préproduction et le site actuel existent encore tous les deux.
---

# Contrôle de parité avant migration

Les pertes liées à une migration se jouent avant la mise en ligne et se diagnostiquent des semaines après, quand l'ancien site n'existe plus et que la comparaison qui aurait expliqué la chute est devenue impossible. Un audit après coup relève de la récupération, pas de la prévention. Celui-ci se mène pendant que les deux versions coexistent, et il débouche sur une décision de lancer ou non, pas sur une liste d'améliorations pour plus tard.

## Ce qu’il vous faut d’abord

- Un crawl complet du site en production exportant URL, statut, canonical, meta robots, title, H1, nombre de mots et nombre de liens internes
- Un accès de crawl à la préproduction protégée par authentification HTTP ou par liste d'IP autorisées, jamais par un blocage robots.txt
- Les principales URL par trafic, par chiffre d'affaires et par domaines référents, sous forme de trois listes distinctes et non d'une seule
- Une date de mise en ligne et le nom de la personne habilitée à l'arrêter

## Méthode

1. Figez le crawl de production dans un fichier daté et conservez-le en dehors du projet. Après la mise en ligne, l'ancien ensemble d'URL ne peut plus être reconstitué, et ce fichier est la seule preuve de ce qui existait.
2. Crawlez la préproduction avec des réglages identiques et comparez les deux listes d'URL. Cette comparaison est le plan de redirections ; ce n'est pas un document à rédiger séparément par la suite.
3. Vérifiez que chaque URL des listes trafic, chiffre d'affaires et backlinks figure dans le plan avec une destination un pour un. Regrouper de nombreuses anciennes URL vers une catégorie ou la page d'accueil est ce qui coûte le plus cher dans une migration, et cela se défend toujours au nom du rangement.
4. Comparez gabarit par gabarit plutôt que page par page : modèle de title, canonical, meta robots, données structurées, H1, nombre de mots du contenu principal et nombre de liens internes. Une régression dans un gabarit se multiplie sur toutes les URL qui l'utilisent.
5. Vérifiez que la préproduction est protégée par authentification et non par robots.txt ou un noindex global, puis vérifiez séparément que la protection est bien retirée au lancement. Ces deux erreurs ont déjà fait sortir des sites entiers de l'index le jour même de la mise en ligne.
6. Testez les règles de redirection en préproduction sur la totalité de la liste figée, pas sur un échantillon : chaînes de requête, barres obliques finales, chemins en majuscules, motifs hérités dont plus personne ne se souvient. Des règles qui passent sur vingt exemples choisis à la main échouent régulièrement sur la longue traîne.
7. Validez le dispositif de surveillance avant la mise en ligne : quelles URL sont contrôlées à la première heure, au premier jour, au septième et au trentième, quels chiffres sont suivis, et quelle valeur déclenche un retour arrière. Décider cela après coup revient à en débattre en pleine crise.

## Ce que ça produit

Un rapport de parité concluant par un feu vert ou un feu rouge, contenant l'inventaire figé de la production, le plan de redirections complet couvrant une pour une toutes les URL de valeur, une comparaison par gabarit, et un plan daté de surveillance et de retour arrière.

## Là où ça dérape

- Protéger la préproduction avec robots.txt ou un noindex global, qui partent l'un comme l'autre en production et désindexent le nouveau site dès le premier jour
- Construire le plan de redirections à partir du sitemap plutôt que des logs et des données de backlinks, si bien que des URL absentes du sitemap mais porteuses de liens et de trafic disparaissent sans bruit
- Livrer un changement de plateforme et une refonte la même semaine, ce qui rend toute chute ultérieure impossible à attribuer à l'un ou à l'autre
- Considérer le plan comme terminé une fois écrit, alors qu'un plan non testé est un tableur, pas une migration

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/pre-launch-migration-parity-check

Ce qu’il vous faut d’abord

• Un crawl complet du site en production exportant URL, statut, canonical, meta robots, title, H1, nombre de mots et nombre de liens internes
• Un accès de crawl à la préproduction protégée par authentification HTTP ou par liste d'IP autorisées, jamais par un blocage robots.txt
• Les principales URL par trafic, par chiffre d'affaires et par domaines référents, sous forme de trois listes distinctes et non d'une seule
• Une date de mise en ligne et le nom de la personne habilitée à l'arrêter

Méthode

1. 01 Figez le crawl de production dans un fichier daté et conservez-le en dehors du projet. Après la mise en ligne, l'ancien ensemble d'URL ne peut plus être reconstitué, et ce fichier est la seule preuve de ce qui existait.
2. 02 Crawlez la préproduction avec des réglages identiques et comparez les deux listes d'URL. Cette comparaison est le plan de redirections ; ce n'est pas un document à rédiger séparément par la suite.
3. 03 Vérifiez que chaque URL des listes trafic, chiffre d'affaires et backlinks figure dans le plan avec une destination un pour un. Regrouper de nombreuses anciennes URL vers une catégorie ou la page d'accueil est ce qui coûte le plus cher dans une migration, et cela se défend toujours au nom du rangement.
4. 04 Comparez gabarit par gabarit plutôt que page par page : modèle de title, canonical, meta robots, données structurées, H1, nombre de mots du contenu principal et nombre de liens internes. Une régression dans un gabarit se multiplie sur toutes les URL qui l'utilisent.
5. 05 Vérifiez que la préproduction est protégée par authentification et non par robots.txt ou un noindex global, puis vérifiez séparément que la protection est bien retirée au lancement. Ces deux erreurs ont déjà fait sortir des sites entiers de l'index le jour même de la mise en ligne.
6. 06 Testez les règles de redirection en préproduction sur la totalité de la liste figée, pas sur un échantillon : chaînes de requête, barres obliques finales, chemins en majuscules, motifs hérités dont plus personne ne se souvient. Des règles qui passent sur vingt exemples choisis à la main échouent régulièrement sur la longue traîne.
7. 07 Validez le dispositif de surveillance avant la mise en ligne : quelles URL sont contrôlées à la première heure, au premier jour, au septième et au trentième, quels chiffres sont suivis, et quelle valeur déclenche un retour arrière. Décider cela après coup revient à en débattre en pleine crise.

Ce que ça produit

Un rapport de parité concluant par un feu vert ou un feu rouge, contenant l'inventaire figé de la production, le plan de redirections complet couvrant une pour une toutes les URL de valeur, une comparaison par gabarit, et un plan daté de surveillance et de retour arrière.

Là où ça dérape

• Protéger la préproduction avec robots.txt ou un noindex global, qui partent l'un comme l'autre en production et désindexent le nouveau site dès le premier jour
• Construire le plan de redirections à partir du sitemap plutôt que des logs et des données de backlinks, si bien que des URL absentes du sitemap mais porteuses de liens et de trafic disparaissent sans bruit
• Livrer un changement de plateforme et une refonte la même semaine, ce qui rend toute chute ultérieure impossible à attribuer à l'un ou à l'autre
• Considérer le plan comme terminé une fois écrit, alors qu'un plan non testé est un tableur, pas une migration

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans SEO technique