Créer une application avec l'IA : méthode et limites

Créer une application avec l'IA prend aujourd'hui une heure pour la première version, puis plusieurs semaines pour la version qu'on peut confier à de vrais utilisateurs. Cet écart tient à trois choses que l'IA ne peut pas deviner à votre place : le modèle de données, les droits d'accès et le critère qui dit qu'un écran est terminé. Les outils écrivent très bien le code. Ils écrivent beaucoup moins bien la spécification qui manque.

Ce tuto s'adresse à ceux qui veulent faire : le fondateur qui monte un MVP, le responsable des opérations qui veut remplacer un tableur partagé, le développeur qui veut livrer plus vite. Il décrit la méthode que nous appliquons chez Noxcod, sur un exemple fil rouge, puis les limites qui imposent de changer d'outil ou de passer la main. Le fil rouge est un scénario illustratif : une PME de maintenance de quinze techniciens veut une application où ses clients déposent une demande d'intervention, où un responsable l'affecte, et où le technicien la clôt avec des photos.

Générateur d'application ou agent de code : par où commencer

Pour une application web autonome avec peu d'intégrations, un générateur dans le navigateur suffit. Dès qu'il faut se brancher sur un système existant, un agent de code qui travaille dans votre propre dépôt est le meilleur point de départ. Ces deux familles d'outils ne s'adressent pas au même projet, et le mauvais choix se paie au moment de la mise en production.

Les générateurs comme Lovable ou Bolt prennent une description en langage naturel et rendent une application qui tourne, hébergée, avec sa base de données. Selon la documentation d'hébergement de Lovable, les projets créés depuis le 13 mai 2026 reposent sur TanStack Start, avec un backend intégré qui peut être déplacé vers Supabase. Vous ne touchez pas au terminal, vous voyez le résultat à chaque message. C'est la voie la plus rapide pour montrer quelque chose à un client ou à un investisseur.

Les agents de code comme Claude Code, Codex ou Cursor travaillent dans un dépôt git que vous possédez. Vous choisissez la stack, l'hébergement et la base. L'agent lit le code existant, propose un plan, modifie plusieurs fichiers et lance les tests. Il faut savoir lire un diff et ouvrir un terminal, mais rien ne vous enferme dans une plateforme.

Après plusieurs reprises de projets nés dans un générateur, nous donnons toujours le même conseil. Commencez dans un générateur seulement si vous connectez le dépôt GitHub dès le premier jour. Un projet versionné se reprend en quelques jours. Un projet qui n'existe que dans l'éditeur en ligne se reprend mal, parce que l'historique des décisions a disparu avec la conversation.

Dans notre fil rouge, l'application doit à terme lire le planning des techniciens dans un logiciel existant. Nous commencerions donc le prototype dans un générateur relié à GitHub, avec l'idée assumée de continuer dans un agent de code dès que l'intégration arrive.

Écrire la fiche de cadrage avant le premier prompt

