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

Un logiciel échoue à l'international parce qu'il a été construit pour une langue et un marché, puis sommé d'en servir d'autres sans changer sa construction. La traduction s'insère très bien. En dessous, le code suppose toujours l'ordre des mots de sa langue d'origine, un seul format de date, un texte exclusivement latin et une devise unique : le produit casse donc d'une façon qu'aucun traducteur ne pourra jamais réparer.

Nous décrivons ce schéma dans les grandes lignes dans développement de logiciels multilingues : la plupart des échecs remontent à un retrofit, une ingénierie conçue pour un marché puis ajustée pour d'autres après coup. Passons au concret. Voici les sept erreurs que nous trouvons le plus souvent en auditant une base de code existante, à quoi chacune ressemble en production, et ce qui l'empêche réellement.

1. Des chaînes codées en dur dans le code

À quoi ça ressemble. Un bouton affiche "Submit" parce que quelqu'un a tapé <button>Submit</button> directement dans un template. Un e-mail de confirmation contient "Your order #" + orderId + " has shipped" au fond d'une fonction Node. Il n'existe nulle part de liste des textes de l'application. Pour ajouter l'allemand, il faut ouvrir chaque fichier, trouver chaque chaîne, et espérer les avoir toutes attrapées.

On ne les attrape jamais toutes. Les audits exhument régulièrement de l'anglais résiduel dans les toasts d'erreur, les e-mails d'administration, les pieds de page PDF et les notifications push, ces recoins que personne n'a pensé à vérifier parce qu'ils ne sont pas sur l'écran principal. Chacun part en production comme un petit bug gênant dans un produit par ailleurs traduit.

Ce qui l'empêche. Chaque chaîne visible par l'utilisateur vit dans un fichier de ressources sous une clé stable (checkout.confirm_button, pas la chaîne elle-même), dès le premier commit. Les développeurs référencent la clé ; les traducteurs travaillent le fichier de ressources. La pseudo-localisation en CI (remplacer chaque chaîne par un texte factice allongé et accentué, puis cliquer partout dans le build) attrape ce qui reste codé en dur avant la mise en production, pas après le signalement d'un client.

2. Des mises en page taillées pour la longueur de l'anglais

À quoi ça ressemble. Un bouton loge « Save » avec de la marge. Le libellé allemand est « Speichern », six lettres de plus, et il passe sur une deuxième ligne ou finit tronqué par des points de suspension. Un panneau de réglages dessiné autour de libellés anglais courts devient un mur de textes coupés une fois tous les libellés traduits. Le finnois aggrave le même problème : ses mots composés dépassent couramment 20 caractères là où l'anglais utilise deux mots courts, si bien qu'un libellé conçu pour « Shipping Address » peut entrer en collision avec « Toimitusosoite » dans le même champ à largeur fixe.

L'ampleur du problème n'est pas une erreur d'arrondi. Le texte d'interface allemand est en moyenne 30 à 35 % plus long que l'anglais, et les chaînes courtes de moins de 10 caractères peuvent s'allonger de 200 à 300 % (W3C). Un bouton dimensionné pour l'anglais n'a plus aucune marge pour cela.

Ce qui l'empêche. Les mises en page utilisent des conteneurs flexibles plutôt que des largeurs fixes, et boutons, libellés et navigation sont testés contre du texte pseudo-localisé ou réellement traduit avant le lancement, pas jaugés à l'œil en anglais en supposant que ça tiendra. Nous couvrons l'architecture plus large derrière cela dans l'i18n expliquée aux non-ingénieurs.

3. Des phrases assemblées à partir de fragments

À quoi ça ressemble. Un développeur écrit "Delete " + itemType + "?" pour économiser une chaîne de traduction, ce qui produit « Delete file? » en anglais. Le même code produit un charabia grammatical en allemand, où l'ordre des mots et le genre du nom changent selon la valeur d'itemType, et une sortie franchement illisible en japonais, dont la structure de phrase ne se colle pas du tout sur un gabarit anglais.

Cette erreur est invisible dans la langue source et flagrante dans toutes les autres. Elle survit plus longtemps que la plupart des bugs, parce que personne ne la voit jamais en testant en anglais.

