Présentation de Claude Code Routines

 (code.claude.com)
13 points par GN⁺ 2026-04-15 | 1 commentaires | Partager sur WhatsApp
  • Fonction d’automatisation de code basée sur le cloud qui s’exécute automatiquement selon un calendrier, des appels API ou des événements GitHub, et fonctionne sur l’infrastructure d’Anthropic
  • Les routines sont composées de prompts, dépôts, connecteurs et déclencheurs, et continuent de s’exécuter même si le portable est éteint
  • Les déclencheurs prennent en charge trois types : calendrier, API et événements GitHub, et plusieurs déclencheurs peuvent être combinés dans une même routine
  • Création et gestion possibles depuis le web, le CLI et l’application desktop, avec exécution de tâches via des connecteurs de services externes comme GitHub, Slack et Linear
  • Disponible avec les offres Pro et supérieures, actuellement en research preview, et les fonctionnalités comme les spécifications API peuvent encore changer

Automatiser le travail avec les routines

  • Les Claude Code Routines sont des configurations de code enregistrées qui s’exécutent automatiquement selon un calendrier, des appels API ou des événements GitHub, sur une infrastructure cloud gérée par Anthropic
  • Les routines sont composées d’un prompt, d’un dépôt et d’un ensemble de connecteurs, et continuent de s’exécuter même si le portable est éteint
  • Il existe trois types de déclencheurs : calendrier, API et événements GitHub, et plusieurs déclencheurs peuvent être combinés dans une seule routine
  • Les routines sont disponibles avec les offres Pro, Max, Team et Enterprise, et peuvent être créées et gérées sur le web ou via le CLI (/schedule)
  • Le service est actuellement en research preview et son fonctionnement ainsi que les spécifications API peuvent évoluer

Principaux cas d’usage des routines

  • Maintenance du backlog : un déclencheur planifié vérifie chaque nuit l’issue tracker, ajoute des labels, assigne des responsables et publie un récapitulatif sur Slack
  • Classification des alertes : un outil de monitoring appelle un déclencheur API lorsqu’une erreur se produit, puis la routine analyse la stack trace et crée une PR de correction
  • Revue de code personnalisée : un déclencheur GitHub s’exécute lors de la création d’une PR pour ajouter automatiquement des commentaires sur la sécurité, les performances et le style
  • Validation de déploiement : un pipeline CD appelle un déclencheur API après le déploiement, puis la routine effectue des smoke tests et inspecte les logs
  • Synchronisation de la documentation : un déclencheur planifié hebdomadaire analyse les PR fusionnées et crée une PR de mise à jour de la documentation API concernée
  • Portage de bibliothèque : lors de la fusion d’une PR, un déclencheur GitHub reporte les changements vers un SDK dans une autre langue

Comment créer une routine

  • Les routines peuvent être créées depuis le web, l’application desktop et le CLI, et toutes les interfaces sont reliées au même compte cloud
  • Éléments à configurer lors de la création d’une routine : prompt, dépôt, environnement, connecteurs, déclencheurs
  • Une routine est une session exécutée automatiquement, capable de lancer des commandes et d’appeler des connecteurs sans approbation d’autorisation
  • Les routines appartiennent à un compte individuel et ne sont pas partagées avec l’équipe. Leur nombre d’exécutions est comptabilisé dans la limite quotidienne du compte
  • Toutes les actions effectuées via des connecteurs comme GitHub, Slack ou Linear apparaissent comme réalisées depuis le compte connecté de l’utilisateur

  • Création sur le web

    • Cliquer sur New routine depuis claude.ai/code/routines
    • Saisir le nom de la routine et le prompt, puis choisir le modèle
    • Sélection du dépôt : ajouter un dépôt GitHub, utiliser une branche avec le préfixe claude/
    • Sélection de l’environnement : configurer l’accès réseau, les variables d’environnement et les scripts d’installation
    • Sélection des déclencheurs : choisir ou combiner calendrier, événements GitHub et API
    • Vérifier les connecteurs, puis retirer ceux qui ne sont pas nécessaires
    • Cliquer sur Create pour créer la routine et l’exécuter immédiatement si besoin

  • Création dans le CLI

    • Création interactive possible avec la commande /schedule (/schedule daily PR review at 9am)
    • Dans le CLI, seuls les déclencheurs planifiés peuvent être créés ; les déclencheurs API et GitHub doivent être ajoutés sur le web
    • Gestion possible avec /schedule list, /schedule update et /schedule run

  • Création dans l’application desktop

    • Sur la page Schedule, sélectionner New remote task
    • Les tâches locales planifiées et les routines sont affichées ensemble

