Il faut arrêter d’appeler tout « Vibe Coding »

J’ai repris le codage après une longue pause, et c’est sur Lovable que je l’ai repris. Les applications avaient l’air super, fonctionnaient à première vue et se montraient opérationnelles en quelques heures. Au début, c’était remarquable. Mais cela ne suffisait plus dès que je voulais savoir ce que faisait le code – et pourquoi. C’est alors que mon approche a commencé à changer.

La différence ne porte pas sur l’outil, ni sur la quantité de code que l’IA écrit pour vous. C’est le contrat que vous acceptez avec votre résultat: si vous pouvez expliquer ce que vous venez déployé dans le monde, ou non.

Au sens d’origine, le « vibe coding » consiste à accepter un logiciel généré par l’IA sans examiner ni comprendre correctement ce qui se trouve dessous. Le développement assisté par l’IA est différent. Le modèle peut encore écrire l’essentiel du code, mais la personne qui construit le système reste responsable de la compréhension de son comportement, de la vérification de ses hypothèses et de la décision de le mettre ou non en production.

Pour une expérience jetable qui ne quitte jamais votre propre machine, la distinction peut avoir peu de conséquences. Dès que le logiciel est déployé, utilisé par d’autres ou connecté à de vraies données, elle devient déterminante.

Comment le “Vibe Coding” a perdu son sens

L’expression « vibe coding » a été créée en février 2025 par Andrej Karpathy, cofondateur d’OpenAI. Son exemple était volontairement désinvolte : un « projet de week-end jetable » construit en cliquant automatiquement sur « Tout accepter », en ignorant les différences et en laissant le code croître au-delà de sa compréhension.

Quelques semaines plus tard, le développeur et créateur d’outils Simon Willison a constaté que l’expression était employée d’une tout autre manière : comme terme générique pour toute programmation assistée par l’IA, ce qui, selon lui, affaiblit son sens et donne une fausse idée de ce que peut accomplir un développement assisté par l’IA responsable.

Fait révélateur, Karpathy a fini par être du même avis. Un an plus tard, il a introduit une autre expression pour désigner un travail plus rigoureux avec les agents de programmation. Il décrit « l’ingénierie agentique » comme un mode de travail dans lequel les développeurs dirigent et supervisent les agents au lieu d’accepter simplement leur production. La distinction compte : le développement professionnel assisté par l’IA exige planification, examen et responsabilité, contrairement au vibe coding occasionnel.

La ligne, c’est la responsabilité

La règle de Willison est simple et constitue un bon test pour tous : ne validez pas du code que vous ne pourriez pas expliquer à quelqu’un d’autre. Cela ne signifie pas lire chaque ligne ; lorsque les agents en produisent des centaines à la fois, même les développeurs expérimentés ne le font plus. Cela signifie comprendre la logique centrale et pouvoir justifier exactement pourquoi le code agit ainsi. Si vous le pouvez, peu importe que le code ait été écrit par un modèle ou par vous : ce n’est pas du vibe coding, c’est l’utilisation d’un outil pour créer un logiciel.

Une étude publiée en décembre 2025 confirme cette distinction. À partir d’observations sur le terrain et d’une enquête qualitative auprès de développeurs professionnels, les chercheurs ont constaté que les praticiens expérimentés gardaient le contrôle de la conception et de la mise en œuvre au lieu de confier tout le processus à l’IA. Ils traitaient les agents comme des collaborateurs, planifiaient soigneusement leur travail et restaient impliqués dans la supervision.

L’expérience seule ne suffit donc pas à expliquer la différence. Il s’agit de savoir si vous acceptez d’assumer la responsabilité de ce que l’IA a généré. Chaque développeur reprend cette décision à chaque projet.

Ce qui se passe quand le contrôle fait défaut

Les conséquences de la publication d’un logiciel dont on ne comprend ni ne vérifie la sécurité n’ont rien d’abstrait. Tea, une application destinée à protéger les femmes lors de rencontres, a exposé des dizaines de milliers de photos d’identité et plus d’un million de messages privés lors de deux incidents de sécurité. Parmi les défaillances figuraient un compartiment de stockage non sécurisé et une base de données distincte accessible sans authentification.

