De Bolt à la production : notre checklist de reprise d'une app générée par IA

Une reprise d’application Bolt consiste à transformer un produit généré par un outil de vibe coding en logiciel exploitable en production, sans repartir de zéro : on vérifie l’authentification, l’isolation des données entre clients, le RGPD, les tests, l’intégration continue, l’observabilité et les performances, puis on corrige dans cet ordre. La même checklist vaut pour une application Lovable, v0, Replit ou Cursor déjà en ligne, et elle décide de ce qui est conservé et de ce qui est remplacé.

Bolt produit vite une interface React ou Next.js adossée à Supabase et déployée sur Vercel. Le résultat fonctionne pour un utilisateur connecté sur un seul compte, parce que c’est ce que le générateur optimise : le parcours nominal. Les questions qui arrivent ensuite (plusieurs organisations dans la même base, des rôles, des données personnelles, des appels à un LLM facturés au token) n’ont pas été posées.

Voici les contrôles à passer, les critères pour décider entre garder la base et réécrire, et l’ordre de travail.

Que vérifier avant de mettre une application Bolt en production ?

L’inventaire se fait du plus critique au plus confortable : chaque point qui échoue devient une ligne du plan.

1. Authentification côté serveur. Un contrôle fait dans le navigateur ne protège rien : chaque route doit être autorisée par le serveur, la session portée par un cookie httpOnly, et aucun compte administrateur créé sans validation.
2. Isolation des données entre clients. Dans Supabase, cela suppose des politiques RLS sur chaque table et un filtre par organisation dans la requête. Le test qui tranche : avec un jeton du compte A, tentez de lire une donnée du compte B. Si elle arrive, la fuite est ouverte.
3. Clés et secrets. La clé de service Supabase et les clés de modèles ne doivent jamais partir dans le navigateur : appels depuis une fonction serveur, rotation des clés, plafond de dépense par compte.
4. Rôles et permissions. La hiérarchie (administrateur, membre, lecteur) est vérifiée côté serveur à chaque action, et les opérations sensibles laissent une trace horodatée.
5. Données personnelles et RGPD. Registre des traitements, base légale, durées de conservation, accords de traitement avec Supabase, Vercel et le fournisseur du modèle, hébergement. Un agent IA ou une brique RAG qui reçoit des données personnelles entre dans ce périmètre.
6. Tests sur les parcours critiques. Inscription, connexion, paiement, génération : un test de bout en bout par parcours qui rapporte de l’argent, rejoué à chaque déploiement.
7. Intégration continue et environnements. Un dépôt Git unique, une préproduction, une CI (GitHub Actions par exemple) qui bloque la mise en production si un test échoue, et une image Docker pour reproduire l’environnement à l’identique.
8. Observabilité. Logs structurés, traces des appels de modèles avec Langfuse ou OpenTelemetry, alertes sur trois signaux : taux d’erreur, latence p95, coût par utilisateur.
9. Performances. Index manquants sur les colonnes filtrées, requêtes en boucle, absence de cache, index vectoriels oubliés si l’application utilise pgvector pour la recherche sémantique.
10. Sauvegardes et migrations. Une sauvegarde jamais restaurée ne vaut rien : testez-en une. Les migrations de schéma vivent dans le dépôt, versionnées.

Faut-il tout réécrire ou garder le code généré par Bolt ?

Gardez la base dans la très grande majorité des cas. Le code produit par ces outils est souvent du React ou du Next.js lisible, avec un schéma correct sur les entités principales, validé par vos utilisateurs : le réécrire efface les corrections apportées sur le terrain et rouvre les mêmes défauts plus tard.

Trois critères suffisent pour trancher :

