Vibe coding pour non-développeurs : ce que vous pouvez construire sans risque en 2026

En 2026, un non-développeur peut vibe-coder beaucoup de choses sans risque, jusqu'à une limite que l'on peut nommer. En dessous, il y a les prototypes, les landing pages, les outils internes et les applis simples avec connexion et base de données. Au-dessus, il y a la logique de paiement sur mesure, les données de santé ou financières, les applis partagées entre de nombreuses entreprises et tout ce qui reçoit un trafic sérieux. Pour ça, il vous faut encore un ingénieur.

Le public est déjà là. Lovable affirme que 80 % de ses utilisateurs se disent non techniques, et qu'ils s'en servent pour des outils internes, des CRM et des boutiques en ligne autant que pour des sites web (The Next Web). Les ratés sont arrivés avec eux. Cette année, UpGuard a trouvé 16 326 bases de données sur Supabase, le backend sur lequel tournent beaucoup de ces applis, dont les tables étaient lisibles par n'importe qui sur internet (UpGuard). Veracode a testé plus de 100 modèles d'IA sur quatre ans et chiffre à 56 % le taux moyen de réussite aux tests de sécurité du code écrit par IA. Dans ses termes : « It hasn't moved » (« ça n'a pas bougé ») (Veracode).

L'essentiel des dégâts vient d'une seule erreur que vous pouvez vérifier sans lire une ligne de code : une base de données qui livre ses lignes à quiconque les demande. Corrigez ça, gardez les clés secrètes hors du navigateur, et la plupart de ce qu'un fondateur, un marketeur ou un analyste veut construire devient permis.

À quoi ressemble le vibe coding en 2026

Vous décrivez ce que vous voulez en langage courant, l'outil écrit le code, vous cliquez dans un aperçu en direct, puis vous demandez la modification suivante. Les outils destinés aux non-développeurs vont désormais bien au-delà de l'interface. Ils créent aussi la base de données, le système d'inscription et l'hébergement : une appli avec de vrais comptes peut exister après un après-midi de prompts.

Lisez le schéma comme une boucle avec une sortie. Cette sortie, c'est la partie que tout le monde saute.

La flèche en pointillés part du test, et c'est voulu. Vous ne pouvez pas juger du code généré en le lisant, mais vous pouvez juger de ce qu'il fait : un second compte voit-il les données du premier ? Une page s'ouvre-t-elle sans connexion ? Quand un test touche à l'argent, aux données privées d'autres personnes ou à une vraie montée en charge, arrêtez-vous et faites appel à quelqu'un qui sait lire du code.

Beaucoup de choses ont bougé cette année. Lovable permet désormais à un seul message de build de tourner jusqu'à 10 heures, et a ajouté une commande /goal qui continue jusqu'à ce qu'une tâche soit terminée, à un prix nettement plus élevé (changelog de Lovable). Replit a lancé Agent 4 avec des agents en parallèle, et son IA fonctionne maintenant en mode Free, avec des modes payants Power et Max. Vercel a reconstruit v0 autour des branches GitHub et des pull requests, son directeur produit expliquant que 90 % du vrai travail consiste à modifier une base de code existante. Base44, propriété de Wix, a entraîné son propre modèle, Base1, que son fondateur espère à terme plus rapide et moins cher pour les clients que les modèles de pointe.

Google AI Studio repère désormais quand une appli a besoin d'une base de données ou d'une connexion et, une fois que vous approuvez, configure Firebase pour les deux. Son ancien builder, Firebase Studio, est en cours de fermeture : tout tutoriel basé dessus est donc déjà périmé.

L'échelle des risques : ce que vous pouvez construire seul

Le risque grimpe avec deux facteurs : à qui appartiennent les données que l'appli détient, et si de l'argent y circule. Un prototype rempli de fausses données ne peut rien divulguer. Une appli d'inscription qui conserve les adresses e-mail d'inconnus, si, et cette année, beaucoup l'ont fait.

L'échelle classe les projets courants selon ce risque. Les trois barreaux du bas sont accessibles à tout le monde. Le barreau orange est celui où se sont produites la plupart des fuites de cette année.

Les prototypes cliquables, les landing pages avec formulaire de contact et les outils internes réservés à l'équipe sont le terrain idéal. Un prototype répond à « faut-il construire ça ? » avant que quiconque écrive un ticket. Un outil de suivi interne pour une équipe commerciale ou ops peut remplacer un tableur auquel personne ne fait confiance, et s'il est limité à l'espace de travail avec une connexion, les seules personnes susceptibles d'en abuser sont vos collègues. Les automatisations simples relèvent aussi de ce barreau, même si un outil de workflow comme n8n ou Zapier fait souvent le travail sans qu'il faille construire d'appli (voir le classement de l'automatisation de workflows).

Les applis clients avec comptes sont le barreau orange. Les outils savent très bien les construire. Le problème, c'est qu'une seule règle de base de données erronée expose tous les utilisateurs d'un coup : construisez, puis payez un ingénieur pour la relire avant que de vraies personnes s'inscrivent.

Les deux barreaux du haut reviennent aux ingénieurs. D'abord les paiements. Un bouton d'achat qui ouvre le checkout hébergé de Stripe ne pose pas de problème, car les données de carte vont directement à Stripe sans jamais passer par votre appli. Le guide de sécurité de Stripe prévient qu'une entreprise qui collecte elle-même les données de carte peut avoir à satisfaire plus de 300 contrôles de sécurité au titre de PCI DSS. La facturation à l'usage et les applis où plusieurs entreprises partagent une même base de données reposent toutes deux sur une logique d'autorisation, précisément là où les chercheurs continuent de trouver des failles dans les applis conçues par IA.

Les données réglementées sont l'autre cas. La FAQ entreprise de Lovable indique que la plateforme ne signe pas de business associate agreements, n'est pas conforme à HIPAA et demande de ne pas y téléverser d'informations de santé protégées. Les données de santé, financières et celles des enfants entraînent des obligations légales qu'aucun scan avant publication ne peut couvrir.

Les outils qui comptent aujourd'hui, et comment chacun vous facture

Cinq builders couvrent l'essentiel des besoins d'un lecteur comme vous, et ils diffèrent moins par ce qu'ils savent produire que par leur facturation et la facilité avec laquelle on peut en partir. Bolt et v0 s'ajoutent à Lovable, Replit et Base44. Les prix sont ceux des premières offres payantes, tirés de la page tarifs de chaque éditeur.

Pour la plupart des non-développeurs, Lovable est le choix par défaut le plus raisonnable. Il publie des exemples de coût par message, analyse les problèmes de sécurité à chaque publication, et son code se synchronise avec GitHub sur n'importe quel plan, gratuit compris. Base44 convient à ceux qui ne veulent jamais voir de code, avec un bémol détaillé dans la section sur la passation plus bas. Replit se justifie si vous voulez un seul espace de travail pour les applis, les présentations et les tableaux de bord de données, et son mode Free est la façon la plus douce de démarrer. Bolt va bien à ceux qui construisent par à-coups, puisque les tokens payants non utilisés sont reportés pendant un mois. v0 est le bon choix quand votre entreprise déploie déjà sur Vercel et que des ingénieurs reprendront le projet.

Deux options no-code plus anciennes couvrent un terrain similaire avec des éditeurs visuels : Bubble crée des applis web et mobiles, et Glide transforme des tableurs en applis. Le classement en direct ci-dessous montre comment se positionne aujourd'hui l'ensemble de la catégorie, et notre comparatif des builders d'applis IA en détaille une douzaine.

Le classement inclut aussi des builders destinés aux développeurs : servez-vous-en pour la découverte, et du tableau pour votre budget.

Pourquoi les crédits fondent plus vite que prévu

Chacun de ces outils facture désormais le travail que fait l'IA, et non le message que vous envoyez. C'est équitable pour les petites retouches et coûteux pour les demandes vagues.

Lovable publie les exemples les plus clairs. « Make the button gray » a coûté 0,50 crédit, « Add authentication » 1,20 et « Build a landing page with images » 2,00, tandis qu'un message en mode plan coûte 1 crédit (Lovable). Comme un message de build peut maintenant durer des heures, Lovable s'arrête pour vous demander confirmation dès qu'un seul message dépasse 20 crédits, un réglage par défaut que vous pouvez relever ou désactiver. Les recharges sur Pro coûtent 15 $ les 50 crédits, soit 0,30 $ le crédit contre 0,25 $ dans le plan de 100 crédits.

Les autres fonctionnent de la même façon sous d'autres noms. Le centre d'aide de Bolt explique que l'essentiel de la consommation de tokens vient de la lecture et de la synchronisation des fichiers du projet : le même prompt coûte donc plus cher à mesure que l'appli grossit. v0 compte l'historique du chat et les fichiers source comme des tokens d'entrée. Base44 indique qu'il n'y a pas de coût fixe par message et situe les modifications typiques entre environ 0,5 et 4 crédits. Le mode Free de Replit ne coûte rien dans la limite d'un quota, mais les modes Power et Max puisent dans des crédits mensuels, et ses packs de crédits supplémentaires expirent six mois après l'achat.

La grille tarifaire de Lovable montre ce que cela donne pour un budget.

Il n'y a presque aucune remise de volume. Chaque palier jusqu'à 800 crédits revient à 0,25 $ le crédit, et celui de 2 000 crédits est encore à 0,24 $. Si vous doublez vos prompts, vous doublez la facture : le vrai levier, ce sont les messages gaspillés.

Le gaspillage vient surtout des boucles de correction : l'IA casse quelque chose, sa correction casse autre chose, et chaque tour est facturé. Planifier d'abord aide, puisqu'un message en mode plan coûte un crédit fixe chez Lovable et que Bolt indique que son mode plan consomme moins de tokens parce qu'il ne modifie rien. Les boutons aident aussi : Bolt précise que publier ou restaurer une version via un bouton ne coûte rien, alors que demander à l'IA de le faire consomme des tokens. Quand une session part de travers, revenez à un point de restauration plutôt que d'essayer de vous en sortir à coups de prompts.

Intégrez vos propres habitudes dans l'estimateur ci-dessous. Il s'appuie sur les coûts d'exemple de Lovable : considérez donc le résultat comme une fourchette budgétaire, pas comme un devis.

Avec les valeurs par défaut, il vous faut environ 162 crédits par mois, ce que couvre le palier à 50 $. Montez les retouches à 60 % et même l'option la moins chère, le plan à 25 $ plus des recharges, grimpe à 70 $. Fixez aussi un plafond : la recharge automatique de Lovable accepte une limite de dépense mensuelle à la place de « No limit », et Replit vous laisse plafonner les dépenses au-delà de vos crédits inclus. Si la tarification par crédits reste floue pour vous, notre explication sur les modèles de tarification des outils IA détaille crédits, licences et tokens.

Le bilan des incidents pointe une seule erreur

Mettez côte à côte les rapports d'incidents de cette année et la même défaillance revient sans cesse. Ce n'est pas du piratage sophistiqué. C'est une base de données qui répond à quiconque la questionne.

L'étude d'UpGuard a relevé environ 300 000 domaines montrant des signes d'utilisation de Supabase et 16 326 bases de données exposant des tables lisibles, dont plus de la moitié avec des signes de données personnelles (UpGuard). Son explication est précise : les tables créées via l'API, c'est-à-dire la façon dont les agents de code dialoguent avec Supabase, n'ont pas la sécurité au niveau des lignes activée par défaut. Le responsable sécurité de Supabase a déclaré à TechCrunch que les projets sont sécurisés par défaut et que la sécurité est une responsabilité partagée.

Moltbook, un réseau social pour agents IA dont le fondateur disait n'avoir « pas écrit une seule ligne de code », a été mis en ligne avec sa clé Supabase dans la page et sans aucune politique de sécurité au niveau des lignes. Les chercheurs de Wiz ont pu atteindre 1,5 million de tokens d'API, 35 000 adresses e-mail et des milliers de messages privés avant que l'équipe corrige quelques heures après avoir été prévenue (Wiz).

Une appli hébergée sur Lovable a exposé 18 697 fiches utilisateurs, dont des milliers de comptes d'étudiants, selon le chercheur Taimur Khan. Il a découvert que le contrôle d'accès était écrit à l'envers : « The guard blocks the people it should allow and allows the people it should block » (« Le garde bloque ceux qu'il devrait laisser passer et laisse passer ceux qu'il devrait bloquer ») (The Register). Lovable a répondu proposer un scan de sécurité gratuit avant publication, qu'il appartient à l'utilisateur d'en tenir compte, que la base de données vulnérable n'était pas hébergée par Lovable et que le projet contenait du code que Lovable n'avait pas généré.

Les plateformes aussi faillissent. Plus tard dans l'année, un chercheur a montré qu'un compte Lovable gratuit pouvait récupérer le code source, les identifiants de base de données et les historiques de chat IA de projets publics appartenant à d'autres. Lovable a d'abord qualifié ce comportement d'intentionnel et de voulu. Puis a reconnu que renvoyer à une documentation peu claire ne suffisait pas, a dit « We'll do better » (« Nous ferons mieux ») et a indiqué avoir corrigé son API pour que les chats des projets publics ne soient plus accessibles (The Register). La société de sécurité RedAccess a compté environ 380 000 applis accessibles publiquement construites avec Lovable, Base44, Replit et Netlify, dont près de 5 000 exposaient des données sensibles. Le PDG de Replit a répondu que l'accessibilité des applis publiques est un comportement attendu et que la confidentialité se règle en un clic.

La recherche dit la même chose, vue de l'autre côté. Le test au long cours de Veracode montre à quel point des modèles plus intelligents ont peu aidé.

Même le meilleur modèle de l'édition 2026 de Veracode échoue à près d'une tâche de sécurité sur trois, et les modèles conçus pour le code ne font pas mieux que les généralistes. Une étude distincte de la startup Tenzai a construit 15 applis avec cinq agents de code et trouvé 69 vulnérabilités. Les pires concernaient l'autorisation et la logique métier, et les classiques bugs d'injection n'apparaissaient pas du tout. Cela colle avec les incidents. L'IA écrit du code qui fonctionne, mais elle ne se demande pas qui devrait avoir le droit de l'utiliser, sauf si vous le lui dites.

La sécurité au niveau des lignes, en clair

Les applis construites ainsi parlent souvent à la base de données directement depuis le navigateur, avec une clé publique par conception. Ce qui empêche un inconnu d'utiliser cette clé pour tout lire, c'est la sécurité au niveau des lignes (row-level security) : des règles internes à la base de données qui décident, ligne par ligne, qui peut lire ou modifier quoi. Le backend intégré de Lovable et la base de Bolt utilisent tous deux ces règles Postgres, le même modèle que Supabase.

La documentation de Supabase est directe. Une table d'un schéma exposé sans RLS « is readable and writable by any role with a grant on it » (« est lisible et modifiable par tout rôle disposant d'un droit dessus ») (Supabase). Une fois la RLS activée, la clé publique ne voit rien tant qu'une politique ne l'autorise pas. Une politique est courte. Celle-ci, du type que votre builder devrait écrire pour une table de commandes, permet à chaque utilisateur connecté de ne lire que ses propres lignes :

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

