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.
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.
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.
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.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
