Routines Claude Code : lancez votre agent de dév selon un planning dans le cloud

Chacune des trois parties a un rôle précis :

• Prompt. La partie la plus importante, car la routine s’exécute sans votre validation à chaque étape. Le prompt doit décrire la tâche de bout en bout et définir le critère de réussite.
• Dépôts. Claude les clone au début de chaque exécution et y réalise son travail.
• Connecteurs. Les intégrations claude.ai de votre compte (Slack, Linear, etc.) que la routine peut lire et écrire pendant l’exécution. Par exemple, une routine de tri du support peut lire un canal Slack et créer des tickets dans Linear.

Les connecteurs des routines se configurent sur la plateforme claude.ai, tout comme les serveurs MCP. Vos configurations locales ne sont pas reprises.

Une routine peut se déclencher de trois façons : selon un planning, via un appel API, ou sur un événement GitHub. Une même routine peut combiner les trois.

Routines versus /loop

Il existe une différence entre /loop et /schedule car ils répondent à des besoins différents.

Une tâche /loop vit dans votre session en cours. Elle ne se déclenche que lorsque Claude Code est ouvert et inactif sur votre machine, et fermer le terminal l’arrête. Idéal pour sonder une construction que vous surveillez en temps réel.

Pour en savoir plus sur /loop et d’autres commandes essentielles, consultez notre tutoriel Claude Code Terminal.

Une routine s’exécute dans le cloud et fonctionne indépendamment de toute session:

Il existe aussi une troisième option locale. Les tâches planifiées sur poste s’exécutent sur votre propre ordinateur pour les travaux qui nécessitent vos fichiers et outils locaux. Elles ne tournent que lorsque la machine est réveillée, mais n’exigent pas que l’application Claude soit ouverte.

La routine que nous allons construire

Le cadre mental est posé. Il vous faut maintenant une cible pour la routine. Pour ce tutoriel, nous avons créé pr-review-demo, un petit projet Python avec une pull request ouverte.

Il contient un package cartlib qui gère un panier : stockage des prix en centimes (entiers), application de remises (membre et volume) et ajout de la taxe locale pour obtenir le total final. Le package sur la branche principale est correct.

La pull request ouverte ajoute un bon de réduction pour la livraison gratuite avec un vrai bug volontairement introduit. Il s’agit d’une incohérence d’unités entre deux fichiers, invisible si l’on ne lit qu’un seul fichier et détectable uniquement en retraçant la valeur à travers les deux. De quoi donner à la routine une tâche réaliste pour la suite du tutoriel.

Créez un fork du dépôt pour suivre avec votre propre copie. C’est un bac à sable, et les méthodes s’adaptent à n’importe quel dépôt que vous ciblez avec une routine.

Prérequis pour suivre

Vous avez besoin d’un compte claude.ai sur une offre Pro, Max, Team ou Enterprise avec Claude Code sur le web activé. Les routines se trouvent sur claude.ai/code/routines.

La commande /schedule s’authentifie avec votre identifiant d’abonnement claude.ai, pas avec une clé API Anthropic ni une authentification Bedrock, Vertex ou Foundry. Elle requiert également une CLI récente : lancez claude update si la vôtre est ancienne.

Deux prérequis GitHub distincts s’ajoutent. D’abord, /web-setup accorde l’accès au clone, nécessaire à la routine planifiée. Ensuite, l’application GitHub Claude, installée séparément, active le déclencheur GitHub abordé plus loin.

Construire des routines Claude Code avec /schedule

Avec un dépôt à cibler, créez la routine depuis la CLI. Exécutez /schedule dans n’importe quelle session. Vous pouvez passer une description directement :

/schedule daily PR review at 9 am

Claude vous guide ensuite à travers les mêmes champs que le formulaire web : nom, prompt, dépôt, environnement, connecteurs et planning. Il confirme l’horaire dans votre fuseau et le convertit pour vous : 9 h devient l’expression cron adéquate sans que vous ayez à l’écrire.

Si votre compte n’a pas encore de connexion GitHub, Claude vous invite à exécuter /web-setup. Faites-le, puis relancez /schedule pour reprendre où vous en étiez.

Rédiger un prompt qui tourne sans vous

Le prompt détermine la réussite ou l’échec de la routine.

Une session classique est conversationnelle : vous pouvez corriger Claude en cours de route. Une routine, non. Elle démarre à froid, s’exécute jusqu’au bout et ne peut pas poser de questions de clarification. Le prompt doit nommer la tâche, le dépôt et décrire à quoi ressemble une exécution réussie.

Comparez ces deux exemples. Le premier laisse trop d’implicites :

Review the open PR.

Il ne nomme ni le dépôt ni les critères de revue, ne prévoit pas d’emplacement pour les commentaires, et n’a pas de définition de fin. Un lancement à froid ne peut pas combler ces manques. Le second prompt couvre tout :

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Ce prompt nomme le dépôt et énonce l’invariant à respecter : des montants uniquement en centimes. Il pointe vers les deux fichiers utiles et définit la fin comme un commentaire en ligne plus un verdict de fusion. De quoi donner à l’exécution une cible atteignable en autonomie. Collez-le lorsque /schedule demande quoi faire.

Par défaut, tous vos connecteurs sont inclus : une routine neuve peut donc déjà atteindre tout ce qui est lié à votre compte. C’est très bien pour l’instant ; nous réduirons plus tard.

Une fois l’assistant terminé, Claude enregistre la routine et confirme qu’elle est active, avec son dépôt, son planning, son modèle et sa prochaine exécution.

La routine apparaît aussi dans le listing sur claude.ai/code/routines. Ouvrez sa page de détails pour tout retrouver au même endroit : statut, dépôt, planning, connecteurs, prompt complet et bouton Exécuter maintenant.

Cliquez sur Exécuter maintenant pour lancer aussitôt, sans attendre 9 h.

Lire une exécution

Chaque exécution part d’un clone à neuf de votre dépôt, récupéré depuis la branche par défaut. Tout ce que vous avez commité est présent. Tout ce que vous avez configuré uniquement en local ne l’est pas : la routine voit donc le dépôt comme vos collègues le verraient.

Une fois terminée, la liste des exécutions affiche un statut vert. Ce vert signifie que la session s’est lancée et achevée sans erreur d’infrastructure. Il ne garantit pas pour autant la réussite de la tâche demandée dans le prompt. Trois types d’échecs peuvent se cacher derrière ce coche vert et n’apparaissent que dans le transcript :

• Une requête réseau bloquée par l’environnement.
• Un outil de connecteur attendu mais injoignable par la routine.
• Un échec fonctionnel : l’exécution s’achève proprement mais fait la mauvaise chose.

Ouvrez donc l’exécution pour la confirmer. Cliquez sur n’importe quelle exécution pour la lire comme une session complète : vous voyez les actions de Claude, revoyez le diff, ouvrez une pull request ou poursuivez la conversation.

Sur le dépôt de démo, le transcript montre le problème détecté : Claude lit checkout.py et constate que le coupon est à 5 au lieu de 500. Il explique que $5 sont traités comme 5 centimes, surfacturant le client de $4,95 par commande, et propose la correction en une ligne. Ensuite, il publie la revue sur la PR via le connecteur GitHub.

Gérer les routines Claude Code depuis la CLI

Une fois créée, une routine se gère avec la même commande : /schedule list pour tout lister, /schedule update pour modifier, et /schedule run pour déclencher immédiatement.

Les préréglages de planning sont : horaire, quotidien, jours ouvrés, hebdomadaire. Pour un intervalle personnalisé (toutes les 2 heures, premier du mois, etc.), choisissez d’abord le préréglage le plus proche, puis lancez /schedule update pour définir directement une expression cron. L’intervalle minimal est de 1 heure : tout plus rapide est refusé.

Les routines comptent aussi dans le quota quotidien de votre compte, et pendant la préversion de recherche, les événements GitHub sont plafonnés à l’heure. Les événements au-delà du plafond sont ignorés, pas mis en file d’attente. Les valeurs actuelles dépendent de l’offre et s’affichent sur claude.ai/code/routines.

