Le développeur-orchestrateur #1 — Pourquoi l’agentique change vraiment le développement web

Depuis des mois, on parle beaucoup d’IA dans le développement web. On compare les modèles, on teste les assistants, on regarde lequel code le plus vite, lequel explique le mieux, lequel se débrouille le mieux dans un terminal ou dans un IDE. C’est normal. C’est visible, concret, immédiatement mesurable.

Mais à force de regarder l’IA par le prisme de la vitesse ou de la qualité brute du code généré, on passe à côté de ce qui est en train de se jouer.

Le vrai sujet n’est pas seulement que l’IA aide à produire plus vite. Le vrai sujet, c’est que le développement web commence à changer de nature. Pas dans un futur lointain. Maintenant.

Nous sommes en train de sortir d’une logique où l’IA était surtout un interlocuteur brillant, parfois utile, parfois approximatif, souvent impressionnant, mais encore cantonné à une forme d’assistance. Ce qui arrive aujourd’hui est différent. L’IA ne se contente plus de répondre. Elle commence à agir dans le workflow. Elle lit des fichiers, propose des plans, modifie du code, lance des commandes, exécute des tests, reformule des specs, prépare une documentation, aide à structurer une review, s’insère dans des branches Git, interagit avec des outils.

Et quand une technologie cesse d’être seulement consultative pour devenir exécutable, les conséquences dépassent largement le simple gain de temps.

C’est pour cela que je pense que l’agentique change vraiment le développement web.

Pas parce qu’elle remplace magiquement les développeurs. Pas parce qu’elle écrirait soudain tout parfaitement. Pas parce qu’un prompt suffirait à produire des applications propres, robustes et maintenables. Au contraire. L’agentique change le développement web parce qu’elle déplace la valeur. Elle la déplace du geste de production brute vers la capacité à organiser, cadrer, superviser et fiabiliser un système de travail.

Et ce déplacement est beaucoup plus profond qu’il n’y paraît.

Nous ne sommes plus seulement dans l’ère du prompt

La première grande phase de l’IA pour développeurs a été conversationnelle. On posait une question, on obtenait une réponse, on corrigeait, on relançait. Cette phase a été importante. Elle a permis à beaucoup de monde de toucher du doigt quelque chose de très concret : oui, un modèle peut expliquer un bug, générer une fonction, proposer des tests, documenter un bout de logique, reformuler une idée d’architecture, accélérer un travail fastidieux.

Mais cette logique a aussi montré très vite ses limites.

Dans une conversation, on peut obtenir de très bonnes réponses ponctuelles. On peut même avoir l’impression d’un vrai dialogue technique. Pourtant, dès qu’on entre dans un projet réel, la difficulté n’est presque jamais dans la réponse isolée. Elle est dans tout ce qui entoure cette réponse : le contexte de l’application, les conventions internes, les choix d’architecture déjà actés, les dépendances existantes, les versions à supporter, les compromis historiques, les règles métier, les enjeux de sécurité, la façon dont une équipe lit, maintient et fait évoluer le code.

C’est là qu’un simple échange, même très bon, commence à montrer sa fragilité.

Un modèle peut très bien produire une solution élégante dans l’absolu et complètement inadéquate dans un projet réel. Non pas parce qu’il est mauvais, mais parce qu’il ne travaille pas naturellement à partir du même niveau de contexte qu’une équipe, ni avec la même mémoire des contraintes, ni avec la même compréhension des priorités.

Pendant un moment, beaucoup ont cru que le sujet principal serait d’écrire de meilleurs prompts. En réalité, ce n’était qu’une étape intermédiaire. Le sujet devient maintenant beaucoup plus large : comment fait-on travailler des systèmes d’IA dans de vraies chaînes de production logicielle, avec de vraies contraintes, de vraies vérifications, et de vraies responsabilités ?

C’est là que l’agentique commence — un sujet que j’avais déjà abordé sous un autre angle dans Fini le codeur solitaire.

Le basculement se produit quand l’IA entre dans le workflow

Je crois qu’il faut être très clair sur ce point : la rupture ne vient pas seulement du fait que les modèles deviennent meilleurs. Elle vient du fait qu’ils deviennent opérables dans des environnements de travail concrets.

Tant que l’IA reste un assistant dans une fenêtre, son impact reste limité à la qualité de ses réponses. Dès qu’elle entre dans un système de travail, la question change complètement.

À partir du moment où une IA peut lire un dépôt, comprendre une partie de l’existant, proposer un plan d’action, modifier plusieurs fichiers, lancer des commandes, vérifier des résultats, documenter ce qu’elle a fait, préparer une suite de tâches ou passer le relais à une autre étape, on ne parle déjà plus de la même chose.

On ne parle plus seulement d’assistance. On parle d’exécution encadrée.

Et cette différence change profondément la manière de penser le métier. Car la bonne question n’est alors plus : quel modèle code le mieux ? La bonne question devient : comment construire un cadre de travail dans lequel des agents peuvent produire quelque chose d’utile sans dégrader la qualité ?

C’est une question d’ingénierie. C’est même, d’une certaine manière, une nouvelle couche d’ingénierie.

Parce qu’un agent qui agit mal coûte plus cher qu’un assistant qui répond mal. Un assistant qui hallucine dans une conversation vous fait perdre un peu de temps. Un agent mal cadré qui modifie, exécute, enchaîne et dérive dans un projet réel peut créer de la confusion, de la dette et parfois des risques bien plus sérieux.

L’arrivée de l’agentique ne réduit donc pas le besoin de rigueur. Elle l’augmente.

Le vrai changement n’est pas la vitesse, c’est l’organisation du travail

Quand on parle d’IA pour développeurs, on tombe très vite dans un imaginaire de productivité immédiate. Produire plus vite. Corriger plus vite. Livrer plus vite. Et évidemment, cette accélération existe. Elle est réelle. Il serait absurde de la nier.

Mais si on s’arrête à ça, on lit le phénomène beaucoup trop superficiellement.

Dans un cadre professionnel, le problème n’a jamais été simplement d’écrire du code. Le problème a toujours été de produire un changement fiable dans un système existant. Un changement qui s’insère correctement dans l’architecture, qui respecte les contraintes du projet, qui ne casse pas autre chose, qui reste compréhensible par d’autres, qui passe dans un cycle de validation, qui peut être maintenu, repris, testé, corrigé, relu.

Autrement dit, ce qui compte n’est pas la vitesse brute de génération. Ce qui compte, c’est la capacité à faire avancer un système vivant sans perdre sa cohérence.

C’est exactement là que l’agentique devient plus intéressante que la simple génération de code. Parce qu’elle oblige à regarder le développement non plus comme une addition de tâches techniques, mais comme une chaîne de travail à structurer.

Qui fait quoi ? Avec quel contexte ? Dans quel ordre ? Avec quelles limites ? Avec quels points de contrôle ? Avec quelle validation humaine ? Avec quels garde-fous ?

Plus on avance dans cette réflexion, plus on comprend que la performance ne vient pas d’un miracle du modèle. Elle vient de la qualité de l’orchestration — un point qui rejoint ce que j’expliquais dans L’illusion du code jetable.

La rupture est d’abord organisationnelle

C’est, à mon sens, le point le plus important et probablement le plus sous-estimé.

On parle souvent de l’IA comme d’une révolution technique. C’est vrai, évidemment. Mais dans le développement web, l’impact majeur est aussi organisationnel. Peut-être même avant tout organisationnel.

Pourquoi ? Parce qu’un agent utile n’est jamais seulement un modèle performant. C’est un modèle inséré dans un rôle, dans une méthode, dans un cadre d’action.

Un agent commence à devenir vraiment intéressant quand on sait précisément ce qu’on attend de lui, ce qu’il a le droit de faire, ce qu’il ne doit pas faire, quelles ressources il peut utiliser, quel niveau de sortie on exige, comment son travail sera vérifié, et à quel moment un humain reprend la main.

Dit autrement, l’agentique pousse les équipes à rendre explicite ce qu’elles laissaient parfois dans l’implicite.

Elle oblige à clarifier. À découper. À nommer les responsabilités. À structurer les séquences. À mieux distinguer l’exploration, l’implémentation, la validation, la revue, le contrôle qualité.

C’est pour cela que je pense que les équipes qui tireront le plus de valeur de l’agentique ne seront pas forcément celles qui ont juste accès aux meilleurs modèles. Ce seront celles qui auront appris à transformer leur manière de travailler.

Les meilleures ne seront pas simplement assistées. Elles seront mieux organisées.

Le développeur ne disparaît pas, il change de centre de gravité

C’est souvent là que les réactions deviennent caricaturales. D’un côté, on entend que l’IA va remplacer les développeurs. De l’autre, on répète qu’elle ne sait pas terminer proprement un vrai projet et qu’il ne faut donc pas la prendre trop au sérieux.

