Ce que piU fait bien, et là où il perd ses utilisateurs
Une démarche de recherche utilisateurs en cinq étapes sur piU, l'encyclopédie d'oiseaux en 3D. On part de ce que disent les utilisateurs des apps de référence (Merlin, BirdNET, eBird), on en tire quatre personas, on passe l'app au crible des heuristiques de Nielsen, puis on la fait utiliser par ces personas et on leur demande ce qu'ils pensent du concept. Une roadmap range enfin les prochaines étapes par complexité et bénéfice.
Chaque page explique la méthode en quelques lignes, puis montre les résultats.
Les cinq étapes
À retenir
Les constats qui reviennent d'une méthode à l'autre, du plus urgent au moins urgent.
Ce que disent les utilisateurs de Merlin, BirdNET et eBird
Avant de regarder piU, on écoute les utilisateurs des trois apps de référence. Les avis des stores, les discussions de r/birding et des forums francophones disent ce que les gens attendent d'une app d'oiseaux et ce qui les fait renoncer.
Chaque citation ci-dessous a été vérifiée automatiquement : elle figure mot pour mot dans sa source, dont le lien est donné.
Besoins et frustrations
Part des 219 avis des stores qui évoquent chaque thème (comptage par mots-clés, ordre de grandeur). Touchez un thème pour filtrer les verbatims.
Ce qu'on en retient
Verbatims
Pour piU
Biais connus
Quatre personnes pour tester piU
Chaque persona résume un profil qui revient dans les avis. Chaque trait renvoie aux verbatims qui le justifient : touchez un numéro pour lire la citation.
Ces personas servent ensuite de consigne aux agents IA des tests : leur texte est donné tel quel à l'agent.
- Sources
- 62 verbatims de l'étape 1.
- Choix
- Les quatre profils demandés : ornithologue amateur, néophyte, enfant de 8-10 ans, enseignante et parent.
- Limite
- Aucun avis d'enfant dans le corpus : Léo est le persona le plus fragile.
Les dix heuristiques de Nielsen, écran par écran
Une évaluation experte : on parcourt chaque écran de l'app réelle et on note chaque écart aux dix principes d'utilisabilité de Jakob Nielsen, avec une gravité de 0 (pas un problème) à 4 (catastrophique). Les points forts sont aussi relevés.
Quand un test par scénario a rencontré le même problème, le constat l'indique.
Treize sessions, jouées pour de vrai dans l'app
Un agent IA par persona et par scénario. Chaque agent n'a accès à l'app que par un pilote Playwright : il voit des captures d'un iPhone, touche, fait défiler, répond aux demandes d'autorisation. Chaque action exige une intention à la première personne et est enregistrée avec sa capture.
La transcription est générée depuis ce journal, jamais depuis le récit de l'agent : une action non réalisée ne peut pas y figurer. Le micro entend un vrai chant de mésange charbonnière (scénario 1) et l'appareil photo voit une vraie image.
Difficulté ressentie
De 1 (évident) à 5 (échec ou abandon). Touchez une case pour lire la session.
Scénarios
Les personas jugent l'idée de piU
Après leurs sessions, on présente à chaque persona le concept de piU en une page et on lui demande de le critiquer sur trois points : le point d'entrée (une liste d'oiseaux en 3D), le déblocage du Carnet par « vu ! », et ce que piU apporte de plus que Merlin.
Chaque critique s'appuie sur ce que le persona a vécu dans ses sessions, avec renvoi aux actions du journal.
- Entrée
- Résumé du concept (concept.md) et résumés des sessions du persona.
- Sortie
- Critique argumentée, verdict, conditions pour que le persona adopte l'app.
- Limite
- Un agent IA peut être trop raisonnable : à confronter à de vrais entretiens.
Convergences et désaccords
Prochaines étapes, rangées par complexité et bénéfice
Chaque action vient d'un constat de la desk research, de l'évaluation heuristique, des tests ou du challenge du concept. On la place selon l'effort qu'elle demande et le bénéfice attendu pour chaque persona.
Choisissez un persona pour voir la matrice de son point de vue : les gains rapides ne sont pas les mêmes pour Bernard et pour Léo.
Roadmap
Dans chaque colonne, du plus grand au plus petit bénéfice pour le persona choisi. Touchez un point de la matrice pour retrouver sa carte.
De l'étude ponctuelle à une boucle continue
Cette étude est une photo : elle décrit piU au 5 octobre 2026. Dès le prochain build, elle vieillit, et rien ne dira si la roadmap a vraiment aidé les utilisateurs.
Avec des agents, on peut faire tourner la même démarche en continu : écouter, tester, trier, corriger, puis valider avec de vrais utilisateurs. Les humains gardent la main là où l'erreur coûte cher.
- Déjà en place
- Le pilote Playwright journalisé, 5 scénarios, 4 personas, le contrôle automatique des résumés.
- À construire
- L'exécution à chaque build, la comparaison entre versions, la veille planifiée, les propositions de correction.
Ce qui change
Une étude ponctuelle
- Cinq étapes menées une fois, un rapport à la fin.
- Les résultats valent pour une version de l'app.
- On ne sait pas si une correction a aidé.
- Les constats restent dans un document.
Une boucle continue
- Les mêmes tests rejoués à chaque nouvelle version.
- Chaque scénario a un historique : mieux, pareil, pire.
- Une correction se mesure dès le build suivant.
- Les constats deviennent des tickets, puis des propositions de correction.
Les cinq temps de la boucle
Chaque temps est confié à un agent ; seul le dernier repose sur de vraies personnes.
Écouter
Un agent relève les nouveaux avis sur piU et sur les apps de référence, et signale les thèmes nouveaux ou en hausse.
Chaque semaineTester
Les 13 sessions persona × scénario tournent en parallèle sur le nouveau build. Les vérifications simples deviennent des tests automatiques classiques.
À chaque buildTrier
Un agent regroupe les constats en tickets, avec captures et extraits de journal, et écarte les doublons.
Après chaque sérieCorriger
Pour les petits problèmes, l'agent propose une correction prête à relire. Pour le reste, il propose des pistes.
Selon le risqueValider
De vrais utilisateurs confirment ou contredisent les agents. Là où ils divergent, on corrige les personas.
Chaque mois ou trimestre
Qui décide quoi
L'autonomie de l'agent dépend de ce que coûte une erreur. Exemples tirés de la roadmap de piU.
L'agent corrige
Un humain relit et fusionne.
- Trier la liste France par fréquence (R01)
- Libellés des onglets (R03)
- Bulle Île-de-France sur la Carte (R06)
- Accessibilité, fautes, bugs évidents
L'agent propose
L'équipe choisit et valide la maquette.
- Noms sous les vignettes (R02)
- Recherche par nom (R04)
- Plusieurs candidats à l'identification (R08)
- Carnet par zone (R12)
L'humain décide
L'agent fournit les éléments, jamais la décision.
- Le concept : place de l'identification, part de jeu
- Les arbitrages de design, comme l'état « vu » exclu par ui.md (R11)
- Les contenus naturalistes : l'agent cite ses sources, un ornithologue valide
Pourquoi pas tout en autonomie
Cette étude en a donné quatre raisons concrètes.
Le premier pilote concluait « Micro indisponible ». C'était l'outil de test qui se trompait, pas l'app. Un agent autonome aurait « corrigé » un problème inexistant.
Sur les erreurs de contenu relevées par l'ornithologue, deux ont été vérifiées dans les données. Les autres restent à vérifier avant toute modification.
Tous les agents viennent du même modèle : ils lisent trop, raisonnent trop bien, et utilisent des libellés invisibles à l'écran. Optimiser pour eux, c'est risquer d'optimiser contre les humains.
Léo est une fiction construite à partir de parents. Seuls de vrais enfants diront si piU leur parle.
Une limite pratique aussi : les sources d'avis sont fragiles (flux Apple vide, Reddit fermé aux scripts, archives qui refusent les agents). La veille doit s'en tenir aux sources autorisées.
Par où commencer
Rejouer les tests à chaque build
Lancer les 13 sessions d'une seule commande et comparer chaque scénario à la version précédente. Ce mini-site devient un tableau de bord qui suit l'évolution de chaque scénario.
Veille hebdomadaire planifiée
Une tâche qui tourne chaque lundi, compare les nouveaux avis aux précédents et ne signale que ce qui change.
Corrections proposées
Commencer par les petites corrections relues avant fusion, puis élargir selon la confiance gagnée, toujours avec un humain qui valide.
Tests avec de vrais utilisateurs
Cinq enfants et cinq adultes sur les mêmes scénarios, pour recaler les agents.