# Ingénierie du contexte : comment donner à l'IA exactement ce dont elle a besoin

> Skeleton trimming, sélection de fichiers par pertinence, contextualisation progressive : trois techniques d'ingénierie du contexte pour des LLM plus précis.

- Date : 2025-09-19
- Lecture : 8 min
- Catégorie : strategie-ia
- Tags : IA, Ingénierie du contexte, LLM, MCP, Optimisation des tokens, Génération de code
- URL : https://www.adservio.fr/insights/articles/ingenierie-du-contexte-comment-donner-a-l-ia-exactement

## L'essentiel

- L'ingénierie du contexte remplace le simple prompting : elle consiste à curer intelligemment ce qu'on envoie au modèle plutôt qu'à en entasser un maximum.
- Même avec les fenêtres d'un million de tokens de 2026, surcharger le contexte ralentit l'inférence, augmente les coûts et brouille le signal utile, c'est le « context rot ».
- Le skeleton trimming ne conserve que la structure essentielle du code (signatures, annotations, déclarations de classes) : un prompt passe de 10 000 à environ 300 tokens.
- La sélection de fichiers par pertinence distingue entrées indispensables, extras conditionnels et fichiers à ignorer ; la contextualisation progressive livre le contexte en trois temps.
- Combinées à MCP, à la compaction automatique et à la récupération juste-à-temps des agents modernes, ces techniques réduisent latence et coûts tout en améliorant la précision.

## Du prompt engineering à l'ingénierie du contexte : le vrai levier de performance des LLM

Si vous suivez de près les cercles du développement IA, vous avez remarqué le basculement : la conversation est passée du simple prompting à ce que les praticiens appellent l'« ingénierie du contexte ». Écrire une bonne instruction ne suffit plus ; ce qui fait la différence, c'est tout ce qui entoure cette instruction, code, documentation, historique de conversation, résultats d'outils, et la manière dont on l'assemble avant de l'envoyer au modèle.

Que vous travailliez avec Claude Fable 5, GPT-5.6 ou Gemini 3.5, la différence entre des résultats médiocres et exceptionnels repose souvent sur un seul facteur : la façon dont vous concevez la fenêtre de contexte. Les modèles de mi-2026 acceptent couramment un million de tokens en entrée, mais cette abondance est un piège : elle déplace le problème au lieu de le résoudre, car la capacité à absorber du contexte croît plus vite que la capacité à l'exploiter correctement. Une fenêtre plus grande relève le plafond ; elle n'améliore pas la qualité de ce qu'on y met.

Cet article explique pourquoi « plus de contexte » dégrade souvent les résultats, puis détaille trois techniques éprouvées issues d'une expérimentation pratique en génération de code back-end, le skeleton trimming, la sélection de fichiers basée sur la pertinence et la contextualisation progressive. Elles viennent du monde Java/Spring Boot, mais les patterns s'adaptent à la plupart des systèmes construits sur des LLM.

## Qu'est-ce que l'ingénierie du contexte ? La curation plutôt que l'accumulation

L'ingénierie du contexte ne consiste pas à entasser plus d'informations dans le prompt : il s'agit d'une curation plus intelligente. Pensez-y comme l'art de structurer, d'optimiser et de réduire les informations pour que les modèles de langage répondent plus vite, moins cher et mieux. Au lieu de décharger l'intégralité d'une base de code ou d'un jeu de données dans la fenêtre de contexte, on fournit stratégiquement au modèle uniquement ce qui compte, les bonnes informations, au bon format, au bon moment.

### Une discipline d'ingénierie à part entière

La discipline s'est structurée depuis 2025 : les grands fournisseurs de modèles publient désormais leurs propres guides d'ingénierie du contexte pour les agents, et le rôle apparaît explicitement dans les organigrammes des équipes IA. Le principe directeur reste constant : traiter la fenêtre de contexte comme une ressource rare, dotée d'un budget, d'une structure et de règles de gouvernance, exactement comme on traite la mémoire ou la bande passante dans un système distribué. Chaque token admis dans la fenêtre doit mériter sa place, et tout le reste doit rester dehors.

L'outillage a suivi. Le Model Context Protocol (MCP) relie les sources de données aux modèles de façon standardisée, les approches code-as-context transforment les bases de code en documentation vivante, et les moteurs de contexte produisent des résumés structurés à partir de projets complexes. Ces briques rendent la curation systématique et reproductible, là où elle relevait auparavant de l'artisanat.

> À lire aussi : [Le Model Context Protocol : au-delà de la tendance, le standard des agents IA](https://www.adservio.fr/insights/articles/le-protocole-model-context-au-dela-de-la-tendance): Architecture, spécification 2026, registre officiel, sécurité : comment le Model Context Protocol est passé du buzz au standard des agents IA en production.

## Le paradoxe du contexte : pourquoi une fenêtre d'un million de tokens ne suffit pas

Surcharger votre IA d'informations la fait souvent moins bien performer. Cela peut sembler contre-intuitif, mais c'est la réalité mesurée de la construction de systèmes IA. Imaginez que vous demandiez à un LLM de générer un UserService en Spring Boot : l'erreur classique du débutant consiste à décharger l'intégralité de la base de code, contrôleurs, logique complète des repositories, classes de configuration, couches utilitaires, jusqu'aux fichiers README, dans le prompt.

Le résultat est triple. Consommation de tokens : plus de 10 000 tokens pour des données largement non pertinentes, facturés à chaque appel. Inférence ralentie : les entrées longues augmentent mécaniquement la latence. Sorties confuses : le modèle peine à distinguer le signal du bruit et produit un code moins cohérent que si on lui avait donné dix fois moins. En pratique, les équipes le découvrent à leurs dépens : la facture croît à chaque appel pendant que la qualité du code généré décline en silence.

### Context rot : la dégradation silencieuse des longues fenêtres

Les benchmarks de type « needle in a haystack » et les études sur le context rot l'ont confirmé : la capacité d'un modèle à exploiter une information décroît à mesure que la fenêtre se remplit, particulièrement pour les éléments situés au milieu du contexte. Une fenêtre d'un million de tokens n'est donc pas une invitation à la remplir : c'est une marge de sécurité qui doit rester largement inutilisée. Les meilleures équipes surveillent le remplissage de leurs fenêtres comme on surveille la pression mémoire d'un serveur. Il ne s'agit pas d'avoir moins de contexte, mais d'avoir le bon contexte, une inclusion stratégique plutôt qu'un déversement.

> À lire aussi : [Pourquoi le context engineering est comme apprendre à l'IA à faire des ricochets](https://www.adservio.fr/insights/articles/pourquoi-le-context-engineering-est-comme-apprendre-a-l-ia): 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.

## Skeleton trimming : réduire un prompt de 10 000 à 300 tokens

Le skeleton trimming consiste à ne conserver que la structure essentielle du code, signatures de méthodes, déclarations de classes, annotations, et à supprimer les corps d'implémentation. L'intuition est simple : pour générer un service cohérent, le modèle n'a pas besoin de savoir comment chaque méthode est implémentée ; il a besoin de connaître le contrat que son code devra respecter. Signatures, types et annotations portent presque toute l'information architecturale, pour une fraction infime des tokens.

### Avant/après sur un contrôleur Spring Boot

Avant le trimming : un contrôleur complet, avec l'annotation @RestController, le mapping de base @RequestMapping("/users"), l'injection du service via le constructeur, puis chaque méthode, createUser en @PostMapping, getUser en @GetMapping, accompagnée de son corps d'implémentation intégral, qui appelle le service et construit la ResponseEntity renvoyée.

Après : seules les annotations de classe et les signatures des méthodes subsistent, @PostMapping createUser(...), @GetMapping getUser(...),sans corps ni déclaration d'injection de dépendances, à la manière d'une interface qui décrit le contrat de l'API sans exposer ses détails internes. Pour générer un UserService, il suffit alors du modèle utilisateur (champs uniquement), de la signature de l'interface repository et des patterns de endpoints du contrôleur : environ 300 tokens au lieu de 10 000, avec des résultats supérieurs. C'est l'astuce au meilleur rapport effort/gain de toute la panoplie, et la plus facile à automatiser dans une étape de pré-traitement.

## Sélection de fichiers basée sur la pertinence : trois catégories d'entrées

La deuxième technique intervient en amont : avant même de préparer les entrées du LLM, on identifie les seuls fichiers directement pertinents pour la tâche, en les triant dans trois catégories aux frontières nettes. L'objectif : constituer le plus petit ensemble de fichiers qui spécifie complètement la tâche, rien de moins, rien de plus.

### Entrées indispensables, extras conditionnels, fichiers à ignorer

Les entrées indispensables définissent directement la tâche : pour générer un OrderService, il faut toujours l'interface OrderRepository (déclarations de méthodes uniquement), le modèle Order (champs et annotations) et les mappings de endpoints de l'OrderController. Les extras conditionnels ne sont inclus que si la tâche en dépend : la classe OrderNotFoundException si le service la lève, le DTO CreateOrderRequest s'il l'utilise. Les fichiers non pertinents, enfin, doivent être écartés sans état d'âme : SecurityConfig, Application.java ou les classes de service sans lien avec la logique en cours n'apportent que du bruit.

En 2026, cette sélection est largement automatisable : recherche sémantique sur la base de code, analyse du graphe d'imports pour suivre les dépendances réelles, ou serveurs MCP spécialisés qui n'exposent à l'agent que les fichiers pertinents. Mais l'automatisation ne dispense pas de la discipline : c'est la taxonomie, indispensable, conditionnel, à ignorer, qui garantit un contexte minimal et suffisant, quel que soit l'outil qui l'applique.

## Contextualisation progressive : livrer le contexte par étapes

Au lieu de fournir tout le contexte en une seule fois, la contextualisation progressive le livre par étapes, chacune ne contenant que les informations pertinentes pour ce point du processus. C'est d'ailleurs le principe qu'appliquent nativement les agents de codage modernes, qui explorent la base de code au fil de la tâche plutôt que de tout charger au départ. Chaque étape resserre le champ des possibles avant que la suivante n'ajoute de la précision.

### Trois temps : cadrage, structure, détail

Le cadrage définit l'objectif et les contraintes de haut niveau, par exemple « implémenter les opérations CRUD pour OrderService ». La structure fournit uniquement les squelettes nécessaires pour esquisser la solution, champs du modèle de commande, interface du repository, DTOs. Le détail ajoute enfin les éléments d'implémentation spécifiques : classes d'exception, constantes, cas limites. En cadençant ainsi le flux d'informations, on guide l'attention du modèle pas à pas, vers des sorties plus claires et plus cohérentes.

Ces trois techniques ne sont pas des normes officielles : elles proviennent d'une expérimentation pratique en génération de code back-end. Considérez-les comme des patterns adaptables, leur combinaison compte davantage que chacune isolément, car elles agissent sur trois moments différents : ce qu'on inclut, sous quelle forme, et à quel rythme.

> À lire aussi : [Du vibe coding au context engineering : 2025 dans le développement logiciel](https://www.adservio.fr/insights/articles/du-vibe-coding-au-context-engineering-2025): Du vibe coding au context engineering : comment 2025 a transformé le développement logiciel et pourquoi MCP, A2A et les agents replacent l'ingénieur au centre.

## Outiller l'ingénierie du contexte en 2026 : MCP, compaction et récupération juste-à-temps

Ces techniques manuelles se combinent désormais avec un outillage mûr. MCP standardise l'accès aux sources de données et évite les intégrations ad hoc. Les agents pratiquent la compaction automatique, résumer l'historique de conversation quand la fenêtre approche de la saturation, et s'appuient sur des mémoires persistantes stockées hors contexte, rechargées à la demande. La récupération juste-à-temps a remplacé le chargement exhaustif : l'agent va chercher l'information au moment précis où il en a besoin, plutôt que de tout embarquer au départ. Les sous-agents poussent la même logique plus loin : chacun travaille avec sa propre fenêtre dédiée avant de renvoyer un résumé.

La gestion efficace du contexte est ainsi devenue une pierre angulaire de la construction de systèmes IA performants. En ne fournissant que les informations les plus pertinentes, on réduit la latence, on maîtrise les coûts et on améliore la précision des résultats, trois bénéfices qui ne demandent pas un modèle plus gros, mais un contexte mieux conçu. C'est aussi pourquoi l'ingénierie du contexte reste rentable quel que soit le fournisseur de modèle choisi.

La règle de fond, elle, n'a pas changé : la qualité de la sortie de votre LLM vaut celle du contexte que vous lui fournissez. Traitez votre budget de tokens comme de l'immobilier premium et remplissez-le de contenu à haute valeur, pas d'encombrement. Une version antérieure de cet article a été publiée sur Medium. Avis de non-responsabilité : les déclarations et opinions exprimées dans cet article sont celles de leurs auteurs et ne reflètent pas nécessairement les positions d'Adservio.

## FAQ

### Qu'est-ce que l'ingénierie du contexte, concrètement ?

C'est l'art de structurer, d'optimiser et de réduire les informations envoyées à un modèle de langage pour qu'il réponde plus vite, moins cher et mieux, en lui fournissant uniquement ce qui compte, au bon format et au bon moment, plutôt que de décharger l'intégralité d'une base de code ou d'un jeu de données dans le prompt.

### Pourquoi donner plus de contexte à un LLM peut-il dégrader ses réponses ?

Un contexte surchargé augmente la consommation de tokens, ralentit l'inférence et brouille la capacité du modèle à distinguer le signal du bruit. Les études sur le context rot montrent que l'exploitation d'une information décroît à mesure que la fenêtre se remplit, même avec les fenêtres d'un million de tokens des modèles de 2026.

### Qu'est-ce que le skeleton trimming ?

Une technique qui ne conserve que la structure essentielle du code, signatures de méthodes, déclarations de classes, annotations, et supprime les corps d'implémentation. Un prompt de génération de service peut ainsi passer d'environ 10 000 tokens à 300, avec des résultats supérieurs, car le modèle reçoit le contrat sans le bruit.

### Comment choisir les fichiers à inclure dans le contexte d'un LLM ?

En les triant en trois catégories : les entrées indispensables qui définissent la tâche (modèle, interface repository, mappings de endpoints), les extras conditionnels inclus seulement si la tâche en dépend (exceptions, DTOs), et les fichiers non pertinents à écarter (configuration, classes sans lien avec la logique en cours).

### Quels outils facilitent l'ingénierie du contexte en 2026 ?

Le Model Context Protocol (MCP) pour standardiser l'accès aux sources de données, les approches code-as-context qui transforment les bases de code en documentation vivante, la compaction automatique de l'historique, les mémoires persistantes hors contexte et la récupération juste-à-temps pratiquée par les agents modernes.