Flutter 3 — créer une app cross-platform et générer l’APK release

Ce tutoriel installe Flutter 3.41 sur une machine de développement, crée un premier projet, le fait tourner sur un émulateur Android, modifie son interface avec le hot reload, puis génère un APK et un AAB signés pour Google Play. Chaque étape est testée pas-à-pas avec ses commandes exactes, ses sorties attendues et les pièges classiques. À la fin, vous aurez sur votre disque un binaire signé prêt à être uploadé sur la Google Play Console — soit la même chaîne de production que celle utilisée par les apps publiées chaque jour.

📍 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

Ce tutoriel suppose un environnement raisonnablement à jour. Si une de ces conditions n’est pas remplie, l’installation de Flutter va échouer ou aboutir à une chaîne de toolchain bancale.

• Système : Windows 10 / 11 (64 bits), macOS Sequoia 15+ ou Ubuntu 22.04 / 24.04
• Espace disque : 10 Go libres minimum (Flutter SDK + Android SDK + caches)
• RAM : 8 Go minimum, 16 Go recommandés pour faire tourner un émulateur en parallèle de l’IDE
• Git installé et fonctionnel — Flutter est un dépôt Git, pas un installeur classique
• Accès Internet stable pour le téléchargement initial des dépendances Gradle (~2 Go)
• Pour iOS : un Mac avec Xcode 26 et macOS Sequoia 15+. Sur Windows ou Linux, on peut développer pour iOS mais on délègue la compilation à un service cloud — le sujet est traité dans le guide sur la CI/CD mobile.

Niveau attendu : développeur débutant qui sait utiliser un terminal. Aucune connaissance préalable de Dart n’est requise. Temps total : une heure trente à deux heures pour la première installation, dix minutes pour les fois suivantes.

Étape 1 — Installer le SDK Flutter

Flutter ne se télécharge pas sous forme d’installeur Windows ou de package Homebrew. C’est un dépôt Git que vous clonez quelque part sur votre disque, et auquel vous ajoutez le sous-dossier bin/ à votre PATH. Cette philosophie permet de gérer plusieurs versions sur la même machine et de revenir facilement à une version antérieure quand un projet client le demande.

On commence par cloner le canal stable. Sur macOS et Linux, ouvrez un terminal et lancez la commande suivante. Sur Windows, ouvrez PowerShell — pas l’invite de commandes classique — et adaptez le chemin ~/development à un dossier de votre choix, par exemple C:\src\flutter.

cd ~
mkdir development
cd development
git clone https://github.com/flutter/flutter.git -b stable

Le clone télécharge environ 1,5 Go. Une fois terminé, vous avez un dossier flutter/ qui contient le SDK complet. Il reste à exposer la commande flutter à votre shell. Sur macOS et Linux avec zsh ou bash, ajoutez la ligne suivante à votre ~/.zshrc ou ~/.bashrc, puis rechargez le shell.

export PATH="$HOME/development/flutter/bin:$PATH"

Sur Windows, ouvrez « Modifier les variables d’environnement système », éditez la variable Path de votre compte utilisateur, et ajoutez C:\src\flutter\bin. Fermez et rouvrez votre terminal pour que le changement prenne effet. Vous pouvez vérifier l’installation avec flutter --version. La commande doit renvoyer une ligne du type Flutter 3.41.x · channel stable. Si elle dit « command not found », le PATH n’a pas été correctement mis à jour.

Étape 2 — Diagnostiquer l’environnement avec flutter doctor

Une fois Flutter installé, l’étape la plus importante est flutter doctor. Cette commande vérifie tout ce qui est nécessaire pour compiler une app : Dart, Android SDK, Xcode (sur macOS), un émulateur, Chrome pour le développement web, un éditeur compatible. Elle remplace tout un wiki de pages de documentation par un seul rapport actionnable.

flutter doctor -v

La sortie liste chaque dépendance avec une coche verte ✓ ou une croix rouge ✗. La première fois que vous lancez la commande, attendez-vous à plusieurs croix. Les messages explicitent ce qu’il faut faire : « Android licenses not accepted », « Xcode not installed », « Android Studio not found ». Vous traitez chaque ligne dans l’ordre.

Pour l’Android SDK, le plus simple est d’installer Android Studio Panda 4 (le canal stable en 2026) ou tout dérivé plus récent, qui embarque le SDK Android, les outils en ligne de commande (command-line tools) et un gestionnaire d’émulateurs. Une fois Android Studio installé, ouvrez-le, allez dans le SDK Manager (icône de cube dans la barre de bienvenue) et installez la dernière version stable d’Android (API 35, soit Android 15 — c’est l’exigence minimale pour Google Play en 2026). Acceptez les licences avec flutter doctor --android-licenses, qui affiche chaque licence et attend un y pour chacune.

