Créer une application avec l'IA : ce qui marche vraiment

Vous avez une idée depuis des mois. Une petite application pour gérer les réservations de votre club, suivre les chantiers de l’équipe, ou remplacer enfin le tableur que tout le monde remplit de travers. Vous avez vu passer des vidéos où quelqu’un tape trois phrases et obtient une application qui tourne. Et vous vous demandez si c’est vrai, ou si c’est encore une démonstration montée pour faire rêver.

Les deux. Créer une application avec l’IA, sans écrire une ligne de code, est réellement possible aujourd’hui. Ce qui est monté, c’est la suite : la vidéo s’arrête au moment où l’application marche pour la première fois, et c’est précisément là que les ennuis commencent pour ceux qui n’y sont pas préparés.

Mon métier d’automaticien consiste à faire tourner des lignes de production, et une machine qui tourne à vide n’a jamais prouvé qu’elle tiendrait en charge. Ce guide suit cette logique : ce que ces outils font bien, l’endroit exact où ils cassent, et la méthode qui évite d’y laisser vos soirées.

Ce que fait réellement un générateur d’applications

Le principe tient en une phrase : vous décrivez ce que vous voulez, l’outil écrit le code à votre place, puis le met en ligne. Vous corrigez ensuite par petites demandes, toujours en français.

Ce qui change par rapport aux constructeurs de sites d’il y a quelques années, c’est tout ce qui se passe derrière l’écran. Une application a besoin d’une base de données (l’endroit où sont rangées les informations : les réservations, les comptes, les commandes), d’une authentification (la porte d’entrée, avec identifiant et mot de passe) et d’un hébergement (l’ordinateur, quelque part, qui fait tourner le tout jour et nuit). Les générateurs récents fournissent ces trois briques d’office. Vous n’avez pas à savoir qu’elles existent pour démarrer, et c’est à la fois leur force et leur piège, on y revient plus bas.

Il existe aujourd’hui quatre façons de construire une application, et elles ne s’adressent pas aux mêmes personnes.

Approche	Pour qui	Délai avant une première version	Ce que vous avez à la fin	Le point faible
Générateur par description (Anything, Lovable, Bolt, Replit)	Quelqu’un qui ne code pas	Une soirée à quelques jours	Une application hébergée par la plateforme, parfois le code source	Sécurité et logique complexe à vérifier soi-même
Constructeur sans code par blocs (Bubble, Glide)	Quelqu’un prêt à apprendre un outil	Quelques jours à quelques semaines	Une application qui vit sur la plateforme	Chaque outil a sa logique, qu’il faut apprendre
Éditeur de code assisté par IA (Cursor, Claude Code)	Quelqu’un qui sait lire du code	Quelques jours	Le code complet, que vous possédez	Inutilisable si vous ne pouvez pas relire ce qu’il écrit
Développeur ou agence	Un projet financé, au cahier des charges clair	Plusieurs semaines	Le code et un interlocuteur responsable	Le coût, et le délai avant le premier retour

Les délais sont des ordres de grandeur pour une application simple, mise en ligne comprise. Si vous ne codez pas et que votre objectif est de savoir si l’idée tient debout, la première ligne est la seule qui vous concerne.

Ce que les générateurs font bien

Supprimer le délai entre l’idée et le premier retour. C’est leur vraie valeur. La plupart des projets ne meurent pas faute de compétence technique, ils meurent pendant les semaines qui séparent l’envie de la première version visible. Quand cette première version existe le soir même, vous pouvez la montrer le lendemain, et le retour d’un vrai utilisateur vaut plus que dix heures de réflexion.

Fournir l’infrastructure ennuyeuse. Base de données, comptes utilisateurs, stockage des fichiers, parfois paiements : tout ce qui demandait autrefois un développeur pour être branché est là dès le départ. Anything, que j’utilise, va jusqu’à l’application mobile installable, avec la soumission aux magasins d’applications prise en charge.

Les applications à périmètre étroit. C’est leur terrain naturel :

• un formulaire de réservation pour une activité, avec confirmation par e-mail ;
• un suivi de stock ou de matériel pour un petit atelier ;
• un annuaire ou un tableau de bord interne pour une équipe de dix personnes ;
• un calculateur de devis qui applique trois ou quatre règles simples ;
• un prototype à montrer à des clients potentiels avant de financer quoi que ce soit.

Le point commun : peu d’écrans, des règles simples, et des utilisateurs que vous connaissez.

Où ils cassent, et ce n’est pas là où l’on croit

On s’attend à ce que l’IA échoue à produire quelque chose qui marche. C’est rarement le cas : l’application s’affiche, les boutons répondent, les données s’enregistrent. Les problèmes se logent ailleurs, là où rien ne se voit.

