Qu'est-ce que le vibe coding - et pourquoi il ne remplace pas l'ingénierie

Le vibe coding est une façon d'écrire du logiciel où l'on ne tape plus la plupart du code soi-même. On décrit en langage courant ce que l'on veut, un modèle d'IA génère l'implémentation, on l'exécute et on pilote au feeling : « ça a l'air bon », « c'est cassé », « fais marcher le formulaire sur mobile ». La boucle, c'est conversation plus exécution - pas une revue soigneuse de chaque ligne. :)

L'expression a décollé en 2025 après qu'Andrej Karpathy a décrit le fait de « se laisser pleinement porter par le vibe » : on oublie que le code existe, on recolle les erreurs dans le chat, et on laisse le modèle conduire. En 2026, le terme est partout - dans les offres d'emploi, les briefs clients et les fils qui promettent une vitesse ×10 ou qui préviennent que plus personne ne comprend le dépôt.

1. Ce qu'est le vibe coding - et ce qu'il n'est pas

Le vibe coding, ce n'est pas « activer l'autocomplétion Copilot ». L'autocomplétion vous laisse dans le fichier : vous lisez les tokens au fur et à mesure. Le vibe coding est plus proche de la mise en scène : vous formulez le résultat, l'agent écrit des fichiers, lance des commandes, et vous jugez le résultat comme un product owner juge une démo.

• C'est : des specs en langage naturel, des éditeurs agentiques (Cursor, Claude Code et équivalents), des boucles lancer-corriger-relancer, et l'acceptation d'un code que vous n'avez pas écrit ligne par ligne.
• Ce n'est pas : un nouveau langage, un remplacement de git, des tests ou de la revue de code, ni une licence pour sauter l'architecture.
• Ce n'est pas non plus magique : le modèle hallucine encore des APIs, recopie des patterns datés, et « corrige » volontiers un bug en supprimant le contrôle qui l'avait attrapé.

2. À quoi ressemble la boucle en pratique

Une session typique de vibe coding, c'est peu de frappe et beaucoup de pilotage. L'objectif reste dans votre tête ; le modèle est un junior très rapide qui a lu tout Internet et aucun de vos incidents de production.

• Vous décrivez le résultat : « Ajoute un index de blog paginé avec des URLs selon la locale, garde la mise en page actuelle. »
• L'agent modifie des fichiers, parfois plusieurs à la fois. Vous jetez un œil au diff - ou pas, si vous êtes pleinement en mode vibe.
• Vous lancez l'app. Si ça casse, vous collez l'erreur ou une capture de l'UI cassée et dites « répare ça ». On répète jusqu'à ce que le vibe soit bon.
• Vous livrez quand ça « a l'air fini ». C'est à cette étape que les amateurs s'arrêtent - et que les professionnels posent des questions gênantes.

3. Vibe coding, prompt engineering et code classique

Les trois se chevauchent — d'où le bruit des débats en ligne. La distinction utile : qui répond de l'exactitude.

• Code classique : vous concevez, tapez et déboguez. Le plus lent jusqu'à la première démo, la plus haute responsabilité sur chaque ligne.
• Prompt engineering : le code reste le vôtre. Vous écrivez des prompts structurés, contraignez la sortie et relisez avant le merge. Le modèle est un outil tranchant, pas le conducteur.
• Vibe coding : vous répondez du résultat plus que de l'implémentation. L'enjeu, c'est la vitesse jusqu'à un écran qui marche. La compréhension peut prendre du retard — jusqu'à ce que la production vous le rappelle.

4. Quand le vibe coding est le bon outil

Utilisé à dessein, c'est l'un des meilleurs accélérateurs de 2026. L'astuce : assortir la méthode au rayon d'impact.

• Prototypes et spikes : prouver une idée UX, une forme d'API ou une intégration tierce avant d'engager un sprint.
• Outils internes et scripts ponctuels : panels admin, convertisseurs CSV, générateurs de rapports - utiles, faible risque public.
• Boilerplate et raccordements : routes Next.js, branchement i18n, schémas de formulaires, squelettes de tests — le travail que vous savez déjà relire.
• Apprendre une nouvelle surface : « montre-moi un Stripe Checkout qui marche dans cette stack » est plus rapide que trois onglets de docs - si vous lisez ensuite ce qui a atterri.

5. Quand ça casse en silence

Le mode de défaillance du vibe coding n'est pas un écran d'erreur rouge. C'est une démo verte qui cache de la dette : logique dupliquée, contrôles d'auth manquants, variables d'env inventées, et un README qui décrit une autre app.

• On ne débogue pas ce qu'on n'a jamais lu. Quand le premier vrai bug arrive, « redemander au modèle » n'est pas une stratégie - c'est un pari.
• Sécurité et argent exigent des humains. Paiements, données perso, auth, et tout ce que voit le client ne se merge pas au vibe seul.
• L'équipe hérite du bazar. Un prototype du week-end devenu produit, c'est le classique pour passer l'année suivante à démêler des spaghettis d'IA.
• Les modèles optimisent pour « on dirait que c'est fini ». Ils ajouteront une fonctionnalité en copiant un fichier deux fois plutôt qu'en extrayant un module partagé - sauf si vous l'exigez.

6. Comment vibe-coder comme un ingénieur senior

Le pattern professionnel de 2026 n'est ni « jamais d'agents » ni « ne jamais lire le code ». C'est vibe, then verify : le modèle rédige le brouillon. Le merge, c'est vous.

• Encadrez le rayon d'impact : une fonctionnalité, une PR, une Definition of Done claire. Les agents errent si le prompt est une liste de souhaits.
• Donnez les contraintes d'emblée : stack, dossiers, « n'ajoute pas de dépendances », « réutilise les composants existants ». Un vibe flou produit du code générique.
• Lisez le diff. Vous n'avez pas besoin de l'avoir tapé. Vous devez pouvoir l'expliquer à la personne suivante - y compris vous dans six mois.
• Exigez des tests et une exécution : « ajoute un test pour l'état vide, puis lance la suite ». Une démo verte dans le navigateur n'est pas un job CI vert.
• Les secrets et identifiants de production ne vont pas dans le chat. Collez des erreurs, pas des fichiers .env.

7. Ce que ça change si vous achetez ou recrutez du dev

Pour un donneur d'ordre, la question n'est pas « est-ce que notre développeur utilise l'IA ? ». Tous les gens sérieux le font. La question : peuvent-ils encore expliquer le système quand le vibe s'est évaporé.

Le vibe coding peut baisser le coût d'une expérience : landing, flux de réservation, spike de Mini App Telegram. Il ne doit pas baisser le coût de possession. Il faut encore quelqu'un qui voit que le checkout a sauté la TVA, que la pagination a cassé les URLs ukrainiennes, ou que le « quick fix » a coupé le rate limiting.

Conclusion : garder le vibe, garder l’exigence

Le vibe coding est réel. C'est ainsi que beaucoup de bon logiciel commence aujourd'hui - et que beaucoup de mauvais se livre. La méthode est un multiplicateur : elle multiplie le goût et la discipline que vous avez déjà. Si vous savez spécifier, relire et assumer, les agents vous rendent plus rapides. Sinon, ils accélèrent le bazar.

Utilisez-le pour les brouillons, les spikes et la colle. Puis remettez le chapeau senior : lisez le diff, lancez les tests, et ne mergez que ce que vous pourriez maintenir à 2 h du matin. Ce n'est pas de l'entêtement à l'ancienne. C'est ainsi que le vibe coding devient de l'ingénierie - et non une démo vieillie en une nuit. :)