Quand les traductions dépassent les limites de caractères de la fiche store
Tu as écrit un nom d'app propre de 28 caractères, un sous-titre percutant de 29 caractères, et un champ de mots-clés qui utilise les 100 caractères disponibles. Puis tu as localisé la fiche et App Store Connect a commencé à rejeter des champs — le sous-titre allemand fait 41 caractères, le français 36. La version anglaise n'a jamais été le problème. Chaque langue a sa propre copie de chaque champ, et chaque copie doit tenir seule dans la même limite.
Voici la référence pour comprendre ces limites, pourquoi la traduction les dépasse, et comment garder une fiche lisible dans chaque langue au lieu de couper des mots en deux.
Les limites de caractères, sur les deux stores
Chaque chiffre ci-dessous s'applique par langue. Quand tu localises en français, en allemand, en japonais, etc., chaque langue conserve sa propre copie de chaque champ, et chacune est vérifiée par rapport au même plafond au moment de la soumission.
Deux points méritent d'être précisés. Le champ mots-clés de l'App Store est un emplacement caché de 100 caractères séparés par des virgules — invisible sur la page produit, mais c'est là que se joue une grande partie de ton référencement, donc chaque caractère compte. Et les champs les plus serrés — le nom et le sous-titre de 30 caractères — sont exactement ceux que la traduction touche le plus durement.
Pourquoi la version traduite dépasse la limite
Le même sens prend une place différente selon les langues. En traduisant depuis l'anglais, la tendance générale est assez cohérente pour être anticipée :
- Allemand : souvent +30 à 40%. Les mots composés fusionnent plusieurs mots anglais en un seul long mot, et il n'y a pas de synonyme plus court vers lequel se rabattre. C'est la langue qui dépasse le plus souvent un champ de 30 caractères.
- Français, espagnol, italien, portugais : environ +15 à 25%. Une expansion modérée et constante. Un nom qui tient confortablement en 24 caractères en anglais se retrouve proche ou au-delà de 30.
- Chinois, japonais, coréen : souvent environ 50% plus court en nombre de caractères. Les écritures CJK condensent plus de sens par caractère, donc la limite du champ est rarement la contrainte déterminante — c'est plutôt la lisibilité et le choix des mots.
- Arabe, hébreu et autres écritures RTL : attendez-vous à une expansion de +15 à 30% en plus d'une inversion de sens. Ces langues nécessitent une relecture humaine, jamais une traduction automatique brute — le texte bidirectionnel et les champs de mots-clés en écriture non latine sont là où les sorties automatisées dérapent silencieusement.
Considérez ces chiffres comme des fourchettes de planification, pas des garanties. L'essentiel, c'est la tendance : si un champ est proche de sa limite en anglais, suppose que les traductions européennes vont la dépasser et que les traductions CJK seront plus courtes. Prévois quelques caractères de marge dans la source anglaise pour laisser de la place à l'expansion.
À quoi ressemble concrètement un dépassement de limite
Apple comme Google appliquent les plafonds au moment de la soumission. En pratique, tu rencontres l'un des deux scénarios d'échec. Le formulaire du store refuse purement les caractères en trop — tu ne peux physiquement pas taper au-delà de la limite, donc une traduction collée est silencieusement coupée à la limite, en plein mot. Ou bien le champ accepte le texte et la fiche est rejetée en révision. Dans les deux cas, le nom ou le sous-titre traduit finit tronqué, défiguré par la coupe, ou absent sur ce marché.
Rien de tout cela n'est visible depuis la fiche anglaise. Ça apparaît langue par langue, une à la fois, généralement après que tu penses la fiche terminée.
La solution : transcréer, ne pas tronquer
Couper un sous-titre allemand au 30ᵉ caractère produit un demi-mot brisé qui sonne comme une bévue de machine aux yeux d'un locuteur natif. La bonne approche consiste à réécrire le nom et le sous-titre par langue pour qu'ils conservent la même intention tout en tenant dans la limite.
- Raccourcis d'abord la source. Un sous-titre anglais de 22 caractères survit à une expansion de 35% ; un de 29 caractères non. La marge en anglais est la correction la moins coûteuse.
- Transcrée les champs les plus serrés. Pour le nom et le sous-titre, choisis un synonyme plus court ou retire un mot de remplissage dans la langue cible plutôt que de traduire mot à mot. L'objectif est une expression qui tient et qui sonne naturellement, pas une correspondance littérale.
- Fais relire par un humain les champs RTL et en écriture non latine. L'arabe, l'hébreu et les listes de mots-clés en écriture non latine sont ceux où la traduction automatique se trompe de façons que tu ne peux pas repérer si tu ne lis pas l'écriture.
- Vérifie le nombre de caractères dans l'écriture cible, pas dans l'anglais. C'est le nombre de caractères que le store mesure, et il diffère selon la langue — donc il doit être mesuré après traduction, champ par champ.
Où Mokbi t'aide
Mokbi traduit toute ta fiche — nom, sous-titre, mots-clés, description — en 50 langues, et affiche le nombre de caractères par langue pour chaque champ au fur et à mesure. Les dépassements apparaissent directement dans l'éditeur, avant même que tu ne colles quoi que ce soit dans App Store Connect ou Play Console, ce qui te permet de repérer le sous-titre allemand de 41 caractères pendant que tu peux encore le raccourcir, plutôt qu'après un rejet.
C'est une première passe, pas une passe finale. Elle met chaque champ dans les limites et signale ceux qui ont dépassé, ce qui représente l'essentiel du travail. Mais tes marchés les plus stratégiques méritent quand même une relecture humaine — un locuteur natif pour confirmer que le nom transcréé sonne juste et que les champs RTL sont corrects. L'outil élimine les suppositions sur quels champs posent problème ; une personne confirme que ceux qui comptent le plus se lisent bien.