Le contexte est fini. Programmons en conséquence.

L'inventaire des techniques qui peuplent la fenêtre, les phénomènes qui la dégradent, les heuristiques pour la maîtriser. Et au passage, l'anti-pattern le plus coûteux qu'on rencontre dans les agents en production.

Prérequis. Cet article suppose que vous savez ce qu'est un token, comment fonctionne grossièrement un transformateur, et pourquoi le modèle reçoit l'historique entier à chaque tour. Si ces notions ne sont pas déjà en place, l'article compagnon « Que se passe-t-il, vraiment, quand vous parlez à une IA ? » pose le décor en quinze minutes.

§ 01 — Inventaire

Tout ce qu'on a inventé pour domestiquer un prédicteur de jetons.

Un transformateur seul ne fait qu'une chose : prédire le prochain jeton à partir de ce qu'il a sous les yeux. Pour le rendre utile en production — qu'il réponde, qu'il se souvienne, qu'il agisse, qu'il tienne dans le temps — on a inventé une douzaine de techniques. Chacune répond à un manque précis. Chacune habite la fenêtre de contexte d'une manière ou d'une autre. Voici l'inventaire, du point de vue de ce que ça coûte et de ce que ça débloque.

Cadrer le comportement · le system prompt

Le texte d'instructions placé en tête de chaque requête. Définit rôle, ton, règles, garde-fous, format de sortie, parfois exemples. C'est ce qui transforme un prédicteur de texte en assistant. Coût : permanent et payé à chaque tour. Souvent 5 000 à 25 000 jetons pour un produit grand public, plus pour un agent avec beaucoup d'outils.

Personnaliser sans dupliquer · les préférences utilisateur

Un petit bloc supplémentaire propre à l'utilisateur, injecté avant la conversation — langue, ton, expertise, projets en cours. Coût : faible en jetons mais à haute priorité, ces lignes pèsent lourd dans la prédiction.

Donner des capacités · les outils et le MCP

Un modèle ne peut ni lire un fichier, ni interroger une base, ni envoyer un courriel — il ne fait que produire du texte. La solution : déclarer des outils qu'il invoque en écrivant un appel structuré (function calling, tool use), que l'application exécute pour lui. Le Model Context Protocol (MCP) standardise la déclaration et l'exposition d'outils, permettant de brancher des serveurs tiers (Asana, Gmail, GitLab, bases internes…) sans réécrire le pipeline. Coût : chaque outil déclaré occupe la fenêtre — schéma JSON, description, paramètres — même quand il n'est jamais appelé. Brancher dix serveurs MCP, c'est dix fois la facture.

Enseigner des procédures · les skills

Des fichiers SKILL.md contenant des recettes procédurales injectées seulement quand un déclencheur correspond. Au lieu de gonfler le system prompt avec toutes les recettes possibles, on les stocke à part et on charge à la demande. Coût : nul tant qu'ils ne sont pas activés ; modéré quand ils le sont. Le piège majeur — un skill mal conçu peut faire entrer dans la fenêtre des données qu'il aurait dû traiter à part. C'est l'objet du § 04.

Garder le fil · l'historique de conversation

Le modèle est sans état. Pour qu'une conversation paraisse continue, l'application reconstitue l'historique entier à chaque tour. Coût : linéaire dans le nombre d'échanges. Au tour 40, on repaie 40 fois le même prix.

Compresser ce qui est ancien · la summarization automatique

Quand on s'approche de la limite, l'application remplace les tours anciens par un résumé condensé produit par le modèle lui-même. Coût : la compression est irréversible — un détail effacé ne revient pas.

Persister entre les conversations · la mémoire

Un magasin distinct de l'historique, qui contient des faits durables (préférences, projets, contexte professionnel) ré-injectés en fenêtre quand pertinent. Coût : faible en jetons, mais demande une discipline — quoi mémoriser, quoi oublier, quoi proposer.

Récupérer plutôt que tout charger · le RAG

Un corpus documentaire (centaines de docs, milliers de pages) ne tient pas dans la fenêtre. Le Retrieval-Augmented Generation indexe le corpus à part, et au moment d'une requête, ne récupère que les passages pertinents pour injection. L'évolution récente — le RAG agentique — laisse l'agent décider quand et quoi récupérer plutôt que d'imposer une étape pré-LLM figée. Coût : infrastructure d'indexation à part, et la qualité de la réponse dépend de la qualité de la récupération.

Réduire le coût des préfixes stables · le prompt caching

Chaque requête recalcule le system prompt et les définitions d'outils — même quand rien n'a changé. Les fournisseurs mettent désormais en cache le calcul d'attention (KV cache) pour les portions stables. Lors des requêtes suivantes, ces jetons coûtent une fraction de leur prix normal et la latence chute. Coût : aucun en jetons — c'est une optimisation pure — mais demande de garder le préfixe identique d'une requête à l'autre, à l'octet près.

Isoler le bruit · les sous-agents

Certaines tâches exigent de lire de gros volumes (web, fichiers, recherches multiples) qui satureraient la fenêtre du parent. Déléguer à un sous-agent qui a sa propre fenêtre, traite le bruit chez lui, et ne renvoie qu'une synthèse compacte. Permet aussi de paralléliser. Coût : chaque sous-agent paie son propre system prompt et ses propres outils ; la compression du résumé reste irréversible. Voir § 06.

Compacter le contexte · l'opération de fond

Au fil d'une longue session agentique — outils appelés, fichiers lus, sous-agents invoqués — la fenêtre se remplit de matériel qui n'est plus pertinent. La compaction élague ou résume les portions périphériques pour libérer de l'espace. C'est l'idée plus générale dont la summarization n'est qu'une instance. Coût : comme toute compression, on perd quelque chose. Le challenge est de perdre la bonne chose.

L'allocation typique

Fig. 1Allocation typique d'un agent en production

Toutes les techniques laissent une empreinte ici. Aucune n'est gratuite.

§ 02 — Phénomènes

Six choses qui se passent dans la fenêtre, et qu'on ne contrôle pas vraiment.

Les solutions précédentes sont des leviers qu'on actionne. Il existe aussi des phénomènes qu'on subit — propriétés du modèle, propriétés de l'attention, propriétés des données — et qu'il faut intégrer comme contraintes. Ces six-là reviennent dans presque tous les agents en production. Avoir un nom pour les désigner est la première étape pour les traiter.

Lost in the middle — l'oubli au milieu

L'attention du modèle n'est pas uniforme sur la fenêtre. Le début et la fin sont privilégiés ; le milieu est sous-exploité. C'est un effet d'architecture documenté empiriquement (papier Lost in the Middle, Liu et al., 2023), atténué sur les modèles récents mais pas disparu.

→ SIGNAL · l'agent ignore une instruction que vous savez présente, mais enfouie au milieu d'un long contexte. Remontez-la en début ou en fin.

Context rot — la pourriture progressive

Plus la fenêtre se remplit, plus la qualité de raisonnement tend à baisser, même bien en-deçà de la limite théorique. Un agent à 150 000 jetons n'est pas équivalent au même agent à 30 000. La compaction n'est donc pas qu'une question d'espace — c'est aussi une question de performance.

→ SIGNAL · les premières actions de votre agent sont précises, les dernières dérivent. Compactez à 50-60 % de remplissage, pas à 95 %.

Attention dilution — la dilution sous bruit

Cas particulier du context rot : même si le modèle a la capacité théorique de tout regarder, ajouter du contenu non pertinent réduit l'importance relative du contenu pertinent. Le bruit ne fait pas que coûter des jetons — il dilue les signaux.

→ SIGNAL · ajouter de la documentation « au cas où » dégrade les performances au lieu de les améliorer. Coupez l'inutile, ne le chargez jamais « par précaution ».

Tool soup — la soupe d'outils

Au-delà d'une certaine quantité d'outils déclarés (en pratique, autour de quinze à vingt selon les modèles), l'agent commence à choisir mal — outils proches confondus, outils manquants ignorés, outils complexes mal paramétrés. Plus c'est gros, plus c'est lent et plus c'est faux.

