TestFlight : qu'est-ce que c'est, tests bêta et travail avec les builds

Qu’est-ce que TestFlight

TestFlight est le moyen légitime et le seul officiel de distribuer des applications iOS à des fins de test sans les publier sur l’App Store. Le service a été lancé par Apple en 2014 après l’acquisition de la société du même nom. Avant TestFlight, les développeurs utilisaient la distribution Ad Hoc avec une limite de 100 appareils par saison — TestFlight a supprimé cette limitation et simplifié le processus en quelques clics.

Pourquoi TestFlight est nécessaire

iOS a une politique de sécurité stricte : une application ne peut être installée sur un appareil que via l’App Store ou à l’aide de certificats spéciaux. TestFlight résout le problème des tests bêta en agissant comme un proxy entre le développeur et le testeur : Apple vérifie le build selon les exigences de base, après quoi les testeurs reçoivent l’application via l’application TestFlight depuis l’App Store, ce qui ne nécessite pas de faire confiance à des fichiers non signés.

TestFlight vs Ad Hoc vs Enterprise

Il existe trois façons de distribuer des applications iOS en dehors de l’App Store : Ad Hoc (limite de 100 appareils, nécessite l’UDID de chaque appareil), Enterprise (distribution interne sans limite, nécessite un certificat Enterprise d’Apple à 299 $/an) et TestFlight (jusqu’à 10 000 testeurs, gratuit, ne nécessite pas de collecte d’UDID). TestFlight est le choix optimal pour les tests bêta, Ad Hoc convient pour les tests spécifiques à un appareil et Enterprise pour les applications d’entreprise.

Comment fonctionne TestFlight

Le processus de publication d’un build via TestFlight comprend cinq étapes : construction dans Xcode, téléchargement dans App Store Connect via Archive Organizer, traitement par Apple, invitation des testeurs et installation de l’application via l’application TestFlight. Chaque étape prend de quelques minutes à une heure selon la complexité du projet.

Exigences d’Apple pour le build

Le build doit être créé avec un certificat de distribution et un profil de provisionnement valide. Apple vérifie : la validité du certificat, la correspondance du bundle identifier, l’absence d’API privées, les icônes correctes (1024×1024) et la présence de l’icône App Store. Si le build échoue à la vérification, TestFlight affiche une erreur avec la description du problème.

Traitement du build

Après le téléchargement, le build passe par la vérification automatisée d’Apple : analyse statique du code binaire, vérification de la signature numérique, recherche d’utilisation d’API privées et de logiciels malveillants. Le traitement prend de 15 minutes à 2 heures pour le premier build et généralement 15 à 30 minutes pour les suivants. L’état du traitement est affiché dans Activity dans App Store Connect.

// Configuration de TestFlight dans Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Vérification : l’application est-elle installée via TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Version bêta via TestFlight")
        }
        return true
    }
}

Testeurs internes et externes

TestFlight divise les testeurs en deux groupes : les testeurs internes (Internal Testers) et les testeurs externes (External Testers). La différence réside dans le nombre de participants, l’accès aux builds et la nécessité d’une révision par Apple. Choisir le bon groupe accélère le processus de test et respecte les politiques de l’App Store.

Testeurs internes (Internal)

Jusqu’à 100 participants de l’équipe Apple Developer Program. Pour inviter un testeur interne, il suffit d’ajouter son identifiant Apple dans App Store Connect — il obtient immédiatement l’accès à tous les builds. Aucun examen Apple n’est requis. Idéal pour les tests quotidiens de fumée et la vérification précoce des fonctionnalités.

Testeurs externes (External)

Jusqu’à 10 000 participants ne faisant pas partie de l’équipe de développement. Le premier build destiné aux testeurs externes fait l’objet d’un examen de base par Apple (généralement 1 à 2 jours). Les builds ultérieurs comportant des modifications n’affectant pas les fonctionnalités principales peuvent passer sans nouvel examen. Les testeurs externes sont invités par courriel ou par lien public.

Comment télécharger un build dans TestFlight

Le téléchargement d’un build dans TestFlight s’effectue via Xcode, Application Loader ou la ligne de commande avec xcrun. La méthode la plus courante est via Xcode Archive Organizer après avoir créé une archive du projet. Une méthode alternative est l’automatisation via Fastlane pour les pipelines CI/CD.

Téléchargement manuel via Xcode

