Tests de localisation des applications mobiles : la liste de contrôle iOS et Android pour les sorties mondiales

Votre application fonctionne parfaitement en anglais. Puis le marketing programme un lancement en Allemagne, au Japon et au Brésil, et soudain le bouton « Continue » devient « Weitermachen », la notification push arrive à 3 h du matin heure locale, et les captures d’écran de l’App Store affichent toujours des prix en dollars américains. Rien de tout cela n’est un problème de traduction. C’est un problème de QA mobile, et cela ne ressemble en rien à la QA que vous avez menée pour la version anglaise.

Les tests de localisation des applications mobiles vérifient qu’une application traduite s’affiche, fonctionne et se fait découvrir correctement sur les appareils iOS et Android, dans chaque marché cible. Cet article se concentre sur ce qui change réellement lorsque la QA de localisation passe du bureau au téléphone : les API de la plateforme, les deux stores, le contenu des notifications push, le clavier et la matrice d’appareils physiques. Les définitions générales et le processus de bout en bout sont traités séparément dans notre aperçu de ce qu’est la QA de localisation. Tout ce qui suit est spécifique au mobile.

Les enjeux méritent d’être précisés. Sensor Tower rapporte que les revenus mondiaux des achats intégrés ont atteint 167 milliards de dollars en 2025, en hausse de 10,6 % sur un an, une croissance tirée par les marchés non anglophones d’Europe occidentale, d’Amérique latine et d’Asie-Pacifique. Un bug de localisation sur un marché important se répercute directement sur le chiffre d’affaires.

Ce que nous vérifions dans la QA de localisation mobile

La qualité de la traduction n’est qu’un des éléments de la QA de localisation, et à elle seule, elle ne couvre peut-être qu’un quart de ce qui peut poser problème. Lorsqu’une version arrive sur nos appareils, nous examinons quatre surfaces en parallèle, et un bug dans l’une d’entre elles peut compromettre tout un lancement. C’est également là que se concentre l’essentiel du travail dans nos services de tests de localisation.

Exactitude linguistique en contexte

Une chaîne qui se lit parfaitement dans un tableur peut devenir incorrecte dès qu’elle se retrouve dans un bouton. « Save », traduit par l’espagnol « Guardar », convient sur une page de réglages mais prête à confusion sur un panier d’achat, où « Guardar » évoque plutôt « garder pour plus tard » que « confirmer ». Nos testeurs vérifient les chaînes dans leur contexte réel d’interface, sur un écran réel, avec de vraies données qui y transitent. Les paramètres comme {username} et {count} reçoivent une attention particulière, car une variable cassée ressemble souvent à une simple faute de frappe jusqu’à ce que quelqu’un remarque qu’elle ne se résout jamais.

Intégrité de l’interface après l’intégration des chaînes

Le texte traduit a une longueur. L’allemand est environ 30 % plus long que l’anglais, le finnois n’est pas loin derrière, et les écritures CJC occupent moins d’espace horizontal mais ont une hauteur de ligne plus importante. Sur un canevas d’iPhone de 375 pixels, cette différence se traduit soit par un retour à la ligne harmonieux, soit par la rupture des barres d’onglets, des en-têtes de navigation et des boutons d’appel à l’action. Nous vérifions la troncature du texte, le chevauchement des boutons, les collisions avec la zone de sécurité sur les appareils à encoche, et la manière dont la mise en page résiste au Dynamic Type sur iOS et à l’échelle de police sur Android.

Comportement sensible à la locale

Les dates, les devises, les formats de numéro de téléphone, les unités de mesure, et même l’ordre de tri changent selon la région de l’utilisateur. Un prix affichant « 1,000.00 EUR » en Allemagne devrait s’afficher localement « 1.000,00 € », avec le symbole après le nombre. Sur iOS et Android 13 et versions ultérieures, la région est indépendante de la langue, si bien qu’un utilisateur peut lire l’application en anglais tout en s’attendant à des unités métriques et à un format horaire sur 24 heures. C’est là que les tests de localisation pour les applications mobiles deviennent moins évidents : un mauvais formateur est un bug fonctionnel.

Les surfaces des stores que les utilisateurs voient avant d’installer

La première surface localisée que la plupart des utilisateurs rencontrent est la fiche du store, pas l’application elle-même. Le titre, le sous-titre, la description, les captures d’écran et la vidéo de présentation doivent correspondre à la langue de l’application dans laquelle ils atterriront après avoir appuyé sur Installer. Si la page de l’App Store promet de l’allemand et que l’application s’ouvre en anglais, la section des avis se remplit de plaintes à une étoile en moins de 48 heures.

