Reprendre un projet nocode ou vibe-codé : ce que personne ne vous dit avant

« On a fait notre app avec une agence il y a 18 mois. Ça marchait, mais maintenant ils ne répondent plus, ça plante en prod, et personne ne comprend comment c'est branché. On peut récupérer ça ? »

Cette phrase, dans ses différentes variantes, je l'entends de plus en plus souvent depuis deux ans. WordPress avec trente plugins assemblés, Wix devenu une usine à gaz, Webflow qui flirte avec ses limites, Bubble bloqué par ses quotas, Make ou Zapier empilés sans architecture. Et plus récemment, du code généré par Cursor, Lovable ou Bolt en mode "vibe coding" sans qu'un humain sache vraiment ce qui a été produit.

Le pattern est presque toujours le même. Petite startup ou TPE qui voulait économiser sur le dev. Premier prototype rapide et impressionnant. Six à douze mois plus tard, scaling impossible, dette technique invisible, et un budget de relance déjà cramé sur la première itération.

Cet article décrit ce que je vois concrètement, les trois cas de figure qui reviennent à chaque fois, et comment vous épargner la facture salée si vous êtes en train d'envisager (ou de subir) un projet de ce type.

Pourquoi le nocode et le "vibe coding" sont vendus comme une bonne idée

Sur le papier c'est imbattable :

• Vitesse : un MVP en 2 semaines au lieu de 2 mois.
• Prix initial : 3 000 € au lieu de 15 000 €.
• Indépendance apparente : "vous pourrez modifier vous-même".

Pour valider une idée sur un marché, c'est effectivement souvent la bonne approche. Je ne suis pas un anti-nocode dogmatique. WordPress est extraordinaire pour un site vitrine ou un blog bien tenu, Webflow est excellent pour un site marketing évolutif, Bubble fait des merveilles sur un POC d'application, et les LLM accélèrent la production de code à condition d'avoir quelqu'un qui sait relire.

Le problème n'est pas l'outil. Le problème, c'est ce qui se passe après le MVP.

Les 4 dettes invisibles d'un projet nocode

1. La dette de plateforme

Vous ne possédez pas votre code. Vous louez l'usage d'une plateforme. Le jour où Bubble triple ses prix (déjà arrivé), où Glide pivote son offre (idem), ou où votre app dépasse les limites du plan : vous payez ou vous partez. Et "partir" veut dire tout refaire ailleurs.

J'ai vu un client passer de 89 €/mois à 599 €/mois en 14 mois sur une plateforme nocode parce que son app commençait à marcher. Faire baisser la facture aurait demandé une refonte. Faire la refonte coûtait 22 000 €. Il a payé pendant 2 ans en serrant les dents.

2. La dette d'architecture

Les outils nocode masquent la structure de données et la logique métier. Quand un client me transmet son app Bubble avec 47 workflows, 18 tables et 6 plugins externes, personne ne sait plus ce qui appelle quoi. Ajouter une fonctionnalité simple devient un jeu d'archéologie. Modifier le calcul d'une commission peut tout casser ailleurs sans qu'on le voie venir.

Sur un projet code classique avec un schéma de base relationnel propre, ces relations sont explicites et grep-ables. Sur Bubble, elles sont planquées dans des conditions visuelles et des plugins.

Pareil pour WordPress avec trente plugins empilés, où chaque mise à jour devient une roulette russe.

3. La dette de talents

C'est le plus pernicieux. Les bons "experts WordPress" ou "experts Bubble" sont rares et coûtent autant qu'un dev web confirmé (TJM 500 à 700 €). Ceux qui ne sont pas chers (TJM 200 à 300 €) font des trucs qui marchent dans le moment mais qui s'effondrent à la première vraie évolution. Et comme la communauté est moins mature qu'en code classique, le turnover des freelances nocode est énorme. Votre prestataire d'il y a 8 mois a peut-être déjà changé de métier.

4. La dette de "vibe coding"

C'est la version 2026 du problème. Un porteur de projet utilise Cursor, Lovable, Bolt ou v0 pour générer une app entière en posant des questions à un LLM. Le résultat fonctionne sur 80% des cas attendus. Les 20% restants, c'est :

• Du code dupliqué dans 15 fichiers parce que le modèle a perdu le contexte.
• Des dépendances installées au pif (versions incompatibles, paquets abandonnés).
• Pas de tests, pas de logs, pas de gestion d'erreur cohérente.
• Une base de données structurée par flair, avec des champs qui ne devraient pas exister et d'autres qui manquent.
• Aucune compréhension de la sécurité (clés API en clair, validation côté client uniquement, etc.).

