> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md).

# W33-Cinq paliers vers le travail de demain, vus à travers les équipes d’agents

Boris Cherny, responsable de Claude Code, a récemment publié un tableau intitulé [Steps of AI Adoption](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit).

Dans son [message d’origine](https://x.com/bcherny/status/2077929379661844559), il évoque un phénomène récurrent. Une personne d’une équipe multiplie sa production par un ordre de grandeur grâce à Claude, tandis que le reste de l’organisation ne suit pas.

Cette observation rejoint mon expérience récente. Les écarts créés par l’IA ne tiennent plus seulement à la maîtrise des outils. Les gens adoptent des façons de travailler radicalement différentes.

Boris distingue cinq niveaux d’adoption de l’IA, de L0 à L4. Plus précisément, il s’agit de cinq états et de quatre transitions. Je préfère y voir cinq paliers vers le travail de demain.

## Les cinq paliers

| Niveau                  | Rôle humain                 | Mode de travail                                                                                       | Principal frein                   |
| ----------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------- |
| L0 Contraint            | Observateur                 | On veut utiliser l’IA, mais les modèles réellement capables restent exclus du travail                 | Accès                             |
| L1 Assistance           | Partenaire                  | On travaille avec un agent ; il exécute, on vérifie chaque étape                                      | Attention humaine                 |
| L2 Parallélisme         | Orchestrateur               | On organise plusieurs agents ; ils exécutent et se vérifient, on valide les résultats                 | Capacité de revue                 |
| L3 Autonomie supervisée | Responsable de responsables | Des tâches planifiées ou des événements déclenchent le travail ; l’humain approuve les exceptions     | Confiance et capacité de décision |
| L4 Natif IA             | Définisseur d’intention     | Des centaines ou des milliers d’agents travaillent selon des objectifs ; l’humain gère les exceptions | Jugement de valeur et gouvernance |

Dans le tableau de Boris, le nombre d’agents passe de 0 à 1, puis 10, 100 et plus de 1 000. Ces nombres indiquent des ordres de grandeur, pas des critères de passage au niveau suivant. Le changement essentiel concerne le rôle de l’humain.

En L1, l’humain reste aux commandes de chaque tâche. L’agent ressemble à un assistant très rapide.

En L2, l’humain commence à concevoir la répartition du travail, à contrôler le contexte et à définir les critères de validation. Plusieurs agents avancent en parallèle, tandis que l’attention humaine porte surtout sur les résultats et les exceptions.

L3 franchit un pas de plus. Les tâches ne sont plus toutes lancées une par une par une personne. Le système surveille les événements, exécute des programmes, détecte des problèmes et crée lui-même du travail. L’humain ne gère plus chaque agent, mais le système de travail qu’ils constituent.

## Plusieurs agents ne forment pas nécessairement une équipe

Nous nous sommes longtemps demandé comment rendre un agent plus puissant et lui confier des tâches plus longues et plus complexes. Mais les capacités d’un agent isolé ont des limites. De plus en plus de personnes en utilisent donc plusieurs à la fois.

Leur multiplication fait apparaître de nouveaux problèmes. La capacité individuelle n’est plus le seul facteur limitant. L’organisation commence à déterminer le plafond de l’ensemble.

Si chaque tâche exige encore qu’une personne choisisse le point d’entrée, rassemble les informations, transporte le contexte, puis transmette le résultat d’un agent au suivant, ces agents restent au fond des outils indépendants. L’humain demeure l’unique routeur de tout le système et, de fait, son goulot d’étranglement.

Pour moi, une équipe d’agents présente trois caractéristiques.

Premièrement, chaque agent prend durablement en charge son domaine. Il sait ce qu’il doit traiter, où s’arrêtent ses responsabilités et quelles questions ne lui appartiennent pas.

Deuxièmement, une partie de la coordination passe de l’humain aux agents. Dans un cadre de responsabilités explicites, ils assurent l’aiguillage, les transmissions et le retour des résultats, sans demander à une personne de relier toutes les étapes.

Troisièmement, l’humain reste dans l’équipe, mais change de place. Il intervient pour l’orientation, les faits, les choix, la revue et les autorisations, sans suivre toute l’exécution.

Mais dès que l’humain cesse de participer à chaque étape, une autre question apparaît. Comment savoir si cette équipe fonctionne bien ?

Une équipe d’agents doit donc aussi pouvoir être observée, comprise et ajustée en continu. Sinon, je passe simplement d’une coordination manuelle de chaque agent à une situation où je ne vois plus ce qu’ils font.

## La première fois que j’ai vraiment ressenti une équipe d’agents

Mon expérience la plus marquante du niveau L2 vient de Multica.

J’y ai d’abord créé une Engineering Squad pour construire un MCP relié à la plateforme d’hébergement de code du réseau interne de l’entreprise. Dans la première version, Claude assurait la stratégie, la décomposition et l’aiguillage, Codex l’implémentation, et Gemini l’exploration et la validation indépendante. Je gardais l’intention produit, les priorités, les arbitrages et l’approbation finale.

Cette combinaison m’a donné, pour la première fois, un fort sentiment de travail en équipe. Une fois l’objectif et les limites précisés, le Leader poursuivait la décomposition et choisissait les agents adaptés à l’exploration, à l’implémentation et à la validation. Je recevais une notification uniquement lorsqu’un jugement était nécessaire, puis je revenais dans la tâche pour décider.

Au début d’une tâche, deux documents se contredisaient sur le style d’interface et le mode d’authentification. Le Leader n’a pas immédiatement demandé à Codex de coder. Il a d’abord lancé une exploration technique limitée. Elle devait répondre à quelques questions factuelles, apporter des requêtes réelles comme preuves, et avait interdiction explicite d’implémenter le MCP. Quelques minutes d’exploration ont évité une implémentation entièrement erronée.

La validation ultérieure a aussi révélé la véritable valeur d’une équipe d’agents. Un rapport s’appuyait sur un retour 401 obtenu avec un jeton invalide pour conclure à l’absence d’un mécanisme d’authentification. La conclusion était juste par hasard, mais le raisonnement ne tenait pas. Une autre série de tests passait intégralement, alors que les seules données de test réelles étaient un tableau vide : la structure des champs de données non vides n’avait jamais été vérifiée.

Ces rapports n’étaient pas falsifiés. Ils étaient simplement corrects, mais incomplets. Le Leader devait réexaminer les preuves avec un autre objectif, et l’auteur comme le validateur devaient éviter de partager la même logique d’autoconfirmation.

Cette tâche a fini par établir quelques règles durables. L’exploration limitée précède l’implémentation. L’auteur ne peut être le seul relecteur d’un changement à haut risque. Les preuves doivent préciser ce qu’elles démontrent et ce qu’elles ne démontrent pas. Les actions visibles de l’extérieur, irréversibles ou engageant l’identité d’une personne s’arrêtent pour lui être soumises.

Voilà mon expérience concrète de L2. Une personne commence à disposer d’une équipe de livraison dont le coût de coordination est très faible.

## D’une configuration ponctuelle à un modèle de fonctionnement

J’ai ensuite fait évoluer mon usage de Multica : d’une configuration temporaire à un modèle de fonctionnement maintenable, que j’ai organisé dans un dépôt Git.

L’essentiel consiste à séparer quatre objets.

| Objet              | Responsabilité                                                            | Rythme d’évolution                        |
| ------------------ | ------------------------------------------------------------------------- | ----------------------------------------- |
| Profession Profile | Responsabilités du rôle, limites du jugement, outils et contrat de preuve | Stable, versionnable                      |
| Agent Instance     | Runtime concret, modèle, permissions et concurrence                       | Remplaçable                               |
| Squad              | Mission persistante, règles d’aiguillage et membres                       | Évolue avec les files de travail durables |
| Issue Run          | Objectif, contexte, preuves et risques résiduels d’une tâche              | Différent à chaque tâche                  |

La valeur centrale de cette séparation est de distinguer les contrats stables des déploiements variables.

Les responsabilités doivent rester stables. Le Delivery Lead assure durablement la décomposition, l’aiguillage, l’arbitrage des conflits et la consolidation des preuves. L’Implementation Engineer réalise l’implémentation et les tests. Le Challenger cherche des contre-exemples et effectue des revues en lecture seule. L’Explorer-Validator explore les grands contextes, analyse les impacts et assure une validation indépendante.

Le runtime et le modèle concrets peuvent changer. Aujourd’hui, le Delivery Lead peut fonctionner sur Claude, l’Implementation Engineer sur Codex, le Challenger sur Grok, et l’Explorer-Validator utiliser Gemini via Antigravity. Si les modèles évoluent, on peut remplacer les instances sans réécrire en même temps les rapports de responsabilité de l’équipe.

Cela ne rend pas les modèles interchangeables sans coût. Les permissions, outils, sessions et modes de défaillance de chaque runtime doivent être revalidés. Être remplaçable signifie que le contrat d’organisation n’est pas lié à une marque de modèle ; cela ne dispense pas de valider le déploiement.

## Ma configuration actuelle de Multica

À l’écriture de cet article, je gère huit Agent Instances et quatre Squads persistantes dans Multica.

Les quatre rôles principaux communs aux Squads sont Delivery Lead, Implementation Engineer, Challenger et Explorer-Validator. Product Architect, Market Researcher, Ops Engineer et Data Analyst les complètent pour les tâches de recherche, d’architecture et de fiabilité.

Les quatre Squads correspondent à des files de travail durables.

| Squad                   | Conditions d’entrée                                                                                   | Parcours par défaut                                                                                                                                                          |
| ----------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Engineering             | Fonctionnalités courantes, refactorisations, bugs ordinaires et livraison logicielle                  | Claude aiguille, Codex est seul à écrire, Gemini valide, Grok conteste au besoin                                                                                             |
| Reliability & Incident  | Cause inconnue, problème entre modules, difficile à reproduire ou touchant la fiabilité en production | Collecte de preuves en lecture seule par plusieurs voies, Claude resserre les hypothèses, Codex est seul à corriger, une autre personne que l’auteur vérifie les régressions |
| Research & Architecture | Choix techniques, arbitrages produit, migrations ou explorations limitées                             | Gemini recueille les preuves, Grok attaque les hypothèses, Codex ne mène que des expériences délimitées                                                                      |
| Frontend Experience     | Parcours utilisateur, visuel, adaptation aux écrans, accessibilité et validation dans le navigateur   | Gemini établit la référence, Codex implémente, Gemini valide sur la page réelle                                                                                              |

Les Squads ne sont pas organisées par dépôt, et l’arrivée d’un modèle ne justifie pas d’en créer une. Un nouveau dépôt est simplement une nouvelle ressource Project. Les tâches dont le responsable est déjà connu sont assignées directement à cet agent. Elles n’entrent dans une Squad que si plusieurs compétences sont nécessaires et que le responsable précis ne peut être déterminé à la création de l’Issue.

Cette configuration impose aussi des limites strictes. Chaque tâche n’a qu’un responsable actuel. Chaque Worktree n’a qu’un auteur autorisé à écrire. Les agents qui écrivent ont une concurrence de 1 ; les rôles sans écriture peuvent monter à 2 ; la concurrence totale du daemon local est limitée à 3. La production, les identifiants, la publication, les envois externes et les actions irréversibles nécessitent toujours mon approbation.

## N’activer que les rôles strictement nécessaires

On confond facilement équipe d’agents et utilisation simultanée de tous les modèles. Cela ne fait généralement qu’augmenter le contexte, les tokens et le coût de coordination.

Une Squad Multica est elle-même un simple objet d’aiguillage. Quand une Issue lui est assignée, le système réveille d’abord son Leader. Celui-ci lit le contexte, puis décide à qui confier la suite. Une Squad ne lance pas automatiquement tous ses membres et n’augmente pas la concurrence.

Ma règle par défaut est donc d’activer, à chaque fois, le plus petit ensemble de rôles suffisant pour accomplir la tâche.

Une petite correction bien délimitée peut aller directement à Codex, sans démarrer de Squad. Pour un grand dépôt inconnu ou une tâche d’interface, Gemini commence par établir le périmètre d’impact et la référence de validation, puis passe la main à Codex. Une revue contradictoire de Grok ne s’ajoute que pour les pannes difficiles à reproduire ou les changements à haut risque.

Par défaut, au maximum deux membres d’exécution sont actifs en même temps. Le parallélisme sert uniquement aux investigations indépendantes, aux revues indépendantes d’un même commit stable, ou à des Worktrees dont les périmètres de fichiers ne se recouvrent pas. Faire modifier le même état par plusieurs agents semble accélérer le travail, mais conduit généralement à des conflits et à des reprises.

Le nombre d’agents ne mesure pas la maturité d’une équipe. Savoir activer le bon rôle au bon moment, voilà la capacité d’orchestration.

## La DoD est l’interface entre les agents

La possibilité pour les agents de collaborer directement ne signifie pas qu’il suffit de dire « reprends la suite ».

J’exige que chaque délégation précise quatre éléments.

```
outcome: 最终可观察结果
evidence: 证明结果的测试、命令、截图、数据或链接
verification: 由谁、用什么方式验收
max_rounds: 最多返工轮数，默认 2
```

C’est la Definition of Done. Elle définit le contrat de preuve à satisfaire avant que le résultat puisse être accepté.

L’Implementation Engineer ne livre pas seulement du code. Il doit aussi transmettre le périmètre des changements, le commit, les commandes de test et leurs résultats bruts. Le relecteur indépendant examine l’objectif, le diff et les tests ; il n’accepte pas la déclaration d’achèvement de l’auteur comme preuve. Lors de la clôture, le Leader doit préciser le résultat réel, les points non vérifiés, les risques résiduels et les décisions humaines nécessaires.

`max_rounds` compte tout autant. Les agents peuvent se mentionner mutuellement, mais le système ne peut pas décider à ma place quand leur collaboration doit s’arrêter. Si les preuves se contredisent encore après deux reprises, l’équipe doit interrompre la boucle et soumettre le désaccord à une personne.

Dans Multica, le statut `completed` d’une Task indique seulement que l’exécution de l’agent s’est terminée normalement, pas que l’objectif de l’Issue est atteint. Ce sont la DoD et les preuves qui déterminent si la tâche peut réellement passer en revue. Cette distinction sépare l’état d’exécution de l’agent de l’état d’achèvement du travail.

## Une équipe d’agents a aussi besoin d’ingénierie de configuration

Un prompt de rôle, aussi bien écrit soit-il, ne prouve pas que l’équipe fonctionnera dans l’environnement réel.

J’ai fait du dépôt Git la source de vérité de la configuration. `config/agents/` conserve les contrats des rôles, `config/squad-*.md` les règles d’aiguillage, et `config/topology.json` la topologie des agents, runtimes, permissions, limites de concurrence et Squads. Les objets en ligne de Multica ne sont qu’une copie en exécution de cette déclaration.

Par défaut, le synchroniseur produit seulement un plan de changements. Il est appliqué après examen humain, puis exécuté à nouveau : le résultat doit être `No changes.`. Les objets non gérés sont signalés, jamais supprimés automatiquement. Les Workspace IDs, Agent IDs, tokens, webhooks et chemins locaux restent hors du dépôt.

Ce mécanisme traite la dérive de configuration. Quand les rôles ou l’aiguillage changent, je peux voir le diff, le relire et réconcilier l’état en ligne avec l’état attendu.

L’intégration réelle m’a aussi montré qu’une équipe d’agents va bien au-delà de quelques prompts. Le Leader doit agir sur le plan de contrôle de Multica sans pouvoir écrire dans les fichiers du projet. Grok doit effectuer des revues en lecture seule sans hériter de capacités réseau et d’écriture trop larges. Les runtimes de bureau dépendent aussi du proxy, du bac à sable, des paramètres de commande et de l’environnement local.

À mesure que ces problèmes apparaissaient, j’ai corrigé la connexion directe au plan de contrôle, les limites du bac à sable et la correspondance des sous-commandes CLI. Une permission inscrite dans un fichier de configuration ne garantit pas la santé du runtime. Chaque rôle essentiel exige de vrais tests de bon fonctionnement, positifs et négatifs.

## Revoir les cinq paliers à travers les équipes d’agents

Vus sous cet angle, les cinq paliers du travail de demain correspondent au transfert progressif vers le système des responsabilités d’aiguillage, de collaboration et de validation.

| Niveau | Organisation des agents                                                                     | Travail principal de l’humain                                                      |
| ------ | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| L0     | Les agents ne peuvent pas accéder au travail réel                                           | Continuer avec les processus existants                                             |
| L1     | Plusieurs outils indépendants ; l’humain est l’unique routeur                               | Fournir le contexte à chaque fois et vérifier chaque résultat                      |
| L2     | Rôles et Squads persistants ; le Leader choisit l’équipe minimale                           | Définir les objectifs et la DoD, valider les preuves, traiter les choix essentiels |
| L3     | Des horaires ou événements déclenchent les équipes d’agents                                 | Gérer les exceptions, permissions, budgets et conditions d’arrêt                   |
| L4     | Plusieurs équipes travaillent selon l’intention ; leur structure peut évoluer dynamiquement | Fixer l’orientation, les valeurs et les limites qui ne peuvent être déléguées      |

Je me situe actuellement entre L2 et L3. Ma configuration Multica traite les rôles, l’aiguillage, les preuves et l’observabilité, mais je crée encore moi-même la plupart des tâches.

Le changement essentiel de L3 concerne le pouvoir de déclenchement. Les [Autopilots](https://multica.ai/docs/autopilots) de Multica peuvent créer automatiquement des Issues à partir de tâches périodiques ou d’événements webhook, puis les confier à un agent ou à une Squad. Dans [« Le Mac d’un Builder a aussi besoin d’un Sweeper »](https://weekly-essay.mikey.wang/fr/2026/w32-a-builders-mac-also-needs-a-sweeper), j’ai décrit des routines qui entretiennent les Skills chaque jour et vérifient l’environnement du Mac chaque semaine. Ce type de travail se rapproche de L3.

Mais le pouvoir de déclenchement ne doit pas devancer la capacité de vérification. Sans DoD, preuves, permissions, conditions d’arrêt et traces observables, réveiller automatiquement davantage d’agents ne fait que provoquer les erreurs plus tôt et les rendre plus difficiles à détecter.

L’équipe dans son ensemble reste surtout en L1, et la plupart des personnes passent de L1 à L2. Chacun sait déjà utiliser un agent. L’étape suivante consiste à faire des rôles, de l’aiguillage, de la validation et des permissions un système de travail commun.