Context engineering vs RAG, fine-tuning et MCP : le guide de décision que personne ne vous a donné

Il y a un scénario que les architectes IA vivent en boucle. Une équipe constate que ses agents hallucinent sur les standards internes. Diagnostic immédiat : "il faut du RAG." On monte une pipeline d'embeddings, un vector store, un système de chunking. Six semaines plus tard, les hallucinations n'ont pas disparu — elles ont changé de forme. Le coût d'infrastructure a doublé. Et la latence des réponses s'est allongée.

Ce n'est pas un problème de RAG. C'est un problème de diagnostic. La bonne question n'était pas "comment récupérer la connaissance ?", mais "comment structurer l'environnement cognitif de l'agent ?" Ces deux questions n'ont pas les mêmes réponses, pas les mêmes outils, pas les mêmes coûts.

En 2026, les équipes qui construisent avec des agents IA disposent de quatre grandes familles de réponses : le context engineering, le RAG, le fine-tuning et le MCP. Chacune répond à un problème distinct. Les confondre — ou pire, les opposer — est une faute d'architecture. Ce guide est un outil de décision, pas un manifeste pour l'une d'elles.

Quatre outils, quatre problèmes — commençons par ne pas les mélanger

Avant d'arbitrer, il faut poser des définitions nettes.

Context engineering : structurer l'environnement cognitif de l'agent

Le context engineering ne se réduit pas au prompt. Andrej Karpathy, qui a popularisé le terme, le définit comme "l'art et la science de remplir la fenêtre de contexte LLM avec les bonnes informations." La nuance est dans "les bonnes" : pas toutes, pas n'importe lesquelles, les bonnes — au bon moment, dans le bon ordre.

La distinction avec le prompt engineering est documentée et concrète. Le prompt engineering optimise une interaction isolée, avec une mémoire éphémère limitée à une session, et produit un retour sur investissement linéaire. Le context engineering optimise l'environnement global, maintient une mémoire persistante cross-sessions, et produit un retour sur investissement composé.¹

Patrick Debois, inventeur du DevOps, résume le problème fondamental que le context engineering résout : "Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir." La mémoire persistante est précisément ce que ni le RAG, ni le fine-tuning, ni MCP ne construisent par défaut.

RAG : récupérer à la volée depuis une base externe

Le RAG (Retrieval-Augmented Generation) répond à un problème précis : accéder à un corpus de connaissance volumineuse qui dépasse la fenêtre de contexte, de manière dynamique, sans ré-entraîner le modèle. C'est son territoire légitime. Mais il porte cinq défis structurels bien documentés : le chunking (la fragmentation artificielle du sens contextuel), les embeddings (les limitations sémantiques inhérentes à la vectorisation), la hybrid search (complexité ajoutée), le reranking (latence et coût supplémentaires) et la gestion d'infrastructure (croissante et coûteuse).²

Fine-tuning : graver un comportement dans les poids

Le fine-tuning modifie les poids du modèle pour lui faire adopter un style, une terminologie ou un comportement très spécialisé. Il est pertinent quand le comportement est stable dans le temps, fréquent, et où le coût du cycle d'entraînement est justifié par le volume d'utilisation. Son problème fondamental : il ne se met pas à jour sans relancer un cycle d'entraînement. Et il ne peut pas personnaliser session par session.

MCP : brancher des outils en temps réel

Le Model Context Protocol connecte l'agent à des systèmes externes — APIs, bases de données, outils métier. Il résout un problème d'action, pas un problème de connaissance. Un agent avec MCP peut envoyer un email, interroger une base de production, déclencher un workflow. Mais s'il n'a pas de contexte structuré pour savoir quand et pourquoi appeler quel outil, il improvise — et l'improvisation des agents sans contexte, c'est l'hallucination d'outil.

Ce que le context engineering fait que les trois autres ne font pas

La confusion vient souvent d'une vision binaire : on pose le context engineering en concurrent du RAG ou du fine-tuning. Ce n'est pas la bonne grille.

Le context engineering est une couche orthogonale. Il structure ce que le RAG récupère. Il fournit le cadre dans lequel MCP exécute. Il comble ce que le fine-tuning ne peut pas personnaliser — la dimension session, projet, utilisateur.

L'architecture 3 tiers et ce que le RAG ne fait pas

Vasilopoulos a formalisé l'architecture de mémoire de l'agent en trois tiers¹ :