Le même problème fondamental — un logiciel qui semble fonctionner alors que sa logique d’autorisation reste dangereusement erronée — est apparu dans une application créée sur la plateforme Lovable : une recherche en sécurité a découvert que la logique d’autorisation était inversée, excluant les utilisateurs connectés tout en laissant les attaquants non authentifiés entrer librement. Plus de 18 000 utilisateurs, dont des étudiants, ont été touchés.

Il ne s’agit pas de cas isolés propres à de « mauvais » projets. Selon Google’s 2025 DORA report, 90 % des développeurs utilisent désormais l’IA au travail, tandis qu’environ un tiers disent n’accorder que peu ou aucune confiance à ce qu’elle génère.

L’utilisation de l’IA est maintenant généralisée malgré une confiance limitée. Cela rend l’examen attentif particulièrement important lorsque le code généré traite l’authentification, les autorisations ou des données sensibles.

Le contrôle se construit par couches, pas d’un seul coup

Dans mon cas, je n’ai pas commencé par un audit de sécurité formel. J’ai simplement refusé d’avancer chaque fois que je ne pouvais pas expliquer pourquoi quelque chose se comportait d’une certaine manière — un réflexe naturel lié à mon travail d’analyste. Je m’intéresse moins à la syntaxe qu’à la conformité du résultat avec le besoin d’origine. Lorsqu’il ne correspond pas, je poursuis l’enquête.

Mon mode de travail est devenu plus structuré à mesure que les projets devenaient sérieux. Au lieu de dépendre uniquement des prompts, j’ai commencé à préparer des spécifications avant toute génération. J’ai documenté les exigences métier, la pile technique et les intégrations. Puis sont venus les tests unitaires et les tests Playwright couvrant les principaux parcours utilisateur.

Les contrôles de sécurité ont été ajoutés de façon comparable. J’ai vérifié les bibliothèques choisies par l’IA et ajouté une analyse antimalware des fichiers téléversés. Chaque contrôle est né de la question « qu’est-ce qui pourrait mal tourner ensuite ? », et non d’une liste préparée dès le départ.

Cette habitude a permis de découvrir un problème sur un projet. L’IA avait introduit une bibliothèque incompatible avec la version du framework utilisée. L’application n’avait pas complètement échoué, si bien que l’incompatibilité aurait facilement pu passer inaperçue. La découvrir plus tard aurait rendu sa cause beaucoup plus difficile à identifier.

Par comparaison avec Tea et Lovable, c’était un problème ordinaire. Je l’ai trouvé tôt, corrigé et j’ai poursuivi. Voilà à quoi ressemble généralement la vérification en pratique. La plupart du temps, elle empêche de petits problèmes de devenir importants.

Je ne me méfie pas d’un code simplement parce que l’IA l’a produit. Je ne lui fais pas non plus confiance uniquement parce que l’application fonctionne. Les tests et l’examen permettent d’établir s’il se comporte comme prévu.

Du Vibe Coding à l’Agentic Engineering

Le passage de Karpathy du « vibe coding » à « l’ingénierie agentique » n’est pas qu’un changement de vocabulaire. « Ingénierie agentique » donne un nom plus utile à la direction prise par le développement professionnel. Les développeurs écriront peut-être moins de lignes eux-mêmes, mais leur responsabilité ne diminue pas. Leur travail se déplace vers la définition du comportement attendu, la direction des agents, le test de leurs résultats et la décision de ce qui peut être publié sans danger.

Le danger n’est pas que l’IA génère rapidement du code. Il est que la génération puisse aller plus vite que la compréhension. Dans ce cas, la productivité apparente dissimule des risques qui nobody has properly examined.

Une règle à conserver

Cessons d’utiliser « vibe coding » pour toutes les formes de développement assisté par l’IA : cela affaiblit l’expression et efface une différence de contrôle essentielle. Fixez une règle simple : ne publiez pas ce que vous ne pouvez pas expliquer. Puis construisez le contrôle à mesure que le projet grandit, couche après couche, en ajoutant des vérifications au rythme des risques qui apparaissent.

L’IA peut écrire l’essentiel du code. Elle ne peut pas assumer la responsabilité de sa publication. Celle-ci nous appartient toujours.