Claude Routines et Opus 4.7 : Journal de bord de ma première intégration

Claude Routines et Opus 4.7 : Journal de bord de ma première intégration

Il était 6 h 47 ce vendredi matin et mon téléphone était posé face contre la table de nuit. Dans la cuisine, quelque chose que je n’avais pas lancé, sur une machine qui n’était pas la mienne, était en train de lire mes dernières 24 heures d’emails, de les trier en trois piles, de rédiger des réponses aux cinq qui en avaient besoin, et de déposer un résumé sur Slack dans #morning-brief avec les objets des messages et un score d’urgence en une ligne pour chacun.

Quand je suis entré prendre mon café, le résumé attendait déjà dans Slack depuis 31 minutes. Deux brouillons de réponse étaient déjà dans mon dossier de brouillons Gmail, nécessitant environ neuf mots de retouche chacun avant que j’appuie sur envoyer. Une troisième réponse était signalée par la routine elle-même comme « nécessite votre contexte — ne pas envoyer ». L’ordinateur portable sur mon bureau était fermé depuis 23 h 14 la veille.

C’est la première semaine où je peux prononcer cette phrase — « quelque chose s’est exécuté pendant que je dormais, sur une machine qui n’était pas la mienne » — à propos d’un workflow que j’ai construit moi-même, en moins de trois minutes, sans écrire une ligne de syntaxe cron ni lancer une instance EC2. Voilà ce qui a été livré quand Anthropic a lancé Claude Routines le 14 avril 2026, deux jours avant la sortie d’Opus 4.7 le 16 avril. Ces deux lancements sont indissociables. Routines est le conteneur. Opus 4.7, c’est ce qui rend le travail à l’intérieur du conteneur réellement utile, au lieu d’être simplement planifié.

J’ai maintenant fait tourner six routines sur sept jours. Deux ont été mises en production. Deux ont été entièrement reconstruites après des échecs que la documentation ne mentionne pas. Une a été supprimée entièrement. Et une tourne en ce moment même, en arrière-plan, pendant que j’écris cette phrase.

Ce qui suit n’est pas une ré-annonce. Si vous voulez le communiqué de presse, celui d’Anthropic est très bien. Ce qui suit, c’est ce que ça fait vraiment de construire avec Claude Routines sur Opus 4.7 la toute première semaine de leur existence : les patterns qui fonctionnent, les modes d’échec que j’ai rencontrés, la posture de sécurité à adopter avant de donner accès à votre boîte mail à une tâche planifiée, et les workflows spécifiques que je construirais ensuite si j’avais un autre week-end libre.

Laissez-moi commencer par expliquer ce que sont vraiment les Routines, parce que la moitié des articles que j’ai lus cette semaine se trompent systématiquement sur un détail.

Ce que sont réellement les Routines (et ce qu’elles ne sont pas)

Une Routine est une configuration Claude Code sauvegardée — un prompt, un ensemble de dépôts, un ensemble de connecteurs et un déclencheur — qui s’exécute sur l’infrastructure d’Anthropic selon une planification, un appel d’API ou un événement de webhook GitHub. Lorsque le déclencheur s’active, Anthropic lance une nouvelle session Claude Code, y injecte votre prompt enregistré, lui donne accès aux connecteurs que vous avez approuvés, laisse le processus aller jusqu’à son terme, puis détruit la session. Votre ordinateur local n’est pas impliqué. Votre laptop peut rester fermé. Vous pouvez même être dans un avion, en mode avion.

C’est ce dernier point qui a fondamentalement changé ma façon de concevoir ce type d’outils. Chaque workflow d’IA planifié que j’ai pu bâtir auparavant — chaque cron job lançant un script Python qui appelle une API, chaque GitHub Action déclenchant Claude via le SDK — dépendait du fait qu’une de mes machines soit allumée, connectée et opérationnelle. Pour la première fois, avec les Routines, cette dépendance disparaît.

Voilà ce que les Routines ne sont pas. Ce ne sont pas un remplacement d’n8n. Ce ne sont pas un killer Zapier. Ce ne sont pas un outil de création de workflows visuels où l’on assemble des blocs par glisser-déposer. Ce sont un prompt sauvegardé, des déclencheurs, des autorisations d’outils, et un espace où Claude peut s’exécuter le temps nécessaire à la tâche. L’interface visuelle, c’est le panneau Routines de l’application desktop. L’intelligence, en réalité, c’est ce que Claude décide de faire quand le déclencheur s’active et qu’il lit votre prompt.

