TestFlight : tester ton application iPhone avant l’App Store

1. TestFlight, c’est quoi et à quoi ça sert ?

TestFlight est le service d’Apple qui permet d’installer une version de test de ton application iPhone avant sa publication sur l’App Store. Tu peux inviter jusqu’à 100 testeurs internes et jusqu’à 10 000 testeurs externes, par e-mail ou par lien public, et chaque version reste testable 90 jours. Pour que ce test serve, donne à chaque testeur une tâche précise et note où il bloque.

On parle de « build » : c’est une version de l’app prête à installer, envoyée à Apple par le développeur. Le testeur, lui, installe l’app gratuite TestFlight sur son iPhone, accepte l’invitation et reçoit ton app comme n’importe quelle autre. Côté projet, il faut être membre de l’Apple Developer Program, qui donne accès à App Store Connect, la console où se gèrent les bêta-tests et la publication.

TestFlight est le dernier filet avant l’examen d’Apple. Les règles sont claires : les démos et versions bêta n’ont pas leur place sur l’App Store, elles passent par TestFlight, et une app testée ainsi doit être destinée à une publication publique (règle 2.2 des App Review Guidelines, version du 16 octobre 2026). Si tu démarres à peine, commence par notre guide pour créer une application mobile.

2. Prototype Figma ou build TestFlight : deux tests différents

Avant TestFlight, tu as peut-être déjà fait essayer un prototype. Un prototype Figma enchaîne des écrans dessinés ; il s’ouvre sur un téléphone avec l’application mobile Figma. Il répond à une question de compréhension : la personne trouve-t-elle son chemin ? Notre guide maquette, prototype ou MVP détaille cette étape.

Un build TestFlight, c’est la vraie app. Elle enregistre des données, demande l’accès au micro ou aux notifications, dépend du réseau et peut planter. Elle répond à une autre question : est-ce que ça marche, sur de vrais iPhone, chez de vraies personnes ? Les deux tests se complètent. Le second ne remplace pas le premier : corriger un parcours mal compris coûte plus cher une fois l’app construite.

Entre les deux, le développeur peut aussi installer l’app directement depuis Xcode sur ses propres appareils. C’est pratique pour vérifier vite, pas pour faire tester d’autres personnes : avec un compte gratuit, l’autorisation d’installation expire sept jours après son émission, selon le comparatif des comptes développeur d’Apple.

3. Testeurs internes et externes : les règles de TestFlight

Ces règles ont été vérifiées en octobre 2026 sur la page TestFlight d’Apple et dans l’aide App Store Connect. Elles évoluent de temps en temps : jette un œil à ces pages avant de lancer ton test.

Les testeurs externes sont rangés dans des groupes, chacun avec ses builds : par exemple un groupe de proches et un groupe de futurs utilisateurs. Le premier build ajouté à un groupe externe part à l’examen TestFlight d’Apple, souvent appelé « Beta App Review » ; les builds suivants n’ont pas toujours besoin d’un examen complet. Apple ne publie pas de délai propre à cet examen. Pour les soumissions en général, sa page App Review indique en octobre 2026 qu’au moins 50 % sont examinées en moins de 24 heures et 90 % en moins de 48 heures : c’est un repère, pas une promesse, alors garde de la marge.

Le lien public peut être ouvert à tous ou filtré par appareil et par version du système, avec une limite que tu fixes entre 1 et 10 000 personnes. Attention, Apple le rappelle : n’importe qui peut faire circuler ce lien. Pour un test confidentiel, préfère l’invitation par e-mail.

Pour ouvrir le test aux externes, il faut remplir les informations de test : une description de la bêta (obligatoire), une adresse e-mail pour les retours et, pour chaque build, ce que tu veux faire tester. Côté appareil, l’iPhone du testeur doit tourner sous iOS 16 ou plus récent, et chaque testeur peut installer la bêta sur 30 appareils au maximum.

4. Comment publier un build sur TestFlight

Si un studio construit ton app, c’est en général lui qui fait ces manipulations. Les connaître t’aide quand même à suivre l’avancement et à poser les bonnes questions.

1. Adhérer à l’Apple Developer Program. Apple annonce 99 USD par an, convertis dans la devise locale (page d’inscription d’Apple, consultée en octobre 2026).
2. Ajouter l’app au compte App Store Connect, avec son nom et son identifiant.
3. Envoyer un build depuis Xcode, ou avec des outils comme Transporter ou Xcode Cloud. Apple le traite, puis envoie un e-mail quand il apparaît dans App Store Connect (aide d’Apple sur l’envoi des builds).
4. Répondre aux questions sur le chiffrement. Sans réponse, Apple marque le build « Missing Compliance » : règle ce point avant d’inviter qui que ce soit.
5. Créer un groupe interne et y ajouter le build : ton équipe peut l’installer dès qu’il est traité.
6. Créer un groupe externe, remplir les informations de test, ajouter le build, puis inviter par e-mail ou lien public une fois l’examen passé.