→ SIGNAL · l'agent invoque le mauvais outil, ou en oublie un dont vous savez qu'il était disponible. Activez les outils par phase, pas tous en permanence.

Runaway agent — l'agent en fuite

Sans plafond explicite, un agent peut entrer dans une boucle où chaque appel d'outil produit un résultat qui justifie un autre appel. La fenêtre enfle, la qualité chute, et la facture grimpe en silence. Particulièrement fréquent quand l'agent cherche, ne trouve pas, et reformule.

→ SIGNAL · une session « simple » consomme dix fois plus de jetons que prévu. Imposez un plafond d'appels d'outils, des points de contrôle, et des seuils de remplissage qui déclenchent une compaction ou un arrêt.

Prompt injection — l'injection d'instructions

Tout contenu externe — page web, e-mail, fichier, résultat d'outil — peut contenir des instructions cachées qui détournent l'agent. Le modèle ne distingue pas naturellement données et ordres. Plus l'agent a d'outils puissants, plus le risque est sérieux. Hygiène mentale obligatoire : traiter les contenus tiers comme potentiellement hostiles.

→ SIGNAL · l'agent fait quelque chose que vous n'avez pas demandé après avoir lu un contenu externe. Marquez les contenus tiers, restreignez les outils utilisables après lecture, validez humainement les actions irréversibles.

§ 03 — Heuristiques

Onze principes pour arbitrer les appétits concurrents.

Connaître les solutions et les phénomènes ne suffit pas : il faut savoir les composer. Voici les heuristiques que j'utilise et que je vois utilisées dans les agents en production. Aucune n'est révolutionnaire prise isolément ; leur valeur tient à la discipline de les appliquer ensemble. Pour chacune, un signal d'alarme qui déclenche son application, et un cas où elle ne s'applique pas.

Mesurer avant d'optimiser

Avant de chercher à compresser ou reformuler, savoir combien chaque artefact pèse réellement. Toutes les API modernes exposent un compte de jetons par message. Compter d'abord, cibler le plus gros poste, puis seulement optimiser.

Signal Vous « sentez » que l'agent rame mais vous ne savez pas où. Ouvrez les logs, comptez les jetons par catégorie (system, tools, history, results).

Sauf si Prototype rapide pour valider une idée. Ne pas optimiser ce qui n'est pas encore stable.

Précision plutôt qu'exhaustivité dans le system prompt

Le réflexe est de bourrer le system prompt d'exemples « au cas où ». Un system prompt long fatigue le modèle (cf. context rot) et augmente le coût de chaque requête. Mieux vaut un cadre resserré et déléguer les détails à des skills chargés à la demande.

Signal System prompt > 30k jetons, ou contenant des sections jamais déclenchées, ou réécrites tous les sprints.

Sauf si Le contexte métier est tellement spécialisé qu'aucun skill ne peut le remplacer (réglementation stricte, ton de marque non-négociable).

Ne brancher que les outils nécessaires

Chaque outil déclaré occupe la fenêtre même quand il n'est jamais utilisé. Brancher dix serveurs MCP « pour le futur », c'est dépenser des milliers de jetons en permanence et nourrir la tool soup. Activer les outils par profil de tâche ou par phase produit des agents nettement plus performants.

Signal Plus de quinze outils déclarés, ou agent qui hésite entre deux outils proches.

Sauf si Vous mesurez et vous savez qu'aucun outil n'est superflu. Dans ce cas, documentez la raison de chacun.

Ne jamais charger un fichier brut quand on peut le traiter par code

C'est le principe le plus important — il fait l'objet du § 04. Demander au modèle de « regarder » un CSV de 100 000 lignes ou un PDF de cinquante pages, c'est la cause la plus fréquente de saturation. Donner au modèle le moyen d'écrire du code qui opère sur les données et de ne ramener que le résultat est le pivot fondamental.

Signal Un seul appel d'outil ramène plus de 5 000 jetons en contexte.

