Skills : des capacités packagées et réutilisables

Le problème que résolvent les skills

Donner à un agent des instructions détaillées pour une tâche récurrente (rédiger un rapport d'incident au format de l'entreprise, remplir un gabarit de documentation, appliquer une checklist de revue de code) dans chaque conversation est répétitif et fragile : le prompt doit être recopié, il dérive au fil du temps, et rien ne garantit qu'il soit appliqué correctement. Un skill est un ensemble d'instructions, d'exemples et parfois de scripts, packagé une fois pour toutes et chargé par l'agent seulement quand la tâche le justifie.

Comment un agent choisit un skill

flowchart TD
    A[Tâche demandée] --> B{Un skill correspond\nà la description de la tâche ?}
    B -- Oui --> C[Chargement du skill\ndans le contexte]
    C --> D[Exécution de la tâche\navec les instructions du skill]
    B -- Non --> E[Traitement standard\nsans skill dédié]

Contrairement à un outil (function calling), qui expose une action ponctuelle (lire un fichier, appeler une API), un skill expose un savoir-faire : une procédure, un format, des conventions propres à une organisation. Claude Skills (Anthropic) fonctionne ainsi : chaque skill est un dossier contenant des instructions en markdown et, si besoin, des scripts, chargé dynamiquement seulement quand sa description correspond à la demande de l'utilisateur, pour ne pas surcharger le contexte avec des skills non pertinents.

Skill vs outil vs agent : où est la limite

Un skill n'agit pas par lui-même : il enrichit ce que l'agent sait faire, mais c'est toujours la boucle agentique (vue au chapitre 3) qui décide de l'utiliser et l'exécute, éventuellement combiné avec des outils.

Cas concret

Une équipe support IT doit rédiger, plusieurs fois par semaine, un rapport de post-mortem suivant un gabarit précis (résumé, chronologie, cause racine, actions correctives). Sans skill, chaque agent recommence de zéro, avec des variations de structure selon le prompt utilisé. Avec un skill "post-mortem" packagé une fois (structure exacte, ton attendu, exemples de bons et mauvais rapports), chaque rapport généré suit systématiquement le même format, sans que l'utilisateur ait à retaper les consignes à chaque fois.

Erreurs fréquentes

• Confondre un skill avec un simple prompt copié-collé : un skill bien conçu est versionné, testé, et chargé automatiquement selon le contexte, pas recopié manuellement.
• Empiler trop de skills disponibles en permanence, ce qui alourdit inutilement le contexte de l'agent même quand aucun n'est pertinent pour la tâche en cours.
• Mettre dans un skill ce qui devrait être un outil : un skill décrit un savoir-faire, il n'exécute pas d'action technique directe (ça reste le rôle des outils).

À retenir

• Un skill packagise une procédure ou un format réutilisable, chargé dynamiquement par l'agent quand la tâche correspond.
• Skill, outil et agent sont complémentaires : l'outil agit, le skill guide la manière de faire, l'agent orchestre les deux.
• Un skill mal ciblé (trop générique ou toujours chargé) alourdit le contexte sans bénéfice réel.

Mini-exercice

Une équipe veut qu'un agent applique systématiquement les mêmes 8 étapes de vérification avant de clôturer un ticket support. Skill ou outil ?

Réponse : un skill. Il ne s'agit pas d'une action technique ponctuelle (ça, ce serait un outil comme "changer le statut du ticket"), mais d'une procédure réutilisable à appliquer de façon cohérente, exactement ce que packagise un skill.