L’agent de code a remplacé tous les frameworks que j’utilisais

> « L’ingénierie logicielle est de retour »

• Avec les progrès des modèles d’IA de pointe et des agents de code, l’ère de la programmation automatisée s’ouvre : le travail manuel consistant à taper soi-même chaque ligne de code disparaît, et les ingénieurs logiciel peuvent à nouveau se concentrer sur la conception et la réflexion essentielles
• Depuis la fin de l’année dernière, la maturité des outils et des modèles s’est améliorée de façon spectaculaire, rendant possible une manière de travailler où l’on se consacre au rôle d’architecte tout en pouvant intervenir directement pour corriger ce qui doit l’être
• Dans le développement web, mobile et desktop, des années de frameworks et couches d’abstraction inutiles se sont accumulées sans résoudre la vraie complexité, et ont au contraire aggravé les problèmes
• Parmi les trois problèmes que les frameworks prétendent résoudre — simplification, automatisation, réduction des coûts de main-d’œuvre — seule l’automatisation avait une valeur réellement légitime, mais l’automatisation par l’IA peut désormais la remplacer elle aussi
• Il ne faut pas se laisser réduire au rang d’opérateur de systèmes conçus par des hyperscalers comme Google, Meta ou Vercel, mais revenir à une véritable ingénierie où l’on conçoit et construit soi-même ses produits

---

L’essor de la programmation automatisée

• Le cadrage « automated programming » proposé par Antirez saisit bien mieux l’essence du phénomène que « vibe coding »
  • Comme l’imprimerie, le métier à tisser ou la chaîne d’assemblage, l’automatisation est au cœur des grandes révolutions historiques, et ce changement s’inscrit dans cette continuité
• Depuis décembre 2025, les capacités des modèles de pointe et des agents de code ont radicalement changé, au point que c’est déjà évident pour quiconque observe attentivement

L’évolution du rôle de l’ingénieur

• Les tâches qui exigent une réflexion approfondie — architecture, arbitrages, décisions produit, cas limites — restent bien présentes
• Ce qui a disparu, c’est le travail manuel épuisant et répétitif qui consistait à taper soi-même chaque ligne de code
• Dans un environnement proprement et rigoureusement configuré, l’usage des modèles et des outils permet de jouer le rôle de l’architecte sans poser soi-même chaque brique
• Cela repose sur vingt ans d’expérience à écrire du code soi-même ; et si le résultat ne convient pas, on peut intervenir directement, le comprendre, le corriger, puis mettre à jour la configuration
• Comme il est possible de produire instantanément les outils nécessaires, on peut consacrer davantage de temps à concrétiser la technologie que l’on imagine

Frameworks et complexité inutile

• Dans le développement web, mobile et desktop, une pollution massive de frameworks, bibliothèques et outils s’est accumulée au fil des années
• Des couches d’abstraction qui n’abstraient rien de réellement significatif se superposent, prétendent résoudre un problème, puis en créent dix nouveaux
• Au lieu d’aiguiser sa réflexion face à la vraie complexité de la construction logicielle, l’ensemble du secteur a choisi d’acheter une pensée préfabriquée
• C’est envelopper une jambe cassée dans de la soie : l’apparence est belle, mais la jambe reste cassée

Les trois problèmes que les frameworks prétendent résoudre

• « Simplification » : des ingénieurs craignent de concevoir eux-mêmes et adoptent aveuglément la structure conçue par d’autres
  • Au lieu de concevoir à rebours à partir de l’objectif, ils appliquent partout un design one-size-fits-all
  • Ce n’est pas de la simplification, mais une capitulation intellectuelle
• « Automatisation » : la seule valeur vraiment défendable était l’élimination du boilerplate
  • Automatisation de tâches répétitives mais indispensables comme les ORM, la gestion CRUD, la génération de code ou la documentation d’API
  • Mais c’est précisément là que l’IA est en train de tout changer
• « Réduction des coûts de main-d’œuvre » : la raison silencieuse, absente des slides de conférence
  • Si l’on laisse Google, Meta ou Vercel décider de la manière de construire les produits et de déployer le code, on peut embaucher non pas un ingénieur logiciel mais un “développeur React”
  • Pas besoin de formation, plug-and-play, une main-d’œuvre interchangeable comme un rouage
  • Ce n’est pas de l’ingénierie, c’est de l’exploitation

La réalité de cette nouvelle manière de travailler

• Cela fait plus de deux ans que cette méthode est utilisée pour développer presque sans défaut, et la véritable révolution a commencé en décembre dernier
  • Une opportunité s’est ouverte : éliminer la complexité inutile pour se concentrer sur la complexité centrée sur les idées
• Le coût d’élimination du boilerplate tend presque vers zéro, ce qui évite d’écrire deux fois le même code
• Il devient possible de construire instantanément de petits outils spécialisés, précisément adaptés au problème
• Sans gestionnaire de monorepo tape-à-l’œil, un simple Makefile couvre 99 % des cas d’usage
• Quand un problème devient réellement très complexe, on y réfléchit à ce moment-là, mais jamais avant par anticipation : c’est cela, l’ingénierie
  • Il faut résoudre le problème que l’on a maintenant, pas celui dont quelqu’un a dit sur une scène de conférence qu’il surviendrait peut-être un jour

Redécouverte de Bash et des outils de base

• Les agents maîtrisent très bien les outils de base qui existent depuis des décennies
• Bash est né en 1989, et aujourd’hui même le modèle le plus banal connaît Bash mieux que n’importe quelle personne au monde
• Les agents de code ont tendance à passer de configurations MCP complexes et coûteuses à de simples boucles d’agents fondées sur Bash
• L’outil le plus ancien est le plus pérenne pour l’avenir

Le coût de la dépendance aux frameworks

• Dans la plupart des cas d’usage, il n’y a pas besoin de frameworks coûteux et défectueux ni de bibliothèques annexes dont on n’utilise que 10 % des fonctionnalités
  • Les coûts invisibles sont élevés — maintenance, mises à jour de sécurité, contraintes de conception — et limitent la liberté des développeurs
• Continuer à accepter ce compromis, c’est passer à côté de la plus grande opportunité depuis des décennies
• Il faut se méfier d’une structure qui rend dépendant de la philosophie de conception des grandes entreprises comme Google, Meta ou Vercel
  • Les développeurs doivent faire confiance à leur propre réflexion et à leur propre sens esthétique, et construire leurs propres outils et produits
    > « N’enveloppez pas une jambe cassée dans de la soie ; construisez quelque chose qui vous appartient vraiment »