La décision ne se prend pas après l’arrivée du fichier dans App Store Connect. Elle commence au moment où vous définissez l’objectif de l’archive, puis se traduit par le mode de distribution sélectionné dans Xcode ou dans votre chaîne d’intégration continue.

Apple indique dans sa documentation officielle sur la distribution des apps pour les tests bêta et les versions que le choix du mode de distribution définit la trajectoire du build. La documentation de téléversement précise également le rôle du flux de distribution lors de l’envoi de l’archive dans App Store Connect : instructions officielles pour téléverser un build.

Pour Xcode 27, Apple a confirmé la prise en charge du téléversement de builds créés avec Xcode 27 RC dans son communiqué officiel du 9 septembre 2026. Cela confirme la compatibilité de l’environnement de téléversement, mais ne change pas la frontière entre build interne, bêta externe et publication.

Un membre de votre équipe App Store Connect n’a pas le même statut qu’un client, qu’un partenaire audio ou qu’un graphiste chargé de valider une interface. Cette distinction est plus importante que le simple fait de vouloir « tester rapidement ».

Les testeurs internes sont associés à l’équipe App Store Connect et doivent disposer du compte et du rôle appropriés. Apple décrit les conditions d’ajout et la portée des builds dans sa page consacrée aux testeurs internes et aux builds disponibles. Le nombre exact de personnes autorisées dépend des règles du compte et de la configuration de l’équipe ; il ne faut donc pas l’utiliser comme critère unique de choix.

Les testeurs externes sont, eux, invités dans un groupe externe. Ils peuvent recevoir une invitation ou rejoindre une bêta au moyen d’un lien public lorsque cette méthode est disponible pour votre configuration. La procédure d’invitation est détaillée dans l’aide officielle consacrée aux invitations de testeurs externes.

Voici la règle de décision :

• Si chaque personne possède un compte membre de l’équipe et que le build ne sortira jamais de ce périmètre, Internal Only est cohérent.
• Si vous devez faire tester l’application à un client, à une agence, à un groupe d’utilisateurs ou à un partenaire créatif, le build doit suivre le canal normal.
• Si le même commit peut devenir une version candidate, ne l’envoyez pas comme Internal Only.
• Si vous développez une fonction de montage vidéo, de traitement audio ou de design d’interface et que les retours viennent de collaborateurs extérieurs, considérez-les comme des testeurs externes, même si le test reste informel.

Un build visible dans TestFlight n’est donc pas automatiquement utilisable par tous les groupes. Apple explique la relation entre testeurs et builds dans la page d’association des testeurs aux builds. Si votre build n’apparaît pas dans un groupe externe, contrôlez d’abord sa classification et son association, avant de toucher aux certificats.

Internal Only est utile lorsque vous voulez empêcher qu’un build de développement soit considéré comme une version publiable. C’est un garde-fou de gouvernance. Ce n’est pas une zone de stockage temporaire dont le statut pourrait être transformé sans conséquence.

Prenons le cas d’un développeur indépendant qui travaille sur une nouvelle fonction d’export vidéo. La branche de développement contient un commutateur de débogage, des journaux détaillés et une interface encore instable. Le build doit être vérifié par le développeur et un designer membre de l’équipe, mais il ne doit pas être envoyé à des clients. Internal Only convient.

Le cas change si le même développeur veut inviter dix utilisateurs extérieurs pour évaluer la qualité de l’export. Il doit préparer un build compatible avec le groupe externe. S’il prévoit déjà de soumettre cette version après les derniers retours, il doit conserver une archive distribuée par le flux normal, avec une numérotation et une signature gérées comme celles d’une candidate.

Les coûts cachés d’une mauvaise décision

Une sélection incorrecte ne se résume pas à un clic à refaire.

