Comment générer une app Flutter avec VULK

Mis à jour le 17 juillet 2026 — actualisé avec des données vérifiées de la plateforme, le flux actuel de build-preview Flutter et les détails d'export APK/AAB.

Comment génère-t-on une app Flutter avec VULK ?

La réponse complète : écris un prompt qui décrit une app mobile en termes mobiles — écrans, navigation inférieure, gestes — et VULK l'achemine automatiquement vers le pipeline Flutter. Il génère un projet Dart complet en Clean Architecture (modèles, écrans, widgets, services, thème centralisé), gère pour toi les dépendances du pubspec.yaml, compile l'app côté serveur et sert un aperçu interactif dans ton navigateur (un vrai build flutter build web, généralement 20–60 secondes). Quand le rendu te convient, tu exportes un APK ou AAB Android natif directement depuis l'éditeur (plan Builder et supérieurs), ou tu télécharges la source complète et l'exécutes localement avec flutter run.

Flutter est la plateforme n°2 sur VULK avec 5,6 % de tous les projets à stack détectable — derrière seulement les web apps React à 80,5 % — et c'est la plateforme la plus demandée dans les prompts des utilisateurs (381 mentions de demande cumulées, devant les backends Node à 310 et Next.js à 265 ; données de la plateforme VULK, juillet 2026). La demande mobile court devant ce que la plupart des builders IA savent livrer, et c'est exactement pour cela que ce pipeline existe.

Pourquoi le mobile est-il le trou dans les builders de code IA ?

Voici ce qui me frustrait dans l'univers des builders de code IA : tout le monde a oublié que le mobile existe. La plupart des outils — Bolt, v0, Lovable — génèrent exclusivement des web apps. Mais regarde comment les gens utilisent réellement les logiciels en 2026. La majorité des interactions grand public se passe sur téléphone. Si tu construis un produit, tu auras probablement besoin d'une app mobile à un moment donné. Et jusqu'à VULK, aucun outil IA ne pouvait te mener du prompt à un binaire Android installable.

J'ai choisi Flutter comme framework mobile principal pour une raison précise. Flutter compile en code véritablement natif sur iOS et Android à partir d'un unique codebase Dart. Ce n'est pas une web view emballée dans une coquille native. Ce n'est pas un pont JavaScript. L'UI est rendue à 60fps via Skia, et tu accèdes aux APIs propres à chaque plateforme. Google le maintient, l'écosystème est mature et la communauté de développeurs est massive — plus d'un million de développeurs actifs.

La question que je n'arrêtais pas de me poser : pourquoi un builder IA peut-il générer une app React complète depuis un prompt, alors que personne n'avait construit l'équivalent pour Flutter ? La réponse : c'est nettement plus difficile. Flutter a son propre langage (Dart), son propre système de widgets, ses propres patterns d'architecture, ses propres paradigmes de gestion d'état. On ne peut pas juste dire à un modèle de langage « écris du code Flutter » et espérer une sortie de qualité production. Il faut un prompt engineering profond et assumé.

C'est donc ce que j'ai construit.

Comment VULK sait-il que tu veux une app Flutter ?

Tu ne sélectionnes pas Flutter dans un menu déroulant. VULK lit ton prompt et infère la plateforme automatiquement. Si ton prompt décrit une application mobile, le mode de génération Flutter s'active.

Les signaux déclencheurs incluent : « app mobile », « app Android », « app iOS », « Flutter », « app native », « APK », « écrans » (au lieu de « pages »), et les références aux patterns natifs du mobile comme les barres de navigation inférieures, les gestes de swipe, les notifications push ou l'accès à la caméra.

Voici la distinction en pratique :

Ceci déclenche React (web) : « Construis un dashboard de gestion de projets avec une sidebar et des tableaux de données. »

Ceci déclenche Flutter (mobile) : « Construis une app mobile de suivi d'entraînements. Inclus une barre de navigation inférieure avec les écrans Accueil, Historique et Profil. »

Si tu veux forcer Flutter quelle que soit la formulation, inclus « Flutter » ou « app mobile » dans ton prompt. L'explicite gagne toujours sur l'inférence.

À quoi ressemble le code Flutter généré ?

