Du chaos dans la feuille de calcul aux insights alimentés par l'IA : un bilan de réalité de 30 jours de Vibe Coding

Pourquoi les fondateurs ne peuvent pas vivre sans Excel—et pourquoi ils devraient

Temps de lecture : 7 minutes
Idéal pour : Constructeurs expérimentant avec le développement IA, fondateurs fatigués de la modélisation financière manuelle

Le problème dont personne ne parle

Entrez dans n’importe quelle réunion de pitch et vous verrez la même scène : un VC demande « Que se passe-t-il si le churn baisse de 2 % ? » Le visage du fondateur devient blanc. La réponse se trouve quelque part dans un cauchemar Excel de 47 onglets. Trois heures à fouiller dans des formules. Une petite erreur de saisie. Une référence circulaire qui fait tout planter.

Ce n’est pas une bizarrerie—c’est la norme. La plupart des entreprises en early stage utilisent encore des feuilles de calcul pour la prévision financière, et les fondateurs détestent universellement cette expérience. Les maths sont simples mais douloureuses : des modèles complexes prennent des jours à construire, des heures à mettre à jour, et des secondes à casser.

Le problème mérite mieux. C’est ce qui a inspiré un développeur à passer 30 jours à tenter l’impossible—construire un outil de conseil financier utilisant du vibe coding et de l’IA, tout en documentant chaque erreur, insight, et leçon apprise.

L’expérimentation de 30 jours : par les chiffres

La configuration :

• Durée : 30 jours de vibe coding continu
• Plateforme : environnement de développement cloud
• Investissement total : $127 en crédits de plateforme
• Lignes de code générées : ~3 500 (principalement assisté par IA)
• Itérations et retours en arrière : 73 fois

Les résultats :

• Intérêt initial exprimé : 23 fondateurs
• Inscription réelle : 2
• Onboarding terminé : 3
• Prêts à payer : 1
• Revenu généré : $0 (validation : engagement de 50$/mois)

Le périmètre :

• Utilisateurs cibles : fondateurs en pré-seed jusqu’à Série A
• Problème principal abordé : mises à jour de modèles financiers prenant des heures
• Solution tentée : conseiller financier alimenté par IA
• Indicateur clé suivi : précision des calculs

Semaine 1 : La lune de miel rencontre la réalité

La vision initiale était ambitieuse : tableaux de bord financiers en temps réel, synchronisation fluide des données avec le logiciel comptable, planification de scénarios à la demande, exportations prêtes pour investisseurs en secondes. Le calendrier semblait raisonnable : 2-3 semaines pour lancer.

Ce ne fut pas le cas.

La première semaine a révélé trois erreurs critiques :

Erreur #1 : Le traitement parallèle ne fonctionne pas
Soumettre plusieurs instructions simultanément à un agent IA crée de la confusion. Demander le mode sombre, des corrections de bugs, et des améliorations de performance dans une seule requête a abouti à un produit Frankenstein qui n’a rien bien fait. La solution : une instruction à la fois, attendre la fin, puis évaluer les résultats.

Coût : 6 retours en arrière, $23 en crédits, 3 heures perdues

Erreur #2 : La complexité de l’UI n’est pas triviale
Une simple demande de « mode nuit » a déclenché 47 changements involontaires. Texte blanc sur fond blanc. Boutons invisibles. Mismatch de polices nécessitant des ajustements pixel par pixel. La mise en œuvre UI a pris 3 semaines supplémentaires que prévu.

Erreur #3 : Des instructions vagues génèrent des erreurs coûteuses
Dire « rends-le plus intuitif » sans détails précis a conduit à des restructurations complètes de la mise en page. La précision est devenue la différence entre $2 itérations et $50 itérations. Un prompt détaillé décrivant couleurs, dimensions, et positionnement a éliminé l’ambiguïté.

Le moment décisif est venu en découvrant une instruction unique qui a transformé tout le workflow : « Ne fais aucun changement sans confirmer ta compréhension avec moi d’abord. »

Cette phrase seule aurait pu éviter plus de 50$ de crédits gaspillés en itérations inutiles.

La phase intermédiaire : quand ça casse

Les complications en milieu de projet sont apparues lors de la deuxième semaine. Voyager avec une WiFi peu fiable a rendu le débogage des erreurs TypeScript presque impossible sur mobile. La fonction de rollback est devenue indispensable—parfois en revenant 12 fois en une seule journée quand des fonctionnalités expérimentales provoquaient plusieurs défaillances système.

Au jour 15, la dépense en crédits avait explosé. La semaine 1 a consommé 34$ ; la semaine 2 a atteint 93$. Chaque itération coûtait entre 2 et 5$ selon la complexité. Cela a conduit à établir un plafond hebdomadaire : le dépasser, c’est faire une pause pour une réflexion stratégique.

La crise du calcul

Le tournant est survenu quand les testeurs ont découvert une faille critique : les calculs financiers étaient erronés d’environ 20 %. Un coût d’acquisition client affiché à $47 alors que la bonne réponse était 58,75$—une variance qui pouvait faire échouer des levées de fonds.

Le responsable : l’IA faisait des hypothèses implicites sur la terminologie. « Churn mensuel » signifiait parfois des taux annuels. Les calculs de « valeur à vie du client » utilisaient des formules inventées au lieu de méthodes standard.

Cela a conduit à un principe essentiel : Toujours valider manuellement les sorties de l’IA. Un tableau parallèle pour vérification est devenu une pratique standard. Les prompts vagues comme « calcule la LTV » ont été remplacés par des instructions chirurgicales précises :

Calculer la LTV comme : (Revenu moyen par utilisateur × Marge brute) / Taux de churn mensuel

_ Où :_

• Revenu moyen par utilisateur = Total MRR / Clients actifs
• Marge brute = (Revenu - COGS) / Revenu
• Taux de churn mensuel = Clients churnés ce mois / Clients actifs au début du mois

Afficher les calculs étape par étape.

Avec cette précision, la fiabilité a considérablement augmenté.

Les retours utilisateurs changent tout

Après deux semaines de développement, le premier groupe de bêta-testeurs a fourni des retours brutaux mais éclairants :

• Les calculs étaient inexactes de marges importantes
• Les exportations plantaient avec des jeux de données de plus de 50 lignes
• Les fonctionnalités principales étaient enfouies sous des couches de navigation
• Le taux d’onboarding était de 0 %, malgré l’intérêt initial

Un commentaire a été transformateur : « Je ne veux pas un autre outil de modélisation financière. Je veux qu’on me dise si mes chiffres ont du sens. »

Cette seule insight a redéfini toute la direction du produit. L’outil n’était pas une meilleure feuille Excel—c’était un conseiller. Pas une autre application de modélisation financière, mais un consultant IA qui valide les hypothèses, signale les projections irréalistes, compare aux standards du secteur, et répond aux scénarios « et si ».

Ce pivot a éliminé la complexité. Au lieu de construire des intégrations d’entreprise, un contrôle de version avancé, et une collaboration multi-utilisateurs, le produit minimum viable s’est concentré sur :

• Saisie manuelle du modèle financier
• Validation et benchmarking alimentés par IA
• Planification de scénarios basique (3 scénarios maximum)
• Questions-réponses en langage naturel sur les métriques financières
• Export vers des formats courants

Les obstacles techniques

Trois limitations majeures sont devenues apparentes :

Regret sur le choix du langage :
Commencer avec TypeScript au lieu de Python a créé des frictions. Les erreurs de type ont consommé des heures de débogage. Les projets futurs nécessitent un choix de langage basé sur la compétence réelle du développeur, pas la popularité.

Promesses d’intégration vs réalité :
Les fondateurs demandaient souvent la synchronisation avec QuickBooks. La réalité : flux OAuth 2.0, validation de webhooks, mapping de données, gestion d’erreurs, rafraîchissement des tokens, validation des règles comptables. Ce n’est pas une tâche de vibe coding.

Précision dans les calculs financiers :
Les formules financières complexes—courbes de rétention, NPV, valeur à vie du client—ont poussé l’aide IA à ses limites. Les prompts « faciles » généraient des résultats confiants mais incorrects. Seules des instructions hyperspécifiques avec des formules explicites produisaient des résultats fiables.

La décision de pivot

Au jour 28, il a fallu réduire la voilure. La vision complète était tout simplement trop complexe pour un prototypage rapide. Le MVP principal a été lancé avec :

✅ Constructeur manuel de modèles financiers
✅ Conseiller IA pour validation et benchmarking
✅ Planification de scénarios basique
✅ Fonctionnalité d’export
✅ Questions-réponses en langage naturel

❌ Intégrations en temps réel (reportées)
❌ Collaboration avancée (reportée)
❌ Sécurité d’entreprise (reportée)

Parfois, moins c’est plus.

Ce qui a fonctionné, ce qui n’a pas fonctionné, et ce qui arrive

Principes clés qui ont marqué

1. La précision chirurgicale l’emporte sur l’instruction vague
« Améliore-le » → Gaspillage. « Change le bouton en #0066CC, augmente la police à 16px, ajoute 8px de padding » → Succès.

2. Mises à jour séquentielles plutôt que changements parallèles
Donner une instruction. Attendre. Vérifier. Continuer. Ne jamais multitâcher l’agent IA.

3. La validation manuelle est non négociable
Ne jamais faire confiance aux calculs IA sans vérification indépendante, surtout dans un contexte financier.

4. Revenir en arrière sans culpabilité
73 retours en 30 jours signifiaient une itération rapide sans peur. Revenir en arrière est plus rapide que déboguer.

5. Les utilisateurs savent ce dont ils ont besoin
L’insight gagnant est venu en écoutant : « Dis-moi si mes chiffres ont du sens » est devenu la stratégie produit.

Ce qui changerait demain

Si je repartais de zéro, mes priorités changeraient :

1. 10 interviews utilisateur AVANT de construire quoi que ce soit—Découvrir l’insight « conseiller pas outil » dès le jour 1, pas le jour 21
2. Choisir Python plutôt que TypeScript—Le confort du langage prime sur la popularité du framework
3. Budget crédit dur de 200-300$—Forcer un meilleur prompt engineering et éviter la spirale de l’itération
4. Processus manuel d’abord, automatisation après—Valider la demande avant de construire des intégrations
5. Délai MVP de deux semaines—Éviter le feature creep, prioriser

Ce qu’il faut totalement éviter

• Mode nuit (personne ne l’a demandé ; a consommé 3 jours)
• UI parfaite (les fondateurs privilégient la fonction à l’esthétique)
• Promesses d’intégration (valider d’abord les workflows manuels)
• Fonctionnalités avancées (obtenir 10 utilisateurs payants avant d’étendre)

La voie à suivre

Le succès ne signifie pas la perfection—il signifie qu’un fondateur est prêt à payer 50$/mois pour la version simplifiée. C’est la validation.

La feuille de route réaliste :

Phase 1 (Semaines 5-8) : Valider la proposition de valeur centrale avec du vibe coding. Objectif : 10 clients payants à 50$/mois. Critères de succès : <10 % de churn mensuel, NPS >40.

Phase 2 (Après 50-100 clients) : Passer au développement traditionnel. Embaucher des devs fintech. Construire des intégrations. Ajouter des fonctionnalités d’entreprise. Budget : 50K-100K$.

Quand le vibe coding atteint ses limites

Ce dans quoi il excelle :

• Prototypage rapide (semaines vs mois)
• Opérations CRUD
• Intégrations API IA
• Fonctionnalités d’export
• Pages de destination
• Cycles d’itération rapides

Ce dans quoi il bute :

• Formules financières complexes (NPV, courbes de rétention)
• Intégrations API d’entreprise (OAuth, webhooks)
• Tâches de synchronisation en arrière-plan
• Architecture de sécurité multi-locataires
• Optimisation des performances (requêtes <300ms)
• Collaboration en temps réel

Le seuil de graduation : quand 10+ clients payants demandent des fonctionnalités que le vibe coding ne peut fondamentalement pas livrer.

Leçons pour tout constructeur expérimentant avec le développement IA

Avant de commencer :

• Choisir un langage que vous comprenez vraiment
• Fixer un budget hebdomadaire en crédits et le respecter
• Définir « terminé » par écrit
• Trouver 3 vrais testeurs (observateurs non intéressés)
• Interviewer 10+ utilisateurs potentiels en premier

Pendant la construction :

• Un prompt par itération ; attendre la fin
• Définir explicitement les termes vagues (“intuitif,” “propre,” “simple”)
• Valider toutes les calculs en indépendant
• Suivre les dépenses quotidiennes
• Prendre des captures d’écran des versions fonctionnelles avant des pivots majeurs

Quand faire une pause :

• La même erreur persiste après 5 tentatives
• Vous expliquez plus que vous ne construisez
• Les testeurs ne peuvent pas réaliser les workflows principaux
• Les demandes de fonctionnalités d’entreprise surgissent constamment
• Les crédits dépensés dépassent $200 sans utilisateurs payants(

En résumé :

Le vibe coding a livré un MVP fonctionnel en 30 jours pour 127$. Il a prouvé que le problème central est que )les fondateurs détestent Excel( et a découvert que la solution centrale est qu’ils ont besoin d’un conseiller, pas d’un autre outil). Il n’a pas réussi à assurer la précision des calculs et a révélé que l’IA a du mal avec la spécificité des formules financières.

Plus important encore : un fondateur prêt à payer a validé tout l’expériment.

Le voyage continue après le Jour 30. La prochaine étape consiste à convertir la validation en revenu, à faire évoluer du concept au produit durable, et à savoir quand passer du prototypage rapide au développement professionnel.

Supprimez le modèle Excel à 47 onglets. Chaque fondateur mérite une intelligence financière en temps réel, une explication IA, une planification de scénarios instantanée, et des exports prêts pour investisseurs. Les outils existent. La question est : est-ce que les fondateurs vont réellement les utiliser ?

Demain commence le Jour 31.