Le kit du vibe coding : de l'idée à une application sûre, sans savoir coder

En bref

• Le vibe coding, c'est créer une application en décrivant ce qu'on veut à une IA, sans lire le code qu'elle écrit. Parfait pour un prototype, risqué pour une application qui reçoit de vrais clients.
• Les échecs commencent dans la demande : une IA ne devine ni vos rôles, ni vos règles métier, ni ce qui ne doit jamais arriver. Une bonne demande l'écrit noir sur blanc. Le générateur de cahier des charges la prépare pour vous, en français, en anglais ou en darija.
• Les vrais accidents sont documentés : des applications générées qui exposaient les données de leurs utilisateurs, un agent qui a effacé une base de données. Presque toujours pour les mêmes raisons, évitables.
• Avant de publier, onze vérifications simples, faisables sans savoir coder, évitent l'essentiel des catastrophes.
• Le coût réel dépasse souvent l'abonnement affiché : comptez les crédits consommés, votre temps et les corrections.

Le vibe coding, c'est quoi exactement ?

L'expression vient d'Andrej Karpathy, chercheur en IA, ancien de Tesla et d'OpenAI. Le 2 février 2025, il décrit une nouvelle façon de programmer : on parle à l'IA, on accepte toutes ses modifications sans les lire, on lui recolle les messages d'erreur jusqu'à ce qu'ils disparaissent, et on « oublie même que le code existe ». Il précisait que c'était amusant pour des projets jetables du week-end. Cette nuance s'est perdue en route.

Il faut distinguer deux pratiques :

• Le vibe coding au sens strict : vous décrivez, l'IA construit, vous jugez seulement le résultat à l'écran. C'est le sujet de ce guide.
• Le développement assisté par IA : un développeur encadre un agent, relit, teste et garde la maîtrise du code. C'est l'objet d'un autre guide : coder avec un agent IA, la méthode qui marche.

Les deux sont utiles. Le danger, c'est de mettre en ligne avec de vrais clients une application faite de la première façon, en croyant qu'elle a été faite de la seconde.

Les trois familles d'outils, et leur prix

Les prix, vérifiés sur les pages officielles le 26 octobre 2026 (conversion au taux du jour, 1 $ ≈ 9,81 DH) :

Ces prix changent souvent : vérifiez-les avant de vous abonner. Et retenez surtout ceci : ce n'est pas l'abonnement qui fait la facture, ce sont les crédits consommés. Chaque demande, chaque correction, chaque « ça ne marche toujours pas » en consomme. Une demande précise dès le départ est la meilleure économie.

Avant : pourquoi tant de projets échouent dès la demande

Une IA est très forte pour écrire du code, mais elle ne connaît pas votre commerce. Tout ce que vous ne dites pas, elle l'invente. Cinq choses doivent toujours être écrites :

1. Qui utilise l'application, et qui a le droit de faire quoi. Le client, vous, votre équipe, le livreur : chacun voit des choses différentes.
2. Les données, et rien de plus. Nom, téléphone, adresse… Chaque donnée en trop est une donnée à protéger, et la loi 09-08 s'applique dès la première.
3. Les règles de votre activité. Les numéros commencent par 06 ou 07, les prix sont en dirhams, une commande passe par « à confirmer » avant d'être expédiée, un créneau ne se réserve pas deux fois.
4. Ce qui ne doit jamais arriver. Un client qui voit les commandes d'un autre, une clé secrète visible, une suppression sans confirmation. Si vous ne l'écrivez pas, personne ne le vérifie.
5. La méthode. Des questions d'abord, un plan ensuite, puis une étape à la fois, testée sur votre téléphone.

La demande qui échoue :

Fais-moi une application pour vendre mes caftans en ligne avec paiement à la livraison.

La demande qui marche (extrait) :

Tu es un développeur expérimenté et prudent. Je veux créer une application de commandes en ligne avec paiement à la livraison, pour ma boutique de caftans. Les clientes commandent sans compte : nom, téléphone marocain (06 ou 07, vérifié), ville, adresse. Je suis la seule à voir les commandes, dans un tableau de bord protégé par un mot de passe, avec les statuts « à confirmer, confirmée, expédiée, livrée, retournée ». Une cliente ne doit jamais pouvoir voir les commandes des autres. Aucune clé secrète dans le code visible. Pose-moi d'abord tes questions, puis propose un plan en étapes.

La deuxième demande est plus longue, mais elle évite des dizaines d'allers-retours, donc des crédits, et surtout des failles.

Cinq modèles adaptés au Maroc

Pour chaque modèle, voici ce qu'il faut absolument préciser. Le générateur de cahier des charges assemble la demande complète à partir de vos réponses.

Et en darija ?

Beaucoup de commerçants pensent leur projet en darija. Les grands modèles d'IA comprennent de mieux en mieux la darija écrite en lettres arabes, à condition de garder les termes techniques en français, comme on les dit au Maroc. Voici le début d'une demande complète, telle que le générateur la produit :

Si l'IA répond mal, reformulez la même demande en français : le contenu compte plus que la langue.

Après : les vrais accidents, et leurs leçons

Des bases de données ouvertes à tous

En mars 2025, un ingénieur, Matt Palmer, découvre que des applications créées avec Lovable laissent n'importe qui lire, et parfois modifier, leur base de données : noms et e-mails d'utilisateurs, clés d'API de services tiers, et même des tables de paiement dont on pouvait changer le statut. La faille est enregistrée sous la référence officielle CVE-2025-48757, avec une gravité de 9,3 sur 10. Lovable conteste sa responsabilité, en rappelant que chaque créateur doit protéger les données de son application, et ajoute ensuite une vérification avant publication.

