TL;DR -- Tu sais ce qu'est un LLM. Maintenant il faut savoir l'utiliser. Cet article couvre les 6 patterns concrets que tout dev doit maitriser en 2026 : prompt engineering, RAG, function calling, MCP, fine-tuning leger, et embeddings + vector DB.

Le fossé entre comprendre et utiliser

Tu sais ce qu'est un LLM. Tu as peut-être même lu mon article sur les Transformers. Mais entre comprendre comment ça marche et savoir l'utiliser concrètement dans ton code... il y a un fossé.

J'ai passé 8 ans à écrire du Java, du React, du Python. Quand j'ai commencé à intégrer des LLM dans mes projets, j'ai réalisé que la vraie difficulté n'est pas le modèle. C'est la plomberie autour. Comment lui donner le bon contexte. Comment le faire agir. Comment le connecter à tes systèmes.

Voici les 6 patterns qui comblent ce fossé.

Pattern 1 : Prompt engineering

C'est pas juste "poser une question". C'est structurer l'input pour obtenir un output fiable et reproductible.

Trois techniques à connaitre :

• System prompt (System prompt) : tu définis le rôle, le ton, les contraintes. C'est le cadre.
• Few-shot (Few-shot / Zero-shot) : tu donnes des exemples de paires input/output. Le modèle comprend le format attendu.
• Chain-of-thought (Chain-of-thought (CoT)) : tu demandes au modèle de raisonner étape par étape. Ça réduit les erreurs sur les problèmes complexes.

messages = [
    {
        "role": "system",
        "content": (
            "Tu es un assistant technique spécialisé en architecture logicielle. "
            "Réponds en français. Structure ta réponse avec : "
            "1) Diagnostic, 2) Options, 3) Recommandation. "
            "Sois concis. Pas de blabla marketing."
        )
    },
    {
        "role": "user",
        "content": "Mon API REST met 3 secondes à répondre sur l'endpoint /users. 50k utilisateurs en base PostgreSQL."
    }
]

Le prompt engineering couvre 80% des besoins. Avant de sortir l'artillerie lourde (RAG, fine-tuning), commence par là. Un bon system prompt avec quelques exemples well-chosen, c'est souvent suffisant.

Pattern 2 : RAG (Retrieval-Augmented Generation)

Le problème

Le LLM ne connait pas TES données. Il ne sait rien de ta documentation interne, de tes tickets Jira, de tes specs produit. Et il ne peut pas tout ingérer dans son contexte -- la fenêtre a une limite.

La solution

Chercher les morceaux pertinents dans tes données, les injecter dans le prompt, puis laisser le modèle générer sa réponse avec ce contexte.

Le flux en une image :

Tes docs --> Découpage en chunks --> Embeddings --> Vector DB
                                                        |
Question --> Recherche sémantique --> Contexte pertinent --> LLM --> Réponse

Concrètement :

1. Tu découpes tes documents en chunks (paragraphes, sections).
2. Tu transformes chaque chunk en vecteur via un modèle d'embeddings.
3. Tu stockes ces vecteurs dans une base vectorielle.
4. Quand l'utilisateur pose une question, tu vectorises la question, tu cherches les chunks les plus proches, et tu les injectes dans le prompt.

// Pseudo-code simplifié d'un pipeline RAG
const questionEmbedding = await embed(userQuestion);
const relevantChunks = await vectorDB.search(questionEmbedding, { topK: 5 });

const prompt = `
Contexte :
${relevantChunks.map(c => c.text).join("\n---\n")}

Question : ${userQuestion}

Réponds en te basant uniquement sur le contexte fourni.
`;

const response = await llm.complete(prompt);

RAG, c'est le pattern le plus utilisé en entreprise. Pas besoin de fine-tuner le modèle, pas besoin de GPU. Tu gardes tes données à jour en re-indexant, et le modèle reste générique.

Pattern 3 : Function calling / Tool use

Le concept

Le LLM ne fait plus que répondre -- il agit. Tu lui déclares des fonctions disponibles (avec leur signature JSON Schema), et le modèle décide quand les appeler en fonction de la conversation.

Comment ça marche

Tu définis une fonction avec son nom, sa description et ses paramètres. Le modèle ne l'exécute pas lui-même -- il retourne un JSON structuré qui dit "appelle cette fonction avec ces arguments". Ton code exécute la fonction et renvoie le résultat au modèle.

{
  "name": "get_user_orders",
  "description": "Récupère les commandes d'un utilisateur par son ID",
  "parameters": {
    "type": "object",
    "properties": {
      "user_id": {
        "type": "string",
        "description": "Identifiant unique de l'utilisateur"
      },
      "status": {
        "type": "string",
        "enum": ["pending", "shipped", "delivered"],
        "description": "Filtrer par statut de commande"
      }
    },
    "required": ["user_id"]
  }
}

Quand l'utilisateur demande "quelles sont les commandes de Jean ?", le modèle ne fabrique pas de réponse. Il retourne :

{
  "function_call": {
    "name": "get_user_orders",
    "arguments": "{\"user_id\": \"jean-42\"}"
  }
}

Ton backend exécute la requête, renvoie les données, et le modèle formule une réponse lisible.

C'est la brique fondamentale pour construire des agents. Sans function calling, un LLM est un perroquet savant. Avec, c'est un orchestrateur.

Pattern 4 : MCP (Model Context Protocol)

Le standard