• L’isolation est-elle réparable ? Ajouter des politiques RLS et un filtre par organisation ne touche pas aux écrans. Un schéma où aucune donnée n’est rattachée au client se reprend à la main.
• La logique métier est-elle testable ? Si les règles de prix, de droits ou de calcul sont dispersées dans les composants, il faut extraire une couche métier ; le reste du code reste en place.
• La dette est-elle localisée ? Un module à reprendre se traite en priorité. Un code incohérent dans toutes les couches justifie un redémarrage partiel, jamais complet.

Réécrire coûte le temps de reconstruction plus la remise au niveau des fonctions déjà utilisées. Vous pouvez continuer à développer avec Cursor ou Claude Code après la reprise, à condition que les tests et les règles du projet vivent dans le dépôt. Pour un exemple de passage à l’échelle, du projet vibe coded au produit en production détaille les étapes et les critères de décision. Un exemple de mise en production: la reprise d’un SaaS construit avec Lovable montre le même enchaînement.

Authentification, multi-tenant et RGPD : ce qui bloque une mise en production

Ce qui arrête une mise en production n’est presque jamais l’interface : c’est le cloisonnement des données. Le code généré suppose un seul client, souvent un seul rôle. Dès la deuxième organisation, les fonctions écrites pour le cas nominal laissent passer des données d’un compte à l’autre, faute de filtre par client dans la requête.

Trois contrôles ferment cette porte. Les droits vérifiés côté serveur, jamais dans le navigateur. Le filtre par organisation testé automatiquement : une requête qui l’ignore fait échouer la CI. Un compte d’administration distinct du compte d’usage courant.

Le volet RGPD se traite en même temps, car il porte sur les mêmes tables : minimiser les données collectées, limiter les durées de conservation, documenter les traitements, savoir où elles sont hébergées. Les écarts se ressemblent d’un projet à l’autre : les failles d’une application vibe codée en production décrivent les cinq points à corriger en premier.

Comment tester et surveiller une application reprise ?

On installe le filet avant de modifier le code, pas après : des tests de bout en bout sur les parcours qui rapportent, et pour les fonctions d’IA un jeu de cas réels rejoué à chaque changement de prompt ou de modèle, ce qu’on appelle des evals. Une première chaîne d’intégration continue est décrite pas à pas dans ce guide sur la CI/CD des agents IA.

Vient ensuite la surveillance, qui relève du LLMOps autant que de l’exploitation : traces des appels de modèles, coût par conversation, taux d’escalade humaine, latence, alertes avant que les utilisateurs ne signalent le problème. La démarche complète (evals, garde-fous, observabilité, déploiement progressif) est sur la page méthode d’industrialisation d’un projet IA.

Combien de temps prend une reprise, et combien ça coûte ?

Quelques jours pour les urgences (fuite d’isolation, clé exposée, panne bloquante), deux à cinq semaines pour l’industrialisation complète d’une application de taille moyenne. Le point de départ est un état des lieux facturé, sur pièce : Check-up à 350 € en une journée pour les risques prioritaires, ou Audit de reprise à 750 € en 3 jours pour le plan d’action chiffré, check-up déduit s’il a été fait. La stabilisation est ensuite chiffrée au forfait, à partir de l’audit.

À mettre en face : le coût d’une réécriture et le risque d’une fuite entre deux clients. Le détail est sur la page des tarifs de reprise et d’industrialisation.

Par où commencer cette semaine

Trois actions, dans cet ordre. Listez les parcours qui génèrent du chiffre, puis refaites-les avec un second compte en tentant de lire les données du premier : c’est le test le plus rapide pour savoir si l’isolation tient. Vérifiez ensuite vos politiques d’accès dans Supabase, l’emplacement de vos clés et votre déploiement. Décidez enfin ce que vous gardez et ce qu’il faut reprendre.

Si vous préférez confier la reprise d’une application générée par IA (Lovable, Bolt, v0, Cursor) à une équipe habituée à ces bases de code, la page décrit le déroulé : état des lieux, critères de sortie écrits avant de commencer, stabilisation sans arrêt de la production, passation documentée à votre équipe.