Le développeur-orchestrateur #4 — Le nouveau métier : cadrer, orchestrer, arbitrer

Depuis le début de cette série, j’essaie de défendre une idée simple, mais structurante.

L’agentique ne transforme pas seulement les outils du développement web. Elle transforme aussi la nature du travail. Elle change ce que l’on produit, mais surtout la manière dont on le produit, le contrôle que l’on garde dessus, et les compétences qui prennent de la valeur.

Dans le premier article, j’expliquais pourquoi l’agentique change vraiment le développement web : parce qu’elle fait entrer l’IA dans le workflow réel, et qu’à partir de là, on ne parle plus simplement d’assistance, mais d’exécution encadrée.

Dans le deuxième, j’expliquais pourquoi un agent seul ne suffit pas : parce que les projets réels demandent de la spécialisation, des handoffs, des validations distinctes et une architecture de responsabilités.

Dans le troisième, j’expliquais pourquoi les skills, le contexte et la méthode changent tout : parce que la qualité ne vient pas du modèle seul, mais du cadre dans lequel on le fait travailler.

Le quatrième article est la conséquence logique de tout cela.

Si l’agentique change l’organisation du travail, si l’agent unique ne suffit pas, et si la qualité dépend du contexte, des skills et de la méthode, alors une autre conclusion s’impose : le métier de développeur est lui aussi en train de se déplacer.

Pas de disparaître.
Pas de se dissoudre.
Pas de devenir secondaire.

De se déplacer.

Et ce déplacement mérite d’être nommé.

Le développeur n’est pas remplacé, il est recentré sur ce qui compte vraiment

Une grande partie du débat public autour de l’IA reste piégée entre deux caricatures.

La première dit que les développeurs vont être remplacés. La seconde répond que l’IA reste trop imparfaite pour menacer quoi que ce soit de sérieux.

Ces deux lectures sont trop courtes.

La première sous-estime la profondeur du travail réel. La seconde sous-estime la vitesse à laquelle ce travail peut être recomposé.

Ce que je vois émerger, ce n’est ni la fin du développeur, ni la continuité pure et simple du métier tel qu’il existait il y a quelques années. Ce que je vois, c’est un recentrage progressif de la valeur.

Certaines tâches deviennent plus accessibles à l’automatisation assistée. Générer une base de code, proposer des variantes, accélérer une documentation, explorer rapidement plusieurs pistes, rédiger des premiers jets, produire des structures répétitives, préparer des tests ou des correctifs simples : tout cela devient plus facile à déléguer, à assister, à accélérer.

Mais à mesure que cette production brute se banalise, autre chose monte en importance.

Comprendre le vrai besoin.
Choisir le bon niveau de découpage.
Savoir ce qu’il faut expliciter.
Déterminer ce qui peut être confié et ce qui doit être vérifié.
Identifier les zones de risque.
Garder une cohérence d’ensemble.
Arbitrer entre vitesse et robustesse.
Maintenir la qualité dans un système de travail plus rapide et plus distribué.

C’est là que la valeur se reconcentre.

Le développeur utile ne disparaît pas. Il devient plus responsable de la forme du système de production que de chaque ligne produite manuellement.

Ce qui se commoditise n’est pas le métier, mais une partie de sa surface

C’est une nuance importante.

Quand on dit que l’IA change le métier, certains entendent immédiatement que le métier perd de sa valeur. En réalité, ce n’est pas si simple. Ce qui perd en rareté, ce n’est pas l’ensemble du développement. C’est surtout une partie de sa surface de production.

Produire vite une structure de base devient moins différenciant. Reformuler un bout de logique devient moins rare. Générer une variante supplémentaire devient moins coûteux. Mettre en forme un premier niveau de documentation devient moins impressionnant. En bref, tout ce qui relève d’une production relativement standardisable tend à se banaliser.

Mais cette banalisation ne supprime pas la difficulté. Elle la déplace.

