Claude Code Routines : agents cloud planifiés, sous-routines et co-routines

Voici le guide approfondi. Pour un aperçu en cinq minutes, lisez l'article de blog associé.

1. Pourquoi les agents planifiés comptent

Jusqu'à récemment, un agent de programmation IA ne travaillait que sous le regard de quelqu'un. Vous ouvriez un terminal, lui confiiez une tâche, approuviez ses actions et lisiez le résultat. Dès que vous fermiez la session, le travail s'arrêtait. Ce modèle convient au travail exploratoire, mais une grande partie du travail d'ingénierie n'est ni exploratoire ni urgente. Elle est récurrente : trier la file des tickets de la nuit, vérifier que la documentation correspond toujours à l'API, relire chaque pull request selon la même checklist, valider un déploiement avant la fermeture de la fenêtre de mise en production.

Les équipes qui voulaient confier ce travail à un agent sans surveillance devaient construire elles-mêmes toute la tuyauterie. Les options habituelles étaient un cron job dans GitHub Actions, une machine de récupération laissée allumée dans un placard, ou un moteur de workflows comme Trigger.dev ou n8n auquel on greffait un appel d'agent. Chacune fonctionne, mais chacune ajoute de l'infrastructure, des identifiants, des coûts et de la maintenance autour de ce qui n'est au fond qu'une seule instruction : « fais ceci chaque nuit et dis-moi ce que tu as trouvé. »

Les routines suppriment cette tuyauterie. La planification, la puissance de calcul, le checkout du dépôt et la piste d'audit résident tous dans Claude Code lui-même.

2. Ce qu'est une routine

Anthropic définit une routine comme une configuration Claude Code enregistrée. Elle comporte cinq éléments :

• Prompt. L'instruction que Claude exécute à chaque lancement. Comme personne n'est là pour répondre aux questions, il doit être autonome et préciser à quoi ressemble un travail « terminé ». C'est aussi ici que vous choisissez le modèle, utilisé pour chaque exécution.
• Dépôts. Un ou plusieurs dépôts GitHub. Chacun est cloné à neuf au début de chaque exécution, à partir de sa branche par défaut sauf indication contraire dans le prompt.
• Environnement cloud. Il contrôle l'accès réseau, les variables d'environnement et un script d'initialisation facultatif qui installe les dépendances. Le résultat de l'initialisation est mis en cache et n'est donc pas réexécuté à chaque fois.
• Connecteurs. Les intégrations MCP de votre compte claude.ai, comme Slack, Linear ou Google Drive, dans lesquelles la routine peut lire et écrire.
• Déclencheurs. Un ou plusieurs parmi : planification, API et événement GitHub. Une même routine peut combiner les trois.

Chaque exécution est une session cloud Claude Code complète. Elle peut lancer des commandes shell, utiliser les skills versionnées dans le dépôt cloné et appeler tous les outils des connecteurs que vous avez inclus. Il n'y a pas de sélecteur de mode de permissions et rien n'attend d'approbation. Cette autonomie est tout l'intérêt de la fonctionnalité, et c'est aussi pourquoi la délimitation du périmètre est essentielle (voir la section 8).

3. Les trois types de déclencheurs

3.1 Planification

Le déclencheur le plus simple exécute la routine selon une cadence prédéfinie (toutes les heures, tous les jours, en semaine ou chaque semaine) ou une seule fois à un moment futur précis. Quelques détails méritent d'être connus :

