Context engineering : pourquoi trop de skills...

Context engineering : pourquoi 600 skills rendent vos agents moins efficaces

Résumé exécutif

Constat : Les repos de skills et les fichiers AGENTS.md donnent l’impression qu’il suffit d’ajouter du contexte pour rendre un agent meilleur. Les mesures récentes racontent une histoire plus nuancée : le contexte aide quand il est ciblé, mais il peut aussi coûter plus cher et dégrader les résultats.

Thèse : Le problème n’est pas la qualité isolée des skills. Le problème est la sélection. Une bonne skill n’est utile que si elle apporte une information non déductible, stable et spécifique au projet. Le besoin précis de la tâche, lui, appartient au prompt.

Point clé : Le context engineering est une discipline de retrait autant que d’ajout. La valeur vient de ce que l’on choisit de ne pas charger.

Implication : Copier un repo de centaines de skills ou générer automatiquement un AGENTS.md revient souvent à déléguer la seule partie où le jugement humain fait une différence mesurable : décider quel contexte mérite d’entrer dans la fenêtre.

Glossaire

Context engineering: : discipline qui consiste à concevoir, sélectionner, organiser et tester le contexte fourni à un agent IA.
Skill agentique: : paquet d’instructions, d’exemples, de scripts ou de ressources que l’agent peut charger pour mieux exécuter une famille de tâches.
AGENTS.md: : fichier de contexte placé dans un repo pour indiquer à un agent de code les conventions, commandes et contraintes locales.
Fenêtre de contexte: : quantité de tokens que le modèle peut prendre en compte dans une requête ou une session.
Token inutile: : information injectée dans le contexte qui n’apporte aucune contrainte ou connaissance locale que le modèle ne pouvait pas déduire. Elle n’est pas neutre : elle consomme du budget d’attention, du temps et de l’argent.
Lost in the Middle: : effet documenté où les modèles utilisent moins bien l’information située au milieu d’un long contexte que celle placée au début ou à la fin.

Un repo GitHub. 600 fichiers Markdown. Chacun écrit par quelqu’un de compétent.

Résultat : l’agent est plus lent, plus cher, et donne parfois de moins bonnes réponses qu’avec cinq fichiers choisis à la main.

Si ça ne vous met pas en colère, c’est que vous n’avez pas encore compris ce que ça implique sur votre propre rôle.

La bibliothèque sans bibliothécaire

600 livres écrits par des experts, empilés dans une pièce sans index ni rayonnages. Vous demandez à un assistant brillant d’y trouver une réponse. Il fouille, tombe sur des passages qui ressemblent à la réponse mais n’en sont pas, perd du temps, et finit par vous donner un résultat moins bon que s’il avait eu cinq livres choisis à la main.

C’est exactement ce qui se passe avec les repos de skills agentiques en 2026.

SkillsBench montre que les skills améliorent la performance moyenne, mais pas uniformément. Sur 84 tâches évaluées, 49 s’améliorent, 25 ne bougent pas, et 16 régressent. Autrement dit : dans près de 20% des tâches, ajouter des skills fait baisser la performance.

L’étude Evaluating AGENTS.md va plus loin : les fichiers fournis par les développeurs n’améliorent la réussite que d’environ 4% en moyenne, tandis que les fichiers générés par LLM la font baisser d’environ 3%. Et dans les deux cas, les fichiers de contexte augmentent l’exploration, les tests, le raisonnement, donc les coûts, de plus de 20%.

Vous pouvez donc payer plus cher pour de moins bons résultats.

Seule exception vraiment intéressante : les fichiers écrits avec une intention chirurgicale. SkillsBench observe que les skills compactes et ciblées apportent beaucoup plus que la documentation exhaustive. Le problème n’est jamais seulement la qualité des livres. C’est qu’il n’y a personne pour décider lesquels ouvrir.

Le grenier et le disjoncteur

“Oui, mais nos modèles ont 128K tokens de contexte. 200K. Un million. On a de la place.”

C’est comme dire que votre grenier fait 200 mètres carrés. Si tout est en vrac, bonne chance pour trouver le disjoncteur quand les plombs sautent.

Les modèles fonctionnent pareil. Leur capacité réelle est bien en dessous du chiffre sur la fiche. L’information au milieu du contexte est partiellement ignorée. Les dépendances entre informations distantes s’effondrent.

Chaque token inutile est un bruit actif. Il réduit la probabilité que le bon token soit utilisé.

L’illusion de la délégation

Face à ces constats, la réaction réflexe est de demander à l’IA de résoudre le problème :

“Génère-moi des skills optimisées."
"Écris-moi un AGENTS.md minimal."
"Analyse mon repo et produis le contexte idéal.”

