Les retours de testeurs ne servent qu'une fois qu'ils changent l'app. Si tu construis surtout par prompts, le chemin le plus court entre une note de testeur et une correction passe par un bon prompt. Un prompt vague donne un changement vague, et un changement non vérifié peut en casser un autre. Cette page te donne une boucle à répéter pour chaque série de retours.
La boucle
- Recueillir
- Prioriser
- Rédiger le prompt
- Appliquer et relire le changement
- Vérifier sur un vrai appareil
- Prévenir le testeur
1. Recueillir des retours structurés
Un « c'est cassé » sans détails est difficile à exploiter. Demande aux testeurs les mêmes quelques champs à chaque fois : ce qu'ils ont fait, ce qu'ils attendaient, ce qui s'est passé, appareil et version de l'OS. Un rapport dans cette forme peut être collé presque tel quel dans un prompt. Voir comment écrire des retours qu'un développeur peut exploiter et le modèle de rapport de bug.
2. Prioriser avant de rédiger
N'envoie pas dix rapports à l'assistant d'un coup. Trie par impact et effort (guide) : plantages et parcours principaux bloqués d'abord, finitions en dernier. Traite un problème par prompt. Les petits changements sont plus faciles à vérifier et à annuler.
3. Rédige un prompt précis
Un bon prompt contient quatre éléments :
- Contexte : quel écran ou quelle fonctionnalité, en une ou deux phrases.
- Le rapport : étapes, résultat attendu, résultat obtenu, appareil et OS.
- La limite : « ne change que ce qui est nécessaire ; ne refactorise pas le code sans rapport ».
- Une vérification : comment tu sauras que ça marche, y compris un comportement voisin qui doit rester identique.
Version à copier-coller : modèle de prompt pour corriger un bug à partir d'un rapport de testeur.
Si tu ne peux pas reproduire le problème toi-même, dis-le dans le prompt et demande à l'assistant d'expliquer sa supposition avant de modifier le code. Ne lui demande pas de « tout corriger dans ce rapport ».
4. Relire le changement
Tu n'as pas besoin de comprendre chaque ligne, mais regarde ce qui a changé : quels fichiers, combien de lignes. Un bug d'une ligne qui produit un changement dans dix fichiers mérite un second regard. Garde chaque correction dans son propre commit ou point de sauvegarde pour pouvoir revenir en arrière.
5. Vérifier sur un vrai appareil
Exécute les étapes exactes du rapport sur un vrai téléphone, idéalement du type utilisé par le testeur. Puis exécute le comportement voisin que tu as indiqué comme « doit rester identique ». Un émulateur est une première passe ; le vrai téléphone fait foi. Voir pourquoi un émulateur ne suffit pas.
6. Boucler la boucle
Dis au testeur ce que tu as changé et demande-lui de revérifier. Les personnes qui voient leurs notes utilisées ont tendance à envoyer de meilleures notes la fois suivante. Nous n'annonçons aucun taux pour cela ; c'est simplement ainsi que les retours deviennent une habitude plutôt qu'un événement isolé.
Quand la correction ne tient pas
- L'assistant a « corrigé », mais les étapes échouent encore : renvoie le même rapport avec ce que tu as observé après le changement.
- La correction a cassé autre chose : annule, puis ajoute le comportement cassé à la ligne « doit rester identique ».
- Deux tentatives, aucun progrès : décris le problème avec tes propres mots, plus petit et avec moins de contexte.
Tiens un court journal
Une ligne par rapport : date, problème, appareil, prompt utilisé, résultat. Après quelques séries, tu verras quels types de rapports donnent des corrections propres.
Où s'inscrit AppReviewX
AppReviewX te donne des retours privés et structurés d'autres développeurs, dans un format qui s'intègre à cette boucle. Un retour que tu rédiges te rapporte un crédit, les crédits achètent des retours sur ta propre app, et les nouveaux comptes démarrent à 0 crédit.
Liés : Hub vibe coding, obtenir tes premiers avis honnêtes en boutique, motifs de refus en boutique, test sur appareil réel.
Commence gratuitement et mets la boucle en pratique.