Je pense que ces deux positions ratent l’essentiel.

Le développeur ne disparaît pas. Mais son centre de gravité bouge.

Certaines tâches deviennent plus faciles à accélérer : générer une base, proposer plusieurs variantes, documenter un morceau de logique, explorer rapidement une piste, automatiser une partie d’un travail répétitif. Ce mouvement est réel. Il va continuer. Et il va banaliser une partie de la production brute.

En parallèle, d’autres compétences prennent plus de valeur. Le cadrage. La compréhension du besoin réel. La qualité du contexte donné au système. Le découpage d’une tâche complexe en étapes vérifiables. La lecture des impacts. L’anticipation des effets de bord. L’architecture. La sécurité. L’arbitrage entre plusieurs options imparfaites. La capacité à dire stop, à corriger une dérive, à refuser une solution séduisante mais fragile.

C’est là que le métier se transforme.

Le développeur de valeur n’est plus seulement celui qui sait produire. C’est de plus en plus celui qui sait organiser une production augmentée sans perdre la maîtrise du résultat.

C’est pour cela que j’utilise l’expression développeur-orchestrateur.

Non pas pour créer un nouveau buzzword, mais pour nommer ce déplacement. On reste dans le développement. On reste dans la technique. On reste dans la responsabilité du livrable. Mais on ajoute une dimension devenue centrale : la capacité à faire travailler intelligemment un ensemble d’agents, d’outils, de validations et de contextes.

Le piège serait de croire qu’un bon modèle suffit

Il y a une idée séduisante qui circule beaucoup : à mesure que les modèles deviennent meilleurs, les problèmes disparaîtront d’eux-mêmes. Il suffira alors de choisir le bon acteur, la bonne interface ou le bon agent, et la machine produira le reste.

Dans la pratique, ça ne se passe pas comme ça.

Même un excellent modèle dérive si la demande est floue. Même un excellent modèle se trompe si les contraintes importantes ne sont pas explicites. Même un excellent modèle produit du bruit si personne ne vérifie réellement ce qu’il fait. Même un excellent modèle peut donner une illusion de cohérence alors qu’il accumule des hypothèses fragiles.

C’est justement ce qui rend le sujet intéressant : la qualité finale dépend moins du “génie” supposé du modèle que de la solidité du cadre dans lequel on le fait travailler.

Et cette réalité change la nature de la différenciation.

La différence ne se fera pas uniquement sur l’accès à une meilleure IA. Elle se fera sur la capacité à construire de meilleurs systèmes de travail autour d’elle. De meilleurs contextes. De meilleures méthodes. De meilleurs points de contrôle. De meilleures règles de passage entre les étapes. De meilleures habitudes de validation.

Autrement dit, l’avantage ne sera pas seulement technique. Il sera méthodologique — un risque que je détaillais dans IA et développement : maîtriser les pièges invisibles.

Le développement web devient un système plus explicite

Pendant longtemps, une grande partie du développement reposait sur une forme de compression humaine. Le développeur absorbait beaucoup de choses à lui seul : la demande, le contexte, les contraintes, les décisions historiques, les chemins les plus risqués, les habitudes du projet, la manière d’éviter certaines erreurs, les arbitrages de livraison.

Avec l’agentique, une partie de cette compression doit être réouverte et structurée.

Ce qui était implicite doit être explicité. Ce qui était tenu en tête doit être documenté, transmis, rendu opérable. Ce qui était diffus dans une équipe doit parfois être transformé en contexte exploitable, en règles, en patterns, en étapes, en contrôles.

C’est un changement important, parce qu’il pousse le développement web vers une logique plus systémique.

Le projet n’est plus seulement une base de code. Il devient aussi un ensemble de conventions, de flux, de points de validation, de mémoires de décision et de rôles outillés. Le développeur ne perd pas sa place dans ce système. Il en devient, au contraire, une pièce encore plus stratégique. Parce que quelqu’un doit donner la forme. Quelqu’un doit décider du niveau de confiance. Quelqu’un doit reprendre la main quand l’automatisation devient imprécise. Quelqu’un doit garder la responsabilité du résultat.

L’agentique n’efface donc pas le développeur. Elle met en lumière ce que les bons développeurs faisaient déjà souvent sans forcément le formaliser : structurer, prioriser, coordonner, vérifier, relier.

La productivité change de définition

C’est une autre conséquence majeure.

