Localisation d'applications mobiles : guide de ressources complet

La localisation (souvent abrégée en L10n) est le travail d'adaptation d'une application, de sa présence dans le store et du marketing qui l'accompagne pour les utilisateurs dans des langues, régions et contextes culturels spécifiques. C'est plus que de la traduction. Une localisation complète inclut le copy d'UI traduit, les métadonnées du store traduites, les légendes de captures d'écran traduites, le formatage de devise et de date correct selon la langue, l'imagerie culturellement appropriée, les méthodes de paiement spécifiques à la région (UPI en Inde, Pix au Brésil, iDEAL aux Pays-Bas) et les divulgations légales adaptées. Sauter l'un quelconque de ces éléments donne aux utilisateurs locaux l'impression d'un produit étranger à demi-effort.

L'App Store et Google Play font apparaître automatiquement les fiches localisées aux utilisateurs dans leur langue préférée — si vous les avez fournies. Si vous ne l'avez pas fait, l'utilisateur voit votre fiche anglaise par défaut, ce qui supprime significativement la conversion sur les marchés non anglophones. La question est rarement « devrions-nous localiser » mais « quels marchés en premier, et à quelle profondeur ».

Les données publiées par Apple et Google confirment ce que la recherche ASO indépendante montre régulièrement : les captures d'écran localisées font bien plus bouger la conversion d'installation que les titres ou descriptions localisés. La raison est la densité d'information. Une capture d'écran communique le produit, la couverture linguistique, le raffinement de la marque et l'adéquation culturelle en un seul moment visuel. Un titre localisé ne communique que le fait que l'application existe dans votre langue.

Le gain n'est pas uniforme. Les marchés est-asiatiques (Japon, Corée, Chine, Taïwan) affichent historiquement le plus grand gain d'installation grâce aux captures d'écran localisées — souvent 30 à 60 % par rapport aux valeurs par défaut anglaises — parce que ces marchés sont les plus sceptiques face aux fiches non localisées. Les marchés européens sont généralement à 10 à 25 % de gain, et les marchés non anglophones avec une bonne maîtrise de l'anglais (Pays-Bas, Suède, Finlande) ne voient parfois que 5 à 15 %. Planifiez l'investissement en localisation par gain attendu, pas par taille de marché seule.

Pour la plupart des applications, les localisations de première vague au plus haut ROI sont : allemand (de), français (fr), espagnol (es), italien (it), portugais (Brésil) (pt-BR), japonais (ja), chinois simplifié (zh-Hans) et coréen (ko). Cela couvre les marchés avec le plus grand volume d'installations + le plus grand gain de localisation. Une seconde vague ajoute souvent : russe (ru), polonais (pl), néerlandais (nl), turc (tr), arabe (ar), vietnamien (vi) et chinois traditionnel (zh-Hant).

Apple et Google prennent en charge significativement plus de langues que cela (Apple a plus de 175 combinaisons langue/pays), mais la longue traîne justifie rarement l'effort sauf si votre produit a une adéquation marché spécifique là-bas. Commencez par les huit, mesurez le gain de conversion par marché, et étendez vers les marchés qui retournent le signal le plus fort.

Trois approches : (1) Envoyer les légendes à un service de traduction professionnel (Smartling, Lokalise, Crowdin) — la plus haute qualité, la plus lente, la plus chère par langue. (2) Utiliser un LLM (GPT-4o, Claude, Gemini) pour une première passe et faire réviser par des locuteurs natifs — rapide, peu cher, étonnamment bon pour le copy marketing court. (3) Embaucher des contractuels locuteurs natifs directement via Upwork ou Fiverr — souvent le meilleur équilibre pour les équipes en début de phase.

Quoi que vous choisissiez, ne traduisez jamais une légende de capture d'écran à la machine et ne la livrez pas sans révision humaine. Le copy marketing est trop important pour une traduction automatisée non révisée. Le coût d'une légende japonaise maladroite est de centaines d'installations perdues ; la révision coûte 5 à 20 $ par langue.

C'est là que la plupart des équipes butent. Traduire « 19,99 $/mois » en « 19,99 $/Monat » est faux dans une fiche allemande — cela devrait être « 19,99 €/Monat ». Conversion de devise à parité de pouvoir d'achat équitable, séparateurs décimaux corrects selon la langue (virgule dans la plupart de l'Europe, point aux US/UK), systèmes d'unités (cm vs pouces), formats de date (JJ/MM/AAAA vs MM/JJ/AAAA vs AAAA-MM-JJ) et formats d'heure (12h vs 24h) doivent tous se rendre par langue.

Le pattern le plus propre consiste à garder toutes les valeurs dépendantes de la langue hors du modèle de capture d'écran lui-même et à les injecter au moment du rendu depuis un fichier de données par langue. C'est à cela que servent les modèles dynamiques et la configuration YAML : un modèle, N fichiers de données par langue, M rendus.

L'arabe, l'hébreu, le persan et l'ourdou sont des écritures de droite à gauche. Localiser les captures d'écran pour ces marchés signifie plus que d'échanger le texte — la mise en page entière se reflète généralement. Le bouton CTA passe de la droite à la gauche, les barres de navigation s'inversent, les indicateurs de progression changent de direction, et même certaines iconographies (flèches arrière, boutons d'envoi) doivent être reflétées.

Pour les marchés RTL, traitez le modèle de capture d'écran comme un artefact distinct, pas comme une superposition de traduction. Le gain d'une capture d'écran arabe correctement reflétée vs une capture d'écran arabe de gauche à droite est important ; le gain d'amélioration d'une capture d'écran déjà reflétée est petit. Faites d'abord la mise en page correctement.