Lokoyote

Il y a quelque chose d’assez vertigineux (au départ) dans le fait de pouvoir dire à une machine « crée-moi une application » et de la voir apparaître, en quelques minutes, sous ses yeux. On a l’impression de pouvoir d’un coup tout faire et de pouvoir créer facilement tout un tas de choses !

Coder sans savoir coder ?

La réponse courte est oui. Le vibe coding permet à quelqu’un qui n’a jamais écrit une ligne de code de produire, en quelques échanges avec une IA de type LLM, une application qui fonctionne.

Le vibe coding c’est ça : décrire dans le prompt d’une IA qui génère du texte, un projet pour le transformer en code fonctionnel et potentiellement en une application visuel.

Grossière on pourrait dire que c’est simple, il suffit de :

1. Choisir le bon modèle d’IA adapté (oui parce que tous les modèles ne se valent pas).
2. Décrire ce que vous voulez (déjà, écrire un vrai prompt suffisamment précis et exhaustif de ce qu’on veut c’est pas si simple).
3. L’IA génère le code.
4. Tester (à condition de savoir quoi tester).
5. Faire des retouts sur les erreurs à l’IA (à condition de savoir quoi lui remonter comme problème).
6. Elle corrige.
7. Vous recommencez (et si vous êtes curieux, vous comprenez comment votre code est fait).

Et si vous ne comprenez pas ce que l’IA a produit, il suffit de lui demander d’expliquer le fichier comme si vous n’aviez jamais programmé de votre vie.

Pour des prototypes, de petits outils, des sites vitrines ou des automatisations, cette mécanique va étonnamment loin. Le début du vibe coding est facile, presque trop facile.

Je vois souvent des influenceurs dire « Oh regardez ce que l’IA a fait ! » en montrant un vidéo d’une page HTML avec des animations, une ébauche de jeu vidéo qui pompe un style (un clone de CoD, RocketLeague et j’en passe).

Ce qu’il faut comprendre c’est que l’IA connaît le code car il existe beaucoup beauuuuucoup de projets sur internet qui ont servi à son entraînement auxquels s’ajoutent de nombreux exemples de programmation pédagogique.

Une IA générative n’invente pas le logiciel à partir de rien. Elle apprend des régularités à partir d’énormes quantités d’exemples et les recombine pour produire une solution plausible. Elle peut donc produire quelque chose de nouveau dans sa forme, mais cela ne signifie pas qu’elle comprend nécessairement le problème comme le ferait un concepteur humain.

Les projets générés par IA sont souvent assez beaux et épurés.
Clairement, 80% du boulot peut être fait en un prompt quand il est bien écrit.

Comprendre qu’un programme n’est pas seulement ce qu’on voit sur un écran est déjà pas simple pour beaucoup de gens.

L’exemple le plus parlant de mon entourage ce sont les « j’ai fait mon site internet avec ChatGPT ». Ok, tu as fait une page HTML jolie, mais où tu l’héberges ? Comment tu fais ta visibilité ? Est-ce que ça marche vraiment ? Comment tu modifies les pages ?

Donc écrire « Fais moi un jeu comme RocketLeague » c’est clairement insuffisant.

Mais…

Tant que tout va bien, on avance vite. Le problème surgit lorsque quelque chose bloque, ou que le projet gagne en complexité : authentification, base de données, sécurité, déploiement, bugs subtils, performances, etc.

Pour les petits bugs, avec des IA payantes en mode « code », on peut continuellement modifier le programme (jusqu’à ce que l’IA soit surchargée de texte et se mélange les pinceaux à cause de sa fenêtre contextuelle trop petite).

Ce genre de « détails » ne se voit pas à l’œil nu, elle se voit trois semaines plus tard, quand une faille de sécurité est exploitée ou qu’une base de données mal pensée s’effondre sous la charge.

C’est à ce moment que quelques fondamentaux cessent d’être optionnels : les variables et les fonctions, les conditions et les boucles, les bases du HTML/CSS/JavaScript, la logique des API et du JSON, le fonctionnement de Git, les principes des bases de données, quelques notions de sécurité. Rien d’extraordinaire pour quelqu’un qui sait coder ou qui connaît les notions, mais assez pour comprendre ce que la machine fait, et surtout pour repérer quand elle se trompe.

Le bon modèle n’est donc probablement pas « apprendre à coder puis vibe coder », ni l’inverse absolu « vibe coder et ne jamais rien apprendre ». C’est plutôt : vibe coder d’abord, pour se lancer et garder la motivation puis apprendre juste assez pour comprendre, contrôler et corriger ce que l’IA produit.

Beaucoup de codeurs utilisent maintenant l’IA comme assistant plutôt que de pratiquer le vibe coding au sens strict (une confiance aveugle au code de l’IA). Cela leur fait gagner énormément de temps, mais la relecture reste indispensable car une IA n’est qu’un générateur de texte à la base qui est capable de produire une réponse convaincante tout en se trompant.

Un projet « fini » n’est pas un projet abouti

Un projet généré par IA donne très vite l’impression d’être terminé. Une belle page d’accueil, des cartes bien alignées, une navigation plausible, quelques animations, une typographie soignée : à première vue, on jurerait un produit fini.

