Comment localiser une application mobile

TABLE OF CONTENTS

Si vous cherchez comment localiser une application mobile, vous n’avez généralement pas besoin de « conseils de traduction ». Vous avez besoin d’un processus fiable pour la mise en production qui couvre les chaînes de l’application, la mise en page, les règles de pluriel, le support droite-à-gauche, les captures d’écran et les métadonnées des stores sans casser le produit.

C’est la distinction essentielle : la localisation d’une application mobile ne se résume pas à traduire du texte. C’est adapter l’application, la page produit et le processus d’assurance qualité pour chaque marché cible. Apple indique que l’App Store est disponible dans 175 régions et 40 langues, tandis qu’Android 13 a introduit les préférences linguistiques par application au niveau du système. Autrement dit, les deux grandes plateformes considèrent désormais le choix de la langue comme une expérience produit fondamentale, pas comme un détail secondaire.

Ce guide passe en revue les étapes pratiques pour les équipes iOS et Android.

En résumé :

Séparez la localisation in-app de la localisation App Store et Google Play.
Externalisez les chaînes avant de traduire quoi que ce soit.
Gérez les pluriels, les variables, les dates, les devises et le RTL dès le départ.
Testez avec des pseudo-langues avant de livrer de vraies traductions.
Localisez les captures d’écran et les ressources des stores, pas seulement les descriptions.

Ce que la localisation d’une application mobile inclut réellement

Le travail de localisation se divise généralement en deux volets.

1. Localisation in-app

C’est le produit lui-même :

Chaînes de l’interface utilisateur
Messages d’erreur et textes d’intégration
Dates, heures, nombres, devises et unités
Chaînes sensibles aux pluriels et au genre
Expansion de la mise en page et comportement droite-à-gauche
Images ou icônes contenant du texte ou un sens directionnel

Apple recommande explicitement d’utiliser Xcode, les API Foundation, Auto Layout, le support Unicode, les catalogues de ressources localisées et les symboles sensibles à la direction pour préparer les applications aux marchés mondiaux. Android recommande de manière similaire les ressources sensibles aux paramètres régionaux, le support des langues par application et les mises en page compatibles RTL au lieu de textes et positionnements codés en dur.

2. Localisation de la fiche du store

C’est ainsi que les utilisateurs découvrent votre application :

Nom de l’application
Sous-titre ou description courte
Description complète
Mots-clés
Captures d’écran
Aperçus de l’application ou vidéos promotionnelles

Traitez cela comme un livrable distinct. Une application bien localisée peut quand même sous-performer si la page produit est générique, non traduite ou visuellement inadaptée au marché cible.

Commencez par l’internationalisation, pas par la traduction

La traduction est la dernière étape d’un pipeline qui commence par la structure.

Externalisez les chaînes et conservez une locale de repli complète

Sur Android, Google avertit que votre fichier res/values/strings.xml par défaut doit définir chaque chaîne dont votre application a besoin. Si le fichier par défaut est incomplet et que l’appareil fonctionne dans une locale non supportée, l’application peut refuser de se charger et afficher une erreur avec un bouton « Forcer l’arrêt ». C’est pourquoi la localisation commence par l’hygiène des ressources, pas par le choix de la langue.

Pour iOS, Apple recommande de séparer le texte et les images visibles par l’utilisateur du code exécutable afin qu’ils puissent être localisés en tant que fichiers de ressources. Dans les workflows Apple modernes, les catalogues de chaînes sont l’approche recommandée dans Xcode 15 et versions ultérieures pour les chaînes contenant des pluriels.

Règle pratique :

ne jamais coder en dur le texte de l’interface dans les vues ou les contrôleurs
conserver une seule langue source canonique
s’assurer que chaque chaîne visible par l’utilisateur possède une clé stable, un contexte et une valeur de repli
inclure des commentaires pour les traducteurs sur les chaînes ambiguës

Un petit exemple rend les choses plus concrètes.