Ce qui l'empêche. Des phrases complètes, pas des fragments, entrent dans le fichier de ressources, avec des variables pour la partie mobile : "Delete {itemType}?" comme unité traduisible unique. Les traducteurs voient et traduisent la phrase entière, dans l'ordre des mots que leur langue utilise vraiment. Le format de messages ICU étend cela aux pluriels et au genre, là où les règles simples de l'anglais masquent une complexité que les autres langues ne partagent pas.

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

À quoi ça ressemble. Une confirmation d'expédition affiche « 04/07/2026 ». Aux États-Unis, c'est le 7 avril. Dans la majeure partie du reste du monde, y compris le pays où vit le client, c'est le 4 juillet. Personne ne voit de message d'erreur. Le client se présente simplement une saison trop tôt, ou un rapport est classé à la mauvaise date, en silence.

Les nombres portent le même piège dans l'autre sens. « 1.500 » se lit un et demi aux États-Unis et quinze cents en Allemagne, où le point est un séparateur de milliers, pas une virgule décimale. Une routine d'import qui lit des nombres étrangers avec les règles américaines ne plante pas. Elle corrompt des données financières et continue de tourner.

Ce qui l'empêche. Dates et nombres sont rendus à partir des données de locale (le Common Locale Data Repository, pas une table de formats bricolée), et les mêmes règles de locale s'appliquent à l'analyse des saisies utilisateur, pas seulement à l'affichage. Un champ de date qui accepte une saisie clavier doit rejeter ou reformater « 04/07/2026 » de façon cohérente avec son affichage, dans les deux sens.

5. Des erreurs de devise et d'arrondi

À quoi ça ressemble. Un tunnel de paiement convertit les prix au taux de change du jour et affiche le résultat avec deux décimales, pour chaque devise, partout. Cela casse de deux façons précises. D'abord, les prix dérivent avec le taux de change au lieu de tenir le prix local fixe qu'un marché attend : un produit à 49,99 EUR hier coûte 51,23 EUR aujourd'hui sans raison visible pour le client. Ensuite, l'hypothèse des deux décimales est fausse en soi : le yen japonais n'a aucune décimale, tandis que le dinar bahreïni, le dinar koweïtien et le rial omanais en utilisent trois. Un panier construit pour deux décimales perd une précision dont il a besoin ou invente une précision qui n'existe pas.

Ce qui l'empêche. Les prix multidevises sont fixés par marché avec un arrondi maîtrisé, pas calculés en direct depuis un flux de taux de change au moment du paiement. Le formatage des devises et la gestion des sous-unités viennent des mêmes données de locale que les dates et les nombres : le JPY s'affiche en nombre entier et le KWD avec trois décimales, parce que le code a interrogé les données au lieu de supposer.

6. Des écritures RTL rendues comme du texte brouillé

À quoi ça ressemble. De l'arabe ou de l'hébreu apparaît 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 pendant que l'écriture, elle, se lit de droite à gauche : navigation, icônes et indicateurs de progression pointent dans le mauvais sens par rapport au fil de lecture. Pire, une phrase qui mêle une expression arabe à un code produit latin ou à un numéro de téléphone peut sortir avec les segments dans le mauvais ordre, un brouillage visuel qui rend le texte réellement difficile à lire, pas seulement inhabituel.

Les utilisateurs le remarquent en quelques secondes, et cela se lit comme un logiciel cassé plutôt qu'une traduction inachevée. C'est l'un des moyens les plus rapides de perdre sa crédibilité auprès d'un marché entier.

Ce qui l'empêche. Les mises en page utilisent les propriétés CSS logiques (start et end, pas left et right) pour que le miroir soit automatique, et la gestion du texte bidirectionnel est testée avec une vraie locale RTL, pas présumée fonctionner parce qu'on n'y a pas touché. Le sujet est assez vaste pour que Globaprom le traite en détail ailleurs dans sa pratique de développement de logiciels multilingues.

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