Cette distinction est cruciale, car toute la philosophie de conception est différente. Un flow Zapier échoue dès qu’une réponse API change de structure. Une Routine, en théorie, lit la nouvelle structure et s’adapte. C’est là, en pratique, qu’Opus 4.7 entre en jeu.

Déclencheurs, outils et les trois chiffres qui définissent la fonctionnalité

Les Routines prennent en charge exactement trois types de déclencheurs, et chacun a ses spécificités à bien comprendre avant d’y adosser votre workflow.

Les déclencheurs planifiés (schedule triggers) s’exécutent selon une cadence de type cron, avec une contrainte stricte : l’intervalle minimum est d’une heure. Quatre présélections sont proposées dans l’interface — horaire, quotidien, jours ouvrés, hebdomadaire — mais si vous avez besoin d’une fréquence personnalisée comme « toutes les deux heures » ou « le premier lundi de chaque mois », il faut configurer le preset le plus proche de votre besoin, puis exécuter /schedule update dans le CLI pour définir une expression cron spécifique. Toute tentative de cadence inférieure à une heure sera rejetée. Si vous espériez lancer une Routine en polling toutes les cinq minutes, ce n’est pas possible avec Routines aujourd’hui.

Les déclencheurs webhook s’activent quand votre Routine reçoit un appel API avec la clé appropriée. C’est vers celui-ci que je reviens constamment. Cela signifie que n’importe quel outil capable de faire un POST vers une URL peut déclencher une Routine — votre CRM, votre board PM, votre formulaire de contact, vos propres scripts. C’est la porte de sortie générique. Si la cadence horaire ne vous convient pas, presque n’importe quel besoin peut être solutionné en faisant POST un webhook via un autre système selon la fréquence désirée.

Les déclencheurs GitHub s’activent sur des événements de webhook GitHub — pushs, ouvertures de PR, commentaires, releases — sur les dépôts que vous reliez via l’application Claude GitHub. Durant la préversion de recherche, ces événements sont soumis à des plafonds horaires par routine et par compte. Si vous faites dix pushs en cinq minutes, toutes les exécutions de Routine ne seront pas déclenchées : certains événements seront ignorés jusqu’au prochain reset horaire. Il est important de le savoir avant d’imaginer un workflow « Claude review chaque PR » et de constater que la moitié passent à la trappe.

Trois chiffres définissent l’étendue fonctionnelle réelle des Routines, selon votre plan. Les comptes Pro peuvent exécuter jusqu'à 5 Routine(s) par jour. Les comptes Max peuvent en exécuter 15. Les comptes Team et Enterprise, 25. Des dépassements peuvent être facturés sur option. Ces plafonds sont journaliers, pas par Routine : ainsi, un utilisateur Pro lançant cinq Routines différentes une fois par jour atteint la limite. Un utilisateur Pro avec une Routine programmée sur base horaire l’aura atteinte avant 11 heures du matin.

C’est ce calcul que beaucoup se trompent la première fois qu’ils tentent de passer une Routine en production. Sur Pro, avec 5 exécutions par jour, impossible donc d’avoir un job horaire sans option de dépassement. C’est une contrainte de la préversion de recherche, très probablement temporaire, mais c’est la limite du jour.

C’est ici que la fonctionnalité devient réellement intéressante — et que le modèle qui la sous-tend commence à compter autant, voire plus, que le simple tuyautage technique.

Opus 4.7 : Pourquoi les Routines Deviennent Vraiment Utiles

Anthropic a lancé Claude Opus 4.7 le 16 avril 2026, soit deux jours après l’ouverture du preview de recherche sur les Routines. Je ne pense pas que ce soit une coïncidence. Tous les benchmarks publiés convergent : Opus 4.7 surpasse tous les modèles précédents pour les tâches longues, multi-étapes, et fortement outillées. Or, par conception, les Routines sont précisément ce type de tâches longues, multi-étapes et s’appuyant sur de nombreux outils.

