I18n et multi-devises pour vendre en UE/Royaume-Uni

Vue d’ensemble : ce que « se lancer en Europe et au Royaume-Uni » signifie vraiment

La localisation n’est pas « traduire un site ». C’est l’alignement de quatre systèmes indépendants : langue, devise, fiscalité et livraison. La langue explique la valeur, la devise fait « ressentir » le prix, la fiscalité et la logistique déterminent le total final. La moindre dissonance fait chuter la conversion. Mieux vaut une localisation « étroite mais impeccable » qu’une couverture large et bancale.

Architecture de localisation : comment modéliser les marchés

Le premier choix n’est pas « en quelle langue », mais comment structurer l’infra.

Langue/région : en-GB ≠ en-IE, fr-FR ≠ fr-BE. Pour l’UX et le SEO, ce sont des pages distinctes. Déclarez vos variantes via hreflang (avec une entrée x-default pour la page globale ou le sélecteur pays/langue).

Structure d’URL : les sous-dossiers (/en-gb/, /fr-fr/) sont souvent plus pratiques que des domaines séparés : maintenance plus simple, autorité consolidée.

Harmonisation du catalogue : le SKU reste commun, tandis que nom, attributs, descriptions, légendes médias, FAQ et compatibilités sont localisés. Les unités visibles (tailles, matériaux, unités de mesure) sont prioritaires.

Catalogue et sens : « littéralement correct » n’est pas toujours « juste »

Un catalogue porte trois sens : ce que c’est, comment ça marche ici, pourquoi c’est avantageux ici. La traduction brute ne règle que le premier. En UE/UK, les deux autres varient par pays.

Pipeline utile :

• Base terminologique par catégorie (pas par produit) : noms de matériaux, teintes, tailles ; liste des faux amis.
• Pseudo-localisation avant traduction : « étirer » les chaînes pour détecter les casses de mise en page.
• Brouillon NMT → post-édition humaine : la machine donne la vitesse, l’humain l’intonation et la pertinence marché.
• Harmonisation des attributs : une même propriété (ex. « longueur de câble ») doit rester identique dans filtres, fiche produit, PDF et e-mails.

Côté qualité, les métriques de type BLEU sont peu parlantes : suivez plutôt l’impact sur la conversion par locale et la baisse des retours.

Devises et arrondis : là où la confiance se brise

Le client lit aussi le rythme des décimales. 19,95 € et 19,99 £ ne « sonnent » pas pareil ; les habitudes diffèrent par pays. Le vrai sujet technique reste les unités mineures (nb de décimales autorisées) et le formatage par locale (CLDR).

Trois règles pratiques :

Source unique d’arrondi. Affichage, panier, PSP et ERP doivent calculer de façon identique. Un centime d’écart suffit à semer le doute.

Montrer le “total à payer”. Si vous collectez taxes/droits en amont, dites-le clairement ; évitez le « calculé plus tard ».

La psychologie du prix après la conformité. Respectez d’abord devise/taxes, ensuite les .99. Un relevé bancaire qui ne matche pas l’affichage détruit l’effet prix.

Taxes et livraison : carte des risques (UE & UK)

UE. Pour le B2C, le paquet e-commerce a introduit OSS (One-Stop Shop) et IOSS (pour les envois importés ≤ 150 €). OSS permet de payer la TVA « en un point » selon le pays de destination ; IOSS évite les mauvaises surprises douanières sur les petits envois. C’est autant de l’UX que de la compta.

UK. Pour les importations ≤ £135, la TVA est due au point de vente ; sur les marketplaces, la plateforme est souvent « fournisseur réputé » et collecte la TVA. Au-delà ou hors marketplace, d’autres mécanismes s’appliquent ; le seuil £135 reste un repère UX central.

Côté logistique : DDP vs DAP. En transfrontalier, DDP (droits/taxes prépayés par le vendeur) réduit les refus à la livraison mais coûte plus cher à l’opérateur. DAP (droits au destinataire) est moins cher pour vous, plus risqué pour la conversion. Testez par SKU et panier : pour une première commande et les cadeaux, le DDP gagne souvent.

Paiements : la « localité » vaut mieux que l’exotisme

Devise locale + méthodes familières (cartes, PayPal, parfois « buy now, pay later ») font plus pour la conversion que des moyens exotiques. Méfiance avec la conversion dynamique (DCC) des banques : si le taux proposé nuit au client, la confiance s’effrite. Mieux vaut traiter dans la devise de la locale et expliquer honnêtement taux/commissions éventuels côté banque.

• SEO et navigation : éviter l’auto-cannibalisation
• hreflang n’est pas un grigri mais un graphe croisé entre versions.
• Réciprocité : chaque locale pointe vers toutes les autres et vers elle-même.
• x-default : vers la page globale ou le sélecteur.
• Cohérence : entêtes HTML ou sitemap, mais pas les deux en divergence.

Pipeline de traduction humain+IA : la vitesse sans perdre le sens

Modèle réaliste :

• Couche 1 : chaînes système. Pseudo-localisation + formats CLDR (dates/devises), vérification des placeholders.
• Couche 2 : entités catalogue. Brouillon NMT, post-édition humaine, term base par catégorie.
• Couche 3 : contenus longs. La machine donne une « pâte », l’éditeur finalise la voix.

Qualité : distance d’édition, time-to-publish et surtout impact sur conversion/retours par locale.

Ne pas perdre la conversion en entrant sur un nouveau marché

Les chutes de CR naissent souvent de la rencontre prix + taxe + livraison à l’ultime étape.

Checklist courte :

• Le total panier = le montant capturé par le PSP, à l’centime près.
• Taxes/droits annoncés en amont (si DAP, c’est dit clairement).
• Formulaires d’adresse conformes (postcodes UK, formats téléphones, provinces/départements).
• Moyens de paiement familiers, devise locale.
• E-mails (commande/expédition) localisés avec le même total que sur le site.

Conclusion

Réussir la localisation, c’est accorder l’argent et les attentes. La langue fait comprendre, la devise et l’arrondi font croire, la fiscalité et la livraison évitent la déception après le clic. En synchronisant ces quatre systèmes et en donnant aux moteurs les bons repères (hreflang), l’UE/UK devient un expérimentarium contrôlé : étape par étape, coût de l’erreur mesuré, effets cumulatifs.