Cinq couches au sein de Claude Code : mémoire, compétences, hooks, sous-agents et plugins.
Claude Code perçu comme un environnement d’exécution d’agents : mémoire CLAUDE.md, compétences sur demande, hooks déterministes, sous-agents isolés et plugins qui regroupent tout cela pour une équipe.
Sources: **Claude Code’s 5-Layer Agent Development Kit: The Architecture Most Engineers Are Missing**
De nombreux ingénieurs considèrent Claude Code comme un assistant de codage très compétent : on ouvre une terminal, on lui confie une tâche, on le laisse lire des fichiers et exécuter des commandes, puis on observe le travail avancer. Cette description est à la fois exacte et incomplète. La documentation d’Anthropic le présente comme un outil de codage agentique qui fonctionne dans la terminal, comprend une base de code, exécute des tâches routinières et accède à des systèmes externes grâce à des mécanismes tels que MCP. En y regardant de plus près, il s’agit moins d’un modèle enveloppé dans une interface en ligne de commande que d’un environnement d’exécution d’agent structuré disposant de plusieurs interfaces de contrôle distinctes.
Ces surfaces comprennent un fichier CLAUDE.md qui persiste en mémoire, des compétences réutilisables, des Hooks déterministes, des sous-agents auxquels le travail est délégué, des plugins qui peuvent être installés, ainsi que des liens MCP vers des systèmes externes. La question pertinente change donc de nature : savoir ce que Claude Code peut générer importe moins que de se demander comment son comportement peut être façonné, restreint, spécialisé et partagé au sein d’une équipe.
Une pile en cinq couches
Un modèle de base peut écrire du code, expliquer des fichiers et répondre à des questions. Toutefois, il ne résout pas seul plusieurs problèmes : mémoriser un projet entre sessions, réutiliser des compétences spécifiques aux tâches, imposer des contraintes au niveau de l’infrastructure, limiter ce qui peut être délégué, et assurer un comportement cohérent au sein d’une équipe. Ces défis relèvent de domaines autres que les instructions fournies, et la conception de Claude Code en tient de plus en plus compte. La documentation décrit les fichiers d’instructions persistants, les compétences extensibles, les sous-agents personnalisés, les points d’ancrage, les plages de paramètres, les plugins ainsi que la connectivité MCP comme des mécanismes distincts. Ensemble, ils ne constituent pas un ensemble hétéroclite de fonctionnalités ; ils forment des couches qui rendent le comportement des agents plus fiable, réutilisable et gérable :
- CLAUDE.md représente la couche de mémoire et de politiques.
- Skills constituent la couche de connaissances, fournissant des compétences sur demande.
Les modèles MCP et les architectures agent-team entourent l’ensemble de ce stack en servant d’intermédiaires entre celui-ci et le monde extérieur.
Cette approche explique un schéma récurrent dans les projets d’agents qui échouent : le modèle était rarement le point faible. Il manquait une couche. Une équipe compte entièrement sur les prompts sans mémoire persistante du projet. Une autre dispose d’instructions détaillées mais n’a pas de contrôles déterministes pour l’utilisation de outils risqués. Une troisième surcharge un agent généraliste alors que le travail devrait être réparti entre des spécialistes. La plupart des échecs d’agents sont d’ordre architectural, et non liés aux prompts. Chaque couche est abordée ci-dessous, en partant de la base.
Pourquoi une approche architecturale l’emporte sur une liste de fonctionnalités
Considérer Claude Code comme une simple liste de fonctionnalités amène à se demander ce qu’il est capable de faire. Le voir sous l’angle de son architecture permet d’en formuler une meilleure : quels niveaux expose-t-il pour contrôler la manière dont le comportement des agents est façonné, restreint, délégué et partagé ? Une fois la question modifiée, il devient facile de comprendre l’architecture dans son ensemble, ainsi que de diagnostiquer les problèmes qui surviennent en pratique.
La documentation permet de dégager deux points importants. Premièrement, aucun de ces mécanismes ne se trouve à l’intérieur du modèle ; ils se situent autour de celui-ci, dans des fichiers, des gestionnaires d’événements, des scopes de configuration et des formats de packaging. Deuxièmement, chacun d’eux répond à un type de défaillance différent : la mémoire permet de faire face à l’oubli, les compétences gèrent le comportement général, les hooks traitent les problèmes de fiabilité, les sous-agents aident à gérer un contexte trop encombré, et les plugins permettent d’éviter de répéter manuellement une bonne configuration.
Couche un : CLAUDE.md en tant que mémoire
La base est CLAUDE.md. Les documents le décrivent comme l’endroit où sont stockées des instructions persistantes concernant la manière de travailler sur un projet, tandis qu’une fonctionnalité de mémoire automatique distincte conserve les notes que Claude écrit pour elle-même après des corrections répétées et en fonction de ses préférences.
Cette séparation est importante. CLAUDE.md n’est pas un carnet de notes temporaire pour des prompts éphémères. Les équipes y placent du contexte à long terme : les normes de codage, les décisions architecturales antérieures, les bibliothèques préférées, les listes de contrôle pour les revues et les limites des workflows, tout ce qui doit être visible avant le premier message d’une session.
La manière dont il se charge constitue la partie technique intéressante. Il ne s’agit pas d’un seul fichier lu uniquement depuis le répertoire courant. Claude parcourt l’arborescence de répertoires à partir du répertoire de travail et charge chaque fichier CLAUDE.md ainsi que CLAUDE.local.md qu’il trouve. Ces fichiers sont concaténés pour former un contexte global au lieu de se surcharger mutuellement, et les instructions situées plus près du répertoire de lancement sont lues en dernier.
Ce qui en fait un système de mémoire ciblé, et non un simple fichier de configuration. Un fichier de niveau supérieur peut contenir des règles valables pour l’ensemble du dépôt, telles que les conventions de nommage, les attentes des tests ou les limites architecturales, tandis qu’un fichier situé plus profondément dans l’arborescence peut affiner le comportement d’un sous-système donné. Imaginez un monorepo : le fichier racine définit la manière dont les tests sont nommés et où se situent les limites des services, tandis qu’un fichier à l’intérieur du répertoire des paiements ajoute les règles plus strictes qui s’y appliquent uniquement. Quiconque lance une session dans ce répertoire reçoit les deux ensembles de règles, les directives plus spécifiques étant lues en dernier.
Les importations permettent une meilleure composabilité. La syntaxe @path/to/import permet aux équipes de diviser de grands ensembles d’instructions en modules plus petits et réutilisables, afin qu’un seul fichier Markdown ne devienne pas un véritable fouillis. Launch affiche les fichiers importés dans leur contexte, et une importation peut elle-même importer d’autres fichiers, jusqu’à cinq niveaux de profondeur. En pratique, CLAUDE.md fonctionne davantage comme une mémoire de projet composable que comme un modèle de prompt statique.
La mémoire automatique et la mémoire déclarative ont des rôles différents. Toutes deux sont chargées au début de chaque conversation, mais CLAUDE.md contient ce que les humains ont écrit délibérément, tandis que la mémoire automatique conserve les notes accumulées par Claude dans un répertoire local, indexé via MEMORY.md. Seules les 200 premières lignes ou 25 KB de cet index sont chargées au démarrage de la session. En revanche, les fichiers CLAUDE.md sont chargés en totalité, quel que soit leur volume, bien que Anthropic note que les fichiers plus courts sont suivis plus efficacement. L’une est contrôlée et déclarative ; l’autre est adaptative et émergente.
Un modèle mental plus efficace que « le contexte est collé une fois afin que Claude se souvienne d’un style » consiste en un charter de fonctionnement pour l’agent. Anthropic précise même les emplacements à utiliser au sein de l’organisation pour gérer de manière centralisée les fichiers CLAUDE.md sur les principaux systèmes d’exploitation de bureau, ce qui montre que cette couche vise à établir des politiques opérationnelles durables et non seulement des préférences personnelles. Cela permet aux équipes d’éviter de répéter les mêmes contraintes à chaque session et offre à l’agent une base stable avant de commencer tout travail spécifique à une tâche.
Une conséquence pratique des règles de chargement est que CLAUDE.md nécessite une attention éditoriale. Comme chaque fichier découvert est chargé dans son intégralité, cela entraîne une surcharge à chaque session ; de plus, les indications d’Anthropic selon lesquelles il est préférable d’utiliser des fichiers plus courts justifient un arborisation régulière. Les procédures qui ont dépassé les limites du fichier sont les premières à être supprimées, ce qui mène directement à l’étage suivant.
Deuxième étage : Les compétences en tant que connaissances sur demande
Alors que CLAUDE.md constitue la mémoire et les politiques persistantes, les compétences fournissent des expertises modulaires qui s’activent au moment voulu. Selon la documentation, c’est en écrivant des instructions dans un fichier SKILL.md que Claude acquiert de nouvelles capacités. Une commande avec un slash invoque explicitement une compétence, ou Claude peut l’utiliser automatiquement lorsqu’il juge que la tâche s’y prête.
Le point architectural clé est le timing. Le « corps » d’une compétence n’est pas une mémoire de projet permanente. Il n’entre dans le contexte que lorsque c’est nécessaire, ce qui permet d’associer des procédures réutilisables, des listes de contrôle et des directives sectorielles sans alourdir chaque session.
De nombreux ingénieurs considèrent la personnalisation comme une seule et longue instruction : ils mettent tout dans un contexte persistant en espérant que le modèle saura distinguer ce qui est important. Les compétences représentent une option plus structurée. Anthropic recommande d’en créer lorsqu’elles mêmes instructions sont collées à plusieurs reprises, ou lorsque une section de CLAUDE.md est passée d’un simple fait à une procédure. CLAUDE.md doit contenir des règles de projet durables ; les compétences, quant à elles, doivent regrouper des savoir-faire opérationnels réutilisables. Cela permet de garder le contexte toujours chargé léger et de transformer des workflows complexes en modules que Claude peut invoquer au moment opportun.
Les compétences ne sont pas non plus simplement des commandes personnalisées rebaptisées. Les fichiers .claude/commands/.md plus anciens et les définitions .claude/skills//SKILL.md plus récentes se comportent de manière similaire au moment de l’appel, mais les compétences offrent un contrôle supplémentaire. Elles permettent l’existence d’un répertoire contenant des fichiers de support, déterminent si l’utilisateur, Claude ou les deux peuvent les déclencher, prennent en charge l’injection dynamique de contexte et peuvent même s’exécuter à l’intérieur d’un sous-agent. C’est pourquoi l’expression « couche de connaissances » convient : une compétence est l’unité grâce à laquelle les expertises, les procédures et le contexte des tâches deviennent composables au sein du système en temps de exécution.
Considérez une compétence comme un paquet scellé de connaissances destiné à un type de tâche particulier. Sa description indique son objectif, la comparaison en temps de exécution détermine si elle convient à la demande actuelle, et les instructions qu’elle contient ne sont chargées que lorsque cela est utile. La documentation précise que les compétences regroupées telles que /debug, /loop et /simplify reposent sur des prompts plutôt que sur une logique fixe, ce qui offre un indice important sur leur conception. Le comportement devient ainsi modulaire sans avoir à coder tout en dur dans le produit principal, ce qui constitue un modèle bien plus scalable que l’idée d’un seul prompt de base capable de couvrir tous les flux de travail.
Considérez une équipe disposant d’une méthode standard pour déboguer des tests instables, examiner les migrations SQL ou rédiger des notes de version. La mémoire persistante est trop générale pour ces tâches, tandis qu’une sollicitation ponctuelle est trop répétitive. L’équipe met en place cette procédure une seule fois, conserve du matériel de référence à côté, et Claude ne la charge que lorsque la tâche l’exige. Un long contenu de référence à l’intérieur d’une compétence ne coûte presque rien tant qu’il n’est pas utilisé, ce qui rend ce modèle plus propre et également moins coûteux à mettre en œuvre.
Les compétences récompensent donc l’habitude de repérer les répétitions. Chaque fois que la même explication est tapée pour la troisième fois, ou qu’un paragraphe dans CLAUDE.md commence à ressembler à une procédure numérotée, il s’agit probablement d’une compétence prête à être extraite. Cette opération ne prend que quelques minutes et se révèle rentable chaque fois que la tâche se reproduit.
Ensemble, CLAUDE.md fournit à l’agent des règles de base stables, tandis que les compétences lui offrent des connaissances ciblées et réutilisables sans surcharger la fenêtre de contexte principale. La couche suivante est ce qui rend ce comportement plus sûr.
Couche trois : Les hooks en tant que garde-fous
Les hooks transforment le comportement de l’agent en quelque chose qui peut être appliqué de manière contraignante. La documentation officielle les décrit comme une automatisation basée sur des événements : une commande s’exécute avant ou après une action donnée dans Claude Code, déclenchée par l’événement lui-même. Les hooks guident et cataloguent les utilisations typiques : le formatage automatique du code après des modifications, le refus des modifications sur des fichiers protégés, la restauration du contexte une fois une conversation ayant été compressée, l’audit des modifications de configuration, le renouvellement de l’état de l’environnement lorsque les fichiers changent, ainsi que l’approbation préalable de certaines demandes de permission.
C’est un travail différent de celui de l’incitation. Une incitation peut suggérer un comportement ; un crochet peut l’intercepter ou le transformer de manière déterministe. C’est pourquoi les crochets doivent être considérés avant tout comme une couche de protection, et non simplement comme un outil pratique pour l’automatisation.
Un exemple concret provient du guide des coûts : un crochet PreToolUse capture les commandes Bash, reconnaît les exécutions de tests et les réécrit, de sorte que le résultat reçu par Claude ne contient que les échecs et non l’ensemble du flux. Mécaniquement, le crochet reçoit un en-tête JSON décrivant l’appel en attente, examine la commande, puis répond par un JSON qui modifie les données d’entrée de l’outil. Rien dans ce processus ne relève d’une décision de la IA pour améliorer les choses ; il s’agit plutôt d’infrastructures qui déterminent ce que le modèle est autorisé à voir ou à faire à un moment donné du flux de travail.
Le contraste avec les règles au niveau des prompts mérite d’être souligné. Les garde-fous souples sont souvent trop faibles pour un environnement de production. Supposons que le code généré doive toujours être reformatté, que les fichiers sensibles ne doivent jamais changer, ou que les appels d’outils destructeurs nécessitent un contrôle plus strict. Se fier uniquement aux instructions écrites est fragile, tandis que les hooks déplacent le contrôle en dehors de la discrétion du modèle et appliquent les règles de flux de travail au niveau des événements.
Les hooks se situent également à côté de la gestion du contexte, et non à l’intérieur. La documentation de dépannage cite « les hooks qui ne s’exécutent pas » comme un problème de configuration à part entière, et recommande l’outil /doctor pour diagnostiquer les problèmes liés aux hooks, aux serveurs MCP et à l’utilisation du contexte. Ces deux éléments montrent que les hooks font partie de l’environnement d’exécution : un comportement piloté par la configuration qui doit être correctement intégré au temps de exécution de la session, et non du texte lu par Claude.
Il y a aussi l’aspect coût. Le guide des coûts d’Anthropic recommande de déplacer le traitement vers des hooks et des compétences, car ces derniers peuvent prétraiter de grandes quantités de données avant même que le modèle ne les voie. Son exemple consiste à filtrer un vaste journal de tests pour n’en conserver que les échecs, réduisant ainsi ce qui pourrait représenter des dizaines de milliers de tokens en un chargement bien plus petit. Ainsi, les hooks contribuent à l’efficacité tout en assurant la sécurité : ils diminuent le gaspillage de tokens, maintiennent un contexte plus clair et épargnent au modèle le travail de filtrage prévisible que la logique de shell déterministe peut effectuer de manière plus économique et fiable.
Il est utile d’imaginer une situation avant et après. Avant les hooks, une équipe écrit « exécutez toujours le formatteur » dans les instructions et espère que cela suffira. Avec les hooks, le formatteur s’exécute à chaque modification, que le modèle s’en souvienne ou non, et un fichier protégé ne peut tout simplement pas être modifié. L’agent continue de raisonner librement sur ce qu’il faut construire ; les hooks déterminent ce qui est autorisé en fonction de cette réflexion.
La plupart des équipes sous-estiment d’abord ce niveau. La mémoire aide l’agent à se souvenir et les compétences l’aident à se spécialiser, mais les hooks transforment des attentes opérationnelles répétées en politiques. Ils se situent précisément là où la réflexion pilotée par le modèle rencontre le comportement imposé par le système, c’est-à-dire là où ont lieu de nombreux échecs en production. Sans eux, la qualité dépend trop fortement des instructions fournies.
Niveau quatre : Sous-agents pour la délégation
Lorsque les hooks gèrent le contrôle, les sous-agents s’occupent de la délégation. Les documents les décrivent comme des assistants IA spécialisés qui traitent des types de tâches spécifiques dans leur propre fenêtre de contexte et ne retournent que le résultat.
Le raisonnement est simple. L’un des moyens les plus rapides de détériorer une session consiste à laisser des tâches secondaires polluer la conversation principale avec des journaux, des résultats de recherche ou des raisonnements exploratoires qui ne seront jamais réutilisés. Au lieu de forcer un agent généraliste à gérer tout cela dans une seule thread, l’agent principal confie une tâche secondaire à un travailleur spécialisé qui fonctionne de manière indépendante et fournit un résumé. Les avantages incluent :
- L’exploration et la mise en œuvre restent hors de la conversation principale, préservant ainsi le contexte.
- L’accès limité aux outils impose des contraintes.
- Les configurations peuvent être réutilisées entre différents projets.
- Des prompts ciblés spécialisent le comportement.
Appeler un sous-agent une instruction nommée est une sous-estimation de sa nature réelle : il s’agit en fait d’une unité de travail autonome, dotée d’une description, d’une instruction système, d’un modèle choisi, d’un ensemble d’outils autorisés, de paramètres de mémoire et d’une limite de temps d’exécution.
Les exemples intégrés illustrent l’intention derrière ces agents. Explore est optimisé pour des recherches en lecture seule et une analyse de base de code, Plan sert à gérer les workflows de planification, tandis que l’agent polyvalent prend en charge des tâches complexes à plusieurs étapes combinant raisonnement et action. La documentation précise que les sous-agents intégrés héritent des permissions de la conversation parente ainsi que de restrictions supplémentaires concernant les outils, ce qui limite par conception la délégation de tâches.
Une autre limite : les sous-agents ne procèdent pas par récursivité. Anthropic stipule qu’un sous-agent ne peut pas générer d’autres sous-agents, ce qui permet à Claude d’éviter un enchaînement infini tout en recueillant le contexte nécessaire. Sans limite stricte, la délégation peut conduire à des arbres d’agents non contrôlés, coûteux, difficiles à surveiller et complexes à comprendre. Le modèle reste simple : l’agent principal transmet les tâches, le sous-agent les exécute de manière isolée et le résultat remonte vers l’agent principal.
D’un point de vue pratique, les sous-agents peuvent être configurés à différents niveaux d’application. Ils peuvent être créés de manière interactive à l’aide de la commande /agents, stockés par utilisateur dans ~/.claude/agents/, stockés par projet dans .claude/agents/, transmis via la ligne de commande pour une session donnée, ou intégrés à des plugins. Chacun d’eux est un fichier Markdown contenant du frontmatter YAML, mais le comportement qu’il définit est riche : le choix du modèle, l’accès aux outils, le fonctionnement de la mémoire, les hooks et les compétences peuvent tous être définis pour ce travailleur délégué. Il s’agit de profils d’exécution packagés, et non de labels de rôle.
C’est pourquoi les sous-agents comptent parmi les couches les plus importantes. CLAUDE.md ancre l’agent principal dans les règles du projet, la fourniture de compétences offre une expertise modulaire et les hooks appliquent les politiques en temps réel, mais les sous-agents empêchent que tout ne se transforme en une conversation surchargée avec trop de responsabilités. L’isolation constitue l’avantage silencieux : un sous-agent peut lire des dizaines de fichiers, effectuer des recherches et suivre des pistes sans que toute cette exploration ne parvienne dans le thread principal, qui n’reçoit que la conclusion. Ils établissent des frontières claires autour des tâches secondaires, permettent aux équipes de se spécialiser dans leurs workflows et maintiennent le contexte principal plus propre et plus durable. Une fois la délégation en place, le problème restant est organisationnel : comment regrouper tout cela pour une équipe.
Choisir où chaque règle doit être placée
Avec cinq couches disponibles, le choix de l’emplacement devient une décision de conception. Un test utile consiste à se demander comment la règle doit fonctionner. Si elle doit toujours être connue, placez-la dans CLAUDE.md. S’il s’agit d’une procédure nécessaire uniquement parfois, faites-en une compétence. Si elle doit être appliquée quel que soit le choix du modèle, il s’agit d’un hook. Si le travail est bruyant, autonome ou adapté à un modèle moins coûteux, confiez-le à un sous-agent. Si l’ensemble doit être transmis, emballez-le en tant que plugin. Les règles placées dans la mauvaise couche ont tendance à échouer de manières prévisibles : une politique laissée sous forme de texte est ignorée, une longue procédure stockée en mémoire écrase tout le reste, et une configuration ingénieuse restée sur un seul ordinateur portable n’atteint jamais l’équipe.
Couche cinq : Plugins pour la distribution
Supposons qu’une équipe dispose déjà de son fichier de mémoire, de ses compétences, de ses outils et de ses sous-agents. Le problème n’est plus le comportement local, mais plutôt la distribution. Comment ce système peut-il être transféré entre des dépôts, des machines et des collègues sans devoir être reconstruit manuellement à chaque fois ?
Anthropic propose plusieurs mécanismes pour emballer et réutiliser des comportements à différents niveaux : sous-agents au niveau de l’utilisateur ou du projet, compétences partagées, paramètres de plugins, déploiement de CLAUDE.md à l’échelle de l’organisation, ainsi que des plugins qui fournissent des capacités liées à l’intelligence de code. Claude Code n’est pas conçu uniquement pour une seule personne ; il vise de plus en plus à permettre aux équipes de standardiser et de distribuer le comportement de l’agent.
Le signal officiel le plus clair est le modèle de plugins et de paramètres. La documentation des paramètres décrit des sections dédiées à la configuration des plugins, des listes d’autorisation et des permissions telles que codeIntelligence.*, ainsi que des paramètres locaux au projet et des paramètres d’utilisateur hérités. Elle indique également que les arguments de la ligne de commande, comme les flags append-system-prompt et allowed-tools, ne se transmettent pas aux plugins, ce qui confirme que ces derniers constituent des unités de distribution autonomes avec leur propre surface de comportement, et non des extensions passives de la session principale. Ainsi, les plugins servent moins à ajouter des outils qu’à emballer le comportement d’un agent afin de pouvoir l’installer, le réutiliser et le gérer à grande échelle.
Le même schéma se retrouve ailleurs. Les sous-agents permettent une installation au niveau de l’utilisateur, au niveau du projet, uniquement pour une session ou définie par des plugins. Les compétences suivent une conception modulaire qui permet à des savoir-faire réutilisables de exister en dehors de la couche mémoire toujours chargée. L’architecture ne s’arrête pas à la question de savoir si l’agent peut effectuer une tâche ; elle se demande de plus en plus comment cette capacité peut être emballée et partagée, ce qui caractérise une plateforme plutôt qu’un assistant pour un seul utilisateur.
La gouvernance fait également partie intégrante de ce système. Un ensemble partagé peut contenir des sous-agents vérifiés, des permissions d’outil strictement limitées, des points d’accroche standard ou des workflows propres à une organisation, de sorte que les équipes diffusent des politiques plutôt que simplement des solutions pratiques. Les chemins d’entreprise pour les fichiers CLAUDE.md gérés de manière centralisée montrent que la standardisation a été planifiée dès le début. Le même design en couches qui permet d’accélérer le travail d’un ingénieur peut devenir un modèle opérationnel au niveau de toute l’équipe, dans lequel la mémoire, les compétences, les contrôles et la délégation sont partagés plutôt que reconstruits.
Que se passe-t-il en l’absence d’une couche ?
Vu dans son ensemble, cet ensemble de composants constitue une liste de contrôle pratique pour diagnostiquer un système d’agents peu fiable. Les symptômes indiquent généralement la couche manquante.
- L’agent continue de poser les mêmes questions ou ignore le style de la maison. Il manque de mémoire. Les règles durables doivent être stockées dans CLAUDE.md, organisées par répertoire et divisées en imports lorsque le fichier devient trop volumineux.
- Chaque session commence par une procédure longuement collée. Les connaissances restent prisonnières des prompts. Il faut déplacer les parties réutilisables dans des compétences afin qu’elles ne soient chargées que lorsque la tâche l’exige.
- Les actions risquées dépendent du fait que le modèle se souvienne d’être prudent. Les garde-fous ne sont que des suggestions. Les hooks permettent d’appliquer le formatage, de protéger les fichiers et de réécrire les commandes indépendamment des décisions du modèle.
- La conversation principale se remplit de journaux et d’impasses. Il n’y a pas de délégation. Des sous-agents dotés d’outils limités s’occupent des tâches fastidieuses et renvoient un résumé.
Le point commun, c’est que aucune de ces solutions ne consiste en une phrase améliorée dans un prompt. Il s’agit de changements structurels, c’est pourquoi ils résistent à de réels charges de travail. Considérer Claude Code comme un kit de développement d’agents livré par hasard à l’intérieur d’un terminal permet de voir plus facilement ces changements, de les discuter plus aisément avec une équipe et de les déployer délibérément, couche par couche.