L'API In-App Review d'Android : demander une note sans être pénible

La plupart des invites « notez-nous » sur Android sont une boîte de dialogue personnalisée avec deux boutons : l’un ouvre la fiche Play Store, l’autre ferme la fenêtre. Elles apparaissent au lancement de l’app, ou après un nombre arbitraire de sessions, et interrompent ce que l’utilisateur était réellement en train de faire. La personne qui appuie sur « noter » quitte votre app, atterrit sur le Play Store, et doit maintenant rédiger un avis à partir de rien — une friction qui tue la majeure partie de l’intention que vous veniez de capter. La personne qui appuie sur « plus tard » ne vous a rien dit, et vous lui redemanderez probablement la semaine suivante de toute façon.

L’API In-App Review de Google résout la moitié mécanique de ce problème : une feuille de notation native qui apparaît par-dessus votre app, laisse l’utilisateur choisir des étoiles (et éventuellement écrire quelques mots) sans quitter l’app, et le ramène exactement là où il en était. Elle ne résout pas la moitié UX — le moment où vous la déclenchez compte encore plus que la manière — mais elle supprime l’excuse de se tromper sur le « comment ».

Comment ça fonctionne réellement

L’API fait partie de Play Core (com.google.android.play:review-ktx). Vous demandez un objet ReviewInfo à l’avance, puis lancez le flux quand vous êtes prêt à l’afficher :

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo)
            .addOnCompleteListener {
                // The flow is finished — you don't get a signal on
                // whether the user actually rated. Treat this as "done,"
                // not "succeeded."
            }
    }
}

Deux détails piègent les gens. D’abord, requestReviewFlow() peut échouer silencieusement ou revenir sans jamais afficher de dialogue — Google limite la fréquence à laquelle un même utilisateur voit cette feuille (environ une fois par an et par app, sans documentation précise, hors de votre contrôle), donc la plupart des appels en test se termineront sans rien afficher. Ensuite, le callback de complétion se déclenche que l’utilisateur ait noté, passé, ou que le quota ait bloqué le dialogue entièrement. Il n’y a pas de onRatingSubmitted — volontairement, pour que les apps ne puissent pas conditionner des fonctionnalités ou relancer l’utilisateur selon le résultat.

Ce qui compte vraiment : le timing

Le fait que l’API soit sans friction ne sert à rien si vous la déclenchez au mauvais moment. Le cas d’échec le plus fréquent que je vois : appeler requestReviewFlow() juste après onCreate(), sur l’idée que plus d’impressions donne plus d’avis. C’est l’inverse — vous demandez avant que l’utilisateur ait un avis, et vous le faites pendant qu’il est en pleine tâche, celle-là même qui l’a amené dans l’app ce jour-là.

Le moment qui fonctionne, c’est juste après que l’app a démontrablement fait son travail. En construisant Mintly, c’est le moment juste après qu’une session de concentration se termine et que l’utilisateur voit sa série progresser — pas la première session, mais une où l’app a déjà gagné un peu de confiance. Quelques règles concrètes qui tiennent quelle que soit la catégorie d’app :

• Déclenchez sur un résultat positif accompli, pas sur un nombre de sessions fixe. Une app de budget après que l’utilisateur a bouclé un mois proprement, une app d’habitudes après un palier de série, une app de rappels après une sauvegarde réellement utile — pas « session n°5 ».
• Ne déclenchez jamais sur un chemin d’erreur. Si quelque chose vient d’échouer ou que l’utilisateur vient de quitter un flux, c’est le pire moment possible pour demander.
• Limitez-vous vous-même même si l’API vous limite déjà. Le quota de Google fait que la plupart des requêtes n’ont silencieusement aucun effet, mais votre propre logique de déclenchement devrait quand même éviter de se déclencher à chaque événement qualifiant — une fois le flux terminé pour un utilisateur, ne le rappelez pas avant plusieurs mois, même si votre suivi ne peut pas confirmer si la feuille s’est réellement affichée.
• Ne le combinez jamais avec votre propre pré-invite. Une boîte de dialogue personnalisée « vous appréciez l’app ? » qui filtre l’accès à la vraie invite réintroduit exactement la friction à deux étapes que l’API est censée supprimer, et vous permet de filtrer qui voit la vraie invite — exactement le genre de manipulation que les règles de Play interdisent explicitement.

Ce qu’elle ne peut pas faire, et ce que les gens essaient quand même

Vous ne pouvez pas détecter si l’utilisateur a réellement laissé une note, lire la valeur des étoiles, ni rediriger les utilisateurs mécontents loin du flux et les utilisateurs satisfaits vers lui. Cette dernière pratique est une demande fréquente et elle est explicitement contraire à la politique développeur de Play — tout l’intérêt de l’API est que chaque personne qui la déclenche voit la même feuille non filtrée. Si vous voulez un canal de support « une difficulté ? », construisez-le comme un lien de retour séparé et honnête — pas comme une bifurcation devant l’invite d’avis.

L’autre limite à connaître : c’est réservé à Play. Il n’existe aucune garantie équivalente sur les autres boutiques d’apps Android, et là-bas vous revenez à un lien manuel « notez-nous » ou au mécanisme propre à la boutique.

Tester sans épuiser votre quota

Comme le vrai quota est opaque, testez via les outils de test de Play Core plutôt que sur votre build de production — l’artefact de test com.google.android.play:review-ktx et les canaux de partage interne d’app vous permettent de déclencher le flux à répétition sans attendre la vraie limitation de Google. Câblez le déclencheur dans un menu de debug pendant le développement pour pouvoir le lancer à la demande, puis retirez ce raccourci avant la sortie. En production, traitez chaque appel comme du fire-and-forget : demandez, lancez, passez à autre chose, et laissez la propre logique de Google décider qui verra réellement la feuille.