Faire tester son app avant publication : de tes proches à TestFlight

Sommaire+

Réponse courte

Fais tester ton app en trois cercles, dans cet ordre :

1. toi, sur ton propre téléphone, pendant quelques jours ;
2. trois à cinq proches qui ressemblent à ton public, avec une mission précise ;
3. un groupe plus large via TestFlight, l'outil de test d'Apple, avec la vraie version installable.

À chaque cercle, l'objectif n'est pas d'entendre « c'est joli », mais de trouver où les gens bloquent. Apple le demande aussi : la règle 2.1 exige une app testée sur un appareil, sans texte provisoire, avant de la soumettre.

Pourquoi faire tester son app avant de la publier ?

Parce que tu connais trop bien ton app. Tu sais où cliquer, tu sais ce que veut dire chaque bouton. Un nouvel utilisateur, lui, découvre tout. Les tests servent à repérer :

• les écrans où l'on ne sait pas quoi faire ;
• les textes peu clairs ou restés en version d'exemple ;
• les bugs : un bouton qui ne réagit pas, une donnée qui disparaît ;
• les fonctions que personne n'utilise (et que tu peux retirer).

C'est aussi ta meilleure protection contre un refus d'Apple. Voir Pourquoi Apple refuse une application.

Étape 1 : comment tester ton app toi-même ?

Avec Briksell, ouvre l'onglet Tester et scanne le QR code avec l'appareil photo de ton téléphone. Ton app s'ouvre dans Safari ou Chrome, à jour de ta dernière version, sans rien installer. Tu peux l'ajouter à ton écran d'accueil pour l'ouvrir en plein écran.

Puis utilise-la dans ta vraie vie, pas seulement assis devant ton ordinateur : dans le métro, d'une main, avec peu de batterie. Note tout ce qui t'agace dans un carnet ou une note.

Que vérifier pendant ton propre test ?

• Le premier lancement : est-ce clair en 10 secondes ?
• Chaque bouton et chaque onglet : est-ce qu'il mène quelque part ?
• Les données : ce que tu saisis est-il toujours là après avoir fermé l'app ?
• Les textes : plus aucun texte d'exemple, plus de fautes.
• L'écran d'abonnement : rappelle-toi qu'il s'agit d'une démonstration, aucun vrai paiement n'est branché.

Limite à connaître : dans l'aperçu web, l'appareil photo, les notifications ou les vibrations peuvent ne pas marcher. L'ouverture dans Expo Go arrive bientôt dans Briksell. Voir Aperçu et test sur téléphone.

Étape 2 : comment faire tester des proches ?

Qui choisir ?

Trois à cinq personnes suffisent pour un premier tour. Choisis-les proches de ton public, pas seulement proches de toi : pour une app de course débutant, un ami qui ne court jamais ne t'apprendra pas grand-chose.

Comment leur envoyer l'app ?

Partage le lien d'aperçu : toute personne qui l'a peut ouvrir ton app sur son téléphone. Si tu veux couper l'accès, révoque le lien : un nouveau est créé et l'ancien ne marche plus.

Comment obtenir des retours utiles ?

Ne demande pas « tu en penses quoi ? ». Donne une mission :

• « Crée ta première séance et dis-moi à quel moment tu as hésité. »
• « Trouve une recette avec des pâtes et ajoute-la à ta liste de courses. »

Puis pose trois questions simples :

1. Qu'est-ce qui t'a bloqué ou surpris ?
2. Qu'est-ce que tu as cherché sans le trouver ?
3. Est-ce que tu la rouvrirais demain, et pourquoi ?

L'idéal : regarder la personne utiliser l'app sans l'aider. Chaque fois que tu as envie d'expliquer, c'est un écran à améliorer.

Que faire des retours ?

Classe-les en trois colonnes : bloquant (à corriger tout de suite), gênant (à corriger avant publication), idée (pour plus tard). Ensuite, demande les corrections à l'IA une par une dans la conversation, et refais tester.

Étape 3 : comment passer à TestFlight ?

C'est quoi, TestFlight ?

TestFlight est l'outil d'Apple pour faire tester la vraie version installable de ton app sur iPhone, avant sa sortie. Les testeurs installent l'app TestFlight, puis ton app depuis une invitation. C'est là que tu peux tester ce que l'aperçu web ne montre pas : notifications, appareil photo, comportement réel sur iOS.

