Comment distribuer vos apps iOS et Android aux testeurs

Pour distribuer des apps iOS aux testeurs, utilisez TestFlight (testeurs internes immédiatement, testeurs externes après une courte Beta App Review) ou un build ad hoc pour les appareils enregistrés. Pour Android, utilisez un canal de test Google Play (interne, fermé ou ouvert), le partage d'app interne de Play pour des liens ponctuels, ou partagez un APK signé via Firebase App Distribution ou en téléchargement direct. Le choix dépend de qui sont vos testeurs, de leur nombre et de la nécessité pour le build de passer par l'infrastructure du store.

Ce guide compare toutes les options, explique comment configurer chacune pour une app Capacitor et liste les erreurs que rencontrent généralement les testeurs.

Choisir une méthode

Règles empiriques :

• Le même build que vous publierez sur le store ? Utilisez TestFlight et les tracks Play. Le binaire utilisé par les testeurs est celui qui sera promu.
• Des builds QA quotidiens ? Tests internes sur les deux stores, ou Firebase App Distribution.
• Need to test a web-layer change in minutes? Déployez un live update vers un canal de test plutôt qu'un nouveau binaire.

Avant de distribuer : la signature

Chaque build de test doit être signé.

• iOS les builds de test utilisent soit un App Store Connect profil (TestFlight) ou un Ad Hoc profil (installation directe). Les deux utilisent un certificat Apple Distribution. Voir les certificats iOS et les profils de provisionnement expliqués.
• Android les builds destinés aux canaux Play sont des AAB signés avec votre clé d'upload. Pour une installation directe, il vous faut un APK signé avec une clé de release. Un APK de debug s'installe aussi, mais il se comporte différemment (debuggable, signature différente) et ne pourra pas être mis à jour ensuite par votre build Play.

iOS : TestFlight

Envoyer un build

Depuis Xcode : Product > Archive, puis Distribuer l'app > App Store Connect > Envoyer. Depuis la ligne de commande ou votre CI, exportez un .ipa et envoyer avec une clé API d’App Store Connect, ou laissez un service de build cloud s’en charger.

Depuis avril 2026, les uploads doivent être compilés avec Xcode 26 ou une version ultérieure.

Ajoutez cette clé à ios/App/App/Info.plist si votre application n’utilise que le chiffrement HTTPS standard, afin qu’App Store Connect ne pose pas la question de conformité à l’exportation pour chaque build :

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Le traitement dure de quelques minutes à environ une heure. Vous recevez un e-mail quand le build est prêt.

Tests internes

1. Dans App Store Connect, ouvrez votre application, TestFlight > Tests internes, et créez un groupe.
2. Ajoutez des membres à l’équipe. Ils doivent avoir un rôl’App Store Connect (Admin, App Manager, Developer, Marketing…). Jusqu’à 100 personnes.
3. Activer distribution automatique ainsi, chaque nouveau build est envoyé au groupe.
4. Les testeurs installent l'application TestFlight depuis l'App Store et acceptent l'invitation.

Aucune revue n'est nécessaire. C'est le chemin le plus rapide de l'upload au téléphone.

Tests externes

