Comment Claude Code fonctionne en ensemble : compétences, sous-agents, MCP, connecteurs, plugins

Qu’est-ce que Claude Code, du point de vue architectural

Claude Code fonctionne le mieux lorsqu’il est considéré comme un système d’orchestration de l’ingénierie logicielle agente, et non comme un générateur de code à solliciter. Il collecte le contexte du projet, détermine ce qui est nécessaire, utilise des outils, transmet des tâches à des sous-agents spécialisés, communique avec des systèmes externes, exécute des actions, vérifie les résultats et recommence si quelque chose ne va pas.

En une phrase, son fonctionnement repose sur un cycle de collecte du contexte, exécution d’actions et vérification des résultats. Le modèle de langage n’est qu’un composant parmi d’autres : la gestion du contexte, des workflows réutilisables, des travailleurs spécialisés, des outils, des intégrations, une automatisation déterministe et des mécanismes de vérification l’entourent.

Comparez les deux processus. Un assistant de codage traditionnel reçoit une demande, génère du code, puis renvoie une réponse. Une configuration agente commence par identifier les exigences, comprend le contexte, sélectionne les capacités nécessaires, exécute les actions, valide les résultats, itère si nécessaire, et finalise par la livraison du produit. Prenons l’exemple d’une demande de fichier de test : un flux de travail agente pourrait examiner le répertoire de code, repérer les conventions de test existantes, identifier l’API concernée, écrire des tests, les exécuter, analyser ce qui a échoué, modifier l’implémentation, valider à nouveau et conclure par un résumé. Le changement majeur réside dans le passage de la production de code à l’exécution et la vérification de tâches.

CLAUDE.md : contexte de projet persistant

CLAUDE.md constitue la couche de contexte persistant du projet. Elle contient des éléments tels que les conventions de codage, les décisions architecturales, la structure du répertoire, les commandes de compilation et de test, les normes de test, les règles de sécurité ainsi que ce qui est considéré comme terminé. Un extrait de ce fichier pourrait être le suivant :

• Framework : Playwright avec TypeScript
• Les tests UI sont exécutés via npm run test:e2e, les tests API via npm run test:api
• Les identifiants ne sont jamais stockés de manière hardcodée
• Chaque nouveau point d’entrée API nécessite des tests négatifs

Cela permet aux ingénieurs d’éviter d’expliquer sans cesse les mêmes conventions. Pensez à ce fichier comme à la réponse à la question "comment ce projet fonctionne-t-il ?"

Le fichier doit contenir des connaissances stables dont Claude a besoin à maintes reprises : les conventions de dépôt, les exigences en matière de tests, les principes d’architecture, les commandes de compilation, les règles de nommage, les exigences de sécurité et les habitudes de l’équipe. Il ne doit pas devenir un manuel volumineux rempli d’instructions étape par étape pour chaque tâche possible. Une distinction utile consiste à ce que CLAUDE.md indique ce que Claude doit savoir sur le projet, tandis qu’une compétence décrit comment effectuer un type de travail donné. Les séparer facilite la maintenance et renforce le contexte.

Compétences : expertise réutilisable

Une compétence représente une expertise réutilisable sous forme de flux de travail. Elle peut inclure des instructions, des scripts et des ressources complémentaires pour une activité spécialisée : les tests d’API, l’examen du code, l’analyse de sécurité, le refactoring, la génération de documentation ou les tests de régression. Rédiger ce flux de travail une seule fois évite de devoir expliquer constamment la même tâche à Claude. Une compétence indique comment effectuer ce type de travail.

Par exemple, une compétence pour les tests d’API pourrait suivre ces étapes dans l’ordre :

1. Identifier le contrat de l’API.
2. Examiner les tests déjà existants.
3. Générer des scénarios positifs.
4. Générer des scénarios négatifs.
5. Générer des cas limites.
6. Exécuter les tests.
7. Analyser les échecs.
8. Élaborer un rapport.

Lorsqu’on reçoit une demande du type « ajouter une couverture de régression pour l’API de paiement », la compétence en question ne se lance pas immédiatement dans l’écriture de code de test. Elle applique une méthodologie de test standard, de sorte que chaque API est testée selon les mêmes normes organisationnelles.

CLAUDE.md versus compétences

La différence réside dans le contexte par rapport à la procédure. CLAUDE.md décrit le projet : les tests d’API utilisent Playwright, chaque point d’entrée nécessite des tests négatifs, et les identifiants proviennent de variables d’environnement. Une compétence de test d’API, quant à elle, décrit la procédure : examiner le contrat, générer des tests positifs, négatifs et de bordure, les exécuter et classer les échecs. Le premier couvre ce que l’agent doit savoir, tandis que le second indique comment il doit effectuer le travail.

Sous-agents : délégation de tâches ciblées

