Livrer une V1 avec l'IA sans vibe coding

Q: Si le développement va plus vite, est-ce que ça coûte moins cher ?

Le délai raccourcit nettement : une V1 se livre en 4 à 8 semaines, pour 5 à 25 k€. Mais le budget ne s'effondre pas dans les mêmes proportions que le temps de code, parce que la valeur s'est déplacée vers le cadrage, la validation et la recette. Payer pour du code généré sans specs validées, c'est acheter une dette technique avec un bon vernis.

Livrer une V1 avec l'IA sans faire du vibe coding tient en une règle : ne jamais générer de code avant que les règles fonctionnelles aient été validées, une par une, par le client. Le reste de la méthode découle de là. Écrans statiques d'abord, dossier de validation ensuite, PRD et tickets seulement après, code en dernier, recette avant livraison.

Nous avons appliqué cette méthode sur Lokali, une place de marché de location entre particuliers à La Réunion : paiement Stripe, empreinte de caution, machine à états, cagnotte, virements SEPA et back-office d'arbitrage. Deux semaines entre la réunion de lancement et la mise en production, pour 25 heures de travail cumulées, dont un tiers seulement de développement. Un projet que nous aurions chiffré autour de deux mois il y a trois ans, estimation tirée de dix ans à livrer ce type de produit.

Cet article détaille les huit étapes, dans l'ordre, et surtout celles que la plupart des gens sautent parce qu'elles ne produisent rien de visible.

Au sommaire

Le goulot d'étranglement a changé de place
Ce que le vibe coding livre réellement
La méthode en huit étapes
L'étape que tout le monde saute : valider les règles
Figer l'architecture avant le premier ticket
La recette devient obligatoire, pas optionnelle
Questions fréquentes

Le goulot d'étranglement a changé de place

Pendant vingt ans, le poste le plus lourd d'un projet logiciel était la production de code. On dimensionnait les équipes, les délais et les budgets là-dessus. Toute la culture projet, des estimations en jours-homme aux méthodes agiles, s'est construite autour de cette contrainte.

Cette contrainte a sauté. Sur Lokali, écrire le code d'une marketplace avec huit statuts, dix transitions, une intégration de paiement et douze écrans de back-office a représenté environ un tiers de l'effort. Les deux autres tiers sont partis dans la conception produit et la validation client.

Répartition réelle des 25 heures

Conception, specs, validation, allers-retours client ≈ 2/3

Architecture et développement ≈ 1/3

Ce renversement a une conséquence désagréable pour beaucoup d'acteurs : la valeur d'une agence ne se mesure plus à sa capacité à produire du code. Elle se mesure à sa capacité à comprendre un métier, à écrire des règles sans ambiguïté et à obtenir un accord explicite du client sur chacune. Ce travail-là ne se délègue à aucun modèle.

Ce que le vibe coding livre réellement

Le vibe coding, c'est décrire une intention à un modèle et accepter ce qui sort sans jamais avoir écrit ce que le système doit faire. Ça marche remarquablement bien pour un prototype. Ça produit des dégâts silencieux dès qu'il y a de l'argent, des données personnelles ou un litige possible.

Une recette sérieuse fait remonter des défauts d'un genre très particulier : ceux que ni la relecture de code ni la démo n'attrapent, et qu'aucun utilisateur ne signale avant longtemps. Trois familles reviennent systématiquement :

Une règle d'unicité de façade

Une contrainte que l'application croit appliquer, mais que rien ne garantit vraiment en dessous. Ça ne se voit qu'en essayant de la contourner, jamais en lisant le code.

Une information due, jamais affichée

Le système fait la bonne opération, mais l'écran de la personne concernée n'en dit rien. Techniquement juste, intenable dès qu'il y a un litige.

Un email à trous

Une variable non substituée, et le destinataire reçoit un message qui ne lui dit pas l'essentiel. Personne ne s'en aperçoit avant le premier client mécontent.

Aucun de ces défauts n'empêche l'application de démarrer. Aucun n'apparaît dans une démo. Tous auraient fini en litige client, en réclamation ou en mise en demeure. C'est exactement ce qu'une V1 vibe codée met en production sans le savoir.

Une app déjà vibe codée entre les mains ?

Notre audit express analyse une URL en quelques secondes : hébergement, connecteurs exposés, SEO, sécurité. Sans inscription, traitement local.

Lancer l'audit gratuit

La méthode en huit étapes

Chaque étape produit un artefact que la suivante consomme. Rien ne se recopie, tout se référence. C'est ce qui permet de changer une règle sans que trois documents deviennent faux.