La CLI crée uniquement des routines planifiées. Pour ajouter un déclencheur GitHub ou API, modifiez la routine dans l’application web.

Déclencher des routines Claude Code depuis GitHub et HTTP

Le planning déclenche votre routine à l’heure. Deux autres déclencheurs permettent à GitHub ou à vos propres systèmes de lancer la même routine. Une routine de revue de PR peut tourner la nuit, réagir à chaque nouvelle PR et s’activer depuis un script de déploiement, simultanément.

Vous ajoutez ces deux déclencheurs en modifiant la routine sur claude.ai/code/routines.

Réagir aux pull requests avec un déclencheur GitHub

Le déclencheur GitHub requiert l’application GitHub Claude installée sur le dépôt auquel vous voulez vous abonner. Si l’app manque, l’assistant de configuration vous proposera de l’installer. Notez que /web-setup vu plus haut n’accorde que l’accès clone : il n’installe pas l’app et n’envoie pas de webhooks, donc il ne couvre pas cette étape.

Une fois l’app installée, ajoutez le déclencheur et choisissez un événement. Ils se répartissent en deux catégories : pull requests et releases, puis vous sélectionnez une action précise. L’interface propose des préréglages (PR ouverte, PR fusionnée, release publiée) et une option personnalisée pour le reste.

Affinez ensuite avec des filtres. Pour les pull requests : auteur, titre, corps, branche de base, branche source, labels, brouillon ou non, fusionnée ou non. Toutes les conditions doivent correspondre pour déclencher la routine.

L’opérateur matches regex teste le champ entier, pas une sous-chaîne. Pour faire correspondre tout titre contenant hotfix, écrivez .*hotfix.*. Un simple hotfix ne correspond qu’à un titre exactement identique.

Déclencheur GitHub configuré pour se lancer à l’ouverture d’une pull request, filtré sur la branche main et un auteur donné.

Pour le dépôt de démo, réglez l’événement sur l’ouverture d’une PR et laissez les filtres vides. Chaque nouvelle PR déclenche ainsi la revue définie plus tôt, sans personne au terminal : la routine suit l’unité du coupon à travers les fichiers, laisse un commentaire en ligne sur le bug et publie un verdict de fusion. 

Chaque événement correspondant lance sa propre session : deux PR consécutives produisent donc deux exécutions indépendantes.

Déclencher une routine via HTTP

Le déclencheur API permet à vos outils de lancer une routine. Choisissez API dans le sélecteur de déclencheur et cliquez sur Générer un jeton. Le jeton s’affiche une seule fois et ne peut pas être récupéré ensuite : stockez-le immédiatement dans le coffre-fort de secrets de votre outil d’alerte.

Ensuite, envoyez un POST vers l’endpoint de déclenchement de la routine avec le jeton et un corps text :

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

La valeur de text est transmise telle quelle et n’est pas parsée : écrivez donc du texte libre plutôt que du JSON. Les données structurées arrivent en texte brut et la routine les lit verbatim. 

L’en-tête anthropic-beta est requis, et l’API est expérimentale : vérifiez la référence API avant de l’intégrer à votre CI. Votre outil de supervision pourra ainsi appeler cet endpoint sur alerte et laisser la routine ouvrir seule une PR de correctif en brouillon.

Définir le périmètre d’accès des routines Claude Code

Une routine tourne en autonomie : avant de la pointer vers un dépôt réel, restreignez son champ d’action. La documentation présente quatre leviers :

• L’identité au nom de laquelle elle agit (votre identité GitHub et vos connecteurs).
• Les branches sur lesquelles elle peut pousser.
• Les connecteurs qu’elle peut utiliser.
• Les hôtes réseau qu’elle est autorisée à joindre.

Limitez chaque élément à ce dont la routine a réellement besoin.

Identité de la routine

L’identité est primordiale car c’est ce que vos collègues verront sur un dépôt partagé. Tout ce que la routine fait via votre identité GitHub ou vos connecteurs apparaît comme venant de vous. 