• Heure locale. Vous saisissez les heures dans votre propre fuseau horaire et Claude Code les convertit : une exécution à 09:00 a donc lieu à 09:00 à votre horloge, où que se trouve le matériel cloud. Certains des premiers guides tiers affirmaient que les planifications n'acceptaient que l'UTC. La documentation d'Anthropic dit le contraire.
• Évitez les heures pile. Les exécutions planifiées exactement à l'heure pile peuvent démarrer avec plusieurs minutes de retard. Choisir 09:07 plutôt que 09:00 donne un horaire plus prévisible.
• Cron personnalisé. Pour les intervalles que les préréglages ne couvrent pas, comme toutes les deux heures ou le premier du mois, choisissez le préréglage le plus proche puis lancez /schedule update dans la CLI pour définir une expression cron. L'intervalle minimum est d'une heure ; toute fréquence plus élevée est refusée.
• Exécutions ponctuelles. Décrivez le moment en langage naturel, par exemple /schedule in 2 weeks, open a cleanup PR that removes the feature flag. Claude confirme l'horodatage exact avant d'enregistrer. Une fois déclenchée, la routine se désactive d'elle-même et est marquée Ran. Les exécutions ponctuelles ne sont pas décomptées du plafond quotidien d'exécutions.

3.2 API

Un déclencheur API dote la routine de son propre endpoint HTTPS. Tout système capable d'envoyer une requête POST authentifiée peut lancer une exécution : un outil d'alerte, un pipeline de déploiement, une page d'administration interne. Le jeton est généré dans l'interface web, affiché une seule fois, limité à cette seule routine, et peut être régénéré ou révoqué à tout moment.

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<ROUTINE_TRIGGER_ID>/fire \
  -H "Authorization: Bearer <ROUTINE_TOKEN>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error rate on checkout-api above 5% for 10 minutes."}'

La réponse contient un identifiant de session et une URL de session que vous pouvez ouvrir pour suivre l'exécution en direct. Le champ facultatif text transporte un contexte propre à l'exécution. Les équipes soucieuses de sécurité noteront que Claude Code encapsule ce texte dans un bloc <routine-fire-payload> et le marque comme données non fiables. Claude ne suivra pas les instructions qu'il contient, sauf si le prompt enregistré de la routine lui demande d'utiliser le payload. Si votre routine doit agir sur le corps d'une alerte, le prompt doit le dire explicitement, par exemple : « Analyse l'alerte décrite dans le bloc routine-fire-payload. » Avec cette conception, un jeton divulgué permet à quelqu'un de lancer une exécution, mais pas de réécrire les instructions de la routine.

L'endpoint est protégé par un en-tête bêta daté. Anthropic indique que les changements incompatibles seront publiés sous de nouvelles versions de l'en-tête, et que les deux versions précédentes continueront de fonctionner pour laisser aux appelants le temps de migrer.

3.3 Événements GitHub

Un déclencheur GitHub démarre une nouvelle session chaque fois qu'un événement correspondant se produit sur un dépôt connecté. Il nécessite que la Claude GitHub App soit installée sur ce dépôt. Deux catégories d'événements sont prises en charge :

• Pull request : ouverte, fermée, assignée, labellisée, synchronisée et autres mises à jour.
• Release : créée, publiée, modifiée ou supprimée.

Des filtres restreignent les événements pris en compte. Vous pouvez filtrer sur l'auteur, le titre, le corps, la branche de base, la branche head, les labels, le statut brouillon et le statut fusionné, avec les opérateurs equals, contains, starts with, is one of, is not one of et matches regex. Toutes les conditions doivent être remplies. Un piège : matches regex teste le champ entier, donc pour attraper tout titre contenant « hotfix », il faut .*hotfix.* et non hotfix.

Chaque événement produit sa propre session indépendante : deux push sur la même pull request donnent donc deux exécutions. Pendant la préversion, les événements GitHub sont aussi soumis à des plafonds horaires par routine et par compte. Les événements au-delà du plafond sont ignorés jusqu'à la réinitialisation de la fenêtre.

4. Créer une routine, étape par étape

Vous pouvez créer des routines depuis trois endroits : le web à l'adresse claude.ai/code/routines, la section Routines de l'onglet Code de l'application Claude Desktop, ou la CLI. Les trois écrivent dans le même compte : une routine créée dans l'un apparaît immédiatement dans les autres.

4.1 Sur le web

