Guides pratiques approfondis

Préparer une migration de site multilingue

Construire une correspondance par langue, préserver les parcours et tester les destinations : préparer un changement d’URL sans perdre les contenus utiles.

Mise à jour :

Chaque ancien parcours mène-t-il au bon contenu dans la bonne langue ?

Une migration multilingue concerne davantage que les pages visibles dans un menu. Fiches à paramètres, catégories, recherche, formulaires, téléchargements et médias peuvent conserver des adresses différentes. L’inventaire doit identifier les contenus, leur langue et leurs dépendances. Ce guide prépare une migration et ses contrôles ; il ne suppose pas qu’un changement d’adresse soit nécessaire pour le site consulté.

  1. Inventorier les URL et leurs usages

    Croiser l’exploration interne, le sitemap, les contenus du système de publication et les parcours connus. Inclure les URL à paramètres qui identifient une fiche. Noter langue, type, statut, liens entrants connus et destination prévue ; distinguer paramètres d’identité et simples états de filtre.

  2. Établir la correspondance par langue

    Associer chaque contenu conservé à son équivalent réel dans la même langue. Pour une fusion, vérifier que la destination reprend l’information utile. Lorsqu’aucun remplacement pertinent n’existe, documenter le retrait plutôt que rediriger automatiquement tout le contenu vers une page d’accueil.

  3. Préparer les signaux de publication

    Mettre à jour les liens internes, adresses canoniques, versions linguistiques et sitemap sur les destinations finales. Vérifier que les équivalents déclarés existent et se correspondent. Contrôler aussi les références aux fichiers, images et téléchargements qui ne sont pas des pages HTML.

  4. Tester les parcours sur l’environnement préparé

    Ouvrir catégories, fiches, recherche et formulaires dans chaque langue. Changer de langue depuis une fiche précise et vérifier le maintien de son identité. Tester le clavier, les fenêtres mobiles et le rendu arabe ; contrôler les réponses HTTP et les destinations, pas seulement l’apparence du menu.

  5. Définir les redirections et les retraits

    Tester les anciennes URL sur la configuration prévue et relever chaque destination. Favoriser un chemin direct vers le contenu final. Vérifier l’absence de boucle, de chaîne inutile et de mélange linguistique. Les contenus retirés sans équivalent doivent renvoyer un état cohérent avec leur suppression.

  6. Prévoir le suivi et la reprise

    Conserver la correspondance validée et le dernier état fonctionnel. Définir les critères de blocage, la personne responsable et les étapes de retour arrière avant le changement. Après publication autorisée, surveiller erreurs, parcours et signaux d’indexation ; ne pas promettre un délai universel de stabilisation.

Situations et arbitrages

Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.

Une fiche conserve son slug mais perd son paramètre

Vérifier que la destination identifie la même fiche, pas seulement le même modèle de page. Tester plusieurs identifiants, des caractères encodés et une valeur inconnue. Une URL de modèle unique ne remplace pas toutes les fiches.

La version traduite n’a pas d’équivalent

Confirmer si le contenu est réellement absent ou simplement mal relié. Créer une traduction utile lorsque son sujet le justifie ; sinon documenter la lacune. Ne pas déclarer comme équivalente une rubrique qui traite une autre intention.

Le formulaire change de langue après une erreur

Contrôler l’action, les champs de contexte et les retours de validation. Préserver la langue et les informations de test nécessaires à la correction. Vérifier le parcours complet jusqu’à l’état observé, avec une destination de test autorisée.

Preuve à conserver

  • Inventaire des URL avec identité, langue, type et décision de conservation.
  • Table de correspondance ancienne URL → destination finale et justification des fusions ou retraits.
  • Résultats HTTP, liens canoniques, équivalents linguistiques et parcours testés.
  • Configuration vérifiée, critères de suivi, responsabilités et procédure de reprise.

Références officielles

Protocoles connexes

Questions fréquentes

Faut-il changer tous les slugs traduits ?

Pas automatiquement. Choisir une structure cohérente avec les contenus et les parcours. Un changement supplémentaire augmente les correspondances à maintenir ; son utilité doit être identifiable avant de l’ajouter.

Peut-on rediriger toutes les pages vers l’accueil ?

Une destination générale ne restitue généralement pas le contenu attendu. Rechercher un équivalent pertinent par langue. En l’absence de remplacement, traiter explicitement le retrait plutôt que masquer la disparition de l’information.

Le sitemap suffit-il comme inventaire ?

Il constitue un point de départ. Comparer avec les pages liées, fiches à paramètres, fichiers et parcours applicatifs. Des contenus utiles peuvent exister hors sitemap, tandis que des entrées périmées peuvent y rester.

Quand effectuer le contrôle final ?

Avant publication, sur la configuration préparée, puis après sur les URL réellement servies. Comparer les deux états. Une modification tardive des routes, contenus ou dépendances justifie de reprendre les contrôles concernés.