Comment restaurer une session cloud Claude Code Projects ? Planification de capacité 2026

Cet article explique comment reprendre une session Claude Code Projects après une coupure, un redémarrage ou un échec de tâche. Nous séparons les sessions, les threads parallèles, les fichiers, les dépendances, les artefacts, les builds et la marge de récupération afin de construire une estimation exploitable en 2026.

Cinq compteurs doivent être séparés dès le départ : sessions, threads parallèles, fichiers et dépendances, tâches de construction, puis marge de récupération. La documentation officielle confirme que les Projects peuvent associer des fichiers, des instructions, des conversations et une mémoire de projet ; elle décrit également les tâches exécutées dans le cloud avec Claude Cowork (détails officiels sur l’organisation des tâches). La restauration de session cloud Claude Code Projects ne doit donc pas être dimensionnée selon le seul nombre d’agents.

Verdict : adapté aux tâches longues, aux équipes qui lancent plusieurs agents et aux postes locaux sujets à la veille ou aux coupures réseau ; moins adapté à une courte tâche isolée, pour laquelle un environnement local léger reste généralement plus simple.

Cette analyse s’adresse aux développeurs qui doivent poursuivre des tâches Claude Code Projects alors que leur ordinateur local s’endort ou perd sa connexion. Elle concerne aussi les responsables de petites équipes qui font travailler plusieurs agents sur un même dépôt, ainsi que les administrateurs chargés de la capacité, des droits d’accès et de la reprise d’un espace de développement cloud.

Le bon modèle de capacité

Une session n’est pas une unité de stockage homogène. Il faut distinguer plusieurs états :

• Session active : l’agent produit une réponse, modifie des fichiers ou attend une action immédiate.
• Session en attente d’outil : le raisonnement est suspendu pendant un appel à un terminal, un dépôt, un service externe ou une tâche de construction.
• Session suspendue : le travail doit rester reprenable après une fermeture, une déconnexion ou un redémarrage.
• Tâche terminée à conserver : le résultat, les journaux, les changements et les décisions doivent rester disponibles pour audit ou reprise.
• Tâche échouée : l’état précédent doit être conservé avant une nouvelle tentative.

Cette distinction change le calcul. Une journée comportant beaucoup de petites demandes peut consommer moins de ressources qu’une seule tâche qui compile, teste, génère des captures et conserve plusieurs versions de sortie. Nous recommandons donc d’enregistrer le pic de concurrence, et non la moyenne quotidienne.

La formule de départ peut rester volontairement simple :

Capacité totale = état des sessions + environnement des projets + dépendances + fichiers générés + tâches de construction + marge de récupération.

La marge ne doit pas être ajoutée à la fin comme un pourcentage automatique. Elle doit correspondre à un événement concret : redémarrage du poste, nouvelle tentative après échec, restauration d’une branche, conservation d’un journal supplémentaire ou exécution temporaire d’un agent chargé du diagnostic.

Les dimensions à mesurer

Sessions et contexte

Pour chaque tâche, nous relevons quatre valeurs : la durée prévue, le nombre de changements de contexte, le volume de fichiers consultés et le volume de sorties à conserver. Le contexte de l’agent n’est pas identique au stockage du dépôt. Une conversation peut référencer beaucoup de décisions sans que toutes les données soient présentes comme fichiers locaux ; inversement, une compilation peut créer de nombreux fichiers sans enrichir la mémoire du projet.

Dans Claude Code Projects, il faut donc séparer :

1. les conversations et fils de travail ;
2. les instructions et la mémoire partagée ;
3. le dépôt Git ;
4. les modifications non validées ;
5. les résultats produits par les outils ;
6. les états de services externes.

Cette séparation est importante pour répondre à une question fréquente :

Comment reprendre une session Claude Code Projects après une coupure ?

La réponse fiable n’est pas de relancer immédiatement le même prompt. Il faut d’abord vérifier si le dernier état est encore identifiable : branche active, modifications locales, dernier journal d’outil, processus interrompu et état du service externe. Si l’un de ces éléments manque, la reprise peut provoquer une action répétée ou une correction appliquée sur une base déjà modifiée.

Projets, fichiers et dépendances

Les fichiers du projet doivent être calculés séparément des dépendances. Le dépôt contient le code source et les configurations ; les dépendances comprennent les bibliothèques téléchargées, les environnements virtuels, les caches de compilation et les images utilisées par les tests. Les artefacts regroupent quant à eux les journaux, captures, vidéos, paquets, rapports de couverture et fichiers générés.

Nous conseillons de créer un inventaire avec les colonnes suivantes :

Ce tableau ne fournit volontairement aucun chiffre de configuration ou de prix. Les ressources réelles dépendent du projet, du type de tâche et de l’environnement loué. La documentation de Git décrit toutefois clairement la différence entre un espace de travail et un worktree (documentation officielle de git worktree). Cette distinction permet d’éviter une erreur courante : plusieurs répertoires logiques ne signifient pas automatiquement que les fichiers physiques sont partagés.

