Code Claude en nuage : un guide de champ pour les sessions en nuage

Vous utilisez probablement Claude Code dans un terminal sur votre ordinateur portable. Cette session dépend de l’ordinateur en trois aspects :

• Il partage votre arbre de travail, de sorte que deux sessions dans un même répertoire peuvent modifier les mêmes fichiers et se disputer le même port.
• Il s’exécute avec vos identifiants.
• Il s’arrête lorsque votre ordinateur s’endort ou que le Wi-Fi tombe.

Une session en ligne exécute Claude Code sur une machine dédiée. Chaque tâche dispose d’une machine virtuelle neuve, avec votre repository cloné sur un nouveau branche et l’installation de votre environnement déjà effectuée.

Vous pouvez commencer avec claude.ai/code, l’application mobile de Claude, l’application de bureau, votre terminal et Slack. Vous pouvez ensuite suivre le processus via le navigateur, l’application mobile ou le bureau. Lorsque le travail est terminé, il se trouve sur une branche que vous pouvez transformer en demande de pull request.

Les sessions en nuage sont incluses avec votre plan Pro, Max, Team ou Enterprise sans coût supplémentaire : il n’y a pas de frais distinct pour l’ordinateur en nuage, et les sessions s’appuient sur les mêmes limites d’utilisation que le reste de Claude Code. Selon votre plan, l’administrateur de l’organisation doit activer les sessions en nuage en premier.

Crédit bonus pour les sessions en nuage. Les abonnés individuels Pro et Max existants peuvent obtenir un crédit bonus unique pour les sessions en nuage, en plus des limites de leur plan : 100 $ pour Pro et 250 $ pour Max. Obtenez-le le 7 octobre via claude.ai/code/claim-credit ou en utilisant /claim-credit dans Claude Code. Le crédit expire le 4 novembre. Une fois utilisé ou expiré, les usages réguliers de votre plan s’appliquent. Il n’est pas valable pour Projects ou Routines. Veuillez consulter les Conditions d’offre de crédit promotionnel.

Pour cette guide, j’ai exécuté quatre sessions de cloud réelles contre un petit répertoire d’exemples. Leurs transcriptions, les diffs et les temps d’exécution apparaissent dans tout le texte. Le répertoire et l’utilisateur sur les captures d’écran sont fictifs. Le travail, les résultats et les chiffres proviennent de ces sessions.

L’un des principaux avantages des sessions en cloud est que vous pouvez exécuter plusieurs tâches en même temps sans qu’elles se gênent mutuellement. Voici trois exemples : j’ai commencé tous ces tâches en 16 secondes, chacune sur une machine distincte. Sur mon ordinateur portable, j’aurais exécuté ces tâches l’une après l’autre, ou je passais mon temps à veiller à ce qu’elles ne se gênent pas mutuellement.

TROIS TÂCHES, UNE BIBLIOTHÈQUE, TROIS MACHINE

Le répertoire d’exemple est tidepool, une petite API Node qui prédit les marées pour trois ports fictifs. Il rencontrait trois problèmes courants : un test échouait environ un quart des fois, les documents de l’API décrivaient des paramètres que le code ne pouvait plus lire, et le logger composait ses lignes en concaténant des chaînes de caractères.

J’ai commencé trois sessions en ligne de commande en 16 secondes chacune, une pour chaque problème. Je les ai lancées de manière programmée, et comme tidepool n’est pas sur GitHub, chaque session a d’abord recréé le dépôt à partir des fichiers dans son prompt. Avec un véritable dépôt, on éviterait cette étape ; depuis un terminal, chaque session correspond à un commande claude --cloud. En résumé, les trois prompts étaient :

claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row."
claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it."
claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."

Les sessions ont duré 61, 65 et 72 secondes, et toutes trois se sont terminées 87 secondes après le début de la première. La ré création du dépôt a pris environ un tiers à un peu plus de la moitié de chaque exécution. Voici les résultats.

• Le test instable. Claude a découvert une course dans TtlCache.get. Le cache ne stocke une valeur qu’après que le chargeur soit terminé, donc un deuxième get pour la même clé pendant un chargement fait réapparaître le chargeur. Claude a modifié le cache pour stocker la promesse en cours d’exécution, a supprimé l’entrée lorsqu’un chargement échoue, et a exécuté npm test 40 fois de suite sans aucune erreur.
• Les documents. Claude a démarré le serveur, a utilisé curl sur chaque point d’extension, et a découvert cinq erreurs dans les anciens documents. Il a mentionné des champs que l’API ne renvoie jamais, a documenté un paramètre days que le code ignore, a indiqué les hauteurs en pieds alors qu’elles sont en mètres, a ignoré le point d’extension /next-high, et n’a pas inclus les réponses d’erreur. Il a également constaté qu’une valeur mal formée de from= renvoyait une liste vide avec un code 200, et a documenté que, comme précaution, on ne leur demandait pas de modifier le code du serveur.
• Le logger. Claude a écrit le logger JSON, a transféré le journal des requêtes dans des champs structurés et a ajouté cinq tests. Son commit contenait un test qui échouait ; donc Claude a réexécuté le test de la cache huit fois, l’a vu échouer dans cinq d’entre eux, et a remonté la cause du problème à la même erreur que celle corrigée lors de la première session. Il a proposé la même correction, mais n’a pas touché à la cache car cela dépassait ses compétences, et a indiqué dans son résumé que l’ensemble des tests n’était pas propre.

Le résultat du logger montre pourquoi les sessions en ligne sont adaptées au travail parallèle. Chaque session disposait d’une copie du repository, de ses propres processus et de sa propre branche. La session documentation et la session logger ont chacune initialisé le serveur API pour tester, sans affecter l’autre. Sur un seul ordinateur portable, deux agents travaillant simultanément sur un même check-out modifieraient les mêmes fichiers, et cela pourrait entraîner des collisions sur un port, à moins que chacun ne choisisse sa propre instance.

En raison de cette isolation, la session de logger n’avait pas accès au correctif du cache que la première session était en train de mettre en œuvre. Les tâches parallèles sont divisées le long des limites des fichiers, les branches sont fusionnées dans un ordre logique, et on s’attend à ce qu’une session rapporte des problèmes que une autre session est déjà en train de résoudre.

Sous le capuchon d’une session CLaude Code Cloud

Une session cloud est une session Claude Code exécutée sur une infrastructure gérée par Anthropic, ou sur les machines de votre organisation avec un environnement self-hébergé. La figure montre les différentes parties. Les quatre points clés qui suivent sont ceux qui influencent votre façon de travailler.

• Chaque tâche dispose de sa propre machine. Une nouvelle VM avec votre dépôt est clonée sur une nouvelle branche, de sorte que les sessions ne peuvent pas accéder aux fichiers ou ports des autres. Consultez ce qui est installé.
• Votre token GitHub ne pénètre jamais dans la VM. Un proxy le conserve, et la session dispose d’une identifiée de courte durée qui ne peut être envoyée qu’à son propre branche de travail. Consultez le proxy GitHub.
• La configuration Claude du repository est incluse. La vôtre ne l’est pas. CLAUDE.md, règles, compétences, agents et commandes sont inclus dans le repo, tandis que votre ~/.claude reste sur votre ordinateur. Consultez les paramètres pour les sessions en nuage.
• Les VMs inactives sont récupérées. Reouvrir la session et vous obtiendrez une nouvelle VM avec la conversation restaurée, afin de commencer le travail qui vous importe. Voir début de l’expiration de l’environnement.

Pour les spécifications, les modes de permission et les niveaux de réseau, veuillez consulter les documents sur les environnements en ligne.

LOCAL ou CLOUD ?

Les sessions en ligne ne remplacent pas les sessions locales, et la plupart des personnes utilisent les deux. Le tableau montre où elles diffèrent, et les paragraphes qui suivent indiquent quand chacune convient.

Restez local lorsque la tâche nécessite quelque chose que seule votre machine peut fournir. Cela inclut une base de données avec des données locales réelles, un service accessible via VPN, une GPU, un simulateur de téléphone ou du matériel sur votre bureau. Restez local également pour des boucles visuelles complexes où vous voulez observer chaque changement dans votre propre navigateur en quelques secondes, et lorsque votre organisation utilise Zero Data Retention, qui met fin aux sessions en cloud.

Deux fonctionnalités se situent entre les options. Le contrôle à distance maintient la session sur votre machine et vous permet de la diriger depuis votre téléphone ou votre navigateur. Les environnements self-hébergés, en beta pour Team et Enterprise, exécutent des sessions cloud sur l’infrastructure de votre organisation, afin qu’elles puissent accéder aux réseaux privés.

Si aucune de ces conditions ne s’applique, cette tâche est un bon candidat pour être exécutée en ligne. La section suivante couvre les processus de travail où cela porte le plus grand intérêt.

SEPT FONDEMENTS DE TRAVAIL QUI S’APPROPRIENT DES SESSIONS EN CLOUD

Ces processus de travail mettent en œuvre les différences présentées dans le tableau : une machine distincte pour chaque tâche, des sessions qui continuent de fonctionner pendant votre absence, et une branche à la fin pour que vous puissiez la revoir.

1. Éliminer le retard en parallèle

Disons que vous avez cinq correctifs mineurs et non liés. Sur le local, vous les effectuerez un par un, ou vous configurerez cinq travaux et garderez leurs ports et installations séparés. En cloud, vous ouvrirez cinq sessions et examineriez cinq branches.

claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude --cloud "Refactor the logger to use structured output"

claude --cloud clone le réseau GitHub de votre branche actuelle, donc tenez d’abord vos commits locaux en tête. Lorsque la VM se lance, l’interface CLI affiche une liste de vérification des étapes de configuration en temps réel et enregistre tout ce que vous tapez.

Écrivez chaque tâche sous forme de ticket auto-contenu, indiquant ce qui est incorrect, ce qui a l’air correct et comment le prouver. Le prompt de test flaky-test a nommé sa preuve : exécuter l’ensemble du test au moins 30 fois consécutivement. La session l’a exécuté 40 fois.

Lorsque les tâches font partie d’un effort plus large, un projet (bêta publique pour Pro et Max) gère une conversation coordonnante qui commence et suit les sessions en ligne pour vous. Il les regroupe ensuite selon l’état : en cours, en attente de votre approbation, ou prêts à être revus.

2. Laissez cela prouver que la correction fonctionne

Un test instable est le cas le plus clair où il faut une vérification répétée : il faut exécuter l’ensemble des tests encore et encore, et on ne veut pas que ce cycle alourdisse l’ordinateur sur lequel on travaille. Dans le cloud, Claude a corrigé la mémoire cache et a exécuté tout l’ensemble des tests 40 fois en une seule commande.

L’instance virtuelle n’a pas de frais de calcul et sa CPU n’est pas à vous, donc demandez une preuve détaillée. Exécutez l’ensemble des tests 200 fois, divisez la régression à partir de 50 commits, exécutez le niveau d’intégration lent, ou lancez l’application et utilisez curl comme l’ont fait lors de la session documentation.

Chaque tour de Claude compte toujours pour votre plan, mais une longue exécution en une seule commande coûte peu. Les commandes en premier plan échouent après 2 minutes par défaut (jusqu’à 10 au maximum), puis continuent à fonctionner en arrière-plan pendant jusqu’à 30 minutes supplémentaires. Vous pouvez augmenter les paramètres par défaut avec BASH_DEFAULT_TIMEOUT_MS et BASH_MAX_TIMEOUT_MS dans les variables de l’environnement.

3. Planifiez à votre bureau, créez dans le cloud, terminez dans votre terminal

Pour un changement plus important, convenez d’abord de l’approche avant de procéder à des échanges coûteux. Mettez Claude en mode plan, établissez le plan ensemble, faites une commit du plan, et envoiez-le.

claude --permission-mode plan
# ...agree on the plan, save it to docs/migration-plan.md, commit and push...
claude --cloud "Execute the migration plan in docs/migration-plan.md"

Pendant que la session en nuage est créée, votre terminal est libre pour d’autres tâches. Lorsqu’elle est terminée, décrochez la session pour la terminer manuellement.

claude --teleport            # pick a cloud session
claude --teleport <session-id>

Le Teleport vérifie que vous êtes dans le même répertoire, récupère la branche de la session, la télécharge et charge toute la conversation dans votre terminal. Il faut qu’il y ait un arbre de travail propre (il propose de le stocker), et la branche doit être envoyée. À l’intérieur de Claude Code, /teleport (ou /tp) ouvre le même choix, et /tasks puis t fonctionnent également. L’application Desktop fonctionne différemment, et son menu Open in envoie une session locale vers le cloud.

4. Se connecter depuis votre téléphone

La boîte de dialogue « Code » dans l’application Claude est connectée aux mêmes sessions. Depuis votre téléphone, vous pouvez lancer une tâche, la suivre, la diriger, répondre à une question posée par Claude, ou demander à Claude de surveiller un pull request.

Un téléphone convient aux questions que vous oublieriez autrement d’ici que de toucher au clavier. J’ai donné une quatrième session avec une question que l’on pourrait taper d’un seul coup : comment le tidepool prédit les marées, et comment cela peut-il échouer aux limites d’une fenêtre temporelle ? Le code a été exécuté pour vérifier sa réponse, et un bug réel a été découvert. Le boucle ne examine jamais les premiers ou derniers échantillons, si bien que l’API manque une marée haute qui tombe exactement au début de la fenêtre.

5. Transmettre les échecs de CI et les commentaires de revue à Claude

Avec l’application GitHub de Claude installée dans un répository, une session en ligne peut surveiller une demande de pull et intervenir sur les événements qui se produisent. Dans la barre CI d’une session sur claude.ai/code, activez Auto-fix. Vous pouvez également exécuter /autofix-pr sur la branche PR dans votre terminal, demander à l’application mobile de surveiller la demande de pull, ou coller le URL de la demande de pull dans une session.

Claude applique des corrections claires pour les vérifications qui échouent et les commentaires de revue, et explique ce qu’il a modifié. Il vous interroge sur tout ce qui est ambigu ou relatif à l’architecture. Les réponses dans les threads de revue sont publiées sous votre nom de GitHub, étiquetées comme Claude Code. Claude ne reçoit pas d’alerte pour les conflits de fusion avec la branche de base, il faut donc lui demander de rebase. Ses commentaires peuvent également déclencher des automatisations basées sur les commentaires, comme Atlantis.

6. Commencer le travail sans le débuter soi-même

Une routine (prévisualisation de recherche) est plusieurs ressources sauvegardées conçues pour accomplir une tâche, telles qu’un prompt, des réservoirs, des connecteurs et un environnement. Chaque exécution constitue une session en ligne, lancée par un déclencheur. Les déclencheurs peuvent être un planning (généralement toutes les heures), une appel HTTP vers l’endpoint de la routine, ou un événement GitHub comme une demande de pull request ou une sortie. Créer une routine via claude.ai/code/routines, dans l’application Desktop, ou avec /schedule dans la CLI. Les routines s’exécutent sans demande d’approbation et, par défaut, elles sont ajoutées dans des branches préfixées par claude/.

Deux outils plus petits peuvent aider ici. Vous pouvez ajouter une tâche de suivi dans une session en cours depuis n’importe quelle machine où vous êtes connecté, y compris un travail de CI.

claude -p "The integration tier is green now; rebase on main and push" --cloud <session-id>

Vous pouvez également marquer une session prédéfinie comme référence. Une URL comme claude.ai/code?prompt=Triage+the+newest+issues&repositories=acme-labs/tidepool ouvrir claude.ai/code avec le prompt et le repository déjà remplis.

7. Exécuter le code dont vous ne faites pas entièrement confiance

Une demande de pull d’un contributeur, un script d’installation d’une nouvelle dépendance, ou un répo qui a été cloné il y a cinq minutes peuvent tous exécuter du code que vous n’avez pas lu. Sur votre ordinateur portable, ce code s’exécute à côté de vos clés SSH, de vos sessions CLI cloud et de votre profil de navigateur. Dans une session cloud, il s’exécute dans une VM jetable, sans aucune de ces éléments : pas de creds GitHub spécifiques à la session, et un réseau que vous pouvez restreindre.

Définir l'accès réseau de l'environnement Aucun pour une utilisation très stricte, ou gardez Fiable, ce qui permet aux registres de paquets, GitHub et aux principaux hébergeurs de SDK cloud. Même en None, Claude Code envoie toujours des requêtes à l’API Anthropic, de sorte que les données puissent quitter la VM de cette manière, et la session peut encore être envoyée vers sa propre branche. Tout trafic sortant passe par un proxy qui enregistre les noms d’hôte.

Se connecter à GITHUB sans rester bloqué

Si votre première session en cloud échoue, c’est très probablement à cause de GitHub. La plupart des problèmes surviennent lorsque les sessions en cloud nécessitent deux permissions distinctes sur GitHub.

• Se connecter avec GitHub indique à Claude qui vous êtes.
• Installation de l’application Claude GitHub sur un compte ou une organisation définit les répositories privés que Claude peut voir.

Les répositories publics fonctionnent uniquement avec le premier. Les répositories privés nécessitent le second, selon l’accoutrement ou l’organisation qui les possède. Si vous avez connecté GitHub et qu’un répository privé manque, l’application n’est généralement pas installée sur l’accoutrement ou l’organisation qui les possède.

Chemin A : se connecter dans le navigateur (recommandé)

Connectez votre compte GitHub via claude.ai/connect-github, puis installez l’application Claude GitHub sur le compte ou l’organisation qui possède votre répertoire. Pour une organisation, l’administrateur doit généralement approuver l’installation. Le quickstart décrit chaque étape.

Si GitHub ne vous renvoie pas vers Claude.ai/code, la page de connexion claude.ai/connect-github peut afficher une petite liste de vérifications pour les causes courantes. L’une d’elles est l’étape de single sign-on, qui cache les répositories d’une organisation si vous l’ignorez.

L’auto-correction, les routines et projets déclenchés par GitHub dépendent également de l’application, donc installez-la même si vous vous connectez d’une autre manière.

Chemin B : connectez-vous depuis votre terminal via /web-setup

Si vous utilisez déjà la CLI gh, exécutez /web-setup dans Claude Code pour envoyer votre token gh sur votre compte Claude. Les sessions peuvent alors accéder à n’importe quel répertoire que le token peut utiliser, avec ou sans l’application. Consultez Se connecter depuis votre terminal pour une explication détaillée. Sur les plans Team et Enterprise, l’utilisateur doit d’abord activer Quick setup.

Chemin C : ignorez GitHub pour une utilisation unique

Exécutez claude --cloud dans un répertoire de code qui ne dispose pas d’un réseau GitHub, ou dans un répertoire où l’application n’est pas installée. Claude Code téléverse alors un bundle de votre répertoire au lieu de le cloner. La session ne peut être mise en push que si votre connexion GitHub a les droits de push sur ce répertoire. Les documents expliquent ce que le bundle contient et ne contient pas.

Si vous utilisez Team ou Enterprise

Le propriétaire dispose d’une liste de vérifications courte : activer le connecteur GitHub à claude.ai/admin-settings/connectors, autoriser les sessions en ligne dans les paramètres d’administration Claude Code, installer l’application GitHub de Claude dans les répositories de l’organisation (ou approuver les demandes des membres), et décider si on active Quick setup. Les organisations disposant de listes d’accès IP ou de GitHub Enterprise Server doivent effectuer un étape supplémentaire. Consultez les documents sur listes d’accès IP et GitHub Enterprise Server.

Lorsque cela ne fonctionne toujours pas

Pour tout autre chose, consultez le troubleshooting dans les dokuments, y compris les réposoirs ne apparaissant plus après connexion à GitHub. Pour se déconnecter complètement de GitHub, utilisez claude.ai/customize/connectors.

Donnez aux sessions ce dont elles ont besoin pour vérifier leur propre travail

Une session qui peut exécuter vos tests vérifie son propre travail avant de le restituer. Sans cela, vous ne pouvez pas examiner les modifications non exécutées. La plupart de la valeur des démonstrations de ce guide proviennent du fait que Claude exécute les tâches : le ensemble est exécuté 40 fois, le serveur et ses curls, ainsi que le calcul de marée au bord de la fenêtre. Dix minutes de configuration de l’environnement permettent à Claude de réaliser ces vérifications.

• Commencer avec l’environnement par défaut. Il utilise l’accès réseau confiance, sans variables ni script de configuration, ce qui est suffisant pour la plupart des dépôts JavaScript, Python, Go et Rust.
• Utilisez un script de configuration pour la machine. Il s’exécute en tant que root avant que Claude Code ne démarre, de sorte que apt install fonctionne. Il doit terminer avec un code 0, sinon la session ne démarrera pas, et il doit se terminer en environ cinq minutes afin que l’environnement soit enregistré dans la cache. Par la suite, de nouvelles sessions commencent à partir d’un snapshot contenant vos outils sur disque. La cache est reconstruite lorsque vous modifiez le script ou les hôtes autorisés, et environ tous les sept jours.
• Utilisez le hook SessionStart pour le projet. Placez npm install et autres étapes dans un hook dans le fichier .claude/settings.json du repository, afin que ceux-ci soient exécutés de la même manière sur le local et en cloud. Vérifiez CLAUDE_CODE_REMOTE si une étape doit s’exécuter uniquement en cloud. Les hooks du repository se chargeent dans les sessions de seul repository.
• Commencer les services par session. Le cache stocke les fichiers. Les processus en cours ne survivent pas à cela. Demandez à Claude d'exécuter service postgresql start, ou faites-le via un hook SessionStart.
• Choisissez le niveau de réseau le plus étroit qui fonctionne. Trusted couvre les registres communs. Utilisez Custom pour ajouter un registre privé, et Full uniquement lorsque la tâche nécessite Internet ouvert. Les modifications sont appliquées aux sessions en cours en environ une minute.
• Ne conservez aucun secret dans les variables partagées. Les variables d’environnement sont visibles pour toute personne qui utilise l’environnement. Sur Pro et Max, les identifiants API de l’environnement attachent une clé aux requêtes pour les hôtes que vous nommez, en dehors de la VM ; ainsi, la clé ne se trouve jamais dans une variable.
• Placez les commandes dans CLAUDE.md. Votre personnel ~/.claude Il ne atteint pas la machine virtuelle en nuage. Si Claude doit savoir comment exécuter les tests d'intégration, le répertoire doit le indiquer.

Habitudes qui rapportent

• Une tâche, une session. Les petites sessions séparées sont plus faciles à examiner et moins coûteuses à éliminer.
• Demande des preuves. Nomme la commande qui prouve que la tâche est terminée, et lise le résumé de Claude avant la comparaison.
• Envoyer le push avant claude --cloud. La VM est clonée depuis GitHub, donc les commits non envoyés ne l’atteignent pas.
• Commencer les commits pendant les tâches longues. Les machines virtuelles inactives peuvent être récupérées.
• Vérifier dans la vue diff. Les commentaires en ligne sont combinés dans votre prochain message, et Créer un PR peut ouvrir un PR complet, un projet en écriture ou la page de composition de GitHub.
• Dirigez en attendant que Claude travaille. Les messages que vous envoyez pendant que Claude travaille sont stockés dans une file, et vous pouvez récupérer un message de cette file.
• Partager la session. Sur Team et Enterprise, définir la visibilité d’une session en « Team » afin qu’un réviseur puisse lire comment la modification a été effectuée. Les commits provenant de sessions en ligne portent un en-tête Claude-Session qui renvoie à la transcription.
• Fais attention à vos limites. Les sessions parallèles exploitent les limites de votre plan en parallèle ; donc, cinq sessions utilisent ces limites environ cinq fois plus rapidement qu’une seule. Les routines ont leurs propres limites horaires, et les projets peuvent démarrer jusqu’à 200 nouveaux threads par jour.

QUESTIONS COMMUNES

Qui peut utiliser les sessions en ligne ? Les abonnements Pro, Max et Team, ainsi que les utilisateurs Enterprise disposant d’un siège premium ou d’un siège Chat + Claude Code, qui s’inscrivent avec un compte claude.ai. Ce service n’est pas disponible avec une clé API Console ou via un fournisseur tiers. Consultez les documents sur les sessions en ligne.

où vont mes données ? Anthropic stocke le transcript du session, et la durée de conservation dépend de votre plan et de la configuration d'amélioration du modèle. Les VMs sont récupérées après un temps d'inactivité, et la suppression d'un session supprime ses données. Voir utilisation des données et sécurité.

Claude s’entraînera-t-il sur les données des sessions en cloud ? Les sessions en cloud suivent la même politique que le reste du code Claude. Sur Team, Enterprise et l’API, Anthropic ne entraîne pas les modèles sur votre code ou vos prompts sauf si votre organisation choisit de le faire. Sur Free, Pro et Max, cela dépend de votre paramètres d’amélioration du modèle. Voir utilisation des données.

Va-t-il gérer mon grand répertoire de données ? La VM dispose d’environ 4 vCPUs, 16 Go de RAM et 30 Go de disque. Effectuez les installations lourdes via un script de configuration afin qu’elles soient exécutées une seule fois et stockées dans le snapshot enregistré.

Et pour GitLab ou Bitbucket ? claude --cloud peut téléverser un bundle depuis n’importe quel répertoire git, mais la session ne peut pas envoyer de données vers ces hôtes. GitHub Enterprise Server est supporté sur Team et Enterprise. Consultez les restrictions de la plateforme.

Que se passe-t-il lorsque les branches parallèles entrent en conflit ? Les sessions ne se connaissent pas les unes les autres. Fusez un branche, puis envoyer la prochaine session une suite comme par exemple claude -p "rebase on main and fix any conflicts" --cloud <session-id>.

Perdrais-je mes outils locaux ? La configuration au niveau utilisateur ne se transmet pas, donc déplacez les éléments nécessaires par l’équipe dans le repository : committez les compétences et les commandes dans .claude/, ajoutez les serveurs MCP spécifiques au projet dans .mcp.json, et documentez les commandes de test dans CLAUDE.md. Les paramètres dans les sessions en ligne indique ce que chaque session lit.

Débutons dans cinq minutes

La configuration prend environ cinq minutes. Après cela, vous pouvez confier une tâche, fermer votre ordinateur portable et revenir à une branche prête à être examinée.

1. Ouvrez claude.ai/code, ou exécutez /login dans Claude Code avec votre compte claude.ai.
2. Connectez GitHub et installez l’application Claude GitHub où se trouve votre répertoire.
3. Choisissez le répertoire et l’environnement par défaut.
4. Donnez à Claude une tâche de son backlog, avec une commande qui prouve qu’elle est accomplie.
5. Fermez la fichete. Rejoignez-moi plus tard depuis votre téléphone, puis examinez le différend et créez la demande de pull sur claude.ai/code.