Claude Code Routines vs GitHub Actions : où planifier vos agents

Claude Code Routines, que Anthropic a lancé en avril 2026, sont une configuration Claude Code sauvegardée : un prompt, un ou plusieurs dépôts, et des connecteurs, emballés une fois et exécutés automatiquement sur l'infrastructure cloud gérée par Anthropic. La documentation officielle décrit trois types de déclenchement : cadence planifiée, API (HTTP POST avec un bearer token), et événements GitHub. GitHub Actions, en contraste, exécute les scripts que vous écrivez sur des runners hébergés par GitHub. Les deux peuvent exécuter des agents IA selon un calendrier. Ce ne sont pas la même chose, et choisir la mauvaise option vous coûte soit de l'argent, soit des heures à vous battre avec du YAML. Cet article cartographie la décision, détaille le worker de file d'attente du blog, et couvre la récupération après défaillance.

Choisir entre Cloud Routines, Desktop, Session Loops, ou Actions

Quatre options d'hébergement existent. Elles ne sont pas interchangeables.

Cloud Routines s'exécutent sur l'infrastructure d'Anthropic, que votre laptop soit allumé ou non. Selon la documentation, chaque routine peut avoir un déclencheur planifié, un déclencheur API, ou un déclencheur d'événement GitHub, et vous pouvez combiner les trois sur une même routine. Le compromis : chaque exécution effectue un clone complet, donc les fichiers locaux ne sont jamais disponibles.

Les tâches planifiées sur Desktop s'exécutent sur votre machine. Elles ont un accès complet à votre système de fichiers local, vos bases de données locales, et vos fichiers .env. Si la machine est éteinte, la tâche ne s'exécute pas. C'est simple.

La planification limitée à une session (les outils CronCreate, CronList, CronDelete) fonctionne uniquement dans une session CLI ouverte. Ce sont des outils de planification de session, pas l'API des routines cloud. Ils disparaissent quand la session se termine.

GitHub Actions avec un déclencheur cron est un fichier YAML de workflow que GitHub exécute sur un runner hébergé. Gratuit pour les dépôts publics, peu coûteux pour les dépôts privés, déterministe, et profondément intégré à votre codebase. Le surcoût est réel si vous ne vivez pas déjà dans GitHub, mais pour les développeurs qui le font, c'est minimal.

Alors : comment choisir ?

1. La tâche s'exécute que votre machine soit allumée ou non, et elle a besoin d'un vrai raisonnement IA (résumer, rédiger, trier) ? Cloud Routine.
2. La tâche a besoin de votre .env local, d'une base de données locale, ou d'outils locaux ? Tâche planifiée sur Desktop.
3. La tâche est un pipeline CI/CD, un gestionnaire d'événement PR, ou un script déterministe qui appelle une API et poste sur Slack ? GitHub Actions, éventuellement avec un court script Python et aucun LLM du tout.
4. La tâche est exploratoire et vit dans une seule session que vous exécutez déjà ? Session loop.

La ventilation d'AI Magicx le pose clairement : si votre routine est « appeler une API, transformer, poster sur Slack », GitHub Actions avec un script Python de 10 lignes est moins cher et plus simple. Les Routines deviennent le bon choix quand le travail bénéficie vraiment du raisonnement de Claude : décider ce qu'il faut rapporter, écrire un récit, examiner la qualité.

Persistance, fichiers locaux, et identifiants selon l'hébergeur

C'est là que les opérateurs se font avoir. Le tableau ci-dessous utilise les informations de la documentation officielle et la recherche communautaire, non des résultats de tests déclarés.

Le write-up 2026 de Shareuhack signale une particularité spécifique qui mérite d'être citée :

« Chaque exécution de Cloud Routine effectue un clone frais dans l'environnement cloud d'Anthropic, elle ne peut pas accéder à votre .env.local local, aux bases de données locales, ou à tout autre état local. »

Et une autre : l'accès réseau dans les routines cloud est par défaut « trusted », ce que certaines API rejettent carrément. Si vous frappez ClickUp ou une autre API qui rejette les demandes en mode trusted, passez à un accès réseau « full » dans les paramètres d'environnement de la routine. Il y a un petit compromis de sécurité, pesez-le donc contre la sensibilité de votre dépôt.

Pour GitHub Actions, les secrets vivent dans les paramètres Secrets du dépôt et sont injectés en tant que variables d'environnement au runtime. L'action anthropics/claude-code-action@v1, qui repose sur le Claude Agent SDK, les récupère automatiquement. Vous passez --model, --max-turns et --allowedTools via l'entrée claude_args pour contrôler ce que l'agent peut réellement faire.

Lire le Worker de la file d'attente du blog courant