Les commits et PR portent votre utilisateur GitHub ; les messages Slack et tickets Linear utilisent vos comptes liés. Vos collègues voient votre nom : choisissez des noms de branches et des titres qui signalent clairement qu’une routine les a générés.

Branches vers lesquelles la routine peut pousser

Les branches viennent ensuite. Une exécution est une session cloud complète, sans invites d’autorisation : elle ne s’arrête jamais pour demander avant d’éditer un fichier ou d’ouvrir une PR. 

Le garde-fou, c’est la branche éligible en écriture. Par défaut, Claude ne pousse que sur des branches préfixées claude/, ce qui l’écarte des branches protégées ou longues durées comme main. 

Un réglage par dépôt, Autoriser les pushs sans restriction, supprime cette limitation. Activez-le en connaissance de cause, uniquement pour les dépôts qui l’exigent.

Connecteurs utilisables par la routine

Les connecteurs sont le levier le plus sensible. Par défaut, tous vos connecteurs claude.ai sont inclus, et Claude peut utiliser chaque outil d’un connecteur inclus, y compris en écriture, sans demander pendant l’exécution. 

Réduisez donc la liste au nécessaire. Une routine de revue de PR a besoin de GitHub et de peu d’autres choses. Un connecteur e-mail ou calendrier inutile reste un vecteur d’accès, et une injection de prompt cachée dans une PR pourrait l’exploiter.

Accès réseau

L’accès réseau est le dernier contrôle. L’environnement par défaut utilise un accès réseau approuvé, qui permet d’atteindre une liste blanche intégrée (registres de packages, API des clouds, registres de conteneurs, domaines courants de développement) et bloque le reste. 

Une requête bloquée renvoie un 403 avec x-deny-reason: host_not_allowed. N’élargissez l’accès que si la routine doit joindre vos services. Sinon, l’échec reste discret et n’apparaît que dans le transcript.

Idées de routines Claude Code à construire ensuite

Vous savez créer, déclencher et borner une routine. Voici quelques exemples issus de la doc officielle, qui associent chaque mission au déclencheur idéal :

• Revue de code sur mesure. Déclencheur GitHub à l’ouverture d’une PR. Applique votre checklist d’équipe, laisse des commentaires en ligne pour la sécurité, les performances et le style, puis ajoute un résumé. La démo, généralisée selon vos standards.
• Maintenance du backlog. Déclencheur planifié, chaque soir de semaine. Lit les issues ouvertes depuis la dernière exécution, applique des labels, assigne des responsables selon la zone de code, et publie un récap sur Slack.
• Vérification de déploiement. Déclencheur API depuis votre pipeline CD après chaque déploiement en production. Lance des smoke tests sur le build, analyse les logs d’erreur pour détecter des régressions et publie un go/no-go sur le canal de release.
• Dérive de documentation. Déclencheur planifié hebdomadaire. Analyse les PR fusionnées depuis la dernière exécution, signale les docs faisant référence à des API modifiées, et ouvre des PR de mise à jour sur le dépôt de doc.

Les routines conviennent aux travaux non surveillés, répétables et liés à un résultat clair. Si vous pouvez écrire les critères de succès dans le prompt, comme pour la revue de PR, la tâche est une bonne candidate. Celles qui exigent un jugement humain en temps réel le sont moins.

Conclusion

Les routines transforment votre gestion des tâches récurrentes. Plutôt que de les lancer à la main au terminal, vous les écrivez une fois et vous consultez les exécutions terminées. La revue de PR configurée s’exécute pendant que votre ordinateur est fermé, et vous lisez le verdict quand vous êtes disponible.

Pour approfondir Claude Code, ces tutoriels complètent bien celui-ci :

• Claude Code : bonnes pratiques pour tirer davantage de chaque session.
• Rédiger un fichier CLAUDE.md afin de partager le contexte entre routines et sessions.
• Spécification avant développement pour les tâches à formaliser avant automatisation.
• Auto mode et canaux pour faire tourner Claude Code avec moins de supervision.