Du Vibe Coding à la production : anatomie d’une migration réussie

Il y a quelques mois, j’ai ouvert par curiosité V0 car on avait besoin d’un CRM taillé pour notre réalité. Un outil visuel, simple et adapté à notre workflow, capable de gérer les comptes à travers les différentes entités du groupe JoliCode. En quelques prompts, j’avais une application fonctionnelle. Exactement ce que j’avais en tête. Je tiens à préciser que je ne suis pas développeur, d’où ce réflexe !

Mais voilà : c’était ma solution, un bricolage, pas notre outil de production.

Aujourd’hui, cette même application est déployée sur nos serveurs, utilisée quotidiennement par toute l’équipe, avec une authentification Google multi-structures, une base de données maîtrisée, et un système de permissions propres. Et le plus intéressant ? On a industrialisé l’idée sans repartir d’une page blanche.

Section intitulée l-app-initiale-rapide-visuelle-fonctionnelleL’app initiale : rapide, visuelle, fonctionnelle

Section intitulée pourquoi-v0Pourquoi V0 ?

V0, c’est l’outil de Vercel pour générer des applications Web à partir du langage humain. La stack générée par V0, c’est du standard moderne : React pour les interfaces, TypeScript pour la solidité du code, et des composants réutilisables bien structurés.

Pour la base de données et l’authentification, j’ai branché Supabase. Une solution backend-as-a-service qui donne une vraie base PostgreSQL avec une API déjà générée et un système d’auth clé en main. Parfait pour démarrer vite.

Section intitulée l-application-en-trois-partiesL’application en trois parties

L’interface construite est organisée autour de trois sections :

• Une checklist en Une qui affiche les actions prioritaires du jour. Les comptes à relancer. Juste l’essentiel pour démarrer la journée sans se perdre ;
• Une gestion des comptes visuels. Des cartes organisées en deux catégories : leads et clients. Chaque carte affiche les infos essentielles en un coup d’œil : nom du compte, entité du groupe concernée par cette carte, et tout l’historique des interactions ;
• Une section partenaires pour suivre nos relations avec nos partenaires. Des acteurs qu’on ne veut pas perdre de vue.

Section intitulée quand-les-limites-apparaissentQuand les limites apparaissent

L’app fonctionnait, mais :

• Le problème de propriété : le projet vivait sur mon GitHub perso, les clés API Supabase étaient dans mes variables d’environnement Vercel. Si je partais en vacances, personne ne pouvait intervenir ;
• L’authentification multi-structures : Supabase Auth, c’est génial mais pour gérer plusieurs entités avec des règles différentes sur qui peut voir quoi, qui peut éditer quel compte, c’était pas adapté ;
• L’évolution du code : Pour itérer vite au début, c’est parfait. Pour maintenir à long terme, il fallait restructurer ! L’avis d’un vrai développeur était nécessaire pour passer du POC au projet déployable.

Et c’est là que Premier Octet est intervenu.

Section intitulée la-transformation-de-prototype-a-outil-proLa transformation : de prototype à outil pro

Section intitulée reprendre-le-controle-de-l-infrastructureReprendre le contrôle de l’infrastructure

• Première étape : dockeriser la base de données. Sortir de Supabase et reprendre la main sur notre stack. L’équipe a créé un environnement Docker avec PostgreSQL. Simple, maîtrisé, reproductible. On peut désormais versionner notre infra, la déployer n’importe où, et scaler si besoin.
• Deuxième étape : passer à Prisma. Supabase génère automatiquement une API REST à partir du schéma de base de données. C’est pratique, mais ça crée une dépendance forte. Avec Prisma, on reprend le contrôle total. C’est un outil qui permet de gérer la base de données de manière type-safe, avec des migrations versionnées qu’on peut partager entre développeurs. L’équipe a généré le schéma Prisma initial à partir de ce qui existait dans Supabase. Pas de perte de données, pas de rupture.

Section intitulée refondre-l-authentificationRefondre l’authentification

L’équipe a intégré Better Auth avec authentification Google. Le gros avantage : support multi-tenant natif. On peut maintenant attacher un utilisateur à plusieurs entités avec des rôles différents. Fini les bricolages !

Section intitulée nettoyer-le-codeNettoyer le code

