L’essentiel
- Anthropic a refondu les Projects de Claude Code : vous décrivez un objectif, un coordinateur le découpe en threads qui tournent chacun comme une session cloud distincte.
- Chaque thread travaille sur sa propre branche et sa copie du dépôt, ouvre des pull requests et lance les tests ; les chevauchements remontent en conflits de merge.
- Une mémoire partagée entre threads et une bibliothèque de fichiers et de résultats s’enrichissent au fil du projet.
- La bêta est ouverte à une partie des abonnés Pro et Max qui utilisent déjà les sessions cloud ; Team et Enterprise suivront.
Le 17 septembre, Anthropic a changé l’unité de travail de Claude Code. Avec la refonte des Projects, on ne lui confie plus une fonction à écrire mais un chantier entier : le développeur décrit un objectif, puis regarde Claude distribuer le travail.
Moins de code à écrire, donc. Mais beaucoup plus de code à relire, et l’adoption dépendra surtout de ce second versant.
Un coordinateur, des threads, et personne au clavier
Jusqu’ici, faire travailler plusieurs agents IA (des programmes qui enchaînent seuls des actions pour atteindre un but) sur un même projet demandait un effort manuel. Anthropic le reconnaît dans son annonce : il fallait découper soi-même le travail, gérer les passations et recoudre les résultats. Le développeur jouait le rôle du contremaître.
Ce rôle passe désormais à Claude. Un projet est une conversation dans laquelle un coordinateur cadre la demande, la délègue à des « threads » parallèles, relit ce qu’ils produisent et assemble le tout. On le briefe, selon la formule d’Anthropic, comme on briefe un chef de cabinet : plusieurs demandes à la fois, dans le désordre, et il les répartit lui-même vers des threads nouveaux ou existants.
Techniquement, chaque thread est une session cloud de Claude Code avec sa propre branche et sa propre copie du dépôt. Il ouvre des pull requests (PR), lance les tests, et peut à son tour confier une partie de sa tâche à des sous-agents, des boucles ou des workflows. L’ensemble continue de tourner quand vous fermez votre ordinateur, et se suit depuis un téléphone.
Lancer des agents en parallèle n’est pas neuf en soi : chez OpenAI, Codex exécute déjà plusieurs tâches à la fois dans le cloud, chacune dans son propre environnement, avec une pull request à la clé. L’apport d’Anthropic tient au coordinateur, qui découpe et séquence le travail à la place du développeur.
L’analogie du chantier tient jusqu’aux conflits
L’image qui vient est celle d’un chantier. Le coordinateur fait office de conducteur de travaux, chaque thread est un corps de métier qui avance sur sa partie. Anthropic donne deux exemples : réduire la latence p75 (le temps de réponse sous lequel passent 75 % des requêtes) d’une page de paiement, en profilant chaque endpoint (point d’accès d’une API) dans un thread distinct ; ou retirer un endpoint v1 obsolète en branchant les dépôts API, web et mobile, avec un thread par dépôt pour migrer les appels.
Dans ce second cas, Claude ouvre les PR, puis indique lesquelles doivent être mergées en premier. Ce séquencement a de la valeur. Sur un vrai chantier, le plombier passe avant le plaquiste, et quelqu’un doit le savoir.
Et quand deux corps de métier touchent au même mur ? Anthropic est explicite : si plusieurs threads travaillent sur le même code, le chevauchement se résout en conflit de merge, « comme n’importe quelle autre PR ». Le coordinateur organise, il ne garantit pas l’absence de collisions. Ce qui reste à arbitrer atterrit dans l’interface Git, c’est-à-dire chez vous.
Qui relit toutes ces pull requests ouvertes en même temps ?
Avec un agent unique, le rythme de production restait à peu près celui de la relecture : une demande, un diff, un examen. Avec des threads parallèles, la production se multiplie, alors que l’attention humaine ne se parallélise pas.
Le goulot quitte l’écriture, que Claude absorbe, pour trois tâches qui restent humaines : relire des diff produits sans vous, trancher les conflits entre branches, décider de l’ordre des merges quand le coordinateur ne l’a pas fait. Une équipe qui adopte ces Projects sans renforcer sa discipline de revue de code risque de merger vite ce qu’elle n’a lu qu’à moitié.
Trois garde-fous prennent alors du poids : une suite de tests assez solide pour servir de premier filtre, des PR petites plutôt qu’un gros lot par thread, et une règle claire sur qui a le droit de merger. Le réglage de la fréquence des points d’étape, que Claude accepte d’adapter à la demande, devient lui aussi un levier de pilotage.
Une mémoire commune qui se construit en silence
L’autre brique de l’annonce est la mémoire partagée. Chaque thread y puise et l’alimente. Anthropic cite des cas parlants : se souvenir que la mise en production a glissé au vendredi, pourquoi un export a été abandonné, ou qui consulter avant de toucher au service de facturation. Une bibliothèque rassemble en parallèle les fichiers déposés et les résultats produits.
L’éditeur y voit un moyen de réduire le prompt engineering (l’art de formuler finement ses instructions au modèle). L’argument se tient, à une réserve près. Une décision mal comprise par un thread, une fois inscrite dans la mémoire commune, sera reprise par tous les autres. Le contexte partagé accélère la cohérence ; il propage aussi l’erreur.
Aux diff s’ajoute ainsi une seconde relecture, plus inhabituelle : de temps en temps, vérifier ce que le projet croit savoir.
Une bêta sous conditions
Le déploiement reste prudent. La bêta s’ouvre à une partie des abonnés Pro et Max qui utilisent déjà les sessions cloud de Claude Code et n’ont aucun projet existant sur le web ou le bureau ; une liste d’attente accueille les autres. Les offres Team et Enterprise viendront ensuite, tout comme l’exécution locale. Les projets actuels continuent de fonctionner comme avant, en attendant leur migration.
Le mouvement prolonge la fusion de Cowork et du chat en un seul Claude, annoncée le 16 septembre : un agent généraliste qui prend une tâche et la mène en votre absence. Pour les équipes de développement, la contrainte se déplace du modèle vers leur propre organisation. Combien de threads peuvent-elles superviser avant que la vitesse de production dépasse leur capacité à comprendre ce qui part en production ?
Mon avis
Le succès de ces Projects se mesurera en heures de relecture économisées ou perdues, bien plus qu’en nombre de PR ouvertes. Je m’attends à voir les équipes les plus mûres brider volontairement le nombre de threads, comme on limite le travail en cours en méthode kanban. Le risque que je trouve le plus sous-estimé reste la mémoire partagée : un bug se corrige dans un diff, alors qu’une fausse certitude inscrite dans le contexte commun contamine en silence chaque thread suivant.
