V
Secrets de Vibe Coding
La lettre
Article · Mai 2026

Comprendre le Vibe Coding :
Fondamentaux, Mécanismes et Philosophie pour Non-Codeurs

La machinerie. Le pourquoi du comment. Le moteur sous le capot.

Jean-Philippe Sportich
Auteur · Mai 2026
TL;DR — En 30 secondes

Cet article répond à la question : “Comment fonctionne vraiment le vibe coding ?”

  • ▪Définition : créer du logiciel en décrivant son besoin en langage naturel à une IA, qui écrit le code. Terme inventé par Andrej Karpathy en février 2025.
  • ▪Le mécanisme : un LLM prédit le mot suivant à partir d’un entraînement massif sur du code existant. Il ne “comprend” pas — il prédit avec une précision hallucinante.
  • ▪Pourquoi ça marche maintenant : trois révolutions superposées (Transformers, agents IA, IDE conversationnels) ont rendu la création logicielle accessible aux non-développeurs. 63% des vibe-codeurs en 2026 ne sont pas développeurs.
  • ▪Ce que vous apprendrez ici : la mécanique sous le capot, le vocabulaire complet (75 termes essentiels), les 4 paradigmes de création logicielle, les pièges cognitifs à éviter, et la philosophie de ce changement structurel.
Prêt à coder ?Consultez notre guide pratique du vibe coding 2026 →
I.

Bon. Vous êtes là.

C’est déjà un signe.

La plupart des gens qui tapent “vibe coding” dans Google veulent construire un truc avant ce soir. Une app de notes pour leur belle-sœur, un dashboard que leur DSI promet depuis 2022, un micro-SaaS qui paiera enfin leurs vacances en Corse. Très bien. Pour eux, on a écrit le guide pratique du vibe coding 2026 — 14 000 mots, des outils, une méthode, un cas concret qui livre une app RH en 3h47.

Illustration éditoriale : une silhouette ouvre le capot d'une voiture, révélant un réseau neuronal lumineux

Le genre qui ouvre le capot avant de démarrer la voiture.

Mais vous, visiblement, vous êtes du genre bizarre.

Le genre qui ouvre le capot avant de démarrer la voiture. Qui lit la notice IKEA même pour une étagère à 19 €. Qui demande “oui mais pourquoi” alors que tout le monde s’en fout déjà depuis deux questions. Le genre qui veut comprendre avant d’agir, même quand tout l’écosystème vous hurle dessus “MAIS VAS-Y, LIVRE, TU VERRAS BIEN”.

Bonne nouvelle : c’est exactement pour vous que cet article existe.

II.

Ce que vous n’allez PAS trouver ici

Vous ne trouverez pas, ou alors juste en passant :

  • ✕Une 47ème définition du vibe coding par Karpathy— on l’a déjà mise dans le guide pilier, et franchement, à force, le pauvre Andrej doit recevoir des notifications Google Alert sur son tweet toutes les 4 minutes.
  • ✕Un comparatif Lovable vs Cursor vs Bolt — on a un silo entier pour ça.
  • ✕Une méthode en 7 étapes pour livrer votre première app — pareil, c’est par là.
  • ✕Des promesses de “passer de 0 à $10K MRR en 30 jours en vibe codant pendant ta sieste”.Ce blog est une zone sans bullshit. On n’a pas le droit syndical d’en faire.
III.

Ce que vous allez trouver

La machinerie. Le pourquoi du comment. Le moteur sous le capot.

Illustration éditoriale : un cerveau mécanique en coupe, mêlant engrenages et réseaux neuronaux

Ce qui se passe vraiment dans les entrailles d’une IA quand vous lui demandez d’écrire du code.

Le moteur

On va parler de ce qui se passe vraimentquand vous tapez “crée-moi une app de gestion de stock” dans Claude Code et qu’il vous pond 400 lignes de TypeScript propre en 12 secondes. Spoiler : ce n’est ni de la magie, ni “l’IA qui pense”. C’est beaucoup plus intéressant que ça.

Le vocabulaire

On va démonter le vocabulaire. Token, contexte, embedding, MCP, agent, hallucination — 75 termes essentiels expliqués comme à un humain normal, pas comme à un doctorant en NLP qui aurait avalé un dictionnaire O’Reilly. Vous pourrez tenir une conversation en soirée tech sans avoir l’air d’avoir débarqué d’un congrès de comptables (sans offense pour les comptables, qui d’ailleurs font partie des meilleurs vibe-codeurs de 2026, mais on y reviendra).

Illustration éditoriale : une loupe qui décode un flux de données

Décoder le vocabulaire : tokens, embeddings, contexte...

Le pourquoi

On va creuser pourquoi ça marche. Et surtout, pourquoi parfois ça ne marche pas. Pas au sens “ton outil plante un mardi à 9h” — au sens beaucoup plus profond : pourquoi votre cerveau humain, votre expertise métier, votre rigueur ou votre flou, transforment exactement le même prompt en succès ou en catastrophe.

La philosophie

On va même parler philosophie. Oui, philosophie. Parce que le vibe coding n’est pas qu’une technique — c’est un basculement culturel sur qui a le droit de créer du logiciel. Et quand un truc bascule à ce point, comprendre ce qu’il dit du monde, c’est aussi se donner une longueur d’avance sur les 18 prochains mois.

IV.

Le pari de cet article

Voici ce qu’on parie ensemble : à la fin de ces ~4 500 mots, vous serez incapable de vous faire avoir.

Illustration éditoriale : une balance en équilibre entre cerveau humain et circuit IA

Le modèle mental complet. Pas la recette du gâteau. La compréhension du four.

  • →Plus jamais un consultant ne vous vendra du “vibe coding” en désignant un Notion templates marketplace.
  • →Plus jamais vous ne confondrez un LLM, un agent et une fenêtre de contexte.
  • →Plus jamais vous ne paniquerez en lisant “MCP” ou “RAG” ou “fine-tuning” — vous saurez ce que c’est, à quoi ça sert, et surtout quand ça ne sert à rien.
  • →Plus jamais vous ne croirez naïvement qu’un code qui marche est un code juste.
  • →Plus jamais vous n’imaginerez non plus qu’il faut être ingé pour construire un outil pro.

Vous aurez le modèle mental complet. Pas la recette du gâteau. La compréhension du four.

V.

À qui ça s’adresse vraiment

Soyons honnêtes. Cet article n’est pas pour tout le monde.

⚡

Si vous voulez livrer ce soir, allez sur le guide pratique, revenez ici dans deux semaines quand vous serez perdu sur un terme bizarre.

✓

Si vous êtes décideur, manager, formateur, RH qui doit lancer un programme citizen developer, ou simplement un curieux pathologique: restez. C’est exactement votre territoire.

?

Si vous êtes sceptiqueet que vous lisez ça en mode “on va bien voir s’il dit des conneries” : restez aussi, et surtout, contestez. Le sceptique informé est notre meilleur lecteur. Le sceptique mal informé est juste un type énervé sur LinkedIn.

VI.

Petit avertissement avant de plonger

Cet article fait environ 4 500 mots. À 230 mots/minute, ça vous fait 20 minutes de lecture concentrée. Vingt minutes. Le temps d’un café et demi. Le temps d’une visio inutile chez Marc en compta. Le temps que met votre dernier mail à Kévin de la DSI pour rester sans réponse.

Si vous lisez ça en diagonale entre deux Slack, vous allez survoler des nuances qui font toute la différence. Vous reviendrez dans trois mois en disant “ah mais en fait je n’avais pas compris ça”. Spoiler : ce sera dit dans cet article. C’est juste vous qui ne l’aurez pas lu.

Donc, suggestion d’humain à humain : mettez le téléphone en mode avion, fermez Slack, prenez 20 minutes. Considérez ça comme un investissement. À la fin, vous aurez économisé peut-être 50 heures de tâtonnement dans les semaines qui viennent.

Pas mal pour un article gratuit, non ?

On y va.

Premier arrêt : ce qui se passe vraiment dans les entrailles d’une IA quand vous lui demandez d’écrire du code. Préparez votre tête, on enlève quelques certitudes.

1.

Comment une IA peut-elle vraiment
écrire du code ?

(le mécanisme expliqué)

Bon. Posons-nous deux minutes.

Vous tapez “crée-moi une app de gestion de notes de frais” dans Claude Code. Vous appuyez sur Entrée. Vous allez chercher un café. Vous revenez. Il y a une app. Elle marche. Elle est plutôt jolie. Elle gère même les justificatifs PDF avec un tableau filtrable et une auth Google.

Question légitime : qu’est-ce qui vient de se passer ?

Si votre première intuition est “l’IA a compris ce que je voulais et l’a codé”, on a un problème. Pas grave, mais réel. Parce que cette phrase contient deux mots qui, techniquement, sont faux : “compris” et “codé”.

Je sais. Insupportable. Mais restez avec moi cinq minutes, parce que comprendre ce qui se passe vraiment va changer la façon dont vous prompterez à partir de maintenant. Genre vraiment changer. Pas du “tips & tricks productivité 2026” — du changement de modèle mental.

1a.

Le LLM en 3 minutes pour non-tech

(sans aucun terme de doctorant)

