# Context engineering : budget, preuves et compaction des agents

> Organiser le contexte d’un agent IA : budget de tokens, état de tâche, sorties d’outils, références et compaction. Un exemple cyber et des tests de reprise.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/context-engineering-budget-compaction/

Le contexte est l’ensemble des informations effectivement présentées au modèle pour un appel : instructions, demande, historique utile, résultats d’outils et sources sélectionnées. Le *context engineering* organise cet ensemble au fil de la tâche. Ajouter des documents ne suffit pas à préserver ce qui doit guider la prochaine décision.

La [présentation d’Anthropic](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents) aborde cette sélection comme un problème d’ingénierie du contexte. Pour un agent cyber, nous proposons de partir d’un état vérifiable : périmètre autorisé, observations, hypothèses et actions encore nécessaires.

## Construire un budget mesurable

Un budget doit réserver de la place pour la sortie et pour les nouveaux résultats d’outils. La capacité annoncée d’un modèle n’indique pas combien de documents seront utiles pour votre tâche. Mesurez les entrées avec le tokenizer applicable ; un mot, un caractère et un token ne sont pas des unités interchangeables.

Voici un exemple de répartition de travail, avec des valeurs choisies pour l’exercice :

| Partie | Budget indicatif | Contenu |
| --- | --- | --- |
| Instructions et périmètre | 2 000 tokens | Objectif, interdictions et format attendu |
| État de tâche | 1 500 tokens | Décisions, blocages et prochaines étapes |
| Preuves sélectionnées | 4 000 tokens | Extraits utiles et références |
| Derniers échanges | 1 500 tokens | Corrections et actions récentes |
| Réserve | 3 000 tokens | Nouveaux outils et réponse |

Cette répartition n’est pas un seuil universel. Elle sert à rendre le budget visible. Un essai doit montrer quel élément est retiré ou déplacé lorsque la réserve diminue.

## Séparer la pièce, l’observation et la conclusion

Dans un exemple fictif de contrôle d’accès API, une pièce est une requête et sa réponse. L’observation peut être « le compte B a reçu ce document ». La conclusion « violation de séparation entre clients » exige aussi de savoir à qui appartient le document et quels droits le compte devait avoir.

Un état compact doit conserver ces différences. Résumer les trois niveaux en « faille confirmée » supprime les conditions nécessaires à la vérification. Une référence vers la pièce complète permet de reprendre le travail sans remettre tout son contenu dans chaque appel.

```json
{
  "objectif": "évaluer la séparation des organisations de démonstration",
  "observation": "le compte B reçoit le document D",
  "statut": "à vérifier",
  "preuve": "artefact:http-17",
  "manquant": "propriétaire attendu du document D"
}
```

## Compacter sans réécrire l’autorisation

Une compaction peut raccourcir une histoire et préserver un état de reprise. Elle ne doit pas élargir les actifs autorisés, transformer une demande encore ouverte en accord ou convertir une hypothèse en résultat.

Nous proposons de conserver le périmètre comme donnée protégée du système d’exécution et de référencer sa version dans le résumé. Une instruction issue d’un document consulté reste une donnée de cette source. Sa répétition dans un résumé ne lui donne pas un rôle supérieur.

Le travail [Lost in the Middle](https://arxiv.org/abs/2307.03172) montre des variations de performance selon la position de l’information dans les tâches et modèles étudiés. Il motive des tests de position ; il ne fournit pas un pourcentage de remplissage à partir duquel tous les modèles échouent.

## Vérifier la reprise après compaction

Préparez une histoire avec une exclusion en début de tâche, un changement de date au milieu et une pièce contradictoire à la fin. Après compaction, vérifiez si le système retrouve les trois éléments et cite leur origine. Ajoutez une demande qui exige de revenir à un artefact externe.

Conservez le résumé produit, les références perdues et la décision obtenue. Une baisse du nombre de tokens est un gain technique seulement si les informations nécessaires à la tâche restent accessibles. Une réserve remplie de texte redondant n’est pas une mémoire fiable.

La suite porte sur la [mémoire durable des agents](/research/memoire-agents-ia-cycle-vie/) et les [contrats entre agents](/research/systemes-multi-agents-contrats-orchestration/). Les sources et le reste de la série figurent dans le [dossier IA et cyber](/dossiers-ia-cyber/).