1. Ouvrez claude.ai/code/routines et choisissez New routine.
2. Nommez-la et rédigez le prompt. Sélectionnez le modèle.
3. Ajoutez les dépôts dans lesquels Claude doit travailler.
4. Choisissez un environnement cloud. L'environnement Default dispose d'un accès réseau Trusted, qui autorise les registres de paquets courants, les API des fournisseurs cloud et les domaines de développement. Si la routine doit atteindre vos propres services, ajustez d'abord les domaines autorisés de l'environnement.
5. Sélectionnez un ou plusieurs déclencheurs. Pour un déclencheur API, enregistrez d'abord la routine ; l'URL et le jeton sont générés ensuite.
6. Passez en revue les connecteurs. Tous vos connecteurs connectés sont inclus par défaut, et Claude peut utiliser chacun de leurs outils, y compris les actions d'écriture, sans demander. Retirez tout ce dont la tâche n'a pas besoin.
7. Choisissez Create, puis Run now pour la tester avant de vous fier à la planification.

4.2 Depuis la CLI

Dans n'importe quelle session Claude Code locale, /schedule (alias /routines) crée une routine planifiée par la conversation. Claude vous interroge sur la cadence, les dépôts et le prompt, puis l'enregistre dans votre compte.

/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarise yesterday's merged PRs
/schedule list
/schedule update
/schedule run
/schedule why did my nightly review do nothing this morning?

Le dernier exemple est particulièrement utile. Claude liste les exécutions récentes de la routine, lit le journal pertinent et explique ce qui s'est passé, y compris les erreurs d'outils et les refus de permissions. Les versions récentes de la CLI peuvent aussi ajouter un déclencheur GitHub par la conversation une fois la GitHub App installée. Les jetons API, en revanche, ne peuvent être créés ou révoqués que sur le web.

Si /schedule n'est pas reconnu, la cause est presque toujours l'authentification. Les routines nécessitent une connexion avec un abonnement claude.ai. Une clé API Console, une variable d'environnement ANTHROPIC_API_KEY ou une connexion via un fournisseur cloud comme Amazon Bedrock masqueront la commande. Sur les offres Team et Enterprise, un Owner peut également désactiver les routines pour toute l'organisation.

5. Rédiger des prompts qui résistent aux exécutions sans surveillance

Le prompt d'une routine s'apparente davantage à un runbook qu'à un message de chat. Personne n'est là pour lever les ambiguïtés : des instructions vagues produisent des résultats vagues ou, pire, des actions menées avec assurance que vous n'aviez pas prévues. Comparez :

Un bon prompt de routine précise :

• Périmètre : quels dépôts, quelle fenêtre temporelle et quels éléments.
• Actions autorisées : ce que Claude peut modifier et, tout aussi important, ce à quoi il ne doit pas toucher.
• Résultat : la destination et le format exacts, par exemple une PR en brouillon, un canal Slack ou un commentaire dans l'outil de suivi.
• Conditions d'arrêt : que faire lorsqu'il n'y a rien à faire, et quand abandonner.
• Traitement du payload : pour les déclencheurs API, s'il faut utiliser le texte de déclenchement et comment.

Attendez-vous à affiner une nouvelle routine deux ou trois fois au cours de sa première semaine. Lisez les transcriptions, pas seulement le badge de statut. Anthropic est explicite : un statut vert signifie seulement que la session a démarré et s'est terminée sans erreur d'infrastructure. Il ne signifie pas que la tâche a réussi.

6. Sous-routines : structurer le travail au sein d'une exécution

Anthropic ne propose aucune fonctionnalité appelée « sub-routines ». Chez Workstation, nous employons le terme de sous-routines (sub-routines) pour un design pattern qui rend les longues exécutions sans surveillance bien plus fiables : le prompt de la routine joue le rôle d'orchestrateur et délègue chaque étape bien définie à un sous-agent ou à une skill versionnée dans le dépôt.

Cela fonctionne grâce à deux briques de Claude Code qui accompagnent votre dépôt :

