Multi-currency et vente internationale sur PrestaShop : guide pratique de configuration

Voici l'erreur que la plupart des marchands font avec l'international sur PrestaShop : ils pensent que le "multi-currency" consiste à afficher un autre chiffre avec un autre symbole. Ce n'est pas le cas. Une devise dans PrestaShop est un petit objet avec son propre taux de change, son propre comportement d'arrondi, son propre placement du symbole et, si vous le souhaitez, ses propres prix fixés volontairement, sans rapport avec le taux de change en direct. Maîtrisez cette mécanique et un client allemand voit un prix net de 49,00 €, tandis qu'un client britannique voit un prix propre de £42.00, tous deux facturés correctement, tous deux en confiance. Ratez-la et vous affichez des prix comme £41.73 qui crient "conversion automatique" et vous coûtent discrètement la vente. Ce guide porte précisément sur la couche devise, celle qui fait réussir ou échouer la vente internationale dans International → Localisation.

Le sujet est volontairement limité. Les taxes, la VAT et l'ensemble du sujet "vendre en Europe" ont leur propre guide (vendre en Europe : langues, devises et taxes) ; traduire votre catalogue relève d'une configuration multilingue ; et le petit sélecteur avec drapeaux qui permet aux clients de changer de langue ou de devise est un détail front-office à part entière. Ici, nous restons sur l'argent.

Ce qu'est réellement une "devise" dans PrestaShop

Chaque devise que vous ajoutez est une ligne dans la table currency, chargée comme objet Currency (classe Currency dans classes/Currency.php). Les champs qui comptent au quotidien sont le code ISO (EUR, GBP, USD — il pilote le symbole et se connecte au formatage CLDR de PrestaShop), le taux de conversion par rapport à votre devise par défaut, ainsi que les paramètres de précision et d'arrondi. Votre devise par défaut a toujours un taux de conversion exactement égal à 1 ; toutes les autres devises sont exprimées comme un multiplicateur de celle-ci. Donc si votre devise par défaut est l'EUR et que vous ajoutez la GBP avec un taux de 0,85, PrestaShop prend le prix en EUR et le multiplie par 0,85 pour afficher les livres sterling.

Cette seule phrase est la source de la plupart des confusions en multi-currency, donc autant être direct : les prix dans PrestaShop sont stockés une seule fois, dans la devise par défaut, puis convertis à la volée pour toutes les autres. Un produit affiché à 100 dans votre back office signifie "100 dans votre devise par défaut". Si vous changez la devise par défaut après avoir saisi vos prix, vous n'avez rien recalculé : vous avez simplement réétiqueté tous les chiffres de votre catalogue. C'est l'erreur la plus coûteuse que nous voyons : choisissez votre devise par défaut avant de saisir le moindre prix produit, et ne la changez jamais sur une boutique en production avec des commandes.

Ajouter une devise correctement

Allez dans International → Localisation → Devises et cliquez sur Ajouter une nouvelle devise. Depuis PrestaShop 1.7.6, le formulaire s'appuie sur les données locales CLDR : choisir le code ISO remplit automatiquement le symbole, la précision décimale et le modèle de formatage. Vous avez rarement besoin de modifier manuellement l'affichage du nombre. Les champs que vous décidez réellement sont :

• Devise — le code ISO 4217. C'est la clé principale ; il définit le symbole (€, £, $) et le modèle de format. Utilisez le vrai code, pas un libellé personnalisé, sinon le formatage CLDR et les passerelles de paiement qui lisent la devise risquent de mal se comporter.
• Taux de change — le multiplicateur par rapport à votre devise par défaut. Saisissez-le comme "combien d'unités de cette devise valent une unité de ma devise par défaut". C'est le champ que les gens inversent ; si votre produit à €100 s'affiche à £117 au lieu de £85, votre taux est à l'envers.
• État — activer/désactiver. Désactivez une devise plutôt que de la supprimer dès que des commandes existent, afin que les commandes historiques gardent leur contexte de devise.

Les décimales et l'arrondi ont quitté l'écran par devise dans les versions récentes : CLDR fournit les données de formatage et de symbole par défaut, même si vous devez toujours vérifier la précision et les paramètres décimaux dans la configuration des devises. Le mode d'arrondi se règle globalement dans Paramètres de la boutique → Général → Définir le mode d'arrondi des prix (valeurs de configuration PS_PRICE_ROUND_MODE et PS_ROUND_TYPE). C'est plus important qu'il n'y paraît, comme le montre la section suivante.

L'arrondi : le réglage discret qui protège vos marges et votre comptabilité

Le mode d'arrondi de PrestaShop décide si 49.005 devient 49.00 ou 49.01 — et à grande échelle, sur des milliers de lignes converties, la différence représente de l'argent réel et, pire, des totaux incohérents qui perturbent comptables et clients. Deux réglages interagissent :