Le worker de la file d'attente du blog est une routine (ou un travail planifié équivalent) qui prend un post dans une file d'attente, génère du contenu, et le marque comme terminé. Voici la structure telle qu'elle se présente, avec des mises en garde claires sur ce que le code fait réellement par rapport à ce que vous pourriez supposer.

L'affirmation conditionnelle : le worker vérifie si un post est déjà revendiqué avant de le récupérer. Cela empêche deux exécutions de saisir le même élément simultanément, du moins en cas de succès. Ce que le code actuel n'a pas, c'est la récupération de revendication obsolète. Si un worker s'arrête en cours d'exécution avec un post marqué « en cours », ce post reste revendiqué jusqu'à ce que quelqu'un le réinitialise manuellement. Ne décrivez pas ceci comme une livraison exactement une fois ou comme une garantie d'un post par jour ; les deux affirmations vont plus loin que ce que le code supporte.

Le diagramme du worker ressemble à peu près à ceci :

1. Récupérer la queue, filtrer par status = queued
2. Réclamer le premier post disponible (définir status = in_progress, écrire un timestamp)
3. Exécuter le prompt de génération contre les métadonnées du post réclamé
4. En cas de succès : définir status = published, écrire le chemin de sortie
5. En cas d'échec : incrémenter retry_count, réinitialiser status = queued (s'il reste des tentatives) ou définir status = failed

L'étape 5 est celle où la plupart des équipes sous-investissent. La logique de retry doit vivre dans le prompt de routine ou le script wrapper, car l'infrastructure cloud elle-même ne réexécute pas une routine qui se termine avec une erreur.

Si vous construisez des pipelines de contenu comme ceci et voulez que la couche agentic soit gérée pour vous, le travail que nous faisons en agentic engineering couvre exactement ce pattern.

Planifier les jobs dus et gérer les retries

La planification d'une routine via la CLI nécessite Claude Code v2.1.225 ou ultérieur. Avant v2.1.211, la CLI rapportait un temps de prochaine exécution fantôme (année 1) pour les routines sans déclencheur de planification. Utile à savoir si vous lisez d'anciens logs.

Une routine avec seulement des déclencheurs API ou événement GitHub n'a pas de prochaine heure d'exécution. La CLI n'affiche rien. C'est le comportement correct, pas un bug.

Pour la gestion des retries, vous avez deux options :

• Retry à l'intérieur du prompt. Écrivez le prompt pour retenter l'étape défaillante jusqu'à N fois avant de marquer le job comme échoué. Le raisonnement de Claude peut distinguer une erreur réseau transitoire d'un problème de contenu authentique.
• Retry via une routine planifiée séparée. Une routine légère de « requeue » s'exécute toutes les heures, recherche les posts où status = queued et retry_count < 3, et retrigger le worker principal via son déclencheur API (un POST vers le point de terminaison par-routine avec un bearer token).

Le deuxième pattern est plus propre à l'échelle. Il découple la politique de retry du prompt de génération, et vous pouvez ajuster les limites de retry sans toucher à la routine principale.

Les plafonds d'exécution quotidienne et l'utilisation d'abonnement partagée sont une vraie contrainte pour les équipes, comme le souligne le rapport Arcade enterprise. Leur recommandation : grouper le travail dans une routine quotidienne unique de « meta-orchestrator » et réserver les déclencheurs en temps réel aux événements prioritaires uniquement.

Pour le côté récupération de mots-clés SEO d'un pipeline de contenu, la stack d'automatisation que nous avons documentée à DataForSEO + Claude Code gère cela séparément et vaut la peine d'être lue avant de concevoir le schéma de queue.

Détecter les réclamations bloquées et vérifier la sortie publiée

Les réclamations obsolètes sont le tueur silencieux des pipelines basés sur queue. Un post qui est en in_progress depuis six heures est presque certainement bloqué, pas en cours d'exécution.

Une routine de détection peut être aussi simple que :

• Requêter les posts où status = in_progress et claimed_at < now() - 2 heures
• Réinitialiser ceux-ci à status = queued, mettre à zéro l'identifiant du worker, enregistrer la réinitialisation
• Alerter via Slack ou un webhook si le nombre de réinitialisations dépasse un seuil

Exécutez ceci comme une routine basse fréquence distincte (toutes les deux heures convient) plutôt que de l'intégrer au worker principal. La séparation des responsabilités importe ici : le worker principal ne doit pas être chargé de nettoyer après lui.

Vérifier la sortie publiée est un problème différent. « Publié » en tant que flag de statut signifie que la base de données a été écrite. Cela ne signifie pas que l'article est apparu correctement sur le site, qu'il a passé une vérification de lisibilité, ou qu'il a été indexé. Une étape de vérification devrait :

