Context engineering — le nouveau nom du RAG evolue, et ce qu'on fait deja¶

Resume¶

Leonie Monigatti (@helloiamleonie, Weaviate, 1.4K likes, 98K vues) pose la question "Is context engineering the new RAG?" et propose une taxonomie en 3 eres :

• RAG (2020-2023) : retrieval one-shot. Pipeline fixe. Toujours retriever (meme quand pas necessaire). Une seule passe.
• Agentic RAG (2023-2025) : routing intelligent. Re-retrieval si insuffisant. Outils specialises. L'agent decide quand et quoi retriever.
• Context Engineering (2025+) : construction complete du contexte LLM, pas juste retrieval. Inclut : instructions, outils disponibles, historique, etat des taches, memoire structuree, outputs d'autres agents. Le retrieval est un sous-ensemble du context engineering, pas l'inverse.

Analyse critique¶

Ce qui est juste¶

La taxonomie est propre et reflete l'evolution reelle du domaine. Le terme "context engineering" est en train de devenir mainstream — Anthropic l'appelle "harness", nous on l'appelle "assemblage de prompt cache-first" dans workflow-rules.md. C'est le meme concept : construire le contexte LLM de maniere dynamique, structuree, et adaptee a la tache.

La distinction "RAG = retrieval" vs "context engineering = construction complete du contexte" est importante. Le RAG ne s'occupe que de "aller chercher de l'info pertinente". Le context engineering s'occupe de tout ce que le LLM voit quand il commence a travailler : les instructions, les outils, l'historique, l'etat courant, la memoire, les outputs d'autres agents, les garde-fous.

Ce qui manque¶

L'article ne mentionne pas les mecanismes de qualite du contexte : comment eviter de surcharger (trop de contexte = dilution de l'attention), comment verifier que le contexte est coherent (notre /coherence Prolog), comment mesurer si le contexte a aide (notre analyze-compounding.py). Le context engineering sans ces mecanismes est juste du "prompt stuffing" plus structure.

Pourquoi le vocabulaire compte¶

Le terme "context engineering" va s'imposer dans les 6 prochains mois. Si on veut communiquer sur notre approche (threads X, doc technique, pitch investisseurs), utiliser ce vocabulaire au lieu de "assemblage de prompt" donnera plus de resonance. Pas parce que c'est plus precis — c'est le meme concept — mais parce que c'est le mot que l'industrie commence a utiliser.

Pertinence ProbatioVault¶

Impact modere — pas en technique (on fait deja du context engineering sans le nommer), mais en communication.

Ce qu'on fait deja = context engineering¶

Notre scripts/lib/inject-docs.sh est un context engineer au sens strict de la taxonomie Monigatti :

Chaque appel a assemble_prompt dans inject-docs.sh construit dynamiquement le contexte en combinant ces 7 sources selon l'etape du workflow. C'est du context engineering, on ne l'appelait juste pas comme ca.

Ce que ca change en communication¶

Pour les threads X et la doc technique : - Remplacer "assemblage de prompt cache-first" par "context engineering pipeline" quand on parle a une audience externe - Le thread #6 (workflow 11 etapes) peut etre reformule comme "un pipeline de context engineering en 11 etapes avec verification formelle" - Le thread #8 (Prolog) peut etre positionne comme "verification de coherence dans le context engineering" - Le futur thread #9 (over-engineering) peut utiliser le terme pour critiquer les architectures RAG 5 couches : "ce n'est pas du context engineering, c'est du context bloating"

Action recommandee¶

Pas de changement technique. Adopter le vocabulaire "context engineering" dans la communication externe (threads X, doc archi, README). Ajouter une ligne dans CLAUDE.md ou docs/infrastructure-ia.md qui definit notre stack en ces termes pour que les futurs agents et contributeurs utilisent le bon vocabulaire.