Android commence généralement avec un fichier strings.xml par défaut :

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Ensuite, votre interface lit la ressource au lieu de coder l’anglais en dur :

Text(text = stringResource(R.string.checkout_cta))

Sur les plateformes Apple, Xcode 15+ gère souvent la même idée dans un catalogue de chaînes. Un extrait simplifié de Localizable.xcstrings peut ressembler à ceci :

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Vous n’avez pas besoin de mémoriser le format du fichier. La leçon opérationnelle est plus simple : chaque chaîne visible par l’utilisateur nécessite une source de vérité unique, suffisamment de contexte pour les traducteurs, et une valeur de repli sûre lorsqu’une locale est incomplète.

Si votre application livre également des fichiers de langue structurés, notre guide sur les Meilleurs traducteurs JSON en 2026 peut vous aider à réfléchir à l’automatisation et à la préservation du format.

Si vous souhaitez un outil direct pour les fichiers de ressources d’application, OpenL JSON Translator mérite un coup d’œil. Il est conçu pour traduire des fichiers .json sans casser les clés ni la structure, ce qui est exactement ce dont vous avez besoin lorsque les chaînes de l’application sont stockées dans des fichiers de localisation lisibles par machine. Le workflow est simple : téléchargez le JSON exporté depuis votre application, CMS ou pipeline de localisation, choisissez la langue cible, et téléchargez un fichier JSON traduit avec la même structure. Selon la page du produit, il prend en charge plus de 100 langues et des fichiers jusqu’à 50 Mo, ce qui en fait un outil pratique pour un premier passage pour les équipes de localisation d’applications travaillant avec du contenu structuré.

Supportez la sélection de langue au niveau de l’application

Les utilisateurs s’attendent de plus en plus à pouvoir choisir la langue de l’application indépendamment de la langue de leur appareil.

Sur les plateformes Apple, les utilisateurs peuvent sélectionner leur langue préférée pour une application indépendamment de la langue de l’appareil. Sur Android, Android 13 a ajouté un paramètre centralisé de langue par application, et Google recommande d’activer le support automatique de langue par application ou de connecter votre sélecteur aux API officielles.

Cela compte pour les vrais produits. Les utilisateurs bilingues et multilingues peuvent garder leur téléphone en anglais mais préférer une application de shopping, de banque ou de livraison dans une autre langue. Si votre application impose un seul modèle linguistique, vous créez des frictions avant même que la qualité de la traduction ne devienne une question.

Utilisez la pile de localisation de la plateforme

Résistez à l’envie d’inventer un système de localisation parallèle, sauf si vous en avez vraiment besoin.

Pour la plupart des équipes, la pile par défaut de la plateforme suffit :

iOS : catalogues de chaînes, Localizable.strings, .stringsdict, formateurs Foundation, Auto Layout
Android : res/values/, dossiers de ressources spécifiques aux locales, LocaleConfig, setApplicationLocales(), supportsRtl

Une infrastructure de localisation personnalisée a du sens à très grande échelle, mais elle ajoute une charge opérationnelle. Commencez par le système natif, puis étendez uniquement là où vous ressentez une vraie douleur.

Localisez les éléments que la plupart des équipes oublient

Les équipes traduisent souvent les phrases visibles et oublient les mécanismes produit qui les entourent.

Pluriels, variables et grammaire

Les règles de pluriel ne sont pas universelles. Les règles de pluriel Unicode CLDR définissent des catégories telles que zero, one, two, few, many et other, et différentes langues utilisent différents sous-ensembles. Apple note que dans les anciens workflows .stringsdict, other est la seule catégorie requise, mais ignorer les catégories spécifiques à une langue peut quand même produire un résultat grammaticalement incorrect. Android et iOS reposent tous deux sur la gestion des pluriels sensible aux locales pour une bonne raison.

C’est là que la traduction automatique naïve échoue :