Sur macOS, pour iOS, installez Xcode 26 depuis le Mac App Store. L’installation pèse 12 Go et prend une bonne heure. Une fois installé, lancez Xcode au moins une fois pour qu’il télécharge ses composants additionnels. Puis ouvrez un terminal et exécutez sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer pour pointer la chaîne d’outils Flutter vers le bon Xcode. Acceptez aussi la licence avec sudo xcodebuild -license accept.

Quand flutter doctor ne renvoie plus que des coches vertes, vous êtes prêt. Sur Windows et Linux, il est normal que la ligne Xcode reste rouge — vous ne pourrez pas compiler iOS, mais Android, web et desktop fonctionneront.

Étape 3 — Créer le premier projet

La commande flutter create génère un projet entier en moins d’une minute, avec sa structure de dossiers, ses dépendances Gradle, ses fichiers iOS (sur macOS), et un exemple d’app fonctionnel. C’est l’équivalent du cargo new de Rust ou du npx create-react-app de l’écosystème JS, en plus complet.

cd ~/development
flutter create my_first_app
cd my_first_app

Le nom du projet doit être en snake_case. Si vous tapez MyFirstApp ou my-first-app, la commande refuse — c’est une convention Dart. À l’intérieur, vous trouvez quatre dossiers principaux. Le dossier lib/ contient votre code Dart, avec main.dart comme point d’entrée. android/ contient le projet natif Android (Gradle, AndroidManifest, Kotlin / Java). ios/ contient le projet natif iOS (Xcode workspace, Info.plist, Swift / Objective-C). test/ contient les tests unitaires et d’intégration.

Cette séparation est importante à comprendre. Quand vous écrivez en Flutter, 99 % du temps vous éditez lib/. Les dossiers android/ et ios/ sont touchés uniquement pour la signature, les permissions, les configurations spécifiques aux plateformes et l’intégration de SDK natifs.

Étape 4 — Lancer l’app sur un émulateur Android

Avant de pouvoir lancer l’app, il faut un émulateur ou un téléphone branché en USB. L’émulateur intégré à Android Studio est le plus pratique pour démarrer. Ouvrez Android Studio, créez un AVD (Android Virtual Device) avec un Pixel 7 et l’image système API 35 (Android 15). Cette étape se fait une seule fois ; ensuite, l’émulateur est démarrable depuis la ligne de commande.

flutter emulators
flutter emulators --launch Pixel_7_API_35

La première commande liste les émulateurs configurés ; la deuxième en démarre un. Une fois l’émulateur visible à l’écran, retournez dans votre terminal positionné sur my_first_app/ et lancez l’app.

flutter run

La première compilation prend trois à cinq minutes le temps que Gradle télécharge ses dépendances. Les compilations suivantes prennent entre dix et trente secondes. Quand l’app est prête, l’émulateur affiche un écran intitulé « Flutter Demo Home Page » avec un compteur, un bouton flottant en bas à droite, et un message « You have pushed the button this many times: 0 ». Si vous appuyez sur le bouton, le compteur s’incrémente. Vous tenez votre première app Flutter.

Étape 5 — Modifier le code et observer le hot reload

Le hot reload est l’argument quotidien qui rend Flutter agréable à utiliser. Il prend une modification de votre code Dart et l’applique à l’app en cours d’exécution sans la redémarrer ni perdre son état. Concrètement, vous pouvez naviguer cinq écrans, modifier la couleur d’un bouton, et voir le changement sans repartir de l’écran d’accueil.

Ouvrez lib/main.dart dans VS Code ou Android Studio. Cherchez la ligne qui définit le titre de l’app, autour de la ligne 35.

title: 'Flutter Demo Home Page'

Remplacez par 'Mon premier projet Flutter', sauvegardez avec Ctrl+S, et regardez l’émulateur. Dans le terminal où flutter run tourne, appuyez sur r minuscule pour déclencher le hot reload. L’écran de l’app rafraîchit en moins d’une seconde, et vous voyez le nouveau titre dans la barre. Le compteur, lui, conserve sa valeur — c’est exactement ce que fait le hot reload : il préserve l’état tout en mettant à jour la présentation.

Pour les changements qui touchent à l’état initial ou au main(), le hot reload ne suffit pas. Appuyez sur R majuscule pour un hot restart qui redémarre l’app proprement, en deux à trois secondes. C’est l’une des erreurs classiques du débutant : « le hot reload ne marche pas » alors qu’il faudrait un hot restart.