• Mode d'arrondi (Paramètres de la boutique → Général) : PrestaShop propose six modes — "Arrondir au supérieur en s'éloignant de zéro" (arrondi commercial, par défaut), "Arrondir à l'inférieur vers zéro", "Arrondir à la valeur paire la plus proche" et "Arrondir à la valeur impaire la plus proche" (variantes de l'arrondi bancaire), plus "Arrondir à la valeur supérieure la plus proche" et "Arrondir à la valeur inférieure la plus proche". Pour une boutique, l'arrondi commercial par défaut est le choix prévisible : c'est ce que les clients et les administrations fiscales attendent.
• Type d'arrondi : arrondir sur chaque article, sur chaque ligne ou sur le total. Arrondir par ligne puis additionner peut produire un panier décalé d'un centime par rapport à ce que le client additionne à la main. Arrondir sur le total évite l'e-mail "votre calcul est faux", mais peut rendre certains prix de ligne légèrement incohérents. Choisissez une méthode, documentez-la, et ne la changez plus une fois des factures émises.

Et alors ? Réglez cela correctement une fois et les prix convertis semblent intentionnels, tandis que vos factures se réconcilient. Réglez-le mal et chaque commande dans une devise convertie devient une petite dispute d'arrondi en attente — multipliée par toutes les commandes dans cette devise.

Garder les taux de change à jour sans les surveiller à la main

Un taux de change figé est une fuite lente. Mettez la GBP à 0,85 en janvier, laissez-la ainsi, et au printemps vous facturez trop peu ou vous effrayez les visiteurs avec un prix qui ne correspond plus à la réalité. PrestaShop inclut un outil de mise à jour. Sur la page Devises, l'action Mettre à jour les taux de change récupère des taux récents (flux devise PrestaShop / source intégrée) et réécrit en un clic le taux de conversion de chaque devise non par défaut.

Cliquer sur un bouton à la main n'est pas de l'automatisation. Branchez-le au planificateur pour qu'il tourne seul. PrestaShop fournit un script dédié cron_currency_rates.php dans votre dossier admin, et la page Devises expose son URL prête à l'emploi (avec une secure_key) dans le panneau "Mettre automatiquement à jour les taux de change" ; vous pointez votre crontab serveur vers cette URL, par exemple chaque matin :

• Planifiez-le avant le trafic du jour — une exécution tôt le matin (par exemple 06:00 heure serveur) garantit des prix frais avant l'arrivée des premiers clients européens, et laisse plusieurs heures pour remarquer un mauvais import avant le pic.
• Considérez le flux comme faillible. Des indisponibilités API peuvent parfois renvoyer un zéro ou un taux absurde, et un mauvais taux corrompt discrètement chaque prix dans cette devise. Ajoutez un contrôle de cohérence — même un coup d'œil chaque matin, ou une garde qui refuse d'appliquer un taux ayant bougé de plus de 10% pendant la nuit — avant de lui faire confiance sans surveillance.
• Prévoyez une marge tampon. Les taux interbancaires en direct n'incluent pas le spread que votre processeur de paiement prélève au règlement. Si vous convertissez au taux brut, la part du processeur mange votre marge sur chaque commande étrangère. Beaucoup de marchands appliquent un petit supplément après mise à jour automatique, ou fixent manuellement les prix des devises clés (section suivante) pour éviter cela.

Prix manuels par devise : quand arrêter de convertir

Voici la fonctionnalité que beaucoup de marchands ne découvrent jamais, alors que c'est le levier le plus fort pour avoir l'air local plutôt que touriste. PrestaShop vous permet de remplacer le prix converti par devise sur un produit, dans l'onglet Prix du produit via Prix spécifiques. Au lieu de laisser le moteur sortir £41.73 depuis une base à €49, vous fixez explicitement le prix GBP à £42.00 — un nombre propre, psychologiquement solide — uniquement pour cette devise.

Pourquoi cela compte en termes business simples :

• Le charm pricing survit à la frontière. Un produit à €49,00 converti automatiquement en £41.73 annule toute la psychologie de prix travaillée sur votre marché d'origine. Un prix spécifique restaure le £42.00 (ou £39.99) qui convertit réellement.
• Vous arrêtez de courir après le taux de change. Un prix local fixe ne bouge pas à chaque passage du moteur de mise à jour. Votre boutique UK a simplement des prix UK.
• Vous fixez le prix selon le marché, pas selon les maths. Si les acheteurs britanniques acceptent un nombre plus élevé ou si vous avez des coûts de livraison supplémentaires vers cette région, vous le décidez volontairement au lieu d'accepter le résultat du multiplicateur.

Le compromis est clair : les prix spécifiques sont par produit, donc fixer à la main mille références dans cinq devises n'est pas réaliste sans import ou outil de pricing. Le schéma pragmatique est le même que pour la traduction : faites-le pour vos meilleures ventes. Fixez des prix locaux intentionnels sur les 20% de produits qui génèrent l'essentiel du chiffre d'affaires, et laissez une conversion automatique propre gérer la longue traîne.

Ce que voit le client — et comment la facturation se passe vraiment

