Du vibe coding à la production : ce qui change vraiment

Le vibe coding et la règle des 80/20

Le vibe coding, c’est créer un logiciel en décrivant ce que vous voulez à un outil d’IA, qui en génère le code. Lovable, Bolt, Replit et les outils du même genre ont rendu la méthode étonnamment efficace : décrivez un outil de gestion clients, un système de réservation ou un tableau de bord interne, et vous avez un prototype qui fonctionne en quelques heures.

Le problème, c’est que « qui fonctionne » et « prêt pour la production », ce n’est pas la même chose. Un prototype qui fonctionne gère le parcours où tout se passe bien. Une app de production gère ce parcours-là, mais aussi celui des erreurs, celui de la sécurité, celui de la surveillance, celui du paiement, et celui de la question « que se passe-t-il à 3 h du matin si la connexion à la base tombe ? »

C’est le partage 80/20 qui piège tous ceux qui font du vibe coding. Les premiers 80 % des fonctionnalités demandent 20 % de l’effort total. Les 20 % restants (rendre l’app sûre, fiable et professionnelle) absorbent les 80 % d’effort qui restent.

Ce qui change quand vous passez en production

La sécurité n’est plus facultative

Au stade du prototype, il peut manquer des policies RLS (la sécurité au niveau des lignes de Supabase), traîner des clés d’API écrites en dur, ou manquer l’authentification sur certaines routes. Tant que vous êtes le seul utilisateur, ce n’est pas grave. Dès que quelqu’un d’autre se connecte, ce sont des failles critiques.

Un freelance avait créé dans Lovable un outil de gestion de factures. Pendant les tests du prototype, avec ses propres données, tout était parfait. En accueillant son premier client, il s’est aperçu que le client A pouvait voir les factures du client B via l’API. Les policies RLS n’avaient jamais été mises en place, puisque le prototype n’avait qu’un seul utilisateur.

La gestion des erreurs devient concrète

Le code généré par l’IA gère en général le parcours où tout se passe bien. Quand un appel d’API échoue, quand une requête à la base renvoie des données inattendues, quand un utilisateur envoie deux fois un formulaire, le code généré ne fait souvent rien, ou plante.

En production, ces cas limites arrivent en permanence. Un créateur dont l’app Lovable comptait 100 utilisateurs actifs racontait qu’elle « cassait au hasard » chez certains. La cause : une API tierce qui renvoyait de temps en temps des erreurs 500. Le code généré ne prévoyait ni nouvelle tentative, ni écran d’erreur : les utilisateurs concernés tombaient sur une page blanche.

La surveillance devient indispensable

Au stade du prototype, vous savez quand quelque chose casse, puisque c’est vous qui utilisez l’app. En production, vos utilisateurs s’en servent pendant que vous dormez.

Sans surveillance, vous découvrez les problèmes quand les utilisateurs se plaignent (ou pire, quand ils partent sans rien dire). Une surveillance de base, c’est : des contrôles de disponibilité (l’app est-elle accessible ?), le suivi des erreurs (y a-t-il des erreurs ?) et la mesure de l’usage (les gens se servent-ils vraiment des fonctionnalités ?).

Les performances comptent

Un prototype avec 1 utilisateur se charge instantanément. La même app avec 50 utilisateurs simultanés peut ralentir si les requêtes à la base ne sont pas optimisées, si les appels d’API sont trop nombreux ou si les ressources statiques ne sont pas mises en cache.

Les apps Lovable hébergées sur Vercel encaissent en général bien un trafic modéré. Mais si vos requêtes ne s’appuient pas sur des index, ou si vos Edge Functions font des appels externes inutiles, les performances se dégradent vite.

La passerelle : ce qu’il faut vraiment faire

Étape 1 : verrouiller la sécurité (2 à 4 heures)

Activez la RLS sur chaque table. Rangez toutes les clés d’API dans les Secrets. Ajoutez l’authentification sur les routes protégées. Passez la Security View de Lovable. C’est le minimum de sécurité pour toute app en production.

Étape 2 : gérer les erreurs sur les parcours critiques (2 à 4 heures)

Repérez les 3 à 5 parcours les plus importants de votre app (inscription, fonctionnalité principale, paiement). Ajoutez à chacun une gestion des erreurs : de nouvelles tentatives pour les appels d’API, des messages d’erreur compréhensibles et un affichage de repli quand les données sont indisponibles.

Étape 3 : mettre en place la surveillance (1 heure)

Ajoutez Sentry pour le suivi des erreurs (l’offre gratuite est généreuse), UptimeRobot pour la surveillance de la disponibilité (gratuit jusqu’à 50 sondes) et Vercel Analytics pour l’usage (inclus avec l’hébergement Vercel). Vous savez désormais quand quelque chose casse, avant que vos utilisateurs ne vous le disent.

Étape 4 : tester avec de vraies données (2 à 4 heures)

Créez des comptes de test qui simulent un usage réel. Déroulez chaque parcours utilisateur. Testez sur différents navigateurs et appareils. Invitez 2 ou 3 utilisateurs de confiance pour une période de bêta avant le lancement complet.

Étape 5 : mettre en place les paiements (2 à 4 heures)

Si vous faites payer votre app, intégrez Stripe. Utilisez Stripe Checkout (plutôt que des formulaires maison) pour limiter la complexité. Traitez les webhooks pour tenir à jour le statut des abonnements, et ouvrez l’accès selon le statut de paiement.

Pourquoi le temps est multiplié

Le prototype vous a pris un week-end. Le consolider pour la production prend 2 à 4 semaines de travail concentré. Ce temps multiplié par 10 à 30 n’est pas un échec du vibe coding : c’est la nature même d’un logiciel en production. Les développeurs classiques subissent le même multiplicateur ; ils l’étalent simplement sur des mois, au lieu de le découvrir d’un seul coup.

L’avantage du vibe coding, c’est d’avoir validé l’idée en un week-end au lieu de 3 mois. Vous n’investissez maintenant le temps de la mise en production que dans des idées qui ont fait leurs preuves.

Réduire l’écart

BWorlds existe précisément pour réduire cet écart de 10 à 30 fois. Au lieu de vérifier à la main la sécurité, la surveillance et la préparation à la production, BWorlds automatise l’analyse et vous remet la liste de ce qu’il faut corriger, classée par priorité. Des semaines d’incertitude deviennent un après-midi de travail clair et concentré.