Un Large Language Model — LLM pour les intimes, “le truc derrière ChatGPT” pour votre tante — n’est ni intelligent, ni stupide. C’est autre chose. Quelque chose qu’on n’avait jamais eu avant, et pour lequel les analogies humaines marchent toutes à moitié.

Voici la meilleure que j’aie trouvée en 3 ans à l’expliquer :

Illustration éditoriale : un perroquet mécanique perché sur une pile de livres de code, crachant des tokens lumineux

Le perroquet à mémoire photographique.

Imaginez un perroquet qui aurait lu absolument tout GitHub, Stack Overflow, la doc Python officielle, 200 000 tutos YouTube transcrits, et la quasi-totalité d’Internet en passant. Un perroquet avec une mémoire photographique et zéro ego.

Ce perroquet ne comprend rien. Mais il a vu tellement, tellement de fois la suite function calculateTotal(items) { être suivie par let total = 0; items.forEach... qu’il peut prédire la suite avec une précision hallucinante.

C’est tout. Vraiment. C’est. Tout.

Comment le LLM génère du code — token par token

crée-moi une app de notes de frais→import React from 'react'; ...
Tokens d’entrée (votre prompt) Tokens prédits (un par un)

Un LLM, c’est une machine à prédire le mot suivant. Pas la phrase, pas l’idée, pas l’intention. Le mot. Enfin techniquement le token, on y reviendra, mais en gros : le bout de mot. Un par un. À une vitesse démente.

Quand vous lui tapez “crée-moi une app de notes de frais”, il ne se dit pas “ah tiens, un humain veut une app”. Il se dit (de façon très métaphorique, il ne se dit rien du tout en fait) : “étant donné ces mots-là, dans cet ordre-là, quel est le token le plus probable qui devrait suivre ?”

Et il le crache. Puis il regarde ce qu’il vient de cracher, et il prédit le suivant. Et ainsi de suite, 5000 fois, à la suite, pendant 12 secondes. Au bout du compte : une app de notes de frais.

C’est de la prédiction statistique appliquée à la production de texte. Le code étant du texte, le LLM le génère exactement comme il génère un poème, une recette de bœuf bourguignon, ou un mail de relance commerciale.

Conséquence pratique n°1

Votre IA ne “sait” pas coder. Elle sait prédire ce à quoi du code ressemble dans la situation que vous décrivez. La nuance est minuscule. Elle change tout.

1b.

Pourquoi le code se prête si bien à ce jeu de prédiction

Voilà une question que personne ne se pose et qui pourtant explique pourquoi le vibe coding existe en 2026 et pas en 2014.

Pourquoi diable les LLM sont-ils si bons pour générer du code, alors qu’ils sont parfois si médiocres pour, mettons, écrire un poème original ou résumer une réunion sans rater l’essentiel ?

Réponse en trois points qui vont vous rester :

CritèreLangage humainCode
01Règles de syntaxeSouples, ambiguës, infiniesStrictes, rigides, prévisibles
02Corpus d'entraînementVarié, contradictoire~300M repos GitHub, cohérent
03Vérification qualitéSubjective, lente, chèreAutomatique en 0,3s : ça marche ou ça plante
01

Le code suit des règles. Le langage humain, bof.

Quand vous écrivez en français, vous pouvez dire “j’ai vu un mec hier qui faisait du vélo en mangeant une pizza”. C’est correct. Mais aussi “hier j’ai vu un mec qui mangeait une pizza en faisant du vélo”. Ou “un mec, hier, mangeait une pizza, et il faisait du vélo”. Trois phrases, même sens. Infiniment ambiguës pour une machine.

✅ Fonctionne

let x = 5;

❌ Plante

Let x = 5;

C’est rigide, c’est strict, c’est prévisible. Et un perroquet à mémoire photographique adore la prévisibilité.

02

Le corpus d’entraînement est gigantesque et propre.

GitHub, c’est ~300 millions de repos publics. Stack Overflow, 25 millions de questions/réponses indexées avec votre vote pour signaler ce qui est juste. La documentation officielle de chaque langage. Les tutos. Les MOOC.

~300M
repos GitHub publics
25M
Q&R Stack Overflow
∞
docs officielles, tutos, MOOC

Le code, c’est un océan d’exemples cohérents. Le rêve de tout perroquet apprenant.

03

Le code se vérifie tout seul.

Vous écrivez un poème : qui dit s’il est bon ? Un éditeur, un lecteur, votre maman. Subjectif. Long. Coûteux.

Vous écrivez du code : vous l’exécutez. Soit il marche, soit il plante. Verdict en 0,3 seconde, gratuit, objectif.Ce qui veut dire que pendant l’entraînement, les ingénieurs peuvent automatiser massivement la vérification de la qualité. Le perroquet apprend à pondre du code qui marche, parce qu’on lui répète 50 milliards de fois “ça, ça marche, fais pareil” / “ça, ça plante, ne fais plus”.

Conclusion contre-intuitive

Le code est probablement le terrain de jeu idéal pour un LLM. Probablement plus que le langage humain naturel. Ce qui est délicieusement contre-intuitif pour quiconque pensait que les machines coderaient en dernier.

1c.

Le rôle de la “fenêtre de contexte”

(et pourquoi votre IA vous oublie parfois)

OK. Maintenant, le truc qui va vous éviter 70% des frustrations futures.

Votre IA a une mémoire de travail limitée. On appelle ça la fenêtre de contexte (ou context windowdans les docs). C’est la quantité de texte qu’elle peut “voir” simultanément quand elle prédit le token suivant.

Illustration éditoriale : vue plongeante sur un bureau éclairé partiellement — la zone éclairée est la fenêtre de contexte

La taille de la table de travail du perroquet. Ce qui dépasse, il l’oublie.

La fenêtre de contexte, c’est la taille de la table de travail du perroquet. Plus la table est grande, plus il peut étaler de documents devant lui pour s’inspirer. Plus elle est petite, plus il doit empiler, et plus il oublie ce qui dépasse.

Quelques ordres de grandeur, mai 2026 :

ModèleAnnéeTokensÉquivalent humain
GPT-3.52022~4 000Une nouvelle
GPT-4202332 000Un mémoire de master
Claude Sonnet 4.52025200 000Un roman entier
Claude Opus 4.720261 000 000Une codebase d'entreprise
Gemini 2.5 Pro20262 000 000Guerre et Paix × 2,5

C’est ce qui a changé entre 2023 et 2026. Pas la “compréhension” — la capacité à voir loin.

Conséquence pratique n°2

Quand vous travaillez sur un projet et que votre IA “oublie” un détail décidé 40 prompts plus tôt, ce n’est pas qu’elle est distraite. Elle ne le voit plus. Le détail est sorti de la table.

Le réflexe pro : récapituler régulièrement le contexte important. Pas par politesse. Par mécanique.

Si votre IA doit savoir que “tous les prix sont en HT, que la TVA est de 20%, et qu’on est en France”, redites-le toutes les 20 prompts. Sinon, attendez-vous à voir surgir un dollar canadien dans votre app de facturation française. Vrai exemple. Pas inventé. Quelqu’un que je connais. Qui n’est pas moi. (Si.)

1d.

Ce qui se passe vraiment quand vous tapez “Crée-moi une app”

Allez, le grand final de cette section. On démonte le moteur, étape par étape, en accéléré.

Votre prompt

“Crée-moi une app de notes de frais avec upload PDF, extraction auto du montant et de la TVA, base Supabase, déploiement Vercel.”

Voici ce qui se passe, dans l’ordre, en ~12 secondes :

Illustration infographique : pipeline montrant les 5 étapes de la génération de code par IA

Le pipeline complet : du prompt à l’app en 5 étapes.

1

Tokenisation

instantané

Votre phrase est découpée en tokens — des bouts de mots. "Crée" peut être un token, "-moi" un autre, "app" un autre. En général, 1 token ≈ 4 caractères en français, ou 0,75 mot.

Votre prompt fait peut-être 35 tokens. Le système ajoute ses propres instructions cachées (le system prompt) qui en font peut-être 2 000. Plus votre historique. Plus les fichiers du projet. Total entrée : peut-être 15 000 tokens.

2

Encodage en vecteurs

instantané

Chaque token est transformé en un embedding — une longue liste de chiffres qui représente sa "position sémantique" dans l'espace des concepts.

"Chien" et "chat" sont proches dans cet espace. "Chien" et "démocratie" sont loin. "App de notes de frais" est proche de tout ce que le perroquet a vu autour de "expense tracker", "facture", "saisie de frais", etc.

3

La grande prédiction

10-12 secondes

Le modèle prédit le premier token de sa réponse. Puis le suivant. Puis le suivant. À chaque token, il regarde l'intégralité du contexte pour décider quoi cracher ensuite.

Il va probablement générer (dans cet ordre, parce qu'il a vu des millions de projets comme ça) : la structure du projet, le schéma de base de données, le composant React de l'upload, la fonction d'extraction PDF, la configuration Supabase, le déploiement Vercel.

4

Exécution

quasi-instantané

Claude Code (ou Cursor, ou Lovable) prend les tokens générés, les interprète comme du code, écrit les fichiers sur le disque, lance les commandes.

npm install, démarrage du serveur de développement. À ce moment-là, vous voyez l'app apparaître dans votre navigateur. Effet "magie". Mais ce n'est pas de la magie.

5

Le test de réalité

⚠️ à vous

C'est ici que la moitié des gens se fait avoir. L'app semble marcher. Vous testez avec un PDF de la SNCF. Ça marche. Vous publiez sur LinkedIn que le vibe coding est l'avenir.

Trois jours plus tard, un collègue uploade une facture allemande en .heic, et tout pète. Pourquoi ? Parce que dans le corpus d'entraînement, les exemples de PDF français bien formatés sont surreprésentés. L'IA a prédit le cas courant. Pas votre cas particulier.

1e.

🎯 Ce qu’il faut retenir de cette section

On a démonté le moteur. Voici les trois insights qui vont changer votre façon de prompter à partir de maintenant :

1

Votre IA ne comprend pas. Elle prédit.

Ce qui veut dire que la qualité de sa sortie dépend de la qualité statistique de ses entrées. Vous lui donnez un prompt vague comme un cours de philosophie ? Elle vous rend du code vague. Vous lui donnez un prompt précis comme une spec technique d'ingénieur ? Elle vous rend du code précis.

2

Sa "mémoire" est une fenêtre, pas une boîte.

Ce qui veut dire que sur les projets longs, récapituler le contexte est une compétence. Pas une politesse. Pas une option. Une compétence pro.

3

Elle reproduit le passé.

Ce qui veut dire que pour les cas standards, elle est imbattable. Pour les cas exotiques de votre métier — et c'est précisément là que vous apportez de la valeur — vous devez enrichir le contexte avec ce qu'elle ne pouvait pas voir dans son entraînement : vos règles métier, vos contre-exemples, vos cas tordus.

Voilà. Vous avez maintenant un modèle mental fonctionnelde ce qu’est un LLM. Pas une métaphore vendeuse. Pas un buzzword. Une vraie image opérationnelle de la mécanique sous-jacente.

À partir de maintenant, quand on vous dira “l’IA a compris ton besoin”, vous saurez sourire en coin. Et quand on vous dira “le vibe coding va remplacer les devs”, vous saurez aussi sourire en coin — mais pas pour la même raison.

On enchaîne. Section suivante : les 3 révolutions techniques qui ont rendu le vibe coding possible. Parce que comprendre le LLM, c’est bien. Comprendre pourquoi tout ça n’existait pas il y a 3 ans, c’est ce qui va vous donner la lucidité stratégique sur les 24 prochains mois.

Suite ci-dessous
II.

Les 3 révolutions techniques qui ont rendu le vibe coding possible

Question légitime : pourquoi maintenant ?

Le concept de “faire écrire du code par une machine” date des années 50. Les premiers générateurs automatiques de code, des années 80. Copilot, 2021. Mais le vibe coding au sens “un expert métier livre une vraie app en 4 heures” — ça, c’est strictement 2025-2026.

Pas parce que les LLM sont devenus magiques. Parce que trois révolutions techniques se sont superposées au même moment. Sans l’une des trois, le vibe coding n’existe pas. Avec les trois ensemble, il devient inévitable. Décortiquons.

2a.

Révolution 1 : les Transformers et l’attention (2017)

L’an zéro du vibe coding s’appelle 2017. Un papier de recherche Google, titre charmant : “Attention is All You Need”. Pas vendeur. Pas viral. Lu par 12 personnes à l’époque. Aujourd’hui, base technique de tout ce que vous utilisez.

Ce que ce papier invente, c’est l’architecture Transformer. Sans rentrer dans la cuisine, retenez ceci :

AVANT 2017

Les modèles de langage lisaient les mots dans l'ordre, un par un, comme un humain lisant une phrase à voix haute. Lents. Limités.

DEPUIS 2017 (TRANSFORMERS)

Le modèle peut regarder tous les mots en même temps et décider de l'importance de chacun pour prédire le suivant. C'est l'attention.

C’est la capacité à dire “pour prédire ce token, je vais surtout regarder ce mot-là, ce mot-là, et ignorer ce blabla-là”.

Concrètement : dans la phrase “Le code que Jean a écrit hier soir, après son cours de yoga, plante.”, un Transformer sait que pour comprendre “plante”, ce qui compte c’est “code”, pas “yoga”. Sans Transformers, le modèle aurait pondéré tous les mots à peu près pareil.

Cette innovation a démultiplié les performances par un facteur ridicule. GPT, BERT, Claude, Gemini, Llama — tous sont des Transformers. Tous descendent en ligne directe de ce papier de 2017.

💡Sans Transformers, pas de LLM capable de tenir une conversation. Sans LLM, pas de vibe coding.
2b.

Révolution 2 : l’agentivité (2024-2025)

OK. Vous avez un LLM qui prédit bien. Sympa. Mais ça ne suffit pas.

Parce qu’un LLM “classique”, c’est un échange ping-pong : vous tapez, il répond, fin. Pour coder une vraie app, ce n’est pas suffisant. Il faut que la machine puisse agir : créer des fichiers, exécuter des commandes, lire ses propres erreurs, corriger, recommencer.

C’est ce qu’on appelle un agent. Et c’est la deuxième révolution. Un agent IA, c’est un LLM avec des mains. Il peut :

  • ✓Lire votre projet existant
  • ✓Écrire des fichiers
  • ✓Exécuter du code et lire le résultat
  • ✓Voir une erreur et décider de la corriger tout seul
  • ✓Boucler sur ce travail, parfois pendant des minutes, sans intervention humaine

La différence est énorme. Avec un chatbot, vous codez à la main en copiant ses suggestions. Avec un agent, vous décrivez ce que vous voulez, vous allez faire pipi, vous revenez, c’est fait.

Cette bascule s’est faite entre fin 2024 et mi-2025. Claude Code en mai 2025 a été un point d’inflexion : premier agent codeur grand public qui tourne vraiment, qui ne se perd pas au bout de 3 itérations.

🤖Sans agents, vous avez un assistant. Avec des agents, vous avez un exécutant.
2c.

Révolution 3 : les IDE conversationnels

Dernier morceau du puzzle. Un agent puissant, ça ne sert à rien si vous devez l’installer en ligne de commande après 3 heures de config Linux. Il faut que l’interface suive.

Petite chronologie express :

2021

GitHub Copilot

Premier assistant code grand public. Autocomplete améliorée. On reste loin du vibe coding.

2023

ChatGPT Code Interpreter

On peut exécuter du Python en chat. Hype massive, usage réel limité.

2024

Cursor & Builders Web (Bolt, Lovable, v0)

Premier IDE pensé "IA-first" (Cursor). Apparition des builders prompt-to-URL (Bolt.new, Lovable) : vous décrivez, ça déploie sans aucun outil à installer.

2025

Claude Code, Windsurf, Replit Agent

Les agents codeurs autonomes deviennent grand public.

2026

MCP (Model Context Protocol) standardisé

Tout se connecte à tout de façon fluide.

En 5 ans, on est passé d’“installez VS Code, configurez votre environnement, créez un compte GitHub, apprenez les bases” à “ouvrez un onglet, décrivez votre app, attendez 3 minutes”.

💻Sans cette révolution d'interface, le vibe coding restait réservé à ceux qui savaient déjà coder.
2d.

🎯 Ce qu’il faut retenir de ces 3 révolutions

Trois révolutions, toutes nécessaires, dont aucune n’aurait suffi seule :

  • 1. Transformers (2017)la machine sait prédire du code de qualité.
  • 2. Agents (2024-2025)la machine sait exécuter le travail seule.
  • 3. IDE conversationnels (2024-2026)l’humain non-tech peut piloter la machine.

Vous avez maintenant le mécanisme et son contexte historique. Vous savez comment ça marche, et pourquoi maintenant.

Reste un détail : tout ce qu’on vient de décrire utilise un vocabulaire spécifique que vous allez croiser partout — token, embedding, MCP, RAG, agent, hallucination — et que la plupart des articles vous balancent sans définir.

C’est là qu’on va maintenant. Section suivante : le glossaire complet du vibe coding en 75 termes. Préparez un café, c’est dense mais c’est la section que vous reviendrez consulter pendant des mois.

On enchaîne. Section suivante : le glossaire complet du vibe coding en 75 termes. Préparez un café, c’est dense mais c’est la section que vous reviendrez consulter pendant des mois.

Découvrir ci-dessous
III.

Le glossaire complet du vibe coding (75 termes essentiels)

Section de référence. À garder en favori. Elle reviendra vous sauver dans 3 semaines quand un consultant vous balancera “RAG”, “MCP server” ou “edge function” en réunion sans broncher.

Comment lire ce glossaire : chaque définition est autonome, compacte, factuelle. Quand un terme mérite une nuance pratique ou une mise en garde, on l'a ajoutée.

Filtrer par catégorie
📑 Index alphabétique (cliquable)
LLM·Token·Contexte·Embedding·Hallucination·Fine-tuning·RAG·Agent·MCP·RLHF·Prompt·System prompt·Température·Modèle de raisonnement·Multimodal·Front-end·Back-end·API·Base de données·Framework·Librairie·Repo·Commit·Branch·Merge·Deploy·Build·Runtime·Dépendance·Package manager·Environnement·Variable·Fonction·Composant·État·IDE·IDE IA-first·Builder visuel·No-code·Low-code·BaaS·PaaS·Edge function·Serverless·Container·Docker·Vercel·Supabase·GitHub·MCP server·Vibe coding pur·Agentic engineering·Spec-driven development (SDD)·Prompt engineering·Méthode CLAIR·Itération·Refactoring·Code review·Test·Debugging·OWASP Top 10·Vulnérabilité·RGPD·Audit log·Secrets manager·OAuth·Zero data retention·Anonymisation·Durée de conservation·Traçabilité·Token cost·Context cost·Plafond mensuel·Micro-SaaS·Citizen developer

LLM

(Large Language Model)Concepts IA

Modèle d'IA entraîné sur d'énormes quantités de texte pour prédire le token suivant. Ex : Claude, GPT, Gemini.

Token

(unité, jeton)Concepts IA

Unité de texte traitée par un LLM. ~4 caractères en français, ~0,75 mot. Vous êtes facturé au token, entrée et sortie.

Contexte

(context window)Concepts IA

Quantité de tokens que le modèle peut voir simultanément. De 4K à 2M selon les modèles. Dépassée = oubli silencieux.

Embedding

(plongement vectoriel)Concepts IA

Représentation d'un mot ou texte en liste de chiffres. Permet de calculer la 'proximité' entre concepts. Base de la recherche sémantique.

Hallucination

Concepts IA

L'IA invente une fonction, une librairie ou un fait qui n'existe pas, avec aplomb. À vérifier systématiquement.

Fine-tuning

(affinage)Concepts IA

Entraînement supplémentaire d'un modèle sur des données spécifiques. Coûteux. Rarement utile en vibe coding — le prompt engineering suffit dans 95% des cas.

RAG

(Retrieval-Augmented Generation)Concepts IA

Technique qui permet à l'IA de chercher dans une base de documents avant de répondre. Utilisé quand le contexte ne suffit pas.

Agent

Concepts IA

LLM capable d'agir : lire, écrire, exécuter, boucler sans intervention humaine. Différence clé avec un chatbot.

MCP

(Model Context Protocol)Concepts IA

Standard ouvert lancé par Anthropic fin 2024 pour connecter agents IA et outils externes. L'USB-C de l'IA.

RLHF

(Reinforcement Learning from Human Feedback)Concepts IA

Méthode d'entraînement où des humains notent les réponses pour rendre l'IA plus utile et moins dangereuse.

Prompt

Concepts IA

Instruction en langage naturel donnée à l'IA. Votre nouvelle compétence cœur.

System prompt

Concepts IA

Instructions cachées données à l'IA avant votre prompt, qui définissent son rôle et son comportement. Souvent invisibles mais déterminantes.

Température

Concepts IA

Paramètre qui règle la créativité d'un modèle. 0 = déterministe et répétitif, 1+ = créatif et imprévisible. Pour du code : 0,2-0,3 idéal.

Modèle de raisonnement

(reasoning model)Concepts IA

Modèle qui prend le temps de 'réfléchir' avant de répondre, en générant des étapes intermédiaires. Plus lent, plus cher, plus précis. Ex : Claude Opus, o3.

Multimodal

Concepts IA

Modèle capable de traiter plusieurs types d'entrées : texte, image, audio, vidéo. Pratique pour analyser une capture d'écran de votre app qui plante.

Front-end

(côté client, frontal)Vocabulaire Dev

La partie visible d'une app : interface, boutons, écrans. Ce que voit l'utilisateur.

Back-end

(côté serveur, dorsal)Vocabulaire Dev

La partie invisible : logique métier, base de données, traitement. Ce qui tourne sur les serveurs.

API

(Application Programming Interface)Vocabulaire Dev

Pont standardisé entre deux logiciels. Votre app appelle l'API Claude → réponse de Claude.

Base de données

Vocabulaire Dev

Stockage organisé d'informations. Excel sous stéroïdes. En vibe coding, souvent Supabase ou Firebase.

Framework

Vocabulaire Dev

Squelette de code qui structure un projet. Ex : React (front), Next.js (full-stack), FastAPI (back).

Librairie

(library, lib)Vocabulaire Dev

Bout de code réutilisable que vous importez dans votre projet. Plus léger qu'un framework.

Repo

(repository, dépôt)Vocabulaire Dev

Dossier de votre projet versionné sur GitHub. Contient tout l'historique des changements.

Commit

Vocabulaire Dev

Sauvegarde d'une version de votre code. Comme un point de restauration Windows, mais qui marche vraiment.

Branch

(branche)Vocabulaire Dev

Version parallèle de votre code pour tester sans casser la version stable.

Merge

(fusion)Vocabulaire Dev

Réunir une branche dans une autre. Étape souvent stressante en équipe, triviale en solo.

Deploy

(déploiement)Vocabulaire Dev

Mettre votre app en ligne, accessible à des utilisateurs. Avec Vercel ou Lovable : un bouton.

Build

(compilation)Vocabulaire Dev

Étape qui transforme votre code source en version optimisée pour la production.

Runtime

(environnement d'exécution)Vocabulaire Dev

Ce qui fait tourner votre code une fois lancé : Node.js, navigateur, serveur. Sujet de bug fréquent.

Dépendance

Vocabulaire Dev

Librairie externe dont votre projet a besoin pour fonctionner. Listées dans package.json côté JavaScript.

Package manager

(gestionnaire de paquets)Vocabulaire Dev

Outil qui installe et met à jour vos dépendances. npm, pnpm, yarn côté JavaScript.

Environnement

(env)Vocabulaire Dev

Configuration de votre projet selon le contexte : développement, test, production. Variables différentes pour chacun.

Variable

Vocabulaire Dev

Étiquette qui désigne une valeur. prix = 19.90. Premier concept de logique à comprendre.

Fonction

Vocabulaire Dev

Bloc de code réutilisable qui prend des entrées et produit une sortie. Le LEGO de base du développement.

Composant

Vocabulaire Dev

Bloc d'interface réutilisable (un bouton, un formulaire, une carte). Logique cœur de React et v0.

État

(state)Vocabulaire Dev

Données qui changent dans votre app (panier, formulaire en cours, utilisateur connecté). Gérer l'état = compétence centrale.

IDE

(Integrated Development Environment)Écosystème Outils

Logiciel pour écrire du code. Ex : VS Code, JetBrains.

IDE IA-first

Écosystème Outils

IDE conçu autour de l'IA, pas avec l'IA en plugin. Cursor, Windsurf en sont les standards 2026.

Builder visuel

(prompt-to-URL)Écosystème Outils

Plateforme où vous décrivez votre app et obtenez un site déployé. Lovable, Bolt.new, v0.

No-code

Écosystème Outils

Construire une app par glisser-déposer dans un éditeur visuel propriétaire. Bubble, Make, Airtable. Code inaccessible.

Low-code

Écosystème Outils

Entre no-code et code : interface visuelle + scripts. Retool, Mendix.

BaaS

(Backend-as-a-Service)Écosystème Outils

Service qui fournit base de données, auth et stockage clé en main. Supabase, Firebase.

PaaS

(Platform-as-a-Service)Écosystème Outils

Service qui héberge et déploie votre app sans gérer les serveurs. Vercel, Netlify, Render.

Edge function

Écosystème Outils

Petit bout de code exécuté au plus près de l'utilisateur, sur un réseau mondial. Rapide, scalable, peu cher.

Serverless

Écosystème Outils

Architecture où vous payez uniquement à l'usage, sans gérer de serveur. Évite les coûts fixes.

Container

Écosystème Outils

Boîte standardisée qui contient votre app et tout ce dont elle a besoin. Tourne pareil partout.

Docker

Écosystème Outils

Outil standard pour créer des containers. Vous n'en avez probablement pas besoin pour démarrer en vibe coding.

Vercel

Écosystème Outils

Plateforme de déploiement très populaire en vibe coding. Édite v0. Gratuit pour démarrer, payant à l'échelle.

Supabase

Écosystème Outils

BaaS open source, hébergement européen disponible. La référence pour la base de données en vibe coding.

GitHub

Écosystème Outils

Plateforme de versioning et de collaboration. Votre filet de sécurité universel.

MCP server

Écosystème Outils

Connecteur qui expose un outil ou un service au protocole MCP. Plus de 10 000 disponibles en 2026.

Vibe coding pur

Méthodologies

Approche originelle de Karpathy : on prompt, on accepte, on ne lit pas le code. OK pour du jetable, dangereux pour la production.

Agentic engineering

Méthodologies

Évolution mature du vibe coding : l'humain pilote, valide chaque étape, teste. La version 2026 qui compte.

Spec-driven development (SDD)

Méthodologies

Méthode qui formalise un cahier des charges avant de prompter. Antidote au mur des 3 mois.

Prompt engineering

Méthodologies

Discipline d'écriture de prompts efficaces. Compétence cœur du vibe coder.

Méthode CLAIR

Méthodologies

Structure de prompt : Contexte, Logique, Acteurs, Interface, Résultat.

Itération

Méthodologies

Cycle prompt → résultat → ajustement. Le vrai travail du vibe coder.

Refactoring

Méthodologies

Réécriture du code pour le simplifier sans changer son comportement. L'IA est excellente pour ça.

Code review

Méthodologies

Relecture critique du code généré. En vibe coding : faite par un autre LLM, ou par un dev humain pour les projets sérieux.

Test

Méthodologies

Vérification automatisée qu'un bout de code fait ce qu'il doit. Souvent négligé en vibe coding. Erreur classique.

Debugging

Méthodologies

Trouver et corriger un bug. En vibe coding : copier l'erreur dans l'IA, recommencer. Compétence 'rouge zen'.

OWASP Top 10

Sécurité & RGPD

Liste des 10 vulnérabilités web les plus critiques. 45% du code généré par IA en contient au moins une (Veracode 2026).

Vulnérabilité

Sécurité & RGPD

Faille de sécurité exploitable. En vibe coding : injection SQL, secrets exposés, auth bricolée.

RGPD

Sécurité & RGPD

Règlement européen sur les données personnelles. Amendes jusqu'à 4% du CA mondial. Pas négociable.

Audit log

(journal d'audit)Sécurité & RGPD

Table qui enregistre qui a fait quoi, quand, sur quelle donnée. À ajouter dès la V1.

Secrets manager

Sécurité & RGPD

Coffre-fort pour vos clés API et mots de passe. Jamais dans le code. Toujours dans le manager.

OAuth

Sécurité & RGPD

Standard d'authentification 'connexion via Google/Microsoft'. Évite de stocker des mots de passe.

Zero data retention

Sécurité & RGPD

Garantie contractuelle qu'un fournisseur d'IA ne stocke pas vos données. Indispensable pour le pro.

Anonymisation

Sécurité & RGPD

Suppression irréversible des données permettant d'identifier une personne. Pseudonymisation ≠ anonymisation.

Durée de conservation

Sécurité & RGPD

Période légale pendant laquelle vous pouvez garder une donnée. CV refusé : 12 mois. Salarié : durée d'emploi + 5 ans.

Traçabilité

Sécurité & RGPD

Capacité à reconstituer l'historique d'une donnée ou d'une décision. Obligation pour l'IA Act sur les décisions automatisées.

Token cost

Économie & Business

Coût d'un appel à l'API, calculé au token entrée + token sortie. Varie selon le modèle. Opus > Sonnet > Haiku.

Context cost

Économie & Business

Coût caché lié à l'envoi du contexte à chaque requête. Recoller un long historique 50 fois = facture explosive.

Plafond mensuel

(budget cap)Économie & Business

Limite que vous fixez dans la console de votre fournisseur. À mettre dans les 10 premières minutes. Pas après.

Micro-SaaS

Économie & Business

Logiciel en ligne payant, sur un marché de niche, opéré par 1 à 3 personnes. Format roi des vibe coders entrepreneurs.

Citizen developer

Économie & Business

Expert métier qui construit ses propres outils logiciels sans être développeur. Gartner prévoit qu'ils créeront 40% des apps d'entreprise d'ici 2028.

3a.

🎯 Ce qu’il faut retenir du glossaire

75 termes. La majorité de ce que vous croiserez dans le vibe coding pendant 18 mois.

Trois conseils d’usage :

  • 1. Ne mémorisez pas tout d’un coup.Revenez consulter quand un terme apparaît dans un article ou une conversation. Le cerveau ancre mieux dans le contexte d’usage.
  • 2. Concentrez-vous sur les 20% qui couvrent 80% du quotidien.LLM, token, contexte, agent, MCP, prompt, API, déploiement, RGPD, plafond mensuel. Maîtriser ces 10-là, c’est déjà 80% des conversations pro.
  • 3. Téléchargez le PDF.Cette section existe aussi en version imprimable, à garder ouverte pendant vos sessions.
Télécharger le glossaire PDF

Maintenant que vous parlez la langue, on peut entrer dans le vrai sujet : qu’est-ce qui différencie vraiment les 4 paradigmes pour construire du logiciel en 2026 ?

Spoiler : ce n’est pas ce qu’on vous raconte.

On enchaîne. Section suivante : Les 4 paradigmes pour faire du logiciel en 2026. Parce qu'un tableau comparatif vous dit quoi choisir. Une analyse paradigmatique vous dit pourquoi vous risquez de mal choisir.

Découvrir ci-dessous
IV.

Les 4 paradigmes pour faire du logiciel en 2026

Le pilier central de ce blog a déjà comparé vibe coding, no-code et low-code dans un tableau efficace. Allez le lire si vous l’avez raté — c’est par ici.

Ici, on creuse autre chose : la philosophie de chaque paradigme. Parce qu’un tableau comparatif vous dit quoi choisir. Une analyse paradigmatique vous dit pourquoi vous risquez de mal choisir.

Quatre familles. Quatre rapports différents au logiciel. Quatre profils humains qu’elles servent.

Paradigme 1le "tout faire main"

Le développement classique

La philosophie : vous maîtrisez chaque ligne. Rien n'est caché. Tout est sous contrôle.

Le profil type : l'artisan-ingénieur. Aime comprendre la mécanique avant de l'utiliser. Tolère la lenteur initiale pour la maîtrise finale.

La force réelle : plafond technique infini. Tout est possible, tout est explicable, tout est auditable. Indispensable pour systèmes critiques.

La faiblesse réelle : coût d'entrée massif. Apprentissage en années. Rentabilité sur des projets sérieux uniquement. Un dev junior coûte 4 000 €/mois.

Quand c'est le bon choix : systèmes critiques 24/7, secteur régulé (banque, santé, défense), produits scalés à des millions d'utilisateurs.

Paradigme 2le "tout cliquer"

Le no-code

La philosophie : vous assemblez. Vous ne construisez pas. La plateforme tient les murs porteurs.

Le profil type : l'opérationnel pragmatique. Veut un résultat aujourd'hui, accepte de louer plutôt que posséder.

La force réelle : vitesse de mise en route. Une app Bubble en 2h, un automate Make en 30 minutes. Imbattable pour le simple et le standard.

La faiblesse réelle : lock-in maximal. Vous habitez le jardin de quelqu'un d'autre. Le jour où Bubble triple ses prix, vous n'avez aucune sortie de secours. Plafond technique bas dès qu'on sort du standard.

Quand c'est le bon choix : automatisations simples, formulaires, MVP très standards, vous n'avez pas vocation à rester sur cette app dans 5 ans.

Paradigme 3le "cliquer + scripter"

Le low-code

La philosophie : un compromis. L'essentiel en visuel, les exceptions en code.

Le profil type : l'hybride. Souvent un développeur fatigué de tout coder ou un opérationnel ambitieux qui a touché à JavaScript.

La force réelle : équilibre vitesse/flexibilité. Plus puissant que le no-code, plus rapide que le code pur.

La faiblesse réelle : double dépendance. Vous êtes coincé entre la plateforme propriétaire ET le code customisé qu'il faut maintenir. Le pire des deux mondes quand la plateforme évolue.

Quand c'est le bon choix : outils internes d'entreprise stables, projets RH/marketing avec un peu de complexité, contextes où la DSI impose la plateforme.

Paradigme 4le "tout décrire"

Le vibe coding

La philosophie : vous orchestrez, l'IA exécute. Le langage naturel devient l'interface de programmation.

Le profil type : l'expert métier décomplexé. Connaît son domaine, sait briefer, accepte d'itérer plutôt que perfectionner.

La force réelle : vous possédez le code. Pas de lock-in plateforme. Plafond technique quasi-illimité. Démarrage rapide.

La faiblesse réelle : rigueur déplacée, pas supprimée. La discipline n'est plus dans la syntaxe — elle est dans le prompt, les tests, la sécurité. Beaucoup la sous-estiment.

Quand c'est le bon choix : outils internes spécifiques, prototypes destinés à devenir des produits, projets où votre expertise métier fait la différence, micro-SaaS.

La matrice de décision : votre profil → votre paradigme

Plus utile qu’un tableau comparatif générique : trois questions qui décident pour vous.

QUESTION 1
Combien d’utilisateurs visez-vous à 12 mois ?
  • • < 50 personnes, usage interne → vibe coding ou no-code.
  • • 50 à 5 000, contexte pro → vibe coding ou low-code.
  • • > 5 000, produit grand public → vibe coding + revue dev, ou dev classique.
QUESTION 2
À quel point votre besoin est-il standard ?
  • • Hyper standard (formulaire, dashboard simple) → no-code suffit.
  • • Standard avec une spécificité → vibe coding optimal.
  • • Complètement spécifique à votre métier → vibe coding ou dev classique.
QUESTION 3
Voulez-vous posséder votre code dans 3 ans ?
  • • Indifférent, je veux juste que ça marche → no-code OK.
  • • Oui, c'est un actif → vibe coding.
  • • Oui et c'est critique → dev classique.

Croisez les trois réponses, et le bon paradigme s’impose souvent de lui-même.

4a.

🎯 Ce qu’il faut retenir des 4 paradigmes

Aucun paradigme n’est supérieur à un autre. Ils servent des contextes différents.

Le piège classique : choisir un paradigme par mode ou par groupe d’appartenance. Les “no-codistes” sur LinkedIn vous diront que tout est no-codable. Les développeurs vous diront que le vibe coding est dangereux. Les vibe-codeurs vous diront que le no-code est mort. Ils ont tous tort, et ils ont tous raison.

La bonne question n’est pas “quel paradigme est le meilleur ?”. C’est “quel paradigme sert le mieux mon contexte précis ?”.

Et maintenant qu’on a posé la mécanique (sections 1-2), le vocabulaire (section 3) et la cartographie des choix (section 4), on peut enfin parler de la dimension la plus négligée : ce qui se passe dans votre cerveau humain quand vous vibe-codez. Parce que c’est là, et pas dans les outils, que se jouent les vrais succès et les vrais échecs.

On enchaîne. Section suivante : Comprendre les mécanismes cognitifs. Les pièges mentaux, l’effet Dunning-Kruger appliqué au code assisté et comment garder la tête froide face au rouge.

5.

Comprendre les mécanismes cognitifs :
pourquoi le vibe coding marche (ou pas)

Voici une statistique qu’on ne lit nulle part : à outil égal, à modèle égal, à brief égal, deux personnes obtiennent des résultats radicalement différents en vibe coding. Le facteur de variation est de l’ordre de 1 à 10.

Ce n’est pas l’outil. Ce n’est pas l’IA. C’est le cerveau humain en face.

Voici ce qui se joue, dans votre tête, quand vous vibe-codez.

5a.

La compétence cœur déplacée : du “savoir-faire” au “savoir-décrire”

Pendant 60 ans, créer du logiciel = maîtriser une syntaxe. Vous ne saviez pas écrire for i in range(10): ? Vous étiez exclu de la création.

Schéma : la pensée structurée traduite directement en architecture conceptuelle par l'IA

La transition du clavier de codeur vers la modélisation conceptuelle.

En 2026, créer du logiciel = savoir décrire un problème sans ambiguïté. La syntaxe est gérée by la machine. Ce qui devient critique, c’est votre capacité à structurer une intention.

Or cette compétence-là, vous l’avez déjà ou pas. Pas grâce à des cours d’informatique. Grâce à vos années à briefer, rédiger des procédures, expliquer à un stagiaire, écrire un cahier des charges.

C’est pour ça que les contrôleurs de gestion, juristes, RH ops et marketeurs cartonnent en vibe coding. Pas parce qu’ils sont “techniques”. Parce qu’ils ont 20 ans d’entraînement à formaliser de la complexité.

5b.

Pourquoi les experts métier battent les développeurs juniors sur leur terrain

Le pilier central raconte le cas de la juriste qui a battu un stagiaire data Python sur l’extraction de clauses contractuelles. Allez le lire icisi ce n’est pas fait — c’est instructif.

L’explication cognitive est simple : le code de la juriste, ce n’est pas son code. C’est son prompt système de 800 mots. Bourré de définitions juridiques, de contre-exemples, de cas particuliers. Du savoir tacite formalisé.

Le stagiaire avait la syntaxe. La juriste avait l’ontologie du métier. En vibe coding, l’ontologie bat la syntaxe à chaque fois.

Conséquence cruelle pour les développeurs juniors : leur compétence différenciante (savoir coder) devient une commodité. Conséquence libératrice pour les experts métier : leur savoir tacite devient enfin transmissible à une machine.

5c.

Les pièges cognitifs du vibe coding

Piège cognitif n°1

L’illusion de compétence

Vous tapez un prompt. L’IA produit 400 lignes de TypeScript. L’app marche.Votre cerveau conclut : “j’ai compris ce qui se passe.”

Dessin conceptuel : une belle façade propre masquant des fondations chaotiques en échafaudages

Non. Vous n’avez pas compris.Vous avez vu un résultat fonctionnel. C’est tout.

L’illusion de compétence est le piège n°1 du vibe coding débutant. Elle vous fait sous-estimer ce qui est sous le capot, sur-estimer votre maîtrise, et déployer en production des choses que vous ne pouvez ni auditer ni corriger.

L’antidote : Accepter explicitement “je sais faire faire, je ne sais pas faire”. C’est OK pour 80% des cas. Ce n’est pas OK pour les 20% critiques (sécurité, données sensibles, scalabilité). Là, il faut un humain qui sait vraiment.
Piège cognitif n°2

La passivité face à l’IA

Karpathy l’a dit en inventant le terme : “tu ne lis pas les diffs, tu acceptes les vibes”. Charmant pour un weekend project. Catastrophique pour un outil de production.

La passivité face à l’IA, c’est accepter les sorties sans les interroger. “Elle l’a dit, donc c’est juste.”Faux. L’IA a prédit le token le plus probable. Probable ≠ juste.

L’antidote : Scepticisme actif systématique. À chaque sortie, deux questions internes : “qu’est-ce qui pourrait casser ?” et “qu’est-ce qu’elle a peut-être inventé ?”. C’est cette posture qui sépare l’agentic engineering du vibe coding pur.
Piège cognitif n°3

La confiance mal calibrée

Vous testez votre app. Ça marche.Vous concluez : “c’est solide.”

Dessin conceptuel : un camion lourdement chargé testant un pont de fils suspendu

Erreur de calibration. Ça marche avec vos données de test.Pas avec les données réelles de Bertrand qui uploade un fichier de 80 Mo nommé “RAPPORT FINAL (V2) - copie - ok bon.pdf” un lundi à 9h.

Le cerveau humain est très mauvais à calibrer la confiance. On surgénéralise depuis 3 cas testés. On confond “ça n’a pas planté” avec “c’est robuste”.

L’antidote : Tester avec les vraies données pourries du quotidien dès l’heure 1. Pas après le déploiement. Pas en V2. Heure 1. Caractères spéciaux, fichiers énormes, valeurs manquantes, doublons. Les vrais utilisateurs sont des artistes du chaos.
5d.

🎯 Ce qu’il faut retenir

Trois compétences cognitives séparent ceux qui livrent de ceux qui galèrent :

  • 1.Formaliser son savoir tacite — votre expertise métier devient votre vrai code.
  • 2.Scepticisme actif— chaque sortie de l’IA est une hypothèse à tester, pas une vérité à accepter.
  • 3.Calibration de la confiance— distinguer “ça marche” de “c’est robuste”.

C’est le sujet de la section suivante. Et on va vous prévenir : ça gratte un peu.

6.

La philosophie du vibe coding :
ce qu’il dit de notre rapport à la technologie

(section de recul critique)

Section bonus pour ceux qui pensent encore que le vibe coding est “juste un outil”.

Spoiler : ça ne l’est jamais. Aucune technologie qui change qui a le droit de créer ne reste “juste un outil”. Elle reconfigure la société. Discrètement, mais profondément.

6a.

La démocratisation de la création logicielle : analogie avec l’imprimerie

1450, Gutenberg. Avant : produire un livre = un moine, deux ans, six bras cassés. Après : produire un livre = quelques heures, presse, papier.

Illustration éditoriale : une presse d'imprimerie Gutenberg modifiée produisant des lignes de code et des crochets lumineux

La presse à imprimer du code : la chute du monopole de la syntaxe.

L’imprimerie n’a pas “fait des moines plus productifs”. Elle a enlevé le monopole d’une classe sociale sur la production de savoir. La Réforme, les Lumières, la révolution scientifique : pas possibles sans elle.

Le vibe coding, c’est ça pour le logiciel. Pendant 60 ans, créer du code = être passé par une école d’ingénieur ou un bootcamp. Aujourd’hui, créer du code = savoir décrire un besoin métier. Le monopole technique tombe.

L’histoire dira si c’est aussi structurant. Tout porte à le croire.

6b.

Le “citizen developer” : nouveau métier ou simple évolution ?

Gartner parle de “citizen developer” depuis 2014. À l’époque, c’était un fantasme marketing pour vendre du Microsoft Power Apps. En 2026, c’est devenu une réalité statistique : 63% des vibe-codeurs actifs ne sont pas développeurs.

Mais “citizen developer” est-il un métier ? Ou une compétence transverse, comme savoir utiliser Excel ?

Mon pari : compétence transverse. Comme Excel dans les années 90. D’abord réservée aux contrôleurs de gestion, puis devenue compétence générale attendue de tout cadre. Le vibe coding suivra la même courbe — sur 5 à 10 ans.

Dans 7 ans, ne pas savoir vibe-coder un outil interne sera aussi gênant que ne pas savoir faire un tableau croisé dynamique aujourd’hui.

6c.

Vibe coding et fracture numérique : ouverture ou nouvelle fracture ?

Côté ouverture : un expert métier sans formation tech peut désormais créer ses propres outils. Énorme libération.

Côté fracture : encore faut-il savoir prompter, comprendre les limites, gérer la gouvernance. Et ça, ça suppose un niveau de littératie numérique élevé. Le vibe coding démocratise pour ceux qui sont déjà numériquement à l’aise. Pas pour les autres.

Risque réel : on remplace la fracture “sait coder vs sait pas coder” par une nouvelle fracture “sait prompter vs sait pas prompter”. Plus subtile. Tout aussi excluante.

La responsabilité collective des écoles, entreprises et formateurs des 5 prochaines années est immense — et la plupart ne l’ont pas vue.

6d.

La question éthique : qui est responsable d’un code généré par IA ?

Votre app vibe-codée plante. Elle facture en double 200 clients. Qui est responsable ?

  • ✕L’IA ? Non, ce n’est pas une personne juridique.
  • ✕Anthropic ou OpenAI ? Décharge contractuelle dans les CGU.
  • ✓Vous ? Oui. Sans ambiguïté.

Le droit français et l’IA Act européen sont clairs : l’humain qui déploie est responsable. Vous ne pouvez pas dire “c’est l’IA qui a écrit ça”. Vous l’avez accepté, déployé, mis entre les mains d’utilisateurs.

Conséquence pratique : la gouvernance n’est pas un luxe optionnel. C’est une protection juridique de base.

6e.

Vibe coding et avenir du travail : 3 scénarios possibles

Illustration éditoriale : diagramme montrant trois voies d'évolution du travail en synergie avec l'IA
Scénario 1

La grande déprofessionnalisation

Les développeurs juniors disparaissent. Les seniors restent. Les experts métier deviennent constructeurs. Probable à 60%.

Scénario 2

La nouvelle ingénierie

Les développeurs montent en abstraction : architecture, sécurité, performance. Les experts métier prennent le périmètre “outil interne”. Coexistence. Probable à 30%.

Scénario 3

Le retour de bâton

Une catastrophe sécuritaire massive provoque un retour aux pratiques traditionnelles. Probable à 10%, mais pas nul.

Dans les trois cas, ne pas s’y mettre n’est pas une stratégie de survie.

6f.

🎯 Ce qu’il faut retenir

Le vibe coding n’est pas un outil. C’est un changement structurelsur qui a le droit de créer du logiciel. Comme l’imprimerie, comme Excel, comme Internet.

Ce qui veut dire que les vrais enjeux ne sont pas dans le choix d’outil. Ils sont culturels, éducatifs, juridiques. Et ceux qui le comprennent prennent 18 mois d’avance sur ceux qui le voient encore comme “un truc de geek”.

Maintenant qu’on a posé la dimension philosophique, on peut regarder les limites conceptuelles profondes — celles que personne ne mentionne dans les articles vendeurs.

On enchaîne. Section suivante : Les limites conceptuelles du vibe coding. Ce que l'IA ne sait intrinsèquement pas faire et comment repérer les murs invisibles avant de s'y écraser.

7.

Les limites conceptuelles (pas opérationnelles)
du vibe coding

(les barrières réelles du modèle)

Le pilier central de ce blog liste les pièges pratiques : tests négligés, sécurité oubliée, DSI court-circuitée. Allez les voir ici, ils sont essentiels.

Ici, on parle d’autre chose. Des limites de fond que même le meilleur vibe-codeur du monde ne peut pas contourner. Celles qui ne se règlent pas avec un meilleur prompt.

7a.

La limite épistémologique

Comment vérifier un code que vous n’avez pas compris ?

Vous lisez le résultat dans le navigateur : ça marche. Vous testez : ça marche. Vous déployez : ça marche. Mais vous ne savez pas pourquoi ça marche. Et donc vous ne savez pas non plus pourquoi ça pourrait ne plus marcher demain.

Cette limite ne se résout pas. Elle se gère: tests automatisés, revues croisées par d’autres IA, audit ponctuel par un développeur humain. Mais elle ne disparaît pas.

7b.

La limite de l’abstraction

À partir de quelle complexité le langage naturel devient-il insuffisant ?

Une app de gestion de notes de frais : le langage naturel suffit. Un système de trading haute-fréquence : impossible. Entre les deux, un seuil flouoù l’imprécision du français devient un obstacle.

Illustration éditoriale : un homme essayant de décrire une structure géométrique tridimensionnelle complexe à l'aide de bulles de texte simplifiées

Le langage naturel montre ses limites face aux structures hautement complexes.

Symptôme : vous écrivez des prompts de plus en plus longs pour préciser, et l’IA se contredit de plus en plus. C’est le signal qu’il faut formaliser autrement (schéma, code partiel, spec technique).

7c.

La limite de la créativité technique

L’IA reproduit ce qu’elle a vu. Elle n’invente pas d’architectures.

Pour 95% des projets, c’est suffisant — vous n’avez pas besoin d’inventer une nouvelle architecture pour faire un dashboard RH. Mais pour les 5% innovants, l’IA vous propose toujours les patterns standards. Pas les ruptures.

Si votre ambition est de créer un produit techniquement original, le vibe coding seul ne suffit pas. Il faut un humain qui pense en dehors du corpus.

7d.

La limite de la dépendance

Que devient votre app si Anthropic explose ses prix, change ses CGU ou disparaît ?

Illustration éditoriale : une ville moderne suspendue par des câbles reliés à un unique monolithe cloud flottant

Le risque du fil à la patte avec les fournisseurs d'APIs IA.

Votre code, lui, reste. C’est l’avantage du vibe coding sur le no-code. Mais si votre app appelle l’API Claude pour son fonctionnement quotidien, vous êtes dépendantd’un fournisseur unique.

Parade : architecturer pour pouvoir changer de modèle. Anthropic aujourd’hui, OpenAI demain, modèle open source après-demain. Compétence d’architecte, pas de vibe-codeur naïf.

7e.

La limite philosophique

Faut-il défendre l’apprentissage du code malgré tout ?

Position décomplexée : oui, partiellement. Pas pour devenir développeur. Pour comprendre ce que vous faites faire. Dix heures sur les bases (variables, conditions, fonctions, erreurs) suffisent à transformer votre vibe coding de “j’espère que ça marche” en “je sais pourquoi ça marche”.

Refuser ces 10 heures par paresse, c’est se condamner à long terme à dépendre des autres pour debug, pour évoluer, pour scaler.

7f.

🎯 Ce qu’il faut retenir

Cinq limites de fond, aucune n’est rédhibitoire, toutes méritent d’être conscientisées.

Ce que la plupart des articles vibe coding ne vous diront jamais : les meilleurs vibe-codeurs sont ceux qui connaissent les limites de leur pratique. Pas les évangélistes qui vous vendent du rêve. Les pragmatiques lucides.

C’est le sujet de la section suivante.

8.

Les 5 profils types face au vibe coding
(et lequel vous êtes)

(typologie des attitudes humaines)

Trois ans à accompagner des humains sur l’IA m’ont fait voir temps de fois cinq attitudes récurrentes. Pas des profils métiers — des profils d’attitude. Reconnaissez-vous le vôtre.

Illustration éditoriale : cinq archetypes de personnages face au code et à la technologie (enthousiaste, chercheur, analyste, developpeur, critique)
Profil 1

L’enthousiaste naïf

Symptômes :tweete sur le vibe coding deux semaines après l’avoir découvert. A déjà déployé trois MVP. Aucun ne tourne en production. Promet à sa direction “une refonte du SI en 2 mois”.

Risque :la chute. Quand le premier projet sérieux plante en production, l’enthousiasme se transforme en rejet total.

Antidote : se forcer à livrer unoutil utilisé en vrai par d’autres pendant 3 mois. Le réel calibre tout.
Profil 2

Le sceptique informé

Symptômes :a lu trois papiers de recherche. Cite Veracode sur les vulnérabilités. Pose des questions précises. N’a livré aucun outil.

Force : ses objections sont presque toutes pertinentes. Il évite les pièges grossiers.

Risque : la paralysie analytique. Six mois à réfléchir, zéro app livrée, pendant que des collègues moins informés livrent.

Antidote : s’imposer une expérimentation contrainte. 48 heures, un outil moche qui marche, sur un irritant réel.L’expérience tranche ce que l’analyse n’arrive pas à trancher.
Profil 3 (Idéal)

Le pragmatique méthodique

Symptômes :lit, teste, mesure, ajuste. Ne s’emballe pas, ne se braque pas. A livré son premier outil en 4 semaines. Le deuxième en 2. Le troisième en 1.

Statistiquement, c’est lui qui livre les outils qui durent et qui scale.

Pourquoi il gagne : il accepte deux vérités contradictoires en même temps. “C’est puissant et ça change tout” + “Ça a des limites réelles qu’il faut respecter.” La majorité du discours ambiant en choisit une seule.

Comment le devenir :alterner volontairement périodes d’enthousiasme (essayer, expérimenter, oser) et périodes de scepticisme (auditer, tester, casser).
Profil 4

Le perfectionniste académique

Symptômes :veut “comprendre comment ça marche en profondeur” avant de commencer. Lit Python pour débutants. Regarde une série de cours sur les Transformers. Six mois plus tard : zéro projet.

Le pilier central en parle déjà ici— pas un hasard, c’est le profil le plus douloureux à voir.

Le piège : confondre maîtrise théorique et capacité à livrer. En vibe coding, la pratique précède toujours la théorie. On comprend mieux la mécanique d’un LLM après avoir cassé 5 apps qu’après avoir lu 5 livres.

Antidote : la règle du minimum viable laid. Livrer un truc moche en 48h, point. La compréhension fine viendra après, jamais avant.
Profil 5

Le résistant culturel

Symptômes :“C’est de la triche”, “Ça ne durera pas”, “Les vrais développeurs vont garder la main”.

Parfois c’est de l’idéologie. Parfois c’est de la légitime peur de la dévaluation de compétences durement acquises. Parfois c’est de la simple lucidité sur les risques.

Risque : rater une vague structurelle par fierté.

Une vérité dérangeante : le résistant a souvent raison sur le diagnostic (les risques sont réels) et tort sur la conclusion(il faut s’en saisir, pas s’en abstenir).

Antidote : dissocier l’analyse de la posture. “Oui, il y a des risques. Donc je m’y mets méthodiquement, pas en m’en abstenant.”
8a.

🎯 Ce qu’il faut retenir

Cinq profils. Vous êtes probablement un mix, dominé par un.

Le bon mouvement ?Migrer vers le pragmatique méthodique, quel que soit votre point de départ. C’est statistiquement le seul qui livre des outils qui durent et qui en tire un avantage stratégique réel.

Maintenant qu’on a posé les profils d’attitude, on va aborder la boîte à outils concrète et opérationnelle pour débuter sereinement en 2026.

9.

Foire aux questions
conceptuelles

(les questions de fond)

Pas les questions opérationnelles (“quel outil choisir”) — celles-là sont dans le pilier central. Ici, les questions de fond que les lecteurs honnêtes finissent par se poser.

Illustration éditoriale : des panneaux conceptuels avec engrenages et points d'interrogation illustrant une FAQ technique

Le vibe coding est-il vraiment du “coding” ?

Techniquement, oui : du code source est produit, exécuté, déployé. Conceptuellement, c’est discutable. Vous ne codez pas — vous spécifiez. Karpathy lui-même reconnaissait que “ce n’est pas vraiment de la programmation”. Le débat sémantique n’a pas grand intérêt. Ce qui compte, c’est que le résultat est du logiciel fonctionnel, indistinguable de celui qu’un humain aurait écrit.

Faut-il quand même apprendre les bases du code si on fait du vibe coding ?

Oui, environ 10 heures sur les fondamentaux : variables, conditions, fonctions, lecture d’erreurs, Git. Pas pour coder à la main — pour comprendre ce que vous faites faire. Refuser ces 10 heures, c’est dépendre des autres pour le moindre bug. Investir ces 10 heures, c’est gagner trois ans d’autonomie.

Le vibe coding produit-il un savoir transférable ou jetable ?

Les deux. Vos prompts et votre méthode sont transférables — ils s’améliorent projet après projet. La connaissance fine du code généré est jetable — chaque génération est unique. Concentrez votre apprentissage sur ce qui se transfère.

Quelle est la différence entre “vibe coding” et “prompt-to-code” ?

“Prompt-to-code” décrit un mécanisme (entrée naturelle, sortie code). “Vibe coding” décrit une pratique culturelle: la posture d’accepter, d’itérer, de ne pas tout maîtriser. Tout vibe coding est du prompt-to-code. L’inverse n’est pas vrai.

Le vibe coding est-il une mode ou un changement durable ?

Le terme est probablement une mode. Karpathy lui-même est passé à “agentic engineering”. La pratique sous-jacente, elle, est durable : piloter une IA en langage naturel pour produire du logiciel ne va pas disparaître. Gartner prévoit 40% des apps d’entreprise créées comme ça d’ici 2028.

Karpathy regrette-t-il d’avoir inventé ce terme ?

Pas de regret public, mais il a explicitement pris ses distances. Sa formulation originale décrivait un mode “weekend project” sans rigueur. La pratique 2026 a peu à voir avec sa définition initiale. Le terme lui a échappé, comme souvent les bons concepts.

Le terme “vibe coding” survivra-t-il à 2027 ?

Probablement pas dans les milieux pro. Trop connoté “amateur”. Sera remplacé par “agentic engineering”, “AI-assisted development” ou un autre. La pratiquerestera, sous un autre nom. Comme “surfer sur le web” a disparu sans que le web disparaisse.

Peut-on parler d’un “métier” du vibe coding ?

Pas un métier en soi. Une compétence transverseintégrée à de multiples métiers — comme Excel l’a été. Dans 7 ans, “vibe coder un outil interne” sera une compétence attendue de tout cadre, pas un poste dédié.

9a.

🎯 Ce qu’il faut retenir

Le vibe coding est un mot temporaire pour une pratique durable. Ne vous accrochez pas au mot — accrochez-vous à la compétence qu’il recouvre. Elle, elle restera.

On arrive au bout. Une conclusion vous attend pour boucler la boucle proprement.

On y est. La conclusion pour refermer ce grand dossier sur les fondamentaux.

10.

On a fait le tour.
Récapitulons proprement.

Vous avez traversé environ 4 500 mots sur ce qui se passe sous le capot du vibe coding. C’est beaucoup. Si vous avez tenu jusqu’ici, vous faites partie d’une minorité statistique très utile : ceux qui veulent comprendre avant d’agir, dans un monde qui valorise l’inverse.

Voici les trois idées-force à emporter :

🎯 Idée n°1 — L’IA ne comprend pas, elle prédit

Tout part de là. Un LLM est une machine à prédire le token suivant, entraînée sur un océan de code existant. Pas un cerveau. Pas un collègue. Pas un assistant intelligent.

Conséquence pratique :la qualité de ses sorties dépend directement de la qualité statistique de vos entrées. Prompt vague = code vague. Prompt précis comme une spec d’ingénieur = code précis. Cette mécanique ne change pas avec la taille du modèle. Elle se précise.

🎯 Idée n°2 — La compétence cœur s’est déplacée

Pendant 60 ans, créer du logiciel = maîtriser une syntaxe. En 2026, créer du logiciel = savoir formaliser une intention métier. La syntaxe est gérée. Ce qui devient critique, c’est votre capacité à structurer, décomposer, anticiper les cas tordus.

Conséquence pratique :vos 15 ans d’expertise métier ne sont pas un handicap face aux développeurs. Ils sont votre vrai avantage compétitif. La juriste bat le stagiaire Python sur l’extraction de clauses contractuelles. Pas parce qu’elle est plus tech — parce qu’elle a 800 mots de prompt système que le stagiaire ne pouvait pas écrire.

🎯 Idée n°3 — La rigueur ne disparaît pas, elle se déplace

Avant : la rigueur était dans la syntaxe. Aujourd’hui : la rigueur est dans le prompt, les tests, la sécurité, la gouvernance. Le vibe coding “vibe” ne tient pas en production. L’agentic engineering rigoureux, lui, tient des années.

Conséquence pratique : les meilleurs vibe-codeurs ne sont pas les plus créatifs. Ce sont les plus méthodiques. Ceux qui acceptent les limites conceptuelles (épistémologique, abstraction, dépendance) et qui les gèrent activement. Pas ceux qui les ignorent.

Ce que vous avez maintenant et que vous n’aviez pas avant

Un modèle mental complet du vibe coding. Pas une recette. Pas une liste de tips. Le moteur sous le capot.

Vous savez ce qu’est un token, un contexte, un agent, un MCP server. Vous savez pourquoi le code se prête mieux à la prédiction IA que le langage humain. Vous connaissez les 4 paradigmes de création logicielle et savez choisir le bon pour votre contexte. Vous reconnaissez les 5 profils types — et le vôtre. Vous voyez les limites conceptuelles que les articles vendeurs oublient.

À partir de maintenant, plus personne ne pourra vous bullshiter sur ce sujet. Et c’est exactement le bouclier qu’il vous fallait pour les 18 prochains mois.

Illustration éditoriale : un train à grande vitesse futuriste fait de lumière et de code projeté vers l'avant

Et maintenant ?

Trois directions possibles selon votre état d’esprit :

Pratique immédiate

Passer à l’action

Prêt à livrer ? Suivez notre méthodologie concrète et notre cas pratique de 3h47.

Le guide pratique →
Équipement

Choisir ses outils

Lovable vs Cursor vs Claude Code vs Bolt vs v0 : notre comparatif exhaustif et sans pub.

Comparatif outils →
Approfondissement

Sujets précis

Découvrez nos dossiers : le protocole MCP, l’histoire de Karpathy, ou faites le test de profil.

Les articles satellites →

Le mot final

Le vibe coding ne va pas créer de nouveaux constructeurs. Il va simplement enlever le gravier dans les chaussures de ceux qui voulaient construire depuis toujours mais ne pouvaient pas.

  • • Vous saviez briefer un stagiaire ? Vous saurez briefer une IA.
  • • Vous saviez rédiger une procédure ? Vous saurez rédiger un prompt.
  • • Vous saviez décomposer un problème métier ? Vous saurez construire un outil.

Ce n’est pas une révolution technologique. C’est une redistribution du pouvoir de créer. Et cette redistribution n’attend ni votre permission, ni celle de votre DSI, ni celle du marché.

Elle se passe. Maintenant. Avec ou sans vous.

À vous de choisir si vous la regardez passer, ou si vous montez dans le train tant qu’il accélère.

Pas de pression.

(Si.)

Ne ratez pas la suite

Recevez les prochains chapitres
avant tout le monde.

Un email par semaine. Pas de spam. Pas de bullshit. Désinscription en un clic.

S’inscrire à la lettre →