/loop et /schedule (boucles et routines)

TL;DR

Deux commandes pour automatiser la répétition côté Claude Code. /loop fait rejouer un prompt à intervalle régulier dans la session ouverte (laptop allumé, terminal vivant), utile pour des itérations courtes pendant que vous travaillez. /schedule crée une Routine cloud (research preview) qui tourne sur l'infrastructure Anthropic, même si vous êtes loin du clavier. Les deux partagent la même logique de prompt récurrent, mais répondent à des besoins très différents.

Pour qui c'est utile

Profils techniques qui tirent le meilleur parti de ces commandes :

• Développeurs en cycle court qui veulent attendre la fin d'un build, d'une CI ou d'un déploiement sans rafraîchir manuellement toutes les 30 secondes. /loop est conçu pour cette boucle d'attente active.
• Ingénieurs DevOps et SRE qui veulent surveiller un endpoint, un job ou un cluster pendant une plage donnée, sans installer un outil de monitoring tiers pour une mission ponctuelle.
• Data engineers et automatiseurs qui doivent rafraîchir un index, lancer un ETL nocturne, ou produire un rapport hebdo : /schedule remplace le cron classique par une routine pilotée par Claude (interrogation contextuelle, sortie raisonnée).
• Tech leads et reviewers qui veulent une revue de PR automatique en début de matinée, un résumé des merges de la veille, ou un triage des alertes nocturnes prêt au café.

Comprendre /loop et /schedule (la mécanique sous le capot)

Les deux commandes appartiennent à la même famille (un prompt qui se rejoue), mais leur infrastructure d'exécution est radicalement différente. Il faut bien les distinguer pour ne pas se tromper d'outil.

/loop est une boucle de session. Quand vous tapez /loop 5m vérifie l'état du déploiement, Claude Code convertit l'intervalle en expression cron locale et programme une ré-exécution du prompt dans la même session terminal. Le prompt s'insère entre vos tours de conversation, jamais en plein milieu d'une réponse en cours. Si vous fermez le terminal, la boucle s'arrête. Si la machine s'éteint ou se met en veille, la boucle s'arrête. Aucune infrastructure cloud derrière : c'est un planificateur local porté par le process Claude Code de votre session. Variante sans intervalle (/loop vérifie si la CI est passée) : Claude choisit lui-même la cadence entre 1 minute et 1 heure selon ce qu'il observe.

/schedule est une Routine cloud (research preview). Quand vous tapez /schedule daily PR review at 9am, Claude Code envoie la définition à claude.ai/code/routines avec le header expérimental experimental-cc-routine-2026-04-01. Au moment du déclenchement, une session Claude Code éphémère est instanciée côté Anthropic, exécute le prompt avec les connecteurs MCP que vous avez attachés, puis se ferme. Aucun lien avec votre laptop : la routine continue à tourner même si vous êtes en vacances. La contrepartie : c'est une preview, les triggers API et GitHub event s'ajoutent uniquement via l'interface web, et le comportement peut évoluer sans préavis.

Différence avec les Scheduled Tasks locales Cowork (fiche D4). Cowork (Desktop) propose aussi des tâches planifiées, mais elles s'exécutent localement, sous votre session Desktop, avec accès aux outils MCP installés sur votre machine. Bon pour la confidentialité locale ou les outils non exposés en cloud, mais dépendant que le Mac soit allumé.

Différence avec les Routines cloud côté Web (fiche SK6). Les Routines créées via l'interface web claude.ai/code/routines sont la même infrastructure que /schedule, mais avec un éditeur graphique : triggers API, GitHub event, gestion des secrets, transcripts visualisables. /schedule en CLI est la porte d'entrée rapide ; le web est la console d'administration.

Quand /loop vs /schedule vs cron classique

/loop brille dans ces cas : - Boucle d'attente active pendant que vous travaillez (build, CI, déploiement) - Itération sur un test qui échoue, vous corrigez, vous attendez le prochain run - Surveillance ponctuelle d'un endpoint pendant une heure

