Pricing multidevise : gérer EUR, USD et RMB sans erreur

Chez un distributeur de câbles que nous avons suivi, les achats et les ventes se font en euros, en dollars et en yuans (RMB), entre l'Europe et l'Asie, sur plus de 3 000 références. Avant le projet, chaque variation du taux de change imposait une mise à jour manuelle des fichiers Excel, en plus de celles liées au cours du cuivre. Voici ce qu'on a appris en sortant ce pricing du tableur. La plateforme est visible dans la démonstration en vidéo.

Pourquoi le multidevise complique autant le pricing ?

Parce qu'un même prix de vente peut traverser trois devises. Le fournisseur facture dans la sienne, le transport est coté dans une autre, et le client attend son offre dans une troisième. Chaque passage est une conversion, avec son taux, sa date et son arrondi.

Dans un tableur, ces conversions finissent dispersées : un taux dans une cellule d'une feuille, un autre recopié en dur dans une formule, un troisième mis à jour le mois dernier par quelqu'un qui a oublié le reste. Le résultat n'est pas forcément faux. Le problème, c'est que personne ne peut dire avec certitude s'il est juste.

Devise d'achat, devise de vente : à quelle étape convertir ?

Notre règle est simple : gardez chaque coût dans sa devise d'origine aussi longtemps que possible, et convertissez une seule fois, à une étape définie, avec un taux daté.

Convertir tôt fait perdre de l'information. Si le prix fournisseur est converti en euros dès l'import, vous ne savez plus quelle part du prix final dépend du dollar, et vous ne pouvez plus mesurer l'effet d'une variation du taux.

Chez notre client, les paramètres de marché d'une simulation incluent le cours du cuivre et les taux de change. Dans la démonstration, le cuivre est saisi en yuans et un coût de transport en dollars. Le moteur enchaîne ensuite ses modules (cuivre, devise, transport, douane, marge), et la devise de l'offre se choisit à la toute fin : euros, dollars ou yuans. Chaque étape de conversion est consultable dans le détail du calcul, ligne par ligne.

Quel taux de change utiliser ?

Il n'y a pas de bonne réponse universelle, mais il y a une mauvaise : ne pas en choisir. Les options courantes :

• un taux de référence publié, comme les taux de référence de l'euro que la Banque centrale européenne publie chaque jour ouvré ;
• le taux pratiqué par votre banque, plus proche de ce que vous paierez réellement ;
• un taux fixé en interne pour une période, revu à date régulière ;
• le taux d'une couverture à terme, si vous en avez négocié une.

Un détail propre aux ventes vers la Chine : RMB désigne la monnaie, CNY est son code ISO pour le marché intérieur, et le yuan traité hors de Chine continentale est coté sous le code CNH, avec un cours légèrement différent. Précisez lequel vous utilisez, surtout si vos fournisseurs et vos banques ne parlent pas du même.

Certaines entreprises ajoutent un coefficient de sécurité au taux. C'est défendable, à condition qu'il soit un paramètre visible et nommé, pas un arrondi discret caché dans une formule.

Comment limiter le risque de change sur une offre ?

Le risque naît de l'écart de temps. Vous calculez un prix aujourd'hui, le client commande dans deux semaines, vous payez le fournisseur plus tard encore. Entre ces dates, le taux bouge.

Plusieurs réponses se combinent :

1. Une date d'expiration sur chaque offre. Plus vos coûts sont volatils, plus elle doit être courte. Chez notre client, elle se fixe au moment de générer l'offre.
2. Une clause de révision de prix au-delà d'une variation de taux convenue.
3. Une facturation dans la devise d'achat, qui reporte le risque sur le client quand le rapport de force le permet.
4. Une couverture à terme avec votre banque. C'est une décision de trésorerie, à prendre avec elle, pas dans le fichier de pricing.

Encore faut-il connaître son exposition. Chez notre client, on duplique une simulation, on modifie le taux de change, on recalcule, puis on compare les deux versions ligne par ligne, avec les plus gros écarts mis en avant. On voit tout de suite quelles références sont les plus sensibles au dollar ou au yuan. Le même mécanisme sert pour le transport, comme on l'explique dans l'article sur la comparaison des scénarios de transport.

Arrondis : là où se cachent les petites erreurs

Les arrondis paraissent anodins. Sur une chaîne de calcul à plusieurs étapes et plusieurs milliers de références, ils ne le sont pas.

• Gardez la précision complète dans les étapes intermédiaires et n'arrondissez qu'au prix final.
• Décidez si vous arrondissez le prix unitaire ou le total de ligne, et tenez-vous-y.
• Fixez une règle par devise de sortie. Un arrondi commercial qui a du sens en euros peut sembler arbitraire en yuans.
• Écrivez ces règles. Un arrondi que seule une personne connaît est une règle de prix non documentée comme une autre.

À quelle fréquence mettre à jour les taux ?

Cela dépend de la volatilité de vos devises et de la durée de validité de vos offres. Si vos offres sont valables quelques jours, un taux révisé chaque mois n'a pas de sens.

La vraie question est ailleurs : combien coûte une mise à jour ? Dans un tableur, elle coûte du temps et un risque d'oubli, donc on la repousse. Dans un moteur de calcul, le taux est un paramètre de marché : on le change et on relance le calcul, qui s'exécute en quelques secondes. Quand la mise à jour ne coûte presque rien, on la fait aussi souvent que nécessaire. Pour les références indexées sur une matière première, la même logique s'applique au cours du métal, détaillée dans l'article sur le prix indexé sur le cuivre.

Les questions à trancher avant d'automatiser

Avant de confier votre pricing multidevise à un outil, qu'il soit du marché ou construit pour vous, répondez par écrit à ces questions :

• Quelle est la devise de chaque coût : prix fournisseur, transport, douane ?
• À quelle étape convertissez-vous, et avec quel taux ?
• Qui met à jour les taux, à quelle fréquence, et où est conservé l'historique ?
• Quelle est la règle d'arrondi pour chaque devise de sortie ?
• Quelle durée de validité pour une offre, selon la devise ?

Chez notre client, ces réponses étaient dans la tête d'une seule personne. Les écrire a pris du temps pendant le cadrage, et c'est ce qui a rendu le moteur fiable. Le projet complet est décrit dans l'article sur l'automatisation du pricing, et nos applications métier partent toujours de ce travail d'écriture.

Commencez par la première question. Prenez une référence vendue à l'export et retracez sur papier chaque devise traversée, de la facture fournisseur à l'offre client. Si vous n'arrivez pas à dire à quel taux et à quelle date chaque conversion a été faite, c'est par là qu'il faut commencer.