🌊 Le mirage du Vibe-coding - démo, produit ou illusion (il n'y a pas de quatrième option)

le 18 juin 2026

Introduction : l'effondrement de la barrière

Le coût de production d'une ligne de code est devenu quasi nul. Nous sommes entrés dans une ère où les barrières à l'entrée dans le secteur du développement logiciel se sont effondrées. Il ne s'agit pas d'une évolution progressive, mais d'une défaillance structurelle des mécanismes traditionnels de sélection des développeurs. Historiquement, la complexité de la syntaxe et le travail manuel que représentait l'implémentation faisaient office de filtre. Aujourd'hui, ce filtre a disparu.

Le développement logiciel n'est pas devenu simple. La simulation, en revanche, est devenue facile.

Le paysage actuel est marqué par une dangereuse asymétrie : l’IA réduit considérablement le coût de la génération de code, mais elle ne réduit pas – et ne peut pas réduire – le coût de la compréhension des systèmes logiciels complexes au même rythme. Nous assistons à l’industrialisation de la « démo », un phénomène où les artefacts visuels des logiciels sont produits à une vitesse qui dépasse largement l’intégrité architecturale nécessaire à leur maintien.

Cela crée une illusion de « code virtuel ». Pour un œil non averti, une URL fonctionnelle est indiscernable d'un système en production. Pour le marché, un ensemble de fonctionnalités déployé rapidement apparaît comme un avantage concurrentiel. En réalité, nous accumulons des risques systémiques à un rythme exponentiel. Si personne ne comprend votre environnement d'exécution, vous n'avez pas de produit. Vous avez une illusion qui se compile.

Archétype n° 1 — Le codeur d'ambiance : l'architecte de la surface

Le Vibe Coder est le principal bénéficiaire de la disparition des barrières à l'entrée. Cet archétype est souvent non technique ou semi-technique ; il utilise des outils de « programmation intuitive » comme Replit ou Lovable pour créer des logiciels par la seule force de son intention. Pour le Vibe Coder, le logiciel est un exercice esthétique. Si l'interface répond et que l'URL est résolue, le développement est considéré comme « terminé ».

L'esthétique de la mise en œuvre

Vibe Coder privilégie l'esthétique et la rapidité. L'entreprise peut « déployer » une application d'apparence fonctionnelle en quarante-huit heures et la partager en interne pour susciter immédiatement l'enthousiasme des parties prenantes. Cependant, cette rapidité est obtenue au détriment des piliers fondamentaux du génie logiciel : les serveurs, les bases de données persistantes et les protocoles de sécurité.

Le Vibe Coder fonctionne exclusivement dans le cadre d'un fonctionnement optimal. Son code est un assemblage de fragments qui répondent aux exigences immédiates d'une démo, mais ne possèdent aucune logique interne pour gérer l'entropie d'un environnement réel. Dans l'univers du Vibe Coder, une URL fonctionnelle est l'objectif final, sans tenir compte du fait qu'une URL n'est qu'un pointeur vers un noyau potentiellement vide.

Le mirage de l'achèvement

Le danger des développeurs à l'esthétique tape-à-l'œil ne réside pas dans leur manque de compétences, mais dans leur confusion entre apparence et ingénierie. Ils créent des produits « chouchous » – des outils que la communauté adore car ils résolvent un problème superficiel – sans comprendre que « la rentabilité vient après l'engouement », et seulement si le produit fonctionne réellement. Lorsqu'une démonstration d'un développeur à l'esthétique tape-à-l'œil est prise pour un produit, cela crée un précédent dangereux pour l'organisation, laissant croire que le « vrai » travail d'ingénierie peut être négligé.

Archétype n° 2 — Le gestionnaire d'invites : l'orchestrateur du code anonyme

Le Gestionnaire de sprints est souvent un développeur chevronné qui est passé du rôle de programmeur à celui d'orchestrateur d'agents. Il utilise des LLM pour gérer les audits de sécurité, les frameworks de test et la génération de code standard à une vitesse impressionnante. Il livre rapidement. Il respecte les délais. C'est le héros du sprint.

L'érosion de l'intention architecturale

L'échec du gestionnaire de processus est subtil : la perte de la maîtrise de l'architecture. En avançant à une vitesse fulgurante, il sacrifie le temps de réflexion nécessaire pour définir précisément ce qui est construit. L'architecture n'est pas un assemblage de fragments fonctionnels ; c'est une stratégie cohérente de gestion de l'état, des flux et des erreurs.

Lorsque le code est généré par invite plutôt que conçu, l'architecture sous-jacente commence à se dégrader. Le gestionnaire d'invites devient un simple passager dans son propre code, incapable de prendre en compte les interactions subtiles entre les modules générés. Il gère un système dont les invariants internes — les règles à ne jamais enfreindre — lui sont même inconnus.

L'illusion de la productivité

Le responsable de la sécurité confond progrès visible et progrès technique. Il croit, à tort, que la présence d'« agents de sécurité » garantit la sécurité de son système. Les audits de sécurité automatisés constituent un minimum, non une garantie. Sans une compréhension approfondie de l'environnement d'exécution, ce responsable bâtit une organisation superficielle : il gaspille ressources et énergie pour s'imposer, tandis que les fondations techniques se dégradent. Il livre un code qu'il ne peut plus expliquer.

Archétype n° 3 — L'ingénieur système : le gardien de l'exécution

L'ingénieur système est le seul archétype à reconnaître l'illusion pour ce qu'elle est. Il utilise l'IA — et peut-être même plus efficacement que les autres — mais il conserve la maîtrise absolue du cœur du système. Pour l'ingénieur système, le code est la partie la moins importante du logiciel. Les éléments les plus importants sont les invariants, les modes de défaillance et l'observabilité.

Appropriation de la complexité

L'ingénieur système sait que la difficulté de son métier n'a jamais été de faire apparaître quelque chose à l'écran. Le plus difficile est de garantir le bon fonctionnement du système lorsque les données doivent être stockées correctement, lorsque des cas particuliers surviennent et lorsque la maintenance du système s'impose six mois plus tard.

Ils considèrent l'IA comme un stagiaire très performant, et non comme un architecte principal. Chaque ligne de code générée par l'IA est soumise à une validation rigoureuse par rapport aux invariants du système. Ils se concentrent sur le comportement à l'exécution : comment le code se comporte réellement sous charge, dans un environnement distribué ou lors d'une panne réseau partielle.

Le manifeste de l'ingénierie

Pour l'ingénieur système, une invite n'est pas de l'architecture. L'ingénierie est la discipline qui consiste à transformer une illusion générée par l'IA en quelque chose de réel. Ses priorités sont :

• Invariants : Définition des vérités constantes de l'état du système
• Observabilité : Concevoir des systèmes qui expliquent leur propre état interne aux opérateurs
• Modes de défaillance : Anticiper les défaillances du système et concevoir une dégradation progressive
• Évolutivité : Comprendre les limites théoriques des structures de données et des modèles de concurrence choisis

L'ingénieur système est celui qui empêche le produit de sombrer dans le « marasme économique ». Il comprend que si l'IA peut générer le « quoi », l'humain doit toujours définir et justifier le « comment » et le « pourquoi ».

Pourquoi les managers se font avoir : la psychologie de la démo

Le moment le plus dangereux du cycle de vie d'un produit est la première démonstration réussie. Les parties prenantes non techniques voient une interface utilisateur fonctionnelle sur une URL déployée et demandent immédiatement : « Pourquoi ne pouvons-nous pas simplement commercialiser cela ? ».

Le piège de la visibilité

Les gestionnaires et les investisseurs en capital-risque sont naturellement enclins à réagir aux progrès visibles. À leurs yeux, si l'interface utilisateur est achevée à 90 %, le projet l'est aussi à 90 %. Ils ne voient ni le système dorsal inexistant, ni la base de données non chiffrée, ni les problèmes de concurrence dans le modèle de gestion des accès concurrents.

Le mirage du codage Vibe exploite ce biais cognitif. Il présente le « visible » comme le « précieux ». Cette pression pousse les équipes d'ingénierie à « aller plus vite », ce qui ne fait qu'accélérer l'accumulation d'une complexité non maîtrisée.

Le chouchou contre le flambeur

Sur le marché actuel, les dirigeants recherchent le succès immédiat, le produit chouchou de la communauté. Ils utilisent des démos pour lever des fonds, tels des flambeurs, dilapidant leurs liquidités dans la distribution. Mais sans la rigueur d'un ingénieur système, ces entreprises disparaissent en moins de 14 mois. La démo leur a permis d'obtenir le rendez-vous ; l'absence de produit a causé leur perte.

Le coût caché de la complexité : la dette invisible

L'IA amplifie la complexité. En réduisant les obstacles à la production de code, elle encourage la création de systèmes plus vastes et plus complexes que ce qu'un être humain, voire une équipe, peut appréhender pleinement.

Érosion architecturale et dette technique

Lorsque nous utilisons des agents pour « avancer à toute vitesse », nous négligeons souvent la phase de conception. Nous passons sous silence les exigences et les documents de conception dont l'humain et l'IA ont besoin pour bien comprendre l'objectif. Cela conduit à une érosion de l'architecture, où la structure du système devient un assemblage disparate d'optimisations locales incohérentes à l'échelle globale.

Le mur de la concurrence et de la scalabilité

L'IA est notoirement mauvaise pour raisonner sur la concurrence et les modes de défaillance dans les systèmes distribués. Elle peut générer une boucle d'événements, mais elle est incapable de prédire son comportement face à un problème de forte concurrence. Elle peut écrire une requête SQL, mais elle ne comprend pas les implications de cette requête en termes de scalabilité sur un ensemble de données de plusieurs téraoctets.

À mesure que le code source s'étoffe, la charge cognitive liée à la compréhension du système augmente de façon exponentielle. Le goulot d'étranglement se déplace : il ne s'agit plus du nombre de lignes de code que l'on peut écrire, mais de la quantité d'informations du système existant que l'on peut assimiler simultanément.

L'avenir de l'ingénierie : la compréhension comme valeur fondamentale

L'avenir de la valeur du génie logiciel se déplace de la syntaxe vers l'orchestration système de haut niveau et les modèles d'exécution.

Le passage à l'orchestration

Dans un monde où le code est devenu une ressource courante, la valeur de l'ingénieur réside dans sa capacité à gérer les systèmes distribués, les boucles d'événements et les systèmes asynchrones. Le nouveau défi n'est plus d'écrire la fonction, mais de s'assurer que ses effets de bord sont observables et réversibles.

Le mandat d'observabilité

Nous nous dirigeons vers un avenir où nous devrons gérer des logiciels que nous n'avons pas écrits. L'observabilité devient ainsi la discipline d'ingénierie la plus cruciale. Si la lecture du code ne nous permet pas de le comprendre, nous devons l'observer s'exécuter. Cela exige une connaissance approfondie de la télémétrie, du traçage et de l'agrégation des journaux.

Les ingénieurs qui réussiront seront ceux qui sauront définir les invariants et utiliser l'IA pour concevoir les mécanismes qui les garantissent. Ils seront les architectes de systèmes robustes, non pas parce que chaque ligne de code est parfaite, mais parce que l'architecture du système est conçue pour résister à l'imperfection.

Références et bibliographie

Sources primaires

Karpathy, A. (2025, 2 février). Article sur X présentant le « codage par vibrations »

MIT Technology Review. (16 avril 2025). Qu'est-ce que le codage vibratoire, exactement ?

Bencoding. (2026, 20 avril). Démo vs IA opérationnelle : la confusion la plus coûteuse en IA

Uphack. (s.d.). L'illusion du bâtiment

He, Y., et al. (2026). La dette derrière le boom de l'IA : une étude empirique à grande échelle du code généré par l'IA en conditions réelles. arXiv.

Winters, T., Manshreck, T. et Wright, H. (2020). Le génie logiciel chez Google : leçons tirées de la programmation au fil du temps (Chap. 10, Documents de conception). O'Reilly. https://abseil.io/resources/swe-book/html/ch10.html

Forsgren, N., Humble, J., et Kim, G. (2018). Accelerate : la science du logiciel agile et du DevOps. IT Revolution Press.

Stack Overflow. (31 juillet 2025). Les outils de programmation IA aident-ils à lutter contre le syndrome de l'imposteur ou l'aggravent-ils ?

CB Insights. (2025). Pourquoi les startups échouent : principales raisons

Consultation Myriade. (2022). Entreprises : comment résister aux crises grâce à la frugalité ?

Littérature scientifique et technique

Brooks, FP (1975). Le mythe du mois-homme. Addison-Wesley.

Dijkstra, EW (1989). Sur la cruauté de l'enseignement réel de l'informatique. Communications of the ACM, 32(12). https://doi.org/10.1145/76380.76381

Vogels, W. (2008). Eventually consistent. ACM Queue, 6(6). https://doi.org/10.1145/1466443.1466448

DORA. (2023). Rapport sur l'état du DevOps. Google Cloud.

Amdahl, GM (1967). Validité de l'approche monoprocesseur pour l'obtention de capacités de calcul à grande échelle. Actes de la conférence AFIPS. https://doi.org/10.1145/1465482.1465560

Conclusion finale

Le mirage du codage visuel est un chant de sirène pour l'ère moderne. Il promet les avantages de l'ingénierie sans l'effort de compréhension. Mais le logiciel n'est pas un média visuel ; c'est un média structurel.

Il nous faut revenir aux fondamentaux : exécution, observabilité et invariants. Si nous continuons à confondre la démo avec le produit, nous ne bâtissons pas un avenir numérique ; nous construisons un cimetière numérique.

« Si vos agents de codage disparaissaient demain, quelle part de votre code source comprendriez-vous encore vraiment ? »

Diagnostic brutal

• Sécurisé : Vous pouvez expliquer chaque transition d'état de votre système et recréer le modèle mental de l'architecture à partir de zéro lors d'une session de tableau blanc. Dangereux : Vous vous fiez à l'IA pour expliquer le comportement de « votre » code lorsqu'un bug apparaît. Vous ne disposez d'aucun document de conception ni d'invariants enregistrés. Dépendance critique : Vous ne pouvez ni déployer, ni déboguer, ni faire évoluer votre système sans qu’une fenêtre LLM soit ouverte. Vous êtes comme un passager dans un véhicule sans volant.