Parallélisme et isolation

Agents séquentiels

Dans un scénario séquentiel, un agent analyse, modifie, teste, puis transmet la main. Cette organisation réduit la contention sur les fichiers et rend le retour arrière plus lisible. Elle convient à une migration délicate, à une refactorisation transversale ou à un projet audio et vidéo où les fichiers générés sont lourds et doivent être validés avant l’étape suivante.

Le principal coût n’est pas forcément le stockage. C’est le temps d’attente entre les étapes et la conservation des états intermédiaires. Si la session est longue, une interruption locale peut néanmoins faire perdre davantage de temps qu’un environnement persistant.

Agents en parallèle limité

Le parallélisme limité permet de séparer, par exemple, l’analyse des tests, la documentation et une correction ciblée. Nous recommandons que chaque agent possède une mission, une branche ou un répertoire clairement identifié. Le partage doit être explicite : dépendance en lecture seule, fichier de sortie dédié ou fusion contrôlée.

Les worktrees Git sont utiles lorsque plusieurs lignes de travail doivent coexister sans mélanger immédiatement les modifications. En revanche, ils ne suppriment pas le coût des fichiers dupliqués, des artefacts de compilation ou des caches distincts. Pour les fichiers volumineux, il faut mesurer la consommation réelle du système de fichiers plutôt que compter uniquement les branches.

Pic de parallélisme

Le pic apparaît lorsque plusieurs agents lancent au même moment une installation, une compilation, un test ou une génération de médias. C’est généralement là que le calcul basé sur le nombre d’agents devient trompeur. Deux agents qui lisent des fichiers peuvent avoir un impact limité ; deux agents qui compilent et écrivent simultanément peuvent saturer le processeur, la mémoire, le disque et la file d’attente réseau.

Nous enregistrons donc, pour chaque mode :

• l’usage processeur pendant l’analyse et pendant la construction ;
• la mémoire occupée par les outils, les serveurs et les caches ;
• les écritures et lectures du disque ;
• le trafic vers les dépôts et services externes ;
• la longueur de la file de construction ;
• le temps nécessaire pour arrêter proprement une tâche.

De combien d’espace cloud un développement Claude Code avec plusieurs agents a-t-il besoin ?

Il n’existe pas de réponse universelle basée uniquement sur le nombre d’agents. Nous partons du pic simultané, de la nature des outils et du besoin de reprise. Un scénario avec plusieurs agents légers et des dépendances partagées peut demander moins de capacité qu’un seul agent qui conserve des sorties de tests, des vidéos, des paquets et plusieurs instantanés.

La règle de décision est la suivante :

• si les agents travaillent sur des fichiers indépendants et que les constructions sont espacées, un parallélisme limité est raisonnable ;
• si plusieurs agents modifient les mêmes modules, il faut réduire le parallélisme et renforcer les points de sauvegarde ;
• si les tâches doivent survivre à une coupure, la persistance et la récupération priment sur l’ajout de nouveaux agents ;
• si les sorties sont volumineuses, la politique de conservation devient une décision de capacité à part entière.

Restauration et reprise contrôlée

État Git

Avant de redémarrer une tâche, nous vérifions la branche, les modifications non validées et les fichiers non suivis. git stash peut mettre temporairement de côté des changements de travail, mais il ne remplace pas une stratégie de validation ou de sauvegarde (documentation officielle de Git Stash). Il faut savoir si la tâche a déjà écrit un résultat avant de relancer l’agent.

Un protocole de reprise en cinq étapes limite les doublons :

1. Identifier le dernier événement confirmé : réponse finale, appel d’outil, commande terminée ou construction interrompue.
2. Lire l’état du dépôt : branche, différences, fichiers non suivis et éventuel verrou de processus.
3. Vérifier les sorties externes : paquet publié, migration exécutée, objet chargé ou commentaire envoyé.
4. Créer un point de retour : validation, copie, étiquette ou journal horodaté.
5. Relancer uniquement l’étape manquante : ne pas rejouer toute la chaîne si une partie est déjà terminée.

Processus et services externes

Une session restaurée ne garantit pas que le processus lancé avant la coupure fonctionne encore. Un serveur local peut avoir été arrêté ; un service distant peut avoir accepté la demande ; une tâche de construction peut avoir écrit un résultat partiel. Les secrets et les variables d’environnement doivent être vérifiés séparément, car ils ne doivent pas être confondus avec la mémoire du projet.

Pour les dépendances persistantes, les volumes de conteneur ont un cycle de vie différent de celui du conteneur lui-même ; la documentation Docker explique ce comportement dans sa présentation des volumes persistants. Cette différence est essentielle lorsqu’un agent recrée un environnement après redémarrage : le conteneur peut être neuf alors que les données doivent rester disponibles.

Artefacts et nettoyage

Les journaux et fichiers de sortie sont nécessaires au diagnostic, mais leur conservation illimitée transforme chaque échec en dette de stockage. Les systèmes d’intégration continue distinguent généralement la production d’un artefact et sa conservation ; la documentation GitHub décrit cette logique pour les artefacts de flux de travail, ainsi que leur suppression manuelle.

Nous recommandons une politique par catégorie :

• conserver les journaux d’échec jusqu’à la clôture du diagnostic ;
• conserver plus longtemps les rapports nécessaires à une comparaison ;
• supprimer les sorties reproductibles après validation ;
• archiver séparément les médias, paquets et captures importants ;
• documenter qui peut supprimer ou restaurer ces fichiers.

La restauration de session cloud Claude Code Projects échoue souvent non pas parce que la conversation est absente, mais parce que le dépôt, les artefacts ou le service externe ne correspondent plus au dernier état décrit par la conversation.

Procédure de calcul opérationnelle

Pour préparer un espace de développement cloud, nous suivons cette séquence :

1. Lister les tâches par durée et par poids : interaction courte, analyse longue, construction, génération de médias, tests et maintenance.
2. Marquer le pic simultané : sessions actives, sessions suspendues et tâches en attente de reprise.
3. Mesurer le projet proprement : code, dépendances, caches, sorties, journaux et fichiers non suivis.
4. Décrire l’isolation : dépôt partagé en lecture, branche séparée, worktree ou copie complète.
5. Évaluer les phases lourdes : installation, compilation, tests, encodage et génération de fichiers.
6. Définir la reprise : point de sauvegarde, journal, vérification externe et responsable de la relance.
7. Ajouter la marge de récupération : nouvelle tentative, diagnostic et restauration simultanée, sans confondre cette marge avec le fonctionnement normal.
8. Répéter le calcul sur le pire créneau : le scénario à retenir est celui qui combine la plus forte concurrence, les fichiers les plus lourds et la conservation la plus longue.

Pour un administrateur, cette méthode doit être transcrite dans un tableau mensuel : pic de sessions, pic d’agents, volume de fichiers, volume d’artefacts, durée de conservation et nombre de reprises réussies. Les ressources doivent être réévaluées lorsqu’un projet ajoute des tests, des modèles, des médias ou une nouvelle étape de construction.

Les environnements cloud ont eux aussi des règles de suspension et d’expiration. À titre de comparaison méthodologique, la documentation GitHub explique le cycle de vie d’un espace cloud et les réglages de délai d’inactivité. Cela rappelle qu’un espace distant n’est pas automatiquement permanent : il faut vérifier ses règles de veille, ses volumes persistants et la façon dont une session reprend après arrêt.

Arbitrage local, cloud et Mac distant

Le poste local reste pertinent pour une tâche courte, une modification isolée ou un projet qui doit accéder directement à des interfaces physiques. Il évite la dépendance à une connexion distante et simplifie certains tests graphiques. En revanche, il devient fragile lorsque l’ordinateur dort, lorsque le réseau change ou lorsque plusieurs agents doivent continuer sans présence humaine.

Un environnement cloud générique peut être souple, mais il ajoute souvent quatre contraintes : durée de vie variable, accès réseau à contrôler, stockage persistant à configurer et environnement graphique parfois limité. Une machine distante dédiée simplifie la continuité et convient mieux aux projets qui combinent outils de développement, tests visuels, traitement audio ou vidéo et sessions longues. Pour comparer les modalités sans inventer de tarif, nous vous recommandons de consulter les options de location de Mac cloud de ZekVPS, puis de rapprocher la capacité affichée de votre propre tableau de pics.

Pour une équipe située en Asie, le choix du nœud peut aussi influencer la latence des outils, des dépôts et des services externes. Il faut examiner séparément la région, le mode de livraison, le cycle de location et les règles de conservation ; une région proche ne compense pas une mauvaise stratégie de reprise. Les informations contractuelles doivent être vérifiées dans les conditions d’utilisation de ZekVPS.

Si le poste actuel est un ordinateur local, ses faiblesses sont concrètes : il peut interrompre les tâches pendant la veille, perdre une connexion pendant une commande longue et manquer d’espace lorsque les artefacts s’accumulent. Un environnement cloud partagé peut, de son côté, mélanger les caches et les branches si l’isolation n’est pas définie. Pour des tâches temporaires, des tests de capacité ou une équipe qui doit maintenir un espace actif pendant l’absence des développeurs, louer un Mac avec ZekVPS offre un cadre plus cohérent qu’un poste qui doit rester allumé en permanence. La décision reste à prendre après le calcul du pic, de la durée et de la marge de récupération ; elle n’est pas justifiée pour une charge stable à très long terme qui serait mieux servie par un achat maîtrisé, ni pour un besoin d’interface physique locale.

Commencez par remplir six champs : concurrence maximale, durée de la tâche, taille du dépôt, dépendances, volume d’artefacts et stratégie de reprise. Si le total dépasse régulièrement les limites de votre poste ou si une coupure oblige à recommencer une construction entière, un espace Mac distant persistant devient une option à comparer sérieusement.