Interprétation du nouveau travail d'Anthropic : comment construire une équipe de collaboration homme-AI efficace

Le 24 juin, le blog officiel d'Anthropic a publié un nouvel article intitulé « Building effective human-agent teams », rédigé par Kristen Swanson.

L'idée centrale de l'article est que le paradigme de la collaboration au niveau de l'équipe IA est en train de changer, passant d'« une personne face à une boîte de dialogue (même si plusieurs agents se cachent derrière) » à « un groupe de personnes et un groupe d'agents partageant le même espace de travail ».

Cet article va, en reprenant les idées clés de l'article original, offrir une synthèse et une réflexion globale basées sur l'expérience pratique de l'IA agent.

I. Thème principal : les équipes collaboratives IA deviennent un « mode en ligne »

Autrefois, l'utilisation de l'IA était une expérience « solo (single-player) » – un individu collaborait avec un agent pour accomplir une tâche personnelle.

Aujourd'hui, un nouveau modèle émerge : humains et agents peuvent collaborer dans le même espace de travail, au service d'un objectif partagé par l'équipe.

Le travail commence à ressembler davantage à un « jeu multijoueur (multiplayer game) » : l'équipe humaine élabore la stratégie, et Claude exécute.

En bref, il s'agit de partager les objectifs, partager le contexte, et surtout partager l'espace de travail.

Comme le montre la figure ci-dessous, une transition vers le modèle de travail complexe de droite est en cours :

Ce qui rend cette transition possible, c'est le nouveau produit d'Anthropic, Claude Tag, une forme qui permet à Claude d'intégrer des outils de collaboration d'équipe comme Slack, d'être mentionné par @ et d'être assigné comme un membre de l'équipe.

Cet article n'est donc pas une pure théorie, mais une direction que le produit même d'Anthropic pousse.

II. Qu'est-ce que le problème de la collaboration « multi-agents » ?

L'article original définit les « multiplayer agents » comme : des modèles d'IA qui collaborent simultanément avec de nombreux humains différents.

Ils ont des points communs avec les agents ordinaires, mais aussi des différences clés :

• Similitudes : ils ont leur propre mémoire et compétences (skills).

• Différences : ils ont leurs propres identifiants (credentials),

et « living where work happens » – ils vivent là où le travail se déroule réellement.

Chez Anthropic, cet endroit est un outil de collaboration d'équipe comme Slack.

Cette configuration – « avoir ses propres identifiants, vivre dans les canaux de l'équipe » – est très importante.

Cela signifie que l'agent n'utilise plus le compte d'une personne pour travailler dans une session privée, mais devient une entité d'équipe dotée d'une identité indépendante : il est visible par toute l'équipe, ses résultats sont visibles pour tous, le contexte qu'il lit est au niveau de l'équipe et non individuel. Comme le montre la figure ci-dessous, il devient un membre de votre logiciel de bureau.

Pour que l'agent puisse « participer efficacement » dans les canaux d'équipe, un ensemble de capacités sous-jacentes spécifiques (comme le produit Claude Tag) + une mémoire persistante spécialement conçue, une identité exclusive, des sources d'information, etc., sont nécessaires.

En outre, les compétences techniques ne suffisent pas : pour qu'une équipe homme-machine « réussisse », il faut un ensemble de méthodes de travail et de normes partagées.

C'est pourquoi les quatre dernières expériences de l'article portent toutes sur la conception de « normes » pour les équipes d'IA.

III. Quatre leçons sur les équipes d'agents IA

Leçon 1 : Réformer la gestion de l'information, donner à l'agent le contexte le plus large possible

Anthropic pense qu'il ne faut pas décider document par document, canal par canal, quelles informations doivent être visibles par l'agent, mais utiliser des limites de sécurité (security boundaries) clairement définies, appliquées de manière uniforme à l'ensemble de l'espace de travail Slack, aux transcriptions de réunions, aux bibliothèques de documents.

L'article original mentionne explicitement cette corvée quotidienne : « Ce canal doit-il être public ou privé ? Ce document peut-il être partagé avec cette personne ? Cet agent peut-il voir ce message ? »

Dans les limites fixées, le contexte doit être visible pour chaque membre de l'équipe – qu'il soit humain ou IA –, et l'IA peut même, comme un humain, demander l'accès à des documents.

L'élégance de cette approche réside dans le fait qu'elle résout deux problèmes à la fois :

