Globaprom.

Développement de logiciels multilingues

Le développement de logiciels multilingues s'adresse aux équipes dont le produit doit fonctionner dans plusieurs langues, alors que leur logiciel actuel se comporte comme si l'anglais était la seule. Globaprom construit des applications web, des portails et des automatisations multilingues dès le premier commit : architecture internationalisée, données propres en Unicode, et pipelines de traduction branchés sur des flux professionnels. Nous avons dirigé une entreprise de traduction internationale pendant plus de 20 ans avant de proposer des services de développement logiciel sur mesure, alors la livraison multilingue n'est pas une option que nous greffons. C'est la façon dont nous avons appris à construire.

Vous trouverez ici pourquoi les logiciels échouent à l'international, ce que contient une architecture multilingue dès la conception, et comment le contenu traduit circule réellement jusqu'à un produit en ligne.

Flat vector illustration of a globe at the center connected by flowing lines to abstract interface panels and speech-bubble shapes, suggesting one system serving many regions

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

La plupart des logiciels échouent à l'étranger pour une seule raison : ils ont été conçus monolingues et traduits après coup. Les mots anglais sont la couche visible. Dessous, on trouve des chaînes codées en dur, des mises en page dimensionnées pour des libellés anglais courts, une logique de dates qui suppose une seule convention de calendrier, et une base de données qui stocke du texte sans se demander quelle écriture il contient.

Le coût commercial se mesure. 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 propre langue, et que 40 % n'achèteront jamais sur des sites dans une autre langue. Environ trois quarts des internautes parlent une langue maternelle autre que l'anglais (Statista, 2024). Un produit uniquement en anglais se dispute une minorité de son marché adressable.

Le rattrapage est la voie coûteuse. Ajouter des langues à une base de code monolingue impose de 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'être livré. Les équipes rapportent un effort d'ingénierie deux à cinq fois supérieur pour un rattrapage par rapport au même support intégré dès le départ (XTM, 2026). Les équipes qui budgètent « traduction » et découvrent qu'elles ont acheté « réingénierie » le découvrent en général en cours de projet.

Les modes de défaillance se répètent si régulièrement que nous les avons catalogués : voir pourquoi les logiciels échouent à l'international (en anglais) pour les sept erreurs que nous rencontrons le plus souvent, et ce que chacune coûte à défaire.

Internationalisation (i18n), localisation (l10n) et traduction

Trois termes s'emploient de façon interchangeable dans les rendez-vous commerciaux. Ce sont des postes budgétaires différents, et les confondre est la manière classique de faire dérailler un budget.

  • L'internationalisation (i18n) est un travail d'ingénierie ; l'abréviation compte les 18 lettres entre le i et le n. Elle rend le logiciel capable de prendre en charge n'importe quelle langue, région ou format sans modification du code : textes externalisés, données sûres côté encodage, logique consciente des locales. Réalisée une fois, elle sert tous les marchés futurs.
  • La localisation (l10n) est l'adaptation du produit à un marché précis : traduire l'interface, mais aussi ajuster formats, images, mentions légales, moyens de paiement et ton.
  • La traduction est une tâche à l'intérieur de la localisation : convertir un texte d'une langue vers une autre.

L'ordre compte. L'internationalisation est la fondation ; la localisation se répète par marché au-dessus ; la traduction est un coût de contenu récurrent. Sautez la première, et chaque localisation repaie la taxe du rattrapage.

Pour une visite guidée du versant ingénierie en langage clair, lisez l'internationalisation logicielle (en anglais) expliquée aux non-ingénieurs. Pour les conséquences budgétaires de la distinction, et la raison pour laquelle les deux se chiffrent séparément, voir localisation ou traduction (en anglais). Nous avons facturé les deux côtés de cette ligne pendant deux décennies.

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

Une architecture multilingue dès la conception est un ensemble de décisions concrètes, pas une philosophie. Voici celles que nous prenons au démarrage de chaque projet :

  1. Unicode partout. Unicode est le standard universel de caractères qui attribue un point de code à chaque caractère de chaque système d'écriture ; UTF-8 en est l'encodage dominant. Chaque colonne de base de données, API, export de fichier et modèle d'e-mail de nos builds est en UTF-8 de bout en bout. Un seul composant hérité avec un autre encodage suffit à corrompre noms et adresses : le texte poubelle « mojibake » que nous disséquons dans Unicode dans les applications métier (en anglais).
  2. Chaînes externalisées. Aucun texte visible par l'utilisateur ne vit dans le code. Chaque libellé, erreur et e-mail se trouve dans des fichiers de ressources avec des clés stables, prêts pour les traducteurs. Les phrases ne sont jamais concaténées à partir de fragments, parce que l'ordre des mots change selon la langue.
  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 par langue. L'anglais a deux formes de pluriel ; l'arabe en a six ; les règles du polonais changent selon le nombre lui-même. ICU gère cela ; les gabarits de chaînes, non.
  4. Données de locales CLDR. Le CLDR (Common Locale Data Repository, maintenu par le Consortium Unicode) fournit les faits de chaque locale (une locale étant une combinaison langue-région telle que fr-BE). Formats de dates, séparateurs de nombres, symboles monétaires, ordres de tri : nous utilisons les données CLDR plutôt que des tables de formats maintenues à 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 (en anglais) 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 servir à chaque utilisateur. Nous le générons programmatiquement à 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 ([!!! Àççôûñt Šéttîñgš !!!]) pour exposer les textes codés en dur et les mises en page qui cassent, avant qu'un seul mot ne soit traduit.