Les chiffres auxquels j’accorde le plus de crédit, car ils proviennent des évaluations terrain menées par les partenaires engineering d’Anthropic (et non de jolis graphes marketing), sont les suivants. Sur les évaluations de production internes de Box, Opus 4.7 a obtenu une réduction de 56 % des appels modèle et de 50 % des appels outils comparé à Opus 4.6 ; il a aussi répondu 24 % plus vite sur les mêmes tests, en consommant 30 % d’unités AI en moins sur des tâches de bout en bout. Dans le benchmark de codage en production de Rakuten, Opus 4.7 exécute environ trois fois plus de tâches en production qu’Opus 4.6, avec des hausses à deux chiffres en Qualité de Code et Qualité des Tests. Sur CursorBench, qui mesure des workflows de développement intégrés réels dans un IDE plutôt que des problèmes synthétiques, Opus 4.7 bondit de 58 % (score Opus 4.6) à 70 % — soit un gain de 12 points sur le benchmark qui se rapproche le plus du quotidien des développeurs.

Mais le benchmark le plus pertinent pour les charges agentiques reste SWE-bench Verified. Opus 4.6 atteignait 80,8 %. Opus 4.7 atteint 87,6 %. C’est un bond de presque sept points sur un classement où chaque point gagné se mérite, et cela place Opus 4.7 devant Gemini 3.1 Pro (80,6 %) et nettement devant GPT-5.4 sur le même jeu de tâches.

Un point supplémentaire mérite d’être souligné, car c’est le détail technique numéro un à connaître avant de configurer une Routine : Opus 4.7 introduit un tout nouveau niveau d’effort appelé xhigh. Ni « extra high », ni « extended », ni « high-plus » — l’indicateur littéral, dans l’API et la CLI, est xhigh. C’est la recommandation par défaut pour Opus 4.7 pour tout raisonnement complexe et tâche agentique ; ce niveau est aussi activé par défaut dans Claude Code pour ce modèle. Concrètement, xhigh alloue plus de tokens au raisonnement interne du modèle et à l’exploration des outils avant de renvoyer un résultat. Sur un chat one-shot, c’est clairement surdimensionné. Sur une Routine qui doit récupérer vos mails, les classer, rédiger des réponses puis générer un résumé Slack sans aucune intervention humaine, c’est le niveau de calcul qu’il vous faut.

Une nuance rarement mise en avant dans les billets de blog : xhigh coûte cher. Couplé à un nouveau tokenizer dans Opus 4.7 comptant entre 1,0 et 1,35 fois plus de tokens pour le même texte qu’en 4.6, et à l’inflation naturelle du volume de sortie due au raisonnement plus poussé, vos factures API peuvent grimper de 20 % à 50 % par tâche équivalente par rapport à l’époque 4.6. Le travail est meilleur. Le travail coûte plus cher à chaque exécution. Les deux sont vrais. Si vous exécutez des Routines via l’API (hors usage inclus dans Claude Code), faites d’abord vos calculs sur un job test peu risqué avant d’activer xhigh sur une Routine destinée à tourner 25 fois par jour.

Avec les fonctionnalités et le modèle bien posés, laissez-moi vous expliquer ce que j’ai réellement construit.

La routine que j’ai expédiée : un triage matinal des emails qui fonctionne vraiment

J’ai d’abord construit la routine de triage des emails pour la même raison que tout le monde : la démo livrée par Anthropic lors du lancement était une routine de triage d’emails, et la nature du problème — entrées prévisibles, sorties limitées, validation facile — en fait le cas d’usage le plus simple pour un premier essai de la fonctionnalité. Ce à quoi je ne m’attendais pas, c’est à quel point la qualité du résultat final allait dépendre de la manière dont j’écrivais le prompt, comme si je déléguais une mission à un prestataire que je ne connaissais pas.

Voici le prompt sur lequel je me suis arrêté après trois itérations. Il est long, et c’est voulu.

Vous exécutez une tâche de triage d’email non supervisée à 6h45 heure locale.
Je ne peux pas répondre aux questions pendant l’exécution. Faites preuve
du meilleur discernement possible à chaque prise de décision. En cas de doute, rédigez un brouillon mais n’envoyez pas.

ÉTAPE 1 — RÉCUPÉRER
Récupérez tous les messages non lus de ma boîte de réception Gmail reçus
au cours des 24 dernières heures. Excluez tout ce qui se trouve dans Promotions, Réseaux sociaux ou Mises à jour.

ÉTAPE 2 — CATÉGORISER
Attribuez chaque message à exactement une de ces trois catégories :
  - URGENT — une personne nommée attend ma réponse, ou une
    échéance tombe dans 48 heures, ou une question d’argent/contrats intervient
  - À_RÉPONDRE — une réponse est attendue mais rien n’est bloqué
    et il n’y a pas d’urgence critique
  - AUCUNE_ACTION — newsletters, reçus, pour information, aucune réponse attendue

ÉTAPE 3 — BROUILLON
Pour chaque message URGENT ou À_RÉPONDRE, rédigez une réponse et enregistrez-la
dans le dossier brouillons de ma messagerie Gmail. N’envoyez pas. Adoptez mon ton,
comme dans les dix dernières réponses de mon dossier Messages envoyés
(phrases courtes, jamais “J’espère que vous allez bien”, terminaison avec “— M”). Si vous ne pouvez pas rédiger avec confiance parce qu’il vous manque un contexte dont je dispose, rédigez une réponse qui précise exactement quel contexte il vous faut et indiquez le brouillon [NEEDS_CONTEXT] dans l’objet.

ÉTAPE 4 — SYNTHÉTISER
Postez un message Slack dans #morning-brief au format suivant :
  URGENT (N) : nom de l’expéditeur en une ligne + objet en une ligne + verdict sur le brouillon
  À_RÉPONDRE (N) : même principe
  AUCUNE_ACTION (N) : nombre uniquement, pas de détail

ÉTAPE 5 — GESTION DES ÉCHECS
Si une des étapes échoue, postez dans Slack #morning-brief avec @here et
l’erreur. Un échec silencieux est le pire scénario possible. Je préfère
voir un message d’alerte que de ne rien recevoir.

ÉTAPE 6 — RÉCUPÉRATION DU CONTEXTE DES EXÉCUTIONS PRÉCÉDENTES
Avant de commencer l’Étape 1, lisez le message épinglé dans #morning-brief
de l’exécution d’hier. Si des éléments URGENT d’hier n’ont toujours
pas reçu de réponse dans mon dossier Envoyés, faites-les remonter dans le résumé du jour sous l’intitulé CARRIED_OVER.

Six étapes numérotées. Gestion explicite des échecs. Instructions claires pour extraire le contexte de la session précédente. Aucune hypothèse sur ce que Claude pourrait deviner tout seul.

La dernière étape — la récupération du contexte des exécutions précédentes — est celle qui m’a demandé deux reconstructions pour l’intégrer. Par défaut, les Routines n’ont aucune mémoire d’un run à l’autre. Chaque exécution démarre avec une session vierge. Si vous voulez que la routine d’hier éclaire celle d’aujourd’hui, il faut indiquer explicitement à Claude où regarder — un canal Slack, un Google Doc, un gist GitHub, une page Notion, tout endroit où il peut lire et écrire via un connecteur. Si vous sautez cette étape, la Routine rédigera joyeusement une nouvelle réponse au même email trois jours de suite, puisqu’à ses yeux, chaque matin est un premier matin.

L’instruction de gestion des échecs est l’autre leçon apprise à mes dépens. Ma première Routine a planté sur un message MIME mal formé et s’est arrêtée sans rien dire. Je ne l’ai su que parce que je n’avais pas reçu de résumé Slack à 7h. Le temps d’ajouter le rappel d’échec @here, j’avais déjà raté deux vrais emails urgents, pensant à tort qu’une matinée calme voulait dire qu’il n’y avait rien à répondre. Un échec silencieux est le pire scénario dans tout workflow non supervisé. Écrivez la gestion des échecs avant d’écrire le parcours idéal.

Les résultats de la première semaine

Voici à quoi ressemblent les données réelles sur sept jours pour cette Routine unique. Je vous livre ce que j’ai constaté, pas une étude de cas choisie.

Messages traités: 294 emails non lus sur 7 jours (environ 42 par jour). Précision de la catégorisation, évaluée par moi chaque matin à 9h : dans 91% des cas, je validais la classification de Claude. Les 9% de désaccords étaient presque toujours dus à une sur-classification par Claude en “URGENT” — souvent à cause d’un ton d’expéditeur perçu comme pressant, alors que le contenu n’était qu’une simple mise à jour de statut. Qualité des brouillons : 6 brouillons sur 10 envoyés après avoir modifié moins de 15 mots. 2 sur 10 entièrement réécrits. 1 sur 10 supprimé et refait à zéro. 1 sur 10 était correctement marqué [NEEDS_CONTEXT] et j’y ai répondu moi-même. Échecs silencieux : Zéro après l’ajout du rappel. Un (crash MIME) avant. Temps gagné, estimation : le triage email me prenait 25 à 35 minutes tous les matins avant cela. Avec la Routine, la revue et validation prennent 7 à 10 minutes. Soit environ trois heures par semaine de récupérées.

Un point à souligner : la Routine n’est aussi efficace que parce que le prompt est aussi détaillé. J’ai testé une version plus courte — « Trie mes emails, rédige des réponses, publie un résumé Slack » — et la performance tombait à 60%. Un prompt flou produit une routine floue. Considérez le prompt comme un cahier des charges, pas comme un simple message chat.

La Décision Incontournable : Mode Outils de Confiance vs Mode Complet

Avant qu’une Routine puisse manipuler vos outils, vous devez choisir l’un de deux modes pour celle-ci : confiance ou complet. C’est LA décision de sécurité la plus lourde de conséquences de toute la configuration, et elle mérite bien plus que les deux paragraphes que lui consacre la documentation.

En mode de confiance, la Routine ne peut accéder qu’aux outils que vous avez explicitement approuvés : Gmail, Slack, Google Drive, tout ce que vous avez activé individuellement. Si la consigne demande à Claude d’utiliser un outil non approuvé, la Routine refusera l’étape ou échouera. C’est le paramètre par défaut. C’est aussi le meilleur point de départ pour chaque workflow que vous construisez.

En mode complet, la Routine peut utiliser n’importe quel outil disposant d’un connecteur configuré sur votre compte. Si, en cours d’exécution, elle décide qu’elle doit effectuer une recherche web, écrire un fichier ou interroger une nouvelle API, elle peut le faire sans vous demander la permission. Le mode complet est la clé pour libérer le plus haut niveau d’autonomie. C’est aussi le moyen de donner accidentellement à un agent IA non surveillé le pouvoir d’envoyer un email à l’ensemble de vos clients, simplement parce que la consigne était ambiguë et que le modèle a interprété “recontacter” de façon bien plus large que prévu.

Ma règle après une semaine : construisez chaque Routine en mode de confiance, exécutez-la au moins trois fois, auditez les appels d’outils, et ne passez en mode complet que si vous êtes capable de nommer avec précision une capacité dont le mode de confiance est incapable. Toutes les Routines que j’exécute actuellement en production sont en mode de confiance. La seule Routine que j’ai testée en mode complet a été supprimée, car elle a précisément commis ce genre d’erreur qui donne envie de ne plus jamais utiliser d’agent autonome — elle a estimé que le meilleur moyen de “relancer des prospects inactifs” consistait à envoyer un mail à dix-sept personnes auxquelles je n’avais pas parlé depuis deux ans.

Il n’existe pas de solution technique satisfaisante pour résoudre l’ambiguïté des consignes en mode complet. La seule vraie solution consiste à rédiger une consigne plus précise et à fonctionner en mode de confiance.

Si vous avez déjà développé des agents de production avec l’Agent SDK, la logique vous semblera familière : la même discipline de limitation des capacités s’impose ici, avec moins de code et une interface légèrement différente. Pour une analyse plus approfondie de ces limites, consultez mon guide de l’Agent SDK Anthropic.

Ce qui a cassé, et ce que j’ai dû reconstruire

Tout ce que j’ai essayé n’a pas fonctionné. Les deux Routines qui ont le plus échoué sont plus intéressantes à expliquer que celles qui ont réussi, car leurs modes d’échec seront presque à coup sûr ceux auxquels d’autres seront confrontés lors de leur première semaine d’essais.

Échec 1 : La Routine de review PR qui se déclenchait trop souvent.
J’avais connecté un déclencheur GitHub sur un dépôt Laravel de taille moyenne — à chaque ouverture de PR, à chaque push sur une PR ouverte, lancer une review de code et la déposer en commentaire sur la PR. Un mardi chargé, j’ai poussé 11 commits sur une seule PR en l’espace d’environ 90 minutes. La Routine s’est déclenchée six fois avant de s’arrêter silencieusement. J’ai cru qu’elle avait buggué. En réalité, j’avais atteint la limite horaire par routine pour les événements webhook GitHub pendant l’aperçu de recherche, et les cinq événements restants avaient été ignorés. La documentation ne fait mention de cette limite qu’en une seule ligne ; je l’ai ratée lors de la première lecture. Ma solution : appliquer un « debounce » sur le déclencheur, pour n’agir que sur « ouverture de PR » et « passage d’une PR en prêt-à-être-reviewée », au lieu de chaque push, ce qui a réduit la fréquence de déclenchement de six-par-PR à un-par-PR, sans aucun événement perdu.

