2026-08-07 · Localisation · 6 min de lecture

Cross-localisation App Store : l'espace mots-clés gratuit que la plupart des apps gaspillent

TL;DR. Chaque boutique de l'App Store indexe plus d'une langue. La boutique US lit ton champ mots-clés en anglais (États-Unis) et un ensemble de locales secondaires — l'espagnol (Mexique) en fait partie. Le Canada lit l'anglais et le français. La plupart des autres boutiques lisent leur propre langue plus l'anglais (Royaume-Uni). Si tu remplis le nom, le sous-titre et le champ mots-clés de la locale secondaire avec des termes distincts, tu doubles à peu près l'espace de mots-clés sur lequel Apple peut te classer dans cette boutique — sans coût supplémentaire. Copie-colle les mêmes mots et tu n'obtiens rien, car Apple compte chaque mot une seule fois et ne relie jamais des mots de deux locales différentes pour former une expression. Le tableau de référence ci-dessous indique quelles locales chaque boutique indexe.

Il existe une astuce sur les champs mots-clés qui se trouve juste dans App Store Connect, ne coûte rien, et que la plupart des apps laissent inexploitée. Ce n'est ni une faille ni une infraction aux règles. C'est simplement qu'Apple indexe plus d'une langue par boutique, et que presque personne ne remplit la seconde.

Voici le mécanisme. Chaque territoire de l'App Store a une locale principale — la langue par défaut de ce marché — et une ou plusieurs locales secondaires que l'algorithme de recherche d'Apple explore également. Les mots-clés de l'une ou l'autre locale peuvent te faire apparaître dans ce pays. La boutique US ne lit donc pas seulement tes champs en anglais (États-Unis) ; elle lit aussi tes champs en espagnol (Mexique). Remplis les deux avec des termes différents et tu as donné à Apple deux ensembles de mots-clés sur lesquels te classer au lieu d'un seul.

Pourquoi c'est un espace gratuit

Une seule locale te donne trois champs indexés : un nom d'app de 30 caractères, un sous-titre de 30 caractères et un champ mots-clés de 100 caractères. Soit 160 caractères indexés par locale. La description n'est pas indexée pour la recherche sur l'App Store, donc ces 160 caractères sont tout le jeu.

Une locale secondaire est un second ensemble des mêmes trois champs, qui alimente le classement de la même boutique. Remplis le champ mots-clés es-MX pour une app US et tu passes de 100 caractères de mots-clés cachés à environ 200 — plus un second sous-titre de 30 caractères qu'Apple indexera aussi. Même audience, même boutique, surface à peu près doublée. Tu ne paies rien pour ça, tu n'as pas besoin d'utilisateurs hispanophones pour en profiter, et tu n'as pas besoin d'une fiche séparée — tu arrêtes simplement de laisser le champ vide.

Si cet espace est « gaspillé », c'est parce que le champ est presque toujours vide ou, pire, rempli d'une copie de la locale principale. Dans les deux cas, l'occasion est perdue.

Le tableau de référence : quelles locales chaque boutique indexe

Voici la carte à mettre de côté. Pour chaque boutique, elle indique la locale principale qu'Apple indexe et la ou les locales secondaires également explorées. Correspondances documentées par les outils ASO en 2026 — Apple les ajuste au fil du temps, donc confirme tes marchés clés dans App Store Connect ou ton outil ASO avant d'écrire :

Japon Japonais — ja Anglais (États-Unis) — en-US

*La boutique US fait figure d'exception : en plus de l'es-MX, elle indexe aussi le français, le chinois simplifié, le chinois traditionnel, le coréen, le portugais (Brésil), le russe, l'arabe et le vietnamien — neuf locales secondaires au total.

Deux tendances ressortent de ce tableau. D'abord, l'anglais (Royaume-Uni) est la locale secondaire de référence — indexée comme locale de secours dans la grande majorité des boutiques non anglophones, ce qui fait du champ en-GB le plus précieux à remplir si tu vends à l'international. Ensuite, les US sont exceptionnellement généreux avec neuf locales secondaires, ce qui explique pourquoi le coup de l'es-MX est le plus souvent cité.

Le piège : uniquement des termes distincts

Le doublement n'a lieu que si la seconde locale contient des mots que la première n'a pas. Deux règles d'Apple rendent cela précis, et toutes deux vont à l'encontre de l'approche paresseuse :

