Routines Claude Code : ce qui change pour un DSI quand l'IA sort du poste de travail

Les routines de Claude Code ne sont pas une fonctionnalité parmi d'autres : elles font passer l'outil du poste du développeur à l'infrastructure de l'entreprise. Ce basculement silencieux déplace quatre questions dans le périmètre de la DSI — permissions, périmètre de décision, traçabilité, responsabilité — qu'il faut avoir cadrées avant d'activer la première routine plutôt qu'après la cinquantième.

La première partie de ce dossier s’achevait sur une question : comment gouverne-t-on un système capable de décider, d’escalader et d’agir sans supervision humaine immédiate ? Les routines de Claude Code la rendent concrète. Jusqu’ici, Claude Code vivait dans le terminal d’un développeur, le temps d’une session, avec un humain qui validait chaque action sensible. Les routines déplacent l’exécution sur l’infrastructure cloud d’Anthropic, où un prompt sauvegardé se déclenche à horaire fixe, sur appel d’API, ou en réaction à un événement GitHub — et tourne jusqu’à son terme sans que personne valide les étapes.

Ce déplacement n’est pas un changement de produit, c’est un changement de catégorie. L’outil de productivité du développeur devient une ressource d’infrastructure de l’entreprise. Les conséquences remontent naturellement d’un cran dans l’organigramme : ce qui était arbitré par une équipe dev devient arbitré par une direction des systèmes d’information.

Ce deuxième article déplie cette bascule en cinq temps. Ce qui change techniquement avec les routines. Pourquoi c’est désormais un sujet DSI et plus seulement un sujet dev. Les quatre questions de gouvernance à poser avant tout déploiement. Le risque invisible que créent les routines mal cadrées dans la durée. Et un cadre RACI pour les gouverner sur le temps long.

Ce qui change avec les routines : trois triggers, une infrastructure, des permissions

Une routine Claude Code est une configuration sauvegardée : un prompt, un ou plusieurs dépôts de code, une sélection de connecteurs, et un ou plusieurs déclencheurs. Elle s’exécute sur l’infrastructure cloud gérée par Anthropic, ce qui signifie qu’elle continue de fonctionner quand la machine de la personne qui l’a créée est éteinte.

Trois types de déclencheurs coexistent. Le premier est temporel : une routine peut tourner toutes les heures, toutes les nuits, chaque semaine, ou selon une expression cron plus fine. Le deuxième est programmatique : chaque routine dispose d’un endpoint HTTP dédié, protégé par un jeton, sur lequel n’importe quel système externe — outil de monitoring, pipeline de déploiement, formulaire interne — peut envoyer une requête POST pour la déclencher. Le troisième est événementiel : une routine peut réagir à des événements GitHub, typiquement l’ouverture d’une pull request ou la publication d’une release. Une même routine peut combiner les trois.

Anthropic positionne cette capacité comme un équivalent cloud des tâches planifiées locales : le laptop fermé n’arrête plus le travail. Le billet officiel d’Anthropic annonçant les routines parle de Claude Code comme d’une ressource d’ingénierie qui persiste en dehors des sessions humaines. La fonctionnalité est encore en research preview au moment où ce dossier s’écrit, ce qui signifie que l’API et les limites peuvent évoluer.

Les connecteurs MCP — Slack, Linear, Sentry, Gmail, Google Drive et d’autres — sont embarqués par défaut dans l’environnement d’exécution d’une routine. L’accès réseau est paramétrable : bloqué par défaut, ouvert à une liste de domaines, ou complètement ouvert. Un garde-fou utile limite l’impact par défaut : Claude ne peut pousser que sur des branches préfixées claude/, ce qui empêche une routine mal cadrée de modifier directement une branche protégée.

Tout cela peut sonner comme une feature de plus dans un produit déjà riche. La section suivante explique pourquoi ça n’en est pas une.

Le seuil de bascule : du poste du développeur à l’infrastructure de l’entreprise

Il faut un instant pour mesurer ce que déplacent les routines. Avant elles, Claude Code était l’extension d’un humain : une session ouverte dans un terminal, un contexte fourni en temps réel par la personne qui codait, des prompts de confirmation à chaque action qui touchait au disque, au réseau, ou au dépôt. La supervision n’avait pas besoin d’être pensée — elle était l’état par défaut. Fermer le laptop suffisait à tout suspendre.

Avec les routines, cet état par défaut bascule. L’outil continue à fonctionner quand personne n’est en ligne. Il utilise des identifiants qui ont été stockés une fois, et qui continuent de servir à chaque déclenchement. Il peut ouvrir des pull requests, commenter des tickets, poster dans des canaux Slack, écrire dans des tableurs, envoyer des mails — sans qu’aucun humain valide l’action au moment où elle se produit. Techniquement, c’est toujours Claude Code. Fonctionnellement, c’est autre chose : un acteur qui agit dans le système d’information sur des plages où il n’y a personne pour superviser.

Cette bascule n’a rien d’anecdotique. Elle fait glisser le sujet d’un registre à l’autre. Tant que Claude Code vivait dans le poste du développeur, son encadrement relevait des pratiques d’équipe — revue de code, standards internes, habitudes professionnelles. Dès qu’il tourne sur l’infrastructure, en autonomie, avec accès aux dépôts et aux connecteurs de production, il entre dans un autre périmètre : celui où l’on pose les questions que l’on poserait à toute nouvelle partie prenante capable d’agir sur le système, qu’elle soit humaine ou non, interne ou externe.

Ce glissement est silencieux. Aucun contrat n’est signé, aucune intégration n’est formalisée, aucune réunion de cadrage n’est programmée. Il se joue dans l’interface d’administration, au moment où un développeur active un trigger. Et c’est précisément ce caractère silencieux qui en fait un sujet DSI plutôt qu’un sujet dev. Les choses qui entrent dans un système d’information sans qu’on les voie sont celles qu’on régulera le moins bien.

Les quatre questions de gouvernance à poser avant tout déploiement

Passer les routines au crible avant de les laisser tourner suppose de répondre à quatre questions. Elles ne sont pas nouvelles — toute DSI un peu structurée les pose déjà quand elle accueille un système tiers ou un prestataire avec accès à la production. Ce qui change, c’est que l’acteur cette fois est un agent capable d’arbitrer ses actions en contexte, et que l’usage est trop simple à activer pour que la réponse soit négociée dossier par dossier. Il faut donc un cadre par défaut, applicable à toute nouvelle routine avant sa mise en service.

Permissions

Que peut-elle lire, écrire, déclencher ? La question commence par les dépôts attachés, mais elle continue par les connecteurs embarqués dans l’environnement d’exécution et par le niveau d’accès réseau autorisé. Les connecteurs MCP sont inclus par défaut : une routine qui n’a besoin que de Slack hérite potentiellement aussi de Linear, de Gmail, et de Google Drive si rien n’est désactivé. L’accès réseau ouvert en grand, pour des raisons de confort pendant la mise au point, reste rarement refermé par la suite. Les garde-fous fournis par Anthropic — le préfixe claude/ imposé par défaut sur les pushs, par exemple — sont utiles mais peuvent être relâchés. La permission par défaut la plus prudente est celle du moindre privilège : ne donner à la routine que les accès strictement nécessaires, et documenter pourquoi chaque accès est là.

Périmètre de décision

Où est la frontière entre action autonome et escalade humaine ? Contrairement à une session interactive, une routine en cours d’exécution ne demande rien à personne. Il n’y a pas de prompt de confirmation, pas de validation au fil de l’eau. Toute la charge de cadrage repose sur la formulation du prompt initial et sur les contraintes de l’environnement.

Cette formulation reprend une observation de Mitch Ashley dans DevOps.com sur l’arrivée des routines Claude Code : pour les équipes qui déploient ces agents, l’effort ne porte plus sur la revue des actions mais sur le périmètre qu’on leur laisse au moment où on les arme. La conséquence pratique est qu’un prompt vague crée un agent vague. Un prompt qui précise ce qu’il faut faire, ce qu’il ne faut surtout pas faire, et ce qu’il faut escalader à un humain via Slack ou un ticket produit des routines tenables dans la durée.

Traçabilité

Les logs d’exécution, la reconstitution de qui a déclenché quoi, la capacité à rejouer un incident — ces questions, que la DSI pose depuis toujours pour les systèmes classiques, se posent aussi pour une routine. Avec une subtilité : le déclencheur peut être humain, programmatique, ou événementiel, et il faut pouvoir distinguer les trois. Une routine déclenchée manuellement par un développeur qui teste son prompt n’a pas le même statut qu’une routine déclenchée par un événement GitHub en production. L’absence de distinction crée un angle mort d’audit, qui se manifestera le jour où un incident forcera à reconstruire a posteriori ce qui s’est passé. La question RGPD affleure ici dès que la routine touche à des données personnelles : le traitement automatisé sans supervision humaine directe relève de régimes spécifiques qu’il faut avoir posés avant et non après.

Responsabilité

C’est la question la plus difficile et la plus souvent éludée. Quand une routine ouvre une pull request qui casse une intégration critique, qui répond ? La personne qui a écrit le prompt, partie depuis six mois ? Celle qui a approuvé l’activation dans l’interface ? L’équipe ops qui a fourni les identifiants du connecteur qui a propagé l’erreur ? La DSI qui a autorisé le déploiement de routines sans politique formelle ? Cette question n’a pas de réponse technique, elle a une réponse organisationnelle. La dernière section de cet article propose un cadre pour y répondre.

