TestFlight affiche « Not Available for Testing » : que faire ? Guide de dépannage 2026

Dans App Store Connect, votre build TestFlight affiche « Not Available for Testing » et vos testeurs ne peuvent pas le lancer.

Consultez d’abord le détail de ce build : Apple associe ce statut à un profil de provisionnement dépourvu de l’identifiant d’application ; corrigez le profil réellement utilisé, recréez l’archive et envoyez un nouveau build.

Ce guide s’adresse aux développeurs indépendants qui viennent d’envoyer leur premier build, aux petites équipes responsables de la signature et aux personnes qui préparent des tests internes ou externes. Il vous aide à séparer le problème de profil des autres états App Store Connect, puis à vérifier que le nouveau build est réellement accessible aux testeurs.

Quand le statut apparaît, distinguez le problème de signature des autres blocages

« Not Available for Testing » est un statut précis, pas un diagnostic générique signifiant que TestFlight est en panne ou que l’invitation a échoué. Dans sa documentation sur les états de build App Store Connect, Apple associe cet état à un profil de provisionnement qui ne contient pas l’identifiant d’application. La correction indiquée consiste à envoyer un nouveau build comprenant cet identifiant.

La distinction compte, car renvoyer une invitation ne modifie ni l’archive ni sa signature. Si la cause se trouve dans le profil, les testeurs resteront bloqués tant que le problème n’aura pas été corrigé dans le processus de construction. À l’inverse, modifier immédiatement les réglages de signature sans vérifier le statut détaillé peut vous faire changer une configuration qui n’est pas en cause.

Les autres états ne doivent pas être rabattus sur cette explication. Un build encore en traitement n’a pas nécessairement fini son parcours d’analyse ; un build qui attend des informations de conformité à l’exportation demande de répondre à la demande correspondante ; un build expiré n’est plus utilisable pour les tests. Apple décrit séparément les informations de conformité à fournir pour les builds bêta. Consultez donc le statut et les détails du build concerné, plutôt que de déduire la cause à partir d’un message de téléversement réussi.

Pour un cas concret, imaginez que votre archive a été générée sur un Mac différent de celui utilisé habituellement, ou par un flux automatisé dont les réglages ont changé. Le projet peut afficher le bon identifiant, tandis que l’archive a été signée avec un autre profil. Cette divergence entre configuration déclarée et artefact livré explique pourquoi relire uniquement l’écran du projet ne suffit pas.

Lorsque le détail mentionne l’identifiant, remontez jusqu’au profil réellement utilisé

L’identifiant d’application est lié à l’identité de la cible que vous distribuez. Le Bundle Identifier visible dans les réglages de votre cible doit correspondre à l’application et au profil concernés. Le nom d’un profil, même s’il paraît cohérent, n’est pas une preuve qu’il contient le bon identifiant : comparez les informations du profil avec celles de la cible et de l’archive.

La documentation Apple explique comment créer un profil de provisionnement App Store, ainsi que comment modifier, télécharger ou supprimer des profils. Servez-vous de ces pages pour vérifier le profil de distribution associé à la bonne application. Les écrans et options disponibles peuvent dépendre de votre configuration de compte et de votre version des outils ; suivez les consignes applicables à votre projet plutôt que de copier des étapes d’une interface ancienne.

Voici les éléments à rapprocher avant de reconstruire :

• La cible distribuée : vérifiez que vous examinez la bonne application et la bonne cible, notamment si votre projet contient plusieurs extensions ou variantes.
• Le Bundle Identifier : relevez sa valeur dans les réglages de la cible qui produit l’application envoyée à TestFlight.
• Le profil de provisionnement : confirmez qu’il concerne cette application et qu’il contient l’identifiant attendu.
• Le mode de signature effectif : déterminez si la signature est gérée automatiquement par Xcode ou définie manuellement pour votre flux de distribution.
• L’archive envoyée : vérifiez que ses informations correspondent aux réglages que vous venez d’examiner. Le changement d’une option après création de l’archive ne corrige pas rétroactivement cette archive.

