Panorama IA : LLM, RAG, agents et MCP

Imaginons que vous vouliez créer un assistant qui répond aux questions sur votre documentation interne, exécute des commandes sur vos serveurs et génère des rapports. Par où commencer ? Quelles briques utiliser ? Ce guide vous donne en 15 minutes une carte mentale complète de l’écosystème IA générative.

À la fin, vous saurez :

Nommer chaque composant (LLM, RAG, agent, MCP)
Comprendre ce que chacun fait et quand l’utiliser
Positionner les outils (Ollama, LiteLLM, LangGraph) dans une architecture
Décider quelle approche choisir pour votre projet

Ce que vous allez apprendre

LLM : qu’est-ce qu’un modèle de langage et comment il génère du texte
RAG : comment augmenter un LLM avec vos propres données
Tool calling : comment un LLM appelle des fonctions
Agents : comment un LLM peut agir sur le monde réel via des outils
MCP : le standard qui connecte agents et outils
Où se placent les outils : LiteLLM, Ollama, LangGraph dans l’architecture

Comment choisir (en 30 secondes)

Vous voulez…	Utilisez…
Répondre sur vos docs internes	RAG (recherche + injection de contexte)
Déclencher une action externe (API, DB, shell)	Tool calling
Enchaîner plusieurs étapes / boucler jusqu’au résultat	Agent (LangGraph, CrewAI…)
Réutiliser vos outils dans Claude Desktop, VS Code, etc.	MCP (standard d’interopérabilité)

LLM : le moteur de génération

Un LLM (Large Language Model) est un programme qui prédit le token suivant dans une séquence. Un token n’est pas forcément un mot : c’est un morceau de texte (mot, partie de mot, ponctuation). Pensez à la fonction “auto-complétion” de votre téléphone, mais à une échelle gigantesque : au lieu de suggérer un mot, il génère des paragraphes entiers.

Concrètement, un LLM peut :

Générer du texte : articles, emails, code, scripts
Répondre à des questions : en synthétisant ce qu’il a “appris”
Résumer des documents : en extrayant l’essentiel
Traduire : en transposant les patterns d’une langue à l’autre
Reformuler : en changeant le style ou le niveau de complexité

Comment ça fonctionne concrètement

Le LLM a été entraîné sur des milliards de textes (livres, sites web, code source, conversations). Pendant cet entraînement, il a “appris” les patterns statistiques du langage : quels mots suivent quels autres, dans quel contexte.

Prédiction LLM : entrée, modèle, probabilités de sortie

Le LLM choisit le token suivant selon des probabilités, puis répète le processus jusqu’à générer une réponse complète. Cette génération token par token explique pourquoi on parle de “coût par token” et de “context window” (fenêtre de contexte).

Ce qu’un LLM sait et ne sait pas

Le LLM sait	Le LLM ne sait pas
La syntaxe du langage	Les événements après sa date d’entraînement
Les patterns courants	Le contenu de vos documents internes
Générer du code valide	La vérité (il “hallucine” parfois)
Suivre des instructions	Agir sur le monde réel

Les principales familles de LLM (février 2026)

Famille	Exemples	Particularité
GPT (OpenAI)	GPT-4o, o1, o3	Polyvalent, API cloud, reasoning
Claude (Anthropic)	Claude 3.5, 4	Long contexte (200k), sûr
Llama (Meta)	Llama 3.3	Open-weights, local possible
Mistral	Mistral Large, Codestral	Performant, européen
Gemini (Google)	Gemini 2.0	Multimodal
Qwen (Alibaba)	Qwen 2.5	Open-source, multilingue

→ Approfondir : Anatomie d’un LLM

RAG : augmenter le LLM avec vos données

Vous avez un LLM, mais il ne connaît pas vos documents internes. Comment lui faire répondre à “Quelle est notre politique de congés ?” ou “Comment déployer sur notre infrastructure ?” C’est là qu’intervient RAG (Retrieval-Augmented Generation).

Le principe en 4 étapes

Indexer : transformer vos documents en vecteurs numériques (on y reviendra)
Chercher : quand une question arrive, trouver les passages pertinents
Injecter : ajouter ces passages dans le prompt du LLM
Générer : le LLM répond en se basant sur ce contexte

Pipeline RAG : question, recherche, contexte, LLM, réponse

Pourquoi RAG plutôt que fine-tuning ?

