Cours Skills et approche agentique — skills, MCP, workflows, permissions, évaluation, garde-fous

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. définir « approche agentique » et situer skills, MCP, hooks, sous-agents, plugins dans une pile cohérente ;
2. écrire un skill simple (en-tête, description, instructions) et expliquer sa charge progressive dans le contexte ;
3. décider quand utiliser un skill, un hook, un serveur MCP ou un sous-agent ;
4. concevoir un workflow agentique avec étapes, vérifications et arrêts ;
5. configurer des permissions de moindre privilège et expliquer leurs limites ;
6. évaluer un skill ou un workflow avec des tâches de test ;
7. appliquer les garde-fous et la règle de confidentialité, y compris pour des skills et serveurs d'origine tierce.

Prérequis

• Notions de Markdown, JSON, ligne de commande et git.
• Avoir lu (ou parcourir) les cours Agents et Claude Code de cette section.
• Aucun outil requis pour lire ; pour pratiquer, un environnement jetable.

Parcours et chapitres

1. Que veut dire « agentique » ?

Une approche agentique confie à un modèle une partie de la conduite d'une tâche : choisir les outils, enchaîner les étapes, réagir aux résultats. Les sources officielles distinguent les workflows (chemin fixé par le code) des agents (chemin décidé par le modèle) et recommandent de partir du plus simple. Dans les outils comme Claude Code, ces éléments se superposent :

2. Les skills : principe et charge progressive

Un skill est, d'après la documentation d'Anthropic, un répertoire contenant au minimum un fichier SKILL.md (instructions et métadonnées) et pouvant inclure des scripts et des ressources. Il fonctionne par divulgation progressive :

Conséquence pratique : la description décide du déclenchement ; elle doit dire ce que fait le skill et quand l'utiliser. Une description vague ou chevauchante fait charger le mauvais skill ou aucun. À distinguer de CLAUDE.md, chargé à chaque session : y mettre ce qui est toujours vrai ; dans un skill, ce qui sert parfois.

Dans Claude Code (page Skills) : emplacements ~/.claude/skills/<nom>/SKILL.md (personnel), .claude/skills/<nom>/SKILL.md (projet), plugins, politique d'organisation ; priorité entre emplacements décrite par la page ; invocation directe par /nom ou automatique selon la description. Champs d'en-tête documentés : name, description, disable-model-invocation, user-invocable, allowed-tools, context: fork, argument-hint, model, paths, etc. (liste susceptible de changer). Pour la plateforme d'API et claude.ai, la page d'aperçu indique name (≤ 64 caractères, minuscules, chiffres, tirets) et description (≤ 1024 caractères) ; ces contraintes sont celles de cette page et leur application à Claude Code est non vérifiée.

Exemple synthétique de skill à effet de bord réservé à l'appel manuel :

---
name: relecture-compte-rendu
description: Relit un compte rendu de réunion fictif et signale ambiguïtés et actions sans responsable. À utiliser quand on demande de relire un compte rendu.
disable-model-invocation: true
---

# Relecture d'un compte rendu

1. Lis le texte fourni par l'utilisateur ; n'ouvre aucun autre fichier.
2. Liste les actions sans responsable ni échéance.
3. Liste les ambiguïtés, sans inventer d'information.
4. Réponds sous forme de tableau : élément, problème, suggestion.
5. Si une information manque, dis-le au lieu de supposer.

3. Sécurité des skills

La documentation d'Anthropic est explicite : n'utiliser que des skills que l'on a écrits ou obtenus de sources de confiance ; un skill malveillant peut diriger l'agent vers des appels d'outils ou une exécution de code sans rapport avec son but affiché (fuite de données, accès non autorisé). Points de contrôle avant d'adopter un skill tiers :

