RAG vs fine-tuning vs MCP : lequel choisir pour votre base de connaissances

"On fait du RAG ou du fine-tuning ?" — c'est la question qu'on entend dans 80 % de nos premiers RDV techniques. Depuis dix-huit mois, on a ajouté une variante : "et le MCP, ça remplace pas tout ça ?".

Spoiler : la question est mal posée. RAG et fine-tuning sont deux approches opposables. MCP est un protocole de connecteurs, pas une troisième voie. Mettre les trois sur le même plan, c'est comparer une cuisinière, un livre de recettes et une prise électrique.

Cet article remet les choses à plat. Pour un CTO de PME qui doit brancher 12 000 PDF métier, deux SharePoint et un Notion à Claude ou Mistral, voici comment on décide chez BUMPSLAB.

RAG en 90 secondes

Retrieval-Augmented Generation. Le principe est simple :

1. On découpe les documents en chunks (typiquement 500-1500 tokens).
2. On calcule un embedding pour chaque chunk, on les stocke dans un vector store (Pinecone, Qdrant, pgvector).
3. À chaque question, on cherche les chunks les plus pertinents et on les injecte dans le prompt avant la question.
4. Le LLM répond avec ce contexte sous les yeux.

Concrètement, un commercial demande dans Claude : "Quelles sont nos conditions de garantie pour la gamme XR-200 ?". Le système retrouve les 4 chunks pertinents dans le manuel produit + 2 chunks d'un mail de la direction technique de mars dernier, puis génère la réponse avec citations sourcées : "Selon le manuel XR-200 §4.2 (juin 2025)…".

Ce qu'on aime avec le RAG :

• Données fraîches : on met à jour l'index, pas le modèle. Un nouveau contrat ajouté à 15h est requêtable à 15h05.
• Traçabilité : chaque réponse cite ses sources. Indispensable en banque, assurance, compliance.
• Coût : pas d'entraînement, juste de l'inférence et du stockage vectoriel. Un setup PME tourne entre 80 et 400 CHF/mois selon le volume.

Là où ça pique : la qualité du RAG dépend à 70 % de la stratégie de chunking et du retrieval, pas du LLM. C'est là qu'on passe le plus de temps en mission. Un mauvais chunking transforme un manuel technique de 400 pages en bouillie sémantique, et aucun re-ranker ne sauvera la mise.

L'autre angle mort : la mise à jour. Re-indexer 50 000 documents quand le service compliance modifie un en-tête, ça se conçoit avec un pipeline incrémental dès le jour 1. Sinon, vous repartez de zéro tous les six mois.

Takeaway : si le besoin tient en "le modèle doit savoir ce que mes docs disent", RAG par défaut.

Fine-tuning en 90 secondes

Le fine-tuning, c'est modifier les poids d'un modèle pré-entraîné en lui montrant des exemples spécifiques (typiquement 500 à 50 000 paires entrée/sortie). On ne change pas ce que le modèle sait, on change ce qu'il fait avec ce qu'il sait.

Trois cas où ça vaut le coup :

• Style et ton métier : un fine-tune apprend à écrire des comptes-rendus d'assurance dans le format exact de la maison, avec le jargon validé par le service juridique. Un prompt ne le fera jamais aussi bien.
• Format de sortie strict : extraction de 47 champs depuis une facture, toujours dans le même JSON. Fine-tuner sur 2000 exemples bat n'importe quel prompt système.
• Latence ou coût d'inférence : un petit modèle fine-tuné (Mistral 7B, Llama 3.1 8B) peut remplacer Claude Sonnet sur des tâches étroites, à 10× moins cher.

Ce qu'on déteste :

• Coût caché de maintenance : à chaque drift métier (nouveau formulaire, nouvelle nomenclature), il faut relancer un entraînement. Compter 1 à 3 jours-homme par itération, plus le coût GPU.
• Le modèle "oublie" : un fine-tune sur 5000 exemples de comptes-rendus dégrade les capacités générales. On l'a vu mille fois.
• Pas de fraîcheur : ce que le modèle "sait" est figé au jour de l'entraînement.

Quelques ordres de grandeur tirés de nos missions : un fine-tune correct sur Mistral 7B coûte entre 600 et 3 000 CHF en GPU (chez Lambda Labs ou Scaleway) plus 5 à 15 jours-homme de préparation de données. Et ça, c'est par itération. Sur un projet sérieux, comptez 4 à 8 itérations avant la mise en prod.

Takeaway : fine-tuner pour le comment, pas pour le quoi. Si vous ne savez pas formuler "voici 1000 exemples parfaits de ce que je veux", vous n'êtes pas prêt.

MCP en 90 secondes

Model Context Protocol : standard ouvert publié par Anthropic fin 2024. Ce n'est ni un modèle, ni une base de données, ni une alternative au RAG. C'est un protocole, comme USB ou HTTP, qui standardise la façon dont un LLM se branche à des sources de données et à des outils.

Un serveur MCP expose :

• des resources (fichiers, pages Notion, documents SharePoint…),
• des tools (lancer une recherche, créer un ticket Jira, requêter une base SQL),
• des prompts (templates réutilisables).

Le LLM (Claude Desktop, Claude Code, n'importe quel client compatible) parle au serveur MCP via JSON-RPC. C'est tout.

Voici un serveur MCP minimal en TypeScript qui expose une fonction de recherche :

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 
const server = new Server(
  { name: "bumpslab-docs", version: "1.0.0" },
  { capabilities: { tools: {} } }
);
 
server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "search_docs",
      description: "Cherche dans la base de connaissances interne",
      inputSchema: {
        type: "object",
        properties: { query: { type: "string" } },
        required: ["query"],
      },
    },
  ],
}));
 
server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "search_docs") {
    const results = await searchVectorStore(req.params.arguments.query);
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
});
 
await server.connect(new StdioServerTransport());

Le point clé : ce serveur MCP fait du RAG. Le LLM appelle search_docs, le serveur fait le retrieval, renvoie les chunks, et le modèle génère sa réponse. MCP est le tuyau, RAG est ce qui coule dedans.

On peut aussi exposer via MCP un modèle fine-tuné, une API métier, une base SQL, ou un agent n8n. MCP est orthogonal au choix RAG/fine-tuning.

L'intérêt principal pour une PME : un serveur MCP écrit une fois est utilisable depuis Claude Desktop, Claude Code, Cursor, et bientôt depuis ChatGPT (OpenAI a annoncé le support début 2026). Plus besoin de réécrire un connecteur SharePoint pour chaque assistant IA déployé en interne.

Takeaway : si vous comparez "RAG vs MCP", arrêtez. Demandez plutôt "RAG via MCP ou via API custom ?".

La matrice de décision

Quatre critères qu'on utilise en atelier avec nos clients pour trancher :

Lecture rapide : pour 90 % des cas PME qu'on voit (banque privée, assurance, immobilier commercial, industrie), le tableau pointe vers RAG. Le fine-tuning ne devient pertinent que quand le format ou le style sont aussi importants que le contenu.

Les combos qu'on déploie

Dans la vraie vie, ce sont rarement des choix purs. Voici les trois architectures qu'on a déployées chez nos clients en 2025-2026.

Combo 1 — RAG + MCP (le plus fréquent)

L'archi par défaut. Un serveur MCP expose le vector store et quelques outils métier (créer ticket, envoyer mail). Claude Sonnet 4.6 côté utilisateur, Qdrant côté infra, le tout hébergé sur Infomaniak ou Scaleway.

Cas concret : un courtier en assurance romand, 240 collaborateurs. 18 000 contrats indexés, citations obligatoires (régulateur FINMA). Déployé en 6 semaines. Aucun fine-tuning. Adoption à 71 % du back-office après 4 mois.

Combo 2 — Fine-tuning + RAG (le combo de luxe)

Le RAG fournit les connaissances fraîches, le fine-tune impose le style ou le format.

Cas concret : une banque privée genevoise, génération de notes de marché hebdomadaires. RAG sur 4 ans d'archives de notes + flux Bloomberg. Fine-tune de Mistral Large sur 800 notes validées par le chef analyste. Résultat : la note "sonne maison" et utilise les chiffres du jour. 6 mois de mission, 11 itérations de fine-tune.

Combo 3 — Fine-tuning seul (rare, justifié 1 fois sur 20)

Quand on a un volume écrasant d'exemples et un domaine fermé. Typiquement : classification de tickets support en 47 catégories, extraction de champs sur des formulaires fiscaux normés.

On a vu des clients vouloir fine-tuner "parce que c'est plus sérieux que le RAG". À chaque fois, c'est un POC qui finit au cimetière. On en parle dans pourquoi les POC IA échouent.

Le piège typique : un comité de direction qui confond "le modèle apprend nos données" avec "on injecte les bonnes données au bon moment". Le premier sonne plus impressionnant en COMEX, le second marche en production.

Takeaway : 80 % RAG+MCP, 15 % combo, 5 % fine-tune seul. Faites les comptes après deux ans, on parie sur la distribution.

Notre choix par défaut chez BUMPSLAB

Quand un client arrive sans contraintes spécifiques, voilà notre stack de référence :

• LLM : Claude Sonnet 4.6 pour la production, Mistral Large 2 quand la souveraineté CH/FR est imposée par le DPO.
• Vector store : Qdrant en self-hosted sur Infomaniak (Suisse) pour la majorité des clients ; Pinecone Serverless quand le client accepte un cloud US managé.
• Embeddings : voyage-3 ou mistral-embed selon la langue dominante.
• Connecteurs : MCP partout. Un serveur par source (SharePoint, Notion, base SQL métier, GED).
• Chunking : recursive avec overlap, taille adaptée au domaine (1200 tokens pour juridique, 500 pour FAQ).
• Eval grid : 80 à 200 questions de référence, scorées en aveugle par 2 experts métier avant mise en prod. Pas de mise en prod sans grid verte.

Le fine-tuning n'arrive qu'à la phase 3, après 3 à 6 mois de RAG en production, et seulement si l'eval grid montre un plafond clair sur le style ou le format.

Sur le tooling, on évite la sur-ingénierie. Pas de LangChain en prod (trop d'abstraction pour ce qu'on fait), pas de framework maison "qui couvre tous les cas". Du code Python ou TypeScript lisible, un orchestrateur n8n quand il y a des workflows métier, et c'est tout. Notre produit Atlas est construit sur cette même base : ce qui doit être custom l'est, ce qui peut être standard l'est aussi.

Pour les détails de l'architecture connecteurs, on a écrit un article dédié sur MCP expliqué.

Une question piège avant de fine-tuner

Si vous lisez cet article parce que vous vous demandez si vous devriez fine-tuner, posez-vous une seule question :

"Est-ce que je peux produire 2000 exemples entrée/sortie parfaits, validés par un expert métier, en moins de 6 semaines ?"

Si la réponse est non : vous n'êtes pas prêt. Faites du RAG, mesurez, revenez dans 6 mois.

Si la réponse est oui mais que vous n'avez pas d'eval grid : vous n'êtes pas prêt non plus. Vous allez fine-tuner à l'aveugle et constater 3 mois plus tard que le modèle hallucine plus qu'avant.

Si la réponse est oui aux deux : appelez-nous, c'est exactement les missions qu'on adore.