Auditer un MVP vibe-codé avant de le faire évoluer

Un MVP vibe-codé qui tourne, jusqu'au jour où il faut le faire évoluer

Un dirigeant qui a fait construire son MVP avec l'aide de l'IA, en interne ou par un freelance, se retrouve tôt ou tard face à la même décision : ouvrir l'outil à de nouveaux utilisateurs, y ajouter une fonctionnalité attendue par un premier client payant, ou le connecter à un autre système. Jusque-là, le MVP a fait son travail. Il a validé une intuition, permis de signer les premiers clients, prouvé qu'un besoin existait. Personne, à ce stade, n'a de raison de douter de sa solidité : il tourne, les démonstrations passent, les premiers retours sont bons.

Le problème apparaît plus tard, quand l'outil doit absorber un volume qu'il n'a jamais vu, ou une règle métier que personne n'avait anticipée en écrivant le prompt initial : un second rôle utilisateur avec des droits différents, une remise cumulable avec une autre, un export qui doit tenir sur dix fois plus de lignes qu'en démonstration. Un MVP vibe-codé qui fonctionne aujourd'hui ne dit rien de sa capacité à continuer de fonctionner une fois qu'on y touche. C'est cette distinction, entre marcher et être prêt à évoluer, que l'audit doit établir avant toute décision de scaling.

Le signal qui déclenche la question de l'audit

Le signal est presque toujours une demande anodine en apparence : un second rôle utilisateur à gérer, une intégration avec un outil tiers, une règle de facturation qui varie selon le client. Le développeur, humain ou assisté par l'IA, tente d'ajouter la fonctionnalité et découvre qu'elle touche un comportement qui n'a jamais été formalisé nulle part. Sur les signaux plus larges qui permettent de reconnaître un projet vibe-codé avant même d'en hériter, notre analyse de la dette technique invisible produite par le vibe coding détaille ce qu'il faut chercher. Ce qui suit ici part d'un principe différent : le diagnostic est déjà posé, le MVP est bien vibe-codé, et la question devient de savoir dans quel ordre le reprendre.

Pourquoi l'ordre de la reprise change tout

Face à un MVP qui fonctionne mais dont personne ne maîtrise entièrement la structure, deux réflexes opposés se présentent, et les deux sont mauvais. Le premier est de foncer : ajouter la fonctionnalité demandée, quitte à empiler une décision de plus sur une base déjà instable. Le second est de tout jeter : décréter que le code généré par IA n'est pas fiable et qu'il faut repartir de zéro avec une équipe de développeurs. Le premier réflexe accélère la casse. Le second jette souvent ce qui fonctionne réellement, à savoir la logique métier validée par les premiers utilisateurs, pour ne garder que l'intuition initiale.

L'ordre dans lequel on reprend un MVP vibe-codé compte davantage que la quantité de travail fournie. Toucher à la structure du code avant d'avoir figé un comportement de référence revient à modifier un système sans savoir ce qu'il fait vraiment aujourd'hui : monter la version d'un ORM ou d'une bibliothèque de dates peut changer silencieusement le format qu'attend un webhook de paiement, sans qu'aucun test n'existe pour le détecter. À l'inverse, vouloir tout formaliser avant de toucher au code retarde indéfiniment une mise à niveau que le MVP réclame déjà.

Cette tension se voit particulièrement sur l'authentification et le modèle de données, les deux endroits où un MVP vibe-codé cache le plus de décisions jamais discutées. Un prompt qui demande « ajoute la connexion utilisateur » obtient une réponse fonctionnelle en quelques minutes, sans qu'aucune question ne soit posée sur la durée de vie d'un jeton JWT, sur qui peut réinitialiser le mot de passe de qui, ou sur ce qui doit se passer si un compte est partagé entre deux services. Ces décisions existent quand même dans le code généré, elles sont simplement prises par défaut, sans que personne ne les ait choisies consciemment.

« Je ne veux absolument pas qu'on tombe dans le côté full prompt pour coder. Je sais qu'on a vite tendance à tomber là-dedans parce que c'est ce qui code le plus vite, 20 fois plus vite qu'un humain, sauf que je sais très bien que ça accumule de la dette technique. »

Cette vitesse est réelle, et elle n'est pas le problème. Le problème est de la laisser décider seule de l'ordre des opérations. Chez Leando, ce principe s'appelle stabiliser avant d'étendre : face à un code qu'on ne maîtrise pas encore entièrement, on fige d'abord ce qui fonctionne, on se donne un moyen de détecter une régression, et on ne touche à la structure qu'ensuite. Pour un MVP généré par IA spécifiquement, ce principe se décline en cinq mouvements concrets, toujours dans le même ordre.

Stabiliser avant de comprendre le reste

Geler les dépendances, sans exception

La première action tient en une pause : aucune dépendance, aucune bibliothèque, aucune version de langage ne bouge tant que le comportement actuel du MVP n'est pas documenté. Un MVP vibe-codé accumule des dépendances au fil des prompts, souvent sans cohérence de version entre elles, parfois avec deux bibliothèques différentes qui font la même chose parce que deux prompts successifs ont résolu le même besoin sans le savoir. L'envie de tout mettre à jour d'un coup pour repartir sur des bases saines est compréhensible et presque toujours prématurée : une mise à jour de React ou d'un ORM peut modifier silencieusement un comportement dont dépendait une règle métier jamais écrite ailleurs que dans le code généré.

Remettre un filet : lint, tests, intégration continue

