L'ingénierie de contexte remplace l'ingénierie de prompt comme compétence IA clé

L'ingénierie de prompt n'a jamais vraiment consisté à trouver des mots magiques. Il s'agissait de donner au modèle suffisamment d'informations pertinentes, dans un format exploitable, pour produire une bonne réponse. Cette distinction comptait moins lorsque la tâche était un simple échange question-réponse. Elle compte énormément aujourd'hui que la plupart des systèmes d'IA en production sont des agents : des boucles qui appellent des outils, lisent des résultats, récupèrent des documents et conservent un état sur des dizaines d'étapes.

La compétence qui détermine si ces systèmes fonctionnent n'est plus la formulation du prompt. C'est l'ingénierie de contexte — la discipline consistant à décider ce qui entre dans la fenêtre de contexte du modèle à chaque étape, comment c'est structuré, et quand c'est évacué. Les équipes qui traitent cela comme secondaire construisent des agents coûteux, lents, et qui se trompent de façons difficiles à déboguer.

Pourquoi l'ingénierie de prompt ne suffit plus

Un prompt unique bien conçu suppose que le modèle possède déjà tout ce dont il a besoin pour répondre. Les flux de travail agentiques ne fonctionnent pas ainsi. Un agent qui diagnostique un incident de production peut rassembler des extraits de logs, un manuel opérationnel, trois fils Slack liés et le résultat de deux appels d'outils — tout cela avant d'écrire le moindre mot de sa réponse réelle. Rien de tout cela n'est «le prompt» au sens de 2023. C'est un budget de contexte, et chaque token qui le compose est une décision.

Des fenêtres de contexte plus grandes ont d'abord aggravé la situation avant de l'améliorer. Quand les modèles de l'ère GPT-4 plafonnaient autour de 32 000 tokens, les équipes étaient contraintes à la sélectivité par nécessité. Les fenêtres de contexte d'un million de tokens ont supprimé cette contrainte, et la réponse naïve — tout déverser et laisser le modèle trier — s'est révélée dégrader les performances. Les recherches sur la récupération en contexte long montrent systématiquement que les modèles portent une attention inégale sur un grand contexte, favorisant souvent les informations proches du début ou de la fin et perdant en précision sur les faits enfouis au milieu. Plus de tokens ne signifie pas plus de signal. C'est souvent plus de bruit avec une facture d'API plus élevée.

Les quatre tâches de l'ingénierie de contexte

En pratique, l'ingénierie de contexte se décompose en quatre problèmes distincts, et la plupart des échecs d'agents remontent à une erreur sur l'un d'eux.

Sélection de récupération

Décider ce qui entre dans le contexte. C'est la tâche pour laquelle les pipelines RAG ont été conçus, mais la qualité de la sélection compte plus que l'exhaustivité de la récupération. Renvoyer les 20 fragments les plus semblables sémantiquement n'est pas la même chose que renvoyer les 5 qui répondent réellement à la question. Les équipes qui optimisent pour l'exhaustivité plutôt que la précision retombent dans le piège du tout-déverser, sauf que c'est désormais un modèle d'embedding qui s'en charge plutôt qu'un humain.

Compression

Les sorties brutes d'outils, fichiers de logs et extraits de documents méritent rarement d'être envoyés tels quels. Une trace de pile de 400 lignes se compresse généralement en trois lignes pertinentes et un résumé sans perdre ce dont le modèle a besoin. La compression est la source de la majorité des économies de coûts en tokens dans les systèmes d'agents en production, et c'est aussi là qu'un résumé naïf peut supprimer silencieusement le seul détail qui comptait.

Structure et ordre

L'emplacement d'une information dans le contexte influence la façon dont le modèle l'utilise. Placer les contraintes et instructions juste avant l'étape de génération, plutôt que de les enfouir en haut d'un long prompt système, améliore mesurablement le respect des instructions en contexte long. L'ordre n'est pas cosmétique — il est structurel.

Réécriture en mémoire

Les agents qui fonctionnent sur plus d'un tour ont besoin d'une politique sur ce qui est écrit en mémoire persistante par rapport à ce qui reste éphémère dans le contexte actuel. Tout écrire transforme la mémoire en un second dépotoir avec le même problème de bruit. N'écrire rien oblige l'agent à redériver les mêmes faits à chaque session, consommant tokens et latence en redécouverte.

Où les équipes se trompent

L'erreur la plus courante consiste à traiter le contexte comme gratuit. Il ne l'est pas. Chaque document supplémentaire dans la fenêtre ajoute de la latence, du coût, et — au-delà d'une certaine densité — une baisse mesurable de la qualité des réponses, parfois appelée «pourrissement du contexte». La deuxième erreur la plus fréquente est l'assemblage statique du contexte : construire un seul pipeline de construction de contexte et l'utiliser pour chaque requête, que la tâche nécessite trois documents ou trente. La troisième est d'omettre complètement la politique d'éviction, si bien qu'une session d'agent longue accumule des sorties d'outils jusqu'à ce que la majeure partie de la fenêtre de contexte soit un échafaudage d'étapes dont l'agent n'a plus besoin.

Ce que cela donne dans un système qui fonctionne

Les équipes qui réussissent ont généralement un budget de contexte explicite par étape : un plafond de tokens pour les documents récupérés, un plafond séparé pour les sorties d'outils, et une allocation réservée pour les instructions et les tours de conversation récents qui n'est jamais déplacée. Elles enregistrent ce qui se trouvait dans le contexte lorsqu'un agent a produit une mauvaise réponse, de la même façon qu'elles enregistreraient une trace de pile, car la composition du contexte est désormais une surface de débogage principale, pas un détail d'implémentation.

À retenir

Arrêtez d'optimiser la formulation du prompt isolément. Vérifiez ce qui entre réellement dans la fenêtre de contexte à chaque étape de l'exécution de votre agent, et mesurez combien le modèle utilise réellement.
Traitez la précision de récupération comme plus importante que l'exhaustivité. Renvoyer moins de résultats plus pertinents vaut mieux que d'en renvoyer plus en espérant que le modèle les filtre.
Construisez une étape de compression pour les sorties d'outils et les logs avant qu'ils n'atteignent la fenêtre de contexte, pas après qu'une revue de coûts signale la dépense en tokens.
Placez l'instruction de tâche et les contraintes près du point de génération, pas enfouies en haut d'un long prompt système, surtout une fois votre contexte dépassant quelques milliers de tokens.
Définissez une politique explicite de réécriture en mémoire plutôt que de tout accumuler ou tout jeter par défaut entre les tours.