En juillet 2026, l’un des mathématiciens les plus célèbres de la planète, Terence Tao, médaillé Fields, a publié sur son blog un billet d’apparence anodine. Il y racontait avoir ressuscité une vingtaine de petits programmes écrits en 1999 (des visualisations mathématiques en Java, un langage que les navigateurs ne lisent plus) et les avoir convertis en JavaScript moderne en quelques heures. Pas en traînant sur des forums. En déléguant le gros du travail à un agent de codage IA.
Un tournant dans la manière dont on fabrique des logiciels. Car ce que Tao a utilisé n’a presque plus rien à voir avec le chatbot auquel on demandait, il y a deux ans, de nous écrire une fonction. Ici, la machine ne propose pas du code ; elle le fabrique, l’essaie, constate qu’il casse et le répare. Voyons pourquoi cela change tout, avec des mots simples.
| 📘 Définitions pour les débutants LLM (grand modèle de langage) : le « cerveau » des IA conversationnelles, entraîné à produire du texte, dont du code, en réponse à une demande. Agent de codage autonome : un LLM auquel on a donné des outils (un terminal, un éditeur de fichiers, la possibilité de lancer des tests) et la liberté d’enchaîner plusieurs actions pour atteindre un objectif. On parle d’agentic coding, ou d’agentic engineering quand la démarche est encadrée et rigoureuse. |
Deux façons de travailler avec l’IA : le conseiller et l’ouvrier
Pour saisir la différence, filons la métaphore d’un chantier. Vous êtes le chef de chantier : vous savez ce qu’il faut construire, pourquoi, et à quoi ressemblera un travail bien fait. Reste à décider qui met les mains dans le ciment.
Le LLM classique : un conseiller au téléphone
Vous appelez un architecte très compétent. Il vous dicte : « Posez le carrelage comme ceci, mélangez le mortier dans ces proportions. » Vous notez, vous exécutez, vous constatez que la troisième rangée est de travers, vous le rappelez, il corrige de vive voix, vous recommencez. Il ne voit jamais le chantier. Vous êtes son unique paire de mains, et le copier-coller de code entre la conversation et votre éditeur en est la version numérique.
L’agent de codage : un ouvrier spécialisé autonome
Cette fois, vous embauchez un ouvrier qualifié. Vous lui remettez le plan et l’objectif : « Cette salle de bains doit être carrelée pour vendredi. » Il prend ses outils, pose, vérifie au niveau à bulle, s’aperçoit d’un défaut, redémarre la rangée, et vous prévient quand il a fini. Vous ne dictez plus chaque geste : vous fixez le cap, puis vous contrôlez le résultat.
| LLM classique (conseiller) | Agent de codage (ouvrier) | |
| Ce qu’il produit | Du code affiché dans une conversation | Des fichiers modifiés dans un vrai projet |
| Qui exécute le code ? | Vous, à la main (copier-coller) | Lui-même, dans son environnement |
| Qui voit les erreurs ? | Vous, qui les recopiez dans le chat | Lui, qui lit les messages d’erreur |
| Qui corrige ? | Vous appliquez ses corrections | Lui, en boucle, jusqu’à ce que les tests passent |
| Votre rôle | Opérateur : exécution et tri | Chef de chantier : cap et contrôle |
La boucle de rétroaction : le secret de l’ouvrier
Le mot barbare, boucle de rétroaction (feedback loop en anglais), désigne quelque chose de très courant. Le thermostat de votre salon en est un : il mesure la température, la compare à votre consigne, chauffe ou coupe, puis mesure de nouveau. Agir, observer, ajuster, recommencer. Rien de plus.
Pour un agent de codage, cette boucle ressemble à ceci, d’après la description qu’en donnent les spécialistes du secteur :
- Comprendre l’objectif que vous lui fixez.
- Explorer le projet : chercher les fichiers utiles et les lire.
- Planifier une suite de modifications et de vérifications.
- Exécuter : écrire du code, lancer des commandes.
- Tester : faire tourner les vérifications automatiques du projet.
- Corriger : lire l’échec, comprendre, modifier, retester.
- Rendre compte : présenter ce qui a changé pour que vous le relisiez.
C’est cette répétition qui distingue l’agent du simple chatbot. Le chatbot rend une copie. L’agent corrige sa copie avant de la rendre.
| 📘 Exemple concret Vous demandez : « Ajoute un bouton d’export en PDF sur la page des factures. » Un chatbot vous renvoie un bloc de code, à vous de le placer, de le tester, de rapporter l’erreur « module introuvable ». Un agent, lui, ajoute le code, lance l’application, rencontre cette même erreur, installe le module manquant, relance, voit que le test d’affichage passe, et vous présente un résumé des modifications. (Exemple illustratif.) |
Le sandbox : le chantier clôturé
Un ouvrier autonome, c’est formidable, jusqu’au jour où il perce une canalisation. D’où la seconde idée clé : le sandbox, littéralement « bac à sable ». C’est un espace fermé où l’agent peut travailler librement sans pouvoir abîmer ce qui se trouve autour, comme un chantier entouré de barrières avec des règles claires : « tu peux tout faire dans cette pièce, rien dans les autres ».
Techniquement, l’isolation repose sur deux piliers, décrits par Anthropic à propos de Claude Code :
- L’isolation du système de fichiers : l’agent n’accède qu’à certains dossiers, ce qui l’empêche de modifier des fichiers sensibles du système.
- L’isolation réseau : l’agent ne peut joindre que des serveurs approuvés, ce qui limite les risques de fuite de données ou de téléchargement de programmes malveillants.
Pourquoi c’est aussi un progrès de confort ? Parce que sans sandbox, l’agent doit vous demander la permission pour chaque action, et l’on finit par cliquer « oui » sans lire : c’est la fatigue d’approbation. Anthropic indique qu’en usage interne, son sandbox réduit les demandes de permission de 84 %, tout en restant sûr. Moins de questions, plus de garde-fous : voilà le marché.
| ⚠️ Ce que le sandbox ne fait pas Il protège votre machine contre les dégâts. Il ne garantit pas que le code produit soit correct. Un agent peut livrer, en toute sécurité, un programme faux. |
Le cas Terence Tao : ce que l’expérience montre
Reprenons l’histoire de Tao à la lumière de ces notions. D’après son billet et les articles qui l’ont commentée :
- Il a migré environ deux douzaines d’applets (petits programmes) écrites en 1999, des outils d’analyse complexe, d’algèbre linéaire et des visualisations mathématiques, vers JavaScript moderne, « en quelques heures ».
- Il a ensuite créé deux nouvelles applications (une visualisation de relativité restreinte et un outil autour de la conjecture de Gilbreath) en quelques heures chacune.
- Il a trouvé un seul bug mineur dans le code migré : un problème de gestion du glisser-déposer dans une applet. À l’inverse, l’agent a repéré deux bugs du code original de 1999 que Tao n’avait jamais vus.
Le point qu’on retient trop peu : Tao est resté chef de chantier. Il a apporté la direction et la connaissance des mathématiques, gardé les décisions de conception, examiné et corrigé les résultats. Il souligne lui-même que l’expérience en programmation et l’expertise du domaine restent essentielles pour repérer les problèmes, et que les agents peuvent produire des bugs évidents ou subtils. Sa règle de prudence : confier ces tâches quand le risque est faible, comme pour des visualisations secondaires, et pas pour du code critique.
Vibe coding, agentic coding, agentic engineering : démêler le vocabulaire
Ces termes fleurissent, et on les emploie parfois à tort et à travers. Voici un repère simple, en gardant en tête que ces étiquettes ne sont pas des normes officielles :
- Vibe coding : formule lancée début 2025 par Andrej Karpathy. On décrit ce qu’on veut, on accepte le résultat sans le relire, on colle les erreurs quand ça casse. Idéal pour un prototype jetable, risqué en production.
- Agentic coding : le fait de confier à un agent l’enchaînement écrire, exécuter, tester, corriger.
- Agentic engineering : expression que Karpathy a proposée en février 2026 : l’humain n’écrit plus lui-même le code la plupart du temps, il orchestre des agents et garde la rigueur d’ingénierie : cadrage, relecture, tests automatiques, garde-fous.
La nuance est capitale. Le même agent peut servir à bricoler ou à ingénier. Ce qui change, c’est la discipline autour de lui.
Ce que cela change pour créer des logiciels
- Le métier se déplace : moins de saisie de code, davantage de cadrage, de relecture et de décisions d’architecture.
- Les tâches ingrates se rétrécissent : migrations de code ancien (comme celle de Tao), écriture de tests, petites corrections répétitives.
- Les débutants et les non-informaticiens accèdent à plus de choses : Tao lui-même est mathématicien, pas ingénieur logiciel de métier.
- La vérification devient la compétence reine : savoir dire « ce résultat est faux » vaut plus que savoir taper vite.
Les limites : ce que l’ouvrier ne voit pas
Aucune baguette magique dans cette histoire. Les guides du secteur décrivent ce qu’ils appellent le « problème des 80 % » : l’agent termine bien le travail visible, mais rate des dépendances invisibles, surtout dans les gros projets. Il produit alors du code localement correct mais globalement incomplet.
- Bugs subtils : le code compile, les tests passent, mais un cas rare est oublié.
- Sécurité : un agent qui lit des documents peut être trompé par des instructions malveillantes qu’on y a glissées (injection de prompt). D’où l’intérêt du sandbox et des permissions.
- Confiance excessive : accepter sans relire, c’est retomber dans le vibe coding.
- Traçabilité : Tao a conservé les transcriptions de ses échanges comme trace d’audit, une habitude à copier.
Pour démarrer sans se brûler : 6 réflexes de chef de chantier
- Commencez petit : une tâche bornée, pas « refais tout mon site ».
- Versionnez : utilisez Git pour pouvoir revenir en arrière en une commande.
- Exigez des tests : sans vérification automatique, la boucle de rétroaction tourne à vide.
- Relisez le résumé des changements avant d’accepter.
- Gardez l’agent dans son sandbox et limitez ses permissions.
- Réservez les tâches critiques (sécurité, paiement) à une relecture humaine renforcée.
Ce qui frappe dans l’exemple de Tao, ce n’est pas la vitesse. C’est la posture : quelqu’un de très compétent dans son domaine, qui délègue l’exécution, garde le jugement, et met le résultat à l’épreuve. C’est cela, le vrai message. L’agent n’abolit pas l’expertise, il la rend plus décisive, car plus on délègue, plus il faut savoir juger ce qu’on reçoit. Le danger n’est pas que les machines codent ; c’est que nous cessions de savoir lire ce qu’elles ont écrit.
Et vous, qu’en pensez-vous ? Quelques questions pour lancer la discussion :
- Avez-vous déjà confié une vraie tâche à un agent de codage ? Le résultat vous a-t-il surpris, en bien ou en mal ?
- Un débutant doit-il apprendre à coder à l’ancienne avant de déléguer, ou peut-il apprendre en supervisant un agent ?
- Jusqu’où faire confiance : quelles tâches ne confieriez-vous jamais à un agent ?
- Le métier de développeur va-t-il se transformer en chef de chantier, ou y a-t-il quelque chose à perdre dans cette évolution ?
Racontez votre expérience en commentaire.