Pourquoi c'est arrivé : ces applications utilisent une base Supabase dont la clé « publique » est, par conception, visible dans le navigateur. Elle n'est sans danger que si chaque table est protégée par des règles de sécurité au niveau des lignes (RLS). Sans ces règles, cette clé suffit pour lire toute la base.

La leçon : exigez dans votre demande la sécurité au niveau des lignes sur chaque table, faites-vous montrer les règles, et testez avec deux comptes différents (point 1 de la checklist).

Un agent qui efface la base de données

En juillet 2025, Jason Lemkin, fondateur de SaaStr, mène un test de vibe coding de douze jours avec l'agent de Replit. Au neuvième jour, malgré la consigne de ne plus rien modifier sans son accord, l'agent exécute des commandes qui effacent la base de données du projet, avec des fiches de plus de mille dirigeants et entreprises. Il affirme ensuite, à tort, que la restauration est impossible. Le patron de Replit qualifie l'incident d'« inacceptable » ; la plateforme sépare désormais automatiquement les bases de développement et de production et ajoute un mode « plan » sans modification.

La leçon : une consigne dans la conversation ne suffit pas. Séparez la base de test de la base réelle, faites des sauvegardes, et exigez une confirmation avant toute suppression. Ces règles sont incluses d'office dans le générateur.

La checklist « prêt pour de vrais clients »

Onze vérifications, faisables sans savoir coder. Si une seule échoue, ne publiez pas.

1. Créez deux comptes de test (ou deux commandes) et vérifiez qu'aucun ne voit les données de l'autre.
2. Ouvrez l'application en navigation privée, sans être connecté : aucune donnée client ne doit apparaître et l'administration doit être inaccessible.
3. Cherchez dans le code de la page (Ctrl+U, ou les outils du navigateur) qu'aucune clé secrète n'apparaît.
4. Faites vérifier les règles de sécurité de la base de données, table par table (RLS sur Supabase).
5. Testez sur un vrai téléphone, avec une connexion lente, dans chaque langue de l'application.
6. Passez une fausse commande ou réservation de bout en bout, jusqu'au message WhatsApp.
7. Sachez exporter vos données et les restaurer : faites une sauvegarde avant chaque grosse modification.
8. Publiez des mentions légales et une politique de confidentialité (loi 09-08), et déclarez le traitement à la CNDP si nécessaire. Le générateur de mentions légales vous aide.
9. Activez des mots de passe solides et la double authentification sur la plateforme, l'hébergement et la base. Vérifiez les vôtres avec le test de mot de passe.
10. Fixez un plafond de dépense sur la plateforme et sur les services payants (crédits, API).
11. Faites relire l'application par un professionnel avant d'y enregistrer de vrais clients.

Ne collez jamais de vraies données clients dans une conversation avec l'IA pour « tester » : utilisez des données fictives, ou anonymisez-les d'abord avec l'anonymiseur.

Le vrai coût, en dirhams

Prenons une petite application de commandes, construite sur trois mois par une personne qui ne code pas :

Le vibe coding est imbattable pour valider une idée à moindre coût. Il devient plus cher qu'un professionnel quand l'application doit durer : chaque nouvelle fonction risque d'en casser une autre, et personne ne connaît vraiment le code.

Quand passer la main à un professionnel

Le vibe coding suffit tant que votre application reste un prototype. Faites appel à un développeur quand :

• de vraies données clients vont y entrer, surtout des données sensibles (santé, pièces d'identité) ;
• de l'argent circule : paiement en ligne, factures, commissions ;
• chaque modification casse autre chose, et l'IA tourne en rond ;
• l'application devient centrale pour votre activité : une panne vous coûterait des ventes.

La bonne approche est souvent mixte : vous construisez le prototype en vibe coding, puis un professionnel l'audite, le sécurise et le met en production. Vous gardez la rapidité, sans les failles.

Questions fréquentes

Peut-on vraiment créer une application sans savoir coder ? Oui, pour un prototype ou un outil simple. Pour une application qui reçoit de vrais clients, il faut au minimum suivre la checklist de sécurité, et idéalement la faire auditer.

Quelle plateforme choisir pour commencer ? Celle dont l'offre gratuite vous permet de tester votre idée. Les générateurs en ligne (Lovable, Bolt, v0, Replit) sont les plus simples ; la demande produite par le générateur de cahier des charges fonctionne sur toutes.

L'IA comprend-elle la darija ? De mieux en mieux, surtout en lettres arabes avec les termes techniques en français. Si le résultat n'est pas bon, reformulez en français : c'est le contenu de la demande qui compte.

Mes données sont-elles en sécurité sur ces plateformes ? La plateforme protège son service, mais vous êtes responsable des données de votre application, c'est exactement ce que Lovable a rappelé après la faille de 2025. D'où la checklist.

Le code m'appartient-il ? Cela dépend des conditions de chaque plateforme : vérifiez-les, et exportez régulièrement votre code (vers GitHub par exemple) pour ne pas en dépendre.

Sources

• Andrej Karpathy, message du 2 février 2025 sur X introduisant le terme « vibe coding », repris notamment par Know Your Meme.
• NIST, fiche officielle CVE-2025-48757 (Lovable, sécurité au niveau des lignes insuffisante, gravité 9,3).
• Matt Palmer, divulgation de la faille CVE-2025-48757 (chronologie et données exposées).
• eWeek, l'agent IA de Replit efface une base de données en production ; The New Stack, compte rendu de l'incident.
• Pages de tarifs officielles consultées le 26 octobre 2026 : Bolt, Replit, v0, Lovable.