Surveiller les avis App Store et Google Play avec n8n et l'IA

Un avis une étoile qui mentionne un plantage au lancement, publié un vendredi soir sur le Play Store, peut rester invisible jusqu'au lundi matin — le temps que quelqu'un pense à ouvrir la fiche de l'application. Entre-temps, l'avis a déjà influencé les téléchargements de la semaine, et personne dans l'équipe produit ne sait qu'un bug critique circule. Contrairement aux avis Google Business Profile ou Trustpilot, où un pipeline de collecte et d'alerte est un cas d'usage n8n bien balisé, les avis App Store et Google Play restent un angle mort : aucun node natif ne les couvre, et la plupart des équipes se contentent de consulter la note moyenne une fois par mois dans la console développeur.

Pourquoi ces avis méritent un traitement à part

Un avis d'application mobile n'est pas un avis client comme un autre. Il arrive au moment où l'utilisateur est le plus susceptible d'agir : il tient encore son téléphone, l'app est encore ouverte, et son irritation (ou sa satisfaction) est fraîche. L'étude fondatrice de Dennis Pagano et Walid Maalej, User Feedback in the AppStore: An Empirical Study (IEEE RE, 2013), montre sur un large corpus d'avis que le volume de retours explose dans les jours qui suivent une nouvelle version, puis retombe très vite — une fenêtre courte pendant laquelle un bug de release se signale massivement, avant de se diluer dans le bruit. Une seconde étude, Bin Fu et ses coauteurs, Why People Hate Your App: Making Sense of User Feedback in a Mobile App Store (KDD, 2013), va plus loin : elle montre qu'une part significative des avis négatifs se regroupe autour de thématiques récurrentes et identifiables (plantages, batterie, publicité intrusive) plutôt que de se disperser au hasard — ce qui rend justement la classification automatique pertinente pour prioriser les correctifs.

Concrètement, un pipeline de surveillance change deux choses : la vitesse de détection d'un bug de release critique, et la visibilité sur les tendances qu'aucune lecture ponctuelle de la note moyenne ne révèle.

Deux stores, deux API, aucun node natif

n8n ne propose ni node App Store, ni node Google Play : les deux s'intègrent exclusivement via le node HTTP Request, chacun avec sa propre logique d'accès.

Collecter les avis iOS via le flux RSS public

Apple expose un flux RSS public, sans authentification, pour les avis récents de n'importe quelle application déjà publiée :

https://itunes.apple.com/fr/rss/customerreviews/id=<APP_ID>/sortBy=mostRecent/json

Un simple node HTTP Request en GET sur cette URL, déclenché par un Schedule Trigger toutes les quelques heures, suffit à récupérer les derniers avis au format JSON. Deux limites à connaître avant de construire dessus : le flux plafonne à environ 500 avis récents par application, et il n'inclut que les avis accompagnés d'un texte — une simple note sans commentaire n'y figure pas. Pour un usage de surveillance continue (et non de reconstitution d'historique), ces limites sont sans conséquence tant que le pipeline tourne au moins quotidiennement.

Pour une intégration plus poussée sur votre propre application (répondre aux avis, accéder à un historique plus large), l'App Store Connect API expose un endpoint customerReviews dédié, mais son authentification par JWT signé (clé ES256, Key ID, Issuer ID) est nettement plus lourde à mettre en place qu'un simple appel RSS — à réserver aux équipes qui ont déjà besoin de cette API pour d'autres usages (gestion des builds, TestFlight).

Collecter les avis Android via l'API Google Play Developer

Côté Android, pas de flux public équivalent : il faut passer par la méthode reviews.list de l'Android Publisher API (Google Play Developer API) :

GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/<PACKAGE_NAME>/reviews

L'authentification suit le même principe que pour Google Cloud Storage dans n8n : un compte de service créé dans la console Google Cloud, dont le fichier JSON (client_email + private_key) alimente une credential générique Google API sur le node HTTP Request, avec le scope https://www.googleapis.com/auth/androidpublisher. Une étape supplémentaire, propre à Google Play, est facile à oublier : ce compte de service doit ensuite être invité dans la Play Console (Utilisateurs et autorisations), avec au minimum le droit « Consulter les infos de l'appli et télécharger des rapports groupés » pour la lecture seule des avis.

Deux limites structurantes de cette API à anticiper dès la conception du workflow : elle ne renvoie que les avis de la semaine écoulée, glissante, et uniquement ceux qui comportent un commentaire — une note seule sans texte reste invisible. Un polling au moins hebdomadaire (idéalement quotidien) devient donc indispensable pour ne rien perdre, avec archivage systématique de chaque avis dès sa première apparition.

Normaliser et dédupliquer dans Supabase

Les deux sources renvoient des formats différents (structure XML/JSON imbriquée côté Apple, objets comments côté Google). Un node Set (Edit Fields) normalise chaque avis vers un schéma commun avant insertion dans une table Supabase : store (ios/android), review_id, note, texte, langue, version_app, date_publication, collecte_le. Un node Postgres avec une contrainte d'unicité sur (store, review_id) évite les doublons quand le même avis revient à chaque exécution planifiée — le même principe de dédoublonnage que dans notre pipeline de veille concurrentielle.

