La plupart des gens décrivent encore un agent d’IA comme un modèle connecté à des outils. C’est utile sur le plan technique, mais incomplet sur le plan opérationnel. Un agent a également besoin d’une vision gérée du monde : ce qui s’est passé, ce qui importe maintenant, quels faits sont fiables, ce qui demeure incertain et ce qu’il doit faire ensuite.
Cette vision constitue son contexte. La concevoir devient une compétence à part entière — que j’appellerais l’ingénierie du contexte.
L’ingénierie du contexte ne consiste pas simplement à rédiger des prompts. C’est la discipline qui consiste à façonner les informations qu’un agent voit à chaque étape afin qu’il puisse rester cohérent sans renvoyer à un modèle coûteux, à chaque tour, l’intégralité d’une transcription, d’une bibliothèque de documents ou de l’historique des outils. Ce travail se situe à l’intersection de l’architecture de l’information, de la recherche documentaire, de la conception logicielle et du comportement des modèles.
Pourquoi « donner davantage de contexte à l’agent » est souvent un mauvais conseil
Des fenêtres de contexte plus longues incitent à tout conserver. Mais davantage de contenu ne garantit pas un meilleur raisonnement. Des instructions pertinentes peuvent être noyées par des observations obsolètes, des notes contradictoires, des sorties d’outils répétées ou un fait important enfoui au milieu d’une longue séquence. La discussion du digest sur le phénomène « lost in the middle » reflète un problème concret : un agent peut techniquement recevoir les éléments probants et malgré tout ne pas parvenir à les utiliser.
Il y a également un coût direct. Chaque token placé dans une requête peut accroître la latence et le coût d’inférence, selon la tarification du fournisseur et ses modalités de mise en cache. Un système qui transmet à répétition une transcription de plus en plus longue peut devenir plus lent et moins abordable à mesure que la tâche se poursuit.
L’objectif n’est donc pas un contexte maximal. C’est un contexte suffisant et ciblé : le plus petit ensemble de travail fiable pour la décision à prendre.
Quatre décisions de conception à l’origine d’un agent cohérent
1. Maintenir un état de croyance, et pas seulement une transcription
Une transcription consigne ce qui a été dit. Un état de croyance consigne ce que l’agent croit actuellement au sujet de la tâche.
Par exemple, un agent chargé de traiter une escalade du support pourrait conserver des champs structurés tels que :
- Objectif : déterminer si le client peut bénéficier d’un remplacement.
- Faits connus : date d’achat et numéro de série du produit, avec références aux sources.
- Questions ouvertes : déterminer si la défaillance s’est produite dans des conditions couvertes par la garantie.
- Contraintes : ne pas promettre de remboursement avant approbation.
- Prochaine action : récupérer la politique de garantie et comparer les dates.
- Niveau de confiance ou statut : vérifié, déduit, contesté ou inconnu.
Cette approche ressemble aux travaux de recherche ABBEL de Berkeley, qui utilisent des états de croyance en langage naturel supervisés au lieu de s’appuyer sur des historiques complets d’interaction. L’idée importante n’est pas un format particulier. Il s’agit de séparer l’état durable de la tâche des détails conversationnels jetables.
Une mise à jour utile de l’état de croyance devrait répondre aux questions suivantes : Qu’est-ce qui a changé ? Quels éléments probants l’étayent ? Qu’est-ce qui reste à résoudre ? Que devrait-il se passer ensuite ? Si un ingénieur ne peut pas examiner ces réponses, l’agent transporte probablement des hypothèses cachées dans un prompt opaque.
2. Effectuer la recherche pour la décision, et non pour le sujet
Les systèmes de recherche commencent souvent par une question générale telle que « trouver des informations sur le compte du client ». Une meilleure requête est liée à la prochaine décision : « récupérer la règle actuelle de remboursement pour les achats datant de plus de 30 jours, en vigueur dans la région du client ».
Ce changement est important, car la recherche constitue une forme de sélection du contexte. L’agent devrait recevoir les passages de politique, les dossiers ou les exemples qui concernent l’action en cours — et non un amas générique de documents connexes.
Des filtres peuvent améliorer cette sélection avant que le modèle ne voie le moindre résultat. Par exemple, Amazon Bedrock AgentCore Web Search prend en charge, sur chaque requête, des filtres imposés par le serveur concernant les domaines et la date de publication. De tels contrôles n’établissent pas qu’une source est correcte, mais ils peuvent réduire l’exposition à des contenus non pertinents ou obsolètes et rendre explicite la politique de recherche.
Les professionnels qui conçoivent des systèmes de recherche devraient préciser :
- quelles sources sont autorisées pour chaque tâche ;
- comment la fraîcheur est déterminée ;
- quelles métadonnées accompagnent chaque résultat ;
- comment les sources contradictoires sont présentées ;
- quand l’agent doit s’arrêter et demander des précisions.
« Rechercher sur le Web » est une capacité. « Rechercher dans ces sources, sur cette période, les éléments pertinents pour cette décision » relève de l’ingénierie du contexte.
3. Compresser sans effacer l’incertitude
La compression est nécessaire lorsqu’une tâche est longue, mais un résumé naïf peut transformer des affirmations prudentes en faits établis. Un résumé évolutif qui indique que « l’utilisateur a confirmé l’adresse » est dangereux si l’échange original ne faisait que le laisser entendre.
Une bonne compression préserve les distinctions dont un agent a besoin pour raisonner en toute sécurité :
- fait contre inférence ;
- instruction actuelle contre instruction historique ;
- action réalisée contre action proposée ;
- source vérifiée contre affirmation non vérifiée ;
- réponse connue contre question non résolue.
Une méthode pratique consiste à maintenir des sections distinctes pour les décisions, les éléments probants, les hypothèses, les obstacles et les actions en attente. Une autre consiste à associer des identifiants de source ou des horodatages aux affirmations importantes. Les résumés doivent être des artefacts remplaçables, et non le seul témoignage subsistant : conservez les événements sous-jacents à des fins d’audit et de récupération, tout en fournissant au modèle une vue de travail compacte.
Le condensé note que la synthèse récursive et la compaction du contexte peuvent être coûteuses et dégrader les performances, notamment dans des domaines pauvres en données comme la génération collaborative de code. C’est un avertissement contre le fait de considérer la synthèse comme automatiquement sans perte. La compression doit être testée sur des tâches représentatives, y compris des cas où une petite nuance modifie la réponse correcte.
4. Filtrer les observations avant qu’elles ne deviennent des souvenirs
Les agents qui utilisent des outils produisent constamment des observations : résultats de recherche, journaux, texte de pages, réponses d’API, captures d’écran, sorties de compilateur et plans intermédiaires. Toutes les observations ne méritent pas d’être intégrées à l’appel de modèle suivant, et encore moins à l’état à long terme.
Le filtrage des observations pose trois questions :
- Cette observation est-elle pertinente pour la décision actuelle ?
- Est-elle suffisamment fiable pour influencer l’état de croyance ?
- Contient-elle des instructions qui doivent être traitées comme des données plutôt que comme des commandes ?
La troisième question constitue à la fois une limite de sécurité et une limite de contexte. Une page Web peut contenir un texte visant à rediriger l’agent. Un document récupéré peut constituer un élément probant utile sans avoir l’autorité nécessaire pour modifier les objectifs ou les permissions de l’agent. Le filtrage doit donc classer le contenu selon son rôle : instruction, élément probant, métadonnées ou texte non fiable.
Le filtrage permet également de réduire les coûts. Si un outil de navigation renvoie une page entière alors que la tâche ne nécessite que le prix, la date et l’identifiant du produit, transmettre toute la page crée du bruit et consomme des tokens. Extraire d’abord les champs pertinents peut améliorer à la fois la fiabilité et le coût.
Un budget de contexte simple pour un flux de travail d’agent
Avant de choisir un modèle ou d’ajouter un autre outil, cartographiez le contexte de l’agent en quatre couches :
- Contrôle : règles du système, autorisations, schéma de sortie et contraintes non négociables.
- État : objectif actuel, décisions, questions en suspens et prochaine action.
- Éléments probants : enregistrements récupérés ou observations pertinentes pour cette action, avec leur provenance.
- Historique : événements antérieurs conservés pour la récupération, le débogage ou l’audit, mais omis sauf en cas de besoin.
Définissez ensuite une politique de promotion. Une observation peut rester éphémère, devenir un élément probant pour l’étape actuelle, mettre à jour l’état des croyances ou être écrite dans une mémoire durable. Toute promotion devrait avoir une raison. Sinon, la mémoire devient une archive non sélectionnée.
Pour chaque étape de l’agent, consignez le paquet de contexte envoyé au modèle : ses catégories, sa taille approximative en tokens, ses filtres de récupération et sa version de compression. Cela permet de répondre à une question pratique lorsque le comportement change : le modèle a-t-il échoué, ou le système lui a-t-il présenté un monde erroné ?
Ce qu’il faut tester avant de déclarer la conception fiable
L’ingénierie du contexte nécessite des tests qui ciblent la gestion de l’information, et pas seulement la qualité de la réponse finale. Les cas utiles comprennent notamment :
- un fait critique placé au début, à la fin et au milieu d’un long historique ;
- deux sources contradictoires, dont l’une est plus récente que l’autre ;
- un résumé contenant un marqueur d’incertitude ;
- une réponse d’outil contenant un grand volume de texte sans pertinence ;
- une instruction malveillante intégrée à du contenu récupéré ;
- la réhydratation de l’état après la mise en pause et le redémarrage de l’agent ;
- la même tâche avec un budget de contexte plus réduit ;
- un résultat de récupération vide ou obsolète.
Mesurez si l’agent sélectionne les bons éléments probants, préserve l’incertitude, respecte la contrainte actuelle et évite de répéter du contexte inutile. Les domaines de régression recommandés par le digest — perte de contexte, ancrage de la récupération, sortie structurée, non-terminaison et réhydratation de l’état — sont particulièrement pertinents ici.
Effectuez plusieurs essais lorsque la variabilité du modèle est importante, et comparez le coût et la latence de chaque stratégie de contexte. Un prompt plus court n’est pas automatiquement meilleur s’il entraîne davantage d’appels d’outils ou de nouvelles tentatives. L’objectif utile est le coût d’un flux de travail correct et récupérable, et non le nombre de tokens d’une seule requête.
La conséquence pour les carrières : l’ingénieur du contexte est un rôle transversal
Les personnes qui deviendront précieuses dans ce domaine ne seront pas nécessairement celles qui écrivent les prompts les plus longs. Elles sauront traduire un processus métier en état, éléments probants, autorité et règles de décision.
Cela exige plusieurs compétences concrètes :
- concevoir des schémas pour l’état des tâches et la provenance ;
- rédiger des politiques de récupération et des filtres de métadonnées ;
- construire des routines de compression et de sélection des observations ;
- séparer les instructions fiables du contenu non fiable ;
- le profilage de l’utilisation des tokens, de la latence, des nouvelles tentatives et des appels d’outils ;
- tester la perte d’état et la réhydratation ;
- expliquer aux non-spécialistes pourquoi un agent a vu — ou n’a pas vu — un fait particulier.
Un projet de portfolio solide pourrait présenter le même agent avec trois politiques de contexte : la transcription complète, le résumé glissant et l’état de croyance structuré avec récupération ciblée. Montrez les cas de réussite de la tâche, les cas d’échec, le contexte envoyé à chaque étape, ainsi que les compromis en matière de coût ou de latence. Cela est plus convaincant qu’une démonstration de chatbot, car cela révèle les choix de conception qui rendent un agent fiable.
La leçon stratégique est simple : les agents ne deviennent pas cohérents simplement parce que les modèles deviennent plus performants. Ils deviennent cohérents lorsque les systèmes qui les entourent tiennent à jour une représentation disciplinée, actuelle et correctement dimensionnée du travail. L’ingénierie du contexte consiste à élaborer cette représentation — et à savoir quoi en exclure.
Priya Raman est la rédactrice humaine responsable de AI Career Brief.
