Développeur à l’ère des agents IA : mutation, industrialisation et avenir du métier
2025 a été un tournant majeur pour beaucoup de développeurs dans leur rapport à l'IA avec l'apparition des agents et c'est sans doute que l'on retiendra.
Bien sûr cela fait maintenant 4 ans qu'on parle d'IA jusqu'à l'écœurement, j'ai fait quelques posts et vidéos sur le sujet, mais l'évolution entre début 2025 et début 2026 est désormais flagrante.
Avec cette évolution vient une question majeure, quel est l'impact pour notre métier ? Comment le réinventer ?
Je vous propose une petite revue de presse pour aborder cette question.
L'ère des agents ?
Dans cet article, Simon Willison, co créateur de Django et Lanyrd, pointe le changement majeur de 2025 : l'année des agents.
Avec l'apparition fin 2024 des flows dans Windsurf et Claude Code en février 2025, tout a changé. Pour beaucoup, nous sommes passés de simple copier-coller entre le navigateur web et notre IDE à une délégation complète de l'activité de production de code.
2025, c'est aussi :
- la popularisation de l'expression vibe coding, qui continue de diviser entre incompréhension et mépris
- la normalisation des abonnements à 200$/mois
- les modèles conversationnels de génération d'image comme nano banana (auparavant on n'itérait pas, il fallait trouver le bon prompt du premier coup)
- le début des modèles de code locaux, que j'espère grandement voir se développer
Allez lire l'article de Simon, c'est beaucoup plus complet. Mais ce qu'il faut retenir c'est qu'avec ces agents, la nature même de notre métier a changé et c'est sans doute pas près de s'arrêter.
Un métier en mutation
Pour ceux, nombreux, qui continuent de ne pas utiliser l'IA, ou qui utilisent uniquement l'auto complétion basique dans l'IDE, le réveil risque d'être brutal. Le métier est en radical changement.
Je vous propose de lire cet article sur ce thème.
Smaine insiste sur l'évolution du rôle :
- from execution to direction
- from local optimizations to system-level thinking
- from writing instructions to defining intent
Et bien sûr que c'est inconfortable puisque ça relativise le prestige traditionnellement associé à l'écriture de code, en apparence.
When an LLM can generate boilerplate, implement well-scoped features, refactor safely, review code tirelessly… Then the act of typing code stops being the core differentiator, and that’s uncomfortable for many of us.
Je dis bien en apparence, car si le métier change, l'expertise/expérience reste un différenciateur important. Dans le flow actuel, je reste celui qui donne les directives, je corrige l'architecture, je définis le besoin et les problèmes à résoudre, les comportements attendus.
l’IA exige une rigueur architecturale encore plus grande. Pourquoi ? Parce que l’IA est un amplificateur. Elle magnifie ce qui existe déjà. Si je lui donne une codebase spaghetti, elle va produire plus de spaghetti, plus vite. Si je lui donne une architecture propre avec des responsabilités claires, elle devient un assistant chirurgical redoutablement efficace. Le principe est simple : Garbage In, Garbage Out.
Maintenant il faut bien comprendre que ces nouvelles pratiques sont apparus en 2025, le terme même de vibe coding est apparu dans un tweet en février ! Donc aujourd'hui, l'une des questions importantes, c'est : "comment allons-nous industrialiser ces nouveaux usages et les rendre plus compatibles avec une production logicielle fiable ?"
Le temps de l'industrialisation
Si je simplifie, mon métier est désormais de concevoir et d'écrire ensuite ce que je veux voir apparaître dans mon application. C'est un métier de rédaction, puis de vérification. Je dois contrôler que l'architecture est correcte, que la sécurité et la performance ont été prises en compte, que le modèle est cohérent.
Une fonctionnalité avancée me prend entre 2 et 6h en fonction de la complexité et de mes crédits disponibles ^^ (non je ne paie pas 200/mois). Certaines fonctionnalités auraient pu me prendre 1 à 2 semaines de travail.
Pour Chris Loy, le software devient une commodité
Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively. Industrialisation of production, in any field, seeks to address both of these limitations at once, by using automation of processes to reduce the reliance on human labour, both lowering costs and also allowing greater scale and elasticity of production. Such changes relegate the human role to oversight, quality control, and optimisation of the industrial process.
Mais nous n'en sommes qu'au début et beaucoup se demandent justement comment fiabiliser ce qui est produit par les assistants de code, ce qui implique :
- d'optimiser le nombre de tokens nécessaires pour réduire les coûts
- de fiabiliser les sources documentaires utilisées par les IA
- de garantir la cohérence globale via l'usage de guidelines
- de garantir la conformité entre l'implémentation et la spec
Bref, industrialiser.
Vous retrouverez toutes ces questions dans l'article de Nicolas Martignole : L’IA générative va changer notre façon de coder (unpopular opinion)
Il y a quelques approches qui ont déjà émergé comme :
- BMAD qui propose tout un ensemble d'agents conversationnels pour simuler une équipe complète.
- SpecKit, un peu dans le même esprit mais en beaucoup plus simple.
Pour avoir essayé les deux, je ne m'y suis pas retrouvé. Effectivement BMAD permet de simuler une équipe complète. Mais ça m'a rappelé les travers des grandes boites. J'ai quadruplé mon temps de conception, j'ai explosé mon quota de crédits et la spécification produite était beaucoup trop verbeuse et complexe. J'ai eu l'impression de faire du SAFe avec moi-même. Et c'est pas une expérience que je recommande...
SpecKit est nettement plus simple, mais toujours trop verbeux à mon goût. Pour une simple fonctionnalité, il a créé une demi-douzaine de fichiers, des PRD, des specs fonctionnelles, des specs techniques etc... C'est sans doute ce qu'on veut dans un grand groupe industriel. C'est inadapté dans à peu près tous les autres contextes. Trop de doc tue la doc.
Ce serait dommage de réinventer un métier et de recréer immédiatement des bullshits jobs robotisés...
Maintenant puisqu'on parle de mutation, est-ce la fin des développeurs ou le renouveau ?
Fin ou renouveau ?
Cette question est revenue tellement au fil des années que ça en devient caricatural.
Jusqu'à présent, la conclusion a toujours été la même : non.
Parce qu'on a eu le fameux effet rebond qui fait qu'en simplifiant l'usage, on a eu plus de demandes de développeurs.
J'ai tendance à modérer cette conclusion qui devient trop automatique aujourd'hui et j'ai bien peur qu'on se conforte dans une de sorte de réflexe pavlovien. Oui la réponse a systématiquement été non mais je vous invite à réfléchir à cet article qui nous rappelle le parallèle entre les développeurs et les tisseurs de 1811 pendant la fameuse révolte des luddites.
Voici ce qu'on oublie souvent : pendant la première révolution industrielle en Angleterre, les salaires réels ont stagné pendant 40 ans alors que la productivité explosait. Quarante ans. Deux générations de travailleurs ont vu leur niveau de vie se dégrader pendant que les propriétaires d'usines s'enrichissaient.
Oui, il peut y avoir un effet rebond, mais ça peut prendre longtemps et ne pas forcément profiter à tous :
Le World Economic Forum note que chaque révolution industrielle a créé plus d'emplois qu'elle n'en a détruits. Mais (et c'est un gros mais) les personnes qui perdent leur emploi ne sont pas forcément celles qui en trouvent un nouveau.
Les recherches historiques montrent que pendant la deuxième révolution industrielle, les jeunes travailleurs s'adaptaient en changeant de métier vers les secteurs en croissance. Les travailleurs plus âgés, eux, restaient coincés dans des emplois dévalorisés ou basculaient vers des postes non qualifiés.
Ce qui est sûr, c'est qu'il semble désormais y avoir une inéluctabilité à ces changements comme le rappelle Salvatore Sanfilippo, le créateur de Redis
But, in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun. (...) you can't control it by refusing what is happening right now. Skipping AI is not going to help you or your career.
Même pour Linus Torvalds, la question ne se pose plus :
Is this much better than I could do by hand? Sure is.
On retrouve ce même constat chez Jaana Dogan (principal engineer chez Google)
I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour.
Vous pourrez retrouver cette citation dans un article de Pragmatic Engineer qui parle du même sujet When AI writes almost all code, what happens to software engineering?.
Je pourrais aussi vous citer Quentin Adam (CEO de Clever Cloud)
As developers, we should be careful not to turn healthy skepticism into outright rejection of innovation. History shows that many of the biggest leaps in our field came from tools or ideas that were initially dismissed as “dangerous”, “lazy”, or “not real engineering”.
Pour finir sur une note plus optimiste, j'ai aimé cet article de Mattias Geniar : Web development is fun again
There’s mental space for creativity in building software again.
Je me retrouve pas mal dans cet article. Construire une application est difficile, mais j'adore construire des produits. Désormais, je peux aller beaucoup plus loin, et plus rapidement. Je peux m'attarder sur ce qui compte vraiment et pas refaire les mêmes boilerplate encore et encore pendant 20 ans. Pour moi, c'est un accélérateur et ça change totalement la façon dont je crée du logiciel. Je passe plus de temps à réfléchir, concevoir, penser aux problèmes à résoudre et moins de temps à me prendre la tête sur des détails d'implémentations. Je produis du meilleur logiciel et oui, c'est fun.
Et maintenant ?
Difficile à dire ce que sera 2026 quand on voit à quelle vitesse tout a accéléré en 2025 d'autant qu'on peut difficilement mettre de côté ce qui se passe aussi dans le monde réel et les potentiels impacts que cela pourrait avoir sur nous. Il me parait improbable que l'on revienne en arrière sur l'usage de l'IA de façon volontaire, mais d'autres évènements extérieurs pourraient nous contrarier en Europe, si par exemple les US nous coupaient l'accès à certains services, ou s'ils les utilisaient pour de l'espionnage industriel à grande échelle.
Alors peut-être que ce sera l'année de la recherche d'optimisation pour faire tourner plus facilement, pour moins cher et moins énergivore, ces fameux agents sur des machines locales. Ce sera peut-être aussi l'année de l'industrialisation de l'usage des LLMs en entreprise, mais avec une séparation nette, entre des boites AI natives et les autres. Je ferai un article plus complet sur ce sujet précis dans le futur.
Quoi qu'il en soit, restez à l'écoute. Le métier change, vite.
