Aller au contenu principal
Context engineering : 8 patterns que j'utilise en 2026
Retour au blog
IA

Context engineering : 8 patterns que j'utilise en 2026

Patrice Huetz11 avril 20266 min

Le « prompt engineering » est mort depuis 2025. Ce qui le remplace, c'est le « context engineering » — l'art de décider quelles informations injecter dans la fenêtre de contexte d'un LLM, dans quel ordre, et sous quelle forme. J'ai construit un Code Buddy perso qui tourne depuis 6 mois en prod, et j'y ai intégré 8 patterns de context engineering qui marchent vraiment. Voici chacun, le code minimal pour le reproduire, et le cas où il casse.

Pourquoi le prompt ne suffit plus

En 2024, on croyait qu'un bon prompt bien formulé suffirait à obtenir un bon résultat. En 2026, avec des modèles à 1M de tokens et des agents qui tournent sur des heures, le problème n'est plus « comment formuler la question » mais « comment sélectionner les 50 000 tokens les plus utiles parmi les 5 millions disponibles ».

Mon Code Buddy, c'est un agent qui répond à des questions sur ma codebase de 48 000 lignes. Le naïf du débutant : tout mettre dans le contexte. Résultat : 3 secondes de latence, 12 $ par question, et des réponses souvent moins bonnes qu'avec un contexte plus petit mais mieux ciblé. Moins de contexte de qualité bat plus de contexte brut. C'est la première leçon.

ℹ️
Un contexte de 50 000 tokens bien choisis bat un contexte de 500 000 tokens en bulk. Toujours.

Les 8 patterns, par ordre d'impact

Architecture context engineering — Code Buddy
Architecture context engineering — Code Buddy

Pattern 1 : hiérarchie sémantique (impact ++)

Au lieu de balancer des fichiers bruts, je les structure en 3 niveaux :

  • L1 : résumé du fichier en 2-3 lignes (toujours injecté)
  • L2 : signatures des fonctions publiques (injecté si le fichier est pertinent)
  • L3 : code complet (injecté seulement si la question cible explicitement ce fichier)
python
def build_context(query, files):
    ctx = [f["summary"] for f in files]  # L1 always
    relevant = rank_files(query, files)[:10]
    for f in relevant[:5]:
        ctx.append(f["signatures"])  # L2
    for f in relevant[:2]:
        ctx.append(f["full_code"])  # L3
    return "\n\n".join(ctx)

Gain mesuré : 62% de réduction de tokens, 14% d'amélioration de qualité (mesurée sur 200 questions test).

Pattern 2 : pinned context (impact ++)

Certaines choses doivent toujours être présentes : la consigne initiale, la stack technique, les contraintes critiques. Je les épingle en tête de prompt, explicitement marquées.

# PINNED CONTEXT
Projet : patricehuetz.fr (Next.js 16, Turso, Claude Sonnet 4.5)
Règle : ne jamais proposer de libs externes sans me demander
Fichier actuellement édité : src/app/blog/[slug]/page.tsx

# HISTORIQUE COMPACTÉ
...

Effet : même après 30 tours, l'agent ne « oublie » pas les contraintes initiales.

Pattern 3 : expansion paresseuse (impact +)

Au lieu de pré-calculer tous les imports d'un fichier, je fournis au début juste le code + les signatures des imports. Si l'agent a besoin du détail d'un import, il appelle un outil expand_import(name) qui retourne le contenu. Économie : 40% de tokens sur les prompts longs.

Pattern 4 : slot-based templating (impact +)

Mon prompt a des slots fixes :

{system_rules}
{pinned_context}
{retrieved_snippets}
{conversation_history_compacted}
{current_question}

Chaque slot a un budget en tokens. Si un slot dépasse, on tronque ce slot uniquement, jamais les autres. Ça garantit que les infos critiques ne sont jamais sacrifiées pour laisser passer du bruit.

Pattern 5 : rerank après retrieve (impact ++)

Mon RAG retourne 20 chunks candidats via embedding, puis un reranker (Cohere rerank-3) réordonne et garde les 5 meilleurs. Sur mes benchmarks, +19% de rappel pour 50 ms de latence additionnelle et 0,0004 $ par requête.

