Internal Testing : ce que c'est, comment ça marche et comment configurer le track

Qu'est-ce qu'Internal Testing ?

Internal Testing est un track de test dans Google Play Console et TestFlight conçu pour distribuer des builds aux membres de l'équipe de développement. Contrairement aux tests bêta ouverts, l'accès à Internal Testing est limité à une liste d'adresses e-mail approuvées par le propriétaire du compte développeur.

Le principal avantage est le temps de livraison minimal du build aux testeurs. Dans Google Play, Internal Testing ne nécessite pas de passer par la modération — le build apparaît pour les participants 5 à 15 minutes après le téléchargement. Dans l'App Store via TestFlight, le build est également livré sans App Review préalable, mais est soumis à une vérification automatique des exigences de sécurité de base.

En quoi Internal Testing diffère des autres tracks

Google Play propose trois tracks de test : Internal Testing, Closed Beta (Open Beta) et Production. Internal Testing est le plus rapide et le plus limité en nombre de participants (jusqu'à 100 personnes). Closed Beta permet jusqu'à 10 000 participants et nécessite la configuration d'une page de test. Production est l'étape finale avec une modération complète.

Quand utiliser Internal Testing

Internal Testing est utilisé pour la vérification initiale des builds avant de les passer aux tracks bêta. Les développeurs téléchargent des builds quotidiens pour l'équipe QA, vérifient l'intégration de nouveaux SDK, testent la compatibilité avec différentes versions d'OS et identifient les erreurs de régression avant que le build ne soit vu par les testeurs externes.

Internal Testing dans Google Play

Dans Google Play Console, Internal Testing est un track séparé disponible dans la section Release → Testing. Pour ajouter un testeur, il suffit de saisir son adresse e-mail — le participant reçoit une invitation et un lien pour rejoindre via Google Play. Les builds sont téléchargés via la même interface que les versions de production.

Processus de publication dans le track Interne

Le développeur télécharge un App Bundle ou APK dans la section Internal Testing de Google Play Console. Le système vérifie les exigences de base : signature, version du code et compatibilité API. Après 5 à 15 minutes de traitement, le build devient disponible pour les testeurs. Le statut est suivi dans la console : Brouillon, En révision, Prêt à tester.

// Fastlane — publication dans le track Internal Testing
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Gestion des testeurs

L'ajout de participants se fait via la section Testers dans Google Play Console. Le téléchargement groupé via fichier CSV est pris en charge. Chaque testeur reçoit un e-mail avec une invitation et des instructions d'installation. Pour révoquer l'accès, il suffit de supprimer le participant du groupe — l'application installée continue de fonctionner, mais les nouvelles mises à jour n'arrivent pas.

Internal Testing dans l'App Store via TestFlight

Dans l'écosystème Apple, le rôle d'Internal Testing est joué par TestFlight — une plateforme de distribution de versions bêta. TestFlight prend en charge jusqu'à 100 testeurs internes, ajoutés par e-mail via App Store Connect. La publication d'un build ne nécessite pas d'App Review complète, mais le build est automatiquement vérifié pour les exigences minimales.

Caractéristiques de TestFlight Internal Testing

Contrairement à Google Play, où Internal Testing ne nécessite aucune modération, Apple effectue une révision de base automatique. La vérification prend 30 à 60 minutes et comprend l'analyse du code binaire pour détecter les API malveillantes et la conformité aux exigences de base. Après une vérification réussie, le build est disponible pour les testeurs dans les 24 heures. Le build est valable 90 jours.

Configuration d'Internal Testing dans App Store Connect

Dans App Store Connect, Internal Testing est configuré dans la section TestFlight → Internal Testing. Le propriétaire du compte ajoute les testeurs par e-mail et attribue les rôles. Après le téléchargement d'un build via Xcode ou Transporter, le système notifie les participants de la disponibilité d'une nouvelle version. Les testeurs installent l'application via l'application TestFlight sur leur appareil.

Comment configurer un track Internal Testing

La configuration d'Internal Testing pour les deux plateformes prend de 10 à 30 minutes. Vous trouverez ci-dessous des instructions étape par étape pour Google Play et App Store. Le processus ne nécessite aucune modification du code de l'application — une configuration unique de la console développeur suffit.

Intégration avec les systèmes CI/CD

Les deux magasins prennent en charge la publication dans Internal Testing via API. Pour l'automatisation, on utilise Gradle Play Publisher (Google Play) et Fastlane (les deux plateformes). Le pipeline CI/CD peut télécharger des builds dans le track Interne après chaque exécution réussie de tests unitaires et de tests UI.

Configuration des comptes de test

Pour les applications avec authentification, il est nécessaire de préparer des comptes de test et de les fournir à l'équipe QA. Les comptes doivent avoir accès à l'environnement de test (staging/development) et ne pas affecter les données de production. Il est recommandé de créer une configuration Firebase de test distincte pour le track Interne.

Flux de travail QA avec Internal Testing

Internal Testing est intégré au pipeline QA après avoir passé les vérifications automatiques dans CI. Le développeur ou l'ingénieur DevOps télécharge le build dans le track Interne, après quoi les ingénieurs QA reçoivent une notification et installent la mise à jour sur les appareils de test via le magasin d'applications.

Fréquence de publication optimale

Il est recommandé de publier des builds dans Internal Testing quotidiennement ou après chaque modification importante de la base de code. L'équipe QA teste les scénarios critiques : authentification, flux utilisateur principal, intégration API et opérations de stockage local. Les tests de régression sont effectués sur chaque troisième ou quatrième build.

Outils de collecte de commentaires

Pour collecter les rapports de bugs, utilisez l'intégration avec les systèmes de suivi : Jira, YouTrack, Trello ou GitHub Issues. Les testeurs envoient des captures d'écran, des logs et les étapes de reproduction. TestFlight prend en charge nativement la collecte de captures d'écran et de logs de l'appareil lors de l'agitation — les données sont envoyées au développeur via App Store Connect.

Intégration avec pipeline CI/CD

Pour publier automatiquement des builds dans le track Internal Testing, configurez un pipeline CI/CD. Après avoir réussi les tests unitaires et les tests UI, le script télécharge le build dans le track Interne et envoie une notification à l'équipe QA. Fastlane fournit l'action prête à l'emploi upload_to_play_store avec le paramètre track: internal. Pour iOS, utilisez Fastlane Pilot pour télécharger vers TestFlight.

Limitations et limites d'Internal Testing

Internal Testing a des limites strictes quant au nombre de participants : jusqu'à 100 personnes dans Google Play et jusqu'à 100 testeurs internes dans TestFlight. Google Play limite également le nombre de groupes — maximum 1 groupe pour le track Interne. L'App Store ne limite pas le nombre de builds, mais chaque build a une durée de validité de 90 jours.

Différences de limites entre les plateformes

Google Play ne limite pas le nombre de builds téléchargés dans le track Interne, mais après 90 jours d'inactivité, le track peut être automatiquement suspendu. TestFlight a des limites plus strictes : jusqu'à 30 builds actifs simultanément, jusqu'à 10 000 testeurs externes (pas internes). Pour lever les restrictions, une participation au programme Apple Developer Enterprise est requise.

Migration d'Internal vers Open Beta

Après stabilisation du build sur le track Interne, il est déplacé vers Closed ou Open Beta pour des tests avec un public externe. Google Play permet de copier les paramètres du track et de transférer le build sans le retélécharger. TestFlight nécessite la création d'un track externe séparé avec de nouveaux groupes de testeurs.

Sécurité du track Internal Testing

Les builds dans le track Interne sont protégés contre l'accès externe : seuls les participants autorisés via Google Play Console ou App Store Connect peuvent télécharger l'application. Même si quelqu'un connaît le lien de l'application, un utilisateur non autorisé ne peut pas installer le build. Cela garantit la confidentialité des nouvelles fonctionnalités et protège la propriété intellectuelle pendant la phase de développement.