Codage assisté par IA : comment j'ai créé un MVP de startup en 30 jours, perdu 127 $, et découvert ce qui compte vraiment

Le problème que personne ne voulait résoudre

J’ai vu des fondateurs piégés dans la même boucle douloureuse des dizaines de fois. Un capital-risqueur pose une question innocente — « Et si votre churn diminuait de 2 % ? » — et soudain la réunion s’arrête net. La réponse du fondateur se cache quelque part dans un cauchemar Excel à 47 onglets. Trois heures à chercher des formules. Des références cassées. Des erreurs circulaires qui plantent tout le modèle.

Le schéma était évident : les fondateurs se noyaient dans des feuilles de calcul alors qu’ils devraient penser à la croissance.

J’ai donc décidé de tester si la nouvelle tendance du vibe coding — utiliser l’IA pour prototyper rapidement — pouvait résoudre ce problème. Que se passerait-il si je passais un mois à construire un outil de planification financière en utilisant l’IA comme principal partenaire de développement ? Je ne suis pas un programmeur moderne (mon dernier codage sérieux remonte à deux décennies), mais je suis à l’aise pour admettre ce que je ne sais pas et apprendre vite.

Ce que j’ai découvert en 30 jours remettrait en question tout ce que je pensais savoir sur le prototypage rapide.

Le rêve vs. la réalité

Le jour 1, c’était électrisant. J’imaginais un cockpit financier élégant : alimenté par l’IA, synchronisé avec QuickBooks, avec la planification de scénarios incluse, des exports prêts pour les investisseurs en quelques secondes. Estimation du délai ? Trois semaines pour un MVP. J’étais confiant.

J’avais aussi complètement tort.

Les premières leçons sont venues vite et à prix élevé. Quand je donnais à l’IA plusieurs instructions en même temps — « Ajoute le mode sombre », « Corrige le bug », « Améliore la performance » — elle ne les traitait pas séquentiellement. Au lieu de ça, elle se figait, confuse, puis créait une version Frankenstein qui n’accomplissait aucune des trois tâches. Cette erreur unique m’a coûté six retours en arrière, trois heures perdues, et $23 des crédits de calcul.

La complexité de l’UI a détruit ma deuxième hypothèse. Une simple demande — « Ajoute le mode nuit » — a déclenché 47 changements séparés. Résultat : texte blanc sur fond blanc, boutons invisibles, une interface complètement défaillante. Corriger les décalages de police et de fond a pris trois jours supplémentaires.

La vraie percée est arrivée quand j’ai arrêté de dire des choses vagues comme « rends-le plus intuitif » et que j’ai commencé à donner des instructions chirurgicales. Au lieu de « améliorer le tableau de bord », j’ai appris à dire : « Change la couleur du bouton Calculate en #0066CC, augmente la police à 16px, ajoute 8px de padding. » La précision a éliminé le gaspillage.

Le parcours coûteux : quand l’IA rencontre les mathématiques financières

En semaine 2, j’avais dépensé $93 des crédits sur Replit. La dépense s’accélérait, pas ralentissait. Chaque itération coûtait entre 2 et 5 dollars selon la complexité. Le schéma était clair : l’itération rapide consumait mon budget à toute vitesse.

Mais la vraie crise est arrivée quand j’ai découvert que les calculs financiers de l’IA étaient erronés de 20 %. Le coût d’acquisition client d’un fondateur affichait $47 alors qu’il aurait dû être de 58,75 $. Cette erreur aurait pu torpiller une présentation de Série A.

La cause ? J’avais donné à l’IA des instructions vagues et laissé faire des suppositions sur la méthodologie. Quand je lui ai demandé de « calculer la LTV », elle interprétait les variables de façon incohérente — utilisant parfois le churn mensuel, parfois annuel, inventant parfois ses propres calculs.

J’ai passé six heures à déboguer une seule formule. La correction a nécessité d’abandonner le langage naturel pour une précision chirurgicale :

Au lieu de : « Calculer la LTV »

J’ai dû écrire : « Calculer la LTV comme (Revenu Moyen Par Utilisateur × Marge Brute) / Taux de churn mensuel où ARPU = Total MRR / Clients actifs ; Marge brute = (Revenu - COGS) / Revenu ; Churn mensuel = Clients perdus ce mois / Clients actifs au début du mois. Montre ton travail étape par étape. »

Cette spécificité a tout changé. L’IA l’a compris à chaque fois après ça.

Le tournant : écouter réellement les utilisateurs fonctionne

Après trois semaines, j’avais trois testeurs et deux modèles financiers terminés. Les retours ont été brutalement humbles.

Un fondateur a coupé court à toute la complexité avec une seule phrase : « Je ne veux pas d’un autre générateur de modèles financiers. Je veux juste demander ‘Comment puis-je prolonger la runway de 3 mois ?’ et obtenir une réponse. »

J’avais construit le mauvais produit.

Toute la proposition de valeur s’est inversée : d’un outil à un conseiller. Au lieu d’une usine de feuilles de calcul, les fondateurs voulaient de la validation — quelqu’un pour leur dire si leurs chiffres ont du sens, signaler des hypothèses irréalistes, suggérer des améliorations, répondre aux questions « et si » en temps réel.

Cette révélation est arrivée au jour 21. Il me restait neuf jours pour tout reconstruire.

Le problème de l’échelle : quand le vibe coding atteint ses limites

Tout ne survit pas à cette approche. Quand des fondateurs ont demandé « Peux-tu synchroniser avec QuickBooks ? », j’ai découvert la vérité brutale : flux OAuth 2.0, validation de webhook, mapping de données, gestion des limites de taux, rafraîchissement des tokens — ce n’est pas du vibe coding. C’est du développement professionnel.

J’avais choisi TypeScript en pensant que c’était la meilleure pratique moderne. En réalité, quand on ne connaît pas vraiment un langage, on paie une taxe d’apprentissage en temps de débogage. Passer deux heures à corriger un problème de type TypeScript — (Type ‘number | undefined’ n’est pas assignable à type ‘number’) — m’a rappelé que choisir un langage qu’on comprend vaut mieux que de suivre la tendance.

Le bouton de rollback est devenu sacré. Je l’ai utilisé 73 fois en 30 jours. Le jour 27, j’ai tout cassé en essayant d’ajouter des « valeurs par défaut intelligentes » — calculs corrompus, fonctionnalités d’export, authentification utilisateur, tout. Plutôt que de déboguer pendant des heures, un clic a restauré la stabilité.

Parfois, le meilleur code est celui que vous n’écrivez pas.

Les chiffres : la validation dans sa forme la plus brute

Après 30 jours :

Métriques de développement : $127 dépensé, 3 500 lignes de code (principalement générées par l’IA), 73 retours en arrière, une seule langue de programmation apprise à la douleur

Acquisition utilisateur : 23 fondateurs intéressés, 12 inscriptions effectives, 3 onboarding terminés, 1 qui paie réellement

Ce fondateur qui propose 50$/mois ? C’est devenu la seule métrique qui comptait.

La dure réalité : créer quelque chose que les gens trouvent intéressant diffère radicalement de créer quelque chose que les gens utilisent. Mon entonnoir de conversion : 23 intéressés → 2 engagés → 0 onboarding terminé. Jusqu’à ce dernier pivot, qui a attiré le fondateur disant : « C’est la première fois que je comprends mes unités économiques sans diplôme en finance. »

Ce que le vibe coding permet réellement (Et ce qu’il ne permet pas)

Ce dans quoi il excelle :

• Prototypage rapide (idée en MVP testable en deux semaines)
• Faibles besoins en capital initial ($127 contre $20K pour les développeurs)
• Cycles d’échec rapides (essayer, casser, revenir en arrière, apprendre en quelques minutes)
• Génération de boilerplate et modèles standards
• Pas de complexité d’embauche

Ce dans quoi il échoue :

• Calculs de précision nécessitant une méthodologie cohérente
• Intégrations API d’entreprise avec OAuth et webhooks
• Architecture de sécurité multi-tenant
• Traitement de jobs en arrière-plan pour la synchronisation des données
• Formules financières complexes (analyse de cohortes, calculs de NPV)
• Fonctionnalités de collaboration en temps réel

Le moment de la graduation arrive quand vous avez 10+ clients payants demandant des fonctionnalités que le vibe coding ne peut fondamentalement pas fournir.

Ce que je ferais différemment (Et ce que je sauterais)

Si je recommençais demain, j’interviewerais 50 fondateurs avant d’écrire une seule ligne de code. Pas 5. Pas 10. Cinquante. Je leur demanderais ce qui prend le plus de temps à mettre à jour, quelles questions les investisseurs posent toujours, ce qu’ils paieraient vraiment. Cela aurait évité deux semaines et beaucoup d’efforts inutiles.

Je choisirais Python plutôt que TypeScript. Je fixerais un budget $200 crédit strict. Je construirais d’abord le processus manuel avant d’automatiser quoi que ce soit. Je sauterais le mode nuit que personne n’a demandé, l’UI parfaite que personne ne voulait, et les promesses d’intégration impossibles à tenir.

Plus important encore, je comprendrais cette vérité dès le premier jour : parler aux clients potentiels n’est pas une étape vers la construction — c’est la base de la construction.

Le chemin restant

La prochaine étape ne consiste pas à tout coder en vibe coding d’un coup. C’est la validation par déploiement incrémental.

Phase 1 (semaines 5-8) : Générateur manuel de modèles financiers + conseiller IA pour valider les hypothèses + planification de scénarios basique + export. Objectif : 10 clients payants.

Phase 2 (semaines 9-24) : Si la validation fonctionne, embaucher des développeurs fintech expérimentés pour construire de vraies intégrations, une sécurité d’entreprise, une infrastructure scalable. Budget : 50K-100K $.

La mission reste la même : éliminer le modèle financier Excel à 47 onglets. Chaque fondateur mérite des tableaux de bord en temps réel, des explications IA des chiffres, une planification de scénarios en secondes, des exports prêts pour les investisseurs instantanément.

Le voyage continue. Mais cette fois, avec de vrais fondateurs pour guider la direction plutôt que mes hypothèses qui pilotent le produit.

Le bénéfice de faire ce puzzle style mots croisés pendant 30 jours ? J’ai appris que la vitesse sans direction n’est qu’un échec coûteux. La précision l’emporte sur le volume. Les utilisateurs l’emportent sur les hypothèses. Et parfois, la meilleure validation, c’est un fondateur prêt à payer.