Bêta de Claude Code Projects : des équipes d’agents qui planifient et coordonnent le travail en parallèle

Le lien entre les équipes d’agents Claude Code et la bêta de Projects

Le annonce des projets repensés présente un projet organisé autour du travail en cours : un coordinateur dirige les fils, la mémoire partagée transmet le contexte entre eux et une bibliothèque rassemble les fichiers et les artefacts.

Le coordinateur a un rôle défini. Il délimite les demandes, délègue le travail à des fils parallèles, examine ce que ces fils produisent et assemble les résultats. Chaque fil effectue son travail dans une session cloud Claude Code.

Les équipes d’agents existaient déjà avant ce lancement. Claude Code v2.1.32, publiée le 5 février 2026, les a introduites sous la forme d’un aperçu de recherche pour la collaboration entre plusieurs agents. Cette version décrivait la fonctionnalité comme gourmande en tokens et exigeait une variable d’environnement expérimentale.

Cette distinction est importante lorsque vous consultez les instructions de configuration. La fonctionnalité CLI de février et la bêta des projets de septembre disposent de points d’entrée documentés différents ; l’annonce des projets ne présente pas l’option CLI expérimentale comme une condition d’activation.

Pour vous orienter parmi ces fonctionnalités, le portail des guides Claude Code constitue un point de départ. Distinguez bien le coordinateur de projet, les fils dans le cloud et les sous-agents lorsque vous choisissez le processus adapté à une tâche.

Accès et configuration au 21 septembre

L’accès initial était limité à certains abonnés Pro et Max utilisant les sessions cloud Claude Code et ne disposant d’aucun projet existant sur le Web ou sur ordinateur. Un accès plus large pour les abonnés Pro et Max était prévu, suivi d’un accès pour Team et Enterprise.

La présentation n’établit pas que le déploiement élargi était terminé au 21 septembre. Un abonnement ne doit donc pas, à lui seul, être considéré comme une preuve que la bêta des projets repensés était disponible pour un compte donné.

Ce que vous configurez

La configuration d’un projet commence par un objectif et un dépôt ou du contexte. Elle comprend l’environnement cloud, les connecteurs, les plugins, les instructions et le modèle.

Pour une tâche de développement, un objectif utile décrirait le résultat souhaité et les contraintes importantes pendant la mise en œuvre. Vous pourriez, par exemple, demander une fonctionnalité couvrant une API et son interface, puis préciser les critères d’acceptation et les parties du code qui nécessitent une attention particulière. Il s’agit d’une suggestion pour cadrer le travail du coordinateur, plutôt que d’une garantie documentée sur la manière dont il répartira la demande.

Vous pouvez orienter le travail dans la conversation du projet ou dans les fils individuels, y compris depuis un téléphone. La conversation du projet vous permet de diriger l’ensemble du travail ; un fil individuel vous permet d’en orienter une partie précise.

Ce qui reste non précisé

L’annonce du lancement ne précise ni version minimale de la CLI, ni nombre maximal de fils simultanés, ni tarif distinct pour la bêta. Elle n’établit pas non plus que l’accès avait été entièrement déployé pour chaque formule d’abonnement éligible à la date limite de publication.

Ces informations manquantes comptent pour la planification. Évitez de construire un processus de travail sur la base d’un nombre supposé de fils simultanés ou d’une date de déploiement présumée.

Comment les fils parallèles s’exécutent et où l’intégration reste importante

Le coordinateur délimite la demande et délègue le travail à des fils parallèles. Chaque fil s’exécute dans une session cloud Claude Code avec sa propre branche et sa propre copie du dépôt, ce qui fournit des copies de travail distinctes pour le travail en parallèle.

Les fils peuvent eux-mêmes utiliser des sous-agents, des boucles et des workflows. Le projet comporte donc plusieurs niveaux de délégation : le coordinateur dirige les fils, et un fil peut déléguer du travail supplémentaire à des sous-agents.

Répartir le travail par livrable

Une manière pratique de préparer une demande consiste à identifier des livrables dissociables. Pour une fonctionnalité proposée, il pourrait s’agir de la mise en œuvre de l’API, des modifications de l’interface et de la revue. Ce sont des exemples de délimitation des tâches, et non une règle de décomposition garantie.

Attribuez à chaque livrable une condition d’achèvement claire. Si deux parties dépendent de la même interface, décrivez ce contrat commun dans les instructions du projet afin que le coordinateur en dispose lorsqu’il délimite le travail.

