La checklist de production qui fait échouer les apps créées par IA (7 choses qui cassent après la démo)

Vous avez construit une app avec un app builder IA, ou vous l'avez vibe-codée prompt après prompt en quelques soirées. Elle fonctionne. Mais regardez les conditions dans lesquelles elle fonctionne : votre téléphone, votre Wi-Fi, votre compte, des données que vous avez saisies vous-même, un build généré il y a une heure. Une démo, c'est une app testée exclusivement en conditions amicales.

Prête pour la production signifie exactement l'inverse : l'app continue de fonctionner une fois les conditions amicales disparues. Des inconnus à votre place, la validation des stores au lieu d'un public conquis, des mois au lieu d'un après-midi.

Nous avons déjà écrit sur l'origine de cet écart : notre article sur les sept murs entre un prototype et les stores cartographie la distance structurelle, et notre papier sur la différence entre créer une app et la faire tourner nomme le travail qui commence après le lancement. Ces articles se terminent sur des questions qui méritent d'être posées. Celui-ci transforme les questions en expériences : sept tests, chacun avec une procédure concrète et une condition de réussite indiscutable, tous réalisables cette semaine. Si un test vous paraît ingrat, c'est exactement le but. La production, c'est là que vivent les bugs ingrats.

1. Un inconnu peut créer un compte, partir et revenir

La démo ne se déconnecte jamais. Vous avez construit l'app déjà authentifié, sur un appareil qui vous reconnaît, si bien que toute la machinerie des comptes n'a jamais été mise à l'épreuve : l'email de confirmation qui atterrit dans les spams, la réinitialisation de mot de passe qui n'arrive jamais, la session qui meurt à chaque redémarrage, le compte qui existe sur votre téléphone et nulle part ailleurs. Les comptes sont la première chose qu'un inconnu touche et la dernière chose qu'une démo teste.

Le test : sur un appareil qui n'a jamais vu votre app (le téléphone d'un proche fait l'affaire ; pour une web app, une fenêtre de navigation privée), créez un compte avec une adresse email à vous, mais jamais utilisée avec l'app. Confirmez-le. Déconnectez-vous. Réinitialisez le mot de passe. Reconnectez-vous. Fermez l'app et revenez le lendemain.

Validé quand : chaque étape fonctionne sans que vous touchiez à un dashboard, renvoyiez quoi que ce soit à la main ou expliquiez un contournement.

2. L'app survit au vide, au hors-ligne et au double appui

Votre démo tourne sur des données que vous avez saisies, avec une bonne connexion, pilotée par la seule personne qui sait où ne pas cliquer. Un vrai utilisateur démarre sans rien de tout cela : un compte tout neuf ne voit aucun contenu, le métro coupe la connexion en pleine action, et un pouce impatient appuie deux fois sur le bouton de paiement. Ce sont les états ingrats, et les apps générées ont tendance à ne pas les gérer, parce que personne ne les a demandés dans un prompt. Apple tombe dessus avant vos utilisateurs : d'après l'expérience de notre équipe de publication, une app est couramment ouverte hors connexion pendant la validation, et ce qu'elle affiche sans réseau compte.

Le test : faites une installation propre de l'app, ou ouvrez-la dans une fenêtre privée, et utilisez-la en mode avion ; coupez aussi la connexion en pleine action. Puis parcourez chaque écran avec un compte neuf qui n'a aucune donnée. Puis appuyez deux fois, vite, sur chaque bouton qui crée ou paie quelque chose. Gardez le volet paiement dans le mode test de votre prestataire, ou utilisez un article bon marché que vous remboursez juste après : ce que vous cherchez, c'est de savoir si deux commandes apparaissent, pas si de l'argent a circulé.

Validé quand : aucun écran blanc, aucun spinner infini, aucun crash, et aucune commande en double.

3. L'App Store et Google Play l'accepteront

