J'ai testé Claude Code Projects : forces et pièges des threads parallèles, découverts en lui faisant construire un site web entier

Projects, dans Claude Code, est une fonctionnalité où Claude découpe votre travail en threads au sein d'une seule conversation et les fait avancer en parallèle dans le cloud. J'ai présenté son fonctionnement et les conditions d'accès dans Ce qu'est Claude Code Projects. Cet article en est la suite : le récit d'un site web entier que je lui ai réellement fait construire.

Je l'ai testé du 26 au 28 septembre 2026, alors que Projects était encore en bêta publique (déploiement progressif pour Pro et Max ; voir la documentation officielle). Les écrans et le comportement peuvent encore changer. Ce qui suit, c'est ce qui s'est réellement passé à ce moment-là, avec des chiffres vérifiés sur les écrans, le rapport de consommation et l'historique du dépôt.

En une phrase : le développement avance étonnamment bien sans surveillance, mais ce qui en sort est un premier jet, pas un produit fini, et la mise en ligne sur un serveur accessible uniquement en SSH bute sur un mur. Voici le bon comme le mauvais, dans l'ordre où les choses se sont passées.

1. Ce que je lui ai fait construire : le cadre, et un aveu d'entrée de jeu

Le sujet : un site de base de données pour savoir de combien de mémoire ont besoin les LLM locaux. Pour répondre à la question « ce modèle tourne-t-il sur ma machine ? », il collecte sur Hugging Face la taille des fichiers quantifiés, calcule la mémoire nécessaire pour chaque longueur de contexte et permet de chercher à rebours à partir de la mémoire de votre GPU ou de votre Mac. Le projet n'est pas trop petit et se découpe naturellement en parties parallélisables (collecte de données, calcul, pages, recherche inversée, SEO), ce qui en faisait un bon banc d'essai pour Projects.

2. Les étapes pour démarrer, et les cinq endroits où j'ai trébuché

Les étapes en elles-mêmes sont courtes : dans l'onglet Code de l'application de bureau, choisissez Projects → New, saisissez un nom, un objectif et un dépôt, puis créez le projet. Autour de ces étapes, en revanche, j'ai trébuché à ces cinq endroits.

À propos du point ② : juste après la création, la conversation affichait le message « Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits ». Autrement dit, jusqu'à $100 de la première utilisation ne sont pas décomptés de vos limites habituelles, et l'écran de consommation l'affichait aussi comme un « crédit de configuration du projet » (environ 24 heures avant expiration). Au 28 septembre, cet avantage n'est pas mentionné sur la page Projects de la documentation officielle. La section 6 montre à quelle vitesse il s'est réellement épuisé.

Là où je me suis perdu dans les réglages d'environnement, c'est pour modifier un environnement existant. Passer par « Add cloud environment » (ajouter un environnement cloud) ouvre l'écran d'un nouvel environnement, et au début j'ai saisi les domaines autorisés dans le champ du script de configuration. Pour modifier un environnement existant, survolez-le dans la liste et cliquez sur l'icône d'engrenage qui apparaît (c'est exactement ce que dit la documentation officielle, mais difficile à deviner à partir de l'écran seul).

3. Environ 20 heures, heure par heure : ce qui s'est passé pendant que je dormais

Voici le déroulé, de la création (vers 22 h le 26 septembre) à la fusion de la dernière PR (vers 17 h 30 le lendemain, le 27). Toutes les heures sont en heure du Japon (JST).

Un point qui ne s'est pas bien passé mérite aussi d'être signalé. En construisant les fondations de la collecte de données, un thread a appelé l'API de Hugging Face 520 fois d'affilée pour comprendre comment fonctionnait la limitation de débit du service externe. Le thread de revue a jugé cela « pas raisonnable » et a rédigé des règles d'utilisation des API externes ; le thread de collecte de données suivant n'a fait que 8 requêtes sur l'ensemble de son travail. Livré à lui-même, il ne pense pas spontanément à la charge qu'il impose aux services extérieurs : cela vaut la peine de l'écrire dans les instructions.

4. Tout faire approuver ou tout déléguer

Comme je l'ai dit dans la section 1, la première moitié a tourné avec des instructions qui imposaient une approbation humaine à chaque étape, et le 27 à 17 h je les ai réécrites pour déléguer. Le comportement a nettement changé.

Il y a eu deux points de vigilance au moment de déléguer. Le premier : les instructions réécrites n'atteignent pas les threads déjà en cours. Le coordinateur l'a lui-même expliqué : « Ce thread a démarré avant la réécriture des instructions, il ne voit donc pas les nouvelles. » Le second : les threads n'ont pas pu effacer les anciennes règles restées dans la mémoire du projet. Une tâche qui tentait de réécrire une vieille note disant « seul un humain fusionne » a été bloquée par une vérification de sécurité. C'est à un humain de supprimer les anciennes notes depuis les réglages → « Memory » (Mémoire).

Voici l'ossature des instructions sur lesquelles j'ai fini par m'arrêter.

Ce projet construit et exploite [votre site].
La façon d'avancer vous revient : le coordinateur peut décider quels threads lancer, combien, avec quels modèles et dans quel ordre.
Vous pouvez fusionner les PR une fois la CI passée. Résolvez vous-mêmes les conflits.

Ne demandez à un humain que pour :
- Tout ce qui coûte de l'argent (API payantes, services payants)
- Tout ce qui nécessite des secrets (clés d'API, mots de passe)
- Le déploiement en production ou la modification des données de production
- Les décisions où les options divergent et où l'une comme l'autre se défendraient
- Tout ce dont vous avez besoin mais que vous ne pouvez pas atteindre (ne comblez pas les vides avec des suppositions ou des données factices)

Respectez les limites de débit des API externes et ne les sollicitez pas massivement pour vos investigations.

Cela dit, au vu de ce que j'ai appris ensuite, je recommande d'ajouter « les modifications de la configuration de CI et des scripts de déploiement doivent être approuvées par un humain ». Les threads à qui l'on délègue peuvent aussi modifier la configuration de CI, et combiné à un mécanisme de déploiement, cela ouvre un chemin par lequel des changements peuvent atteindre la production sans que personne ne vérifie (section 7).

5. La qualité découverte après la mise en ligne : tous les tests passaient

J'ai repris ce que le projet avait construit dans mon Claude Code local habituel et je l'ai mis en production. Ma première impression juste après la mise en ligne : « bof, c'est plutôt quelconque ». Il n'y avait pas une seule page de modèle. En remontant la cause, un trou propre au développement en parallèle est apparu.

Dix threads, bien plus d'une centaine de tests, des revues sur Opus et la CI : rien de tout cela n'a repéré cet oubli, parce que chaque thread avait raison à l'intérieur de son propre périmètre. Sans un rôle qui regarde l'ensemble de bout en bout, des trous s'ouvrent aux frontières entre les tâches.

Le chargement des vraies données a fait apparaître deux autres problèmes.

• Les tableaux de quantification contenaient des fichiers qui n'étaient pas le modèle principal. Des modèles auxiliaires de décodage spéculatif (MTP, EAGLE, etc.) et des fichiers LoRA étaient comptés comme des quantifications du modèle principal, si bien que le tableau d'un modèle 12B commençait par une ligne « Q8_0 0,47 Go » (le vrai Q8_0 pèse 12,7 Go). Après correction, 195 fichiers répartis dans 56 dépôts ont été reclassés comme auxiliaires.
• Pour les modèles les plus récents et les plus demandés, la mémoire nécessaire affichait « calcul impossible ». La formule écrite au départ ne prenait pas en charge les architectures de nouvelle génération (par exemple celles où les couches ne conservent pas la mémoire de la même façon). Le principal argument du site manquait précisément sur les pages les plus consultées.

Ces deux problèmes ne sont apparus qu'une fois les vraies données chargées en production, parce que les tests reposaient entièrement sur des données d'exemple. Voici ce que j'ai corrigé avec Claude Code en local, et le temps que cela a pris (le 28 septembre de 17 h 21 à 22 h 54, 13 commits).

Il y avait aussi de vrais points positifs. Les pages étaient rapides (environ 0,1 seconde pour les principales), les tailles de fichiers correspondaient aux valeurs réelles de Hugging Face, et la mémoire nécessaire des modèles pris en charge concordait avec la formule. Le travail de SEO, avec les titres, les données structurées, le sitemap et llms.txt, était là dès le départ. Mon bilan : le squelette et les détails étaient bien faits ; ce qui manquait, c'étaient les « jointures » entre les parties et les vraies données.

6. Consommation et coût : où sont passés 191,8 millions de tokens

L'écran « Usage » des réglages du projet affiche les tokens par thread et par modèle. Un bouton en haut à droite permet de tout copier sous forme de texte. Le rapport du 27 septembre à 11 h 47 se présentait ainsi.

190 millions, cela paraît énorme, mais 97,7 % étaient des lectures de cache. Un thread relit toute la conversation à chaque action ; quand un thread enchaîne des centaines d'actions, on obtient cette forme-là. Le coordinateur n'a ajouté que 2 % : le coût de gestion était minime.

Pour comparer, j'ai rapporté « tokens lus ÷ tokens produits » à Claude Code en local (les trois derniers jours sur mon propre PC) : environ 330 pour le projet et environ 340 en local. La consommation par unité de travail était à peu près la même qu'une session locale. Si Projects paraît plus lourd, c'est sans doute parce que tout avance en parallèle d'un coup, et que la consommation se concentre sur une courte période (le travail n'étant pas le même, c'est une comparaison indicative).

Côté coût, j'ai pu suivre la façon dont le crédit de configuration ($100) s'est épuisé.

Ce crédit se comportait à peu près comme un montant calculé aux tarifs de l'API. En valorisant le rapport de 11 h 47 aux tarifs officiels d'Anthropic (Pricing : Sonnet 5 à $2 en entrée, $10 en sortie et $0.20 en lecture de cache ; Opus 5.5 à $4 en entrée, $20 en sortie et $0.20 en lecture de cache, le tout par million de tokens), on arrive à environ $58–65, ce qui correspond à peu près à ce qu'affichait l'écran à ce moment-là (78 % = $78). Les « $100 » signifient donc la quantité qui coûterait $100 si on la payait via l'API, ce qui n'est pas énorme à l'échelle d'un forfait Max. Par ailleurs, un autre crédit distribué pour les sessions cloud ($250 avec Max) indiquait sur son écran d'activation que « les Projects ne sont pas éligibles », et effectivement pas un seul dollar n'en a été consommé.

7. Pourquoi la mise en production a bloqué

Le plus difficile a été de mettre en production ce qui avait été construit, parce que l'hébergeur était un hébergement mutualisé accessible uniquement en SSH.

• Les threads dans le cloud ne peuvent pas atteindre le serveur de production (la clé SSH se trouve uniquement sur mon PC).
• Pour tourner sur le PC local, on utilise l'option « Work locally » (travailler en local) du projet. Sous le capot, c'est Remote Control, et il faut activer « Use this computer from your phone and claude.ai » (utiliser cet ordinateur depuis votre téléphone et claude.ai) dans l'application de bureau.
• Or ce réglage s'applique à la liste de tous les dossiers ouverts jusque-là dans Claude Code, constituée automatiquement. Dans mon environnement, il y en avait 22, dont un dossier parent contenant plusieurs dizaines de projets. Tant qu'il est activé, tous deviennent des endroits où l'on peut lancer du travail à distance, et les noms de dossiers, les chemins et les URL des dépôts sont aussi envoyés à Anthropic. Pour se limiter à un seul dossier, il faut passer par une autre voie : ouvrir un terminal dans ce dossier et lancer claude remote-control.

J'ai donc étudié plusieurs façons de déployer.

Au bout du compte, j'ai archivé le projet et transféré ce qu'il avait construit dans mon fonctionnement habituel avec Claude Code en local. J'ai jugé plus sûr de le brancher sur la même chaîne de déploiement que mes autres sites plutôt que d'ajouter un nouveau mécanisme.

Avec le recul, il vaut mieux considérer Projects comme pensé pour aller avec un hébergement qui déploie automatiquement dès qu'on fusionne sur GitHub. Avec Vercel, par exemple, il suffit de le connecter à GitHub pour que les changements aillent jusqu'à la production, et l'impasse que j'ai rencontrée ne se produirait pas. Cela dit, l'offre gratuite Hobby de Vercel est réservée à un usage non commercial, et diffuser de la publicité comme Google AdSense exige l'offre payante Pro (à partir de $20 par mois) (Fair Use Guidelines). Ce n'est pas non plus le choix naturel pour un site PHP et MySQL comme celui-ci. L'essentiel est de choisir les technologies et l'hébergeur ensemble, dès le départ.

Je prévois de détailler dans un article à part les risques qu'il y a à laisser piloter son propre PC à distance, et en quoi cela diffère de l'usage quotidien de Claude Code. L'utilisation de votre session locale depuis un téléphone est présentée dans l'article sur Remote Control.

8. Les travaux qui s'y prêtent, et ceux qui ne s'y prêtent pas

Voici, tirés de cette expérience, les points à vérifier avant de commencer.

• Hébergeur : une fusion sur GitHub déclenche-t-elle un déploiement automatique ? Si SSH est nécessaire, décidez à l'avance d'une solution, par exemple faire récupérer le code par le serveur.
• Droits GitHub : le périmètre d'installation de la Claude GitHub App. Utilisez un compte dédié ou restreignez les dépôts.
• Jusqu'où déléguer : dans les instructions du projet, n'écrivez que ce qui doit être demandé à un humain. Soumettez à approbation les modifications de la configuration de CI et de déploiement.
• Réseau : si vous utilisez des API ou des sites externes, mettez dans la liste d'autorisation à la fois le domaine principal et ses sous-domaines.
• Vérification avec de vraies données : ne vous rassurez pas parce que les tests sur données d'exemple passent. À la fin, lancez un thread dont le rôle est de faire passer des données identiques à celles de la production de bout en bout et d'examiner le résultat.
• Limites d'utilisation : revoyez le modèle par défaut des threads. Pendant les 24 premières heures, vous disposez d'un crédit de configuration de $100.

Conclusion

Projects prend réellement en charge le travail d'un humain qui distribue les tâches, les relance et réexplique le même contexte. Trois tâches ont avancé en parallèle pendant la nuit, les threads se sont coordonnés entre eux, et une fois la main confiée, il a pris seul les décisions de fusion et le choix de la suite. Les tokens par unité de travail n'étaient pas différents de ceux de Claude Code en local.

En revanche, ce qui en sort est un premier jet. Découper le travail en parallèle ouvre des trous aux frontières entre les périmètres. Tous les tests sur données d'exemple peuvent passer et les vraies données révéler quand même des bugs. Et la fonctionnalité s'accorde mal avec les serveurs accessibles uniquement en SSH. Si vous l'utilisez, trois précautions devraient vous éviter les détours que j'ai faits : choisir un hébergeur intégré à GitHub, écrire dès le départ jusqu'où vous déléguez, et lancer à la fin un thread chargé de tout vérifier de bout en bout avec de vraies données.

FAQ

Q. Combien coûte Projects ?

R. Il n'y a pas de facturation à part : la consommation est prise sur vos limites habituelles de Pro ou Max. Cette fois, j'ai en plus bénéficié d'un « crédit de configuration » grâce auquel jusqu'à $100 d'utilisation, pendant environ les 24 premières heures, n'étaient pas décomptés de mes limites (affiché à l'écran ; absent de la documentation officielle au 28 septembre). Le travail, 10 threads et 11 PR, a consommé environ 190 millions de tokens et épuisé ce crédit. Aux tarifs de l'API, cela représente environ $100.

Q. Le travail continue-t-il vraiment quand je ferme mon ordinateur ?

R. Oui. Les threads qui tournent dans le cloud ont continué, que je ferme le PC ou le mette en veille. Pendant ce test, trois tâches se sont terminées au cours d'environ 7 heures de nuit. En revanche, les threads lancés sur votre propre PC avec « Work locally » ne tournent que tant que le PC est éveillé.

Q. Puis-je l'utiliser avec des dépôts hébergés ailleurs que sur GitHub ?

R. Les threads qui travaillent sur du code supposent un dépôt github.com sur lequel la Claude GitHub App est installée. Comme je gérais ce projet sur mon propre serveur git, j'ai créé un compte GitHub réservé à Claude, j'ai démarré là-bas, puis j'ai tout rapatrié chez moi à la fin.

Q. Que se passe-t-il si je modifie les instructions du projet en cours de route ?

R. Le coordinateur les prend en compte immédiatement, et sa façon de travailler a changé sans que j'aie besoin de lui parler. En revanche, elles n'atteignent pas les threads déjà en cours : si nécessaire, faites poursuivre le travail dans un nouveau thread. Les anciennes règles restées dans la mémoire du projet ont dû être supprimées par un humain depuis les réglages.

Q. « Work locally » est-il sûr ?

R. Le seul trafic est une connexion chiffrée sortante depuis votre PC ; aucun port d'écoute n'est ouvert. En revanche, activer le réglage dans l'application de bureau fait de la liste des dossiers tirée de votre historique d'utilisation (22 dans mon cas, dont plusieurs dizaines de projets à l'intérieur d'un dossier parent) des endroits où l'on peut lancer du travail à distance. Il faut adopter des habitudes comme ne l'activer que le temps de s'en servir et vérifier que le compte avec lequel vous vous connectez utilise l'authentification à deux facteurs.

Q. Peut-on utiliser tel quel ce qu'il construit ?

R. Dans mon cas, non. Le squelette et le travail de SEO étaient bien faits, mais la logique aux frontières entre les périmètres manquait entièrement, et certains bugs n'apparaissaient qu'avec les vraies données. Avant la mise en ligne, il faut une étape qui charge les vraies données et vérifie l'ensemble de bout en bout.