Qu’est-ce que TestFlight ? Le guide complet pour débuter, de la première invitation à l’installation

Informations vérifiées le 17 septembre 2026. Cet article se concentre sur l’iPhone et l’iPad. Les interfaces et les règles d’Apple évoluent : référez-vous aux documents officiels cités et aux pages que vous voyez réellement.

Vous avez créé une application et souhaitez la faire essayer à vos amis, mais vous n’êtes pas encore prêt à la publier sur l’App Store. Leur envoyer le code source ne convient pas, et même avec un fichier d’installation, rien ne garantit qu’ils puissent l’installer.

C’est précisément le problème que TestFlight résout.

L’abréviation « TF » désigne généralement TestFlight. Ce service de distribution de versions de test est proposé par Apple : les développeurs chargent une version bêta, invitent des personnes à l’installer, recueillent leurs retours, puis diffusent une version améliorée. Les testeurs installent une véritable application qui fonctionne sur leur appareil, pas une capture d’écran ni une démonstration sur le Web.[1][2]

Retenez d’abord trois choses :

• Le test interne s’adresse aux membres disposant des autorisations appropriées dans App Store Connect.
• Le test externe convient aux amis, clients et membres d’une communauté, sans leur donner accès à l’interface de gestion des développeurs.
• Chaque build peut être testé pendant 90 jours au maximum, à compter du jour de son chargement. L’approbation pour les tests ne signifie pas une publication sur l’App Store.[1][3]

Si vous avez simplement reçu un lien, vous pouvez commencer par la section 9 sur l’installation côté testeur. Si vous souhaitez partager votre propre application, commencez au début.

1. TestFlight, App Store Connect et App Store : à quoi servent-ils ?

Imaginez votre nouvelle application comme une boutique en phase d’ouverture à l’essai : TestFlight vous aide à inviter des personnes pour l’essayer, tandis que l’App Store est le canal de son ouverture officielle. Cette phase d’essai a elle aussi une durée limitée et des règles : ce n’est pas un moyen détourné d’éviter les examens.

Ces trois noms se ressemblent, mais leurs fonctions sont différentes :

Si le tableau est trop large, faites-le défiler horizontalement. Au clavier, placez le focus dessus, puis utilisez les touches fléchées.

Sur l’App Store, vous téléchargez l’outil TestFlight, puis vous l’utilisez pour installer les applications que l’on vous invite à tester. La présence d’une application dans TestFlight ne signifie pas qu’elle soit déjà trouvable sur l’App Store.[1][3]

Apple s’en sert pour relier les étapes « diffuser une version — inviter des testeurs — recueillir les problèmes — mettre à jour la version ». Aujourd’hui, TestFlight n’exige plus des développeurs qu’ils recueillent individuellement les identifiants des appareils des testeurs, ni qu’ils créent un profil de provisionnement distinct pour chacun.[2]

En revanche, il n’écrit pas l’application à votre place, ne prouve pas que toutes ses fonctions sont correctes et ne transforme pas automatiquement une bêta en version publique. Même après un examen pour les tests, rien ne garantit l’absence de failles ou de pertes de données. Si vous testez une application inconnue, n’y exposez pas l’unique copie de données importantes.

2. L’histoire de TestFlight : Apple ne l’a pas créé de toutes pièces

Son histoire explique les différences de noms, de limites de testeurs et de procédures que l’on rencontre dans les anciens tutoriels.

• Janvier 2011 : lancement public d’un service tiers. À l’époque, tester une application iPhone non publiée impliquait souvent de gérer des identifiants d’appareils, des fichiers d’installation et des profils de provisionnement, puis de synchroniser le tout avec iTunes sur un ordinateur. TestFlight a grandement simplifié l’installation sans fil. Cette date correspond au passage d’un test privé à un service public, pas à la création juridique de l’entreprise.[H1]
• Mars 2012 : annonce du rachat par Burstly. TestFlight était encore un produit tiers.[H2]
• Février 2014 : Apple rachète Burstly. TestFlight rejoint Apple avec sa société mère.[H3]
• Octobre 2014 : Apple annonce les invitations aux tests par e-mail via iTunes Connect. iTunes Connect était le prédécesseur de l’actuel App Store Connect, et permettait alors d’inviter jusqu’à 1 000 personnes. Attention : ce chiffre est historique.[H4]
• Juillet 2017 : le nombre de testeurs externes pouvant être invités passe à 10 000.[H5]
• Septembre 2018 : Apple introduit les liens d’invitation publics. Les développeurs peuvent recruter des testeurs en partageant un lien, sans recueillir au préalable chaque adresse e-mail.[H6]

Le service couvre aujourd’hui plusieurs plateformes Apple, notamment l’iPhone, l’iPad, le Mac, l’Apple Watch, l’Apple TV et l’Apple Vision Pro. Cet article prend l’iPhone pour exemple : cela ne signifie ni que TestFlight se limite aux applications iPhone, ni qu’il permet de distribuer des applications Android.[2][3]

3. Cinq termes à connaître : bêta, version, build, groupe et examen