Étape 6 — Tester sur un téléphone réel

L’émulateur est utile pour tester rapidement, mais il ne reflète pas tout. Les performances réelles, les permissions caméra et géolocalisation, le comportement réseau sur 4G et le rendu visuel d’un écran physique se vérifient seulement sur un téléphone. Heureusement, Flutter rend l’opération triviale.

Sur Android, activez d’abord le mode développeur. Dans Paramètres → À propos du téléphone, tapotez sept fois sur « Numéro de build ». Un message confirme que vous êtes développeur. Retournez dans Paramètres → Système → Options pour les développeurs, et activez « Débogage USB ». Branchez le téléphone à votre ordinateur en USB, autorisez l’ordinateur quand le téléphone le demande, puis vérifiez qu’il est reconnu.

flutter devices

La commande liste tous les périphériques disponibles : votre émulateur en cours, votre téléphone branché, et éventuellement Chrome si vous avez activé le support web. Lancez l’app sur le téléphone avec flutter run -d <device_id> en remplaçant le device_id par celui retourné par flutter devices. L’app se compile, s’installe sur le téléphone et démarre automatiquement.

Étape 7 — Configurer la signature Android

Une app Android non signée ne peut pas être installée hors mode développeur, et encore moins publiée sur Google Play. Avant de générer le binaire de production, il faut créer une upload key, un certificat cryptographique que Google Play utilisera pour vérifier que les futures mises à jour proviennent bien de vous.

Créez un keystore avec l’utilitaire keytool fourni avec le JDK. La commande ci-dessous demande un mot de passe — choisissez-en un solide, vous en aurez besoin à chaque build. Notez-le dans un gestionnaire de mots de passe : la perte de cette clé interdit définitivement la mise à jour de votre app sur Google Play, sauf à demander un reset à Google qui prend plusieurs jours.

keytool -genkey -v -keystore ~/upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -alias upload

L’outil pose six questions (nom, organisation, ville, etc.). Les réponses ne sont pas critiques — elles n’apparaîtront jamais aux utilisateurs. Le fichier généré, upload-keystore.jks, est votre clé. Ne le mettez jamais dans Git. Sauvegardez-le hors de votre dépôt, idéalement dans un coffre-fort de mots de passe ou un stockage chiffré.

Indiquez ensuite à Gradle où trouver cette clé. Créez un fichier android/key.properties à la racine de votre projet — pas dans android/app — avec le contenu suivant. Adaptez les chemins et les mots de passe.

storePassword=VOTRE_MOT_DE_PASSE
keyPassword=VOTRE_MOT_DE_PASSE
keyAlias=upload
storeFile=/Users/votre_user/upload-keystore.jks

Ajoutez ce fichier à votre .gitignore immédiatement, avec echo "android/key.properties" >> .gitignore. Modifiez ensuite android/app/build.gradle.kts (ou build.gradle selon la version de Flutter) pour qu’il lise ces credentials et signe le release. La documentation officielle de Flutter donne le bloc exact à insérer ; copiez-le sans le retaper, les espaces et imports ont leur importance.

Étape 8 — Builder l’APK release

Avec le keystore en place, vous pouvez générer un APK signé en production. C’est un fichier que vous pouvez installer manuellement sur n’importe quel téléphone Android, distribuer à des testeurs par lien, ou héberger sur votre site sans passer par Google Play.

flutter build apk --release

La compilation prend deux à cinq minutes la première fois. À la fin, l’APK se trouve dans build/app/outputs/flutter-apk/app-release.apk. Sa taille typique pour le projet par défaut est de 22 à 28 Mo — gros parce qu’il contient les binaires pour ARM64, ARM32 et x86_64 simultanément. Pour réduire cette taille, utilisez le split-per-abi.

flutter build apk --release --split-per-abi

Cette commande produit trois APK séparés, un par architecture, autour de 8 à 10 Mo chacun. C’est utile pour la distribution hors-store. Vérifiez la taille avec ls -lh build/app/outputs/flutter-apk/. Si vous voyez bien app-armeabi-v7a-release.apk, app-arm64-v8a-release.apk et app-x86_64-release.apk, le split a fonctionné.

Étape 9 — Builder l’AAB pour Google Play

Google Play n’accepte plus d’APK depuis août 2021. Le format requis est l’AAB (Android App Bundle), un format qui contient tout le code et toutes les ressources, et que Google découpe en APK optimisés pour chaque appareil au moment du téléchargement par l’utilisateur. Concrètement, vos utilisateurs téléchargent moins de données et vous publiez un seul artefact.

flutter build appbundle --release

