TestFlight : faire tester une app iPhone et iPad

Sur iPhone, pas question d’envoyer un fichier d’installation par WhatsApp, comme on le fait parfois avec un APK Android. Pour faire essayer votre app à de vraies personnes avant sa sortie, la voie officielle s’appelle TestFlight, le service de bêta d’Apple.

Il est puissant : jusqu’à 10 000 testeurs externes par app, des captures d’écran annotées envoyées depuis l’app, des rapports de plantage. Mais il a ses règles, qui surprennent la première fois : une vérification par Apple avant d’inviter le public, des builds qui expirent, des testeurs qui peuvent rester anonymes.

À la fin de cet article, vous saurez choisir entre testeurs internes et externes, passer la vérification bêta d’Apple, inviter vos testeurs par e-mail ou par lien public, obtenir des retours utiles et tester votre app aussi bien sur iPhone que sur iPad.

Comment fonctionne TestFlight, en cinq étapes

TestFlight fait partie d’App Store Connect, l’espace en ligne où les membres de l’Apple Developer Program gèrent leurs apps. Tout se passe dans l’onglet TestFlight de votre app.

1. Renseignez les informations de test : description de la bêta, adresse e-mail pour les retours et informations destinées à l’équipe de vérification d’Apple.
2. Envoyez un build vers App Store Connect, en général depuis Xcode.
3. Créez des groupes de testeurs et ajoutez-y des builds.
4. Invitez vos testeurs, internes ou externes. Pour les externes, Apple vérifie d’abord le build.
5. Les testeurs installent l’app TestFlight, acceptent l’invitation, testent et vous envoient leurs retours.

Côté testeur, il faut l’app gratuite TestFlight et, pour une app iOS, un iPhone ou un iPad sous iOS 16 ou iPadOS 16 au minimum. Un testeur peut installer la bêta sur 30 appareils au plus. Pendant la bêta, les achats intégrés sont gratuits et ne sont pas conservés dans la version de l’App Store.

Testeurs internes ou externes : lequel choisir ?

TestFlight distingue deux familles de testeurs. Le tableau suivant les compare point par point.

Quelques règles à connaître : pour créer un groupe externe, il faut d’abord avoir créé un groupe interne. Seuls les rôles Account Holder, Admin et App Manager peuvent inviter des testeurs externes. Enfin, un build envoyé comme « TestFlight Internal Only » reste réservé aux groupes internes.

Passer la vérification bêta d’Apple (Beta App Review)

Avant d’inviter des testeurs externes, Apple exige deux séries d’informations dans l’onglet TestFlight. D’abord les informations de test : une description de la bêta (obligatoire) et une adresse e-mail de retour, qui sert aussi d’adresse de réponse dans les invitations. Ensuite les informations pour la vérification : un contact, et un compte de démonstration si l’app demande une connexion.

Quand vous ajoutez votre premier build à un groupe externe, vous l’envoyez à la vérification avec le bouton Submit Review. Le premier build d’une version passe une vérification complète ; les builds suivants de la même version n’en ont pas toujours besoin. Retenez aussi ces limites : un seul build par version en cours de vérification à la fois, et six builds au plus soumis par période de 24 heures.

Si Apple accepte, les utilisateurs qui ont le rôle Admin reçoivent un e-mail. S’il refuse, le build passe à l’état Rejected : le détail se trouve dans la section App Review de l’app, et vous pouvez faire appel auprès de l’équipe TestFlight App Review.

La vérification bêta suit les mêmes directives que l’App Store. Apple y précise deux points importants : une app distribuée par TestFlight doit être destinée à une publication réelle, et l’accès à la bêta ne doit jamais être vendu ni offert en contrepartie, par exemple en récompense d’un financement participatif. Les mises à jour importantes d’une bêta doivent aussi repasser par la vérification.

Inviter vos testeurs : groupes, e-mail et lien public

Les groupes organisent tout : chaque groupe reçoit les builds que vous lui attribuez. Dans l’onglet TestFlight, cliquez sur le bouton + à côté de External Testing, nommez le groupe, puis utilisez Add Builds pour choisir un build. À cette étape, vous rédigez la note What to Test et vous pouvez cocher Automatically notify testers ; sinon, il faudra prévenir les testeurs vous-même après l’accord d’Apple.

Vous invitez ensuite les testeurs de deux façons :

• Par e-mail : bouton + à côté de Testers, puis ajout d’adresses une par une ou import d’un fichier CSV. Vous voyez le nom, l’adresse, la date d’installation, les sessions et les plantages de chacun.
• Par lien public : dans l’onglet des testeurs, Create Public Link, puis Open to Anyone (tout le monde) ou Filter by Criteria (filtre par appareil et version du système). Vous pouvez fixer une limite, de 1 à 10 000 testeurs, et désactiver le lien à tout moment.