Attention : un profil disponible dans le compte développeur ou sélectionné dans un réglage ne prouve pas à lui seul qu’il a servi à signer le build envoyé. Cherchez la correspondance dans les réglages de construction, les journaux du processus et les informations de l’archive.

Cette vérification évite une erreur fréquente : régénérer un profil correct, puis relancer un flux qui continue d’utiliser l’ancien. Elle permet aussi de circonscrire la réparation à la cible concernée, au lieu de modifier des certificats ou des profils sans lien établi avec le statut.

Avec Xcode ou une automatisation, établissez une chaîne de preuve

Avec une archive créée manuellement dans Xcode, partez de la cible qui a produit l’application. Relisez ses réglages de signature et de provisionnement, puis vérifiez les informations associées à l’archive qui a été envoyée. Si vous modifiez le profil après coup, créez une nouvelle archive : l’ancien artefact conserve les éléments avec lesquels il a été construit.

Apple décrit le parcours de distribution dans son guide sur la distribution d’une application avec Xcode. Utilisez la documentation correspondant à la version de Xcode et au type de distribution de votre projet. Si vous ne pouvez pas déterminer à partir des écrans quel profil a été appliqué, faites une nouvelle construction contrôlée après avoir consigné les réglages pertinents, puis comparez les informations de l’archive au résultat attendu.

Dans un flux automatisé, vérifiez la configuration de la tâche qui crée et signe l’archive, pas seulement les réglages visibles sur votre poste de développement. Les variables d’environnement, les fichiers de configuration et les identifiants installés sur la machine d’intégration peuvent sélectionner un profil différent de celui que vous pensiez utiliser. Conservez les journaux de compilation pertinents et identifiez clairement l’artefact envoyé : sans cette correspondance, un succès de compilation ne démontre pas que la bonne signature a été appliquée.

L’ordre de vérification le plus fiable est le suivant :

1. Identifier l’artefact : retrouvez l’archive et le build correspondant au statut affiché dans App Store Connect.
2. Confirmer la cible : relevez la cible et son Bundle Identifier, sans vous fier au nom général du projet.
3. Établir la méthode de signature : notez si elle est gérée par Xcode ou imposée par une configuration manuelle ou automatisée.
4. Vérifier le profil de l’archive : comparez son identité et son contenu avec l’application attendue.
5. Corriger la source de configuration : actualisez le profil et le réglage qui sont réellement utilisés pour la distribution.
6. Créer un nouvel artefact : réarchivez et téléversez le build corrigé conformément au guide Apple de téléversement des builds.
7. Contrôler le résultat dans App Store Connect : revenez au build nouvellement envoyé et vérifiez son état avant de prévenir les testeurs.

Ces étapes produisent une trace exploitable : cible, identifiant, provenance du profil, méthode de signature, archive et état après envoi. Si le statut reste inchangé, cette trace vous aide à trouver l’endroit où la correction n’a pas été prise en compte, sans refaire au hasard la configuration du compte.

Questions fréquentes sur les builds TestFlight indisponibles

Que signifie « Not Available for Testing » ?

Dans la documentation Apple, ce statut indique que le profil de provisionnement ne contient pas l’identifiant d’application requis. Cela ne signifie pas que toute indisponibilité TestFlight a la même cause. Ouvrez le détail du build concerné, confirmez le statut exact et corrigez la signature avant de renvoyer l’archive. Un build encore en traitement, expiré ou en attente d’informations d’exportation nécessite une démarche différente.

Quel profil faut-il examiner ?

Examinez le profil réellement utilisé pour signer l’archive envoyée, et non un profil choisi uniquement parce que son nom semble correspondre. Comparez son application avec le Bundle Identifier de la cible, puis confrontez ce résultat aux réglages de signature et aux informations de l’archive. Cette méthode s’applique aussi lorsque plusieurs cibles ou variantes de l’application partagent le même projet.

Comment réparer un profil sans identifiant d’application ?

Confirmez d’abord la cible et son identifiant, puis créez ou modifiez le profil App Store correspondant selon les indications Apple. Faites ensuite appliquer ce profil par le processus qui signe effectivement votre application : réglages Xcode pour une archive manuelle, ou configuration de la tâche concernée pour une construction automatisée. Réarchivez et envoyez un nouveau build ; modifier un profil après l’archivage ne répare pas l’artefact déjà produit.

