Devenir PM à l'ère de l'IA 09 | D'exécutant à orchestrateur : votre nouveau métier, c'est diriger une flotte d'agents

Regardons d’abord comment travaillent aujourd’hui les gens les plus efficaces.

Ils lancent plusieurs agents à la fois — chacun avec sa propre fenêtre de contexte, sa propre part du travail, son propre périmètre de fichiers, tournant en asynchrone ; et eux, au-dessus, découpent le travail, le répartissent, reviennent de temps en temps réceptionner. Ils ne fixent plus un seul agent qui modifie le code phrase par phrase en temps réel. Addy Osmani distingue très nettement ces deux façons de faire : dans la première, vous êtes un chef d’orchestre, vous menez un seul agent en direct et votre cerveau est le plafond ; dans la seconde, vous êtes un orchestrateur, vous avez une flotte d’agents en main, vous planifiez, répartissez, revenez vérifier à intervalles réguliers, et la production n’est plus bridée par votre seule bande passante.

C’est une bonne nouvelle pour les product managers. Parce que « l’orchestration », c’est précisément le vieux métier du product manager — découper un grand objectif en tâches, les confier à des personnes différentes, surveiller les frontières de chaque bloc, puis réceptionner et assembler. Sauf qu’avant, vous orchestriez des humains, et maintenant vous avez en plus une flotte d’agents. La part mécanique de la coordination (relancer sur l’avancement, répéter le besoin, aligner le format) est reprise par les agents, et le jugement d’orchestration, lui, reste — et vaut désormais plus cher. Voici quatre gestes concrets à appliquer.

1. Ne suivez plus un seul agent du début à la fin

Le gaspillage le plus courant, c’est de traiter l’IA comme un stagiaire que vous devez surveiller en permanence : vous envoyez une phrase, vous attendez qu’elle finisse, vous jetez un œil, puis vous envoyez la suivante. Votre attention devient son plafond, et vous ne pouvez faire avancer qu’une seule chose à la fois.

L’orchestrateur fait l’inverse : si une tâche se découpe en trois blocs indépendants les uns des autres, il ouvre trois agents en même temps, donne un bloc à chacun et les laisse tourner en parallèle. Vous passez de « accompagner un agent en direct » à « réceptionner trois agents de temps en temps ». Cela déroute au début, parce qu’il faut lâcher l’obsession du « il faut que je regarde chaque étape » — mais c’est exactement là que la production se multiplie.

2. Découpez le travail en blocs parallèles aux frontières qui ne se chevauchent pas

Le premier savoir-faire de l’orchestration, c’est le découpage. La qualité de ce découpage décide directement si cette flotte d’agents vous aide ou vous complique la vie.

Un bloc que l’on peut confier en parallèle doit remplir deux conditions : être indépendant des autres (A n’a pas à attendre le résultat de B) et avoir des frontières qui ne se chevauchent pas (deux agents ne toucheront pas à la même chose en même temps et ne se marcheront pas dessus). Par exemple, pour une fonctionnalité, vous pouvez découper en « l’API back-end », « la page front-end » et « les tests de ce bloc » et confier ces trois blocs à trois agents ; mais « d’abord concevoir la base de données, puis écrire l’API qui en dépend » ne peut pas se faire en parallèle, il faut enchaîner en série. Avant de découper, posez-vous la question : ces deux blocs peuvent-ils être menés à terme chacun de son côté ? Si non, ne forcez pas le parallèle.

3. Pour chaque bloc, donnez un spec clair

C’est le maillon le plus critique de l’orchestration, et la version amplifiée de ce dont parlait le cinquième article. Addy Osmani le dit sans détour : une instruction floue est amplifiée en une flotte entière d’agents qui se trompent ; une instruction précise est amplifiée en une flotte entière d’implémentations justes.

Quand vous menez un seul agent, si l’instruction est vague et qu’il se trompe, vous corrigez sur le champ. Quand vous en lancez cinq à la fois, chacun tenant la même phrase vague, cela fait cinq dérapages, et au moment de réceptionner, les cinq sont à refaire. Alors, avant de répartir, appliquez la méthode du cinquième article — remplacer les adjectifs par des chiffres, écrire tous les états, lister clairement les frontières et le « ce qu’on ne fait pas » — puis envoyez chaque bloc un à un. Plus vous répartissez, plus la précision du spec est amplifiée de façon multiplicatrice, vers la bonne ou la mauvaise direction.

4. Votre travail devient : découper, réceptionner et relier

Une fois que les agents ont pris en charge « le fabriquer », il vous reste en main trois choses plus lourdes : au début, bien découper le travail ; au milieu, donner des frontières claires ; à la fin, récupérer les blocs, les réceptionner et les assembler en un tout.

L’erreur la plus facile à commettre ici, c’est de démanger et de descendre soi-même faire ce qu’un agent aurait très bien pu faire — dès que vous vous enfoncez dans les détails d’implémentation d’un bloc, toute l’orchestration s’arrête. L’orchestrateur doit rester « au-dessus » : surveiller si chaque bloc rendu est juste (avec la méthode du huitième article, faites-le d’abord exposer sa démarche, puis vérifiez), et les assembler pour voir si l’ensemble tient debout. Votre valeur ne se mesure pas au bloc que vous avez écrit de vos mains, mais au fait que ce que cette flotte d’agents rend, une fois assemblé, tienne ou non.

Une chose à faire dès aujourd’hui : choisissez une tâche que vous vous apprêtez justement à faire et qui peut être découpée, essayez de la couper en deux ou trois blocs indépendants les uns des autres, ouvrez un agent pour chacun, et ne faites que trois choses — découper, donner le spec, réceptionner. Éprouvez une première fois la différence entre « faire avancer trois choses en même temps » et « les enchaîner une par une ».

Pour aller plus loin

• Addy Osmani, « The future of agentic coding: conductors to orchestrators » (chef d’orchestre vs orchestrateur, l’amplification multiplicatrice d’un spec précis) : https://addyosmani.com/blog/future-agentic-coding/
• Le cinquième article de cette série, « Quand le besoin est mal formulé, l’IA comble les trous n’importe comment » (la précision du spec) : /fr/blog/say-it-clearly/
• Le huitième article de cette série, « L’IA ne peut pas trouver le vrai problème à votre place » (faites-le exposer sa démarche avant de réceptionner) : /fr/blog/find-the-real-problem/