• relire tous les fichiers (instructions, scripts, images, ressources) ;
• chercher les appels réseau, accès à des fichiers hors sujet, commandes d'installation, URL externes (le contenu récupéré peut contenir des consignes piégées, et une dépendance de confiance peut changer avec le temps) ;
• examiner allowed-tools : un skill de projet peut pré-approuver des outils ; la page précise que ces pré-approbations n'écrasent pas les règles deny ;
• préférer disable-model-invocation: true pour tout effet de bord (déployer, supprimer, envoyer) ;
• restreindre ou masquer un skill via les règles de permission et les réglages (la page cite une règle Skill(...) en refus et un réglage de visibilité) ;
• noter que les skills ne sont pas couverts par la conservation zéro donnée (page d'aperçu) et que leur partage dépend de la surface : individuel sur claude.ai, partagé au niveau de l'espace de travail sur l'API, fichiers locaux ou paquets de plugins dans Claude Code.

Un dépôt cloné peut contenir des skills, hooks et configurations MCP : les lire avant de démarrer un agent dans ce dépôt.

4. Skills, Gems et autres « paquets d'instructions »

D'autres produits proposent des notions voisines : les Gems de Gemini (instructions et fichiers réutilisables) évoluent selon l'aide Google vers des skills (calendrier annoncé : novembre 2026 pour les comptes personnels, 2027 pour les comptes professionnels et scolaires d'après un résultat de recherche, à confirmer). Les projets et GPT personnalisés de ChatGPT jouent un rôle proche (voir le cours ChatGPT). La spécification MCP mentionne en outre une extension optionnelle « Skills over MCP » (instructions riches découvertes et consommées via MCP), signe que la frontière skills/MCP évolue. Ces conventions ne sont pas interchangeables : vérifier le format et le périmètre propres à chaque produit.

5. MCP : connecter des services

MCP expose des outils, ressources et invites à un hôte d'IA. Dans Claude Code :

• trois portées : locale (par défaut, configuration utilisateur propre au projet), projet (.mcp.json, partageable par versionnement), utilisateur ;
• transports : HTTP distant (recommandé par la page), SSE (déprécié), processus local (stdio), WebSocket ;
• les serveurs d'un .mcp.json demandent une approbation en mode interactif ; en mode non interactif ils se chargent sans invite : attention aux scripts ;
• authentification par OAuth ou en-têtes statiques : un jeton en clair dans une commande ou un fichier de configuration est un secret exposé, à éviter.

Exemple (à lire, non exécuté ; URL fictive) :

Sécurité : la page de Claude Code avertit que les serveurs qui récupèrent du contenu externe exposent à l'injection de consignes ; recommande des identifiants en lecture seule ; Anthropic précise ne pas auditer chaque serveur. La documentation de sécurité MCP recense notamment : le problème du « délégué confus » dans les proxys OAuth, le transfert de jeton sans validation (interdit par la spécification), les requêtes sortantes vers des ressources internes (SSRF), le piratage de références d'état, la compromission de serveurs locaux (commandes de démarrage malveillantes) et la minimisation des portées. Retenir côté utilisateur : un serveur local est du code exécuté avec vos droits ; un serveur distant reçoit ce que l'agent lui envoie ; demander le moins de portées possible.

6. Hooks et workflows

Un hook exécute une commande (ou une requête HTTP, un appel d'outil MCP, un prompt, un sous-agent) à un événement du cycle de vie : SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, etc. (liste de la page, susceptible de changer). La commande reçoit les données de l'événement en JSON sur l'entrée standard et agit par son code de sortie : 0 = pas d'objection ; 2 = bloque l'action pour un hook PreToolUse. Différence clé avec un skill (page « Extend Claude Code ») : un hook se déclenche sans que le modèle décide ; une règle « ne jamais éditer .env » écrite dans CLAUDE.md ou un skill est une demande, un hook PreToolUse qui bloque est une application.

Squelette conceptuel (synthétique, non exécuté, champs JSON à lire dans la référence des hooks du jour) :

#!/bin/sh
# lire le JSON de l'événement sur l'entrée standard
# si l'outil vise un chemin protégé : écrire la raison sur l'erreur standard
#   et terminer avec le code 2 (action bloquée)
# sinon terminer avec le code 0

Workflows. Un workflow agentique enchaîne des étapes avec des points de contrôle : planifier (mode plan), exécuter, vérifier (tests ou lint), relire (sous-agent à contexte neuf), valider (humain), puis publier. Claude Code propose en outre des « workflows dynamiques » (scripts qui lancent de nombreux sous-agents) et des sessions parallèles ; ces fonctions sont décrites comme évolutives (certaines en aperçu ou expérimentales : non vérifié pour la version de Stéphane). Règle de conception : garder chaque étape vérifiable, avec une condition d'arrêt et une borne de coût.

7. Permissions : moindre privilège

Rappels (page Permissions de Claude Code) :

• modes : Manuel, acceptEdits, plan, auto, dontAsk, bypassPermissions ; le dernier est réservé aux environnements isolés ;
• règles deny, ask, allow évaluées dans cet ordre ; un refus l'emporte ;
• une règle Bash(…) s'apparie au texte de la commande et n'est pas une frontière de sécurité autour d'un programme ; pour une garantie, utiliser le sandbox, qui n'isole que les commandes shell (pas les outils de fichiers, MCP ou hooks) et n'existe pas sur Windows natif ;
• des réglages d'organisation (réglages gérés) peuvent interdire bypassPermissions ou auto ;
• les sous-agents peuvent recevoir des outils limités.

Méthode : partir de tout refusé, autoriser l'essentiel en lecture, ajouter des autorisations ciblées (commande + arguments), refuser explicitement les secrets et le réseau inutile, relire périodiquement /permissions.

8. Évaluer skills et workflows

Un skill ou un workflow doit être testé comme du code :

1. Écrire 5 à 10 tâches synthétiques avec critère vérifiable (fichier produit, test qui passe, tableau conforme).
2. Inclure des cas pièges : entrée vide, texte contenant une consigne piégée, demande hors périmètre qui doit être refusée.
3. Exécuter plusieurs essais (les sorties varient) ; garder les transcriptions.
4. Noter : réussite, coût approximatif, écarts, cause (description trompeuse, consigne ambiguë, outil mal décrit).
5. Rejouer après chaque modification du skill (régression).

Les sources officielles donnent le vocabulaire (tâche, essai, correcteur, transcription) et recommandent de donner à l'agent un moyen de vérifier. Claude Code décrit des niveaux de contrainte : demander la vérification dans la consigne, une condition d'objectif évaluée à chaque tour, un hook Stop qui empêche de terminer tant qu'un contrôle n'a pas réussi, ou un sous-agent de vérification à contexte neuf. La documentation avertit qu'un relecteur invité à trouver des lacunes en signalera même si le travail est sain : borner ce qu'il doit relever.

9. Garde-fous : synthèse

Principe de ce corpus (non une citation) : combiner plusieurs barrières indépendantes ; ne pas compter sur la seule consigne ; supposer qu'un contenu externe puisse contenir une injection.

10. Confidentialité : ce qu'il ne faut pas envoyer

Skills, MCP et workflows augmentent ce que l'agent lit et peut transmettre. Ne jamais laisser un agent connecté à un service hébergé lire, résumer ou envoyer, sans autorisation et examen préalable : mots de passe, clés d'API, jetons, clés privées, fichiers .env, identifiants, noms d'hôtes ou détails d'infrastructure réelle, tickets privés, données de santé, données personnelles de tiers, documents confidentiels d'un employeur ou d'un client, contenus sous droits. Ne jamais écrire un secret dans un SKILL.md, un .mcp.json, un hook ou une commande claude mcp add. Utiliser des exemples synthétiques.

Attention aux fichiers de configuration versionnés : un skill, un hook ou un .mcp.json committé est partagé avec quiconque a accès au dépôt. Les transcriptions locales de Claude Code sont stockées en clair (30 jours par défaut d'après la page « Usage des données ») et peuvent contenir ce que l'agent a lu : les purger quand elles ne servent plus.

Exercices et vérifications de fin de cours

1. Pile : dessiner la pile skills/MCP/hooks/sous-agents/permissions pour un besoin synthétique.
2. Skill : écrire un SKILL.md complet, avec description testable.
3. Audit : auditer un skill tiers fictif (liste de signaux).
4. Hook : décrire un hook de blocage et son test sur dépôt jetable.
5. Évaluation : jeu de cinq tâches avec cas piège d'injection.
6. Permissions : jeu de règles de moindre privilège pour un agent de lecture.
7. Revérification : rouvrir les pages officielles listées et noter les écarts à la date du jour.

Critères de réussite

• Expliquer la charge progressive d'un skill et le rôle de la description.
• Choisir le bon mécanisme (skill, hook, MCP, sous-agent) pour un besoin.
• Citer au moins cinq signaux d'alerte pour un skill ou un serveur tiers.
• Distinguer consigne (demande) et application (hook, sandbox).
• Concevoir une évaluation avec essais répétés et cas piège.
• Appliquer la règle « aucun secret dans les fichiers de configuration ».