Test A/B sur l'App Store : mener une expérience vraiment concluante

Le graphique devient séduisant bien avant de devenir fiable

Une nouvelle capture prend la tête au bout de quarante-huit heures. Elle affiche 16 % de mieux que la version d'origine, l'équipe aime déjà son style et la tentation d'arrêter est forte. Pourtant, avec peu de visites, quelques utilisateurs très motivés suffisent à créer cet écart. La semaine suivante peut raconter l'histoire inverse.

Le vrai travail d'un test A/B commence donc avant sa mise en ligne. Il consiste à décider ce qui constituerait un progrès utile, à protéger une mesure de qualité et à accepter qu'une expérience puisse ne pas trancher. Sans ce cadre, la console sert surtout à habiller une préférence graphique avec des chiffres.

Un test sur l'App Store ou Google Play doit répondre à une question commerciale étroite : cette présentation aide-t-elle davantage de visiteurs pertinents à installer l'application ? Elle ne cherche pas à élire la plus jolie maquette.

La conversion de la fiche n'est qu'une étape

La fiche intervient avant la première utilisation. Elle peut mesurer l'effet d'une icône, d'une suite de captures, d'une vidéo ou de certains éléments textuels pris en charge par la plateforme. Elle ne dit pas à elle seule si les nouveaux utilisateurs terminent leur inscription, comprennent le service ou reviennent.

Ces comportements relèvent de l'analytique mobile et, quand le volume le permet, des expériences dans l'application. Une promesse très spectaculaire peut augmenter les installations tout en dégradant l'activation. Elle attire alors plus de personnes, mais pas les bonnes.

Il faut aussi distinguer un partage simultané du trafic d'un simple avant/après. Comparer le mois suivant une refonte au mois précédent mélange le visuel avec les campagnes, la saison, le classement, les concurrents et la nouvelle version du produit. La répartition aléatoire réduit une grande partie de ce bruit puisque les traitements traversent la même période.

Formuler une hypothèse qui peut perdre

« Rendre la page plus dynamique » n'est pas une hypothèse. Personne ne sait exactement ce qui change ni quel résultat permettrait de dire qu'elle est fausse. Une formulation exploitable ressemble plutôt à ceci :

> Pour les nouveaux visiteurs de la fiche française, montrer le bénéfice obtenu avant l'interface augmentera les premières installations, car la valeur sera comprise plus vite, sans réduire le taux d'inscription terminée.

Cette phrase fixe l'audience, l'unique différence, le mécanisme attendu, l'indicateur principal et une limite à ne pas franchir. L'icône, les autres captures et l'acquisition restent stables. Quel que soit le résultat, l'équipe apprend quelque chose sur le premier message.

Les bonnes hypothèses viennent d'un doute observé. Beaucoup d'impressions et peu d'ouvertures orientent vers l'icône ou l'accroche visible dans les résultats. Beaucoup de visites et peu d'installations orientent vers le début de la fiche. La recherche de mots-clés ASO permet aussi de vérifier si le message correspond à l'intention qui a amené la personne.

Choisir la décision qui mérite du trafic

Il est inutile de tester une couleur simplement parce qu'une déclinaison existe déjà. Le trafic d'une app est une ressource limitée. Il doit servir à résoudre une incertitude qui modifiera réellement la page.

Pour la première capture, on peut opposer un résultat concret à une fonctionnalité, une situation réelle à une interface isolée, ou une preuve à une déclaration. Le reste du système graphique reste identique. Le guide sur les captures de l'App Store aide à construire la narration ; l'expérience ne doit en interroger qu'une partie.

Changer en même temps l'icône, la vidéo, le texte et toute la série de captures peut produire une hausse. Il sera ensuite impossible de savoir quoi conserver. À l'autre extrême, déplacer une légende de quelques pixels risque de ne créer aucune différence utile. Un bon traitement est assez distinct pour changer la perception et assez contrôlé pour rester explicable.

Product Page Optimization côté Apple

Product Page Optimization compare la page d'origine avec jusqu'à trois traitements comportant d'autres icônes, captures ou aperçus vidéo. L'équipe choisit la part de trafic et les localisations prises en charge ; les visiteurs sont affectés de manière aléatoire. L'aide actuelle d'App Store Connect précise que l'app doit être Ready for Distribution.

Le test dépend du calendrier de publication. Une icône alternative doit déjà se trouver dans le binaire actuellement distribué. Des captures ou aperçus inédits peuvent passer par la validation du store. Une nouvelle version publiée pendant l'expérience peut également modifier les ressources ou le contexte. Le responsable de la sortie doit donc connaître le protocole.

Apple présente notamment la conversion estimée, l'amélioration relative, les intervalles et le niveau de confiance. Un traitement peut être signalé comme meilleur ou moins bon à partir de 90 % de confiance. La mention « Likely to be Inconclusive » indique au contraire que le trafic et l'écart observé risquent de ne pas suffire. C'est une information utile, pas un problème à contourner.

Store Listing Experiments côté Google Play

Google Play permet d'expérimenter sur les fiches par défaut et personnalisées. La configuration comprend la part d'audience, l'effet minimal détectable et le niveau de confiance. Dans sa documentation sur les expériences, Google conseille de modifier un seul élément à la fois afin de mieux attribuer l'effet.