Pendant longtemps, on pouvait lire la productivité de manière assez simple : vitesse d’exécution, quantité produite, rythme de livraison, capacité à traiter des tickets, à sortir des features, à corriger des bugs.

Avec l’agentique, cette lecture devient trop pauvre.

Un développeur peut désormais aller très vite tout en créant plus de bruit autour de lui. Il peut produire davantage de code, davantage de changements, davantage de branches, davantage de sorties intermédiaires… sans pour autant augmenter la valeur nette pour le projet. Parfois même en la dégradant, si rien n’est réellement orchestré.

La vraie productivité devient donc plus exigeante. Ce n’est plus seulement la capacité à accélérer. C’est la capacité à accélérer sans perdre le contrôle, sans diluer la cohérence, sans faire exploser la charge de revue, sans créer une dette silencieuse que l’équipe paiera plus tard.

Cette nuance est essentielle. Parce qu’elle rappelle une chose simple : la vitesse n’a de sens que si elle reste compatible avec la qualité.

Et dans un environnement agentique, la qualité ne vient plus seulement du talent individuel de production. Elle vient aussi de la façon dont le travail a été cadré, distribué, vérifié et repris.

Les meilleurs vont apprendre à organiser, pas seulement à prompter

Je pense que les développeurs qui tireront le plus de valeur de cette phase ne seront pas forcément ceux qui accumulent les prompts ou qui changent d’outil toutes les deux semaines. Ce seront ceux qui comprendront que le sujet de fond est la structuration du travail.

Ils apprendront plus vite que les autres à transformer une demande floue en étapes nettes. À définir des rôles clairs. À exiger des sorties vérifiables. À donner du contexte utile plutôt que du bruit. À faire intervenir la revue humaine au bon moment. À distinguer ce qui peut être largement automatisé de ce qui doit rester fortement arbitré.

En bref, ils comprendront que l’agentique n’est pas d’abord un sujet de fascination technologique. C’est un sujet de discipline.

Et c’est sans doute là le point le plus contre-intuitif de cette nouvelle phase : plus l’IA devient capable, plus elle exige un cadre sérieux pour produire de la valeur durable.

Pas moins de méthode. Plus de méthode.
Pas moins de rigueur. Plus de rigueur.
Pas moins d’ingénierie. Une ingénierie plus large — un sujet que j’explore aussi dans J’ai arrêté BMAD.

Le vrai sujet est déjà devant nous

À ce stade, la question n’est déjà plus vraiment de savoir si les agents vont trouver une place dans le développement web. Cette place est en train de se construire sous nos yeux.

La vraie question est plutôt celle-ci : quel type de système de travail allons-nous bâtir autour d’eux ?

Parce qu’un agent sans cadre n’est qu’un amplificateur d’ambiguïté. Une IA sans contexte n’est qu’une approximation plus rapide. Une automatisation sans validation n’est qu’un risque mieux emballé.

L’agentique n’est pas un raccourci magique. C’est une nouvelle couche de responsabilité.

Et c’est pour cela qu’elle change vraiment le développement web. Non pas parce qu’elle supprimerait le besoin de développeurs, mais parce qu’elle oblige les développeurs à rendre plus explicite, plus structuré et plus gouverné tout ce qui permet réellement de produire de la qualité.

Conclusion

L’agentique ne marque pas seulement une nouvelle étape dans l’assistance au code. Elle ouvre une phase où le développement web devient plus systémique, plus orchestré, plus dépendant de la qualité du contexte, du découpage, de la validation et de la supervision.

Ce changement est profond, parce qu’il touche moins le spectacle de la génération que la réalité de la production.

Dans ce paysage, le développeur ne s’efface pas. Il devient plus central sur ce qui compte vraiment : comprendre, cadrer, structurer, arbitrer, vérifier, assumer le résultat final.

Autrement dit, il ne cesse pas d’être développeur. Il devient aussi orchestrateur.

Et c’est précisément ce que je vais creuser dans le prochain article de cette série : pourquoi un agent seul ne suffit pas.

À suivre dans la série

Le développeur-orchestrateur #1 — Pourquoi l’agentique change vraiment le développement web
Le développeur-orchestrateur #2 — Pourquoi un agent seul ne suffit pas
Le développeur-orchestrateur #3 — Pourquoi les skills, le contexte et la méthode changent tout
Le développeur-orchestrateur #4 — Le nouveau métier : cadrer, orchestrer, arbitrer