Planifier Claude Code : Cloud, Desktop ou /loop
Choisissez Cloud, Desktop ou /loop pour Claude Code, testez les fichiers et le déclenchement, puis vérifiez la veille, la reprise de session et l’annulation.
Sommaire

Commencez par localiser les données et déterminer si la tâche doit tourner lorsque l’ordinateur est éteint. Un fichier local exige l’accès à votre machine ; un contrôle de dépôt sans ordinateur allumé nécessite un environnement cloud distinct. Pour une courte surveillance pendant le travail actuel, /loop peut suffire.
Un horaire enregistré ne prouve ni l’accès aux fichiers, ni l’exécution, ni l’existence d’un résultat vérifiable.
Choisir le lieu d’exécution
| Condition | Cloud routine | Local task Desktop | /loop en session |
|---|---|---|---|
| Environnement | Cloud | Votre ordinateur | Session Claude Code active |
| Ordinateur éteint | Oui | Non | Non |
| Fichiers locaux | Données à rendre accessibles au cloud | Adapté | Adapté |
| Après redémarrage | Horaire conservé | Horaire conservé | Reprise des tâches inachevées, non expirées et admissibles |
Cloud utilise normalement un clone du dépôt choisi, pas votre dossier local actuel. Desktop accède aux fichiers locaux, mais l’application doit rester ouverte et l’ordinateur éveillé. Voir la documentation Desktop pour ces conditions et le choix du dossier.
Tester d’abord une exécution manuelle
Préparez un petit projet avec un README.md sans secrets et gardez-en une copie. Pour Cloud, commitez ce fichier dans le dépôt de test sélectionné. Utilisez la même consigne :
Ouvre uniquement README.md dans le projet sélectionné.
Renvoie la première ligne non vide et le nombre de titres de niveau deux
commençant par "## ". Si le fichier manque, signale-le.
Ne modifie aucun fichier, ne lance aucune commande shell et n’envoie aucun message.
Commence la réponse par SCHEDULE_CHECK.
Vérifiez vous-même la ligne et le compte, puis l’absence de modifications. Ce test porte sur l’accès et la clarté. La consigne exprime une intention ; les capacités réelles dépendent de l’environnement et des permissions des outils.
Si le fichier reste inaccessible, le calendrier n’y changera rien. Corrigez le projet, l’accès ou le chemin avant de tester le déclencheur.
Un /loop explicite pour un contrôle court
Dans la session CLI actuelle :
/loop 5m Lis uniquement README.md. Réponds avec SCHEDULE_CHECK et la première ligne non vide. Ne modifie aucun fichier, ne lance aucune commande et n’envoie aucun message.
Notez l’intervalle confirmé et l’ID. Attendez une réponse automatique, demandez la liste des tâches et annulez précisément cet ID. Relisez la liste pour confirmer sa disparition.
L’intervalle n’est pas un minuteur exact : un décalage est possible et une session occupée exécute plus tard. Les tâches récurrentes expirent après sept jours. Une nouvelle conversation ne les reprend pas ; --resume ou --continue restaure uniquement les tâches admissibles non expirées. Voir le guide /loop.
Fournissez toujours la consigne de test. Un /loop vide peut lancer une procédure intégrée de maintenance du travail actuel plutôt que votre essai README.
Desktop pour les fichiers locaux
Dans Routines, créez une Local task, choisissez le dossier et collez la consigne. Utilisez d’abord Run now, examinez le résultat et les demandes de permission. Activez ensuite l’horaire et vérifiez une autre exécution automatique dans l’historique.
Après la veille, Desktop peut rattraper une exécution au réveil : il retient le dernier horaire manqué dans les sept jours, pas chaque itération. Définissez les données à traiter en cas de retard. Un contrôle quotidien peut lire les changements d’une date précise plutôt que prendre l’heure réelle pour le début d’une nouvelle journée de rapport.
Passez en Paused après l’essai. Distinguez exécution manuelle, automatique, omission et attente de permission. Run now valide l’exécution, pas à lui seul le calendrier.
Cloud quand l’ordinateur peut être éteint
Si votre compte dispose des Cloud routines, créez-en une dans Routines, sélectionnez dépôt et environnement, ajoutez uniquement les connectors nécessaires, puis la consigne et l’horaire. Testez Run now, puis une session planifiée distincte.
La routine s’exécute de façon autonome, sans demandes ordinaires de permission pendant l’exécution. Dépôts, réseau, variables d’environnement et connectors déterminent l’accès. Le test README n’a besoin ni de messagerie professionnelle ni de publication. Voir Routines.
Désactivez la répétition après le test. Gardez ID, horaires prévu et réel, lien du résultat et motif d’omission éventuel. Remplacez ensuite la consigne par votre tâche et revérifiez entrées, permissions et résultat. Cloud ou Desktop détermine où le travail tourne ; la tâche doit être validée séparément.