Routines Claude Code

Problème : Ton laptop doit rester ouvert pour que Claude Code fasse quoi que ce soit. Les tâches planifiées sur le bureau et /loop tournent en local, ce qui veut dire qu'un couvercle fermé tue chaque automatisation que tu as mise en place. Tu n'as pas non plus moyen de réagir à des événements externes comme une PR GitHub ou une alerte de monitoring sans polling.

Victoire rapide : Crée ta première routine cloud depuis la CLI et teste-la à la demande :

/schedule daily PR review at 9am

/schedule run

La première commande crée une routine qui clone ton repo sur le cloud d'Anthropic chaque matin et lance le prompt. La seconde la déclenche maintenant pour que tu puisses vérifier le résultat avant de faire confiance au planning.

Ce que sont les routines

Une routine regroupe trois choses : un prompt, un ou plusieurs dépôts GitHub, et un ensemble de connecteurs (serveurs MCP comme Slack, Linear, ou Datadog). Tu la configures une fois. Le cloud d'Anthropic l'exécute chaque fois qu'un déclencheur se produit.

Chaque run clone une copie fraîche de ton repo, lance une session Claude Code complète, et s'exécute de façon autonome. Pas de prompts de permissions. Pas de clics de validation. La session peut lancer des commandes shell, utiliser les skills committés dans le repo, et appeler chaque connecteur que tu as attaché.

Les routines sont sorties le 14 avril 2026 en preview de recherche. Le comportement et la surface d'API peuvent changer avant la GA.

Où vivent les routines

Trois surfaces créent et gèrent les routines. Toutes écrivent dans le même compte cloud.

Interface web sur claude.ai/code/routines. Contrôle complet sur chaque réglage : prompt, modèle, repos, environnement, déclencheurs et connecteurs.

CLI via /schedule. Crée uniquement des routines planifiées. Sous-commandes :

Application desktop via Schedule > New task > New remote task. Choisir "New local task" crée une tâche planifiée Desktop à la place, qui tourne sur ta machine.

Les déclencheurs API et GitHub ne peuvent être configurés que depuis l'interface web. La CLI ne les supporte pas encore.

Trois types de déclencheurs

Une seule routine peut combiner les trois. Une routine de review de PR pourrait tourner chaque nuit sur planning, réagir immédiatement quand une PR s'ouvre, et accepter des appels ad-hoc depuis un script de déploiement.

Les déclencheurs de planning se déclenchent selon une cadence. Les préréglages incluent horaire, quotidien, jours de semaine et hebdomadaire. Les expressions cron personnalisées fonctionnent aussi (configure-les avec /schedule update). L'intervalle minimum est d'une heure. Les heures utilisent ton fuseau horaire local.

Les déclencheurs API donnent à chaque routine un endpoint HTTP dédié. Poste dessus depuis n'importe quel système. Le champ text optionnel dans le corps de la requête est ajouté au prompt de la routine comme contexte supplémentaire :

curl -X POST \
  https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

La réponse retourne un ID de session et une URL. Clique sur l'URL pour regarder Claude travailler en temps réel :

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

Les déclencheurs GitHub s'abonnent aux événements du dépôt. 18 catégories d'événements sont supportées :

Les déclencheurs de pull request supportent des filtres. Chaque filtre doit correspondre pour que la routine se déclenche :

Chaque événement GitHub correspondant démarre sa propre session indépendante. Pas de réutilisation de session entre les événements.

En quoi les routines diffèrent de tout le reste

Claude Code a maintenant quatre façons de lancer du travail en arrière-plan. Elles résolvent des problèmes différents.

Les routines sont le bon choix quand le travail doit se faire peu importe si ta machine est allumée, ou quand un système externe doit le déclencher.

Les tâches planifiées Desktop sont meilleures quand tu as besoin d'accès aux fichiers locaux ou d'intervalles inférieurs à l'heure.

/loop convient au polling rapide limité à la session qui doit mourir quand tu fermes le terminal.

Monitor est pour les réactions event-driven à un processus en cours (surveiller des logs, suivre un serveur de dev).

Ce que tu peux automatiser

Six patterns couvrent la plupart des cas d'usage. Chacun correspond à un type de déclencheur et un workflow concret.

Triage de tickets nightly (planning). La routine lit les nouvelles issues de Linear ou GitHub via connecteur, applique des labels basés sur la zone de code, assigne des propriétaires, et poste un résumé sur Slack. Tourne chaque nuit à 2h.

