Étendre Claude Code

Skills : apprendre un workflow à Claude

Un skill est un fichier markdown (SKILL.md) qui enseigne à Claude un workflow reproductible, déclenché par une commande slash. Au lieu de recoller un long prompt à chaque fois, vous l'invoquez : /my-skill.

Anatomie : un frontmatter (nom, description, déclencheurs) + des instructions + parfois des fichiers de référence et des scripts. La description est cruciale : c'est elle qui permet à Claude de choisir le bon skill au bon moment.

Pierre dispose d'une collection qui illustre la puissance du mécanisme :

• graphify : transformer n'importe quel dossier en graphe de connaissances interrogeable.
• dream : consolidation automatique de la mémoire chaque nuit.
• continuous-learning : analyser l'historique git pour extraire les patterns récurrents et proposer des règles.
• model-custom : activer son system prompt composé (Frankenstein).
• skill-builder : un skill pour créer des skills (meta).

Un skill est de la connaissance procédurale encapsulée : vous codez votre façon de faire une chose une seule fois, Claude la rejoue parfaitement à chaque appel.

MCP : connecter des outils externes

MCP (Model Context Protocol) est le standard ouvert qui relie Claude à des serveurs d'outils et de données externes : une base de données, une API, un CMS, un SaaS. Une fois qu'un serveur MCP est connecté, ses outils deviennent appelables par Claude comme des outils natifs.

Concrètement, vous connectez un serveur via /mcp ou la configuration, et les prompts du serveur apparaissent au format /mcp__[server]__[prompt]. C'est exactement la même technologie que les Connecteurs du côté Cowork.

Exemples issus du setup de Pierre :

• Un MCP Strapi (CMS headless) pour son projet MarketDLAGO : Claude lit et modifie le contenu du site directement.
• Des MCP tiers connectés à la session : Gmail, Calendar, Drive, Canva, Gamma, outils SEO (Ahrefs), Adobe...

Un piège à connaître, vécu par Pierre : un MCP peut être scopé au projet. Son MCP Strapi n'expose ses outils que si Claude Code démarre depuis le bon dossier de projet. Démarrer ailleurs signifie outils manquants. Règle : vérifier le scope quand un outil MCP attendu n'apparaît pas.

Sous-agents : déléguer dans un contexte isolé

Un sous-agent est un agent Claude que l'agent principal lance pour une tâche donnée, avec son propre contexte isolé. Il effectue son travail et ne renvoie que sa conclusion à l'agent principal, sans tout le désordre intermédiaire.

Deux avantages majeurs :

• Propreté du contexte : la recherche exploratoire (lecture de 30 fichiers) se déroule dans le sous-agent ; l'agent principal ne reçoit que le résultat. Il ne se pollue pas.
• Parallélisme : vous pouvez lancer plusieurs sous-agents simultanément sur des tâches indépendantes.

