Vibe coding vs agentic coding : le guide de décision pour le fondateur non technique

Un fondateur avec qui nous travaillons, ancien associé en private equity et désormais CEO d’un SaaS vertical pour cliniques, a ouvert un Loom le mois dernier avec la phrase « j’ai vibe codé ça ce week-end, vous pouvez le terminer ? ». Le Loom montrait un flux de réservation qui marchait, un générateur de factures qui marchait, et le début d’un vrai produit. Il montrait aussi trois versions du même schéma de base de données dans trois fichiers différents, deux implémentations d’auth qui se concurrençaient, et un dossier nommé final_v3_actually_final contenant une app React entière qu’il avait oublié avoir commencée.

Vibe coding l’a mené à une démo en deux jours. Agentic coding l’aurait mené à un produit. Il a utilisé le bon outil pour la mauvaise étape, et la facture du nettoyage a été huit semaines de notre équipe.

C’est l’article sur vibe coding vs agentic coding pour les fondateurs non techniques. Les deux sont réels. Les deux fonctionnent. Le choix entre les deux est une décision d’étape, pas un débat de méthodologie, et se tromper est devenu l’une des erreurs les plus coûteuses qu’un fondateur peut commettre dans sa première année.

Ce qu’est le vibe coding, en pratique

Le vibe coding est le terme qu’Andrej Karpathy a popularisé début 2025 pour décrire une façon spécifique d’écrire du logiciel avec un LLM. Vous décrivez en langage naturel ce que vous voulez, vous acceptez le code que le modèle produit, vous l’exécutez, et quand ça casse vous décrivez le bug au modèle et acceptez le correctif. Vous ne lisez pas le code attentivement. Vous « vous laissez aller aux vibes », pour reprendre sa phrase, et vous jugez le résultat à la question « est-ce que l’écran fait ce que je voulais ».

La sortie du vibe coding est un artefact qui marche. Le coût est que vous ne savez pas ce qu’il y a dedans. Le modèle a choisi la structure, le modèle a choisi les bibliothèques, le modèle a choisi le pattern d’auth, et vous êtes le product owner d’un code que vous ne pouvez pas lire.

Pour un prototype de week-end, c’est très bien. Pour une démo cliquable qui teste une hypothèse avec cinq clients, c’est plus que très bien. Pour quoi que ce soit qui doit continuer à tourner pendant que des clients en dépendent, c’est un instrument de dette.

Ce qu’est l’agentic coding, en pratique

L’agentic coding, c’est ce qui se passe quand les mêmes LLMs sont enveloppés dans une boucle de planification, une boucle d’usage d’outils et une boucle de feedback, puis pointés vers une vraie codebase soumise à de vraies pratiques d’ingénierie. L’agent lit le code existant, planifie les changements, écrit des tests, les exécute et itère jusqu’à ce que le travail soit prouvé. Un ingénieur senior relit et merge.

La sortie de l’agentic coding est du logiciel publié. Le modèle a tapé, mais les décisions d’ingénierie (quoi construire, où le mettre, comment le tester, comment il échoue en sécurité) sont prises par une personne qui en répond. La codebase a une forme. Le nouveau travail s’inscrit dans cette forme. Quand quelque chose casse, quelqu’un peut trouver la cause sans avoir à appeler Karpathy.

Si le vibe coding est un croquis, l’agentic coding est un plan. Les deux laissent des lignes sur le papier. Seul l’un des deux est quelque chose que vous pouvez confier à un constructeur.

Vibe coding et agentic coding, est-ce la même chose ?

Non, et la confusion entre les deux est ce qui fait que le mauvais outil continue d’être choisi en Series A.

La confusion se comprend. Les deux impliquent une personne qui tape dans une boîte de chat et une IA qui produit du code. L’action mécanique est identique. La différence est ce qui se passe autour de la sortie de l’IA.

Le vibe coding n’a pas de surface de revue. L’auteur est juge et juré, et le critère est « est-ce que l’écran a fait la chose ». L’agentic coding a les mêmes surfaces de revue qu’une vraie équipe d’ingénierie a toujours eues : code review, suite de tests, pipeline de déploiement, astreinte. L’IA est à l’intérieur de cette machine. La machine continue de fonctionner.

Un test utile : si la sortie casse dans six mois, qui la répare, et comment cette personne comprend ce qui a été construit ? Dans le vibe coding, la réponse est « réécris-le depuis l’historique des prompts, si quelqu’un se souvient de ce qui a été demandé ». Dans l’agentic coding, la réponse est « lis le code, lis les tests, lis les PRs ».