Le risque invisible : la dette opérationnelle des routines mal cadrées

La dette technique est un coût caché qui absorbe 20 à 40 % du budget IT. Elle est désormais bien documentée, on sait la mesurer, la chiffrer, la réduire. Les routines introduisent une variante moins lisible, qu’on peut appeler la dette opérationnelle : une accumulation silencieuse de traitements automatisés qui continuent à s’exécuter sans qu’on les questionne.

Quelques signes faciles à reconnaître : des routines qui postent quotidiennement dans un canal Slack que personne ne lit plus ; des routines dont la clé de connecteur est expirée depuis des semaines mais qui réessaient chaque nuit ; des routines qui ont été écrites par une personne partie de l’entreprise et que personne n’ose désactiver, parce qu’on ne sait plus exactement ce qu’elles font ; des routines qui agissent sur des dépôts archivés ou renommés, générant des erreurs qui remontent dans les logs d’Anthropic sans atteindre qui que ce soit dans l’organisation. Chacun de ces cas coûte peu en isolé. Ensemble, ils forment une couche d’entropie qui se superpose au système d’information sans valeur associée.

La comparaison avec les scripts cron hérités est immédiate : tout DSI a rencontré ces tâches planifiées qu’on ne touche plus parce qu’on ne sait plus pourquoi elles tournent. La différence est que les scripts cron font toujours la même chose. Les routines, elles, décident en contexte — donc leur comportement peut dériver silencieusement à mesure que le contexte change. Un nom de canal Slack modifié, un label Linear renommé, une convention de nommage interne qui évolue, et la routine produit autre chose que ce qu’on attendait d’elle, sans qu’aucun message d’erreur ne le signale. Le jour où la dérive devient visible, diagnostiquer son origine prend plus de temps que pour un script dont on pourrait relire le code d’un œil.

La bonne pratique qui désamorce cette dette n’est pas technique, elle est organisationnelle : chaque routine active doit avoir un responsable nommé, une date de revue, et une procédure de sortie documentée. Cela suppose aussi de prioriser à l’arrivée plutôt qu’au départ. La matrice MoSCoW, utile pour arbitrer les fonctionnalités d’un projet, sert aussi à arbitrer les routines à déployer : celles qui doivent absolument tourner, celles qui apporteraient un vrai gain, celles qui ne sont que commodes, et celles dont on n’a pas vraiment besoin. Les trois premières catégories sont les seules qui justifient le coût de gouvernance qu’une routine active demande — et la dernière, qui ne se présente jamais comme telle, est celle qui génère l’essentiel de la dette opérationnelle quand on la laisse s’installer.

Ce que vous devez retenir

Les routines de Claude Code ne sont pas un outil de productivité individuel, ce sont un acteur de l’infrastructure. Ce basculement ne se voit pas à l’écran — techniquement, c’est le même Claude Code qu’auparavant. Il se voit dans les permissions accordées, dans le périmètre de décision laissé à l’agent, dans la traçabilité des actions qu’il effectue, dans la chaîne de responsabilité qui s’active quand quelque chose dérape. Ce sont les quatre questions que la DSI doit avoir cadrées avant d’autoriser une première routine, et que le déploiement suivant doit pouvoir reprendre sans renégocier chaque point.

Sur le terrain, cette gouvernance prend la forme d’un cadre de rôles explicites. Ce qu’on pratique pour les décisions applicatives — les rôles de la matrice RACI — s’applique aussi aux agents autonomes, avec un ajustement : l’acteur exécutant n’est plus humain. Sur une routine de triage d’alerte type, qui reçoit via son endpoint API les événements remontés par un outil de monitoring et publie un résumé d’astreinte sur Slack, la RACI peut se lire comme suit.

Ce cadre n’a rien d’original. Il n’est que le RACI appliqué à un nouvel objet. Ce qui est nouveau, c’est l’objet — et c’est précisément parce que l’objet est nouveau qu’il vaut la peine de poser le cadre dès la première routine plutôt que de le reconstruire en urgence à la cinquantième. Une organisation qui adopte les routines sans ce cadre ne les encadrera pas mieux que les scripts d’équipe qu’elle avait déjà du mal à gouverner. Une organisation qui pose le cadre dès le départ crée une capacité qui scale.

Cela ne règle pas pour autant la question la plus difficile, celle qui ferme ce dossier. Les routines de Claude Code offrent une autonomie qui permet d’agir sur le cycle de vie complet d’une application métier — de la maintenance corrective à la surveillance continue, de l’intégration continue à la modernisation d’un existant. Cette possibilité n’en fait pas une recommandation. À quelles étapes de ce cycle l’IA agentic apporte-t-elle une vraie valeur, et à quelles étapes introduit-elle un risque que seul le jugement humain peut arbitrer ? C’est la question sur laquelle se refermera ce dossier.