Claude Code automatisation : hooks, routines et CI/CD

Un développeur qui travaille avec Claude Code en mode interactif valide chaque écriture de fichier, chaque commande shell, chaque proposition de refactorisation. Ce rythme convient à l'exploration d'un code existant, beaucoup moins aux tâches qui reviennent chaque jour : formater un fichier après modification, relire une pull request, produire un rapport de dépendances obsolètes. L'automatisation consiste précisément à sortir ces tâches de la boucle de validation humaine, en gardant un contrôle sur ce que l'agent a le droit de faire.

Ce que Claude Code automatise réellement

Un agent qui exécute plutôt qu'il ne répond

L'interface web de Claude produit une réponse textuelle que vous copiez ensuite dans votre éditeur. Claude Code vit dans le terminal et manipule directement le dépôt : (cite index="9-4">il lit les fichiers, raisonne dessus, écrit et modifie du code, exécute des commandes, observe la sortie, et recommence jusqu'à ce que la tâche soit terminée. Cette boucle agentique est ce qui rend l'automatisation possible, puisque l'outil corrige lui-même un test qui échoue ou une ligne de lint non conforme.

La limite tient à la nature de cet outil : (cite index="9-6">Claude Code n'a pas de runtime persistant par défaut, il termine la tâche et s'arrête. Toute automatisation revient donc à organiser le déclenchement : un script, un événement de cycle de vie, un planificateur. Les équipes qui en tirent le plus sont celles qui ont déjà des rituels codifiés, revue de pull request, génération de changelog, mise à jour de documentation technique.

Installer la CLI et poser le contexte avec CLAUDE.md

L'installation passe par le gestionnaire de paquets Node, suivie d'une authentification au premier lancement, soit avec un abonnement Claude, soit avec une clé API rattachée à une organisation. Le choix a des conséquences directes sur l'automatisation : un abonnement individuel suffit pour des exécutions ponctuelles depuis un poste de développement, tandis qu'une clé API facturée à l'usage s'impose dès qu'un serveur ou un runner CI déclenche des sessions sans qu'un humain soit connecté.

Le fichier CLAUDE.md placé à la racine du dépôt est lu à chaque démarrage de session et joue le rôle de mémoire projet : conventions de nommage, commandes de build et de test, architecture des dossiers, interdits explicites. Un CLAUDE.md précis réduit le nombre d'aller-retours nécessaires pour obtenir un résultat correct, ce qui compte double en mode automatisé puisque personne ne corrigera l'agent en cours de route. Un fichier claude md par sous-projet reste possible dans un monorepo, les instructions les plus proches du répertoire de travail prenant le dessus.

Les quatre mécanismes d'automatisation de Claude Code

Le mode headless et le drapeau -p

Le drapeau -p lance Claude Code en mode non interactif : il reçoit un prompt, exécute la tâche, écrit le résultat sur la sortie standard et rend la main. C'est la brique de base de toute automatisation, celle qui se branche dans un script shell, une tâche cron locale, un Makefile ou une étape de pipeline. Le format de sortie JSON permet de récupérer le texte produit, le coût de la session et son statut dans un objet exploitable par un autre programme.

Ce mode se combine avec des restrictions d'outils pour limiter le périmètre d'action, par exemple autoriser la lecture et l'écriture dans un dossier précis sans accorder l'accès au réseau. Un code de sortie non nul signale l'échec au script appelant, ce qui suffit à faire tomber un job CI sans logique supplémentaire.

Les hooks de cycle de vie

Les hooks sont des rappels déclenchés à des moments précis de la boucle d'exécution. La liste couvre notamment (cite index="14-2">PreToolUse, PostToolUse, PostToolUseFailure, Notification, UserPromptSubmit, SessionStart, SessionEnd, Stop, SubagentStart, SubagentStop, PreCompact et PermissionRequest. Chacun reçoit un objet typé décrivant l'événement, par exemple le nom de l'outil appelé et ses paramètres pour un PreToolUse.

Deux propriétés rendent ce mécanisme intéressant en production : (cite index="17-2">les hooks s'exécutent dans votre processus applicatif et non dans la fenêtre de contexte de l'agent, ils ne consomment donc pas de contexte, et (cite index="17-3">un hook PreToolUse qui rejette un appel d'outil empêche son exécution, Claude recevant le message de rejet à la place. Le comportement devient déterministe là où un simple prompt resterait une recommandation.

Les skills et commandes slash personnalisées

Une commande slash est un fichier Markdown déposé dans le répertoire de commandes du projet et invoqué par son nom dans une session. Elle encapsule un prompt long, testé et versionné, que toute l'équipe appelle de la même façon. Les skills vont plus loin en embarquant des instructions, des scripts et des ressources que l'agent charge quand la tâche le justifie.

L'intérêt pour l'automatisation est la reproductibilité : la même formulation produit des résultats comparables d'une exécution à l'autre, et le fichier vit dans le dépôt, donc il passe en revue de code comme n'importe quel autre artefact. Une commande de préparation de release ou de rédaction de message de commit se partage ainsi sans copier-coller de prompt.

Les routines et exécutions planifiées

Côté infrastructure gérée, (cite index="2-3">Claude Code sur le web exécute des sessions sur l'infrastructure cloud d'Anthropic, et une routine y est une configuration enregistrée : un prompt, un ou plusieurs dépôts et des connecteurs, empaquetés pour tourner sans surveillance sur un horaire, en réponse à des événements GitHub, ou sur appel HTTP. La routine remplace le couple serveur plus crontab pour les équipes qui ne veulent pas héberger de runner.

Le pendant côté API porte le nom de déploiement planifié : (cite index="1-2">il permet à un agent de démarrer des sessions de façon autonome, pour accomplir des tâches à une cadence prévisible. Les deux approches partagent la même idée, une configuration figée qui s'exécute seule, et imposent la même discipline sur les permissions.

Configurer les hooks dans settings.json

La configuration se fait en deux endroits distincts : (cite index="15-3">les scripts de hook dans le dossier .claude/hooks, qui décrivent le comportement à exécuter, et la configuration dans le fichier de réglages, qui décrit quand le hook doit se déclencher. Le bloc de configuration associe un événement, un matcher qui filtre les outils concernés et une liste de commandes à lancer. (cite index="12-5">Les hooks déclarés dans settings.json acceptent plusieurs types : command pour un script shell, http pour un POST vers un endpoint, prompt pour une évaluation par le modèle et agent pour lancer un agent vérificateur, et (cite index="12-6">ils se déclenchent dans l'agent principal comme dans les sous-agents qu'il lance.

Trois automatisations couvrent la majorité des besoins quotidiens d'une équipe de développement :

• Formatage automatique : un hook PostToolUse sur les outils Write et Edit lance le formateur du projet sur le fichier modifié, ce qui évite les diffs parasites dans la pull request.
• Blocage de commandes dangereuses : un hook PreToolUse sur Bash inspecte la commande et la refuse. Dans un exemple publié sur le forum de la communauté n8n, un script de ce type bloque les commandes qui exposeraient des secrets, (cite index="16-5">un code de sortie 2 bloquant l'appel et affichant la raison à Claude même si une règle d'autorisation l'aurait laissé passer.
• Notifications et journal d'audit : un hook PostToolUse qui envoie une requête HTTP vers un webhook interne permet de tracer chaque modification de fichier, avec horodatage et nom de l'outil.

Déclencher sans surveillance : routines et pipelines CI

Choisir le bon déclencheur : cron, API ou GitHub

Le déclencheur horaire repose sur une syntaxe cron classique : (cite index="3-11">une expression POSIX à cinq champs, minute, jour du mois, mois, jour de la semaine, associée à (cite index="1-13">un identifiant de fuseau IANA, avec (cite index="1-9">une granularité maximale à la minute. Attention aux raccourcis : (cite index="3-13,3-14">la syntaxe cron étendue, les champs secondes ou année, les caractères spéciaux L, W, # et ?, ainsi que les raccourcis prédéfinis comme @daily ne sont pas pris en charge. La documentation recommande d'ailleurs (cite index="1-27">de planifier hors de la fenêtre locale 1h-3h, ou d'utiliser UTC, quand une exécution manquée ou dupliquée n'est pas acceptable, à cause des changements d'heure.

Le déclencheur API ouvre les cas d'usage réactifs, par exemple relancer une analyse quand un job CI échoue. Il faut (cite index="2-7,2-8">générer un jeton depuis l'écran d'édition de la routine, en ajoutant un déclencheur de type API, ce jeton n'étant affiché qu'une seule fois et ne pouvant pas être récupéré ensuite. Les quotas bornent l'usage : (cite index="2-1">chaque routine accepte jusqu'à 30 déclenchements par heure, partagés entre les appels API, le bouton d'exécution manuelle et les ré-armements, et chaque compte est limité à 100 déclenchements API par heure toutes routines confondues, selon la documentation de la plateforme Claude.

Revue de pull request et quality gates dans le pipeline

Le cas d'usage le plus adopté reste la revue automatique sur chaque pull request. Une étape GitHub Actions lance Claude Code en mode headless avec un prompt cadré, lui donne accès au diff et lui demande de signaler les problèmes de sécurité, les oublis de tests ou les écarts aux conventions décrites dans le CLAUDE.md du dépôt. La sortie est publiée en commentaire sur la pull request, ce qui laisse au relecteur humain un point de départ plutôt qu'une page blanche.

Pour transformer cette revue en quality gate, demandez une réponse structurée en JSON avec un champ de verdict et une liste de constats numérotés par fichier et par ligne. Le script appelant parse ce JSON, échoue le job au-delà d'un seuil de sévérité, et archive le document comme artefact de build. Ce format évite d'interpréter du texte libre et permet d'alimenter un tableau de bord ou un ticket automatiquement.

Passer à l'échelle : sous-agents et garde-fous

Paralléliser avec des sous-agents spécialisés

La plateforme Claude propose une (cite index="8-9">orchestration multi-agents qui permet à l'agent d'une session de confier du travail à d'autres agents, en sous-agents ou dans des workflows, avec des (cite index="8-10">workflows dynamiques, c'est-à-dire des programmes que l'agent écrit pour lancer plusieurs agents en arrière-plan et combiner leurs résultats. Un audit de sécurité, une migration de dépendances et une mise à jour de documentation peuvent tourner en parallèle sur le même dépôt, chacun avec son propre contexte.

Un piège revient souvent dans les configurations multi-agents : (cite index="11-16,11-17">les sous-agents n'héritent pas automatiquement des permissions de l'agent parent, ce qui multiplie les demandes d'autorisation, et la parade consiste à auto-approuver certains outils via des hooks PreToolUse ou à configurer des règles de permission qui s'appliquent aux sessions de sous-agents. Sans cela, une exécution censée tourner seule reste bloquée sur une invite.

Contexte, coûts et permissions : les trois points de vigilance

Une session longue finit par saturer sa fenêtre de contexte et déclenche une compaction qui fait perdre des détails utiles. Découper la tâche en étapes courtes, chacune avec son propre run et un fichier intermédiaire sur disque pour passer le relais, donne des résultats plus stables qu'une consigne unique de plusieurs centaines de lignes. Côté budget, les SDK exposent des limites dures : (cite index="19-1,19-2">dépasser le nombre de tours ou le budget met fin au run avec une erreur terminale, error_max_turns ou error_max_budget_usd, et l'exécution s'arrête une fois la dépense déjà au-dessus du plafond, donc un cycle peut se terminer légèrement au-delà.

Le risque le plus concret reste la permission trop large. Désactiver globalement les demandes d'autorisation sur un poste qui contient des clés de production revient à confier un shell non supervisé à un processus qui improvise ses commandes. La bonne configuration combine une liste d'outils autorisés explicite, des règles de refus sur les chemins sensibles, un hook PreToolUse qui inspecte les commandes shell et un environnement isolé. Une exécution planifiée peut aussi échouer silencieusement : (cite index="1-16">un déploiement ne se déclenche pas si la ressource d'environnement a été archivée, ou si la création de session est limitée en débit, d'où l'intérêt de surveiller l'historique des runs plutôt que de supposer qu'ils ont eu lieu.

Cas d'usage concrets de l'automatisation

Au-delà de la revue de pull request, plusieurs automatisations se mettent en place en quelques heures et se maintiennent seules :

• Analyse de sécurité périodique : une routine hebdomadaire qui parcourt le dépôt, repère les secrets en clair, les dépendances vulnérables et les requêtes SQL concaténées, puis ouvre un ticket par constat.
• Triage des tickets entrants : à l'arrivée d'une issue, l'agent qualifie le problème, cherche le fichier concerné dans le code, propose un plan de correction et, pour les cas simples, ouvre une pull request de correctif.
• Tâches répétitives de maintenance : correction des erreurs de lint, migration d'un appel d'API déprécié sur l'ensemble des fichiers, mise à jour de la documentation après un changement de signature.
• Design system : génération de composants conformes aux tokens existants et détection des écarts entre la bibliothèque de composants et son usage réel dans l'application.

Un point commun à ces exemples : le résultat passe par une revue humaine avant fusion. L'agent prépare le travail, il ne le valide pas.

Questions fréquentes sur l'automatisation avec Claude Code

Claude Code peut-il s'exécuter sans intervention humaine ?

Oui, via le mode headless, une routine planifiée ou un déploiement programmé. Le prix de cette autonomie est une configuration de permissions stricte en amont, puisque l'agent ne pourra pas demander d'arbitrage en cours d'exécution.

Quelle différence entre un hook et une routine ?

Un hook réagit à un événement interne à une session en cours, typiquement avant ou après l'appel d'un outil, et s'exécute en dehors du contexte du modèle. Une routine est une configuration enregistrée qui démarre une session entière, sur horaire, événement GitHub ou appel HTTP. Le hook contrôle le comportement, la routine déclenche le travail.

L'option qui ignore les permissions est-elle utilisable en production ?

Elle supprime les demandes de confirmation et donc le dernier filet de sécurité avant une commande destructrice. Son usage raisonnable se limite à un conteneur jetable, sans accès au réseau interne ni aux secrets, avec un dépôt monté en lecture seule quand c'est possible. Sur une machine partagée ou un serveur de production, préférez des règles d'autorisation explicites complétées par des hooks de blocage.

Claude Code fonctionne-t-il avec n8n ou d'autres orchestrateurs ?

Oui, en l'appelant en mode headless depuis un nœud d'exécution de commande, ou en déclenchant une routine via son endpoint HTTP. La distinction à garder en tête, telle que l'éditeur n8n la formule dans sa comparaison : (cite index="9-1,9-2">n8n exécute des workflows persistants qui attendent un déclencheur puis s'exécutent, des milliers de fois, là où Claude Code exécute des tâches ponctuelles. L'orchestrateur gère la planification, les reprises sur erreur et l'historique, Claude Code gère le raisonnement sur le code.

Avant d'activer quoi que ce soit en continu, lancez la même tâche en mode headless pendant une semaine, archivez chaque sortie JSON et comparez les résultats entre eux. Si deux exécutions sur le même dépôt divergent fortement, le problème vient du prompt, pas de l'outil, et une routine planifiée ne ferait qu'industrialiser cette instabilité.

Récapitulatif

Mécanisme	Déclencheur	Cas d'usage type	Supervision requise
Mode headless (`-p`)	Appel manuel, script, étape CI	Tâche ponctuelle scriptable, sortie JSON exploitable	Faible, le script contrôle le périmètre
Hooks de cycle de vie	Événement de session (PreToolUse, PostToolUse, Stop...)	Formatage, blocage de commandes, audit, notifications	Aucune après configuration
Skills et commandes slash	Invocation dans une session ou par l'agent	Workflow répétable et versionné partagé en équipe	Humaine, en session interactive
Routines et exécutions planifiées	Cron, événement GitHub, appel HTTP authentifié	Rapport récurrent, analyse de sécurité, revue de pull request	Revue a posteriori des runs