Faire coder son MVP par une IA : ce qu'elle écrit vraiment, et ce qu'il faut reprendre avant de vendre

---

title: "Faire coder son MVP par une IA : ce qu'elle écrit vraiment, et ce qu'il faut reprendre avant de vendre" seoTitle: "MVP codé par IA : ce qu'il faut reprendre" description: "Claude Code ou Cursor vous ont sorti un MVP en un week-end. Le code tourne, les écrans sont là, et pourtant il n'est pas vendable en l'état. Voici ce que ces outils écrivent très bien, les sept défauts qu'on retrouve d'un projet généré à l'autre, et la reprise à mener avant le premier client payant." seoDescription: "Ce qu'un MVP généré par Claude Code ou Cursor contient vraiment, les sept défauts récurrents, et la reprise à mener avant le premier client payant." date: "2026-09-18" author: "Équipe Raicode" tags: ["IA", "mvp", "saas", "développement"] category: "SaaS & MVP" keywords: ["MVP généré par IA", "Claude Code MVP", "Cursor développement SaaS", "reprendre du code généré par IA", "coder un MVP avec l'IA", "qualité du code IA", "MVP vibe coding production", "sécuriser un MVP SaaS"]

Vous avez décrit votre produit en français à un agent de codage, et trois jours plus tard vous aviez une application qui tourne : inscription, tableau de bord, base de données, facturation Stripe, déploiement. La démo passe. Les premiers utilisateurs test cliquent partout sans rien casser. Puis vient le moment de faire payer quelqu'un, et quelque chose vous retient — une intuition que vous n'arrivez pas à formuler, ou un développeur à qui vous avez montré le dépôt et qui a fait une drôle de tête.

Cette intuition est fondée, mais pas pour la raison qu'on entend habituellement. Le problème n'est pas que « l'IA écrit du mauvais code » : une bonne partie de ce qu'elle a produit est meilleure que ce qu'un développeur pressé aurait écrit à trois heures du matin. Le problème est que ce qu'elle écrit mal est toujours concentré aux mêmes endroits, et que ces endroits sont précisément ceux qui coûtent cher quand ils lâchent : l'isolation entre clients, l'argent, les données, les secrets. Un MVP généré n'est pas à jeter. Il est à reprendre, et la reprise se cible.

Ce que ces outils écrivent réellement bien

Il faut commencer par là, parce que la moitié des articles sur le sujet sont écrits par des gens qui ont intérêt à ce que vous payiez un développeur pour tout refaire.

Sur la plomberie d'une application web moderne, un agent de codage est excellent. Les écrans, les formulaires avec leur validation, les états de chargement, la pagination, les routes CRUD, le schéma de base, les composants d'interface accessibles, la configuration du build, les fichiers de déploiement : c'est du code hautement conventionnel, massivement représenté dans ce sur quoi ces modèles ont été entraînés, et il est produit en quelques heures là où il occupait un développeur pendant deux à trois semaines. Sur les projets que nous reprenons, la partie interface d'un MVP généré est régulièrement plus soignée que celle d'un MVP artisanal du même budget : les états vides sont gérés, les messages d'erreur existent, le responsive tient.

Les tests unitaires simples sont également corrects, les migrations de schéma lisibles, et la documentation interne souvent meilleure que la moyenne du secteur — un agent commente sans se lasser. Si vous avez généré votre MVP en trois jours au lieu de six semaines, vous avez réellement gagné six semaines sur une partie du travail, et ce que cela change sur le calendrier d'un MVP n'est pas anecdotique.

Ce qui suit ne remet rien de tout cela en cause. Ce sont les zones où la génération échoue de façon systématique, pas occasionnelle.

Les sept défauts qu'on retrouve d'un projet généré à l'autre

1. L'isolation entre clients n'est pas garantie côté serveur

C'est, de loin, le défaut le plus fréquent et le plus grave. L'agent construit une route qui reçoit un identifiant de projet, de facture ou d'organisation, et lit l'enregistrement correspondant. Le filtre par utilisateur, lui, vit dans l'interface : le tableau de bord n'affiche que vos projets, donc vous ne demandez jamais ceux des autres. Sauf qu'une route HTTP ne se soucie pas de ce que l'interface affiche. Changez le numéro dans l'URL et vous lisez les données d'un autre client.

