Montants et automatisations : éviter les erreurs de centimes

Un devis affiche le bon prix, mais l’export comporte un centime d’écart. Une liaison entre deux logiciels transmet « 1250 » sans préciser s’il s’agit d’euros ou de centimes. Ces situations illustratives révèlent un problème de conception : chaque outil peut interpréter différemment un montant pourtant lisible à l’écran.

Avant de relier catalogue, formulaire et logiciel de gestion, définissez comment les montants circulent et à quel moment ils sont arrondis. Cette méthode concerne la fiabilité technique des échanges ; les règles comptables et fiscales applicables restent à faire valider par votre professionnel compétent.

Donner une unité et un sens à chaque montant

Pour chaque champ, écrivez ce qu’il représente : prix unitaire, total de ligne, remise, montant hors taxes ou toutes taxes comprises. Ajoutez la devise, l’unité transmise et la précision autorisée. Un champ nommé seulement « prix » laisse trop de décisions à l’intégrateur.

Prenons un exemple fictif : un article à 12,50 EUR. Si le logiciel destinataire attend des centimes, la valeur transmise sera 1250 avec la devise EUR. S’il attend une valeur décimale en euros, son contrat d’interface peut demander « 12.50 ». Le choix dépend de cette interface, pas de la présentation française utilisée sur le site.

Stripe documente par exemple des montants d’API exprimés dans l’unité mineure de la devise. Son guide distingue les devises à deux décimales, celles sans décimales et des cas particuliers. Une règle « toujours multiplier par cent » ne convient donc pas à toutes ses opérations et devises. Documentation Stripe sur les devises et les montants.

Demandez une fiche de correspondance pour chaque connexion : champ source, unité source, champ cible, unité cible et conversion attendue. Une conversion doit avoir un emplacement identifié pour éviter de l’appliquer deux fois.

Choisir une représentation adaptée aux calculs

Les nombres utilisés par un programme ne se comportent pas toujours comme les nombres écrits sur une facture. MDN montre qu’en JavaScript, l’addition de 0.1 et 0.2 produit une valeur légèrement différente de 0.3 avec le type Number. Certains nombres décimaux ne sont pas représentables exactement dans ce format binaire. Explication MDN sur la précision numérique.

Cela ne signifie pas que tout calcul produit un écart visible. En revanche, une égalité stricte ou un arrondi au mauvais endroit peut donner un résultat inattendu. Évitez de corriger un écart en ajoutant systématiquement une petite constante : la même documentation explique que la tolérance dépend notamment de la taille des nombres.

Deux approches peuvent être étudiées avec le développeur : des entiers dans une unité fixée lorsque le calcul le permet, ou une représentation décimale adaptée à la précision nécessaire. Les quantités fractionnaires et les pourcentages demandent malgré tout une règle d’arrondi explicite.

PostgreSQL recommande notamment son type numeric pour les montants et les calculs exigeant de l’exactitude. Une colonne configurée avec un nombre limité de décimales arrondit toutefois les valeurs qui dépassent cette limite. Le stockage peut donc devenir lui-même une étape d’arrondi. Documentation PostgreSQL sur les types numériques.

Décider où l’arrondi intervient

Écrivez la séquence de calcul avant de regarder le total final. Arrondit-on un prix unitaire, chaque ligne ou seulement le total ? Une remise intervient-elle avant ou après une autre opération ? Quel mode d’arrondi doit être utilisé pour les cas à mi-chemin ?

Un exemple purement mathématique montre pourquoi l’ordre compte. Avec une règle d’arrondi au centime qui monte à partir du demi-centime, trois valeurs de 0,335 donnent chacune 0,34, soit 1,02 après addition. Leur somme avant arrondi vaut 1,005, qui donne 1,01 avec cette même règle. Cet exemple ne prescrit aucune méthode de facturation : il sert à demander laquelle votre système doit appliquer.

Faites produire quelques résultats de référence validés par la personne responsable des règles métier. L’intégrateur doit pouvoir expliquer chaque transformation. Un ajustement silencieux du total pour « faire tomber juste » masque le désaccord entre les étapes.

Séparer la valeur échangée de son affichage

Le texte « 1 250,50 € » est pratique à lire. Pour un échange entre applications, conservez une valeur structurée et sa devise, selon le format attendu par le destinataire. Évitez de recalculer un montant en retirant au hasard les espaces et symboles d’un texte déjà mis en forme.

Intl.NumberFormat permet en JavaScript de formater un nombre selon une langue et des options, notamment une devise. Ses exemples montrent que les séparateurs et le nombre de décimales affichées varient. Cette fonction sert à la présentation ; la règle de calcul doit être définie séparément. Documentation MDN sur Intl.NumberFormat.

Pour une saisie humaine, précisez les formats acceptés et affichez clairement la valeur comprise avant validation. Un champ vide doit rester distinct d’un montant nul. Si une IA extrait un prix d’un document, faites contrôler l’unité, la devise et le sens du champ par des règles déterministes ; une ambiguïté doit rester à vérifier.

Tester le parcours complet avec des valeurs fictives

Préparez un petit jeu de tests avant tout envoi réel ou déclenchement de paiement. Il peut comprendre :

• un prix simple en euros, vérifié dans le formulaire, l’échange technique et le logiciel destinataire ;
• une quantité fractionnaire et une remise qui produisent des décimales intermédiaires ;
• le cas d’arrondi retenu comme référence, avec résultat attendu à chaque étape ;
• une devise différente, uniquement si elle fait partie du périmètre du projet ;
• une valeur nulle, une valeur absente et une valeur négative, chacune acceptée ou refusée selon une règle explicite ;
• une saisie avec virgule et une autre avec point, afin de vérifier l’interprétation prévue.

Comparez les valeurs réellement enregistrées, pas seulement les captures d’écran. Un affichage arrondi peut cacher une différence dans les données envoyées. Rejouez aussi un export et son éventuel réimport pour vérifier que le format ne change pas le montant.

Le livrable à conserver tient en trois éléments : la définition des champs, les règles de conversion et d’arrondi, puis les exemples validés avec leurs résultats. Ce dossier permet de tester une nouvelle intégration ou une mise à jour sans redécouvrir à chaque fois l’origine d’un centime d’écart.