Vérifie aussi sous quel compte développeur l’app sera publiée : les testeurs, les retours puis la fiche App Store vivent dans ce compte. Chez Yodavio, TestFlight fait partie de la publication, dernière étape de notre méthode de développement en 4 étapes : on prépare la fiche App Store, on teste sur TestFlight, puis on soumet à Apple. Notre guide pour publier une application sur l’App Store détaille la suite.

5. Côté testeur : installer TestFlight et envoyer un retour

Envoie ces consignes à tes testeurs. Elles suivent la page d’aide TestFlight d’Apple.

1. Installer l’app TestFlight, gratuite sur l’App Store, sur l’iPhone qui servira au test.
2. Ouvrir l’e-mail d’invitation sur cet iPhone et suivre le bouton qui ouvre TestFlight, ou toucher le lien public.
3. Accepter l’invitation, puis installer l’app. Elle arrive sur l’écran d’accueil avec un point orange à côté de son nom : c’est la version bêta.
4. Pour signaler un problème, faire une capture d’écran dans l’app et la partager comme commentaire bêta, ou ouvrir TestFlight, choisir l’app et envoyer un commentaire, avec ou sans capture. Le texte peut aller jusqu’à 4 000 caractères.

Si l’app plante, TestFlight propose d’envoyer les détails du plantage, à condition que le développeur ait laissé cette option active. Trois points à annoncer avant le test : la bêta remplace la version App Store si elle est déjà installée ; les achats intégrés sont gratuits pendant le test et ne sont pas conservés ensuite ; un abonnement testé se renouvelle chaque jour, jusqu’à six fois en une semaine.

Côté confidentialité, Apple transmet au développeur les rapports de plantage, le nom et l’adresse e-mail du testeur, des données d’usage et ses commentaires. Avec un lien public, le nom et l’e-mail restent masqués, mais le développeur voit le nombre de sessions et de plantages. Dis-le à tes testeurs avant qu’ils acceptent : c’est plus honnête et ça évite les surprises.

6. Que faire tester, et comment s’y prendre

Le champ « ce qu’il faut tester » s’affiche chez tes testeurs à chaque nouveau build. Ne l’utilise pas pour écrire « dis-moi ce que tu en penses ». Donne une à trois tâches précises, décrites comme une situation réelle, sans dire où appuyer.

Quand c’est possible, regarde quelqu’un faire la tâche, en vrai ou en visio. Ne l’aide pas, même s’il hésite. Note où il s’arrête, ce qu’il dit à voix haute et ce qu’il pense avoir obtenu à la fin. C’est la même méthode que pour un prototype ; la différence, c’est que l’app réagit vraiment. Profite donc de ce que seul un vrai build permet de vérifier :

• le premier lancement, l’inscription et les demandes d’autorisation (micro, caméra, notifications), acceptées puis refusées ;
• un réseau faible ou coupé, un appel qui interrompt l’app, un retour dans l’app après plusieurs heures ;
• plusieurs tailles d’iPhone et plusieurs versions d’iOS ;
• les achats et abonnements, gratuits pendant la bêta ;
• les écrans d’erreur : ce qui s’affiche quand quelque chose rate.

On l’a fait pour nos propres apps, comme Talkana, l’app pour parler japonais à voix haute, testée sur TestFlight avant son arrivée sur l’App Store le 5 novembre 2026. Après chaque tâche, pose trois questions courtes : qu’est-ce qui t’a semblé compliqué ? Qu’est-ce que tu t’attendais à trouver et qui n’y était pas ? L’utiliserais-tu encore la semaine prochaine, et pourquoi ? Ce que la personne fait pèse plus lourd que ce qu’elle promet.

7. Qui recruter comme testeurs, et combien

Ton entourage est utile pour un premier tour : il repère les plantages, les fautes et les boutons qui ne répondent pas. Mais il te connaît, il veut t’encourager et il ne ressemble pas toujours à ton public. Pour savoir si l’app répond au besoin, il faut des personnes qui ont vraiment le problème que tu résous.