C'est ici que ce que produit votre builder rencontre le monde extérieur. Les stores veulent des binaires natifs signés, des comptes développeur (99 USD par an chez Apple, 25 USD en une seule fois chez Google), des métadonnées de store et des déclarations de confidentialité qui n'existaient pas il y a quelques années : la section Data safety de Google Play est obligatoire depuis juillet 2022, les manifestes de confidentialité d'Apple depuis mai 2024. Beaucoup d'outils prompt-to-app génèrent des applications web, parce qu'une web app est ce qu'un prompt peut déployer en une étape, si bien que ce mur a tendance à arriver tard. Une web app est une surface légitime (GoodBarber livre une Progressive Web App à côté du natif), mais elle renonce à la distribution des stores et, pour la plupart des utilisateurs iOS, au push. Puis vient la validation : parmi les premières soumissions traitées par notre équipe de publication sur les douze mois jusqu'à avril 2026, environ 42 % sont revenues rejetées par Apple, et c'est la norme pour une équipe préparée, pas une pénalité pour débutants.

Le test : trois questions, dont les réponses doivent être des noms, pas des suppositions. Votre outil peut-il produire des binaires iOS et Android signés ? Avez-vous des comptes développeur Apple et Google ? Pouvez-vous dire, aujourd'hui, quelles données l'app collecte, où elles sont stockées et quels services tiers y touchent ?

Validé quand : trois oui, par écrit, avant de fixer une date de lancement.

4. Un push programmé ce soir est sur l'écran verrouillé demain matin

Le push est la raison pour laquelle une app bat un site web en rétention, et c'est aussi la fonctionnalité qu'une démo simule le mieux : tout a l'air branché jusqu'au premier téléphone verrouillé. La livraison est binaire, et c'est pourquoi ce test est une expérience d'une nuit plutôt qu'une question. Depuis iOS 16.4 (mars 2023), iOS ne livre le web push qu'aux web apps que l'utilisateur a délibérément ajoutées à son écran d'accueil ; dans le navigateur, rien ne sonne. Une web app générée par IA peut donc être identique à une app native sur votre écran, et devenir muette à l'instant où le téléphone se verrouille. Si vous ne trouvez même pas où, dans votre outil, se programme une notification push, vous avez déjà votre réponse : le test est raté.

Le test : programmez une notification push vers votre propre téléphone pour demain 7 h 00, et verrouillez le téléphone ce soir.

Validé quand : le message est posé sur l'écran verrouillé à votre réveil.

5. Vous savez nommer chaque service dont l'app dépend, et chaque facture

Une app générée est une app assemblée. Sous la démo repose une stack que le prompt a choisie pour vous : l'hébergement ici, une base de données là, un service d'envoi d'emails, du stockage d'images, des statistiques, peut-être un prestataire de paiement. Chacun a un identifiant, une offre gratuite qui se termine, des clés qui expirent et une facture qui grimpe sur sa propre courbe. La démo cache tout cela, parce que pour un utilisateur sur un après-midi, tout est gratuit et rien n'a encore cassé. La production pose une question plus dure : quand l'app est en panne à 2 h du matin, lequel de ces services vérifiez-vous en premier, et qui répond ?

Le test : dressez l'inventaire, en commençant là où un non-développeur peut réellement commencer : cherchez dans votre boîte mail tous les messages « Welcome to » et « Verify your email » reçus pendant la construction, ajoutez chaque identifiant créé en chemin, chaque prélèvement récurrent sur votre relevé de carte, et tout ce que listent les pages intégrations et facturation de votre builder. Pour chaque ligne : qui possède le compte, ce qu'il coûte à 1 000 utilisateurs, et s'il se renouvelle en silence.

Validé quand : chaque ligne a un propriétaire et un prix. Si dresser la liste vous a surpris, la surprise est déjà un résultat.

Cet inventaire vous resservira plus loin. Les services qui y figurent sont aussi ceux qu'il faudrait remplacer pour changer de builder un jour, et c'est là que se loge la vraie dépendance : nous avons creusé la question dans posséder son app, ce n'est pas encore pouvoir la quitter.

6. Un changement part en ligne sans entraîner le reste