Version bêta (Beta) : une version de l’application encore en cours de validation et d’amélioration, qui peut présenter des problèmes.

Version (Version) : un identifiant tel que 1.0 ou 1.1, qui désigne une version destinée aux utilisateurs.

Build : un résultat précis de la compilation et de la préparation de l’application. Par exemple, 1.0 (12) correspond à la version 1.0, build numéro 12. Après avoir corrigé un problème, vous pouvez charger 1.0 (13) : la version destinée aux utilisateurs reste la même, mais le contenu installé a changé.[7]

Groupe (Group) : il détermine qui peut recevoir quels builds. Vous pouvez créer un groupe « Équipe » et un groupe « Premiers utilisateurs », puis leur attribuer les mêmes builds ou des builds différents. Un groupe peut contenir plusieurs builds, et un même build ordinaire peut être attribué à plusieurs groupes.[2][5][6]

Examen pour les tests (TestFlight App Review) : l’examen réalisé par Apple pour les tests externes. Il est distinct de l’examen nécessaire à la publication officielle sur l’App Store.[1][6]

Pour vous repérer, retenez cette relation : l’application est le projet dans son ensemble ; le build est un contenu d’installation précis ; le groupe détermine qui peut l’essayer. Un lien d’invitation public appartient à un groupe externe : il n’est pas définitivement rattaché à un build donné.

4. Que doivent préparer l’éditeur et les testeurs avant de commencer ?

Ce que l’éditeur doit préparer

1. Une adhésion valide à l’Apple Developer Program. Le tarif standard actuel d’Apple est de 99 dollars américains par an ; les prix peuvent varier selon la région, et certains organismes admissibles peuvent demander une exonération des frais. TestFlight est inclus dans les services concernés de l’adhésion : ce n’est pas un abonnement supplémentaire à acheter pour les testeurs.[4]
2. Une fiche d’application correcte dans App Store Connect. L’identifiant, la signature et le contenu chargé doivent correspondre. Vous ne pouvez pas y ajouter arbitrairement le fichier d’installation d’une autre application.[7]
3. Des autorisations de compte suffisantes, sans être excessives. Les rôles Titulaire du compte, Administrateur, Gestionnaire d’apps ou Développeur peuvent charger des builds ; la gestion des tests externes nécessite le rôle Titulaire du compte, Administrateur ou Gestionnaire d’apps. Pouvoir charger un build ne signifie pas pouvoir modifier tous les réglages des tests externes.[6][7]
4. Les informations nécessaires aux tests. Cela comprend la description de l’application, l’adresse e-mail de contact pour les retours et ce que vous souhaitez faire tester. L’examen externe nécessite également des coordonnées de contact et un moyen de connexion ou d’accès aux fonctions réellement utilisable par les personnes chargées de l’examen.[6][8]
5. Des appareils et du temps pour tester. Un chargement réussi ne signifie pas que l’installation et les fonctions principales ont été vérifiées.

Ne communiquez pas votre mot de passe Apple à vos amis. Pour leur faire tester une application, envoyez une invitation au lieu de partager un compte de gestion.

Ce dont un testeur ordinaire a besoin

Il vous suffit d’un compte Apple, d’un appareil compatible, de TestFlight et d’une invitation valide. Vous n’avez pas besoin de payer une adhésion au programme pour développeurs, ni d’accéder à leur interface de gestion.[1][3]

À la date de vérification de cet article, l’aide Apple destinée aux testeurs indique iOS 16 et iPadOS 16 ou une version ultérieure pour l’iPhone et l’iPad. Mais une application donnée peut exiger un système plus récent, et une invitation publique peut aussi filtrer les appareils et les versions du système. Pouvoir installer TestFlight ne signifie pas pouvoir installer toutes les applications qu’il propose.[3][6]

Si vous utilisez un compte Apple géré fourni par votre employeur ou votre établissement scolaire, vérifiez particulièrement votre admissibilité : l’aide Apple sur les tests externes précise que ces comptes ne peuvent pas servir à tester des builds. L’aide sur les tests internes indique séparément que les comptes gérés créés dans un domaine réservé ne peuvent pas être utilisés pour les tests. Dans ce cas, vérifiez la page d’aide correspondante et les règles de votre organisation, plutôt que d’y voir un dysfonctionnement du lien d’invitation.[5][6]

5. Quelle est la différence entre test interne et test externe ?

La différence essentielle porte sur le statut et les autorisations dans l’interface de gestion, et non sur votre proximité avec la personne ou sur l’envoi de l’invitation par e-mail.

Si le tableau est trop large, faites-le défiler horizontalement. Au clavier, placez le focus dessus, puis utilisez les touches fléchées.

Les rôles admissibles pour les testeurs internes sont : Titulaire du compte (Account Holder), Administrateur (Admin), Gestionnaire d’apps (App Manager), Développeur (Developer) et Marketing (Marketing). Ces personnes doivent aussi avoir accès à l’application concernée.[2][5]

Même pour inviter un ami en privé par e-mail, le test externe reste généralement le bon choix. Externe ne signifie pas public : vous pouvez tout à fait n’inviter que quelques personnes, sans activer de lien public.

Ne donnez pas de droits d’administrateur à un testeur ordinaire dans le seul but d’éviter un examen. Il ne s’agit pas d’un simple bouton autorisant l’installation, mais de véritables droits de gestion.

Autre limite facile à oublier : un compte de développeur individuel peut ajouter au maximum 50 utilisateurs App Store Connect. La limite de « 100 testeurs internes » de TestFlight ne signifie donc pas que chaque compte individuel peut créer 100 membres supplémentaires dans l’interface de gestion.[9]

6. Comment ajouter un build ? Distinguez « charger » et « ajouter à un groupe de test »

Il s’agit en réalité de deux opérations :

• Charger un build : transmettre à Apple une application déjà compilée et préparée, depuis un outil de développement ou de compilation.
• Ajouter un build à un groupe : choisir, parmi les builds déjà chargés et disponibles, celui que vous souhaitez distribuer à ce groupe.

Dans un groupe de test d’App Store Connect, « Ajouter des builds (Add Builds) » ne permet ni de glisser du code source pour générer automatiquement une application, ni de charger un fichier local.[5][6][7]

Première publication : que faire si l’application n’existe pas encore dans l’interface de gestion ?

Une personne ayant le rôle Titulaire du compte, Administrateur ou Gestionnaire d’apps doit ouvrir Apps (Apps) → « + » → Nouvelle app (New App), sélectionner la plateforme, puis renseigner le nom de l’application, la langue principale, l’identifiant de lot (Bundle ID), le SKU utilisé pour la gestion et les autres informations requises. Elle définit ensuite l’accès des membres et crée la fiche. L’identifiant de lot doit correspondre au projet ; si vous ne savez pas lequel utiliser, demandez à la personne chargée de préparer le build, plutôt que de choisir arbitrairement celui d’une autre application.

Si la création est impossible, vérifiez que le titulaire du compte a accepté les derniers contrats. Créer une fiche d’application ouvre simplement un espace de gestion : cela ne charge ni ne publie l’application.[15]

Le parcours de base pour charger un build avec Xcode

Si vous avez déjà un projet iOS, procédez dans cet ordre :

1. Vérifiez que l’identifiant de lot et l’équipe de signature correspondent à la fiche de l’application dans App Store Connect.
2. Attribuez à ce nouveau chargement un numéro de build qui n’a pas déjà été utilisé, par exemple en passant de 1.0 (12) à 1.0 (13).
3. Sélectionnez une destination de distribution pour un appareil réel, puis cliquez sur Product → Archive pour créer une archive, au lieu de tenter de charger une version pour simulateur.
4. Dans Window → Organizer → Archives, sélectionnez l’archive et cliquez sur Distribute App. Pour un usage classique de TestFlight suivi d’une publication officielle, choisissez TestFlight & App Store ; dans un parcours personnalisé, cela correspond à la distribution via App Store Connect. Suivez les étapes de signature et de chargement affichées.[16]
5. Après le chargement, ouvrez App Store Connect → Apps (Apps) → votre application → TestFlight.
6. Attendez le traitement par Apple. Si des questions de conformité à l’exportation apparaissent, répondez fidèlement selon le chiffrement réellement utilisé par votre application ; ne choisissez pas systématiquement « aucun chiffrement » pour continuer.
7. Une fois le traitement terminé et le build disponible, ajoutez-le à un groupe de test interne ou externe.

Des outils comme Xcode Cloud et Transporter peuvent aussi intervenir dans le chargement. Changer d’outil ne permet pas de contourner le traitement d’Apple, la conformité, les groupes ou l’examen externe.[7] Les exigences minimales relatives aux outils de chargement et aux SDK évoluent : consultez les exigences actuelles d’Apple pour les chargements au moment de procéder. La version du SDK utilisé pour compiler n’est pas la version minimale du système sur lequel l’application peut être installée.[18]

Attention à l’option « réservé aux tests internes »

TestFlight Internal Only impose une restriction liée au mode de chargement : ces builds ne peuvent être ajoutés qu’à des groupes internes. Ils ne peuvent servir ni aux tests externes, ni à une distribution aux utilisateurs de la version publique. Si vous souhaitez ensuite effectuer des tests externes ou publier officiellement, vous devez charger un nouveau build selon la méthode appropriée ; changer simplement le groupe du build existant ne suffit pas.[5][6]

À l’inverse, ajouter d’abord un build ordinaire à un groupe interne ne le transforme pas automatiquement en build « réservé aux tests internes ». Ne confondez pas « actuellement testé par des membres internes » et « ce chargement est limité à un usage interne ».

Si vous développez votre application dans AirBuild

Vous pouvez demander à AirBuild de vous aider à préparer un build distribuable, à le signer, à le charger, ainsi qu’à configurer les groupes de test et les invitations. Précisez d’abord que vous souhaitez « diffuser sur TestFlight », et indiquez s’il s’agit de membres de l’équipe ou d’amis externes. Connectez ensuite l’équipe de développeurs Apple disposant des droits nécessaires, ou confirmez cette connexion, puis vérifiez les instructions de test, l’adresse e-mail de contact pour les retours, la personne à contacter pour l’examen et l’activation éventuelle d’un lien public.