Pour un test de parcours, pas besoin de centaines de testeurs. Dans un article de 2000 toujours en ligne, Jakob Nielsen recommande de tester avec environ cinq personnes, de corriger, puis de refaire un tour, plutôt que de tout miser sur un seul grand test (Nielsen Norman Group). Si ton app vise des publics très différents, prévois quelques personnes par public. Les gros volumes servent à autre chose : faire apparaître des plantages rares, sur des appareils variés.

Pour aller au-delà de tes proches :

• les communautés liées au sujet de ton app (club, forum, groupe en ligne), en respectant leurs règles sur l’autopromotion ;
• ta liste d’attente ou tes abonnés, si tu en as ;
• un lien public filtré par appareil et version d’iOS, pour toucher les bons profils ;
• des personnes qui utilisent aujourd’hui une solution concurrente, ou un carnet et un tableur, pour le même besoin.

Explique en deux lignes ce que tu attends, combien de temps ça prend et jusqu’à quand. Une demande claire, avec une durée, est plus facile à accepter qu’une invitation vague. Pense aussi à remercier et à dire ce qui a changé grâce aux retours : tu auras besoin de ces personnes au tour suivant.

8. Trier les retours avant la soumission à Apple

Les retours arrivent dans App Store Connect, onglet TestFlight, rubrique Feedback : les captures commentées d’un côté, les plantages de l’autre. Les rapports de plantage se téléchargent pendant 120 jours, d’après l’aide d’Apple sur les retours des testeurs. Ajoute tes notes d’observation et les messages reçus ailleurs, puis classe tout dans trois catégories.

Un avis isolé n’est pas une règle ; une même difficulté vue chez plusieurs personnes en est presque une. Méfie-toi aussi des demandes de nouvelles fonctions : elles allongent le projet sans dire si la première version marche. Reviens toujours à la question de départ : la tâche principale est-elle réussie sans aide ?

Quand les bloquants sont corrigés, envoie un nouveau build et fais refaire la tâche à quelques testeurs. N’oublie pas qu’un build expire 90 jours après son envoi. Ensuite seulement, prépare l’envoi à Apple : notre guide sur la validation App Store prend le relais.

9. Questions fréquentes

Comment trouver des testeurs au-delà de son entourage ?

La question a été posée sur un forum de développeurs francophones. Cherche là où ton public se trouve déjà, explique la tâche et sa durée, et utilise un lien public filtré par appareil. Quelques personnes qui ont vraiment le besoin t’apprendront souvent plus qu’un grand cercle d’amis bienveillants.

Peut-on payer des testeurs, ou faire payer l’accès à la bêta ?

Un développeur a posé la question sur les forums d’Apple, sans obtenir de réponse sur le fond. La règle 2.2 précise qu’une app TestFlight ne peut pas être distribuée aux testeurs en échange d’une compensation, quelle qu’elle soit, y compris en récompense d’un financement participatif. L’accès à ta bêta ne se vend donc pas. Le texte ne parle pas explicitement de rémunérer des testeurs ; avant d’acheter un « lot » de testeurs, demande-toi surtout s’ils ressemblent à ton public.

Les testeurs voient-ils mes consignes de test ?

Oui. Selon Apple, TestFlight prévient le testeur à chaque nouveau build et lui affiche les instructions de ce qu’il faut tester. L’invitation par lien public montre aussi la description de la bêta.

TestFlight me demande un code d’invitation : que faire ?

Sur iPhone, l’invitation passe normalement par le bouton de l’e-mail ou par le lien public, sans code à saisir : l’aide TestFlight d’Apple ne décrit la saisie d’un code que pour l’Apple TV. Des développeurs signalent pourtant cette demande sur les forums d’Apple, sans réponse officielle. Commence par mettre TestFlight à jour : ses notes de version sur l’App Store indiquent qu’une version récente est nécessaire pour accepter une invitation par code. Ouvre ensuite le lien sur l’iPhone où TestFlight est installé, ou demande une nouvelle invitation.

TestFlight existe-t-il sur Android ?

Non, TestFlight est réservé aux appareils Apple. Sur Android, la Play Console propose des tests internes (jusqu’à 100 testeurs), fermés et ouverts. Les comptes personnels créés après le 13 novembre 2023 doivent faire passer un test fermé à au moins 12 testeurs pendant 14 jours d’affilée avant de pouvoir demander l’accès à la production, selon Google en octobre 2026.

Que se passe-t-il au bout de 90 jours ?

Le build ne s’ouvre plus chez les testeurs. Pour continuer, il faut en envoyer un nouveau. Une fois l’app publiée, ils la téléchargent depuis l’App Store comme tout le monde.