La première mise à jour est le test le plus dur qu'affronte une app créée par IA, parce que deux horloges se mettent en marche au lancement. La première est la vôtre : les utilisateurs trouvent des bugs, et les corriger par prompt peut réécrire en silence des parties qui fonctionnaient, ce que nous appelons le regeneration drift (la dérive de régénération). Sur une base de code générée, même changer un simple libellé suit une boucle bien particulière : modifiez le libellé, régénérez, puis découvrez lesquels des écrans que vous n'avez pas touchés ont changé quand même. La seconde horloge appartient à Apple et Google : chacun livre un OS majeur chaque année, Google relève chaque année la version minimale d'Android qu'une app doit cibler, et Apple retire les apps restées trois ans sans mise à jour avec quasiment aucun téléchargement, après un préavis de 90 jours. Une app que vous ne pouvez pas modifier sans risque est une app que vous ne pouvez pas garder publiée ; nous avons raconté ce qui casse en silence quand une app cesse d'être mise à jour pour la version au ralenti.

Le test : changez un détail visible (un libellé, un prix, une couleur) et livrez-le : en mise à jour sur les stores si vous êtes en ligne, en régénérant et redéployant sinon. Puis vérifiez que trois choses qui marchaient avant marchent toujours.

Validé quand : le changement est parti, les trois parcours retestés fonctionnent toujours, et la boucle entière a pris un après-midi, pas une semaine.

7. Quelqu'un peut faire tourner l'app sans rouvrir le builder

Dans six mois, ce dont l'app aura besoin relève de l'exploitation, pas de la génération : publier l'article de la semaine, changer un prix, répondre à un client, envoyer le push promo, lire les chiffres. Si chacune de ces tâches signifie rouvrir l'outil qui a généré l'app et re-prompter prudemment autour de ce qui ne doit pas casser, l'app a un point de défaillance unique : vous, dans le builder, pour toujours. Une app est exploitable quand ses tâches quotidiennes vivent dans une interface faite pour elles, ou peuvent être confiées à quelqu'un d'autre : un collègue, ou un agent IA connecté via un protocole ouvert comme MCP. Qui assure la moitié « faire tourner » du travail, et avec quels outils, décide davantage de l'avenir de votre app que n'importe quel écran que vous avez généré.

Le test : listez les cinq tâches dont votre app aura besoin chaque semaine. Pour chacune, nommez qui la fait et dans quel outil.

Validé quand : aucune des cinq réponses n'est « moi, en re-promptant le builder en croisant les doigts ».

Notez-vous honnêtement. Sept réussites : annoncez le lancement. Un ou deux échecs : vous savez en quoi consiste le travail de la semaine. Trois ou plus : ce que vous avez est une idée validée, ce qui a une vraie valeur, et elle mérite des fondations construites pour la partie qui vient ensuite.

Voici pourquoi nous pouvons publier cette checklist sans ciller : sur GoodBarber, l'essentiel n'est pas votre travail.

Les tests 1 et 2 sont gagnés d'avance. Comptes, sessions, comportement hors-ligne et états vides sont livrés en composants natifs, éprouvés sur les milliers d'apps en service que la plateforme héberge, plutôt que générés de zéro pour la vôtre. Le test 3 est un service. GoodBarber compile de vrais binaires natifs, Swift pour iOS et Kotlin pour Android, plus une Progressive Web App issue de la même configuration. Les déclarations de confidentialité qu'Apple et Google réclament partagent leur source de vérité avec le build lui-même, les fonctionnalités que vous avez activées, si bien que déclaration et binaire ne peuvent pas diverger. Et si vous préférez ne pas affronter la validation seul, l'équipe de publication qui peut prendre en charge votre soumission a récupéré 91 % des rejets de première soumission d'Apple (suivi interne de l'équipe de publication, douze mois jusqu'à avril 2026).

Le test 4 est de l'infrastructure : le pipeline de push tourne de bout en bout sur la plateforme et achemine plusieurs millions de notifications par semaine. Le test 5 tient en une seule ligne, parce qu'hébergement, base de données, CMS, push, statistiques et passerelles de paiement vivent dans un seul abonnement, avec 0 % de commission GoodBarber sur les transactions e-commerce. Cette consolidation explique en grande partie pourquoi le coût total de possession atteint environ un dixième de celui d'un développement sur mesure. Et le test 6 est absorbé en amont : quand Apple ou Google modifie une exigence, GoodBarber applique le correctif une fois, et votre prochaine mise à jour l'embarque.

