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.
La boucle de Ralph : le même prompt jusqu'au vert
Le fan-out répète une tâche sur cent fichiers. Son symétrique existe : répéter cent fois le même prompt sur une seule tâche, jusqu'à ce qu'elle soit vraiment finie. La technique porte un nom, la boucle de Ralph (d'après Ralph Wiggum, le personnage des Simpson), et un auteur, le développeur Geoffrey Huntley, qui l'a résumée en une ligne de shell : une boucle infinie qui renvoie PROMPT.md à l'agent, encore et encore.
Le mécanisme mérite qu'on s'y arrête, parce qu'il a l'air absurde et qu'il ne l'est pas. Vous savez depuis le chapitre 2 que l'agent ne se souvient de rien d'une session à l'autre. Mais son travail, lui, persiste : dans les fichiers, dans l'historique git. À chaque tour, l'agent relit le même prompt, découvre l'état dans lequel sa tentative précédente a laissé le code, et reprend là où elle s'est arrêtée.
La mémoire n'est pas dans la session : elle est dans le dépôt.
Tout repose alors sur la condition de sortie, et vous la connaissez déjà : c'est le critère de done exécutable du chapitre 6. Le prompt doit contenir la preuve exigée (« tous les tests passent ») et une promesse de complétion que l'agent n'a le droit d'écrire que quand cette preuve est faite. Ajoutez un plafond d'itérations, parce que sans ces deux garde-fous, la boucle est réellement infinie. Dans Claude Code, un plugin fait tout le montage : /ralph-loop intercepte chaque fin de session et renvoie le prompt tant que la promesse n'apparaît pas.
❯ /ralph-loop "Fais passer les 12 tests de checkout. ❯ N'écris <promise>VERT</promise> que si npm test passe." ❯ --completion-promise "VERT" --max-iterations 15 · Itération 1... 8/12 verts. L'agent veut s'arrêter : le hook le relance avec le même prompt. Itération 2 : 11/12. Itération 3 : 12/12, npm test vert. <promise>VERT</promise> détectée : la boucle s'ouvre. 3 itérations, zéro intervention.
Réservez la boucle aux tâches qui la méritent : un objectif bien défini, un critère de succès mesurable, du raffinement itératif. Pour tout ce qui demande un choix de design ou du jugement, elle est le mauvais outil : elle convergera avec entêtement vers une cible que personne n'a validée.
Le rituel de la donnée : votre analyste à heure fixe
Les rituels planifiés croisés un peu plus haut méritent un exemple complet, et le meilleur n'est pas du code : c'est la donnée produit. Savoir ce que les utilisateurs font vraiment tient en trois gestes que personne n'a le temps de faire, et qu'un agent fait très bien.
- Le plan de taggageAvant de mesurer, décider quoi mesurer : événements, propriétés, conventions de nommage. Claude, en casquette d'analyste (chapitre 8), connaît déjà le code : il propose les événements qui correspondent aux parcours réels et les implémente dans la foulée. Le plan et son implémentation sortent du même contexte : ils ne divergent pas.
- L'analyseDonnez-lui accès aux données : un export CSV suffit pour commencer, un accès en lecture à la base ou à l'outil d'analytics (MCP ou CLI, chapitre 9) fait mieux. Entonnoirs, cohortes, parcours qui fuient ; et le cas où il brille : le bilan d'un A/B test, avec la question qui fâche, « l'écart est-il significatif ou est-ce du bruit ? ». Exigez le calcul, les effectifs et l'intervalle, pas une impression.
- Le rituelUn cron, et l'analyste prend son poste tous les lundis : il lit la semaine écoulée, compare à la précédente, rédige le bilan et le poste là où votre équipe vit, sur Slack, dans Notion ou par mail, via un MCP ou un simple CLI.
❯ cat bilan-hebdo.sh # lancé par cron le lundi à 8 h claude -p "Lis les événements de la semaine dans data/events.csv, compare à la semaine précédente, rédige le bilan et poste-le sur Slack #cabinet." ❯ # Lundi, 8 h 03, sur Slack : Réservations : 142 (+12 %). A/B du bouton « Réserver » : variante B +9 %, significatif sur 1 830 visites. Point noir : 38 % d'abandons à l'étape du téléphone. Recommandation : rendre le champ optionnel, à retester.
Talia n'a pas de data analyst, et n'en aura jamais. Elle a mieux : un bilan qui arrive tout seul, qui dit où les patients butent, et qui lui laisse la seule partie du travail qui lui appartient : décider. La boucle est complète : le produit mesure, l'agent analyse, vous tranchez, et la recommandation retestée nourrit le bilan suivant.
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.
Qu'est-ce que la boucle de Ralph (Ralph loop) ?
Une technique d'itération autonome popularisée par Geoffrey Huntley : le même prompt est renvoyé à l'agent en boucle, et comme son travail persiste dans les fichiers et dans git, chaque tour reprend là où le précédent s'est arrêté, jusqu'à remplir le critère de sortie. Elle exige deux garde-fous : un critère de done exécutable assorti d'une promesse de complétion que l'agent n'écrit que quand la preuve est faite, et un plafond d'itérations. Dans Claude Code, le plugin ralph-loop monte la boucle en une commande ; la version artisanale tient en une ligne de shell autour du mode headless.
Claude peut-il analyser mes données produit ou mes A/B tests ?
Oui, à deux moments. En amont, il rédige le plan de taggage (événements, propriétés, conventions de nommage) puis l'implémente dans le code, ce qui garantit que le plan et la mesure coïncident. En aval, donnez-lui les données, un export CSV ou un accès en lecture à la base ou à l'outil d'analytics, et demandez le bilan : entonnoirs, cohortes, significativité d'un A/B test. Planifié par cron en mode headless, ce bilan devient un rituel : un rapport hebdomadaire posté sur Slack, dans Notion ou par mail. Exigez toujours les effectifs et le calcul derrière chaque conclusion.
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.
La suite par email
Recevez les prochains chapitres.
Les guides s'écrivent chapitre par chapitre et se révisent quand les outils bougent. Laissez votre email : un message à chaque publication ou révision majeure, rien d'autre.
Uniquement les publications des guides. Désinscription sur simple réponse.
Pour votre équipe
Ce guide existe aussi en formation.
Le guide donne la méthode, la formation l'installe : une à deux journées avec votre équipe, sur vos projets réels, avec un plan d'outillage à la fin.
Discutons de votre équipeDavid 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.