Sauf si Le fichier est petit (< 2k jetons) et le modèle doit en saisir la totalité (relecture nuancée d'un texte court, par exemple).

Placer l'essentiel aux extrémités

Compte tenu de l'effet lost in the middle, les instructions critiques vont en début ou en fin de la fenêtre. La règle métier qu'on ne veut pas voir ignorée ? En fin de system prompt. La consigne immédiate la plus importante ? Dans le dernier message utilisateur.

Signal Une instruction documentée n'est pas suivie. Avant d'en déduire que « le modèle est nul », vérifier sa position dans la fenêtre.

Sauf si Vous avez peu de contenu et tout tient dans un horizon court. La règle n'apparaît qu'au-delà de quelques milliers de jetons.

Stabiliser le préfixe pour activer le KV cache

Le prompt caching ne fonctionne que si la portion en tête est identique d'une requête à l'autre, à l'octet près. Mettre la date du jour ou un identifiant de session au tout début, c'est invalider le cache à chaque tour. Garder le préfixe immuable et placer les éléments variables plus loin est une optimisation gratuite — souvent 80-90 % de réduction sur le coût des prefixes stables, et latence divisée par deux ou trois.

Signal Vos appels Anthropic / OpenAI ne montrent pas de cache hit alors que le system prompt est « identique ».

Sauf si Vos requêtes sont rares ou irrégulières — le cache a une durée de vie limitée (5 min chez Anthropic par défaut).

Compacter tôt, pas en panique

Attendre que la fenêtre soit pleine pour compacter, c'est compacter dans l'urgence — donc mal. Les agents bien construits déclenchent la compaction par seuil (60 % de remplissage est un bon point de départ), avec une stratégie réfléchie : quoi résumer, quoi élaguer, quoi garder verbatim.

Signal La compaction s'enclenche à 95 %, ou pire, n'existe pas et les sessions longues plantent.

Sauf si Vous êtes dans une session courte par construction (single-turn, ou plafond d'appels imposé).

Déléguer aux sous-agents le travail bruyant

Toute tâche qui implique de lire beaucoup pour produire peu — exploration web, lecture de fichiers volumineux, recherches multi-sources — est candidate naturelle pour un sous-agent. Le parent garde sa fenêtre légère ; le sous-agent absorbe le bruit dans la sienne et ne renvoie qu'une synthèse.

Signal Le contexte de l'agent principal est rempli à 70 % par des résultats de recherche ou des contenus bruts.

Sauf si La tâche exige que le parent voie le détail (audit, traçabilité, raisonnement multi-étapes sur des éléments précis).

Traiter tout contenu externe comme hostile

Une page web, un courriel, un résultat d'outil sont des données — et peuvent contenir des instructions cachées (cf. prompt injection). Pour les agents avec outils sensibles (envoi d'emails, accès systèmes internes, exécution de code), c'est non-négociable. Marquer les contenus tiers, restreindre les outils utilisables après lecture, valider humainement les actions irréversibles — disciplines, pas options.

Signal Votre agent a accès à du courriel, à un browser, ou à des données externes ET peut exécuter des actions à effet de bord.

Sauf si L'agent est purement read-only et n'a aucun outil à effet de bord. Le risque devient théorique.

Mémoriser ce qui dure, pas ce qui passe

La mémoire persistante est précieuse mais piégeuse. On y met des faits durables (préférences, projets en cours, contexte professionnel), pas des micro-détails d'une conversation. Règle utile : si l'information n'est pas pertinente dans au moins trois conversations futures, elle n'a rien à faire en mémoire.

Signal La mémoire contient « l'utilisateur a dit X mardi » pour des X qui ne reviendront jamais. Ou pire, des contradictions accumulées.

Sauf si C'est explicitement un agent de prise de notes ou de journal personnel — la rétention granulaire est alors la fonctionnalité.

Itérer avec des évals, pas à l'œil

L'optimisation de contexte ressemble au tuning de performance : on a souvent tort en jugeant à l'intuition. Construire quelques tests reproductibles — voici une question, voici la réponse attendue — et mesurer l'impact de chaque changement empêche les régressions silencieuses. Ajouter un outil ou un skill sans mesurer dégrade étonnamment vite.

Signal Vous ajoutez une fonctionnalité et un autre comportement, sans lien apparent, devient instable.

Sauf si Vous êtes en exploration pure et la performance n'est pas encore un critère. Une fois en production, plus d'excuses.

§ 04 — L'anti-pattern

Skills qui lisent vs skills qui exécutent.

C'est la distinction la plus mal comprise de l'ingénierie d'agent. Un skill, ce n'est pas un endroit où on dépose des données pour que le modèle les contemple : c'est un mode d'emploi pour les opérer hors contexte. C'est aussi l'optimisation qui produit les gains les plus spectaculaires — souvent deux ordres de grandeur sur la consommation de jetons.

↯ Anti-pattern

Le skill qui lit

Charge le fichier brut dans la fenêtre, demande au modèle de tout regarder puis de tout résumer. Coûteux, lent, fragile, plafonné par la taille du fichier, et soumis au context rot.

✓ Bon pattern

Le skill qui exécute

Apprend au modèle à écrire du code qui opère sur les données — analyse, filtre, agrège, valide. Seul le résultat compact revient en contexte. Le code voit les octets, le modèle voit l'agrégat.

Le coût réel, en chiffres

Cas concret : « Combien de transactions de plus de 1 000 $ y a-t-il dans ce CSV de 100 000 lignes ? » Le fichier fait environ 8 Mo de texte, soit grossièrement 2 millions de jetons. Comparons les deux trajectoires :

A · Le skill qui lit (anti-pattern)

postejetons

→ Tentative de chargement intégral2 000 000

→ Limite de fenêtre dépassée (200k)échec

→ Stratégie de repli : chunking + résumés~180 000

→ Résultat : approximation, pas de comptage exactimprécis

TOTAL · 1 réponse approximative~180 000 tk

B · Le skill qui exécute (bon pattern)

postejetons

→ Skill chargé en contexte~400

→ Modèle écrit un script Python~200

→ Script lit le CSV hors contexte (pandas)0

→ Sortie du script en contexte : "47 322"~5

TOTAL · 1 réponse exacte~605 tk

Rapport ~300×. Et au passage : la réponse B est exacte alors que la A est nécessairement approximative. Le bon pattern est plus rapide, moins cher, et plus précis. Ce n'est pas un compromis — c'est juste une meilleure architecture.

Fig. 2Deux trajectoires de données

Le skill bien conçu garde les données sur disque et ne ramène que le calcul.

Cette idée — code execution as context compression — est le pattern le plus rentable de l'ingénierie d'agent contemporaine. Quand vous concevez un skill, demandez-vous toujours : est-ce que le modèle a besoin de voir les données, ou seulement le résultat de leur traitement ? La réponse est presque toujours « le résultat ».

§ 05 — Audit

Comment mesurer ce qui se passe vraiment dans votre fenêtre.

Tout le reste de cet article suppose que vous savez ce que votre agent consomme. La plupart des équipes que je rencontre n'en ont qu'une intuition. L'audit n'est pas compliqué ; il demande juste qu'on s'y mette une fois et qu'on instrumente proprement.

Les quatre métriques de base

Pour chaque appel au modèle, journalisez quatre nombres. Jetons d'entrée totaux — la taille complète envoyée au modèle. Jetons de sortie — ce que le modèle a généré. Jetons mis en cache (cache hit) — ce qui a coûté la fraction. Jetons facturés au plein tarif — la différence. Toutes les API sérieuses (Anthropic, OpenAI, Google) exposent ces compteurs dans la réponse ; il faut les capturer et les agréger.

La répartition par catégorie

Une fois les totaux connus, ventilez l'entrée. Combien pour le system prompt ? Combien pour les définitions d'outils ? Combien pour l'historique ? Combien pour les résultats d'outils de la session courante ? Combien pour les skills chargés ? La majorité des agents en production découvre à ce stade que les résultats d'outils dévorent 40-60 % de la fenêtre et que personne ne le savait. C'est typiquement là qu'il faut tirer.

Les indicateurs de santé

Trois indicateurs valent la peine d'être suivis dans le temps. Le taux de cache hit — sous 70 %, votre préfixe n'est pas stable. Le remplissage moyen de la fenêtre en fin de session — au-dessus de 70 %, vous êtes en zone de context rot. Le nombre moyen d'appels d'outils par session — s'il dérive vers le haut sans gain de qualité, vous avez un runaway agent en formation.

Outils pratiques

Au minimum, un middleware qui capture les compteurs API et les écrit dans une base ou un fichier de logs structuré. Pour aller plus loin : les fournisseurs offrent des dashboards (Anthropic Console, OpenAI Usage), qui donnent une vue globale mais sans la ventilation par catégorie. Pour Claude Code spécifiquement, la commande /context affiche en temps réel la répartition de la fenêtre courante — c'est la lecture la plus précieuse à apprendre. On y revient au § 07.

§ 06 — Architecture

Sous-agents : des fenêtres isolées.

Quand un parent délègue à un sous-agent, il lui ouvre une fenêtre propre. Le sous-agent absorbe le bruit — lecture brute, recherches, exploration — puis ne renvoie qu'une synthèse compacte. Le parent reçoit un télégramme, pas un fleuve. C'est le pattern qui permet à un agent d'orchestration de traiter des problèmes qui dépassent largement sa propre fenêtre.

Fig. 3Délégation parallèle

Chaque sous-agent ouvre sa propre fenêtre, traite le bruit, renvoie un télégramme.

Avantages

Isolation : un sous-agent qui sature sa propre fenêtre n'affecte pas le parent. Parallélisation : plusieurs sous-agents peuvent travailler simultanément, ce que la fenêtre unique d'un agent monolithique interdit. Spécialisation : chaque sous-agent peut avoir son propre system prompt et ses propres outils, finement adaptés à sa tâche.

Limite

La compression est irréversible. Si le sous-agent omet un détail dans son résumé, le parent n'a aucun moyen de le récupérer — sauf à relancer une délégation, ce qui coûte un nouveau cycle complet. C'est pour cette raison que les sous-agents demandent un soin particulier dans la définition de leur contrat de retour : que doit-il impérativement remonter, même si ça allonge la synthèse ?

§ 07 — Focus pratique

Comment ça se traduit dans Claude Code et compagnie.

Vous utilisez probablement Claude Code, Cursor, Cline, ou un agent maison basé sur l'API Anthropic ou OpenAI. Voici comment les principes précédents se manifestent dans ces outils — et où regarder pour les diagnostiquer.

Lire la fenêtre en temps réel

Dans Claude Code, la commande /context affiche la répartition exacte de votre fenêtre courante : system prompt, outils MCP, skills chargés, historique, résultats d'outils. C'est la lecture la plus utile à apprendre. Lancez-la régulièrement pendant une session longue ; vous identifierez très vite quel poste dévore l'espace. La majorité du temps, c'est les résultats d'outils — typiquement les Read de gros fichiers ou les Bash qui ramènent du JSON volumineux.

La compaction automatique

Claude Code déclenche une compaction automatique quand la fenêtre approche de sa limite. Les anciens tours sont remplacés par un résumé. Vous pouvez aussi la déclencher manuellement avec /compact, en ajoutant des instructions sur ce que la compaction doit préserver (« garde la liste des fichiers que j'ai modifiés, les commandes Bash exécutées et leur résultat »). Compacter tôt et avec des instructions explicites donne presque toujours de meilleurs résultats que laisser l'auto-compaction décider seule au bord du gouffre.

L'arbitrage MCP

Quand vous branchez plusieurs serveurs MCP (GitHub, Linear, base de données, Sentry, etc.), chacun ajoute son lot de définitions d'outils en permanence. Mesurez le coût : /context vous le donne. Si vous voyez 20-30k jetons en outils MCP qui ne servent qu'occasionnellement, envisagez d'activer les serveurs par projet via la configuration plutôt que globalement. C'est un des leviers les plus rentables sur Claude Code.

Les skills, en pratique

Les SKILL.md ne sont pas chargés par défaut : ils sont décrits dans le system prompt sous forme d'index, et l'agent les ouvre via leur outil view quand un déclencheur correspond. Ce design est l'application directe du § 04 : la procédure n'occupe la fenêtre qu'à la demande, et seulement quand elle sert. Quand vous écrivez vos propres skills, suivez le même principe : instructions courtes, références à du code, jamais de données brutes empaquetées dans le markdown.

Le sous-agent Task

Claude Code expose un outil Task qui lance un sous-agent avec son propre contexte. Excellente application du § 06 : déléguez les recherches multi-fichiers, les explorations de gros répertoires, les audits de code à un sous-agent. Vous récupérerez une synthèse au lieu d'inonder votre contexte principal.

Cursor, Cline, Copilot, et les autres

Les principes sont les mêmes, l'instrumentation diffère. Cursor expose moins de visibilité sur la composition de la fenêtre ; il faut souvent passer par les logs API. Cline et les agents open-source basés sur le Model Context Protocol exposent généralement plus de détails. Quel que soit l'outil, la question à se poser reste la même : qu'est-ce qui occupe ma fenêtre, et pourquoi ?

§ 08 — État des lieux

Où on en est, en mai 2026.

Le terrain bouge vite. Cette section est datée pour cette raison : ce qui est vrai au moment de la publication ne le sera peut-être plus dans six mois. Quelques tendances notables que vous pouvez intégrer dans votre raisonnement d'ingénieur.

Les fenêtres standard ont stagné autour de 200k, mais des offres expérimentales à 1M de jetons existent (Claude Sonnet en bêta, Gemini depuis longtemps). Le coût par jeton en mode « long contexte » reste sensiblement plus élevé, et la dégradation à grande fenêtre y est plus marquée — autrement dit, l'option « 1M » est utile pour les cas singuliers (un gros document à traiter d'un coup) mais reste un mauvais réflexe par défaut.

Le KV cache est devenu un acquis universel. Anthropic, OpenAI et Google exposent tous des mécanismes de prompt caching avec des tarifications explicites. Si vous ne les utilisez pas, vous laissez de l'argent sur la table. La discipline du préfixe stable n'est plus une optimisation avancée : c'est l'attendu de base.

Le MCP est devenu le standard de fait pour la déclaration d'outils tiers. L'écosystème compte désormais des centaines de serveurs publics, ce qui est à la fois une chance (capacités énormes accessibles rapidement) et un piège (tentation de la tool soup). Le défi 2026 est moins de brancher que de choisir judicieusement quoi brancher.

Les skills ont quitté la marge. Anthropic les a popularisés en 2025 avec Claude Code ; le pattern s'est diffusé. Les agents qui n'ont pas de système de skills explicite ont tendance à accumuler tout dans le system prompt — c'est-à-dire à payer en permanence ce qu'ils pourraient charger à la demande.

Le pattern « code execution as context compression » — l'idée du § 04 — est devenu un sujet de discussion dans la communauté d'ingénierie d'agent et fait l'objet d'articles techniques d'Anthropic et d'autres. Si vous ne l'avez pas encore appliqué dans votre architecture, c'est probablement la plus haute priorité de votre prochaine itération.

L'évaluation systématique reste sous-pratiquée. C'est la mesure que je vois le moins souvent en place dans les équipes qui construisent des agents ; et c'est paradoxalement celle qui permet d'appliquer toutes les autres avec confiance. Cela bouge — des outils comme Promptfoo, Inspect, et les évals d'Anthropic se diffusent — mais l'écart entre les équipes qui évaluent et celles qui n'évaluent pas reste considérable.

★ Pour aller plus loin

Anthropic · Effective context engineering for AI agents L'article fondateur sur la discipline, par l'équipe applied AI d'Anthropic.
Liu et al. · Lost in the Middle (2023) Le papier qui a documenté empiriquement la non-uniformité de l'attention sur la fenêtre.
Model Context Protocol · spécification Le standard ouvert pour la déclaration et l'exposition d'outils aux agents.
Anthropic · Claude Code documentation La référence pour les commandes /context, /compact, et le système de skills.
Anthropic · Prompt caching Comment activer le KV cache et structurer son préfixe pour en tirer le maximum.
Article compagnon · Que se passe-t-il, vraiment, quand vous parlez à une IA ? Les fondations conceptuelles, pour qui veut partager le sujet à un public moins technique.