Context engineering
l'art de bien nourrir l'IA

Imaginez que vous engagiez le meilleur expert du monde pour résoudre un problème, mais que vous ne lui accordiez que quelques minutes et une seule page de notes. Tout se jouerait sur ce que vous choisiriez d'écrire sur cette page. Trop peu d'informations, et l'expert avancerait à l'aveugle. Trop d'informations, et il se noierait, incapable de distinguer l'essentiel du bruit. Un modèle de langage, aussi puissant soit-il, se trouve exactement dans cette situation à chaque requête. Sa « page de notes » porte un nom technique — la fenêtre de contexte — et l'art de la remplir intelligemment est devenu, en 2025, la compétence la plus recherchée de tout l'écosystème de l'IA^[1].

Prompt engineering, context engineering : quelle différence ?

Commençons par dissiper la confusion, car les deux termes sont souvent employés l'un pour l'autre. La distinction, pourtant, est simple et se résume en une phrase : le prompt engineering s'intéresse à ce que vous dites au modèle ; le context engineering s'intéresse à ce que le modèle sait au moment où vous le dites^[2].

Le prompt engineering, c'est l'art de la formulation. Bien tourner sa demande, donner un exemple, préciser le format de réponse attendu, demander au modèle de raisonner étape par étape. C'est une compétence réelle et toujours utile — mais elle ne concerne qu'une seule pièce du puzzle : l'instruction ponctuelle. Le context engineering, lui, embrasse l'ensemble. Il ne se demande pas seulement « quelle question poser ? », mais « quelles informations réunir, dans quel ordre, en quelle quantité, pour que le modèle ait toutes les cartes en main — et seulement les bonnes ? »^[3].

Une image aide à saisir le glissement. Le prompt engineering, c'est apprendre à poser une bonne question à un bibliothécaire. Le context engineering, c'est concevoir la bibliothèque elle-même : décider quels livres sont sur les rayonnages, lesquels sont à portée de main, lesquels on range et lesquels on jette, pour que la bonne information se trouve toujours là au bon moment. La première compétence s'exerce en une phrase ; la seconde structure tout l'environnement de travail du modèle. Et à mesure que l'on passe des simples chatbots aux agents — ces IA qui enchaînent des dizaines d'étapes, appellent des outils, lisent des fichiers et mènent des tâches longues —, c'est cette seconde compétence qui devient décisive^[3].

Le vrai problème : l'attention est une ressource rare

On pourrait croire que la solution est évidente : puisque les fenêtres de contexte modernes acceptent des centaines de milliers de mots, il suffirait de tout y déverser. Erreur — et c'est la contre-intuition centrale de toute la discipline. Le facteur limitant n'est pas la capacité brute, mais l'attention. Comme un esprit humain qui décroche quand on l'inonde de détails, un modèle voit sa performance se dégrader à mesure que son contexte se remplit, bien avant d'avoir atteint sa limite théorique^[1]. Chaque mot ajouté puise dans un budget d'attention fini. L'objectif n'est donc pas d'en mettre le plus possible, mais de trouver le plus petit ensemble d'informations à fort signal qui maximise les chances d'une bonne réponse^[4].

Les chercheurs ont documenté plusieurs façons dont un contexte trop chargé fait dérailler un modèle. La plus célèbre porte un nom imagé : le « perdu au milieu » (lost in the middle). Une information placée au centre d'un long contexte est nettement moins bien retrouvée qu'une information située au début ou à la fin — la courbe d'attention a la forme d'un U^[5]. D'où une règle pratique, simple et puissante : placez ce qui compte vraiment au début ou à la fin, jamais enfoui au milieu.

D'autres pièges guettent, et il vaut la peine de les nommer, car les reconnaître, c'est déjà à moitié les éviter. Il y a l'empoisonnement : une erreur ou une hallucination entre dans le contexte, puis se propage parce que le modèle continue de s'y référer comme à un fait acquis. Il y a la distraction : un seul document hors sujet suffit à faire baisser la performance — l'effet n'est pas proportionnel, c'est un décrochage brutal. Il y a la confusion : quand le contexte mêle plusieurs types de tâches, le modèle applique parfois les consignes de la mauvaise. Et il y a le conflit : deux informations exactes mais contradictoires qui se neutralisent^[6]. Dans tous les cas, la leçon est la même : un contexte encombré n'est pas neutre. Il nuit activement.

Les quatre gestes fondamentaux

Face à cette rareté de l'attention, la communauté a convergé vers une boîte à outils remarquablement claire, popularisée notamment par les équipes de LangChain et reprise partout depuis. Quatre gestes, quatre verbes, qui suffisent à décrire presque toute la pratique : écrire, sélectionner, compresser, isoler^[7]. Voyons-les un par un, sans technicité.

Écrire, d'abord. Plutôt que de garder tout l'historique d'une tâche dans la fenêtre, l'agent note ses résultats intermédiaires ailleurs — sur un « bloc-notes » externe, un fichier, une base de données — et ne les rappelle qu'au besoin. C'est exactement ce que fait un humain qui griffonne ses calculs sur une feuille plutôt que de tout retenir de tête. La fenêtre reste ainsi légère et concentrée sur l'instant présent^[7].

Sélectionner, ensuite. C'est le principe de la fameuse « génération augmentée par récupération » (RAG, dans le jargon) : au lieu de charger toute la documentation d'une entreprise, on va chercher, à la volée, les trois ou quatre passages réellement utiles à la question posée. Le tri se fait avant d'entrer dans le contexte, pas après. Bien fait, ce geste évite à la fois la distraction et le gaspillage d'attention.