Vous n'avez pas à l'écrire. En revanche, vous devez vérifier qu'il en existe une pour chaque table. La clé secrète, ou « service role », contourne totalement ces règles : elle ne doit donc jamais figurer dans le code du navigateur. Et tout ce qui se trouve dans votre front end, y compris un contrôle du genre « cet utilisateur est-il admin ? », peut être modifié par la personne qui utilise l'appli, ce pour quoi la documentation de Lovable dit que le code front end ne doit jamais prendre de décisions de sécurité.

Un processus de construction sûr, étape par étape

Cet ordre garde les erreurs peu coûteuses : de fausses données jusqu'à la dernière étape, de vraies personnes seulement à la fin.

1. 1Rédigez un cahier des charges d'une page avant le premier prompt. Dites qui utilise l'appli, listez les cinq ou six écrans, précisez ce que chaque type d'utilisateur peut voir et modifier, et nommez ce qui est hors périmètre. Collez-le en mode plan et demandez à l'outil d'y chercher les failles.
2. 2Prototypez avec de fausses données. Construisez les écrans et les parcours avec des enregistrements inventés, gardez le projet privé et montrez-le à ceux qui s'en serviront. Changez de cap maintenant, tant qu'un changement coûte un message.
3. 3Décrivez le modèle de données avec des mots simples. Listez chaque type d'enregistrement (clients, commandes, notes) et son propriétaire, puis demandez à l'outil de créer les tables et d'expliquer, table par table, qui peut lire et modifier les lignes. Si une réponse est « n'importe qui », corrigez avant d'avancer.
4. 4Ajoutez l'inscription et les permissions dans la même étape, puis relisez les règles. Base44, par exemple, accepte des règles écrites en phrases, comme « Only the person who submitted an order should be able to see it » (« Seule la personne qui a passé une commande doit pouvoir la voir »).
5. 5Testez avec deux comptes et de fausses données. Inscrivez-vous en tant qu'Alice, puis en tant que Bob. Sous le compte de Bob, essayez d'ouvrir les fiches d'Alice, modifiez le numéro d'enregistrement dans la barre d'adresse et utilisez l'appli déconnecté. Tout ce que Bob atteint sans y avoir droit est un bug, quel que soit l'aspect du code.
6. 6Passez l'étape sécurité. Utilisez le scan intégré, corrigez chaque problème critique, puis parcourez la checklist de la section suivante. L'audit complet de Bolt ne consomme aucun token quand on le lance depuis le menu Publish. Si l'appli contient des données personnelles de clients, c'est ici qu'un ingénieur la relit.
7. 7Lancez petit, avec des garde-fous. Invitez d'abord une poignée de vrais utilisateurs, fixez des limites de dépense, vérifiez que les sauvegardes et le retour en arrière fonctionnent, et supprimez les faux comptes.

