Tout ce que vous avez appris jusqu'ici s'est joué dans un terminal ouvert, vous devant, l'agent sous vos yeux. Cette image est déjà datée. Un agent correctement cadré (chapitre 3) et correctement vérifié (chapitre 6) n'a pas besoin qu'on le regarde travailler : c'est même la définition d'un agent.
Ce chapitre déplie tout ce que cette idée débloque, dans l'ordre où vous l'adopterez probablement : d'abord le téléphone, puis les sessions parallèles, puis plus de session du tout. Le bureau devient une option.
- Le téléphoneLa session lancée au bureau ne meurt pas quand vous fermez le capot.
- Les sessions parallèlesSi l'agent n'a pas besoin de vous en continu, pourquoi n'en faire tourner qu'un ?
- Plus de session du toutL'agent devient un collègue qui prend son poste à heure fixe, sans qu'on le lui rappelle.
Le bureau dans la poche
Claude Code ne vit pas que dans votre terminal : il existe aussi sur le web et sur mobile, via claude.ai/code. Trois gestes deviennent possibles depuis un téléphone : lancer une session sur l'un de vos dépôts, suivre et piloter une session démarrée au bureau, puis relire et merger la PR produite, directement depuis GitHub sur mobile.
Le deuxième geste est celui qui change le plus les journées. Vous partez en réunion pendant que Claude déroule le plan validé, vous jetez un œil depuis le couloir, vous répondez à sa question bloquante depuis le téléphone, et le travail repart.
La relation change de nature : vous ne surveillez plus un outil, vous suivez un collaborateur à distance, comme vous suivriez un développeur en télétravail.
Un exemple vécu, sans mise en scène. Il y a quelques semaines, entre deux rendez-vous client, un message m'arrive : sur une application que je maintiens, l'écran de commande affiche une erreur pour certains créneaux. J'avais vingt minutes devant moi et pas d'ordinateur.
Depuis mon téléphone, j'ai lancé une session sur le dépôt, décrit le symptôme, et exigé la méthode du chapitre 6 : diagnostic d'abord, puis un correctif couvert par un test qui capture le bug. Le temps de rejoindre mon rendez-vous à pied, Claude avait trouvé la cause, écrit le test, poussé une PR.
Je l'ai relue depuis GitHub sur mobile, demandé un ajustement du message d'erreur, attendu le retour au vert, mergé. Le tout avant que la réunion commence. Rien de spectaculaire dans ce déroulé, et c'est exactement le point : la surprise n'est pas que ce soit possible, c'est à quel point c'est banal une fois la méthode en place.
Plusieurs Claude en parallèle
Boris Cherny, le créateur de Claude Code, travaille lui-même avec plusieurs sessions en parallèle, chacune sur son sujet. L'outil qui rend cette pratique propre est un vétéran de git : les worktrees. Un worktree donne à chaque session son propre checkout du dépôt : même historique, dossiers séparés, aucun risque que deux agents s'écrasent mutuellement leurs fichiers.
❯ git worktree add ../site-article feat/article-blog ❯ git worktree add ../site-panier fix/panier-vide Deux dossiers, deux branches, zéro conflit. ❯ # Un terminal par dossier, un Claude par terminal. ❯ cd ../site-article && claude # session 1 : rédige ❯ cd ../site-panier && claude # session 2 : corrige Chaque session travaille sur sa propre copie du dépôt.
Le parallélisme n'est pas qu'une affaire de débit. Le pattern le plus utile est le duo écrivain/relecteur : une session écrit la fonctionnalité, une autre session, vierge de tout le contexte de l'auteur, relit le diff avec le regard critique du chapitre 8. Vous savez déjà pourquoi cette séparation compte : le contexte de l'auteur contamine le regard du relecteur, chez l'IA comme chez l'humain. Deux sessions, deux postures, un angle mort en moins.
Un mot de prudence tout de même : le parallélisme se mérite. Deux sessions mal cadrées produisent deux fois plus de travail à reprendre, pas deux fois plus de valeur. La bonne progression est celle du guide : maîtrisez d'abord une session propre, du brief à la vérification, puis seulement dupliquez le geste.
Votre vraie limite ne sera pas la machine, ce sera votre capacité à relire sérieusement ce que plusieurs agents produisent en même temps.
Sans écran du tout : headless, CI, cron
Dernier étage : plus de session interactive du tout. Le mode headless tient en une commande : claude -p "votre prompt" exécute la demande et rend la main. Une commande comme une autre, donc scriptable : dans un alias, dans un script, dans une CI.
Et parce qu'un script a besoin de lire ce qui sort, la commande sait rendre autre chose que de la prose : --output-format json renvoie un objet unique dont vous extrayez le résultat, --output-format stream-json une ligne JSON par événement, à consommer au fil de l'eau. C'est ce qui sépare un agent qu'on regarde d'un agent qu'on branche sur une chaîne qui existait avant lui.
C'est aussi ce qui permet de lancer un agent en arrière-plan et de passer à autre chose : il vous notifie quand c'est prêt.
❯ claude -p "Corrige le lint sur src/ et ouvre une PR" & Session lancée en arrière-plan. ❯ # Vous passez à autre chose. Plus tard, la notification : Session terminée : 14 fichiers corrigés, lint vert, PR #212 ouverte, prête pour relecture. Vous n'avez rien regardé, et rien ne vous a manqué.
Deux actions GitHub officielles industrialisent le geste. claude-code-action fait intervenir l'agent sur vos issues et vos pull requests : on lui confie un ticket, il propose le correctif. claude-code-security-review rejoue le rôle d'expert sécurité du chapitre 8, automatiquement, sur chaque PR : la revue de sécurité cesse d'être un événement pour devenir un péage obligatoire, que la PR vienne d'un humain ou d'un agent.
Et puisque claude -p est une commande comme une autre, une tâche planifiée suffit pour installer des rituels : un cron qui lance la veille du matin, un autre qui compile le rapport quotidien du projet.
Le fan-out : cent fichiers, cent sessions
Il reste un usage du mode headless que peu de gens trouvent seuls, et c'est celui qui transforme une migration de trimestre en après-midi. Puisque claude -p traite une demande puis rend la main, rien n'interdit de l'appeler en boucle, une fois par fichier, chaque appel repartant d'un contexte vierge.
La grosse migration cesse alors d'être une session épique qui déborde de la fenêtre. Elle devient cent petites tâches indépendantes, chacune exactement de la taille que le chapitre 5 recommande.
❯ claude -p "Liste les fichiers encore en classes" > liste.txt 87 fichiers listés. ❯ for f in $(cat liste.txt); do ❯ claude -p "Convertis $f en composant fonctionnel. ❯ Réponds OK ou ÉCHEC." --allowedTools "Edit,Bash(npm test *)" ❯ done 84 OK, 3 ÉCHEC à reprendre à la main. Chaque fichier a eu son contexte neuf. Aucun ne paie le poids des quatre-vingt-six autres.
Deux précautions séparent le fan-out du carnage. Rodez le prompt sur deux ou trois fichiers avant de lâcher la boucle sur les quatre-vingts : ce que vous corrigez au troisième vous épargne quatre-vingts reprises. Et bornez les outils avec --allowedTools, puisque personne ne validera les permissions à votre place pendant que ça tourne.
Vous reconnaissez l'idée du chapitre 4, vue d'un autre côté : c'est la frontière qui autorise le volume. Là-bas, elle rendait possibles plusieurs chantiers de front ; ici, elle rend possible la même tâche répétée cent fois sans que la centième paie le contexte des quatre-vingt-dix-neuf premières.
Les garde-fous
Un agent hors de votre regard obéit à une règle simple : moins vous surveillez, moins il doit pouvoir. Concrètement, quatre ceintures.
Une remarque avant de les dérouler, car elle vaut aussi pour vos sessions ordinaires : ces réglages ne servent pas qu'à l'automatisation. Le dixième clic d'approbation d'une session interactive n'est plus une validation, c'est un réflexe, et un réflexe ne protège personne. Trois réponses existent et se combinent : autoriser une bonne fois les commandes que vous savez sûres, isoler l'exécution dans une sandbox, ou passer en mode auto, où un modèle classificateur examine chaque commande et ne bloque que ce qui sort du cadre. Vous rendez la surveillance sélective au lieu de la rendre continue, ce qui est la seule façon de la garder honnête.
- 01 · Permissions restreintesL'agent qui corrige du lint en CI n'a aucune raison de pouvoir tout faire.
- 02 · AllowlistsÉnumérer les commandes autorisées plutôt que d'interdire au cas par cas.
- 03 · SandboxIsoler l'exécution de ce qui compte.
- 04 · BudgetPlafonner ce qu'une session autonome peut dépenser. Le chapitre 10 vous a appris à payer juste ; hors surveillance, le plafond n'est plus une optimisation, c'est une ceinture de sécurité.
Questions fréquentes sur Claude à distance
Peut-on utiliser Claude Code depuis son téléphone ?
Oui. Claude Code existe sur le web et sur mobile, via claude.ai/code. Depuis un smartphone, vous pouvez lancer une session sur un de vos dépôts, suivre et piloter une session démarrée au bureau, puis relire et merger la PR produite depuis GitHub sur mobile. La condition pour que ce soit confortable n'est pas matérielle, elle est méthodologique : des tâches bien cadrées et des critères de vérification exécutables, comme aux chapitres 5 et 6, pour pouvoir juger sur le diff et le vert des tests.
Comment automatiser une revue de PR avec Claude ?
Deux actions GitHub officielles couvrent le besoin. claude-code-action fait intervenir l'agent sur les issues et les pull requests du dépôt : on lui confie un ticket ou une relecture, il produit sa réponse dans le fil. claude-code-security-review effectue une revue de sécurité automatique sur chaque PR, dans la posture adversariale de l'expert sécurité du chapitre 8. Dans les deux cas, restreignez les permissions du workflow au strict nécessaire : une revue lit un diff, elle n'a aucune raison de pouvoir écrire.
Qu'est-ce que le mode headless de Claude Code ?
C'est l'exécution sans session interactive : claude -p "votre prompt" lance la demande, la traite et rend la main. Comme c'est une simple commande, elle se met partout où un script passe : alias, CI, tâche planifiée par cron pour une veille ou un rapport quotidien, agent en arrière-plan qui notifie quand le travail est prêt. La contrepartie est disciplinaire : permissions restreintes, allowlists, sandbox et budget plafonné, puisque personne ne regarde l'agent pendant qu'il agit.
La suiteAu chapitre 12, Claude sort du code : des vidéos écrites en code avec Remotion, des visuels, de la voix et du montage, produits avec la même méthode de brief, de vérification et d'itération que tout le reste du guide.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe