L’agent de code a remplacé tous les frameworks que j’utilisais
(blog.alaindichiappari.dev)> « 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 »
- Les développeurs doivent faire confiance à leur propre réflexion et à leur propre sens esthétique, et construire leurs propres outils et produits
5 commentaires
Voilà une véritable méthodologie de développement pensée pour rendre la maintenance difficile. C’est quelqu’un qui met en pratique, à l’ère de l’IA, une nouvelle manière de préserver sa place à vie.
Je n’adhère vraiment pas à cette idée de « frameworks et bibliothèques annexes coûteux et défectueux dont on n’utilise que 10 % des fonctionnalités dans la plupart des cas d’usage »... Le vrai mérite, ce n’était pas justement de bien choisir un environnement à la bonne taille pour son projet ? Si on ne pense pas développer grand-chose, on peut utiliser quelque chose de léger comme express. Faut-il vraiment créer dès le départ de quoi remplacer express ?
S’il faut parler d’outils riches en fonctionnalités dont on n’utilise qu’une petite partie, ce serait plutôt des serveurs web comme Apache ou nginx. Mais parce que ce serait trop lourd, est-ce qu’on recrée un serveur web depuis zéro ? Non, on le configure simplement et on l’utilise.
Il existe déjà des frameworks bien structurés, avec une documentation abondante sur laquelle l’IA a beaucoup été entraînée ; je ne vois pas vraiment pourquoi il faudrait créer quelque chose de nouveau juste pour soi. Au contraire, cela me semble plutôt faire baisser la productivité.
Je ne pense pas qu’il faille abandonner ce qui nous a permis de réduire le coût de conception de l’architecture et de nous concentrer sur l’essentiel, c’est-à-dire le service.
Hum… ce genre de pratique ne date-t-il pas plutôt de l’époque où Cursor offrait une utilisation illimitée… ? La vraie question serait plutôt : comment économiser les tokens et bien assister l’IA ? Au moins pour le moment, c’est ce qui semble être la direction à suivre.
On peut éliminer les duplications sans payer des tokens hors de prix, alors pourquoi ne pas utiliser un framework ?
Réactions sur Hacker News
Dans un futur proche, beaucoup de développeurs et d’entreprises risquent de subir un gros choc à cause du bluff autour de l’IA
Aujourd’hui, on peut certes construire des choses avec l’IA, mais les vrais problèmes sont ceux qu’on ne découvre qu’en s’y confrontant directement
Au final, ceux qui ne font que du « vibe coding » finiront par se heurter à des limites bien réelles, et seuls survivront ceux qui comprennent comment les systèmes fonctionnent réellement
Le bug pouvait être corrigé et mergé en deux minutes, et « comprendre le système » et « ne pas écrire soi-même le code » sont deux choses compatibles
AWS mise énormément sur cette direction, et à mesure que ces outils non déterministes se stabilisent, ils ont de fortes chances de dépasser la qualité humaine
Sans compréhension, on ne peut garantir ni l’exactitude du résultat, ni sa maintenabilité, ni sa capacité à passer à l’échelle
Mais si je travaille avec ce genre de personnes, je me demande pourquoi on devrait leur verser des centaines de milliers de dollars tout en payant aussi leur abonnement à un LLM
Bien sûr, on verra des applications issues du « vibe coding » se casser la figure, mais les équipes qui combinent tests, gestion de versions et documentation vont au contraire encore mieux s’en sortir
Au final, c’est une approche équilibrée qui compte
de-slopping)Peut-être qu’un jour on verra apparaître un « bot de de-slopping »
Si on utilise des frameworks, c’est parce que leurs concepteurs ont rencontré davantage de problèmes et de difficultés de montée en charge que nous
Au début d’un projet, tout semble simple, mais quand l’échelle augmente, la refonte devient douloureuse
En lisant ce genre de texte, on a souvent l’impression que l’article lui-même a été écrit par un LLM
Des métaphores du type « couper et recoudre des briques » ne font que montrer la contradiction
Construire toute sa stack soi-même reste inefficace et coûteux à maintenir
Ce qui change aujourd’hui, c’est qu’il est devenu facile de créer des composants sur mesure adaptés au problème
Pas besoin d’apprendre quelque chose de nouveau : les frameworks familiers suffisent
mon problème, le problème de la plateforme, et le problème de contourner le framework
Je trouve étrange ce type de texte qui parle de la souffrance d’écrire du code. Le coding, c’est plutôt la partie facile
Si Tolkien avait utilisé l’IA, il aurait probablement perdu son temps à peaufiner ses prompts
Surtout sur les parties difficiles, l’aide de l’IA devient plutôt un handicap
Si ce sont les mêmes personnes, c’est contradictoire
Ces temps-ci, si on le confie à Claude Code, c’est généralement réglé en quelques minutes
Mais moi, j’ai davantage confiance dans le code que j’ai écrit moi-même. Au final, la profondeur de compréhension compte plus que la vitesse
Comme Warhol, bien utiliser de nouveaux outils peut aussi être une forme d’art
Les LLM ne sont qu’un outil qui aide dans les premières étapes de la création, mais le génie vient toujours de l’humain
Considérer les correctifs de sécurité Node.js comme une corvée est une erreur
C’est un privilège. Une solution faite maison n’a ni communauté sécurité ni recul, et elle comporte davantage de vulnérabilités
On trouve facilement des développeurs React, mais il n’existe pas de développeurs pour un « framework propriétaire créé par l’IA »
Ce n’est pas si extraordinaire
Il existe une position intermédiaire entre les agents de coding et les frameworks
J’utilise toujours les mêmes outils, mais les tâches répétitives sont confiées aux agents
Moi, je me concentre sur l’architecture et les cas limites
Ignorer les agents comme leur faire une confiance aveugle, ce sont deux extrêmes
La vraie compétence, c’est de savoir quand reprendre le volant
Le problème de ce texte, c’est qu’il oppose les frameworks et la « vraie ingénierie »
Des plateformes comme Vercel, Next.js ou Firebase permettent déploiement immédiat et CI/CD
Quand on repense à l’époque où il fallait tout configurer soi-même avec Jenkins, c’est révolutionnaire
La vraie ingénierie, ce n’est pas « réinventer », c’est livrer rapidement au client
Il est inefficace que l’IA réimplémente des frameworks existants sans validation par l’épreuve du terrain
Sans écosystème ni patterns communs, la collaboration devient difficile
Des développeurs peu expérimentés qui utilisent mal l’IA, ce n’est pas différent d’avant
Si on fait tout soi-même, on perd la documentation, les middlewares et la maintenabilité
Ils en sont au stade où ils réalisent à nouveau qu’« on peut relier des API entre elles »
Mais ce genre de découverte ne s’accompagne pas forcément d’une compréhension des compromis
Depuis six mois, je fais du développement embarqué avec Cursor + Opus 4.x
Les LLM aident non seulement pour le logiciel, mais aussi pour la conception de circuits, la CAO et le CNC
Par exemple, j’ai finalisé en trois prompts une fonction wrapper pour un écran basé sur le ST7789
Désormais, je n’utilise presque plus de bibliothèques en dehors de LVGL, TinyUSB, la compression et le chiffrement
Les fonctions ciblées produites par les LLM sont petites, rapides et sans abstraction inutile
Je pense que le moment est venu pour beaucoup de bibliothèques de tirer leur révérence
Quelque chose comme .NET est irremplaçable, mais un ensemble de fonctions génériques peut tout à fait être remplacé
La partie pénible du coding, ce n’est pas la frappe, mais la collaboration humaine, les tests et la réflexion de conception
Ce qui m’a récemment le plus épuisé, c’est de concevoir une structure de données lock-free
À l’ère des LLM, la valeur des frameworks augmente encore
Grâce à leurs données d’entraînement, les LLM sont très à l’aise avec des patterns familiers comme React
Le fait qu’un humain puisse intervenir pour déboguer reste aussi important
Même si l’AGI arrive, il n’y a aucune raison de ne pas réapprendre des frameworks efficaces
Cette conversation en elle-même est une expérience intéressante