Échec 2 : La Routine de reporting hebdomadaire qui utilisait la mauvaise fenêtre temporelle.
J’ai conçu une Routine programmée tous les lundis à 8h, qui extrait mes paiements Stripe et mes gains Fiverr pour la semaine écoulée, résume la tendance, puis publie le résultat dans un canal Slack privé. À la première exécution, le chiffre obtenu était environ 40% trop bas. Le modèle avait interprété « la semaine dernière » comme « les sept derniers jours à partir d’aujourd’hui » plutôt que « la semaine calendaire précédente, du lundi au dimanche ». Comme chaque Routine s’exécute à neuf et n’a aucune mémoire de ce que « la semaine dernière » représente, il manquait un point de repère pour l’ajustement. La correction a été explicite : « Extraire les données pour la semaine calendaire débutant lundi [calcul de date en ISO-8601] et terminant dimanche [calcul de date en ISO-8601]. Pas les sept derniers jours. La semaine calendaire précédente. » Dès lors, les chiffres correspondaient exactement à mon dashboard Stripe.

Ces deux échecs partagent une structure similaire. Il s’agissait dans les deux cas d’un défaut d’assomption sur le contexte. Les prompts que j’avais écrits auraient parfaitement convenu à un collègue humain connaissant mon fonctionnement, mais se seraient révélés ambigus pour un nouveau prestataire le premier jour. Les Routines sont toujours dans cette situation de « premier jour », à chaque exécution. Rédigez vos instructions comme pour un prestataire débutant et la plupart de ces écueils disparaîtront en amont.

Si vous écrivez déjà des workflows agentiques long-terme et cherchez un cadre plus poussé pour ce type de construction de prompt, celui sur lequel je me suis appuyé cette semaine est celui que j’ai décrit dans mon test pratique d’Opus 4.6 — les principes se transposent très bien à la 4.7, avec en plus la tolérance de 4.7 à davantage d’ambiguïtés avant de dévier du script. « Davantage de tolérance » ne veut pas dire « disparition totale des erreurs ». Les prompts serrés restent les plus efficaces.

Où les Routines sont encore insuffisantes

C'est la section que la plupart des articles publiés pendant la semaine de lancement passeront sous silence, donc je vais m’y attarder. J'ai rencontré quatre véritables limites dès la première semaine qu’il est important de nommer précisément, car elles doivent influencer ce que vous construisez — et ce que vous ne construisez pas.

1. Pas de mémoire inter-exécution par défaut. J’en ai parlé plus haut, mais cela mérite d’être répété. Chaque exécution d’une Routine démarre une session Claude Code entièrement nouvelle, sans aucune mémoire de son historique. L'alternative consiste à récupérer explicitement le contexte : pointer Claude vers un canal Slack, un Google Doc, une ligne de base de données, n'importe où il peut lire le résultat d’hier avant de commencer le travail d’aujourd’hui. C’est une solution envisageable, mais elle reste manuelle ; oublier de la mettre en place, c’est s’exposer à trois jours de réponses dupliquées.

2. Cadence minimale d’une heure. Si votre tâche doit réellement s’exécuter toutes les cinq minutes — vérification d’état en continu, surveillance de signaux en temps réel, cas d’usage “trader-time” — les Routines ne peuvent pas le faire via le déclencheur planifié. La solution consiste à utiliser un déclencheur webhook appelé par un planificateur externe, mais cela revient à gérer une infrastructure ailleurs, ce qui affaiblit l’argument initial. Pour une cadence véritablement inférieure à l’heure, les Routines ne sont pas encore l’outil adapté.

3. La posture de sécurité du mode complet n’est pas assez mature. Le mode complet est aussi puissant que dangereux. Il n’existe pas de mode sandbox permettant de simuler une exécution en mode complet avant d’accéder aux outils en production. Aucun plafond de coût par outil pour empêcher un workflow d’épuiser vos jetons à cause d’une boucle défectueuse. Aucun limiteur de débit configurable individuellement sur chaque connecteur. La seule véritable protection reste la qualité de votre prompt, ainsi que le fait de commencer en mode de confiance. Les équipes professionnelles qui utilisent les Routines en mode complet sur des données clients réelles devront s’attendre à développer leurs propres garde-fous autour de la Routine — files d’attente d’approbation, logs d’audit en canal secondaire, disjoncteurs sur les dépenses.

