Gérer le multilingue avec Payload CMS et Next.js n’est pas une question de plugin à activer. C’est un modèle produit : quels champs sont localisés, comment les URLs se comportent, et comment votre équipe publie sans casser le SEO. Voici une méthode concrète utilisée en production sur beease.fr (FR / EN) et sur des projets clients livrés avec cette stack.
Si vous construisez un site vitrine ou une refonte headless, l’objectif business est simple : une équipe marketing qui publie en français, une version anglaise cohérente, et Google qui comprend clairement quelle langue servir. Notre offre Payload CMS + Next.js est conçue exactement pour ça.
Le vrai problème : un site bilingue, deux vérités
Beaucoup de projets « multilingues » finissent en doublons fragiles : deux arborescences copiées à la main, des plugins de traduction qui se battent avec le thème, des URLs instables, des meta oubliées dans une locale. Le marketing perd du temps, le SEO se dilue, et chaque évolution de page devient un ticket technique.
Avec un CMS headless comme Payload, vous séparez clairement :
- le contenu éditorial (pages, articles, meta) localisé dans le CMS ;
- le chrome UI (boutons, labels de navigation, messages d’erreur) géré côté front ;
- le routage (préfixe de locale, slugs, hreflang) branché une fois pour toutes.
C’est la même logique qui rend Payload plus sain qu’une usine à plugins WordPress : moins de rustines, plus de cadre. On l’a déjà détaillé dans Payload CMS vs WordPress et dans notre comparatif des alternatives headless à WordPress.
Ce que Payload localise (et ce qu’il ne localise pas)
Sur beease.fr, la config Payload est volontairement simple : deux locales (fr, en), locale par défaut fr, et fallback: true. Concrètement, si un champ EN n’est pas encore rempli, Payload renvoie la valeur FR à la lecture. Vous évitez les pages blanches pendant la traduction.
1
2
3
4
5
6
7
8
localization: {
locales: [
{ label: 'Français', code: 'fr' },
{ label: 'English', code: 'en' },
],
defaultLocale: 'fr',
fallback: true,
},Les champs localisés typiques sur un site Beease :
- title, slug, richtext (content / layout / hero) ;
- meta SEO (title, description, image) via
@payloadcms/plugin-seo; - certains labels de globals (header, footer).
Ce qui reste non localisé volontairement : catégories, dates de publication, relations structurelles, et souvent les médias (sauf l’alt). Un même document Payload a un seul ID et plusieurs jeux de champs localisés. Vous ne dupliquez pas la page : vous complétez la locale.
Règle pratique : publier d’abord la locale source (FR), puis traduire la même fiche. Jamais deux documents « jumeaux » à synchroniser à la main.
La doc officielle Payload sur la localization couvre les options ; le différenciant, c’est de les brancher sur un vrai front Next.js et un process éditorial clair.
Next.js : routage next-intl sans surprise
Côté front, beease.fr s’appuie sur next-intl avec localePrefix: "as-needed" et localeDetection: false. Traduction métier :
- le français n’a pas de préfixe (
/blog/...) ; - l’anglais vit sous
/en/...; - pas de bascule automatique selon
Accept-Language: l’utilisateur (ou le lien) choisit la langue.
Pourquoi désactiver la détection auto ? Parce qu’elle surprend les visiteurs, casse le partage d’URL, et mélange souvent SEO et UX. Une URL stable par locale, un switcher explicite, et des alternates / hreflang générés depuis les slugs de chaque locale : c’est plus prévisible pour Google et pour vos équipes.
Le couple Next.js + Payload permet aussi de garder le contenu HTML côté serveur : indispensable pour un CMS vraiment optimisé SEO.
Deux couches : contenu CMS vs chrome UI
Une erreur fréquente : tout mettre dans Payload, y compris « Lire la suite » ou « Accueil ». Sur beease.fr, on sépare :
- Payload : titres, corps, CTA éditoriaux, meta, slugs ;
- messages next-intl (
messages/fr.json,messages/en.json) : labels d’interface, breadcrumb, états vides.
Résultat : les rédacteurs travaillent sur le contenu qui convertit. Les développeurs versionnent le chrome UI comme du code. Moins de friction, moins de régressions à chaque release. Pour le vocabulaire technique du projet, le glossaire du développement web peut aider vos équipes non tech.
Slugs différents par langue
Le slug est localisé. La version EN peut donc viser une intention SEO anglaise sans coller un calque FR. Le front résout le chemin avec la locale active, et le sitemap / les hreflang pointent vers chaque variante, avec x-default vers le FR.
Un workflow éditorial efficace
La stack ne suffit pas : il faut un process. Voici un workflow qui fonctionne bien en production :
- Rédiger et valider en FR (draft Payload, locale fr uniquement).
- Traduire sur le même document vers en (même ID), en draft, sans écraser la source.
- Adapter, ne pas calquer : titres, meta, ancres de liens, slugs SEO EN.
- Publier quand les deux locales sont prêtes (ou publier FR puis EN si le business l’exige, grâce au fallback).
Les médias (thumbnail, images de blocs) restent partagés : on traduit l’alt si besoin, on ne duplique pas le fichier. Les liens internes restent des relations Payload (pages / posts / réalisations), pas des URLs hardcodées : le front choisit le bon slug selon la locale.
Si vous migrez depuis WordPress multilangue, budgettez le nettoyage des URLs et le mapping des slugs avant la bascule. Ensuite, industrialisez la prod avec une stack claire (VPS, Docker, HTTPS).
Pour le déploiement self-host, voir notre guide déployer Payload CMS avec Next.js.
Ce que gagne le marketing (pas seulement les devs)
Le multilingue efficace se juge côté métier. Votre responsable marketing doit pouvoir :
- ouvrir la fiche FR, basculer en EN dans l’admin Payload, et compléter sans toucher au code ;
- ajuster title / description SEO dans chaque locale sans ticket développeur ;
- prévisualiser l’URL locale (préfixe
/enou non) avant publication ; - garder le design et les blocs (CTA, comparaison, code) alignés entre langues.
C’est exactement l’autonomie que l’on cherche avec Payload : un cadre sûr, des champs clairs, pas une jungle de plugins de traduction. Les développeurs posent le modèle une fois ; le marketing itère ensuite.
Quand démarrer le multilingue (et quand attendre)
Tout site n’a pas besoin de deux langues le jour 1. Si 95 % de votre trafic et de vos leads sont FR, priorisez un excellent socle monolingue (perf, SEO technique, contenus piliers). Ajoutez l’EN quand vous avez une intention business claire : export, partenaires, recrutement international, ou pages produit déjà demandées en anglais.
En revanche, si vous savez dès le brief que le site sera bilingue, modelez la localisation dès le départ. Retrofitter les champs localized après coup est possible, mais plus coûteux (migrations, relecture, redirects). Sur beease.fr, FR + EN fait partie du produit : la config Payload et le routing Next.js ont été pensés ensemble.
Checklist multilingue avant mise en ligne
- Locales déclarées dans Payload + fallback cohérent avec la langue pivot.
- Champs éditoriaux et meta SEO marqués
localized: true; structure partagée hors locale. - next-intl (ou équivalent) : préfixe, pas de détection auto si vous voulez des URLs prévisibles.
- Slugs FR / EN distincts quand l’intention SEO diffère.
- hreflang + x-default générés depuis les chemins par locale.
- Sitemap dynamique incluant les variantes de langue.
- Switcher de langue qui pointe vers le document équivalent, pas vers l’accueil.
- Revue humaine de la locale cible (ton, CTA, longueurs meta).
Cette checklist complète les bonnes pratiques d’un CMS optimisé SEO : le multilangue n’est qu’une couche de plus sur un socle déjà crawlable.
Passer à l’action sur votre site multilingue
Un site vitrine ou une refonte PME gagne rarement à improvisation sur les langues. Ce qui marche : un document Payload par contenu, des locales explicites, un front Next.js qui route proprement, et un workflow FR → EN tenu par le marketing dans un cadre sûr.
Beease conçoit justement ce socle (modèle de contenus, SEO, autonomie éditoriale). Découvrez notre intégration Payload CMS, ou contactez-nous pour en parler autour de votre projet.
Martin Lotz
CEO
Ingénieur commercial
Martin Lotz est CEO et ingénieur commercial chez Beease Digital. Membre clé de l’équipe, il assure le lien entre les besoins business des clients et les solutions techniques de l’agence.
Planifier une démo avec Martin