1. TestFlight > Tests externes > + pour créer un groupe.
2. Ajoutez des testeurs par e-mail, ou activez un lien public avec une limite de testeurs optionnelle.
3. Ajoutez le build au groupe et remplissez Informations de test (quoi tester, e-mail de feedback, description de l'app bêta et identifiants de démo si besoin).
4. Soumettre pour Examen de l'app bêta. Le premier build de chaque version est examiné, généralement en moins d'un jour. Les builds suivants d'une même version sont souvent publiés sans examen complet.

Les tests externes acceptent jusqu'à 10 000 testeurs. Les testeurs peuvent envoyer des captures d'écran avec leur feedback directement depuis TestFlight, que vous retrouvez dans App Store Connect.

Limites de TestFlight à connaître

• Les builds expirent après 90 jours.
• Les testeurs doivent avoir une version d'iOS compatible avec votre build (Capacitor 8 nécessite iOS 15 ou version ultérieure).
• Les builds TestFlight utilisent la signature App Store de production, donc les notifications push utilisent la Production Environnement APNs.
• Les achats in-app dans TestFlight utilisent l’environnement sandbox et ne sont pas facturés.

iOS : distribution ad hoc

Les builds ad hoc s’installent directement sur les appareils enregistrés dans le portail Apple Developer, sans TestFlight ni revue Apple.

1. Récupérez l’UDID de chaque testeur. Les testeurs peuvent l’obtenir sur leur propre téléphone avec le Recherche d'UDID iOS, ou vous pouvez le lire depuis Finder ou Xcode lorsque l’appareil est connecté.
2. Enregistrez les appareils dans Certificats, identifiants et profils > Appareils.
3. Créez un fichier Ad Hoc profil de provisionnement incluant ces appareils et téléchargez-le.
4. Compiler un .ipa avec ce profil (Xcode : Distribute App > Release Testing, qui est le nouveau nom d'Ad Hoc).
5. L'installer :
   • Glissez le .ipa sur l'appareil dans le Finder ou Xcode > Window > Devices and Simulators.
   • Ou hébergez-l’avec un itms-services manifeste via HTTPS pour que les testeurs n'aient qu'à cliquer sur un lien. Des services comme Firebase App Distribution le font pour vous.
6. Sur iOS 16 et versions ultérieures, l’installation .ipa depuis un Mac (Xcode ou Apple Configurator) nécessite Mode développeur sur l’appareil (Réglages > Confidentialité et sécurité). Les installations via un itms-services lien n’en ont pas besoin. Voir Comment activer le mode développeur sur iOS.

Ajouter un nouveau testeur implique d’enregistrer son UDID, de régénérer le profil et de recompiler. Les emplacements d’appareils (100 par famille d’appareils) ne se réinitialisent qu’au renouvellement de votre adhésion annuelle, n’enregistrez donc pas d’appareils à la légère.

Android : canaux de test Google Play

Play Console propose trois pistes de test en plus de la production. Toutes nécessitent un AAB signé avec votre clé d’upload.

Tests internes

1. Tester > Test interne > Testeurs: créez une liste d’e-mails (jusqu’à 100 adresses).
2. Créer une nouvelle release, envoyez l’AAB, ajoutez les notes de version, enregistrez et déployez.
3. Copiez le lien d'opt-in et l'envoyer aux testeurs. Ils acceptent et installent via le Play Store.

Les releases internes sont généralement disponibles en quelques minutes sans attendre une revue complète. La première release d'une toute nouvelle application peut prendre plus de temps pendant que Google traite l'app.

Tests fermés

Les canaux fermés sont examinés et acceptent les listes d'e-mails ou Google Groups. C'est le canal qu'il vous faut pour la 12 testeurs pendant 14 jours Cette règle s'applique aux comptes développeurs personnels créés après le 13 novembre 2023, avant l'accès à la production. Utiliser un Google Group facilite l'adhésion des testeurs. Plus de détails dans comment créer des comptes développeurs Apple et Google Play.

Tests ouverts

N'importe qui peut rejoindre via votre fiche Play Store. Utilisez-le pour une bêta publique une fois votre fiche store terminée. Les retours des testeurs ouverts sont privés et n'affectent pas votre note publique.

Notre Guide de test bêta sur Android compare les canaux de test plus en détail.

Android : Internal app sharing

L'Internal app sharing est le moyen le plus rapide d'installer un APK ou un AAB sur un appareil via le Play Store, sans les règles de version code et sans examen.

1. Dans la Play Console, ouvrez Partage d'applications en interne (sous Test) et ajoutez des uploaders.
2. Envoyez un APK ou un AAB. Vous obtenez un lien.
3. Testers open the Play Store app, go to settings, tap the version du Play Store sept fois pour afficher les paramètres développeur, puis activent Partage d'applications en interne.
4. Les testeurs ouvrent le lien et installent.

C'est utile pour la QA des builds de pull request, car il n'est pas nécessaire d'incrémenter les codes de version.

Android : APK direct et Firebase App Distribution

APK direct

Compilez un APK de release signé. Un nouveau projet Capacitor n'a pas de release configuration de signature, donc assembleRelease cela produirait un APK non signé qui ne pourra pas s'installer. Ajoutez un signingConfigs.release bloc (chemin du keystore et mots de passe, généralement lus depuis key.properties) à android/app/build.gradle et pointez buildTypes.release.signingConfig vers lui en premier.

bun run build
bunx cap sync android
cd android && ./gradlew assembleRelease

Partager android/app/build/outputs/apk/release/app-release.apk via un lien. Les testeurs autorisent leur navigateur ou leur gestionnaire de fichiers à installer des applications inconnues, puis ouvrent le fichier. S'ils ont déjà une version du Play Store installée, ils doivent d'abord la désinstaller, car les signatures diffèrent. Vous pouvez aussi installer par USB avec adb install -r app-release.apk (voir comment activer les options développeur sur Android).

À partir du 30 septembre 2026, les appareils Android certifiés au Brésil, en Indonésie, à Singapour et en Thaïlande n'installeront que les applications dont le nom de package est enregistré par un développeur vérifié, avec un déploiement mondial prévu pour 2027. Si vos testeurs se trouvent dans ces pays, enregistrez le nom de package dans l'Android Developer Console ou la Play Console. Les installations via adb ne sont pas concernées.

Firebase App Distribution

Firebase App Distribution fonctionne pour les deux plateformes, envoie des invitations par e-mail et suit qui a installé quel build.

bun add -g firebase-tools
firebase login

firebase appdistribution:distribute android/app/build/outputs/apk/release/app-release.apk \
  --app 1:1234567890:android:abc123def456 \
  --groups "qa-team" \
  --release-notes "Fix checkout crash"

• Les testeurs Android installent depuis le lien reçu par e-mail ou depuis l'application App Tester.
• Les testeurs iOS doivent toujours figurer dans un profil ad hoc (ou de développement). App Distribution récupère leurs UDID lorsqu'ils acceptent l'invitation, mais c'est à vous de les enregistrer et de relancer le build.
• La distribution d'un AAB nécessite de lier le projet Firebase à Google Play.

Les builds cloud qui remettent un lien aux testeurs

Si vous ne voulez pas maintenir des Macs et la signature sur chaque runner de CI, Build Capgo compile les apps Capacitor dans le cloud. Pour les builds de test, il peut éviter la publication sur les stores et envoyer le binaire via un lien de téléchargement à durée limitée avec un QR code :

# Android APK/AAB for testers, no Play upload
bunx @capgo/cli@latest build request com.example.app \
  --platform android --no-playstore-upload --output-upload --output-retention 2d

# iOS ad hoc build (no App Store submission)
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-distribution ad_hoc --output-upload

# iOS build uploaded to TestFlight for external groups
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-testflight-groups "Beta Testers"

Ajoutez --output-record build.json et lire le lien dans la CI avec bunx @capgo/cli@latest build last-output --path build.json --field outputUrl pour le poster dans une pull request ou un chat. La Capgo Docs de build liste toutes les options.

Évitez de recompiler pour les changements web

La plupart des changements dans une app Capacitor se trouvent dans la couche web. Recompiler et redistribuer un binaire pour une simple correction de texte fait perdre une journée de traitement et de validation TestFlight. Avec les live updates Capgo, les testeurs conservent le build installé, et vous envoyez de nouveaux bundles JS vers un canal de test :

bunx @capgo/cli@latest bundle upload --channel beta

Vous pouvez même attribuer un canal propre à chaque pull request et permettre à la QA de basculer entre eux sur la même app installée. Voir transformez chaque pull request en une preview installable.

Troubleshooting

« Impossible d'installer » sur iOS ad hoc. L'UDID de l'appareil n'est pas dans le profil, ou le profil a expiré. Vérifiez avec security cms -D -i profile.mobileprovision.

L'application s'ouvre et se ferme immédiatement sur iOS. Le mode développeur est désactivé (builds ad hoc/de développement), ou le profil a expiré.

Le build TestFlight est bloqué sur « Processing ». Attendez jusqu'à une heure. Si cela échoue, l'e-mail en indique la raison, souvent une chaîne de description d'utilisation manquante (NSCameraUsageDescription et autres similaires) ou un problème d'icône.

« Missing Compliance » sur TestFlight. Répondez à la question de conformité à l'exportation dans App Store Connect ou ajoutez ITSAppUsesNonExemptEncryption vers Info.plist.

Erreur « Application non installée » sur Android. Une version avec une signature différente est déjà installée, ou l'APK n'est pas signé ou est corrompu. Désinstallez l'application existante.

Le testeur ne voit pas l'application dans le Play Store après avoir rejoint le test. Patientez quelques minutes, assurez-vous que le testeur est connecté avec le compte invité, et vérifiez que la release est déployée sur la piste et que son pays est bien pris en charge.

« La version code est déjà utilisée » lors de l'upload. Incrémenter versionCode dans android/app/build.gradle. L'Internal App Sharing est l'exception.

Les notifications push n'arrivent pas dans TestFlight. TestFlight utilise l'environnement APNs de production. Vérifiez l' aps-environment entitlement et le paramètre d'environnement de votre fournisseur de push.

Configuration recommandée pour une petite équipe

1. Groupe interne TestFlight avec distribution automatique, ainsi qu'un canal de test interne Play, pour chaque merge vers main.
2. Un groupe externe TestFlight et un canal de test fermé Play pour les bêta-testeurs, mis à jour chaque semaine.
3. Des live updates sur un beta canal pour les correctifs web uniquement entre deux builds.
4. Une fois la bêta stable, promouvez le même build en production sur les deux stores et suivez le guide du premier examen de l'app.