Où iOS et Android divergent en matière de localisation

Android représente environ 71 à 73 % des expéditions mondiales de smartphones jusqu’en 2026, tandis qu’iOS capte la majorité des dépenses des consommateurs en applications, selon le Worldwide Quarterly Mobile Phone Tracker d’IDC. Les deux sont nécessaires, et les deux plateformes gèrent la locale de manière véritablement différente.

Mécanismes de locale sur iOS

iOS stocke les traductions dans des fichiers .strings pour les paires clé-valeur simples et des fichiers .stringsdict pour les pluriels et les formes genrées. Info.plist déclare les locales prises en charge par le bundle via CFBundleLocalizations. NSLocalizedString récupère la bonne chaîne à l’exécution en fonction des langues préférées de l’utilisateur, résolues via le Bundle. Depuis iOS 13, les utilisateurs peuvent choisir une langue différente par application dans Réglages → App → Langue, sans changer la langue de tout l’appareil, ce qui signifie que la QA doit changer de langue en cours de session et vérifier que les chaînes mises en cache se rafraîchissent.

Mécanismes de locale sur Android

Android utilise des dossiers de ressources qualifiés : values/, values-fr/, values-b+es+419/ pour l’espagnol d’Amérique latine. Les chaînes se trouvent dans strings.xml, les pluriels dans plurals.xml, et Android parcourt une chaîne de repli si une locale est manquante. Depuis Android 13 (API 33), LocaleManager et AppCompatDelegate.setApplicationLocales() permettent la sélection de la langue par application. La prise en charge de droite à gauche nécessite android:supportsRtl=”true” dans le manifeste, ainsi que les attributs de mise en page start/end plutôt que left/right.

Un tableau comparatif rapide à garder sur votre tableau blanc QA :

La liste de contrôle QA propre au mobile

Voici six vérifications qui ne comptent que sur un téléphone. Sautez-en une seule, et le lancement s’en ressentira. Les sections ci-dessous varient dans leur forme, car les vérifications elles-mêmes varient : certaines se prêtent à la prose, d’autres à une liste.

Expansion du texte sur un canevas de 375 pixels

Faites de la pseudo-localisation avant l’arrivée des vraies traductions. Remplacez les chaînes anglaises par des variantes latines allongées (« Sëttîngß » au lieu de « Settings ») pour forcer un stress test de la mise en page à chaque build. Vérifiez l’orientation paysage, l’affichage partagé sur iPad, et l’échelle de police réglée à 200 % pour l’accessibilité. Les boutons qui paraissent déjà serrés en anglais casseront en allemand le jour où les traductions arriveront, et à ce moment-là, le sprint sera déjà terminé.

Mise en page RTL sur une interface tactile

L’arabe, l’hébreu, l’ourdou et le persan retournent entièrement l’interface. Les gestes de navigation s’inversent, les chevrons se reflètent, les barres de progression se remplissent depuis le bord opposé, et les curseurs de défilement vidéo se déplacent dans la direction opposée. Les icônes évoquant un mouvement doivent être inversées, tandis que les marques et logos de la marque restent inchangés. Vérifiez que l’appareil est bien réglé sur l’arabe, et testez les surfaces que la plupart des équipes oublient : l’historique des transactions, l’alignement des messages de chat, les erreurs de validation de formulaire, et tout graphique dessiné sur mesure.

Notifications push par locale

La localisation des notifications push pose des problèmes difficiles à détecter sans tests dédiés. APNs prend en charge loc-key et loc-args, et FCM prend en charge title_loc_key et body_loc_args, qui permettent tous deux au système d’afficher les notifications dans la langue actuelle de l’appareil plutôt que dans la langue supposée par votre serveur au moment de l’envoi. Cela compte, car un utilisateur peut changer la langue de l’application après avoir enregistré son jeton push. Les testeurs devraient vérifier :

• La troncature du corps de la notification sur l’écran de verrouillage, environ 60 caractères sur iOS et 65 sur Android, selon l’appareil.
• Les envois programmés dans le temps sont basés sur le fuseau horaire du destinataire plutôt que sur l’UTC. Une notification « bonjour » programmée à 8 h UTC arrive à Tokyo à 17 h.
• Les heures calmes, le mode Ne pas déranger et le comportement du mode Focus selon la région.
• Les images de notification enrichies avec un contenu spécifique à la locale, le cas échéant.

