🔧 Qu'est-ce qu'un Skill ?
Dans le contexte des agents IA, un skill (appelé aussi tool or function) est une capacité empaquetée et réutilisable qu'un LLM peut invoquer pour interagir avec le monde extérieur à sa fenêtre de contexte. Les skills comblent le fossé entre la compréhension du langage et l'action dans le monde réel.
Chaque skill possède quatre composants :
- Name — un identifiant unique que le modèle utilise pour référencer le skill (par ex.,
web_search) - Description — du texte en langage naturel expliquant ce que fait le skill et quand l'utiliser ; le LLM lit ceci pour décider quand appeler le skill
- Schéma d'entrée — une définition structurée des arguments (JSON Schema) ; le modèle les remplit en fonction de la tâche
- Implementation — le code réel qui s'exécute : un appel API, une requête base de données, une commande shell, ou toute autre opération
Exemple : A get_weather le skill a la description "Récupère la météo actuelle pour une ville", accepte { "city": "string" } en entrée, et appelle une API météo. Le LLM ne voit jamais la clé API ni l'appel HTTP — il reçoit simplement le résultat sous forme de texte.
⚙️ Comment le Calling d'Outils Fonctionne
Quand un agent a accès à des skills, le LLM ne les appelle pas directement — il requests un appel en générant une sortie structurée. Le runtime (le code de votre application) exécute l'appel réel et retourne le résultat. Voici le cycle complet :
- Enregistrement de l'outil — Votre code envoie au modèle une liste de skills disponibles avec leurs descriptions et schémas
- Raisonnement du modèle — Le LLM lit la tâche et les outils disponibles, décide quel outil appeler et avec quels arguments
- Requête d'appel d'outil — Le modèle produit un message structuré "tool call" (par ex.,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — Votre code runtime appelle la fonction, l'API ou le service réel
- Injection de résultat — Le résultat est réinjecté dans le contexte de la conversation
- Raisonnement continu — Le modèle lit le résultat et appelle soit un autre outil, pose une question de suivi, ou génère la réponse finale
Cette boucle peut se répéter plusieurs fois dans un même tour. Une tâche agentique complexe peut appeler 10–20 outils en séquence avant de produire une réponse finale.
📊 Skills vs Plugins vs MCP Servers
La terminologie a évolué rapidement. Voici comment les concepts se rapportent historiquement :
| Era | Name | Comment cela fonctionnait | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | Extensions installables par l'utilisateur avec une spec OpenAPI ; ChatGPT les appelait via HTTP | Obsolète (remplacé par GPTs + tools) |
| 2023 | OpenAI Function Calling | Définitions JSON Schema au niveau API ; le modèle produit un appel de fonction structuré, votre code l'exécute | Actif — renommé "tool use" |
| 2023– | Tool Use / Skills | Identique à l'appel de fonction ; Anthropic a forgé le terme "tool use", d'autres utilisent "skills" ou "functions" | Actif — norme actuelle |
| 2024– | MCP Servers | Protocole standardisé (Anthropic, déc. 2024) pour empaqueter et distribuer des serveurs d'outils ; tout client MCP peut se connecter à n'importe quel MCP server | Actif — écosystème en croissance |
Distinction clé : L'utilisation traditionnelle d'outils est définie inline dans le code de votre application. Les MCP servers sont des processus autonomes qui exposent des outils via un protocole standardisé — les rendant réutilisables par différents clients IA (Claude Desktop, Cursor, VS Code, agents personnalisés). Lire la suite : Qu'est-ce que MCP.
🗂️ Catégories d'outils et niveaux de risque
Tous les outils n'ont pas le même niveau de risque. Les regrouper par niveau de risque aide à définir la espace d'action et où ajouter des points de contrôle human-in-the-loop :
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | Autoriser en autonome ; consigner tous les appels |
| Écrire (local) | write_file, create_dir, edit_code | Medium | Limiter à un répertoire de travail sandboxé |
| Réseau / Externe | send_email, post_to_slack, call_api | Moyen–Élevé | Approbation HITL pour envois irréversibles |
| OS / Shell | run_command, execute_script, install_package | High | Restreindre à un environnement containerisé ; HITL requis |
| Destructive | delete_file, drop_table, revoke_access | Critical | Toujours exiger une confirmation humaine explicite |
🏗️ Anatomie d'un bon Skill
La décision de conception la plus importante pour un skill est son description. Le LLM lit les descriptions pour décider quel outil appeler — une description mal rédigée conduit à un mauvais choix d'outil, à des appels manqués ou à des arguments ambigus.
Qu'est-ce qui rend une description efficace
- Être explicite sur quand l'utiliser — "Utilisez cet outil lorsque l'utilisateur demande des données en temps réel ou des événements actuels" est mieux que "Searches the web"
- Indiquer ce qu'il NE fait PAS — "Ne retourne pas de données historiques de plus de 30 jours"
- Décrire le format de sortie — "Retourne un tableau JSON de résultats de recherche avec les champs title, url et snippet"
- Limiter à 200 mots — des descriptions plus longues que ~200 tokens peuvent surcharger l'attention du modèle lorsque de nombreux outils sont enregistrés
Principes de conception du schéma
- Requis vs optionnel — Ne marquez les champs comme requis que si c'est vraiment nécessaire ; les champs optionnels avec valeurs par défaut réduisent les erreurs du modèle
- Utiliser des enums pour les valeurs contraintes —
"format": {"enum": ["json", "markdown", "text"]}préviens les valeurs hallucinées - Préférer les outils idempotents — Les outils qui peuvent être relancés en toute sécurité (lectures, recherches) sont plus sûrs que des actions à usage unique (envois, suppressions)
- Retourner des données structurées — Les réponses JSON sont plus faciles à raisonner pour le modèle que des blobs de texte non structurés
💡 Exemples concrets
| Nom du skill | Ce qu'il fait | Arguments clés | Risk |
|---|---|---|---|
web_search | Interroger un moteur de recherche et retourner les meilleurs résultats | query: string, num_results?: number | Low |
read_file | Lire un fichier depuis le répertoire de travail | path: string, offset?: number, limit?: number | Low |
write_file | Créer ou écraser un fichier | path: string, content: string | Medium |
run_tests | Exécuter la suite de tests du projet et retourner les résultats | filter?: string | Medium |
browser_screenshot | Naviguer vers une URL et retourner une capture d'écran | url: string | Medium |
send_email | Envoyer un e-mail à un ou plusieurs destinataires | to: string[], subject: string, body: string | Élevé — toujours HITL |
run_shell | Exécuter une commande shell arbitraire | command: string, cwd?: string | Élevé — bac à sable requis |
✅ Bonnes pratiques
Permissions minimales
Accorder à chaque agent seulement les outils dont il a besoin pour sa tâche spécifique. Un agent qui répond aux FAQ n'a pas besoin de write_file or send_email. Plus l'espace d'action est restreint, plus le rayon d'impact est petit si l'agent est manipulé. Voir : Agence excessive.
Auditer tous les appels d'outils
Consigner chaque appel d'outil avec ses arguments et son résultat. Cela permet le débogage, l'attribution des coûts, et la détection de comportements anormaux (par ex., un agent lisant ~/.ssh/ alors qu'il ne devrait accéder qu'au répertoire du projet). Des plateformes AgentOps comme LangSmith facilitent cela.
Humain dans la boucle pour les actions irréversibles
Toute action difficile ou impossible à annuler — envoi de messages, suppression de données, achats — doit exiger une confirmation humaine explicite avant exécution. Intégrez des points de contrôle HITL dans votre environnement d'exécution pour l'agent, pas seulement dans le prompt. Les prompts peuvent être remplacés ; le code non.
Se méfier de la contamination d'outils
Si vous permettez aux agents d'installer ou de découvrir dynamiquement des MCP servers, un serveur malveillant peut enregistrer un outil avec une description contenant des instructions cachées. Passez toujours en revue les descriptions d'outils avant de les ajouter au registre de votre agent. Voir : Contamination d'outils.
Écrire des retours d'erreur clairs
Quand un outil échoue, retourner une erreur structurée avec suffisamment de contexte pour que le modèle puisse récupérer ou s'escalader — pas une trace de pile d'exception brute. Exemple : { "error": "rate_limited", "retry_after": 5 }. Une erreur bien décrite permet à l'agent de réessayer, d'utiliser un outil de secours, ou d'informer l'utilisateur de manière élégante.