Claude Code dans le cloud : toutes les configs, sans le marketing

Il y a un moment précis où j’ai compris que quelque chose avait changé dans ma façon de travailler. J’étais dans le train, téléphone à la main, et une tâche que j’avais lancée depuis mon bureau tournait toujours, sur une machine qui n’était pas la mienne, dans un dépôt que je n’avais même pas cloné localement. Mon PC était éteint depuis deux heures.

Claude Code, à la base, c’est un outil en ligne de commande qui tourne sur votre machine, dans votre dossier. Depuis un moment, il peut aussi tourner ailleurs : sur l’infra d’Anthropic, ou sur votre propre serveur. Entre le terminal, l’application Desktop, le web, le mobile et le VPS, on s’y perd un peu. Alors j’ai pris le temps de démêler tout ça : les configurations possibles, comment brancher GitHub proprement, à quoi ça sert vraiment, et surtout les limites.

Les différentes configurations

Le nom « Claude Code » désigne aujourd’hui plusieurs choses qui se ressemblent mais ne font pas la même chose.

C’est là que la plupart des articles se plantent, et moi le premier, dans ma première version de cet article : ils listent « les modes de Claude Code » en mélangeant l’endroit où le code s’exécute et l’endroit d’où on le pilote.

Clarifions donc nos deux axes. Le premier, l’exécution, répond à la question « quelle machine fait le travail ? » :

• Votre machine — accès total à vos fichiers, vos outils, votre réseau local. Le mode historique, et toujours le plus puissant.
• Le cloud d’Anthropic — une VM isolée et jetable, qui clone votre dépôt GitHub. Rien à installer, mais elle ne voit que ce dépôt.
• Votre VPS — votre propre serveur. Environnement sur mesure et accès à vos services, en échange de la casquette d’admin sys.

Le second, le pilotage, répond à « d’où j’appuie sur les touches ? » : le terminal, l’app Desktop (diff visuel, sessions parallèles, éditeur intégré), le web sur https://claude.ai/code, ou l’application mobile.

Et c’est en croisant les deux qu’on y voit enfin clair :

✅ mode natif, prévu pour ça  ·  ⚠️ possible mais limité  ·  🔧 débrouille, non documenté officiellement

Deux enseignements sautent aux yeux. D’abord, chaque exécution a son pilotage « naturel » : le terminal pour le local et le VPS, l’App Desktop pour le cloud. On peut sortir de ces cases, mais on perd en confort. Ensuite, la ligne « Votre VPS » est volontairement pleine de bricolage : c’est la config la plus libre, et celle qu’Anthropic n’a pas vraiment prévue pour vous. Assumé.

Je me souviens la première fois que j’ai lancé un fix dans le cloud sur un projet Open Source (Gladys Assistant). Claude Code a créé une branche, analysé le bug, proposé un fix que j’ai validé, implémenté le fix et créé la PR. Depuis mon téléphone, sans écrire une ligne de code. J’ai alors compris l’intérêt de ces sessions Cloud pour des cas d’usages précis, moins puissant que claude dans le terminal mais beaucoup plus confortable.

Mini-tuto : brancher GitHub proprement

C’est le point de passage obligé. Une session cloud n’a pas accès à votre disque dur, elle doit donc récupérer le code quelque part. Ce quelque part, c’est GitHub.

Étape 1 — Connecter son compte

Rendez-vous sur claude.ai/code (ou sur l’App Desktop) et lancez la connexion GitHub. Vous installez l’application GitHub d’Anthropic, et, point important, vous choisissez à quels dépôts elle a accès. Résistez à la tentation du « All repositories ». Sélectionnez les dépôts un par un. C’est deux minutes de plus, et ça vous évite de donner un accès en écriture à l’intégralité de votre vie numérique.

Étape 2 — Comprendre les permissions demandées

L’application réclame essentiellement deux droits :

• Contents (lecture + écriture) : lire les fichiers, créer des branches, pousser des commits.
• Pull requests (lecture + écriture) : préparer et suivre les PR.

Oui, c’est de l’écriture. Non, ce n’est pas négociable si vous voulez que Claude pousse quoi que ce soit. D’où l’importance de l’étape 1.

Étape 3 — Lancer, et garder la main sur le merge

Vous décrivez la tâche, Claude clone le dépôt dans sa VM, travaille, teste, commite. Et voici le comportement que je trouve très bien pensé : par défaut, il ne crée pas la pull request tout seul. Il pousse sur une branche et vous renvoie un lien vers une page de création de PR pré-remplie. Il peut aussi créer la PR vers votre repository ou le respository original en cas de fork si vous lui demandez.

Pourquoi c’est malin ? Parce que ça respecte vos règles de protection de branche, et surtout ça garde un humain sur le dernier bouton. Vous relisez le diff, vous décidez. C’est exactement le garde-fou que je réclamais dans mon article sur l’IA générative : l’outil produit, l’humain valide.

Étape 4 (optionnelle) — L’environnement

Une VM vierge ne connaît pas vos dépendances. Si votre projet a besoin d’un npm install, d’une version précise de Node ou de variables d’environnement, prévoyez un script de setup ou un fichier de dev container dans le dépôt. Sans ça, Claude va lire votre code mais échouera à lancer vos tests, et une session qui ne peut pas tester, c’est une session qui code à l’aveugle.

Un mot sur l’isolation

Chaque session tourne dans une VM isolée, séparée de votre machine et des autres sessions. L’accès réseau est restreint par défaut et passe par un proxy obligatoire que le bac à sable ne peut pas contourner : seules des destinations autorisées sont joignables. Et vos identifiants Git ne sont pas placés à l’intérieur du sandbox. Vous pouvez jouer sur l’accès Internet dans les paramètres de l’environnement Cloud

C’est une architecture sérieuse, pensée pour qu’un agent autonome ne puisse pas partir avec vos secrets. À nuancer tout de même : même réseau coupé, la session communique avec l’API d’Anthropic, donc des données peuvent sortir de la VM par ce canal. Ce n’est pas une faille, c’est le principe même de l’outil. Mais autant le savoir avant d’y balancer du code sensible ou des secrets.

Les cas d’usage parfaits pour Claude Code à distance

Après avoir joué avec, voilà où le cloud apporte quelque chose que le local ne fait pas :

• Le parallélisme. C’est le gain numéro un. Lancer trois tâches sur trois sujets différents pendant que vous continuez sur un quatrième. En local, vous êtes limité par votre machine et votre attention ; là, vous devenez chef d’orchestre.
• Le dépôt qu’on n’a pas cloné. Une correction rapide sur un projet secondaire, sans utiliser git clone, l’installation des dépendances et les vingt minutes de mise en route. Vous décrivez, ça se fait.
• Les tâches longues et ingrates. Migration d’une dépendance, renommage massif, ajout de tests sur un module oublié. Le genre de corvée qu’on lance et qu’on va vérifier plus tard.
• Loin de sa machine. Lancer depuis le téléphone, suivre l’avancement, relire le diff le soir. C’est mon scénario du train du début de l’article.
• Le code auquel on ne fait pas confiance. Explorer un dépôt inconnu dans une VM jetable plutôt que sur son poste, c’est objectivement plus sain.

Les limitations (parce qu’il y en a)

Maintenant, la partie que les articles enthousiastes oublient soigneusement.

1. Le transfert ne marche que dans un sens. Vous pouvez rapatrier une session cloud dans votre terminal avec --teleport. L’inverse, pousser une session locale en cours vers le web, n’est pas possible. Il faut donc décider assez tôt où la tâche doit vivre.

2. La VM ne connaît que votre dépôt. Pas d’accès à votre base de données locale, à votre NAS, à vos services internes, à ce fichier de config qui traîne hors du dépôt. Tout ce qui vit à côté du dépôt n’existe pas pour elle. Pour un projet un peu intégré, c’est bloquant et c’est précisément là que l’option VPS reprend l’avantage.

3. Le réseau restreint peut freiner. L’allowlist qui vous protège vous gêne parfois : un paquet à récupérer sur un registre privé, une API à appeler pour tester.

4. Les quotas. Tout part du même pot. Votre usage sur le web, le desktop, le mobile et Claude Code puise dans les mêmes limites (fenêtres glissantes de quelques heures + plafonds hebdomadaires selon le plan). Et depuis mi-2026, l’usage autonome (agents en headless, intégrations CI, SDK) est comptabilisé à part de l’usage interactif. Multiplier les sessions parallèles, c’est donc consommer plus vite. Aucune optimisation possible comme RTK.

Pendant une session, Claude avait besoin de lire le code du backend pour modifier le frontend. Après avoir tourné en boucle pendant 10 minutes à essayer de récupérer le backend et de le lancer, je l’ai arrêté.

La voie du milieu : Claude Code sur votre propre VPS

Il y a une troisième option dont on parle beaucoup moins, et qui devrait parler aux habitués de ces pages : faire tourner Claude Code sur votre serveur. Ni votre portable, ni l’infrastructure d’Anthropic. Votre VPS, accessible en SSH.

Si vous avez suivi ma série sur le projet Voskos, vous voyez déjà où je veux en venir. C’est la même philosophie : plutôt que de louer le service de quelqu’un d’autre, on héberge soi-même et on garde la main.

Pourquoi faire ça ?

• L’environnement est le vôtre. Vos versions, vos outils, vos dépendances, installés une fois pour toutes. Fini le script de setup à maintenir pour une VM jetable.
• L’accès à vos services. C’est le gros point faible du cloud d’Anthropic : la VM ne voit que votre dépôt. Sur votre VPS, Claude peut atteindre votre base de données, vos conteneurs, vos API internes.
• Pas d’allowlist réseau. Un registre privé, une API à interroger, un paquet exotique : ça passe.
• Ça tourne 24/7. Comme le cloud, mais chez vous. Vous fermez le portable, ça continue.

Le piège de l’authentification headless

Premier obstacle, et il surprend tout le monde : la connexion à Claude Code passe normalement par un navigateur (OAuth). Or votre VPS n’a pas d’interface graphique. Vous vous retrouvez donc à devoir vous authentifier… sans navigateur.

Deux solutions, par ordre de simplicité :

1. Un token OAuth généré ailleurs. Sur votre machine locale (qui, elle, a un navigateur), vous générez un token de longue durée avec claude setup-token, puis vous l’installez sur le VPS dans la variable d’environnement CLAUDE_CODE_OAUTH_TOKEN. C’est la voie normale quand on a un abonnement Pro ou Max.
2. Une clé API. Si vous êtes en facturation à l’usage via la Console, un simple ANTHROPIC_API_KEY suffit. Le plus direct, mais le modèle de facturation n’est pas le même.

Prévoyez aussi un peu de ressources : comptez 4 Go de RAM minimum pour que ça tourne bien.

Faire survivre la session

Deuxième réflexe indispensable. Si vous lancez claude directement dans votre SSH et que la connexion saute, votre session meurt avec elle. Frustrant quand la tâche tournait depuis vingt minutes.

La solution est vieille comme Unix : un multiplexeur de terminal (Tmux ou Screen).

# Créer une session nommée
tmux new -s claude

# Lancer Claude Code dedans, puis se détacher : Ctrl+b puis d
# La connexion peut sauter, ça continue de tourner.

# Plus tard, depuis n'importe où :
ssh mon-vps
tmux attach -t claude

Vous pouvez même connecter l’app Desktop à cette session

⚠️ La sécurité

C’est le point où il faut être sérieux deux minutes. Sur le cloud d’Anthropic, vous héritez d’un bac à sable pensé pour contenir un agent autonome : VM isolée, réseau filtré, identifiants Git tenus hors du sandbox. Sur votre VPS, ce filet n’existe pas. Vous mettez un agent capable d’exécuter des commandes sur une machine qui est, par définition, exposée à Internet. Respectez donc les normes de sécurité (utilisateur dédié, clé SSH, …)

Bref : c’est la config la plus puissante, et de loin la plus exigeante. Vous gagnez le contrôle, vous héritez de la responsabilité. C’est le deal habituel du selfhosting.

J’ai toujours une session qui tourne sur mon NAS à la maison, prêt à démarrer un Claude Code sur un des projets actifs. Accessible via Tailscale depuis n’importe où. Je l’utilise pour les longues sessions ou quand je sais que dois faire tourner le serveur avec une base de données.

Alors, quelle config choisir ?

Résumons :

• Travail de fond, projet complexe, accès à vos services → CLI local ou Desktop. Le cloud ne remplace pas ça.
• Tâches parallèles, corvées, dépôt non cloné → sessions cloud, sans hésiter.
• Suivi en mobilité → cloud + consultation depuis le mobile.
• Piloter sa propre machine à distance → Remote Control, mais en gardant en tête que le PC doit rester allumé.
• Besoin de vos services, d’un environnement sur mesure, ou simple goût du contrôle → VPS perso. À condition d’assumer la casquette d’admin sys.

Mon avis

Ce qui m’a le plus marqué, ce n’est pas la prouesse technique, faire tourner un agent dans une VM, on sait faire depuis longtemps. C’est le changement de posture. On passe de « j’utilise un agent sur mon ordinateur » à « je délègue et je vérifie depuis n’importe où ».

Et ça change la façon dont je découpe mes journées. Avant, je me demandais « qu’est-ce que je peux faire maintenant ? ». Maintenant je me demande d’abord « qu’est-ce que je peux lancer ? », puis je m’occupe de ce qui requiert vraiment mon cerveau pendant que le reste avance. La migration de dépendances, le renommage massif, les tests sur ce module oublié : tout ça tourne pendant que je fais autre chose. C’est bête, mais c’est exactement le genre de gain qu’on ne mesure qu’après coup, quand on se rend compte qu’on a arrêté de repousser les corvées.

L’autre bonne surprise, c’est la liberté de composer son propre setup. Rien ne vous force à choisir un camp. Vous pouvez rester puriste du terminal, prendre le confort du Desktop pour relire un diff, envoyer les tâches longues dans le cloud, et garder votre VPS pour ce qui touche à vos services. Chacun sa recette, et on peut en changer selon le moment. Pour un outil aussi jeune, c’est suffisamment rare pour être souligné — et c’est très exactement l’esprit qui m’a fait monter Voskos : ne pas dépendre d’une seule façon de faire.

Alors oui, il reste des angles morts, et je les ai listés plus haut sans les enjoliver. Mais on tient là quelque chose de rare : un outil qui s’adapte à votre manière de travailler plutôt que l’inverse. Mon PC peut rester éteint — le boulot, lui, continue d’avancer. Franchement, je ne reviendrai pas en arrière.

Et vous, vous l’utilisez comment ? Vous êtes plutôt terminal, Desktop, cloud ou serveur perso ? 👇

Sources & documentation

• Doc officielle — Use Claude Code on the web
• Doc officielle — Application Desktop
• Doc officielle — Remote Control
• Anthropic Engineering — Sandboxing de Claude Code
• Doc officielle — Sécurité
• Claude — Plans et tarifs (pour les quotas à jour)
• Doc officielle — Dev containers (pour isoler sur votre serveur)
• Authentifier Claude Code sur un VPS headless
• Run Claude Code on a VPS : install, secure, persist