MCP, c'est le protocole ouvert créé par Anthropic pour standardiser la connexion entre les LLM et les outils externes. La métaphore officielle : "l'USB-C de l'IA".

Le problème qu'il résout

Avant MCP, chaque intégration était custom. Tu voulais connecter ton LLM à GitHub ? Code spécifique. A Jira ? Autre code. A ta base de données ? Encore un autre. Chaque fournisseur de modèle avait son propre format.

L'architecture

MCP définit deux rôles :

• MCP Server : expose des outils (tools), des ressources (resources) et des prompts. C'est ton code qui fait le boulot.
• MCP Client : le LLM (ou son hôte) qui consomme ces outils. Claude Desktop, Cursor, Zed, VS Code -- tous sont des clients MCP.

Tu construis un serveur MCP une fois. N'importe quel client compatible peut l'utiliser. Plus de lock-in.

// Exemple simplifié d'un MCP Server
const server = new MCPServer({
  name: "mon-crm",
  tools: [
    {
      name: "search_clients",
      description: "Recherche des clients par nom ou email",
      inputSchema: {
        type: "object",
        properties: {
          query: { type: "string" },
          limit: { type: "number", default: 10 }
        },
        required: ["query"]
      },
      handler: async ({ query, limit }) => {
        return await db.clients.search(query, limit);
      }
    }
  ]
});

Ce qui rend MCP intéressant pour un dev, c'est l'interopérabilité. Tu écris tes outils une fois, et ils marchent dans Claude, dans Cursor, dans ton propre client. C'est un vrai standard, pas un SDK propriétaire.

Pattern 5 : Fine-tuning léger (LoRA / QLoRA)

Quand le prompt ne suffit plus

Parfois, le modèle se trompe systématiquement sur ton domaine. Il utilise la mauvaise terminologie. Il ne respecte pas le format attendu malgré des instructions claires. C'est là que le fine-tuning entre en jeu.

LoRA en deux phrases

Au lieu de ré-entraîner tout le modèle (des milliards de paramètres), LoRA injecte de petites matrices entraînables dans les couches d'attention. Tu entraînes 0.1% des paramètres pour adapter le comportement du modèle à ton cas d'usage.

QLoRA : la version accessible

QLoRA fait la même chose, mais quantifie le modèle en 4 bits d'abord. Résultat : tu peux fine-tuner un modèle 7B sur un GPU grand public (24 Go VRAM). Plus besoin d'un cluster de A100.

Quand l'utiliser (et quand s'abstenir)

Utilise le fine-tuning quand :

• Le modèle se trompe sur la terminologie de ton domaine malgré un bon prompt
• Tu as besoin d'un format de sortie très spécifique et reproductible
• Tu as des données d'entraînement de qualité (quelques centaines d'exemples suffisent avec LoRA)

N'utilise PAS le fine-tuning quand :

• Un bon prompt engineering résout le problème (essaie d'abord)
• Tes données changent souvent (RAG est plus adapté)
• Tu veux juste ajouter des connaissances factuelles (RAG, encore)

Pattern 6 : Embeddings + Vector DB

Au-delà du RAG

Les embeddings sont au coeur du RAG, mais ils servent bien au-delà. Un embedding, c'est une représentation vectorielle d'un texte qui capture son sens. Deux phrases sémantiquement proches auront des vecteurs proches, même si elles n'ont aucun mot en commun.

Les vector databases

Pour chercher efficacement dans des millions de vecteurs, tu as besoin d'une base spécialisée :

• Pinecone : managé, simple à intégrer, scale bien
• Chroma : open source, léger, parfait pour le prototypage
• Weaviate : open source, filtrage hybride (vecteur + metadata)
• Qdrant : open source, performant, API propre

Cas d'usage concrets

• Recherche sémantique : "trouve les tickets similaires à celui-ci" -- même si les mots sont différents
• Déduplication : détecter les contenus quasi-identiques dans une base documentaire
• Recommandation : "les utilisateurs qui ont aimé X aiment aussi Y"
• Classification : classer un texte en comparant son embedding aux embeddings de catégories connues

Quand c'est overkill

Si tes recherches marchent bien avec du full-text search (Elasticsearch, PostgreSQL tsvector), tu n'as pas besoin d'embeddings. Les vector DB ajoutent de la complexité. Utilise-les quand la recherche par mots-clés ne capture pas l'intention.

Quand utiliser quoi ?

En pratique, tu combines. Un pipeline classique en production, c'est : prompt engineering + RAG + function calling. MCP par-dessus pour standardiser les outils. Fine-tuning si le domaine est très spécifique. Et les embeddings sont la fondation silencieuse qui fait marcher le RAG.

Ressources

• Retrieval-Augmented Generation (paper original) — le paper fondateur du RAG
• Model Context Protocol - Documentation — spec officielle MCP
• LoRA: Low-Rank Adaptation — le paper LoRA
• QLoRA: Efficient Finetuning — fine-tuning en 4-bit
• OpenAI Function Calling Guide — documentation officielle
• Anthropic Tool Use Guide — documentation Claude

La suite

Cet article fait partie de la série "Comprendre l'IA en 2026".

• Ce qui s'est passé en IA depuis ChatGPT -- la frise chronologique 2022-2026.
• Comment fonctionnent les LLM -- l'architecture Transformer, l'attention, la tokenisation.
• Cet article : RAG, MCP, function calling -- les patterns d'intégration.
• Prochain : Les agents IA ne sont pas du hype -- quand le LLM planifie, raisonne et agit en autonomie.