Formateurs au niveau du système, pas de chaînes codées en dur

Partout où vous voyez une date, une devise, un numéro de téléphone ou une unité de mesure dans l’interface, vérifiez qu’elle passe par le formateur de la plateforme. Sur iOS, cela signifie DateFormatter, NumberFormatter et MeasurementFormatter. Sur Android, DateFormat.getDateInstance() et NumberFormat.getCurrencyInstance(). Un formatage codé en dur comme String.format(“$%.2f”, price) est la source la plus courante de bugs de locale, et l’une des plus faciles à détecter en revue de code avant même d’atteindre la QA.

Claviers, correction automatique et dictée

Les IME japonais, chinois et coréens modifient la hauteur du champ de saisie lorsque le bandeau de suggestions apparaît, ce qui peut pousser un bouton de validation sous le clavier sur les petits écrans. Le cyrillique et le devanagari nécessitent une expression régulière de validation des caractères différente de celle des écritures latines. La correction automatique peut altérer silencieusement un nom propre dans une langue et le laisser intact dans une autre. Testez chaque champ de formulaire avec le clavier réel que l’utilisateur cible utilisera, et non le clavier anglais par défaut.

Changement de locale sur l’appareil sans redémarrage

iOS 13+ et Android 13+ permettent tous deux aux utilisateurs de changer la langue de l’application sans redémarrer l’appareil. Si votre application met en cache les chaînes au lancement et ne les relit jamais, la moitié de l’interface reste dans l’ancienne langue jusqu’à ce que l’utilisateur force la fermeture de l’application. Changez de langue en cours de session en QA, parcourez chaque parcours principal, et confirmez que chaque écran se met à jour. Ce bug est courant, silencieux, et ne se révèle que sur des appareils réels avec de vrais utilisateurs. Le même écart lié aux appareils réels apparaît dans l’ensemble plus large des défis des tests mobiles, où les bugs de locale et les particularités des fabricants ont tendance à se regrouper.

QA de la localisation des fiches App Store et Play Store

Les métadonnées du store ne sont pas l’application, mais elles constituent la première surface localisée qu’un utilisateur voit. Deux stores, deux flux de travail, deux ensembles de pièges, et les deux soumissions peuvent être rejetées pour des problèmes que la QA aurait dû détecter en premier.

App Store Connect

La localisation de l’App Store sur iOS passe par App Store Connect, où chaque locale dispose de son propre titre (30 caractères), sous-titre (30), champ de mots-clés (100), texte promotionnel (170), description (jusqu’à 4000), captures d’écran par taille d’appareil, vidéos de présentation, et texte « Nouveautés » par version. La localisation d’App Store Connect comporte un piège spécifique : le nombre de caractères est calculé en points de code, si bien que des katakana japonais ou des sinogrammes chinois dans un titre peuvent silencieusement dépasser la largeur visuelle même lorsqu’ils respectent le nombre autorisé. Vérifiez que les captures d’écran de chaque locale utilisent l’interface réellement localisée de l’application, plutôt que l’interface anglaise avec une légende traduite collée par-dessus.

Console Google Play

La localisation du Play Store sur Android est gérée dans Google Play Console sous Fiche du store, avec titre (30), description courte (80), description complète (4000), image de présentation, captures d’écran et vidéo promotionnelle par langue. Les fiches de store personnalisées vous permettent de proposer un contenu différent selon le pays, l’état de pré-inscription ou l’état d’installation. Le formulaire de Sécurité des données doit également être localisé. Une vérification à ne pas négliger : confirmer que la traduction automatique de Google Play est désactivée si vous avez livré des traductions humaines, car des métadonnées traduites automatiquement superposées à un contenu humain créent un texte incohérent pour l’utilisateur et nuisent à la conversion.

Une fiche de store qui promet une localisation complète alors que l’application elle-même reste à moitié traduite récoltera des avis à une étoile plus vite que toute autre erreur de lancement. Les notes chutent, et le classement ASO suit.

Le problème de la matrice d’appareils réels

Les émulateurs mentent sur le rendu des locales. Xiaomi livre MIUI avec sa propre pile de polices, capable de déformer les glyphes du devanagari et de l’arabe. La surcouche One UI de Samsung remplace certains comportements du Dynamic Type. Les anciens iPhones sans encoche ont des calculs de zone de sécurité différents, ce qui peut casser le texte de bannière localisé sur l’écran d’accueil. Les chaînes de repli des polices diffèrent selon les fabricants, et une chaîne en chinois qui s’affiche parfaitement sur un Pixel peut sembler défectueuse sur un téléphone Vivo pourtant populaire sur ce marché précis.

