Cela fait des mois que j’exécute des tâches avec Claude Code via un cron maison. Un script Bash qui lance une session headless, passe un prompt, attend la fin, et ferme. Ça marche. De celle manière, mais ça marche. Je l’ai mis sur GitHub au cas où ça intéresse quelqu’un.
Et vendredi, avec la version 2.1.71, Anthropic introduit /loop. Un scheduler natif. Directement dans la session Claude Code elle-même.
Ma première réaction : “Ils ont tué mon projet.”
Ma seconde réaction, après l’avoir testé : “Non. Mais presque.”
Ce que /loop fait
La syntaxe est simple :
/loop 5m check the deploy status
Cela dit à Claude Code : “toutes les 5 minutes, exécute ce prompt”. Sans quitter la session. Sans cron. Sans scripts. Claude analyse l’intervalle, programme la tâche et l’exécute tant que la session est ouverte et idle.
On peut enchaîner des slash commands :
/loop 20m /review-pr 1234
/loop 1h make test 2>&1 | tail -5
Chaque boucle a un filet de sécurité : elle expire automatiquement après trois jours. Parce qu’un cron oublié, ça fait partie des classiques douloureux.
À quoi ça peut servir
Je l’ai testé depuis un jour et j’ai déjà trouvé trois utilisations claires :
1. Surveiller des tests pendant le développement. Je suis sur Tokamak, en train d’implémenter quelque chose de gros (par exemple cinq étapes d’optimisation du cold start). Plutôt que de lancer make test à chaque souffle, voici ce que je fais :
/loop 10m make test 2>&1 | grep -E "passed|failed"
Si quelque chose casse, Claude m’en informe sans que je doive lever le petit doigt.
2. Babysitter un déploiement. Quand je pousse une nouvelle version et veux savoir immédiatement quand la CI est terminée :
/loop 3m gh run list --limit 1
3. Monitorer l’API des incidents. Aujourd’hui, j’ai corrigé un bug sur Tokamak, où les incidents de Claude Desktop s’affichaient sans rapport avec Claude Code. Pendant que je corrigeais, il aurait été utile d’avoir :
/loop 5m curl -s https://status.claude.com/api/v2/incidents/unresolved.json | python3 -c "import sys,json; print(len(json.load(sys.stdin)['incidents']), 'incidents')"
Ce que /loop N’EST PAS
Et voici les petites lignes. /loop est un scheduler dans la session. Attention aux implications :
- Il meurt avec la session. Si vous fermez le terminal, c’est fini. Aucune persistance.
- Il fonctionne uniquement en mode idle. Si Claude est occupé par une autre tâche, la boucle attend. Elle ne peut pas interrompre.
- Trois jours maximum. Vous ne pouvez pas garder une boucle active une semaine entière.
- Pas d’état entre exécutions. Chaque itération est un nouveau prompt. Aucune mémoire des itérations précédentes.
Pour le dire simplement : /loop est une sorte de watch sous stéroïdes. Ce n’est pas un cron.
Alors, à quoi sert un cron ?
Mon claude-cron fait quelque chose d’entièrement différent. Il lance une nouvelle session en mode headless, exécute le prompt et ferme. Il ne nécessite pas de terminal ouvert. Il n’a pas besoin de session active. Il fonctionne via launchd, cron ou systemd – tout ce que vous avez – et tourne même si vous dormez.
/loop | claude-cron | |
|---|---|---|
| Besoin d’une session ouverte | Oui | Non |
| Survit à la fermeture du terminal | Non | Oui |
| Durée maximale | 3 jours | Pas de limite |
| Cas d’utilisation idéal | “Surveille ça pendant que je travaille” | “Fais ça toutes les nuits à 3h” |
| Complexité | Aucune (une commande) | Script + launchd/cron |
Ils sont complémentaires. /loop pour l’éphémère, claude-cron pour le permanent.
Un exemple réel : j’ai un cron qui traduit chaque nuit les nouveaux articles de mon blog en quatre langues et les commit. Ça, /loop ne peut pas le faire. Je ne vais pas laisser un terminal ouvert toute la nuit juste pour qu’une boucle se souvienne de traduire à 3h.
Mais si je suis en train d’écrire un article et que je veux que Claude vérifie l’orthographe toutes les 15 minutes pendant que je le corrige… /loop est parfait. Pas besoin de monter une infrastructure pour quelque chose d’éphémère.
Le futur : les tâches programmées
Il y a un troisième acteur qui va compliquer les choses : les scheduled tasks de Claude Code et Cowork. Des tâches programmées qui s’exécutent en background, sans session, gérées par Anthropic. C’est d’ailleurs cela qui a causé l’incident du daylight saving time ce week-end (une boucle infinie cherchant des tâches à une heure inexistante).
Quand ce système sera mature, il risque bien de tuer claude-cron. Un scheduler natif, intégré avec l’authentification, sans scripts Bash, sans launchd. Mais c’est pour plus tard. Aujourd’hui, les scheduled tasks sont en preview et cassent tout à cause du changement d’heure. Mon script Bash est donc encore sur le banc pour un moment.
En résumé
/loop est un outil génial pour un cas d’utilisation spécifique : des tâches récurrentes mais éphémères dans une session de travail. Cela ne remplace pas un cron, mais cela élimine le besoin d’un cron pour 80 % des cas du quotidien.
Mon workflow maintenant : /loop pour surveiller des éléments pendant que je travaille, claude-cron pour les tâches nocturnes, et un œil sur les scheduled tasks pour quand Anthropic corrigera le changement d’heure.
Trois niveaux d’automatisation. Chacun à sa place. Parfois, la solution n’est pas de choisir un outil, mais de savoir quand utiliser chacun.