1. Élargir le contexte accessible à l'agent et à l'humain ;
2. Éliminer la fatigue décisionnelle due au « partage élément par élément » .

Le bénéfice de l'ouverture des droits est tangible : il n'y a plus de perte d'informations par transmission, et comme l'agent lit les textes bien plus rapidement qu'un humain, il peut « routinely surface relevant work that humans would otherwise have missed » (mettre en évidence régulièrement des travaux pertinents que les humains auraient autrement manqués).

À mon avis , il s'agit essentiellement d'un changement de culture organisationnelle et de mécanisme de droits.

Le « par défaut interne ouvert » est pour de nombreuses entreprises un changement culturel profond à opérer.

Parce qu'Anthropic est dès le départ une entreprise hautement confiante et à l'information plate, elle ne comprend pas vraiment la maladie des grandes entreprises, surtout dans les secteurs traditionnels où le fossé d'information entre les niveaux hiérarchiques crée des écarts de ressources.

De plus, pour les organisations soumises à des exigences strictes de conformité et de cloisonnement de l'information (finance, santé, juridiction multiple), l'« application uniforme au niveau de l'espace de travail » n'est pas toujours possible.

Ce qui est réellement applicable, c'est le mécanisme d'approbation simplifié qui le sous-tend. Par exemple, si un agent est dans un groupe, il peut naturellement lire les documents auxquels ce groupe a accès. Même avec une gestion des droits, on peut gérer en masse de manière naturelle, plutôt que de devoir d'abord attribuer les documents, puis organiser la qualité.

Leçon 2 : Chaque personne/agent a un rôle et des outils clairs

L'image dans l'article original est très évocatrice : l'équipe homme-machine partage un organigramme, un ensemble de livrables, un espace de travail.

Au-dessus de cela, les agents ont des spécialisations :

• Un agent détient l'analyse des données d'un projet ;
• Un autre détient et applique les normes de conception ;
• Un troisième est responsable de la synthèse de recherche (research synthesis).

Au lancement du projet, les humains discutent d'abord avec les agents pour décider comment répartir les rôles, comment les humains et les agents collaboreront.

Ensuite, on obtient la combinaison de rôles, règles et moments d'intervention illustrée ci-dessous.

Une fois les rôles clairs, un agent peut même « spin up » (lancer) d'autres agents, garantissant que chaque tâche spécifique est confiée à l'agent disposant de la bonne mémoire et des bons droits d'accès.

La clé est de fournir les bons outils : l'agent d'analyse de données peut avoir besoin d'accès à BigQuery, l'agent de QA peut avoir besoin de Playwright MCP.

Les humains conservent les rôles que seuls les humains peuvent occuper, garantissant que le jugement humain est utilisé pour les décisions les plus importantes.

À mon avis : c'est aussi l'architecture précédemment étudiée par Anthropic pour les mécanismes de flux de travail.

Utiliser un lead agent pour coordonner l'ensemble et déléguer les tâches à des subagants spécialisés fonctionnant en parallèle. Ce type de mécanisme est effectivement très pratique, la qualité étant presque doublée (90,2 % de plus), bien que le coût en tokens augmente de 15 fois. Cependant, « plus d'agents = plus fort » n'est pas une conclusion universelle, mais plutôt « pour certains types de tâches, une amélioration obtenue au prix d'une puissance de calcul considérable ».

Cela est particulièrement vrai pour les tâches prioritaires en largeur et parallélisables, et grâce à un mécanisme de validation croisée plus fort, la précision des informations est meilleure.

Il faut également une conception minutieuse, avec une bonne décomposition des tâches et une isolation des rôles, plutôt que de simplement « empiler plus d'agents ».

Sinon, ce serait une nouvelle génération de malentendu du style « 18 000 jin par mu ».

Beaucoup de ces points étaient également présents dans l'article précédent sur la façon d'utiliser les Dynamic Workflows de Claude pour une recherche approfondie.

Leçon 3 : Définir un rôle d'étoile polaire, laisser l'agent résoudre les problèmes de manière proactive

L'article original distingue deux types d'agents : ceux qui se contentent de « terminer les tâches assignées », et les plus importants, qui proposent de nouveaux projets et de nouveaux flux de travail.

Ces derniers apparaissent généralement dans une équipe qui possède déjà un contexte riche et des rôles clairs, avec en plus une directive supplémentaire – l'étoile polaire (north star) .