Classifier chaque avis par IA

Un avis brut ne dit pas à lui seul s'il mérite une réaction immédiate. Un appel IA avec un Structured Output Parser transforme le texte en signal exploitable :

{
  "categorie": "bug_crash",
  "severite": 4,
  "version_mentionnee": "4.2.1",
  "resume": "L'application plante au lancement depuis la dernière mise à jour sur Android 14.",
  "action_suggeree": "investiguer_urgence"
}

Le prompt doit distinguer au minimum quatre catégories : bug_crash, demande_fonctionnalite, avis_positif et spam_hors_sujet — sur le même principe de classification contrainte que notre guide du node Sentiment Analysis. Un avis une étoile qui dit simplement « nul » sans détail technique n'a pas la même valeur d'action qu'un avis deux étoiles qui décrit précisément une séquence de plantage : le champ severite doit refléter cette différence, pas seulement recopier la note laissée par l'utilisateur.

Router : alerte immédiate ou digest hebdomadaire

Un node Switch sépare les avis selon leur urgence, sur le même schéma que notre pipeline de mentions de marque :

• Catégorie bug_crash avec sévérité ≥ 4 → alerte Slack immédiate vers le canal produit, avec le résumé, la version mentionnée et le lien direct vers la fiche de l'avis.
• Tout le reste → archivage simple dans Supabase, agrégé dans un digest hebdomadaire envoyé le lundi matin : nombre d'avis par catégorie, top des mots-clés récurrents dans les avis négatifs, évolution de la note moyenne par version.

Pour les cas où une réponse publique s'impose (un utilisateur clairement identifiable avec un problème résolu depuis), le modèle peut générer un brouillon de réponse affiché dans Slack pour validation — jamais publié directement. Sur les stores mobiles plus encore qu'ailleurs, une réponse mal calibrée reste visible indéfiniment sous l'avis. Pour les cas ambigus, un circuit d'approbation humaine avec boutons Slack met le workflow en pause jusqu'à validation explicite.

Sécuriser les accès

Le compte de service Google Play ne doit porter que le scope androidpublisher en lecture seule — inutile de lui accorder le droit de répondre aux avis si le workflow se contente de les surveiller. Notre guide de sécurisation des credentials API détaille comment restreindre les scopes au strict nécessaire et faire tourner les clés régulièrement. Le flux RSS Apple, lui, ne nécessite aucune credential — mais reste un appel HTTP externe standard, à protéger des mêmes bonnes pratiques de retry et de timeout décrites dans notre guide HTTP Request en cas d'indisponibilité ponctuelle du flux.

Pièges fréquents

• Confondre note et sévérité : un avis une étoile sans détail technique ne mérite pas la même réaction qu'un avis deux étoiles qui décrit un plantage reproductible — laissez le prompt IA trancher sur le contenu, pas sur la seule note.
• Oublier le fuseau et la langue : le flux RSS Apple se décline par pays (/fr/, /us/…) ; sans boucle sur chaque marché ciblé, une partie des avis internationaux passe inaperçue.
• Interroger Google Play trop rarement : au-delà d'une semaine sans exécution, la fenêtre glissante de l'API fait disparaître des avis jamais archivés — un cron hebdomadaire est un minimum strict, pas un confort.
• Publier une réponse générée sans relecture : sur un canal aussi visible qu'une fiche d'application, l'erreur reste affichée indéfiniment sous les yeux de futurs utilisateurs.

Étendre la veille aux mentions de la marque sur le web

Le même pipeline (collecte, déduplication, classification IA, routage) s'applique aux mentions hors stores : presse, blogs, forums.

• Sources : Google Alerts reste gratuit mais détecte avec quelques heures à plusieurs jours de retard et rate une partie des forums peu indexés. Une recherche périodique via l'opération Search de Firecrawl réduit ce délai, moyennant quelques crédits par requête.
• Faux positifs : avant le scoring de sentiment, un premier appel LLM répond seulement oui ou non à « ce texte parle-t-il de la marque X dans le secteur Y ? ». C'est plus fiable qu'un filtre par mots-clés quand le nom de marque est aussi un mot courant ou le nom d'une autre entreprise.
• Réponse : le LLM peut préparer un brouillon, mais rien ne se publie automatiquement sur un canal public ; une validation humaine reste obligatoire.
• Coût : avec un petit modèle, filtrage et scoring coûtent une fraction de centime par mention, soit quelques centimes à un euro par mois pour quelques dizaines de mentions par jour.

Pour aller plus loin

Ce pipeline de surveillance réutilise directement la mécanique de classification et d'alerte Slack du Pack Inbox IA (79 €) : le tri par IA et le digest quotidien qu'il installe pour une boîte mail s'adaptent presque sans modification à un flux d'avis mobiles. Une fois l'historique constitué dans Supabase, le Pack Assistant RAG (119 €) permet d'aller plus loin en rendant cet historique interrogeable en langage naturel — « pourquoi la version 4.2 a-t-elle généré autant de plaintes ? » — plutôt que de rester une simple archive qu'il faut relire ligne par ligne.