La fiche de cadrage est un texte d'une page qui décrit les utilisateurs, leurs rôles, les objets manipulés et les trois parcours principaux. L'IA la relit à chaque demande, ce qui l'empêche d'inventer un modèle de données différent à chaque session. Sans elle, le premier prompt (« crée une app de gestion d'interventions ») laisse l'outil choisir à votre place des dizaines de détails que vous corrigerez ensuite un par un, en crédits.

Pour notre PME de maintenance, la fiche tient en une vingtaine de lignes :

Application : suivi des demandes d'intervention.
Rôles : client (voit ses demandes), responsable (voit tout, affecte),
technicien (voit ses interventions affectées, les clôt).
Objets : Client, Site, Demande, Intervention, Photo, Commentaire.
Une Demande appartient à un Site, un Site à un Client.
Une Intervention a un statut : à planifier, planifiée, en cours, close.
Parcours 1 : un client crée une demande avec description et photo.
Parcours 2 : le responsable affecte la demande à un technicien et une date.
Parcours 3 : le technicien clôt l'intervention avec photos et commentaire.
Hors périmètre de la V1 : facturation, devis, application mobile native.
Règle : un technicien ne voit jamais les demandes des autres techniciens.

Deux lignes de cette fiche évitent à elles seules les corrections les plus coûteuses. La ligne « Hors périmètre » empêche l'IA d'ajouter un module de facturation que personne n'a demandé, et qu'il faudrait ensuite sécuriser. La dernière ligne, la règle de visibilité, sera reprise telle quelle dans les tests de droits plus loin.

Où ranger la fiche dépend de l'outil. Dans Claude Code, elle va dans le fichier CLAUDE.md à la racine du dépôt, que l'agent charge à chaque session. Dans un générateur, collez-la dans le champ d'instructions permanentes du projet plutôt que dans le premier message de la conversation. Un message se perd au fil des échanges, une instruction de projet reste.

Le piège classique est d'oublier les objets secondaires. L'historique des statuts, les pièces jointes et les commentaires apparaissent rarement dans le premier prompt. L'IA les ajoute ensuite sous forme de colonnes improvisées dans une table existante, et la base devient difficile à faire évoluer. Les écrire dans la fiche coûte cinq minutes, les rattraper coûte une migration.

Construire par tranches verticales, une fonctionnalité à la fois

Une tranche verticale est une fonctionnalité complète, de la table en base jusqu'à l'écran, que vous demandez, testez et sauvegardez avant de passer à la suivante. Dans notre exemple, la première tranche est le parcours 1 entier : le formulaire de demande, la table Demande, l'envoi de la photo et la liste « mes demandes » côté client. La deuxième tranche est l'affectation, la troisième la clôture.

L'erreur inverse consiste à générer tous les écrans d'un coup, puis à brancher les données. On obtient une maquette impressionnante dont aucun bouton ne fonctionne vraiment, et chaque correction touche dix fichiers à la fois. Un premier prompt trop large y conduit presque toujours, quel que soit l'outil.

Chaque tranche suit le même cycle. Vous demandez d'abord un plan, sans modification de code : le mode Plan de Lovable facture un crédit par message, plus les éventuelles recherches, et Claude Code dispose d'un mode équivalent qui propose avant d'écrire. Vous relisez le plan contre la fiche de cadrage. Si l'agent propose une table que la fiche ne prévoit pas, vous corrigez le plan, pas le code.

Le critère de fin s'écrit dans le message lui-même. Pour le parcours 1, il tient en une phrase : un client connecté crée une demande avec une photo, la voit dans sa liste, et un autre client ne la voit pas. Sans critère, l'outil s'arrête quand l'écran a l'air fini, ce qui n'est pas la même chose.

La sauvegarde après chaque tranche n'est pas une précaution de développeur pointilleux. Sur les projets que nous reprenons, après quelques dizaines d'échanges, l'outil a souvent perdu le fil des décisions prises au début et casse une fonctionnalité en réparant une autre. Un commit par tranche permet de revenir en arrière en une commande au lieu de négocier la réparation avec l'IA.

Notre article sur l'utilisation de Claude Code au quotidien détaille ce cycle plan, exécution, vérification côté agent de code, avec les commandes exactes.

Vérifier les droits d'accès avant d'inviter le premier utilisateur

Le test qui compte se fait en dix minutes : deux comptes de rôles différents, une requête sans compte, et la liste des tables qui n'ont aucune règle d'accès. Une application créée avec l'IA peut fonctionner parfaitement dans la démonstration et laisser n'importe qui lire la base, parce que la démonstration se fait toujours avec le bon compte.

Ce risque a été mesuré. Dans son rapport 2026 sur la sécurité du code généré, Veracode indique qu'environ 44 % des tâches de génération confiées aux modèles testés ont produit du code contenant une vulnérabilité connue. Le taux de réussite moyen en sécurité est de 56 %, contre 55 % dans le premier rapport. Sur le cross-site scripting, il tombe à 15 %.

Pour les applications adossées à Supabase, la protection repose sur la sécurité au niveau des lignes, appelée RLS. La documentation de Supabase précise qu'une fois la RLS activée sur une table, aucune donnée n'est accessible via la clé publique tant qu'aucune règle n'existe. Le danger vient notamment des tables où elle n'a jamais été activée, et des règles trop permissives. Cette requête, à lancer dans l'éditeur SQL du projet, liste l'état de chaque table :

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Toute ligne avec rowsecurity à false doit être corrigée avant la mise en ligne. Testez ensuite depuis l'extérieur, avec la clé publique que l'application embarque de toute façon dans le navigateur :

curl "https://VOTRE-PROJET.supabase.co/rest/v1/demandes?select=*" \
  -H "apikey: VOTRE_CLE_PUBLIQUE"

La réponse attendue est une liste vide. Si des demandes de clients s'affichent, la base est ouverte. Le registre américain des vulnérabilités NVD référence depuis le 30 mai 2025 la CVE-2025-48757, qui décrit des règles RLS insuffisantes dans Lovable, jusqu'au 15 avril 2025, permettant de lire ou d'écrire sans authentification dans les tables des sites générés. La même fiche indique que Lovable conteste cette classification, chaque client restant selon lui responsable de la protection des données de son application. Les deux positions convergent sur un point pratique : la vérification vous revient.

Lovable lance désormais une analyse de sécurité automatique à l'ouverture de la fenêtre de publication, qui contrôle notamment les règles d'accès à la base. Elle est utile, mais elle ne connaît pas votre règle métier. Seul un test avec un compte technicien prouve qu'un technicien ne voit pas les interventions de ses collègues.

Combien coûte une application créée avec l'IA

L'abonnement payant d'entrée coûte 25 dollars par mois chez Lovable comme chez Bolt, selon leurs pages tarifs détaillées ci-dessous, et la dépense réelle augmente avec chaque aller-retour, en particulier pendant les corrections. Le prix affiché achète une quantité de travail de l'IA, pas une application.

Chez Lovable, la grille des abonnements consultée le 13/11/2026 démarre à 25 dollars par mois pour 100 crédits mensuels, puis 50 dollars pour 200 crédits et 100 dollars pour 400 crédits. L'offre gratuite donne 5 crédits de construction par jour, plafonnés à 30 par mois. Un message en mode construction coûte un nombre variable de crédits selon la complexité de la demande.

Chez Bolt, la page tarifs consultée le même jour affiche une offre gratuite à 1 million de tokens par mois, avec une limite de 300 000 tokens par jour. L'offre Pro coûte 25 dollars par mois et commence à 10 millions de tokens mensuels. La documentation de Bolt sur les tokens précise que la lecture et la synchronisation des fichiers du projet représentent la plus grande part de la consommation : plus le projet grossit, plus chaque message coûte.

Il faut ajouter ce que l'abonnement ne couvre pas toujours : le nom de domaine, l'hébergement au-delà des quotas inclus, l'envoi d'e-mails, et surtout les appels aux modèles si votre application intègre elle-même de l'IA. Dans notre fil rouge, un résumé automatique de chaque intervention ajouterait un coût par appel, payé chaque mois, longtemps après la fin du développement.

Méfiez-vous aussi de votre propre impression de vitesse. Dans une étude contrôlée publiée par METR en 2025, 16 développeurs open source expérimentés, travaillant sur leurs propres projets avec les outils du début 2025, prévoyaient de gagner 24 % de temps grâce à l'IA. Ils ont en réalité mis 19 % de temps en plus, tout en estimant après coup avoir gagné 20 %. Fixez donc un plafond de crédits par tranche, notez la consommation réelle, et arrêtez une boucle de correction après trois tentatives ratées. Au-delà, revenez au dernier commit et reformulez la demande.

Les limites qui imposent de passer la main à un développeur

Quatre signaux indiquent que l'outil a atteint sa limite : une correction qui en casse une autre, une intégration avec un système existant, des données sensibles, et une application que plusieurs personnes doivent faire évoluer. Aucun ne condamne le projet. Chacun change la façon de travailler.

Les développeurs professionnels restent prudents. Dans l'enquête 2025 de Stack Overflow, 46 % des développeurs se méfient de la justesse des outils d'IA, contre 33 % qui lui font confiance. Le même sondage relève que 72 % des répondants ne pratiquent pas le vibe coding dans leur travail. L'édition 2026 apporte une nuance : 48 % font confiance à l'IA quand ils peuvent facilement vérifier sa réponse.

Le premier signal, la boucle de corrections, se traite en reprenant la main sur le code. Le projet exporté sur GitHub s'ouvre dans un éditeur, un développeur stabilise l'architecture, et l'IA redevient un assistant plutôt qu'un pilote. Notre guide pour reprendre un projet Lovable ou Bolt décrit l'audit à mener avant de décider entre correction et réécriture.

Le deuxième signal, l'intégration, arrive dès que l'application doit parler à un ERP, à un CRM ou à un annuaire d'entreprise. Il faut gérer des secrets, des erreurs réseau et des droits côté serveur, ce qui demande plus de contrôle que l'interface d'un générateur n'en offre. Le troisième, les données sensibles, impose de savoir où la base est hébergée, qui y accède et comment l'accès est journalisé, ce que le RGPD vous demande de documenter.

Le quatrième signal est le plus sous-estimé. Une application créée par une seule personne dans une conversation avec l'IA n'a souvent ni tests, ni documentation, ni conventions. Le jour où un deuxième contributeur arrive, il doit tout redécouvrir. Dans les projets que nous reprenons, c'est souvent à ce moment-là qu'apparaissent les incidents de production liés au vibe coding.

Quand le projet franchit l'un de ces seuils, deux options sérieuses existent. Une agence Lovable reprend le projet sans le réécrire si la base est saine. Un développement sur mesure s'impose quand l'application porte un métier critique et doit durer plusieurs années. Dans les deux cas, la fiche de cadrage et l'historique des commits font gagner plusieurs jours à celui qui reprend.

Questions fréquentes

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

Oui pour un prototype ou un outil interne simple, avec un générateur comme Lovable ou Bolt. Il faut en revanche savoir décrire précisément ce que l'on veut, tester avec plusieurs comptes et lire une requête SQL de vérification. Sans ces réflexes, l'application fonctionne en démonstration mais reste fragile face à de vrais utilisateurs. Pour une application qui stocke des données clients, prévoyez au minimum une revue des droits d'accès par un développeur avant la mise en ligne.

Combien de temps faut-il pour créer une application avec l'IA ?

Un prototype navigable se monte en une journée. Une première version utilisable par une équipe, avec trois parcours, des rôles et des droits testés, demande plutôt deux à quatre semaines de travail par tranches. La différence vient des tests, des corrections et des cas limites, que l'IA ne traite pas d'elle-même. Les intégrations avec des logiciels existants allongent ce délai, parfois davantage que tout le reste du projet.

Peut-on sortir son application de Lovable ou de Bolt ?

Oui. Lovable propose une synchronisation avec un dépôt GitHub, et Bolt permet de télécharger le projet complet en archive depuis un ordinateur. Le code produit repose sur des technologies standards comme React et TypeScript, qu'un développeur reprend sans formation particulière. Les éléments extérieurs au code, comme la base de données, les variables d'environnement et les clés de services, se reconfigurent à la main. Connectez GitHub dès le premier jour pour garder l'historique complet de vos décisions.

Une application créée avec l'IA est-elle sécurisée par défaut ?

Non. D'après la fiche NVD de la CVE-2025-48757, Lovable considère que la protection des données de chaque application revient à son client. Les analyses automatiques intégrées repèrent les erreurs fréquentes, comme une table sans règle d'accès. Elles ne vérifient pas vos règles métier, par exemple qu'un technicien ne voit que ses propres interventions. Faites le test avec deux comptes de rôles différents et une requête anonyme avant chaque mise en ligne importante.