Context Engineering : comment optimiser ce qu'on envoie à un LLM
La fenêtre de contexte ne peut pas tout contenir. Priorité par message, budget tokens, compression extractive et nettoyage : le pipeline qui choisit quoi garder.
8 min de lecture
Tu as un agent IA qui marche. Il a sa mémoire, ses outils, son prompt bien rédigé.
Mais à chaque appel, tu envoies tout. L'historique complet. Les consignes. Les résultats d'outils. Et ta facture explose.
Le context engineering, c'est l'art de choisir quoi envoyer au LLM et quoi sacrifier, quand la fenêtre de contexte ne peut pas tout contenir.
C'est le sujet dont tout le monde parle en 2025, et c'est probablement le skill le plus sous-estimé quand on build des agents IA.
Le principe : tout ne rentre pas
Un LLM a une fenêtre de contexte limitée. C'est le nombre maximum de tokens qu'il peut traiter en un seul appel.
Même avec 128 000 tokens (GPT-4o), ton prompt se remplit vite :
┌─────────────────────────────────────────┐
│ Fenêtre de contexte (100%) │
│ │
│ ┌───────────────────────────────┐ │
│ │ System prompt + consignes │ 15% │
│ ├───────────────────────────────┤ │
│ │ Description des outils │ 10% │
│ ├───────────────────────────────┤ │
│ │ Historique des messages │ 50% │ ← le gros morceau
│ ├───────────────────────────────┤ │
│ │ Résultats d'outils (RAG, web) │ 15% │
│ ├───────────────────────────────┤ │
│ │ Question + place réponse │ 10% │
│ └───────────────────────────────┘ │
└─────────────────────────────────────────┘
Quand ça déborde, tu as deux options :
- Ne rien faire : l'API tronque ou plante
- Choisir consciemment ce qui reste et ce qui part
Le context engineering, c'est l'option 2.
Étape 1 : Tout a une priorité
Tous les messages ne se valent pas. En context engineering, on assigne un poids à chaque type de message :
system (poids 10) → "Qui tu es, tes règles"
developer (poids 8) → "Comment répondre"
user (poids 6) → "Ce que l'utilisateur demande"
assistant (poids 4) → "Ce que tu as déjà répondu"
Le system prompt ne doit jamais être sacrifié. C'est lui qui définit le comportement de l'agent. Si tu le perds, le LLM oublie ses consignes, un bug classique en prod que presque tout le monde rencontre sur les conversations longues.
À l'inverse, les anciennes réponses de l'assistant sont les premières à sauter. Elles sont utiles pour le contexte, mais sacrifiables.
Étape 2 : Le budget tokens
Avant d'envoyer quoi que ce soit au LLM, tu comptes.
L'heuristique de base pour estimer les tokens :
1 token ≈ 4 caractères
"Bonjour, comment ça va ?"
= 25 caractères
≈ 7 tokens
C'est une approximation, mais elle suffit pour du budget management. En prod, tu utiliserais un tokenizer exact (comme tiktoken pour OpenAI), mais le principe reste le même.
Le workflow :
1. Compter les tokens de chaque message
2. Comparer au budget disponible
3. Si ça dépasse → sélectionner par priorité
4. Vérifier que ça rentre
5. Envoyer
L'algorithme de sélection est glouton (greedy) : tu tries les messages par score décroissant, tu les ajoutes un par un tant que le budget le permet, puis tu remets tout en ordre chronologique.
Étape 3 : Compresser sans LLM
C'est la partie la plus intéressante. Quand un bloc de texte est trop long, un résultat de recherche, un vieux résumé, un document, tu peux le compresser sans appeler de LLM.
Comment ? Avec de la compression extractive : tu scores chaque ligne du texte et tu gardes les meilleures.
Le scoring
Chaque ligne reçoit un score basé sur des signaux simples :
La ligne est un titre (# ou ** ou -) ? → +2 points
La ligne contient un chiffre ? → +1 point
La ligne contient un nom propre ? → +1 point
Exemple concret
Un rapport de réunion de 12 lignes qu'on doit compresser à 5 :
# Rapport de réunion → score 2 (titre)
Introduction générale sur le projet → score 0
- Objectifs atteints à 85% → score 3 (titre + chiffre)
Discussions diverses sur l'équipe → score 0
- Budget de 150 000 euros alloué → score 3 (titre + chiffre)
Commentaires généraux → score 0
# Décisions importantes → score 2 (titre)
- Lancement prévu le 15 mars 2025 → score 3 (titre + chiffre)
Autres remarques sans importance → score 0
Marie Dubois sera responsable technique → score 1 (nom propre)
- Budget supplémentaire de 25 000 euros → score 3 (titre + chiffre)
Conclusion générale du rapport → score 0
Résultat après compression (les 5 meilleurs scores, remis en ordre) :
- Objectifs atteints à 85%
- Budget de 150 000 euros alloué
# Décisions importantes
- Lancement prévu le 15 mars 2025
- Budget supplémentaire de 25 000 euros
Les lignes "blabla" (introduction, commentaires, conclusion) ont été éliminées. Les lignes avec des chiffres, des titres et des noms ont survécu.
Pourquoi ne pas demander au LLM de résumer ?
| Compression extractive | Résumé par LLM | |
|---|---|---|
| Coût | 0, c'est du code | Un appel API payant |
| Vitesse | Instantané | 1 à 3 secondes |
| Déterminisme | Même entrée = même sortie, toujours | Peut varier à chaque appel |
| Fiabilité | Copie les lignes telles quelles, impossible d'halluciner | Peut déformer un chiffre ou un nom |
En prod, tu veux que la couche de compression soit gratuite, rapide, et prévisible. Le LLM intervient après, sur un contexte déjà nettoyé.
Étape 4 : Nettoyer avant d'envoyer
Deux opérations de nettoyage que les gens oublient souvent :
Déduplication
Dans une longue conversation, le même message peut apparaître plusieurs fois (retry, bug côté client, boucle d'agent). Chaque doublon gaspille des tokens pour rien.
La règle : on parcourt les messages de la fin vers le début, et on garde uniquement la première occurrence (= la plus récente). Les doublons anciens disparaissent.
Traçabilité des citations
Quand un message cite une source (un lien Wikipédia, un document interne), les messages suivants qui n'ont pas de source héritent de cette citation.
Message 3 : "Selon wikipedia.org, le PIB est de..." → source: wikipedia
Message 4 : "Donc le PIB par habitant serait..." → pas de source
→ hérite de la source du message 3
C'est critique en entreprise. Quand un manager demande "d'où vient ce chiffre ?", tu veux pouvoir remonter la chaîne. Le context engineering inclut la provenance des informations, pas seulement leur contenu.
Le pipeline complet
Les étapes forment une chaîne. Voici l'ordre dans lequel le contexte est préparé avant chaque appel au LLM :
Conversation brute
│
▼
┌─────────────────────┐
1. │ Composer le prompt │ System + Developer + User
└──────────┬──────────┘
▼
┌─────────────────────┐
2. │ Sélectionner la │ Rolling (récent)
│ mémoire │ + Episodic (important)
└──────────┬──────────┘
▼
┌─────────────────────┐
3. │ Nettoyer │ Déduplication
│ │ + Citations
│ │ + Compression extractive
└──────────┬──────────┘
▼
┌─────────────────────┐
4. │ Packer sous budget │ Scoring + sélection gloutonne
│ │ + remise en ordre chrono
└──────────┬──────────┘
▼
Envoi au LLM ✅
Chaque étape réduit la taille du contexte tout en préservant la qualité de l'information. Le LLM ne reçoit que le nécessaire — propre, priorisé, dans le budget.
Le takeaway
Tu vas forcément perdre de l'info. La fenêtre de contexte est limitée, c'est une contrainte physique.
La vraie question n'est pas "comment tout garder ?" mais "est-ce que tu choisis consciemment quoi garder, ou tu laisses le LLM tronquer au hasard ?"
Le context engineering, c'est choisir. Et c'est souvent plus impactant que le choix du modèle lui-même.
Sujets abordés
- IA
- LLM
- context engineering
- agents
- TypeScript