Voici ce que la plupart des gens supposent à tort du code Flutter généré par IA : ils s'attendent à du code brouillon, sans structure, ou truffé d'anti-patterns. La sortie Flutter de VULK suit la Clean Architecture parce que j'ai passé des mois à ingénierer le prompt pour l'imposer.

Une structure de projet générée typique :

lib/
  main.dart                    -- App entry, theme, routes
  models/
    workout.dart               -- Data classes with fromJson/toJson
    exercise.dart
  screens/
    home_screen.dart            -- StatefulWidget per screen
    history_screen.dart
    profile_screen.dart
  widgets/
    exercise_card.dart          -- Reusable components
    workout_summary.dart
  services/
    workout_service.dart        -- Business logic / data layer
  utils/
    constants.dart              -- Colors, spacing, strings
    theme.dart                  -- ThemeData configuration
pubspec.yaml                    -- Dependencies

Les décisions d'architecture sont délibérées :

La gestion d'état évolue avec la complexité. Les apps simples reçoivent setState. Les apps avec un état partagé entre écrans reçoivent Provider ou Riverpod. Si ton prompt mentionne un panier qui persiste entre les écrans, attends-toi à voir Provider apparaître dans les dépendances.

La navigation utilise le Navigator intégré de Flutter avec des routes nommées. La navigation inférieure utilise un Scaffold avec bottomNavigationBar et un IndexedStack pour préserver l'état des écrans lors du changement d'onglet — comme les développeurs Flutter expérimentés la construisent.

Le style est centralisé. Material Design 3 avec un ThemeData personnalisé. Couleurs, typographie et thèmes de composants sont définis dans un seul fichier de thème, pas éparpillés dans les widgets. C'est le pattern qui rend les modifications ultérieures gérables.

Les modèles de données incluent les factory methods fromJson et toJson, prêts pour l'intégration API dès le premier jour.

Comment écrire des prompts qui produisent d'excellentes apps mobiles ?

Les apps mobiles ont des patterns UX fondamentalement différents des web apps. Tes prompts doivent le refléter, et c'est là que la plupart des gens gâchent leurs premiers essais.

Pense en écrans, pas en pages. Les apps mobiles ont des écrans et des piles de navigation. Utiliser une terminologie web comme « pages » et « sidebar » poussera la sortie vers une mise en page de style web qui sonne faux sur mobile.

Précise le pattern de navigation. Onglets inférieurs, menu drawer et barre d'onglets supérieure sont des architectures nettement différentes dans Flutter. Sois explicite : « Navigation inférieure avec quatre onglets » donne à VULK un cadre de navigation clair.

Voici de vrais prompts qui produisent de bons résultats :

App e-commerce :

Construis une app mobile Flutter pour une boutique de sneakers. Navigation inférieure avec les onglets Accueil, Recherche, Panier et Profil. L'Accueil montre une liste horizontale défilante de sneakers en vedette en haut et une grille verticale de tous les produits en dessous. Chaque carte produit montre une image, un nom, un prix et un bouton « Ajouter au panier ». L'écran Panier montre les articles avec des contrôles de quantité et le total du checkout. Utilise un thème noir et blanc avec une couleur d'accent orange.

Ce prompt précise des patterns natifs du mobile : onglets inférieurs, listes à défilement horizontal, grilles, steppers de quantité. VULK génère les widgets appropriés — ListView.builder avec scrollDirection: Axis.horizontal, GridView.builder, BottomNavigationBar.

Tracker de fitness :

Crée une app mobile de fitness avec trois écrans : Dashboard, Enregistrer un Entraînement et Progrès. Le Dashboard montre le nombre de pas hebdomadaire sous forme d'indicateur de progression circulaire, les calories brûlées et les minutes actives. Enregistrer un Entraînement a un formulaire avec un menu déroulant de type d'exercice, un slider de durée et une note d'intensité. Progrès montre un graphique en ligne des entraînements par semaine. Utilise des couleurs vert et gris foncé.

Remarque les éléments d'UI spécifiques au mobile : indicateurs de progression circulaires, sliders, notes en étoiles. Ils correspondent directement à des widgets Flutter.

App de chat :

Construis une app de messagerie en Flutter. Liste de conversations avec avatar, nom, aperçu du dernier message et horodatage. Toucher une conversation ouvre un écran de chat avec des bulles de message (envoyées à droite en bleu, reçues à gauche en gris), champ de texte en bas avec bouton d'envoi. Inclus un floating action button sur la liste des conversations pour démarrer un nouveau chat.

