Pourquoi commencer par une carte
La plupart des contenus sur les agents IA commencent par le code. Résultat : on copie une configuration, ça marche à peu près, et au premier problème on est perdu — parce qu'on n'a jamais compris qui fait quoi.
Ce parcours prend le chemin inverse. Avant de créer votre première skill (étape 3) ou votre premier serveur MCP (étape 7), on installe le modèle mental. C'est un investissement de dix minutes qui rend les huit étapes suivantes évidentes — et qui vous évitera les erreurs d'architecture les plus coûteuses, celles qu'on découvre en production.
Trois acteurs, trois rôles. Regardez la carte ci-dessus : elle vous suivra pendant tout le parcours.
Le modèle : le cerveau qui orchestre
Au centre, le modèle de langage — Claude, dans notre cas. C'est le seul acteur qui décide. Deux points fondamentaux, souvent mal compris :
Le modèle est enfermé dans sa fenêtre de contexte. Il ne « sait » que ce qui se trouve dans la conversation en cours : vos messages, les instructions système, et ce qu'on y injecte. Il n'a pas d'accès natif à vos fichiers, votre base de données ou votre agenda. Tout ce qui n'est pas dans le contexte n'existe pas pour lui.
Le modèle est le seul point de décision. C'est lui qui choisit de charger une skill, lui qui choisit d'appeler un tool MCP, lui qui interprète les résultats. Les skills et les MCP sont des périphériques passifs branchés sur ce cerveau : ils ne se parlent jamais entre eux directement, et ils ne déclenchent jamais rien d'eux-mêmes.
Ce second point est la source du contresens le plus fréquent : non, un MCP ne peut pas « appeler une skill ». La flèche part toujours du modèle.
La skill : le manuel d'expertise
Une skill est un dossier d'instructions — concrètement, un fichier SKILL.md accompagné parfois de scripts d'appui — que le modèle charge à la demande quand la tâche s'y prête.
Ce qu'une skill transmet, c'est du savoir-faire :
- « Voilà comment produire un document Word professionnel dans les règles de l'art »
- « Voilà le format maison de nos comptes-rendus, les sections obligatoires, le ton attendu »
- « Voilà la procédure de déploiement, dans cet ordre, avec ces vérifications »
Deux propriétés font toute la valeur du mécanisme :
Le chargement à la demande. La skill n'occupe pas la fenêtre de contexte en permanence. Seule sa description (quelques lignes) est toujours visible ; le contenu complet n'est chargé que si le modèle juge la skill pertinente pour la tâche en cours. On peut donc disposer d'une bibliothèque de dizaines de skills sans saturer le contexte.
La description est le déclencheur. C'est elle — et elle seule — qui permet au modèle de savoir quand charger la skill. Une skill excellente avec une description floue ne sera jamais chargée : elle n'existe pas, en pratique. Nous y consacrerons une section entière à l'étape 3, car c'est le point de défaillance numéro un des skills en entreprise.
Le MCP : les mains
MCP — Model Context Protocol — est un protocole standard qui permet de brancher le modèle sur des systèmes externes. Un serveur MCP est un programme (local ou distant) qui expose des tools : des fonctions que le modèle peut appeler.
Ce qu'un MCP apporte, c'est de l'accès :
- lire et écrire dans une base PostgreSQL
- consulter un agenda, envoyer un e-mail
- interroger l'API GitHub, piloter un navigateur
- lire des fichiers sur un serveur
Le déroulé d'un appel est toujours le même : le modèle décide d'appeler un tool → le serveur MCP exécute → le résultat revient dans la fenêtre de contexte → le modèle continue avec cette nouvelle information. Le serveur, lui, est bête et méchant : il reçoit un appel, il exécute, il répond. Il ne sait même pas que les skills existent.
L'analogie qui a fait le succès du protocole : MCP est l'USB-C de l'IA. Une prise standard, définie une fois, sur laquelle n'importe quel outil peut venir se brancher — au lieu de développer une intégration spécifique par modèle et par service.
Précision de vocabulaire avant d'aller plus loin : MCP est le nom du protocole — la grammaire d'échange standardisée — et ce que l'on branche concrètement, ce sont des serveurs MCP qui l'implémentent. L'usage courant dit « un MCP » pour désigner le serveur ; nous le ferons parfois aussi, la nuance étant posée : les mains, c'est le serveur — la prise standard qui permet de les brancher, c'est le protocole.
Les trois ensemble : la boucle complète
Mettons les trois acteurs en mouvement sur un cas réel — celui qui servira de fil rouge à tout le parcours : la production automatisée d'un compte-rendu de réunion.
- Vous demandez : « fais-moi le compte-rendu de la réunion de ce matin et envoie-le à l'équipe »
- Le modèle charge la skill
compte-rendu-maison: il y lit le format attendu, les sections obligatoires, le ton, les règles de diffusion - Le modèle appelle un tool MCP
get_meeting_notespour récupérer les notes brutes dans votre outil de prise de notes - Le modèle produit le compte-rendu en appliquant les règles de la skill aux données ramenées par le MCP
- Le modèle appelle un second tool MCP
send_summarypour la diffusion
La skill a fourni le comment (l'expertise), le MCP a fourni le quoi (les données) et le faire (l'action). Le modèle a orchestré l'ensemble. Aucun des deux périphériques n'a pris une seule décision.
À l'étape 3, nous écrirons cette skill. À l'étape 7, nous coderons ce serveur MCP. À la fin du parcours, vous aurez construit cette boucle complète de vos mains.
Skills, MCP, RAG, fine-tuning : qui fait quoi
Quatrième source de confusion classique : situer skills et MCP par rapport aux deux autres techniques d'« augmentation » d'un modèle que sont le RAG et le fine-tuning.
La bonne nouvelle : ces quatre techniques se combinent. Un même assistant peut suivre une skill (procédure), appeler des tools MCP (accès), s'appuyer sur du RAG (connaissances) — le fine-tuning restant, dans la grande majorité des cas d'entreprise, la dernière option à considérer, pas la première. Nous avons détaillé cet arbre de décision dans notre guide RAG en production.
📚Pour aller plus loin
Pour les geeks : l'économie de la fenêtre de contexte. Pourquoi le chargement à la demande des skills est-il si important ? Parce que la fenêtre de contexte est une ressource finie et facturée. Instruction permanente dans le system prompt = coût en tokens payé à chaque requête, pertinente ou non. Skill = quelques lignes de description toujours visibles (négligeable), contenu complet chargé uniquement quand nécessaire. Sur un assistant d'équipe recevant des centaines de requêtes par jour avec 20 procédures documentées, la différence entre « tout dans le system prompt » et « tout en skills » se chiffre vite : c'est le même raisonnement d'optimisation que nous détaillons dans notre guide des coûts LLM. Corollaire d'architecture : une skill doit être autonome et ciblée — si elle a besoin d'une autre skill pour fonctionner, le découpage est mauvais.
📚Pour aller plus loin
Pour les geeks : où « tourne » chaque acteur. Le modèle tourne chez le fournisseur (ou en local pour les modèles open-weight — voir notre comparateur). La skill ne « tourne » nulle part : c'est du texte chargé dans le contexte ; seuls ses éventuels scripts d'appui s'exécutent, dans l'environnement d'exécution du client. Le serveur MCP, lui, est un vrai processus : soit local (lancé sur votre machine, communication stdio), soit distant (service HTTP). Cette distinction locale/distant a des implications réseau, d'authentification et de surface d'attaque majeures — nous les traiterons en profondeur aux étapes 6 et 8. À ce stade, retenez : skill = donnée, MCP = programme. On n'audite pas une donnée comme on audite un programme.
📍 Parcours Skills & MCP — étape 1/9
Vous venez de poser la carte. La suite du chemin :
- 🗺️ La carte avant le territoire ← vous êtes ici
- 🔬 Anatomie d'une skill
- 🛠️ Créer sa première skill
- 🏛️ Skills en entreprise : gouvernance
- 🔌 MCP : le protocole expliqué
- ⚡ Utiliser un serveur MCP existant
- ⚙️ Créer son serveur MCP minimal
- 🛡️ Sécuriser ses MCP
- 📡 L'écosystème : où trouver, où ça bouge
Prochaine étape → Anatomie d'une skill : on dissèque un vrai fichier SKILL.md ligne par ligne, et vous comprendrez pourquoi 20 lignes de texte bien structurées valent parfois un développement de trois semaines.
Pour aller plus loin dès maintenant : notre fiche Sécurité des agents IA — « vos nouveaux employés n'ont pas de badge » — et la fiche 40 outils Claude & MCP.