Claude Code permet maintenant de coder depuis votre téléphone. Voici ce que j'ai appris à mes dépens.
J'étais dans un taxi en route vers la plage quand l'email de Vercel est tombé.
Production en panne. Déploiement échoué.
J'ai fixé mon téléphone une seconde. Puis je me suis souvenu : Claude Code a maintenant une version web. Ça marche depuis mobile. Je voulais tester depuis un moment.
Alors j'ai fait le truc logique. J'ai ouvert Claude Code web, décrit l'erreur, et regardé un agent IA réparer mon système de production pendant que j'étais littéralement en route pour aller nager.
Trois minutes plus tard : correction faite, branche poussée, PR prête.
Je l'ai mergée depuis GitHub mobile.
Viva la Vida. 😎
Puis j'ai posé mon téléphone et je suis allé à la plage. Parce que c'est ce qu'on fait quand une IA gère votre infrastructure.
Dix minutes plus tard, Vercel a envoyé un autre email.
TL;DR : Oui, Claude Code Web permet de réparer la production depuis son téléphone. Oui, j'ai testé depuis un taxi. Oui, ça "marche". Le reste de cet article raconte ce qui s'est passé ensuite.
Voici ce que je n'ai PAS fait avant de merger : lancer git diff. Ou npm run build. Ou littéralement quoi que ce soit qui m'aurait pris trente secondes et épargné quarante minutes.
Pour ma défense, j'étais dans un taxi. Et la correction semblait raisonnable. Trois fichiers modifiés, un message de commit propre. Qu'est-ce qui pouvait mal tourner.
(Tout. Tout pouvait mal tourner.)
Le Container Ne Vit Pas Dans Votre Projet
Laissez-moi expliquer ce que Claude Code web fait réellement quand il prend une tâche, parce que les démos donnent l'impression que c'est magique et ce n'est pas le cas (c'est quelque chose de plus intéressant et plus limité à la fois).
Quand vous soumettez une tâche, Claude Code web lance un container cloud isolé tout frais, clone votre repository dedans, et se met au travail. Ce qu'il a : votre code. Ce qu'il n'a pas : votre fichier .env, vos packages locaux, votre version spécifique de framework, votre configuration de déploiement, et tout contexte des commits qui ont eu lieu avant qu'il débarque.
Il lit vos fichiers. Il lance des commandes. Il observe les erreurs que ces commandes produisent. Puis il corrige ce qu'il voit.
Le décalage est assez subtil pour passer inaperçu. L'IA n'a pas tort (elle diagnostique depuis un environnement différent de celui où votre code tourne réellement). Ses corrections sont cohérentes. Elles sont juste cohérentes avec un contexte qui ne correspond pas au vôtre.
Imaginez envoyer une photo de votre vélo cassé à un mécanicien par WhatsApp. Il regarde, dit "c'est la chaîne." Vous remplacez la chaîne. Le vélo ne marche toujours pas. Le vrai problème était le câble de frein (pas visible sur la photo). Le mécanicien était-il incompétent ? Non. Il a travaillé avec ce qu'il pouvait voir. Le reste lui était invisible.
Claude Code web, c'est le mécanicien. Votre repo sans contexte d'environnement, c'est la photo. Votre vrai bug de production, c'est le câble de frein.
Dans mon cas, ça s'est joué avec une précision impressionnante.
Tour de Mes Corrections Fantômes
Voici ce que le sandbox a documenté dans sa propre session, et voici ce qui se passait vraiment :
Correction #1 : Le swap de package de police.
Le sandbox a noté : "Le problème de déploiement le plus probable est l'échec du fetch Google Fonts pendant le build Turbopack. Passer à un package bundlé localement évite les requêtes réseau pendant le build."
Complètement logique. Dans un container isolé avec accès réseau sortant restreint, récupérer des polices depuis un CDN externe au moment du build échoue. Donc il a basculé vers une alternative bundlée localement. Malin.
Dans mon vrai environnement de production, l'import original marche parfaitement et marche depuis des mois. Le sandbox a corrigé un problème que je n'ai jamais eu, en utilisant une dépendance que je n'avais jamais installée. Cool. Merci.
Correction #2 : L'URL placeholder.
Variable d'environnement manquante dans le container → client planté au build → solution : ajouter un fallback vers une URL cloud morte pour que le build ne casse pas.
En production, la vraie variable existe. Donc le fallback ne ferait silencieusement rien, sauf si la variable venait à manquer (auquel cas l'app se connecterait discrètement nulle part au lieu de planter bruyamment).
Génial. Une correction qui marche correctement dans un environnement qui n'existe pas, et se dégrade silencieusement dans un environnement qui existe.
Correction #3 : L'initialisation lazy.
Celle-là était vraiment correcte. Instancier un client au moment du chargement de module cause de vrais problèmes avec le prerendering statique, peu importe les env vars. Le refactor vers une initialisation lazy est genuinement une meilleure pratique.
Une sur trois. Je prends.
Aucune des trois n'a touché à la vraie raison pour laquelle mon déploiement échouait.
Le Vrai Bug (C'était une Icône)
Quelques commits avant tout ça, j'avais ajouté un favicon custom. Un petit fichier, glissé dans un répertoire où le framework tournait. Ce que je ne savais pas : dans ma version de framework, placer un fichier avec ce pattern de nommage spécifique dans ce répertoire fait qu'il est traité comme un route handler, pas comme un asset statique. Le build était silencieusement cassé depuis ce commit.
Le sandbox ne l'a jamais mentionné. Pourquoi l'aurait-il fait (les erreurs dans ses logs de build étaient le fetch de police et la env var manquante). Le problème d'icône produisait un type d'échec différent, qui ne se montre que dans un environnement de build spécifique. Invisible depuis le container.
Quand j'ai finalement posé les fesses devant mon laptop et lancé un build local, la sortie pointait directement vers le fichier d'icône. Trente secondes pour identifier. Cinq minutes pour corriger.
Cette correction n'est pas dans la branche du sandbox. Elle ne pouvait pas y être. Le sandbox n'avait aucune idée qu'elle existait.
Donc pour récapituler : j'ai mergé une branche qui ajoutait une dépendance dont je n'avais pas besoin, introduisait un mode d'échec silencieux, et refactorisait correctement un truc (pendant que la vraie cause de ma panne de production restait intouchée, attendant que j'ouvre mon laptop comme un adulte).
Le Revert (Oui, J'ai Dû Reverter la Correction)
Le package de police bundlé localement n'était pas dans mes dépendances originales. Le sandbox l'avait ajouté. Donc après merge, lancer un build local a produit un tout nouvel échec : package listé comme dépendance, pas vraiment installé.
J'ai récupéré le fichier layout original depuis l'historique git. Supprimé le nouveau package. Réinstallé. Reverté l'URL placeholder vers un crash franc sur env var manquante (parce que si cette variable disparaît un jour en production, je veux une explosion bruyante, pas une connexion polie vers nulle part).
Gardé l'initialisation lazy. Celle-là avait mérité sa place.
Commit. Push. Déploiement propre.
Temps total écoulé entre "le laptop reste fermé" et "le laptop se referme" : quarante minutes. La plage était bien. Le debugging, pas du tout.
Trois Règles Qui Tiennent Vraiment
Traitez chaque branche de sandbox comme du code de quelqu'un qui n'a jamais lancé votre projet.
Pas parce que l'IA est mauvaise dans son boulot. Parce qu'elle n'a littéralement pas lancé votre projet (elle a lancé une reconstruction, à laquelle manquent les parties qui vivent en dehors de votre repository). Reviewez la diff. git diff main..origin/branch-name prend quinze secondes. Si vous voyez un nouveau package, une URL de fallback, une dépendance que vous n'avez pas mise là (le sandbox compensait quelque chose qu'il n'avait pas). Déterminez si ce quelque chose est réel avant que ça parte en prod.
Lancez un build localement avant de merger quoi que ce soit près de la config de build.
npm run build. Ou ce qui vous rapproche de votre vrai environnement de deploy. Cette seule étape aurait terminé toute mon aventure avant qu'elle commence. La correction fantôme de police aurait échoué immédiatement (package pas installé). Trente secondes de sortie terminal battent quarante minutes d'archéologie post-merge.
Les trois minutes que ça ajoute à votre workflow ne sont pas le goulot d'étranglement. Vous le savez. Admettez-le.
Donnez au sandbox votre environnement avant de lui confier une tâche.
L'écran de création de tâche de Claude Code web a un champ variables d'environnement. Collez vos vraies env vars là. Le container tourne maintenant avec quelque chose qui ressemble à votre vrai contexte. La plupart des corrections fantômes disparaissent. L'agent arrête de résoudre des problèmes que vous n'avez pas et commence à résoudre celui que vous avez vraiment.
La Version Honnête du Rêve
Parlons une seconde du fantasme "coder de n'importe où".
Personne ne veut vraiment débugger une panne de production sur une plage. Ce n'est pas un rêve, c'est une punition. Plisser les yeux sur un écran de téléphone en plein soleil, du sable dans le clavier, essayer de comprendre une stack trace. C'est un cauchemar avec un bon éclairage.
Le vrai rêve est différent. Pouvoir mettre en queue quelque chose et s'en aller. Lancer un refactor, le laisser tourner, revenir à un résultat. Cette partie marche. Claude Code web gère les tâches autonomes proprement (tout ce où cloner le repository donne à l'agent tout ce dont il a besoin). Écrire des tests. Nettoyer un composant. Mettre à jour la documentation. Renommer des trucs. Des tâches qui vivent entièrement dans le code, pas d'env vars requises, pas de bizarreries d'environnement de build.
Le workflow taxi-vers-plage se casse spécifiquement quand le problème est environnemental. Ce qui, il s'avère, est souvent le cas des échecs de déploiement en production.
Mettez la tâche en queue. Allez à la plage. Revenez et reviewez la diff sur votre laptop comme un professionnel.
C'est le vrai rêve. Le reste, c'est un tweet qui attend d'arriver. 😬
Même principe sous-jacent que vibe coding without constraints : une IA travaille de façon cohérente dans le contexte qu'elle a. Donnez-lui un contexte incomplet, et vous obtenez des solutions cohérentes au mauvais problème. Env vars dans le sandbox, build local avant merge, git diff avant approve (même mouvement à chaque fois). Vous ne combattez pas l'IA. Vous lui donnez votre réalité au lieu d'une photocopie.
Dans six mois, un devtool va livrer "intelligent sandbox context sync" comme feature premium. Il y aura une waitlist. L'email d'onboarding dira "codez de n'importe où."
Les développeurs qui lancent déjà un build local avant de merger n'en auront pas besoin.
Ils savent déjà ce que le container ne peut pas voir.
Ils sont déjà allés à la plage. Sans leur laptop. Exprès.
C'est le vrai futur du dev.
Ressources : Documentation Claude Code — Guide sandboxing Anthropic
J'écris sur la construction de systèmes de production avec des outils IA (les parties qui n'arrivent pas dans les threads de lancement). Pas de planning, pas de remplissage. Ça sort quand il y a quelque chose qui vaut le coup d'être dit.
(*)La cover est générée par IA. J'aurais pu aller à la plage au lieu de la prompter. Rétrospectivement, ça aurait été le choix le plus malin.
Comment réparer une infrastructure en production depuis un taxi ? Mon dernier article raconte comment Claude Code web m'a sauvé... et presque coulé.