Le mur du contexte : Pourquoi les 128k d'OpenFox ont capitulé face au million de tokens

Publié par · septembre 29, 2026 · Calcul du temps...
Le mur du contexte : Pourquoi les 128k d'OpenFox ont capitulé face au million de tokens

Autopsie d'un crash opérationnel survenu en pleine session de développement : comment une fenêtre de contexte saturée transforme un agent brillant en saboteur amnésique, et pourquoi le million de tokens change radicalement la donne.


1. L'ILLUSION DU CONTEXTE « SUFFISANT »

Dans la documentation des modèles d'intelligence artificielle, afficher une fenêtre de contexte de 128 000 tokens (l'équivalent de près de 300 pages de texte) semble être une promesse de confort absolu. On se dit : « C'est largement suffisant pour n'importe quelle tâche de programmation ».

C'est vrai pour un script isolé de 200 lignes.

C'est rigoureusement faux dès lors que vous orchestrez une constellation de 15 dépôts interconnectés, avec des règles de gouvernance strictes, des contrats d'APIs croisés, des historiques d'incidents et des dépendances d'outils.

Le 29 septembre, lors d'une session de refonte intensive de notre outillage, nous avons fait l'expérience cuisante de cette limite physique avec l'agent OpenFox (consigné dans l'Issue JARVIS-WorkFlow#556).

Ce qui devait être une simple mise à jour de synchronisation s'est transformé en un naufrage technique édifiant.


2. L'INCIDENT DU 29 SEPTEMBRE : QUAND L'AGENT DEVIENT AVEUGLE

Le scénario de l'incident est un cas d'école de dégradation d'attention contextuelle (l'effet Needle In A Haystack) :

  1. La saturation progressive : Au fur et à mesure que l'agent lisait les fichiers de configuration, les dépendances des 20 serveurs d'outils et l'historique des commits récents, la jauge des 128k tokens a été atteinte.
  2. L'amnésie des consignes initiales : Pour faire de la place aux nouveaux fragments de code, le mécanisme d'attention du modèle a mécaniquement « compressé » et oublié les invariants fondamentaux énoncés au tout début de la session.
  3. La panique probabiliste : Ne trouvant plus le fil de sa logique, l'agent s'est mis à halluciner des conflits imaginaires, à tenter de réécrire des bibliothèques entières qu'il avait lui-même importées dix minutes plus tôt, et a fini par tourner dans une boucle infinie de modifications destructrices.
               LA COURBE D'AMNÉSIE DU MODÈLE À 128K
               ───────────────────────────────────
   Précision Sémantique
      100% ────┐
               │  (Zone de Confort : Scripts Isolés)
       75%     └────────┐
                        │  (Flotte Multi-Dépôts : Saturation)
       25%              └──────────────┐
                                       │  (Amnésie Totale : Hallucinations & Boucles)
        0% ────────────────────────────┴─────────────────▶
              0k             64k             128k (Tokens Ingérés)

En moins d'une heure, l'agent avait généré un état de confusion tel que nous avons dû prononcer son bannissement immédiat et définitif des tâches de développement de la flotte (Issue #556 : « OpenFox banni — le développement y est impossible »).

🚨 LA PERTE D'ATTENTION : LE PIÈGE SILENCIEUX

Un LLM dont le contexte est saturé ne s'arrête pas en disant « Je ne me souviens plus ». Il continue de générer du code avec un aplomb imperturbable, mais en inventant des fonctions inexistantes et en détruisant silencieusement les pans de code qu'il n'a plus en mémoire vive.


3. LE SAUT QUANTIQUE DU MILLION DE TOKENS (GEMINI & ANTIGRAVITY)

La bascule vers des modèles dotés d'une fenêtre de 1 à 2 millions de tokens (tels que la famille Gemini 1.5 sous l'environnement Antigravity) n'est pas une simple amélioration quantitative : c'est un changement de nature opérationnelle.

Avec un million de tokens exploitables :

  • L'agent peut ingérer l'intégralité du code source des 15 dépôts, la documentation pérenne, et l'ensemble des règles de gouvernance en une seule passe.
  • Il conserve une vue panoramique des interactions sans jamais sacrifier la consigne de départ.
  • Les dépendances cachées et les effets de bord d'un commit sont détectés avant même la première ligne de code rédigée.

Ce qui relevait du numéro d'équilibriste permanent sous 128k devient une promenade d'ingénierie fluide et déterministe.


4. LA DOCTRINE DU NAVIGATEUR OBSERVABLE : FIN DU TRAVAIL SOUS-MARIN

L'incident du 29 septembre a révélé une seconde faille tout aussi dangereuse : l'action invisible.

Pour certaines tâches de vérification web, l'agent utilisait un navigateur en mode aveugle (Headless). Ne voyant pas ce que l'agent affichait à l'écran, l'architecte humain ne pouvait pas se rendre compte qu'un script était bloqué sur une page de captcha ou cliquait dans le vide.

Pour vacciner l'ensemble du système, nous avons gravé un nouveau principe de gouvernance : l'interdiction absolue de naviguer hors de la vue de l'humain (Issues #522 et #607).

⚡ LE PRINCIPE DU NAVIGATEUR TRANSPARENT

Chaque action visuelle entreprise par une IA doit être immédiatement observable sur l'écran de l'opérateur. La transparence n'est pas une option esthétique : c'est l'unique rempart contre les actions fantômes et les dérives hors de contrôle.


5. LES LEÇONS DE L'INCIDENT POUR VOS ARCHITECTURES

Si vous concevez des systèmes multi-agents, tirez profit de nos cicatrices :

  1. Ne sous-estimez jamais l'empreinte contextuelle : Dans un workflow agentique, les métadonnées, les logs d'erreurs et les outils consomment 70 % de la fenêtre disponible avant même la première réponse.
  2. Dimensionnez pour le pire cas : Si votre application manipule plus de 50 000 tokens de base documentaire, un modèle à 128k est déjà dans sa zone de danger critique. Optez sans hésiter pour les modèles à fenêtre longue.
  3. Gardez l'œil ouvert : Ne faites jamais confiance à un agent qui affirme avoir « vérifié sur le web » si vous n'avez pas un rendu visuel ou une preuve cryptographique de son passage.
Partager :

Architecte cloud & veille technologique — IA, DevOps, FinOps, Agentic Engineering.