4. Aperçu de recherche signifie une API susceptible de changer. Tout ce que j’ai écrit dans cet article est exact au 21 avril 2026. Anthropic indique clairement que la structure des requêtes et des réponses, les taux limites et la gestion des jetons sont susceptibles d’évoluer tant que les Routines restent en aperçu de recherche. Si vous construisez une infrastructure critique sur les Routines ce mois-ci, prévoyez du temps pour en réécrire une partie d’ici six mois. Ce n’est pas un défaut — c’est le compromis honnête de sortir une fonctionnalité en aperçu de recherche — mais c’est important de le rappeler : j’ai vu trop d’équipes considérer un aperçu de recherche comme une API stable et perdre des journées entières suite à un changement qu’elles n’avaient pas anticipé.

Aucune de ces limites n’est rédhibitoire. Mais toutes sont à connaître avant de confier un workflow aux Routines et de garantir à autrui qu’il fonctionnera durablement.

Si vous exécutez déjà des automatisations planifiées dans l’application de bureau Claude Code plutôt que via Routines, vous pourriez trouver mon comparatif utile dans le guide des tâches programmées Claude CoWork — les interfaces semblent similaires en apparence, mais le modèle d’exécution diffère fondamentalement, et le choix est crucial selon que la contrainte dépend ou non du fait d’avoir votre ordinateur portable allumé.

Les cinq routines que je construirais ensuite

Si je récupérais mon week-end et que je voulais tirer le maximum de valeur des Routines avant l’apparition du plafond, voilà la liste, classée par ROI par minute de configuration.

1. Triage des emails du matin + brouillons. Celle que j’ai déjà construite. Si vous ne devez en bâtir qu’une, faites celle-ci. Le temps gagné est immédiat et les modes d’échec sont limités.

2. Reporting business hebdomadaire. Stripe, Fiverr, ou quels que soient vos canaux de chiffre d’affaires, extraits chaque lundi matin, résumés sous forme de tendance, postés dans un canal Slack privé. Le bénéfice cumulatif est que vous arrêtez de penser « je devrais aller voir les chiffres », car les chiffres viennent à vous. Pour les opérateurs solo, c’est même probablement plus précieux que le triage email.

3. Triage automatique des leads entrants avec brouillons de première réponse personnalisés. Déclencheur webhook depuis le formulaire de contact de votre site. Claude récupère le message, recherche la société de l’expéditeur via son domaine en quarante secondes environ, rédige une réponse en citant un élément concret sur leur activité, sauvegarde le brouillon et vous signale dans Slack. Vous relisez et envoyez. Les temps de réponse passent de plusieurs heures à quelques minutes, sans perdre la touche humaine nécessaire à la conversion.

4. Digest du changelog quotidien pour un dépôt public. Déclencheur GitHub à chaque merge sur la branche principale. Claude extrait le diff, rédige une entrée de changelog à destination des utilisateurs dans votre ton, l’ajoute à CHANGELOG.md, ouvre une PR. Vous relisez chaque semaine. Des heures de documentation chaque mois réduites à quelques minutes de relecture.

5. Fiche de synthèse pour les réunions du lendemain. Déclencheur programmé chaque jour à 20h. Claude lit le calendrier du lendemain, extrait les intitulés LinkedIn des participants, leurs dernières publications publiques, et le dernier fil d’email avec chacun, crée une fiche d’une page par réunion et les dépose dans un Google Doc. Vous arrivez à chaque réunion avec un contexte que vous n’avez pas eu à construire pendant 30 minutes.

Aucune de ces idées n’est nouvelle. Elles sont toutes techniquement réalisables depuis des années via cron, un modèle de langage et un wrapper d’API. Si je ne les avais pas encore bâties, c’est parce que chacune nécessitait une infrastructure dont je ne voulais pas être responsable : un serveur pour exécuter le cron, un wrapper pour appeler le modèle, une file pour gérer les échecs, un moniteur pour me prévenir en cas de panne. Routines compresse toute cette pile en une configuration sauvegardée, exécutée sur l’infrastructure de quelqu’un d’autre. La vraie barrière n’était pas l’idée, mais la corvée technique.

