Claude Code Routines : automatiser sans serveur

Les Routines Claude Code permettent d’exécuter des tâches automatisées sur l’infrastructure cloud d’Anthropic, sans serveur à gérer et sans ordinateur allumé. Lancées en research preview le 14 avril 2026, elles transforment Claude Code d’un outil de développement local en plateforme d’automatisation cloud déclenchée par planning, appel API ou événement GitHub.

J’ai configuré mes premières Routines dès la sortie de la research preview. Après une semaine d’utilisation quotidienne sur trois dépôts, ce guide couvre les trois types de triggers, la configuration pas à pas, les cas d’usage DevOps concrets et les limites à connaître avant de déployer vos premières routines.

Ce que sont les Routines Claude Code

Une Routine est une configuration sauvegardée qui associe un prompt, un ou plusieurs dépôts GitHub et un ensemble de connecteurs MCP. Anthropic l’exécute dans un environnement cloud isolé à chaque déclenchement, en clonant vos dépôts depuis la branche par défaut.

Contrairement à une session interactive où vous échangez avec Claude en temps réel, une Routine fonctionne de manière autonome. Il n’y a pas de mode permission ni de validation humaine pendant l’exécution : Claude peut lancer des commandes shell, utiliser les skills commitées dans le dépôt cloné et appeler tous les connecteurs configurés. C’est un point important pour la sécurité de vos workflows : chaque Routine a accès à tout ce que vous lui donnez.

Les Routines sont disponibles sur les plans Pro, Max, Team et Enterprise avec Claude Code web activé. Vous les gérez depuis claude.ai/code/routines ou via la commande /schedule dans le CLI.

Ce qui distingue les Routines des autres options d’automatisation

Les Routines sont à mi-chemin entre un cron job et un agent managé. Elles conviennent aux équipes qui veulent automatiser sans écrire de code d’orchestration ni maintenir d’infrastructure.

Les trois types de triggers

Les 3 triggers d’une Routine Claude Code : planning, API et GitHub, pour un coût runtime de 0,08 $/h.

Chaque Routine peut combiner un ou plusieurs triggers. Un même workflow peut donc s’exécuter à heure fixe, réagir à un événement GitHub et être appelé par un outil externe simultanément.

Trigger planifié (Scheduled)

Le trigger planifié exécute la Routine sur une cadence récurrente : toutes les heures, chaque jour, les jours ouvrés ou chaque semaine. Les horaires sont saisis dans votre fuseau local et convertis automatiquement.

Pour une cadence personnalisée (toutes les deux heures, le premier de chaque mois), sélectionnez le preset le plus proche dans l’interface web, puis utilisez /schedule update dans le CLI pour définir une expression cron spécifique. L’intervalle minimum est d’une heure : les expressions plus fréquentes sont rejetées.

Cas d’usage typique : une routine de maintenance du backlog qui s’exécute chaque soir, lit les issues ouvertes depuis la dernière exécution, applique des labels, assigne les propriétaires et poste un résumé dans Slack.

Trigger API

Chaque Routine disposant d’un trigger API reçoit un endpoint HTTP dédié avec authentification par bearer token. Un POST sur cet endpoint démarre une nouvelle session et retourne l’identifiant de session ainsi qu’une URL pour suivre l’exécution en temps réel.

L’appel accepte un champ optionnel text pour transmettre du contexte spécifique à l’exécution (corps d’alerte, log d’erreur, payload webhook). Voici un exemple d’appel :

POST /v1/claude_code/routines/{trigger_id}/fire
Headers:
  Authorization: Bearer {votre_token_routine}
  anthropic-beta: experimental-cc-routine-2026-04-01
  anthropic-version: 2023-06-01
  Content-Type: application/json
Body:
  {"text": "Alerte Sentry SEN-4521 en production."}

La réponse inclut l’URL de la session pour suivre ce que Claude fait :

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

Cas d’usage typique : votre outil de monitoring (Sentry, PagerDuty, Datadog) appelle l’endpoint quand un seuil d’erreur est franchi. La Routine corrèle la stack trace avec les commits récents et ouvre une pull request avec un correctif proposé.

Trigger GitHub

Le trigger GitHub démarre une session automatiquement quand un événement correspondant se produit sur un dépôt connecté. L’application GitHub de Claude doit être installée sur le dépôt (la configuration vous guide dans l’installation si elle manque).

Deux catégories d’événements sont prises en charge :

Vous pouvez filtrer les pull requests selon l’auteur, le titre, le corps, la branche cible, la branche source, les labels, le statut draft ou le statut merged. Chaque filtre utilise un opérateur : égalité, contient, commence par, fait partie de, regex.

Cas d’usage typique : une routine de code review se déclenche sur pull_request.opened, applique votre checklist de revue (sécurité, performance, style) et laisse des commentaires inline pour que les reviewers humains se concentrent sur l’architecture.

Configurer une Routine pas à pas

La création se fait depuis l’interface web, l’application Desktop ou le CLI. Les trois surfaces écrivent dans le même compte cloud.

Depuis l’interface web

1. Ouvrez le formulaire sur claude.ai/code/routines et cliquez sur “New routine”.