Aucun de ces éléments n'est coûteux quand il est choisi au départ. Tous sont coûteux à rattraper. Cette asymétrie est l'argument entier en faveur du multilingue dès la conception. Le reste de nos pratiques est rassemblé dans concevoir des applications pour des utilisateurs internationaux (en anglais).

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

Deux familles d'écritures exposent le plus vite une internationalisation faible.

Les écritures de droite à gauche (RTL) (arabe et hébreu) inversent le sens de lecture de toute l'interface. Une vraie prise en charge RTL (en anglais) 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 une gestion correcte du texte bidirectionnel, 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 affiche le texte RTL comme un brouillage visuel ; les utilisateurs le remarquent en quelques secondes.

Les écritures CJC (chinois, japonais, coréen) cassent d'autres hypothèses. Il n'y a pas d'espaces entre les mots, donc la logique de retour à la ligne doit connaître l'écriture. Les caractères sont plus denses, donc des tailles de police et des interlignes réglés pour le texte latin deviennent illisibles. Recherche, tri et méthodes de saisie se comportent tous différemment.

Ajoutez 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) et la leçon reste la même : les mises en page doivent être testées contre de vraies écritures, pas seulement traduites en dernier. Nous testons avec la pseudo-localisation plus au moins une locale RTL et une locale CJC sur chaque build multilingue.

Multidevise, dates, nombres et formats : les détails qui érodent la confiance

Les erreurs de format produisent rarement des rapports de bug. Elles produisent une méfiance silencieuse : le sentiment qu'un produit a été construit pour ailleurs.

  • Devise. Une tarification multidevise signifie des prix par marché avec des arrondis contrôlés, pas un calcul de taux de change au moment de l'affichage. Elle suppose aussi de respecter les unités mineures : le yen japonais n'a pas de décimales, et certaines devises en utilisent trois. Stockage, arrondi et règles d'affichage sont couverts dans gestion multidevise dans les logiciels (en anglais).
  • Dates et heures. 04/07/2026 est avril à New York et juillet à Bruxelles. Nous affichons les dates par locale à partir des modèles CLDR et stockons les horodatages en UTC avec fuseaux explicites, une habitude qui garde aussi le reporting transfrontalier honnête.
  • Nombres. 1.500 vaut un et demi aux États-Unis et quinze cents en Allemagne. Séparateurs décimaux et de groupement doivent suivre la locale à l'affichage et à la saisie ; un import qui les lit de travers corrompt des données financières en silence.
  • Noms et adresses. Ordre des noms, titres de civilité, formats postaux et conventions téléphoniques varient selon le marché. Les formulaires qui imposent une structure américaine rejettent des clients parfaitement valides.

Chaque détail est petit. Ensemble, ils décident si un acheteur belge, un dispatcheur saoudien ou un technicien d'usine japonais vit le logiciel comme le sien.

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

C'est notre terrain. Un pipeline de traduction est le trajet automatisé que le contenu parcourt de votre base de code vers les traducteurs, puis en retour. C'est ce qui sépare un logiciel multilingue qui reste à jour d'un logiciel qui a été traduit une fois.

Un pipeline de production compte cinq étapes :

  1. Extraction. Les chaînes nouvelles et modifiées sont détectées automatiquement à chaque release. Personne n'envoie de tableurs par e-mail.
  2. Transmission au TMS. Un système de gestion de traduction (TMS) est la plateforme qui route le contenu vers les traducteurs et suit l'avancement. Il applique la mémoire de traduction (traductions déjà approuvées, réutilisées au lieu d'être rachetées) et des glossaires terminologiques pour que le vocabulaire de votre produit reste cohérent d'une release et d'une langue à l'autre.
  3. Traduction. Traducteurs humains, traduction automatique, ou post-édition de traduction automatique (MTPE, une sortie machine relue et corrigée par un professionnel), au choix par type de contenu. Les textes juridiques et les chaînes d'interface méritent le soin humain ; les descriptions de catalogue en masse justifient souvent la MTPE.
  4. Relecture en contexte. Les traducteurs voient les chaînes là où elles apparaissent, 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 approuvées reviennent par les mêmes portes de relecture que le code. Avec la localisation continue, cette boucle tourne à chaque release, si bien qu'aucune langue n'attend jamais une « phase de traduction ».