Le binaire final se trouve dans build/app/outputs/bundle/release/app-release.aab. Sa taille tourne autour de 25 Mo — plus gros qu’un APK split, mais c’est attendu : il contient tous les modules. C’est ce fichier que vous uploaderez sur la Google Play Console pour la première soumission. La procédure complète de soumission est détaillée dans le guide dédié au déploiement Play Store et App Store avec fastlane.

Étape 10 — Vérifier le binaire avant de soumettre

Avant de pousser un AAB sur Google Play, faites trois vérifications qui économisent une journée de revue rejetée.

La première est le targetSdkVersion. Ouvrez android/app/build.gradle.kts et cherchez la ligne targetSdk. Elle doit être à 35 ou plus pour toute soumission depuis le 31 août 2025. Flutter 3.41 met cette valeur par défaut, mais une dépendance ou une migration depuis un projet plus ancien peut l’avoir laissée à 34 ou 33. Vérifiez aussi compileSdk qui doit être au même niveau que targetSdk.

La deuxième est le nom et la version de l’app. Dans android/app/build.gradle.kts, vérifiez versionCode (entier, doit être incrémenté à chaque upload) et versionName (chaîne visible aux utilisateurs, du type « 1.0.0 »). Sans ces deux valeurs cohérentes, Google Play refuse le bundle. Pour le premier upload, versionCode = 1 et versionName = "1.0.0" conviennent. Pour les suivants, n’oubliez pas d’incrémenter versionCode à chaque fois — Google Play refuse les uploads avec un code identique ou inférieur au précédent.

La troisième est l’ID d’application. Le champ applicationId dans le même fichier est l’identifiant unique mondial de votre app, du type com.votreentreprise.monapp. Une fois publié, il est figé : vous ne pouvez plus le changer sans publier une « nouvelle » app. Choisissez-le avec soin avant la première soumission.

Une fois ces trois vérifications passées, votre AAB est prêt. Le tutoriel suivant de la série prend le relai et explique comment l’uploader sur la Play Console, gérer les pistes de test, et automatiser la soumission avec fastlane.

Erreurs fréquentes

Tutoriels associés

• React Native avec Expo et EAS — premier projet de bout en bout
• CI/CD pour applications mobile — GitHub Actions et Codemagic
• Déployer une app sur Play Store et App Store avec fastlane

Pour aller plus loin

• 🔝 Retour au guide principal : Développement mobile 2026 : Flutter 3, React Native, Expo, stores
• Documentation officielle Flutter — installation
• Flutter — déploiement Android (signature, AAB)
• Android Developers — gérer les AVD
• Flutter — release notes officielles

FAQ

Q : Pourquoi flutter doctor affiche une croix sur Visual Studio Code ?

R : Parce que l’extension Flutter pour VS Code n’est pas installée. Ouvrez VS Code, allez dans l’onglet Extensions, cherchez « Flutter » (publiée par Dart Code), installez-la. La sous-extension Dart s’installe automatiquement. Relancez flutter doctor et la croix devient une coche verte.

Q : Combien de RAM mon émulateur consomme-t-il vraiment ?

R : Comptez 3 à 4 Go pour un Pixel 7 sous API 35. Sur une machine avec 8 Go totaux, l’émulateur, l’IDE et un navigateur saturent rapidement. Branchez plutôt un téléphone Android réel : il ne consomme rien de la RAM de votre ordinateur, démarre plus vite et reflète mieux les performances finales.

Q : Faut-il apprendre Dart en profondeur avant de commencer ?

R : Non. Le sous-ensemble nécessaire pour les premiers écrans Flutter — variables, fonctions, classes, async/await, listes et maps — s’apprend en deux ou trois heures pour qui connaît déjà JavaScript ou Java. Les sujets avancés (mixins, isolates, extensions) viennent quand on en a besoin, pas avant.

Q : Mon AAB fait 25 Mo, c’est normal ?

R : Oui, pour un projet par défaut. Cette taille inclut le moteur Flutter compilé pour trois architectures CPU. Lorsqu’un utilisateur télécharge votre app depuis Google Play, il ne reçoit que la partie correspondant à son téléphone, soit autour de 8 à 10 Mo réellement transmis. C’est l’avantage de l’App Bundle sur l’APK monolithique.

Q : Puis-je publier l’app sans Google Play, juste avec un APK distribué par lien ?

R : Oui. C’est ce qu’on appelle le sideloading. Hébergez l’APK sur votre serveur, partagez le lien à vos utilisateurs, qui devront autoriser « Sources inconnues » dans les paramètres Android pour l’installer. C’est une option valable pour des apps internes d’entreprise ou des bêtas privées. Pour atteindre le grand public, Google Play reste incontournable.