Étape	Ce qu'elle produit	Ce qu'elle évite
1. Devis et prototype	Un objet manipulable dans un navigateur	Le cahier des charges de cinquante pages que personne ne lit
2. Réunion de cadrage	Les specs fonctionnelles V1	Les hypothèses non dites qui explosent en recette
3. Écrans statiques	Le flux et le contenu, validés sans une ligne de back	De refaire un parcours déjà codé
4. Dossier de validation	Chaque règle acceptée ou commentée par le client	Le « ce n'est pas ce que j'avais demandé »
5. PRD (méthode BMAD)	Des exigences numérotées et un périmètre borné	Le scope qui gonfle sans avenant
6. Epics et tickets	Des tickets qui référencent, jamais qui recopient	Les tickets devenus faux après un changement de règle
7. Architecture puis code	Un modèle de données décidé une fois pour toutes	Douze décisions de modélisation incohérentes
8. Cahier de recette	Chaque règle vérifiée sur l'application réelle	Les défauts silencieux découverts par les utilisateurs

Sur Lokali, ça donne : 31 écrans statiques, 113 règles validées par le client, un PRD de 50 exigences, 19 epics, une machine à états de 8 statuts et 10 transitions, puis 150 cas de recette. Le détail complet est dans le cas client Lokali.

L'étape que tout le monde saute : valider les règles

C'est l'étape la plus ingrate et la plus rentable. Un client qui regarde une maquette valide une impression : « oui, ça me plaît ». Un client qui lit « la caution ne peut pas dépasser la valeur déclarée de l'objet » avec l'écran concerné sous les yeux valide une décision. Ce n'est pas la même chose, et ça ne s'attrape pas au même moment.

Concrètement, nous construisons un petit outil de validation : chaque écran s'affiche en iframe à côté de ses règles fonctionnelles. Pour chacune, le client répond validée, à revoir, ou laisse un commentaire. À la fin, l'ensemble s'exporte en Markdown. Sur Lokali, 113 règles sur 113 ont été traitées, aucune laissée en attente.

Pourquoi ça change tout pour la suite

Le Markdown exporté devient l'entrée du PRD. Aucune ressaisie, aucune déperdition.
Les mêmes règles se convertissent en cahier de recette sans effort de rédaction : c'étaient déjà des critères d'acceptation.
Un désaccord se règle en relisant une ligne datée et validée, pas en confrontant deux souvenirs de réunion.
Ce qui est hors périmètre est écrit noir sur blanc. Si le scope bouge, c'est un avenant, pas une négociation.

Sur Lokali, trois vagues de retours client se sont enchaînées en trois jours sur les écrans statiques. Modifier un écran HTML à ce stade coûte quelques minutes. Le même changement demandé après le développement aurait coûté des jours.

Figer l'architecture avant le premier ticket

Un PRD décrit ce que le système fait, jamais comment il est construit. C'est volontaire. Mais un découpage en tickets ne tient que si le modèle technique est décidé avant, sinon l'IA prend douze décisions de modélisation indépendantes dans douze tickets, et elles ne seront pas cohérentes entre elles.

Sur Lokali, quatre décisions devaient être prises une fois, avant le premier ticket :

Les entités et leurs relations : utilisateur, annonce, réservation, avis, mouvement de cagnotte, demande de virement, litige, catégorie.
Le typage des dates et le fuseau. Une fois écrit en migration, c'est très coûteux à changer. Un test de non-régression de fuseau a été livré avec le socle, exécuté en heure de La Réunion.
Où vit la machine à états : colonne de statut plus table d'historique, ou table d'événements. La traçabilité était une exigence, il fallait décider comment.
Le découpage front/back et la forme de l'API, ainsi que le stockage des photos d'annonces.

Ce que ça donne concrètement dans le code livré

Montants en centimes, arithmétique entière, jamais de flottant. Un seul endroit du code calcule la commission, et les devis gelés ne sont jamais recalculés.
La double réservation est refusée par la base de données elle-même, pas par un contrôle applicatif qui relit juste avant d'écrire. La base tranche, le code se contente d'attraper l'erreur.
Toute opération de paiement est tracée en base avant d'être envoyée au prestataire. Un incident réseau ne peut produire ni double débit, ni échec silencieux.
Les dates de location sont des jours calendaires, jamais converties en UTC, et les tests temporels tournent à l'heure de La Réunion. Un bug de fuseau ne se voit pas quand on teste en UTC.
Les emails partent toujours après validation de la transaction, jamais à l'intérieur. Un rollback ne doit pas laisser un message qui annonce quelque chose qui n'a pas eu lieu.

Aucune de ces décisions ne sort d'un prompt. Elles se prennent en lisant les règles métier, une fois, avant de découper en tickets. Ensuite le développement assisté les applique partout sans les rediscuter. Résultat sur Lokali : 24 741 lignes de Go écrites à la main, dont 7 499 de tests, et 224 fonctions de test réparties sur 20 migrations et 64 vues.

