Déployer une app sur Play Store et App Store avec fastlane

Ce tutoriel automatise la publication d’une application mobile sur Google Play et l’App Store avec fastlane. Vous configurerez d’abord les comptes développeurs et les API d’accès stores, puis fastlane match pour centraliser les certificats iOS, et enfin deux lanes qui uploadent en une commande l’AAB sur Google Play Internal Testing et l’IPA sur TestFlight. À la fin, fastlane android beta et fastlane ios beta remplacent une heure de manipulations manuelles dans les consoles, et s’intègrent au pipeline CI/CD pour des releases entièrement automatisées.

📍 Guide principal de la série : Développement mobile 2026 : Flutter 3, React Native, Expo, stores

Pour le panorama complet, lire d’abord ce guide.

Prérequis

Le déploiement aux stores demande des comptes payants et plusieurs identifiants à préparer en amont. La majorité des étapes ci-dessous suppose qu’ils sont déjà créés.

• Compte Apple Developer à 99 $/an, créé sur developer.apple.com
• Compte Google Play à 25 $ une fois, créé sur play.google.com/console
• App déjà signée et builds testés localement (voir tutoriels Flutter et React Native+Expo)
• Mac avec macOS Sequoia 15+ et Xcode 26 pour la partie iOS (en local ou via runner cloud)
• Ruby 3.0+ avec gestionnaire (rbenv, asdf, ou Ruby intégré macOS)
• Un dépôt Git privé pour stocker les certificats iOS via match
• Bundle Identifier iOS et applicationId Android définitifs (ils seront figés après publication)

Niveau attendu : développeur intermédiaire ayant déjà construit une app et compris la signature de base. Temps total : trois à quatre heures pour la première mise en place de fastlane des deux côtés, ensuite chaque release prend dix minutes.

Étape 1 — Créer l’app sur Google Play Console

Google Play exige que l’app soit déclarée sur la console avant tout upload, même via API. La création prend dix minutes et fixe trois éléments durables : le nom de l’app, le bundle ID Android (applicationId) et le pays de paiement.

Connectez-vous sur play.google.com/console avec le compte développeur. Cliquez sur « Créer une application », saisissez le nom (modifiable plus tard), la langue par défaut, le type (application ou jeu), et la catégorie (gratuit ou payant). Acceptez les déclarations Play Policies et la déclaration export US. La console crée la fiche et redirige vers le tableau de bord de l’app.

Avant de pouvoir uploader le premier AAB, Google demande de remplir cinq sections obligatoires accessibles depuis la barre latérale : « Politique de confidentialité » (URL publique), « Publicités » (déclaration), « Accès à l’app » (instructions de connexion pour les évaluateurs Google), « Classification du contenu » (questionnaire) et « Public cible ». Ces formulaires prennent vingt à trente minutes selon le profil de l’app. Aucune ne peut être ignorée.

Une fois ces sections complètes, allez dans « Tests et publication » → « Tests » → « Tests internes ». C’est ici qu’on uploadera les premiers AAB sans passer par la revue store complète. Créez la piste de tests internes, ajoutez votre email comme testeur initial, et notez l’URL de la piste — vous en aurez besoin pour la première installation.

Étape 2 — Générer le service account Google Play API

Pour que fastlane upload des AAB sans intervention humaine, il faut une clé API. Google Play utilise les service accounts Google Cloud avec des permissions spécifiques sur la console.

Sur Google Play Console, allez dans Paramètres → Accès API. Si c’est votre premier projet, cliquez sur « Lien à un projet Google Cloud » et acceptez la création automatique. Dans la liste des comptes de service Google Cloud, cliquez sur « Créer un compte de service ». Saisissez un nom (par exemple fastlane-publisher), une description, et passez les rôles Google Cloud (laissez vide). Une fois créé, le compte apparaît dans la liste.

Cliquez sur le compte créé, onglet « Clés », « Ajouter une clé » → JSON. Le navigateur télécharge un fichier JSON contenant la clé privée — c’est ce fichier que fastlane utilisera. Ne le commit jamais. Stockez-le dans un coffre-fort, ajoutez son chemin dans .gitignore, et notez son emplacement.

Retournez sur Google Play Console → Accès API. Le compte de service apparaît dans la liste. Cliquez sur « Accorder l’accès », choisissez « Administrateur » pour la portée des permissions (ou un rôle plus restreint si vous savez exactement ce dont fastlane a besoin), et confirmez. Sans cette étape, fastlane recevra une erreur 403 à chaque upload — c’est l’oubli numéro un des premiers déploiements.