Les sous-agents sont des travailleurs spécialisés qui s’occupent d’une tâche précise dans leur propre contexte et envoient les résultats au agent principal. Un agent principal peut déléguer des tâches à un sous-agent de test d’interface utilisateur, à un sous-agent de test d’API et à un sous-agent de sécurité. Chacun étudie son domaine de manière indépendante, et l’agent principal fusionne leurs résultats en un résultat final.

Pourquoi pas un seul grand agent ?

Les travaux d’ingénierie complexes comportent souvent plusieurs aspects indépendants. Une nouvelle fonction de paiement peut nécessiter une validation de l’interface utilisateur, des tests de régression d’API, une analyse de sécurité et une vérification de la base de données. Un seul agent pourrait essayer de gérer tout cela, mais le contexte deviendrait trop volumineux et des éléments non liés se mélangeraient. Les sous-agents offrent quatre avantages :

• Isolation du contexte : chacun ne reçoit que les informations qui lui sont pertinentes.
• Spécialisation : chacun peut suivre des instructions différentes.
• Enquête parallèle : les tâches indépendantes peuvent être analysées séparément.
• Contexte principal plus propre : les journaux intermédiaires n’ont pas besoin de rester dans le contexte principal de l’orchestrateur.

Compétence versus sous-agent

Une compétence décrit la manière dont le travail doit être effectué, tandis qu’un sous-agent est celui qui s’occupe d’une partie spécialisée de ce travail. La compétence de test d’API définit la méthodologie de l’organisation. Le sous-agent chargé des tests d’API reçoit une API spécifique et l’analyse à l’aide d’instructions et d’outils appropriés.

Sous-agents et fenêtre de contexte

Les tâches d’agent génèrent de nombreux résultats intermédiaires. Une revue de sécurité peut produire une analyse des dépendances, des constats relatifs à l’authentification et à l’autorisation, des journaux de sécurité, des recherches dans le code ainsi que des résultats de tests. Intégrer tout cela dans l’agent principal rend l’orchestration de plus en plus complexe avec le temps. Un sous-agent de sécurité peut effectuer ces recherches par lui-même et retourner un résultat compact, tel que deux constats critiques, quatre constats de niveau moyen, des modifications recommandées ainsi que les tests nécessaires. L’agent principal reçoit alors le résultat final et non chaque étape du processus. L’isolation du contexte constitue donc à la fois un avantage architectural et une commodité.

MCP et outils

Qu’est-ce que MCP

MCP signifie Model Context Protocol. Il s’agit du mécanisme d’intégration grâce auquel un agent communique avec des systèmes externes et des sources de données. Claude Code se trouve d’un côté, tandis que de l’autre se trouvent GitHub, Jira, des bases de données, des API, des navigateurs et des systèmes de surveillance. Cela permet à l’agent de sortir de l’environnement de codage local pour accéder aux systèmes utilisés tout au long du cycle de vie du développement.

Le génie logiciel ne reste rarement confiné à un éditeur. Un développeur peut avoir besoin de Jira pour les exigences, de GitHub pour les fichiers sources et les demandes de fusion, de bases de données pour la validation, de systèmes de surveillance pour détecter les erreurs en production, et d’API pour comprendre le comportement de l’application. Avec MCP, un flux de travail peut lire une demande Jira, examiner le répertoire concerné, identifier l’API, générer des tests, les exécuter et ouvrir une demande de fusion. L’agent de codage devient ainsi partie intégrante d’un processus d’ingénierie plus large.

MCP versus outils

Ce ne sont pas la même chose. MCP est le protocole ou la couche d’intégration, tandis qu’une outil représente la capacité spécifique que l’agent peut utiliser. Un serveur Jira MCP peut exposer get_issue(), search_issues() et create_comment(). Ces fonctions sont des outils, et MCP est ce qui permet de les atteindre. En bref, MCP est le moyen par lequel l’agent se connecte, et un outil est ce qu’il peut faire.

Quels outils à la disposition d’un agent

Les outils permettent à un agent de prendre des actions. Sans eux, un LLM se contente principalement de raisonner et d’écrire du texte. Avec eux, il peut lire un fichier pour comprendre une implémentation, rechercher dans le répertoire des codes pertinents, modifier un fichier pour changer son comportement, exécuter une commande pour lancer un test, lire les résultats pour diagnostiquer une erreur, modifier à nouveau le fichier pour la corriger, puis relancer la validation pour confirmer. Les outils transforment un générateur de réponses en un participant actif aux travaux d’ingénierie.

Types d’outils

Claude Code dispose de fonctionnalités intégrées pour lire et modifier des fichiers, rechercher du code, exécuter des commandes, interagir avec des ressources et lancer des workflows de sous-agents spécialisés. MCP peut en exposer davantage. Il est utile de les classer par fonction :

