Migrer un site sans déplacer le problème

Si les URL restent identiques, le travail porte surtout sur la copie des fichiers, de la base, des certificats, des formulaires et des tâches planifiées. Si elles changent, il faut en plus une correspondance entre chaque ancienne adresse et sa destination.

Changer de CMS et de domaine pendant une refonte complète mélange trois causes de panne. Google recommande de séparer les changements importants lorsque c’est possible.

On relève les URL indexées, les contenus, les fichiers, les langues, les formulaires, les comptes, les droits, les automatisations et les connexions externes.

Les essais utilisent des données fictives ou anonymisées. Les accès à la préproduction, les copies temporaires, leur durée de conservation et leur suppression sont écrits avant le premier export de production.

Le bon socle dépend du modèle de contenu, des rôles, des langues, des connexions et de la personne qui devra le maintenir.

Un prototype sur un échantillon révèle plus que dix réunions : une page complexe, un formulaire, un média, une langue et un cas de redirection suffisent à tester le trajet.

On teste les redirections, les URL canoniques, le robots.txt, les plans de site, les formulaires et les événements avant d’ouvrir le nouveau site.

La zone DNS est exportée puis vérifiée : web, MX, SPF, DKIM, DMARC, sous-domaines, TTL et DNSSEC. Un test de charge couvre aussi le crawl habituel du nouveau site et les visites redirigées depuis l’ancien ; latence, 429, 5xx et blocages WAF ont des seuils de retour arrière.

Le registre de dépendances couvre CORS, CSP, OAuth, webhooks, cookies et stockage local : changer de domaine change aussi l’origine du navigateur. Le consentement repart refusé par défaut ; seul un transfert fonctionnel explicite, signé et à usage unique peut reprendre un brouillon.

La source d’écriture reste nommée pendant toute la transition. Les imports incrémentaux, le gel final, le dernier delta et la réconciliation des tâches et webhooks précèdent la bascule ; un retour arrière de données exige une synchronisation inverse, pas seulement un changement DNS.

Les connexions sortantes sont rejouées depuis la cible avec ses vraies IP : pare-feu, listes d’autorisation et certificats clients mTLS sont validés chez chaque service externe. Le DNS est interrogé depuis Internet, le VPN, les bureaux et les réseaux de services afin qu’une zone privée ne continue pas à désigner l’ancien serveur.

Quand un CDN ou un proxy inverse est ajouté, seuls ses relais peuvent atteindre l’origine. La chaîne de confiance des en-têtes Forwarded, X-Forwarded-For, Host et Proto est testée contre l’usurpation. Les applications et partenaires qui épinglent un certificat ou une clé publique reçoivent le nouveau jeu avant la rotation.

La cible ne reçoit du trafic qu’après un contrôle fonctionnel des données, médias, formulaires et connexions. L’ancien serveur cesse de recevoir de nouvelles requêtes puis draine les téléversements et connexions persistantes. Son horloge et celle de la cible sont synchronisées et surveillées avant de tester JWT, signatures, TLS et tâches planifiées.

Le registre distingue le stockage web, lié à l’origine, des cookies, limités par nom, Domain, Path et SameSite. Les cookies host-only ou préfixés __Host- empêchent les deux versions de s’écraser. Les scripts tiers et conteneurs de tags sont inventoriés avec propriétaire, version, données et destinations, puis gelés pendant la recette.

Pendant la coexistence, anciens et nouveaux processus lisent les deux versions des messages et valeurs de cache ; schémas et espaces de noms sont versionnés. Une restauration chiffrée est réellement déchiffrée dans la cible et dans le retour arrière avec les clés KMS, autorisations et contextes attendus. Enfin, les documents non HTML reçoivent leur en-tête Link canonique, et chaque langue garde une URL explorable avec une clé de cache cohérente avec l’en-tête Vary.

Les autorisations caméra, micro, géolocalisation, paiement et plein écran sont contrôlées sur la nouvelle origine. Les listes Permissions-Policy et les attributs allow des iframes nomment explicitement les nouveaux domaines. Pour FedCM, le fournisseur enregistre exactement la nouvelle origine du service utilisateur et vérifie son en-tête Origin ; le fichier web-identity du fournisseur reste disponible.

Les connexions d’entreprise migrent comme des contrats : Entity ID, URL ACS, URL de déconnexion, métadonnées et certificats SAML sont ouverts sur les deux versions pendant la transition. La base SCIM, ses jetons et les routes Users et Groups sont testés avec création, modification, désactivation et suppression afin d’éviter les comptes fantômes.

Si le site encaisse avec Apple Pay, chaque domaine marchand publie son fichier d’association et est vérifié avant la bascule ; l’expiration TLS est surveillée. Les rapports CSP changent aussi d’adresse : la directive moderne et son repli historique pointent vers un collecteur actif, avec un test réel puisque la directive moderne prend la priorité lorsqu’elles coexistent.