Plusieurs expériences localisées peuvent fonctionner en parallèle. Cette capacité ne signifie pas qu'il faille tester chaque idée disponible. Une file d'attente classée selon l'impact attendu, le manque de preuves, le volume et l'effort de production évite de disperser le trafic sur des différences anecdotiques.

Apple et Google n'emploient pas toujours les mêmes mots. Un journal interne commun simplifie le suivi : question, témoin, traitements, pays et langue, sources de trafic, date, modification, résultat principal, indicateur de qualité, événement perturbateur et décision.

Une localisation gagnante n'est pas un modèle à traduire

Le traitement anglais peut échouer en français même si la traduction est correcte. Les phrases changent de longueur, les codes de la catégorie ne sont pas identiques et une preuve rassurante dans un pays peut sembler artificielle dans un autre. La composition du trafic compte également.

Il faut reprendre la logique, puis réécrire le traitement. Si présenter le résultat avant le mécanisme a fonctionné, la version française peut tester la même raison avec un vocabulaire, un exemple et un visuel crédibles localement. La check-list de localisation de la fiche doit être achevée auparavant. Sinon, l'expérience mesure peut-être une phrase tronquée ou une capture dans la mauvaise langue.

Évitez aussi de regrouper des marchés différents uniquement pour atteindre un volume plus flatteur. Une moyenne globale peut masquer un gain fort dans un pays et une perte tout aussi forte ailleurs. Commencez par une localisation prioritaire avec un trafic suffisamment homogène.

Créer des traitements qui apportent une explication

Une bonne variante modifie un signal qui a du sens pour le visiteur. Dans une série de captures, le premier message peut passer de « gérez vos rendez-vous » à « réduisez les créneaux perdus », tandis que la direction artistique et la suite restent stables. Pour une icône d'application, comparez des concepts reconnaissables, pas trois nuances de la même forme.

*Le traitement modifie un signal pertinent tandis que le contexte reste comparable.*

Avant le lancement, insérez les ressources dans une recherche réaliste et dans la fiche complète. Vérifiez les petits formats, les appareils nécessaires, les modes clair et sombre et chaque langue. Enfin, confirmez que l'app réalise vraiment ce qui est montré. Une allégation trompeuse peut gagner la première métrique et perdre la confiance ensuite.

Fixer la règle de décision à froid

Le protocole doit noter la conversion habituelle, le plus petit gain qui justifierait la production et la localisation, le niveau de confiance, une fenêtre couvrant le rythme normal de la semaine et les événements qui obligeraient à annoter ou recommencer. Une grande campagne, une mise en avant, une panne ou une nouvelle version peuvent changer la population ou le produit pendant le test.

L'effet minimal utile évite de poursuivre une différence trop petite pour avoir une valeur commerciale. Google Play permet de régler un effet minimal détectable. Chez Apple, le même raisonnement aide à concevoir des traitements assez éloignés pour produire une réponse avec le trafic disponible.

Ajoutez un garde-fou après installation : inscription terminée, première réservation, première leçon ou activation le lendemain. L'attribution à chaque traitement ne sera pas toujours aussi nette que celle de l'installation. Elle reste indispensable au moment de déployer le gagnant.

Lire le chiffre absolu avant de raconter le pourcentage

Un passage de 20 % à 22 % représente deux points de conversion et une amélioration relative de 10 %. Les deux sont exacts. Mentionner seulement 10 % amplifie facilement l'impression de progrès.

L'intervalle d'incertitude complète ces nombres. S'il contient encore une baisse possible et une hausse possible, la direction n'est pas établie. La courbe la plus haute du jour ne devient pas pour autant une preuve.

Une expérience non concluante peut signifier que les créations se valent, que leur différence est trop faible ou que le trafic manque. La bonne suite peut être de conserver le témoin, de tester une opposition plus forte ou de changer de marché. Choisir la variante préférée après coup efface précisément l'information obtenue : nous ne savons pas encore.

Apprendre avec peu de trafic

Une petite app doit d'abord éliminer les mauvaises options hors du store. Montrez des maquettes réalistes à des personnes proches du public, demandez ce qu'elles s'attendent à trouver et ce qu'elles retiennent. Ce travail qualitatif ne prédit pas le taux de conversion, mais il évite de gaspiller les rares impressions sur un message incompréhensible.

Ensuite, concentrez le trafic sur un seul traitement vraiment différent dans la localisation prioritaire. Une opposition de promesse se détecte plus facilement qu'un détail cosmétique. Si la plateforme ne peut toujours pas conclure, gardez cette réponse plutôt que de fabriquer un gagnant.

Un changement séquentiel, comparé sur des périodes équivalentes et soigneusement documenté, peut fournir une orientation. Les campagnes, sorties et événements externes doivent rester aussi stables que possible. Le résultat est alors un indice, pas une preuve causale équivalente à la randomisation.

Comment Appfyl prépare ces expériences

Chez Appfyl, le travail commence par la continuité entre la fiche et la première valeur du produit. L'équipe définit qui arrive, ce que la personne cherche et ce qu'elle doit réussir après l'installation. Le design peut ensuite construire des traitements contrôlés plutôt qu'une refonte sans question.

Produit et analytique fixent le mécanisme et le garde-fou ; la personne responsable de la sortie vérifie binaire, validation et langues. Cette coordination fait partie du travail de l'équipe mobile Appfyl. Elle empêche une promesse convaincante dans le store d'être contredite par les premiers écrans.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes