# Le contexte comme primitive de premier rang : pourquoi les capacités de votre agent ne devraient pas être figées dedans

> Une décision d'architecture discrète se cache dans la plupart des agents IA, et elle conditionne tout le reste : où vivent réellement les capacités de l'agent ?

Language: fr · Category: governance · Author: Nicolas Corod · Published: 2026-08-26

**En bref : les capacités d'un agent IA ne devraient pas être soudées à l'agent. Traitez le contexte (savoir-faire, outils, état) comme une primitive de premier rang : des skills et des connecteurs distincts, que l'agent découvre, autorise et charge à la demande. Vous gagnez composition, itération indépendante et gouvernance, au prix d'une vraie couche d'orchestration.**

Aujourd'hui, pour la plupart des agents, la réponse à la question « où vivent ses capacités ? » est : « dedans ». Les outils qu'il peut appeler, le savoir métier sur lequel il s'appuie, les intégrations avec lesquelles il dialogue : tout est soudé à l'agent au moment du build. Pour une démo, ça tient. En production, ça vieillit mal. Chaque nouvelle capacité oblige à toucher le cœur, chaque correction impose un redéploiement, et l'agent se fige peu à peu en un objet que seuls ses auteurs d'origine osent modifier.

Le choix plus durable consiste à traiter **le contexte comme une primitive de premier rang** : quelque chose qu'on peut nommer, faire circuler, composer, versionner et charger à la demande, plutôt que quelque chose d'enfoui dans l'agent. Skills et connecteurs sont l'unité naturelle de ce changement, mais seulement s'ils sont traités comme des entités distinctes et interchangeables, et non câblés dans l'agent comme des pièces fixes.

## Ce que « de premier rang » veut vraiment dire

L'expression est empruntée à dessein. Dans les langages de programmation, faire des fonctions des « citoyens de premier rang » (des valeurs qu'on peut stocker, passer et composer) n'a rien eu de cosmétique. Des paradigmes entiers en sont nés, parce que le comportement devenait quelque chose qu'on manipule, et non plus quelque chose de gravé dans le flot de contrôle.

Le même mouvement s'applique au contexte. Quand le contexte est de premier rang, la capacité cesse d'être une propriété de l'agent et devient une chose à part entière : découvrable, interchangeable, attribuable à un responsable. Encore faut-il être précis sur ce que « contexte » recouvre ici, car il s'agit de trois choses distinctes :

- **Le savoir** : procédures, expertise métier, style maison, la façon dont *votre* entreprise fait réellement une chose. C'est ce qu'empaquette une **skill**.
- **Les outils et les actions** : la capacité d'atteindre un système externe et d'y faire quelque chose. C'est ce que fournit un **connecteur**.
- **L'état** : ce qui est pertinent, maintenant, pour la tâche que l'agent a devant lui.

Le codage en dur fusionne les trois dans l'agent. Les rendre de premier rang les sépare en entités qu'on peut raisonner indépendamment. C'est de cette séparation que viennent les bénéfices.

Une précision, car « entité » se lit facilement comme « fichier séparé ». Ce n'en est pas un. Un [`SKILL.md`](https://agentskills.io) dans un dépôt ou une procédure dans une page Notion n'est qu'un emballage : nécessaire, mais pas l'essentiel. Ce qui fait d'une chose une entité, c'est une propriété d'exécution : l'agent peut la découvrir, l'autoriser et la charger à la demande sans que son propre code change. Faites un `git clone` du dépôt de skills dans votre build, ou collez ce document Notion dans un prompt système, et la frontière du fichier survit mais la séparation disparaît : vous avez replié la capacité dans l'agent. C'est toujours du codage en dur, avec des étapes en plus. C'est la couche de découverte et de chargement qui rend un fichier de premier rang, pas l'endroit où il est rangé.

## Ce que cela permet

**La composition.** Quand skills et connecteurs sont des entités distinctes, on assemble la capacité tâche par tâche au lieu de reconstruire l'agent pour chacune. Un agent support et un agent finance peuvent partager un connecteur CRM et charger des jeux de skills entièrement différents. On compose au lieu de dupliquer. Tout l'intérêt est dans la réutilisation combinatoire : *n* skills et *m* connecteurs donnent bien plus que *n + m* comportements.

**Une fenêtre de contexte allégée.** Un agent dans lequel tous les outils et toutes les procédures sont figés les transporte à chaque requête, que la tâche en ait besoin ou non. Ce n'est pas seulement du gaspillage : cela dégrade activement les performances, parce que l'attention du modèle se disperse sur deux cents outils qu'il n'appellera jamais. Quand la capacité est chargée à la demande, l'agent ne prend que ce que la tâche exige. Le contexte reste pertinent, et la précision s'améliore en conséquence directe. Le mécanisme est détaillé dans [du context bloat au context load](/fr/blog/du-context-bloat-au-context-load/).