Configuration des déclencheurs

  • Une routine peut avoir un ou plusieurs déclencheurs calendrier, API ou GitHub
  • Les déclencheurs peuvent être ajoutés ou supprimés à tout moment

  • Déclencheur calendrier

    • Exécution horaire, quotidienne, en semaine ou hebdomadaire selon le fuseau horaire
    • L’intervalle minimum entre deux exécutions est d’une heure
    • Le CLI permet de définir une expression cron via /schedule update

  • Déclencheur API

    • Chaque routine dispose de son propre endpoint HTTP, authentifié par jeton Bearer
    • Une requête POST crée une nouvelle session et renvoie son URL
    • Le champ text du corps de requête peut transmettre le contexte d’exécution
    • Le jeton n’est affiché qu’une seule fois et peut être régénéré ou révoqué
    • L’endpoint /fire nécessite l’en-tête bêta experimental-cc-routine-2026-04-01

  • Déclencheur GitHub

    • Exécution automatique lorsqu’un événement se produit dans un dépôt connecté
    • Nécessite l’installation de la Claude GitHub App
    • Configuration possible uniquement dans l’interface web
    • Une limite horaire s’applique en cas de dépassement du volume d’événements

    • Événements pris en charge

      • Environ 20 types d’événements GitHub sont pris en charge, dont Pull request, Push, Release, Issues et Discussion
      • Chaque événement peut réagir à des actions détaillées (opened, closed, edited, etc.)

    • Filtrage des PR

      • Filtrage possible par auteur, titre, corps, branche, label, statut de fusion, origine fork, etc.
      • Ex. : is draft=false → exécuter uniquement les PR prêtes pour revue, labels include needs-backport → déclencher uniquement avec un label donné

    • Mapping des sessions

      • Chaque événement s’exécute dans une session indépendante, sans réutilisation de session entre événements

Gestion des routines

  • Un clic sur une routine dans la liste ouvre sa page de détail
  • Il est possible d’y consulter le dépôt, les connecteurs, le prompt, les déclencheurs et l’historique d’exécution

  • Voir les exécutions et interagir

    • Chaque exécution s’ouvre sous forme de session, avec possibilité d’examiner les changements, de créer une PR et de poursuivre la conversation
    • Le menu de session permet de renommer, archiver ou supprimer

  • Édition et contrôle

    • Run now permet une exécution immédiate
    • Le bouton Repeats permet de mettre en pause ou de reprendre
    • Edit routine permet de modifier le nom, le prompt, le dépôt, l’environnement et les déclencheurs
    • La suppression conserve les sessions passées

Dépôts et autorisations de branche

  • Les routines nécessitent une authentification GitHub, avec configuration de la connexion via /web-setup
  • Par défaut, les push ne sont autorisés que vers les branches préfixées claude/
  • L’option Allow unrestricted branch pushes permet de lever cette restriction

Connecteurs

  • Les routines accèdent à des services externes comme Slack, Linear et Google Drive via des connecteurs MCP
  • Tous les connecteurs reliés sont inclus par défaut ; il est recommandé de retirer ceux qui ne sont pas nécessaires
  • La gestion est possible via Settings > Connectors ou /schedule update

Configuration de l’environnement

  • Chaque routine s’exécute dans un environnement cloud
  • L’environnement permet de contrôler l’accès réseau, les variables d’environnement et les scripts d’installation
  • Il est possible de préconfigurer l’accès API, l’installation des dépendances et les restrictions réseau

Utilisation et limites

  • Les exécutions de routines consomment le quota d’abonnement comme des sessions normales
  • Il existe une limite quotidienne d’exécutions par compte
  • Si le dépassement est autorisé, des exécutions excédentaires facturées sont possibles
  • La consommation est consultable sur claude.ai/settings/usage

Ressources associées

À lire aussi

