Créer une application avec l'IA (Claude, ChatGPT) : jusqu'où aller seul ?

Claude et ChatGPT ont rendu banal d’obtenir en quelques soirées une application qui s’ouvre et enregistre des données. La question n’est plus de savoir si l’IA sait écrire une application, mais quand arrêter de le faire seul, surtout sur mobile, où les stores imposent leurs règles. Voici où passe la ligne, la méthode pour l’atteindre, et ce que coûte la suite quand une équipe de développement d’applications mobiles prend le relais.

Peut-on créer une application avec l’IA sans savoir coder ?

Oui, jusqu’au prototype : un fondateur sans compétence technique peut aujourd’hui créer avec Claude ou ChatGPT une application qui fonctionne en démo, de quoi tester une idée ou convaincre un investisseur. Non, seul jusqu’aux stores, dès que l’application gère des comptes, des données personnelles ou de l’argent : là, le code doit être relu, testé et assumé.

Un assistant de code IA est un outil qui écrit, modifie et explique du code à partir d’instructions en français courant, comme Claude, ChatGPT ou Cursor. Il produit vite ce que vous décrivez, mais ne vérifie de lui-même ni la sécurité, ni les règles des stores, ni la tenue en production.

Tout dépend de ce que vous voulez en faire :

La vraie ligne de partage, ce sont les conséquences d’un bug. Un écran mal aligné dans une démo coûte un sourire gêné. Une règle d’accès oubliée dans une application qui stocke des données de santé coûte une fuite, une notification à la CNIL et la confiance de vos premiers clients.

Que savent faire Claude et ChatGPT pour créer une application ?

Ils écrivent vite et correctement tout ce qui se décrit bien : écrans, parcours, formulaires, modèle de données simple, explications d’erreurs, tests, textes de fiche store. Pour un prototype, c’est suffisant. C’est d’ailleurs pourquoi l’IA écrit une grande partie du code chez Krafter aussi, à une différence près : chaque ligne est relue et testée par un associé senior.

Les outils se rangent en trois familles :

• Les assistants conversationnels (ChatGPT, Claude) : pour clarifier l’idée, générer un écran ou comprendre une erreur. Vous assemblez vous-même.
• Les générateurs d’applications (Lovable, Bolt) : quelques phrases donnent une application web hébergée. Le plus rapide pour une démo, le plus opaque pour la suite.
• Les agents de code (Claude Code, Cursor) : ils travaillent dans les fichiers du projet et corrigent leurs erreurs en boucle. Les plus puissants, pour qui sait relire leur travail.

Leur limite commune : l’IA répond à la question posée, et ce que vous ne demandez pas n’existe pas dans le code généré. Suppression de compte, restauration d’un achat, comportement quand le réseau coupe, frontière entre les données de deux utilisateurs : personne ne pense à les demander sans connaître les règles des stores. Le problème d’un fondateur non technique n’est pas la qualité des réponses, c’est la liste des questions qu’il ne sait pas encore poser.

Qu’est-ce qui bloque pour créer une application mobile avec l’IA ?

Tout ce qui se passe hors du code : les comptes développeur, la signature et la compilation iOS, la review des stores, les notifications, le paiement intégré, le serveur, les données personnelles et les obligations qui reviennent chaque année. Aucun de ces sujets n’apparaît dans une démo, et tous arrivent le jour de la publication.

Les comptes développeur et la signature

Publier exige un compte Apple Developer à 99 $ par an et un compte Google Play à 25 $ une fois, idéalement au nom de votre société dès le premier jour. Côté Google, un compte personnel créé après le 13 novembre 2023 doit d’abord mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption avant d’accéder à la production (aide de la Play Console). Aucune IA ne trouve ces douze personnes à votre place.

Apple vise aussi le fondateur seul : une application de santé, de finance ou qui demande des informations sensibles doit être soumise par une entité juridique, et une application issue d’un service de génération par le propriétaire de son contenu, pas par la plateforme (App Review Guidelines, règles 5.1.1 et 4.2.6).

La signature de code est un mécanisme cryptographique qui prouve qu’une application vient bien de son éditeur et n’a pas été modifiée depuis ; aucun store n’accepte un fichier sans elle. Côté iPhone, elle passe par des certificats générés dans le compte Apple, puis par Xcode, l’outil d’Apple qui ne tourne que sur Mac, ou par un service de compilation dans le cloud. L’IA explique ses erreurs mieux qu’elle ne les corrige : elle n’a pas accès à votre compte.