Chaque mot est indexé une seule fois. Si un terme apparaît à la fois dans le champ mots-clés principal et secondaire, le doublon ne sert à rien. Copie ta liste de mots-clés en-US dans es-MX et tu as brûlé le second champ pour zéro portée supplémentaire.
Les mots ne sont pas combinés entre locales. Apple forme des expressions à plusieurs mots au sein d'une seule localisation, jamais entre deux. Mets « budget » en en-US et « presupuesto » en es-MX et tu peux te classer sur chaque mot séparément — mais tu ne te classeras pas sur une expression qui relie l'un à l'autre.

La bonne approche n'est donc pas de traduire tes mots-clés principaux dans le champ secondaire. C'est d'y mettre un ensemble de mots totalement différent — les termes qui n'ont pas tenu dans les 100 premiers caractères, des synonymes, des cas d'usage voisins, des variantes de longue traîne. Le second champ est un espace de débordement, pas un miroir.

C'est aussi pourquoi une passe naïve de « tout traduire » aggrave le problème au lieu de le résoudre. Traduire automatiquement ton champ mots-clés anglais en espagnol produit les mêmes concepts dans une autre langue, ce qui, pour une boutique partagée, reste un doublon de sens et souvent de correspondance pour Apple. La valeur est dans la diversification du second champ, pas dans la traduction mot à mot du premier.

Comment vraiment exploiter le second champ

Un exemple concret pour une app de budget US. Les champs principaux en en-US portent déjà les termes évidents — disons que le nom est Ledger: Budget & Money et le sous-titre Track spending and savings, avec le champ mots-clés en-US contenant expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit.

Le champ mots-clés es-MX est alors libre de porter un tout autre lot de mots isolés — aucun ne répétant le nom, le sous-titre ou le champ en-US — par exemple subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement. C'est un second champ de 100 caractères qui alimente le même classement US, rempli de termes qu'Apple ne pouvait pas voir avant. Ajoute un sous-titre es-MX distinct et tu as aussi étendu le signal nom-plus-sous-titre.

La même logique s'applique à toute échelle du tableau. Une app allemande remplit en-GB avec des termes anglais de débordement. Une app canadienne remplit fr-CA. Une app brésilienne remplit en-GB. Dans chaque cas, le second champ contient des termes distincts, pas une traduction, et chaque terme décrit toujours honnêtement l'app — ce qui te tient à l'écart de la directive 2.3.7 d'Apple sur les mots-clés non pertinents ou de marques déposées.

Pourquoi c'est un travail de recherche, pas de traduction

La raison pour laquelle la plupart des apps gaspillent cet espace, c'est que le remplir correctement demande un vrai travail. Il te faut un ensemble de mots-clés pour la locale principale, puis un second ensemble, sans chevauchement, pour la locale secondaire, et ce pour chaque boutique qui t'intéresse. Multiplie par les 50 langues de métadonnées de l'App Store et le nombre de champs secondaires à garder distincts grandit vite. On comprend pourquoi les équipes finissent soit par sauter le champ secondaire, soit par y coller le champ principal et passer à autre chose.

Mokbi est l'endroit où vivent la rédaction et le suivi de tout ça. C'est un véritable outil de publication de fiche store, pas juste un éditeur de captures d'écran : le parcours suit Screenshots → Feature graphic → Store text → Translate → Publish, et il rédige le texte de la fiche — nom, sous-titre, champ mots-clés, description — et gère un ensemble de mots-clés par locale sur 50 langues, pour que tu puisses voir, côte à côte, ce que contient chaque champ et où tu te répètes par inadvertance.

Soyons clairs sur ce que l'outil fait et ne fait pas ici : il n'invente pas magiquement des mots-clés secondaires distincts tout seul, et une traduction en un seul passage dupliquerait tes termes au lieu de les diversifier. La cross-localisation est une stratégie que toi pilotes — décider quelles locales secondaires cibler, écrire un ensemble de mots séparé pour chacune, et éviter qu'ils se chevauchent. Mokbi te donne les champs par locale pour rédiger et organiser tout ça à un seul endroit plutôt que dans un tableur, puis exporte la fiche pour que tu la relises et la publies toi-même dans App Store Connect.

La version en un paragraphe

Repère quelle locale secondaire tes principales boutiques indexent — le tableau ci-dessus couvre les grandes, ton outil ASO couvre le reste. Remplis le nom, le sous-titre et le champ mots-clés de cette locale secondaire avec des termes distincts que tu n'as pas pu caser dans la locale principale. Ne duplique jamais un mot entre les deux, et n'attends jamais qu'Apple construise une expression à cheval sur les deux. Bien fait, c'est l'expansion de mots-clés la moins chère de l'App Store, et elle se trouve dans un champ que tu as déjà.

Se connecter à Mokbi