Le test 7 est celui où l'IA revient, du bon côté de la démo cette fois. Chaque app GoodBarber peut être pilotée par un agent IA via le serveur MCP de la plateforme : dites à votre assistant ce qu'il vous faut, et l'article part, le push se programme, le prix change, et les chiffres de la semaine dernière reviennent en langage clair, depuis Claude, ChatGPT, Cursor ou n'importe quel client compatible MCP. L'intégralité du test 7 devient une décision de délégation. Et agent ready signifie que l'app peut être pilotée par un agent, pas qu'elle tourne toute seule : les règles et la relecture finale restent chez vous.

Le périmètre de GoodBarber, ce sont les apps de contenu et le commerce mobile : la plateforme ne crée pas de jeux, et une marketplace bâtie sur une lourde logique sur mesure mérite une autre réponse, que nous préférons vous donner maintenant. À l'intérieur de ce périmètre, cette checklist est ce que la plateforme est construite pour porter. Quelque part, une app GoodBarber est téléchargée toutes les 4 secondes, et les clients payants de la plateforme sont répartis dans 152 pays. Voilà ce que donnent ces tests réussis, année après année.

Que signifie « prête pour la production » pour une app mobile ?

Une app prête pour la production survit aux trois choses qu'une démo ne contient jamais : de vrais utilisateurs, une vraie validation des stores et du temps qui passe. Concrètement : des inconnus créent des comptes sans assistance, l'app gère les états vides et hors-ligne, les stores acceptent ses binaires signés et ses déclarations de confidentialité, les notifications push sont livrées, chaque service de sa stack a un propriétaire identifié, elle peut être mise à jour sans casser ce qui fonctionne déjà, et son exploitation hebdomadaire ne dépend pas d'une seule personne.

Mon app créée par IA est-elle prête pour la production ?

Passez sept tests : création et récupération de compte sur un appareil qui n'a jamais vu l'app, états vides et hors-ligne, soumission aux stores avec un binaire natif signé, livraison du push sur un téléphone verrouillé, un inventaire chiffré de chaque service de la stack, une mise à jour qui ne change rien d'autre que ce qu'elle visait, et une exploitation semaine après semaine hors du builder. Réussissez les sept et vous pouvez annoncer. Les échecs les plus probables sont la soumission aux stores, le push et la première mise à jour, parce que beaucoup d'app builders IA génèrent des applications web plutôt que des binaires natifs signés, et que la génération ne couvre ni la conformité aux stores ni la maintenance.

Une app créée par IA peut-elle passer la validation de l'App Store ?

Seulement en tant que vraie app native. Apple exige des binaires signés, des déclarations de confidentialité complètes et une app qui soit davantage qu'un site web réemballé (Guideline 4.2). Le rejet est la norme plutôt que l'exception : Apple a refusé environ 42 % des premières soumissions traitées par l'équipe de publication de GoodBarber sur les douze mois jusqu'à avril 2026, et 91 % de ces rejets ont ensuite été acceptés après retouches.

Qu'est-ce qui casse en premier après le lancement d'une app créée par IA ?

Les choses ingrates, à peu près dans cet ordre : l'authentification (emails de confirmation, réinitialisations de mot de passe, sessions mortes), puis les états vides et hors-ligne, puis la livraison du push, puis la première mise à jour, où corriger un bug par prompt peut réécrire des parties qui fonctionnaient. Le schéma derrière tout cela est le même : une démo est testée en conditions amicales, et la production les retire une par une.

Faut-il un développeur pour garder une app créée par IA en service ?

Si l'app est du code généré posé sur une stack assemblée, quelqu'un doit posséder ce code et cette stack, et c'est un travail de développeur, que vous sachiez le faire ou non. Sur une plateforme managée comme GoodBarber, l'équipe d'ingénierie de la plateforme maintient le code, l'hébergement, l'infrastructure de push et la conformité aux stores ; vous pilotez l'app depuis un back office, ou confiez les tâches du quotidien à un agent IA via le serveur MCP. Vous gardez le rôle d'opérateur, pas celui d'ingénieur.

Prochaine étape : rien de ce que vous avez construit n'est perdu. La démo a réglé la question la plus coûteuse, celle de savoir si l'idée mérite une app, et vos écrans sont désormais le cahier des charges. Démarrez un essai gratuit GoodBarber, reconstruisez l'idée à partir de ce cahier des charges, et passez cette même checklist sur le résultat : les six premiers tests sont portés par la plateforme, et le septième tient en une phrase à un agent.