# Stratégie d'avis et de notes

URL: https://storelift.net/fr/guide/review-and-rating-strategy/
Language: fr
Updated: 2026-08-31

« Combien d'avis faut-il pour se classer » est une question distincte, déjà mesurée — voir combien d'avis pour se classer, corrélation quasi nulle dans nos propres données. Cette page pose une autre question : que vous laissent réellement faire les API des deux stores pour demander un avis, et qu'interdisent-elles explicitement toutes les deux.

## Apple : requestReview, plafonné à 3 fois par 365 jours

La page d'Apple le dit clairement : si l'utilisateur n'a pas noté ou commenté l'app sur cet appareil, StoreKit affiche la demande de note et d'avis au maximum trois fois sur une période de 365 jours. Vous pouvez appeler l'API aussi souvent que vous voulez dans le code — c'est le système qui limite la fréquence réelle d'affichage, le développeur ne maîtrise donc pas directement la fréquence.

- Si l'utilisateur a déjà noté, l'invite ne réapparaît pas.
- Les 365 jours forment une fenêtre glissante par utilisateur, non liée à la version de l'app.
- Tenter de contourner le système pour l'afficher plus souvent est explicitement signalé comme interdit dans les recommandations d'Apple.

## Google Play : In-App Review API, quota non divulgué

La documentation de Google ne publie PAS de chiffre : « Google Play applique un quota limité dans le temps sur la fréquence à laquelle un utilisateur peut voir la boîte de dialogue d'avis. En raison de ce quota, appeler la méthode launchReviewFlow plus d'une fois sur une courte période (par exemple, moins d'un mois) peut ne pas toujours afficher de boîte de dialogue. » Aucun chiffre — seulement « moins d'un mois » à titre d'exemple.

NOTE: Les recommandations de Google interdisent aussi de poser à l'utilisateur une question AVANT ou PENDANT l'affichage de l'invite — y compris une question de satisfaction (« Aimez-vous l'app ? ») ou prédictive (« Lui donneriez-vous 5 étoiles ? »). Filtrer en amont pour ne montrer l'invite qu'aux utilisateurs satisfaits enfreint la règle de Google elle-même, ce n'est pas une zone grise.

## Ce que les deux stores interdisent, malgré des quotas différents

Mécanisme de limitation différent, mêmes deux interdictions : récompenser un avis par une réduction, un déblocage ou un avantage, et poser une question de qualification en amont pour que seuls les utilisateurs satisfaits voient l'invite. Cette page ne propose aucune tactique au-delà de ce qui est déjà public — elle liste ce que la documentation d'API de chaque store indique comme limite et comme interdiction.

## FAQ

Q: Puis-je appeler requestReview aussi souvent que je veux ?
A: Vous pouvez l'appeler aussi souvent que vous voulez dans le code, mais StoreKit limite lui-même l'affichage réel : au plus 3 fois sur 365 jours si l'utilisateur n'a pas encore noté. Chercher à le déclencher plus souvent revient à contourner la limite du système, ce que les recommandations d'Apple visent directement.

Q: Quel est le quota d'avis intégrés de Google Play ?
A: La documentation de Google ne publie pas le chiffre — elle donne seulement « moins d'un mois » comme exemple de période où un second appel peut ne pas afficher de boîte de dialogue, et précise que le quota peut changer.

Q: Cette page dit-elle combien d'avis il faut pour se classer ?
A: Non — c'est un constat distinct et mesuré ; voir combien d'avis pour se classer. Cette page couvre seulement ce que les règles d'API de chaque store prévoient et interdisent.