1 file vs 2 files est facile en anglais
Les langues slaves nécessitent souvent plus de deux formes plurielles
Certaines langues modifient les noms, les verbes ou les mots environnants ensemble

Ne construisez jamais une interface pluralisée en concaténant des fragments comme "You have " + count + " messages". Utilisez plutôt les ressources de pluriel de la plateforme.

Voici la forme minimale de cela sur chaque plateforme.

Android :

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Exemple iOS legacy .stringsdict :

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

Dans Xcode 15 et versions ultérieures, Apple recommande de gérer les pluriels dans les catalogues de chaînes, mais le principe reste le même : donnez à la plateforme un modèle de message et laissez-la choisir la bonne forme linguistique.

Pour des garde-fous plus approfondis sur les espaces réservés et les chaînes structurées, consultez Comment traduire des documents techniques sans casser le code.

Dates, nombres, devises et unités

Apple recommande explicitement d’utiliser les API Foundation pour formater les dates, les longueurs, les poids, les prix et les symboles de devise selon les locales. Le même principe s’applique sur Android : formatez les données avec des API sensibles aux locales au lieu de coder en dur la ponctuation, les séparateurs décimaux ou l’ordre des unités.

Les erreurs courantes incluent :

03/04/2026 signifiant des choses différentes selon les régions
Des signes dollar codés en dur pour des marchés non-USD
1,234.56 affiché incorrectement dans les locales qui utilisent la virgule comme séparateur décimal
Des unités de mesure affichées dans le mauvais système

Si votre application contient de la planification, de la facturation, des créneaux de livraison ou des analyses, cela fait partie de la localisation, pas de la finition.

Expansion de la mise en page et support droite-à-gauche

L’anglais est généralement compact. L’allemand est plus long. L’arabe et l’hébreu inversent le sens de lecture. Une mise en page qui fonctionne bien en anglais peut se casser sérieusement dans d’autres locales.

Apple recommande de tester avec des pseudo-langues, y compris une pseudo-langue droite-à-gauche et une pseudo-langue à longueur doublée, avant même d’importer de vraies traductions. Android recommande d’utiliser start et end au lieu de left et right, d’activer android:supportsRtl="true", et de tester les mises en page RTL sur l’appareil avec Force RTL.

Votre liste de vérification ici est simple :

Permettre aux boutons et aux labels de s’agrandir
Éviter les conteneurs de texte à largeur fixe pour l’interface importante
Refléter l’interface directionnelle lorsque c’est approprié
Vérifier les icônes, les chevrons, les flux de progression et les carrousels en RTL
Tester le texte bidirectionnel comme une interface en arabe avec des noms de produits latins ou des codes promo

Images, icônes, captures d’écran et vidéos

Les recommandations de localisation d’Apple soulèvent un point important que beaucoup d’équipes négligent : les images peuvent aussi être localisées. Cela inclut les jeux d’images, les jeux de symboles et la directionnalité des symboles personnalisés. Si votre capture d’écran contient une interface en anglais, du texte anglais dans des bannières ou des flèches de gauche à droite, alors la capture d’écran elle-même n’est pas localisée.

C’est particulièrement important pour les écrans d’intégration, les cartes tutoriels et les ressources de l’App Store. Les utilisateurs ne séparent pas mentalement les « visuels marketing » du « langage du produit ». Ils jugent l’ensemble de l’expérience d’un seul coup.

Localisez vos pages App Store et Google Play séparément

C’est là que de nombreuses équipes perdent des installations même après avoir bien fait le travail in-app.

Exigences de l’App Store à anticiper

Apple recommande de localiser les métadonnées dans App Store Connect, y compris la description de l’application, les mots-clés, les aperçus de l’application et les captures d’écran. Apple indique également que vous pouvez présenter jusqu’à 10 captures d’écran sur votre page produit, et jusqu’à 3 aperçus d’application par taille d’appareil et langue supportés. Les aperçus d’application peuvent durer jusqu’à 30 secondes, et les captures d’écran comptent encore plus lorsqu’aucun aperçu n’est présent car les premières une à trois captures d’écran peuvent apparaître dans les résultats de recherche.

Cela a deux implications :

Vos premières captures d’écran sont des ressources de découvrabilité, pas seulement de la documentation.
Vous devriez localiser les captures d’écran et les aperçus pour les marchés prioritaires au lieu de réutiliser les ressources en anglais partout.

Exigences de Google Play à anticiper

Google Play traite la localisation des fiches comme un workflow à part entière. Play Console vous permet d’ajouter du texte localisé, des captures d’écran dans la langue cible et des ressources graphiques localisées. Si vous ajoutez des traductions de texte sans ressources graphiques localisées, Google indique que les visuels de la langue par défaut seront toujours affichés.

Google note également que si vous n’ajoutez pas vos propres traductions de fiche, les utilisateurs pourraient voir une traduction automatique avec une mention indiquant qu’elle a été générée automatiquement. C’est utile comme solution de repli, mais ce n’est pas une stratégie d’entrée sur le marché convaincante.

Une fonctionnalité actuelle particulièrement pertinente : Play Console indique pouvoir traduire en continu les chaînes de l’application à l’aide des modèles Gemini sans frais. Plus précisément, Google indique que cela s’applique aux chaînes d’application provenant de strings.xml dans les bundles d’applications téléchargés vers les versions brouillon, et que vous pouvez prévisualiser les traductions générées dans un émulateur intégré avant de publier. C’est un excellent moyen d’accélérer la couverture de premier passage, mais cela devrait toujours être suivi d’une relecture humaine pour les flux critiques.

Construisez un workflow de mise en production et d’assurance qualité

Un bon processus de localisation consiste moins à traduire plus vite qu’à livrer moins de surprises.

Étape 1. Choisissez les locales cibles de manière délibérée

Ne commencez pas par « tout traduire dans 20 langues ».

Commencez par :

votre mix de téléchargements actuel
les pays que vous supportez activement
la couverture en facturation, juridique et support client
la possibilité de localiser l’application et la fiche du store ensemble

Livrer un marché de bout en bout bat généralement livrer cinq marchés à moitié.

Étape 2. Créez des ressources prêtes pour la localisation

Avant que la traduction ne commence, figez et préparez :

les chaînes sources avec contexte
la liste des captures d’écran par locale
le glossaire et les règles de noms de produits
les règles pour les espaces réservés
les indications de limite de caractères pour le texte du store
les responsables de relecture par locale

Si l’application utilise des dépôts séparés ou plusieurs formats de fichiers, standardisez le nommage et l’extraction tôt.

Étape 3. Testez d’abord avec la pseudolocalisation

Sur les plateformes Apple, utilisez les pseudo-langues à longueur doublée et droite-à-gauche. Sur Android, testez les locales non supportées, Force RTL et les paramètres de langue par application. Cela détecte :

les boutons tronqués
les en-têtes coupés
le texte masqué
l’alignement incorrect
les chaînes non localisées
les hypothèses codées en dur gauche/droite

C’est l’un des passages d’assurance qualité les moins coûteux que vous puissiez effectuer.

Étape 4. Effectuez une QA linguistique sur de vrais appareils

Après l’arrivée des traductions :

testez les flux critiques dans chaque langue cible
comparez le comportement entre la langue du système et la langue de l’application
vérifiez le comportement des pluriels et des espaces réservés
contrôlez les paiements, les dates et les adresses
relisez les captures d’écran et les fiches du store dans le marché cible

Si un bug affecte l’intégration, le paiement, la vérification d’identité ou les notifications, traitez-le comme un bloquant de mise en production.

Checklist pour un premier sprint de localisation

Si c’est votre premier déploiement sérieux, gardez le sprint suffisamment petit pour le terminer proprement :

Cette checklist est intentionnellement limitée. Une seule locale avec une expérience applicative propre et des ressources de store synchronisées vous en apprend bien plus qu’un lancement précipité sur de nombreux marchés.