• Les sous-agents sont des fichiers Markdown avec un front matter YAML dans .claude/agents/. Chacun possède son propre prompt système, sa liste d'outils autorisés et un modèle facultatif, et s'exécute dans sa propre fenêtre de contexte. Seul un résumé remonte à l'appelant. Les sous-agents peuvent s'exécuter en parallèle et, par défaut, déléguer eux-mêmes jusqu'à trois niveaux de profondeur.
• Les skills dans .claude/skills/ regroupent des procédures réutilisables, comme votre style de notes de version ou votre checklist de revue de sécurité, que Claude charge lorsqu'elles sont pertinentes. Les routines utilisent les skills versionnées dans le dépôt cloné.

Une routine de maintenance nocturne construite de cette façon pourrait ressembler à ceci :

# Routine prompt (orchestrator)
1. Use the issue-triager subagent to label and assign issues opened since the last run.
2. Pick the single highest-priority bug labelled "good-first-fix".
3. Use the bug-fixer subagent to implement a fix on a claude/ branch.
4. Use the test-runner subagent to run the test suite; if it fails twice, stop and report.
5. Open ONE draft PR, using the release-notes skill for the description.
6. Post a three-line summary to #eng-nightly.

# .claude/agents/issue-triager.md
---
name: issue-triager
description: Labels and assigns new issues. Never edits code.
tools: Read, Grep, Glob
model: haiku
---
You triage GitHub issues. Apply area labels from CODEOWNERS and
assign the owning team. Return a table of issue, label and owner.

Les bénéfices sont concrets. Chaque assistant ne voit que ce dont il a besoin : le contexte de l'orchestrateur reste réduit et ciblé tout au long d'une longue exécution. Les permissions d'outils sont plus restreintes à chaque étape : le trieur ci-dessus ne peut modifier aucun fichier. Des modèles moins coûteux peuvent prendre en charge les étapes mécaniques. Et comme les sous-agents et les skills vivent dans le contrôle de version, toute modification du comportement de la routine passe par la revue de code, comme n'importe quel autre changement.

7. Co-routines : des routines qui coopèrent

Là encore, « co-routines » est notre terme, pas une fonctionnalité d'Anthropic. Nous l'utilisons pour désigner plusieurs routines indépendantes qui se transmettent le travail, à la manière d'une chaîne de production qui fait passer une pièce d'un poste au suivant. Les routines ne peuvent pas s'appeler directement et ne partagent aucune mémoire. À la place, une routine produit un artefact durable que le déclencheur d'une autre routine surveille.

Une chaîne typique :

1. Routine A (planification) trie le backlog les soirs de semaine et ouvre une PR en brouillon depuis une branche claude/fix-….
2. Routine B (GitHub, pull_request.opened) est filtrée sur les branches head commençant par claude/. Elle applique la checklist de revue de l'équipe et ajoute un label à la PR.
3. Un humain relit et fusionne. C'est le point de validation.
4. Routine C (GitHub, pull_request.closed, merged = true) met à jour la documentation ou porte la modification vers un SDK jumeau, puis ouvre une PR de suivi.
5. Routine D (API) est appelée par le pipeline de déploiement après la mise en production. Elle exécute des smoke tests et publie un verdict go ou no-go. En cas de no-go, elle crée un ticket dans l'outil de suivi, que la Routine A reprend la nuit suivante.

Les canaux de transmission, du plus structuré au moins structuré :

• Événements GitHub : natifs, filtrables et entièrement auditables.
• Labels et conventions de nommage des branches : aiguillent le travail sans écrire de code d'intégration.
• Appels API : depuis la CI, la supervision ou des outils internes, avec un payload traité comme un contexte non fiable.
• Un outil de suivi ou un artefact partagé : un ticket Linear ou une page de statut que lit la prochaine exécution planifiée.

