TestFlight est l'outil d'Apple pour distribuer une application avant sa sortie sur l'App Store. Vous envoyez le binaire signé sur App Store Connect, vous invitez des personnes, et elles l'installent sur leur propre iPhone via l'application TestFlight. Ce qu'elles reçoivent n'est ni un aperçu ni un simulateur : c'est exactement le build que vous soumettrez ensuite à l'App Review, avec son icône, ses permissions et son code natif.
Trois chiffres cadrent tout le service. Jusqu'à 100 testeurs internes membres de votre équipe App Store Connect, jusqu'à 10 000 testeurs externes invités par e-mail ou par un lien public, et 90 jours de validité pour chaque build. Tout le reste, de la beta review aux captures d'écran de feedback, découle de la façon dont ces deux groupes sont traités différemment. Ce guide suit le parcours de l'envoi jusqu'au téléphone d'un testeur, puis liste les limites et les erreurs qui retardent un lancement.
TestFlight est une étape d'un parcours plus long. S'il vous faut toute la séquence, du compte développeur à la sortie, lisez notre guide pour publier une app sur l'App Store.
Ce qu'est TestFlight et où il se situe
TestFlight vit dans App Store Connect, sous l'onglet du même nom, et sur les appareils des testeurs sous la forme d'une application gratuite de l'App Store. Il exige une adhésion à l'Apple Developer Program de votre côté, et rien d'autre qu'un compte Apple du côté du testeur. Il couvre iOS, iPadOS, macOS, tvOS, watchOS et visionOS, donc un build Mac ou Vision Pro suit le même parcours qu'un build iPhone.
Sa place dans la chaîne se situe entre le build et la review. Les outils antérieurs montrent votre code sur un téléphone plus vite, mais pas comme votre vraie app : Expo Go ne charge que votre JavaScript dans une coquille partagée, et un development build embarque votre code natif mais avec les outils de développement à l'intérieur. TestFlight est le premier moment où vous tenez le binaire de production. Notre guide pour tester avec Expo Go couvre cette étape antérieure et ses limites.
De l'envoi au téléphone d'un testeur, étape par étape
1. Envoi et traitement
Un build arrive sur App Store Connect depuis Xcode, depuis l'application Transporter d'Apple, depuis un service de build comme EAS Submit, ou depuis une plateforme comme Cadrant qui pilote EAS pour vous. Une fois envoyé, le build passe par un traitement : Apple vérifie le paquet, indexe les symboles et l'analyse, ce qui prend de quelques minutes à environ une heure aux heures de pointe. Il apparaît ensuite sous l'onglet TestFlight de votre app avec un statut.
Le premier arrêt est souvent « Missing Compliance ». Apple demande si l'app utilise un chiffrement au-delà de ce qu'iOS fournit ; pour la plupart des apps qui ne font que des appels HTTPS, la réponse est non, et vous pouvez définir la clé ITSAppUsesNonExemptEncryption dans la configuration de l'app pour que la question ne bloque plus jamais un build. Tant que la réponse n'est pas enregistrée, personne ne peut installer le build.
2. Testeurs internes : votre équipe, sans review
Les testeurs internes sont les personnes qui ont un rôle dans votre équipe App Store Connect : Admin, App Manager, Developer, Marketing ou Customer Support. Vous pouvez en avoir jusqu'à 100 par app, et ils reçoivent chaque build quelques minutes après le traitement, sans review d'Apple. Vous pouvez même cocher « distribuer automatiquement » sur un groupe interne pour que chaque nouvel envoi parte tout seul. C'est la boucle de votre propre équipe : envoyer, tester, corriger, renvoyer, plusieurs fois par jour si nécessaire.
3. Testeurs externes : jusqu'à 10 000 personnes et une beta review
Les testeurs externes, c'est tout le monde d'autre : des clients, des amis, une liste d'attente. Vous les organisez en groupes, vous les invitez par e-mail ou vous partagez un lien public, et chaque groupe peut recevoir des builds différents. La limite est de 10 000 testeurs externes par app, tous groupes confondus. La présentation de TestFlight par Apple fixe les règles des deux cercles.
La différence avec le test interne, c'est la Beta App Review. Le premier build que vous ajoutez à un groupe externe est envoyé à l'App Review pour vérifier qu'il respecte les App Review Guidelines, en pratique un contrôle plus léger que la review de sortie, qui passe en général sous un jour. Les builds suivants d'une même version partent souvent sans nouvelle review complète, sauf si vous changez ce à quoi Apple tient. Pour que cette review passe, remplissez les informations de test : quoi tester, un e-mail de contact, et un compte de démonstration si l'app exige une connexion.
4. Du côté du testeur
Un testeur installe l'application TestFlight, ouvre l'e-mail d'invitation ou le lien public, accepte, et touche Installer. L'app apparaît sur l'écran d'accueil avec un point orange à côté de son nom, le signe qu'il s'agit d'une bêta. Quand vous envoyez un nouveau build, TestFlight le prévient et peut mettre à jour automatiquement. Pour envoyer un retour, il prend une capture d'écran et passe par la feuille de partage, ou secoue l'appareil si vous l'avez activé ; la capture et son commentaire arrivent dans App Store Connect, avec les rapports de crash pour tout plantage subi pendant le test.
Limites, délais et les erreurs qui coûtent une semaine
| Règle | Valeur | Conséquence |
|---|---|---|
| Testeurs internes | 100 par app, utilisateurs App Store Connect | Ajoutez d'abord vos collègues à l'équipe ; il leur faut un rôle, pas seulement un e-mail |
| Testeurs externes | 10 000 par app, e-mail ou lien public | Un lien public peut être plafonné et fermé ; des critères sur le lien réduisent qui peut entrer |
| Beta App Review | Premier build par groupe externe, en général sous un jour | Prévoyez le premier build externe un jour avant d'avoir besoin des testeurs dessus |
| Validité d'un build | 90 jours | Passé ce délai, l'app ne s'ouvre plus chez les testeurs tant qu'un nouveau build n'est pas envoyé |
| Traitement | De quelques minutes à environ une heure | Ne renvoyez pas un build parce qu'il « n'est pas encore là » ; attendez l'e-mail |
| Coût | Gratuit avec le Developer Program | L'adhésion à 99 $ par an est le seul frais |
Les délais dont les gens se plaignent viennent rarement d'Apple. Ils viennent de ces erreurs :
- Laisser la question du chiffrement sans réponse. Le build reste en Missing Compliance et les invitations ne partent jamais. Définissez la clé de chiffrement dans la configuration une fois pour toutes.
- Croire que le test externe est immédiat. L'interne est immédiat ; l'externe attend la Beta App Review. Utilisez un groupe interne pour les premières heures et le groupe externe pour les premiers jours.
- Pas de notes de test, pas de compte démo. La Beta App Review a besoin d'une porte d'entrée, exactement comme la review de sortie. Un identifiant qui fonctionne évite un build refusé.
- Inviter le mauvais compte Apple. L'invitation est liée à l'e-mail ; si l'appareil du testeur utilise un autre compte Apple, l'invitation ne correspond jamais. Les liens publics évitent le problème.
- Traiter TestFlight comme un canal de distribution. Les guidelines interdisent de s'en servir pour livrer une app au public à la place de l'App Store, et les builds meurent de toute façon après 90 jours.
TestFlight avec Cadrant
Si votre app est un projet mobile Cadrant, les étapes avant TestFlight sont prises en charge : le build iOS tourne sur votre propre compte Expo (le plan gratuit couvre 15 builds iOS par mois), et Expo dépose le binaire fini sur votre compte App Store Connect, où la fiche de l'app et le certificat de distribution ont été créés pendant un parcours guidé. À partir de là, vous êtes dans le parcours TestFlight standard : ouvrez App Store Connect, répondez à la question du chiffrement si elle est posée, ajoutez des testeurs internes ou un groupe externe, et installez sur vos appareils.
Ce qu'il faut y vérifier, c'est ce que l'aperçu dans l'éditeur et Expo Go ne peuvent pas montrer : les API natives comme la caméra, les notifications push et les sélecteurs de fichiers, les parcours de connexion et de données contre votre projet Supabase, les performances sur un vrai appareil, et le comportement quand une permission est refusée ou hors ligne. Un bug ? Corrigez-le dans Cadrant, publiez un nouveau build, distribuez-le, et recommencez jusqu'à être prêt pour l'App Review. La documentation Tester avec TestFlight liste les clics exacts.
En résumé
- Envoyer, attendre le traitement, répondre à la question du chiffrement : ce n'est qu'à ce moment que quelqu'un peut installer.
- Les testeurs internes (100 membres de l'équipe) reçoivent les builds immédiatement ; les testeurs externes (10 000) attendent une Beta App Review sur le premier build d'une version.
- Remplissez les notes de test et un compte démo, invitez par lien public quand vous le pouvez, et n'oubliez pas l'expiration à 90 jours.
- Testez sur TestFlight ce qu'Expo Go ne peut pas montrer, parce que le reviewer, lui, le verra.
Utilisé ainsi, TestFlight n'est pas une étape de plus avant le lancement : c'est le lancement, répété avec de vraies personnes sur de vrais téléphones, quelques jours en avance.