Claude Code comme infrastructure

Andrej Karpathy a forgé un terme pour désigner ce qui se développe autour d’un agent LLM : des griffes (claws). Les hooks, scripts et systèmes d’orchestration qui permettent à l’agent de saisir le monde au-delà de sa fenêtre de contexte.¹ La plupart des gens utilisent Claude Code comme une boîte de dialogue avec accès aux fichiers. Ils tapent un prompt, regardent l’outil modifier un fichier, et passent à autre chose. Cette vision passe à côté de ce qu’est réellement l’outil.

Claude Code n’est pas une fonctionnalité d’IDE. C’est une infrastructure. Et l’écart entre le traiter comme l’un ou l’autre détermine si le développement assisté par IA reste à 10 % de gains de productivité ou perce vers quelque chose de fondamentalement différent.

TL;DR

Claude Code expose 17 événements de cycle de vie, chacun pouvant être intercepté par des scripts shell qui se déclenchent avant, pendant ou après chaque appel d’outil.² Empilez des hooks dans des dispatchers, des dispatchers dans des skills, des skills dans des agents, des agents dans des workflows, et vous obtenez une couche programmable entre vous et le modèle qui impose des contraintes que le modèle ne peut pas contourner. J’ai construit 84 hooks, 48 skills, 19 agents et environ 15 000 lignes d’orchestration en deux mois. Zéro framework. Zéro dépendance externe. Uniquement du bash et du JSON. Le résultat est un système de développement autonome qui écrit, revoit et déploie du code pendant que je dors. Cet article explique l’architecture, pourquoi la vision « IDE » freine les gens, et ce qui change maintenant que Remote Control rend cette infrastructure accessible depuis n’importe où.

La vision « IDE » est erronée

Le modèle mental par défaut : Claude Code est un autocomplete plus intelligent. Vous vous installez devant un terminal, vous lui confiez des tâches et vous supervisez le résultat. Ce modèle plafonne votre productivité à ce que vous pouvez personnellement surveiller.

Le modèle mental « infrastructure » : Claude Code est un runtime programmable avec un noyau LLM. Chaque action du modèle passe par des hooks que vous contrôlez. Vous définissez des politiques, pas des prompts. Le modèle opère au sein de votre infrastructure de la même manière qu’un serveur web opère sous les règles de nginx. Vous ne vous asseyez pas devant nginx pour taper des requêtes. Vous le configurez, le déployez et le surveillez.

La distinction compte parce que l’infrastructure se compose. Un hook qui bloque les credentials dans les commandes bash protège chaque session, chaque agent, chaque exécution autonome. Un skill qui encode votre grille d’évaluation d’articles de blog s’applique de manière cohérente, que vous l’invoquiez ou qu’un agent le fasse. Un agent qui revoit le code pour la sécurité exécute les mêmes vérifications que vous soyez présent ou non.

Simon Willison résume le moment actuel par une observation unique : écrire du code est devenu bon marché.³ C’est exact. Mais le corollaire que personne ne veut entendre, c’est que la vérification est désormais la partie coûteuse. Du code bon marché sans infrastructure de vérification produit des bugs à grande échelle. L’investissement rentable n’est pas un meilleur prompt. C’est le système autour du modèle qui attrape ce que le modèle rate.

La couche infrastructure

Le système de hooks de Claude Code déclenche des commandes shell sur 17 événements de cycle de vie.² PreToolUse se déclenche avant l’exécution d’un outil et peut le bloquer. PostToolUse se déclenche après et peut fournir un retour. UserPromptSubmit se déclenche quand vous tapez et peut injecter du contexte. Stop se déclenche quand le modèle essaie de terminer et peut le forcer à continuer. Chaque événement reçoit du JSON sur stdin avec le contexte complet : ID de session, nom de l’outil, entrée de l’outil, répertoire de travail courant.

Le système de hooks n’est pas un système de plugins. C’est une architecture événementielle. La différence : les plugins étendent les fonctionnalités d’un outil. Les événements vous permettent d’intercepter, modifier et contrôler chaque action de l’outil. Vous devenez le middleware.

Les hooks : la couche déterministe

Les hooks sont des scripts shell. Ils ne peuvent être ni hallucinés, ni contournés par la flatterie, ni détournés par injection de prompt. Le modèle veut exécuter rm -rf / ? Un script bash de 10 lignes vérifie la commande contre une liste noire et la rejette avant que le shell ne la voie. Le modèle essaie de lire .env ? Une regex sur le chemin du fichier intercepte l’appel à l’outil Read. Rien de tout cela ne nécessite la coopération du modèle. Le hook se déclenche que le modèle le veuille ou non.