Concevez vos co-routines avec soin. Utilisez des filtres pour qu'une routine ne se déclenche jamais sur sa propre production, par exemple en excluant les auteurs ou les branches qu'elle crée. Conservez une fusion humaine entre toute routine qui écrit du code et toute routine qui le livre. N'oubliez pas que chaque étape puise dans le même plafond quotidien d'exécutions au niveau du compte et dans les mêmes plafonds d'événements GitHub. Si vous vous retrouvez à construire de la logique de branchement, des reprises et du fan-out sur de nombreuses routines, vous avez dépassé ce pattern, et un moteur de workflows dédié est l'outil le plus adapté.

8. Sécurité et gouvernance

• Les routines agissent en votre nom. Les routines appartiennent à un compte claude.ai individuel et ne sont pas partagées avec vos collègues. Les commits et les pull requests portent votre identité GitHub, et les actions des connecteurs utilisent vos comptes liés. Traitez une routine comme un jeton d'accès personnel doté d'un cerveau.
• Protection des branches. Par défaut, Claude pousse vers des branches préfixées claude/. Il refuse de pousser vers des branches protégées, vers des branches faisant l'objet d'une PR ouverte par quelqu'un d'autre et vers des branches contenant les commits d'autres personnes.
• Moindre privilège. Retirez les connecteurs inutiles. Laissez l'accès réseau sur Trusted sauf si un domaine précis est requis ; les requêtes bloquées échouent avec 403 et x-deny-reason: host_not_allowed. Sur les offres Pro et Max, stockez les clés API en tant qu'API credentials de l'environnement plutôt qu'en variables simples, visibles par toute personne utilisant l'environnement.
• Entrées non fiables. Les payloads API et le texte de Run now arrivent marqués comme non fiables. Le contenu récupéré pendant une exécution, comme le corps des tickets et les pages web, conserve le traitement habituel contre l'injection de prompts. Rédigez des prompts qui indiquent à Claude à quoi se fier.
• État de la connexion. Si la connexion GitHub expire, les exécutions sont ignorées pendant 72 heures au maximum, puis la routine se désactive d'elle-même jusqu'à ce que vous vous reconnectiez.
• Contrôle au niveau de l'organisation. Les Owners Team et Enterprise peuvent désactiver les routines pour tous les membres depuis les paramètres d'administration.

9. Offres, utilisation et limites

Les routines consomment l'utilisation de l'abonnement de la même manière que les sessions interactives. Le plafond quotidien s'applique en plus. Votre quota actuel est affiché sur claude.ai/code/routines et peut évoluer pendant la préversion. Avec les crédits d'utilisation activés, les exécutions au-delà du plafond se poursuivent en dépassement facturé à l'usage ; sans eux, les exécutions supplémentaires sont refusées jusqu'à la réinitialisation de la fenêtre. Les exécutions planifiées ponctuelles ne sont pas décomptées du plafond. Lorsqu'un abonnement est suspendu, ses routines sont mises en attente.

10. Les routines comparées aux autres options de planification

10.1 Au sein de Claude Code

Les tâches /loop sont liées à la session et expirent au bout de sept jours. Elles sont idéales pour surveiller un build ou une pull request pendant que vous travaillez, mais elles ne remplacent pas une routine.

10.2 En dehors de Claude Code

• GitHub Actions est peu coûteux, vit à côté du code et offre un contrôle total sur le runner. Le prix à payer : du YAML, la gestion des secrets et la maintenance des runners. Choisissez Actions pour les étapes de build déterministes, et les routines pour le travail qui demande du discernement.
• Les moteurs de workflows comme Trigger.dev gèrent les reprises, le fan-out et l'orchestration de longue durée, mais c'est vous qui écrivez l'orchestration en code. Utilisez-les lorsque le workflow lui-même est le produit.
• Les plateformes d'intégration comme n8n et Zapier excellent à faire circuler des données entre outils SaaS. Les routines excellent à raisonner sur du code, des journaux et des documents. Les deux se combinent bien : un flux n8n peut appeler l'endpoint API d'une routine.

11. Les cas d'usage qui fonctionnent bien

