Compétences: le langage invisible entre vous et vos agents
Les compétences sont des intentions encapsulées et réutilisables qui transforment les invites répétitives en un comportement d’agent évolutif et respectueux de l’architecture. Ils fusionnent trois éléments: le contexte (ce que l’agent sait lorsqu’il est utilisé), la capacité (ce qu’il peut faire) et l’intention (le résultat souhaité). En bref, une compétence définit: “Quand vous demandez cela, agissez comme ça. Toujours.” Et ça change tout.
Des invites au système
Sans compétences, vous pourriez fonctionner comme ceci:
“Revoyez ce PR et dites-moi les problèmes, analysez, soyez concis…”
Avec des compétences, vous diriez:
“Exécuter analyseTicket”.
Ce n’est pas seulement une question de commodité. C’est de l’architecture. Une compétence sait déjà:
- où chercher
- comment analyser
- quel format retourner
- quels outils utiliser
Vous arrêtez d’écrire des instructions et commencez à orchestrer des comportements.
Le parallèle que tout développeur comprend
Si vous êtes un développeur, cela vous semblera familier. Passer des invites aux compétences, c’est comme passer de scripts lâches à des fonctions bien conçues. Ou mieux encore: les services.
Vous ne répétez pas la logique. Vous l’encapsulez. Vous ne dépendez pas de la façon dont vous l’écrivez aujourd’hui; vous dépendez de la façon dont la compétence est définie. Cela ouvre les portes à:
- comportement versionné
- tests d’agents
- réutilisation dans les équipes
- améliorations incrémentielles sans interrompre les flux
Là où les compétences brillent: lorsqu’elles sont connectées à MCP
Les compétences seules sont utiles, mais lorsqu’elles sont connectées au MCP, elles atteignent un tout autre niveau. Ils ne sont plus simplement un moyen de dialoguer avec le modèle et deviennent de véritables actions sur les systèmes.
Une compétence peut:
- lire les tickets Azure DevOps
- interroger Freshdesk
- revoir le code dans les dépôts
- analyser les métriques
- déclencher des actions
Et tout cela sous une seule et même intention.
Exemple réaliste: résoudreIncident
Cette compétence pourrait:
- récupérer les alertes récentes
- les recouper avec les journaux
- examiner les modifications récentes du dépôt
- suggérer des causes probables
- proposer une solution
Vous n’enchaînez pas les invites. Vous exécutez un flux intelligent.
Le plus grand changement mental
Il y a un coût à démarrer de cette façon. Passez de la question du modèle aux fonctionnalités que vous souhaitez dans votre système. C’est du design, pas de la conversation. C’est essentiel si vous souhaitez faire évoluer les agents pour de vrai, et pas seulement exécuter de jolies démos.
Le piège commun
Une erreur fréquente consiste à créer trop de compétences très spécifiques. Cela conduit à un système rigide et difficile à maintenir, sans doute pire que l’écriture d’invites.
Une bonne compétence a un équilibre:
- suffisamment spécifique pour être utile
- assez général pour être réutilisable
Ce n’est pas anodin, mais c’est là que réside la valeur.
Sommes-nous en train de construire une nouvelle couche logicielle?
Oui. Et c’est assez important. Les compétences sont en quelque sorte l’API interne de vos agents.
Pour en savoir plus sur les mécanismes plus larges derrière les compétences et les API, voir: