Agents IA en production : pourquoi la couche de contexte change tout

Chez Bridgers, nous concevons et déployons des solutions IA pour nos clients : agents conversationnels, pipelines de traitement de données, automatisations intelligentes. Chaque projet nous confronte à la même question d'architecture : comment gérer la fenêtre de contexte quand un agent enchaîne des dizaines d'appels outils par session ? La sortie d'un grep sur un répertoire peut injecter 8 000 tokens dans le contexte, dont 95% sont du bruit. Multipliez par 30 appels, et vous avez un agent qui paie cher pour être distrait. Context Gateway, le nouveau proxy open source de Compresr (YC W26), attaque ce problème de front. Nous l'avons testé en local sur nos projets internes, et voici notre analyse d'architectes.

Le problème de la saturation de contexte dans les architectures agentiques

Quand nous construisons un agent IA pour un client, la question du contexte n'arrive pas en fin de projet. Elle conditionne l'architecture dès le départ. Un agent qui utilise des outils (lecture de fichiers, appels API, recherches en base) génère un volume de tokens qui croît de manière incontrôlée au fil de la session.

Les trois vecteurs de dégradation

Vecteur 1 : le coût par session. Les fournisseurs de LLM facturent au token d'entrée. Un agent de code comme Claude Code ou Cursor, qui enchaîne des lectures de fichiers et des grep, peut consommer 500 000 tokens en une seule session de debugging. Sur un usage quotidien intensif, la facture mensuelle grimpe rapidement.

Vecteur 2 : la latence d'inférence. L'attention des Transformers a une complexité quadratique en O(n²). Doubler la taille du contexte ne double pas le temps d'inférence, il le quadruple. Pour des agents en production qui doivent répondre en temps réel, c'est un mur.

Vecteur 3 : la dégradation de la précision. C'est le point le moins intuitif mais le plus documenté. Les évaluations de GPT-5.4 citées par Compresr montrent une précision passant de 97,2% à 32K tokens à 36,6% à 1M tokens. Claude Opus 4.6 affiche 91,9% de récupération needle-in-a-haystack à 256K, mais tombe à 78,3% à 1M selon AIMultiple. Sonnet 4.6 passe de 90,6% à 256K à 65,1% à 1M.

La conclusion est contre-intuitive : envoyer plus de contexte au modèle dégrade ses performances. L'information pertinente se noie dans le bruit, et le modèle perd en capacité de récupération.

L'impact concret sur un déploiement client

Prenons un cas typique que nous rencontrons chez Bridgers. Un client nous demande de construire un agent de support technique qui interroge une base documentaire de 50 000 pages. Le pipeline RAG récupère les chunks pertinents, mais chaque chunk fait 2 000 tokens, et le retriever en renvoie 10 par requête. À 20 000 tokens de contexte RAG par appel, plus le prompt système et l'historique, la fenêtre sature avant la dixième itération.