Types courants : un agent Explore (recherche en lecture seule), un agent Plan (conception d'une stratégie), des agents spécialisés (revue de code, audit SEO, analyse concurrentielle). Vous les gérez via /agents.

Disponibles depuis juillet 2025, les sous-agents sont le bloc de base de tout ce qui suit : les workflows et les équipes d'agents ne sont que des façons structurées de les orchestrer.

Mise à jour, juillet 2026 : depuis Claude Code v2.1.198 (1er juillet 2026), les sous-agents tournent en arrière-plan par défaut : la conversation principale continue de travailler et est notifiée quand ils terminent. L'assistant de création /agents a été retiré dans la même version (demandez à Claude de créer un agent, ou éditez .claude/agents/ directement). Le module orchestration a une leçon dédiée à ce que cela change.

Hooks : automatiser le cycle de vie

Les hooks sont des actions déclenchées automatiquement à des moments clés du cycle de vie de Claude Code : avant/après un appel d'outil, quand Claude a terminé, à chaque édition de fichier, au démarrage de session.

Point essentiel : c'est le harness qui exécute les hooks, pas le modèle. Tout comportement de la forme "chaque fois que X, faire automatiquement Y" ne peut pas vivre dans la mémoire ou les préférences : il doit être un hook dans settings.json.

Utilisations typiques :

• Formater/linter automatiquement après chaque édition de fichier.
• Lancer les tests quand Claude annonce qu'il a terminé.
• Bloquer un commit si un secret est détecté.
• Déclencher un système CI externe via webhook quand une tâche se termine.

Pierre utilise des hooks git (post-commit) pour rafraîchir automatiquement ses graphes Graphify à chaque commit, et des tâches planifiées pour la consolidation de la mémoire. C'est ce qui transforme une pratique manuelle en pipeline automatique.

Plugins et équipes d'agents

Plugins : un plugin est un bundle versionné qui regroupe plusieurs skills, sous-agents, commandes slash, hooks, styles de sortie et définitions de serveurs MCP. C'est la façon canonique de partager des extensions Claude Code réutilisables, via une marketplace.

Pierre active plusieurs plugins dans son settings.json : superpowers (workflows avancés), frontend-design, code-review, security-guidance, et une marketplace personnelle searchfit-seo avec ses propres skills SEO. Un plugin, c'est installer d'un coup une boîte à outils entière et cohérente.

Équipes d'agents : disponibles depuis février 2026, elles permettent à plusieurs agents de se coordonner sur des sous-tâches parallèles. C'est le niveau au-dessus des sous-agents isolés : non seulement on délègue, mais les agents collaborent vers un objectif commun. Nous approfondissons l'orchestration dans le module 9.

La progression à retenir : skill (un workflow) -> plugin (une boîte à outils partagée) -> équipe d'agents (plusieurs agents qui collaborent). Chaque niveau compose le précédent.

Créez votre propre skill

Un skill dans Claude Code est un ensemble d'instructions réutilisables stocké dans un fichier Markdown appelé SKILL.md. Lorsque vous déclenchez le skill, Claude lit ce fichier et l'applique comme ensemble de règles pour la tâche en cours. Les skills se trouvent dans ~/.claude/skills/<skill-name>/SKILL.md (global, disponible dans tous les projets) ou dans .claude/skills/<skill-name>/SKILL.md à l'intérieur d'un dépôt spécifique (portée projet).

Chaque SKILL.md commence par un bloc frontmatter (un court en-tête YAML entre deux lignes ---). Les deux clés obligatoires sont name (un identifiant court) et description (une phrase qui indique à Claude quand le skill s'applique). C'est la description que Claude Code affiche dans la liste des skills et utilise pour décider s'il doit le suggérer automatiquement.

Un skill se déclenche de deux façons. Premièrement, de façon explicite : l'utilisateur tape /skill-name comme commande slash. Deuxièmement, automatiquement : si votre description correspond à ce que l'utilisateur demande, Claude Code peut l'invoquer sans qu'on lui demande. Le corps du fichier SKILL.md (tout ce qui suit le frontmatter) est du Markdown ordinaire et peut contenir des instructions étape par étape, des contraintes, des règles de format de sortie, ou même des modèles de code.

La structure de dossier recommandée pour un skill bien organisé est :

• SKILL.md (obligatoire) : le frontmatter et les instructions
• README.md (facultatif) : documentation lisible par l'auteur du skill
• examples/ (facultatif) : exemples d'entrées et de sorties attendues dont Claude peut s'inspirer
• templates/ (facultatif) : modèles de fichiers que Claude doit copier ou compléter lors de l'exécution

Découvrir et installer des skills

Claude Code est livré avec un outil Skill intégré, un mécanisme qui permet à l'agent de charger un prompt spécialisé, un workflow ou un mini-agent à la demande. Un skill est un paquet nommé stocké dans ~/.claude/skills/<name>/SKILL.md. Quand vous (ou Claude lui-même) invoquez un skill, l'outil Skill lit ce fichier et adopte ses instructions pour le reste de la tâche.

Les skills se découvrent par plusieurs canaux. Le plus simple est de taper une commande slash comme /graphify ou /code-review dans le prompt de Claude Code. Claude vérifie la liste des skills disponibles (affichée dans son rappel système) et appelle l'outil Skill automatiquement. Vous pouvez aussi demander en langage naturel : "find a skill for X" déclenche le skill find-skills, qui parcourt le registre et suggère ce qu'il faut installer.

Le principal point de distribution est le dépôt communautaire affaan-m/ECC sur GitHub, qui regroupe des centaines de skills prêts à l'emploi. Il suffit de cloner ou copier les skills voulus dans ~/.claude/skills/ pour qu'ils soient immédiatement disponibles. Des auteurs individuels publient aussi des fichiers SKILL.md sous forme de gists ou de sous-dossiers de dépôt que vous pouvez déposer de la même façon.

Points essentiels à comprendre sur le système de skills :

• Invocation : commande slash (ex. /deep-research) ou déclencheur en langage naturel défini dans CLAUDE.md.
• Portée : les skills dans ~/.claude/skills/ sont globaux ; un projet peut ajouter les siens dans .claude/skills/.
• Composition : un skill peut appeler l'outil Skill pour enchaîner sur un autre skill.
• Inventaire : exécutez /skill-stocktake pour auditer chaque skill installé et son déclencheur.

L'écosystème MCP

MCP (Model Context Protocol) est un standard ouvert qui permet à Claude de se connecter à des outils externes, des sources de données et des invites réutilisables via une interface unique et uniforme. Plutôt que de coder en dur chaque intégration, vous branchez un serveur MCP (un petit programme qui parle le protocole) et Claude acquiert immédiatement de nouvelles capacités.

MCP définit exactement trois primitives (les briques de base que chaque serveur expose) :

• Outils : des fonctions appelables que Claude peut invoquer, comme rechercher dans une base de données, exécuter une commande shell ou appeler une API. Chaque outil a un nom, une description et un schéma d'entrée type afin que Claude sache comment l'appeler correctement.
• Ressources : des sources de données en lecture seule (fichiers, URL, lignes de base de données) que Claude peut récupérer et inclure dans sa fenêtre de contexte (la mémoire de travail utilisée par conversation). Les ressources sont identifiées par une URI et renvoyées sous forme de texte ou de blobs binaires.
• Invites : des modèles d'invites nommés et réutilisables stockés sur le serveur. Une invite peut accepter des arguments et renvoyer un message prêt à l'emploi, ce qui facilite le partage d'instructions cohérentes au sein d'une équipe sans copier-coller.

Dans Claude Code, vous configurez les serveurs MCP dans .claude/settings.json sous la clé mcpServers. Une fois enregistrés, tous les outils exposés par le serveur apparaissent automatiquement dans l'agent, et vous pouvez voir la liste complète avec /mcp dans l'invite de Claude Code.

Connecter un serveur MCP

MCP (Model Context Protocol) est un standard ouvert qui permet à Claude Code de communiquer avec des outils externes et des sources de données via un petit processus serveur. Chaque serveur MCP expose un ensemble d'outils (des actions que Claude peut appeler) et de ressources (des données que Claude peut lire). Il suffit d'en installer un, d'indiquer son emplacement à Claude Code, et ces fonctionnalités apparaissent automatiquement dans chaque conversation.

Claude Code supporte deux portées pour les serveurs MCP. La portée utilisateur rend un serveur disponible dans tous les projets de votre machine. La portée projet limite le serveur à un dépôt spécifique, ce qui permet d'isoler les identifiants et les ensembles d'outils. Les serveurs à portée projet sont déclarés dans .claude/settings.json au sein du dépôt ; ceux à portée utilisateur se trouvent dans votre fichier global ~/.claude/settings.json.

De nombreux serveurs MCP nécessitent une authentification avant que Claude Code puisse appeler leurs outils. Les deux méthodes courantes sont le jeton statique (vous collez une clé secrète une fois et elle est enregistrée dans la configuration) et OAuth (Open Authorization, un flux basé sur le navigateur où vous vous connectez avec votre vrai compte et le serveur délivre un jeton d'accès temporaire). OAuth est préféré lorsque le service dispose déjà de vos identifiants, car aucun secret durable n'est stocké dans un fichier.

• Ajouter un serveur à portée utilisateur : claude mcp add <name> -- <command> [args]
• Ajouter un serveur à portée projet : claude mcp add --scope project <name> -- <command> [args]
• Lister les serveurs connectés et leur statut : claude mcp list
• Supprimer un serveur : claude mcp remove <name>
• Déclencher un flux de connexion OAuth pour un serveur : claude mcp authenticate <name>

Construire son propre serveur MCP

Le Model Context Protocol (MCP) est un standard ouvert qui permet à Claude Code d'appeler des outils externes que vous définissez vous-même. Au lieu d'être limité aux commandes intégrées, vous pouvez exposer n'importe quelle fonction (une requête en base de données, un appel API, une transformation de fichier) comme un outil que Claude découvre et invoque automatiquement.

Les serveurs MCP communiquent avec Claude Code via l'un des deux transports disponibles (le canal par lequel transitent les messages). stdio (entrée/sortie standard) est le plus simple : Claude Code lance votre serveur comme un processus enfant et échange des messages JSON via stdin et stdout. HTTP avec Server-Sent Events (SSE) fait tourner votre serveur comme un service web persistant, utile quand le serveur doit être partagé entre plusieurs machines ou rester actif entre les sessions. Pour les outils locaux, stdio est presque toujours le bon choix.

Chaque outil que vous exposez comporte trois parties obligatoires : un nom unique, une description lisible par un humain (Claude la lit pour décider quand appeler l'outil), et un schéma d'entrée (un objet JSON Schema qui décrit les paramètres acceptés par l'outil). Claude Code valide chaque appel par rapport au schéma avant de l'exécuter, ce qui permet de détecter les mauvais arguments très tôt.

• Installez le SDK : npm install @modelcontextprotocol/sdk
• Choisissez stdio pour les outils locaux, HTTP/SSE pour les serveurs partagés ou distants.
• Rédigez une description claire : Claude choisit les outils en lisant ce texte.
• Validez les entrées avec les champs required et type de JSON Schema.

Patterns de sous-agents

Un sous-agent est un processus Claude Code distinct que Claude lance pour traiter une tâche spécifique en isolation. "Isolation" signifie qu'il dispose de sa propre fenêtre de contexte vierge (le tampon mémoire contenant la conversation en cours), ce qui l'empêche de voir l'historique, les identifiants ou le raisonnement intermédiaire de la session parente. C'est intentionnel : un contexte frais reste concentré et évite de polluer les résultats avec des informations sans rapport.

Quand faut-il déléguer à un sous-agent ? La règle de base est la suivante : déléguer quand une tâche est indépendante (elle n'a pas besoin de connaissances que le parent possède déjà), coûteuse (elle consommerait la majeure partie du budget de contexte du parent en lisant de nombreux fichiers), ou parallélisable (plusieurs tâches similaires peuvent s'exécuter en même temps). On peut citer comme exemples l'exécution d'un audit de sécurité complet sur un seul module, la génération d'une traduction pour chaque langue prise en charge, ou l'exécution d'une suite de tests sur une branche.

Claude Code reconnaît trois types d'agents nommés que vous rencontrerez dans les skills et la documentation :

• Orchestrateur : l'agent parent qui planifie le travail, le divise en sous-tâches et assemble les résultats. Il utilise l'outil Task en interne pour lancer les enfants.
• Sous-agent (travailleur) : un processus enfant qui reçoit une invite unique et bien délimitée et renvoie un résultat. Il n'a aucune mémoire des agents frères.
• Agent évaluateur : un sous-agent spécialisé dont le seul rôle est d'évaluer la production d'un autre agent par rapport à une liste de critères, puis de signaler une réussite ou un échec avec justification.

Étant donné que chaque sous-agent démarre à froid, l'orchestrateur doit passer tout le contexte nécessaire dans l'invite elle-même : chemins de fichiers, extraits de code pertinents, contraintes et format de sortie attendu. Traitez chaque invite de délégation comme un ticket autonome remis à un prestataire qui n'a jamais vu votre projet.

Événements de hook : le cycle de vie

Claude Code expose un système de hooks qui vous permet d'exécuter vos propres scripts à des moments précis d'une session. Chaque moment est appelé un événement de hook. Vous enregistrez un hook dans settings.json en associant le nom d'un événement à une commande shell. Claude Code exécute cette commande automatiquement lorsque l'événement se déclenche.

Les principaux événements de hook sont :

• PreToolUse : se déclenche juste avant que Claude appelle un outil (lecture de fichier, commande bash, requête web, etc.). Utilisez-le pour journaliser, bloquer ou modifier l'appel.
• PostToolUse : se déclenche immédiatement après qu'un outil a retourné son résultat. Utilisez-le pour auditer la sortie, déclencher des effets de bord ou mettre à jour un affichage de statut.
• Stop : se déclenche lorsque Claude a terminé sa réponse finale et s'apprête à passer en veille. Utilisez-le pour effectuer un nettoyage, envoyer une notification ou mettre à jour un fichier mémoire.
• SessionStart : se déclenche une seule fois à l'ouverture d'une nouvelle session Claude Code. Utilisez-le pour charger du contexte, afficher un tableau de bord ou définir des variables d'environnement pour la session.
• Notification : se déclenche lorsque Claude Code émet une notification destinée à l'utilisateur (par exemple, une demande de permission ou une mise à jour d'une tâche en arrière-plan).

Les hooks reçoivent via stdin un JSON structuré décrivant l'événement : quel outil a été appelé, quels arguments ont été passés, quel est le résultat, etc. Votre script lit ce JSON, effectue son travail et se termine. Un code de sortie non nul sur un hook PreToolUse annule complètement l'appel à l'outil, vous offrant ainsi un contrôle léger mais efficace.

Écrire un script de hook

Un script de hook est un petit programme que Claude Code exécute automatiquement à un moment précis, par exemple avant qu'un outil s'exécute ou après qu'un fichier est sauvegardé. Les hooks vous permettent d'imposer des règles, de journaliser des actions ou de transmettre des informations supplémentaires à Claude sans modifier vos prompts.

Chaque hook reçoit un payload JSON (un objet de données structuré) sur l'entrée standard (stdin) décrivant ce que Claude s'apprête à faire. Le payload contient un champ tool_name que vous pouvez comparer pour décider si votre script doit agir. Les noms d'outils courants sont Bash, Edit, Write et Read.

Votre script contrôle la suite via son code de sortie (un nombre que votre script renvoie au système d'exploitation à la fin de son exécution) et sa sortie standard (stdout) :

• Exit 0 : autorise l'appel de l'outil à se poursuivre normalement.
• Exit 2 : bloque l'appel de l'outil et affiche votre message stdout à l'utilisateur sous forme d'erreur.
• Tout autre code non nul : bloque silencieusement (Claude Code le traite comme un échec critique).

Si vous écrivez un objet JSON sur stdout avec un champ continue défini à true et une chaîne stopReason, Claude lit ce texte et peut ajuster son action suivante. C'est ainsi que vous transmettez du contexte au modèle en cours de tâche, transformant un garde passif en conseiller actif.

Plugins : tout regrouper en un seul endroit

Un skill Claude Code est un répertoire qui se distribue comme une unité installable. À l'intérieur, vous pouvez combiner tous les points d'extension que vous avez appris : slash commands, hooks, déclarations de serveur MCP et même des définitions de sous-agents. Quand quelqu'un installe votre skill, toutes ces pièces s'activent ensemble, sans câblage manuel.

Le point d'entrée est un fichier SKILL.md. Claude le lit au moment de l'invocation pour comprendre la finalité du skill, ses commandes disponibles et les instructions de configuration. À côté de lui, le répertoire du skill contient généralement les scripts de support, les extraits de configuration et les manifestes MCP qui servent ces commandes.

Un skill bien structuré couvre quatre couches :

• Commandes : les slash commands que l'utilisateur peut saisir, définies comme sections dans SKILL.md ou comme fichiers .md séparés dans un sous-dossier commands/.
• Hooks : scripts de cycle de vie (par exemple PostToolUse ou Stop) déclarés dans un sous-dossier hooks/ et référencés dans settings.json.
• Serveurs MCP : fournisseurs d'outils externes listés sous mcpServers dans le fragment settings.json associé au skill.
• Agents : invites de sous-agents réutilisables que les commandes du skill peuvent lancer via l'outil Task.

Les skills résident dans ~/.claude/skills/<skill-name>/ pour un usage global, ou dans .claude/skills/<skill-name>/ à l'intérieur d'un dépôt pour un usage limité au projet. Invoquer un skill est aussi simple que de taper /skill-name dans l'invite Claude Code.

settings.json en profondeur

settings.json est le fichier de configuration qui contrôle le comportement de Claude Code dans un projet ou de façon globale. Il couvre quatre domaines principaux : les permissions (les outils que Claude peut utiliser sans demander confirmation), les variables d'environnement (valeurs injectées dans chaque session), les hooks (commandes shell déclenchées automatiquement à certains moments) et les règles de localisation des fichiers ainsi que de priorité.

Il existe deux niveaux de portée. Le fichier utilisateur situé à ~/.claude/settings.json s'applique à tous les projets ouverts. Le fichier projet situé à .claude/settings.json à la racine d'un dépôt s'applique uniquement à ce dépôt. Lorsque les deux existent, les paramètres du projet prennent le dessus sur les paramètres utilisateur pour chaque clé commune, et le reste est hérité.

Le bloc permissions utilise une liste allow et une liste deny. Chaque entrée est un identifiant d'outil tel que Bash, Edit ou un nom d'outil MCP. Les entrées dans allow autorisent Claude à appeler cet outil sans confirmation ; les entrées dans deny le bloquent complètement. Le bloc env est un simple objet clé-valeur : chaque clé devient une variable d'environnement disponible pour les hooks et tout sous-processus lancé par Claude.

Le bloc hooks associe des événements du cycle de vie à des commandes shell :

• PreToolUse : s'exécute avant qu'un outil soit appelé (utile pour la journalisation ou le blocage).
• PostToolUse : s'exécute après la fin d'un appel d'outil.
• Stop : s'exécute à la fin de la session (utile pour les résumés ou la synchronisation mémoire).
• Notification : se déclenche lorsque Claude envoie un événement de notification.

Chaque entrée de hook est un objet comportant un matcher (nom d'outil ou "*" pour tous) et une chaîne command exécutée dans le shell. Les hooks s'exécutent en tant qu'utilisateur courant et disposent donc d'un accès complet au système : gardez-les courts et vérifiés.

Styles de sortie

Claude Code adopte par défaut un style conversationnel et détaillé : il explique son raisonnement, liste les étapes et confirme les actions. Ce comportement par défaut est utile quand vous apprenez, mais il génère du bruit lorsque vous êtes dans une boucle d'itération rapide ou que vous redirigez la sortie vers un autre outil.

Vous contrôlez le style de sortie via deux leviers principaux : les options de la ligne de commande et les instructions directement dans le prompt. Les options sont fiables et lisibles par les machines ; les instructions de prompt sont flexibles et portables.

Les options les plus importantes sont :

• --output-format json : émet un objet JSON structuré plutôt que du texte, utile lorsqu'un script doit analyser le résultat.
• --output-format text : texte brut, sans markdown, pratique pour rediriger vers grep ou sed.
• --verbose : affiche les appels d'outils et les étapes de raisonnement internes, utile pour comprendre pourquoi Claude a fait quelque chose d'inattendu.
• --no-stream : attend la réponse complète avant de l'afficher, au lieu de diffuser les tokens au fur et à mesure.

Dans le prompt, vous pouvez ajouter des directives de style comme "réponds uniquement avec le contenu du fichier, sans commentaire" ou "retourne une seule commande shell, rien d'autre." Claude Code les respecte de façon cohérente avec claude-opus-4-8, claude-sonnet-4-6 et claude-haiku-4-5.

Tâches de fond et outils web

Claude Code peut lancer des processus longs en arrière-plan afin que vous n'ayez pas à attendre leur fin avant de donner la prochaine instruction. L'option run_in_background demande à l'outil Bash de démarrer une commande sans bloquer : Claude la lance, continue sa tâche et vous notifie quand elle se termine. C'est utile pour les compilations, les suites de tests ou les serveurs de développement qui gèleraient sinon la conversation.

Deux outils web étendent Claude Code au-delà de vos fichiers locaux. WebSearch interroge le web et renvoie une liste classée de résultats avec titres, URLs et extraits. WebFetch récupère le contenu complet d'une URL précise, supprime le HTML et transmet le texte lisible à Claude. Ensemble, ils permettent à Claude de répondre à des questions nécessitant des informations récentes ou une documentation externe, sans que vous n'ayez à copier-coller quoi que ce soit.

Savoir quel outil utiliser est important. Utilisez WebSearch quand vous devez découvrir des sources (vous ne connaissez pas encore la bonne URL). Utilisez WebFetch quand vous avez déjà une URL et souhaitez que Claude lise la page en entier (par exemple une référence d'API ou un journal des modifications). Utilisez run_in_background quand une commande shell prendrait plus de quelques secondes et que vous voulez continuer à travailler en parallèle.

• run_in_background : exécution shell non bloquante, résultat délivré sous forme de notification.
• WebSearch : recherche web en direct, retourne des extraits et des liens.
• WebFetch : récupère et lit une page complète à une URL donnée.
• Les trois fonctionnent dans une conversation Claude Code normale, sans plugin requis.

MCP grandit : la révision du 28-07-2026

MCP (Model Context Protocol) est le standard ouvert qui permet à un client IA, comme Claude Code, de dialoguer avec des outils et des sources de données externes via des serveurs indépendants plutôt que des intégrations sur mesure au coup par coup. Depuis son lancement, MCP a connu des mises à jour incrémentales, mais la version dont la release candidate a été figée le 21 mai 2026 et dont la spécification finale est datée du 28-07-2026 est la plus grande révision qu'ait connue le protocole. Elle change la façon dont les connexions sont établies, ajoute deux nouvelles capacités (interface utilisateur interactive et tâches longue durée), renforce la sécurité et instaure une gouvernance formelle pour l'approbation des futurs changements.

Le changement principal est que le cœur du protocole devient sans état (stateless), ce qui signifie que le serveur n'a plus besoin de se souvenir de quoi que ce soit concernant une connexion client spécifique entre les requêtes. Dans l'ancien modèle, un client ouvrait une connexion via une poignée de main d'initialisation (initialize handshake) (un échange de configuration où client et serveur s'accordent sur les capacités avant que le vrai travail ne commence) et le serveur suivait cette session à l'aide d'un en-tête Mcp-Session-Id attaché à chaque requête. Les deux disparaissent dans cette révision. Désormais, les métadonnées du client (des informations d'identification comme le nom et la version du client) voyagent dans un champ _meta sur chaque requête, si bien que chaque requête est autonome. C'est important car des requêtes sans état peuvent être traitées par n'importe quelle instance de serveur disponible, ce qui signifie qu'un répartiteur de charge (load balancer) peut répartir les requêtes sur un pool de serveurs MCP en tourniquet (round-robin, en passant d'un serveur à l'autre dans l'ordre) au lieu d'attacher un client à un seul serveur pour toute la durée d'une session. C'est la différence entre un serveur MCP qui ne peut tourner que comme un unique processus fragile et un serveur qui peut monter en charge horizontalement comme une API web classique.

Deux nouvelles extensions officielles débloquent des capacités qui étaient auparavant rajoutées de façon ad hoc. MCP Apps permet à un serveur de livrer une interface utilisateur interactive qui s'affiche dans une iframe sandboxée (un cadre de navigateur intégré, isolé de la page hôte pour des raisons de sécurité), si bien qu'un outil n'est plus limité à renvoyer du texte brut ou du JSON : il peut remettre à l'utilisateur un vrai panneau interactif. L'extension Tasks donne au protocole un moyen standard de représenter un travail de longue durée, comme une tâche qui prend des minutes plutôt que des secondes, afin qu'un client puisse vérifier le statut ou recevoir des mises à jour sans garder une connexion ouverte en attendant.

La sécurité et l'interopérabilité ont elles aussi reçu de vraies améliorations. OAuth/OIDC (les protocoles standards de connexion déléguée et de vérification d'identité utilisés à travers le web) ont été renforcés dans cette révision, resserrant la façon dont les serveurs MCP authentifient les clients. La spécification prend désormais aussi en charge le contexte de traçage W3C (W3C trace context), un format standard pour faire transiter des identifiants de traçage entre systèmes afin qu'une requête puisse être suivie à travers plusieurs sauts, utile pour déboguer une chaîne d'appels d'outils. En plus de cela, MCP dispose désormais d'une politique de dépréciation (deprecation policy) formelle à trois états, Active, Deprecated et Removed, et d'une règle imposant qu'au moins 12 mois s'écoulent entre le marquage Deprecated d'un élément et sa suppression effective (Removed), donnant aux équipes une trajectoire prévisible plutôt qu'une rupture surprise.

La gouvernance a changé aussi. Les propositions Standards Track (des changements destinés à intégrer la spécification officielle) doivent désormais réussir une suite de tests de conformité obligatoire avant d'être acceptées, sous la supervision de l'AAIF (Agentic AI Foundation), l'organe de gouvernance désormais responsable de l'orientation du protocole. Les SDK bêta (kits de développement logiciel, les bibliothèques que les développeurs utilisent pour construire des clients et des serveurs MCP) pour cette nouvelle révision sont sortis le 29 juin 2026 pour Python, TypeScript, Go et C#, permettant aux développeurs de commencer à tester le nouveau comportement avant que la spécification ne soit finalisée un mois plus tard.

L'écosystème autour de MCP à la mi-2026 donne une idée de l'échelle et de l'endroit où placer sa confiance. Le registre officiel sur registry.modelcontextprotocol.io était en gel d'API à la version 0.1, en route vers une disponibilité générale 1.0, listant environ 2 000 serveurs, un nombre restreint mais soigneusement sélectionné. Les registres tiers sont bien plus grands : Glama en listait environ 52 581 open source, PulseMCP environ 15 930, et Smithery environ 7 300. L'échelle diffère nettement de la vérification, donc un compte énorme sur un registre tiers n'offre pas la même garantie qu'une liste officielle plus petite mais mieux curatée. Les fournisseurs cloud se standardisent eux aussi autour de MCP : le serveur AWS MCP a atteint la disponibilité générale le 6 mai 2026 avec plus de 60 serveurs officiels, et lors de Cloud Next 26, Google a ouvert ses serveurs MCP gérés par Google à tout le monde, avec plus de 50 en disponibilité générale ou en préversion.

La bibliothèque de skills : une carte guidée

Un skill est un ensemble empaqueté d'instructions, et parfois de scripts, qui apprend à Claude Code à traiter un certain type de tâche correctement : déboguer d'une certaine façon, concevoir une interface d'une certaine façon, rédiger un certain format de document. Vous installez des skills, puis vous les invoquez par leur nom (en tapant /nom-du-skill) ou vous laissez Claude Code en choisir un automatiquement quand la tâche correspond à sa description. En juillet 2026, l'écosystème a suffisamment grossi pour que le vrai savoir-faire consiste à savoir quel skill mobiliser.

Deux mécaniques ont changé récemment et toutes deux comptent pour votre travail au quotidien. D'abord, depuis Claude Code v2.1.199 (2 juillet 2026), les skills peuvent être empilés : taper /skill-a /skill-b tâche charge plusieurs skills sur un seul prompt, si bien que Claude peut, par exemple, appliquer un skill de design et un skill de vérification à la même tâche en une seule fois plutôt qu'en passes séparées. Ensuite, un skill /dataviz pour créer des graphiques et des visualisations de données est livré intégré à Claude Code depuis la v2.1.198, ce qui signifie qu'il est disponible d'emblée, sans installation.

La distribution elle-même est décentralisée, et cela vaut la peine d'être compris avant d'installer quoi que ce soit. Le chemin officiel est une marketplace de plugins git : un dépôt git qui empaquette un ou plusieurs skills pour l'installation, ajouté avec /plugin marketplace add owner/repo puis installé avec /plugin install. Au-delà de ce chemin officiel, des annuaires tiers ont pris une ampleur énorme : SkillsMP indexe plus de 2 millions de skills, et claudemarketplaces.com revendique plus de 300 000 développeurs mensuels parcourant ses listes. Personne ne tient un index central ni un processus d'approbation unique, donc la qualité et la sécurité varient énormément d'un skill à l'autre ; traitez un skill inconnu comme vous traiteriez un paquet npm inconnu, pas comme vous traiteriez une fonctionnalité livrée par Anthropic.

Voici une carte guidée du paysage par catégorie, pour savoir quoi chercher plutôt que de fouiller à l'aveugle.

• Discipline de processus : la collection superpowers couvre les habitudes qui préviennent le mauvais travail avant qu'il ne commence, notamment brainstorming (explorer le problème avant de construire), systematic-debugging (diagnostiquer avant de corriger), test-driven-development (écrire le test qui échoue en premier), et verification-before-completion (exécuter et confirmer avant d'affirmer que c'est fait).
• Design et interface : frontend-design fixe la direction visuelle, high-end-visual-design vise une finition digne d'une agence, make-interfaces-feel-better ajuste les micro-détails comme l'espacement et les zones cliquables, et theme-factory applique un thème instantané à un artefact existant.
• Jeux : une chaîne de production complète allant de make-game (créer le squelette d'un nouveau jeu) à add-assets (remplacer les formes provisoires par de vrais visuels), add-audio (musique et effets sonores), add-multiplayer (réseau temps réel ou au tour par tour), jusqu'à monetize-game (ajouter des mécaniques de monétisation).
• SEO et GEO (GEO : optimisation pour les moteurs génératifs, c'est-à-dire la visibilité dans les réponses générées par l'IA plutôt que dans les seuls résultats de recherche) : un skill audit pour trouver les problèmes, technical pour la crawlabilité et la santé du site, on-page pour optimiser une page précise, et ai-visibility pour suivre comment une marque apparaît dans les réponses des assistants IA.
• Recherche : deep-research déploie plusieurs recherches web en parallèle et vérifie les affirmations de façon contradictoire avant de rédiger un rapport sourcé, agent-reach récupère du contenu sur 15 plateformes dont Reddit, GitHub et YouTube, et market-research gère l'analyse concurrentielle et le dimensionnement de marché.
• Documents : docx pour créer et modifier des fichiers Word, xlsx pour les tableurs.
• Connaissance : obsidian-second-brain pour gérer un coffre de connaissances personnel, graphify pour transformer une base de code en graphe interrogeable au lieu de relire les fichiers à chaque fois, et continuous-learning pour accumuler des enseignements d'une session à l'autre.
• Sécurité : owasp-security vérifie le code par rapport aux catégories de vulnérabilités du Top 10 OWASP, et security-scan exécute une analyse automatisée plus large.
• Orchestration : des skills pour concevoir des flux de travail dynamiques à plusieurs étapes, faire travailler des agents en parallèle, et gérer les budgets de tokens pour qu'une session longue ne manque pas de contexte.
• Méta-skills : skill-builder vous permet d'écrire votre propre skill de zéro, et find-skills vous aide à découvrir d'autres skills correspondant à un besoin que vous ne savez pas encore nommer.

Une règle simple évite que tout cela devienne écrasant : charger les skills de processus d'abord, les skills d'implémentation ensuite. Faites du brainstorming ou déboguez méthodiquement avant de recourir à un skill de design ou de code, sinon vous finissez par peaufiner la mauvaise solution. Si un skill peut plausiblement s'appliquer à la tâche devant vous, chargez-le avant d'agir plutôt qu'après ; l'empilement est peu coûteux depuis la v2.1.199, donc charger un skill de trop coûte peu, alors qu'en oublier un dont vous aviez besoin coûte davantage. Et comme la distribution est décentralisée et non contrôlée, auditez toujours les skills tiers avant de les installer, en particulier tout ce qui embarque des scripts exécutables ; une leçon ultérieure du module sécurité explique précisément comment mener cet audit.

Pour donner un ordre de grandeur, la collection superpowers (hébergée sur le dépôt obra/superpowers) est considérée comme le cadre de référence pour la discipline de processus, et avait atteint environ 150 000 étoiles GitHub en avril 2026. Sa version v6.1.0, datée du 30 juin 2026, a spécifiquement réduit le coût en tokens du chargement de la collection par session, un changement notable si vous l'empilez régulièrement avec d'autres skills.

Mise à jour du 11 juillet 2026 : la carte décrite ici est devenue publique. Ce cours héberge désormais un annuaire cherchable de 496 skills, plugins et marketplaces sur mastering-claude.com/skills/, avec un moteur sémantique local qui répond à « quelle skill pour cette tâche » en trois langues, les compteurs d'installations réels de l'écosystème et la checklist d'audit intégrée. Notez aussi que l'écosystème a bougé : le dépôt everything-claude-code a été renommé affaan-m/ECC et s'installe désormais comme plugin, et superpowers vit dans la marketplace officielle d'Anthropic.