Vous ne savez pas à quel barreau correspond votre idée ? L'arbre ci-dessous vous donne une réponse en trois questions maximum.

Si l'arbre vous envoie vers un ingénieur, le prototype n'est pas perdu. Une maquette fonctionnelle accompagnée d'un cahier des charges est le brief le plus clair qu'un développeur puisse recevoir.

La checklist de sécurité avant lancement

Passez-la en revue avant que quiconque en dehors de vos comptes de test reçoive un lien. Rien ne vous oblige à lire du code. Chaque point est un réglage à regarder, un scan à lancer ou un test à faire.

Deux points font l'essentiel du travail. La sécurité au niveau des lignes sur chaque table se vérifie dans la vue base de données ou sécurité de votre builder, et Bolt signale les règles « always true », c'est-à-dire celles qui laissent entrer tout le monde. Le test avec un second compte détecte ce que les scanners ratent, comme le contrôle d'accès à l'envers de l'appli Lovable évoquée plus haut.

Le reste est rapide. Bolt active par défaut la protection contre les mots de passe compromis, et le scan de Lovable avant publication le signale quand elle est désactivée. Dans Lovable, tout ce qui porte un préfixe VITE_ finit dans le navigateur : une clé secrète ne doit donc jamais en avoir un.

Les scans ont des limites, et les éditeurs le disent. La documentation de Lovable précise que ses outils « cannot guarantee complete security » (« ne peuvent pas garantir une sécurité complète ») et recommande une revue par un professionnel pour les applis qui traitent des données sensibles. Celle de Base44 est plus brève : vous êtes responsable des paramètres de sécurité de votre appli.