La sécurité des données. En mars 2025, le chercheur en sécurité Matt Palmer a signalé à Lovable une faille dans des applications générées par l’outil : les règles qui décident qui a le droit de lire quelle ligne de la base de données manquaient ou étaient insuffisantes. Concrètement, un inconnu pouvait interroger directement la base et lire des données d’autres utilisateurs, parfois des clés d’accès ou des informations de paiement. La faille a été rendue publique fin mai 2025 sous la référence CVE-2025-48757, et le recensement de Matt Palmer a compté 170 projets exposés sur 1 645 examinés. Les applications concernées fonctionnaient parfaitement pour leurs utilisateurs. C’est tout le problème.

Les modifications qui s’empilent. Sur un petit projet, chaque demande fait ce qu’on attend. Plus l’application grossit, moins les modifications sont prévisibles : une demande anodine peut casser un écran qui fonctionnait depuis deux semaines, sans que vous le remarquiez tout de suite.

L’agent qui agit trop vite. En juillet 2025, Jason Lemkin, fondateur de SaaStr, a raconté comment l’agent de Replit avait supprimé la base de données de son application pendant une période où il avait explicitement demandé qu’on ne touche à rien. Plus de 1 200 fiches de dirigeants et plus de 1 190 fiches d’entreprises ont disparu. Le patron de Replit a qualifié l’incident d’inacceptable et annoncé une séparation automatique entre les données de test et les données réelles. L’outil a été corrigé, la leçon reste : un agent qui a les mains sur vos données peut faire des dégâts réels.

La logique métier. Des règles de calcul imbriquées, des droits d’accès fins (le chef d’équipe voit tout, le technicien voit ses chantiers, le client voit sa facture), des exceptions à chaque étage : c’est là que tous ces outils montrent leurs limites, et qu’il faut à un moment quelqu’un qui code.

La dépendance à la plateforme. Certains outils vous rendent le code, d’autres non. Le jour où vous voulez partir, la différence se chiffre en semaines de travail. Le comparatif Anything ou Lovable détaille ce point, qui ne se voit pas le premier jour.

La méthode qui tient

Rien de tout cela ne doit vous décourager. Ces outils valent largement le détour, à condition de les utiliser dans le bon ordre. Voici celui que je suivrais.

1. Écrire l’application en cinq phrases, avant d’ouvrir l’outil. Qui l’utilise, pour faire quoi, avec quelles informations, et ce qui se passe une fois la tâche faite. Si vous n’y arrivez pas, aucun générateur ne comblera le trou : il exécute une demande claire, il ne devine pas une intention floue. Coût : vingt minutes.
2. Réduire à une seule fonctionnalité. Celle qui porte l’idée. Le reste attendra le premier retour d’un utilisateur, et une bonne partie ne sera jamais nécessaire.
3. Une demande, une modification. « Ajoute un bouton pour exporter les réservations de la semaine en tableur » donne un résultat net. Cinq changements dans le même message donnent un résultat confus, et vous ne saurez plus quelle demande a cassé quoi.
4. Garder une copie de chaque version qui marche. La plupart de ces outils conservent un historique des versions. Repérez où il se trouve avant votre première grosse modification, pas après.
5. Faire le test du deuxième compte. Créez deux comptes utilisateurs, remplissez des données dans le premier, connectez-vous avec le second et vérifiez qu’il ne voit rien qui ne le regarde pas. C’est grossier, c’est gratuit, et c’est exactement le type de faille décrit plus haut.
6. Montrer à cinq personnes qui ont le problème. Pas à vos proches, qui trouveront ça très bien. À cinq personnes qui vivent réellement le problème que l’application prétend résoudre.

Une fois l’application branchée sur d’autres services (un agenda, un outil de facturation), vous croiserez le mot API. Le guide pour comprendre une API simplement suffit pour savoir ce que vous demandez à l’outil de faire.

Par quel outil commencer

Si vous ne codez pas, le choix se fait en une question : votre application doit-elle s’installer sur un téléphone, avec une icône sur l’écran d’accueil ?

Si oui, commencez par Anything. C’est l’outil de la catégorie qui va le plus loin vers l’application mobile réelle, et il est pensé pour quelqu’un qui ne veut jamais voir une ligne de code. L’objection habituelle est la dépendance : vous restez sur la plateforme. Elle est réelle, et elle ne pèse rien tant que l’idée n’est pas validée. Le jour où le projet tient debout et rapporte, vous aurez les moyens de le faire reprendre proprement.

Si une adresse web suffit et que vous tenez à récupérer le code pour le confier un jour à un développeur, Lovable est le choix plus prudent.

Pour un simple site vitrine plutôt qu’une application, la page créer un site sans coder compare les approches plus légères. Et si votre besoin réel est de relier des outils existants plutôt que d’en construire un nouveau, le pilier IA et automatisation vous évitera de fabriquer une application là où une automatisation suffisait.

Votre prochain geste

Ce soir, avant d’ouvrir quoi que ce soit, écrivez les cinq phrases qui décrivent votre application. Si elles tiennent, ouvrez Anything et donnez-lui la première, et seulement la première. L’avis complet sur Anything détaille le reste : où l’outil déçoit, et le piège de la première demande.