Même les ébauches de « jeux vidéo » semblent prometteurs avec quelques interactions.

C’est ce qu’on pourrait appeler le phénomène du « 80/20 visuel ».

Un LLM atteint une grande partie de la finition apparente en un temps record, mais ces derniers 10 à 20 % peuvent concentrer une part disproportionnée du travail réel.

La fameuse « loi de Pareto ».

Ces petits 20% manquants sont souvent ce qui fait la différence :

• les micro-ajustements de mise en page.
• la cohérence entre toutes les pages et tous les états de l’interface.
• les cas limites et les comportements inhabituels.
• les sécurités.
• les transitions, espacements, alignements et hiérarchies visuelles.
• la gestion de données réelles, imprévisibles.
• l’accessibilité, la gestion des erreurs, le responsive, les performances.
• la cohérence du système visuel sur la durée.
• etc

Il suffit de poser quelques questions simples pour se rendre compte que le fond n’est pas encore fini : que se passe-t-il si la donnée est vide ? Si le titre fait trois lignes au lieu d’une ? Sur mobile ? Avec deux cents éléments dans la liste ? En cas d’erreur réseau ? Après le cinquième clic sur le même bouton ? Quand deux composants qui se ressemblent doivent évoluer différemment ?
C’est là qu’on découvre que les fameux « 20 % restants » ne sont pas des détails cosmétiques mais l’architecture réelle du produit.

Tous ces trucs pénibles à corriger mais essentiels.

Du coup, on peut se demander si plus un LLM devient bon en génération visuelle, plus il risque de créer l’illusion d’un projet terminé.

Une interface magnifique donne envie de penser qu’un projet est fini puisqu’on nous a toujours appris à faire la mise en forme à la fin.

Cela ne veut pas dire que les projets générés par IA sont systématiquement bâclés ! Certains, notamment des interfaces assez standards, peuvent effectivement être quasi finalisables directement.

Ce qu’un LLM fait très bien :

• explorer rapidement plusieurs directions différentes.
• produire la structure globale.
• traduire une intention floue en interface concrète.
• générer les composants répétitifs.
• rendre le projet utilisable dans la grande majorité des cas simples.
• accélérer considérablement les premiers 70 à 90 % du travail.

Ce qu’un LLM fait beaucoup moins bien :

• sentir qu’un alignement est « légèrement faux ».
• garder une cohérence parfaite sur trente écrans différents.
• anticiper tous les cas d’usage réels.
• choisir les compromis.
• juger qu’un détail visuellement insignifiant est en réalité important pour un utilisateur.

Ce dernier segment peut représenter une part disproportionné du temps total du projet, parce qu’il ne s’agit plus d’ajouter des éléments mais de traquer des incohérences, souvent invisibles tant qu’on n’a pas cherché à les voir. De modifier des choses initialement cohérentes pour les ajuster.

Le LLM n’est pas un concepteur qui remplace le travail humain. C’est une machine extrêmement rapide pour produire une première solution plausible.

On peut demander à des agents IA de se surveiller entre eux en jouant des rôles, ça permet de gagner encore plus de temps mais il faut tout de même une surveillance.
On n’aura certainement pas une IA qui écrit du code toute seule pour des grands projets, mais une chaîne de contrôles entre plusieurs IA qui rend possible des projets presque automatisés.

L’IA peut inspecter, exécuter et même tester visuellement une partie de ce qu’elle produit, mais cela ne garantit pas qu’elle juge correctement le résultat du point de vue d’un utilisateur réel.

Si on reprend l’exemple de RocketLeague : il faut comprendre le ressenti du véhicule, la maniabilité, l’effet de caméra, la gestion réelle de la latence avec d’autres joueurs en situation réelle (et pas seulement sur un ordinateur en local), l’équilibrage de la difficulté, etc.

Le codeur reste encore celui qui décide, quels détails comptent vraiment, et reste celui qui vérifie que l’ensemble tient réellement debout.

Le vibe coding ne supprime pas la programmation. Il déplace la difficulté et laisse plus de temps pour gérer des problèmes de fond importants (c’est pas comme si on avait des fuites de données à gogo en ce moment par exemple).

Je pense qu’on peut réellement faire de beaux projets avec des bonnes idées même en « vibe codant » sans être codeur. De même qu’on peut avoir un bon sens artistique et des idées mais ne pas savoir retranscrire son imagination (par le dessin, la musique ou la vidéo). Ou simplement, ne pas avoir le temps de coder de A à Z quand ce n’est pas notre métier.

À ce moment, le Vibe coding est une solution facile pour retranscrire ses idées en quelque chose de concret.

Peut-être que ça déplace l’humain vers les tâches ingrates du codes qu’on voulait justement laisser aux robots ?
Peut-être que l’IA ne supprime finalement pas le travail difficile du code : elle supprime surtout une partie du travail facile à automatiser et laisse à l’humain les décisions, les arbitrages et les problèmes que l’on ne peut pas simplement résoudre en générant davantage de code.
On peut commencer à sen rendre compte en vibe codant justement.