Étape 3 — Installer fastlane

Fastlane est un gem Ruby. Sur macOS, il fonctionne avec le Ruby intégré, mais il est plus propre d’utiliser un Ruby géré par rbenv ou asdf. Sur Linux, installez Ruby via apt ou asdf. Sur Windows, fastlane fonctionne mais avec quelques limitations — préférez WSL2 ou un Mac pour la partie iOS.

gem install fastlane

La commande télécharge fastlane et ses dépendances (environ 50 gems, 100 Mo). Vérifiez l’installation avec fastlane --version qui doit retourner 2.233.0 ou une version proche en mai 2026. Si la commande échoue avec « permission denied », utilisez sudo gem install fastlane ou installez via Homebrew avec brew install fastlane qui gère les permissions automatiquement.

Étape 4 — Initialiser fastlane dans le projet Android

Naviguez dans le dossier android/ de votre projet Flutter ou React Native, et lancez l’initialisation. Pour un projet React Native pur (sans Expo), c’est le dossier android/ à la racine. Pour un projet Flutter, c’est aussi android/.

cd android
fastlane init

L’assistant pose plusieurs questions. Choisissez l’option 4 « Manual setup » — les autres options supposent un workflow Gradle classique qui ne correspond pas exactement à Flutter ou React Native. L’assistant crée un dossier fastlane/ avec deux fichiers : Appfile (configuration globale) et Fastfile (les lanes elles-mêmes).

Éditez Appfile pour pointer vers votre service account et déclarer le package name.

json_key_file("../fastlane-publisher.json")
package_name("com.votreentreprise.monapp")

Le chemin du JSON est relatif au dossier android/fastlane/. Si vous avez stocké la clé dans ~/.config/google-play-keys/, indiquez le chemin absolu. Le package_name doit correspondre exactement à l’applicationId déclaré dans build.gradle.kts.

Étape 5 — Écrire la lane Android beta

Une lane est une fonction Ruby dans Fastfile qui regroupe les actions à exécuter. Pour la beta Android, on veut deux choses : builder l’AAB en release, l’uploader sur la piste de tests internes. Ajoutez la lane suivante dans Fastfile, sous le bloc platform :android do.