python
from cohere import Client
co = Client()

def rerank_chunks(query, chunks, top_k=5):
    response = co.rerank(model="rerank-3", query=query, documents=chunks, top_n=top_k)
    return [chunks[r.index] for r in response.results]

Pattern 6 : compaction par ancienneté (impact ++)

Dans les conversations longues, je garde les 5 derniers tours en entier et je compacte tout ce qui est plus ancien en résumé d'une ligne. Déjà détaillé dans mon article sur les agents qui bouclent — c'est le fix numéro 1 contre le context rot.

Pattern 7 : hints déterministes (impact +)

Parfois on sait d'avance ce qui compte. Si la question contient « test », on injecte automatiquement le dossier tests/. Si elle contient « db » ou « schema », on injecte drizzle/schema.ts. Un tableau statique de mots-clés → dossiers associés.

python
HINTS = {
    r"\btest\w*\b": ["tests/"],
    r"\bdb|database|schema\b": ["drizzle/schema.ts", "drizzle/queries/"],
    r"\bauth\w*\b": ["src/lib/auth.ts", "src/middleware.ts"],
}

Ça capture les 80% des cas où le ranking par embedding est sous-optimal.

Pattern 8 : tool-specific context (impact +)

Quand l'agent appelle un outil, il ne reçoit pas tout le contexte de la conversation — seulement ce qui est pertinent pour cet outil. Exemple : si l'agent appelle run_tests(), il reçoit le résultat brut, pas 12 000 tokens d'historique. Résultat : l'outil peut répondre rapidement sans payer le coût du contexte complet.

Les résultats cumulés sur Code Buddy

VersionTokens moyensLatence p50Coût/requêteQualité (1-5)
Naïf (tout en bulk)128 0002 840 ms3,80 $3,2
+ Hiérarchie sémantique48 0001 410 ms1,44 $3,7
+ Pinned + rerank52 0001 620 ms1,56 $4,1
+ Compaction + tous les patterns39 0001 180 ms1,17 $4,3

Passer de 3,80 $ à 1,17 $ par requête, tout en améliorant la qualité, c'est ce qui m'a convaincu d'investir dans le context engineering plutôt que d'ajouter des prompts plus sophistiqués.

Les 2 patterns qui ne marchent pas chez moi (mais marchent ailleurs)

Pattern « graph-based context »

L'idée : représenter la codebase comme un graphe (imports, références) et faire du graph traversal pour le contexte. J'ai essayé avec tree-sitter + networkx. Résultat : belle théorie, mais sur une codebase Next.js avec plein de dynamic imports et de fichiers barrel, le graphe est incomplet et trompeur. Abandonné après 2 semaines.

Pattern « multi-shot examples »

L'idée : injecter 5-10 exemples de questions/réponses similaires en few-shot. Ça marche bien sur des tâches bien cadrées (classification, extraction). Sur une conversation technique ouverte comme un Code Buddy, ça dégrade la qualité parce que les exemples influencent le style de réponse. J'ai mesuré -8% sur mes tests.

⚠️
Les patterns marketing comme le « graph RAG » ne sont pas des solutions magiques. Teste-les sur **ton** workload avant de t'y engager.

Ce qu'il faut retenir

  1. 1.Moins de contexte de qualité bat plus de contexte brut. Toujours.
  2. 2.6 patterns sur 8 donnent un gain mesurable dans la plupart des setups agent.
  3. 3.Rerank + hiérarchie sémantique sont les 2 patterns à implémenter en premier — 80% du gain.
  4. 4.Teste sur ton workload — les patterns à la mode (graph RAG, multi-shot) ne marchent pas partout.

Pour aller plus loin sur l'architecture d'un Context Engine complet type Code Buddy, j'ai écrit un livre sur les mécanismes de mémoire et de contexte des LLM :

La Mémoire des Machines
La Mémoire des Machines

Du KV-Cache au Context Engineering.

Découvrir →
🔒

Soutenez mon travail sur Patreon

Accès anticipé aux articles, contenu exclusif, et la satisfaction de soutenir un auteur indépendant.

Rejoindre — à partir de 3€/mois

Commentaires

Chargement des commentaires...

Laisser un commentaire