1 commentaires

 
GN⁺ 2026-04-15
Réactions sur Hacker News

  • Les LLM et leurs fournisseurs restent encore des boîtes noires géantes
    J’en tire beaucoup de valeur, mais les nouvelles fonctionnalités lancées par Anthropic ne m’inspirent pas confiance
    Il est difficile de croire à la fois que les fonctions ne seront pas bridées ou supprimées, et à la pérennité de l’entreprise sur le long terme
    Donc je n’ai pas l’intention de bâtir un business ou un flux de développement au-dessus de cette plateforme
    Je veux me limiter à Claude Code, en gardant un minimum de lock-in pour pouvoir basculer vers OpenCode ou Codex en cas de problème

    • Je pense pareil. Ces dernières semaines, en voyant ma dépendance à Claude Code augmenter, j’ai commencé à réduire son usage
      La fonctionnalité "Memory" a surtout été décisive. Les données d’apprentissage ne sont stockées que dans un chemin local, donc elles ne restent pas dans git
      En plus, avec les nouvelles conditions d’utilisation qui interdisent l’usage d’autres CLI, l’agent de débogage automatique qu’on testait en entreprise s’est retrouvé bloqué
      Bref, c’est “so long Claude”
    • Moi aussi, j’ai essayé de rester indépendant du modèle, mais la stratégie de lock-in d’Anthropic devient de plus en plus explicite, au point qu’il devient difficile d’y échapper
      Je n’utilise que des fonctions portables comme MCP ou Skills
      En voyant se répéter cette stratégie de moat à la Silicon Valley, je n’ai pas envie de me faire avoir une nouvelle fois
    • Au contraire, dès qu’ils ont l’occasion de brider une fonctionnalité, ils le font immédiatement
    • Je pense que l’inquiétude autour du lock-in est un héritage du passé. Aujourd’hui, la migration d’agents est facile, donc on peut passer d’un fournisseur à l’autre en quelques heures
      Les principaux fournisseurs de LLM copient mutuellement leurs fonctions, donc au final tout se fait sur des standards communs
      En cas de problème, je pense qu’on pourra vite migrer en lift-and-shift
    • Cette discussion me rappelle les anciennes stratégies multi-cloud
      À l’époque aussi, les craintes de lock-in étaient fortes, mais dans la pratique ce n’était pas aussi grave que prévu chez AWS et consorts
      Je pense que les LLM suivront une trajectoire similaire, donc je ne m’en préoccupe pas particulièrement

  • Les ToS sont confuses. Faire tourner claude -p depuis cron, c’est autorisé, mais si on le met dans un bot Telegram, ça devient une violation ?
    La fonction Routines marche aussi avec l’abonnement et il y a des callbacks API, donc si un bot appelle l’API, est-ce que le compte peut être suspendu ? Je n’en ai aucune idée

    • Le fait qu’Anthropic ne clarifie pas ce point crée beaucoup de confusion. C’est frustrant parce que la documentation se contredit d’un endroit à l’autre
    • On dirait une ambiguïté volontaire. Un peu comme les licences en volume de Microsoft, une stratégie pour faire peur aux utilisateurs et éviter qu’ils n’abusent de leur abonnement
    • Ces derniers mois, la confusion a ressemblé à ça
      • le SDK a autorisé l’authentification OAuth
      • la documentation a été modifiée pour dire « n’utilisez pas OAuth »
      • un employé a tweeté que « pour un usage personnel, c’est bon »
      • puis un mail général a annoncé « ne l’utilisez surtout pas »
        Liens associés : documentation SDK, mise à jour Reddit, annonce HN
    • Je ne comprends pas pourquoi on ne pourrait pas utiliser claude -p avec d’autres outils
      J’essaie d’intégrer ClaudeCode dans mon IDE, mais je n’ai absolument aucune idée d’où commence ou s’arrête la notion de “3rd party harness”

  • Récemment, la baisse de performance de Claude a été telle que j’ai fini par migrer vers d’autres modèles
    On en est au point où même un simple script Python de base doit être relancé à cause d’erreurs de syntaxe
    Avant, l’ordinateur exécutait toujours les instructions comme demandé, maintenant ce n’est plus le cas

    • Voir le tracker de performance Claude Code de marginlab.ai
    • J’utilise Codex 5.4 xhigh. Il communique mal, mais il fait le travail
    • Moi non plus je ne croyais pas à l’idée que « le modèle est devenu plus bête », mais cette semaine je n’ai pas eu d’autre choix que de l’admettre. Opus s’en sort même plus difficilement que Sonnet

  • On dirait qu’Anthropic sort presque chaque semaine la même fonctionnalité avec un nouveau nom

    • La direction annule tous les projets de la semaine précédente et pousse maintenant Routines
      Les équipes DevOps annoncent la centralisation du Routines Hub. Ceux qui ne suivent pas seront remplacés
    • On en est à faire des blagues du genre : « au bout de 7 jours, c’est sorti de la fenêtre de contexte… »
    • C’est peut-être ça, la définition du vibecoding sur plusieurs sessions
    • La semaine prochaine, on verra sans doute remonter sur GitHub Issues de nouvelles fonctionnalités cassées discrètement
      Aujourd’hui, Sonnet 4.6 m’a donné des réponses totalement à côté, donc grosse déception. Je vais sans doute retenter Opus 4.6
    • Il y a déjà beaucoup de cas où le nom entre en conflit avec une fonctionnalité que j’avais créée. J’aurais dû déposer la marque “dispatch”

  • Il y a des rumeurs récentes selon lesquelles les limites d’usage de Claude Code auraient été réduites
    (lien associé)
    Je me demande si des outils autonomes peuvent vraiment fonctionner correctement avec ce genre de contraintes

    • D’après des discussions avec des amis, la source du problème serait l’introduction d’une fenêtre de contexte de 1M de tokens
      Au début, cela donnait des résultats impressionnants, mais ensuite la charge a augmenté et ils sont depuis en train d’ajuster en permanence
      Le mode “High” est en fait devenu l’ancien “Medium”, et la vraie haute performance n’est plus accessible que via des réglages cachés
      Je pense qu’il faudrait permettre aux utilisateurs d’ajuster eux-mêmes la taille de la fenêtre de contexte
      Liens associés : discussion HN, solution par rétrogradation de version
    • La compétition actuelle dans l’IA ressemble à un jeu de dette. Au final, quelqu’un devra payer l’addition
    • Les commentaires semblent maintenant rétablis
    • Les limites sont bien réelles : article de ghacks.net

  • Si les ressources de calcul sont insuffisantes, c’est étrange de sortir encore plus de fonctions d’automatisation

    • Ils essaient sans doute d’orienter l’usage pour prévoir la charge, peut-être en lissant l’exécution vers la nuit
    • Mais au fond, il s’agit de renforcer le lock-in. Une stratégie pour pousser des intégrations difficiles à défaire
    • Le compte Max inclut 15 exécutions par jour, et au-delà il y a une facturation supplémentaire
    • On dirait qu’ils cherchent moins à maximiser le simple volume d’usage qu’à encourager des schémas d’utilisation stratégiques. Les logs d’écriture de code ont bien plus de valeur
    • En fin de compte, c’est une manière d’enfermer les utilisateurs dans leur propre écosystème

  • Je pense qu’on est en train d’entrer dans l’ère du cloud IA
    La logique consiste à empiler des services avancés au-dessus des modèles, puis à sécuriser les revenus via le lock-in

  • J’avais déjà automatisé des revues de PR avec claude-code-action GitHub Action
    Mais comme ça ne fonctionnait pas sur les dépôts forkés, j’ai dû le corriger moi-même
    La fonction Routines semble pouvoir résoudre ce problème
    En revanche, la limite de 15 exécutions automatiques par jour est vraiment trop faible. Sur le projet OpenWrt, il y a 20 PR par jour, donc difficile de tout traiter
    Il faudrait aussi une fonction de relance après correction
    Une augmentation du nombre d’exécutions quotidiennes ou un report sur 7 jours serait appréciable
    J’ai aussi eu deux fois un bug où la fenêtre se fermait pendant l’édition d’une routine

  • On peut faire tourner Claude Code en mode pilotage automatique.
    L’idée est de définir des routines qui réagissent à un planning, à des déclencheurs API ou à des événements GitHub
    Comment appeler ça ? “ingénierie logicielle” ? “programmation” ?

    • Ce n’est qu’une configuration d’agent, pas quelque chose qui mérite vraiment le nom de programmation
    • “openclawing” conviendrait mieux
    • Quelqu’un a proposé “promptramming”
    • “vibe coding” serait aussi un bon candidat
    • Certains disent qu’il faudrait simplement appeler ça “gramming”

  • J’utilise depuis assez longtemps cette fonctionnalité, qui s’appelait autrefois “Scheduled”
    Il y a eu des bugs, mais maintenant c’est stable
    Voici des cas d’usage que j’en ai tirés

    1. surveiller un canal Slack de feedback, créer automatiquement des issues, puis corriger directement les cas simples avant de répondre avec un lien vers la PR
    2. pour des tâches hors code, générer un rapport quotidien résumant l’activité GitHub, Slack et email
      J’ai aussi essayé avec CoWork, mais le connecteur GitHub de Claude Code était bien plus précis
      Quand ça marche correctement, c’est un outil d’automatisation très utile