Le traitement d’Apple, l’examen externe, les limites du nombre de testeurs et les règles de validité continuent de s’appliquer. Lors de la livraison, distinguez bien la version et le numéro de build exacts, le groupe pour lequel il est disponible et l’éventuelle attente de l’examen externe. L’aide d’AirBuild ne permet pas de contourner l’examen d’Apple, et une validation dans le simulateur ne couvre pas nécessairement tous les comportements sur les appareils réels.

Il s’agit ici d’une explication du fonctionnement d’AirBuild, et non d’une obligation imposée par Apple d’utiliser un outil particulier. Ne pas disposer de Xcode localement sur un Mac ne signifie pas non plus qu’il faille maîtriser tous les détails de la préparation des builds pour publier en collaboration avec d’autres personnes.

7. Comment ajouter des testeurs internes ? Attention aux deux invitations

Ce parcours vous concerne, vous et les collaborateurs qui ont réellement besoin d’accéder à l’interface de gestion de l’application.

Première invitation : donner à la personne un accès autorisé à la gestion

Une personne ayant le rôle Titulaire du compte (Account Holder), Administrateur (Admin) ou Gestionnaire d’apps (App Manager) ajoute l’utilisateur :

1. Ouvrez Utilisateurs et accès (Users and Access) → Personnes (People).
2. Cliquez sur « + » et renseignez le nom et l’adresse e-mail.
3. Attribuez un rôle approprié. Si ce rôle permet de limiter l’accès à certaines applications, n’accordez que les accès nécessaires. Ne donnez pas le rôle Administrateur par défaut. L’accès des administrateurs, des utilisateurs Finance et de ceux qui disposent de ressources supplémentaires, comme les rapports ou les certificats, ne peut pas être limité à une seule application : vérifiez la portée des autorisations avant de les attribuer.[9]
4. Envoyez l’invitation et demandez à la personne de l’accepter pour activer son accès à la gestion.

Apple précise actuellement que cette invitation à devenir utilisateur de l’interface de gestion expire après 3 jours. Vous pouvez la renvoyer après expiration. Ce n’est ni l’invitation TestFlight qui vient ensuite, ni la durée de validité de 90 jours du build.[9]

Si la personne possède déjà un rôle admissible et l’accès à cette application, vous pouvez sauter cette étape.

Deuxième invitation : ajouter la personne et le build à un groupe de test interne

1. Ouvrez Apps → votre application → TestFlight.
2. Cliquez sur « + » à côté de Tests internes (Internal Testing) pour créer un groupe, par exemple « Équipe ».
3. Ouvrez le groupe et choisissez Inviter des testeurs (Invite Testers), ou cliquez sur « + » à côté de la liste des testeurs.
4. Sélectionnez les membres admissibles de l’interface de gestion et ajoutez-les au groupe.
5. Cliquez sur Ajouter des builds (Add Builds), puis sélectionnez un build dont le traitement est terminé et qui peut être testé.
6. Renseignez Éléments à tester (What to Test), puis validez l’ajout.
7. Demandez à la personne d’installer TestFlight sur son appareil, d’accepter l’invitation au test, puis d’installer l’application.[5]

Voir un nom dans la liste ne suffit pas à considérer l’opération comme terminée. Il faut aussi un build disponible, et la personne doit effectivement accepter l’invitation et l’installer.

Vous ne trouvez pas la personne à inviter ? Vérifiez d’abord qu’elle a accepté l’invitation à la gestion, que son rôle est admissible et qu’elle a accès à cette application. Ne rechargez pas immédiatement l’application.

Certains groupes internes permettent d’activer la distribution automatique, mais ne supposez pas que les builds de toutes les provenances seront automatiquement ajoutés à tous les groupes. L’aide actuelle d’Apple précise notamment que les builds créés par Xcode Cloud doivent être ajoutés manuellement aux groupes dans App Store Connect.[5]

8. Comment ajouter des testeurs externes ?

Ce parcours convient aux amis, clients, premiers utilisateurs et testeurs de votre communauté. C’est généralement le choix le plus adapté pour partager une application pour la première fois.

Préparer un groupe externe capable de recevoir des builds

Ces opérations nécessitent le rôle Titulaire du compte, Administrateur ou Gestionnaire d’apps :

