App Store Optimization : référencer son application

L’App Store Optimization regroupe les actions qui améliorent la visibilité et le taux de téléchargement d’une application sur l’App Store et sur Google Play. Deux leviers seulement : être trouvé par une requête, puis convaincre sur la fiche. Les deux stores publient leurs règles, et elles diffèrent sur presque chaque champ.

Ce que l’App Store Optimization décide réellement

Un store ressemble à un moteur de recherche doublé d’un point de vente. La requête et l’installation tiennent dans le même écran, à deux gestes d’intervalle.

Apple décrit le mécanisme sans détour. Ses résultats de recherche reposent sur la pertinence du texte, avec les correspondances trouvées dans le titre, le sous-titre, les mots-clés et la catégorie principale, puis sur le comportement des utilisateurs, dont les téléchargements, les notes et les avis. La catégorie principale et la catégorie secondaire optionnelle sont elles aussi indexées, précise la documentation Apple.

L’ASO travaille donc deux surfaces à la fois : l’apparition dans une liste de résultats, puis l’installation une fois la fiche ouverte. Négliger l’une produit des impressions sans téléchargement, ou une fiche soignée que personne n’atteint.

La comparaison avec le référencement d’un site web s’arrête vite. Aucun maillage externe à construire, aucune page à faire explorer, aucun article à publier chaque mois. Le texte utile tient en quelques centaines de caractères, et les signaux d’usage pèsent lourd dans le classement des stores : une note moyenne qui chute dégrade la visibilité et la conversion dans le même mouvement.

Tout ceci suppose une distribution par les stores : une application web installable n’a aucune fiche à optimiser, et le choix du type d’application mobile décide de l’existence même de ce travail.

Les champs que chaque store lit sur votre fiche

Les deux plateformes ne demandent ni les mêmes textes, ni les mêmes formats d’image, et leurs pages développeurs publient les limites exactes.

Du côté de la fiche Apple

• Nom de l’application : 30 caractères au maximum
• Sous-titre : 30 caractères, affiché sous le nom partout dans l’App Store
• Champ mots-clés : 100 caractères au total, termes séparés par des virgules sans espace
• Texte promotionnel : 170 caractères, affichés en tête de la description
• Visuels : jusqu’à dix captures et trois aperçus vidéo de trente secondes maximum

Le champ mots-clés occupe une place à part sur une fiche App Store : la firme le présente comme un signal de recherche, pas comme un argumentaire de vente.

Du côté de la fiche Google

La console de Google expose trois zones de texte : le nom de l’application, limité à 30 caractères, la description courte, limitée à 80 caractères, et la description longue, limitée à 4 000 caractères. Aucun champ caché ici. Le vocabulaire d’une fiche Google Play vit entièrement dans le texte que lisent les visiteurs.

Les règles de métadonnées de Google encadrent ce texte de près. Titres, icônes et descriptions doivent rester honnêtes, pertinents et convenables pour tous les publics. Sont proscrits les mots-clés répétitifs ou hors sujet, les mentions de performance dans la boutique du type « application de l’année » ou « numéro 1 », les émojis et caractères spéciaux répétés, et les majuscules intégrales en dehors d’un nom de marque.

Côté images, Google demande une icône de 512 par 512 pixels, une image de mise en avant de 1 024 par 500 pixels, et au minimum deux captures réparties sur différents types d’appareils pour publier. Le plafond monte à huit captures par type d’appareil. La documentation recommande au moins quatre captures d’au moins 1 080 pixels pour une application, et réserve surtout la vidéo d’aperçu aux jeux.

Choisir les mots-clés que vos utilisateurs tapent

Un utilisateur formule un problème, rarement le nom d’une fonctionnalité. Une application de suivi de chantier se cherche avec « compte rendu de visite » ou « photos de chantier », pas avec le nom interne du module. L’écart entre ces deux vocabulaires explique la plupart des fiches invisibles.

Apple publie une liste précise de ce qui gaspille les 100 caractères du champ dédié aux mots-clés de l’application :

• Les mots déjà présents dans le nom, le sous-titre ou la catégorie, à ne pas répéter
• Les pluriels d’un terme déjà saisi, traités comme des doublons
• Les termes génériques trop larges pour l’application, du type « app » ou « jeu »
• Les mots de liaison, qui consomment des caractères sans rien apporter
• Les caractères spéciaux, sauf s’ils appartiennent à l’identité de la marque

La même page interdit les marques déposées utilisées sans autorisation, les noms de célébrités et les noms d’applications concurrentes. Elle formule aussi l’arbitrage central de l’exercice : peser un bon classement sur des termes peu recherchés contre un classement plus bas sur des termes populaires.

Cet arbitrage conduit à la longue traîne. Trois requêtes précises qui amènent des utilisateurs qualifiés valent mieux qu’une requête large où votre fiche apparaît en vingtième position. Elles se récoltent dans les mots des utilisateurs : entretiens menés pour valider une idée de produit, messages reçus au support, avis déjà publiés.

Reste la place du nom de marque. Trente caractères laissent peu de marge : une marque courte, deux mots d’usage, et la limite est atteinte. Consacrez cet espace à ce que l’application fait, pas à un slogan.