Le lien public a un revers : n’importe qui peut le faire circuler, et les testeurs qui l’utilisent apparaissent comme anonymes. Vous voyez leur date d’installation, leurs sessions et leurs plantages, mais ni leur nom ni leur e-mail.

Si vous manquez de testeurs, GeekTest fournit des testeurs iPhone et iPad réels : vous recevez leurs identifiants Apple à inviter comme testeurs externes, ou vous leur transmettez votre lien public.

Builds et durée de validité : ne laissez pas expirer votre test

Chaque build peut être testé pendant 90 jours au plus, à compter de son envoi. Le testeur voit dans TestFlight le nombre de jours restants ; ensuite, la bêta ne s’ouvre plus. Pour un test long, envoyez un nouveau build avant l’échéance et prévenez vos testeurs.

Vous pouvez aussi arrêter un build plus tôt avec Expire Build. C’est utile après une publication : si vous n’expirez pas le build et que vous publiez l’app sur l’App Store, les testeurs invités peuvent continuer à utiliser la bêta, même une fois l’app en ligne.

Deux réglages méritent votre attention :

• Mises à jour automatiques : depuis TestFlight 3, le testeur peut installer automatiquement chaque nouveau build. Vérifiez qu’il teste bien la bonne version avant de lire ses retours.
• Abonnements : dans TestFlight, un abonnement se renouvelle chaque jour, jusqu’à six fois par semaine, quelle que soit sa durée réelle. Pratique pour tester les renouvellements sans attendre un mois.

Recueillir des retours utiles : captures, plantages et « What to Test »

TestFlight permet au testeur de prendre une capture d’écran dans votre app, de l’annoter et de l’envoyer avec un commentaire. Après un plantage, il peut aussi ajouter du contexte au rapport. Vous retrouvez tout dans la section Feedback de l’onglet TestFlight, avec des filtres par plateforme, version du système, appareil ou build. Les tableaux de bord montrent aussi, par testeur, le nombre de sessions et de plantages.

La qualité des retours dépend surtout de la note What to Test. Une note vague (« Testez l’app ») donne des retours vagues. Voici un modèle à adapter à chaque build :

Build 1.4 (52) - ce qui a changé
- Nouveau : paiement Mobile Money depuis le panier
- Corrigé : la photo de profil ne s'enregistrait pas sur iPad

À tester en priorité (20 minutes)
1. Payer une commande avec le compte de test fourni
2. Couper le réseau pendant le paiement, puis le rétablir
3. Refaire le parcours sur iPad, en mode paysage

Pour signaler un problème
Faites une capture dans l'app, entourez le problème
et écrivez ce que vous attendiez à la place.

Pour transformer ces captures en corrections, appuyez-vous sur notre guide du rapport de bug efficace : étapes, résultat attendu, résultat obtenu, appareil.

iPhone et iPad : ce qu’il faut tester sur chaque appareil

Apple demande, dans ses directives, que les apps iPhone fonctionnent sur iPad chaque fois que c’est possible. Même si vous pensez « iPhone d’abord », une partie de vos utilisateurs ouvrira l’app sur une tablette. Or un écran pensé pour un téléphone en portrait peut se déformer en paysage sur un grand écran.

Utilisez le lien public filtré par appareil pour recruter quelques testeurs iPad, et faites passer à chaque build cette liste de contrôle. Pour aller plus loin sur le choix des appareils, lisez notre article sur le test de compatibilité.

TestFlight ou test fermé Google Play : ce qui change

Si vous publiez sur les deux stores, ne copiez pas votre plan de test d’une plateforme à l’autre. Le tableau suivant résume les différences principales.

La différence la plus lourde est la première : chez Apple, personne ne vous impose un nombre de testeurs ni une durée. C’est une liberté, pas une raison de sauter l’étape. Côté Android, notre guide Google Play : réussir le test fermé à 12 testeurs détaille la marche à suivre.

Pour aller plus loin

• Apple Developer : TestFlight (nouvel onglet) — la présentation officielle : 100 testeurs internes et leurs rôles, 10 000 testeurs externes, lien public avec critères, retours par capture d’écran (en anglais, consultée le 20 octobre 2026).
• App Store Connect Help : TestFlight overview (nouvel onglet) — les étapes, la vérification du premier build externe et la durée de 90 jours par build.
• App Store Connect Help : Invite external testers (nouvel onglet) — groupes, invitations par e-mail, lien public, limites de la vérification bêta et recours en cas de refus.
• Apple Developer : Testing Apps with TestFlight (nouvel onglet) — le guide des testeurs : versions d’iOS requises, 30 appareils, achats intégrés et abonnements en bêta.
• App Review Guidelines (nouvel onglet) — les directives d’Apple, notamment la règle 2.2 sur les bêtas et la règle 2.4.1 sur les apps iPhone sur iPad.
• Aide Play Console : exigences de test d’applications pour les nouveaux comptes de développeur personnels (nouvel onglet) — la règle des 12 testeurs et des 14 jours, pour la comparaison avec Google Play.