Comment un Headless CMS gère-t-il les associations entre contenus multilingues pour les sites web internationaux ?

Après le lancement d’un site web multilingue à l’échelle mondiale, les problèmes courants ne tiennent pas à l’absence de traductions, mais au fait que, lorsqu’une page produit anglaise est mise à jour, on ne sait pas ce qu’il faut synchroniser sur la page allemande ; que l’utilisateur change de langue et se retrouve sur la page d’accueil ; ou que des traductions retirées du site apparaissent toujours dans la navigation par langue. Pour gérer ces relations, il faut relier les différentes versions linguistiques à l’aide d’un identifiant stable de groupe de contenu, puis enregistrer séparément la langue, la région, le statut de publication et la version source, plutôt que de deviner les correspondances à partir des titres ou des URL.

Lors de l’évaluation d’une solution de CMS headless pour des sites web internationaux, il faut vérifier à la fois le modèle de contenu, le processus de traduction et le rendu côté front-end. Le fait que le CMS conserve les associations ne garantit pas que le site gérera correctement le changement de langue ou générera les balises hreflang ; l’API de livraison doit fournir suffisamment d’informations pour que le front-end puisse déterminer « quelles versions linguistiques d’un même contenu sont accessibles au public ».

Définir d’abord ce qui constitue « un même contenu », puis décider comment stocker les traductions

Les présentations en anglais et en allemand d’un même produit appartiennent généralement à un seul groupe de contenu. En revanche, des pages promotionnelles destinées à différents marchés et proposant des conditions différentes ne sont pas nécessairement de simples traductions. Avant la modélisation, il convient de définir quelles pages partagent la même identité métier et quelles pages correspondent à des contenus de marché distincts. Sans cela, un appariement forcé risque de rediriger les utilisateurs vers des pages qui ne sont pas équivalentes.

Il est recommandé de dissocier l’identité métier de l’identité de la version linguistique, afin d’éviter que les associations ne deviennent invalides lorsque les titres ou les chemins changent :

• contentGroupId : identifie un même contenu dans différentes langues et ne change pas à la suite d’une traduction ou d’un renommage.
• variantId et locale : identifient une version précise et sa région linguistique, par exemple de-DE ; une contrainte d’unicité doit s’appliquer à une même locale au sein d’un groupe.
• sourceVariantId et sourceRevision : indiquent la version et la révision sur lesquelles la traduction est basée, afin de déterminer si elle est obsolète.
• slug, statut et date de publication : sont gérés séparément pour chaque version linguistique ; le résultat de publication de la langue source n’est pas hérité par défaut.

Il est préférable d’utiliser le format BCP 47 pour les codes de langue. Le choix de distinguer en-US et en-GB, par exemple, doit dépendre des différences de contenu, et non de la seule présence d’un pays cible. Les codes de marché utilisés dans les systèmes métier peuvent être stockés séparément ; ils ne doivent pas être confondus avec les champs de langue.

Champs localisés ou entrées linguistiques indépendantes : comment choisir ?

Les deux modèles permettent d’établir des associations ; la différence réside dans le niveau de granularité de l’édition et de la publication.

Les modèles de produits et les spécifications techniques peuvent être partagés, tandis que les titres, les descriptions et les textes SEO sont gérés par langue ; les prix, les informations de certification et les conditions de livraison peuvent, quant à eux, nécessiter des valeurs propres à chaque marché. Il ne faut ni traduire systématiquement tous les champs, ni laisser les « champs partagés » masquer de réelles différences régionales.

Les associations doivent également couvrir les contenus référencés. Lorsqu’une page produit allemande fait référence à une ressource téléchargeable en anglais, le système doit préciser s’il s’agit d’un contenu partagé dont l’utilisation est autorisée ou si la version allemande manque ; il ne suffit pas de vérifier le texte principal de la page.

Intégrer les associations de traduction au processus de publication, et pas seulement à l’interface d’édition

L’existence d’une traduction ne signifie pas qu’elle est toujours à jour. Après la modification du texte source, il faut comparer la révision source enregistrée pour la traduction à la révision actuelle, puis marquer les versions concernées comme « à réviser », plutôt que d’écraser directement un texte déjà approuvé. Le retrait éventuel d’une ancienne traduction doit dépendre du risque lié à la modification : une retouche de formulation et une modification de paramètres de sécurité ne doivent pas suivre la même stratégie.

1. Lorsque le texte source est prêt à être traduit, générer une tâche comprenant le groupe de contenu, la langue, le chemin du champ et la révision source.
2. À la réception de la traduction, vérifier la révision source ; si le texte source a changé, conserver le brouillon traduit et signaler le conflit, sans l’écraser silencieusement.
3. Lors de la révision, vérifier la terminologie, les ressources référencées, les restrictions régionales et les champs SEO localisés, puis publier avec les autorisations appropriées.
4. Après la publication ou le retrait du contenu, déclencher, via un Webhook, la reconstruction des pages, l’invalidation du cache et la mise à jour de la navigation par langue ; prévoir une nouvelle tentative en cas d’échec de l’événement.

Les rappels de tâches doivent être traités de manière idempotente afin d’éviter la création d’entrées en double lors des nouvelles tentatives. Les interfaces d’aperçu et de livraison publique doivent également être isolées, pour empêcher que des brouillons ne soient exposés en ligne via la liste des contenus associés par langue.

Le résultat de repli de l’API doit être identifiable

Si une requête pour une page en français renvoie un contenu en anglais, mais que le front-end l’identifie toujours comme du français, la déclaration de langue ne correspondra pas au corps de la page. L’API doit renvoyer la langue demandée, la langue effectivement renvoyée et indiquer si un mécanisme de repli a été déclenché ; elle ne doit pas se contenter de renvoyer le corps du contenu.

Il est recommandé de définir des règles de repli distinctes pour le corps du contenu, les menus et les ressources partagées. Si une traduction de menu manque, un repli peut être prévu selon la stratégie produit. En revanche, si la traduction d’une page entière n’est pas encore publiée, il faut choisir explicitement de masquer l’entrée de cette langue, d’indiquer qu’elle n’est pas disponible ou de rediriger vers l’adresse dans la langue source ; il ne faut pas copier silencieusement le texte source sous une URL dans la langue cible.

La clé de cache doit au minimum distinguer le contenu, la langue et l’environnement de livraison. Sinon, même si les associations en base de données sont correctes, la réutilisation du cache peut entraîner le renvoi d’une même page pour des requêtes dans différentes langues.

Les associations SEO ne doivent référencer que des versions réellement accessibles

Le changement de langue et les balises hreflang doivent s’appuyer sur les mêmes données d’association publiées. Lors du changement de langue, il faut conserver le groupe de contenu, plutôt que de simplement remplacer le préfixe de langue dans le chemin ; si la version cible n’existe pas, ne pas générer de lien qui semble valide.

• Les balises hreflang doivent inclure la page actuelle et les versions correspondantes qui existent réellement, avec des références réciproques ; les codes de langue et de région doivent également respecter les formats pris en charge par les moteurs de recherche.
• Les pages linguistiques indépendantes indexables utilisent généralement une balise canonical autoréférente. Elles ne doivent pas toutes pointer vers la page dans la langue source, au risque d’envoyer des signaux de canonicalisation contradictoires.
• Les versions non publiées, redirigées, renvoyant une erreur ou définies sur noindex ne doivent plus être proposées comme alternatives linguistiques destinées à l’indexation.

Lors de la recette, vous pouvez tester quatre situations avec un même groupe de contenu — « modification du texte source », « traduction non publiée », « retrait d’une version linguistique » et « renommage du slug » — et vérifier si l’API, la navigation par langue, le cache et les balises hreflang sont mis à jour de manière synchronisée. Si les associations semblent correctes dans le back-office, mais que des adresses obsolètes restent en ligne, il faut d’abord examiner les événements de publication et la chaîne de génération du front-end, plutôt que de recréer les relations de traduction.