2. Rédigez le prompt. C’est l’élément le plus critique. Comme la routine s’exécute sans supervision, le prompt doit être autonome et explicite sur ce qu’il faut faire, ce qu’il faut vérifier et à quoi ressemble le succès. Sélectionnez aussi le modèle Claude à utiliser.

3. Sélectionnez les dépôts GitHub. Chaque dépôt est cloné au début de l’exécution depuis la branche par défaut. Claude crée des branches préfixées claude/ pour ses modifications.

4. Choisissez un environnement cloud. L’environnement contrôle l’accès réseau (bloqué, domaines autorisés, sources de confiance, internet complet), les variables d’environnement (clés API, tokens) et un script de setup (dépendances, outils). Le résultat du script est mis en cache.

5. Configurez les triggers. Ajoutez un ou plusieurs triggers parmi planning, API et GitHub.

6. Vérifiez les connecteurs. Tous vos connecteurs MCP sont inclus par défaut. Retirez ceux dont la routine n’a pas besoin pour limiter la surface d’accès.

7. Créez la routine. Elle apparaît dans la liste et s’exécute au prochain déclenchement. Utilisez “Run now” pour un test immédiat.

Depuis le CLI

La commande /schedule permet de créer une routine planifiée de manière conversationnelle :

/schedule daily PR review at 9am

Claude vous guide dans la configuration (prompt, dépôts, environnement). Pour ajouter un trigger API ou GitHub, complétez la configuration sur l’interface web. Commandes utiles :

• /schedule list : lister toutes les routines
• /schedule update : modifier une routine existante
• /schedule run : déclencher une exécution immédiate

Cas d’usage DevOps concrets

Les Routines sont conçues pour des tâches non supervisées, répétables et liées à un résultat mesurable. Voici six scénarios issus de la documentation officielle et des retours de la communauté.

Triage d’alertes automatisé

Votre outil de monitoring appelle l’endpoint API de la Routine quand un seuil d’erreur est franchi. La Routine récupère la stack trace, la corrèle avec les commits récents dans le dépôt, et ouvre une pull request avec un correctif proposé et un lien vers l’alerte. L’équipe d’astreinte revoit la PR au lieu de partir d’un terminal vide.

Vérification post-déploiement

Votre pipeline CD appelle l’endpoint API après chaque déploiement en production. La Routine exécute des smoke tests contre le nouveau build, analyse les logs d’erreur à la recherche de régressions et poste un verdict go/no-go dans le canal de release avant la fin de la fenêtre de déploiement.

Revue de code personnalisée

Un trigger GitHub sur pull_request.opened lance la Routine. Elle applique la checklist de revue propre à votre équipe, laisse des commentaires inline sur les problèmes de sécurité, performance et style, et ajoute un commentaire récapitulatif. Selon une enquête Pragmatic Engineer (fev. 2026) auprès de 15 000 développeurs, 73 % des équipes d’ingénierie utilisent des outils IA au quotidien, et les retours de la communauté indiquent une réduction notable du temps consacré aux revues mécaniques répétitives.

Détection de dérive documentaire

Un trigger planifié hebdomadaire scanne les PR mergées depuis la dernière exécution, identifie la documentation qui référence des API modifiées et ouvre des PR de mise à jour dans le dépôt de documentation.

Maintenance du backlog

Chaque soir, la Routine lit les issues ouvertes via un connecteur, applique des labels selon la zone de code concernée, assigne les propriétaires et poste un résumé dans Slack pour que l’équipe démarre la journée avec un backlog trié.

Portage de bibliothèques

Un trigger GitHub sur pull_request.closed filtré aux PR mergées dans un dépôt SDK déclenche la Routine. Elle porte les modifications vers un SDK parallèle dans un autre langage et ouvre une PR correspondante, maintenant les deux bibliothèques synchronisées sans intervention humaine.

Bonnes pratiques pour des Routines fiables

Rédigez des prompts autonomes

Le prompt fait tout le travail. Chaque exécution démarre dans un environnement cloud propre sans historique de conversation. Votre prompt doit inclure :

• Ce que la Routine doit faire, étape par étape
• Ce qu’elle doit vérifier avant de considérer la tâche terminée
• À quoi ressemble le succès (PR ouverte, message Slack envoyé, label appliqué)
• Les limites : ce qu’elle ne doit pas faire (merger une PR, supprimer une branche)

Évitez les références à du contexte externe absent de la session cloud. Si la Routine a besoin de données, utilisez un connecteur ou passez-les via le champ text du trigger API.

Stockez la logique réutilisable dans les Skills

Pour les prompts complexes, créez des fichiers dans le répertoire .claude/skills/ de votre dépôt. La Routine y accède automatiquement puisque le dépôt est cloné à chaque exécution. Cette approche permet de versionner et partager la logique entre plusieurs routines.

Limitez la surface d’accès

Retirez les connecteurs MCP dont la Routine n’a pas besoin. Configurez l’accès réseau au niveau le plus restrictif possible (domaines autorisés plutôt qu’internet complet). Gardez les branches limitées au préfixe claude/ sauf nécessité explicite.