J’exécute 84 hooks répartis sur 17 types d’événements. La répartition est révélatrice : 35 imposent du jugement (portes, gardes, validateurs) et 49 gèrent l’automatisation (injecteurs, loggers, trackers). Ce ratio a commencé à 1:6. Deux mois de dysfonctionnements en exécution autonome l’ont poussé à 4:5. Chaque hook de jugement existe parce que quelque chose a échoué sans lui. Un agent a commité du code avec des commentaires TODO. Un agent a exécuté une commande git destructrice. Un agent a laissé fuiter un chemin de credentials dans un fichier de log. Chaque défaillance a engendré une porte.

La leçon la plus importante : des dispatchers plutôt que des hooks indépendants. J’avais sept hooks qui se déclenchaient tous sur UserPromptSubmit, chacun lisant stdin indépendamment, deux écrivant dans le même fichier d’état JSON. Les écritures concurrentes tronquaient le JSON. Chaque hook en aval qui analysait ce fichier plantait. Un seul dispatcher par événement exécutant les hooks séquentiellement à partir du stdin mis en cache a résolu le problème. Surcoût invisible, 200 ms par prompt.

Les skills : la couche de connaissances

Les skills sont des jeux d’instructions en markdown qui s’activent à la demande ou via des hooks.⁴ Chacun encode une expertise de domaine dans laquelle le modèle puise lorsqu’il est invoqué. Mon skill blog-evaluator définit une grille pondérée à 6 catégories avec des critères de notation spécifiques, des minimums par catégorie et des interdépendances. Mon skill jiro encode une boucle qualité en 7 étapes avec une porte d’évidence qui exige des preuves spécifiques pour chaque critère.

Les skills se composent avec les hooks. Un skill peut définir ses propres hooks dans le frontmatter, qui ne s’activent que pendant l’exécution du skill. Les skills de philosophie s’activent automatiquement via les hooks SessionStart, injectant des contraintes de qualité dans chaque session sans invocation explicite.

48 skills couvrant : la qualité du code (jiro, testing-philosophy, debugging-philosophy), le contenu (blog-writer-core, blog-evaluator, citation-verifier), l’architecture (fastapi, swiftui, database, htmx-alpine), les opérations (deploy, cache, analytics, security) et la méta-orchestration (deliberation, scan-intel, ralph). Des recherches sur les préférences propres de Claude Code ont révélé qu’il gravite vers certains frameworks et patterns.⁹ Les skills vous permettent de remplacer ces comportements par défaut par les vôtres.

Les agents : la couche de délégation

Les agents sont des sous-agents spécialisés avec des fenêtres de contexte isolées.⁵ Chacun reçoit une tâche ciblée et un contexte vierge. Mon système de revue de code lance trois agents en parallèle : correction, sécurité et conventions. Chacun revoit indépendamment. Les désaccords entre relecteurs font émerger précisément les problèmes qu’un relecteur unique manquerait.

La contrainte critique : un garde-fou de récursion. Un script shell se déclenche avant chaque appel à l’outil Task, vérifie un compteur de profondeur de lancement dans un fichier d’état partagé et bloque l’appel si la profondeur dépasse un seuil. Sans cela, les agents délèguent à des agents qui délèguent à des agents, chacun perdant du contexte et brûlant des tokens. La limite par défaut est de 3 niveaux. En pratique, le travail utile se fait à la profondeur 1 (agent principal plus un sous-agent). Tout ce qui dépasse la profondeur 2 signifie généralement que la décomposition de la tâche était mauvaise.

19 agents couvrant : le développement (ios-developer, backend-architect), la revue (code-reviewer, security-reviewer, conventions-reviewer, yagni-reviewer), l’exploration (project-scout, code-explorer, code-architect) et la validation (test-runner, correctness-reviewer).

Remote Control change la donne

Le 25 février 2026, Anthropic a lancé Remote Control : la possibilité de se connecter à une session Claude Code locale depuis n’importe quel navigateur ou l’application mobile Claude.⁶ La fonctionnalité a obtenu 531 points et 313 commentaires sur Hacker News, la plupart étant des plaintes concernant des bugs. Les plaintes sont fondées. La fonctionnalité reste transformatrice.