L’équipe a séparé clairement les responsabilités : les composants d’interface d’un côté, la logique de récupération des données de l’autre, et les appels à la base de données dans une couche dédiée. On a aussi renforcé le typage partout pour éviter les erreurs silencieuses. Résultat : un code plus lisible, plus maintenable, plus robuste.

Section intitulée migrer-les-donneesMigrer les données

On avait déjà plusieurs semaines de données dans Supabase. L’équipe a écrit a utilisé un script de migration Better Auth qui récupère toutes les données existantes et les injecte dans la nouvelle base PostgreSQL.

Section intitulée deployer-sur-coolifyDéployer sur Coolify

Coolify, c’est un peu le Vercel open-source qu’on héberge soi-même. Déploiement Git, builds automatiques, gestion des variables d’environnement, monitoring, logs centralisés. Tout ce qu’on attend d’un service moderne, mais sur notre propre serveur. Coolify gère le build de l’application, le déploiement, les certificats SSL automatiques, les redémarrages en cas de crash. On a aussi déployé la base PostgreSQL sur Coolify. Backup automatique, monitoring des performances, alertes en cas de problème.

Section intitulée les-nouvelles-fonctionnalitesLes nouvelles fonctionnalités

Une fois la migration terminée, l’équipe a pu ajouter des features (youpi !)

Une page Leads avec crawler automatique. Un système qui récupère automatiquement des infos sur nos leads : scraping de certains sites web pour identifier les technos qu’ils utilisent par exemple.

Section intitulée quand-le-metier-se-rapproche-de-la-techQuand le métier se rapproche de la tech

On assiste à un mouvement de fond : les outils comme V0 ou Cursor permettent aux profils métier de créer leurs prototypes, tester leurs idées et mâcher le travail des développeurs qui passent derrière. Ça me rappelle un épisode d’IFTTD avec Frédéric Najman où on parlait justement de cette porosité croissante entre métier et tech. Les barrières tombent “un peu”. Et c’est plutôt sain.

Ce qui m’intéresse encore plus, ce sont les projets comme Database qui donnent plus d’impact au métier, plus de capacité de pilotage direct, tout en libérant du temps aux équipes tech souvent surchargées. On inverse la logique : au lieu de saturer les développeurs avec des micro-demandes, on leur donne l’espace pour se concentrer sur ce qui compte vraiment.

Section intitulée et-si-on-allait-plus-loinEt si on allait plus loin ?

En discutant de cette expérience avec Thibault, je vois qu’il y a des mini-demandes qui font perdre un temps fou aux équipes tech. Corriger une faute de trad. Ajouter un paramètre manquant dans une requête. Modifier un label d’UI. Ajuster un composant déjà existant.

Pour chaque micro-tâche, un développeur doit ouvrir un ticket, créer une branche, pousser le fix, créer une PR, la tester, la merger. Énormément de friction pour quelque chose de trivial.

Section intitulée l-idee-donner-la-main-aux-pm-po-sur-ces-petites-tachesL’idée : donner la main aux PM/PO sur ces petites tâches

Pas en mode cowboy mais via une interface guidée qui génère du code propre avec les règles du projet, qui sort directement une PR déployée en preview testable, et qui passe ensuite en review obligatoire côté dev avant merge.

Le gain serait triple : les PM/PO avancent plus vite sur leurs petits besoins sans saturer les devs, les devs se concentrent sur le cœur technique (features complexes, archi, perf), et tout reste sécurisé et maintenable grâce aux règles du projet et à la CI/CD.

Techniquement, ça pourrait ressembler à une surcouche SaaS qui fait trois choses : une interface guidée pour les PM/PO qui génère automatiquement un prompt enrichi avec les conventions du projet, l’automatisation du workflow qui génère une PR directement sur GitHub/GitLab avec preview app, et le contrôle avec review dev obligatoire et traçabilité IA vs humain.

Bon, on me fait signe que Cursor a annoncé fin août l’intégration directe avec Linear pour lancer des agents depuis un ticket. Mince… Mais validé !

Section intitulée tu-as-une-app-qui-dort-sur-un-coin-de-githubTu as une app qui dort sur un coin de GitHub ?

Si tu as vibe codé une solution qui marche, mais que tu sens qu’elle mérite mieux… c’est possible de passer au niveau supérieur sans tout reprendre. Nos copains de Premier Octet peuvent reprendre ce genre de projets pour les transformer en outils pros. Si ça t’intéresse, on en parle 🙂