1. S’il n’existe pas de groupe interne, créez-en un d’abord. Le tutoriel actuel d’Apple pour les tests externes indique la création préalable d’un groupe interne comme prérequis. Cela ne signifie ni que l’application doit déjà être officiellement publiée, ni que les testeurs externes doivent d’abord devenir des membres internes.[6]
2. Ouvrez Apps → votre application → TestFlight.
3. Dans Informations de test (Test Information), renseignez la description de la bêta, l’adresse e-mail de contact pour les retours et toutes les coordonnées nécessaires à l’examen. Si une connexion est requise, fournissez un accès valide et des instructions aux personnes chargées de l’examen, et assurez-vous que les serveurs concernés sont disponibles. N’utilisez pas les données privées d’utilisateurs réels comme données de démonstration.[6][8][14]
4. Cliquez sur « + » à côté de Tests externes (External Testing) et créez un groupe, par exemple « Premiers utilisateurs ».
5. Ouvrez le groupe, cliquez sur Ajouter des builds, puis choisissez la plateforme, la version et le build précis.
6. Renseignez les Éléments à tester. Par exemple : « Créez une entrée, quittez l’application, puis rouvrez-la et vérifiez que l’entrée est toujours là », plutôt que simplement « Essayez ce que vous voulez ».
7. Cochez si nécessaire Notifier automatiquement les testeurs (Automatically notify testers).
8. Selon l’état affiché, choisissez de soumettre le build à l’examen ou de commencer les tests, puis attendez la fin de tout examen nécessaire.
9. Invitez les testeurs par e-mail, par lien public ou avec les deux méthodes.[6]

Après une première approbation, les examens sont-ils définitivement terminés ?

Non.

Le premier build soumis pour un test externe doit passer un examen complet. Les builds suivants de la même version peuvent ne pas nécessiter d’examen complet, mais personne ne peut garantir qu’ils en seront toujours dispensés. Apple exige également que les mises à jour majeures de la bêta soient soumises à un examen pour les tests avant leur distribution.[6][14]

Le délai d’examen n’est pas fixe. Ne promettez pas que l’application sera « forcément installable quelques minutes après le chargement » ou « approuvée sous 24 heures ».

Si vous n’avez pas coché la notification automatique lors de l’ajout du build, vous devez encore utiliser Notifier les testeurs (Notify Testers) après l’approbation. Dans la barre latérale gauche de TestFlight, sous Builds (Builds), sélectionnez la plateforme et la version, puis cliquez sur l’action de notification dans la ligne d’état du build. Approuvé, distribué et installé par le destinataire sont trois états différents.[6]

Méthode 1 : inviter par e-mail

Ouvrez le groupe externe, puis cliquez sur « + » à côté de Testeurs (Testers). Vous pouvez saisir les adresses e-mail de nouveaux testeurs, sélectionner des testeurs existants ou importer une liste.[6]

Les destinataires reçoivent une invitation au test, sans obtenir pour autant des droits de gestion dans App Store Connect.

Méthode 2 : créer et partager un lien public

Ouvrez la page des testeurs du groupe externe et choisissez Créer un lien public (Create Public Link) :

1. Sélectionnez Ouvert à tous (Open to Anyone) ou Filtrer selon des critères (Filter by Criteria).
2. Définissez si nécessaire une limite de recrutement pour ce lien, de 1 à 10 000 personnes. Elle reste soumise à la limite totale de testeurs externes de l’application.
3. Si vous appliquez un filtre, définissez les conditions relatives aux appareils et aux versions du système ciblés.
4. Confirmez, puis copiez le lien réellement généré et envoyez-le à vos amis, à une communauté, par e-mail ou sur un site Web.[6]

Le lien commence généralement par https://testflight.apple.com/join/…. Copiez le véritable lien généré par Apple : n’inventez pas le code qui suit et ne prenez pas l’adresse d’une page de gestion d’App Store Connect pour un lien d’installation.

Un code QR peut contenir ce même lien, mais ce n’est pas un autre mode de distribution, et il ne permet pas de contourner l’examen.

Quatre points à vérifier avant de partager le lien

• Le groupe externe visé contient bien le build que vous voulez partager.
• Les examens nécessaires sont approuvés et la distribution a commencé.
• Le build n’a pas expiré et il est compatible avec les appareils ciblés.
• Le lien est activé, des places restent disponibles et les filtres n’excluent pas les utilisateurs visés.[3][6]

Un lien qui s’ouvre ne garantit pas que la nouvelle version soit installable. De même, la disponibilité d’un ancien build ne signifie pas que le plus récent a déjà été distribué à ce groupe.

Un lien public peut être repartagé : ce n’est pas une liste confidentielle. Si vous ne voulez inviter que quelques personnes précises, privilégiez les invitations par e-mail et mettez en place un contrôle d’accès approprié au niveau des comptes de votre application.

Par défaut, le nom et l’adresse e-mail des personnes qui rejoignent le test par un lien public n’apparaissent pas dans la liste des testeurs TestFlight. En revanche, la date d’installation, les sessions d’utilisation et les plantages, entre autres, restent visibles. Ces personnes peuvent aussi fournir leur adresse e-mail lorsqu’elles envoient volontairement un retour. Cela ne signifie pas qu’elles sont totalement anonymes vis-à-vis d’Apple ou du système de connexion de l’application elle-même.[3][6]

Pour les builds suivants, vous pouvez généralement conserver le lien du même groupe externe, sans recruter à nouveau tout le monde à chaque mise à jour. Dans Gérer (Manage), vous pouvez aussi modifier les critères, la limite de testeurs ou désactiver le lien. Désactiver le lien ferme l’accès aux nouvelles inscriptions : cela ne supprime pas les installations existantes, ne clôture pas les comptes de l’application et n’efface pas les données sur le serveur.[6]