Voici pourquoi. Avant Remote Control, l’infrastructure que j’ai décrite avait deux modes : supervisé (je regarde le terminal) ou non supervisé (je m’éloigne en croisant les doigts). Aucun des deux n’est idéal. Le mode supervisé plafonne le débit à ma capacité d’attention. Le mode non supervisé risque de laisser le modèle prendre de mauvaises décisions sans que personne ne s’en aperçoive.

Remote Control crée un troisième mode : la gouvernance asynchrone. Je lance des boucles autonomes qui traitent des PRD multi-stories pendant la nuit. Les demandes d’approbation pour les actions externes (git push, appels API, tout ce qui sort de la machine) arrivent sur mon téléphone. J’approuve, rejette ou redirige depuis n’importe où. La couche de gouvernance reste la même. La latence entre « l’agent a besoin d’une approbation » et « l’humain la fournit » passe de « quand je consulte mon laptop » à « 10 secondes depuis mon téléphone ».

Le flux d’approbation se compose avec la classification de rayon d’impact de mes hooks. Les opérations locales (écritures de fichiers, exécutions de tests) s’approuvent automatiquement. Les opérations partagées (commits git) avertissent. Les opérations externes (pushes, appels API, déploiements) sont soumises à une revue humaine. Remote Control transforme ce chemin de « soumission » d’une attente bloquante en une notification asynchrone. L’agent continue à travailler sur la story suivante pendant que je revois la précédente.

Des outils comme Agent Multiplexer gèrent déjà les sessions Claude Code via tmux.¹⁰ Des alternatives open source comme Emdash fournissent des environnements de développement agentiques complets.¹¹ Ceux qui suggèrent SSH plus tmux comme alternative ont raison : ça fonctionne pour l’accès terminal. Aucun de ces outils ne vous offre le routage des approbations. C’est ce routage qui rend l’opération sans surveillance sûre, pas seulement possible.

Le coût comme architecture

L’article « Making MCP Cheaper via CLI » (304 points HN) a documenté un pattern : encapsuler les appels d’outils MCP dans des invocations CLI pour éviter le surcoût du maintien d’une connexion à un serveur MCP.⁷ L’insight plus large est que le coût est une décision architecturale, pas une considération opérationnelle après coup.

Mon infrastructure gère le coût à trois niveaux :

Niveau tokens. Compression du system prompt. J’utilise environ 3 500 tokens de system prompt répartis dans un fichier CLAUDE.md et 8 fichiers de règles. Les réductions à fort rendement : supprimer les exemples de code tutoriel (le modèle connaît les API), consolider les règles dupliquées entre fichiers et remplacer les explications par des contraintes. « Rejeter les appels d’outils correspondant à des chemins sensibles » fait le même travail qu’une explication de 15 lignes sur pourquoi les credentials ne devraient pas être lues. Densité sémantique plutôt que compression brute.⁸

Niveau agents. Des lancements frais plutôt que de longues conversations. Chaque story d’une exécution autonome obtient un nouvel agent avec une fenêtre de contexte propre. Au moment du lancement, l’agent reçoit un briefing : état git actuel, ce que les agents précédents ont accompli, ce qu’il doit faire. Un briefing plutôt qu’une mémoire. Les modèles exécutent un briefing clair mieux qu’ils ne naviguent dans 30 étapes de contexte accumulé. Le contexte ne gonfle jamais car chaque agent démarre à zéro. Geoffrey Huntley a documenté un pattern similaire dans « The Ralph Loop », exécutant du développement autonome à 10,42 $/heure sur Sonnet.¹³ Des orchestrateurs multi-agents comme OpenSwarm formalisent le pipeline worker-reviewer avec escalade de modèle.¹⁴

Niveau architecture. CLI d’abord plutôt que MCP quand l’opération est sans état. Un appel claude --print pour une évaluation ponctuelle coûte moins cher et n’ajoute aucun surcoût de connexion. Un serveur MCP a du sens quand l’outil nécessite un état persistant ou du streaming. Context Mode a démontré l’inverse : compresser 315 Ko de sortie MCP en 5,4 Ko en utilisant l’indexation FTS5 avec le classement BM25.¹² Les deux approches réduisent la consommation de tokens, depuis des directions différentes. La plupart de mes invocations de skills sont ponctuelles. Mon analyse du cache de prompts a révélé que le CLI de Claude Code met en cache les system prompts par défaut au-delà de 4 096 tokens. Aucune configuration nécessaire.