Approche	Avantages	Inconvénients
RAG	Pas de réentraînement, données à jour, traçabilité (citations)	Dépend de la qualité de la recherche
Fine-tuning	Comportement personnalisé, pas de latence de recherche	Coûteux, données figées, risque d’oubli

Les étapes d’un pipeline RAG (expliquées)

Extraction : Récupérer le contenu brut de vos sources (HTML, PDF, Markdown). C’est le “web scraping” ou “parsing” de vos documents.
Chunking : Découper en morceaux de 500-1000 tokens. Pourquoi ? Parce que le LLM a une fenêtre de contexte limitée, et parce qu’un passage court est plus pertinent qu’un document entier.
Embeddings : Convertir chaque chunk en vecteur numérique (une liste de nombres). C’est comme donner une “adresse” à chaque chunk dans un espace mathématique où les textes similaires sont proches.
Indexation : Stocker ces vecteurs dans une base vectorielle (ChromaDB, FAISS). C’est une base de données optimisée pour chercher “le vecteur le plus proche”.
Retrieval : Quand une question arrive, la convertir aussi en vecteur, puis chercher les chunks les plus proches. C’est la “recherche sémantique”.
Génération : Injecter les chunks trouvés dans le prompt du LLM. Il répond en se basant sur ce contexte, pas sur sa mémoire.

Ce qui fait la différence en production

Un RAG “démo” fonctionne vite. Un RAG production-ready nécessite 3 éléments supplémentaires :

Métadonnées & filtres : chaque chunk porte des infos (source, date, produit, ACL). Sinon impossible de filtrer par équipe, restreindre par droits, ou dater les réponses.
Hybrid retrieval + reranking : combiner recherche dense (embeddings) et lexicale (BM25), puis re-classer les résultats avec un modèle de reranking. Gain de pertinence significatif.
Citations / traçabilité : renvoyer à l’utilisateur les extraits utilisés avec leurs liens ou IDs. Sans ça, impossible de vérifier ni d’auditer.

→ Approfondir : Introduction au RAG

Agent : un LLM qui agit

Jusqu’ici, le LLM ne fait que parler. Mais si vous voulez qu’il agisse — réserver un vol, déployer un service, envoyer un email — il lui faut des outils et une boucle de décision. C’est ce qu’on appelle un agent.

Concrètement, un agent peut :

Appeler des API : météo, Slack, GitHub, votre backend
Exécuter du code : Python, shell, SQL
Lire/écrire des fichiers : logs, configs, rapports
Interroger des bases de données : PostgreSQL, MongoDB, Elasticsearch
Naviguer sur le web : scraper, remplir des formulaires

La boucle agent (expliquée)

L’agent fonctionne en boucle jusqu’à ce que la tâche soit terminée :

Boucle agent : Perceive, Think, Act, Observe

Chaque étape a un rôle précis :

PERCEIVE : L’agent reçoit la demande (“Déploie la version 2.1 sur staging”)
THINK : Le LLM analyse la situation et décide quoi faire (“Je dois d’abord vérifier si staging est disponible”)
ACT : Il appelle un outil (check_status("staging"))
OBSERVE : Il lit le résultat (“staging: OK, prêt”)
Recommencer ? : Si la tâche n’est pas finie, retour à THINK (“Maintenant je peux déployer”)

Agent vs Chatbot

Chatbot simple	Agent
Répond à une question	Accomplit une tâche
Une seule interaction LLM	Plusieurs itérations
Pas d’action externe	Appelle des outils
Déterministe	Autonome (et risqué)

Patterns d’agents courants

Pattern	Description	Use-case
ReAct	Raisonnement + Action alternés	Tâches complexes multi-étapes
Plan-Execute	Planifier d’abord, exécuter ensuite	Tâches avec dépendances
Reflection	Auto-critique et correction	Améliorer la qualité
Router	Orienter vers le bon sous-agent	Spécialisation par domaine

→ Approfondir : Patterns agentiques (à venir)

Tool calling : le LLM appelle des fonctions

Vous vous demandez peut-être : “Comment le LLM sait-il appeler une API ?” La réponse : il ne le fait pas vraiment. Le LLM génère du texte structuré (JSON) qui décrit quelle fonction appeler et avec quels paramètres. C’est votre code qui exécute réellement l’action.

C’est le tool calling (ou function calling) : une convention où le LLM “demande” d’appeler une fonction, et votre code l’exécute.

Comment ça fonctionne concrètement