Cela décrit des flux d'interaction (toucher pour ouvrir, FAB pour créer) et un positionnement visuel (bulles à gauche vs à droite) — le genre de détail qui produit une sortie réellement utilisable.

Comment fonctionne l'aperçu Flutter ?

Après la génération, VULK compile ton app Flutter côté serveur et l'affiche dans l'aperçu du navigateur. C'est une vraie compilation flutter build web de ton code Dart — pas une maquette — servie dans l'éditeur. Un build prend généralement 20–60 secondes et se relance après chaque modification. Tu peux toucher les boutons, naviguer entre les écrans, faire défiler les listes et remplir les formulaires.

Chaque itération est une compilation fraîche côté serveur. La mise en page, la navigation et le style de l'aperçu correspondent à l'app, et les fonctionnalités propres à la plateforme comme l'accès caméra, le GPS et les notifications push tournent sur un vrai appareil ou un émulateur.

Les prompts de suivi fonctionnent exactement comme pour les projets React :

Ajoute un splash screen avec le logo de l'app centré sur un fond sombre. Affiche-le 2 secondes avant de naviguer vers l'Accueil.

Les cartes produit ont besoin d'une icône cœur dans le coin supérieur droit pour les favoris. La toucher doit basculer entre cœur au contour et cœur rempli avec une animation d'échelle.

Chaque suivi modifie uniquement les fichiers concernés. Tes écrans, modèles et thème existants restent intacts. Sur l'ensemble de la plateforme, la conversation médiane de construction fait 4 messages — un prompt solide plus quelques raffinements (données de la plateforme VULK, juillet 2026).

Comment les dépendances sont-elles gérées ?

VULK gère le pubspec.yaml pour toi. Quand ton prompt fait référence à une fonctionnalité qui exige un package — graphiques, cache d'images, requêtes HTTP, gestion d'état — VULK ajoute la bonne dépendance, avec des versions épinglées pour que le build côté serveur réussisse.

Packages couramment inclus : provider ou flutter_riverpod pour la gestion d'état, fl_chart pour les graphiques, cached_network_image pour le chargement d'images, google_fonts pour la typographie, intl pour le formatage des dates, shared_preferences pour le stockage local. Si tu veux un package précis, nomme-le dans ton prompt et VULK l'utilisera à la place de son choix par défaut.

Comment passer de l'aperçu à l'APK ou l'AAB ?

Une fois que ton app Flutter te convient dans l'aperçu, tu peux l'exporter en binaire Android natif. L'export compile ton code Dart ahead-of-time en code machine ARM — la même app, mais tournant nativement au lieu de passer par le build web. Clique sur le bouton d'export APK dans la barre d'outils de l'éditeur, attends le build (généralement 30–90 secondes) et télécharge le .apk. L'export AAB est aussi disponible pour la soumission au Google Play. Les deux sont inclus à partir de Builder (19,99 €/mois).

Tu peux aussi télécharger le code source complet en ZIP. Ouvre-le dans Android Studio ou VS Code avec l'extension Flutter, lance flutter pub get, puis flutter run. Le code est à toi — pas de dépendances VULK, pas de packages propriétaires, pas de lock-in. Pour le parcours d'export complet, voir Comment Exporter un APK depuis VULK.

Pourquoi Flutter plutôt que React Native par défaut ?

On me le demande régulièrement. React Native est un excellent framework, et VULK peut aussi générer du code React Native + Expo. Mais Flutter est notre défaut pour le mobile pour deux raisons : le système de widgets est plus prévisible pour la génération par IA (chaque élément d'UI est un widget composable aux propriétés claires), et la sortie est du code natif véritablement compilé, pas un pont JavaScript. Pour des apps générées par IA où tu veux une sortie cohérente et pixel-perfect entre plateformes, l'architecture de Flutter convient mieux.

Les données sont d'accord : sur VULK, les projets Flutter dépassent les projets React Native d'environ 19 contre 1 (5,6 % vs 0,3 % des projets à stack détectable ; données de la plateforme VULK, juillet 2026). Les apps Flutter ont l'aperçu de build en direct et l'export APK/AAB ; la génération React Native produit un projet Expo correct que tu exécutes avec Expo Go.