SkillsBench a déjà répondu : les skills auto-générées n’apportent aucun gain moyen. Zéro. L’IA sait produire du texte bien structuré. Elle ne sait pas toujours décider ce qui ne doit pas exister.

Et c’est la même chose quand vous copiez un repo de 600 skills communautaires. Chaque skill, prise isolément, peut être excellente. Mais l’acte de valeur n’a jamais été dans la skill elle-même. Il est dans la décision de savoir si cette règle mérite d’exister comme contexte stable du projet.

Il est dans tout ce que vous avez choisi de ne pas mettre dans le contexte.

Copier des skills, c’est consommer le jugement de quelqu’un d’autre sans exercer le sien. Faire générer le contexte par l’IA, c’est déléguer la seule partie du processus où l’intelligence humaine fait une différence mesurable.

Votre intelligence a déménagé. Vous avez reçu l’avis ?

Pendant des décennies, la valeur d’un développeur résidait dans sa capacité à produire : écrire du code, concevoir des architectures, résoudre des bugs. En 2026, les modèles frontier font tout ça. Pas parfaitement, mais suffisamment pour que la production brute ne soit plus le goulet d’étranglement.

Le goulet, c’est le contexte.

Pas plus de texte. De meilleures décisions :

qu’est-ce que cet agent doit toujours savoir sur ce projet ?
qu’est-ce qui relève du contexte stable, et qu’est-ce qui relève du prompt du moment ?
qu’est-ce qui doit rester dans le tiroir ?

C’est du context engineering. C’est un travail de retranchement autant que d’ajout. Et c’est un travail que seul un humain qui comprend le projet, le domaine et l’intention peut faire correctement.

Cette compétence n’est pas innée. Elle se construit par itération : écrire une skill, tester l’agent avec et sans, mesurer la différence, élaguer.

Le context engineering n’est pas un talent. C’est une pratique.

Le repo aux 600 skills est le symptôme parfait de l’ancien réflexe : accumuler, documenter, couvrir tous les cas. L’instinct du développeur qui se dit “au pire, ça ne fait pas de mal”.

Sauf que les données disent le contraire. Ça fait parfois du mal. Mesurablement. Plus de 20% de surcoût dans l’étude AGENTS.md. Près de 20% de tâches dégradées dans SkillsBench. Un AGENTS.md moyen généré par LLM qui fait baisser la performance.

Le context engineering, c’est l’inversion de cet instinct.

Ce n’est pas :

qu’est-ce que je peux ajouter ?

C’est :

qu’est-ce que je peux retirer sans perdre de signal ?

En pratique : le test du token inutile

La théorie est posée. Reste la question qui compte : comment on fait, concrètement, pour ne pas être le type qui empile 600 skills en croyant bien faire ?

Avant d’ajouter une ligne à votre contexte agentique, qu’il s’agisse d’une skill, d’un AGENTS.md ou d’une documentation de référence, posez-vous trois questions.

1. Le modèle le sait-il déjà ?

Les conventions standard de Python, les patterns REST, la syntaxe TypeScript : le modèle frontier les connaît. Les écrire dans votre AGENTS.md, c’est lui répéter son propre cours.

2. Est-ce spécifique à ce projet ?

“Utiliser des noms de variables explicites” n’est pas spécifique.

“Les IDs patients utilisent le format NBI-XXXX-YY et jamais d’UUID” l’est.

3. Est-ce une règle stable ?

Le périmètre précis d’une tâche doit être porté par le prompt : “refactor ce composant React”, “prépare le déploiement Kubernetes”, “corrige ce test”.

La skill, elle, doit porter ce qui reste vrai d’une tâche à l’autre : conventions locales, invariants métier, commandes du repo, architecture décidée, formats non déductibles.

Une instruction qui n’est vraie que pour la demande du jour n’a rien à faire dans une skill.

Si la réponse à l’une de ces trois questions est non, le token n’a rien à faire là.

Un exemple vaut mieux qu’un slogan

Vous travaillez sur un dispositif médical connecté en Bluetooth : firmware, app mobile, protocole de stimulation.

Votre lead dev rédige une skill pour cadrer le code de l’agent.

Avant : skill “senior”, mais générique

Les services Bluetooth doivent suivre une convention de nommage claire et cohérente dans tout le projet.

Les commandes envoyées au dispositif doivent retourner un type de résultat explicite plutôt que des valeurs ambiguës ou des exceptions dispersées.

Les erreurs remontées par le firmware doivent être normalisées dans une couche dédiée avant d’être exposées au reste de l’application.

Le cycle de vie du dispositif doit être représenté par une machine d’état explicite, avec des transitions autorisées et testables.

En cas de conflit entre plusieurs traitements concurrents, la logique de priorité doit être définie et appliquée de manière déterministe.

Ça a l’air sérieux. C’est bien écrit.