Là où le vibe coding fonctionne réellement

Nous avons utilisé le vibe coding nous-mêmes. Nous allons continuer. Il y a trois endroits où il vaut son prix.

Les prototypes jetables qui existent pour tuer une idée. Si vous pouvez construire la chose un samedi et que la réponse est « non, aucun client n’en veut », vous vous êtes économisé un trimestre d’ingénierie réelle. Le jetable est le but. N’y mettez pas un client dessus. N’y mettez pas votre levée dessus.

Les expériences internes où vous êtes le seul utilisateur. Un script d’admin bricolé, un nettoyage ponctuel de données, un remplaçant temporaire de Google Sheets qui vit six semaines pendant un lancement. Si ça casse, vous le réparez ou vous abandonnez. Personne d’autre n’en dépend.

Le tout premier MVP, avec une date limite ferme. Celui-ci est dangereux. Le vibe coding produit un MVP crédible en un week-end, et la crédibilité de la démo séduit le fondateur à laisser des clients payants l’utiliser. La règle que nous donnons à nos clients : si vous avez vibe codé le MVP, vous avez quatre-vingt-dix jours pour remplacer la fondation ou tuer le produit. Toute autre chose est un accident au ralenti.

Le pattern dans les trois cas est le même. La sortie a une vie courte connue et la conséquence d’une casse est bornée. Dès que le produit bascule dans « il y a des gens qui dépendent de ça et nous n’arrêtons pas », le vibe coding est le mauvais outil.

Là où l’agentic coding fonctionne réellement

L’agentic coding est le bon outil partout où le vibe coding est le mauvais. Et cela inclut la majeure partie de ce qu’une startup publie réellement.

Le gain par rapport à une équipe purement humaine n’est pas « l’IA écrit le code, donc nous n’avons pas besoin d’ingénieurs ». C’est qu’une petite équipe de seniors produit notablement plus. Nous avons mesuré quelque chose comme 40 à 60 pour cent d’augmentation de production par ingénieur sur le type de travail produit CRUD-lourd qui remplit la majeure partie d’une roadmap early-stage. L’ingénieur senior continue à faire la pensée porteuse : l’architecture, le modèle de données, les modes de défaillance, les frontières de sécurité. L’agent absorbe la frappe, le boilerplate et une part significative de l’écriture des tests.

Le piège à éviter est d’utiliser l’agentic coding sans le senior. Les agents produisent gaiement du code architecturalement faux avec une confiance totale et une couverture de tests complète de la mauvaise chose. Ils ne sont pas des relecteurs porteurs de décision. Ce sont des collaborateurs juniors très rapides. L’ingénieur senior reste le relecteur porteur de décision, et la startup qui licencie ses seniors parce que « les agents font le travail maintenant » répète la même erreur que la vague no-code nous a apprise. Elle confond l’apparence du levier avec sa substance.

Cela rejoint directement un conseil que nous avons déjà écrit : le CTO que vous ne pouvez pas recruter n’est presque jamais votre vrai problème en Pre-Seed et Seed. L’ingénieur senior, lui, l’est. Le vibe coding ne change pas ce calcul. L’agentic coding rend le senior plus productif, ce qui rend effectivement le calcul moins douloureux, mais n’élimine pas le besoin.

Le vibe coding est-il meilleur que coder ?

C’est la mauvaise question, et nous en recevons une variante à chaque appel de fondateur cette année.

C’est la mauvaise question parce que « coder » n’est pas une seule activité. Écrire la première preuve qu’un flux est possible est différent d’écrire la version sur laquelle un hôpital va s’appuyer. La première veut de la vitesse et une faible pénalité quand on se trompe. La seconde veut de la justesse et une faible pénalité quand on change. Des outils différents gagnent à des étapes différentes.

Un cadrage plus utile : le vibe coding est plus rapide que l’agentic coding pendant la première heure d’un projet, et plus lent que l’agentic coding pendant chaque heure suivante. Le croisement se produit quelque part autour de la troisième feature, quand la codebase est assez grande pour que le modèle ait besoin d’un contexte que le prompt ne peut pas fournir facilement, et que les changements sur une partie du système se mettent à casser d’autres parties dont le modèle n’a jamais su qu’elles existaient.

