Prix en devise locale sur une landing page : faut-il l’afficher ?

Un coach nord-américain tombe sur votre landing page. Le prix affiché : « 89 € ». Il sait vaguement que l’euro vaut un peu plus que le dollar, mais pas exactement combien — alors il ouvre un nouvel onglet, tape « 89 euros en dollars » dans un moteur de recherche, obtient un chiffre, et revient… ou ne revient pas. Ce détour, même de quinze secondes, est un point de friction que la plupart des landing pages francophones ignorent complètement dès qu’elles visent aussi un public anglophone ou nord-américain. La question n’est pas seulement « faut-il traduire ma page », elle est aussi : dans quelle devise faut-il compter ?

Pourquoi la devise affichée change la décision, pas seulement le confort de lecture

Ce n’est pas qu’une question d’esthétique. Dès 1985, l’économiste Richard Thaler a montré, dans son article fondateur sur la « comptabilité mentale » (mental accounting), qu’un acheteur évalue un prix par rapport à un point de référence mental plutôt que dans l’absolu (Thaler, 1985). Une devise étrangère n’offre pas ce point de référence immédiat : le cerveau doit d’abord convertir, puis comparer — deux étapes là où un prix en devise locale n’en demande qu’une. Plus spécifiquement au commerce en ligne transfrontalier, une étude de Xi Chen et Hag-Min Kim publiée en 2021 dans International Trade, Politics and Development montre que la « distance psychique » perçue par un acheteur — dont la devise affichée est une composante concrète — influence directement sa confiance et son intention d’achat (Chen & Kim, 2021). Un prix dans une devise inconnue n’est pas neutre : c’est un signal discret, mais réel, que la page n’a pas été pensée pour ce visiteur-là.

Le problème propre à une landing page générée statiquement

Si votre landing page est générée statiquement avec generateStaticParams — le choix recommandé pour la vitesse et le SEO, voir notre guide sur le déploiement Next.js sur Vercel — le HTML livré au navigateur est le même pour tout le monde : il a été figé au moment du build, bien avant qu’un visiteur n’arrive. À cet instant, rien ne dit si la page partira vers un lecteur à Lyon ou à Toronto. Adapter l’affichage à la devise du visiteur ne peut donc pas se jouer côté build : ça se passe forcément après coup, une fois la page arrivée dans le navigateur du visiteur.

Détecter la devise probable sans bandeau cookies

Bonne nouvelle : deviner la devise probable d’un visiteur ne nécessite aucune donnée personnelle, donc aucun bandeau de consentement — le même principe que celui détaillé dans notre article sur les analytics sans cookies. Trois signaux, du plus simple au plus fiable :

• Le fuseau horaire du navigateur, via Intl.DateTimeFormat().resolvedOptions().timeZone — un indice côté client, disponible sans aucun appel réseau supplémentaire.
• L’en-tête Accept-Language envoyé avec chaque requête HTTP — un bon indice sur la langue, un peu moins direct sur le pays.
• La géolocalisation IP fournie par la plateforme d’hébergement (sur Vercel, l’en-tête x-vercel-ip-country posé par le edge network) — le signal le plus direct pour déduire un pays, donc une devise probable.

Aucun de ces trois signaux n’identifie une personne : ce sont des métadonnées de requête, pas des données personnelles au sens du RGPD, donc pas de bandeau de consentement à afficher pour ce seul usage — voir notre guide RGPD et formulaire de landing page pour la limite à ne pas franchir si vous les combinez ensuite avec du tracking marketing.

Convertir le prix : taux fixe arrondi plutôt qu’API en temps réel

Deux approches s’opposent. La première interroge une API de taux de change à chaque affichage : précise, mais fragile — un appel réseau de plus qui peut retarder ou faire clignoter le prix affiché, ce qui pénalise le Core Web Vitals de la page, pour un chiffre à la décimale près qui donne une fausse impression de précision sur un montant qui, de toute façon, ne sera pas celui réellement débité. La seconde fixe des prix arrondis par grande zone monétaire — 89 € devient 99 $, pas 96,43 $ — mis à jour manuellement tous les quelques mois. Pour un achat ponctuel de moins de 250 €, l’écart avec le taux du jour est dérisoire face au gain en simplicité et en fiabilité ; c’est l’approche que retiennent la plupart des vendeurs de produits numériques à prix fixe.

Le prix affiché n’est pas toujours le prix facturé — la mention à ne pas oublier

Point de vigilance : si votre paiement — par exemple un Payment Link Stripe configuré en euros — ne facture que dans une seule devise, le prix localisé que vous affichez n’est jamais le montant réellement débité, c’est une conversion indicative. Il faut le dire clairement, avec une formule du type « soit environ 99 $ » plutôt qu’un prix ferme, et rappeler que la carte du visiteur appliquera le taux du jour de sa banque, pas celui affiché sur la page. Omettre cette nuance n’est pas qu’une question d’honnêteté : un prix affiché comme ferme puis débité différemment au moment du paiement alimente les demandes de remboursement et la méfiance — l’inverse de l’effet recherché, et le même ressort que les dark patterns décrits dans notre article dédié.

Multi-devise complet ou simple conversion indicative : lequel choisir

Un vrai encaissement multi-devise — plusieurs Payment Links Stripe, un par devise, ou Stripe Adaptive Pricing qui ajuste automatiquement le montant au moment du paiement — a du sens pour un SaaS avec des clients récurrents dans plusieurs zones, où le coût d’implémentation se rentabilise sur la durée de vie du client. Pour un produit à prix fixe et achat unique — un ebook, une formation, un template comme ceux de LanderKit — l’effort est rarement justifié : un prix de référence dans une devise, complété d’une conversion indicative pour les autres, suffit à lever le principal frein sans complexifier ni la comptabilité ni le support client.

Ce que ça change concrètement sur votre page dès aujourd’hui

Avant d’investir dans un vrai multi-devise, commencez par le geste le moins coûteux : afficher, sous le prix principal, une conversion indicative dans la devise probable du visiteur, calculée côté client avec Intl.NumberFormat et un taux arrondi mis à jour à la main. Les dix templates LanderKit (89 € l’unité, 229 € le pack) sont livrés en code Next.js autonome : le bloc prix de chaque template — voir par exemple SaaS Waitlist (démo) — est un composant isolé, simple à brancher sur une détection de devise sans toucher au reste de la page.