Vibe Coding : l'engouement qui cache un vrai problème

Récemment, une fondatrice m'a montré son app web. Elle l'avait construite en un week-end avec des outils de coding IA. Pas de diplôme en informatique. Pas de bootcamp. Juste une bonne idée et des prompts bien fichus.

Le résultat ? Un système de login, un dashboard, de la persistence de données. Le tout en moins de 72 heures.

Puis elle m'a demandé de l'aider à déployer pour de vrais utilisateurs.

C'est là que ça se corse.

Le Protocole vs la Prod

Son prototype tournait parce qu'elle était la seule utilisatrice. Dès qu'on a voulu ajouter une deuxième personne, des bugs de concurrence sont apparus. La base de données n'avait pas de schema migrations — un rollback aurait détruit des données. Aucun test en vue. Donc refactorer, c'était jouer à l'aveugle avec une grenade dégoupillée. Et le déploiement ? Entièrement manuel, sans documentation.

Son week-end de coding ? Un excellent proof of concept. Mais pas du software prêt pour la prod.

C'est ce que la conversation sur le "vibe coding" refuse de voir. Les outils sont réels. La vitesse est réelle. La démocratisation du dev, c'est du concret.

Mais il y a une différence entre générer du code et engineer du software. Et cette différence, elle compte. Surtout quand tu te retrouves à 3h du matin face à un incident.

La Métrique Qui Compte Vraiment

Ma question favorite quand je vois du code généré par IA :

Est-ce que ça peut être safely mergé dans un codebase partagé ?

Pas "est-ce que ça marche". Pas "est-ce que le demo a fonctionné". Safely merged.

Ce mot "safe" veut tout dire. Le code peut être review par quelqu'un qui ne l'a pas écrit. Les tests vérifient le comportement, pas juste que ça ne crash pas. Le rollback est possible sans perte de données. Le change est assez narrow pour être compris et expliqué.

Quand un vibe coder mesure son succès, il mesure le temps pour avoir une première version qui marche. C'est utile pour du discovery et du prototyping. Mais dès que le software entre dans un environnement partagé, cette métrique ne veut plus rien dire.

Maintenant, tu mesures le time to safe merge. Et ça inclut le coût de la review, la qualité des tests, le risque au déploiement, la coordination, et la maintenance future.

Un software engineer pense à tout ce cycle dès le départ. Un vibe coder découvre ces enjeux plus tard — quand ils coûtent bien plus cher à adresser.

Génération vs Ownership

Il y a un shift subtil mais critique quand une IA génère ton code.

Le output n'est pas encore ton travail. C'est un point de départ. Du raw material qui doit être transformé en quelque chose que tu possèdes vraiment.

Ownership ça veut dire quoi concrètement ?

• Tu peux expliquer chaque décision meaningful dans le change
• Tu sais pourquoi chaque fichier existe et ce qu'il fait
• Tu as constrained le change à exactement ce qui était nécessaire — pas de boilerplate inutile ni de cleanup non lié
• Tu as écrit ou vérifié des tests qui check le comportement, pas juste les métriques de coverage
• Tu as considéré le rollback path

Ce travail, l'IA ne peut pas le faire pour toi. L'IA génère. Toi, tu décides. Et "décider" implique que tu as pensé aux alternatives, pesé les tradeoffs, et compris les conséquences.

Le code AI-generated qui n'a pas été correctement owned ? Je vois les mêmes problèmes à chaque fois :

• Changes trop larges parce que le modèle a généré plus que nécessaire
• Packages ajoutés sans justification claire
• Tests qui ont l'air écrits pour satisfaire un outil de coverage plutôt que pourattraper de vrais bugs
• Boilerplate qui existe parce que le modèle defaults vers du scaffolding au lieu de la simplicité

Rien de tout ça n'est la faute de l'IA. C'est le résultat d'un auteur qui a treaté le generated output comme du progrès au lieu de raw material.

Le Problème de Review Que Personne Ne Voit

Voici ce qui me keeps up at night :

Le code généré par IA change complètement l'équation de la review.

Quand un engineer humain écrit du code, il y a usually un decision trail. Tu peux ne pas être d'accord avec ses choix, mais au moins il y a des choix. Tu peux demander pourquoi il a utilisé cette abstraction, pourquoi la validation vit là, pourquoi ce library.

Avec du code AI-generated, certaines de ces "décisions" ne sont pas des décisions du tout. Ce sont des completions. Le modèle a choisi un pattern parce qu'il était statistiquement probable, pas parce que c'était le bon fit pour ton problème.

Et si l'auteur n'a pas converti cette completion en owned work, la review devient un cauchemar.

Tu ne peux pas demander au modèle pourquoi il a choisi cette approche. Tu ne peux pas demander à l'auteur pourquoi il a fait ce choix s'il ne le sait pas vraiment. Donc la review either surfac issues à travers un trial and error douloureux, soit elle n'arrive pas du tout.

C'est pourquoi je crois que la skill la plus importante à l'ère du AI-assisted development, c'est pas le prompting. C'est la capacité de prendre du generated output et de le transformer en code que tu comprends assez profondément pour own, explain et maintain.

Ce Que Ça Veut Dire Pour Ton Équipe

Si tu construis un prototype pour tester une idée, le vibe coding est totally legitimate. La vitesse d'apprentissage compte quand tu valides encore des assumptions. Utilise les outils, bouge vite, construis quelque chose à montrer.

Mais si ce prototype va devenir un vrai produit, à un moment donné le generated code doit passer à travers le filtre de quelqu'un qui pense comme un engineer.

Pas pour gatekeep. Pas pour ralentir. Mais pour s'assurer que ce qui ship est du code que ton équipe peut comprendre, maintain, et trust quand les choses merdent à 2h du mat'.

Chez NameOcean, on voit ce pattern tout le temps. Des startups qui bougent vite avec des outils IA pour valider leurs idées, puis qui hit a wall quand elles doivent scale. Les bonnes brings in engineering help à ce moment-là. Les mauvaises keeps piling features onto a codebase que personne ne comprend vraiment.

Le goal n'est pas d'éviter le AI-assisted development. Le goal, c'est d'être honnête sur où le travail commence et où il finit.

L'IA peut générer du code. Toi, tu dois engineer du software.

Le Mot de la Fin

Le vibe coding est un excellent point de départ. C'est un moyen de tester des idées rapidement, d'apprendre ce qui est possible, et de passer d'un concept à quelque chose de tangible sans des mois de dev traditionnel.

Mais le software engineering, c'est le full lifecycle. C'est du code que ton équipe peut review, maintain, et trust quand les choses merdent à 2h du mat'. Des changes assez narrow pour être compris et rollback si nécessaire. Prendre responsabilité pour les décisions — même quand ces décisions ont été informées par des suggestions IA.

Les meilleurs developers que je connais utilisent massivement les outils IA. Ils le font juste avec les yeux ouverts. Ils savent que le generated code, c'est du raw material, pas un finished product. Et ils savent qu'à un moment donné, quelqu'un doit faire le travail d'ingénierie qui fait la différence entre un demo cool et du software qu'on peut vraiment ship.

Donc oui, vibe code away. Construis vite, expérimente librement, utilise chaque outil à ta disposition.

Juste sache quand c'est le moment de passer du vibe à l'ingénierie.

Ton futur self, et ta future équipe, te diront merci.