L’annonce antérieure des équipes d’agents, en février, insistait particulièrement sur les tâches indépendantes reposant largement sur la lecture, comme les revues de bases de code. Ce positionnement reste utile pour choisir le travail à paralléliser : évaluez la coordination nécessaire à une tâche avant de la répartir en plusieurs missions.

Des branches distinctes n’éliminent pas les conflits

L’annonce des projets indique explicitement que les modifications de code qui se chevauchent restent soumises à la résolution des conflits de fusion. Des branches et des copies de dépôt distinctes ne suppriment pas le travail d’intégration lorsque les fils modifient le même code.

Pour cette raison, la revue doit aussi examiner la manière dont les productions s’articulent. Une liste de vérification suggérée consiste à vérifier que les interfaces concordent, que les modifications qui se chevauchent ont été conciliées et que le résultat assemblé répond à l’objectif initial.

La présentation n’établit pas de processus pour coordonner des modifications dans plusieurs dépôts. Le fait qu’un fil dispose de sa propre copie du dépôt ne suffit pas à prouver la prise en charge d’une orchestration entre dépôts ; cette capacité doit donc rester une question ouverte.

Mémoire partagée et bibliothèque du projet

Les fils contribuent à la mémoire partagée du projet, tandis que la bibliothèque du projet rassemble les fichiers importés et les artefacts générés. Ces éléments fournissent deux formes de contexte persistant pour le projet : la mémoire alimentée par les fils et une collection de ressources associées au travail.

Pour les développeurs, cette distinction aide à organiser les éléments d’entrée. Un document de conception ou un fichier de référence trouve naturellement sa place parmi les ressources du projet ; les informations découvertes pendant l’exécution du travail peuvent contribuer à la mémoire partagée.

Prévoir les besoins des travaux futurs

Lors de la préparation d’un projet, déterminez quelles contraintes doivent rester disponibles au fil du travail. Il peut s’agir, par exemple, du comportement attendu d’une interface, des conventions du dépôt ou de décisions qui concernent plusieurs livrables.

Ces exemples sont des recommandations pour organiser un projet. La présentation du lancement ne précise pas le format exact de la mémoire partagée et ne garantit pas que tous les détails de chaque fil seront conservés.

Elle ne définit pas non plus les durées de conservation, les limites de stockage ni les règles précises selon lesquelles les informations mémorisées sont transmises à un autre fil. L’affirmation étayée est plus limitée : les fils contribuent à la mémoire partagée, et la bibliothèque rassemble les fichiers téléversés et les artefacts générés.

Examinez les artefacts générés lorsque vous évaluez le résultat assemblé. Leur présence dans la bibliothèque indique qu’ils y sont rassemblés ; elle ne suffit pas, à elle seule, à établir leur exactitude.

Les sous-agents et le précédent flux de travail des équipes d’agents dans la CLI

Les sous-agents de Claude Code permettaient le développement en parallèle avant la bêta des projets. L’annonce d’Anthropic du 29 septembre 2025 donnait l’exemple d’un sous-agent construisant une API backend pendant que l’agent principal construisait le frontend.

Dans les projets repensés, un fil peut invoquer des sous-agents. Les sous-agents font ainsi partie des moyens d’exécution disponibles au sein d’un fil, tandis que le coordinateur gère la définition du périmètre, la délégation et l’assemblage à l’échelle du projet.

Le guide des sous-agents constitue un complément utile pour planifier ce niveau interne de délégation. Distinguez sa configuration de la question de savoir si votre compte a accès à la bêta des projets.

L’option expérimentale de la CLI a un périmètre précis

La version v2.1.32 de février nécessitait cette variable d’environnement pour l’aperçu de recherche sur les équipes d’agents :

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

L’annonce des projets de septembre ne cite pas cette variable comme condition d’activation de la bêta. Son activation ne doit donc pas être présentée comme une instruction permettant d’obtenir l’accès aux projets repensés.

Le lancement de février documentait également la prise de contrôle directe via Maj+Haut/Bas ou tmux. Ces commandes datent du lancement du précédent flux de travail des équipes d’agents ; il ne faut pas supposer qu’elles décrivent l’interface des projets repensés.

Évitez les instructions obsolètes de configuration des sous-agents

Par v2.1.198 du 1 juillet 2026, l’assistant /agents avait été supprimé. Le journal des modifications daté invite les utilisateurs à demander à Claude de créer ou de gérer des sous-agents, ou à modifier .claude/agents/ directement.

Un guide de septembre doit utiliser ces méthodes plutôt que d’inviter les lecteurs à ouvrir l’ancien assistant. Cet exemple concret montre pourquoi les informations de version datées comptent lorsqu’on combine des instructions sur les projets, les équipes d’agents et les sous-agents.

Utilisation, choix des modèles et exécution locale

Les sessions de projet parallèles consomment plus rapidement les quotas d’utilisation. L’annonce des projets permet aux utilisateurs de consulter l’utilisation du projet et de choisir les modèles et le niveau d’effort du coordinateur et des agents exécutants, mais elle ne fournit aucun multiplicateur chiffré du coût du travail en parallèle.

Le périmètre constitue donc un choix de planification important. Avant d’ajouter des fils, déterminez si le travail comporte suffisamment de parties indépendantes pour justifier l’activité supplémentaire. Appuyez-vous sur les choix de modèles et de niveaux d’effort disponibles, ainsi que sur les informations d’utilisation du projet, pour évaluer le flux de travail.

La modification des limites en septembre

Le L’avis relatif aux limites hebdomadaires de Claude Code indique qu’à compter du 14 septembre, les limites hebdomadaires ont été augmentées de façon permanente de 25 % par rapport aux niveaux antérieurs à la promotion pour Pro, Max, Team et Enterprise avec facturation par siège.

La promotion précédente de 50 % s’est déroulée du 13 mai au 13 septembre et s’est terminée à 11:59 h, heure du Pacifique. Elle ne modifiait pas les limites sur cinq heures, et les sièges Free et Enterprise avec facturation à la consommation en étaient exclus.

Claude Code fournit cette commande CLI pour consulter l’utilisation :

/usage

Le Le guide des limites de requêtes peut vous aider à comprendre les notions connexes d’utilisation. L’augmentation des limites hebdomadaires ne supprime pas l’avertissement de l’annonce des projets selon lequel les sessions parallèles consomment les quotas plus rapidement.

L’exécution locale était encore à venir

L’annonce de septembre présentait l’exécution locale comme une fonctionnalité à venir. Au 21 septembre, le flux de travail documenté des projets utilisait des sessions cloud, pilotées depuis la discussion du projet ou les fils individuels.

Un flux de travail local avec Claude Code et la bêta des projets cloud repensés doivent donc être évalués séparément. La présentation ne fournit aucune date de lancement des projets locaux et ne fait état d’aucun déploiement local achevé.

Points clés

• Les projets repensés ont été lancés en bêta le 17 septembre, avec un coordinateur qui définit le périmètre des demandes, délègue le travail à des fils parallèles, examine les productions et assemble les résultats.
• Les équipes d’agents de Claude Code sont antérieures à la bêta : la version v2.1.32 a introduit l’aperçu de recherche distinct dans la CLI le 5 février.
• Chaque fil de projet dispose de sa propre session cloud, de sa propre branche et de sa propre copie du dépôt ; les modifications qui se chevauchent nécessitent toujours la résolution des conflits de fusion.
• Les fils contribuent à la mémoire partagée du projet, et une bibliothèque rassemble les fichiers téléversés et les artefacts générés.
• L’accès initial était réservé à certains abonnés Pro et Max remplissant les conditions annoncées. Le travail en parallèle consomme les quotas plus rapidement, et l’exécution locale restait à venir.

FAQ

Comment accéder à la bêta des projets repensés ?

L’accès initial concernait certains abonnés Pro et Max utilisant les sessions cloud de Claude Code et n’ayant aucun projet existant sur le Web ou dans l’application de bureau. Un accès élargi à Pro et Max était prévu, suivi de Team et Enterprise, mais la présentation n’établit pas qu’un déploiement plus large était achevé au 21 septembre.

Quelle est la différence entre les projets, les équipes d’agents et les sous-agents ?

Un projet repensé dispose d’un coordinateur qui dirige les fils des sessions cloud et assemble leurs résultats. Les équipes d’agents ont été introduites auparavant sous la forme d’un aperçu de recherche distinct dans la CLI, tandis que les sous-agents exécutent le travail délégué et peuvent être invoqués au sein des fils de projet.

Que se passe-t-il lorsque deux fils modifient le même code ?

Chaque fil de projet travaille sur sa propre branche et sa propre copie du dépôt. Les modifications de code qui se chevauchent nécessitent toujours la résolution des conflits de fusion ; l’annonce des projets ne promet pas de réconciliation automatique.

Les fils de projet peuvent-ils s’exécuter localement, et comment les piloter ?

Au 21 septembre, la bêta documentée utilisait les sessions cloud de Claude Code, et l’exécution locale était annoncée comme à venir. Vous pouvez piloter le travail depuis la discussion du projet ou les fils individuels, y compris depuis un téléphone.