Une matrice d’appareils pragmatique pour un lancement en Allemagne, au Japon et au Brésil ressemble à ceci :

• iPhone 15, iPhone 13, iPhone SE (2ᵉ génération) couvrant les mises en page iOS actuelles et anciennes
• Pixel 8 comme référence Android
• Samsung Galaxy S23 pour le comportement de One UI
• Xiaomi Redmi Note 12 pour le rendu des polices de MIUI
• Une tablette par plateforme (iPad et n’importe quelle tablette Android de 10 pouces)

Nous testons uniquement sur des appareils réels, précisément pour ces raisons, et cela fait partie intégrante de notre pratique de tests d’applications mobiles sur plus de 300 produits. Les simulateurs ne peuvent pas reproduire les piles de polices propres aux fabricants, le comportement réel du clavier, ni la façon dont un modèle d’appareil précis affiche une notification sur son écran de verrouillage. Lorsqu’un bug apparaît sur un marché à cinq étoiles, il est presque toujours spécifique à l’appareil, et ce n’est presque jamais quelque chose que l’émulateur aurait détecté.

Avant de cliquer sur Envoyer

La QA de localisation mobile est l’endroit où la traduction, les API de plateforme, les soumissions aux stores et la fragmentation des appareils se rejoignent tous à la même date de lancement. Une seule couche mal gérée, et le marché dans lequel vous avez investi se refroidit. Les quatre bien gérées, et l’application paraît native dès que l’utilisateur l’ouvre, ce qui est précisément la raison d’être de la localisation. Si vous préparez un déploiement multi-marchés et souhaitez une QA qui a déjà rencontré ces modes de défaillance sur des centaines de produits, contactez-nous, et nous établirons un périmètre adapté à vos marchés cibles et à votre profil d’appareils.

FAQ

Comment testez-vous la localisation d’une application mobile ?

Commencez par basculer un appareil réel sur la locale cible, plutôt que de changer un paramètre sur un émulateur. Vérifiez les traductions en contexte sur chaque écran, contrôlez l’interface pour l’expansion et la troncature du texte, confirmez que les dates, devises et formats de téléphone utilisent les formateurs de la plateforme, testez les notifications push et leur minutage selon le fuseau horaire, et parcourez la fiche du store séparément dans App Store Connect et Google Play Console. Faites tout cela sur les appareils réellement populaires dans le marché cible, et non sur le matériel qui se trouve sur votre bureau.

Qu’est-ce que le test de localisation pour une application mobile ?

C’est une discipline de QA qui vérifie qu’une application mobile traduite fonctionne correctement pour les utilisateurs dans une langue, une région et un environnement d’appareil spécifiques. Elle couvre l’exactitude linguistique en contexte, l’intégrité de l’interface après l’expansion ou la contraction des chaînes, le formatage sensible à la locale pour les dates et les devises, le comportement des notifications push, les métadonnées de la fiche du store, et le rendu sur des appareils réels des fabricants populaires sur ce marché. La traduction seule n’en est qu’une partie.

Quelle est la différence entre les tests de localisation iOS et Android ?

Les plateformes gèrent la locale via des formats de fichiers, des API et des flux de soumission au store différents. iOS utilise des fichiers .strings et .stringsdict avec NSLocalizedString, et soumet des métadonnées par locale via App Store Connect. Android utilise des dossiers de ressources qualifiés et strings.xml avec getQuantityString, et gère les fiches par langue dans Google Play Console. Les réglages de langue par application sont arrivés avec iOS 13 et Android 13. La fragmentation est plus profonde sur Android, car les surcouches des fabricants comme MIUI et One UI modifient le rendu des polices, ce qui élargit la matrice d’appareils à tester.

Ai-je besoin d’appareils réels pour la QA de localisation ?

Oui. Les émulateurs ne peuvent pas reproduire les piles de polices propres aux fabricants, le comportement du clavier, le rendu des notifications sur de vrais écrans de verrouillage, ni la façon dont les appareils spécifiques à une région gèrent le repli des glyphes. Une chaîne en chinois qui s’affiche parfaitement sur un émulateur Pixel peut sembler cassée sur un téléphone Vivo qui domine ce marché. Presque tous les bugs de localisation qui atteignent les avis de l’App Store ou du Play Store sont spécifiques à un appareil, ce qui explique pourquoi les tests sur appareils réels sont une exigence incontournable pour un lancement mondial.