Pourquoi le context engineering est comme apprendre à l'IA à faire des ricochets
Fenêtres de contexte d'un million de tokens : le context engineering reste décisif. Sélection, structure, timing, l'art du ricochet appliqué à vos LLM.
INSIGHTS ADSERVIO · GENAI

EN BREF
- La fenêtre de contexte limite la quantité d'information qu'un LLM peut traiter en une seule fois ; même à un million de tokens, un contexte plus grand n'est pas un contexte meilleur.
- Trop d'information dilue l'attention du modèle, augmente coûts et latence, et expose au phénomène du "lost in the middle".
- Le context engineering applique quatre principes façon ricochet : bien choisir l'information, bien la structurer, la découper en hiérarchie, et gérer le timing de son introduction.
- Des techniques avancées, compression, chargement dynamique, injection stratégique, compaction et mémoire agentique, affinent encore l'usage du contexte disponible.
- Mesurer le taux d'utilisation du contexte, la précision de récupération et le coût par interaction permet de piloter la stratégie dans la durée.
SECTION 1
La fenêtre de contexte, la ressource la plus disputée de vos applications IA
Dans l'IA, il existe un terme qui est critique : la fenêtre de contexte. Elle désigne la limite d'informations qu'un modèle peut « se souvenir » ou traiter à la fois. Vous l'avez peut-être remarquée en interagissant avec des modèles de langage : après de longs échanges, le modèle peut « oublier » ce qui a été dit plus tôt dans la conversation, ou perdre le fil d'une consigne pourtant posée dès le départ.
Mais la fenêtre de contexte n'est pas qu'une limite technique ennuyeuse. Comprendre et optimiser l'utilisation du contexte est devenu l'une des compétences les plus importantes du développement d'applications IA modernes, au point que le context engineering a largement supplanté le prompt engineering comme discipline centrale des équipes qui construisent des produits sur les LLM et les agents. Les équipes qui excellent ne sont plus celles qui écrivent les meilleurs prompts, mais celles qui assemblent le meilleur contexte.
Et voici l'analogie qui rend tout cela limpide : le context engineering est comme apprendre à faire des ricochets avec des pierres sur l'eau.
SECTION 2
La métaphore du ricochet : la finesse plutôt que la force
Quand vous apprenez à faire des ricochets, vous découvrez rapidement que tout ne dépend pas de la force. Lancer une pierre aussi fort que possible ne garantit pas qu'elle rebondira plusieurs fois. En réalité, cela garantit presque qu'elle coulera immédiatement.
Le secret des ricochets réussis tient à cinq facteurs : choisir la bonne pierre, plate, lisse, de la bonne taille ; l'angle, trop raide et elle coule, trop plat et elle glisse ; la rotation, donner à la pierre le bon spin ; la vitesse, ni trop rapide, ni trop lente ; et le timing, comprendre l'état de l'eau, calme ou agitée.
De même, le context engineering ne consiste pas à donner au modèle autant d'informations que possible. Il s'agit de fournir les bonnes informations, dans le bon format, au bon moment, avec la bonne structure. C'est un travail de curation permanente : chaque token présent dans le contexte doit y gagner sa place.
SECTION 3
Fenêtres de contexte en 2026 : des millions de tokens, le même problème
La fenêtre de contexte est le nombre maximal de tokens (morceaux de texte) qu'un LLM peut traiter dans une seule interaction. À l'été 2026, les modèles frontière se sont installés au-delà du million : les derniers Claude d'Anthropic (Opus 4.8, Fable 5) offrent une fenêtre d'un million de tokens, tout comme Gemini 3.1 Pro de Google ; GPT-5.4 d'OpenAI dépasse le million ; Grok atteint deux millions ; et Llama 4 Scout de Meta annonce jusqu'à dix millions de tokens en configuration étendue. La médiane du marché, elle, reste autour de 200 000 tokens.
### Pourquoi « plus grand » ne veut pas dire « meilleur »
Ces chiffres impressionnent, mais trois réalités tempèrent l'enthousiasme. La fiabilité de rappel se dégrade à mesure que le contexte se remplit : les benchmarks longue portée montrent que même les meilleurs modèles ne restituent pas parfaitement une information noyée dans un million de tokens. Le coût grimpe : plusieurs fournisseurs facturent plus cher les requêtes qui dépassent un seuil de tokens d'entrée. Et la latence s'allonge proportionnellement au volume traité.
Faites l'expérience de pensée : donneriez-vous à quelqu'un un manuel de 750 000 mots en vous attendant à ce qu'il se souvienne de chaque détail au moment précis où vous lui posez une question ? La capacité brute n'a jamais remplacé la pertinence.
SECTION 4
Dilution du contexte: attention, latence et lost in the middle
Voici ce qui se passe quand on jette trop d'informations dans le contexte. Premier effet, la dilution de l'attention : les LLM, comme les humains, ont une « attention » limitée. Lorsque le contexte est surchargé, le modèle peut perdre de vue ce qui compte réellement. Vous voulez qu'il résume les décisions d'une réunion, mais vous lui donnez le transcript complet de 15 000 mots, les profils LinkedIn de tous les participants, l'historique de l'entreprise et les politiques RH : il se perd dans les détails non pertinents et manque les décisions clés enfouies dans le transcript.
### Le budget de tokens, une contrainte économique autant que technique
Deuxième effet, la latence et les coûts : plus le contexte est grand, plus le traitement est long, plus la facture par token s'alourdit, surtout au-delà des seuils de tarification longue portée, et plus le risque d'erreur augmente. Sur une application servant des milliers de requêtes par jour, un contexte deux fois trop verbeux double le coût d'inférence sans améliorer la qualité. Raisonner en budget de tokens, comme on raisonne en budget de performance web, devient un réflexe d'équipe.
Troisième effet, le « lost in the middle » : la recherche montre que les LLM exploitent mieux les informations placées au début ou à la fin du contexte. Les informations situées au milieu peuvent être « perdues », un biais confirmé par les benchmarks de rappel longue portée et qui persiste même sur les modèles récents. Placer les consignes critiques au bon endroit reste donc un levier de qualité à coût nul.
SECTION 5
Quatre principes de ricochet pour structurer le contexte
Premier principe, choisir la bonne pierre, la sélection d'information. Mauvaise approche : charger l'intégralité de la base documentaire de 50 000 pages et la déverser dans le prompt, en laissant au modèle le soin de retrouver l'aiguille dans la botte de foin. Bonne approche : ne récupérer que les documents pertinents pour la question posée, par exemple les trois meilleurs résultats d'une recherche hybride combinant vecteurs et mots-clés, affinés par un reranker, et ne transmettre que ce sous-ensemble précis.
### L'angle et la rotation : structurer l'information
La structure du contexte affecte énormément la manière dont le modèle le traite. Un contexte en vrac, prix, stock et statut de plusieurs produits mélangés phrase après phrase, ne lui donne aucun repère. Un contexte structuré, chaque produit isolé sous une fiche balisée par des délimiteurs explicites, en Markdown ou en XML léger, lui permet de localiser instantanément l'information demandée.
### La vitesse : chunking et hiérarchie
Ne donnez pas tout le contexte d'un coup ; créez une hiérarchie d'informations. La summarization hiérarchique en est l'illustration : on résume d'abord chaque document à un niveau global, on classe ces résumés par pertinence, puis on ne va chercher le détail complet que pour les documents les mieux classés. Le contexte final combine une vue d'ensemble et le détail ciblé, plutôt que l'intégralité brute de chaque source.
Quatrième principe, le timing, la gestion active de la fenêtre. Une technique éprouvée est la fenêtre glissante avec résumés : un gestionnaire de conversation conserve les messages récents sous un budget de tokens donné ; dès que ce budget est dépassé, les messages les plus anciens sont condensés en un résumé unique, et seuls ce résumé courant et les échanges récents sont réinjectés dans le contexte envoyé au modèle.
@cite:quatre-techniques-de-recuperation-pour-ameliorer-la-rag
SECTION 6
Techniques avancées : compression, chargement dynamique et mémoire agentique
La compression de contexte réduit l'information tout en préservant le sens : des outils comme LLMLingua ramènent un contexte de 1 000 tokens à 200 tokens en conservant les faits clés, avant injection dans le prompt. Le chargement dynamique adapte le contexte à la progression de la conversation : un gestionnaire détecte le sujet de chaque requête, recharge le sous-graphe de connaissances correspondant quand le sujet change, ou approfondit le sujet courant quand il reste stable. Ces techniques se combinent naturellement au sein d'un même pipeline de préparation du contexte.
L'injection stratégique contre le « lost in the middle » consiste à classer les éléments de contexte par importance, à placer le plus critique en tête et le deuxième en clôture du prompt, le reste étant regroupé au milieu sous des délimiteurs explicites. Pour les questions complexes, le raisonnement multi-hop construit le contexte progressivement : on décompose la question en sous-questions, on répond à chacune en s'appuyant sur le contexte accumulé, puis on produit la réponse finale à partir des réponses intermédiaires.
Les agents autonomes ont fait émerger une génération de techniques supplémentaires : la compaction, qui résume automatiquement l'historique d'un agent approchant la limite de sa fenêtre pour lui permettre de poursuivre une tâche longue ; la prise de notes structurée, où l'agent externalise ses découvertes dans des fichiers ou une mémoire persistante plutôt que de tout garder en contexte ; et les architectures multi-agents, où des sous-agents explorent chacun avec leur propre fenêtre et ne remontent qu'une synthèse condensée à l'orchestrateur.
@cite:ingenierie-du-contexte-comment-donner-a-l-ia-exactement
SECTION 7
Mesurer, corriger et faire durer sa stratégie de contexte
Trois métriques permettent de piloter le context engineering dans la durée. Le taux d'utilisation du contexte : la proportion des éléments présents dans le contexte qui se retrouvent effectivement exploités dans la réponse, un ratio faible signale un contexte surchargé, dont une grande partie n'est jamais utilisée. La précision de récupération : la proportion des documents récupérés qui appartiennent réellement à l'ensemble pertinent attendu pour la requête. Et le coût par interaction : le rapport entre la qualité de la réponse et le coût du contexte consommé, plus ce ratio est élevé, plus la stratégie est efficace. Suivies en continu, ces métriques transforment le context engineering d'un art artisanal en une discipline mesurable.
### Trois erreurs qui ruinent les meilleurs pipelines
La première est le « kitchen sink context » : déverser toute la base de connaissances, tout l'historique utilisateur et tous les documents disponibles dans un seul prompt sans discrimination, soyez sélectif et pertinent. La deuxième est d'ignorer la structure : concaténer plusieurs documents bout à bout sans séparateur, en obligeant le modèle à deviner où finit l'un et où commence l'autre, utilisez des délimiteurs et une hiérarchie claire. La troisième est le contexte statique : charger le contexte une fois puis le réutiliser figé pour toutes les questions suivantes, même quand la conversation change de sujet, adaptez-le dynamiquement.
Le context engineering est comme l'art du ricochet : pas de force brute, mais de la finesse, du timing et une compréhension de la physique sous-jacente. Les meilleurs praticiens maîtrisent la sélection, la structure, le timing, la compression et l'adaptation. Et à mesure que les fenêtres grandissent, l'importance de la discipline ne diminue pas, elle augmente, car un contexte plus grand sans stratégie équivaut simplement à plus de bruit. Maîtrisez l'art du ricochet : votre IA vous remerciera.
@cite:du-vibe-coding-au-context-engineering-2025
FAQ
Questions fréquentes
Qu'est-ce que la fenêtre de contexte d'un LLM ?
C'est le nombre maximal de tokens (morceaux de texte) qu'un modèle de langage peut traiter en une seule interaction. En 2026, elle atteint un million de tokens sur les modèles frontière et jusqu'à dix millions sur certaines configurations étendues, mais une fenêtre plus grande ne garantit pas de meilleurs résultats.
Le context engineering est-il encore utile avec des fenêtres d'un million de tokens ?
Plus que jamais. La fiabilité de rappel se dégrade à mesure que le contexte se remplit, plusieurs fournisseurs facturent plus cher au-delà d'un seuil de tokens, et la latence croît avec le volume. Un contexte massif sans curation équivaut à plus de bruit : la sélection et la structure restent décisives.
Pourquoi donner plus de contexte à un modèle IA n'améliore-t-il pas toujours les résultats ?
Parce qu'un contexte surchargé dilue l'attention du modèle, augmente la latence et les coûts (facturés au token), et expose au phénomène du "lost in the middle" où les informations placées au milieu du contexte sont moins bien exploitées que celles situées au début ou à la fin.
Quelles sont les techniques concrètes pour éviter le "lost in the middle" ?
Il s'agit notamment d'injecter les informations critiques en début et fin de contexte, de structurer l'information avec des délimiteurs explicites, de construire une hiérarchie (résumé puis détail) et de gérer activement une fenêtre glissante qui condense les échanges anciens en résumés plutôt que de tout conserver tel quel.
Quelles métriques suivre pour piloter le context engineering ?
Trois indicateurs clés : le taux d'utilisation du contexte (part des éléments fournis réellement exploités dans la réponse), la précision de récupération (part des documents récupérés effectivement pertinents) et le coût par interaction (qualité de réponse rapportée au coût des tokens consommés).
À PROPOS D'ADSERVIO
Adservio est un partenaire de transformation digitale AI-native : DSI augmentée par l'IA, ingénierie logicielle, DevOps, MLOps, cybersécurité et gouvernance IA.
Discutons de votre projet : hello@adservio.fr · adservio.fr/contact