Quand un client change de devise (via le sélecteur front-office, traité dans sélecteur de devise et drapeaux de langue), PrestaShop enregistre son choix dans le panier et recalcule les prix affichés par le même chemin de conversion. Point crucial : la commande est enregistrée dans la devise utilisée par le client au checkout — l'id_currency est sauvegardé sur le panier et la commande, et la facture est générée dans cette devise. Votre liste de commandes back-office et votre comptabilité voient donc "ce client a payé £42.00", pas un montant EUR avec astérisque.

Gardez en tête la réalité du règlement : c'est votre passerelle de paiement, pas PrestaShop, qui décide ce qui arrive sur votre compte bancaire. Stripe, PayPal, Mollie et les autres ont chacun leurs règles de règlement multi-currency et de conversion : certains règlent chaque devise nativement, d'autres reconvertissent tout dans la devise de votre compte et prennent un spread au passage. PrestaShop facture au client le bon montant local ; ce que votre processeur en fait avant votre compte est une question séparée à vérifier sur votre passerelle avant de lancer une nouvelle devise.

Géolocalisation : présélectionner la bonne devise, avec prudence

Vous pouvez faire deviner à PrestaShop la devise d'un visiteur à partir de sa localisation, afin qu'un visiteur britannique arrive directement en livres sans cliquer. Cela se règle dans International → Localisation → Géolocalisation et s'appuie sur la base MaxMind GeoLite2, que vous téléchargez chez MaxMind puis chargez dans PrestaShop (l'ancienne GeoLite intégrée a été arrêtée, donc une boutique actuelle a besoin du fichier GeoLite2). Une fois activée, vous pouvez définir par défaut la devise et le pays correspondant aux visiteurs d'un pays donné.

Deux prudences, parce que la géolocalisation inspire trop facilement confiance :

• Ne verrouillez jamais le choix. La géolocalisation doit présélectionner, jamais forcer. Un expatrié, un voyageur ou une personne sous VPN sera mal détecté ; s'il ne peut pas revenir à la devise dans laquelle il pense, il part. Gardez toujours le sélecteur de devise visible.
• Gardez la base GeoLite2 fraîche. Les correspondances IP-pays changent ; une base obsolète oriente mal une part croissante de visiteurs avec le temps. Rafraîchissez-la selon un planning, comme vos taux de change.

Une devise par défaut, ou une boutique par marché ?

Une seule boutique PrestaShop peut servir plusieurs devises à la fois : c'est tout ce qui précède. Mais il existe un moment où "plusieurs devises sur une boutique" ne suffit plus : quand chaque marché a besoin non seulement d'une devise différente, mais d'une devise par défaut différente, de prix saisis nativement plutôt que convertis, d'un domaine différent ou d'un catalogue différent. C'est là que Multiboutique entre en jeu, par exemple avec une boutique zone euro en EUR et une boutique UK en GBP depuis le même back office, chacune avec sa devise par défaut et sa base de prix. C'est une décision d'architecture plus lourde, détaillée dans gérer plusieurs boutiques depuis un seul panneau d'administration.

Un moyen rapide de savoir de quel côté vous êtes :

Ordre de lancement pratique pour une nouvelle devise

En résumé, voici la séquence qui évite les erreurs coûteuses :

• Confirmez que votre devise par défaut est correcte et définitive avant tout le reste — c'est la base de chaque conversion et la seule chose que vous ne devez pas changer ensuite.
• Ajoutez la nouvelle devise avec son vrai code ISO pour que le formatage CLDR et les passerelles se comportent correctement.
• Réglez le taux de change dans le bon sens et vérifiez mentalement le prix converti d'un produit avant d'aller plus loin.
• Fixez votre mode et votre type d'arrondi dans Paramètres de la boutique, puis n'y touchez plus une fois des commandes existantes.
• Automatisez la mise à jour des taux avec un cron quotidien et une garde contre les taux zéro ou absurdes.
• Définissez des Prix spécifiques intentionnels sur vos meilleures ventes dans la nouvelle devise, afin que les montants paraissent locaux et non auto-convertis.
• Vérifiez le règlement avec votre passerelle de paiement pour cette devise, puis passez une vraie commande de test et lisez la facture.

La couverture des moyens de paiement compte autant que le prix : un client allemand qui attend une facture ou un client néerlandais qui attend iDEAL abandonnera un checkout uniquement par carte, même si vos prix en euros sont parfaitement propres. C'est une décision de stack paiement plutôt qu'une décision de devise, et le tableau régional plus large est traité dans vendre en Europe.

Le multi-currency sur PrestaShop récompense les marchands qui le traitent comme une discipline de pricing, pas comme un interrupteur d'affichage. La plateforme convertira volontiers tout pour vous en pilote automatique — et "tout en pilote automatique" est précisément ce qui produit des prix à £41.73 et des surprises de flux de taux. Décidez votre devise par défaut une fois pour toutes, automatisez vos taux avec une garde, et fixez à la main les prix de vos produits essentiels sur chaque marché. Faites cela et chaque nouvelle devise que vous ouvrez devient un marché qui voit des prix pensés pour lui — ce qui est tout l'intérêt de vendre à l'étranger.