Les langages de programmation ont été conçus pour que des humains donnent des instructions à des machines.
Leur syntaxe porte la trace de cette histoire. Nous employons des noms de variables lisibles, des mots-clés mémorisables, de l'indentation, des commentaires, des fichiers, des classes et des abstractions taillées pour des modèles mentaux humains. Les erreurs de compilation sont rédigées pour des personnes. La documentation est organisée pour des personnes. Les dépôts de code sont structurés pour que des personnes s'y retrouvent.
Mais les humains cessent rapidement d'être responsables de l'écriture du code lui-même.
Avec Senternet, le studio logiciel où je conçois des produits et expérimente le développement assisté par IA, je crée désormais une grande partie de mes logiciels en dirigeant des agents de codage. Je décris ce que je veux, j'examine le résultat, je teste le comportement et je renvoie l'agent corriger ce qui cloche. L'agent produit toujours du TypeScript, du Python, du SQL et d'autre code source classique, mais cela ressemble de plus en plus à un vestige de l'écosystème existant plutôt qu'à une exigence du travail.
L'agent écrit du code lisible par des humains avant tout parce que nos compilateurs, bibliothèques, systèmes d'exploitation, API, gestionnaires de paquets et infrastructures de déploiement l'attendent.
D'où une question qui ne me lâche pas :
Quel sera le premier langage de programmation conçu d'abord pour des agents plutôt que pour des humains ?
Le code lisible devient un format intermédiaire
Pendant l'essentiel de l'histoire de l'informatique, le code source avait deux publics.
Le premier était l'ordinateur qui allait le compiler ou l'interpréter. Le second était toute personne susceptible de devoir le comprendre, le déboguer, le maintenir ou l'étendre plus tard.
Ce second public a façonné presque toutes les grandes décisions de conception des langages.
Python met l'accent sur la lisibilité. Ruby cherche à paraître naturel et expressif. TypeScript ajoute une structure qui aide de grands groupes à raisonner sur JavaScript. Rust rend explicites la propriété et la sûreté mémoire, afin que les développeurs comprennent et maîtrisent des comportements que d'autres langages masqueraient.
Ce sont des atouts précieux, parce que l'attention humaine a toujours été la ressource rare.
Le codage agentique change cette économie.
Un agent n'a pas besoin d'une syntaxe facile à taper. Il n'a pas besoin de mots-clés faciles à retenir. Il n'a pas besoin d'un langage enseignable en un semestre ou explicable en une étagère de livres. Il ne fatigue pas en parcourant un dépôt gigantesque. Il peut traiter des représentations qui seraient fastidieuses, verbeuses ou incompréhensibles pour une personne.
Il pourrait tirer parti de propriétés très différentes :
- une sémantique sans ambiguïté
- une représentation compacte en tokens
- des dépendances et des effets de bord explicites
- des transformations déterministes
- la vérification formelle
- la parallélisation automatique
- des diagnostics lisibles par la machine
- une traçabilité intégrée
- la compilation incrémentale
- une optimisation propre au matériel
- l'expression directe des contraintes et des tests
Dès lors que les agents deviennent les principaux auteurs du logiciel, la lisibilité humaine cesse d'être la contrainte centrale de conception.
Elle ne devient pas sans valeur. Elle devient une interface générée.
La représentation native de la machine pourrait devenir la source de vérité, tandis que les humains reçoivent la vue la plus utile sur le moment : une explication, un diagramme, une spécification comportementale, un rapport de sécurité, un plan de tests, voire du TypeScript généré.
Le code lisible ne sera peut-être pas plus fondamental que la vue graphique d'un schéma de base de données.
Pourquoi les agents écrivent encore du Python et du TypeScript
Le plus grand obstacle à tout nouveau langage n'est pas sa syntaxe.
C'est l'écosystème.
Un nouveau langage a besoin de compilateurs, de débogueurs, de bibliothèques, de documentation, de gestion de paquets, de prise en charge dans les éditeurs, d'outils de déploiement, d'analyse de sécurité et d'accès aux plateformes existantes. Les développeurs rechignent à adopter un langage qui les oblige à reconstruire tout ce qu'ils possèdent déjà.
Les agents n'éliminent pas ce problème, mais ils peuvent le réduire considérablement.
Historiquement, un nouveau langage devait aussi convaincre des millions de personnes de l'apprendre. Il fallait des formations, des exemples, des livres, une communauté et assez de confiance pour risquer sa carrière et son entreprise sur une technologie inconnue.
Un agent n'a pas besoin de mois de formation. Dès qu'un modèle ou un système de codage sait produire un langage de façon fiable, tous ses utilisateurs y accèdent immédiatement.
Cela lève l'une des plus grandes barrières historiques à l'adoption d'un langage.
Le problème de l'écosystème demeure, ce qui signifie que le premier langage agent-native à réussir ne remplacera sans doute pas Python, JavaScript, Rust et C++ d'un coup. Il les absorbera.
Il pourra compiler via LLVM, viser WebAssembly, appeler des interfaces C existantes, importer les paquets actuels et dialoguer avec les API établies. Il pourra commencer comme une représentation intermédiaire cachée sous un agent de codage, et non comme un langage que les développeurs choisissent sciemment.
La transition pourrait se faire sans que la plupart des gens s'en aperçoivent.
Une partie se produit déjà
Il n'existe pas encore de langage généraliste largement adopté, écrit et consommé avant tout par des agents. Plusieurs projets précoces vont pourtant dans cette direction.
Des chercheurs ont présenté Quasar en 2025 comme un langage pour les actions de code exécutées par des agents fondés sur de grands modèles de langage. Les agents génèrent couramment du Python lorsqu'ils doivent appeler des outils ou construire un flux de contrôle, mais les chercheurs estimaient que Python n'offre pas les garanties de performance, de sécurité et de fiabilité nécessaires.
Quasar ajoute la parallélisation automatique, le suivi de l'incertitude et des mécanismes de validation des actions potentiellement dangereuses. Dans l'implémentation actuelle, le modèle écrit un sous-ensemble restreint de Python qui est transpilé en Quasar. Les chercheurs rapportent une réduction de 42 % du temps d'exécution lorsque la parallélisation était possible et de 52 % des interactions d'approbation requises lorsque ses mécanismes de sécurité s'appliquaient.
Quasar n'est pas la forme définitive d'un langage agent-native. L'agent émet encore du code proche de Python. Mais il rend la pression évidente : un langage conçu pour des personnes n'est peut-être pas le meilleur modèle d'exécution pour des agents.
Pel est un autre langage expérimental créé spécifiquement pour orchestrer des agents IA. Il utilise une grammaire minimale et met l'accent sur la génération contrainte, le contrôle des capacités, la communication entre agents, l'exécution sûre et la parallélisation automatique.
Pel s'inspire de langages comme Lisp, Elixir, Gleam et Haskell, mais sa conception pose que la facilité avec laquelle un modèle peut le générer de façon fiable est elle-même une caractéristique du langage.
C'est un renversement de priorités notable. Les concepteurs de langages traditionnels demandent si la syntaxe est compréhensible par une personne. Les concepteurs de langages agent-native demanderont plutôt si un modèle peut la générer de manière constante, la valider mécaniquement et se remettre d'une erreur sans intervention humaine.
Les agents de codage commencent aussi à montrer qu'ils n'ont pas besoin d'apprendre un langage inconnu comme le font les humains.
Dans une étude de 2026 sur des agents de codage confrontés à des langages ésotériques, les meilleurs agents écrivaient fréquemment des programmes Python qui généraient et déboguaient le code cible inconnu. Lorsque les chercheurs ont interdit cette stratégie de métaprogrammation, les performances ont nettement chuté.
C'est une forme primitive mais significative de l'avenir que je décris.
Un agent peut inférer une représentation cible, construire un générateur pour elle, tester le résultat et réviser le générateur. Il n'a pas besoin de comprendre ni de maintenir le code cible au sens humain. Le langage cible n'est qu'une représentation machine de plus qu'il peut manipuler.
Le premier langage agent-native pourrait ne pas ressembler à un langage
Quand on imagine un nouveau langage de programmation, on imagine d'ordinaire une nouvelle syntaxe.
C'est peut-être la partie la moins importante.
Un langage agent-native pourrait être une représentation structurée de :
- comportement attendu
- interfaces
- contraintes
- permissions
- invariants
- tests
- limites de ressources
- objectifs de performance
- politiques de sécurité
- modes de défaillance acceptables
L'agent de codage et le compilateur pourraient décider ensemble comment mettre en œuvre ces exigences.
Pour une charge de travail, le résultat serait du code machine natif. Pour une autre, du WebAssembly. Pour une autre encore, un plan de requête, un noyau GPU, une fonction serverless ou une composition de services existants.
Il n'existerait peut-être aucun fichier source permanent correspondant à l'implémentation.
L'artefact durable serait l'intention, et la preuve que l'implémentation la satisfait.
Cela suggère une progression en trois étapes.
Étape un : les agents écrivent des langages humains
C'est notre situation actuelle. Les agents produisent du code qui ressemble à ce qu'un développeur humain aurait pu écrire.
Étape deux : les agents écrivent des représentations intermédiaires orientées machine
Les humains examinent surtout le comportement, les tests, les spécifications, les explications générées et les évolutions de capacités. L'implémentation sous-jacente compte moins dans la revue courante.
Étape trois : les agents génèrent directement des systèmes exécutables
La source de vérité devient un ensemble d'intentions, de politiques, d'interfaces, de contraintes et de preuves de vérification. L'agent génère et régénère les implémentations exécutables selon les besoins.
À ce stade, demander dans quel langage une application est « écrite » n'aura peut-être plus grand sens.
Lisible par un humain ne veut pas dire auditable par un humain
L'argument le plus fort contre cet avenir est que le code source ne sert pas qu'à écrire du logiciel.
Il sert aussi au débogage, à l'audit, à la gouvernance, à la revue de sécurité, à la maintenance et à la responsabilité.
On ne peut pas exploiter en sécurité des systèmes importants dont personne ne peut inspecter le comportement.
Mais le code source lisible est déjà un piètre substitut à la compréhension réelle. Une grande application moderne peut contenir des millions de lignes de code propre et dépendre de millions d'autres via des paquets, des fichiers générés, des services cloud, des systèmes d'exploitation et des micrologiciels. Presque personne ne comprend l'ensemble.
Le code peut être lisible sans que le système soit intelligible.
Un système agent-native devrait offrir des formes d'inspection plus solides qu'un tas de fichiers sources. Il pourrait produire :
- des explications de comportements précis
- des cartes de circulation des données
- des preuves de propriétés importantes
- des rapports de permissions et de capacités
- des historiques de dépendances
- des simulations de modifications envisagées
- des tests exécutables
- des traces des raisons de chaque décision
- des implémentations lisibles quand c’est nécessaire
Le but ne devrait pas être de préserver le code lisible à tout prix.
Le but devrait être de préserver le contrôle humain.
Ce n'est pas la même chose.
Le coût environnemental d'un code taillé pour les humains
Il y a une autre raison pour laquelle les agents pourraient finir par dépasser les langages actuels : l'énergie.
Une étude de 2017 sur l'efficacité énergétique de 27 langages de programmation très citée a comparé temps d'exécution, usage mémoire et consommation d'énergie sur dix problèmes de référence.
Dans ses résultats normalisés, Python consommait environ 76 fois plus d'énergie que C et exigeait environ 72 fois plus de temps d'exécution. Python figurait presque en bas du classement énergétique.
Ce résultat a souvent été résumé en une affirmation : Python serait l'un des pires langages pour l'environnement.
La réalité est plus compliquée.
Une réanalyse de 2024 de l'efficacité énergétique des langages a montré que ces comparaisons peuvent confondre le langage avec son implémentation, la qualité du programme de test, le nombre de cœurs actifs, le comportement des bibliothèques, l'activité mémoire et d'autres détails d'exécution.
Après contrôle de ces facteurs, les chercheurs ont conclu que l'implémentation du langage n'avait pas d'effet significatif sur la consommation d'énergie au-delà du temps d'exécution.
Le problème central n'était pas que la syntaxe d'un langage consomme davantage d'électricité. Les programmes plus lents consommaient globalement plus d'énergie parce que le matériel restait actif plus longtemps.
Cette nuance ne fait pas disparaître le problème.
Le Python standard est souvent bien plus lent que du code compilé optimisé pour les travaux gourmands en calcul. Un programme qui met beaucoup plus de temps à accomplir la même tâche peut consommer beaucoup plus d'énergie, même si le processeur consomme à un rythme comparable pendant l'exécution.
La bonne nouvelle est que cette inefficacité n'est pas une fatalité.
Une étude de 2025 sur les implémentations compilées de Python a comparé CPython à plusieurs systèmes de compilation et d'optimisation, dont PyPy, Numba, Codon, Cython, Nuitka, Mypyc et Pyston-lite.
Les chercheurs ont constaté que la compilation pouvait nettement améliorer le temps d'exécution, l'usage mémoire et la consommation d'énergie. Codon, PyPy et Numba ont produit des gains de vitesse et d'énergie supérieurs à 90 % sur certaines charges testées.
La conclusion la plus juste n'est pas que Python serait intrinsèquement destructeur pour l'environnement.
C'est que les humains ont souvent choisi leurs langages en fonction de la productivité humaine, en traitant l'efficacité d'exécution comme une préoccupation secondaire.
Python réussit parce qu'il est lisible, expressif, indulgent et adossé à un immense écosystème. Dans beaucoup d'organisations, économiser du temps de développeur vaut bien de dépenser du temps de calcul.
Les agents n'affrontent pas le même arbitrage.
Un agent de codage n'a pas besoin d'une syntaxe agréable pour rester productif. Il n'a pas besoin d'un langage facile à enseigner, à taper ou à retenir. Il pourrait générer une représentation choisie pour la charge précise, la compiler pour le matériel disponible, mesurer le résultat et la remplacer dès qu'une implémentation plus efficace apparaît.
La consommation d'énergie pourrait devenir une propriété de premier plan de la programmation, plutôt qu'une optimisation tentée une fois le logiciel écrit.
Cela compte, car les agents ne vont pas simplement remplacer le code humain ligne à ligne. Ils vont probablement augmenter le volume total de logiciel produit et exécuté.
Les agents peuvent générer des dizaines d'implémentations, lancer des milliers de tests, créer des programmes jetables pour des tâches ponctuelles et régénérer sans cesse des systèmes fonctionnels. Une inefficacité tolérable quand le logiciel était produit lentement par des humains devient plus lourde de conséquences quand des machines peuvent générer du code presque sans limite.
Le premier langage agent-native pourrait donc optimiser plus que la correction et la vitesse. Il pourrait prendre en compte :
- la consommation d'énergie totale
- la fréquence d'exécution attendue
- les processeurs et accélérateurs disponibles
- les mouvements de mémoire
- le coût de compilation
- l'intensité carbone de l'électricité disponible
- la possibilité de différer ou de déplacer une charge
- le fait qu'une implémentation tournera une fois ou des milliards de fois
Il n'existe peut-être pas de représentation universellement optimale.
Une conversion de données ponctuelle privilégiera un coût de compilation minimal. Un service censé traiter des milliards de requêtes justifiera une optimisation native agressive. Une charge sur un appareil sur batterie privilégiera l'énergie sur la latence. Un traitement en centre de données pourra être planifié selon la disponibilité d'électricité moins carbonée.
Un agent pourrait prendre ces décisions automatiquement.
L'erreur environnementale ne serait peut-être pas de laisser les agents écrire du code illisible. Ce serait de les forcer à continuer d'écrire du Python simplement parce que les humains aiment le lire.
Que devient le programmeur ?
Rien de tout cela ne signifie que les humains cessent de construire des logiciels.
Cela signifie que notre travail monte d'un cran.
Au lieu de passer l'essentiel de notre temps à décrire des étapes d'implémentation dans une syntaxe pensée pour les compilateurs, nous passerons plus de temps à définir :
- ce que le système doit accomplir
- ce qu'il ne doit jamais faire
- quels compromis sont acceptables
- qui peut accéder à quoi
- comment le succès se mesure
- comment les échecs doivent être traités
- quelles preuves sont exigées avant le déploiement
C'est encore de la programmation.
À bien des égards, c'est plus directement de la programmation que de traduire soi-même ces décisions en boucles, classes, fonctions et fichiers de configuration.
Le rôle du programmeur tient moins à la production de code source qu'à l'établissement de l'intention, des contraintes, de l'architecture et du jugement. C'est une raison de plus pour laquelle je reviens sans cesse à l'idée que le goût est le goulot d'étranglement dès lors que construire devient bon marché.
Le difficile, dans le développement logiciel, n'a jamais été de taper la syntaxe. Le difficile était de décider ce qui devait se passer.
Les agents suppriment la couche de traduction.
Qui le créera ?
Le premier véritable langage agent-native ne sera peut-être pas présenté lors d'une conférence de développeurs.
Il n'aura peut-être ni nom astucieux, ni spécification publique, ni communauté débattant de sa syntaxe.
Il pourrait apparaître discrètement à l'intérieur d'une plateforme d'agents, comme une représentation intermédiaire privée servant à planifier, générer, vérifier, optimiser et compiler du logiciel. Il pourrait d'abord viser des langages classiques et des chaînes d'outils existantes, puis s'en passer peu à peu.
Le temps que les humains le reconnaissent comme un langage de programmation, les agents s'en serviront peut-être déjà pour écrire une part notable du logiciel mondial.
Le vainqueur ne sera pas nécessairement le langage que les humains prennent le plus de plaisir à lire.
Ce sera la représentation avec laquelle les agents produiront les systèmes les plus fiables, les plus sûrs, les plus efficaces et les plus vérifiables, tout en laissant aux humains un contrôle réel sur le résultat.
Les langages de programmation ont été inventés pour que les humains puissent dire aux ordinateurs quoi faire.
Le prochain sera peut-être inventé pour que les ordinateurs se le disent à eux-mêmes.
Top comments (0)