TestFlight : tester son app iPhone avant l'envoi à Apple
23 septembre 2026, 7 min
Testeurs internes ou externes, revue bêta, lien public, builds valables 90 jours : TestFlight expliqué simplement, avec la liste à vérifier avant Apple.
TestFlight, c'est quoi et à quoi ça sert ?
TestFlight est le service d'Apple qui te permet d'installer ton app 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'app 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.
Pour utiliser TestFlight, il te faut un compte Apple Developer payant : le service n'est pas accessible avec un compte gratuit. Tout le reste de ce guide suppose que tu en as un.
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. 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. D'après la documentation d'Expo, 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 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 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.
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, et chacun peut installer l'app sur plusieurs appareils, jusqu'à 30.
Leur gros avantage : pas de revue bêta. Dès que la build a fini son traitement, 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, 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, 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.
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, avec les libellés de l'interface en anglais :
- Dans App Store Connect, ouvre ton app puis l'onglet TestFlight.
- Sous External Testing, sélectionne ton groupe externe.
- Clique sur Create Public Link.
- Choisis Open to Anyone pour ouvrir le lien à tous, ou Filter by Criteria pour le limiter à certains appareils et versions d'iOS.
- 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. 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. 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 : 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 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.
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, 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 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. 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 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.
Passer de TestFlight à l'App Store, accompagné
TestFlight est l'étape où ton app devient réelle : elle tourne sur un vrai iPhone, entre les mains de vrais gens. Dans L'Accélérateur iOS, c'est la deuxième semaine du programme : 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.
Le format : 4 semaines, 3 lives par semaine en groupe de 10 places au plus, avec les replays. Tu gardes un accès à vie au groupe privé Discord, aux replays et aux modèles, et ton dossier App Store est relu avant l'envoi. Le prix est de 489 €, ou 3 × 163 € sans frais avec Klarna. La prochaine session commence le lundi 12 octobre 2026.
Personne ne peut te garantir qu'Apple acceptera ton app : c'est Apple qui décide. Je peux en revanche t'aider à envoyer un dossier propre et à corriger vite si un refus tombe. Si ça te correspond, le détail de l'offre est ici.