Étude de cas : à quoi ressemblent 84 hooks en pratique

Une trace de session concrète issue d’une exécution autonome la semaine dernière, traitant un PRD avec 5 stories :

1. SessionStart se déclenche. Le dispatcher injecte : date courante, détection du projet, contraintes de philosophie, vérification des performances système, initialisation du suivi des coûts. Cinq hooks, 180 ms au total.

2. L’agent lit le PRD, planifie la première story. UserPromptSubmit se déclenche sur le prompt interne. Le dispatcher injecte : contexte du projet actif, ligne de base de dérive de session (embedding Model2Vec du premier prompt pour des vérifications de similarité ultérieures). 120 ms.

3. L’agent appelle Bash pour exécuter les tests. PreToolUse:Bash se déclenche. Le dispatcher exécute : vérification des credentials (pas de chemins .env dans la commande), validation du bac à sable (commande absente de la liste noire), détection du projet. 90 ms. Les tests s’exécutent. PostToolUse:Bash se déclenche : battement d’activité enregistré, vérification de dérive par rapport à la ligne de base (similarité cosinus 0,63, bien au-dessus du seuil de 0,30).

4. L’agent appelle Write pour créer un fichier. PreToolUse:Write se déclenche : vérification de la portée du fichier (ce chemin est-il dans le répertoire du projet ?). PostToolUse:Write se déclenche : vérification du lint sur le fichier écrit, suivi des commits, battement d’activité.

5. L’agent termine la story. Stop se déclenche. Le hook de porte qualité vérifie : l’agent a-t-il cité des preuves pour chaque critère ? A-t-il utilisé un langage évasif (« should », « probably ») ? Y a-t-il des commentaires TODO dans le diff ? Si une vérification échoue, le hook retourne exit 2 et l’agent continue de travailler.

6. Vérification indépendante : un agent frais exécute la suite de tests sans faire confiance à l’auto-évaluation de l’agent précédent.

7. Trois agents de revue de code se lancent en parallèle. Chacun revoit le diff indépendamment. Les résultats sont fusionnés. Si un relecteur signale un problème CRITICAL, la story retourne dans la file d’attente.

8. La story passe. La story suivante se charge. Le cycle se répète pour les 5 stories.

Total de hooks déclenchés sur 5 stories : environ 340. Temps total dans les hooks : environ 12 secondes. Un surcoût invisible qui a empêché trois fuites de credentials, une commande destructrice et deux implémentations incomplètes en une seule exécution nocturne.

Points clés à retenir

Claude Code est un runtime, pas un outil. Les 17 événements de cycle de vie le rendent programmable. Les hooks, skills et agents sont le jeu d’instructions. Le modèle est le moteur d’exécution. Vous êtes l’architecte système.

La gouvernance grandit avec l’automatisation. Chaque hook qui ajoute une contrainte réduit le risque de l’opération sans surveillance. Le ratio entre hooks de jugement et hooks d’automatisation est votre marge de sécurité. Le mien est de 4:5 et en progression.

L’infrastructure se compose, les prompts non. Un bon prompt améliore une interaction. Un bon hook améliore chaque interaction. Un bon skill améliore chaque agent qui l’invoque. Un bon agent améliore chaque workflow qui lui délègue. Investissez dans la couche qui multiplie.

Remote Control rend l’infrastructure portable. Le routage des approbations transforme le mode « non supervisé » en « supervisé de manière asynchrone ». Cette distinction fait la différence entre espérer que le modèle prenne les bonnes décisions et vérifier qu’il le fait.

Le coût est de l’architecture, pas de l’optimisation. Les lancements d’agents frais, les invocations CLI d’abord, la compression des system prompts et la mise en cache des prompts sont des décisions structurelles qui se composent. Optimiser après coup coûte plus cher que concevoir en amont.

Zéro framework nécessaire. 84 hooks, 48 skills, 19 agents, environ 15 000 lignes d’orchestration. Des scripts bash dans un répertoire. Des fichiers d’état JSON. Aucune dépendance d’exécution. Vous pouvez adopter un seul hook ou la pile entière. L’infrastructure croît organiquement en résolvant de vrais problèmes, pas en implémentant le framework de quelqu’un d’autre.

Cet article fait partie de la série AI Engineering. Précédemment : Why My AI Agent Has a Quality Philosophy. Voir aussi : Thinking With Ten Brains et The Blind Judge.