9. Comment les testeurs installent-ils, mettent-ils à jour, envoient-ils leurs retours et quittent-ils le test ?

Après avoir reçu une invitation, procédez sur l’iPhone ou l’iPad destiné au test :

1. Installez l’application officielle TestFlight d’Apple depuis l’App Store.
2. Ouvrez l’e-mail d’invitation ou le lien public.
3. Suivez les indications pour accéder à TestFlight, choisissez Accepter (Accept), puis Installer (Install).
4. Lisez les éléments à tester, puis commencez à utiliser l’application.
5. Lorsqu’un nouveau build est disponible, mettez l’application à jour dans TestFlight ; vous pouvez aussi activer les mises à jour automatiques. Les testeurs déjà inscrits peuvent voir directement Mettre à jour (Update) ou Ouvrir (Open).[3]

Un test externe ordinaire ne nécessite ni le mot de passe du développeur, ni un rôle dans l’interface de gestion, ni la création préalable d’un compte sandbox spécifique.

Si la version publique est déjà sur le téléphone, aura-t-on deux installations ?

En général, non. La version bêta TestFlight d’une même application remplace la version App Store présente sur l’appareil.[3]

Sauvegardez ou exportez donc vos données importantes au préalable. Une bêta peut modifier le format des données, et une ancienne version ne saura pas nécessairement relire ce que la nouvelle a enregistré. Changer de version n’est pas une opération garantie sans perte.

Si le développeur propose encore d’autres builds valides, vous pouvez les choisir dans Builds précédents (Previous Builds). Cette fonction n’est pas un dépôt de téléchargement conservant indéfiniment toutes les anciennes versions.[3]

Comment envoyer un retour facile à comprendre pour le développeur ?

Ouvrez la fiche de l’application dans TestFlight, puis touchez Envoyer un retour sur la bêta (Send Beta Feedback). Sur les systèmes compatibles, vous pouvez aussi faire une capture d’écran dans l’application testée et l’envoyer avec votre retour. Après un plantage, une invitation à partager des informations complémentaires peut apparaître.[3]

Voici un message plus utile que « ça ne marche pas » :

J’utilise [modèle de l’appareil], avec [version du système], et l’application est en [version et numéro de build]. J’ouvre les réglages, je change la langue, puis je reviens à l’accueil. Je m’attendais à ce que tous les textes changent de langue, mais l’accueil reste dans l’ancienne langue. J’ai reproduit le problème lors de 2 essais. Voici une capture d’écran.

N’incluez pas dans vos captures des mots de passe, des informations de paiement ou des données privées d’autres personnes. Les retours envoyés via TestFlight sont également transmis à Apple ; un formulaire de retour propre à l’application constitue un autre canal.[3]

Comment arrêter de participer ?

Dans TestFlight, ouvrez la page d’information de l’application et choisissez Arrêter les tests (Stop Testing). Si une version publique existe, vous pouvez ensuite la télécharger ou l’acheter sur l’App Store. Une application uniquement disponible en bêta, et pas encore publiée officiellement, n’a pas forcément de version publique vers laquelle revenir.[3]

Arrêter les tests ne supprime pas le compte que vous avez créé dans l’application. La gestion du compte et des données dans le cloud dépend des règles de l’application.

10. Les paiements dans TestFlight débitent-ils réellement de l’argent ?

Dans une application installée via TestFlight, les transactions de test effectuées au moyen des achats intégrés Apple passent par le sandbox et ne sont pas réellement facturées. Cela inclut les tests d’abonnements avec StoreKit.[3][10]

Le « sandbox » est un environnement d’essai du parcours d’achat : l’application peut récupérer les informations des produits, lancer un achat de test, restaurer des achats et traiter les notifications de transaction, sans générer pour autant un véritable chiffre d’affaires.[10]

Le point le plus souvent mal compris est le périmètre de ce sandbox.

L’absence de débit ne rend pas la version publique gratuite à vie

Apple précise que les achats intégrés effectués pendant les tests ne sont pas transférés comme achats dans la version publique de l’App Store. Ne promettez pas aux testeurs : « Cliquez une fois maintenant et vous aurez un abonnement à vie après le lancement. »[3]

Si le développeur décide séparément d’offrir des avantages liés au compte de l’application, c’est une décision commerciale de sa part, pas une règle automatiquement fournie par TestFlight.

Le calendrier des abonnements de test n’est pas celui de la facturation réelle

Pour les abonnements à renouvellement automatique, l’aide actuelle de TestFlight destinée aux testeurs indique un renouvellement quotidien pendant les tests, quelle que soit la durée initiale de l’abonnement, avec au maximum 6 renouvellements en une semaine. Les commandes avancées utilisant un compte sandbox permettent aussi d’ajuster la fréquence de renouvellement. N’appliquez pas directement aux tests TestFlight ordinaires les paramètres « 5 minutes » ou « 12 renouvellements » d’autres scénarios sandbox.[3][10]