Le problème n’est plus seulement d’écrire quelque chose. Le problème est de faire produire correctement un système qui peut désormais écrire beaucoup, vite, et parfois de manière trompeusement convaincante.

Autrement dit, quand la génération devient plus facile, la sélection, la structuration et la validation deviennent plus stratégiques.

C’est exactement ce que beaucoup de métiers ont déjà vécu sous d’autres formes. Quand une capacité de production se démocratise, la vraie valeur remonte souvent vers la direction, la cohérence, la qualité de jugement et le contrôle du résultat final.

Le développement web entre lui aussi dans cette logique.

Le nouveau point de tension, c’est l’arbitrage

Il y a une compétence qui devient particulièrement importante dans ce nouveau paysage : l’arbitrage.

Un système agentique peut proposer plusieurs options. Plusieurs implémentations. Plusieurs architectures. Plusieurs façons de découper une tâche. Plusieurs compromis. Plusieurs manières de contourner une contrainte. Plusieurs interprétations d’un besoin encore flou.

Vu de loin, cela ressemble à une abondance formidable. Vu de près, cela crée un nouveau type de pression.

Car quelqu’un doit décider.

Quelqu’un doit choisir la version acceptable, et pas seulement la version possible. Quelqu’un doit distinguer la solution la plus rapide de la solution la plus saine. Quelqu’un doit savoir quand une proposition élégante est en réalité trop fragile. Quelqu’un doit repérer quand le système a bien répondu à la demande… mais pas au vrai problème.

C’est là que l’arbitrage devient central.

Et cet arbitrage n’est pas un supplément “managerial” posé au-dessus de la technique. C’est un acte profondément technique, parce qu’il suppose de comprendre les effets de bord, la maintenabilité, la sécurité, la cohérence, la compatibilité, le coût futur de certaines décisions, et la solidité réelle des chemins proposés.

Plus les systèmes deviennent capables de produire rapidement, plus le jugement qui sélectionne, corrige et valide prend de la valeur.

Cadrer devient une compétence de production à part entière

Pendant longtemps, beaucoup de développeurs ont vu le cadrage comme une étape préparatoire, parfois nécessaire, parfois un peu frustrante, avant “le vrai travail”, celui qui consiste à construire.

Avec l’agentique, cette hiérarchie devient beaucoup moins évidente.

Parce qu’un système outillé, si on le cadre mal, peut produire énormément de choses inutiles, inadaptées ou coûteuses à relire. À l’inverse, un système bien cadré peut accélérer très fortement sans sacrifier le sens.

Du coup, le cadrage change de statut. Il n’est plus un préambule. Il devient un levier direct de qualité et de productivité.

Bien cadrer, ce n’est pas simplement reformuler une demande. C’est clarifier ce qui compte vraiment. C’est réduire l’ambiguïté utilement. C’est poser les bonnes frontières. C’est éviter de transformer un flou métier en certitude technique prématurée. C’est définir des attentes de sortie vérifiables. C’est décider à quel niveau on demande une exploration, une implémentation, une revue, ou un contrôle.

En clair, cadrer devient une manière de produire mieux.

Et cela change le profil qui prend de la valeur dans une équipe. Non pas seulement celui qui exécute vite, mais celui qui sait préparer un espace d’exécution propre.

Orchestrer n’est pas déléguer aveuglément

Le mot “orchestration” peut parfois donner l’impression d’une supervision confortable, presque distante, comme si le développeur se contentait de distribuer des tâches à des agents avant de récolter le résultat. Ce n’est pas ce que j’entends par là.

Orchestrer, ce n’est pas dire “faites ça” à une collection d’outils et attendre. Orchestrer, c’est construire une chaîne de travail où chaque étape a une fonction claire, un niveau de contexte adapté, des critères de réussite compréhensibles, et une articulation cohérente avec les autres.

Cela suppose des décisions très concrètes.

