L'orchestration d'agents, c'est du project management
La compétence la plus importante en développement AI-native n'est pas le prompting. C'est la décomposition, le mapping de dépendances et l'intégration — exactement ce qui distinguait les grands engineering managers des médiocres depuis trente ans.
La compétence la plus importante en développement AI-native n'est pas le prompting. C'est la même compétence qui distinguait les grands engineering managers des médiocres depuis trente ans : la capacité à décomposer un travail ambigu en unités parallélisables, bien délimitées, avec des critères de succès clairs.
Ça contredit tout ce que l'industrie te raconte sur les compétences en IA. Le discours ambiant est dominé par les cours de prompt engineering, les threads « développeur 10x » et l'idée que le goulot d'étranglement serait dans ta façon de parler au modèle. Mais quiconque a réellement orchestré plusieurs agents IA sur une codebase partagée découvre autre chose. Le plus dur, ce n'est pas la conversation avec l'agent. Le plus dur, c'est tout ce qui se passe avant et après.
Le goulot d'étranglement s'est déplacé
Le développement logiciel a toujours eu deux couches : la planification et l'exécution. Historiquement, l'exécution absorbait l'essentiel du coût et du risque. Un cahier des charges médiocre avec un ingénieur brillant pouvait quand même produire du bon logiciel. Un cahier des charges brillant avec un ingénieur médiocre ne produisait presque jamais rien.
Les agents IA sont en train d'inverser ça. Le coût d'exécution s'effondre. Un seul orchestrateur peut désormais lancer des dizaines d'agents qui développent des features en parallèle — chacun avec son propre contexte, son propre périmètre isolé, chacun produisant du code fonctionnel en quelques minutes. Sur des tâches bien délimitées avec suffisamment de contexte, la qualité du résultat approche ce qu'on attendrait d'un ingénieur mid-level compétent — pas systématiquement, mais assez souvent pour changer l'économie de la production logicielle.
Quand l'exécution est quasi gratuite, toute la valeur bascule vers la couche de planification. Décomposition. Mapping de dépendances. Préparation du contexte. Définition des interfaces. Stratégie d'intégration. Le travail autour du travail devient le travail.
Ça renverse tout, et la plupart des organisations ne l'ont pas encore intériorisé.
La décomposition est LA compétence
L'approche naïve de l'orchestration d'agents consiste à ouvrir une seule session, coller une codebase entière et dire « construis tout ça. » Ça échoue pour exactement la même raison qu'on ne peut pas donner à un seul ingénieur un cahier des charges de trente pages et dire « fais tout ça pour vendredi. » Le périmètre est trop large. Les dépendances ne sont pas claires. Le contexte est écrasant.
Une orchestration efficace nécessite la décomposition — identifier quelles features sont indépendantes, lesquelles partagent des surfaces (navigation, design tokens, schémas de base de données), et lesquelles ont des dépendances de séquencement stricts. Un tracker d'options n'a pas besoin de connaître une interface de chat. Un système de monitoring de heartbeat n'a aucune dépendance avec l'UI des cron jobs. Tout ça peut tourner en parallèle. Mais tous touchent la navigation latérale et le composant de layout partagé. Ces points d'intégration doivent être spécifiés en amont.
La qualité de cette décomposition détermine tout en aval. Bien exécutée, un essaim d'agents parallèles peut construire une application complète en quelques heures avec un minimum de conflits. Je l'ai fait — vingt-cinq agents construisant un dashboard de quarante-sept pages en une seule journée, avec une compilation propre dès le premier build intégré. Mal exécutée, tu passes plus de temps à corriger les problèmes d'intégration que tu n'en as économisé en parallélisant.
Ce n'est pas une compétence nouvelle. C'est la même compétence que tout bon engineering manager exerce pendant la planification de sprint, que tout tech lead exerce pendant la revue d'architecture, que tout ingénieur senior exerce en découpant une grosse PR en morceaux revuables. Le medium a changé. Le travail cognitif, non.
Raisonnement first principles plutôt que pattern matching
L'écart de qualité dans la décomposition se résume au mode de raisonnement. La plupart des développeurs découpent les projets par analogie — « ça ressemble à un dashboard, donc on le structure comme le dernier dashboard. » Ils vont chercher des templates, des boilerplates, des implémentations précédentes. Ça marche quand le problème est familier. Ça échoue précisément quand l'orchestration d'agents est la plus précieuse : sur du travail nouveau, transversal, ambigu.
La décomposition par first principles pose des questions différentes. Pas « à quoi ça ressemble ? » mais « quelles sont les vraies dépendances de données ? Où sont les véritables surfaces d'intégration ? Qu'est-ce qui peut être vérifié indépendamment ? » Un cahier des charges par pattern matching dit « construis un widget de suivi d'options. » Un cahier des charges first principles dit « ce composant lit depuis /api/options, affiche un tableau avec des colonnes triables, partage le type greeksMap avec la page portfolio, et ne doit rien importer directement du module dashboard. »
La différence dans la sortie de l'agent est mesurable. Les prompts par pattern matching produisent du code qui fonctionne en isolation et casse à l'intégration. Les prompts first principles produisent du code qui se merge proprement parce que les interfaces ont été définies à partir des contraintes, pas des suppositions.
Ça s'étend au-delà des tâches individuelles. L'architecture entière d'un build parallèle — quels agents partagent un schéma de base de données, lesquels touchent des composants UI partagés, lesquels peuvent être totalement isolés — est un problème de first principles. On ne le résout pas en copiant la structure du dernier projet. On le résout en cartographiant le graphe de dépendances réel de ce système spécifique et en trouvant les véritables frontières de parallélisation.
Les ingénieurs et managers qui raisonnent par défaut en first principles ont un avantage structurel en orchestration d'agents. Tous les autres livrent des intégrations cassées.
Les context windows sont des docs d'onboarding
Il y a une dynamique bien connue dans les équipes d'ingénierie : la production d'une nouvelle recrue pendant son premier mois est largement déterminée par la qualité de son onboarding. Des diagrammes d'architecture clairs, des environnements de dev fonctionnels et des cartographies de quel fichier fait quoi produisent des contributions significatives dès la deuxième semaine. Des pages Confluence périmées produisent trois semaines de fausses hypothèses.
Les agents fonctionnent de manière identique. Plus chaque agent reçoit de contexte — chemins de fichiers, signatures de types, patterns de composants existants, tokens du design system — moins il hallucine. Les agents avec des prompts minimalistes produisent du code qui fonctionne mais ne s'intègre pas. Ils inventent leur propre palette de couleurs. Ils créent des endpoints API qui existent déjà. Ils structurent des fichiers de manière cohérente en interne mais globalement incompatible.
Ça correspond précisément au concept d'engineering management de « localement correct, globalement faux. » Un ingénieur travaillant sans contexte ne produit pas du mauvais code — il produit du code qui paraît bien en isolation et qui se disloque aux jointures. La solution a toujours été la même : investir dans le contexte en amont pour éviter le retravail en aval.
Le compromis est explicite et mesurable. Un prompt d'une page avec les chemins de fichiers exacts, les signatures de types, les références de composants et les étapes de vérification de build produit du code qui se merge proprement. Un prompt de deux phrases produit du code qui nécessite une revue et un refactoring extensifs. Le temps que tu investis dans la spécification est le temps que tu économises à l'intégration. C'est le compromis spec-vs-revue que chaque organisation d'ingénierie navigue depuis que la première équipe logicielle a livré un produit.
L'intégration est là où tout casse
Voici un pattern que reconnaîtra quiconque a géré des feature branches parallèles : chaque agent individuel réussit, et le résultat combiné est cassé.
Des conflits CSS de deux agents stylisant le même composant différemment. Des migrations de base de données en double de trois agents ajoutant des colonnes à la même table. Des erreurs d'hydratation dues à des hypothèses conflictuelles sur les composants de layout partagés. La sortie de chaque agent compile, passe ses propres vérifications et fait exactement ce qui lui a été demandé. Les échecs sont tous aux jointures.
Fred Brooks l'a observé en 1975 : la surcharge de communication croît de manière non linéaire avec la taille de l'équipe. Les agents n'ont pas de surcharge de communication — mais ils ont quelque chose de pire. Ils n'ont absolument aucune conscience les uns des autres. Chacun construit sa section du pont avec une confiance totale, et les sections ne se rejoignent pas au milieu.
C'est, en tout point significatif, le même travail que revoir et merger des PR d'une équipe d'ingénieurs travaillant sur des branches parallèles. Les contributions individuelles sont bien. L'intégration requiert quelque chose qu'aucun agent individuel ne possède : un modèle mental du système complet.
Le travail d'intégration est là où la compétence d'orchestration est la plus visible. Il nécessite la capacité à garder l'architecture complète en mémoire de travail, repérer les conflits qui traversent plusieurs composants et prendre des décisions sur quelle approche standardiser quand deux agents ont pris des chemins différents. C'est du travail d'ingénieur senior — le genre qui nécessite un contexte accumulé sur le système, pas une capacité brute de codage.
La prime à la planification
L'implication est significative : à mesure que les agents IA banalisent l'exécution, la prime sur les compétences de planification augmente proportionnellement.
Les contributeurs individuels les mieux payés en logiciel ont traditionnellement été des spécialistes de l'exécution — ingénieurs systèmes, experts en performance, des gens capables de tenir un module complexe entier dans leur tête. Ces compétences comptent toujours. Mais le levier bascule vers les personnes capables de prendre de grands projets ambigus et de les découper en unités parallélisables propres avec des interfaces bien définies.
C'est le jeu de compétences associé à l'engineering management et au technical program leadership. Les personnes déjà bonnes en décomposition, spécification, mapping de dépendances et intégration ont une longueur d'avance significative en orchestration d'agents — même si elles n'ont jamais écrit un prompt de leur vie.
Considère la boucle complète d'une orchestration d'agents efficace :
- Évaluer le périmètre
- Identifier les frontières naturelles entre les features
- Déterminer ce qui se parallélise et ce qui a des dépendances
- Rédiger des spécifications détaillées avec assez de contexte pour éviter les hypothèses erronées
- Définir les critères de succès pour chaque unité
- Exécuter en parallèle
- Surveiller la progression
- Revoir les résultats
- Gérer l'intégration
- QA du résultat combiné
Ce n'est pas une description de « prompting IA. » C'est une description de gestion de sprint. Le medium a changé — des agents au lieu de personnes, des prompts au lieu de tickets, des minutes au lieu de semaines — mais le travail cognitif est identique.
Le paradoxe de l'expertise
Il y a une question plus profonde qui mérite d'être examinée. Si la valeur se déplace entièrement vers la décomposition et l'intégration, qu'advient-il de la façon dont on développe cette compétence ?
La capacité à bien décomposer des projets se construit typiquement en les exécutant d'abord. On apprend où les jointures d'intégration cassent parce qu'on a été celui qui écrivait le code qui cassait à ces jointures. On apprend ce qui fait un bon cahier des charges parce qu'on en a souffert des mauvais. On développe une intuition architecturale en vivant à l'intérieur des systèmes assez longtemps pour comprendre leurs points de pression.
Si l'exécution est abstraite — si la prochaine génération de tech leads ne passe jamais d'années à écrire le code eux-mêmes — d'où vient leur intuition de décomposition ? Peut-on apprendre à être un grand orchestrateur sans avoir d'abord été un praticien ?
Cette question n'a pas encore de réponse. Mais elle a des parallèles historiques. L'industrie manufacturière a traversé la même transition — les meilleurs directeurs d'usine comprenaient l'atelier parce qu'ils y avaient travaillé. Le cinéma suit le même schéma : les meilleurs réalisateurs ont presque toujours commencé comme monteurs, directeurs de la photographie ou acteurs. Les chefs d'orchestre sont presque toujours d'abord des instrumentistes accomplis. Le schéma est constant : la maîtrise de l'orchestration naît de la maîtrise de l'exécution.
Les couches d'abstraction créent du levier. Elles créent aussi de la distance avec la matière. Les organisations qui navigueront bien cette transition seront celles qui construisent des parcours délibérés de l'exécution vers l'orchestration — pas celles qui supposent que la compétence d'orchestration peut être enseignée de manière isolée.
L'implication inconfortable
Ça crée un problème dont personne dans l'industrie des compétences IA ne veut parler.
Si la compétence à plus fort levier en développement AI-native est la décomposition — et que la décomposition se construit à travers des années d'expérience d'exécution — alors le chemin pour devenir un grand orchestrateur passe toujours par le travail que tout le monde suppose que l'IA va éliminer. On ne peut pas sauter les répétitions. La couche d'abstraction ne remplace pas l'intuition qu'elle requiert.
Le vivier de talents pour l'orchestration d'agents n'est pas dans les bootcamps IA ou les cours de prompt engineering. Il est dans tes organisations d'ingénierie existantes — tech leads, architectes seniors, engineering managers qui ont passé des années à apprendre exactement où les systèmes cassent quand ils sont construits en parallèle. Ils n'ont pas besoin d'apprendre une nouvelle compétence. Ils ont besoin d'appliquer une compétence ancienne à un nouveau medium. Forme-les aux outils. Le jugement, lui, se transfère.
Le titre de « prompt engineer » a toujours semblé provisoire. Ce que l'orchestration d'agents exige réellement ressemble bien davantage à du technical program management — cadrage, décomposition, mapping de dépendances, intégration, assurance qualité — avec une couche d'exécution radicalement plus rapide en dessous.
Le rôle n'est pas nouveau. Les outils le sont. La compétence a toujours eu de la valeur. C'est le levier qui a changé.