01.02 — c'est le 1er février ou le 2 janvier ? Les pièges de la localisation qui coûtent cher

La chaîne « 01.02.2025 » désigne le 1er février dans un pays et le 2 janvier dans un autre. Si une boutique en ligne ou une application affiche une telle date sans tenir compte de la locale, le client peut la lire autrement que prévu. Ces détails figurent rarement dans le cahier des charges, pourtant ils sont à l'origine de retours, de délais manqués et de messages de support embarrassants. Passons en revue les pièges les plus courants de la localisation et voyons comment les éviter.

Dates et heures : un même jour, trois lectures possibles

L'ordre des éléments d'une date dépend du pays. En Russie, en Allemagne et dans la majeure partie de l'Europe, on adopte le format « jour.mois.année ». Aux États-Unis, le mois vient en premier : « 03/04/2025 » y désigne donc le 4 mars, et non le 3 avril. Au Japon, en Chine et en Corée, l'ordre est inversé : on commence par l'année, puis le mois et le jour.

Il en va de même pour l'heure. En Russie, dans la majeure partie de l'Europe et en Amérique latine, le format sur 24 heures est la norme, alors qu'aux États-Unis, au Canada, en Australie et en Inde, le format sur 12 heures avec les mentions AM et PM est largement utilisé. Une indication « 5:00 » sans précision se lit différemment selon les pays : un rendez-vous fixé à « cinq heures » pourrait donc se retrouver décalé de douze heures.

Pour ne rien laisser au hasard, mieux vaut utiliser la norme ISO 8601 dans les données et les API (par exemple 2025-02-01T14:30). Dans l'interface, il faut afficher la date à l'aide des outils de la locale plutôt que de la saisir manuellement.

Séparateurs dans les nombres : la virgule là où il y a un point

Le nombre « 1 500,75 » en Russie et « 1,500.75 » aux États-Unis représentent la même valeur. En Allemagne et au Brésil, on sépare les milliers par un point et on écrit la partie décimale après une virgule : « 1.500,75 ». En Suisse, on utilise l'apostrophe : « 1'500.75 ». En Inde, le regroupement des chiffres est différent : « 1,00,000 » signifie cent mille.

L'erreur est ici particulièrement insidieuse. Si un prix « 1.500 » était censé valoir mille cinq cents, mais que le système l'a lu comme un peu plus d'une unité, l'acheteur ne s'en rendra compte qu'à la caisse. Dans le code, ne concaténez donc jamais les chaînes contenant des nombres à la main : utilisez le formatage selon la locale et vérifiez l'analyse des nombres lors de l'import de fichiers.

Devises : symbole, place et arrondi

Le symbole monétaire paraît anodin, mais il prête facilement à confusion. Le signe « $ » est utilisé aux États-Unis, au Canada, en Australie et dans plusieurs autres pays ; sans code de devise, « $ » peut donc désigner des dollars de n'importe lequel d'entre eux. C'est pourquoi, dans les contextes internationaux, on indique le code à trois lettres selon la norme ISO 4217 : USD, EUR, RUB.

La place du symbole varie également. Dans les pays anglophones, on écrit « $100 », en France « 100 € » avec une espace insécable, en Russie « 100 ₽ » ou « 100 руб. ». Parfois, l'erreur se manifeste au niveau de la traduction : une phrase comme « prix TVA comprise » demande une structure différente selon la langue, et si le texte est assemblé à partir de fragments dans lesquels le montant est inséré, l'ordre des mots se trouve désorganisé.

L'arrondi dépend lui aussi de la devise. Le yen japonais n'a généralement pas de décimales, tandis que le dinar koweïtien se divise en millièmes. Si le système calcule chaque montant avec deux décimales quelle que soit la devise, le total peut différer de quelques centimes par rapport au relevé bancaire, et de sommes bien plus importantes sur de gros volumes.

Système métrique et système impérial

La plus grande partie du monde utilise le système métrique, mais les États-Unis emploient les pieds, les livres, les gallons et les degrés Fahrenheit. Au Royaume-Uni, les panneaux routiers indiquent les distances en miles et le lait se vend en pintes, la pinte britannique étant plus grande que l'américaine : environ 568 millilitres contre à peu près 473. Le gallon diffère lui aussi de part et d'autre de l'Atlantique.

Pour une boutique en ligne, cela signifie que les dimensions du produit, le poids du colis et le volume de l'emballage doivent être affichés dans les unités familières à l'acheteur, tout en conservant la précision. Le traducteur qui travaille sur des notices doit déterminer s'il faut traduire l'unité ou convertir la valeur. Par exemple, si le mode d'emploi indique « 10 pouces », pour une édition française il est plus judicieux de donner « 25 cm », tout en conservant la valeur d'origine entre parenthèses si elle est importante pour les caractéristiques techniques.

Téléphones, adresses et noms dans les formulaires

Les formulaires d'inscription se cassent le plus souvent sur trois champs. Le téléphone : en Russie, on peut avoir « +7 (999) 123-45-67 », en Allemagne la longueur du numéro est variable, et de nombreux modèles au masque rigide ne l'acceptent pas. Mieux vaut un champ avec sélection de l'indicatif pays et une bibliothèque de validation des numéros.

L'adresse : au Japon, on indique du plus grand au plus petit (préfecture, ville, quartier, numéro de pâté de maisons), alors qu'en Russie et en Europe c'est l'inverse. Le code postal américain comporte cinq chiffres, tandis qu'au Royaume-Uni il s'agit d'une combinaison de lettres et de chiffres. Un champ « Code postal, chiffres uniquement » rejette une partie des adresses réelles.

Le nom et le prénom : en Espagne et en Amérique latine, on compte souvent deux noms de famille, en Islande on utilise le patronyme à la place du nom de famille, et certaines personnes n'ont qu'un seul nom. L'apostrophe dans « O'Brien » ou le trait d'union ne doivent pas provoquer d'erreur. L'exigence minimale est simple : ne rendez pas obligatoires deux champs là où ce n'est pas nécessaire, et acceptez tous les caractères Unicode.

Éviter les erreurs : normes et vérification

Le travail sur les formats ne commence pas au stade de la vérification, mais à celui de la conception. Voici ce qui aide :

Stockez les dates au format ISO 8601, les nombres sans mise en forme, les devises avec leur code ISO 4217, et confiez l'affichage à la locale.
Utilisez les bibliothèques de localisation standard plutôt que des modèles faits maison, par exemple ICU ou les outils intégrés à la plateforme.
Fournissez aux traducteurs le contexte : le texte doit permettre de comprendre les unités, la devise et le type de date, pas seulement les mots.
Testez l'interface avec des dates comme 01.02, 12:00 et 1 000,50 dans plusieurs locales, y compris celles où l'ordre diffère.
Faites relire la version finale par des locuteurs natifs. Ils repèrent plus vite que « cinq heures du soir » s'écrit « 17.00 » là où on ne dit pas ainsi.

La conclusion principale est simple : le format fait partie du sens. Une bonne traduction préserve non seulement les mots, mais aussi la façon dont le lecteur comprendra la date, le prix et la distance. Si la localisation est prévue dès le départ, ces pièges se contournent presque sans frais. Si on les découvre après la mise en production, la correction coûte plus cher que tout le reste.