Faut-il commencer par explorer ou spécifier ?
Faut-il faire produire une première base avant la review, ou faire passer une étape de cadrage plus forte ?
Faut-il séparer nettement l’implémentation et la validation ?
À quel moment injecter les contraintes de sécurité ?
Quand faut-il interrompre une chaîne pour éviter qu’elle ne propage une mauvaise hypothèse ?
Quels résultats sont assez fiables pour passer au stade suivant ?
Qu’est-ce qui doit rester sous revue humaine obligatoire ?

L’orchestration n’est donc pas une abdication de la technique. C’est une technique de plus haut niveau.

Elle demande moins de fascination pour les outils et plus de maîtrise sur les conditions dans lesquelles ils travaillent.

Le développeur-orchestrateur reste un développeur

C’est un point important, parce qu’il permet d’éviter un malentendu.

Quand je parle de développeur-orchestrateur, je ne parle pas d’un profil qui aurait quitté la technique pour devenir une sorte de coordinateur flou. Je parle d’un développeur qui reste profondément ancré dans la réalité du code, de l’architecture, des contraintes projet, des bugs, des arbitrages de qualité, des dépendances, de la maintenance, de la sécurité, des livrables.

Simplement, ce développeur ne tire plus toute sa valeur de sa seule capacité à produire lui-même chaque morceau à la main.

Il tire de plus en plus sa valeur de sa capacité à faire travailler correctement un système de production enrichi par l’IA.

Il comprend ce qui est produit.
Il comprend pourquoi cela a été produit ainsi.
Il comprend ce qu’il faut vérifier.
Il comprend où le système peut mentir, dériver ou simplifier à tort.
Il comprend quand accélérer et quand freiner.

C’est précisément pour cela que ce rôle reste profondément technique. Il n’est pas moins technique que le développement traditionnel. Il est technique autrement, avec un niveau supplémentaire de structuration, de discernement et de responsabilité.

La responsabilité finale ne peut pas être externalisée

C’est peut-être le point le plus important de tous.

Dans beaucoup de discours sur l’IA, on sent une tentation : imaginer que la responsabilité pourrait suivre la délégation. Comme si, à mesure que l’on confie plus de travail à des agents, une partie du poids du jugement pouvait se dissoudre avec lui.

Je ne crois pas à cette lecture.

On peut déléguer une partie de l’exécution. On peut accélérer une partie de la production. On peut automatiser certains enchaînements. On peut assister, enrichir, structurer, distribuer. Mais on ne peut pas externaliser la responsabilité du résultat final.

Quelqu’un doit rester comptable de la qualité livrée.
Quelqu’un doit assumer le fait qu’un choix a été accepté.
Quelqu’un doit être capable d’expliquer pourquoi cette option a été retenue plutôt qu’une autre.
Quelqu’un doit porter la cohérence du produit, du projet, de l’architecture et des risques.

C’est précisément là que le développeur-orchestrateur se distingue. Il n’utilise pas les agents pour s’effacer. Il les utilise pour construire un système plus puissant, tout en gardant la responsabilité de ce qui compte.

Cette nuance est décisive. Parce qu’elle fait toute la différence entre une équipe réellement augmentée et une équipe simplement fascinée par l’automatisation.

Les freelances, les agences et les équipes ne seront pas impactés de la même manière, mais tous seront touchés

Cette transformation n’aura pas exactement les mêmes effets partout. Mais elle n’épargnera personne.

Pour un freelance, l’agentique peut devenir une formidable extension de capacité. Elle permet d’explorer plus vite, de préparer mieux, de tester plus large, de documenter plus proprement, de produire des bases solides plus rapidement. Mais elle oblige aussi à monter en niveau sur le cadrage, la méthode, la revue et la responsabilité assumée. Le freelance qui se contentera de “faire produire” sans organiser finement le système prendra des risques très vite.

