Plateforme multilingue : réussir l'internationalisation d'un site ou d'un logiciel

Une entreprise qui vend en Suisse, en Belgique, au Canada ou en Afrique francophone découvre vite que « mettre le site en anglais » ne règle rien. Les clients suisses paient en francs suisses, les clients canadiens n'écrivent pas tout à fait le même français, un catalogue technique traduit à moitié devient inutilisable, et les moteurs de recherche affichent la mauvaise version au mauvais public.

Ce guide s'adresse aux entreprises qui ouvrent un site, une boutique ou une plateforme à plusieurs langues ou à plusieurs pays. Il distingue ce qui relève de la conception (à décider avant le développement) de ce qui relève du contenu (à organiser dans la durée).

Internationaliser, puis localiser

Le W3C, l'organisme qui définit les standards du web, distingue deux étapes :

• L'internationalisation consiste à concevoir le logiciel pour qu'il puisse s'adapter à plusieurs langues et pays sans être réécrit : textes sortis du code, formats de date et de nombre gérés par des bibliothèques, gestion de plusieurs devises, mises en page qui supportent des textes plus longs.
• La localisation consiste à adapter le contenu à un public donné : traduction, mais aussi devise, unités, exemples, mentions légales, moyens de paiement.

La première coûte peu si elle est prévue dès le départ, et cher si elle arrive après coup : il faut alors reprendre chaque écran, chaque e-mail et chaque document généré. C'est la raison principale pour laquelle nous posons la question de l'international dès le cadrage, même si la deuxième langue n'arrive que plus tard.

Une adresse par langue : la structure des URL

Chaque version linguistique doit avoir sa propre adresse. Google décrit trois structures possibles, avec leurs avantages et leurs limites.

Google déconseille en revanche les paramètres d'adresse (exemple.com?lang=de), difficiles à exploiter. Pour une PME, le sous-répertoire est en général le meilleur compromis : un seul site, une seule base, une seule maintenance.

Deux erreurs fréquentes sont à éviter. La première : rediriger automatiquement le visiteur vers une langue selon son adresse IP ou la langue de son navigateur. Google le déconseille, parce que cela peut empêcher les visiteurs et les moteurs d'accéder aux autres versions ; il recommande plutôt des liens visibles vers les autres langues. La seconde : mélanger deux langues sur une même page. Google détecte la langue d'une page à partir de son contenu visible, et non de l'attribut lang du code ni de l'adresse.

Les annotations hreflang

Les annotations hreflang indiquent aux moteurs quelles pages sont des versions linguistiques ou régionales les unes des autres. Selon la documentation de Google, trois règles comptent :

• Les liens sont réciproques : chaque version pointe vers elle-même et vers toutes les autres. Si une page ne renvoie pas vers une autre, Google ignore les annotations concernées.
• La valeur x-default désigne la page de repli pour les visiteurs dont la langue ne correspond à aucune version, typiquement une page de choix de la langue.
• Trois méthodes équivalentes existent : des balises dans l'en-tête HTML, un en-tête HTTP ou le plan du site (sitemap). Les cumuler n'apporte rien.

Sur une plateforme qui génère des milliers de pages (catalogue, annonces, fiches), ces annotations doivent être produites automatiquement par le logiciel, à partir des traductions réellement disponibles. Une page sans traduction ne doit pas être annoncée comme traduite.

Le back-office multilingue : là où tout se joue

Sur une plateforme, la difficulté n'est pas l'interface publique mais la gestion des contenus en plusieurs langues. Il faut décider :

• Quels contenus sont traduits : fiches produits, catégories, pages, e-mails transactionnels, documents générés (devis, factures, rapports).
• Comment les traductions sont stockées : un champ par langue, avec une langue de référence et un statut (à traduire, traduit, relu).
• Ce qui s'affiche quand une traduction manque : la langue de référence, avec un signalement dans le back-office, plutôt qu'un champ vide.
• Qui traduit et qui valide, et comment une modification du texte de référence signale les traductions à revoir.

Pour le Tapas Tour organisé par Grupo Rouleaux, l'application publique est disponible en cinq langues, et le back-office gère les fiches des restaurants et des tapas dans chacune d'elles. Pour la boutique Pièces Peugeot Motocycles réalisée pour APARO, la version anglaise s'appuie sur un catalogue constructeur qui arrivait brut, en majuscules, sans accents et abrégé : il a fallu le normaliser automatiquement sur l'ensemble des références avant même de parler de traduction. C'est un cas fréquent : la qualité des données d'origine conditionne la qualité de toutes les langues.

Devises, formats, taxes : la localisation qui ne se voit pas

La traduction est la partie visible. Le reste est souvent plus coûteux à corriger après coup :