Combien de testeurs, et pour combien de temps ?

D'après Apple :

• jusqu'à 100 testeurs internes : des membres de ton équipe dans App Store Connect ;
• jusqu'à 10 000 testeurs externes, invités par e-mail ou par un lien public ;
• chaque build est testable pendant 90 jours, après quoi il n'est plus disponible.

Faut-il une validation d'Apple ?

Pour les testeurs internes, non. Pour les testeurs externes, oui : le premier build ajouté à un groupe externe passe par une review bêta d'Apple. Les builds suivants n'ont pas forcément besoin d'une review complète. Les tests démarrent une fois le build approuvé.

Apple rappelle aussi (règle 2.2) qu'une app en TestFlight doit être destinée à une publication publique et respecter les règles de l'App Store, et que tu ne peux pas faire payer tes testeurs ni les récompenser en échange.

Comment les testeurs donnent-ils leur avis ?

Dans TestFlight, un testeur peut faire une capture d'écran, l'annoter et l'envoyer comme retour. Si l'app plante, tu reçois un rapport de plantage. Dans App Store Connect, tu peux aussi remplir le champ « What to Test » pour dire aux testeurs sur quoi se concentrer, et indiquer une adresse e-mail pour les retours.

Attention avec le lien public : n'importe qui peut le partager, donc des personnes que tu n'as pas invitées peuvent rejoindre ton test. Tu peux limiter le nombre de places.

TestFlight avec Briksell ?

L'envoi sur TestFlight depuis Briksell arrive bientôt. En attendant, si tu es abonné, exporte ton code (Export du code et GitHub), puis utilise EAS Build et EAS Submit d'Expo : une fois envoyé à App Store Connect, le build apparaît dans TestFlight. Il te faut un compte Apple Developer (99 $/an, affiché en euros à l'inscription), à ton nom : la règle 4.2.6 impose que chaque créateur publie depuis son propre compte. Le détail sans Mac est dans Publier une app sur l'App Store sans Mac.

Pour la partie technique de TestFlight (groupes, invitations, statuts), lis notre guide TestFlight : tester son app.

Quand arrêter de tester et publier ?

Tu es prêt quand :

• tes testeurs réussissent les missions sans ton aide ;
• il ne reste plus de problème « bloquant » ni « gênant » ;
• l'app a tourné quelques jours sur de vrais iPhone sans plantage ;
• les textes, l'icône et les pages légales sont définitifs.

Avant d'envoyer, un dernier passage avec App Store Readiness (abonnés) contrôle le code sur les règles Apple qui concernent ton app ; seule Apple décide au final. Voir App Store Readiness.

Quelles erreurs éviter ?

• Ne tester que sur ordinateur : ton app sera utilisée sur un téléphone.
• Faire tester uniquement ta famille : elle sera gentille, pas utile.
• Expliquer pendant le test : tu caches les vrais problèmes.
• Tout corriger d'un coup : une correction à la fois, puis on reteste.
• Envoyer en review externe une version pleine de textes d'exemple : la review bêta applique les mêmes règles.

Passer à l'action

Tu n'as pas encore d'app à faire tester ? Commence par la décrire, tu pourras scanner le QR code dans la foulée : Créer mon app. Pour voir tout le parcours dans l'ordre, lis Créer une app sans coder : les étapes, et la FAQ.

Sources et date de vérification

Vérifié le 22 octobre 2026 sur les pages officielles suivantes :

• TestFlight, Apple Developer
• TestFlight, présentation (App Store Connect Help)
• Inviter des testeurs externes
• App Store Review Guidelines (règles 2.1, 2.2, 4.2.6)
• Expo, Submit to the Apple App Store

Sources

• TestFlight (Apple Developer) · vérifiée
• TestFlight, présentation (App Store Connect Help) · vérifiée
• Inviter des testeurs externes (App Store Connect Help) · vérifiée
• App Store Review Guidelines, 2.1 App Completeness et 2.2 Beta Testing · vérifiée
• Expo, Submit to the Apple App Store · vérifiée

Informations vérifiées le 22 octobre 2026.