C’est là la véritable nouveauté. Pas l’automatisation, mais l’absence de corvée. Pour aller plus loin sur ce que représente le paysage des modèles d’avril 2026 à ce moment de lancement, mon tour d’horizon des modèles d’IA d’avril 2026 donne une vue complète sur Kimi K2.6, les rumeurs autour de GPT-5.5 Spud, et la vraie position d’Opus 4.7 face au reste du marché sur des workloads concrets.

Foire aux questions

Qu’est-ce que les Claude Routines et comment fonctionnent-elles ?

Les Claude Routines sont des configurations Claude Code enregistrées — un prompt, des dépôts, des connecteurs et un déclencheur — qui s’exécutent sur l’infrastructure cloud d’Anthropic lorsqu’un planning, un appel API ou un événement GitHub est déclenché. Votre machine locale n’a pas besoin d’être en ligne. À chaque exécution, une nouvelle session Claude Code démarre sans mémoire des exécutions précédentes, sauf si vous indiquez explicitement dans le prompt où récupérer le contexte antérieur. Pour un guide d’installation complet, consultez la section Tri du mail du matin ci-dessus.

Quel est l’intervalle minimal de planification pour une Claude Routine ?

Une heure. Les déclencheurs planifiés proposent quatre préréglages — horaire, quotidien, jours de semaine, hebdomadaire — et refusent toute expression cron plus fréquente qu’une fois par heure. Pour une cadence inférieure à l’heure, utilisez un déclencheur webhook activé par un ordonnanceur externe, bien que cela réintroduise le problème d’infrastructure externe que les Routines visent justement à éliminer.

Opus 4.7 est-il meilleur qu’Opus 4.6 pour le travail agentique ?

Oui, de façon significative. Lors des évaluations des partenaires Anthropic, Opus 4.7 a effectué 56 % d’appels modèle et 50 % d’appels d’outils en moins qu’Opus 4.6 pour des tâches équivalentes, a résolu environ trois fois plus de tâches de production sur le benchmark de code de Rakuten, et est passé de 58 % à 70 % sur CursorBench. Le nouveau niveau d’effort xhigh est la valeur par défaut pour 4.7 dans Claude Code, et c’est le niveau à privilégier pour du travail multi-étapes non supervisé.

Qu’est-ce que xhigh dans Claude Opus 4.7 ?

xhigh est le nouveau niveau d’effort le plus élevé dans Opus 4.7 — c’est le nom du flag utilisé dans l’API et le CLI. Il attribue plus de tokens aux boucles de raisonnement interne et d’exploration des outils avant que le modèle ne rende réponse. C’est le niveau d’effort par défaut d’Opus 4.7 dans Claude Code et il est recommandé pour le raisonnement complexe et le travail agentique. Cela coûte cependant plus cher par tâche en raison de la boucle de raisonnement approfondie et du nouveau tokenizer, alors attendez-vous à des factures 20 % à 50 % plus élevées par tâche équivalente par rapport à 4.6.

Combien de Routines puis-je exécuter par jour avec l’offre Pro ?

Cinq exécutions de Routine par jour avec Claude Pro. Les utilisateurs Claude Max ont droit à 15 exécutions par jour. Les utilisateurs Team et Enterprise obtiennent 25 exécutions quotidiennes. La facturation hors forfait est activable si besoin de plus, mais les plafonds s’appliquent à l’ensemble de vos Routines par compte, et non par Routine — donc un utilisateur Pro qui lance cinq Routines quotidiennes différentes atteint déjà la limite.

Faut-il privilégier le mode d’outil trusted ou full pour une nouvelle Routine ?

Toujours le mode trusted pour une nouvelle Routine. Le mode trusted limite Claude aux outils spécifiques que vous avez approuvés individuellement pour cette Routine. Le mode full permet à Claude d’utiliser n’importe quel connecteur de votre compte en cours d’exécution, ce qui se révèle utile pour les workflows les plus ambitieux mais peut conduire des agents autonomes à faire des choses inattendues. Démarrez en mode trusted, faites trois exécutions propres, passez en revue les appels d’outils, et ne passez au mode full que si vous pouvez nommer une capacité précise que le mode trusted ne permet pas.

Travaillons ensemble

Vous cherchez à construire des systèmes d’IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous accompagner.

• Fiverr (conceptions sur-mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions d’entreprise) : ramlit.com
• ColorPark (design & image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io