Configurer les sessions cloud de Claude Code en toute sécurité : une configuration qui protège la production, et 5 pièges où j’ai bloqué

Vous pouvez confier du développement aux sessions cloud de Claude Code sans ouvrir une nouvelle porte vers la production, à condition que le cloud ne puisse toucher qu’un seul dépôt GitHub et que votre serveur de production se contente de récupérer (pull) depuis ce dépôt. Pour en arriver là, j’ai pourtant bloqué plus d’une fois. Cet article est mon compte rendu (je gère ce site) de mes débuts avec les sessions cloud sur un projet de développement distinct, le 4 octobre 2026, revérifié par rapport au texte original de la documentation officielle.

Sources : Use Claude Code in the cloud et Configure cloud environments. Vérifié le 4 octobre 2026. Pour le fonctionnement, la prise en main et les tarifs, voir « Que sont les sessions cloud de Claude Code ? »

1. Une configuration qui protège la production : la production ne fait que des pulls

Ma plus grande crainte était que passer par GitHub ajoute une nouvelle voie d’accès au serveur de production. J’ai retenu la configuration ci-dessous (c’est mon propre choix, pas une recommandation officielle). Les flèches indiquent le sens dans lequel les données sont récupérées.

• Session cloud Écrit le code et pousse des branches (ne peut pas entrer en production)
• →push
• Dépôt GitHub privé Le seul dépôt sur lequel l’App est installée
• ←fetch
• Serveur de production Fait des pulls avec une clé de déploiement en lecture seule ; c’est un humain qui lance le déploiement

2. Ce qui est envoyé si vous démarrez sans GitHub

D’habitude, je garde mon code dans un dépôt git sur mon propre serveur ; au départ, j’ai donc envisagé d’utiliser les sessions cloud sans GitHub. D’après la documentation officielle, quand vous lancez claude --cloud "task description" dans, par exemple, un dépôt sans remote, votre dépôt local est empaqueté en un seul bundle et envoyé dans le cloud. Voici ce qui est envoyé.

Les cas à risque sont quand vous suivez dans git un fichier contenant des secrets et que vous l’avez modifié, et quand vous avez commité des secrets à un moment donné dans le passé. Un .env exclu par .gitignore n’est de toute façon pas envoyé.

Autre point : d’après la documentation officielle, une session créée à partir d’un bundle ne peut pousser que vers « repositories your GitHub connection has push access to » (les dépôts sur lesquels votre connexion GitHub a le droit de push). Je n’ai trouvé dans la documentation aucun moyen de renvoyer directement les résultats vers un dépôt auto-hébergé hors GitHub. Après être allé jusqu’à rédiger une procédure, j’ai renoncé et créé un dépôt privé sur GitHub.

3. Les cinq endroits où j’ai réellement bloqué

Voici les accrocs rencontrés entre la création d’un dépôt privé sur GitHub et le vrai démarrage, chacun présenté sous la forme symptôme, cause et solution.

1) Le dépôt n’apparaît pas dans la liste

2) Sur quelle étendue installer la GitHub App

3) Des dépôts d’organisations sans l’App s’affichent

4) Un ancien environnement cloud traînait encore

5) J’ai voulu lui faire lire un fichier local

4. Ce qui change pour les modes d’autorisation dans le cloud

Juste avant d’envoyer, j’ai remarqué que le mode d’autorisation était réglé sur « Accept edits ». Le nom laisse penser que c’est le mode qui fonce le plus, mais d’après la documentation officielle, Accept edits dans le cloud correspond au mode par défaut (Manual) de Claude Code en local. Dans le cloud, les modifications de fichiers sont pré-approuvées dans tous les modes, si bien que le mode par défaut apparaît simplement sous ce nom.

Je voulais qu’il continue à travailler sans moi, je suis donc passé en Auto. À noter : dans le cloud, vous ne pouvez pas choisir le mode qui saute toutes les vérifications (bypass permissions), et il est ignoré même s’il est défini dans le fichier de réglages du dépôt. Pour une comparaison détaillée de chaque mode, voir « Modes d’autorisation de Claude Code ».

5. Ce que ça a vraiment coûté : 226 $ pour une seule consigne

Une fois tout cela en place, j’ai lancé une session cloud avec le crédit à durée limitée du forfait Max (250 $). Dans le premier message, j’ai transmis le document de conception et les consignes, avec le mode d’autorisation sur Auto. Ensuite, je ne lui ai plus parlé une seule fois. En cours de route, j’ai consulté l’écran d’utilisation, j’ai été surpris par la vitesse à laquelle le crédit fondait, et je lui ai dit de s’arrêter. Au moment de l’arrêt, il me restait 24 $ de crédit. Si je ne l’avais pas arrêté, il aurait consommé la totalité des 250 $.

Source : mon écran d’utilisation de Claude Code (4 octobre 2026, forfait Max 20x). Les 86 % de la limite hebdomadaire incluent l’utilisation hors cloud.

Voici, à partir d’une seule consigne, la quantité de travail que le cloud avait abattue au moment où je l’ai arrêté (d’après mon journal de travail).

Pourquoi le crédit fond si vite

Le coût ne dépend pas du nombre de fois où vous lui parlez, mais du nombre de fois où Claude appelle le modèle et de la quantité de contexte qu’il lit à chaque fois. Quand il tourne en autonomie, chaque lecture de fichier, écriture de fichier et exécution de tests déclenche un appel ; il peut donc atteindre des centaines ou des milliers d’appels sans aucune conversation. La documentation officielle (Manage costs effectively) indique elle aussi que les coûts augmentent avec la taille du contexte.

Chaque appel relit tout le contexte accumulé jusque-là. Même avec le cache, les lectures ne sont pas gratuites : au prix de lecture en cache d’Opus 5.5 (0,20 $ par million de jetons), lire 500 000 jetons une fois coûte environ 0,10 $. Répétez cela 1 000 fois et vous arrivez à environ 100 $ (c’est un exemple que j’ai calculé à partir du prix unitaire ; je n’ai pas vérifié le nombre réel d’appels ni la répartition par modèle pour cette session). Le code et les tests qu’il écrit sont comptés à part, au prix de la sortie.

La répartition : relectures et sous-agents

Après l’arrêt, j’ai ouvert la répartition détaillée sur l’écran d’utilisation (ces chiffres couvrent toute la session, y compris le résumé que je lui ai fait rédiger après l’arrêt).

Source : la vue par session de mon écran d’utilisation de Claude Code (4 octobre 2026). Coût affiché : 231,09 $.

Je n’ai été aux commandes que 2 minutes 24 secondes ; pendant les plus de 8 heures restantes, Claude a travaillé seul. Pendant tout ce temps, la conversation principale sur Opus et les sous-agents, eux aussi sur Opus, relisaient encore et encore une conversation de plus en plus longue. Quand j’ai demandé à la session cloud de faire le décompte, elle a indiqué qu’achever un outil prenait environ 30 actions pour un sous-agent Sonnet et de 130 à 230 actions pour un sous-agent Opus (c’est le décompte de la session elle-même ; je ne les ai pas vérifiés un par un).

Le coût affiché à l’écran (231,09 $) était presque identique à la baisse du crédit au moment où j’ai ouvert cet écran (250 $ → 18 $, soit 232 $). Il me restait 24 $ quand j’ai arrêté la session ; j’ai ouvert cet écran ensuite, et le solde avait encore un peu baissé entre-temps. D’après la documentation officielle, le coût affiché sur cet écran est une estimation fondée sur le nombre de jetons multiplié par les prix catalogue. On peut donc, semble-t-il, supposer sans grand risque que le crédit est décompté aux prix catalogue de l’API (la documentation officielle ne l’indique pas explicitement).

Si vous ne précisez pas de modèle, les sous-agents utilisent le même modèle que la conversation principale (documentation officielle : « Create custom subagents »). Avec Opus comme modèle principal, même le travail de masse finit par tourner sur Opus.

Comment réduire les coûts (par ordre d’impact)

• 1. Faire tourner les sous-agents sur Sonnet Écrivez « run subagents with model: sonnet » dans vos consignes. Vous pouvez aussi changer la valeur par défaut avec la variable d’environnement CLAUDE_CODE_SUBAGENT_MODEL (ce n’est pas un secret, on peut donc la mettre dans l’environnement).
• 2. Garder des conversations courtes (/compact ou une nouvelle session) Plus la conversation est courte, moins chaque action coûte. Si vous restez sur le même sujet, résumer avec /compact la raccourcit sans changer de session (vous pouvez préciser ce qu’il faut garder, par exemple « garde les résultats des tests »). Quand le sujet change, ou quand vous reprenez après une longue pause, démarrez une nouvelle session. Si vous lui faites consigner l’avancement dans un document de passation, rien n’est perdu quand vous découpez le travail.
• 3. Fixer un point d’arrêt dès le départ Écrivez par exemple « arrête-toi et fais le point une fois le socle terminé » ou « arrête-toi et fais le point vers 50 $ » (il n’existe pas de réglage de plafond de dépenses, servez-vous donc des consignes pour poser des limites).
• 4. Déléguer aussi le travail d’intégration Laissez les sous-agents s’occuper des tests, des commits et des pushs, pour que moins de travail se fasse dans la conversation principale, longue et coûteuse.
• 5. Alléger les vérifications Ne lancez les tests d’interface que pour les outils qui viennent d’être construits, et la suite de tests complète une fois avant la fusion. Prenez des captures d’écran une fois par outil en largeur ordinateur et une fois en largeur téléphone.
• 6. Arrêter tout de suite le travail inutile Un sous-agent arrêté en cours de route ne laisse aucun résultat, et ce qu’il a consommé n’est pas remboursé.

En règle générale, faites-en tourner 2 à 3 en parallèle. D’après l’évaluation de la session cloud elle-même, réduire le parallélisme ne fait qu’allonger la durée sans beaucoup changer le coût total. Plus que le nombre de tâches en parallèle, ce qui compte, c’est de garder chaque conversation courte et chaque consigne précise.

En m’appuyant sur la documentation officielle, voici comment je choisis entre /compact et une nouvelle session. /compact relit toute la conversation pour produire un résumé, mais tant que le cache est encore chaud, une grande partie de cette relecture provient du cache ; ce n’est donc pas aussi cher que la taille de la conversation pourrait le laisser croire (« Prompt caching »). Après une longue période d’inactivité, une fois le cache expiré, tout est relu sans cache, ce qui coûte cher. Une nouvelle session, à l’inverse, ne coûte rien mais ne reprend pas ce qui précède (« Manage costs effectively »). Les résumés peuvent perdre des détails ; il est donc plus sûr de faire d’abord consigner dans un document tout ce que vous voulez garder. À noter : dans les sessions cloud, /compact fonctionne mais pas /clear ; on démarre une nouvelle session depuis la barre latérale (« Claude Code on the web »).

Voici le type de message que je colle au début de la session suivante (nom du projet masqué).

Reprends là où tu t’étais arrêté.
Lis CLAUDE.md → docs/HANDOFF.md → docs/TODO.md et respecte les règles.
Sujet de cette session : XX
Fais tourner les sous-agents avec model: sonnet, 2 à 3 en parallèle au maximum.
Arrête-toi et fais le point quand tu atteins un budget de XX $. Fais ton compte rendu en français.

Pour le résumé du contexte dans les sessions cloud, le cloud définit lui-même la variable d’environnement CLAUDE_AUTOCOMPACT_PCT_OVERRIDE ; l’ajouter à votre environnement n’a donc aucun effet. Pour déclencher le résumé plus tôt, utilisez CLAUDE_CODE_AUTO_COMPACT_WINDOW ou /autocompact, comme le conseille la documentation officielle.

6. Liste de vérification avant de commencer

• Compte GitHub Le compte connecté à claude.ai est-il bien celui que vous voulez utiliser ?
• Étendue de l’App L’avez-vous installée uniquement sur les dépôts nécessaires, avec « Only select repositories » ?
• Historique Des secrets commités par le passé traînent-ils encore dans l’historique du dépôt ?
• Environnement En avez-vous créé un nouveau pour ce projet ? Ses variables d’environnement sont-elles exemptes de secrets ?
• Production Avez-vous évité de créer le moindre chemin du cloud ou de GitHub vers la production (la production fait-elle des pulls) ?
• Règles Avez-vous mis les règles que vous réutilisez dans le CLAUDE.md du dépôt ?
• Mode d’autorisation Avez-vous choisi Auto pour le laisser avancer, ou Accept edits pour valider chaque étape ?

Résumé

Utiliser les sessions cloud tout en protégeant la production se résume à trois points : le cloud ne touche qu’un seul dépôt GitHub, la production en fait des pulls avec une clé en lecture seule, et c’est un humain qui lance le déploiement. Vous pouvez démarrer sans GitHub, mais le dépôt est envoyé avec l’historique de toutes les branches, et sous Windows, les modifications non commitées des fichiers suivis sont envoyées quel que soit leur nom.

Là où j’ai réellement bloqué : un autre compte GitHub était connecté, l’étendue de l’App, un ancien environnement resté en place, des fichiers locaux invisibles, et « Accept edits » qui s’arrête à chaque commande. La liste de vérification ci-dessus permet d’éviter tout cela.

Côté coût, une seule consigne exécutée en autonomie a consommé 226 $ du crédit à durée limitée avant que je lui dise de s’arrêter en cours de route. Le coût ne dépend pas du nombre de fois où vous lui parlez, mais du nombre d’appels et de la longueur du contexte. Dans la répartition, l’essentiel venait de la relecture de la conversation et des sous-agents tournant sur le même modèle que la conversation principale. Mettez les sous-agents sur Sonnet, gardez des conversations courtes avec /compact ou une nouvelle session, et écrivez un point d’arrêt dans vos consignes.

FAQ

Q. Puis-je essayer les sessions cloud sans GitHub ?

R. Oui. claude --cloud "task description" empaquette et envoie votre dépôt local. Il doit faire moins de 100 Mo et contenir au moins un commit. L’historique de toutes les branches est envoyé, et la documentation officielle ne décrit aucun moyen de renvoyer directement les résultats vers un dépôt hors GitHub.

Q. Des dépôts d’organisations où je n’ai pas installé l’App apparaissent dans la liste. Y a-t-il une fuite ?

R. Pas s’il s’agit de dépôts publics. Quand vous vous connectez via la GitHub App, les sessions cloud peuvent utiliser tous les dépôts publics ; ils apparaissent donc comme options. Les dépôts privés ne sont utilisables que là où l’App est installée.

Q. Puis-je mettre une clé d’API dans une variable d’environnement ?

R. Je ne le recommande pas. La documentation officielle avertit que toute personne qui utilise un environnement peut lire ses variables d’environnement, et déconseille d’y mettre des secrets. Avec Pro et Max, vous pouvez plutôt l’enregistrer sous « API credentials », dont la session ne peut pas lire la valeur.

Q. J’ai choisi « Accept edits », mais il s’arrête à chaque commande.

R. C’est voulu. Dans le cloud, les modifications sont autorisées dans tous les modes ; le mode par défaut apparaît donc sous le nom « Accept edits ». Pour laisser les commandes s’exécuter sans approbation, choisissez Auto (il n’apparaît que si votre organisation l’autorise et que le modèle le prend en charge).

Q. Pourquoi le crédit baisse-t-il autant alors que je ne lui parle même pas ?

R. Parce que le coût ne dépend pas du nombre de fois où vous parlez, mais du nombre de fois où Claude appelle le modèle et de la quantité de contexte qu’il lit à chaque fois. Quand il tourne en autonomie, chaque lecture de fichier, écriture de fichier et exécution de tests déclenche un appel, et le contexte ne cesse de grossir. Dans mon cas, une seule consigne a consommé 226 $ avant que je l’arrête en cours de route (section 5).

Q. Le crédit à durée limitée peut-il aussi servir à cela ?

R. Oui. Le crédit de Pro et Max (Pro 100 $, Max 250 $) s’applique automatiquement à l’utilisation des sessions cloud, et tant qu’il dure, cette utilisation n’est pas décomptée des limites d’utilisation de votre forfait. Vous pouvez le réclamer jusqu’au 7 octobre, heure du Pacifique (États-Unis), et il expire à la fin du 4 novembre (le 5 novembre à 16 h 59, heure du Japon). Il ne peut pas servir pour Projects, Routines, Remote Control, etc. Pour plus de détails, voir l’article d’aide officiel et « Que sont les sessions cloud de Claude Code ? »

Sources

• Documentation officielle de Claude Code : Use Claude Code in the cloud (y compris la section « Send local repositories without GitHub »)
• Documentation officielle de Claude Code : Get started with cloud sessions
• Documentation officielle de Claude Code : Configure cloud environments
• Documentation officielle de Claude Code : Permission modes
• Documentation officielle de Claude Code : Manage costs effectively
• Documentation officielle de Claude Code : Create custom subagents
• Centre d’aide Claude : Cloud sessions bonus credit promotion
• GitHub Docs : Managing deploy keys et Error: Key already in use

Toutes les spécifications officielles ont été vérifiées par rapport au texte original le 4 octobre 2026. Le compte rendu de configuration provient d’un seul essai sur un seul de mes projets, et ce qu’affichent les écrans peut changer selon les versions et avec le temps.