Nous avons fait tourner de tels 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. L'architecture complète, choix d'outils compris, se trouve dans notre guide des pipelines de traduction (en anglais).

Comment nous construisons multilingue d'abord : l'héritage comme preuve

Globaprom est né de BeTranslated, une entreprise de traduction internationale que nous avons fondée et que nous exploitons toujours (l'histoire derrière Globaprom retrace tout le parcours). Cet héritage se voit dans le travail, de façon précise et vérifiable :

  • Nous avons été notre propre premier client. Nos systèmes multilingues de facturation, de devis et de portail fournisseurs ont été construits pour nos propres opérations de traduction : multidevise, multi-locale, en production pendant des années avant que nous vendions le moindre build.
  • Les locales sont cadrées, pas supposées. Chaque projet démarre par une matrice de locales : quelles langues, écritures, devises et formats, maintenant et plausiblement plus tard. Les critères d'acceptation i18n entrent dans le périmètre fixe.
  • Vitesse assistée par IA, qualité relue par des humains. Nous construisons avec le développement assisté par IA, et c'est précisément pourquoi la checklist i18n ci-dessus est imposée par la relecture et par des tests de pseudo-localisation en CI : le code généré retombe par défaut sur des hypothèses anglophones si le pipeline ne l'interdit pas. Notre processus est documenté dans comment nous cadrons, construisons et relisons.
  • La traduction n'est pas votre problème à organiser. Via notre réseau de linguistes professionnels, nous connectons votre TMS, organisons la traduction humaine ou la MTPE, et remettons un pipeline qui tourne, pas un dossier de chaînes accompagné de vœux pieux.

Aucune autre agence de logiciel sur mesure sur ce marché ne peut aligner cet ensemble de preuves. C'est la raison d'être de cette offre.

Logiciels multilingues par secteur

Les exigences multilingues diffèrent dans chaque vertical. Chacune de nos pratiques sectorielles les intègre par défaut :

Étude de cas : la livraison multilingue en pratique

C21 Perdomo : site web multilingue et système de suivi. Pour cette agence immobilière, nous avons construit un nouveau site multilingue assisté par IA avec un système de suivi intégré, internationalisé dès le premier commit plutôt que rattrapé. Ce build montre en production l'approche décrite ici : contenu conscient des locales et interface multilingue livrés comme un seul système cohérent.

D'autres retours de projets sont rassemblés dans nos études de cas (en anglais).

Questions fréquentes sur les logiciels multilingues

Qu'est-ce que le développement de logiciels multilingues ?

Le développement de logiciels multilingues consiste à construire des applications qui fonctionnent correctement dans plusieurs langues, écritures et formats régionaux. Il combine l'internationalisation (i18n), l'ingénierie qui rend toute langue possible, avec la localisation (l10n) et les flux de traduction qui livrent la version de chaque marché.

Quelle est la différence entre internationalisation et localisation ?

L'internationalisation (i18n) est une ingénierie réalisée une fois, qui rend le logiciel capable de prendre en charge n'importe quelle langue : chaînes externalisées, données Unicode, formatage conscient des locales. La localisation (l10n) est le travail par marché au-dessus : traduire le contenu et adapter formats, devises et conventions pour un public précis.

Construire multilingue dès le premier jour coûte-t-il plus cher ?

Marginalement, oui : chaînes externalisées, discipline UTF-8 et formatage par locale ajoutent peu quand ils sont prévus dès le départ. Rattraper la même capacité plus tard impose de retravailler chaque couche d'un produit en ligne, pour un effort d'ingénierie deux à cinq fois supérieur (XTM, 2026).

Pouvez-vous ajouter des langues à un logiciel existant ?

Oui. Nous internationalisons les bases de code existantes par étapes : audit de l'encodage et des chaînes codées en dur, externalisation des textes, correction de la logique de formatage, puis branchement d'un pipeline de traduction. L'audit vient en premier, parce que la réponse honnête sur l'effort dépend de la profondeur des hypothèses anglophones.

Comment les mises à jour de traduction arrivent-elles dans le logiciel ?

Par un pipeline de traduction. Les chaînes nouvelles et modifiées sont extraites automatiquement, routées vers un système de gestion de traduction (TMS), traduites par des humains ou en post-édition de traduction automatique (MTPE), relues en contexte, puis fusionnées à chaque release. Pas de tableurs, pas de langues périmées.

Traduisez-vous le contenu vous-mêmes ?

Nous l'organisons. Globaprom est né d'une entreprise de traduction forte de plus de 20 ans d'activité sur des dizaines de paires de langues, alors nous connectons votre produit à des linguistes professionnels via le pipeline que nous construisons. Vous choisissez traduction humaine, MTPE, ou un mélange par type de contenu.

Construisez-le une fois, vendez-le partout

Dites-nous quels marchés votre logiciel doit servir (langues, écritures, devises comprises). Nous répondons avec un périmètre fixe, un prix fixe et une date de livraison en semaines, pipeline de traduction inclus dans le plan.

Demander un devis à prix fixe