Vibe coding : le mirage à 31 milliards et la revanche du bas-niveau

Ce que vous allez lire — et pourquoi ça vaut le détour

Il y a quelques semaines, je demandais encore à Claude si Rust était vraiment aussi bas-niveau que le C. Une question naïve en apparence. Mais à force de creuser le sujet avec l’IA elle-même, j’ai compris que la vraie question n’avait rien de technique. Elle était presque philosophique : si apprendre la syntaxe d’un langage ne coûte plus rien, pourquoi continue-t-on à tolérer des abstractions qui gaspillent de l’énergie et des cycles CPU ? Pourquoi ne pas tout coder en C, en Rust unsafe, voire en assembleur, maintenant que l’IA peut générer n’importe quel niveau de bas-niveau à notre place ?

C’est la promesse implicite du vibe coding. Et c’est aussi le piège dans lequel on est en train de tomber — collectivement, les yeux grands ouverts. Il y a trois jours, un simple billet de blog sur la modernisation du COBOL par IA a fait perdre 31 milliards de dollars à IBM en une séance. L’histoire ne fait que commencer.

Le vibe coding : d’un tweet viral à la nouvelle norme

Le 2 février 2025, Andrej Karpathy — cofondateur d’OpenAI, ex-responsable IA chez Tesla — publie un post sur X qui va être vu plus de 4,5 millions de fois. Il y décrit une nouvelle façon de coder où l’on « oublie que le code existe ». On décrit ce qu’on veut en langage naturel, l’IA génère, on accepte les suggestions sans forcément lire les diffs, on colle les messages d’erreur dans le prompt, et ça marche — plus ou moins. Karpathy lui-même reconnaissait que c’était surtout adapté aux « projets jetables du week-end ».

Le terme a frappé les esprits. En quelques mois, il a fait la une du New York Times, d’Ars Technica, du Guardian, a été élu mot de l’année 2025 par le dictionnaire Collins, et s’est ancré dans le vocabulaire quotidien de millions de développeurs. Y Combinator rapportait dès mars 2025 que 25 % des startups de sa promotion d’hiver avaient des bases de code générées à 95 % par IA.

Un an plus tard, en février 2026, Karpathy lui-même fait évoluer le concept. Il propose de remplacer le terme par « agentic engineering » — ingénierie agentique — pour souligner qu’il ne s’agit plus de vibrer dans le vide, mais d’orchestrer des agents IA avec rigueur et supervision. Le vibe coding pur, celui où on ferme les yeux et on fait confiance, c’était fun. L’ingénierie agentique, c’est la version adulte.

Mais dans la pratique, en février 2026, la réalité est plus nuancée. Cursor, Windsurf, Claude Code, Replit Agent, les workflows à la Devin : les outils sont partout, et une part croissante du code neuf est générée ou co-générée par IA. La question n’est plus de savoir si l’IA code — c’est un fait. La question est : qu’est-ce qu’elle code, et à quel prix ?

Le paradoxe énergétique : quand Python coûte 20 fois trop cher en watts

Pour comprendre le paradoxe, il faut des chiffres. Et on en a de solides.

Une étude menée par une équipe de six chercheurs de trois universités portugaises, publiée sous le titre Energy Efficiency Across Programming Languages, a comparé 27 langages sur 10 problèmes algorithmiques standardisés, en mesurant la consommation électrique, la vitesse d’exécution et l’empreinte mémoire de chacun. Les résultats sont éloquents.

