Pourquoi les logiciels échouent à l'international : sept erreurs récurrentes

De nombreux échecs d’internationalisation surviennent lorsqu’un logiciel, conçu pour une seule langue ou région, est adapté a posteriori à d’autres marchés sans avoir anticipé les besoins de localisation. La traduction, elle, se greffe sans difficulté. En revanche, le code sous-jacent présuppose souvent l’ordre des mots de la langue source, un format de date unique, un alphabet exclusivement latin et une seule devise : le produit finit alors par dysfonctionner d’une manière qu’aucun traducteur ne pourra corriger.

Nous résumons ce mécanisme dans le développement de logiciels multilingues : la plupart des échecs proviennent d’une adaptation tardive, d’une ingénierie pensée pour un marché puis ajustée pour d’autres. Sept erreurs reviennent le plus souvent quand nous auditons une base de code existante.

1. Des chaînes de caractères codées en dur

Ce à quoi cela ressemble. Un bouton affiche « Submit » parce qu’un développeur a saisi <button>Submit</button> directement dans un template. Un e-mail de confirmation contient « Your order # » + orderId + « has shipped » enfoui dans une fonction Node. Aucune liste centralisée des textes de l’application n’existe. Pour ajouter l’allemand, il faut ouvrir chaque fichier, repérer chaque chaîne et espérer ne rien avoir oublié.

On ne les recense jamais toutes : les audits révèlent régulièrement de l’anglais résiduel dans les notifications d’erreur, les e-mails d’administration, les pieds de page PDF ou les notifications push, ces recoins que personne ne songe à vérifier car ils ne figurent pas sur l’écran principal. Chacun passe en production comme un petit bug agaçant dans un produit par ailleurs traduit.

La solution. Chaque texte visible par l’utilisateur est stocké dans un fichier de ressources sous une clé stable (checkout.confirm_button, et non la chaîne elle-même), dès le premier commit. Les développeurs référencent la clé ; les traducteurs travaillent sur le fichier de ressources. La pseudo-localisation en intégration continue (remplacer chaque chaîne par un texte factice allongé et accentué, puis naviguer dans le build) permet de repérer les éléments restés en dur avant la mise en production, et non après une réclamation client.

2. Des interfaces conçues pour la longueur de l’anglais

Ce à quoi cela ressemble. Un bouton accueille « Save » avec une marge confortable. En allemand, le libellé « Speichern » compte cinq lettres de plus et passe à la ligne ou se retrouve tronqué par des points de suspension. Un panneau de paramètres, dessiné autour de libellés anglais courts, devient illisible une fois tous les textes traduits. Le finnois pose un autre problème : ses mots composés, comme ceux de l’allemand, soudent ce que l’anglais sépare. « Shipping Address » devient un seul mot, « Toimitusosoite », impossible à couper sur une espace dans un champ étroit.

L’ampleur du problème n’a rien d’anecdotique. Les traductions peuvent être bien plus longues que l’anglais : le W3C recommande de concevoir des interfaces flexibles, car pour des chaînes anglaises de moins de 10 caractères, il évoque une expansion pouvant atteindre 200 à 300 % (W3C, La taille des textes dans les traductions). Un bouton dimensionné pour l’anglais n’a aucune marge pour absorber cela.

La solution. Les interfaces utilisent des conteneurs flexibles plutôt que des largeurs fixes, et boutons, libellés et menus de navigation sont testés avec du texte pseudo-localisé ou réellement traduit avant le lancement, et non évalués à l’œil nu en anglais en supposant que « ça passera ». Nous détaillons l’architecture sous-jacente dans l’i18n expliquée aux non-ingénieurs.

3. Des phrases reconstituées à partir de fragments

Ce à quoi cela ressemble. Un développeur écrit « Delete » + itemType + « ? » pour économiser une chaîne de traduction, ce qui donne « Delete file? » en anglais. Le même code produit un charabia grammatical en allemand, où l’ordre des mots et le genre du nom varient selon itemType, et une phrase incompréhensible en japonais, dont la structure ne se prête pas du tout à un gabarit anglais.