Pour une agence, la question devient encore plus structurelle. L’agentique touche directement à la manière de distribuer le travail, de transmettre les standards, d’industrialiser les bonnes pratiques, de fiabiliser les livrables et de transformer l’expérience de l’équipe en actif réutilisable. L’enjeu n’est pas seulement individuel. Il devient organisationnel.

Pour une équipe produit ou technique interne, la transformation se lit souvent dans les workflows, les critères de validation, les règles de revue, les zones d’automatisation acceptable, les référentiels de skills et la qualité du contexte projet. Là aussi, la maturité ne viendra pas seulement de l’outil adopté, mais de la façon dont l’équipe recompose son système de travail.

Le point commun reste le même : la valeur va monter vers ceux qui savent structurer.

Ce qui va distinguer les meilleurs profils dans les années qui viennent

Je pense que les profils les plus solides ne seront pas seulement ceux qui savent “utiliser l’IA”, formule devenue beaucoup trop large pour être vraiment utile.

Les meilleurs profils seront ceux qui savent :

• transformer une demande floue en espace de travail exploitable ;
• distinguer ce qui doit être automatisé de ce qui doit être arbitré ;
• construire des chaînes de travail lisibles ;
• préserver la qualité sous accélération ;
• stabiliser des skills et des patterns réutilisables ;
• détecter les zones où l’IA devient trompeusement convaincante ;
• garder un haut niveau de responsabilité sur le résultat final.

Autrement dit, ils sauront moins “faire confiance à la machine” que organiser correctement les conditions dans lesquelles cette machine peut être utile.

C’est là que se jouera une grande partie de la différenciation.

Pas dans l’enthousiasme.
Pas dans le nombre d’outils testés.
Pas dans la quantité de code générée.
Mais dans la qualité du système de travail mis en place.

Le métier ne se réduit pas, il monte en densité

On pourrait croire que l’agentique simplifie le métier de développeur en retirant une partie du travail. À court terme, elle simplifie certaines tâches, oui. Mais à plus long terme, elle densifie le métier.

Parce qu’elle oblige à être plus explicite.
Parce qu’elle pousse à mieux formaliser.
Parce qu’elle rend visibles des compétences qui restaient parfois implicites.
Parce qu’elle met sous tension la qualité du jugement humain.
Parce qu’elle transforme le contexte, la méthode et l’organisation en actifs de production réels.

Le développeur qui s’adapte à cela ne devient pas moins important. Il devient plus stratégique.

Son rôle n’est plus seulement de produire. Il est de garantir qu’un système de production plus puissant reste aligné avec la réalité du besoin, les exigences du projet et la qualité attendue.

C’est pour cela que je parle de développeur-orchestrateur.

Pas comme une formule à la mode. Comme un nom pour désigner le point où se déplace la valeur.

Comme je l’expliquais dans J’ai arrêté BMAD, la méthode n’est pas un accessoire — c’est le socle. Et ce socle, c’est précisément ce que le développeur-orchestrateur construit et maintient.

Conclusion

L’agentique ne signe pas la fin du développeur. Elle déplace le centre de gravité du métier.

Ce qui perd un peu de rareté, c’est une partie de la production brute.
Ce qui gagne fortement en valeur, c’est la capacité à cadrer, orchestrer et arbitrer.

Cadrer, pour créer un espace de travail clair.
Orchestrer, pour structurer une chaîne de production fiable.
Arbitrer, pour garder la qualité, la cohérence et la responsabilité là où elles doivent rester.

Le développeur qui comptera demain ne sera pas seulement celui qui sait écrire du code. Ce sera celui qui saura organiser intelligemment un système de production enrichi par des agents, sans jamais renoncer à son jugement.

C’est précisément pour cela que je pense que le vrai métier qui monte n’est pas celui d’un développeur remplacé, mais celui d’un développeur-orchestrateur.

Fin de 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

*Nicolas Dabène — Architecte de la transition AI-native du e-commerce & créateur de solutions IA pour PrestaShop. Réservez un appel strategy pour explorer comment l’IA peut transformer votre activité.