Le vibe coding devait permettre de construire sans vraiment se préoccuper du code. Mais que devient cette expression lorsque des développeurs expérimentés utilisent eux aussi des agents IA pour produire une grande partie de leurs applications ? La différence n'est peut-être plus dans celui qui écrit le code, mais dans celui qui maîtrise ce qui est construit.
Au commencement, le « vibe coding »
Le 2 février 2025, Andrej Karpathy publie un message qui va donner un nom à une nouvelle manière de produire du logiciel avec l'IA : le vibe coding.
La pratique qu'il décrit est assez particulière.
Il demande à une IA de produire le code, accepte largement ses modifications sans lire systématiquement les différences, teste le résultat et lui renvoie les erreurs lorsqu'elles apparaissent.
Jusqu'à, volontairement, ne plus vraiment se préoccuper du code lui-même.
Ce détail est important.
Le vibe coding ne désigne donc pas simplement le fait d'utiliser une IA pour développer.
Dans son acception initiale, il décrit une façon particulière de le faire : privilégier le résultat et le flux d'itérations plutôt que la compréhension détaillée du code produit.
Karpathy précise d'ailleurs que l'approche convient plutôt à des projets personnels et relativement jetables.
Puis le terme a rapidement dépassé cette définition.
Une autre idée s'est installée autour du vibe coding :
j'ai une idée, l'IA sait coder, je peux donc construire mon application sans développeur.
C'est probablement là que commence le quiproquo.
D'un côté, l'IA permet effectivement à quelqu'un qui ne sait pas développer de produire des choses qui lui étaient auparavant difficilement accessibles.
C'est une évolution considérable.
Mais de l'autre, les développeurs eux-mêmes ont commencé à intégrer ces mêmes outils dans leur travail.
Et ce n'est pas nécessairement la même pratique.
Un développeur peut demander à une IA de produire énormément de code tout en continuant à raisonner sur l'architecture, les dépendances, les données, la sécurité, les tests, le déploiement ou la maintenabilité.
Extérieurement, les deux situations peuvent pourtant sembler identiques.
On décrit ce que l'on veut.
L'IA écrit le code.
L'application apparaît.
C'est peut-être cette similitude qui nous a induits en erreur.
Parce que la différence n'est progressivement plus dans qui tape le code.
Elle est dans qui comprend, dirige et assume ce qui est en train d'être construit.
« Je vais faire comme toi, le vibe coding… »
C'est justement une discussion récente qui m'a fait revenir sur cette question.
En expliquant à un ami ma manière actuelle de travailler avec l'IA et les outils que j'utilise, il m'a répondu :
« Je vais faire comme toi, le vibe coding, en utilisant… »
Je me suis immédiatement arrêté sur ces deux mots : vibe coding.
Pas parce que je considère cette pratique comme illégitime.
Simplement parce que je ne me reconnaissais pas vraiment dans cette description.
Pourtant, sa remarque était parfaitement logique.
Vu de l'extérieur, je décrivais exactement ce que l'on associe désormais au vibe coding : je formule un besoin, je travaille avec des agents IA, ils explorent le projet, produisent ou modifient du code, exécutent certaines tâches et m'aident à arriver beaucoup plus rapidement au résultat attendu.
Je produis aujourd'hui de cette manière une quantité de code qu'il m'aurait fallu beaucoup plus de temps pour écrire manuellement.
Alors pourquoi refuser l'étiquette ?
Parce que si toute utilisation intensive de l'IA pour produire du logiciel devient du vibe coding, alors une part croissante du développement moderne pourrait bientôt être qualifiée ainsi.
Or il existe une différence entre demander à une IA de construire quelque chose que l'on ne sait pas réellement évaluer et lui déléguer une partie de la construction d'un système que l'on continue à concevoir, diriger, contrôler et assumer.
Dans les deux cas, l'IA peut écrire l'essentiel du code.
La différence se situe ailleurs.
La quantité de code généré n'est plus le bon critère
On pourrait tracer une frontière simple.
D'un côté, le développeur qui écrit son code.
De l'autre, celui qui demande à une IA de l'écrire.
Cette frontière me semble déjà dépassée.
Un développeur expérimenté peut laisser un agent produire une fonctionnalité entière, modifier plusieurs fichiers, écrire des tests ou corriger une erreur sans intervenir directement dans chaque ligne.
À l'inverse, quelqu'un qui ne maîtrise pas réellement le développement peut obtenir le même résultat apparent.
Dans les deux cas, une grande partie du code aura été générée.
La différence se situe davantage dans le niveau de maîtrise conservé sur ce qui est produit.
Générer n'est pas décider
Lorsque je confie une tâche à un agent, je ne lui confie pas nécessairement la décision qui se trouve derrière cette tâche.
Je peux lui demander d'implémenter une API sans lui déléguer le choix de l'architecture générale.
Je peux lui demander de modifier une application sans lui laisser décider librement des dépendances à introduire.
Je peux lui demander de résoudre un problème puis refuser sa proposition parce qu'elle fonctionne techniquement mais ne correspond pas aux contraintes du projet.
L'IA peut produire la solution sans être celle qui décide de la solution.
Un résultat peut fonctionner sans être une bonne solution.
Une application peut compiler tout en introduisant une mauvaise dépendance.
Un test peut passer tout en vérifiant la mauvaise chose.
Une architecture peut être élégante mais disproportionnée.
Et une réponse produite avec beaucoup d'assurance par un agent peut simplement être fausse.
Le vrai critère : pouvoir reprendre la main
C'est probablement ici que je placerais aujourd'hui la frontière.
Pas dans le nombre de prompts.
Pas dans le nombre de lignes générées.
Pas même dans le fait de lire systématiquement chaque ligne produite.
Mais dans une question plus exigeante :
Suis-je encore capable de comprendre les décisions importantes, de détecter qu'une direction est mauvaise et de reprendre la main lorsque cela devient nécessaire ?
Si la réponse est non, je délègue également une partie de ma compréhension du système.
Si la réponse est oui, je délègue l'exécution tout en conservant la maîtrise du processus.
C'est à partir de là que le mot orchestration commence, pour moi, à prendre du sens.
Alors, qu'est-ce que j'orchestre réellement ?
Parler d'orchestration peut facilement devenir abstrait.
Dans ma pratique, c'est pourtant très concret.
Lorsque je travaille avec un agent, je ne commence généralement pas par :
« Développe-moi cette fonctionnalité. »
Je commence par lui donner un terrain de jeu.
Il existe un projet, une architecture, des conventions, des contraintes techniques, parfois un historique important et surtout un objectif à atteindre.
Le contexte avant le prompt
C'est l'un des changements majeurs dans ma manière de travailler.
Je raisonne de moins en moins en termes de « bon prompt » et davantage en termes de contexte disponible pour l'agent.
Comprend-il l'architecture ?
Connaît-il les conventions ?
Dispose-t-il des informations nécessaires ?
Sait-il ce qu'il peut modifier ?
Dispose-t-il des outils permettant de vérifier son propre travail ?
Un agent performant avec un mauvais contexte reste capable de produire une très mauvaise solution.
Correctement cadré et outillé, il peut au contraire prendre en charge beaucoup plus qu'une simple génération de code.
Il peut explorer le projet, rechercher une implémentation existante, identifier les fichiers concernés, proposer une stratégie, l'implémenter, lancer les vérifications disponibles et corriger certains problèmes.
Dans certains cas, mon intervention directe pendant cette séquence devient très faible.
Mon travail ne consiste alors plus à superviser chacune de ses actions.
Il consiste à organiser les conditions dans lesquelles je peux lui laisser cette autonomie.
Tests, compilation, analyse statique, comportement fonctionnel, historique Git ou pipeline d'intégration deviennent autant de points de contrôle.
Le contrôle change de granularité.
Je ne cherche plus nécessairement à vérifier comment chaque ligne a été produite.
Je vérifie que le système obtenu respecte toujours les propriétés que j'attends de lui.
Et lorsque l'agent part dans une mauvaise direction, je reprends la main : correction du contexte, modification de l'objectif, réduction du périmètre, remise en cause de l'approche ou intervention directe.
L'orchestration n'est donc pas regarder des IA travailler à ma place.
C'est décider quoi déléguer, avec quel contexte, quels outils, quelles limites et quels mécanismes de contrôle.
L'agent voit aussi mes angles morts
Mais cette relation ne se limite pas à la délégation et au contrôle.
C'est probablement l'un des aspects que je trouve aujourd'hui les plus intéressants.
L'agent peut m'aider à découvrir ce que je n'avais pas vu.
Il peut identifier une contrainte que je n'avais pas envisagée, questionner une hypothèse, signaler un cas limite ou proposer une piste à laquelle je n'avais pas pensé.
Il peut voir certains de mes angles morts.
C'est particulièrement utile lorsque l'objectif lui-même n'est pas parfaitement défini.
À défaut de pouvoir mener immédiatement le travail de bout en bout, l'agent peut participer à l'exploration du problème et contribuer à révéler les zones d'ombre qu'il reste à éclaircir.
Mais cette relation fonctionne dans les deux sens.
L'agent possède lui aussi ses angles morts.
Il peut manquer une connaissance métier implicite, surinterpréter une information présente dans son contexte, ignorer une contrainte organisationnelle ou proposer quelque chose de cohérent en théorie mais inadapté au système réel.
Parfois, il ne sait tout simplement pas qu'une information lui manque.
Il voit certains de mes angles morts, et mon expérience me permet d'en voir certains des siens.
C'est probablement une meilleure représentation de ma manière de travailler avec l'IA que celle d'un développeur donnant simplement des instructions à une machine.
Il ne s'agit plus uniquement de déléguer puis de contrôler.
Il s'agit aussi de confronter deux capacités de raisonnement imparfaites, avec des forces et des faiblesses différentes, pour obtenir une meilleure compréhension du problème avant même d'en produire la solution.
Mais est-ce encore du développement ?
Je pense que oui.
À condition de distinguer développer et écrire du code.
Développer une solution n'a jamais consisté uniquement à transformer manuellement une spécification en lignes de code.
Il faut comprendre un besoin, le traduire techniquement, choisir une architecture, comprendre les données, anticiper l'exploitation, faire des compromis, tester, diagnostiquer et faire évoluer l'existant.
L'écriture du code matérialise ces décisions.
Elle n'est pas l'ensemble de ces décisions.
Nous utilisons d'ailleurs depuis longtemps des abstractions.
Un framework évite de reconstruire des mécanismes standards.
Un ORM produit des requêtes que nous n'écrivons pas directement.
Une bibliothèque encapsule du code que nous ne lirons probablement jamais.
Une chaîne CI/CD automatise des opérations autrefois manuelles.
Les agents IA poussent cette logique beaucoup plus loin.
Ils commencent à automatiser non seulement des opérations techniques déterministes, mais une partie de la production intellectuelle intermédiaire : analyser un projet, proposer une implémentation, écrire le code, produire des tests ou rechercher l'origine d'un problème.
La rupture est importante.
Mais le raisonnement ne disparaît pas.
Il se déplace.
Moins écrire peut exiger de mieux comprendre
Lorsque je réalise moi-même une tâche, je peux ajuster certaines décisions progressivement pendant son implémentation.
Pour déléguer efficacement cette même tâche, je dois parfois être beaucoup plus clair dès le départ.
Quel est réellement le problème ?
Quel est son périmètre ?
Quelles contraintes sont non négociables ?
Qu'est-ce qui peut être modifié ?
Qu'est-ce qui constitue un résultat acceptable ?
Et quelles décisions suis-je prêt à laisser prendre à l'agent ?
Déléguer efficacement repose donc sur une capacité qui n'a rien de nouveau :
savoir décomposer un problème avant de distribuer son exécution.
L'expérience change de fonction
Mes années passées à développer, intégrer des systèmes, travailler sur différentes architectures ou exploiter des applications ne servent plus uniquement à savoir comment écrire une solution.
Elles servent aussi à déterminer si la solution proposée est raisonnable.
À reconnaître une architecture inutilement complexe.
À sentir qu'une abstraction arrive trop tôt.
À identifier qu'un problème présenté comme local révèle une faiblesse plus structurelle.
À comprendre qu'une solution correcte dans un environnement deviendra problématique dans un autre.
Cette expérience constitue le référentiel avec lequel j'évalue ce que l'agent me propose.
Le développeur ne disparaît donc pas derrière l'agent.
Son centre de gravité peut en revanche se déplacer : davantage concevoir qu'implémenter, davantage cadrer que détailler, davantage vérifier le comportement que suivre chaque instruction qui l'a produit.
Cela ne signifie ni que tous les développeurs deviendront des « orchestrateurs », ni que savoir coder deviendra inutile.
Ce serait reproduire le même quiproquo : confondre l'automatisation d'une partie du travail avec la disparition de la compétence permettant de le maîtriser.
Je formulerais plutôt les choses ainsi :
l'orchestration est en train de devenir une compétence supplémentaire du développement.
Et peut-être une compétence de plus en plus importante.
Lorsque la capacité à produire du code devient abondante, la valeur se déplace vers la capacité à décider quel code mérite d'être produit, dans quel système, sous quelles contraintes et avec quel niveau de confiance.
Alors, est-ce que je fais du vibe coding ?
Je peux maintenant revenir à la phrase qui a déclenché cette réflexion :
« Je vais faire comme toi, le vibe coding, en utilisant… »
Je comprends parfaitement pourquoi mon ami a employé cette expression.
Il voit des agents produire une part importante de mon code. Des outils capables d'explorer un projet, proposer des solutions, les implémenter et parfois mener une tâche presque jusqu'à son terme.
Mais non, ce n'est pas vraiment ce que j'appellerais du vibe coding.
Pas parce que je souhaite tracer une frontière entre ceux qui sauraient « vraiment » développer et les autres.
Simplement parce que le terme ne décrit plus suffisamment ce qui se passe.
Dans son sens initial, le vibe coding accepte précisément de relâcher la compréhension détaillée du code produit.
Dans ma pratique, je peux au contraire déléguer massivement sa production sans vouloir déléguer la maîtrise de ce que je construis.
Je déplace mon attention vers le problème, le contexte, les contraintes, les choix structurants, les points de contrôle et le résultat.
Et cette relation n'est pas à sens unique.
L'agent produit, explore, questionne et révèle certains de mes angles morts.
Mon expérience me permet de cadrer son travail, remettre en cause ses propositions et identifier certains des siens.
C'est pourquoi le terme qui correspond aujourd'hui le mieux à ma pratique reste probablement orchestration.
Pas parce que je serais devenu un chef d'orchestre regardant des machines travailler à ma place.
Mais parce que mon travail consiste de plus en plus à organiser un ensemble de capacités — humaines et artificielles — pour résoudre un problème et construire une solution que je reste capable de comprendre et d'assumer.
La nuance peut sembler mince lorsque l'on regarde simplement qui écrit le code.
Pour moi, elle change presque tout.
Sources
- Andrej Karpathy, publication du 2 février 2025 introduisant l'expression « vibe coding ».
- Réflexions ultérieures d'Andrej Karpathy sur la distinction entre vibe coding et utilisation professionnelle des assistants de développement IA.