platform :android do
  desc "Build et upload sur Google Play Internal Testing"
  lane :beta do
    sh "cd ../.. && flutter build appbundle --release"
    upload_to_play_store(
      track: 'internal',
      aab: '../build/app/outputs/bundle/release/app-release.aab',
      skip_upload_apk: true,
      skip_upload_metadata: true,
      skip_upload_changelogs: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

Cette lane fait deux opérations. D’abord sh "cd ../.. && flutter build appbundle --release" qui retourne à la racine du projet et lance le build Flutter en release. Ensuite upload_to_play_store qui upload l’AAB généré sur la piste internal, en sautant la mise à jour des métadonnées (qu’on ne veut pas écraser à chaque release de bêta).

Lancez la lane depuis le dossier android/.

fastlane android beta

Le premier upload prend cinq à dix minutes le temps que Flutter compile et que fastlane upload via l’API. La sortie affiche en vert « Successfully uploaded build to Internal Testing track » — c’est le signal que l’AAB est arrivé. Connectez-vous à Google Play Console pour vérifier qu’il apparaît dans « Tests internes » avec le bon versionCode.

Étape 6 — Initialiser fastlane dans le projet iOS et configurer match

Côté iOS, fastlane match centralise les certificats et provisioning profiles dans un dépôt Git privé chiffré, accessible à toute l’équipe et au CI. C’est l’outil le plus important pour éviter que chaque développeur jongle avec ses propres certificats.

Naviguez dans ios/ et initialisez fastlane.

cd ../ios
fastlane init

Choisissez l’option 4 « Manual setup ». Ensuite, créez un dépôt Git privé sur GitHub ou GitLab (par exemple certs-monapp). Initialisez match avec une référence vers ce dépôt.

fastlane match init

L’assistant demande l’URL du dépôt Git de stockage. Collez l’URL HTTPS ou SSH du dépôt privé créé. Match crée un fichier Matchfile dans ios/fastlane/. Maintenant générez les certificats de distribution App Store.

fastlane match appstore

La commande demande un mot de passe — ce sera la clé qui chiffre tous les certificats dans le dépôt Git. Notez-le précieusement, vous en aurez besoin sur chaque machine et sur chaque runner CI. Match se connecte ensuite à votre compte Apple Developer (il vous demandera vos identifiants Apple), génère un nouveau certificat de distribution et un provisioning profile App Store, les chiffre, et les pousse dans le dépôt Git. La première exécution prend cinq minutes.

Étape 7 — Écrire la lane iOS beta vers TestFlight

Une fois match configuré, la lane iOS beta peut récupérer les certificats sans intervention, builder l’IPA et l’envoyer à TestFlight. Ajoutez la lane suivante dans le Fastfile de ios/.

platform :ios do
  desc "Build et upload vers TestFlight"
  lane :beta do
    match(type: "appstore", readonly: true)
    sh "cd ../.. && flutter build ipa --release"
    upload_to_testflight(
      ipa: "../build/ios/ipa/Runner.ipa",
      skip_waiting_for_build_processing: true
    )
  end
end

Le drapeau readonly: true dit à match de récupérer les certificats existants sans en créer de nouveaux — c’est ce que vous voulez en CI et en local après l’init. upload_to_testflight envoie l’IPA à App Store Connect et l’inscrit en tant que nouveau build TestFlight. skip_waiting_for_build_processing permet de ne pas attendre que TestFlight finisse de traiter le binaire (ce qui peut prendre 15-20 minutes) — la commande retourne dès que l’upload est réussi.

Lancez la lane.

fastlane ios beta

La sortie indique étape par étape : récupération des certificats depuis match, build Flutter, signature, upload à App Store Connect. La première exécution échoue souvent parce qu’Apple demande une vérification 2FA via votre téléphone. Préparez-vous à entrer un code reçu par SMS ou via l’app « Apple Developer ». Pour automatiser cette étape en CI, configurez une app-specific password dans appleid.apple.com et stockez-la dans une variable d’environnement FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD.

Étape 8 — Préparer la fiche App Store et Play Store

Avant la première soumission « production », il faut remplir les fiches stores. Sur Apple, c’est dans App Store Connect ; sur Google, dans Play Console → « Store Listing ».

Les éléments obligatoires sont les mêmes des deux côtés : icône (1024×1024 sur iOS, 512×512 sur Android), captures d’écran (au moins une, idéalement 3-5 par format de device), description courte (170 caractères iOS, 80 Android), description longue (4 000 caractères max), URL de support, URL de politique de confidentialité, classification d’âge, catégorie. Côté iOS s’ajoutent les mots-clés (séparés par virgules, 100 caractères max) qui pèsent sur l’ASO. Côté Android s’ajoutent les graphiques de couverture du Play Store.

Fastlane peut automatiser le push de ces métadonnées via les actions upload_to_app_store (iOS) et l’option skip_upload_metadata: false (Android). Mais la première fois, faites-le manuellement dans les consoles : c’est plus rapide pour comprendre les contraintes de chaque champ. Dès que les métadonnées sont stables, vous les versionnez en local sous fastlane/metadata/ et automatisez les futures mises à jour.

Étape 9 — Soumettre à la revue App Store

Apple impose une revue manuelle avant chaque release sur l’App Store public. Cette revue dure généralement 24 à 48 heures en mai 2026, parfois moins, parfois plus selon la charge. Beaucoup de premières soumissions échouent — préparez-vous à itérer.

Sur App Store Connect, sélectionnez votre app, version « 1.0.0 », choisissez le build TestFlight uploadé à l’étape 7, remplissez le champ « Notes pour l’évaluation Apple » (instructions de connexion si l’app a un login, mention spécifique si elle utilise des contenus particuliers), et cliquez « Submit for review ». Le statut passe à « Waiting for Review » puis « In Review ».

Les motifs de rejet les plus fréquents en 2026 sont au nombre de cinq. Métadonnées trompeuses (description ne correspond pas aux fonctionnalités). Politique de confidentialité absente ou inaccessible. Login obligatoire sans option pour les évaluateurs. Privacy Manifest manquant — Apple impose PrivacyInfo.xcprivacy pour toutes les nouvelles soumissions depuis le 1ᵉʳ mai 2024. Crash au lancement sur les devices d’évaluation. Anticipez chacune avant de soumettre.

Étape 10 — Soumettre à la revue Google Play et automatiser le rollout

Google Play est plus permissive qu’Apple sur la revue initiale. Le premier upload sur la piste « Production » passe par une revue de 1 à 7 jours selon le profil de l’app. Les mises à jour suivantes sont souvent revuées en quelques heures.

Modifiez votre lane Android pour ajouter une lane « production » qui pousse sur la piste production avec un rollout progressif.

lane :production do
  sh "cd ../.. && flutter build appbundle --release"
  upload_to_play_store(
    track: 'production',
    rollout: '0.1',
    aab: '../build/app/outputs/bundle/release/app-release.aab',
    skip_upload_metadata: false,
    skip_upload_changelogs: false
  )
end

Le paramètre rollout: '0.1' active un déploiement progressif à 10 % des utilisateurs. C’est une protection essentielle : si votre nouvelle version a un bug critique, seuls 10 % des utilisateurs sont impactés et vous pouvez l’arrêter avant un déploiement complet. Pour augmenter la part au cours des heures suivantes, utilisez fastlane supply --rollout 0.5 sans rebuilder.

Côté iOS, Apple ne propose pas de rollout progressif aussi fin — la version validée est immédiatement disponible à 100 % des utilisateurs. La protection équivalente passe par le suivi attentif des crash reports (Sentry, Firebase Crashlytics) dans les heures qui suivent la sortie. Pour une release iOS, prévoyez d’être disponible en backup les premières 24 heures.

Erreurs fréquentes

Tutoriels associés

• Flutter 3 — créer une app cross-platform et générer l’APK release
• React Native avec Expo et EAS — premier projet de bout en bout
• CI/CD pour applications mobile — GitHub Actions et Codemagic

Pour aller plus loin

• 🔝 Retour au guide principal : Développement mobile 2026 : Flutter 3, React Native, Expo, stores
• Documentation officielle fastlane
• fastlane — upload_to_play_store
• fastlane — upload_to_testflight
• fastlane match — code signing
• Apple — App Review Guidelines
• Apple Developer — upcoming requirements
• Google Play Console — centre d’aide

FAQ

Q : Faut-il acheter l’Apple Developer Program pour tester sur un iPhone ?

R : Non. Depuis Xcode 7, Apple permet de signer des apps avec un Apple ID gratuit pour les tester sur ses propres devices. La limite est de 7 jours — au bout d’une semaine, l’app expire et il faut la re-signer. Pour TestFlight, l’App Store, ou pour distribuer à plus de quelques devices, le programme payant à 99 $/an devient nécessaire.

Q : Combien de temps prend la première revue App Store ?

R : En mai 2026, Apple annonce un délai médian de 24 heures, avec 90 % des soumissions répondues sous 48 heures. Les rejets arrivent généralement dans les 24 premières heures. La première soumission tend à prendre légèrement plus longtemps — comptez 48 à 72 heures pour le premier « Approved ». Les fenêtres de fin d’année et de WWDC ralentissent le processus.

Q : Peut-on automatiser entièrement la soumission App Store sans interaction humaine ?

R : Pas totalement. Le clic « Submit for review » final doit être fait depuis App Store Connect, sauf à utiliser upload_to_app_store avec submit_for_review: true. Mais la 2FA Apple peut interrompre tout pipeline non-interactif si l’app-specific password n’est pas configuré. La pratique courante est d’automatiser jusqu’à TestFlight, puis de promouvoir manuellement à App Store quand on est prêt.

Q : Que se passe-t-il si je perds mon keystore Android ?

R : Si vous utilisez Google Play App Signing (activé par défaut depuis 2021 pour toute nouvelle app), vous pouvez demander à Google de réinitialiser votre clé d’upload. La procédure prend quelques jours et passe par un formulaire de support. Vos utilisateurs ne sont pas impactés, parce que la signature finale qui certifie l’app sur leurs téléphones est gérée par Google. Si en revanche vous avez choisi de gérer vous-même la clé d’app, sa perte rend impossible toute mise à jour future de votre app — vous devez publier sous un nouvel applicationId.

Q : Pourquoi mon app passe la revue technique mais est rejetée pour « metadata »?

R : Les rejets pour métadonnées sont les plus fréquents et les plus rapides à corriger. Les motifs typiques sont : description trompeuse, captures qui ne montrent pas l’app, mots-clés non liés au contenu, mention de plateformes concurrentes, langue de la description ne correspondant pas à la langue de l’app. Corrigez la fiche, soumettez à nouveau pour revue. Pas besoin de rebuilder le binaire.