/schedule brille dans ces cas : - Tâche récurrente quotidienne ou hebdomadaire qui doit tourner même laptop fermé - Besoin d'un raisonnement contextuel à chaque run (résumer, trier, prioriser) - Intégration avec des MCP cloud (GitHub, Linear, Slack)

Un cron classique reste préférable dans ces cas : - Script déterministe sans besoin de raisonnement (rotation de logs, backup, sync de fichier) - Latence et coût critiques : un appel Claude coûte plus cher qu'un curl - Environnement on-premise sans appel sortant autorisé

Pas à pas détaillé

Lancer un /loop interactif

1. Ouvrez une session Claude Code dans le dossier de votre projet : claude puis attendez le prompt.
2. Tapez /loop 5m vérifie si le déploiement est terminé et résume ce qui s'est passé. Le 5m se lit cinq minutes ; vous pouvez écrire 30s, 1m, 1h.
3. Claude affiche la cadence interprétée, un identifiant de job à 8 caractères, et confirme.
4. Toutes les 5 minutes, le prompt se rejoue entre vos tours de conversation. Vous pouvez continuer à dialoguer normalement entre deux itérations.
5. Pour arrêter la boucle : appuyez sur Esc pendant qu'elle attend le prochain run, ou tapez /loop stop.

Créer une Routine via /schedule

1. Dans une session Claude Code, tapez /schedule daily PR review at 9am (récurrente) ou /schedule tomorrow at 9am, summarize yesterday's merged PRs (one-off).
2. Claude résout l'horaire dans votre fuseau local et demande les informations manquantes : nom de la routine, repo cible, environnement cloud, connecteurs MCP à attacher.
3. Confirmez les choix. La routine est sauvegardée sur votre compte et apparaît dans claude.ai/code/routines.
4. Au déclenchement, une session Claude Code cloud démarre, exécute le prompt, puis se ferme. Le transcript est conservé pour consultation.

Voir les runs et désactiver

5. Pour lister vos routines depuis le CLI : /schedule list. Vous voyez nom, cadence, prochain run, statut.
6. Pour ouvrir l'interface web : tapez l'URL claude.ai/code/routines dans un navigateur connecté à votre compte. Vous y trouvez le transcript de chaque run, les paramètres, et les options d'édition.
7. Pour désactiver temporairement : utilisez le toggle dans l'interface web, ou supprimez la routine via /schedule delete <id>.
8. Pour modifier le prompt ou la cadence : /schedule update <id> en CLI, ou édition complète via l'interface web.

Cas d'usage avec exemples concrets

Itération sur un test qui échoue. Vous corrigez une fonction et vous voulez relancer la suite à chaque sauvegarde. /loop 30s lance pnpm test et résume les erreurs restantes rejoue le test toutes les 30 secondes. Quand le test passe, Claude vous le signale dans la même session, vous tapez Esc pour arrêter.

Refresh quotidien d'un index. Vous maintenez un index sémantique de documentation qui doit se rafraîchir chaque nuit. /schedule daily at 3am, refresh the docs index by reading the latest changes in /docs and updating the embeddings via the configured MCP. La routine tourne en cloud à 3h du matin, sans dépendre de votre laptop. Vous lisez le transcript le matin.

Monitoring d'un endpoint. Vous attendez qu'un service tiers réponde 200 après une maintenance. /loop 1m curl -sf https://api.partenaire.example/health et alerte-moi quand la réponse change boucle pendant que vous faites autre chose. Dès que la sortie change, Claude vous le mentionne dans son tour suivant.

ETL nocturne. Vous extrayez des données depuis une source SaaS chaque nuit, vous les transformez, vous les déposez dans un entrepôt. /schedule every night at 2am, run the ETL pipeline: fetch from the configured MCP source, transform via the pipeline script, push to the destination, and post a summary to the Slack channel. La routine cloud exécute la chaîne avec les connecteurs MCP attachés.

À retenir