La review des stores

Apple examine chaque application avant publication, selon ces règles mises à jour pour la dernière fois le 8 juin 2026. Cinq d’entre elles piègent les applications générées, parce qu’aucune démo ne les rappelle :

• toute application qui permet de créer un compte doit permettre de le supprimer depuis l’application (règle 5.1.1) ;
• une politique de confidentialité doit être accessible dans l’application et dans la fiche store (règle 5.1.1) ;
• si l’application a des comptes, l’équipe de review doit recevoir un compte de démonstration, et le serveur doit tourner pendant l’examen (règle 2.1) ;
• une application qui n’apporte rien de plus qu’un site web reconditionné peut être refusée (règle 4.2) ;
• une connexion via Google ou un réseau social impose une autre option équivalente, qui limite la collecte au nom et à l’adresse e-mail (règle 4.8).

Sur Melimelo, notre application Flutter d’organisation du foyer, plus de 50 versions sont passées par ce circuit : la review prend en général 1 à 2 jours, le vrai travail est la préparation de chaque version.

Les notifications, le paiement et le serveur

Une notification push est un message envoyé par un serveur vers un téléphone, même application fermée. L’IA écrit le code qui la reçoit ; l’envoi demande un serveur, une clé fournie par Apple, un service équivalent côté Android et la gestion du refus de l’utilisateur.

Pour débloquer un contenu numérique, abonnement ou version premium, Apple impose son achat intégré, hors exceptions régionales (règle 3.1.1) ; pour un bien physique ou un service consommé hors de l’application, c’est l’inverse : achat intégré exclu (règle 3.1.3). Apple prélève une commission réduite à 15 % pour les développeurs sous 1 million de dollars de revenus annuels, via son programme pour les petites entreprises, et Google applique ses propres frais de service. Restaurer un achat, gérer un remboursement, synchroniser l’abonnement avec le serveur : voilà ce qui manque à un paiement généré.

Dès qu’il y a des comptes, il y a un back-end, la partie serveur invisible qui stocke les données, gère l’authentification (la vérification de l’identité de chaque utilisateur) et décide qui a le droit de voir quoi. Les outils d’IA le branchent volontiers sur un service prêt à l’emploi en laissant ces règles trop ouvertes, une faille détaillée dans que faire d’un prototype généré par IA.

Les données personnelles et les obligations annuelles

Chaque store exige une déclaration de ce que l’application collecte, briques tierces comprises : étiquettes de confidentialité chez Apple, section Sécurité des données chez Google. Une IA qui ajoute un outil d’analyse en une ligne ne met pas cette déclaration à jour. Si l’application envoie des données personnelles à un service d’IA tiers, Apple exige de le dire clairement et d’obtenir l’accord explicite de l’utilisateur (règle 5.1.2).

Enfin, Google relève chaque année la version d’Android à cibler, Apple la version d’Xcode exigée, et une application qui ne suit pas ne reçoit plus de mise à jour : en 2026, Android 16 et Xcode 26, comme le détaille l’article sur l’obligation Android 16.

Jusqu’où aller seul avec l’IA, étape par étape ?

Jusqu’au prototype testé par de vrais utilisateurs, et pas un pas de plus. La ligne rouge est la première vraie donnée personnelle, le premier paiement ou la première soumission aux stores. Avant elle, l’IA vous fait gagner des mois. Après elle, chaque semaine passée seul augmente à la fois le risque et le coût de la reprise.

1. Écrivez le problème avant le premier prompt. Une page : pour qui, quelle action principale, quelles règles métier (« une réservation s’annule jusqu’à 24 heures avant »). Elle servira à l’IA, à vos testeurs, puis au studio.
2. Générez un prototype web, pas une application des stores. Ni compte développeur, ni signature, ni review à ce stade.
3. Travaillez avec des données fictives. Aucun vrai nom, aucune carte bancaire : le prototype n’a pas les protections qui vont avec.
4. Confiez-le à une dizaine d’utilisateurs cibles. Observez ce qu’ils font, pas ce qu’ils disent, et corrigez les parcours avec l’IA : c’est là qu’elle brille.
5. Gardez tout à votre nom. Le dépôt Git (l’espace qui stocke le code et son historique), les comptes cloud, le nom de domaine.
6. Arrêtez-vous à la ligne rouge. Premier client qui saisit ses vraies données, premier paiement, première soumission : c’est le moment de faire relire.
7. Faites auditer avant de décider. Un audit de reprise de 1 à 3 jours, soit 700 à 3 300 € HT, dit ce qui se garde du prototype et ce que coûte la version de production. Le rapport vous appartient.