La langue change la donne. La console Google Play propose d’ajouter des traductions de fiche, par traduction professionnelle ou automatique, et Apple tient une note moyenne distincte par territoire. Une fiche traduite mot à mot depuis l’anglais rate les requêtes locales : les utilisateurs d’un pays nomment leur problème autrement.

Notes, avis et conversion de la fiche

Les notes et avis jouent sur deux tableaux : ils pèsent dans la recherche, et ils décident à la lecture. Google indique que la note affichée est pondérée vers les notes les plus récentes, afin de refléter les changements apportés à l’application. Une mauvaise période se répare donc, à condition de livrer un correctif.

Apple fonctionne différemment. La note de synthèse est propre à chaque territoire de l’App Store, et se réinitialise au moment de la publication d’une nouvelle version. La firme recommande d’utiliser cette possibilité avec parcimonie : une fiche presque sans note décourage, et la réinitialisation n’efface pas les avis écrits.

La sollicitation se joue au bon moment. Apple autorise jusqu’à trois demandes de note sur une période de 365 jours, via une interface standard qui garde l’utilisateur dans l’application. Google applique de son côté un quota de temps à son interface d’avis intégrée, déconseille un bouton dédié, puisqu’un utilisateur ayant atteint son quota ne verrait rien s’afficher, et interdit toute question préalable du type « aimez-vous cette application ». Demandez la note après une tâche accomplie, jamais à l’ouverture.

Les réponses comptent autant que les notes. App Store Connect autorise une réponse à tous les avis, quelle que soit leur date ; l’auteur reçoit une notification et peut modifier son avis. Un défaut corrigé, signalé en réponse, transforme parfois une note basse en note haute.

Les reproches récurrents décrivent souvent un obstacle d’usage, parfois un défaut couvert par les règles d’accessibilité numérique d’une application : libellés absents, contrastes faibles, messages d’erreur illisibles.

Mesurer la fiche, puis corriger un élément à la fois

Les deux consoles livrent les chiffres nécessaires, sans outil tiers. Apple définit les impressions uniques comme le nombre de personnes qui voient l’icône de votre application sur l’App Store un jour donné, et le taux de conversion comme le rapport entre les téléchargements totaux et ces impressions uniques. Le détail par source distingue la navigation dans l’App Store, la recherche, les renvois depuis une autre application et les renvois web ; les téléchargements, eux, séparent premières installations et réinstallations.

Ces deux nombres orientent le diagnostic. Peu d’impressions signale un problème de vocabulaire ou de catégorie. Beaucoup d’impressions et peu d’installations signalent un problème de promesse, d’icône ou de captures d’écran.

Les tests se mènent dans les consoles. Apple propose de comparer jusqu’à trois variantes de page produit avec la version d’origine, en allouant à chaque variante un pourcentage du trafic choisi. Un test dure quatre-vingt-dix jours, ou s’arrête plus tôt à la main, et le tableau de bord affiche impressions, taux de conversion, écart en pourcentage et niveau de confiance.

Google documente des expériences de fiche équivalentes et conseille de tester en priorité icône, vidéo et captures. Deux recommandations méritent d’être suivies à la lettre : un seul élément à la fois pour obtenir un résultat lisible, et une semaine minimum pour absorber la différence entre semaine et week-end. La console suit l’acquisition et la rétention à un jour pour chaque version de fiche.

Le rythme se cale sur les livraisons. Chaque mise à jour technique devient une occasion de retoucher un champ ou de remplacer une capture devenue fausse. Cette charge se provisionne au même titre que la maintenance, dans le budget de création d’une application.

Les erreurs fréquentes et trois mois de feuille de route

Les mêmes fautes reviennent d’un projet à l’autre :

• Un titre bourré de mots-clés, contraire aux règles de métadonnées de Google et inutile chez Apple, qui déconseille de répéter dans le champ mots-clés les termes déjà présents dans le nom
• Des captures génériques : un écran de connexion, un menu, aucune trace du résultat attendu par l’utilisateur
• Une description longue consacrée à l’entreprise et à son histoire plutôt qu’à l’usage de l’application
• Une demande de note déclenchée au premier lancement, avant la moindre réussite
• Une fiche jamais traduite, alors que les notes et les classements se jouent territoire par territoire
• Dix modifications livrées le même jour, qui rendent toute mesure impossible

Le travail d’App Store Optimization se planifie mieux sur un trimestre que sur une semaine, en trois étapes.

Le premier mois sert à l’inventaire. Relevez les caractères réellement utilisés dans chaque champ, les impressions uniques, le taux de conversion, la note par territoire et les sources de téléchargement. Écrivez ensuite la liste des requêtes visées, classées par intention.

Le deuxième mois traite le texte. Nom, sous-titre et champ mots-clés du côté d’Apple, nom, description courte et description longue du côté de Google. Une modification, une date notée, deux semaines d’observation avant la suivante.

Le troisième mois traite les visuels et les avis. Lancez un test de page produit ou une expérience de fiche sur un seul élément, répondez aux avis en attente en commençant par les notes basses, et corrigez ce qui revient trois fois. Quand le reproche porte sur le parcours lui-même, le chantier quitte la fiche et rejoint l’UX design.

Prochaine étape : ouvrez votre fiche sur un téléphone que vous n’utilisez jamais et comptez les secondes avant de comprendre ce que fait l’application. Au-delà de cinq, le premier chantier est trouvé.