Cette erreur reste invisible dans la langue source et saute aux yeux dans toutes les autres. Elle survit plus longtemps que la plupart des bugs, car personne ne la remarque en testant uniquement en anglais.

La solution. Des phrases complètes, et non des fragments, sont intégrées au fichier de ressources, avec des variables pour les éléments dynamiques : « Delete {itemType}? » comme unité traduisible unique. Les traducteurs voient et traduisent la phrase entière, dans l’ordre des mots propre à leur langue. Le format ICU étend cette logique aux pluriels et au genre, là où les règles simples de l’anglais masquent une complexité que les autres langues ne partagent pas. L’internationalisation implique d’éviter la concaténation de chaînes et de séparer les éléments localisables du code source, afin que chaque langue puisse appliquer son propre ordre des mots (W3C).

4. Des formats de date et de nombre supposés universels

Ce à quoi cela ressemble. Une confirmation d’expédition affiche « 04/07/2026 ». Aux États-Unis, cela correspond au 7 avril. Dans la plupart des autres pays, dont celui du client, c’est le 4 juillet. Aucun message d’erreur n’apparaît. Le client se présente simplement une saison trop tôt, ou un rapport est classé à la mauvaise date, sans que personne ne s’en aperçoive.

Les nombres posent le même piège, mais à l’envers. « 1.500 » se lit un virgule cinq aux États-Unis et mille cinq cents en Allemagne, où le point sert de séparateur de milliers, et non de virgule décimale. Une routine d’import qui interprète des nombres étrangers avec les règles américaines ne plante pas : elle corrompt des données financières et continue de s’exécuter.

La solution. Les dates et les nombres sont affichés à partir des données de locale (le Common Locale Data Repository, et non une table de formats maison), et les mêmes règles s’appliquent à l’analyse des saisies utilisateur, et pas seulement à l’affichage. Un champ de date qui accepte une saisie au clavier doit rejeter ou reformater « 04/07/2026 » de manière cohérente avec son affichage, dans les deux sens. Le W3C recommande de prendre en charge les préférences locales, notamment pour les formats de date, d’heure et de chiffres, plutôt que de supposer un format universel (W3C).

5. Des erreurs de devise et d’arrondi

Ce à quoi cela ressemble. Un tunnel de paiement convertit les prix au taux du jour et les affiche avec deux décimales, pour toutes les devises, partout. Cela pose deux problèmes précis. D’abord, les prix fluctuent avec le taux de change au lieu de rester fixes comme le marché l’attend : un produit à 49,99 EUR hier coûte 51,23 EUR aujourd’hui sans raison apparente pour le client. Ensuite, l’hypothèse des deux décimales est erronée : le yen japonais n’en utilise aucune, tandis que le dinar bahreïni, le dinar koweïtien et le rial omanais en comptent trois. Un panier conçu pour deux décimales perd une précision nécessaire ou en invente une qui n’existe pas.

La solution. Les prix multidevises sont fixés par marché avec un arrondi maîtrisé, et non calculés en temps réel à partir d’un flux de taux de change au moment du paiement. Le formatage des devises et la gestion des sous-unités s’appuient sur les mêmes données de locale que les dates et les nombres : le JPY s’affiche sans décimale et le KWD avec trois, car le code interroge les données plutôt que de faire des suppositions. Les API de formatage sensibles à la locale produisent des résultats adaptés à chaque pays : MDN illustre par exemple « 123.456,79 € » pour l’allemand et précise que le yen japonais n’utilise pas d’unité mineure.

6. Des écritures de droite à gauche rendues illisibles

Ce à quoi cela ressemble. De l’arabe ou de l’hébreu s’affiche dans une interface jamais conçue pour une lecture de droite à gauche. Au lieu d’une mise en page en miroir, l’interface reste alignée à gauche tandis que le texte, lui, se lit de droite à gauche : la navigation, les icônes et les indicateurs de progression pointent dans le mauvais sens par rapport au sens de lecture. Pire encore, une phrase mêlant une expression arabe à un code latin ou à un numéro de téléphone peut voir ses segments s’afficher dans le désordre, créant un brouillage visuel qui rend le texte difficile à déchiffrer, et pas seulement inhabituel.