Vous définissez des outils avec leurs schémas (nom, description, paramètres)
L’utilisateur pose une question
Le LLM décide quel outil appeler et avec quels paramètres
Votre code exécute l’outil et retourne le résultat
Le LLM intègre le résultat dans sa réponse

# Définition d'un outil
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Obtenir la météo d'une ville",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "Nom de la ville"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
                },
                "required": ["city"]
            }
        }
    }
]

# Le LLM génère ceci (pas le résultat, juste l'appel) :
# {"name": "get_weather", "arguments": {"city": "Paris", "unit": "celsius"}}

# Votre code exécute get_weather("Paris", "celsius") → "18°C, nuageux"
# Le LLM répond : "Il fait 18°C à Paris, avec un ciel nuageux."

→ Approfondir : Tool calling & contrats d’interface (à venir)

MCP : le standard pour connecter les outils

Vous avez créé un outil “get_weather” pour votre agent LangGraph. Super ! Mais maintenant vous voulez l’utiliser dans Claude Desktop, VS Code Copilot et votre chatbot Chainlit. Vous allez réécrire l’intégration 3 fois ? C’est exactement le problème que MCP (Model Context Protocol) résout.

Le problème N×M (avant MCP)

Comparaison avant/après MCP : N×M vs N+M intégrations

Architecture MCP

Composant	Rôle	Exemple
Host	L’application utilisateur	Claude Desktop, VS Code, Chainlit
Client	Maintient la connexion aux serveurs	Bibliothèque MCP
Server	Expose ressources, outils, prompts	Votre serveur MCP

Les 3 primitives MCP

Primitive	Description	Exemple
Resources	Données contextuelles (read-only)	Fichiers, entrées de DB
Tools	Fonctions appelables par le LLM	`check_status()`, `deploy()`
Prompts	Templates réutilisables	”Résume cet incident”

→ Approfondir : MCP : standardiser les outils (à venir)

Exemple concret : un assistant DevOps

Pour bien comprendre comment tout s’assemble, imaginons un assistant DevOps complet :

Le besoin

Vous voulez un assistant qui peut :

Répondre aux questions sur votre documentation interne (procédures, runbooks)
Vérifier l’état de vos services
Récupérer des logs
Créer des tickets d’incident

La solution, brique par brique

Besoin	Brique IA	Implémentation
Répondre sur la doc interne	RAG	ChromaDB avec vos runbooks indexés
Vérifier l’état des services	Tool calling	Outil `check_status(service)`
Récupérer des logs	Tool calling	Outil `get_logs(service, lines)`
Créer un ticket	Tool calling	Outil `create_ticket(title, body)`
Orchestrer tout ça	Agent	LangGraph avec boucle de décision
Standardiser les outils	MCP	Serveur MCP “devops-tools”
Interface utilisateur	—	Chainlit ou Slack bot
Inférence	LLM	GPT-4 via LiteLLM (avec fallback Claude)

Architecture résultante

Architecture assistant DevOps : Agent, MCP, outils, RAG

Erreurs fréquentes

Avant de passer à la suite, évitez ces pièges classiques :

Erreur	Pourquoi c’est faux	Bonne approche
”RAG = fine-tuning”	RAG injecte du contexte à la volée ; fine-tuning modifie les poids du modèle	Utilisez RAG pour des données changeantes, fine-tuning pour un comportement personnalisé permanent
”Un agent = un chatbot”	Un chatbot répond ; un agent agit (boucle, outils, autonomie)	Chatbot si Q&A simple, agent si tâches multi-étapes
”MCP sécurise mes outils”	MCP est un protocole d’interopérabilité, pas de sécurité	Ajoutez sandbox, allowlist, audit par-dessus MCP
”Le LLM appelle l’API”	Le LLM génère du JSON ; votre code exécute l’appel	Validez toujours le JSON avant exécution

À retenir

LLM = génération : prédit le token suivant. Base de tout. Mais ne sait que ce qu’il a appris.
RAG = contexte : augmente le LLM avec vos données. Recherche + injection dans le prompt.
Tool calling = interface : le LLM génère du JSON, votre code exécute. Validez toujours.
Agent = action : LLM + boucle + outils. Autonome mais risqué. Garde-fous obligatoires.
MCP = standard : connecte apps et outils. Évite le N×M. Resources, Tools, Prompts.

Prochaines étapes

Anatomie d'un LLM Comprendre tokenisation, attention, génération

Prompt Engineering Écrire des prompts efficaces

LiteLLM Commencer avec l'inférence multi-provider

Introduction au RAG Construire votre premier pipeline RAG