• Entretien du backlog : labellisation nocturne, attribution des responsables et synthèse matinale.
• Tri des alertes : la supervision appelle le déclencheur API, et Claude corrèle la stack trace avec les commits récents puis ouvre un correctif en brouillon.
• Revue de code sur mesure : votre propre checklist appliquée à chaque PR prête pour la revue.
• Vérification des déploiements : smoke tests et analyse des journaux après chaque mise en production, avec un verdict final go ou no-go.
• Dérive de la documentation : une analyse hebdomadaire des PR fusionnées et des PR de mise à jour pour la documentation qui fait référence à des API modifiées.
• Portage de bibliothèques : répercuter les modifications fusionnées d'un SDK dans son équivalent dans un autre langage.
• Hygiène des dépendances : une revue hebdomadaire des paquets obsolètes avec une seule PR de mise à niveau testée.

Les routines sont moins adaptées au travail à une fréquence inférieure à l'heure, aux tâches qui nécessitent une décision humaine en cours d'exécution et aux workflows complexes à branches multiples avec reprises.

12. L'accueil de la communauté

Les réactions sont partagées, mais globalement positives. InfoQ a cité des ingénieurs enthousiastes à l'idée de brancher l'IA directement sur des tableaux de bord d'observabilité et des workflows de CI via des webhooks. D'autres se sont montrés sceptiques. Ils ont rappelé que de précédentes fonctionnalités de planification de Claude ne tournaient que sur la machine de l'utilisateur, et estimé que la fiabilité, la disponibilité et les limites de quota méritaient de l'attention avant de nouvelles fonctionnalités. Notre expérience : les routines sont bien conçues sur le plan de la sécurité, en particulier pour le traitement des payloads non fiables et la protection des branches. Les principaux risques opérationnels sont des connecteurs trop larges et des prompts insuffisamment précis.

13. Comment Workstation s'en sert

Chez Workstation, nous opérons de l'automatisation agentique pour nos clients dans les domaines du DevOps, des opérations financières et des parcours clients. Les routines s'intègrent bien à notre approche : une infrastructure déterministe pour la tuyauterie, l'IA pour le discernement, et une validation humaine avant que quoi que ce soit n'atteigne la production. Si vous souhaitez de l'aide pour concevoir des chaînes de routines, des bibliothèques de sous-agents ou la gouvernance qui les entoure, parlez à notre équipe.

14. Points clés à retenir

• Une routine est un prompt enregistré, avec des dépôts, un environnement, des connecteurs et des déclencheurs, exécuté de façon autonome dans le cloud.
• Les déclencheurs peuvent être une planification (minimum une heure, heure locale), un appel API (jeton bearer, payload non fiable) ou un événement GitHub de pull request ou de release.
• Disponible sur Pro, Max, Team et Enterprise, avec des plafonds quotidiens d'exécutions en plus de l'utilisation normale. La fonctionnalité est toujours en préversion de recherche.
• Utilisez des sous-routines (sous-agents et skills) pour qu'une longue exécution reste ciblée et limitée au moindre privilège.
• Utilisez des co-routines (des routines qui se transmettent le travail via des PR, des labels et des appels API) pour les pipelines à plusieurs étapes, avec une fusion humaine au milieu.
• Délimitez strictement les connecteurs et l'accès réseau, rédigez vos prompts comme des runbooks et lisez les transcriptions.

Sources et lectures complémentaires

• Anthropic : Introducing routines in Claude Code (14 avril 2026)
• Documentation Claude Code : Automate work with routines
• Documentation Claude Code : Run prompts on a schedule (/loop)
• Documentation Claude Code : Subagents
• Documentation Claude Platform : Trigger a routine through the API
• InfoQ : Anthropic Introduces Routines for Claude Code Automation
• MindStudio : Claude Code Routines: How to Run Scheduled AI Agents Without a Server
• Tahir sur Medium : What is Claude Code Routines?

Les routines sont en préversion de recherche. Le comportement, les limites et l'API peuvent évoluer. Les informations de ce guide reflètent la documentation publiée par Anthropic au 25 septembre 2026.