Une demi-journée d'architecture. Elle évite de refaire des migrations en cours de route, et elle transforme le développement assisté en production de code cohérent plutôt qu'en collection de fragments qui marchent isolément.

La recette devient obligatoire, pas optionnelle

Quand un humain écrit le code, il porte en tête le contexte de ce qu'il vient de faire. Quand un modèle l'écrit ticket par ticket, ce contexte n'existe nulle part. La cohérence d'ensemble n'est garantie par personne. La seule façon de la vérifier, c'est de dérouler l'application comme un utilisateur, cas par cas.

Sur Lokali, deux cahiers de recette ont été rédigés, un pour le site public, un pour le back-office. 150 cas exécutés, 140 conformes, 10 en échec. Le déroulé a été fait sur l'environnement de développement, avec pilotage du navigateur pour rejouer chaque parcours.

Ce que la recette a confirmé, et ce qu'elle a trouvé

La mécanique était juste. Tous les calculs tombaient au centime sur sept réservations et quatre durées différentes. La machine à états respectait ses huit statuts. Le cloisonnement entre comptes a tenu à toutes les tentatives d'accès direct. La chaîne complète, de la demande au virement SEPA, se déroulait sans accroc.

Neuf défauts sur dix portaient sur ce que l'application dit, pas sur ce qu'elle fait : libellés, emails, notifications, traçabilité affichée. C'est la moitié la moins coûteuse à corriger, mais c'est aussi celle qui déclenche les litiges.

Les dix défauts ont été arbitrés le jour même, regroupés en quatre tickets, corrigés, et la plateforme est passée en production dans la foulée.

Points clés à retenir

Le code ne représente plus qu'environ un tiers de l'effort d'une V1. Les deux autres tiers sont de la conception et de la validation client.
Aucune ligne de code n'est générée avant que les règles fonctionnelles aient été validées une par une par le client.
Les écrans statiques servent à valider le flux et le contenu, pas la technique. Les corriger à ce stade coûte des minutes.
L'architecture se décide une fois, avant le premier ticket, sinon le développement assisté produit des choix de modélisation incohérents.
La recette n'est plus optionnelle : sur Lokali, 150 cas déroulés ont trouvé 10 défauts qu'aucune relecture n'aurait vus.

Voir la méthode appliquée de bout en bout

Le cas client Lokali détaille les huit étapes avec les dates, les chiffres et les arbitrages réels du projet.

Lire le cas client Lokali

Questions fréquentes

Quelle différence entre développement assisté par IA et vibe coding ?

Le vibe coding consiste à décrire une intention à un modèle et à accepter ce qui sort, sans avoir écrit au préalable ce que le système doit faire. Le développement assisté part de règles fonctionnelles validées, d'une architecture figée et de tickets qui référencent ces règles. Le modèle produit le code, mais il ne décide ni du périmètre, ni du modèle de données, ni des arbitrages métier.

Pourquoi faire des écrans statiques plutôt qu'une maquette Figma ?

Parce qu'un écran HTML se manipule dans un navigateur, sur mobile, sans compte ni installation, et qu'il montre le comportement réel : un calcul de prix qui se met à jour, un calendrier qui barre les jours pris, un message d'erreur. Une maquette montre un état, un écran statique montre un parcours. Et il se corrige en quelques minutes tant qu'aucun back-end n'existe.

Qu'est-ce que la méthode BMAD ?

C'est une méthode de structuration des specs qui sépare nettement le fonctionnel, le technique et les tests. Le PRD décrit ce que le système fait, avec des exigences numérotées et référençables. Les choix techniques vivent dans un document d'architecture distinct. Les critères d'acceptation deviennent le cahier de recette. Cette séparation est ce qui permet de changer une règle sans rendre trois documents faux.

Est-ce que ça marche sur tous les projets ?

Sur les V1 et les produits dont les règles métier peuvent s'écrire, oui. Sur un projet où le client ne sait pas encore ce qu'il veut, l'étape de validation prend beaucoup plus de temps, et c'est normal : c'est là que se joue le projet. En revanche, la méthode ne compense pas un cadrage impossible. Nous refusons les projets dont les règles ne peuvent pas être écrites avant de coder.

Si le développement va plus vite, est-ce que ça coûte moins cher ?

Le délai raccourcit nettement : nous livrons une V1 en 4 à 8 semaines, pour 5 à 25 k€. Mais le budget ne s'effondre pas dans les mêmes proportions que le temps de code, parce que la valeur s'est déplacée vers le cadrage, la validation et la recette. Payer pour du code généré sans specs validées, c'est acheter une dette technique avec un bon vernis.

Livrer une V1 avec l'IA sans faire du vibe coding