L'étoile polaire est chargée d'aider l'équipe à déterminer « quelles tâches et quels flux de travail sont les bons » .

L'article original insiste sur plusieurs disciplines :

• L'étoile polaire est toujours définie par l'humain, et ancrée dans la mission et les objectifs commerciaux de l'entreprise ;

• Une fois l'étoile polaire clairement écrite, l'humain la partage avec les agents de l'équipe ;

• Ensuite – et c'est crucial – l'humain choisit quels agents doivent proposer activement de nouveaux flux de travail.

Supposez une entreprise et un produit pilotés par les opérations : c'est le rôle opérationnel qui doit devenir l'agent dominant, plutôt que le produit, la technologie ou la finance.

Comme le modèle « Classify-And-Act » (Router) dans l'article sur l'utilisation des Dynamic Workflows de Claude pour une recherche approfondie, un agent identifie d'abord le type de tâche, puis la distribue à l'agent spécialisé le plus approprié.

À mon avis, dans de nombreux articles d'Anthropic, on voit leur vision de ce qu'est un agent et ce qu'est un workflow.

Le premier « pilote dynamiquement son propre processus et ses outils, contrôlant comment accomplir la tâche ».

Le second est un système déterministe « orchestré via des chemins de code prédéfinis ».

Donc, pour créer une équipe IA, il faut donner à l'agent une étoile polaire plutôt qu'une liste de tâches, ce qui pousse consciemment le système du workflow vers l'agent.

Une équipe avec un objectif (Team) apportera une certaine créativité, plutôt que de chercher des problèmes à résoudre dans un cadre limité.

Bien sûr, la plupart des équipes IA que nous créons actuellement sont des workflows programmés ou IAisés, ce qui résout déjà de nombreux problèmes. Si nous avons besoin à l'avenir de créativité, d'auto-motivation et de capacité proactive à résoudre des problèmes, alors il est nécessaire de concevoir une telle équipe de type agent.

Leçon 4 : Laisser l'agent grandir avec le temps