Le problème : chaque phrase dit quoi faire sans dire comment le projet le fait.

Un modèle frontier, face à du TypeScript et du BLE médical, appliquerait déjà ces principes par défaut. Nommage cohérent, types explicites, machine d’état, gestion de priorité : ce sont les bonnes réponses génériques au domaine.

Vous venez de dépenser des tokens pour reformuler ce que le modèle savait déjà. Tout est vrai. Rien n’est utile.

Après : skill ciblée, située

Les services BLE exposent uniquement des fonctions préfixées gvs_.

Toutes les commandes de stimulation retournent StimResult<T>.

Les erreurs firmware sont normalisées en EREFError ; elles ne doivent jamais être lancées directement.

La machine d’état autorisée est strictement : idle -> armed -> active -> cooldown -> idle.

En cas de conflit, l’ordre de priorité est : safety > stimulation > diagnostic > telemetry.

Mêmes dimensions : nommage, type de retour, erreurs, machine d’état, priorités.

Mais chaque ligne contient une décision de design que le modèle ne pouvait pas deviner.

C’est du signal pur : tout ce qui est ici est non déductible.

Le mécanisme de chargement n’a pas besoin d’être magique

Il suffit souvent de ranger les skills là où elles s’appliquent :

stimbox-v4/
  packages/
    firmware/
      .claude/skills/
        eref-safety/SKILL.md
    webapp/
      .claude/skills/
        api-contracts/SKILL.md

L’agent qui travaille dans firmware/ charge les skills de firmware/.claude/skills/.

Celui qui travaille dans webapp/ charge les siennes.

Pas de fichier de routing, pas de config, pas de logique de sélection pseudo-intelligente. Juste la structure du projet.

C’est déterministe, pas intelligent. Et c’est précisément pour ça que ça marche.

La maintenance est non négociable

Une skill qui n’est pas testée régulièrement contre un prompt réel peut dériver vers l’effet négatif mesuré par SkillsBench.

Le contexte agentique est un produit vivant, pas un livrable qu’on pousse et qu’on oublie.

Si vous avez lu jusqu’ici en vous disant “ok, je vais écrire cinq bonnes skills et passer à autre chose” : mauvaise nouvelle. Le context engineering n’est pas un livrable. C’est une discipline continue.

Des golden standards, pas des opinions

Vous avez besoin d’un jeu de prompts de référence, des cas concrets de votre projet, avec les résultats attendus.

Sans ça, vous optimisez à l’aveugle.

Quand vous modifiez une skill, vous la rejouez contre ces cas. Le résultat s’améliore, se dégrade, ou ne bouge pas. C’est le seul arbitre valable.

Le test ultime : le diff avec et sans

Lancez l’agent avec vos skills.

Lancez-le sans.

Si le diff est négligeable, vos skills n’apportent rien. Si le diff est négatif, elles font du mal. Le seul cas qui justifie le coût en tokens, c’est un diff clairement positif.

Dix minutes. Ne pas le faire, c’est piloter à l’aveugle.

S’arrêter sur les erreurs

Quand l’agent se trompe, la tentation est de rajouter une ligne dans la skill.

C’est le réflexe d’accumulation.

Le bon réflexe : comprendre pourquoi l’erreur est arrivée. Parfois la correction, c’est de retirer du contexte, pas d’en ajouter.

Changer de modèle, c’est changer les résultats

Une skill optimisée pour Claude ne donne pas les mêmes résultats sur GPT, ni sur la version suivante du même modèle.

Ce qui était non déductible hier peut devenir du bruit demain.

C’est un boulot à plein temps. Quelqu’un doit posséder le contexte agentique comme on possède une base de code : le tester, le versionner, le tailler.

Si personne ne le fait, vous retournerez au repo de 600 skills en trois mois.

Le mot de la fin

Le prompt engineering promettait : trouvez la bonne formulation, le modèle fait le reste.

Cette promesse est morte.

La performance agentique se joue dans l’architecture du contexte : ce qui doit être stabilisé dans une skill, ce qui doit rester dans le prompt, et ce qui doit disparaître.

Et surtout, quoi ne pas charger.

Le repo aux 600 skills n’est pas forcément un mauvais repo. C’est un monument à un réflexe périmé. Chaque skill peut être un bon livre. Mais la valeur n’a jamais été dans les livres.

Elle est dans le bibliothécaire qui sait lequel vous tendre, et surtout, lesquels laisser sur l’étagère.

Si vous êtes en train de copier un repo de skills ou de faire générer votre AGENTS.md par l’IA, posez-vous une question :

êtes-vous en train de construire du contexte, ou de consommer celui de quelqu’un d’autre ?

Parce que la réponse détermine si vous êtes le context engineer, ou le token de trop.