Testez avec “Run now” avant de planifier

Chaque Routine dispose d’un bouton “Run now” qui lance une exécution immédiate. Utilisez-le pour valider le comportement avant d’activer le trigger automatique. L’exécution manuelle ne compte pas dans le quota quotidien.

Tarifs et limites d’utilisation

Les Routines consomment les quotas d’abonnement comme les sessions interactives, avec en plus un plafond quotidien d’exécutions automatiques.

Le coût runtime est identique à celui des Managed Agents : 0,08 $ par heure de session active, selon la documentation Anthropic. En pratique, une routine de 45 secondes revient à environ 0,001 $ en runtime (hors tokens), et une routine de 15 minutes coûte environ 0,02 $ en runtime.

Quand le quota quotidien est atteint, les organisations ayant activé l’usage supplémentaire (extra usage) peuvent continuer à exécuter des routines en overage payant. Sans cette option, les exécutions supplémentaires sont rejetées jusqu’à la réinitialisation du compteur.

Avec 5 exécutions par jour sur le plan Pro, les Routines conviennent mieux à quelques automatisations bien ciblées qu’à des dizaines de jobs. Pour des volumes plus importants, les frameworks auto-hébergés avec des fournisseurs de modèles moins coûteux restent plus économiques, au prix d’une maintenance d’infrastructure supplémentaire.

Pour replacer ce coût dans son contexte : le marché des agents IA devrait atteindre 12 milliards de dollars en 2026, selon MarketsandMarkets, avec un TCAC de 46,3 % jusqu’en 2030. Le segment codage/développement logiciel affiche la croissance la plus rapide (52,4 % de TCAC). J’estime que les Routines positionnent Anthropic sur ce segment en réduisant la barrière d’entrée par rapport aux agents auto-hébergés.

Limites actuelles de la research preview

Les Routines sont en research preview depuis le 14 avril 2026. Plusieurs contraintes méritent d’être anticipées :

• Intervalle minimum d’une heure pour les triggers planifiés : impossible de déclencher une routine toutes les 15 minutes.
• Événements GitHub limités aux pull requests et releases : les push, issues et autres événements ne sont pas encore pris en charge comme triggers directs.
• Pas de partage entre membres d’équipe : chaque Routine appartient à un compte individuel claude.ai et n’est pas visible par les coéquipiers.
• Actions sous votre identité : les commits, PR et messages Slack générés par une Routine utilisent votre identité GitHub et vos comptes connectés.
• API sous header bêta : l’endpoint /fire nécessite le header anthropic-beta: experimental-cc-routine-2026-04-01. Le format des requêtes et réponses peut évoluer.
• Caps horaires sur les webhooks GitHub : pendant la preview, les événements au-delà du cap horaire par routine sont ignorés jusqu’à la réinitialisation.

Ces limitations évolueront au fil des itérations d’Anthropic. Consultez la page claude.ai/code/routines pour suivre les mises à jour.

Routines vs /loop vs Desktop Scheduled Tasks

Comparaison des 3 automatisations Claude Code : seules les Routines tournent sans laptop avec un quota de 5 à 25 exécutions/jour.

Claude Code propose trois mécanismes d’automatisation qui répondent à des besoins différents :

Choisissez les Routines pour les tâches récurrentes qui doivent tourner sans votre présence. Utilisez /loop pour les itérations longues sur un projet local pendant que vous travaillez. Préférez les Desktop Scheduled Tasks pour les automatisations qui nécessitent l’accès à vos fichiers locaux.

Premiers pas : votre première Routine en 5 minutes

Pour démarrer rapidement, voici un scénario simple de résumé quotidien des PR ouvertes :

1. Rendez-vous sur claude.ai/code/routines et cliquez “New routine”.

2. Nommez-la “Daily PR Summary” et rédigez ce prompt :

Lis toutes les pull requests ouvertes sur le dépôt principal.
Pour chaque PR, extrais : titre, auteur, nombre de fichiers modifiés,
ancienneté en jours.
Poste un résumé formaté dans le canal Slack #dev-team avec :
- Les PR de plus de 3 jours en premier (à traiter en priorité)
- Le nombre total de PR ouvertes
- Une ligne par PR avec titre, auteur et ancienneté
Ne merge aucune PR. Ne laisse aucun commentaire sur les PR.

3. Sélectionnez votre dépôt GitHub principal.

4. Ajoutez un trigger planifié “Daily” à 9h00.

5. Vérifiez que le connecteur Slack est inclus, puis créez la routine.

6. Cliquez “Run now” pour valider le comportement avant la première exécution planifiée.

Si vous maîtrisez déjà Claude Code et ses fonctionnalités de base, les Routines sont la suite naturelle pour passer de l’automatisation assistée à l’automatisation autonome dans le cloud. Mon conseil : commencez par une seule routine de faible criticité (résumé de PR, triage de backlog) pour valider le fonctionnement avant d’automatiser des tâches plus sensibles. En quelques minutes de configuration par routine, vous libérez du temps sur les tâches répétitives qui jalonnent chaque journée DevOps.