Les données officielles ici m'ont beaucoup surpris : les ingénieurs d'Anthropic ont réussi à faire en sorte que les agents de l'équipe traitent indépendamment 500 corrections de bugs – mais ils précisent immédiatement : « things certainly didn't start off that way (ce n'était certainement pas le cas au début). »

Ils comparent l'agent à un nouveau collègue humain : il faut plusieurs cycles de feedback pour externaliser la connaissance tacite du type « quelle est la meilleure façon d'effectuer la tâche ».

L'utilisateur doit tester l'agent à plusieurs reprises avec différentes tâches pour découvrir les limites de ses compétences, comment décrire clairement les objectifs, de quels fichiers de compétences il a besoin, quel prompt suscite le comportement souhaité.

L'article original attire également l'attention sur un point souvent négligé : les modèles étant mis à jour, les tâches doivent être retestées – les prompts peuvent devoir être réécrits, et les barrières (Harness) qui étaient utiles par le passé peuvent au contraire brider un modèle plus intelligent dans sa recherche de solutions créatives.

La partie la plus riche de cette leçon concerne la vérification (verification) :

Nous avons constaté que les meilleurs agents à long terme disposent de nombreuses façons de vérifier leur propre travail avant de le soumettre aux humains.

• Le code a des tests, bien sûr ;
• Mais la plupart des autres travaux peuvent également être vérifiés : la documentation technique peut être évaluée à l'aide de rubriques (rubric) et de guides de style (style guide) ;
• Lorsque les humains définissent des normes et s'assurent que tout le travail confié à l'agent peut être examiné, la qualité se maintient et ne s'écarte pas de l'intention initiale ;
• De plus, on peut faire travailler un agent et faire vérifier par un autre – c'est ce qu'on appelle le « Doer-Verifier » (exécutant – vérificateur) agent harness.

L'article original donne un exemple complet : un responsable technique reprend une nouvelle équipe avec un important backlog. Il rassemble quelques personnes + quelques agents pour prioriser ensemble.

Un groupe d'agents parcourt tous les éléments du backlog, détermine si quelqu'un y travaille déjà, et attribue des scores de complexité aux éléments sans propriétaire ;

Un autre groupe filtre les éléments de complexité faible à moyenne dans la liste et produit directement des modifications de code.

Au début, les humains examinent chaque décision de l'agent et marquent celles qui nécessitent une intervention humaine ; ensuite, les humains « enseignent » à l'agent à renvoyer ce type de décisions directement aux humains, garantissant que les décisions impliquant des compromis difficiles ont toujours un « human in the loop ».

Et chaque semaine, l'équipe demande à l'agent de rédiger un rapport hebdomadaire contenant les « leçons et erreurs (lessons & missteps) », permettant à l'agent de se souvenir des erreurs et d'éviter de les répéter. Au fil du temps, le responsable peut confier à l'agent des modifications de plus en plus complexes, tout en consacrant moins de temps aux conseils quotidiens, comme le montre la figure ci-dessous :

Cela ressemble beaucoup au processus d'élevage d'un homard intelligent.

Le dernier paragraphe est l'aperçu que j'apprécie le plus dans tout l'article – lorsque l'agent devient plus indépendant, le responsable commence à enseigner à l'agent à considérer « l'attention humaine » comme une ressource rare :

Par exemple, regrouper les questions pour permettre à l'humain de répondre en une seule fois, répéter le contexte clé pour que l'humain se mette rapidement dans le bain, limiter le nombre d'éléments confiés à l'humain à la fois.

Certains mettent même en place un agent spécifique dont l'unique mission est de décider comment regrouper les tâches et de ne remonter aux humains que les communications les plus importantes.

D'autres fixent à l'agent une « limite maximale de travail par jour » – afin que l'humain ait le temps de participer de manière significative et de préserver ses compétences importantes de l'inactivité.

À mon avis, ces expériences sont les plus profondes de tout l'article en matière de « relation homme-machine ».

• Premièrement, la pensée d'Anthropic : une supervision efficace ne consiste pas à approuver chaque action, mais à « être en mesure d'intervenir au moment crucial » (being in a position to intervene when it matters).
• Deuxièmement, considérer explicitement « l'attention humaine » comme une ressource rare à optimiser est un principe de conception largement sous-estimé. La plupart des discussions sur les agents se concentrent sur l'optimisation des « capacités des agents », alors que le goulot d'étranglement réel est déjà la « bande passante cognitive humaine ».
• Troisièmement, l'ingénierie du Harness consiste, dans une équipe homme-machine, à simuler complètement le mode de fonctionnement d'une équipe performante. Après tout, certains bons chevaux n'ont effectivement pas besoin de rênes, seulement d'un objectif.

IV. L'ère de la collaboration homme-machine amplifiera sans pitié la qualité organisationnelle de l'équipe d'origine

La phrase la plus honnête et la plus facile à négliger de cet article apparaît à la fin :

Il dit que les quatre expériences ci-dessus ne sont pas vraiment nouvelles ; elles existaient bien avant l'IA. Une bonne équipe a besoin d'une étoile polaire solide, de rôles clairs, d'une documentation solide, de normes de qualité partagées, d'un espace pour apprendre de ses erreurs – ce sont des habitudes d'équipe saines que nous connaissons depuis des décennies.

Les équipes d'agents IA ne font que rendre ces fondamentaux encore plus importants.

Sans un cadre mécanique raisonnable, l'IA ne rendra pas automatiquement une équipe plus forte ; elle peut même créer des tensions et, finalement, du chaos, comme par exemple :

• Une équipe au contexte dispersé (par exemple, qui gère par l'asymétrie d'information) : l'arrivée d'un agent ne fera qu'aggraver la dispersion (plus l'isolement de l'information est grand, plus les résultats s'écartent de la cible) ;
• Une équipe aux rôles mal définis : l'agent ne fera que reproduire la confusion, avec des responsabilités professionnelles qui s'emmêlent et des sources de jugement faussées pour les décideurs.
• Une équipe sans culture de vérification : les erreurs de l'agent se propageront à une vitesse accélérée, la vitesse du code IA dépassant déjà largement celle de la relecture humaine.

Par conséquent, à mon avis, « les équipes qui tireront le meilleur parti de cette vague d'agents sont celles qui sont les plus conscientes de mettre en pratique ces fondamentaux. »

Pour les organisations qui misent sur les agents IA, la véritable leçon de cet article n'est peut-être pas « comment utiliser Claude », mais de revenir en arrière pour refaire sérieusement ces quatre vieilles choses : le contexte, les rôles, les objectifs et les normes de qualité de leur équipe.