Internationalisation (i18n) d’une application : traduire et localiser pour l’international
Obtenez un résumé intelligent et des insights personnalisés
L’internationalisation application i18n est un travail technique. Elle rend notamment une application capable de fonctionner dans plusieurs langues et régions sans réécrire son code. Ce qui prépare le terrain avant même que la première traduction ne soit lancée. En effet, une application pensée dès le départ pour l’international coûte nettement moins cher à ouvrir à un nouveau marché qu’une application qu’il faut retravailler après coup.
Pourquoi l’Internationalization ne se fait pas au dernier moment ?
Beaucoup de porteurs de projet pensent à l’international une fois l’application déjà en production. C’est l’erreur la plus fréquente. Ajouter une deuxième langue à une application qui n’a pas été conçue pour cela oblige souvent à retoucher :
- L’interface
- La base de données
- Et parfois l’architecture entière.
En effet, il y a quatre piliers d’une internationalisation application i18n réussie. À savoir :
- L’architecture technique
- Les formats régionaux
- Le workflow de traduction
- Et le SEO multilingue.
Chez AquilApp, nous accompagnons des projets qui touchent plusieurs pays. Tel est le cas notamment de programmes institutionnels internationaux. D’ailleurs, cette expérience nourrit les recommandations qui suivent.
Comparons l’internationalisation application i18n vs l10n : deux étapes complémentaires
L’internationalisation application i18n et la l10n (l10n, Localization) sont deux étapes distinctes, mais liées.
- L’i18n prépare le code pour qu’il puisse accueillir n’importe quelle langue.
- La l10n adapte ensuite le contenu à une langue et une culture précise.
En outre, l’i18n se fait une seule fois, en amont, par l’équipe de développement. La l10n se répète à chaque nouveau marché, avec des traducteurs et parfois des experts culturels locaux. Une application bien internationalisée facilite chaque nouvelle localisation.
| Critère | i18n (internationalisation) | l10n (localisation) |
|---|---|---|
| Quand | En amont, dès la conception | À chaque nouveau marché |
| Qui | Équipe de développement | Traducteurs, relecteurs locaux |
| Quoi | Architecture, clés de traduction, formats | Textes, images, tonalité, devises |
| Fréquence | Une seule fois | Répétée par langue/pays |
Source : principes définis par le W3C Internationalization Activity.
Comment préparer l’architecture de l’internationalisation application i18n dès le départ ?
Une application internationalisable ne contient aucun texte écrit en dur dans le code. Chaque texte affiché passe par une clé de traduction. Le tout est stocké dans un fichier de ressources séparé. Cette règle simple évite des refontes coûteuses plus tard.
Toutefois, faites attention à la pluralisation. C’est le piège technique le plus courant. Le français ou l’anglais utilisent deux formes (singulier, pluriel). D’autres langues en utilisent davantage. Selon le référentiel Unicode CLDR (Common Locale Data Repository), l’arabe utilise jusqu’à six formes plurielles selon la quantité, contre deux pour le français. Un développement qui ne gère que « 1 article / plusieurs articles » produira des phrases incorrectes dans ces langues.
À savoir : ICU MessageFormat est le standard le plus utilisé pour gérer cette complexité. Il permet d’écrire une seule règle de traduction. Cette dernière s’adapte automatiquement au nombre, sans code conditionnel supplémentaire.
Pour l’implémentation, plusieurs bibliothèques dominent le marché :
- i18next : la référence pour les projets JavaScript et React.
- react-intl : une alternative intégrée à l’écosystème React, avec un support natif du format ICU.
- gettext : un standard plus ancien, toujours utilisé dans de nombreux langages serveur.
L’architecture de l’application doit aussi anticiper les variations de longueur du texte. Une même phrase peut occuper deux fois plus de place en allemand qu’en anglais. C’est un point à traiter dès la conception du design system. De quoi vous assurer que les composants d’interface absorbent ces écarts sans casser la mise en page.
Comment gérer les formats régionaux pendant l’internationalisation i18n ?
Un format régional mal géré crée de la confusion. La date « 03/04 » signifie le 3 avril en France et le 4 mars aux États-Unis. Une application internationale doit donc adapter automatiquement les dates, les devises et les adresses selon la locale de l’utilisateur.
| Élément | France (fr-FR) | États-Unis (en-US) | Arabie saoudite (ar-SA) |
|---|---|---|---|
| Date | 22/07/2026 | 07/22/2026 | ٢٢/٠٧/٢٠٢٦ |
| Devise | 1 200,00 € | $1,200.00 | ١٬٢٠٠٫٠٠ ر.س |
| Sens de lecture | Gauche à droite | Gauche à droite | Droite à gauche |
Source : référentiel Unicode CLDR.
Le RTL (Right-to-Left) concerne les langues qui se lisent de droite à gauche. Exemple : l’arabe ou l’hébreu. Ce n’est pas qu’une question de traduction. En effet, il inverse l’ensemble de la mise en page, des icônes de navigation aux barres de progression. Une application qui vise ces marchés doit prévoir cette inversion dès la conception de l’interface, pas comme un correctif après-coup.
Comment se passe le workflow de traduction : outils, processus, CI
Un workflow de traduction structuré suit quatre étapes :
- Extraction automatique des clés de texte
- Envoi vers un outil de gestion de traduction (TMS)
- Traduction et relecture humaines
- Puis réintégration dans l’application.
Deux outils dominent notamment le marché pour piloter ce processus : Crowdin et Phrase (anciennement PhraseApp). Les deux permettent aux traducteurs de travailler directement sur les chaînes de texte. Le tout se fait avec un contexte visuel de l’écran concerné. Ce qui réduit les erreurs de contresens.
En outre, ne négligez pas l’intégration dans la CI (Continuous Integration). En effet, elle synchronise automatiquement les traductions à chaque déploiement. De quoi éviter qu’une version de l’application parte en production avec des textes non traduits ou obsolètes.
Vous envisagez une internationalisation i18n au-delà de deux langues ? Un tableur partagé devient rapidement ingérable. Un TMS dédié fait gagner du temps dès le deuxième marché ouvert. De plus, il devient indispensable à partir du troisième.
Comment gérer le SEO multilingue : hreflang, structure d’URL, indexation
Le hreflang est une balise qui indique à Google quelle version linguistique d’une page proposer selon la langue et la région de l’internaute. D’ailleurs, Google recommande d’utiliser des URL distinctes pour chaque langue plutôt qu’un changement de contenu basé sur des cookies. En effet, son robot d’exploration ne détecte pas toujours ces changements dynamiques.
Qu’en est-il de la structure d’URL ? Trois options s’offrent à vous :
- Un sous-dossier (aquilapp.fr/en/)
- Un sous-domaine (en.aquilapp.fr)
- Ou domaine dédié par pays.
Néanmoins, le sous-dossier reste le choix le plus simple à maintenir pour la majorité des projets. Pour cause, il concentre l’autorité SEO sur un seul domaine.
Attention, ne commettez pas l’erreur de reste l’absence de balise hreflang entre des pages très proches en plusieurs langues. Google peut alors les considérer comme du contenu dupliqué. En plus, il les fera concurrencer entre elles dans ses résultats.
Pourquoi l’internationalisation i18n est-elle un investissement rentable ?
Le CSA Research a mené une recherche auprès de plus de 8 700 consommateurs dans 29 pays. Une large majorité préfère acheter un produit avec des informations disponibles dans leur langue maternelle. En plus, une part significative des internautes n’achète jamais sur un site dans une langue étrangère. Ce constat vaut aussi pour les plateformes B2B et les services publics numériques.
Chez AquilApp, nous avons accompagné des projets nécessitant une coordination multi-pays, notamment pour des programmes institutionnels internationaux. La cohérence entre versions linguistiques conditionnait directement l’adoption par les utilisateurs finaux. Ces projets partagent tous le même constat : la préparation technique en amont réduit drastiquement le temps d’ouverture de chaque nouveau marché.
FAQ sur l’internationalisation application i18n Qu’est-ce que l’internationalisation i18n d’une application ? L’internationalisation application i18n est le travail technique qui rend une application capable de recevoir plusieurs langues et formats régionaux sans modification du code. Elle précède toujours la traduction elle-même. Quelle différence entre i18n et l10n ? L’i18n prépare l’architecture une seule fois, en amont. La l10n adapte ensuite le contenu à chaque langue et culture, à répéter pour chaque nouveau marché. Faut-il gérer le RTL dès le début d’un projet ? Oui, si l’arabe ou l’hébreu figurent parmi les marchés cibles. Le RTL inverse toute la mise en page. L’ajouter après coup revient souvent à refaire une partie de l’interface.En résumé
L’internationalisation application i18n se joue dans l’architecture, bien avant la première traduction. Une application qui gère proprement ses clés de texte, sa pluralisation, ses formats régionaux et son SEO multilingue s’ouvre à un nouveau marché en quelques semaines. C’est aussi le cas pour les marchés francophones émergents. En effet, ils demandent une attention particulière au mode hors-ligne et au paiement mobile.
AquilApp accompagne les équipes produit et technique dans cette préparation, de l’architecture à la mise en ligne multilingue. Demander un devis gratuit pour internationaliser votre application.