Exemples concrets

Les idées fondamentales ci-dessus ne sont pas théoriques.

DoorDash a traité la traduction comme un problème de plateforme

En 2022, DoorDash a déclaré avoir déjà traduit plus d’un million de chaînes dans quatre langues et réduit l’intégration de nouvelles langues de plusieurs heures d’effort développeur à une seule commande en une minute. La leçon intéressante n’est pas seulement l’échelle. C’est la structure : DoorDash a séparé les chaînes statiques et dynamiques, ajouté un support de glossaire et de guide de style, et construit des garde-fous pour empêcher les chaînes non traduites de passer à travers les mailles du filet.

Dans un article de blog DoorDash du 2 février 2026, l’entreprise a déclaré que sa plateforme d’intégration reconstruite alimente désormais les inscriptions sur tous les marchés DoorDash et permet des lancements internationaux rapides avec une localisation fluide. C’est exactement à quoi ressemble une localisation mature : des workflows réutilisables, une flexibilité régionale et moins de solutions ad hoc.

Meta a traité la localisation à la fois comme un problème linguistique et un problème de taille d’application

Meta indique qu’environ 57 % des utilisateurs de Facebook pour Android et 49 % des utilisateurs de Facebook pour iOS utilisent l’application dans une langue autre que l’anglais. Dans le même article, Meta indique que la suppression des fichiers de traduction intégrés a permis d’économiser jusqu’à 16,6 Mo dans l’application iOS et a permis à Android d’ajouter près d’une douzaine de langues supplémentaires sans augmenter la taille de l’application.

La leçon est utile même pour les petites équipes : la localisation a des conséquences techniques. Elle affecte la taille du binaire, le chargement à l’exécution, la livraison des traductions et la mécanique de release, pas seulement la rédaction.

Checklist finale avant la mise en production

Utilisez ceci comme dernière vérification :

Toutes les chaînes visibles par l’utilisateur sont externalisées.
Les ressources de repli par défaut sont complètes.
Les pluriels et les espaces réservés utilisent le support de localisation natif de la plateforme.
Les dates, heures, nombres, devises et unités sont sensibles aux locales.
Les mises en page RTL et le texte bidirectionnel ont été testés.
Le texte de la fiche du store est localisé pour les marchés cibles.
Les captures d’écran et les aperçus sont localisés pour les langues prioritaires.
La sélection de langue in-app fonctionne comme prévu sur iOS et Android.
La QA linguistique a couvert les parcours utilisateurs les plus importants.

Conclusion

La manière la plus simple de penser à la localisation d’une application mobile est celle-ci : traduisez le produit, localisez l’expérience et testez la mise en production.

Si vous faites cela pour la première fois, ne visez pas une couverture mondiale parfaite dès le premier jour. Choisissez une ou deux locales stratégiques, localisez l’application et la page du store ensemble, effectuez un passage sérieux d’assurance qualité et apprenez de l’usage réel. Si vous gérez déjà des fichiers de ressources et du contenu orienté développeurs, associez ce workflow avec Comment traduire des documents techniques sans casser le code et Meilleurs traducteurs JSON en 2026.

Si vous ne devez retenir qu’une seule action cette semaine, faites ceci : choisissez 1 locale, effectuez 1 passage de pseudolocalisation et localisez 1 fiche App Store ou Google Play correspondante. Ce test en trois parties vous en dira plus sur votre état de préparation que de traduire vingt locales en parallèle.

Si vous avez besoin d’un premier passage rapide pour le texte de l’application, les captures d’écran ou les fichiers de langue structurés, utilisez l’automatisation pour accélérer le brouillon, puis conservez une étape de QA humaine avant la mise en production. C’est la partie qui protège la confiance des utilisateurs et empêche un lancement « traduit mais pas vraiment localisé ».

Références

Apple Developer. Localization. https://developer.apple.com/localization/
Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/