Passer le projet à un développeur

Une appli vibe-codée qui fonctionne aura tôt ou tard besoin d'un ingénieur, pour la relire ou pour en prendre la charge. Préparez la passation dès le premier jour.

Connectez tôt un dépôt GitHub. La synchro bidirectionnelle de Lovable fonctionne sur tous les plans, et un développeur peut cloner le dépôt et continuer à travailler dans son propre éditeur. Celle de Base44 démarre avec son plan Builder. Dans v0, un dépôt connecté devient la source de vérité, et v0 pousse ses changements sur une branche de travail plutôt que directement sur la branche de départ. Bolt synchronise lui aussi ses commits avec GitHub.

Sachez ce que le code laisse derrière lui. La documentation de Lovable indique que ni la synchro Git ni le téléchargement du code n'incluent les données de votre base, et son guide d'hébergement ailleurs vous demande de déplacer les fichiers de stockage à la main. Base44 affirme que rien n'est verrouillé sur sa plateforme et que la synchro GitHub exporte l'intégralité du code source. Sa documentation développeur décrit aussi un SDK que les projets exportés utilisent pour accéder aux services propres de Base44 pour les données et les fonctions backend. C'est notre lecture, pas une affirmation de Base44 : quitter complètement Base44 peut impliquer de remplacer cette couche.

