Les Routines Claude Code

Le problème : ton laptop doit rester ouvert pour que Claude Code fasse quoi que ce soit. Les tâches planifiées Desktop et /loop tournent en local, ce qui veut dire qu'un couvercle fermé tue toutes tes automatisations. Et tu n'as aucun moyen de réagir à des événements externes comme une PR GitHub ou une alerte de monitoring sans faire du polling.

Gain 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 exécute le prompt. La seconde la lance immédiatement pour que tu vérifies la sortie avant de faire confiance au planning.

Ce que sont les Routines

Une routine, c'est trois choses packagées ensemble : 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 déclencheur.

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 permission. Pas de clics d'approbation. La session peut exécuter des commandes shell, utiliser les skills committés dans le repo, et appeler chaque connecteur attaché.

Les Routines ont été livrées le 14 avril 2026 en research preview. Le comportement et la surface API peuvent changer avant la GA.

Où vivent les Routines

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

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

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

App 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.

Les trois types de déclencheurs

Une seule routine peut combiner les trois. Une routine de revue de PR pourrait tourner la nuit sur un planning, réagir instantanément à l'ouverture d'une PR, et accepter des appels ad hoc depuis un script de déploiement.

Les déclencheurs de planning tirent sur une cadence. Les presets incluent hourly, daily, weekdays, et weekly. 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é. POST depuis n'importe quel système. Le champ optionnel text 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 renvoie un session ID 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 événements.

En quoi les Routines diffèrent du reste

Claude Code a maintenant quatre façons de faire tourner 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 produire que ta machine soit allumée ou non, 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é à une session, qui doit mourir quand tu fermes le terminal.

Monitor est pour les réactions event-driven à un processus en cours (regarder 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 d'issues nocturne (planning). La routine lit les nouvelles issues depuis Linear ou GitHub via connecteur, applique des labels selon 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 vers l'endpoint de la routine. Claude tire la stack trace, la corrèle avec les commits récents, et ouvre une PR draft avec un correctif proposé. Quand l'astreinte ouvre la page, le contexte est déjà assemblé.

Revue de code sur chaque PR (GitHub). Se déclenche sur pull_request.opened avec is_draft: false. Claude applique la checklist de revue 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 cibler les modules sensibles uniquement.

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

Détection de dérive de docs (planning). Tourne chaque semaine. 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 atterrit dans le SDK Python, la routine clone le repo du SDK Go, porte le changement, et ouvre une PR correspondante.

15 autres idées à automatiser

Tirées de vrais utilisateurs qui ont partagé ce qu'ils ont construit dans les premières heures après le lancement.

1. Préparation du standup matinal. Digère l'activité GitHub, les threads Slack, et les mises à jour Linear en un briefing unique posté dans ton channel avant le standup.
2. Audit de dépendances. Scan hebdomadaire des packages obsolètes. Ouvre une PR qui bumpe les mises à jour sûres et marque les breaking changes.
3. Scanner de TODO. Sweep nocturne de la codebase pour les nouveaux commentaires TODO. Les poste dans un channel 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 revue de sécurité. Déclenche sur les PRs touchant les répertoires auth ou payments. Lance un audit de sécurité ciblé et signale les patterns risqués.
6. Auto-fix de logs d'erreur. Toutes les 2 heures, scanne les logs applicatifs pour les entrées FATAL. Si le fix est évident, ouvre une PR draft.
7. Nettoyage de branches stale. 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 le 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. Monitoring de concurrents. Routine quotidienne qui vérifie les pages de changelog des concurrents et poste un résumé des différences.
11. Triage de feedback client. Déclencheur API depuis ton outil de support. Claude lit le ticket, le classe, et le route vers la bonne équipe.
12. Fraîcheur des docs d'onboarding. Vérification mensuelle que les guides de setup correspondent aux étapes d'installation réelles.
13. Surveillance de PR. Déclencheur GitHub sur les échecs de CI. Claude lit la sortie CI, tente un fix, et pousse sur la même branche.
14. Monitoring HN et Reddit. Routine quotidienne qui cherche les mentions de ton produit et poste un digest.
15. Revue de migration de base de données. Déclencheur GitHub sur les PRs qui touchent des fichiers de migration. Claude revoit le rollback sûr, le risque de perte de données, et la durée des locks.

Limites de plan

Les Routines comptent contre ton quota de runs quotidiens et le budget token 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'overage au compteur. 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 fournirait normalement par l'échange.

Sois explicite sur l'objectif. "Revue les PRs" est trop vague. "Lis chaque PR ouverte sur ce repo. Pour chacune, vérifie la gestion des erreurs manquante dans les fonctions async, les requêtes SQL sans inputs paramétrés, et les composants React qui appellent des hooks conditionnellement. Laisse un commentaire inline sur chaque résultat. 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 de PR. Ne pas poster sur Slack."

Limite la sortie. "Crée une PR draft, pas une PR prête à review. Push vers une branche préfixée claude/. Ne merge rien."

Inclus des instructions d'échec. "Si le build échoue après tes changements, reverte le commit et laisse un commentaire expliquant ce qui s'est passé."

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

Les Routines agissent en ton nom. Les commits portent ton username GitHub. Les messages Slack utilisent ton compte lié. Traite l'accès des routines comme tu traiterais le fait de donner tes credentials à quelqu'un pour une heure.

Restrictions de branches. Par défaut, les routines ne peuvent pousser que vers des branches préfixées avec claude/. Ça empêche un mauvais prompt de pousser directement vers main. Désactive cette restriction uniquement quand la routine a spécifiquement besoin de pousser vers d'autres branches et que tu as des règles de protection de branches 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 revue 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 à la génération. Stocke-les immédiatement dans ton secret manager. Tu ne pourras pas les récupérer plus tard.

Limitations actuelles

Les Routines sont en research preview. Quelques frontières à connaître avant de construire dessus.

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. Pas d'accès aux fichiers locaux et pas d'état conservé entre les runs. Si une routine doit se souvenir de quelque chose d'un run à l'autre, 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éclencheur larges peut épuiser le plafond rapidement.

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

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

Pour commencer

Trois étapes pour avoir une routine utile qui tourne aujourd'hui.

Commence par quelque chose de peu risqué. Un digest matinal, un scan hebdomadaire de TODO, ou un passage de labellisation d'issues nocturne. Rien qui pousse vers main ou envoie des messages à des clients.

Crée-la depuis la CLI avec /schedule ou depuis l'interface 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 en fonction de 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à à reviewer quand tu le rouvres.