Sans gestion intelligente du contexte, deux options : tronquer brutalement (et perdre de l'information) ou payer le plein tarif (et accepter la dégradation de précision). Aucune n'est satisfaisante.

Architecture de Context Gateway : le proxy transparent en Go

Le flux de traitement

``` [Agent : Claude Code / Cursor / OpenClaw / Codex]

|

| Requête HTTP (sortie outil dans le body) v [Context Gateway Proxy, binaire Go local]

1. Interception de la requête sortante

2. Extraction de la sortie outil du payload

3. Exécution du classificateur SLM Compresr (conditionné par l'intention)

4. Remplacement de la sortie par sa version compressée

5. Stockage de l'original dans le session store local

|

| Requête HTTP modifiée (payload compressé) v [API LLM : Anthropic / OpenAI / etc.]

Thread d'arrière-plan :

• Monitoring de l'utilisation de la fenêtre de contexte

• À 85% de capacité : résumé de l'historique de conversation

• Stockage du résumé, swap au prochain tour

• Log dans logs/history_compaction.jsonl

```

La compression par classificateur SLM : pas du résumé

La distinction architecturale clé : Compresr n'utilise pas de résumérisation. Leurs small language models (SLM) fonctionnent comme des classificateurs binaires au niveau du token. Pour chaque token de la sortie d'outil, le SLM décide : pertinent ou non pertinent, en fonction de l'intention de l'appel.

Cette approche a trois propriétés architecturales importantes :

Conservation de la structure. Puisqu'il n'y a pas de génération de texte, la structure de la sortie originale (indentation, noms de variables, chemins de fichiers, messages d'erreur) est préservée. Un résumé perdrait cette structure.

Conditionnement par l'intention. La compression n'est pas uniforme. Si l'agent a appelé grep pour chercher des patterns d'authentification, le SLM conserve les lignes qui matchent ce pattern et élimine les résultats non pertinents. Le même fichier sera compressé différemment selon la requête.

Overhead minimal. Un classificateur est fondamentalement moins coûteux qu'un générateur autoregressif. Pas de beam search, pas de sampling, pas de tokens générés un par un. La compression ajoute quelques millisecondes, pas des secondes.

Les trois modèles de compression

Compresr expose trois modèles via son API, chacun adapté à un pattern architectural différent :

Pour les architectes qui conçoivent des pipelines RAG, coldbrew_v1 en première passe puis latte_v1 sur les chunks retenus est une combinaison intéressante qui allie efficacité et précision.

expand() : la récupération à la demande

Le proxy stocke toutes les sorties d'outils originales dans un session store local. Si le LLM réalise qu'il a besoin d'une information qui a été compressée, il appelle expand() pour récupérer la version complète.

C'est l'équivalent d'un mécanisme de cache avec lazy loading : la version compressée est la représentation par défaut, et la version complète est chargée à la demande. L'architecture suppose que le modèle est capable de détecter quand il manque d'information, ce qui est une hypothèse raisonnable mais pas garantie dans des chaînes agentiques profondes.

Gestion de session et observabilité

Au-delà de la compression, Context Gateway apporte des fonctionnalités d'opérations que les outils natifs n'offrent pas :

• Compaction d'historique en arrière-plan : à 85% de capacité, sans bloquer la session (contrairement au /compact natif de Claude Code qui bloque pendant environ 3 minutes)

• Dashboard web : suivi des sessions en cours et passées (le frontend TypeScript représente 6,5% du codebase)

• Plafonds de dépenses : limites de tokens configurables par session, essentiels pour des agents en production où un agent qui s'emballe peut générer des factures imprévues

• Notifications Slack : alertes quand l'agent attend un input utilisateur

• Logs auditables : tous les événements de compaction enregistrés dans logs/history_compaction.jsonl

• Support Docker : Dockerfile inclus pour un déploiement conteneurisé

Pour une agence comme Bridgers qui gère des agents pour des clients, les plafonds de dépenses et le monitoring sont des fonctionnalités non négociables.

Performance : ce que disent les chiffres (et ce qu'ils ne disent pas)

Les métriques annoncées par Compresr doivent être lues avec discernement.

Notre lecture d'architecte. Le ratio par défaut de 0,5 (50% de réduction) est le chiffre à retenir pour le dimensionnement. Le 200x est un cas extrême sur un workload RAG très ciblé. Le benchmark FinanceBench (141 questions sur 79 documents SEC jusqu'à 230K tokens) est intéressant mais utilise une référence à « GPT-5.2 » qui ne correspond pas à la nomenclature OpenAI connue, comme l'a noté l'analyse du YC Tier List, ce qui « mine la crédibilité ».

Pour un déploiement client, nous recommandons de tabler sur 40 à 60% de réduction de tokens, pas sur les chiffres marketing. C'est déjà un gain significatif.

L'équipe Compresr : le pedigree académique qui compte

Le CEO et le CTO ont des publications dans des conférences de premier plan (EMNLP, NeurIPS) sur exactement le sujet de leur startup. C'est un signal fort pour des architectes qui évaluent la solidité technique d'un outil. Le dépôt GitHub affiche 412 étoiles, 34 forks, et 12 releases en 5 semaines, un rythme de développement indicatif d'une équipe engagée.

Comparatif technique : Context Gateway, LLMLingua, Google ADK

Pour un architecte qui doit choisir une stratégie de gestion de contexte, voici le comparatif des approches disponibles.

Proxy vs. framework natif vs. bibliothèque de recherche

Les concurrents émergents

The Token Company (YC W26) travaille sur un modèle ML qui compresse les inputs LLM avant qu'ils n'atteignent le modèle. Également YC W26, mais focalisé sur la compression de prompts en général plutôt que sur une architecture proxy.

Le papier Sentinel (arXiv 2026) propose un sondage d'attention pour la compression de contexte, atteignant 5x de compression sur LongBench avec un modèle proxy de 0,5B paramètres. Pas de release production, mais un indicateur que le front de recherche avance vite.

Le risque de commoditisation

Le scepticisme exprimé sur Hacker News (85 points, 49 commentaires) est légitime d'un point de vue architectural. L'analyse du YC Tier List résume le risque : « Microsoft Research livre déjà LLMLingua, et n'importe quel fournisseur de LLM majeur peut internaliser la compression nativement, transformant cela en fonctionnalité plutôt qu'en entreprise. »

Le commentateur @verdverm sur HN a noté que Google ADK gère déjà la compaction avec un simple flag compaction_interval. @kuboble a prédit que Claude Code résoudrait le problème lui-même en quelques mois.

C'est un risque réel. Mais c'est aussi un argument pour la valeur à court terme : tant que les solutions natives restent grossières (le /compact de Claude bloque pendant 3 minutes), un proxy transparent a sa place.

Intégrer Context Gateway dans une architecture existante

Scénario 1 : agent de développement (Claude Code / Cursor)

L'intégration la plus simple. Installation en une commande :

``bash curl -fsSL https://compresr.ai/api/install | sh context-gateway ``

Le wizard TUI configure l'agent, le modèle de résumé, le seuil de compression, et le webhook Slack optionnel. Le proxy tourne en local et intercepte les requêtes de manière transparente.

Scénario 2 : pipeline RAG en production

Pour un pipeline RAG, le SDK Python (pip install compresr) est plus adapté que le proxy. Vous intégrez la compression directement dans votre code :

• coldbrew_v1 en première passe pour filtrer les chunks non pertinents

• latte_v1 en seconde passe pour compresser les chunks retenus au niveau token

Scénario 3 : agent personnalisé avec outils custom

Le mode custom du proxy permet de configurer n'importe quel agent qui communique avec une API compatible OpenAI. Le proxy est agnostique au modèle : il fonctionne avec Anthropic, OpenAI, ou tout endpoint compatible.

Les limites architecturales à anticiper

Après avoir testé Context Gateway sur nos projets internes chez Bridgers, voici les limites que nous avons identifiées et que tout architecte doit anticiper.

L'invalidation du cache de prompts. Si vous utilisez Claude avec le prompt caching, chaque compaction modifie le préfixe du contexte. Le cache est invalidé, et vous payez le plein tarif pour l'historique complet. Sur des workflows qui dépendent fortement du caching, cela peut annuler les économies de la compression. C'est un point technique critique soulevé sur Hacker News.

Le ratio fixe ne s'adapte pas au contenu. Le ratio de 0,5 s'applique uniformément. Un bloc de JSON structuré et un log verbeux de 500 lignes reçoivent le même traitement. L'équipe travaille sur un traitement différentiel structuré/non structuré, mais ce n'est pas encore disponible.

La fiabilité de expand() dans les chaînes profondes. Le mécanisme expand() suppose que le modèle détecte quand il manque d'information. Dans une chaîne agentique avec 15 appels outils successifs, cette hypothèse est fragile. Un token supprimé au tour 3 peut manquer au tour 12 sans que le modèle ne le réalise.

La surface de sécurité. Le proxy gère toutes les clés API et tout le trafic réseau de l'agent. La version 0.4.4 a introduit le renforcement de la sécurité et le support OAuth, ce qui implique que les versions antérieures avaient des lacunes. Pour un déploiement client, un audit de sécurité est indispensable.

L'early-stage du produit. Quatre fondateurs, 52 commits, version 0.5.2 en date du 12 mars 2026. Le produit fonctionne, mais le hardening enterprise est en cours. Il est trop tôt pour le recommander à des clients qui exigent un SLA.

L'absence de benchmarks indépendants. Les chiffres de performance viennent exclusivement de Compresr. Aucun benchmark tiers ne valide les claims. La référence à « GPT-5.2 » dans les benchmarks du site reste inexpliquée.

Qui devrait considérer Context Gateway ?

Pour vos projets si :

• Vous construisez des agents qui consomment beaucoup de tokens via des outils et votre facture LLM est un poste de coût significatif.

• Vous avez besoin de monitoring et de plafonds de dépenses pour des agents en production, et les outils natifs ne les proposent pas.

• Vous gérez des pipelines RAG avec des documents volumineux et vous voulez optimiser le ratio coût/précision.

• Vous cherchez une alternative à la compaction bloquante de Claude Code pour améliorer l'expérience développeur.

Il est prématuré si :

• Votre usage agent est léger et le coût tokens est négligeable.

• Vous opérez dans l'écosystème Google ADK, qui propose déjà une compaction native.

• La sécurité et la conformité exigent un audit complet avant tout intermédiaire réseau, et le produit n'a pas encore la maturité pour le passer.

• Vous préférez attendre que les fournisseurs LLM intègrent nativement une gestion de contexte performante.

Perspective d'agence : la gestion de contexte comme couche d'infrastructure

Chez Bridgers, nous observons un changement de paradigme dans l'architecture des agents IA. La gestion du contexte passe de « détail d'implémentation » à « couche d'infrastructure ». Les signaux sont clairs : Google ADK ajoute la compaction comme flag natif, Kubernetes forme un groupe de travail AI Gateway, et plusieurs startups YC W26 construisent des produits dédiés à cette couche.

Context Gateway est l'un des premiers outils open source à proposer une solution opérationnelle à ce problème. Avec 412 étoiles GitHub, 12 releases en 5 semaines, et une équipe de chercheurs publiés à EMNLP et NeurIPS, c'est un outil sérieux qui mérite d'être évalué par toute équipe qui construit des agents IA en production.

La question stratégique reste ouverte : cette couche de compression deviendra-t-elle un produit autonome ou une fonctionnalité native des fournisseurs ? La réponse déterminera la viabilité à long terme de Compresr. En attendant, pour les architectes qui font face au problème aujourd'hui, Context Gateway offre une solution concrète, testable, et open source.