En moyenne, les langages compilés (C, C++, Rust, Ada) consomment environ 120 joules pour exécuter les solutions de test. Les langages sur machine virtuelle (Java, C#) : 576 joules. Les langages interprétés (Python, Ruby, Perl) : 2 365 joules. C’est un facteur de l’ordre de 20× entre Python et C, rien que sur de l’algorithmique de base.

Le top 5 de l’efficacité énergétique ? C, Rust, C++, Ada, Java. En bas du classement : Lua, Python, Perl, Ruby, TypeScript. Et les chercheurs ont démontré un résultat contre-intuitif : la vitesse d’exécution et la consommation d’énergie ne sont pas toujours corrélées. Dans l’un des benchmarks, un programme Chapel s’exécutait 55 % plus vite que son équivalent Pascal, mais le programme Pascal consommait 10 % d’énergie en moins. L’efficacité énergétique est un problème à part entière, pas un simple sous-produit de la performance.

Un papier plus récent d’octobre 2024, publié à l’IEEE, a cependant nuancé ces résultats en montrant que la relation causale entre choix de langage et consommation d’énergie est plus complexe qu’on ne le pensait : l’implémentation spécifique, le nombre de cœurs actifs et l’activité mémoire jouent un rôle considérable. Le langage compte, mais il n’est pas le seul facteur.

Il n’empêche : l’ordre de grandeur reste spectaculaire. Et il se heurte de plein fouet à une autre réalité.

Les data centers en surchauffe : la contrainte qui change tout

La consommation électrique des data centers est en train de devenir un sujet géopolitique.

Selon le rapport Energy and AI publié par l’Agence Internationale de l’Énergie (AIE) en 2025, les data centers consommaient environ 415 TWh en 2024, soit 1,5 % de la consommation électrique mondiale. Aux États-Unis seuls, c’est 183 TWh — plus de 4 % de la consommation nationale, l’équivalent de la demande annuelle du Pakistan.

La projection de l’AIE : cette consommation doublera d’ici 2030, pour atteindre 945 TWh — l’équivalent de la consommation actuelle du Japon. L’IA en est le moteur principal : elle représentait 5 à 15 % de la consommation des data centers ces dernières années, et pourrait atteindre 35 à 50 % d’ici 2030.

Les conséquences se font déjà sentir. En Virginie, épicentre des data centers américains, 26 % de l’électricité est déjà absorbée par ces installations. Dominion Energy a proposé en 2025 sa première augmentation de tarif de base depuis 1992 — en partie à cause de la demande des data centers. En Irlande, les data centers représentent 21 % de la consommation nationale, un chiffre qui pourrait atteindre 32 % dès 2026. Une étude de Carnegie Mellon estime que les data centers et le minage de cryptomonnaies pourraient entraîner une hausse de 8 % de la facture d’électricité moyenne américaine d’ici 2030, et jusqu’à 25 % dans les marchés les plus sollicités.

Dans ce contexte, chaque watt compte — et chaque euro aussi. Le passage au bas-niveau n’est plus seulement une question d’éthique énergétique : c’est une question de survie financière. Avec l’explosion des tarifs d’électricité et la répercussion directe sur le coût du compute cloud, une instance AWS qui fait tourner du Python peut coûter quatre à cinq fois plus cher qu’une instance Rust à performance équivalente. La discipline FinOps — l’optimisation financière de l’infrastructure cloud — est en train de devenir le levier le plus concret pour forcer le choix du langage. On ne parle plus d’idéalisme green coding, on parle de facture mensuelle.

Et la question prend une dimension nouvelle : si l’on sait que C et Rust consomment 20× moins qu’un Python, et que la barrière d’apprentissage de ces langages est en train de tomber grâce à l’IA, pourquoi ne bascule-t-on pas massivement vers le bas-niveau pour économiser des térawattheures ?

C’est la thèse séduisante. Voici pourquoi elle ne tient pas — ou pas complètement.

Antirez et le vrai visage du vibe coding bas-niveau

Pour comprendre ce qui bloque, il n’y a pas de meilleur guide que Salvatore Sanfilippo, alias antirez. Créateur de Redis, l’une des bases de données les plus utilisées au monde, codeur C depuis des décennies, puriste revendiqué du minimalisme logiciel. Pas exactement le profil d’un enthousiaste IA naïf.

Et pourtant. En janvier 2026, dans un billet intitulé « Don’t fall into the anti-AI hype » qui a été vu près de 500 000 fois, antirez a posé un constat brutal : le code écrit à la main, c’est fini pour l’essentiel. Selon ses mots, il ne serait plus « raisonnable » d’écrire soi-même le code pour la plupart des projets, sauf par plaisir.

Pour étayer son propos, il raconte quatre tâches qu’il a accomplies en quelques heures au lieu de semaines :

Il a fait modifier sa bibliothèque linenoise pour supporter l’UTF-8, avec un framework de test complet basé sur un terminal émulé — un chantier qu’il avait repoussé depuis des années faute de temps. Il a fait corriger par Claude Code des échecs transitoires dans les tests de Redis, des problèmes de timing et de deadlock TCP, un travail particulièrement ingrat. Il a fait générer en cinq minutes une bibliothèque C complète d’inférence pour des modèles d’embedding BERT-like : 700 lignes, même sortie que PyTorch, seulement 15 % plus lente. Et il a fait reproduire en vingt minutes un travail de refactoring interne de Redis Streams à partir de son document de design.

Mais — et c’est là que ça devient intéressant — antirez ne fait pas du vibe coding. Il fait de l’ingénierie assistée par IA. La différence est cruciale. Il guide, il inspecte, il corrige les comportements indéfinis subtils, il comprend chaque ligne. Il décrit les LLMs comme de « bons amplificateurs, mais de mauvais travailleurs autonomes ». Sans supervision humaine sérieuse, le code généré devient sur-complexe, fragile, et truffé de bugs silencieux.

Autrement dit : antirez obtient un facteur ×20 en productivité sur du C parce qu’il a trente ans d’expertise pour cadrer l’IA. C’est un résultat spectaculaire. Mais il est non-transférable à quiconque ne comprend pas ce que sont un undefined behavior, un buffer overflow ou une calling convention. L’IA est une commodité — c’est le savoir-faire humain qui fait la différence.

Et c’est précisément là que le rêve du vibe coding bas-niveau se fracasse.

Pourquoi l’IA ne nous ramènera pas à l’assembleur

Le raisonnement « l’IA supprime la barrière d’apprentissage, donc on peut aller plus bas-niveau » oublie un fait fondamental : la difficulté du bas-niveau n’est pas dans la syntaxe, elle est dans la sémantique.

Écrire mov rax, rbx n’a jamais été le problème. Le problème, c’est de savoir que cette instruction va écraser une valeur dont une autre partie du programme dépend trois cents lignes plus loin. C’est de comprendre que votre optimisation SIMD fonctionne sur un processeur mais pas sur un autre à cause d’un alignement mémoire différent. C’est de débugger un segfault qui ne se manifeste que sous charge, en production, le vendredi soir.

L’IA peut générer du code assembleur syntaxiquement correct. Mais même les meilleurs modèles de 2026 hallucinent sur les offsets relatifs, les conventions d’appel spécifiques à une architecture, les dépendances de pipeline entre instructions. Sur du C, les erreurs sont plus subtiles encore : un comportement indéfini peut passer tous les tests unitaires et exploser en production. Le compilateur a le droit de faire littéralement n’importe quoi quand il rencontre un UB — y compris supprimer votre vérification de sécurité.

C’est pour ça que Rust safe est devenu le sweet spot de l’IA en 2026. Le borrow checker — le système de vérification de propriété de Rust — force une structure cohérente à la compilation. Quand l’IA génère du Rust safe, le compilateur rejette les erreurs de mémoire avant l’exécution. C’est une forme de garde-fou structurel que C et l’assembleur n’ont tout simplement pas. L’IA fait moins d’erreurs en Rust non pas parce qu’elle « comprend » mieux le langage, mais parce que le langage ne la laisse pas se tromper silencieusement.

Voilà pourquoi la hiérarchie réelle en 2026 ressemble à ceci :

Le paradoxe se résout ainsi : plus on descend vers le métal, plus le gain énergétique est élevé, mais plus la supervision humaine nécessaire est pointue, rare et coûteuse. L’IA ne supprime pas le besoin d’expertise — elle amplifie la productivité de ceux qui l’ont déjà.

La dette cognitive : le vrai coût caché du vibe coding

Concentrons-nous maintenant sur ce qui est peut-être le danger le plus insidieux du moment : non pas le manque de performance, mais l’accumulation silencieuse de code que personne ne comprend.

Les chiffres commencent à tomber, et ils sont préoccupants.

Le rapport State of AI vs. Human Code Generation de CodeRabbit, publié fin 2025, a analysé 470 pull requests open source sur GitHub. Résultat : le code généré par IA introduit 1,7× plus de problèmes que le code écrit par des humains. Détail par catégorie : 1,75× plus d’erreurs de logique, 1,64× plus de problèmes de maintenabilité, 1,57× plus de failles de sécurité, 1,42× plus de problèmes de performance. L’unique domaine où l’IA fait mieux que les humains ? L’orthographe dans les commentaires.

Le rapport DORA 2025 de Google, relayé par SonarSource, confirme cette tendance à grande échelle : une adoption accrue de l’IA de 90 % est associée à une hausse de 9 % du taux de bugs, une augmentation de 91 % du temps de revue de code, et des pull requests 154 % plus volumineuses.

L’étude de Carnegie Mellon publiée fin 2025, qui a suivi 807 dépôts GitHub ayant adopté Cursor entre janvier 2024 et mars 2025, est peut-être la plus révélatrice. Malgré l’amélioration continue des modèles au cours de cette période — Sonnet 4.0, Opus 4.1 — les indicateurs de qualité ne se sont pas améliorés. Le code est produit plus vite, mais il n’est pas meilleur. Et le risque va au-delà du constat immédiat : si le code public sur lequel les futurs modèles s’entraînent est lui-même de qualité dégradée par la génération IA, on entre dans ce qu’on pourrait appeler une consanguinité des LLMs — une boucle de rétroaction où chaque génération de modèle hérite des défauts de la précédente et les amplifie. Un effondrement progressif de la logique logicielle globale, silencieux et cumulatif.

Les mainteneurs de projets open source majeurs tirent la sonnette d’alarme. Des équipes comme celles de Blender et VLC signalent une explosion du volume de pull requests — une hausse de l’ordre de 40 % en un an — mais un taux de merge en baisse. Les contributions compilent, mais elles ne s’intègrent pas dans l’architecture existante. Elles importent des bibliothèques inutiles, dupliquent des fonctionnalités existantes, introduisent des dépendances non nécessaires. Le temps de revue explose, et les mainteneurs passent plus de temps à expliquer pourquoi le code ne convient pas qu’à écrire des fonctionnalités.

GitClear a documenté une multiplication par 8 de la fréquence des blocs de code contenant cinq lignes dupliquées ou plus entre 2020 et 2024. Pour la première fois en 2024, le nombre de lignes copiées-collées a dépassé le nombre de lignes refactorisées. Le code pousse plus vite qu’il ne mûrit.

C’est ça, la dette cognitive du vibe coding. Pas un problème de performance brute, mais un problème de compréhension. Du code qui tourne, mais que personne ne peut expliquer. Des systèmes qui grossissent, mais que personne ne peut simplifier. Une base de code mondiale qui gonfle, mais dont la lisibilité et la maintenabilité se dégradent.

Le cas COBOL : quand un billet de blog fait perdre 31 milliards à IBM

Au moment où j’écris ces lignes, l’illustration la plus spectaculaire de tout ce que cet article décrit vient de se produire — en temps réel.

Le 23 février 2026, Anthropic publie un billet de blog expliquant comment Claude Code peut aider à moderniser les bases de code COBOL. Le principe : l’IA cartographie les dépendances à travers des milliers de lignes de code, documente les flux de travail, trace les chemins d’exécution, identifie les risques — tout ce travail d’exploration et d’analyse qui rendait la modernisation du COBOL prohibitivement coûteuse depuis des décennies. Selon Anthropic, des chantiers qui prenaient des années pourraient être ramenés à quelques mois.

La réaction de Wall Street est immédiate et brutale. L’action IBM plonge de 13 % en une seule séance — sa pire journée depuis octobre 2000. Plus de 31 milliards de dollars de capitalisation boursière évaporés. Accenture et Cognizant, qui bâtissent une part significative de leur chiffre d’affaires sur la modernisation de systèmes legacy, perdent eux aussi 6 à 7 %. Bloomberg rapporte que les actions IBM reculent de 27 % sur le mois de février, leur pire mois depuis 1968.

Pourquoi une telle panique ? Parce que COBOL est l’incarnation absolue de la dette cognitive à l’échelle planétaire. Ce langage, né à la fin des années 1950, fait tourner 95 % des transactions des distributeurs automatiques aux États-Unis. Des centaines de milliards de lignes de COBOL s’exécutent chaque jour dans la finance, l’aviation, l’administration publique, les assurances. Et le nombre de développeurs qui comprennent ce code diminue chaque année — sans que la relève soit formée en nombre suffisant.

IBM avait bâti un empire de services et de conseil autour de cette dépendance : si personne d’autre ne comprend le code, tout le monde paie IBM pour le maintenir. L’idée qu’une IA puisse soudain « lire » et cartographier ce code menace directement ce modèle économique.

Sauf que les experts s’accordent à dire que la panique est largement excessive. Le magazine Programmez! rappelle qu’IBM proposait déjà son propre outil IA de modernisation COBOL (watsonx Code Assistant for Z) depuis 2023. The Register qualifie le billet d’Anthropic de contribution à une « longue tradition de COBOL FUD ». Slashdot résume : réécrire du code critique qui gère des milliards de transactions par un LLM entraîné sur du code médiocre… qu’est-ce qui pourrait mal tourner ?

Ce cas COBOL cristallise tout le paradoxe de cet article. L’IA peut aider à comprendre du code legacy que plus personne ne maîtrise — c’est un gain réel. Mais comprendre n’est pas moderniser. Cartographier n’est pas réécrire. Et viber du COBOL bancaire sans experts humains, c’est la même erreur que viber de l’assembleur sans comprendre les conventions d’appel.

Antirez le dit pour le C, les mainteneurs de Blender et VLC le disent pour l’open source, et le cas COBOL le hurle pour les systèmes critiques : l’IA est un amplificateur extraordinaire de la compétence humaine, et un multiplicateur tout aussi extraordinaire de l’incompétence.

Le scénario réaliste : une polarisation, pas une révolution

Alors, que va-t-il se passer ?

Pas de retour massif à l’assembleur. Pas de disparition de Python. Mais une polarisation croissante entre deux mondes qui coexistent déjà :

Le monde du prototype et du jetable. Python, JavaScript, TypeScript. Vibe coding au sens premier : on décrit, l’IA génère, on teste vaguement, on déploie. C’est le monde des MVPs, des side-projects, des démos, des outils internes que personne ne maintiendra plus de six mois. Le vibe coding y crée une catégorie nouvelle : le code biodégradable. On ne cherche plus à le maintenir, on le jette et on le régénère à chaque changement de besoin. C’est l’antithèse absolue du COBOL — et c’est assumé. Dans ce monde, l’inefficacité énergétique est un non-sujet : le code ne vit pas assez longtemps et ne tourne pas à assez grande échelle pour que ça compte.

Le monde de l’infrastructure qui dure. Rust safe en première ligne, C pour les cas spécifiques sous supervision humaine forte, Go pour la concurrence. C’est le monde des backends qui gèrent des millions de requêtes, de l’inférence IA en production, des nœuds blockchain, de l’embarqué critique, des systèmes d’exploitation. Dans ce monde, chaque watt compte, et la pression énergétique va pousser inexorablement vers des langages plus efficaces. L’IA y est un amplificateur — comme antirez le démontre — mais pas un remplaçant.

La nouveauté de 2026, c’est que la frontière entre ces deux mondes se durcit. Avant l’IA, un prototype Python pouvait être progressivement optimisé, refactorisé, amélioré au fil du temps. Avec le vibe coding, les prototypes sont générés si vite et avec si peu de compréhension humaine qu’ils sont souvent irrécupérables. La réécriture complète dans un langage performant devient plus économique que l’optimisation incrémentale. C’est un changement de paradigme discret mais profond.

Ce qui va vraiment changer la donne

Si la vraie économie d’énergie ne viendra pas du vibe coding en assembleur, d’où viendra-t-elle ?

De meilleurs algorithmes, pas de micro-optimisations manuelles. Remplacer un O(n²) par un O(n log n) par une simple modification de structure de données aura toujours plus d’impact sur la facture énergétique que de réécrire un mauvais algorithme en assembleur. C’est un gain de plusieurs ordres de grandeur qui éclipse le choix du langage. Et c’est précisément le genre de transformation où l’IA peut aider : identifier des goulots d’étranglement algorithmiques dans des bases de code existantes, proposer des structures de données plus adaptées, repérer des calculs redondants. Antirez l’a montré avec Redis Streams : le gain ne vient pas d’avoir écrit du C plus vite, il vient d’avoir pu explorer et implémenter un meilleur design plus rapidement. Mais il faut être lucide sur ce que l’IA sait faire ici : elle excelle à optimiser localement — transformer une boucle for en opération vectorisée, dérouler une récursion, paralléliser un calcul. Repenser globalement une architecture de données pour changer de classe de complexité exige encore une directive humaine très précise. L’IA est votre ouvrier pour la réécriture ; vous restez l’architecte de la complexité.

Du matériel spécialisé. Les puces d’inférence IA (TPU, NPU, les accélérateurs ASIC) réduisent la consommation par opération de manière bien plus drastique que n’importe quel choix de langage. L’architecture matérielle est le levier le plus puissant — et le moins médiatisé — de l’efficacité énergétique.

De la rigueur dans les choix d’infrastructure. Dimensionner correctement ses instances cloud, éviter le sur-provisionnement, choisir Rust plutôt que Python pour un service qui tourne 24/7 sur mille nœuds : ce sont des décisions d’architecture, pas de syntaxe. Et ce sont elles qui déterminent l’essentiel de la facture énergétique.

Ce qu’on peut faire concrètement, dès maintenant

Si vous avez lu jusqu’ici, tout l’article tient en trois piliers :

1. La sémantique sur la syntaxe — comprendre le quoi plutôt que le comment.
2. Le bas-niveau assisté — utiliser Rust comme garde-fou contre les hallucinations.
3. La sobriété comme métrique — le watt comme nouveau KPI, au même titre que la vélocité.

En pratique, ça se traduit comment ?

Arrêtez de demander à l’IA de minimiser les lignes de code. Demandez-lui de minimiser les watts. Ce n’est pas la même chose. Un code court peut être inefficace ; un code un peu plus verbeux mais qui utilise les bonnes structures de données et évite les allocations inutiles peut consommer dix fois moins d’énergie. Formulez vos prompts différemment.

Pour les projets qui durent, apprenez Rust. Pas parce que c’est à la mode, mais parce que c’est le seul langage qui combine efficacité énergétique proche du C, sécurité mémoire à la compilation, et excellente compatibilité avec les outils IA. Le borrow checker est votre meilleur allié face aux hallucinations de l’IA.

Relisez le code. C’est le conseil le plus banal et le plus crucial. Simon Willison, créateur de Datasette et observateur lucide de l’écosystème IA, a posé la règle d’or : ne commitez jamais du code que vous ne pourriez pas expliquer à quelqu’un d’autre. Si vous ne comprenez pas ce que l’IA a généré, vous ne faites pas de l’ingénierie — vous accumulez de la dette.

Ne confondez pas vibe coding et ingénierie assistée. Le premier est un jouet merveilleux pour le prototypage. Le second est une discipline qui demande plus de rigueur, pas moins, que le développement traditionnel. Antirez code en C avec l’IA depuis janvier 2026 et obtient des résultats spectaculaires — mais il insiste : c’est parce qu’il sait exactement ce qu’il veut et qu’il vérifie tout.

Le mot de la fin

L’IA ne va pas nous ramener à l’assembleur en masse. Elle ne va pas non plus tuer Python — le langage est trop utile comme outil de pensée rapide et comme couche d’orchestration. Ce qu’elle va faire, c’est rendre le choix du langage plus conséquent qu’il ne l’a jamais été.

Quand écrire du Rust au lieu du Python ne prend plus six mois d’apprentissage mais trente minutes de prompt engineering, l’excuse du « c’est trop compliqué » disparaît. Il ne reste que la vraie question : est-ce que ce projet mérite qu’on économise 20× l’énergie qu’il consomme ? Pour un script qui tourne une fois par jour, non. Pour un service qui gère des millions de requêtes en continu, oui — et de plus en plus, les contraintes du monde réel vont imposer cette réponse.

Antirez a résumé l’essentiel dans son billet de janvier : le feu intérieur du développeur, ce n’était pas la syntaxe. C’était construire. L’IA ne menace pas ce feu — elle amplifie sa portée, pour ceux qui savent ce qu’ils veulent bâtir.

L’ère du code gratuit est terminée. Chaque abstraction a un prix en watts, chaque hallucination une facture en production. Ceux qui vibent sans comprendre ne codent pas — ils hypothèquent.