**Une itération indépendante.** C'est le bénéfice que les product owners ressentent le plus. Si l'API d'un connecteur change ou qu'une procédure doit être mise à jour, on corrige la skill ou le connecteur, pas l'agent. Les cycles de vie sont découplés. Pas de réentraînement, pas de redéploiement du cœur, pas de risque de régression sur des capacités sans rapport. L'équipe qui possède la logique de facturation peut livrer une meilleure skill de facturation sans jamais ouvrir le code de l'agent.

**La réutilisation entre agents.** Une skill bien écrite n'est pas liée à un seul assistant. Le même savoir empaqueté peut servir tous les agents de l'organisation, et un connecteur peut alimenter de nombreux flux. Écrivez une fois la skill « comment nous traitons les remboursements » : tous les agents en contact avec les clients en héritent. C'est exactement la prémisse de [skilder.ai](https://skilder.ai) : réunir skills et connecteurs dans des rôles, configurés une fois sur le savoir-faire de l'entreprise et servis à tous les outils d'IA qu'elle utilise. L'unité de travail devient la skill, pas la réécriture d'intégration.

**La découvrabilité à l'exécution.** Parce que les capacités sont des entités nommées et non des branches cachées dans le code, un agent peut *chercher* la bonne quand une tâche se présente, au lieu de devoir tout connaître d'avance. Cela passe à l'échelle comme le codage en dur ne le fera jamais : on n'énumère pas chaque capacité à la conception, on laisse l'agent trouver ce qui convient à l'exécution. Organiser ces capacités en graphe plutôt qu'en fichiers épars, c'est l'objet de [comment les skill graphs passent à l'échelle](/fr/blog/skill-graphs-mise-a-echelle/).

**La gouvernance à la frontière.** Quand un connecteur est une entité distincte, les permissions, l'isolation et la journalisation s'y attachent directement. On peut dire « cet agent peut utiliser le connecteur d'analytique en lecture seule, mais pas celui qui émet des remboursements » comme un fait de configuration, pas comme un point de revue de code. La sécurité vit à une frontière nette au lieu d'être dispersée dans une logique monolithique, ce qui la rend aussi auditable.

**Les effets d'écosystème.** Une fois skills et connecteurs de premier rang, des tiers peuvent en écrire. Votre équipe cœur cesse d'être le goulot d'étranglement de chaque intégration. La capacité croît avec l'écosystème plutôt qu'avec vos effectifs : la même dynamique qui a fait des registres de paquets la colonne vertébrale du développement logiciel moderne. Côté outils, c'est ce que permet le [Model Context Protocol](https://modelcontextprotocol.io), dont l'articulation avec les skills est détaillée dans [au-delà de « MCP vs skills »](/fr/blog/au-dela-de-mcp-vs-skills/).

**La testabilité.** Chaque skill et chaque connecteur se vérifie isolément. On peut tester « la skill de remboursement produit-elle les bonnes consignes ? » sans monter l'agent complet, ce qui rend l'ensemble plus maintenable à mesure qu'il grandit.

## Les vrais compromis

Rien de tout cela n'est gratuit. Sortir la capacité de l'agent introduit une complexité d'orchestration : quelque chose doit décider quoi charger, et quand. La qualité de la découverte devient un vrai sujet : si l'agent ne *trouve* pas de façon fiable la bonne skill, une grande bibliothèque nuit plus qu'elle n'aide. Les versions et la compatibilité entre un agent et ses connecteurs demandent une gestion active. Le chargement dynamique ajoute de la latence. Et charger de la capacité à l'exécution élargit la surface à sécuriser.

Il faut cependant être clair sur le sens dans lequel jouent les coûts. Orchestrer le contexte, c'est-à-dire ne charger que les skills et connecteurs utiles à la tâche, *réduit* de façon fiable la consommation de tokens d'un agent au lieu de l'augmenter : le modèle ne transporte plus à chaque appel des centaines de définitions d'outils et de procédures inutiles. Cela allège aussi le coût d'exécution de l'orchestration elle-même, puisqu'il y a moins à traiter à chaque tour. La complexité se déplace vers la couche de chargement et de découverte, mais l'empreinte par requête diminue.

Aucun de ces points n'est une raison de refiger la capacité dans le cœur. Ce sont des raisons d'investir dans les couches d'orchestration, de découverte et de gouvernance : celles qui font qu'un système de premier rang fonctionne vraiment.

## La direction à prendre

Le pari sous-jacent est simple : l'agent devrait être un raisonneur relativement léger, posé sur un substrat de contexte riche et interchangeable. L'intelligence ne tient pas à la quantité de choses codées en dur, mais à la capacité de l'agent à saisir le bon savoir et la bonne action au bon moment.

Des skills et des connecteurs traités comme des entités distinctes, de premier rang, rendent ce substrat possible. Traitez le contexte comme une primitive, et votre agent cesse d'être un monolithe que vous entretenez pour devenir un système que vous faites grandir.