Le code "marche". Mais quand il faut le faire évoluer, personne ne sait expliquer pourquoi telle décision a été prise, parce qu'elle a été prise par un modèle de langage il y a 3 semaines.

Une histoire concrète que j'ai vécue récemment

Pour rendre tout ça moins théorique, voici un cas réel sur lequel j'ai été contacté il y a quelques mois.

Le contexte. Un porteur de projet me contacte avec une plateforme SaaS B2C par abonnement (49 € par mois pour ses utilisateurs). Le produit fonctionnait. Le client était même content au début. Facturé 10 000 € à une agence en bout de chaîne, le tout livré en quelques semaines. L'utilisateur arrive chez moi parce que la prod plante de plus en plus souvent, les utilisateurs se plaignent, et l'agence ne répond plus.

Ce que j'ai trouvé en ouvrant le projet.

• Un frontend Next.js déployé sur Vercel pour ce qui ne nécessitait absolument pas un framework React full-stack. Un site statique avec quelques pages d'admin aurait suffi.
• Un service worker Express.js séparé déployé sur Render, en service 24/7, pour faire du polling toutes les 5 secondes vers une API externe. Donc deux infrastructures à payer en parallèle (Vercel + Render), pour un produit qui n'avait aucun besoin d'une architecture distribuée.
• Une base Supabase avec du Row Level Security configuré à moitié, et des fonctions critiques qui faisaient le tour par la service_role key directement depuis le frontend (sans contrôle d'accès réel).
• Des mots de passe utilisateurs stockés en base64. Pas chiffrés. Encodés. Dans le README, mention "à remplacer par un vrai chiffrement en production". Spoiler : ça n'avait jamais été fait. Le code était en production depuis 8 mois.
• Aucun test automatisé. Aucun monitoring. Aucun log centralisé. Stripe webhook avec un secret qui n'était pas vérifié correctement, donc potentiellement vulnérable aux replays.
• Un schéma de base de données qui empilait des champs ajoutés au fil de l'eau, sans migrations propres, avec des JSON partout où une vraie table relationnelle aurait dû être.
• Le polling MetaAPI toutes les 5 secondes (latence insupportable pour le métier visé) consommait des appels API à un rythme qui dépassait largement les limites du plan, ce qui causait les plantages observés en prod.

Verdict honnête. Pas récupérable. Pas par paresse, pas par parti pris. Récupérable si on ignore tout le reste, mais alors on prolonge un produit qui ne tiendra de toute façon pas la charge dès qu'il dépassera 200 utilisateurs simultanés.

J'ai chiffré la refonte à 14 000 €, avec un délai de 3 mois et une vraie architecture en place. Le porteur n'avait plus le budget. Il a continué tant bien que mal pendant 6 mois supplémentaires sur le code existant, jusqu'à ce que la base de données se corrompe sur un déploiement raté. Là il a tout perdu. Il aurait économisé largement à refaire propre dès le départ.

Ce que ça illustre. Le sujet n'est pas que l'agence était mauvaise au sens absolu. Ils ont livré quelque chose qui marchait dans le moment. Mais ils ont vendu un produit "professionnel" facturé 10 000 € qui techniquement était un POC bricolé avec une stack copiée d'un tutoriel. Le client n'avait aucun moyen de le savoir. Et c'est exactement le piège.

Les 3 cas que je vois quand un projet arrive chez moi

Quand un client me contacte pour reprendre un projet nocode, vibe-codé, ou bricolé par une agence pas sérieuse, je fais un audit en 2 à 5 heures selon la complexité. Dans 95% des cas, ça tombe dans une de ces trois catégories.

Cas 1, récupérable en l'état (≈ 20% des audits)

Le projet est en nocode mais bien architecturé, les workflows sont documentés, le schéma de données est cohérent. Le client veut juste ajouter des fonctionnalités, optimiser des coûts ou intégrer une API.

Action : je continue dans la plateforme actuelle et j'ajoute ce qu'il manque. Coût : 2 000 à 8 000 € selon le périmètre. Délai : 2 à 4 semaines.

Cas 2, migration partielle (≈ 35% des audits)

La partie publique (site marketing, landing, blog) est en Webflow ou WordPress propre et marche très bien, on ne touche pas. Mais l'app métier qui tourne en Bubble ou en Glide arrive à ses limites : performance, coût, ou besoins qui sortent du périmètre de l'outil.

Action : on migre uniquement l'app métier vers du code (Node.js, Laravel, Python, selon le besoin), on garde le reste. Souvent un backoffice plus une API consommée par le frontend existant.

Coût : 8 000 à 25 000 € selon la complexité. Délai : 6 à 12 semaines. ROI : souvent atteint en 12 à 18 mois rien qu'en abonnements économisés.

Cas 3, refonte totale (≈ 45% des audits)

Là c'est moins sympa à annoncer. La dette est telle qu'expliquer le code existant prendrait plus de temps que de tout refaire. Soit parce que la plateforme nocode est devenue un boulet, soit parce que le code est inmaintenable, soit (souvent) parce que le besoin réel a tellement évolué qu'aucune des décisions initiales n'est encore valable.

Action : spec complète, choix d'architecture, dev from scratch en gardant uniquement la base de données ou les contenus.

Coût : 12 000 à 40 000 € selon le périmètre. Délai : 3 à 6 mois. Le sujet douloureux : il faut souvent réinvestir une somme équivalente ou supérieure à ce qui a déjà été dépensé sur la version précédente. Les budgets cassés, c'est ici.

La grille de décision avant de lancer (ou de continuer)

Si vous êtes en train d'hésiter, posez-vous ces questions dans l'ordre :

1. Combien d'utilisateurs simultanés ou clients dans 18 mois ?

• Moins de 100 : nocode tient probablement.
• 100 à 1 000 : ça dépend de la complexité, audit recommandé.
• Plus de 1 000 : partez sur du code dès le départ, vous gagnerez du temps.

2. Combien de logique métier spécifique (calculs, workflows, intégrations) ?

• Standard (formulaire, base client, paiement Stripe) : nocode OK.
• Spécifique avec exceptions et règles métier : code, sinon vous allez galérer sur tout sauf le happy path.

3. Êtes-vous prêt à payer indéfiniment l'abonnement de la plateforme ?

• Oui : nocode OK.
• Non : posez le calcul sur 5 ans, c'est souvent plus cher que du code custom hébergé chez vous.

4. Avez-vous les compétences internes pour maintenir un nocode ?

• Oui (vous ou un membre de l'équipe sait modifier les workflows) : nocode OK.
• Non, vous comptez payer un prestataire à chaque modif : autant payer un dev qui maîtrise vraiment.

5. Le projet est-il critique (chiffre d'affaires direct, conformité légale, données sensibles) ?

• Oui : code, point. Vous voulez maîtriser ce qui se passe.
• Non, c'est un side-project ou un outil interne : nocode est légitime.

Ce que j'aurais préféré qu'on me dise plus tôt

À ceux qui se lancent : le nocode n'est pas "le code en plus simple". C'est un outil différent, avec ses propres règles, ses propres pièges et ses propres coûts cachés. Il accélère le démarrage. Il complique souvent la croissance.

À ceux qui sont coincés avec un projet nocode mal en point : ne paniquez pas, mais ne traînez pas non plus. Plus vous attendez, plus la dette s'accumule et plus la refonte coûte cher. Un audit honnête en quelques heures vous dit où vous en êtes, et vous évite de continuer à empiler des plâtres sur un mur qui s'effondre.

À ceux qui utilisent Cursor, Lovable ou Bolt pour générer du code sans relecture : arrêtez avant que ça ne devienne ingérable. L'IA est un excellent assistant pour quelqu'un qui sait lire ce qu'elle produit. Ce n'est pas un remplaçant de développeur pour quelqu'un qui ne sait pas. La différence ne se voit pas tout de suite. Elle se voit dans 6 mois, quand vous voudrez ajouter la fonctionnalité que vos clients réclament et que personne ne pourra le faire.

En pratique

Si vous êtes dans une de ces situations, j'audite gratuitement les projets sous 48h ouvrées. L'audit comprend :

• Une analyse du code ou des workflows existants
• Une estimation du coût de refonte vs continuation vs migration partielle
• Une recommandation honnête, même si c'est "vous n'avez pas besoin de moi, continuez comme ça"

J'ai géré ce type de reprise pour des artisans, des PME et des collectivités. Je vous dis franchement ce qui se passe et combien ça coûte vraiment.

« On a payé 6 000 € à une agence pour une app qui ne tient plus la charge. Tu nous demandes 14 000 € pour refaire en propre. Est-ce qu'on peut au moins récupérer la base utilisateurs ? »

Oui. Toujours. Et c'est généralement la première chose qu'on fait.