Ces règles d’accélération servent à tester le renouvellement et l’expiration ; elles ne représentent pas le cycle de facturation des utilisateurs de la version publique.

Seul le canal d’achat Apple passe automatiquement en sandbox, pas toute l’application

Une application TestFlight peut toujours :

• se connecter à un serveur de production et modifier de véritables enregistrements ;
• envoyer de vrais e-mails ou messages ;
• supprimer de vrais comptes ou de vraies données ;
• ouvrir une page Web qui encaisse réellement des paiements ;
• utiliser des moyens de paiement autres que les achats intégrés Apple.

Les paiements sur le Web, Apple Pay et les achats intégrés StoreKit sont des choses différentes. Le fait qu’une application provienne de TestFlight ne garantit pas qu’un paiement sur le Web ou une opération réelle soit sans coût. Les développeurs doivent configurer séparément les données de test, les serveurs et les autres environnements de paiement.[10] ; précision sur le périmètre des systèmes de l’application

Chaque testeur doit-il créer un compte sandbox ?

Non. Pour une installation TestFlight et des tests d’achat ordinaires, vous pouvez utiliser votre compte Apple habituel.[10]

C’est seulement pour des commandes telles que l’effacement de l’historique des achats ou la modification de réglages de test avancés que le développeur doit configurer un Sandbox Apple Account conformément à la documentation Apple. Les étapes avancées peuvent impliquer de se déconnecter de « Contenu multimédia et achats », ce qui peut affecter l’accès aux contenus achetés sur l’appareil. Ce n’est pas une étape obligatoire pour un testeur ordinaire avant l’installation, et il ne faut surtout pas lui demander sans raison de déconnecter tout son appareil d’iCloud. Apple recommande d’envisager un appareil réservé aux tests.[10]

Si l’achat apparaît comme réussi, mais que l’application ne débloque pas la fonction, signalez-le au développeur. La configuration des produits, la validation des transactions, l’attribution des droits, la restauration des achats et la gestion des renouvellements doivent toutes être correctement mises en œuvre. Un achat sandbox réussi ne prouve ni qu’un paiement réel fonctionnerait, ni que les revenus ont été perçus, ni que toute la logique des abonnements est correcte.

11. Quelles sont les limites de TestFlight ?

Si le tableau est trop large, faites-le défiler horizontalement. Au clavier, placez le focus dessus, puis utilisez les touches fléchées.

Après les 90 jours, suffit-il de renvoyer une invitation ?

Non. La durée de validité appartient au build, pas au testeur. Une personne qui rejoint le test plus tard ne bénéficie pas de 90 jours supplémentaires. Après l’expiration, la bêta ne peut plus être ouverte ; le développeur doit fournir un nouveau build valide.[3]

Pour éviter une interruption des tests, chargez et distribuez un nouveau build avant l’expiration de l’ancien, puis rappelez aux testeurs de faire la mise à jour. Le nouveau build a sa propre durée de validité ; il ne prolonge pas celle de l’ancien.

Peut-on utiliser durablement TestFlight pour vendre une application ou des places de test ?

Ne le considérez pas comme un canal de vente permettant de contourner la publication officielle.

La règle 2.2 des consignes d’examen d’Apple exige que les applications de test respectent les règles d’examen et soient destinées à une publication publique. Elle interdit également de proposer une distribution de test via TestFlight en échange d’une contrepartie, quelle qu’elle soit, y compris comme récompense de financement participatif. En clair, « payez pour rejoindre le groupe et obtenir la bêta » n’est pas un mode de distribution TestFlight normal et autorisé.[14]

12. Problèmes fréquents : pourquoi les autres n’arrivent-ils pas à installer l’application ?

Si le tableau est trop large, faites-le défiler horizontalement. Au clavier, placez le focus dessus, puis utilisez les touches fléchées.

Ce sont des pistes de diagnostic, pas des moyens de déterminer la cause exacte à partir d’un seul message d’erreur.[3][5][6][11]

Attention : le statut vert « En cours de test (Testing) » dans l’interface de gestion peut simplement indiquer une utilisation par un groupe interne. Pour savoir si les utilisateurs externes peuvent installer l’application, vérifiez le groupe externe visé, le build exact et son état de disponibilité pour ce groupe.[11]

« Prêt à soumettre (Ready to Submit) », « En attente d’examen (Waiting for Review) », « En cours d’examen bêta (In Beta Review) » et « Prêt pour les tests (Ready to Test) » ne désignent pas non plus le même stade. En particulier, un build prêt pour les tests peut encore nécessiter l’ajout de testeurs ou l’envoi d’une notification manuelle.[11]

13. Où consulter les retours et comment diffuser la version suivante ?

Ouvrez Apps → votre application → TestFlight → Retours (Feedback) pour consulter les Captures d’écran (Screenshots) et les Plantages (Crashes), puis filtrer par version, appareil et autres critères. La possibilité d’envoyer un retour depuis l’application dépend aussi des réglages du groupe.[12]

Traitez d’abord les problèmes reproductibles, puis lancez le cycle suivant :

