Le Code a Toujours Évolué Vers l'Anglais. Il Vient d'y Arriver.

11 min read

Chaque dev senior que je croise ces temps-ci (10, 15 ans de boîtes, de migrations, de stacks abandonnées au pire moment, des gens qui ont survécu à l'époque où tout devait être en microservices même pour une app CRUD qui gérait 12 utilisateurs par jour) porte la même chose. « Je n'arrive pas à savoir si je dois encore apprendre à coder ou juste devenir meilleur en prompting. » « J'enseigne à la fac, mais doit-on encore enseigner PHP à des étudiants qui sortiront dans 4 ans... » « Mon boulot ne ressemble plus à ce qu'il était il y a 1 an, je ne sais pas pourquoi. »

Tokenmaxxer ou pro vibe-coder. Lequel choisir ?

TLDR : Les devs les plus expérimentés que je connaisse n'arrivent pas à nommer ce qui les met mal à l'aise dans la direction que prend le développement logiciel. Ce malaise a un nom, et il se manifeste tous les 20 à 30 ans depuis 1957. La question que vous vous posez n'est peut-être pas la bonne.

Ce qui me frappe à chaque fois, ce n'est pas l'inquiétude. C'est la précision du flou. Ces gens debuggent des race conditions en prod, ils voient arriver les cycles de hype de loin. Et pourtant : le même blanc à la fin de la phrase. J'ai reconnu ce blanc. On a déjà vécu ça. Juste pas avec les LLMs.

Deux développeurs à leurs bureaux avec des approches opposées : l'un code frénétiquement avec des livres de programmation, l'autre parle calmement dans un casque avec du code propre affiché.
Ancienne garde vs nouvelle garde : l'un sue sur la syntaxe, l'autre demande juste poliment.

Chaque Conversation. Même Silence.

L'angle enseignement revient dans toutes ces conversations, et c'est celui qui me marque le plus. « Est-ce que j'enseigne encore Python à des étudiants qui sortiront dans 4 ans ? » Ça a une deadline ferme. La personne qui pose la question doit prendre une décision de programme pour septembre. Pas le temps de « voir comment ça évolue ».

À travers les forums, les serveurs Discord, les threads Slack : quelqu'un qui build du SaaS en Next.js, quelqu'un qui dirige une boîte de dev à 3 personnes et se demande s'il faut monter en compétences sur les agents ou creuser les fondamentaux, quelqu'un qui ship des intégrations pour vivre et se demande si ce job existe encore dans 18 mois. Différents pays, différentes stacks, différents contextes.

Pas « Je ne comprends pas ce qui se passe. » Plutôt : « Je sens que quelque chose change mais je n'arrive pas à le nommer. Et j'ai vécu assez de transitions pour savoir que ça compte. »

Cette dernière partie, c'est le révélateur. Ne pas savoir ce qui se passe, c'est inconfortable. Ne pas arriver à nommer quelque chose qu'on ressent clairement, c'est un inconfort d'une tout autre nature. Ça veut généralement dire que le vocabulaire n'a pas encore rattrapé.

J'ai passé 40 minutes mardi dernier à nommer un dossier. Pas un repo. Un dossier. Le problème du naming en informatique est éternel et les LLMs ne l'améliorent pas. Ils génèrent plus de mauvais noms qui sonnent plausibles, plus vite. C'est tout, circulez.

70 Ans, Une Direction

Il y a un truc qu'on n'enseigne pas en informatique parce que ça casse la mystique du « les langages c'est dur » : depuis 1957, chaque génération de langages de programmation a bougé dans la même direction, vers l'anglais, sans exception.

Le code machine était binaire. L'assembleur vous donnait des mnémoniques qu'on pouvait presque lire en plissant les yeux. Puis FORTRAN et COBOL, en 1957 et 1959, sont arrivés avec quelque chose qui n'avait jamais existé : une ligne de code qu'on pouvait lire à voix haute sans explication. « MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY. » C'est du COBOL. Un manager d'entreprise en 1960 pouvait le parser à froid, sans aucun background en programmation.

[INFOGRAPHIC: TITLE "70 Ans Vers l'Anglais" + subtitle "une direction, aucune exception". Metaphor: a long horizontal road with 5 milestone road signs, left-to-right progression from binary to speech bubble. Style: Franco-Belgian ligne claire comic, thick black outlines, flat colors, clean horizon. Palette: cobalt blue #1A4FD8, signal red #E8291C, warm cream #FFF9F0, black #111111, light gray #DDDDDD. Content: 5 signs labeled MACHINE CODE (1950), ASSEMBLY (1952), COBOL/FORTRAN (1957-1959), PYTHON (1991), LLMs (2026). Each sign shows a small developer figure getting progressively more relaxed, last figure standing with mouth open and no keyboard visible. Highlight: LLMs sign in signal red with starburst, figure gesturing without keyboard. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist tech aesthetic, NOT boring timeline with dots.]

Python, quand il est arrivé en 1991, était conçu explicitement pour se lire comme du pseudocode. La lisibilité n'était pas un accident, c'était un objectif de design, énoncé dans la documentation du langage. Et chaque transition a eu la même réaction de la génération qui se faisait déplacer. « Trop d'abstraction. » « Tu perds le contrôle. » « C'est pas de la vraie programmation. » FORTRAN était considéré comme dangereusement haut niveau en 1957. Les gens qui l'écrivaient se faisaient dire que les compilateurs ne pourraient jamais égaler l'assembleur optimisé à la main. Même réaction, sauvegarde différente. Ils avaient tort. Les gens qui ont dit que Python était trop lent et pas du vrai code en 1991 avaient tort aussi.

Ce n'est pas une révolution. C'est la continuation d'un mouvement vieux de 70 ans.

La Question Est Déjà Obsolète

Tout le monde demande s'il faut encore apprendre à coder. La question est déjà obsolète. Ça sonne plus dramatique que ça ne l'est.

Ce qui s'est passé avec chaque couche d'abstraction précédente : la couche du dessous n'a pas disparu. L'assembleur existe encore. COBOL fait tourner plus de transactions bancaires que n'importe quel autre langage sur terre (je pense qu'il y a plus de lignes COBOL en production active aujourd'hui que de lignes Python, même si personne ne veut dire ça dans une conf). La question n'a jamais été « est-ce que l'ancienne couche disparaît ? » C'était toujours « qu'est-ce que la nouvelle couche change sur quand tu utilises quel outil ? »

Pour la première fois dans l'histoire de l'informatique, la nouvelle couche d'abstraction n'est pas un langage légèrement plus lisible que le précédent. C'est un système qui comprend déjà le langage humain et peut l'exécuter directement. L'intermédiaire syntaxique est, pour la première fois, optionnel. Pas disparu. Optionnel.

Ça change ce qu'est la vraie question. Le post viral sur X qui se moquait de « 80% du code écrit par IA en 2025, puis 100%, puis 12%, puis 300% de bugs en 2028 » a fait plus d'1 million de vues parce que le cadrage est absurde et les gens l'ont reconnu immédiatement. Ce n'est pas une question de pourcentage. C'est une question de couche.

Mais il y a une deuxième question dans la question de couche, et c'est celle qui met mal à l'aise : qu'est-ce qui se passe quand vos spécifications deviennent directement exécutables ? Quand la spec n'est pas un document que vous donnez à un développeur qui écrit du code, mais quelque chose que le LLM exécute directement, sans intermédiaire, sans traduction ? Dans un workflow AI-first aujourd'hui, il y a encore un humain qui lit la spec et écrit du code qui traduit l'intention en quelque chose d'exécutable. Le LLM assiste, accélère, génère parfois la plupart du code. Mais l'étape de traduction est encore là. La question qui met les gens mal à l'aise n'est pas « est-ce que cette étape disparaît ? » C'est « pour quelles catégories de problèmes elle disparaît en premier, et à quelle vitesse cette ligne bouge ? » Le mouvement de 70 ans vient d'atteindre sa destination logique pour ces catégories. Pas pour tous les problèmes. Même pas la plupart, encore. Mais la direction n'a pas changé en 7 décennies.

Tokenmaxxing et Vibe Coding Sont des Symptômes, Pas des Stratégies

C'est là que je suis censé vous dire que l'un est juste et l'autre faux. Ce sont tous les deux des symptômes de la même chose.

Le tokenmaxxing, c'est ce que vous faites quand vous croyez que plus de contexte aide toujours. Le vibe coding, c'est ce que vous faites quand vous croyez que le LLM gère tout si vous ne vous mettez pas en travers. Aucun des deux n'est une stratégie. Les deux sont le comportement de quelqu'un qui sent le changement de couche arriver mais n'a pas encore développé le modèle mental pour ça.

Une histoire qui circule dans la communauté : un builder a shippé 540k lignes. Parmi elles, 276k lignes de tests. 33 cron jobs. Le post-mortem a été brutal. Les tests contrôlaient un agent qui n'avait pas besoin d'être contrôlé. Les cron jobs monitoraient un système qui se gérait déjà. Tout ce code était une cage. L'instinct était juste (contrôler ce qui compte), le modèle était faux (le code est encore comment on obtient le contrôle dans le nouveau paradigme). YOU DIED. La prochaine fois peut-être construire la prison après avoir confirmé que le prisonnier en a besoin.

Même impulsion, direction opposée : quelqu'un build 2 pipelines parallèles pour la même tâche. L'un est impressionnant, avec des boucles de feedback et des agents en cascade. L'autre fait 4 fichiers. Ils mettent les deux devant un LLM et demandent lequel étendre. Face au choix entre architecturalement impressionnant et quelque chose qui marchait juste en 4 fichiers, le modèle a choisi la version 4 fichiers à chaque fois.

Les deux patterns sont exactement ce que faisaient les premiers programmeurs COBOL quand ils ont eu accès à un langage haut niveau : ils structuraient leur code comme l'assembleur qu'ils connaissaient avant, parce qu'ils n'avaient pas encore de nouveau modèle mental. L'ancien modèle appliqué à une nouvelle couche produit du gaspillage dans les deux sens, que ce soit 540k lignes de construction de cage ou 1000x de burn de tokens sur une tâche qui avait besoin de 4 fichiers.

Le point de départ pratique pour ne pas tomber dans l'un ou l'autre piège, c'est la méthode Blueprint dans Vibe Coding, For Real, assez structurée pour que vous ne fassiez pas du vibe-coding aveuglément, assez légère pour que vous ne construisiez pas la cage. Et au niveau infrastructure, why CLIs beat MCP layers for AI agents applique la même leçon à l'outillage : moins d'abstraction, plus de prévisibilité.

3 Objections. 3 Parallèles Historiques.

Les 3 objections sérieuses à ce changement de couche méritent de vraies réponses.

Le coût. L'IA agentique consomme jusqu'à 1000x plus de tokens qu'un appel LLM standard. Microsoft, Meta et Amazon ont tous reculé sur le tokenmaxxing interne cette année. 1 builder d'infrastructure a publiquement cité 1,3M$ en tokens en un seul mois. C'est de l'argent réel. Le parallèle : les premières exécutions de compilateur coûtaient cher. IBM facturait au cycle CPU en 1957. La question a toujours été de savoir si le gain de productivité justifiait le coût, et c'était le cas. Les coûts de tokens chutent d'environ 10x tous les 18 mois. Mintlify a coupé la consommation de tokens par 30 en servant du Markdown à leurs agents au lieu de HTML. Cloudflare a coupé de 80%. L'objection du coût est un problème d'outillage avec des solutions déjà en production.

La fiabilité. L'étude ETH Zurich (438 tâches de coding, avril 2026) a trouvé quelque chose de contre-intuitif : les fichiers AGENTS.md générés par LLMs ont réduit le succès des tâches de 3% et augmenté le coût de 20%. AGENTS.md écrit par des humains : +4% sur le succès. L'interprétation compte ici : c'est la preuve que les pratiques pour cette couche ont 2 ans, pas 20, pas que les LLMs ne peuvent fondamentalement pas être fiables. FORTRAN n'était pas fiable en 1957. Il a fallu des années d'échecs de production accumulés avant que les équipes lui fassent confiance dans les chemins critiques. On est à l'équivalent 1959 avec l'IA agentique. Les pratiques se forment maintenant, exactement comme elles l'ont toujours fait.

La sécurité. Réelle, et pas encore résolue. Les buffer overflows ont été découverts dans les années 70 et se trouvent encore dans le code legacy aujourd'hui. L'injection SQL a été décrite formellement en 1998 et reste dans le top 10 OWASP. Les problèmes de sécurité introduits par les nouvelles couches d'abstraction sont des problèmes d'ingénierie qui se résolvent avec le temps, avec des incidents en chemin. La couche LLM a déjà sa propre version. Ce n'est pas un argument contre la couche.

Ce Que Vous Décidez Vraiment

Les 7 devs n'arrivaient pas à nommer leur malaise. Voici ce que c'est : le périmètre de leur job a bougé. Le job n'a pas disparu. Le périmètre a bougé.

Le code ne va pas disparaître. Il devient le langage des couches déterministes, les parties où avoir tort coûte quelque chose de réel. Une validation de paiement, un webhook routé vers le bon handler basé sur un enum fixe, une frontière d'auth, une opération qui doit réussir exactement une fois ou pas du tout — ces problèmes vivent dans le code parce que le code est auditable, testable, déterministe. On ne tokenmaxe pas son chemin à travers une transaction financière.

Le langage naturel prend les couches intentionnelles : générer une description produit à partir d'input utilisateur, décider quel contenu faire remonter pour un segment d'utilisateurs, rédiger une réponse à un ticket support qui a atterri dans un cas limite que votre spec ne couvrait pas. Ces problèmes vivent dans les prompts et specs parce qu'ils concernent l'intention exprimée, où l'itération sur le comportement compte plus que l'exécution exacte. Que la spec devienne directement exécutable, c'est le point là, pas un risque.

La question concrète pour un builder aujourd'hui n'est pas « est-ce que j'écris encore du code ? » C'est « où vit ce problème spécifique ? » La validation de paiement vit dans le code, et le routage d'un webhook vers un enum fixe ou l'application d'une frontière d'auth aussi. Générer des descriptions produit à partir d'input utilisateur vit dans une spec, et ajuster une ligne d'objet d'email à l'historique d'un utilisateur aussi. La ligne bouge à mesure que les LLMs deviennent plus fiables dans les contextes déterministes. Mais le modèle mental pour la tracer est disponible maintenant.

Le prof qui décide son programme pour septembre a une réponse plus claire qu'il ne le pense. Enseigner pourquoi le code existe. Ce qu'est un type, ce qu'est une exception, ce que ça veut dire pour une opération d'être idempotente. Pas PHP spécifiquement, parce que les langages spécifiques comptent moins chaque année. Les étudiants qui comprennent pourquoi le déterminisme a de la valeur sauront vers quoi se tourner et quand, peu importe à quoi ressemble la stack dans 4 ans.

How to stop gambling on prompts and start shipping est un framework pratique si c'est là que vous êtes bloqué côté intentionnel.

Le blanc à la fin de la phrase que ces 7 devs n'arrivaient pas à remplir n'était pas de l'ignorance. C'était de la lucidité, qui arrivait avant le vocabulaire.

Le changement a déjà eu lieu. Maintenant le vocabulaire doit rattraper.

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission — ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité tous les jours pour votre plaisir de lecture.