Puis-je créer une application mobile avec l’IA sans savoir coder ?

Vous pouvez en créer une simple : un agent de code peut écrire les écrans, les données et la connexion avec React Native et Expo. Il vous faut quand même lire les erreurs, tester sur un téléphone et gérer vous-même les étapes des stores, ce qui demande des bases du terminal plutôt qu’une expérience de programmation.

Flutter ou React Native : lequel choisir pour créer une application avec l’IA ?

Si vous débutez, React Native avec Expo est plus simple : Expo Go affiche instantanément chaque changement sur votre téléphone, et JavaScript et TypeScript sont les langages que les agents de code connaissent le mieux. Flutter est aussi un bon choix, surtout si vous connaissez déjà Dart.

Puis-je publier sur l’App Store une application créée avec l’IA ?

Oui. Apple et Google jugent l’application, pas la personne qui a tapé le code. Il vous faut une adhésion payante à l’Apple Developer Program, une politique de confidentialité, des captures d’écran et une application assez solide pour passer la validation.

Quel est le backend le plus simple pour une application mobile ?

Un backend hébergé comme Supabase ou Firebase est bien plus simple que d’écrire votre propre serveur. Tous deux offrent d’emblée authentification, base de données et stockage de fichiers ; l’essentiel est de ne pas laisser les règles de sécurité ouvertes (RLS dans Supabase, règles de sécurité dans Firebase).

Pourquoi les agents IA peinent-ils avec les erreurs de build natif ?

Parce que ces erreurs viennent de l’environnement, pas du code : Xcode, le SDK Android, CocoaPods, les versions de Gradle et les certificats de signature. L’agent ne voit pas votre machine ; donnez-lui la sortie d’erreur complète et utilisez un build cloud comme EAS Build pour garder l’environnement stable.

Créer une application mobile avec l’IA : d’Expo aux stores

Pour créer une application mobile avec l’IA, le plus rapide est de demander à un agent de code de mettre en place un projet React Native avec Expo, d’essayer chaque changement sur votre propre téléphone avec Expo Go et d’utiliser un backend hébergé comme Supabase ou Firebase. L’agent écrit les écrans, la couche de données et la connexion ; vous testez sur l’appareil, renvoyez les erreurs et gérez les étapes des stores. La publication exige toujours des comptes développeur Apple et Google, ainsi que leurs processus de validation.

Cet article suit tout le chemin, du dossier vide aux stores : la stack que je choisis et pourquoi, le premier prompt que je donne à l’agent, ma façon de tester sur un téléphone, l’authentification et les notifications, la publication, et les endroits où les agents trébuchent le plus.

Fixer les attentes d’abord

Faire du vibe coding pour un site web et pour une application mobile n’a rien d’équivalent. Sur le web, si le code tourne, c’est fini. Sur mobile, il y a une couche de plateforme au-dessus du code : outils de build, certificats de signature, permissions, règles des stores. L’agent gère confortablement l’essentiel du code ; la partie plateforme demande vos yeux et vos mains.

La bonne nouvelle : avec les bons outils, vous n’aurez presque pas à toucher cette couche pendant les premières semaines.

Quelle stack : Expo, Flutter ou natif

Il y a trois grandes voies.

Option	Langage	Pourquoi la choisir	Points d’attention
React Native + Expo	TypeScript	Test instantané sur l’appareil avec Expo Go, builds cloud, le langage que les agents connaissent le mieux	Les bibliothèques natives personnalisées ne tournent pas dans Expo Go ; il faut un development build
Flutter	Dart	Une seule base de code, rendu homogène, outillage solide	Moins d’exemples Dart dont les agents peuvent s’inspirer ; tester sur l’appareil demande une chaîne d’outils locale
Natif (Swift / Kotlin)	Swift, Kotlin	Accès complet à la plateforme, meilleures performances	Deux applications distinctes, Xcode et Android Studio requis

Pour un débutant, ma réponse est claire : React Native + Expo. La raison tient moins au mérite technique qu’à la vitesse du retour. L’agent change quelque chose et vous le voyez sur votre téléphone quelques secondes plus tard. Plus cette boucle est courte, mieux le vibe coding fonctionne.

