Avant le battage médiatique autour de Protocole de contexte de modèle (MCP) Alors que la polémique avait eu le temps de se calmer, Anthropic a sorti un autre atout de son chapeau : Compétences de l'agentCette évolution nous oblige à repenser l'architecture fondamentale des systèmes d'IA.

Nous dépassons la simple dichotomie « agent ou outil ? » pour adopter une compréhension plus nuancée. Les agents sont des entités décisionnelles complètes dotées d'invites système, d'un accès aux outils, de modèles sous-jacents (Claude, ChatGPT, etc.) et de boucles d'exécution leur permettant d'orchestrer les flux de travail et de gérer l'état. À l'inverse, les nouvelles compétences d'agent sont des ensembles modulaires et déclaratifs d'expertise : des connaissances procédurales organisées et conditionnées en unités réutilisables que les agents chargent progressivement selon leurs besoins.

Cela soulève une question architecturale intéressante et fondamentale : qu’est-ce qui doit être un agent et qu’est-ce qui doit être une compétence ? Ce choix a des implications concrètes sur la gestion du périmètre, la fiabilité des fenêtres de contexte, l’extensibilité et l’évaluabilité. La réponse ne consiste pas à privilégier l’un plutôt que l’autre. agents dotés de compétences.

Pourquoi les agents ne peuvent pas évoluer uniquement grâce aux invites.

Les premiers systèmes multi-agents se sont heurtés à des limitations prévisibles. Les équipes développaient des agents spécialisés pour chaque cas d'usage : un agent de service client, un agent de programmation, un agent de recherche. Lorsque ces agents nécessitaient de nouvelles fonctionnalités, les développeurs mettaient à jour les messages système ou créaient un agent entièrement nouveau. Cette approche fonctionne pour les tâches simples, mais devient rapidement ingérable à grande échelle.

Ce schéma se répétait d'une organisation à l'autre : un nouveau cas limite nécessitait des modifications immédiates, qui parfois résolvaient le problème, mais entraînaient souvent des régressions ailleurs. Les agents ne disposaient pas de mécanismes pour apprendre de leur exécution ni pour transférer leurs connaissances d'un contexte à l'autre. Les fenêtres de contexte se retrouvaient encombrées d'instructions de plus en plus complexes ou de contradictions, ce qui perturbait les agents, les rendait confus ou incapables de raisonner face à des informations contradictoires.

Collectivement, nous pensions que les agents seraient très différents selon les domaines, en fonction de leurs instructions et de leurs outils. Mais la relation modèle-agent sous-jacente est en réalité plus universelle que nous le pensions. Cette constatation a suggéré un modèle différent : un agent généraliste doté d’une bibliothèque de fonctionnalités spécialisées.

Pourquoi les agents ont besoin de compétences

Les compétences nous permettent d'enrichir l'expertise métier sans modifier l'architecture. Elles sont principalement déclaratives : les experts métier peuvent ainsi contribuer sans modifier la logique de l'agent. Une équipe de sécurité peut, par exemple, intégrer ses processus de conformité dans une compétence. Une équipe d'ingénierie des données peut y intégrer ses bonnes pratiques ETL. Ces contributions ne nécessitent aucune intervention sur le système principal de l'agent ni sur son processus de décision.

Face à de nouveaux scénarios, les compétences définissent clairement les responsabilités des agents. Les équipes peuvent ainsi mettre à jour une compétence pour un domaine sans risquer de régressions dans un autre. Les compétences peuvent être versionnées, testées individuellement et améliorées grâce à la télémétrie, le tout sans les inconvénients liés à l'ingénierie des invites système.

Les compétences permettent chargement progressifCette fonctionnalité introduit des ressources progressivement afin de limiter la surcharge des fenêtres de contexte. Quiconque utilise des agents a probablement déjà constaté les problèmes liés à la surcharge de ces fenêtres, et des recherches menées tout au long de l'année 2025 ont démontré que cette surcharge entraîne des dysfonctionnements inattendus.

Le chargement progressif résout ce problème : lors de l’exécution, les agents ne voient que les métadonnées des compétences (nom et description). Le contenu complet n’est chargé que lorsque l’agent détermine qu’une compétence est pertinente pour la tâche en cours. Ainsi, la quantité de contexte intégrée aux compétences peut être pratiquement illimitée sans compromettre les capacités de raisonnement de l’agent.

Quand créer un agent ou une compétence

Alors, comment choisir ? Utilisez le tableau comparatif suivant pour guider vos décisions architecturales :

De nombreux agents existants — des invites structurées offrant un accès aux outils — peuvent probablement devenir des compétences moyennant quelques modifications mineures. Cependant, certains cas d'utilisation nécessitent réellement le contrôle, la gestion du périmètre et l'évaluabilité qu'offrent les agents complets.

Un exemple concret : la migration de ClickHouse

Nous avons été confrontés à ce même dilemme architectural lors de la construction. clickhouse.buildClickHouse est un assistant de codage interactif qui aide les développeurs à migrer leurs charges de travail analytiques de Postgres vers ClickHouse. Notre interface en ligne de commande (CLI) proposait initialement quatre agents spécialisés : un scanner qui identifie les requêtes analytiques dans les bases de code, un outil de migration de données pour configurer ClickPipes, un outil de migration de code qui ajoute des interfaces ClickHouse tout en maintenant la rétrocompatibilité, et un agent d’assurance qualité pour valider les modifications.

Le périmètre était volontairement restreint : requêtes Postgres et bases de code TypeScript. Cette spécificité garantissait des agents performants, mais limitait leur applicabilité. Lorsque Anthropic a lancé Agent Skills en octobre 2025, nous avons vu l’opportunité d’élargir ce périmètre sans compromettre la qualité.

Grâce à l'introduction des Skills, nous pouvons désormais prendre en charge d'autres sources de traitement transactionnel en ligne (OLTP) telles que MySQL et MongoDB, les bases de code Python et Java, et proposer des flux de travail d'assurance qualité plus flexibles sans avoir à réécrire nos agents principaux. Les responsables des clients de langage peuvent développer des Skills pour leurs domaines (Golang, Java, Python) sans modifier la logique d'orchestration des agents. Nous pouvons ainsi concevoir des évaluations autour de Skills spécifiques et les améliorer indépendamment.

Les agents ont besoin d'une licence pour exercer leurs compétences.

L'avenir de Agent IA Il ne s'agit pas de choisir entre agents et compétences, mais d'avoir des agents dotés des compétences adéquates au moment opportun ; des agents habilités à exercer leurs compétences, en quelque sorte. Les agents orchestrent, gèrent le périmètre et garantissent la qualité par le biais d'évaluations. Les compétences, quant à elles, regroupent l'expertise, protègent les fenêtres de contexte et permettent aux experts du domaine de contribuer.

Cette architecture est déjà en train de remodeler des systèmes de production comme clickhouse.build, et avec l'émergence de compétences en tant que norme ouverte parallèlement à MCP, elle est en passe de devenir la voie par défaut pour la construction de systèmes d'IA évolutifs et maintenables.