Triage d'alertes (API). Ton outil de monitoring (Datadog, PagerDuty, Sentry) poste le corps de l'alerte sur l'endpoint de la routine. Claude récupère la stack trace, la corrèle avec les commits récents, et ouvre une PR brouillon avec un correctif proposé. Quand l'on-call ouvre la page, le contexte est déjà assemblé.

Review de code sur chaque PR (GitHub). Se déclenche sur pull_request.opened avec is_draft: false. Claude applique la checklist de review de ton équipe, laisse des commentaires inline pour les patterns de sécurité et de performance, et ajoute un commentaire de résumé. Filtre par branche de base ou labels pour le limiter aux modules sensibles uniquement.

Vérification de déploiement (API). Ton pipeline CD appelle l'endpoint après chaque déploiement. Claude lance des smoke checks sur l'environnement live, scanne les logs d'erreurs pour les régressions introduites dans les 30 dernières minutes, et poste un message go/no-go sur le canal de release.

Détection de drift de docs (planning). Tourne hebdomadairement. Scanne les PRs mergées des 7 derniers jours, identifie les pages de docs qui référencent des endpoints API ou des signatures de fonctions modifiés, et ouvre des PRs de mise à jour pour chacune.

Portage cross-SDK (GitHub). Se déclenche sur pull_request.closed filtré sur is_merged: true. Quand un changement arrive dans le SDK Python, la routine clone le repo SDK Go, porte le changement, et ouvre une PR correspondante.

15 autres idées qui valent l'automatisation

Ces idées viennent d'utilisateurs réels qui ont partagé ce qu'ils ont construit dans les premières heures du lancement.

1. Préparation du standup matinal. Digère l'activité GitHub, les fils Slack et les mises à jour Linear en un seul briefing posté sur ton canal avant le standup.
2. Audit de dépendances. Scan hebdomadaire des packages obsolètes. Ouvre une PR qui bump les mises à jour sûres et signale les cassantes.
3. Scanner de TODOs. Balayage nightly de la codebase pour les nouveaux commentaires TODO. Poste-les sur un canal de suivi.
4. Notes de release. Déclenche sur la publication d'une release. Compile les PRs mergées en changelog formaté et met à jour CHANGELOG.md.
5. Porte de review sécurité. Déclenche sur les PRs touchant les répertoires auth ou paiements. Lance un audit de sécurité ciblé et signale les patterns risqués.
6. Auto-fix des logs d'erreur. Toutes les 2 heures, scanne les logs de l'application pour les entrées FATAL. Si le correctif est évident, ouvre une PR brouillon.
7. Nettoyage des branches stagnantes. Routine hebdomadaire qui liste les branches sans commits depuis 30 jours et poste un résumé de nettoyage.
8. Vérification de contrat API. Après la merge d'une PR dans le repo backend, vérifie que le frontend correspond toujours aux types API.
9. Détection de régression de performance. Déclencheur GitHub sur push vers main. Lance la suite de benchmarks et commente le commit si quelque chose a régressé.
10. Surveillance des concurrents. Routine quotidienne qui vérifie les pages changelog des concurrents et poste un résumé des différences.
11. Triage des retours clients. Déclencheur API depuis ton outil de support. Claude lit le ticket, le classifie, et le route vers la bonne équipe.
12. Fraîcheur des docs d'onboarding. Vérification mensuelle que les guides de setup correspondent toujours aux vraies étapes d'installation.
13. Garde-fou de PR. Déclencheur GitHub sur les échecs de CI. Claude lit la sortie CI, tente un correctif, et pousse sur la même branche.
14. Monitoring HN et Reddit. Routine quotidienne qui cherche des mentions de ton produit et poste un digest.
15. Review de migration de base de données. Déclencheur GitHub sur les PRs qui touchent les fichiers de migration. Claude vérifie le rollback sûr, le risque de perte de données et la durée de lock.

Limites des plans

Les routines comptent contre ton quota de runs journaliers et le budget de tokens de ton abonnement. Les deux limites s'appliquent indépendamment.

Les organisations avec la facturation d'usage supplémentaire activée peuvent dépasser ces plafonds à des tarifs d'excédent mesuré. Vérifie la consommation sur claude.ai/settings/usage.

Écrire de bons prompts pour les routines