Les utilisateurs le remarquent en quelques secondes, et cela donne l’impression d’un logiciel défectueux plutôt que d’une traduction incomplète. C’est l’un des moyens les plus rapides de perdre toute crédibilité auprès d’un marché entier.

La solution. Les interfaces utilisent les propriétés CSS logiques (start et end, et non left et right) pour que le miroir soit automatique, et la gestion du texte bidirectionnel est testée avec une vraie locale RTL, et non présumée fonctionnelle parce qu’on ne l’a pas modifiée. Le détail est dans notre article sur le support RTL.

7. Des colonnes de base de données incapables de stocker les écritures non latines

Ce à quoi cela ressemble. Un client nommé « José » est enregistré, puis affiché, comme « José ». Une raison sociale japonaise sauvegardée en base ressort sous forme de points d’interrogation ou de carrés. Cela se produit quand une colonne de base de données, une API héritée ou un export de fichier utilise un encodage limité aux caractères latins : tout ce qui sort de cet ensemble est corrompu au moment de l’écriture, et non de l’affichage. Le problème survient au niveau du stockage, donc il reste invisible jusqu’à ce qu’on examine les données brutes, ou qu’un client se plaigne que son nom est mal orthographié sur sa facture.

La solution. Unicode, le standard qui attribue un point de code à chaque caractère de chaque système d’écriture, doit être l’encodage de chaque couche : colonne de base de données, contenu d’API, export de fichier, modèle d’e-mail. UTF-8, l’encodage Unicode le plus répandu, doit être utilisé de bout en bout, car un seul composant en encodage différent suffit à corrompre noms et adresses dans tout le système. Le W3C inclut d’ailleurs l’utilisation d’Unicode et la gestion des encodages parmi les objectifs de l’internationalisation (W3C).

La logique derrière ces sept erreurs

Chacune de ces erreurs semble mineure prise isolément : un bouton tronqué, une date erronée, un nom déformé. Ces défauts peuvent passer inaperçus lorsque les tests sont menés uniquement dans la langue d’origine du produit ; des essais avec plusieurs locales et systèmes d’écriture augmentent les chances de les détecter. C’est en partie pourquoi ils survivent jusqu’en production et sont découverts par des clients payants à l’étranger, plutôt que lors de la recette.

L’enjeu commercial est réel. Une enquête de CSA Research auprès de 8 709 consommateurs dans 29 pays révèle que 76 % privilégient les produits présentés dans leur langue, et que 40 % n’achèteront jamais sur des sites dans une autre langue (CSA Research). Un produit qui trébuche sur sa propre traduction perd cette confiance aussi vite qu’un produit jamais traduit.

Corriger ces sept erreurs après le lancement coûte souvent bien plus cher que de les éviter dès le départ. Le rattrapage peut exiger une refonte complexe et coûteuse, car l’internationalisation touche le code, l’affichage, les données et les formats. Chaque couche (chaînes, mise en page, formats, stockage) doit être identifiée et corrigée d’un seul tenant, tandis que le produit continue d’être livré. Ces sept points frappent particulièrement fort dans le développement e-commerce sur mesure, où paiement, prix et données produit cumulent toutes les erreurs de cette liste, et dans le logiciel logistique sur mesure, où documents douaniers, applications multilingues pour chauffeurs et formats de date et de devise transfrontaliers ne laissent aucune place à l’approximation.

Questions fréquentes sur les erreurs d’internationalisation

Concevez un logiciel qui ne trébuche pas sur sa propre traduction

Dites-nous quels marchés votre logiciel doit conquérir. Nous identifions lesquelles de ces sept erreurs vous concernent déjà, puis chiffrons à prix fixe leur correction et la mise en place d’un pipeline de traduction qui empêchera les nouvelles langues de les reproduire.

Demander un devis à prix fixe →