• Les devises : prix fixés par devise ou convertis, arrondis, affichage, et devise de règlement auprès du prestataire de paiement.
• Les formats : dates, nombres, séparateurs décimaux, numéros de téléphone, adresses postales. Les bibliothèques fondées sur les données Unicode CLDR gèrent ces différences pour la plupart des pays, à condition de ne pas les coder à la main.
• Les taxes et mentions : TVA ou taxes locales, mentions légales, conditions générales, durée de rétractation. La Suisse, par exemple, applique sa propre TVA, en dehors du régime européen.
• Les moyens de paiement et la livraison : les habitudes diffèrent d'un pays à l'autre, et les transporteurs aussi.
• Les fuseaux horaires : une prise de rendez-vous ou une échéance doit être affichée dans l'heure du client et stockée sans ambiguïté.

Nos clients se trouvent en France, mais aussi en Suisse, en Belgique, au Canada et en Afrique francophone, notamment en Guinée et au Cameroun. Même en restant en français, ces marchés imposent des devises, des formats et des usages différents, et le logiciel doit les prendre en compte dès sa conception.

La traduction : humaine, automatique ou assistée

Les outils de traduction automatique et les modèles de langage produisent aujourd'hui des premiers jets de bonne qualité. Ils ne dispensent pas d'une relecture par une personne qui connaît la langue et le métier, en particulier pour :

• les pages qui engagent : conditions générales, mentions légales, promesses commerciales ;
• la terminologie technique : un glossaire par langue évite que la même pièce porte trois noms différents ;
• le ton : le vouvoiement, les formules de politesse et le niveau de formalité varient selon les pays.

Une approche efficace consiste à automatiser le premier jet dans le back-office, à suivre le statut de chaque traduction, puis à faire relire les contenus qui comptent. L'outil doit rendre cette relecture simple, sinon elle n'aura pas lieu.

Le référencement par pays

Une version linguistique bien construite ne se positionne pas d'elle-même. Elle a besoin de contenus pensés pour son public (les requêtes ne sont pas les mêmes d'un pays à l'autre, même en français), de liens depuis les autres versions et d'un suivi par pays dans la Search Console. Les assistants IA, qui répondent de plus en plus aux questions des acheteurs, s'appuient eux aussi sur des contenus clairs et structurés dans chaque langue. Notre guide du référencement dans les IA détaille ce point.

Les erreurs les plus fréquentes

• Traduire l'interface mais pas les e-mails et les documents. Le client navigue en allemand, puis reçoit sa confirmation de commande et sa facture en français.
• Coder les formats à la main. Une date écrite « 08/10/2026 » se lit le 8 octobre en France et le 10 août aux États-Unis.
• Oublier la longueur des textes. Une traduction peut être nettement plus longue que le texte d'origine : boutons coupés, menus qui débordent, colonnes qui se décalent. Les maquettes doivent être vérifiées dans chaque langue.
• Annoncer une langue sans contenu. Une version dont la moitié des pages renvoie au français déçoit le visiteur et brouille les signaux envoyés aux moteurs.
• Ne pas désigner de responsable. Sans une personne chargée de chaque langue, les traductions vieillissent plus vite que la version de référence.

Par où commencer

L'ordre que nous recommandons tient en quatre étapes. D'abord, rendre le logiciel prêt pour l'international, même avec une seule langue : textes sortis du code, formats, devises. Ensuite, ouvrir une deuxième langue sur les pages et les parcours qui comptent le plus pour vos clients étrangers, plutôt que sur tout le site d'un coup. Puis mesurer : visites, demandes et commandes par pays, questions reçues. Enfin, étendre aux autres contenus et aux autres langues en fonction de ces résultats.

Notre approche

Nous traitons l'international comme une question de conception : dès le cadrage, nous identifions les langues, les pays, les devises et les contenus concernés, même si toutes les versions ne sont pas lancées en même temps. Le logiciel est ensuite construit pour les accueillir sans être réécrit. Le fondateur suit le projet du premier rendez-vous à la mise en service, le budget est fixé en forfait global ferme après le cadrage, et le code vous appartient.

Pour en savoir plus : plateformes web et portails clients, refonte de site internet et nos zones d'intervention.

Pour aller plus loin

• Refonte de site ou de plateforme : quand et comment la mener
• Shopify, WooCommerce, PrestaShop ou sur mesure
• Paiements de plateforme avec Stripe
• Migrer les données d'un ancien logiciel : la méthode
• Une application doit-elle être accessible ?

Sources

• Google Search Central, Versions localisées de vos pages (mise à jour du 24 septembre 2026) : developers.google.com (nouvel onglet)
• Google Search Central, Managing multi-regional and multilingual sites (mise à jour du 10 décembre 2025) : developers.google.com (nouvel onglet)
• W3C, Localization vs. Internationalization, consulté le 8 octobre 2026 : w3.org (nouvel onglet)
• Unicode Consortium, Unicode CLDR Project, consulté le 8 octobre 2026 : cldr.unicode.org (nouvel onglet)
• YMHB Web, études de cas Tapas Tour et Pièces Peugeot Motocycles (APARO), publiées sur ymhb-web.com (2026).