Sur les MVP générés que nous auditons, nous trouvons ce défaut sur une majorité des routes qui manipulent une ressource appartenant à un utilisateur. La cause est structurelle : l'agent a écrit chaque route en réponse à une demande locale (« ajoute une page qui affiche un projet »), sans modèle d'autorisation global, parce que personne ne lui en a donné un. Il a correctement implémenté l'authentification — savoir qui vous êtes — et sauté l'autorisation — savoir à quoi vous avez droit. Les deux mots se ressemblent, le second est celui qui vous expose.

2. Les secrets fuient vers le navigateur

Une clé d'API qui ne fonctionnait pas côté client a été « corrigée » en lui ajoutant le préfixe qui la rend publique. C'est la réparation la plus naturelle du monde pour un agent à qui on dit « ça ne marche pas, corrige » : l'erreur disparaît effectivement. La clé, elle, part désormais dans le bundle JavaScript téléchargé par tous les visiteurs. Nous avons vu ainsi des clés de service de base de données, des jetons d'envoi d'emails et, une fois, une clé d'API LLM avec un plafond mensuel à quatre chiffres.

3. Le paiement fonctionne en démonstration, pas en production

Le parcours d'abonnement est presque toujours généré dans sa version heureuse : redirection vers la page de paiement, retour sur une page de succès, et mise à jour du statut de l'abonné à ce moment-là. Trois choses manquent presque toujours. La signature du webhook n'est pas vérifiée, donc n'importe qui peut déclarer un paiement réussi. L'état de l'abonnement est dérivé du retour navigateur plutôt que de l'événement serveur, donc un utilisateur qui ferme l'onglet trop tôt paie sans être activé. Et le traitement n'est pas idempotent, donc un webhook rejoué — ce que fait tout prestataire de paiement en cas de doute — crédite deux fois.

4. Le schéma de données tient jusqu'au premier volume

Les symptômes sont constants : des montants stockés en nombres à virgule flottante plutôt qu'en centimes entiers, des dates sans fuseau, aucun index sur les colonnes utilisées dans les filtres, des contraintes d'unicité absentes, et un schéma poussé directement en base plutôt que par des migrations versionnées. Rien de tout cela ne se voit à vingt enregistrements. Tout se voit à cinquante mille, et la migration coûte alors dix fois ce qu'elle aurait coûté avant le premier client. C'est le même mécanisme que les erreurs de conception qui coûtent cher en développement SaaS, accéléré par la vitesse de génération.

5. La même logique métier existe en six exemplaires

L'agent optimise localement. Vous lui demandez une septième route qui ressemble aux six précédentes, il écrit une septième route, avec sa propre copie du calcul de quota, de la vérification de rôle ou du formatage de facture. Tant que vous générez, ça ne se sent pas. Le jour où la règle de quota change, il faut la retrouver à six endroits, et il en restera un — généralement celui qui compte.

6. Les traitements asynchrones n'ont pas de filet

Envoi d'emails, génération de PDF, appels à une API externe, traitement LLM : tout ce qui sort du cycle requête-réponse est généré dans sa forme la plus optimiste. Pas de file d'attente, pas de reprise sur échec, pas de trace de ce qui a été tenté. Un try/catch avale l'erreur, écrit une ligne dans la console d'un serveur dont personne ne lit les journaux, et l'utilisateur ne reçoit jamais son email sans que quiconque l'apprenne. Sur les fonctionnalités LLM, l'absence d'idempotence ajoute une facture : un traitement relancé trois fois est facturé trois fois, mécanisme qu'on retrouve au cœur des factures d'API qui explosent sans explication.

7. Les tests passent parce qu'ils testent les simulacres

La suite de tests affiche du vert et ne prouve rien : les appels externes sont remplacés par des simulacres qui renvoient toujours le cas nominal, et les assertions vérifient que la fonction a bien appelé le simulacre. Aucun test ne traverse le parcours d'inscription, de paiement et d'accès. C'est le vert le plus dangereux qui soit, parce qu'il vous fait livrer avec confiance.

Le mur, et pourquoi il arrive toujours au même endroit

Le scénario se répète : les trois premiers jours sont euphoriques, puis à partir d'un certain volume chaque nouvelle demande casse quelque chose ailleurs. La correction d'un bug en introduit deux. L'agent commence à réécrire du code qui fonctionnait.

La cause n'est pas mystérieuse. Un agent travaille avec ce qu'il voit de votre dépôt à l'instant où vous lui parlez. Tant que le projet tient dans sa fenêtre d'attention, il maintient une cohérence remarquable. Passé quelques dizaines de milliers de lignes réparties dans des centaines de fichiers, il ne voit plus qu'un fragment, et il redécide localement de choses déjà décidées ailleurs. Il ne sait pas qu'une règle d'autorisation existe trois dossiers plus loin. Il en réécrit une.

C'est exactement la différence que nous décrivions dans notre réponse sur le remplacement des développeurs par l'IA : la production de code n'est plus le goulot d'étranglement, la tenue d'une architecture dans la durée l'est toujours. Un MVP généré ne bute pas sur la difficulté du code, il bute sur l'absence de quelqu'un qui garde le plan d'ensemble.

La reprise : trois jours, quatre chantiers

Un MVP généré de quinze à vingt mille lignes se rend vendable en deux à trois semaines de travail, dont trois jours de diagnostic. C'est l'ordre de grandeur que nous observons sur ce type de reprise, et c'est ce que nous menons dans nos projets de MVP et de SaaS quand un founder arrive avec un dépôt déjà généré plutôt qu'avec une page blanche. Il reste très inférieur aux six à huit semaines d'une construction complète : le pari de la génération est gagnant, à condition de reprendre avant le premier client payant plutôt qu'après le premier incident.

Jour 1 — inventaire de l'exposition. Lister toutes les routes serveur, et pour chacune répondre à une seule question : qu'est-ce qui empêche un utilisateur authentifié quelconque d'appeler cette route avec l'identifiant d'un autre ? Si la réponse est « l'interface ne propose pas le bouton », c'est une faille. Cet inventaire tient dans un tableau et donne d'emblée la taille du chantier.

Jour 2 — les quatre blocs qu'on réécrit à la main. L'autorisation (une couche unique, traversée par toutes les routes, jamais réimplémentée au cas par cas), l'argent (webhooks signés, idempotents, état de l'abonnement dérivé du serveur seul), les données (migrations versionnées, montants en entiers, index et contraintes d'unicité), les secrets (rotation de tout ce qui a fui, inventaire de ce qui part dans le bundle). Ces quatre blocs se réécrivent en connaissance de cause. C'est la partie où l'assistance d'un agent aide à taper mais ne décide de rien.

Jour 3 — le filet. Cinq à dix tests d'intégration qui traversent réellement les parcours critiques — inscription, paiement, accès à une ressource d'un autre compte qui doit échouer — une intégration continue qui les exécute à chaque modification, et des journaux d'erreurs envoyés quelque part où quelqu'un les lit. Sans ce filet, la suite du développement reproduira les mêmes défauts à la même vitesse.

Le reste du code généré — écrans, composants, formulaires, mise en page — se garde tel quel. Le réécrire n'apporte rien et brûle le gain.

Continuer avec l'agent sans recréer le problème

La reprise ne signifie pas arrêter de générer. Elle signifie changer le cadre dans lequel on génère.

Quatre pratiques suffisent à changer la trajectoire. Écrire les règles du projet dans un fichier que l'agent lit à chaque session — modèle d'autorisation, où vit la logique métier, ce qu'on ne duplique jamais — parce qu'une règle non écrite n'existe pas pour lui. Faire écrire le test avant la fonctionnalité sur tout ce qui touche à l'argent ou aux droits. Travailler par modifications petites et revues, pas par régénérations de dossiers entiers. Et relire systématiquement à la main tout ce qui franchit une frontière : authentification, paiement, appel externe, accès à une ressource d'un autre compte.

C'est peu, c'est fastidieux, et c'est ce qui sépare un dépôt généré qui vieillit correctement d'un dépôt généré qu'on rouvre dans six mois en se demandant qui a écrit ça.

Ce qu'il faut retenir avant de facturer un premier client

Un MVP généré par Claude Code ou Cursor est un vrai gain de temps sur une vraie partie du travail, et un risque concentré sur quatre points précis. Il n'est pas vendable en l'état, non parce qu'il serait mal écrit, mais parce que personne n'a encore pris les décisions que l'agent n'était pas en position de prendre.

La prochaine action est simple, et elle prend une heure : ouvrez la route serveur qui lit la ressource la plus sensible de votre produit — une facture, un document client, un projet — et cherchez la ligne qui vérifie que le demandeur en est bien propriétaire. Si elle n'y est pas, vous connaissez la taille du chantier, et vous savez qu'il faut le mener avant le premier paiement, pas après le premier appel d'un client qui a vu les données d'un autre.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.