Le deuxième mouvement consiste à remettre en place ce que le vibe coding saute presque systématiquement. Sur la plupart des MVP que nous auditons, la configuration ESLint existe dans le dépôt, générée par défaut par l'outil de scaffolding, mais personne ne l'a jamais exécutée en dehors de l'éditeur, et aucune intégration continue ne la fait tourner à chaque push. Il n'existe généralement aucun test : pas un fichier Vitest, pas un scénario Playwright, rien qui vérifie qu'un parcours de commande ou de création de compte fonctionne encore après une modification. Rien de tout cela n'a besoin d'être exhaustif au départ. Un pipeline GitHub Actions ou GitLab CI qui lance `eslint` et deux ou trois tests Vitest sur les parcours qui font tourner l'activité, avant d'autoriser un déploiement, vaut mieux qu'une suite complète repoussée indéfiniment faute de temps. Ce filet minimal est ce qui transforme la suite de l'audit d'un pari en une vérification.

Regrouper le state dispersé et la logique métier, puis sécuriser l'authentification

Le state dispersé, symptôme numéro un

Une fois le filet posé, le state dispersé est le signal le plus révélateur sur un MVP vibe-codé, bien avant une logique métier vaguement mal organisée : plusieursuseState locaux qui portent la même information sans jamais se synchroniser. Le cas le plus fréquent, un total de panier suivi par un useState dans le composantCart et par un second, indépendant, dans CheckoutSummary : dès qu'un code de réduction s'applique côté panier, le résumé de commande continue d'afficher l'ancien montant jusqu'à ce qu'un rechargement de page les remette en phase par hasard. L'IA, prompt après prompt, résout chaque écran isolément : elle recrée un state local plutôt que de lire une source commune, ce qui produit au passage du prop drilling sur quatre ou cinq niveaux de composants pour faire descendre une simple valeur de rôle utilisateur. Passé deux ou trois écrans, l'absence d'un store centralisé (un Context React, Zustand, ou toute solution équivalente) cesse d'être un détail d'architecture : chaque nouvel écran devient plus risqué que le précédent, parce qu'il ajoute une nouvelle copie du même état à tenir synchronisée.

La même dispersion touche la logique métier au sens strict : un calcul de prix dupliqué dans trois composants d'interface légèrement différents, une règle de validation écrite une fois côté formulaire, par exemple un schéma Zod dans le composant React, et jamais vérifiée côté serveur, ce qui laisse un appel direct à l'API, via un simple curl, contourner la règle entièrement. Regrouper state et règles métier dans une couche dédiée, même sommaire, un hook personnalisé ou un module de services partagé, est ce qui permet ensuite d'ajouter une fonctionnalité sans la réécrire à trois endroits différents.

Traiter l'authentification comme un chantier à part entière

L'authentification mérite une attention séparée parce qu'elle est presque toujours le point le plus bricolé d'un MVP vibe-codé : un jeton JWT signé sans date d'expiration (exp), une vérification de rôle qui conditionne seulement l'affichage d'un bouton côté interface, sans qu'aucun contrôle équivalent n'existe dans le gestionnaire de la route API correspondante, un mot de passe par défaut resté actif depuis les premiers tests. L'IA générative traite l'authentification comme n'importe quel autre écran à générer, sans en connaître les conséquences en production, ce qui explique le bricolage bien plus qu'il ne trahit une négligence du développeur. Avant d'ouvrir l'outil à de nouveaux utilisateurs, un audit ciblé sur qui peut accéder à quoi, et comment cet accès est vérifié à chaque appel côté serveur et pas seulement côté interface, est non négociable : c'est le seul des cinq mouvements où une faille découverte impose de corriger avant de continuer, plutôt que d'attendre son tour dans l'ordre.

Ce n'est qu'après ces quatre mouvements, dépendances gelées, filet de tests posé, state et logique métier regroupés, authentification vérifiée, que la migration des versions majeures et les nouvelles fonctionnalités redeviennent un chantier normal plutôt qu'un pari.

Ce que cet ordre exclut

Cet ordre ne classe pas tout MVP vibe-codé comme suspect, et il n'impose pas de repousser indéfiniment toute évolution en attendant un audit parfait. Une bonne partie des MVP générés avec l'aide de l'IA n'ont besoin que d'une stabilisation légère : l'ampleur des quatre premiers mouvements dépend directement de la taille du projet et du nombre de mains qui ont écrit des prompts dessus. Un MVP construit seul par un fondateur technique sur deux mois demande rarement le même travail qu'un projet vibe-codé par trois développeurs juniors en parallèle pendant six mois, avec chacun son propre style de state management et sa propre idée de ce qu'un rôle utilisateur autorise.

Cet ordre exclut également l'idée que la vitesse du vibe coding serait le problème. Elle ne l'est pas : elle a permis à un MVP d'exister et de rencontrer ses premiers clients plus vite qu'un développement classique ne l'aurait fait. Le problème n'est jamais la vitesse de production, c'est l'absence d'un moment dédié à vérifier ce qu'elle a réellement produit avant de s'appuyer dessus pour scaler. Une fois ce moment posé, la vitesse redevient un atout plutôt qu'un risque.

Le test à faire sur votre propre MVP

Demandez à la personne qui a construit votre MVP, freelance, associé technique ou vous-même, de vous montrer en cinq minutes où sont gelées les dépendances, où est le test qui protège votre parcours de commande, où vit le state du panier ou de la session (un seul endroit ou trois), et qui peut accéder à quoi dans l'outil. Si les réponses sont claires, votre MVP est probablement prêt à évoluer. Si l'une d'elles ouvre un silence gêné, vous savez par lequel des cinq mouvements commencer. Une fois cette stabilisation posée, la question suivante devient de vous donner un budget et une feuille de route de maintenance pour qu'il continue de tenir une fois les premiers nouveaux utilisateurs arrivés.