• Reconstruction : il peut être nécessaire de recréer l’archive avec le bon mode d’exportation.
• Signature : les certificats, profils et autorisations associés au pipeline peuvent différer.
• Numérotation : un nouvel envoi doit respecter la progression du numéro de build.
• Validation : les groupes internes, externes et les règles de revue doivent être revérifiés.
• Coordination : des testeurs peuvent attendre un build qui n’est finalement pas accessible à leur groupe.
• Traçabilité : une équipe peut perdre la correspondance entre commit, archive, build et candidate.

Apple décrit TestFlight comme un environnement de distribution bêta, avec des parcours distincts pour les testeurs internes et externes dans sa présentation officielle de TestFlight. La documentation ne promet pas qu’un build Internal Only deviendra publiable après une modification de configuration. Votre processus doit donc traiter la destination comme une propriété de l’archive.

Le canal normal offre davantage de réutilisation lorsque le build doit passer de l’équipe à une bêta externe, puis éventuellement à la soumission. Internal Only offre davantage de protection contre une réutilisation accidentelle d’un développement qui ne devrait jamais parvenir à un client.

Ne choisissez donc pas Internal Only parce que l’envoi semble plus pratique. Choisissez-le parce que vous acceptez explicitement de renoncer à la bêta externe et à la soumission de ce build. À l’inverse, ne donnez pas à chaque tâche automatisée les droits de publication sous prétexte que le pipeline doit être flexible.

Un Mac distant peut exécuter deux familles de travaux : la validation interne et la préparation candidate. La séparation doit être visible dans le dépôt, dans les schémas Xcode, dans les profils d’exportation et dans les permissions du coureur CI.

Pour une mise en œuvre contrôlable, procédez ainsi :

1. Définissez la destination avant l’archive. Écrivez dans la documentation du projet si la branche produit un build interne, une bêta externe ou une candidate.
2. Créez deux tâches CI nommées sans ambiguïté. Par exemple, une tâche de validation interne et une tâche de publication candidate. Évitez un seul script dont le comportement dépend d’un paramètre manuel peu visible.
3. Associez chaque tâche à une branche ou à une règle de fusion. La branche de développement ne doit pas pouvoir déclencher directement le téléversement candidat.
4. Séparez les schémas et les modes d’exportation. Le schéma interne peut activer des journaux ou des fonctions expérimentales ; le schéma candidat doit utiliser la configuration destinée à la publication.
5. Isolez les certificats, profils et clés privées. Le runner utilisé pour les tests internes ne doit pas recevoir automatiquement les secrets nécessaires à la publication.
6. Limitez les identifiants App Store Connect. Utilisez un accès adapté à la tâche, sans exposer une clé API de publication à tous les jobs.
7. Ajoutez une approbation humaine pour la candidate. L’approbation doit confirmer le commit, le numéro de build, le changelog, la conformité et la destination.
8. Conservez les journaux et l’archive de façon identifiable. Masquez les adresses, identifiants d’équipe, identifiants d’application, chemins locaux et jetons dans les artefacts partagés.
9. Vérifiez le statut dans App Store Connect. Le statut d’un build peut évoluer pendant le traitement ; consultez la référence officielle des statuts de build, sans promettre un délai fixe.
10. Documentez le retour arrière. En cas d’erreur, bloquez la promotion du build et corrigez le canal ou la tâche avant de révoquer un certificat.

Cette architecture est particulièrement pertinente lorsque vous utilisez un Mac distant comme serveur de compilation iOS. Vous pouvez consulter les indications de configuration d’un environnement Mac distant pour la compilation iOS avant de décider quels jobs doivent rester actifs en permanence. Si votre besoin alterne entre prototypage, validation audio ou préparation d’une version publique, la séparation des tâches évite de transformer une machine de développement en point unique de publication.

Ne validez pas uniquement le fichier local. Le contrôle doit suivre le parcours complet : archive, exportation, téléversement, traitement, visibilité et association aux testeurs.

Utilisez cette liste avant de considérer le pipeline comme fiable :

• [ ] L’objectif du build est écrit avant l’archivage.
• [ ] La branche et le schéma correspondent à cet objectif.
• [ ] Le mode Internal Only est réservé à une branche qui ne produit jamais de candidate.
• [ ] Le build interne apparaît uniquement dans le périmètre interne attendu.
• [ ] Un build candidat est associé au groupe externe prévu, lorsque cela est nécessaire.
• [ ] La tâche candidate demande une approbation distincte.
• [ ] Les clés privées et identifiants de téléversement sont absents du job interne.
• [ ] Les logs ne contiennent ni clé API, ni jeton, ni identifiant sensible.
• [ ] Le numéro de build et le commit sont inscrits dans l’artefact de livraison.
• [ ] L’équipe sait quel build peut être soumis et lequel doit rester interne.
• [ ] Un échec de visibilité est d’abord traité comme un problème de classification ou d’association.
• [ ] La procédure de reprise évite de révoquer ou de recréer les certificats sans diagnostic.

Pour une validation réaliste, téléversez un build de test anonymisé destiné à l’équipe, puis un build candidat séparé. Vérifiez le libellé interne, les groupes accessibles et la possibilité de poursuivre le circuit de publication. Cette vérification doit être réalisée avec un compte de test approprié, sans exposer de véritable adresse de client, de Team ID, de Bundle ID ou de clé.

N’interprétez pas un traitement lent ou une file d’attente comme une preuve que le mauvais canal a été choisi. Apple ne fournit pas ici de délai fixe à utiliser comme engagement opérationnel. Commencez par contrôler le mode d’envoi, la classification, le numéro de build et l’association au groupe.

Si votre Mac local ne peut pas rester disponible pour exécuter les validations et les candidates, le problème n’est pas seulement le choix TestFlight. Il concerne aussi la continuité du serveur de compilation, les droits de publication et la reprise après interruption. Dans ce cas, la location d’un Mac distant chez KVMNODE peut être plus adaptée qu’un poste local laissé allumé en permanence : vous conservez un environnement macOS dédié, tout en séparant les tâches internes et candidates dans le pipeline. Examinez les options de Mac distant pour vos tâches de développement et de publication, puis vérifiez que votre projet justifie réellement une machine accessible en continu.

Questions fréquentes

Un build Internal Only peut-il être converti en bêta externe ?

Non. Sa classification limite le build aux tests internes. Si votre stratégie évolue vers une bêta externe, créez une nouvelle archive avec le canal de distribution approprié. Ne promettez pas aux testeurs qu’une modification ultérieure dans App Store Connect rendra automatiquement le build disponible.

Un build interne peut-il servir à une soumission App Store ?

Non. Un build réservé à l’équipe ne doit pas être traité comme une candidate. Lorsque la publication devient possible, repartez d’un flux normal, vérifiez la signature, la configuration de production, la conformité et l’association avec les groupes de test concernés.

Comment choisir dans Xcode 27 ?

Faites correspondre le choix à la destination finale. Internal Only convient à une validation strictement interne. Le canal normal convient à une bêta externe ou à une version susceptible d’être soumise. La sélection doit être documentée avant l’archive, notamment lorsque Xcode 27 est appelé automatiquement par la CI.

Comment organiser un Mac distant pour deux canaux ?

Utilisez deux jobs, deux règles de déclenchement et deux niveaux d’autorisation. Le job interne ne doit pas pouvoir publier une candidate. Le job candidat doit contrôler la branche, l’archive, le numéro de build et l’approbation humaine avant le téléversement.

Pourquoi un build n’est-il pas proposé à un groupe externe ?

Vérifiez d’abord s’il a été téléversé comme Internal Only. Contrôlez ensuite le groupe sélectionné, l’association du build et les droits du testeur. Cette vérification est plus sûre qu’un nettoyage immédiat des certificats ou des profils de signature.

Pour un projet qui reste strictement interne, Internal Only est le choix le plus net. Pour toute version destinée à des personnes extérieures ou susceptible de devenir une candidate, choisissez le flux normal. Si vous publiez souvent, le double canal est la solution la plus prévisible : il réduit le risque de confondre un prototype, une bêta et une version prête pour l’App Store.