Remettez au développeur un court dossier de passation :

• Le cahier des charges, avec chaque écran et qui peut l'utiliser.
• L'accès au dépôt et au projet dans le builder.
• Une liste en langage clair de chaque table et de qui devrait pouvoir la lire et la modifier.
• Les intégrations que vous avez ajoutées et les noms des secrets qu'elles utilisent, jamais les valeurs elles-mêmes dans un chat ou un e-mail.
• Les bugs connus, les contournements bizarres que vous avez obtenus par prompt, et ce que le projet a coûté en crédits jusqu'ici.

Demandez une revue de sécurité avant d'ajouter de nouvelles fonctionnalités : règles d'accès, fonctions côté serveur et emplacement des secrets. La plupart des développeurs ouvriront le dépôt dans un outil de code comme Cursor ou Claude Code. Notre comparatif des assistants de code et assistants de code IA ou builders d'agents expliquent en quoi ces outils diffèrent des builders d'applis, et le classement des assistants de code IA passe en revue le secteur.

Questions fréquentes

Suis-je propriétaire du code qu'écrit un outil de vibe coding ?

Lovable, Base44, Bolt et v0 synchronisent tous le code vers un dépôt GitHub que vous contrôlez, Base44 à partir de son plan Builder. Posséder le code n'est toutefois pas la même chose que posséder l'appli en production. Vos données, vos fichiers stockés et vos services backend peuvent rester sur la plateforme tant que personne ne les migre.

Quel outil de vibe coding est le moins cher pour démarrer ?

Les cinq ont une offre gratuite. Lovable donne aux utilisateurs gratuits 5 crédits de build par jour, plafonnés à 30 par mois, et le mode Free de Replit fonctionne sur ses plans individuels gratuit et payants, avec des limites fixées par le plan. Parmi les plans payants, Starter de Base44 est affiché à 16 $ par mois facturés annuellement et Replit Core à 20 $ par mois.

Puis-je encaisser des paiements dans une appli vibe-codée ?

Oui, via un checkout hébergé. L'intégration Stripe de Lovable ouvre Stripe Checkout et stocke votre clé secrète comme secret backend, pas dans le code de l'appli. Testez d'abord avec des clés sandbox et la carte de test de Stripe. La facturation à l'usage, les versements à d'autres utilisateurs et la facturation de comptes multi-entreprises sont du ressort des ingénieurs.

L'IA peut-elle vérifier elle-même la sécurité de son code ?

En partie. Les scans intégrés détectent les problèmes courants comme les règles d'accès manquantes, les clés exposées et les paquets vulnérables. Mais les éditeurs reconnaissent que les scans ne peuvent pas garantir la sécurité, et l'appli qui a laissé fuiter 18 697 fiches se trouvait sur une plateforme proposant un scan gratuit avant publication. Voyez le scan comme un plancher, pas comme une validation.

Qu'est-il arrivé à Firebase Studio ?

Google le ferme. Il ne crée plus de nouveaux espaces de travail, il fermera en 2027, et Google indique aux utilisateurs qu'ils peuvent migrer leurs espaces existants vers Google AI Studio ou Antigravity. Les services Firebase comme Firestore et Authentication continuent de fonctionner comme avant.