• /loop est une montre à votre poignet : ne tourne que tant que la session est ouverte, expire seule au bout de 7 jours.
• /schedule est une horloge dans le cloud : tourne même quand vous dormez, tant que vous ne la supprimez pas.
• Intervalle minimum : 1 minute pour /loop, 1 heure pour une routine cloud récurrente.
• Une Routine cloud agit sous votre identité : commits, messages, tickets apparaissent comme venant de vous. Vérifiez les permissions avant d'attacher des MCP sensibles.
• Le statut vert d'un run signifie « session terminée sans erreur d'infrastructure », pas « tâche réussie ». Toujours ouvrir le transcript pour valider.
• /schedule est en research preview : le comportement peut changer, ne pas déployer en production sans relecture régulière.

Pièges à éviter

• Research preview = instable. Les Routines portent le header expérimental experimental-cc-routine-2026-04-01. L'API, les quotas et les triggers peuvent évoluer sans préavis. Avant un usage critique, revérifier la doc officielle et prévoir un plan B (cron classique en parallèle).
• Idempotence non garantie par défaut. Si une routine échoue puis retente, certaines actions peuvent s'exécuter deux fois (commit doublé, mail envoyé en double, ligne insérée deux fois). Concevez le prompt pour vérifier l'état avant d'agir : « si la PR a déjà été commentée aujourd'hui, ne pas recommenter ».
• Credentials dans une Routine. Une Routine cloud agit sous votre identité avec les MCP attachés. Ne pas attacher de connecteurs ayant des droits trop larges (admin GitHub, owner Notion) si la routine se contente de lire. Préférez des comptes de service avec scopes restreints.
• Coût du quota. /loop consomme votre quota d'usage Claude tant qu'il tourne, même si vous oubliez de l'arrêter. /schedule consomme également votre quota à chaque run, et un plafond quotidien de runs par compte s'applique (les one-off ne comptent pas dedans). Faites le ménage sur claude.ai/code/routines au moins une fois par mois.
• Boucle infinie de session. /loop récurrent expire automatiquement après 7 jours, mais consomme votre quota pendant tout ce temps. Pensez à Esc quand le besoin disparaît.
• Session fermée = /loop perdu. Fermer le terminal arrête la boucle. claude --resume ne la relance que si elle n'a pas expiré et si la session reprend correctement.
• Triggers API et GitHub via web uniquement. /schedule en CLI ne crée que des routines planifiées (cron-like). Pour déclencher sur évènement API ou GitHub webhook, il faut passer par l'interface web.
• Désactivation par admin. Sur Team ou Enterprise, si l'admin a coupé le toggle Routines, vos routines existantes cessent de tourner et vous ne pouvez plus en créer.

Exercice 1 minute

Ouvrez une session Claude Code dans n'importe quel projet et tapez /loop 2m affiche l'heure courante et compte les fichiers Markdown modifiés depuis 10 minutes. Observez deux itérations, puis appuyez sur Esc pour arrêter. Tapez ensuite /schedule list pour voir si vous avez déjà des routines cloud actives sur votre compte. Si la liste est vide et que vous voulez tester, créez /schedule tomorrow at 9am, summarize yesterday's changes in this repo et supprimez-la juste après pour vérifier que le cycle de vie fonctionne.

Variantes par plan

• Free : pas d'accès aux Routines cloud. /loop reste disponible si vous avez Claude Code installé (vérifier la version avec claude --version, minimum v2.1.72).
• Pro : /loop et /schedule disponibles, plafond quotidien standard de runs cloud.
• Max : équivalent Pro avec un quota d'usage plus large, pertinent si vous comptez sur plusieurs routines actives.
• Team : Routines disponibles sauf si l'admin a désactivé le toggle Routines. Centralisation possible des routines partagées entre membres.
• Enterprise : équivalent Team, audit centralisé des runs, politiques de désactivation par organisation, possibilité de restreindre les MCP attachables.

Liens internes

• Feature liée : desktop/04-taches-planifiees-locales (fiche D4 : Scheduled Tasks locales côté Cowork Desktop, alternative locale à /schedule)
• Feature liée : skills-mcp/06-routines-cloud (fiche SK6 : vue complète des Routines cloud côté Web, triggers API et GitHub event)
• Feature liée : claude-code/01-cli-base (base d'usage Claude Code pour comprendre où ces commandes s'exécutent)
• Feature liée : modules/claude-code/05-mcp-integration.md (connecteurs MCP attachables à une Routine)