Les fondateurs qui tirent le plus de valeur de la programmation assistée par LLM sont ceux qui utilisent le vibe coding comme test de faisabilité, puis basculent vers un vrai processus d’ingénierie (agentic ou autre) pour la construction. Les fondateurs qui se font mal sont ceux qui ne basculent jamais.

Les vibe coders comprennent-ils leur propre code ?

Réponse honnête : en général non, et c’est le design.

La proposition entière du vibe coding est que vous n’avez pas besoin de comprendre le code pour livrer l’artefact. C’est une économie réelle pour un croquis. Cela devient un passif réel à l’instant où vous devez modifier l’artefact. Chaque modification est une nouvelle ronde de décrire-et-prier. Chaque bug se débogue par symptômes, pas par causes. Et toute pression externe (une revue de sécurité, un audit SOC 2, un partenaire d’intégration qui demande à voir votre spec d’API) expose la faille.

Nous avons reconstruit trois systèmes vibe-codés cette année. Le pattern a été identique à chaque fois. Le fondateur a manqué de vibes vers le troisième mois, quand le modèle s’est mis à insister sur des changements qui cassaient la production et refusait de se rappeler des contraintes posées deux prompts plus tôt. Demander au modèle de réparer le travail du modèle au-delà d’un certain seuil de complexité est un tapis roulant. À un moment vous descendez et vous payez un ingénieur pour tout relire.

Nous facturons moins pour reconstruire un système vibe-codé que pour sauver un système no-code, mais plus que pour construire le même produit à neuf. Le cas du milieu est le plus cher des trois. La codebase a une forme, mais la forme est fausse, et la défaire prend plus de temps que partir d’une feuille blanche en aurait pris.

Une règle de décision par étape

La façon la plus propre que nous ayons trouvée de penser le vibe coding vs agentic coding est par étape et par utilisateur.

Si la question est « est-ce que cette idée fonctionne, et je suis le seul à y toucher », vibe codez. Allez vite, jetez, et traitez tout ce qui survit comme un accident heureux.

Si la question est « je veux le mettre devant cinq clients pour voir s’ils me l’arrachent des mains », vibe codez la démo, mais écrivez le contrat avec vous-même avant de commencer. Vous n’allez pas laisser la démo devenir le produit. À l’instant où le cinquième client dit oui, vous démarrez la vraie construction.

Si la question est « ça part en production, des clients vont en dépendre, et nous ne l’éteignons pas dans six semaines », c’est le territoire de l’agentic coding, avec un ingénieur senior qui tient le stylo et le LLM qui tient le clavier. Le senior est non négociable. La suite de tests est non négociable. La pipeline de déploiement est non négociable. Aucune de ces choses ne devient négociable juste parce qu’il y a une IA dans la boucle.

Si la question est « nous avons déjà vibe codé le MVP et des clients l’utilisent », vous avez une horloge. Quatre-vingt-dix jours, et soit la fondation est remplacée soit le produit est éteint. Plus l’horloge tourne, plus la reconstruction coûte cher, et la reconstruction aura lieu de toute façon. Nous l’avons vu se dérouler sur six engagements clients cette dernière année. Cela se déroule à chaque fois. Cela se déroule plus vite que vous ne le pensez.

Le vrai choix du fondateur non technique

La question du vibe coding vs agentic coding est cadrée comme un combat entre deux techniques d’IA. Elle ne l’est pas. C’est une question d’étape habillée en outil.

Vous décidez, sur chaque surface produit, combien de temps vous voulez que le travail dure. Le vibe coding optimise pour la première version d’une réponse. L’agentic coding optimise pour la version qui survit à la deuxième version. Les deux ont leur place. Aucun des deux n’est une religion.

Les fondateurs qui réussissent traitent le vibe coding comme ils traitent un modèle financier au dos d’une serviette : utile, rapide, à jeter avant qu’il ne prenne une vraie décision à votre place. L’agentic coding est l’état financier audité. On ne pilote pas une entreprise depuis la serviette. On ne pilote pas non plus une entreprise depuis les vibes.

Si vous voulez une version plus affûtée de ce raisonnement appliquée à votre propre produit, c’est la moitié des conversations que nous avons en ce moment avec des fondateurs. Lisez notre texte sur ce qu’est réellement un MVP pour le cadrage que nous utilisons pour tracer la ligne. Et si vous décidez d’engager une software house, la même logique d’étape s’applique. Choisissez le partenaire dont le défaut est l’étape suivante, pas l’actuelle.

La synthèse tient en une phrase. Le vibe coding construit la question. L’agentic coding construit la réponse. Ne livrez pas la question.