Guide TestFlight (2026) : testeurs internes et externes, revue bêta et lien public

TestFlight est le service de bêta-test d’Apple pour les apps iOS, iPadOS, macOS, tvOS, watchOS et visionOS. Vous envoyez un build dans App Store Connect, vous le partagez aussitôt avec jusqu’à 100 testeurs internes de votre équipe, puis, une fois le premier build de la version validé par la revue TestFlight, avec jusqu’à 10 000 testeurs externes invités par e-mail ou par lien public. Chaque build reste testable 90 jours. Ce guide suit tout le parcours, de l’archive à la soumission sur l’App Store, avec les blocages les plus courants.

Points clés

• Testeurs internes : des utilisateurs App Store Connect de votre équipe, jusqu’à 100, sans revue, dès la fin du traitement du build.
• Testeurs externes : n’importe qui, jusqu’à 10 000 par app, invités par e-mail ou lien public, après validation par la revue TestFlight.
• Le premier build d’une version passe une revue complète ; les suivants de la même version, pas forcément. Six builds au plus peuvent être soumis à la revue en 24 heures.
• Un lien public peut être plafonné (de 1 à 10 000 testeurs) et filtré par appareil et version d’OS.
• Les builds expirent au bout de 90 jours. Le statut « Missing Compliance » signale une question de chiffrement (conformité à l’exportation) sans réponse.
• Les testeurs envoient captures annotées et commentaires de plantage depuis l’app ; vous les lisez dans App Store Connect ou dans Xcode.

Testeurs internes ou externes

TestFlight distingue deux publics, et presque toutes les questions à son sujet en découlent. D’après la présentation de TestFlight dans l’aide App Store Connect :

Chaque testeur peut installer vos builds sur 30 appareils au plus, selon la page TestFlight d’Apple. Un testeur interne a besoin d’un rôle dans App Store Connect et devient donc utilisateur de votre compte : pour un client ou un testeur ponctuel, préférez une invitation externe à une place dans l’équipe.

Envoyer un build : Xcode, Xcode Cloud ou Transporter

Tout build TestFlight part d’une archive. Commencez par incrémenter le numéro de build (CFBundleVersion) : App Store Connect identifie chaque envoi par son identifiant de bundle, sa version et son numéro de build, et refuse un numéro déjà utilisé pour la même version. Choisissez ensuite l’une des méthodes listées dans la page Upload builds :

• Xcode. Product › Archive, puis Distribute App dans l’Organizer. L’option « App Store Connect » envoie un build testable puis soumettable ; « TestFlight Internal Only » envoie un build réservé aux groupes internes, qui ne pourra jamais aller aux testeurs externes ni aux clients.
• Xcode Cloud. Un workflow avec une action Archive et une post-action TestFlight livre les builds aux groupes choisis. La documentation d’Apple ajoute des conditions pour le test externe, comme un build propre depuis une seule branche.
• Transporter. L’app Mac d’Apple envoie un .ipa ou un .pkg exporté, pratique quand le build vient d’une autre machine ou d’un autre système d’intégration continue.
• Ligne de commande et API. xcrun altool et l’API App Store Connect servent aux chaînes automatisées.

Après l’envoi vient le traitement : Apple valide le binaire, prépare les variantes par appareil et effectue ses contrôles automatiques. Vous recevez un e-mail à la fin du traitement, ou un e-mail listant les problèmes (codes ITMS-) si le build est invalide. Apple n’annonce aucune durée de traitement ; elle est en général courte, mais gardez de la marge avant une échéance.

Conformité à l’exportation : la question du chiffrement

Chaque build doit indiquer s’il utilise du chiffrement, car les règles américaines d’exportation s’appliquent aux apps distribuées dans le monde entier. Tant que la question reste sans réponse, le build affiche Missing Compliance et personne ne peut le tester. La présentation de la conformité à l’exportation détaille les usages exemptés : chiffrement fourni par les systèmes d’Apple, connexions HTTPS et TLS, algorithmes standard. La plupart des apps n’utilisent que du chiffrement exempté ; répondez alors une fois pour toutes dans Info.plist et la question disparaît des envois suivants :

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Ne mettez false que si c’est exact. Une cryptographie propriétaire ou non standard exige une documentation, examinée par Apple avant toute distribution (statuts « Waiting for Export Compliance Review » puis « In Compliance Review »). Apple rappelle aussi que la France contrôle l’importation et l’exportation de certaines apps de chiffrement, sous l’égide de l’ANSSI. La déclaration engage votre responsabilité : faites-vous conseiller si votre app embarque son propre chiffrement.

Test interne : groupes et distribution automatique

Dans l’onglet TestFlight, créez un groupe interne, ajoutez-y des utilisateurs App Store Connect, puis des builds. Selon la page consacrée aux testeurs internes, l’option Enable automatic distribution envoie à tout le groupe chaque build transmis depuis Xcode ; sans elle, vous ajoutez les builds à la main. Le champ « What to Test », rempli à l’ajout d’un build, dit aux testeurs ce qui a changé et où regarder ; il s’affiche dans l’app TestFlight.

C’est en test interne que doivent mourir la plupart des bugs. Pour nos propres versions, un petit groupe interne reçoit automatiquement chaque build, et un build ne passe aux groupes externes qu’après quelques jours sans incident sur de vrais appareils.

Test externe et revue TestFlight (Beta App Review)

Pour inviter des testeurs externes, il faut d’abord un groupe interne, puis un groupe externe. Avant la première soumission, remplissez la page Test Information : une description de la bêta et une adresse e-mail de retour sont obligatoires, et la section Beta App Review Information demande un contact pour l’examinateur et, si l’app exige une connexion, des identifiants valides.

Dès que vous ajoutez un build à un groupe externe, il part en revue TestFlight. La page sur les testeurs externes précise que le premier build soumis passe une revue complète, que les builds suivants de la même version peuvent y échapper, et qu’on peut soumettre jusqu’à six builds en 24 heures. Le statut passe de « Waiting for Review » à « In Beta Review », puis à « Ready to Test » ou « Testing » une fois le build accepté. Si vous n’avez pas coché « Automatically notify testers », cliquez vous-même sur Notify Testers.

La revue bêta applique les règles de l’App Store. La règle 2.2 en fixe trois à connaître :

• Une bêta TestFlight doit être destinée à une diffusion publique et respecter les règles. TestFlight n’est pas un canal de distribution privé pour une app qui ne passerait jamais App Review.
• L’accès à la bêta ne peut donner lieu à aucune contrepartie, y compris en récompense d’un financement participatif.
• Les mises à jour importantes d’une bêta doivent repasser par la revue TestFlight avant d’être distribuées.

Un build bêta accepté n’est pas une app acceptée. App Review réexamine la soumission finale, avec ses métadonnées, ses réponses de confidentialité et ses achats intégrés : une bêta validée peut encore être refusée, par exemple au titre des règles 4.2 ou 4.3.

Groupes, lien public et critères de testeurs

Les groupes servent à organiser les testeurs et à décider qui reçoit quel build. Une configuration courante : un groupe interne pour l’équipe, un groupe externe pour les clients ou les proches, et un groupe de bêta publique. Chaque groupe peut recevoir des builds différents, ce qui permet de confier une fonction risquée à un petit groupe d’abord.

Le lien public permet à n’importe qui de rejoindre un groupe externe depuis une URL partagée sur votre site, votre newsletter ou vos réseaux. À sa création, vous choisissez entre « Open to Anyone » et « Filter by Criteria » :

• Plafond de testeurs : limitez le nombre de personnes qui peuvent rejoindre le groupe par le lien, de 1 à 10 000.
• Critères : filtrez par type d’appareil et version d’OS (une plage, un minimum, un maximum ou toutes les versions prises en charge). Utile quand la bêta exige un iOS récent ou une famille d’appareils précise.
• Gestion : modifiez les critères, changez le plafond ou désactivez le lien à tout moment depuis le groupe.

Les testeurs venus par lien public apparaissent comme anonymes dans App Store Connect : vous voyez installations, sessions et plantages, mais ni nom ni e-mail, sauf si le testeur indique son adresse en envoyant un retour. Pour savoir qui teste, invitez par e-mail.

TestFlight sur Mac, Apple Vision Pro et autres plateformes

TestFlight ne se limite pas à l’iPhone : il accepte les builds iOS, iPadOS, macOS, tvOS, watchOS et visionOS, et les testeurs installent l’app TestFlight sur l’appareil correspondant. Deux points comptent pour les apps multiplateformes :

• Apps iPhone et iPad sur Mac Apple silicon. L’option est désactivée par défaut. Dans les réglages de chaque groupe, activez « Test iPhone and iPad apps on Apple silicon Macs » si vous comptez proposer l’app sur le Mac App Store, puis testez redimensionnement des fenêtres, clavier et pointeur.
• Apps Mac et visionOS natives. Chaque plateforme a sa propre liste de builds dans l’onglet TestFlight. Les testeurs envoient des captures commentées depuis TestFlight sur Mac et sur Apple Vision Pro, comme sur iPhone.

Recueillir retours, captures et rapports de plantage

Les testeurs envoient leurs retours sans quitter votre app : une capture, quelques annotations, un commentaire. En cas de plantage, TestFlight propose de le signaler avec un commentaire facultatif. La page View tester feedback indique où tout cela arrive :

• App Store Connect, onglet TestFlight › Feedback › Screenshots et Crashes, avec appareil, version d’OS, build et groupe. Les rapports de plantage se téléchargent pendant 120 jours.
• Xcode, via Open in Xcode ou l’Organizer, où les plantages sont symbolisés à partir de votre archive.
• L’API App Store Connect et les webhooks, pour verser les nouveaux retours dans votre outil de suivi.
• Les indicateurs de build : invitations, installations, sessions des sept derniers jours, plantages et nombre de retours.

La qualité des retours dépend de vos consignes. Une note « What to Test » précise (« Nouveau : export CSV dans Réglages. Essayez avec plus de 100 entrées ») donne des rapports bien plus utiles que « corrections de bugs ». L’adresse e-mail de retour saisie dans Test Information reste disponible pour ceux qui préfèrent écrire.

Que tester avant la soumission App Store ?

La session TestFlight la plus utile est la dernière : le build exact que vous allez soumettre, testé comme le fera l’examinateur. La règle 2.1 sanctionne plantages, liens cassés et contenus provisoires, et la plupart se voient d’abord dans TestFlight. Notre checklist de soumission App Store couvre les métadonnées ; voici le versant build.

Les achats méritent un passage à part. Une app installée depuis TestFlight fonctionne dans l’environnement sandbox, donc personne n’est débité, et les abonnements se renouvellent en accéléré : selon la page d’Apple sur les achats intégrés dans TestFlight, tout abonnement se renouvelle chaque jour, six fois au plus sur une semaine, quelle que soit sa durée. De quoi vérifier renouvellement, expiration et restauration. Pour les nouvelles tentatives de facturation et autres cas limites, utilisez un compte Apple sandbox. Notre guide sur la validation des abonnements par App Review détaille ce que les examinateurs regardent sur le paywall.

Problèmes TestFlight fréquents et solutions

Deux réflexes évitent l’essentiel de ces soucis : incrémenter le numéro de build à chaque archive, et inscrire la clé de chiffrement dans Info.plist dès la première version. Qu’un build expire pendant une longue bêta est normal ; prévoyez un nouvel envoi au moins tous les deux mois pour que vos testeurs aient toujours un build valide.

Comment Develak utilise TestFlight

Develak publie plus de 30 apps sur l’App Store, et chaque version passe par TestFlight avant la soumission : test interne sur nos propres appareils, puis contrôle du build final avec la liste ci-dessus. Pour nos clients, nous configurons les groupes, rédigeons les consignes de test, menons les bêtas externes avec leurs utilisateurs et suivons la revue TestFlight jusqu’à la soumission sur l’App Store. Pour une première version, notre offre de développement de MVP inclut cette phase bêta ; pour une app déjà en ligne, notre maintenance d’application iOS couvre builds réguliers, sessions TestFlight et mises à jour d’iOS.

FAQ