• Les outils d’observation lisent, recherchent et inspectent.
• Les outils d’action écrivent, modifient et exécutent.
• Les outils d’intégration se connectent à des plateformes externes.
• Les outils de délégation font appel à des agents spécialisés.

Ensemble, ils permettent au système d’observer son environnement, de prendre des décisions, d’agir et de vérifier le résultat.

Hooks, commandes et plugins

Hooks

Les hooks fournissent une automatisation déterministe basée sur des événements. Une compétence peut demander à Claude d’exécuter des tests de régression lors de la vérification d’une API. Un hook fonctionne différemment : chaque fois qu’un événement donné se produit, une validation s’exécute automatiquement. Par exemple, après modification du code, le hook peut déclencher le formatteur, puis le vérificateur de syntaxe, puis des tests ciblés, avant de retourner les résultats de validation. Cela est très utile lorsque certains contrôles techniques doivent avoir lieu à chaque fois.

Les compétences représentent des workflows que le modèle peut utiliser, tandis que les hooks sont des automatisations déclenchées par des événements. Une compétence décrit le processus recommandé pour une revue de code. Un hook exécute immédiatement la validation du vérificateur de syntaxe après toute modification de fichier. Les compétences aident le modèle à comprendre comment fonctionner, tandis que les hooks s’assurent que des actions clés ont lieu lors de l’apparition d’événements spécifiques.

Pourquoi les hooks sont importants en production

L’IA générative est probabiliste, donc les équipes ne devraient pas compter sur le modèle pour décider si un contrôle important doit être exécuté. Si chaque modification doit passer par un formatage, un contrôle de syntaxe, un scan de sécurité et des tests unitaires, ces étapes peuvent être associées à une automatisation déterministe plutôt qu’être laissées au jugement du modèle. Le principe consiste à utiliser le raisonnement de l’IA pour des décisions flexibles et l’automatisation déterministe pour les contrôles obligatoires, et cette distinction est particulièrement importante dans les environnements d’entreprise.

Commandes

Les commandes sont des flux de travail déclenchés de manière explicite, tels que /review, /test et /debug. En tapant /review, on lance délibérément un flux de travail de revue de code prédéfini. Une commande signifie « Je veux explicitement exécuter ce flux de travail ».

Les commandes sont initiées par l’utilisateur tandis que les hooks sont initiés par un événement. Taper /test constitue une commande explicite. La modification du code source et l’exécution automatique de tests en réponse relèvent d’une automatisation basée sur les événements. Ainsi, une commande est déclenchée par un humain, tandis qu’un hook est déclenché par un événement.

Les commandes et les compétences se recoupent également, car une compétence réutilisable peut exposer un flux de travail que les utilisateurs invoquent intentionnellement. Une fonction de révision pourrait être intégrée dans une compétence et lancée à l’aide de /review. Cependant, une compétence contient bien plus qu’un simple prompt : des instructions, des ressources complémentaires, des scripts ainsi que des paramètres de configuration autour d’une capacité technique réutilisable.

Plugins

Les plugins empaquetent et distribuent des extensions. Imaginez une organisation de test qui a développé une compétence de test d’API, une compétence de test de sécurité, un sous-agent pour API, un sous-agent pour la sécurité, des points d’ancrage de validation ainsi que des intégrations MCP. Au lieu que chaque développeur doive recréer cet environnement, tous ces éléments sont fournis ensemble sous forme d’un seul plugin.

C’est pourquoi les plugins sont importants pour les entreprises. Ils transforment l’ingénierie basée sur des agents, en passant d’une simple productivité personnelle à une véritable capacité organisationnelle. En l’absence d’emballage partagé, chaque ingénieur finit par configurer l’environnement d’IA différemment. Un plugin standard peut regrouper des normes d’ingénierie, des méthodes de test, des agents spécialisés, des règles d’automatisation et des intégrations, permettant ainsi à chaque projet d disposer de capacités identiques. En termes d’architecture, les plugins appartiennent à la couche de gouvernance et de normalisation.

Comment les composants s’assemblent

Une représentation concise attribue une tâche à chaque composant :

• CLAUDE.md connaît le projet.
• Les compétences savent comment travailler.
• Les sous-agents s’occupent des tâches spécialisées qui leur ont été déléguées.
• Les outils exécutent des actions.
• MCP se connecte aux systèmes externes.
• Les hooks automatisent les événements du cycle de vie.
• Les commandes déclenchent des workflows sur demande.
• Les plugins emballent et distribuent des fonctionnalités.

Claude Code se trouve au centre et les orchestre. Ils répondent à des problèmes architecturaux différents et ne sont pas des fonctionnalités interchangeables.

Un workflow du début à la fin

Prenons l’exigence « ajouter une couverture de régression pour la nouvelle API de paiement ». Un déroulement plausible se présente ainsi :