Un prompt de routine tourne sans humain dans la boucle. Le prompt doit porter tout le contexte qu'une conversation fournit normalement par l'aller-retour.

Sois explicite sur l'objectif. "Review PRs" est trop vague. "Lis chaque PR ouverte sur ce repo. Pour chacune, vérifie les erreurs de gestion manquantes dans les fonctions async, les requêtes SQL sans paramètres, et les composants React qui appellent des hooks conditionnellement. Laisse un commentaire inline sur chaque finding. Poste un commentaire de résumé à la fin." Cette version tourne de façon autonome sans deviner.

Définis à quoi ressemble le succès. "Si aucun problème n'est trouvé, poste un seul commentaire : 'Reviewed, no issues.' Ne pas ouvrir une PR. Ne pas poster sur Slack."

Délimite la sortie. "Crée une PR brouillon, pas une PR prête à review. Pousse sur une branche préfixée claude/. Ne merge rien."

Inclus les instructions d'échec. "Si le build échoue après tes changements, reverte le commit et laisse un commentaire expliquant ce qui a mal tourné."

Sécurité et contrôle d'accès

Les routines agissent en ton nom. Les commits portent ton nom d'utilisateur GitHub. Les messages Slack utilisent ton compte lié. Traite l'accès aux routines de la même façon que tu traiterais le fait de donner tes credentials à quelqu'un pendant une heure.

Restrictions de branches. Par défaut, les routines ne peuvent pousser que vers des branches préfixées par claude/. Ça empêche un mauvais prompt de pousser directement vers main. Ne désactive cette restriction que lorsque la routine a spécifiquement besoin de pousser vers d'autres branches et que tu as des règles de protection de branche comme filet de sécurité.

Scope des connecteurs. Chaque connecteur que tu as lié est inclus par défaut. Supprime ceux dont la routine n'a pas besoin. Une routine de review de PR n'a pas besoin d'accès en écriture Slack. Une routine de digest Slack n'a pas besoin d'accès push GitHub.

Variables d'environnement. Les secrets (clés API, tokens) vivent dans la configuration d'environnement, pas dans le prompt. Configure-les sur claude.ai/code/environments avant d'attacher l'environnement à une routine.

Stockage des tokens. Les tokens de déclencheur API sont affichés exactement une fois lors de leur génération. Stocke-les dans ton gestionnaire de secrets immédiatement. Tu ne peux pas les récupérer plus tard.

Limitations actuelles

Les routines sont en preview de recherche. Quelques limites valent la peine d'être connues avant de construire autour.

L'intervalle de planning minimum est d'une heure. Pour tout ce qui est plus rapide, utilise les tâches planifiées Desktop (minimum 1 minute) ou /loop.

Chaque run clone le repo frais. Il n'y a pas d'accès aux fichiers locaux et pas d'état porté entre les runs. Si une routine doit se souvenir de quelque chose entre les runs, elle doit écrire cet état dans le repo (un fichier JSON, un commentaire, ou une issue).

Les événements webhook GitHub ont des plafonds horaires par routine et par compte pendant la preview. Un repo à fort trafic avec des filtres de déclencheurs larges peut épuiser le plafond rapidement.

Les routines appartiennent à ton compte individuel. Elles ne sont pas partagées avec les coéquipiers. Chaque membre d'équipe qui veut la même automatisation crée sa propre copie.

L'endpoint de l'API /fire nécessite le header beta anthropic-beta: experimental-cc-routine-2026-04-01. Ça changera avant la GA.

Commencer

Trois étapes permettent de lancer une routine utile aujourd'hui.

Choisis quelque chose de bas risque. Un digest matinal, un scan hebdomadaire de TODOs, ou un passage nightly de labels d'issues. Rien qui pousse vers main ou contacte des clients.

Crée-la depuis la CLI avec /schedule ou depuis le web sur claude.ai/code/routines. Écris le prompt comme si tu briefais un prestataire qui n'a jamais vu ta codebase. Teste avec /schedule run.

Regarde les trois premiers runs. Clique sur l'URL de session, lis ce que Claude a fait, vérifie la sortie. Affine le prompt sur ce que tu vois. Puis laisse tourner.

Les routines comblent le fossé entre "Claude fait ce que tu lui dis" et "Claude fait ce qui doit être fait, tout seul." Le laptop reste fermé. Le travail se fait. La session est là pour être revue quand tu l'ouvres.