À quoi ça ressemble. Un client nommé « José » est enregistré, puis affiché, comme « José ». Une raison sociale japonaise sauvegardée en base ressort en rangée de points d'interrogation ou de carrés. Cela arrive quand une colonne de base de données, une API héritée ou un export de fichier utilise un encodage de caractères qui ne couvre que les caractères latins : tout ce qui sort de cet ensemble est corrompu au moment de l'écriture, pas de l'affichage. Le dégât se produit dans la couche de stockage, donc il reste invisible jusqu'à ce que quelqu'un regarde les données brutes, ou qu'un client se plaigne que son propre nom est mal orthographié sur sa propre facture.

Ce qui l'empêche. 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 dominant, doit tourner de bout en bout, car un seul composant hérité sur un autre encodage suffit à corrompre noms et adresses dans tout le système.

Le schéma derrière les sept

Chacune de ces erreurs paraît petite isolément : un bouton tronqué, une date fausse, un nom brouillé. Aucune n'apparaît dans des tests menés entièrement dans la langue d'origine du produit, parce que c'est précisément la seule langue qu'aucune d'elles n'affecte. C'est exactement pourquoi elles survivent jusqu'en production et sont découvertes par des clients payants dans d'autres pays plutôt que par la recette.

L'enjeu commercial est réel. L'enquête de CSA Research auprès de 8 709 consommateurs dans 29 pays a montré que 76 % préfèrent acheter des produits présentés dans leur propre langue, et que 40 % n'achèteront jamais sur des sites dans d'autres langues (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 bien plus cher que les éviter au départ. Les équipes rapportent deux à cinq fois plus d'effort d'ingénierie pour rattraper l'internationalisation dans un produit en exploitation que pour l'intégrer dès le premier jour (XTM, 2026), parce que chaque couche (chaînes, mise en page, formats, stockage) doit être trouvée et corrigée d'un coup pendant que le produit continue de livrer. Nous voyons ces sept points frapper le plus fort dans le développement e-commerce sur mesure, où paiement, prix et données produit touchent toutes les erreurs de cette liste en même temps, et dans le logiciel logistique sur mesure, où documents douaniers, applications chauffeur multilingues et formats de date et de devise transfrontaliers ne laissent aucune place à l'approximation.

Questions fréquentes sur les erreurs d'internationalisation

Quelle est la cause la plus fréquente d'échec d'un logiciel à l'international ?

Il a été construit en supposant une langue et une région, puis traduit après coup au lieu d'être conçu dès le départ pour en servir plusieurs. La traduction couvre le texte visible ; les chaînes codées en dur, les mises en page figées et les hypothèses de format en dessous restent cassées.

Peut-on corriger ces erreurs sans reconstruire le produit ?

Oui, mais pas à bas coût. Chaque erreur doit être trouvée et corrigée dans la couche où elle vit (code, mise en page ou base de données) pendant que le produit continue de tourner : c'est pourquoi un retrofit coûte deux à cinq fois plus cher que l'intégration dès le départ (XTM, 2026).

Ces problèmes ne touchent-ils que les langues de droite à gauche comme l'arabe ?

Non. L'expansion du texte, la confusion des dates et les arrondis de devise frappent tous les marchés non anglophones, y compris ceux qui lisent de gauche à droite. Les écritures RTL exposent les erreurs le plus vite et le plus visiblement, mais elles ne sont pas les seules langues où ces sept échecs apparaissent.

Comment vérifier si mon logiciel a ces problèmes ?

Lancez une passe de pseudo-localisation : remplacez chaque chaîne par un texte factice allongé et accentué, puis parcourez le produit en cherchant boutons tronqués, texte resté dans la langue d'origine et mises en page cassées. Cela fait remonter la plupart de ces sept erreurs en un après-midi.

Corriger l'internationalisation m'oblige-t-il à tout traduire moi-même ?

Non. L'internationalisation est un travail d'ingénierie qui rend la traduction possible ; elle ne vous demande de rien traduire vous-même. Une fois le code corrigé, la traduction passe par un pipeline i18n (en anglais) distinct, séparé de la question budgétaire localisation vs traduction.

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

Dites-nous quels marchés votre logiciel doit atteindre. Nous auditons lesquelles de ces sept erreurs vous avez déjà, puis chiffrons à prix fixe la correction et un pipeline de traduction qui empêche les nouvelles langues de les répéter.

Demander un devis à prix fixe →