Le « Vibe Coding » qu’est-ce que c’est ? Et pourquoi tout le monde en parle ?

Depuis quelques mois maintenant la vague de l’intelligence artificielle inonde le marché, et s’infiltre dans les domaines de l’informatique avec une adoption record, modifiant profondément le comportement de certains travailleurs, dont … ceux des développeurs.

Et c’est avec ce grand mouvement qu’une nouvelle « méthode de développer » est apparue : le vibe coding.

Pour définir rapidement le Vibe Coding : déléguer le développement pur et dur à un LLM, via un IDE comme Cursor (ou Windsurf, VS Copilot …), et converser dans un language naturel pour développer le projet, tout en laissant un maximum de liberté au modèle de langage.

Pourquoi la sphère des devs en parle autant ?

Au delà de l’enjeu éthique, de nombreux développeurs s’enflamment sur les réseaux sociaux, évoquant des multitudes de problèmes inhérents à cette pratique :

• Faiblesses de sécurité dans le code généré,
• Mauvaise optimisation et utilisation de bibliothèques / fonctions dépréciées,
• Lourdeur du code / mauvaise gestion des ressources,
• Dépendance à un / plusieurs LLM,
• Surconsommation des ressources liées à l’execution des LLM,
• Diminution des connaissances au profit de la productivité

Autant vous dire que l’encre coule à ce sujet, et qu’avec la vitesse exponentielle d’évolution ce n’est pas encore prêt de s’arrêter.

Personnellement je rejoins ces constats sur plusieurs points, toutefois, et pour la science, j’ai quand même testé, et utilisé cette nouvelle méthode dans certains projets … Et je vous détaille mon ressenti juste ici.

Mon ressenti du « Vibe coding »

Pour la configuration, j’ai sélectionné VS Code avec l’extension Github Copilot + le mode agent.

L’objectif du projet démo :

• Partir d’un boilerplate Next.JS (incluant déjà un ORM ainsi que Auth.js),
• Ajouter tout le système d’authentification Google,
• Créer une section protégée derrière une authentification,
• Utiliser un scope particulier du compte Google pour récupérer la liste des fichiers hébergés sur le Google Drive de l’utilisateur,
• Permettre à l’utilisateur de lister ces fichiers avec une pagination,
• Un utilisateur pourrait renommer en masse ces fichiers suivant une convention de nommage (par ex. fichier-{nombre}.extension)
  

Les technos utilisées sont donc assez récentes, et le travail est déjà encadré par mon mini cahier des charges + les librairies déjà indiquées dans le package.json

Utilisation du mode agent

C’était assez étrange pour commencer, mais une fois mon fichier d’environnement configuré manuellement, à la place de taper des lignes de code, je me suis directement rendu dans le chat Copilot et j’ai tapé ma liste au père noël.

1 – L’authentification

Pour cette partie, l’agent a ajouté une vingtaine de lignes, en créant même une toute nouvelle petite arborescence pour la partie « protégée » derrière l’authentification.

Je me suis appliqué à relire chaque lignes de code généré, et à ma grande surprise, c’était assez qualitatif et aucune retouche n’a été nécessaire.

2 – L’espace « membre »

Encore une fois, j’ai simplement écrit ma petite liste au père noël, et cette fois-ci la génération s’est un peu compliquée.

Le besoin semble avoir été « compris », toutefois au bout d’une petite minute j’ai pu apercevoir que nous partions sur une fausse piste, j’ai du reprendre mon prompt et reformuler jusqu’à attteindre le résultat escompté.

Je suis directement passé au test, sans relire tout le code : encore une fois, impressionnant mon souhait était intégré.

3 – Intéraction avec l’API Google Drive

La dernière partie de la conception portait donc sur l’utilisation de l’API Google Drive pour récupérer les fichiers de l’utilisateur.

Place au chat, je n’avais même plus envie de taper une ligne de code, tant je considérais pour l’instant que ce code ne m' »appartenait plus ».

J’avais le sentiement d’être dans la peau d’un client qui commande sa conception avec un droit de regard dessus !

Ma demande a bien été comprise, et j’ai juste du ajuster un tout petit peu mon prompt pour m’assurer que la dernière version de l’API était bien utilisée.

5 – Sécurisation et documentation

Sur cette dernière phase de conception, j’ai demandé à l’agent de repasser en autonomie pour nous garantir une sécurité dans le stockage des informations, l’échange entre les API et le client, ainsi que générer une documentation technique dans un fichier markdown.

Toutes mes attentes ont été respectées, jusqu’à la documentation technique finalement largement suffisante et assez détaillée pour que j’en vienne à comprendre toute l’infrastructure du projet qu’il venait de générer.

Mon avis sur cette « expérience » du Vibe coding :

En tant que développeur qui a commencé à se former avec des livres, en écrivant du code et des algorithmes sur papier (avant de mourir d’impatience d’avoir un ordi à proximité pour tester tout ça), je ne vais pas vous le cacher : ça fait très bizarre.

