Le Mac qui ne dort pas

Ce que c'est et pourquoi ça compte

Claude Code peut travailler pendant des heures même quand vous n'êtes pas là. Un soir, je le lui ai vraiment écrit : « Je vais dormir, tu as les pleins pouvoirs. » Le lendemain matin, le build était en ligne.

Mais ça ne marche que si vous lui laissez trois choses : un objectif clair, un moyen de vérifier lui-même son travail et une limite à ce qu'il peut toucher.

Sans objectif, il tourne en rond. Sans vérification, il vous raconte que tout va bien. Sans limites, il peut faire des dégâts. Avec les trois, le matin vous trouvez le travail et une liste de décisions à valider, pas de surprises.

1. Le message du soir

Je l'écris dans la session Claude Code ouverte sur le projet, comme dernier message avant d'aller me coucher. Copiez-le et remplissez les parties entre [ ].

Je vais dormir. Tu as les pleins pouvoirs sur ce travail, jusqu'à demain matin.

OBJECTIF
[Une seule phrase, concrète. Ex. : "La nouvelle page des tarifs, en ligne sur le site de test".]
Tu as fini quand : [ex. "la page s'ouvre sur le téléphone et les boutons mènent au paiement de test"].

COMMENT TU VÉRIFIES TOI-MÊME
- Lance les tests après chaque modification et ne continue pas si l'un d'eux échoue.
- Ouvre la page dans le navigateur et fais une capture d'écran de chaque écran terminé.
- Ne me dis pas "fait" sans la preuve : la commande que tu as utilisée et le résultat.

LIMITES (ce que tu ne peux PAS toucher)
- La vraie base de données, les données des utilisateurs, les vrais paiements.
- Ne supprime pas de fichiers, ne publie rien sur l'App Store, ne change pas les clés.
- Si pour avancer tu dois faire l'une de ces choses : arrête-toi et écris-le-moi.

SI TU ES BLOQUÉ
Essaie deux pistes différentes. Si aucune ne marche, écris où tu t'es arrêté et passe à la partie suivante.

DEMAIN MATIN
Laisse-moi un résumé : ce que tu as fait, ce que tu as décidé seul et pourquoi, ce dont tu as besoin de ma part.

Comment remplir les parties entre [ ]

• Objectif : une seule chose. « Arrange le site » n'est pas un objectif. « La nouvelle page des tarifs, en ligne sur le site de test », si.
• « Tu as fini quand » : écrivez ce que vous verriez, de vos propres yeux, si le travail était fait. C'est la ligne qui lui dit quand s'arrêter.
• Les tests doivent déjà exister et passer avant que vous alliez dormir. Si vous n'en avez pas, le travail de cette nuit peut être justement de les écrire.
• Claude ne peut faire les captures d'écran que s'il a un moyen d'ouvrir le navigateur, par exemple connecté à Chrome. Sinon, enlevez cette ligne ou mettez à la place une vérification qu'il peut faire depuis le terminal.

2. Avant d'éteindre la lumière

Si le Mac se met en veille, Claude s'arrête aussi. Avant de coller le message, je fais quatre choses :

1. J'enregistre tout avec un commit. Comme ça, le lendemain matin, je ne vois dans les modifications que le travail de la nuit.
2. Je branche le chargeur.
3. Je laisse l'ordinateur portable ouvert. Fermer le capot le met en veille, même avec les réglages qui le gardent éveillé.
4. J'empêche la mise en veille. Dans l'application de bureau Claude, il y a l'option Keep computer awake, dans Settings > This computer > System. Depuis le terminal, j'utilise une commande que le Mac a déjà : caffeinate.

Depuis le terminal, je lance Claude Code comme ça :

caffeinate -i claude

caffeinate -i garde le Mac éveillé tant que Claude Code reste ouvert. Quand vous le fermez, le Mac se comporte de nouveau comme d'habitude. L'écran, lui, peut s'éteindre, ça ne change rien.

3. Ne le laissez pas bloqué à attendre un oui

En mode Manual, Claude Code vous demande la permission avant la plupart des modifications et des commandes. La nuit, ça veut dire qu'à la première question il reste planté là jusqu'à votre réveil.

C'est pour ça qu'avant d'aller dormir, je regarde dans quel mode je suis. Dans le terminal, vous le changez avec Shift+Tab et vous le voyez écrit sous le prompt. La nuit, j'utilise l'un de ces deux :

• auto : Claude travaille sans rien vous demander, et un second modèle contrôle les actions avant qu'elles ne s'exécutent, en bloquant celles qui sont risquées (déploiements en production, suppressions en masse, force push). Il tient compte aussi des limites écrites dans le message. Si vous ne le trouvez pas avec Shift+Tab, votre compte ou votre modèle ne l'a pas : utilisez l'autre.
• acceptEdits : il accepte de lui-même les modifications de fichiers et quelques commandes de base, comme créer ou déplacer des dossiers. Pour les autres commandes, il demanderait, donc il va de pair avec les règles allow que vous voyez plus bas, pour le laisser lancer au moins les tests.

