Créer une application mobile avec Claude : oui, et voilà où ça coince Commençons par la réponse, parce qu'elle est oui.
Claude écrit du vrai code d'application mobile. Pas une maquette, pas un site déguisé en application : du code source natif, dans un vrai projet, celui qu'un développeur ouvrirait. Si tu as passé un week-end dessus et que quelque chose tourne sur ton téléphone, tu n'as pas rêvé.
Je m'appelle Noé Calmes, je conçois des applications mobiles pensées pour générer des revenus, j'en ai publié plus de 20 sur l'App Store et Google Play, et j'utilise l'IA tous les jours pour coder. Cet article n'est pas là pour te dire que tu t'es trompé. Il est là pour répondre à la question qui arrive juste après, et à laquelle aucun tutoriel ne répond : pourquoi ça marche sur ton téléphone et pourquoi ça ne part pas sur les stores.
Le oui est même plus large que tu ne crois
Deux choses méritent d'être dites, parce qu'elles sont récentes et que beaucoup de gens les ignorent encore.
D'abord, ça se passe désormais dans l'outil officiel d'Apple. En février 2026, Apple a annoncé l'arrivée du codage agentique dans Xcode, son environnement de développement. Son communiqué cite deux agents en exemple, celui d'Anthropic et celui d'OpenAI, les met exactement sur le même plan et n'en recommande aucun. C'est une intégration technique, pas une caution, et il faut le lire comme ça. Connecter des modèles Claude au chat de Xcode était d'ailleurs déjà possible avant : ce qui a changé, c'est le mode agent, capable d'avancer seul sur un objectif et de vérifier son travail.
Ensuite, l'application de bureau de Claude Code sait maintenant piloter un simulateur d'iPhone. Elle compile ton application, l'installe, la lance, tape dans l'écran et relit le résultat pour vérifier ses propres modifications, pendant que tu regardes. Ce n'est pas de la démo, c'est utilisable.
Donc non, tu n'es pas en train de bricoler dans ton coin avec un outil de seconde zone.
Deux détails qui coûtent du temps si on les ignore
Ce pilotage du simulateur ne marche que sur un Mac, uniquement en local, et surtout uniquement sur des simulateurs : jamais sur un vrai iPhone. Et côté Anthropic, se connecter avec un compte Claude dans Xcode suppose une offre payante, une clé API facturée à l'usage étant l'autre voie possible.
Ce que Claude te rend vraiment
C'est le malentendu numéro un, et il n'a rien d'une faute de ta part.
Ce qui sort, c'est un projet de développement . Du code source, des fichiers, une structure. C'est déjà énorme, et c'est très différent de ce que produisent les générateurs type Lovable ou Base44, qui te rendent une interface web générée, pas du natif. Là, tu as du natif, du vrai. J'ai détaillé cette différence dans Lovable, Base44 et les générateurs d'applications .
Et c'est là que la frontière apparaît, précisément à l'endroit où l'outil s'arrête. Claude pilote un simulateur, jamais un vrai téléphone. Un simulateur ne demande ni signature, ni certificat, ni compte vérifié : c'est un logiciel qui tourne sur ton Mac. Le jour où tu veux sortir de cette bulle, tout ce qui suit t'attend d'un coup.
Un projet de développement n'est pas une application publiable. Entre les deux, il y a une chaîne d'étapes qui n'a rien à voir avec le code, que personne ne t'annonce, et qui n'est pas technique : elle est administrative, contractuelle et fiscale.
La bonne nouvelle d'abord
Ce que tu as construit n'est pas perdu. Le code est un point de départ réel, et surtout tu as appris quelque chose sur ton produit que personne n'aurait pu t'apprendre à ta place. Ce qui te bloque maintenant n'est pas dans ton code.
Le ticket d'entrée, avant même la première ligne utile
Pour compiler et signer une application iOS, il faut Xcode. Xcode ne tourne que sur macOS. Pas de Mac, pas de build iOS, et aucun assistant au monde ne contourne ça.
Ensuite viennent les comptes : 99 dollars par an chez Apple, 25 dollars une seule fois chez Google. Ce n'est pas le montant qui pose problème, c'est que ces comptes ne s'achètent pas comme un abonnement en ligne. Ils demandent une vérification d'identité, et cette vérification prend le temps qu'elle prend.
C'est le premier délai que tu ne contrôles pas. Et c'est le seul de toute la chaîne qui ne dépend ni de toi, ni de ton code, ni de ton budget.
Le piège des sept jours
Voilà le mur invisible le plus fréquent, et celui qui donne la fausse impression d'avoir terminé.
Avec un compte Apple gratuit, tu peux installer ton application sur ton propre iPhone. Elle s'ouvre, elle fonctionne, tu la montres autour de toi. Sauf qu'un compte gratuit délivre des autorisations temporaires : au bout de sept jours, l'application refuse de s'ouvrir. Il faut la réinstaller depuis un Mac. À chaque fois.
Pourquoi c'est traître
Ça ne ressemble pas à un blocage, ça ressemble à un bug. Beaucoup de gens passent des jours à chercher ce qui cloche dans leur code alors qu'il n'y a rien à corriger : c'est le compte qui est gratuit. Et tant qu'il l'est, ni TestFlight ni l'App Store ne sont accessibles, donc tu ne peux même pas faire tester ton application à dix personnes.
Ce que Claude ne peut pas signer à ta place
C'est le cœur du sujet, et la partie dont personne ne parle en français.
Publier une application, ce n'est pas déposer un fichier. C'est engager une identité . Trois chaînes séparées, chacune avec ses délais.
L'identité. Tu publies soit en ton nom propre, soit au nom d'une société. En société, Apple demande un identifiant d'entreprise rattaché à une entité juridique réelle, et le vérifie. Un nom commercial ou une enseigne ne suffit pas. En nom propre, c'est ton nom légal qui apparaît sur la fiche.Le statut de vendeur. Dès que tu vends, en Europe, tu dois te déclarer vendeur professionnel et fournir des coordonnées de contact qui deviennent visibles du public. Une adresse professionnelle ou de domiciliation convient, tu n'es pas obligé d'afficher ton domicile, mais tu dois en avoir une.L'encaissement. Avant qu'un seul euro puisse te revenir, il faut accepter le contrat des applications payantes, remplir des formulaires fiscaux et renseigner des coordonnées bancaires validées. Tant que cette chaîne n'est pas complète, tu peux publier une application gratuite, mais tu ne peux rien vendre.
Aucune de ces trois étapes ne se code. Claude peut t'expliquer chacune, il ne peut en franchir aucune. Ce n'est pas une limite technique, c'est une limite de nature : ces étapes engagent une personne ou une société, et il n'y a personne derrière un assistant.
0 €
c'est ce que rapporte une application parfaitement fonctionnelle tant que la chaîne d'encaissement n'est pas ouverte. Le code n'y change rien.
La revue, puis l'entretien à vie
Une fois soumise, ton application est relue par un humain chez Apple. Les refus sont courants, y compris pour des équipes expérimentées, et la plupart se corrigent puis repassent. Ce n'est donc pas un mur, mais c'est un aller-retour, et il faut savoir lire ce qu'on te reproche pour le corriger.
Ensuite vient ce que presque personne n'anticipe : une application publiée n'est pas finie. Les stores imposent régulièrement de recompiler avec des versions plus récentes de leurs outils, sous peine de ne plus pouvoir publier de mise à jour. Ce n'est pas théorique : côté Google, les nouvelles applications et les mises à jour doivent depuis fin août 2026 viser Android 16, et si tu as besoin de temps tu peux demander un délai, jusqu'au 1er novembre 2026 seulement. Une application que personne ne tient devient donc injoignable toute seule, sans qu'une ligne de code ait bougé. C'est le sujet de faire évoluer une application mobile .
Alors, Claude oui ou non ?
Oui, et sans réserve, pour ce qu'il fait bien : écrire du code, aller vite, te faire passer de l'idée à quelque chose de tangible sans dépenser un euro de développement.
Ce qu'il ne fait pas, ce n'est pas du code non plus. C'est décider ce qui sera payant, à quel moment l'offre apparaît, et pourquoi quelqu'un reviendrait demain. Je développe ce point dans créer une application avec l'IA .
La bonne façon de voir les choses : Claude t'emmène jusqu'à la porte des stores, très vite et très loin. Il ne la franchit pas avec toi.
Par où commencer si tu es déjà bloqué
Dans cet ordre précis, parce qu'il est fait pour que les délais tournent pendant que tu travailles.
Décide qui publie, aujourd'hui. Nom propre ou société. Ça conditionne tout le reste et ça se décide en dix minutes.Ouvre les comptes développeur immédiatement. C'est le seul délai que tu ne peux pas raccourcir, alors lance-le en premier et code pendant qu'il court.Règle la chaîne d'encaissement avant de construire l'écran d'abonnement. Contrat, informations fiscales, banque. Construire le paywall avant d'avoir le droit d'encaisser, c'est travailler dans le vide.Prépare la soumission en dernier. Fiche, captures, politique de confidentialité, gestion des données. Là seulement.
Et si tu as déjà du code qui tourne et que tu veux savoir ce qui est récupérable : envoie-le moi. Je regarde et je te dis franchement ce qui tient, ce qui est à reprendre, et ce qui te sépare vraiment du premier euro encaissé.
À lire aussi :
← Retour au blog Accueil · Concevoir une application qui rapporte · Ma méthode · Blog · Tester ton idée · FAQ