Compresser, aussi. Une conversation qui dure, une série d'appels d'outils qui s'accumulent — tout cela gonfle vite. La compression consiste à remplacer le volume par l'essentiel : résumer les vingt derniers échanges en un paragraphe, transformer un rapport de dix pages en cinq puces, condenser un résultat technique en une ligne de référence. On garde le sens, on jette le poids.

Isoler, enfin. Quand une tâche est trop vaste pour une seule fenêtre, on la découpe et on confie chaque morceau à un sous-agent distinct, doté de son propre contexte, vierge et focalisé. C'est le principe des architectures multi-agents. Attention toutefois — nous y reviendrons — car cette élégance a un coût, et un piège.

Les agents changent la donne

Tant qu'on discute avec un chatbot, l'enjeu reste modeste : quelques échanges, un contexte qui grandit lentement. Tout bascule avec les agents. Un agent qui mène une tâche longue — analyser un dossier, écrire du code, mener une recherche — accumule des résultats d'outils à chaque étape. Et ces résultats deviennent vite écrasants : dans les trajectoires d'agents observées, les sorties d'outils peuvent représenter jusqu'à plus de 80 % du contexte total^[8]. Sans discipline de contexte, l'agent s'étouffe littéralement sous ses propres traces.

C'est ici qu'intervient une idée particulièrement utile pour les organisations : les compétences d'agent (agent skills), et le principe de la divulgation progressive. Plutôt que de charger d'emblée toute l'expertise disponible, l'agent ne connaît au démarrage que les noms et de courtes descriptions des compétences à sa disposition. Le contenu détaillé d'une compétence ne se charge que lorsqu'elle devient pertinente pour la tâche^[9]. C'est le principe même du menu de restaurant : on vous présente d'abord les intitulés des plats, pas la recette complète de chacun. Vous ne recevez les détails que de ce que vous commandez. Résultat : l'agent reste rapide et léger, tout en ayant accès, à la demande, à une profondeur d'expertise considérable.

Il faut aussi être lucide sur l'économie de ces systèmes. Un agent avec outils consomme environ quatre fois plus de tokens qu'un simple chat ; un système multi-agents, environ quinze fois plus^[10]. Ce n'est pas un détail comptable : c'est une décision d'architecture. On ne déploie pas une escouade de sous-agents pour le plaisir de reproduire un organigramme d'entreprise. On le fait pour une seule bonne raison : isoler les contextes et paralléliser le travail quand la tâche le justifie vraiment. Le reste n'est que coût.

Bien structurer le contexte : quelques principes concrets

Au-delà des grandes stratégies, la pratique quotidienne repose sur des gestes simples que n'importe quelle équipe peut adopter. Le premier : structurer ses instructions. Un contexte bien organisé, avec des sections clairement délimitées — informations de fond, consignes, guidage des outils, format de sortie attendu — aide le modèle à s'orienter, exactement comme des intertitres aident un lecteur^[11]. Un modèle qui sait où chercher chaque type d'information dans son contexte s'en sert mieux.

Le deuxième : résumer plutôt que déverser. Pour un agent, il vaut presque toujours mieux condenser un résultat intermédiaire en une synthèse compacte avant de le transmettre à l'étape suivante, plutôt que de faire circuler le flux brut^[12]. Le troisième : soigner les descriptions d'outils. Dans un agent, les définitions d'outils sont placées en tête de contexte et orientent fortement le comportement ; une description claire et un message d'erreur explicite valent mieux qu'une documentation exhaustive et confuse. Le quatrième, transversal : évaluer. On ne pilote bien que ce qu'on mesure. Tester différentes façons de composer le contexte, comparer les résultats, itérer — c'est ainsi qu'on transforme l'intuition en méthode.

Un mot de prudence, enfin, sur les chiffres qui circulent. On lit parfois des seuils précis de dégradation par modèle — tel modèle décrocherait à tant de milliers de mots, tel autre tiendrait plus longtemps. Ces repères, issus de bancs d'essai récents, sont utiles comme ordres de grandeur, mais ils évoluent à chaque nouvelle génération de modèles et varient selon la nature de la tâche^[6]. Mieux vaut retenir le principe — la dégradation existe, elle arrive plus tôt qu'on ne le croit — que mémoriser des nombres qui seront périmés dans six mois.

Pourquoi cela compte pour une PME

On pourrait croire ce sujet réservé aux ingénieurs des grands laboratoires. C'est une erreur. Le context engineering est précisément ce qui sépare, pour une petite entreprise, un usage frustrant de l'IA d'un usage réellement productif. Le dirigeant qui se plaint que « l'IA raconte n'importe quoi » ou « oublie ce que je lui ai dit » ne bute presque jamais sur les limites du modèle. Il bute sur un problème de contexte : il n'a pas fourni la bonne information, ou il en a fourni trop, ou en désordre^[2].

La bonne nouvelle, c'est que ces principes ne demandent ni doctorat ni budget colossal. Rassembler les documents pertinents dans une bibliothèque bien tenue, poser une consigne claire et structurée, résumer les échanges longs, ne connecter à un assistant que les sources vraiment utiles : ce sont des gestes accessibles, qui transforment radicalement la qualité des résultats. Le context engineering n'est pas une technologie de plus à acheter. C'est une manière de penser sa relation à l'outil — la même exigence de rigueur qui, ailleurs sur ce blog, nous faisait plaider pour rassembler plutôt que disperser, et pour garder la maîtrise de ses données.