1. Corrigez les problèmes, compilez avec un nouveau numéro de build et chargez-le.
2. Attendez le traitement et remplissez les obligations de conformité nécessaires.
3. Ajoutez le nouveau build au groupe visé et faites effectuer tout examen externe nécessaire.
4. Actualisez les éléments à tester et notifiez les testeurs selon les réglages.
5. Demandez aux membres du groupe visé de confirmer la version et le build réellement installés, puis de réessayer l’opération qui posait problème.

L’historique des chargements, les listes des groupes et les approbations sont importants, mais la vérification finale reste la suivante : les personnes visées ont-elles bien installé le build prévu ?

Une simple capture d’écran d’un test interne ne prouve pas que tous les utilisateurs externes peuvent installer l’application. De même, un fonctionnement dans le simulateur ne remplace pas le résultat d’une installation sur appareil.

14. Comment terminer les tests ou publier officiellement ?

Commencez par déterminer ce que vous voulez arrêter :

• Ne plus recruter de nouveaux utilisateurs : désactivez le lien d’invitation public du groupe externe.
• Modifier qui peut recevoir quels builds : gérez les testeurs, les groupes et l’attribution des builds.
• Empêcher les nouvelles installations d’un build : ouvrez ses détails et choisissez Faire expirer le build (Expire Build). N’y voyez pas une suppression à distance de l’application sur tous les téléphones, ni un effacement des comptes dans le cloud.[6][13]
• Publier officiellement : préparez les informations nécessaires à la version publique sur l’App Store, sélectionnez un build admissible et soumettez-le séparément à l’examen officiel.[1][2]

Un build admissible déjà chargé par la procédure TestFlight ordinaire peut être sélectionné pour une soumission officielle. Il n’est pas forcément nécessaire de le recompiler simplement parce que vous souhaitez le publier. En revanche, toute modification réelle du code nécessite un nouveau build, et les chargements « réservés aux tests internes » ne peuvent pas servir à la publication officielle.[2][5]

L’approbation de l’examen TestFlight ne publie pas automatiquement l’application sur l’App Store. Inversement, la publication de la version officielle ne met pas automatiquement fin aux bêtas encore valides : organisez séparément la fin des tests et la transition des utilisateurs.[1]

15. Un modèle de message pour vos premiers testeurs

J’aimerais te proposer d’essayer une première version de [nom de l’application].

Installe d’abord l’application officielle TestFlight d’Apple depuis l’App Store, puis ouvre [véritable lien d’invitation] sur ton iPhone, accepte l’invitation et installe l’application.

Pour cette phase, j’aimerais surtout que tu testes : [1 ou 2 tâches précises]. Appareils et systèmes compatibles : [exigences réelles].

C’est une version bêta, qui peut présenter des problèmes : pense à sauvegarder tes données importantes. En cas d’anomalie, utilise « Envoyer un retour sur la bêta » dans TestFlight pour m’indiquer ce que tu as fait, le résultat attendu et ce qui s’est réellement passé, idéalement avec une capture d’écran et le numéro de version.

Remplacez les éléments entre crochets par les informations réelles. Avant d’envoyer le message, assurez-vous que le build du groupe externe visé est effectivement installable. N’envoyez pas à tout le monde un lien encore en attente d’examen en le présentant comme déjà disponible.

Avant la diffusion, vérifiez ces 10 points

• □ J’ai choisi le test interne ou externe en fonction des autorisations du compte, sans accorder de droits excessifs par facilité.
• □ Le traitement du build visé est terminé et aucun obstacle à sa distribution ne reste non résolu.
• □ Le groupe visé contient effectivement ce build.
• □ Les examens externes nécessaires sont approuvés et les notifications requises ont été envoyées.
• □ J’ai vérifié le mode d’invitation utilisé : les e-mails ont été envoyés aux bonnes personnes ; si j’utilise un lien public, il est activé et des places sont disponibles. Les appareils et les systèmes ciblés respectent les exigences.
• □ La description du test, l’adresse e-mail de contact pour les retours et les éléments à tester sont exacts et utiles.
• □ Les testeurs savent qu’il s’agit d’une bêta et qu’elle peut remplacer la version publique.
• □ Je distingue bien les achats sandbox des serveurs réels, des paiements Web et des opérations réelles.
• □ J’ai vérifié la date d’expiration du build et prévu les mises à jour suivantes.
• □ Une personne du public visé a confirmé avoir effectivement installé le build prévu, et pas seulement ouvert la page d’invitation.

Lors d’une première diffusion, le véritable point d’arrivée n’est pas « chargement terminé ». C’est le moment où les bonnes personnes ont installé la bonne version, savent quoi tester et comment vous signaler les problèmes.

Sources et lectures complémentaires

Les ressources suivantes ont été vérifiées le 17 septembre 2026. Les jalons historiques s’appuient sur des articles de l’époque ou sur les annonces publiées par Apple cette année-là ; les règles actuelles reposent principalement sur l’aide officielle d’Apple. L’interface peut varier selon la langue et la version.