1. Exigence. Claude Code reçoit la demande.
2. Contexte du projet. CLAUDE.md définit les normes de test, les commandes, les conventions de répertoire ainsi que les exigences en matière de sécurité.
3. Sélection des compétences. Une compétence de test d’API fournit la méthodologie de l’organisation.
4. Délégation. Des sous-agents spécialisés analysent la fonctionnalité de l’API, les problèmes de sécurité et l’impact des régressions.
5. Intégrations. Les systèmes connectés via MCP permettent d’accéder aux plateformes externes pertinentes.
6. Outils. Claude Code lit du code, recherche dans les fichiers, écrit des tests et exécute des commandes.
7. Validation. Les hooks exécutent des vérifications de syntaxe, du formatage, des tests ciblés ou d’autres contrôles.
8. Vérification. Claude évalue les résultats et décide s’il est nécessaire de poursuivre les travaux.
9. Résultat final. L’agent restitue les tests, leurs résultats, la documentation ainsi qu’un résumé de ce qui a été fait.

C’est un véritable flux de travail d’ingénierie agente, et ce n’est pas du tout de la simple génération de code.

Le cycle agente

Pour reformuler le modèle de base : recueillir le contexte, agir, vérifier les résultats. La collecte comprend la compréhension des exigences, du répertoire, de l’architecture, des conventions, des dépendances et de l’implémentation actuelle. L’action consiste à utiliser des outils pour rechercher, modifier, exécuter, intégrer ou déléguer des tâches. La vérification implique l’exécution de tests, la lecture des résultats, la détection d’échecs et l’évaluation de la satisfaction réelle des exigences. Une vérification échouée renvoie le système à l’étape de collecte ou d’action.

En pratique, le flux est plus proche de : contexte, action, vérification, correction, nouvelle vérification, puis finalisation. C’est cette itération qui distingue un agent fiable d’une génération de code ponctuelle.

Concevoir une infrastructure d’ingénierie de tests pour l’IA

Une architecture SDET solide sur Claude Code pourrait combiner :

• CLAUDE.md avec des frameworks de test, une architecture définie, des conventions de test, des règles de sécurité ainsi qu’une définition de ce qui constitue une tâche terminée.
• Des compétences en test d’API, en test d’interface utilisateur, en test de régression et en analyse des pannes.
• Des sous-agents pour les tâches liées à l’interface utilisateur, aux API, à la sécurité et aux tests de régression.
• Des outils pour la recherche dans les dépôts, l’édition de fichiers, l’exécution de commandes et la gestion des tests.
• Des connexions MCP vers GitHub, Jira, des bases de données, des API et des systèmes de surveillance.
• Des hooks qui exécutent des opérations de mise en forme, de vérification syntaxique, de test et de validation après chaque modification.
• Des commandes telles que /api-test, /regression, /security-review et /debug.
• Un plugin qui regroupe tout cela afin que plusieurs équipes d’ingénierie puissent le réutiliser.

L’orchestrateur coordonne ces éléments conformément aux exigences.

Choisir le mécanisme approprié

Cinq questions permettent de déterminer le composant idéal.

• S’agit-il de connaissances réutilisables pour effectuer une tâche ? Utilisez un Skill.
• Est-il nécessaire d’utiliser un travailleur spécialisé et indépendant ? Utilisez un Subagent.
• L’agent doit-il effectuer une opération ? Utilisez un Tool.
• L’action dépend-elle d’une plateforme ou d’une source de données externe ? Examinez MCP.
• Faut-il que quelque chose s’exécute automatiquement chaque fois qu’un événement de cycle de vie se produit ? Utilisez un Hook.

Une dernière question concerne la distribution : si la capacité doit être emballée et partagée, utilisez un Plugin. Ce cadre montre une compréhension des responsabilités de chaque couche, c’est pourquoi il est abordé dans les discussions d’architecture.

La leçon principale

Une ingénierie agente réussie ne repose pas principalement sur un LLM plus grand ou plus intelligent. Un système fonctionnel nécessite plusieurs capacités coordonnées :

• Contexte, afin que l’agent comprenne le projet.
• Compétences, pour une expertise reproductible.
• Délégation, car les tâches complexes peuvent nécessiter des intervenants spécialisés.
• Outils, pour que l’agent puisse agir.
• Intégration, pour accéder à des systèmes d’ingénierie externes.
• Automatisation, afin que les processus obligatoires s’exécutent de manière fiable.

Vérification, afin de déterminer si les actions ont réellement fonctionné.

Emballage, permettant aux capacités d’être réutilisées au sein de différentes équipes.

L’évolution se déroule ensuite comme suit : chatbot IA, assistant de codage IA, agent IA, flux de travail d’ingénierie agentic, et enfin une plateforme d’ingénierie logicielle agentic.