Du context bloat au context load.

Pourquoi votre IA d’entreprise s’alourdit à mesure qu’elle gagne en capacités, et comment corriger le problème structurellement.

TL;DR : votre agent ne devient pas plus bête. Votre contexte devient plus lourd.

---

Votre agent était excellent en v1.

Puis sont arrivés le deuxième tool, le troisième garde-fou, le quatrième script de workflow. Chaque ajout avait du sens sur le moment. Personne n’a rien retiré. Arrivé en v3, votre agent traîne 8 000+ tokens de contexte avant même que l’utilisateur n’ait dit un mot. Il ignore des instructions, coûte plus cher, et répond plus lentement.

Le réflexe est d’incriminer le modèle. Mais le modèle n’a pas changé. Ce qui a changé, c’est le contexte.

Le paradoxe des capabilities : plus vous ajoutez à votre agent, moins il performe de manière fiable. Ce n’est pas un problème de modèle. C’est un problème d’architecture du contexte.

---

Trois couches qui grossissent sans limite.

Les agents d’entreprise transportent trois types de contenu, chacun raisonnable isolément, collectivement toxiques sans gouvernance :

Tools : schémas d’API, définitions de fonctions. Un seul tool avec ses paramètres et exemples peut peser 200 à 400 tokens. 15 tools : jusqu’à 6 000 tokens avant le premier mot.

Skills : instructions comportementales, règles de conformité, lignes de conduite de persona. Écrits une fois, jamais élagués. Ils accumulent les amendements comme un contrat juridique.

Scripts : échafaudages de chain-of-thought, arbres de décision. Verbeux par construction. Un script de triage peut consommer 2 000+ tokens, dont l’essentiel est inutile à un appel donné.

À 3 $/M de tokens, 10 000 conversations par jour, 6 tours chacune : environ 1 500 $/jour rien qu’en coût de contexte système, avant même que la conversation ne démarre.

---

Le bloat fait mal de quatre façons distinctes.

~2×	plus d’échecs de suivi d’instructions quand le context grossit
18-24 %	de latence en plus en passant de 1 400 à 8 400 tokens
440 K $	de surcoût annuel à 10 000 conversations/jour

Issu de nos propres déploiements sur 3 pilotes entreprise (novembre 2024 à février 2025). Signal directionnel, pas un benchmark industriel. Les observations sur la latence rejoignent les travaux d’Anthropic sur le context engineering, qui montrent que la précision du modèle décroît à mesure que la fenêtre de contexte se remplit.

Au-delà du coût et de la latence : le modèle se met à faire des arbitrages silencieux entre instructions (lesquelles suivre, lesquelles ignorer partiellement) d’une façon que personne ne peut prédire ni expliquer. Nous l’avons observé comme une hausse constante des escalades et des flags de revue de sortie dès que les system prompts dépassaient 6 000 tokens.

Sur l’élargissement des fenêtres de contexte : passer à un modèle avec une fenêtre de 500 K tokens ne corrige pas le bloat. Cela le rend simplement plus cher. Des fenêtres plus grandes relèvent le plafond. Elles ne corrigent pas le problème de discipline sur ce qui doit réellement être chargé.

---

Arrêtez de déverser. Commencez à charger.

La plupart des équipes traitent la fenêtre de contexte comme un fichier de configuration : on la remplit de tout ce dont l’agent pourrait avoir besoin et on la laisse statique. C’est l’état d’esprit du bloat.

L’alternative : traiter le contexte comme un payload runtime. Assemblé à neuf à chaque appel. Contenant uniquement ce dont cet agent, traitant cette tâche, à ce tour, a réellement besoin.

Le principe du load : chaque token de votre contexte doit pouvoir répondre à la question : pourquoi est-il ici, pour cet appel précis, maintenant ? Si la réponse est « ça pourrait servir », ce token est probablement du bloat.

---

Découplez les capabilities des agents.

Patcher chaque agent individuellement ne passe pas à l’échelle. Dès que vous avez 6, 10, 15 agents, vous avez n agents qui résolvent indépendamment le même problème de contexte, sans gouvernance partagée, sans versioning partagé, avec des jours de décalage à chaque changement d’un tool ou d’une règle de conformité.

La réponse structurelle : les agents ne devraient pas posséder leurs capabilities. Les tools, skills et scripts doivent être définis centralement, versionnés indépendamment, et assemblés dans le contexte dynamiquement au runtime selon le rôle et la tâche.

En pratique, cela donne un graphe de capabilities : les nœuds sont des tools, skills et scripts, les arêtes définissent leurs relations. Un agent déclare un rôle. Un moteur de résolution traverse le graphe et charge exactement le bon bundle pour cet appel.

Avant : 12 tools + 6 blocs de skills + 2 scripts = 8 400 tokens par appel.

Après : 3 tools + 1 bloc de skill + 1 script = 2 000 tokens par appel. Une réduction de 76 %, cohérente avec notre première migration pilote.

---

Le paysage des modèles tire dans les deux sens.

Modèles frontier : les fenêtres de contexte continuent de grossir, mais les coûts par token aussi. Un prompt boursouflé de 8 400 tokens sur un modèle frontier premium ne corrige pas le bloat. Il le fait tourner sur une infrastructure plus chère.

Small language models : les SLMs (Phi-4, Mistral Small, Llama 3.2) montent vite pour les déploiements on-premise, sensibles au coût ou contraints par la souveraineté des données. Leurs limites de 4 K à 32 K tokens rendent l’architecture des capabilities non plus optionnelle, mais obligatoire.

Le graphe de capabilities est une couche d’abstraction indépendante du modèle. Il se moque de savoir si le modèle sous-jacent dispose de 8 K ou de 800 K tokens. Il assemble le bon payload et le passe à n’importe quel modèle que le déploiement exige : la même architecture pour un SLM on-premise dans une banque régulée et un modèle frontier traitant des workflows entreprise complexes.

---

Six questions pour auditer la santé de votre contexte.

• Ratio d’injection : quelle proportion de votre system prompt est injectée à chaque appel vs conditionnellement ? Surtout systématique : risque de bloat.
• Utilisation des tools : quelle part de vos tools enregistrés est réellement appelée ? Sous 40 % : c’est du tool sprawl.
• Âge des instructions : quand avez-vous revu chaque bloc pour la dernière fois ? Tout ce qui n’a pas bougé depuis plus de 90 jours contient probablement de la redondance ou des contradictions.
• Cadence de retrait : quand avez-vous retiré quelque chose pour la dernière fois ? Une équipe qui n’ajoute qu’accumule par définition.
• Propriété des capabilities : si l’API d’un tool change, combien de définitions d’agents faut-il mettre à jour ? Au-delà de trois, vous avez un problème de gouvernance.
• Observabilité du contexte : pouvez-vous voir le payload exact envoyé à chaque appel en production ? Sinon, vous ne pouvez ni auditer, ni optimiser, ni gouverner.

Un rôle d’agent bien cadré devrait transporter 2 000 à 3 500 tokens de contexte système pour une tâche focalisée. Sur les agents que nous avons audités avant migration, la médiane était à 7 800 tokens.

---

Le context bloat est le symptôme d’un contexte traité comme un fichier de configuration. Le context load, c’est ce qui se passe quand vous le traitez comme de l’ingénierie.