Développement de logiciels multilingues

Pourquoi la plupart des logiciels échouent à l'international (le piège du rattrapage)

La plupart des logiciels échouent hors de leur marché d'origine pour une seule raison : ils ont été conçus dans une langue et traduits après coup. Les mots ne sont que la couche visible. Dessous, on trouve des chaînes codées en dur, des mises en page calibrées pour des libellés courts, une logique de dates qui suppose une seule convention de calendrier, et une base de données qui stocke du texte sans savoir quelle écriture il contient.

Cela vous coûte des ventes. L'étude « Can't Read, Won't Buy » de CSA Research, menée auprès de 8 709 consommateurs dans 29 pays, a établi que 76 % préfèrent acheter des produits présentés dans leur langue, et que 40 % n'achèteront jamais sur des sites dans une autre langue. Moins de 20 % de la population mondiale parle anglais, alors que près de la moitié des sites web sont rédigés dans cette langue (Statista, 2026). Un produit disponible dans une seule langue se dispute une minorité de son marché.

Le rattrapage est la solution la plus chère. Ajouter des langues à une base de code monolingue oblige à toucher toutes les couches à la fois (chaînes d'interface, validation, e-mails, PDF, champs de base de données, recherche) pendant que le produit continue d'évoluer. Les équipes rapportent un effort d'ingénierie deux à cinq fois supérieur pour un rattrapage que pour le même support intégré dès le départ (XTM, 2026). La plupart découvrent en cours de projet qu'elles avaient budgété de la traduction et acheté de la réingénierie.

Nous croisons les mêmes défaillances si souvent que nous les avons répertoriées : pourquoi les logiciels échouent à l'international détaille les sept erreurs que nous rencontrons le plus, et ce que chacune coûte à corriger.

Architecture i18n : quoi intégrer dès le premier jour

Une architecture multilingue dès la conception tient en une courte liste de décisions concrètes. Prises au départ, chacune coûte peu. Rattrapées plus tard, chacune coûte cher. Voici ce que contient chaque projet que nous livrons :

1. Unicode partout. Unicode attribue un point de code à chaque caractère de chaque système d'écriture, et UTF-8 en est l'encodage dominant. Chaque colonne de base de données, API, export de fichier et modèle d'e-mail que nous construisons est en UTF-8 de bout en bout, car un seul composant hérité avec un autre encodage suffit à corrompre noms et adresses. Ce texte illisible porte un nom, le « mojibake », et nous le décortiquons dans Unicode dans les applications métier.
2. Chaînes externalisées. Aucun texte visible par l'utilisateur ne vit dans le code. Chaque libellé, message d'erreur et e-mail se trouve dans des fichiers de ressources à clés stables, prêts pour les traducteurs. Les phrases ne sont jamais assemblées à partir de fragments, car l'ordre des mots change d'une langue à l'autre.
3. Formatage de messages ICU. ICU (International Components for Unicode) est la bibliothèque open source qui gère pluriels, genre, listes et valeurs formatées selon la langue. L'anglais a deux formes de pluriel, l'arabe en a six, et en polonais la règle change selon le nombre lui-même. Des gabarits de chaînes n'y suffisent pas. ICU, si.
4. Données de locales CLDR. Le CLDR (Common Locale Data Repository, maintenu par le Consortium Unicode) fournit les données de chaque locale, c'est-à-dire d'une combinaison langue-région comme fr-BE : formats de date, séparateurs numériques, symboles monétaires, ordres de tri. Nous l'utilisons plutôt que des tables de formats tenues à la main.
5. Un modèle de données traduisible. Les chaînes d'interface ne sont que la moitié du problème. Noms de produits, catégories, modèles de documents et notifications vivent dans la base de données, donc le schéma les stocke par langue dès le premier jour, en général derrière un CMS multilingue ou des champs de contenu localisés.
6. hreflang et routage par locale. hreflang est l'annotation HTML qui indique aux moteurs de recherche quelle version linguistique d'une page afficher à chaque utilisateur. Nous la générons à partir de la configuration des locales, jamais à la main.
7. Pseudo-localisation en CI. La pseudo-localisation remplace le texte par des chaînes factices accentuées et rallongées, comme « [!!! Àççôûñt Šéttîñgš !!!] », pour débusquer les textes codés en dur et les mises en page qui cassent avant qu'un seul mot ne soit traduit.

Le reste de nos pratiques est rassemblé dans les bonnes pratiques des applications mondiales. Sur votre projet, les critères d'acceptation i18n qui les imposent sont inscrits dans le périmètre fixe.

RTL, CJC et les écritures qui cassent les interfaces naïves

Deux familles d'écritures révèlent une internationalisation fragile plus vite que tout le reste. Repérez les problèmes en test, et vos utilisateurs ne les verront jamais.

Les écritures de droite à gauche (RTL), l'arabe et l'hébreu, inversent le sens de lecture de toute l'interface. Une vraie prise en charge RTL suppose des mises en page en miroir (navigation, icônes, parcours de progression), des propriétés CSS logiques plutôt que des valeurs gauche/droite, et un texte bidirectionnel correct, quand une phrase arabe contient un code produit latin ou un numéro de téléphone qui se lit dans l'autre sens. Une interface naïve transforme le texte RTL en bouillie visuelle, et les utilisateurs le remarquent en quelques secondes.

Les écritures CJC (chinois, japonais, coréen) cassent d'autres hypothèses. Pas d'espaces entre les mots : le retour à la ligne doit connaître l'écriture. Des caractères plus denses : les tailles de police et les interlignes réglés pour l'alphabet latin deviennent illisibles. La recherche, le tri et les méthodes de saisie se comportent aussi autrement.

Reste l'expansion du texte. Les libellés allemands sont environ 30 % plus longs que l'anglais, et même des mots courants débordent des boutons à largeur fixe. Les mises en page doivent être testées avec de vraies écritures, pas traduites en dernier : chaque projet multilingue que nous livrons passe la pseudo-localisation plus au moins une locale RTL et une locale CJC.

Pipelines de traduction : relier votre application à des flux de traduction professionnels

Ici, nous jouons à domicile. Un pipeline de traduction est le trajet automatisé que suit votre contenu, de la base de code jusqu'aux traducteurs, puis en retour. C'est lui qui garde un logiciel multilingue à jour, version après version, au lieu d'une traduction unique qui vieillit.

Un pipeline de production compte cinq étapes :

1. Extraction. Les chaînes nouvelles ou modifiées sont détectées automatiquement à chaque version. Plus personne n'envoie de tableurs par e-mail.
2. Transmission au TMS. Un système de gestion de traduction (TMS) répartit le contenu entre traducteurs et suit l'avancement. Il applique la mémoire de traduction (des traductions déjà validées, réutilisées au lieu d'être payées deux fois) et des glossaires terminologiques, pour que le vocabulaire de votre produit reste cohérent d'une version et d'une langue à l'autre.
3. Traduction. Traducteurs humains, traduction automatique, ou post-édition de traduction automatique (MTPE : une traduction automatique relue et corrigée par un professionnel), selon le type de contenu. Textes juridiques et chaînes d'interface méritent un soin humain. Les descriptions de catalogue en volume justifient souvent la MTPE.
4. Relecture en contexte. Les traducteurs voient les chaînes là où elles s'affichent, pas dans une colonne de tableur. La plupart des défauts de traduction sont des défauts de contexte.
5. Fusion et déploiement. Les traductions validées passent par les mêmes contrôles de relecture que le code. Avec la localisation continue, la boucle tourne à chaque version, et aucune langue n'attend jamais une « phase de traduction ».

Nous avons fait tourner ce type de flux sur des dizaines de paires de langues pendant plus de 20 ans, en tant que prestataire de traduction, en coordonnant des centaines de linguistes professionnels sous délais fermes. Choix d'outils et architecture complète : notre guide des pipelines de traduction.