Flutter est un bon choix si vous connaissez Dart ou si votre équipe l’utilise déjà. Le natif n’a de sens que pour une raison précise, comme le traitement de la caméra, des graphismes lourds ou une intégration poussée à la plateforme.

Étape 1 : mise en place

Ce qu’il vous faut :

Node.js (une version LTS) et un gestionnaire de paquets
Un agent de code : Claude Code, Codex, Gemini CLI ou un autre agent de code
Expo Go sur votre téléphone, depuis l’App Store ou Google Play
Git, pour pouvoir annuler chaque étape de l’agent

Créez le projet vous-même. Quand les agents créent la base de zéro, ils choisissent parfois des modèles obsolètes :

npx create-expo-app@latest habits
cd habits
git init && git add -A && git commit -m "initial scaffold"
npx expo start

Un QR code apparaît dans le terminal. Scannez-le avec l’appareil photo sur iPhone, ou depuis Expo Go sur Android, et l’application s’ouvre sur votre téléphone. Votre ordinateur et votre téléphone doivent être sur le même Wi‑Fi. Si le réseau gêne, essayez npx expo start --tunnel.

Étape 2 : le premier prompt

Le premier prompt façonne chaque décision que l’agent prendra ensuite. Laissez des trous, et il les comblera avec ses propres préférences. J’écris quelque chose comme ceci :

This is an Expo (React Native, TypeScript) project. We're building a
simple habit tracker.

Screens:
1. Today: list of habits, each with a "done" button
2. Add: create a habit with a name and a daily goal
3. History: calendar view of the last 30 days

Rules:
- Use expo-router for navigation and follow the existing app/ folder.
- Keep data on the device for now (AsyncStorage). Backend comes later.
- Add packages with npx expo install, not npm install.
- Don't add native packages that don't run in Expo Go; ask first.
- Run npx tsc --noEmit after each step and fix the errors.
- When done, list the files you changed.

Deux lignes comptent le plus. npx expo install choisit la version du paquet compatible avec votre SDK Expo, et les agents l’oublient tout le temps. La règle « pas de paquets qui ne tournent pas dans Expo Go » vous tient à l’écart des builds natifs tant que vous n’en avez pas vraiment besoin.

Étape 3 : tester sur le téléphone et itérer

Tant que npx expo start tourne, l’application se recharge sur votre téléphone à mesure que l’agent modifie les fichiers. La boucle :

Essayez sur le téléphone et notez ce qui ne va pas.
Dites-le précisément à l’agent : « Sur l’écran Add, le clavier couvre le bouton d’enregistrement, sur iPhone. »
Si l’écran d’erreur rouge apparaît, copiez le texte tel quel dans l’agent. Une capture d’écran marche aussi ; la plupart des agents savent lire les images.
Faites un commit après chaque étape qui fonctionne.

Testez à la fois sur iOS et sur Android. Le même code se comporte différemment : marges de zone sûre, gestion du clavier, bouton retour, ombres. Avec un seul téléphone, utilisez un émulateur Android ou (sur Mac) le simulateur iOS pour l’autre plateforme.

Étape 4 : backend avec Supabase ou Firebase

Dès que vous voulez des données partagées entre appareils et des comptes utilisateur, il vous faut un backend. N’écrivez pas votre propre serveur ; choisissez un service hébergé :

Supabase : construit sur PostgreSQL. Base de données, authentification, stockage de fichiers et mises à jour en temps réel. Un bon choix si vous connaissez SQL ou voulez l’apprendre.
Firebase : la plateforme de Google. Base de documents Firestore, authentification, messagerie. Très intégrée à l’écosystème mobile.

Faites construire le tout couche par couche par l’agent, pas d’un coup :

We're moving to Supabase. For now, only do this:
1. Write a SQL file under supabase/migrations that creates habits and
   completions tables. Every row has a user_id.
2. Enable Row Level Security on both tables so a user can only read
   and write their own rows.
3. Don't change the app code yet. Show me the SQL; I'll apply it.

Ne sautez pas la partie RLS. La clé Supabase livrée dans une application mobile est publique par conception ; ce qui protège vos données, ce sont les règles dans la base, pas le secret de cette clé. Dans Firebase, ce sont les règles de sécurité qui jouent ce rôle.

