Accueil > Articles > Claude Code pendant la nuit : qui garde la main ?

Tech · Déléguer sans disparaître

Claude Code pendant la nuit : qui garde la main ?

Programmer le travail de Claude Code, c’est aussi décider de ses droits et de la manière dont on acceptera son résultat.

Une heure de déclenchement ne fait pas un critère de réussite.

TechClaude Code15 janvier 2026
Illustration générée par IA : tapisserie brodée montrant une horloge, un atelier de nuit et une personne examinant une pièce de tissu.
Illustration générée par IA : un atelier imaginaire pour distinguer le déclenchement du travail et son examen.

Il y a quelque chose de très séduisant dans l’idée de retrouver, le matin, un travail accompli pendant notre sommeil. Les dépendances vérifiées, les petites anomalies repérées, un compte rendu prêt à lire. Avec un assistant de programmation, cette promesse ressemble vite à celle d’un collègue qui prendrait le relais.

Korben présente Claude Code Scheduler, un plugin qui permet de programmer des tâches pour Claude Code. Je trouve l’idée intéressante précisément parce qu’elle paraît modeste : ajouter une heure et une répétition à une demande. Mais le mot « automatique » recouvre ici plusieurs décisions qui n’ont rien d’équivalent.

Choisir le moment où un programme démarre, lui permettre de modifier des fichiers et décider que son résultat est bon : ce sont trois affaires différentes. Les confondre, c’est donner à une horloge une autorité qu’elle n’a pas.

Une horloge, pas un nouveau cerveau

Le projet est développé par jshchnz : il ne s’agit pas d’un composant officiel d’Anthropic. Son README décrit un fonctionnement assez concret. Une demande formulée en langage naturel sert à préparer une tâche ; son déclenchement est ensuite confié aux outils du système : launchd sur macOS, crontab sous Linux, le Planificateur de tâches sous Windows.

Autrement dit, le langage courant facilite la préparation du rendez-vous. Il ne remplace pas le mécanisme qui compte les heures. La consigne « vérifie les dépendances chaque mardi » doit finir sous une forme que l’ordinateur sait exécuter, dans un dossier déterminé, avec une commande déterminée.

Le code qui construit cette commande appelle Claude en mode non interactif avec une instruction. Ce n’est pas une deuxième intelligence chargée de surveiller la première. Le planificateur lance le travail prévu ; il ne transforme pas une demande vague en critère de réussite.

La procédure d’ajout de tâche prévoit d’ailleurs une confirmation du calendrier et des prochaines échéances. C’est un bon endroit pour garder les yeux ouverts. Une phrase comprise de travers peut devenir une erreur régulière, bien plus ponctuelle que nous.

Le rendez-vous suppose une machine disponible

Le recours au système d’exploitation a un intérêt réel : la tâche enregistrée n’a pas besoin que la conversation avec Claude reste ouverte. Mais survivre à un redémarrage ne signifie pas travailler pendant que l’ordinateur est éteint. Le rendez-vous peut persister sans que toutes les conditions de son exécution soient réunies.

Sous Windows, Microsoft documente un réglage distinct, WakeToRun, pour réveiller une machine en veille ou en veille prolongée. L’adaptateur Windows du plugin ne montre pas la configuration de ce réglage. Je n’en déduis donc aucune promesse de réveil automatique.

Il reste aussi des choses très terre à terre : l’emplacement de Claude dans l’environnement d’exécution, les droits sur les fichiers, le bon répertoire de travail. Une commande qui fonctionne dans un terminal ouvert ne constitue pas, à elle seule, la preuve qu’elle fonctionnera dans le contexte d’une tâche programmée.

Avant de multiplier les rendez-vous, je commencerais par une tâche minuscule et une exécution contrôlée. Pas pour mesurer une prétendue productivité nocturne : pour vérifier que le résultat apparaît au bon endroit, que les erreurs sont visibles et que l’on sait arrêter la répétition.

Moins de confirmations, davantage de pouvoir

Le point délicat arrive quand on veut éviter toute interruption. Le plugin peut ajouter l’option nommée --dangerously-skip-permissions. Ce nom mérite d’être lu jusqu’au bout : on ne choisit pas simplement une heure plus commode, on contourne les demandes de permission de Claude Code.

Cela ne donne pas magiquement tous les droits du système à la commande. Cela ne crée pas non plus une enceinte protectrice autour d’elle. Les droits du compte qui exécute le programme restent une limite ; à l’intérieur de ce périmètre, retirer des validations peut néanmoins rendre possibles des actions que l’on aurait refusées en étant présent.

Dans son texte sur le cloisonnement de Claude Code, publié en octobre 2025, Anthropic distingue justement les permissions et les limites imposées aux accès aux fichiers et au réseau. Un bac à sable cherche à contenir les effets d’une commande. Supprimer une question de confirmation ne remplit pas cette fonction.

Je séparerais donc deux demandes : « prépare-moi un diagnostic » et « modifie ce que tu juges nécessaire ». Elles peuvent viser le même dossier, pas le même niveau de délégation. La confiance dans une consigne ne remplace pas la définition de ce que l’outil a le droit de toucher.

Un journal rempli n’est pas un travail réussi

Le projet prévoit des journaux et un historique d’exécution. C’est utile pour retrouver une sortie ou comprendre un incident. Ce n’est pas l’équivalent d’une relecture du travail : un assistant peut produire beaucoup de texte, terminer sans incident apparent et se tromper sur ce qu’il devait vérifier.

Un détail du module d’historique rend la distinction très concrète. Sa fonction de reconstruction depuis les fichiers de journaux peut classer une exécution comme réussie parce qu’un fichier de sortie n’est pas vide, ou selon la présence de certains mots dans un fichier d’erreurs. Ce classement ne teste pas le fonctionnement du logiciel modifié.

Il ne faut pas en conclure que tous les résultats du plugin seraient faux. Il faut simplement lire le voyant pour ce qu’il mesure. Une trace d’exécution répond à « quelque chose s’est-il passé ? ». Des tests ciblés, une comparaison des fichiers et une relecture répondent à des questions différentes.

Pour une vérification de dépendances, j’attendrais par exemple une liste précise des éléments examinés et des anomalies constatées. Pour une correction, je voudrais voir les changements et les contrôles effectués. Ce sont des exigences à définir dans le travail confié, pas des garanties que l’étiquette « planifié » fournirait toute seule.

Déléguer un périmètre, pas une inquiétude

L’usage qui me paraît le plus convaincant commence petit : un rapport sur un dossier connu, une comparaison limitée, une préparation à relire. On peut alors décider à l’avance ce qui doit être produit et reconnaître assez vite une réponse hors sujet.

À l’inverse, « occupe-toi de la sécurité du projet toutes les nuits » est une belle manière de déplacer son inquiétude sans préciser le travail. Quels fichiers ? Quelles vérifications ? Quelle réaction si une anomalie apparaît ? Une répétition quotidienne ne répond à aucune de ces questions.

Le gain éventuel dépendra aussi du temps consacré à relire, corriger et entretenir la consigne. Je ne compterais pas chaque minute passée hors du clavier comme une minute économisée. Une tâche facile à contrôler peut être utile ; une tâche qui exige de tout revérifier peut surtout déplacer l’effort au lendemain.

Claude Code Scheduler ajoute donc une commodité réelle : ne plus avoir à être là pour demander que le travail commence. Ce qui m’intéresse maintenant, c’est la suite. Au matin, saurons-nous expliquer ce qui était autorisé, ce qui a été fait et pourquoi nous acceptons le résultat ?