Une chose à savoir sur le mode auto : s'il bloque une action 3 fois de suite, ou 20 fois au total, il se met en pause et Claude recommence à vous demander la permission. Si le matin vous le trouvez arrêté sur une question, regardez ce qu'il voulait faire : c'est justement une des décisions qui vous reviennent.

Celui qui saute toutes les permissions (bypassPermissions), en revanche, je ne l'utilise pas : la documentation dit de ne l'utiliser que dans des conteneurs ou des machines virtuelles isolés, pas sur votre Mac.

4. De vraies limites : règles et hooks

Une règle écrite dans le message est une demande ; un hook est un mur. La documentation le dit aussi, avec d'autres mots : les permissions sont appliquées par Claude Code, pas par le modèle. Ce que vous écrivez dans le message oriente ce que Claude essaie de faire, mais ne change pas ce qui lui est permis.

Les règles allow et deny

Ce sont des lignes dans le fichier .claude/settings.json du projet. Allow : ce que Claude peut faire sans demander. Deny : ce qu'il ne peut jamais faire, dans aucun mode. Si quelque chose est à la fois dans allow et dans deny, c'est deny qui gagne. Vous pouvez aussi les voir et les modifier en tapant /permissions dans Claude Code.

Dans la journée, je demande à Claude de les préparer :

Ajoute au fichier .claude/settings.json de ce projet une règle allow pour lancer les tests sans me demander, et des règles deny pour : git push, les commandes rm, les modifications du fichier .env. Montre-moi le fichier avant de l'enregistrer.

Ça doit donner à peu près ça (à la place de npm test, mettez la commande de test de votre projet) :

{
  "permissions": {
    "allow": ["Bash(npm test *)"],
    "deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Edit(./.env)"
    ]
  }
}

Attention : une règle bloque la commande écrite de cette façon, pas le même programme lancé sous une autre forme. C'est pour ça que les limites restent aussi dans le message, et il vaut mieux que les vraies clés ne soient pas du tout dans le projet.

Le hook sur les commandes dangereuses

Un hook est une commande que Claude Code lance tout seul à un moment précis. Celui qu'il vous faut ici s'appelle PreToolUse : il se déclenche avant que Claude utilise un outil, par exemple avant chaque commande dans le terminal. Le script regarde la commande et, s'il se termine avec le code 2, Claude Code la bloque et transmet la raison à Claude, pour qu'il prenne un autre chemin. Le hook bloque aussi les commandes qu'une règle allow laisserait passer.

Vous n'avez pas à l'écrire vous-même. Je le demande à Claude, toujours dans la journée :

Crée un hook PreToolUse pour ce projet, dans .claude/settings.json, qui bloque les commandes Bash contenant : rm -rf, git push --force, [la commande avec laquelle vous publiez votre app]. Le script doit se terminer avec le code 2 et écrire la raison du blocage. Ensuite, teste-le : montre-moi qu'une commande interdite est vraiment arrêtée et qu'une commande normale passe.

Ensuite, je tape /hooks dans Claude Code et je vérifie qu'il apparaît dans la liste, sous PreToolUse.

5. Le lendemain matin

La première chose que je lis, c'est le résumé, surtout la partie « ce que tu as décidé seul ». C'est là que se trouvent les choses à valider. Ensuite, je relance moi-même une des commandes qu'il a utilisées comme preuve : si j'obtiens un résultat différent, cette preuve ne compte pas.

Et dans la même session, je demande :

Montre-moi la liste des fichiers que tu as modifiés cette nuit. Pour chaque décision que tu as prise seul, dis-moi ce qui se passe si je l'annule.

Les erreurs les plus courantes

• Le laisser en mode Manual : à la première demande de permission, il s'arrête jusqu'au matin. Avant de partir, choisissez le mode et préparez les règles allow.
• Un objectif vague, du genre « améliore l'app » : il travaille toute la nuit et vous ne savez pas sur quoi. Écrivez une seule chose, avec la ligne « tu as fini quand ».
• Fermer le capot ou le laisser sur batterie : le Mac se met en veille ou se décharge en pleine nuit. Laissez-le ouvert, branché au chargeur, avec caffeinate ou l'option qui le garde éveillé.
• Se fier uniquement aux limites écrites dans le message : ce sont une demande, et dans une longue conversation elles peuvent se perdre. Pour ce qui ne doit jamais arriver, mettez une règle deny ou un hook.

Check-list

• Un objectif en une phrase et la ligne « tu as fini quand »
• Les tests existent et passent avant le début de la nuit
• Tout enregistré avec un commit avant la nuit
• Mode choisi : auto, ou acceptEdits avec les règles allow
• Règles deny et hook testés dans la journée
• Chargeur branché, capot ouvert, Mac qui ne se met pas en veille
• Le message du soir collé, avec vos limites

Questions fréquentes