Étape 5 : authentification

La connexion par e-mail est la plus simple ; Supabase et Firebase la proposent tous deux. Sign in with Google et Sign in with Apple demandent plus de configuration : URI de redirection, schéma d’application et enregistrement dans la console de chaque plateforme.

À savoir : selon les règles de l’App Store, si votre application propose une connexion sociale tierce, Apple peut aussi attendre Sign in with Apple ou une option équivalente respectueuse de la vie privée, avec quelques exceptions. Vérifiez les règles en vigueur avant de soumettre.

Voici comment je demande l’authentification :

Add email + password sign-in with Supabase Auth.
- If there's no session, redirect to the sign-in screen.
- Store the session with expo-secure-store.
- Put a sign-out button on the Settings screen.
- Error messages should be clear and in plain English.
Don't add Google or Apple sign-in yet.

Étape 6 : notifications push

Les notifications push prennent plus de temps que tout le reste sur mobile. Dans Expo, on commence par expo-notifications :

npx expo install expo-notifications expo-device

Ce qu’il faut savoir :

Les notifications locales (« rappelle-moi chaque soir à 21 h ») n’exigent aucun serveur et sont de loin les plus simples. Pour un suivi d’habitudes, elles suffisent souvent.
Le push distant signifie obtenir un token push, le stocker sur votre serveur et envoyer depuis là. Sur iOS, il faut un compte Apple Developer et la capacité push.
Testez le comportement des notifications sur un vrai appareil. La prise en charge des notifications dans le simulateur et dans Expo Go peut être limitée et évolue avec le temps.

Demandez d’abord des notifications locales à l’agent, vérifiez qu’elles fonctionnent, puis passez au push distant.

Étape 7 : builds et stores

Expo Go sert au développement ; les stores reçoivent un vrai binaire d’application. Le service cloud d’Expo, EAS, le construit pour vous :

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android
eas build --platform ios

Le grand avantage des builds cloud est de ne pas avoir à installer vous-même Xcode et le SDK Android. Vous pouvez même produire le build iOS sans Mac.

Apple :

Une adhésion annuelle payante à l’Apple Developer Program.
Une fiche d’application dans App Store Connect avec captures d’écran, description, URL de la politique de confidentialité et la déclaration de données App Privacy.
Distribuez d’abord via TestFlight à vous-même et à quelques testeurs, puis soumettez à la validation.
Les refus sont normaux. Motifs courants : plantages, texte de confidentialité manquant, applications « enveloppe de site web » trop minces, et applications qui permettent de créer un compte mais pas de le supprimer.

Google :

Une inscription payante, unique, à la Google Play Console, plus une vérification d’identité.
Une fiche de store, le questionnaire de classification du contenu et le formulaire Data safety.
Les nouveaux comptes développeur personnels peuvent devoir mener un test fermé avec un certain nombre de testeurs pendant une durée donnée avant la production ; vérifiez la règle en vigueur dans la console.

eas submit facilite l’envoi des builds vers les deux stores, mais les formulaires des stores, c’est vous qui les remplissez. Lisez-les plutôt que de les déléguer à l’agent ; déclarer les données que collecte votre application relève de votre responsabilité.

Où les agents peinent

Voici la liste des endroits où j’ai perdu le plus de temps en faisant du vibe coding mobile.

Erreurs de build natif

Gradle, CocoaPods, versions de Xcode, niveaux du SDK Android. Ces erreurs sont longues, bruyantes et propres à l’environnement. L’agent ne voit pas le Xcode de votre machine ; il devine. Ce qui aide :

Collez toute la sortie d’erreur, pas seulement les premières lignes. La vraie cause se trouve souvent vers le bas ou noyée au milieu.
Utilisez EAS Build quand c’est possible ; l’environnement reste stable.
Ne laissez pas l’agent modifier à la main les dossiers ios/ et android/. Dans Expo, ils sont généralement générés depuis la configuration, donc les changements durables vont dans app.json ou un config plugin.

Signature et certificats

Certificats, profils de provisionnement et identifiants de bundle sur iOS ; un keystore sur Android. Les agents peuvent donner ici des instructions assurées mais fausses. Laisser EAS gérer les identifiants est le chemin le plus fluide. Si vous perdez votre clé d’envoi Android, publier des mises à jour de la même application devient un vrai casse-tête : sauvegardez-la.

Versions incompatibles

L’agent utilise une API de paquet datant de son entraînement ; votre projet peut avoir une autre version. npx expo install --check liste les paquets incompatibles. Dire à l’agent « vérifie d’abord la version dans package.json, puis écris selon la documentation de cette version » aide.

Tester sur une seule plateforme

L’agent écrit une mise en page qui marche sur iOS et déborde sur Android. Vérifiez chaque fonctionnalité sur les deux.

Tout demander d’un coup

« Ajoute l’authentification, les notifications et les paiements » laisse les trois à moitié faits. Une fonctionnalité à la fois, avec un commit entre les deux.

La sécurité compte encore plus sur mobile

Tout ce que vous mettez dans une application mobile finit sur l’appareil de l’utilisateur, où il peut être extrait et lu. Donc :

Ne mettez jamais de secrets dans le bundle de l’application. Dans Expo, les variables d’environnement qui commencent par EXPO_PUBLIC_ sont intégrées au bundle, donc publiques. La clé service_role de Supabase, la clé secrète d’un prestataire de paiement ou une clé d’API d’IA ne doivent jamais être livrées dans l’application ; leur place est côté serveur, par exemple dans une edge function.
Gardez les secrets dans un fichier .env et vérifiez que .env est dans .gitignore.
Ne collez pas de clés d’API dans le chat. Dites à l’agent quelle variable d’environnement lire, pas la clé elle-même.
Testez les règles de votre base. Connectez-vous avec un second compte et vérifiez si vous pouvez lire les données du premier.
Lisez les commandes que l’agent exécute, surtout eas, git push, les suppressions et les commandes de base de données, avant de les approuver.

Le faire avec AgentVera

Tout ce qui précède se fait dans un simple terminal. Sur les projets mobiles, j’aime faire tourner plusieurs agents côte à côte, et je le fais dans AgentVera :

Des agents séparés dans des worktrees séparés. Par exemple, Claude Code travaille sur le schéma Supabase et les edge functions dans un worktree git pendant que Codex construit les écrans dans un autre. Le panneau Git montre les changements de chaque branche.
Un terminal dans la grille. npx expo start reste ouvert dans un volet pour voir la sortie de Metro à côté des agents ; c’est à cela que sert le panneau éditeur et terminal.
Relire avant de fusionner. La revue de code automatique fait vérifier chaque tour d’agent par un second modèle ; vous devez quand même lire le diff vous-même.
La base de données. Ajoutez la connexion Postgres de Supabase au gestionnaire de bases de données pour vérifier les tables et lignes créées par l’agent.
Suivi des jetons. Les longs journaux de build gonflent vite le contexte ; l’utilisation des tokens est visible par volet.

AgentVera ne construit pas pour votre téléphone et ne soumet pas aux stores ; cette partie reste du ressort d’Expo et des consoles des stores.

Liste de contrôle rapide

Projet Expo créé par vous, premier commit dans git
Le premier prompt liste les écrans, les règles et l’exigence npx expo install
Chaque fonctionnalité testée sur un téléphone, sur les deux plateformes
RLS dans Supabase ou règles de sécurité dans Firebase activées et testées
Aucune clé secrète dans le bundle de l’application
Keystore Android sauvegardé
Politique de confidentialité et déclarations de données des stores prêtes

Pour conclure

Créer une application mobile avec l’IA est désormais un objectif réaliste, mais cela ne s’arrête pas à « écris-moi une application ». Commencez avec Expo, regardez chaque changement sur votre téléphone avec Expo Go, utilisez un backend hébergé, ajoutez les fonctionnalités une par une et prenez en main vous-même les étapes de plateforme : signature, formulaires des stores, validation. Pour vérifier ce que l’agent a écrit, lisez la revue de code par IA ; pour faire tourner des agents en parallèle, voyez les worktrees git pour agents parallèles.