Pas forcément dans la peur d’être un jour totalement « remplaçé«  par ces IA, mais dans cette nouvelle vision du développement.

En effet, si elle vient à se démocratiser, et qu’elle s’éloigne de la tendance pour en devenir une norme, certaines craintes s’éveillent en moi :

• Le plaisir et la satisfaction n’était pas là une seule minute,
  • Rien n’était comparable entre écrire et débugger le code VS laisser un agent le faire à ma place,
• J’avais l’impression de laisser mon siège à un executant et devenir un contrôleur qualité avec une casquette de superviseur,
• La patience s’est vite transformée en frustration et FOMO de productivité,
  • Lorsqu’un prompt est mal interprété, le besoin de ré-ajuster, attendre, « ne rien faire », re-itérer, jusqu’à que le code corresponde à mes attentes m’ont transformé en petit boule de frustration attendant juste un résultat sans plus même penser au chemin,
• La satisfaction du produit final était réduite,
  • En tant que développeur, un des plus beau moment pour moi est la présentation + l’exploration du produit fini. Là, cette fois-ci, je n’ai pas retrouvé un centième de ça, en étant juste content de terminer le produit, sans avoir marché sur la route pour y arriver.
• L’impression que le code ne m’appartient pas,
  • Un des sentiments le plus désagréable à mon goût, couplé à ce besoin de repasser sur sa propre architecture en « découvrant » des mécanismes 100% conçus par une autre « intelligence »,
  • Je me souviens d’une époque où je codais avec des collègues sur un même projet, en le partageant sur des repos, et en m’habituant à leur pattes, leur méthodes, leur coding guideline.
  • Là c’était juste un code efficace, « sécurisé » à la demande du prompt, mais sans empreinte, juste une combinaison gagnante.

Toutefois, même si le négatif était facile de souligner, je tiens quand même à rapporté quelques expériences positives et agréables :

• Un gain de temps plus que significatif pour des tâches que j’aurais délégué avec plaisir à l’époque,
  • L’intégration SSO par exemple, où le protocole reste toujours le même, déjà répété mille fois auparavant,
  • Les communication avec l’API de Google Drive, où l’agent a directement « pondu » toute la structure attendue par l’API ainsi que sa réponse, qui souvent prendrait une vingtaine de minutes à re-appréhender depuis la documentation officielle.
• L’impression d’avoir un compagnon qui pourrait me débloquer,
  • Un peu inhérent à la montée de l’IA dans notre domaine, mais cette sentation d’avoir une aide précieuse en cas de grand besoin ou même manque de temps pour une deadline,
• Le sentiment de pouvoir faire plus, en moins de temps
  • Sans forcément tomber dans le Vibes coding, le couplage avec l’IA donne l’impression d’avoir ce super pouvoir, qui compresse le temps et nous en laisse plus pour les tâches qu’on aime réellement dans le dev (gain du temps sur le SSO, au profit de plus de temps sur le développement de cet algo qui nous reste dans la tête depuis une semaine)

Synthèse de l’expérience

Malgré une balance avantages/inconvénients assez déséquilibrée à titre personnel, ce n’est pas forcément ces éléments qui vont me fait m’éloigner de cette pratique.

C’est plutôt cet amour du code, un peu toxique, qui m’empêche de me coucher tôt pour un bug, mais que me motive le matin à démarrer rapidos mon projet avant le taf pour appliquer le correctif.

Toutes ces petites satisfactions, qui se sont totalement évanouies à travers le « Vibes Coding », remplacées par de l’écriture de mes besoins comme un cahier des charges perpetuel que je rédige.

Un autre élément qui m’inquiète un peu plus, et qui me fait m’éloigner au « maximum » de cette pratique, est là dépendance à quelque chose qui nous échappe, et qui nous dépasse mille fois.

La dépendance à internet pour coder est déjà quelque chose que j’aime éviter, pour me permettre d’être autonome à des moments où la configuration ne me permet pas un accès, mais rajouter par dessus une indépendance à une infrastructure privée, à l’autre bout du monde, opaque, c’est trop pour ma part.

Toutefois, je souhaite pondérer les propos tenus par de nombreuses personnes en ligne : le vibe coding est dangereux, le code généré n’est pas sécurisé, …

=> Oui, et non. Comme tout usage de l’IA, la base est le prompt, et la finalité, la manière de le rédiger et d’échanger avec lui.

Effectivement, une personne sur un IDE IA avec aucune connaissance en code, va très certainement « vibe coder » une solution qui aura plus de chances d’être vulnérable, non sécurisée, et non optimisée.

Mais encore une fois, un véritable développeur qui « vibe code » sera en mesure de répérer ces faiblesses, essayera de « prompter » mieux, et de demander dans le pire des cas des corrections des fragilités qu’il remarquerait.

J’espère que cet article vous aura plu, et vous aura donner une idée plus précise de cette nouvelle tendance, et vous, vous en pensez quoi du vibe coding ?