• Récupérer l'URL en direct et confirmer qu'elle retourne un 200
• Vérifier le nombre de mots ou un signal de qualité léger par rapport à un seuil défini (choisissez votre propre nombre et étiquetez-le comme une heuristique d'équipe, pas une norme universelle)
• Si la vérification échoue, revenir le statut à queued avec un retry_count incrémenté et un flag verification_failed

Le pipeline humanizer que nous avons décrit à AI Content Humanizer Pipeline exécute une étape de vérification post-publication similaire et mérite d'être référencée si vous construisez cette couche.

Coût d'exploitation et propriété

C'est là que le récit « les routines sont plus simples » rencontre des frictions.

Les Routines Cloud s'exécutent sur l'infrastructure d'Anthropic et consomment les limites de session Claude Code de la même manière qu'une session interactive. L'aperçu de recherche le rend explicite : les routines consomment vos limites. Pour un petit opérateur indépendant exécutant trois ou quatre routines par jour, c'est probablement acceptable. Pour une équipe groupant 20+ exécutions quotidiennes, vous atteindrez le plafond et devrez prévoir une architecture autour.

GitHub Actions est gratuit pour les repos publics et facturé par minute pour les repos privés. Une exécution d'agent Claude Code dans Actions via anthropics/claude-code-action@v1 consomme toujours des tokens API (facturés à votre tarif API Anthropic), mais vous contrôlez entièrement le runner, le timeout et la logique de retry. Cette propriété est l'essentiel.

Le partage des responsabilités en pratique :

• Les Routines possèdent : les tâches lourdes en jugement qui nécessitent le raisonnement de Claude, les tâches qui doivent s'exécuter sans surveillance sans surcharge d'infrastructure, les revues PR déclenchées par GitHub, et le triage Sentry/logs.
• GitHub Actions possède : les pipelines CI/CD, la gestion des événements PR et les flux d'installation, les séquences déterministes build-test-deploy, et toute tâche où un script Python de 10 lignes fait réellement le travail.

Ni l'un ni l'autre ne remplace l'autre. L'article Shareuhack l'expose bien : « La combinaison optimale laisse GitHub Actions gérer la CI/CD tandis que les Routines gèrent les parties intensives en raisonnement. » Cette formulation est correcte, et c'est la limite décisionnelle qui mérite d'être gardée en mémoire.

FAQ

Une Routine Cloud peut-elle écrire dans mon repository ?

Oui. Les Routines se connectent à un ou plusieurs repositories, et elles peuvent faire des commits push et ouvrir des pull requests via le repo connecté. Ce qu'elles ne peuvent pas faire, c'est accéder aux fichiers qui n'existent que sur votre machine locale. Tout ce dont la routine a besoin doit être dans le repo ou configuré comme une variable d'environnement dans les paramètres d'environnement cloud de la routine.

Que se passe-t-il si une Routine Cloud atteint une limite de débit en pleine exécution ?

La routine elle-même ne réessaie pas automatiquement en cas d'erreurs de limite de débit. Si elle se termine avec une erreur, elle reste échouée jusqu'à la prochaine exécution planifiée ou jusqu'à ce que vous la déclenchiez manuellement via le point de terminaison API. Intégrer une logique de retry dans la prompt (détecter une réponse de limite de débit, attendre, tenter à nouveau) ou utiliser une routine de requeue distincte sont tous deux des atténuations raisonnables.

L'installation de l'application GitHub est-elle distincte de la commande /web-setup du CLI ?

Oui, et cela prend beaucoup de gens au dépourvu. Exécuter /web-setup dans le CLI accorde l'accès de clonage à la routine mais n'installe pas l'application GitHub. La livraison par webhook pour les déclencheurs d'événements GitHub nécessite l'installation distincte de l'application GitHub. Le flux de configuration de la routine vous y guide, mais les deux étapes sont distinctes.

Les déclencheurs d'événements GitHub dans les Routines ont-ils des limites de débit pendant l'aperçu de recherche ?

Selon la documentation officielle des routines, les événements webhook GitHub sont soumis à des plafonds horaires par routine et par compte lors de l'aperçu de recherche. Les événements au-delà du plafond sont supprimés jusqu'à la réinitialisation de la fenêtre. Prévoyez en conséquence si vous attendez des rafales d'activité PR.

Puis-je utiliser des skills dans un workflow GitHub Actions avec `anthropics/claude-code-action` ?

Oui. L'entrée prompt accepte les invocations de skills comme /skill-name . Vous devez avoir une étape actions/checkout avant l'action pour que les fichiers de skills dans .claude/skills/ soient présents sur le runner. Les skills et les commandes sont des concepts distincts dans Claude Code ; consultez la documentation officielle des skills avant de les confondre.

La mise en garde la plus importante de tout ce qui précède : les Cloud Routines consomment vos limites de session Claude Code exactement comme le font les sessions interactives, et le worker de file d'attente actuel n'a pas de récupération de réclamation obsolète intégrée. Concevez votre solution pour les deux avant de la déployer en production.