Du vibe coding à l’application en production
Lovable, Bolt ou Cursor permettent de construire vite une application qui fonctionne. Nous vérifions ce que l’outil a généré (sécurité, données, tests, déploiement), puis nous vous la remettons en production, documentée et maintenable, sous l’encadrement de nos leads techniques.
Visio de 30 minutes, gratuite et sans engagement, suivie d’un récapitulatif écrit avec un ordre de grandeur.
Ce que nous réalisons
Les outils de « vibe coding » ont changé la manière de lancer un produit. Une idée devient en quelques jours une application cliquable, avec ses écrans, ses comptes utilisateurs et sa base de données. C’est un excellent moyen de tester un usage, de convaincre des premiers clients ou de clarifier un besoin, et le code produit est souvent une base tout à fait exploitable.
Ce que ces outils ne garantissent pas, c’est ce que la production exige : des règles d’accès qui protègent réellement les données, des secrets qui ne quittent pas le serveur, un schéma de base de données versionné, des tests sur les parcours critiques, un déploiement reproductible et un code qu’un autre développeur peut comprendre. Notre travail consiste à ajouter ces éléments, en conservant tout ce qui fonctionne déjà.
Lecture du dépôt, des dépendances, de la structure des composants et de la logique métier. Nous identifions ce qui peut être conservé tel quel, ce qui doit être restructuré et les quelques points qui bloquent une mise en production.
Clés et secrets exposés, règles d’accès Supabase ou Firebase, authentification, droits par rôle, validation des données côté serveur, appels aux services tiers. Les corrections de sécurité passent en premier.
Migrations de base de données versionnées, gestion des erreurs, tests automatisés sur les parcours qui comptent pour votre activité, environnements séparés pour développer, recetter et exploiter.
Chaîne de déploiement, hébergement adapté, supervision, sauvegardes et documentation. Vous gardez la propriété du code et une application que votre équipe, ou la nôtre, peut faire évoluer.
Les signaux à reconnaître
Une application générée par IA peut sembler terminée alors qu’elle n’a jamais été confrontée à de vrais utilisateurs. Ces situations indiquent qu’une reprise technique est nécessaire avant d’ouvrir l’accès, ou rapidement si l’application est déjà utilisée.
L’outil corrige un écran et en dérègle un autre. Les prompts successifs ont empilé des variantes de la même logique, et plus personne ne sait laquelle s’applique.
Les tables ont été créées au fil des demandes, sans vérification des règles d’accès. Un utilisateur connecté peut parfois consulter ou modifier les données d’un autre.
Une clé d’API de paiement, d’envoi d’e-mails ou de modèle d’IA est appelée depuis le code front-end. Toute personne qui inspecte la page peut la récupérer et l’utiliser.
Des colonnes ajoutées depuis la console, aucun historique des changements, pas de sauvegarde vérifiée. Impossible de reconstruire l’environnement ou de revenir en arrière.
Elle n’existe que dans l’espace de travail de l’outil, ou sur le poste de la personne qui l’a construite. Le code n’est pas dans un dépôt que vous contrôlez.
Ce que couvre la reprise
Notre diagnostic suit l’ordre des risques. Les failles qui exposent des données passent avant les questions de confort de développement, et chaque constat débouche sur une correction concrète, estimée et priorisée.
Recherche des clés dans le code front-end et l’historique du dépôt, distinction entre clés publiques prévues pour le navigateur et clés de service à garder côté serveur, rotation des secrets exposés, déplacement des appels sensibles (paiement, e-mails, modèles d’IA) vers des fonctions serveur.
Activation et contrôle des politiques Row Level Security de Supabase table par table, revue des règles de sécurité Firestore et Storage côté Firebase, tests qui vérifient qu’un utilisateur ne lit que ses propres données.
Inscription, vérification d’adresse, réinitialisation du mot de passe, durée des sessions, rôles et administration. Les contrôles d’accès sont appliqués par le serveur ou la base, pas seulement par l’interface.
Lecture du schéma, contraintes et index manquants, données dupliquées. Mise en place de migrations versionnées dans le dépôt, de jeux de données de test et de sauvegardes dont la restauration a été vérifiée.
Tests automatisés sur les parcours critiques (inscription, paiement, création et partage de données), revue des dépendances, suppression du code mort, regroupement des composants et des logiques dupliqués.
Requêtes répétées, pages sans pagination, images et bundles trop lourds, gestion des erreurs, journaux et alertes. L’application doit rester rapide et lisible quand les données et les utilisateurs augmentent.
Lorsque l’application a été générée en React ou en Next.js, ce qui est fréquent avec ces outils, nous la reprenons avec nos équipes React et Next.js, sans changer de technologie si elle convient au produit.
Du travail aux livrables
Export du code vers un dépôt que vous possédez, inventaire des services utilisés (base de données, authentification, paiement, e-mails, hébergement), lecture du code et tests des parcours. Vous obtenez une liste des risques classés par gravité et un plan de reprise chiffré.
Rotation des secrets exposés, règles d’accès, contrôles côté serveur. Si l’application est déjà ouverte au public, ces corrections sont livrées en priorité, avant toute nouvelle fonctionnalité.
Migrations versionnées, environnements séparés, tests automatisés, restructuration des parties fragiles du code et documentation. Les évolutions sont livrées par étapes et démontrées.
Déploiement automatisé, supervision, sauvegardes, nom de domaine et accès administrateurs à votre nom. Une passation documentée permet à votre équipe de reprendre la main, ou de nous confier la suite.
La réalisation en pratique
Nous faisons évoluer le produit voyageurs en React et Flutter, et nous avons construit de zéro une plateforme d’affiliation pour les partenaires BtoB.
Une plateforme en Java et React, développée par une équipe où développeurs et experts réglementaires travaillent ensemble.
Les choix qui comptent
Une application générée par IA n’a pas besoin d’être réécrite par principe. Dans bien des cas, l’interface, les parcours et une partie de la logique peuvent être conservés, et l’effort se concentre sur la sécurité, la base de données, les tests et le déploiement. Le diagnostic distingue ce qui se garde, ce qui se restructure et les rares parties qu’il vaut mieux reconstruire, par exemple une logique de paiement ou de droits devenue impossible à vérifier.
Le choix de l’hébergement fait partie de la reprise. Rester sur l’hébergement proposé par l’outil, passer sur une plateforme d’hébergement front-end ou sur votre propre cloud : la décision dépend de vos contraintes de données, de vos coûts et de votre besoin d’indépendance. Nous pouvons prendre en charge cette partie avec notre offre DevOps et cloud management.
Si votre application repose elle-même sur un modèle d’IA, comme un assistant, un agent ou une extraction de documents, la reprise de POC IA ajoute ce qui est propre à ces usages : évaluations de la qualité des réponses, supervision et suivi des coûts d’appel aux modèles. Et si vous souhaitez seulement un état des lieux avant de décider, un audit technique peut être mené seul.
Le cadre de collaboration
Partagez un accès au code et au projet de base de données, une démonstration des parcours principaux et ce que vos utilisateurs attendent. Le diagnostic est mené par nos ingénieurs, encadrés par nos leads techniques, puis la reprise est pilotée en projet au forfait, avec un interlocuteur identifié, sur un périmètre défini.
Si le produit n’en est qu’au stade de l’idée, ou si le prototype ne peut pas être repris, nous pouvons aussi construire un MVP sur-mesure en repartant de ce que votre prototype a permis d’apprendre. Pour un prototype construit autour de l’IA, consultez aussi notre offre de reprise de POC IA, jusqu’à la production.
Questions fréquentes
Oui, à condition de vérifier ce que l’outil a généré. Le code produit par Lovable, Bolt ou v0 peut servir de base à une application en production. Il faut en revanche contrôler les règles d’accès aux données, l’authentification, la gestion des secrets et la base de données, ajouter des tests et un déploiement maîtrisé, puis mettre en place supervision et sauvegardes.
Rarement. Le diagnostic indique ce qui peut être conservé, ce qui doit être restructuré et ce qu’il vaut mieux reconstruire. Une réécriture complète ne se justifie que si le code est devenu impossible à faire évoluer ou à vérifier, et nous vous l’indiquons avec les raisons et l’effort associé.
Cela dépend de ses politiques Row Level Security. La clé publique de Supabase est conçue pour être utilisée dans le navigateur, mais elle ne protège rien si les tables n’ont pas de règles d’accès adaptées. Nous vérifions chaque table, testons qu’un utilisateur ne peut lire ou modifier que ce qui lui revient et nous assurons que la clé de service n’est jamais exposée côté client. Le même travail s’applique aux règles de sécurité de Firebase.
À vous. La première étape de la reprise consiste à placer le code dans un dépôt que vous possédez et à mettre les comptes de base de données, d’hébergement et de nom de domaine à votre nom. Le code que nous écrivons ensuite vous appartient également, avec la documentation nécessaire pour le reprendre.
Oui, ces outils restent utiles pour prototyper de nouveaux écrans ou accélérer le développement. Nous recommandons simplement que les modifications passent par le dépôt, les tests et une revue de code avant d’atteindre la production, pour ne pas réintroduire les problèmes corrigés.
Cela dépend de la taille de l’application, de l’état de sa base de données, du nombre de services connectés et du fait qu’elle soit déjà utilisée ou non. Le diagnostic initial permet de chiffrer un plan de reprise par étapes, en commençant par les corrections de sécurité.
Votre application fonctionne. Rendons-la fiable.
Montrez-nous votre application, l’outil qui l’a générée et ce que vous attendez de sa mise en production. Nous vous dirons ce qu’il faut reprendre pour l’ouvrir sereinement à vos utilisateurs.