• Hot Memory (Constitution) : toujours chargé. Les conventions, la culture, les contraintes permanentes de l'agent. Charge zéro à la requête.
• Warm Memory (Agents Spécialisés) : experts invoqués à la demande. 50% de faits, peu de directives. Chargement conditionnel.
• Cold Memory (Knowledge Base) : savoir de référence massif — specs, docs, corpus — tiré uniquement au besoin.

Le RAG opère principalement au niveau du Cold tier : il récupère depuis une base externe au moment de la requête. Mais il ne maintient pas la Hot Memory — les conventions permanentes de l'agent. Il ne gère pas non plus la Warm Memory — les agents spécialisés chargés dynamiquement selon la tâche. Ces deux niveaux sont du ressort du context engineering.

L'inversion de la complexité : le gain composé

C'est ici que le context engineering se distingue le plus radicalement de ses alternatives. L'ingénierie traditionnelle produit une complexité croissante : chaque feature rend la suivante plus difficile (dette technique). Le Compound Engineering — la pratique du context engineering sur la durée — produit une complexité décroissante : chaque feature rend la suivante plus facile (boucle d'apprentissage), d'après Shipper & Klaassen (2025).

La boucle concrète : Planifier (produire du contexte structuré que l'agent peut consommer) → Exécuter & Évaluer (le travail représente environ 10% du temps, la validation environ 40%) → Composer (chaque bug et insight documenté pour les cycles futurs — "l'étape magique").¹

Le résultat mesuré : une vélocité ×5 — un développeur bien outillé équivaut à cinq développeurs traditionnels — pour un coût de maintenance de l'ordre de 1 à 2 heures par semaine.¹ Patrick Debois formule la dimension stratégique : les modèles se commoditisent, les outils convergent — mais "la connaissance produit accumulée — cas limites catalogués, besoins utilisateurs cartographiés, raisonnement domaine encodé — crée un avantage que les concurrents ne peuvent pas répliquer".³

RAG : ni mort ni universel — la tension en chiffres

Le débat "RAG vs context engineering" est en partie un faux débat. La vraie question est : pour quel volume de connaissance, avec quelle fréquence de mise à jour, et à quel coût ?

Philippe Ensarguet a posé la thèse provocatrice en octobre 2025 : "RAG was never the destination — it was a temporary detour." L'argument : les fenêtres de contexte des modèles modernes ont évolué de 8K tokens en 2022 vers des tailles permettant d'y charger directement des corpus entiers — certains modèles supportent jusqu'à 1 million de tokens. À ce volume, le besoin de chunking et d'indexation vectorielle s'atténue pour de nombreux cas d'usage.

Mais Leonie Monigatti (2025) nuance avec une évolution documentée : RAG vanilla → Agentic RAG → Agent Memory. Dans l'Agentic RAG, l'agent décide lui-même quand et si récupérer (la question passe de "comment récupérer ?" à "est-ce que je dois récupérer ?"). Dans l'Agent Memory, l'agent peut désormais écrire dans sa base de connaissance — opérations lecture-écriture bidirectionnelles — ce qui rapproche le RAG du context engineering, au prix de nouveaux risques : corruption mémoire, versioning, conflits.⁴

Patrick Debois tranche sur le fond : des fenêtres de contexte infinies ne suppriment pas le besoin de structurer le contexte. Elles "transforment le défi de la curation en défi de gouvernance, potentiellement plus complexe".⁵

Quand RAG reste le bon choix : corpus juridique ou normatif de plusieurs dizaines de milliers de documents mis à jour fréquemment ; connaissance tierce dont vous n'avez pas le contrôle éditorial ; réponse à des questions ponctuelles sur un corpus fermé et stable. Quand RAG ne suffit pas : maintenir la cohérence entre sessions, encoder des conventions d'équipe, construire un avantage cumulé sur la durée.

Fine-tuning : ce que le contexte ne remplacera jamais — et ce qu'il fait mieux

Le fine-tuning a une niche légitime et difficile à challenger : le comportement ultra-spécialisé, stable dans le temps, avec un volume d'utilisation qui amortit le coût du cycle d'entraînement. La terminologie médicale très précise, le style rédactionnel d'une marque exigeant une parfaite uniformité à grande échelle, les patterns de code d'un secteur réglementé avec des contraintes figées.

Là où le fine-tuning montre ses limites : la personnalisation par session (impossible sans ré-entraîner), la mise à jour en temps réel, et — surtout — le coût de la rigidité.

Des chercheurs de Stanford, SambaNova Systems et UC Berkeley ont publié en octobre 2025 le framework ACE (Agentic Context Engineering, arXiv 2510.04618). Leur thèse : le contexte évolutif est une alternative viable au fine-tuning pour de nombreux cas. L'architecture ACE (Generator → Reflector → Curator) permet une adaptation contextuelle sans labels ground-truth, avec une amélioration mesurée de +10,6% sur des benchmarks agents standards et +8,6% sur des tâches de raisonnement financier, pour une réduction de la latence d'adaptation de 86,9% en moyenne.⁶ ACE nomme deux pathologies à éviter : le brevity bias (compression excessive du contexte, perte de nuances) et le context collapse (dégradation qualité sur itérations).

Le CDLC de Patrick Debois le formule différemment : le context engineering opère à trois niveaux que le fine-tuning ne peut pas adresser simultanément — le niveau technique (standards, patterns), le niveau projet (priorités, scope du sprint) et le niveau business (conformité, attentes client). La plupart des équipes ne fournissent que le premier. Le fine-tuning ne fournit que le premier. Le context engineering structure les trois.⁵

La règle de décision : fine-tunez quand le comportement est gravé dans le marbre et que le volume justifie le coût du cycle. Structurez le contexte quand vous avez besoin de personnalisation par session, de mise à jour fréquente, ou d'un effet cumulatif.

MCP : l'outillage ne remplace pas la carte

Le Model Context Protocol résout un problème distinct et réel : permettre à l'agent d'agir sur le monde réel — appeler une API, lire une base de données, envoyer une notification. C'est de l'action, pas de la connaissance.

La confusion arrive quand on imagine que "donner des outils à l'agent" est équivalent à "lui donner le contexte pour bien les utiliser." Ce n'est pas le cas.

Rod Johnson, créateur du Spring Framework et fondateur d'Embabel, formule le problème dans son article sur DICE (Domain-Integrated Context Engineering) : MCP propose des interactions "semi-typées" qui perdent de la fidélité par rapport à des domain objects bien définis.⁷ Un agent avec dix outils MCP et un contexte vide hallucine sur quel outil appeler, dans quel ordre, et dans quel cas d'usage. Le contexte structure la décision ; MCP l'exécute.

La complémentarité est réelle : MCP devient puissant quand le contexte Hot Memory encode quels outils l'agent doit utiliser pour quels types de tâches, et quand les agents Warm Memory spécialisés sont configurés pour orchestrer les appels MCP de façon cohérente. Sans ce fond, MCP ajoute de la surface d'attaque — chaque outil est un vecteur potentiel d'injection ou d'exfiltration — sans garantie d'usage raisonné. Le contexte structure la sécurité autant que la performance.

La matrice de décision : choisir, combiner, séquencer

Voici la grille synthétique pour arbitrer. Elle n'est pas exclusive — les meilleurs systèmes combinent plusieurs couches.

Outil	Problème résolu	Coût principal	Quand ne pas utiliser seul
Context engineering	Environnement cognitif persistant, mémoire cross-sessions, ROI composé	1-2 h/semaine de maintenance	Jamais : c'est la couche de base
RAG	Corpus volumineuse et dynamique dépassant la fenêtre de contexte	Infrastructure (chunking, vector store, reranking), latence	Quand le corpus rentre en contexte ; quand la mise à jour est rare
Fine-tuning	Comportement stable et très fréquent (style, terminologie figée)	Cycle d'entraînement, rigidité à la mise à jour	Quand le comportement change fréquemment ; quand le volume ne justifie pas le coût
MCP	Actions live sur systèmes externes	Surface d'attaque, orchestration, latence réseau	Sans contexte Hot Memory pour guider les appels

Les combinaisons qui fonctionnent

Context engineering + RAG : le contexte Hot Memory charge les conventions permanentes ; le RAG tire la connaissance volumineuse à la demande depuis le Cold tier. Les deux coexistent naturellement dans l'architecture 3 tiers — ce sont deux couches distinctes. Rod Johnson le confirme avec DICE : la "structured persistence" via SQL ou Cypher peut compléter le vector search pour plus de précision.⁷

Context engineering + MCP : le contexte guide quels outils appeler et dans quels cas ; MCP exécute. C'est la combinaison qui produit des agents véritablement fiables en production — le contexte encode la décision, MCP encode l'action.

Context engineering + fine-tuning : le fine-tuning grave le style et la terminologie du domaine ; le contexte apporte la dimension projet, session, et les conventions évolutives. Ce n'est pas une redondance — c'est une complémentarité de couches temporelles : le fine-tuning pour ce qui ne change pas, le contexte pour ce qui évolue.

L'ordre de mise en œuvre recommandé

Ne pas commencer par le RAG ni par le fine-tuning. Commencer par le context engineering : ROI immédiat, coût faible, effet composé. Ajouter le RAG quand la connaissance dépasse la fenêtre de contexte disponible. Ajouter le fine-tuning quand le comportement est stabilisé et que le volume d'utilisation le justifie. Connecter MCP quand l'agent doit agir sur des systèmes externes — avec un contexte Hot Memory qui guide ces actions.

Le traitement du contexte comme une dépendance logicielle — versionnée, testée, distribuée comme un package — est la pratique que Debois appelle le CDLC : Générer (rendre l'implicite explicite), Évaluer (TDD du contexte), Distribuer (package versionné), Observer (boucle de feedback).¹

Ce que SFEIR observe : le context engineering n'est pas une étape, c'est le socle

Dans les missions SFEIR, le schéma récurrent n'est pas l'échec du RAG ou du fine-tuning en eux-mêmes — c'est leur adoption dans un vide de context engineering. Les agents sont outillés avant d'être contextualisés. Le résultat : des agents capables d'agir, mais sans la structure qui rend l'action cohérente et prévisible.

La progression que SFEIR documente — prompt engineering → context engineering → harness engineering — indique précisément l'ordre de maturité. Le context engineering est la couche intermédiaire sans laquelle le harness engineering (l'équation Agent = Model + Harness, avec les guides feedforward et les sensors feedback) ne peut pas produire ses gains documentés de 20+ points de performance à modèle égal.

La formule de Didier Girard est directe : "Le contexte est un actif, pas une dépense. L'ingénieur de demain ne sera pas celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte." Ce déplacement de valeur — de l'écriture du code vers l'architecture du contexte — est exactement ce que les quatre outils de ce comparatif éclairent par leur complémentarité.

Pour approfondir l'architecture 3 tiers de la mémoire, lire Architecture 3-tier du contexte : Hot, Warm et Cold Memory. Pour la dimension financière du budget de tokens, Coût des tokens et context engineering : le FinOps du contexte. Pour le déploiement multi-agents, Context engineering pour les systèmes multi-agents. Et pour MCP en détail, MCP Tools : le protocole d'outillage des agents.

La vraie question n'est pas « lequel ? » mais « dans quel ordre ? »

Context engineering, RAG, fine-tuning, MCP : aucun de ces outils n'est le bon outil pour tout faire. Chacun répond à une couche du problème.

Le context engineering structure l'environnement cognitif persistant — la base. Le RAG complète avec la connaissance volumineuse que la fenêtre ne peut pas contenir. Le fine-tuning grave ce qui ne change pas. MCP connecte à l'action réelle.

La question n'est pas de choisir l'un contre les autres. C'est de les séquencer dans le bon ordre — en commençant par le socle, sans lequel les trois autres opèrent à l'aveugle.

Un agent contextualisé avec un RAG bien pensé, des outils MCP guidés par un contexte structuré, et un fine-tuning ciblé sur ce qui est vraiment stable : voilà un système robuste. Un agent avec du RAG, du MCP, un fine-tuning — mais sans context engineering — c'est un système puissant et incontrôlable.

La distinction vaut le temps qu'on prend à la faire avant de déployer.

Pour aller plus loin dans le cluster :

• Context Engineering : le guide complet — le pilier du cluster
• Architecture 3-tier du contexte — Hot, Warm, Cold Memory (Vasilopoulos)
• Maintenir le contexte avec le TDD et les évals — le contexte pourrit, voici comment le tester
• Sécuriser le contexte des agents IA — le contexte comme surface d'attaque
• MCP Tools — le protocole d'outillage des agents en détail

Sources

1. SFEIR (Didier Girard) — Context Engineering — L'art de nourrir les agents IA, matière first-party, mars 2026.
2. Philippe Ensarguet, From RAG to Rigor Mortis — linkedin.com, 8 octobre 2025.
3. Patrick Debois (Tessl), The Context Flywheel — tessl.io, 26 février 2026.
4. Leonie Monigatti, The Evolution from RAG to Agentic RAG to Agent Memory — leoniemonigatti.com, 3 novembre 2025.
5. Patrick Debois (Tessl), Context Development Lifecycle — tessl.io, 19 février 2026.
6. Zhang et al., Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models — arxiv.org, 7 octobre 2025.
7. Rod Johnson, Context Engineering Needs Domain Understanding — medium.com, 23 juillet 2025.