Créez une archive (Product → Archive), ouvrez l’Organizer, sélectionnez l’archive et cliquez sur Distribute App. Sélectionnez TestFlight comme méthode de distribution, spécifiez le certificat et le profil de provisionnement. Xcode téléchargera le build dans App Store Connect, où il apparaîtra après le traitement. L’ensemble du processus prend 10 à 20 minutes pour le premier téléchargement.

Automatisation via Fastlane

Fastlane est l’outil le plus populaire pour automatiser le téléchargement des builds dans TestFlight. La commande fastlane pilot télécharge le build et gère les testeurs sans ouvrir Xcode. L’intégration de Fastlane avec un serveur CI/CD permet de publier automatiquement des builds dans TestFlight après la réussite de tous les tests.

# Fastfile — téléchargement du build dans TestFlight
default_platform(:ios)

lane :beta do
    # Obtention des certificats via match
    match(type: "appstore")

    # Compilation et signature
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Téléchargement dans TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot télécharge automatiquement l’IPA dans App Store Connect, attend le traitement (si skip_waiting_for_build = false) et attribue le build aux groupes de testeurs sélectionnés. La commande distribute_external: true envoie immédiatement le build aux testeurs externes après le traitement.

Téléchargement en ligne de commande

Sans Fastlane, vous pouvez utiliser xcrun : xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool est pris en charge par Apple pour les environnements CI et ne nécessite pas d’interface graphique. Le mot de passe est transmis via le trousseau ou un mot de passe spécifique à l’application — n’utilisez pas de mots de passe en texte clair.

Collecte des commentaires et diagnostic dans TestFlight

TestFlight fournit plusieurs mécanismes de retour d’information : un formulaire de commentaires intégré, une collecte automatique des journaux d’incidents, des métriques d’utilisation et des captures d’écran. L’équipe reçoit toutes les données dans App Store Connect sans avoir besoin d’intégrer des SDK tiers pour les tests bêta.

Formulaire de commentaires intégré

Le testeur ouvre l’application TestFlight, sélectionne votre build et clique sur Send Feedback. Le formulaire permet d’envoyer un commentaire texte, de joindre une capture d’écran et d’indiquer la gravité. Tous les commentaires sont collectés dans App Store Connect sous TestFlight → Feedback. Le développeur peut répondre au commentaire et le testeur recevra une notification dans l’application TestFlight.

Journaux d’incidents et diagnostic

En cas de plantage d’une application, TestFlight recueille automatiquement un rapport d’incident : pile d’appels, version du système d’exploitation, modèle de l’appareil et heure du plantage. Les journaux d’incidents sont disponibles dans Xcode Organizer (Crashes) et App Store Connect (TestFlight → Crashes). Pour obtenir des journaux d’incidents symbolisés, vous devez télécharger les fichiers dSYM avec le build ou séparément via Xcode.

Suivi de l’utilisation

TestFlight affiche des métriques : nombre d’installations, testeurs actifs, sessions et plantages. Les analyses sont mises à jour quotidiennement et aident à évaluer l’engagement des testeurs. Si aucun testeur n’a ouvert l’application depuis une semaine, il convient de revoir la communication avec le groupe ou la qualité du build.

De TestFlight à la publication sur l’App Store

TestFlight fait partie intégrante du processus de publication sur l’App Store. Le même build qui a passé les tests bêta via TestFlight peut être soumis à l’examen d’Apple sans recompilation — il suffit de cliquer sur un bouton dans App Store Connect. Cela élimine le risque que le build de production diffère de celui qui a été testé.

Soumettre à l’examen de l’App

Dans App Store Connect, sélectionnez le build qui a passé les tests et cliquez sur Submit for Review. Apple utilise le même build que celui de TestFlight — aucun nouveau téléchargement n’est nécessaire. Le temps d’examen est généralement de 1 à 3 jours. Si le build est rejeté, corrigez les problèmes, téléchargez un nouveau build dans TestFlight et répétez le processus.

Dernier build avant la publication

Il est recommandé d’attendre 24 à 48 heures après la dernière série de tests dans TestFlight avant de soumettre à l’examen. Ce temps permet aux testeurs de découvrir les bogues critiques qui pourraient échapper aux tests automatisés. Le build release candidate (RC) dans TestFlight est une pratique standard pour les équipes iOS matures.

Que faire après la publication

Les builds TestFlight deviennent automatiquement indisponibles pour les nouvelles installations après la sortie de la version finale sur l’App Store. Les testeurs qui ont déjà installé la version bêta peuvent continuer à l’utiliser pendant 30 jours après la publication de la version finale, après quoi l’application cesse de s’ouvrir. Assurez-vous que les testeurs mettent à jour vers la version de l’App Store.