Trois signaux montrent que la ligne est déjà franchie : vous corrigez les corrections de l’IA plus que vous n’avancez, un testeur demande s’il peut payer, ou quelqu’un demande où sont stockées ses données.

Combien coûte la suite après un prototype fait avec l’IA ?

Un MVP mobile se chiffre de 6 000 à 25 000 € HT, publication sur l’App Store et Google Play comprise, et le passage du prototype au MVP prend 6 à 12 semaines. Un prototype bien fait tire le prix vers le bas, parce qu’il a déjà défini les écrans, les parcours et les règles métier.

Le plancher de 6 000 € n’est pas un prix d’appel : il vaut quand le besoin est défini, processus, règles métier et écrans posés. Il tient grâce à un socle open source, FastEdgy, à deux associés seniors qui s’appuient sur l’IA puis relisent chaque ligne, et à l’absence de couche commerciale. Un prototype testé apporte justement cette définition du besoin, ce qui peut rendre le cadrage inutile. Le contenu d’un MVP à chaque palier est détaillé dans notre article sur le prix d’un MVP.

Prenons un scénario type. Un fondateur veut une application de réservation de cours collectifs de sport. En trois semaines de soirées avec Claude, il construit un prototype web : planning, réservation, annulation, rappel. Une dizaine de coachs l’utilisent un mois, puis demandent à payer un abonnement. L’audit de deux jours, soit 1 400 à 2 200 € HT, garde la logique de réservation comme spécification et reconstruit le code en Flutter, une seule base pour iOS et Android. Besoin défini, donc pas de cadrage : 15 000 € HT pour six écrans avec comptes et notifications, plus 6 000 € HT pour l’abonnement intégré, soit 21 000 € HT et dix semaines jusqu’aux stores. Le maintien en conditions coûte ensuite 1 700 à 2 500 € HT par an.

Pour situer votre projet, le simulateur de budget donne une fourchette en 8 questions ; l’offre complète est sur la page développement de MVP.

Quand créer son application seul avec l’IA suffit-il ?

Quand personne ne perd rien si l’application casse : un outil interne pour quelques collègues, une démo pour lever des fonds, un test de la demande avant d’investir. Dans ces trois cas, payer un studio serait une erreur, et nous vous le dirons dès le premier appel.

Une PWA, ou progressive web app, est une application web qui s’installe sur l’écran d’accueil d’un téléphone sans passer par les stores : ni compte développeur, ni review, ni commission. Trottr, notre logiciel de gestion d’interventions terrain, est lui-même une PWA, vendue par abonnement et utilisée notamment par Engie : le format tient en production. Pour un outil interne aux données peu sensibles, une PWA générée avec l’IA suffit, avec des sauvegardes et des accès nominatifs. Si l’outil grandit, la page développement de PWA détaille ce qu’il faut ajouter.

La démo pour lever des fonds n’a ni charge à tenir ni review à passer : elle doit rendre l’idée tangible en dix minutes. Pour tester la demande, une page de présentation et une liste d’attente suffisent.

Le piège n’est pas de partir seul, c’est de rater le jour où l’outil interne devient le logiciel dont dépend l’entreprise. Ce jour-là, une seule question compte : qui répond du code quand il casse ?

Par où commencer cette semaine ?

Ouvrez Claude ou ChatGPT, écrivez votre page de problème, générez un prototype web et montrez-le à une dizaine d’utilisateurs avant de penser aux stores. Si le prototype trouve son public et que l’application doit gérer des comptes, des données ou des paiements, faites-la relire avant la première soumission, pas après le premier incident.

Gardez ce prototype : même si son code ne part pas en production, il documente écrans, parcours et règles mieux qu’un cahier des charges. Pour savoir ce qui s’en garde et pour quel budget, 30 minutes en visio avec un associé suffisent. Montrez-nous votre prototype ou votre idée, y compris si la bonne réponse est de continuer seul encore un mois.