# TestFlight : c'est quoi, et comment tester une app iPhone

> TestFlight est l'app gratuite d'Apple pour installer une app iPhone en bêta avant sa sortie : 100 testeurs internes, 10 000 externes, 90 jours par build.

Page originale : [TestFlight : c'est quoi, et comment tester une app iPhone](https://devoria.fr/blog/testflight-tester-son-app-iphone)
Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi)
Publication : 2026-09-23
Dernière révision du contenu : 2026-11-04


## TestFlight, c'est quoi et à quoi ça sert ?

TestFlight est le service d'Apple qui te permet d'installer ton application sur de vrais iPhone avant sa sortie sur l'App Store. Tu envoies une build dans App Store Connect, tu invites des testeurs, et ils l'installent avec l'application TestFlight, gratuite sur l'App Store. Il y a deux types de testeurs : les internes, jusqu'à 100 membres de ton équipe, sans revue d'Apple ; et les externes, jusqu'à 10 000 personnes, invitées par e-mail ou par lien public, après une revue bêta de ta première build. Chaque build reste testable 90 jours.

**Tu as reçu une invitation TestFlight ?** D'après [la page TestFlight d'Apple](https://testflight.apple.com/), installe l'app TestFlight depuis l'App Store, ouvre l'e-mail et touche View in TestFlight, ou touche le lien public sur ton iPhone. Ensuite Accept, puis Install. TestFlight ne fonctionne que sur les appareils Apple : iPhone, iPad, Mac, Apple TV, Apple Vision Pro et Apple Watch.

| Critère            | Testeurs internes          | Testeurs externes           |
| ------------------ | -------------------------- | --------------------------- |
| Nombre maximum     | 100                        | 10 000                      |
| Accès à ton compte | Oui, avec un rôle          | Non                         |
| Invitation         | Ajout au groupe interne    | E-mail ou lien public       |
| Revue bêta d'Apple | Aucune                     | Sur la première build       |
| Pour qui           | Toi, un associé, un proche | Amis, premiers utilisateurs |

Pour utiliser TestFlight, il te faut un [compte Apple Developer payant](https://devoria.fr/blog/compte-developpeur-apple-prix-inscription) : [le service n'est pas accessible avec un compte gratuit](https://developer.apple.com/support/compare-memberships/). Tout le reste de ce guide suppose que tu en as un, au titre du programme standard : le [programme Entreprise d'Apple](https://devoria.fr/blog/apple-developer-enterprise-program) ne donne pas accès à TestFlight.

Sur mes apps, chaque build envoyée par EAS Submit passe par TestFlight et par mon iPhone avant d'être envoyée en revue. C'est là que je trouve les problèmes qui ne se voient pas en développement.

## Envoyer une build dans TestFlight

Une build, c'est une version compilée et signée de ton app : mal signée, Apple la refuse à l'envoi en [ITMS-90034](https://devoria.fr/blog/itms-90034-signature-invalide). Pour qu'elle apparaisse dans TestFlight, tu dois l'envoyer à App Store Connect. Avec Expo, c'est `eas build --platform ios` puis `eas submit --platform ios`, avec une image de build assez récente pour éviter [ITMS-90725](https://devoria.fr/blog/itms-90725-sdk-version-xcode). [D'après la documentation d'Expo](https://docs.expo.dev/submit/ios/), la build apparaît dans TestFlight après son traitement par Apple, en général en 10 à 15 minutes. Tu peux faire tout ça depuis un PC : le guide [publier une app iOS sans Mac](https://devoria.fr/blog/publier-une-app-ios-sans-mac) détaille la chaîne complète.

Deux détails bloquent souvent la première fois :

- **Le numéro de build doit changer à chaque envoi.** Apple refuse [deux builds avec le même numéro](https://devoria.fr/blog/numero-de-build-version-app-store-connect) pour une même version. Avec EAS, active l'incrémentation automatique et tu n'y penses plus.
- **La question sur le chiffrement.** Tant que tu n'as pas répondu à la question sur l'usage du chiffrement, la build reste bloquée avec un statut de conformité manquante. Tu peux y répondre à chaque fois dans App Store Connect, ou le déclarer une fois pour toutes dans la configuration de ton app. Les deux gestes, pour ce build et pour les suivants, sont dans [Missing Compliance TestFlight : corriger le statut pour de bon](https://devoria.fr/blog/missing-compliance-testflight-chiffrement).

## Testeurs internes : ton équipe, sans attendre

Les testeurs internes sont des utilisateurs de ton compte App Store Connect, avec un rôle attribué. [Apple en autorise jusqu'à 100](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview), et chacun peut [installer l'app sur plusieurs appareils](https://developer.apple.com/testflight/), jusqu'à 30.

Leur gros avantage : pas de revue bêta. Dès que la build a fini son traitement, sans erreur automatique comme [ITMS-90717](https://devoria.fr/blog/itms-90717-icone-app-store-transparence), tu l'ajoutes à ton groupe interne et elle est disponible. C'est le bon groupe pour toi, et pour un associé ou un proche à qui tu donnes un accès à ton compte.

Leur limite : il faut les ajouter comme utilisateurs de ton compte App Store Connect. Ce n'est pas adapté à des inconnus.

## Testeurs externes et revue bêta

Les testeurs externes n'ont besoin d'aucun accès à ton compte. [Tu peux en inviter jusqu'à 10 000](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview), par e-mail ou par lien public. C'est le bon groupe pour des amis, des premiers utilisateurs, une communauté.

En contrepartie, Apple vérifie la build avant de la leur ouvrir. [Quand tu ajoutes la première build d'une version à un groupe externe](https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers), elle part en revue bêta. Les builds suivantes de la même version ne demandent pas forcément une revue complète.

Avant cet envoi, App Store Connect te demande des informations de test :

- **une description de la bêta**, qui dit aux testeurs ce qu'ils doivent regarder ;
- **une adresse e-mail pour les retours** ;
- **tes coordonnées**, pour qu'Apple puisse te joindre.

> La revue bêta n'est pas la revue de l'App Store. Une build acceptée en TestFlight peut encore être refusée à la publication.

La revue bêta vérifie que la build respecte les règles, mais la revue finale regarde aussi ta fiche, tes abonnements, tes textes légaux et l'expérience complète. Garde en tête les motifs de refus classiques, racontés dans [pourquoi Apple refuse une app](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app).

## Inviter des testeurs par lien public

Le lien public est la façon la plus simple de faire tester ton app à des gens que tu ne connais pas encore. Voici [la marche à suivre d'Apple](https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers), avec les libellés de l'interface en anglais :

1. Dans App Store Connect, ouvre ton app puis l'onglet **TestFlight**.
2. Sous **External Testing**, sélectionne ton groupe externe.
3. Clique sur **Create Public Link**.
4. Choisis **Open to Anyone** pour ouvrir le lien à tous, ou **Filter by Criteria** pour le limiter à certains appareils et versions d'iOS.
5. Si tu veux, fixe une limite de testeurs avec **Set Limit**.

Tu partages ensuite le lien où tu veux : message, réseau social, e-mail. La personne installe l'app TestFlight, ouvre le lien et accepte l'invitation.

Deux choses à savoir avant de le diffuser largement :

- **Fixe une limite.** Si ton lien circule plus que prévu, tu garderas le contrôle du nombre de testeurs.
- **Les testeurs par lien public sont anonymes.** App Store Connect n'affiche pour eux que la date d'installation, les sessions et les plantages. Si tu veux savoir qui a testé quoi, invite plutôt par e-mail.

## Combien de temps dure une build TestFlight ?

[Une build reste disponible pour les testeurs pendant 90 jours](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview). Au-delà, elle expire et tes testeurs ne peuvent plus l'ouvrir. Si ta bêta dure plus longtemps, envoie simplement une nouvelle build avant l'échéance.

En pratique, tu enverras de nouvelles builds bien plus souvent : à chaque correction importante. Chaque nouvelle build ajoutée au groupe est proposée à tes testeurs, qui la récupèrent dans l'app TestFlight.

## Récupérer les retours des testeurs

TestFlight intègre un système de retours : [le testeur fait une capture d'écran dans ton app, peut l'annoter, et te l'envoie](https://developer.apple.com/testflight/). Si l'app plante, tu reçois un rapport de plantage, et le testeur peut ajouter du contexte. Tu retrouves tout dans App Store Connect.

C'est utile, mais ça ne suffit pas pour comprendre un plantage précis. Sur mes apps, j'ajoute Sentry, qui remonte l'erreur avec la ligne de code en cause, et PostHog, qui montre où les utilisateurs abandonnent. Les deux fonctionnent dans une build TestFlight comme en production.

## Tester les abonnements dans TestFlight

Si ton app vend un abonnement, TestFlight est l'endroit où tu vérifies qu'il fonctionne vraiment. [Les achats faits dans une build TestFlight passent par l'environnement de test d'Apple](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testing-subscriptions-and-in-app-purchases-in-testflight/) : tes testeurs ne sont pas débités. Les renouvellements sont accélérés : chaque abonnement se renouvelle une fois par jour, six fois au plus sur une semaine, quelle que soit sa durée réelle.

Vérifie au minimum que [les prix affichés](https://devoria.fr/blog/prix-app-store-par-pays) sont les bons, que l'achat débloque bien l'app, et que le bouton de restauration retrouve l'abonnement après une réinstallation. J'utilise RevenueCat pour gérer les abonnements de mes apps ; tout le montage, des produits App Store Connect au paywall, est décrit sur la page [abonnements in-app iOS](https://devoria.fr/expertise/abonnement-in-app-ios).

## Ce que tu dois tester avant l'envoi à Apple

C'est la liste que j'applique avant chaque envoi en revue. Chaque point correspond à un motif de refus ou à un plantage évitable.

### Le premier lancement

- Supprime l'app, réinstalle-la depuis TestFlight, ouvre-la. C'est ce que fera le reviewer.
- Parcours l'onboarding en entier, sans rien sauter.
- Refuse chaque permission ([notifications](https://devoria.fr/blog/guideline-4-5-4-notifications-push), caméra, position) et vérifie que l'app continue de fonctionner.

### L'argent

- Le paywall affiche les prix, la durée et les liens vers les conditions d'utilisation et la politique de confidentialité.
- L'achat fonctionne, la restauration aussi.
- Tous les produits configurés sont visibles pour le reviewer : [la guideline 2.1](https://developer.apple.com/app-store/review/guidelines/) demande que les achats intégrés soient complets, visibles et fonctionnels.

### Les conditions difficiles

- Le mode avion et un réseau lent : un message clair, pas un écran blanc.
- Le plus petit iPhone que tu prends en charge et le plus grand : [rien de coupé, rien de masqué par le clavier](https://devoria.fr/blog/guideline-4-0-design). C'est un écran coupé sur petit iPhone qui m'a valu un refus sur Solys.
- Les textes longs, si ton app est traduite.

### Le dossier pour le reviewer

- Si ton app demande une connexion, un compte de démonstration dans les notes de revue, avec ton backend allumé. La guideline 2.1 le demande explicitement.
- Des notes de revue qui expliquent en deux phrases ce que fait l'app et où trouver la fonction principale.

Si malgré tout ton app est refusée, la page [application refusée par Apple](https://devoria.fr/expertise/application-refusee-par-apple) explique comment répondre sans perdre une semaine. Et pour la vue d'ensemble de la publication, de la fiche à la sortie, lis [publier une application sur l'App Store](https://devoria.fr/expertise/publier-une-application-sur-app-store).

## Une grille de recette à remplir sur ta build

[Télécharge la grille de 16 scénarios au format CSV](https://devoria.fr/ressources/recette-premiere-app-ios.csv). Elle distingue la préparation, le geste à réaliser, le résultat attendu et la preuve observée. Importe-la dans Numbers, Excel ou Google Sheets, puis renseigne la version, l’appareil et le résultat de chaque essai.

Pour un carnet de lecture fictif, « enregistrer une page » ne suffit pas : note la page 24, ferme complètement l’app, relance-la et retrouve la valeur. Un test qui n’a pas été exécuté reste « À tester ». Si ton app n’a aucun abonnement, indique « Non applicable » pour les scénarios d’achat, avec cette raison.

La grille est un point de départ à adapter, pas une certification. Retrouve aussi les [notes App Review et les autres modèles gratuits](https://devoria.fr/ressources) pour expliquer au reviewer le parcours que tu as réellement vérifié.

## Passer de TestFlight à l'App Store

TestFlight est l'étape où ton app devient réelle : elle tourne sur un vrai iPhone, entre les mains de vrais gens. Dans le parcours du [Kit iOS](https://devoria.fr/kits/ios), c'est la deuxième étape : construire le cœur de l'app et la tester sur ton iPhone avec TestFlight, avant de brancher les abonnements puis de préparer la publication.

Après TestFlight vient la review d'Apple : le [Kit Review Apple](https://devoria.fr/kits/review-apple) réunit ma checklist avant l'envoi et les notes pour le testeur. L'accueil montre les quatre étapes pour [créer ton application mobile](https://devoria.fr/) avec Claude Code.

Personne ne peut te garantir qu'Apple acceptera ton app : c'est Apple qui décide.

## Questions fréquentes

### TestFlight, c'est quoi en une phrase ?

C'est le service d'Apple qui sert à distribuer les versions bêta d'une app, à gérer ses testeurs et à recueillir leurs retours, selon [l'aide d'App Store Connect](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview). Le développeur y envoie une build, le testeur l'installe avec l'app TestFlight, avant la sortie sur l'App Store.

### TestFlight est-il gratuit ?

Pour le testeur, oui : Apple parle de l'app TestFlight comme d'une app gratuite, et les achats intégrés ne sont pas facturés pendant la bêta. Pour le développeur, TestFlight est inclus dans l'Apple Developer Program, à 99 $ par an, et n'est pas accessible avec un compte Apple gratuit.

### Comment installer une app avec TestFlight quand on est testeur ?

Installe l'app TestFlight depuis l'App Store. Ouvre ensuite l'e-mail d'invitation et touche View in TestFlight, ou touche le lien public sur ton iPhone. Touche Accept, puis Install. Les mises à jour de la bêta arrivent ensuite dans l'app TestFlight.

### Que se passe-t-il quand une build TestFlight expire ?

Au bout de 90 jours, la build n'est plus disponible pour les testeurs et l'app ne s'ouvre plus. Pour continuer la bêta, le développeur envoie une nouvelle build avant l'échéance, et les testeurs la récupèrent dans TestFlight.

### TestFlight existe-t-il sur Android ?

Non. TestFlight est réservé aux appareils Apple. Sur Android, l'équivalent passe par [les tests internes, fermés ou ouverts](https://support.google.com/googleplay/android-developer/answer/9845334?hl=fr) de la Google Play Console.

### Comment tester son app iPhone avec TestFlight ?

Envoie une build à App Store Connect, puis ajoute-la à un groupe de testeurs. Avec Expo, tu la compiles avec EAS Build et tu l'envoies avec [EAS Submit](https://devoria.fr/blog/publier-app-expo-app-store-eas) : elle apparaît dans TestFlight après son traitement par Apple, en général en 10 à 15 minutes d'après Expo. Tes testeurs l'installent avec l'app TestFlight, gratuite sur l'App Store. Il te faut un compte Apple Developer payant.

### Comment générer un lien TestFlight pour inviter des testeurs ?

Dans App Store Connect, ouvre l'onglet TestFlight de ton app, sélectionne ton groupe sous External Testing et clique sur Create Public Link. Choisis Open to Anyone ou Filter by Criteria, puis fixe une limite avec Set Limit. Les testeurs par lien public restent anonymes : si tu veux savoir qui a testé quoi, invite-les plutôt par e-mail.

### La revue bêta de TestFlight remplace-t-elle la revue de l'App Store ?

Non. La revue bêta vérifie que la build respecte les règles, mais la revue finale regarde aussi ta fiche, ton [age rating](https://devoria.fr/blog/classification-age-app-store-connect), tes abonnements, tes textes légaux et l'expérience complète. Une build acceptée en TestFlight peut donc encore être refusée à la publication. Seuls les testeurs externes déclenchent une revue bêta, sur la première build d'une version : les testeurs internes n'en passent aucune.

### Combien de testeurs peut-on inviter sur TestFlight ?

Tu peux inviter jusqu'à 100 testeurs internes et jusqu'à 10 000 testeurs externes. Les internes sont des membres de ton compte App Store Connect, sans revue bêta, et chacun peut installer l'app sur jusqu'à 30 appareils. Les externes sont invités par e-mail ou par lien public, après une revue bêta de la première build. Chaque build reste testable 90 jours.

### Peut-on tester un abonnement dans TestFlight sans être débité ?

Oui, les achats faits dans une build TestFlight passent par l'environnement de test d'Apple : [tes testeurs ne sont pas débités](https://devoria.fr/blog/codes-offre-promo-app-store-connect). Les renouvellements sont accélérés : chaque abonnement se renouvelle une fois par jour, six fois au plus sur une semaine, quelle que soit sa durée réelle. Vérifie au minimum les prix affichés, le déblocage de l'app et la restauration après une réinstallation. Le montage complet est décrit sur [abonnements in-app iOS](https://devoria.fr/expertise/abonnement-in-app-ios).

### Que faut-il vérifier dans TestFlight avant d'envoyer l'app à Apple ?

Réinstalle l'app depuis TestFlight, comme le fera le reviewer, et parcours l'onboarding en entier. Refuse chaque permission, teste l'achat et la restauration, puis essaie le mode avion, le plus petit et le plus grand iPhone que tu prends en charge. Si l'app demande une connexion, prépare un compte de démonstration dans les notes de revue, avec ton backend allumé.


## Ton projet

[Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement.

[Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement.

[Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio.

[Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.