Comment confirmer que les testeurs ont accès au nouveau build ?

Vérifiez le statut du nouveau build dans App Store Connect, puis son association au groupe de test visé et l’accès accordé aux personnes concernées. Apple distingue les étapes de test et les exigences applicables aux groupes dans son aperçu de TestFlight et son guide pour ajouter des testeurs aux builds. Pour les tests externes, vérifiez aussi séparément l’étape de revue bêta applicable.

Après le renvoi, séparez l’état du build de l’accès au groupe

Un téléversement confirmé ne garantit pas que le build est déjà prêt à être testé. Revenez dans App Store Connect et examinez l’état du nouvel artefact : il peut encore être en traitement, demander une information de conformité ou signaler un autre problème. N’attribuez pas ces situations au profil sans indication correspondante dans l’état du build.

Quand l’état permet les tests, vérifiez ensuite l’affectation du build au groupe adéquat. Les tests internes et externes n’ont pas exactement les mêmes conditions d’accès. Pour les tests externes, l’examen bêta éventuel constitue une étape distincte de la correction du profil et de la disponibilité technique du build. Les règles applicables aux testeurs et à leur ajout sont détaillées dans le guide Apple sur les testeurs et les builds TestFlight.

Votre compte rendu de réparation doit permettre de répondre à trois questions : quel artefact a été envoyé, avec quelle configuration de signature, et quel état App Store Connect affiche désormais ? Notez le commit ou la version du projet, l’identifiant du build, la provenance du profil et le résultat final. Si vous ne pouvez pas relier ces éléments, vous ne savez pas encore si la correction a résolu le problème ou si un nouvel artefact a simplement été téléversé.

Choisissez la prochaine action selon le statut observé

• Si le statut exact est « Not Available for Testing » et que son détail signale l’identifiant d’application manquant, vérifiez le profil de l’archive, corrigez la signature et envoyez un nouveau build.
• Si le build est encore en traitement, attendez son résultat dans App Store Connect avant de modifier les profils ; si un autre statut apparaît ensuite, suivez sa propre définition officielle.
• Si des informations de conformité à l’exportation sont demandées, fournissez-les selon la procédure Apple prévue pour les builds bêta au lieu de reconstruire uniquement pour corriger la signature.
• Si le build est expiré, sélectionnez un artefact encore utilisable ou envoyez une nouvelle version appropriée ; ne traitez pas l’expiration comme la preuve d’un profil incomplet.
• Si le build est disponible mais que les testeurs ne le voient pas, vérifiez son association au groupe et les droits d’accès avant de refaire l’archive.
• Si vous ne pouvez pas identifier le profil de l’archive, reproduisez la construction avec une configuration explicitement contrôlée, puis confrontez les journaux, les réglages du projet et les informations de l’artefact.

Si la signature doit être fiabilisée, examinez aussi votre environnement Mac

Si vous construisez et archivez sur votre Mac habituel, que les profils utilisés sont identifiables et que les incidents restent ponctuels, conserver ce flux local est généralement le choix le plus simple. En revanche, une machine dédiée peut être pertinente si les archives dépendent d’un environnement toujours disponible, si votre équipe doit reproduire une signature à distance ou si votre Mac local manque d’espace pour les outils et les archives. Pour comparer ces modes d’accès sans confondre coût matériel et besoin réel, consultez notre comparatif des solutions Mac.

Un environnement distant ne corrige pas automatiquement une mauvaise configuration : il faut toujours vérifier le profil, l’archive et le résultat dans App Store Connect. Il peut toutefois fournir une machine Mac accessible pour reconstruire et contrôler un artefact lorsque vous ne souhaitez pas acheter un Mac uniquement pour les tâches de publication. Si cette option correspond à votre fréquence de builds et à votre organisation, découvrez les possibilités de Mac à distance avec VpsHold. Si vous avez besoin d’un matériel local permanent ou d’interfaces physiques propres à votre poste, l’achat d’un Mac reste plus adapté ; pour un dépannage ponctuel, votre environnement actuel peut suffire.

Questions fréquentes