Un LLM sorti de sa boîte est un collègue brillant… amnésique, coupé du monde et figé à sa date d’entraînement. Il ne connaît ni vos documents, ni votre base de données, ni la météo de ce matin. Et il ne fait rien : il ne sait que parler. Toute l’ingénierie des applications IA consiste à combler ces manques. Le problème, c’est l’étagère : RAG, RIG, tool calling, MCP, fine-tuning, contexte long, mémoire… on choisit trop souvent la techno au buzz plutôt qu’au besoin, et on se retrouve avec une base vectorielle pour interroger trois tables SQL.
Ce guide remet chaque outil devant le manque qu’il comble, avec un tableau de décision et (première sur ce blog) une boîte interactive pour vous accompagner dans le choix. C’est pas sorcier.
La bonne question : quel manque comblez-vous ?
Tout se simplifie quand on classe les technologies par déficit comblé plutôt que par popularité. Un LLM a quatre manques, et chaque famille d’outils en vise un :
| Le manque | La question à se poser | Les remèdes |
|---|---|---|
| Savoir | « il ne connaît pas mes données » | contexte direct, RAG, RIG |
| Agir | « il ne peut rien exécuter » | tool calling, MCP |
| Être | « il ne parle pas comme il faut » | prompt engineering, fine-tuning |
| Se souvenir | « il oublie tout entre deux sessions » | mémoire conversationnelle |
L’erreur classique, et coûteuse, est de croiser les colonnes : fine-tuner pour injecter des connaissances (elles seront périmées au premier changement), ou vectoriser des données qui méritaient une requête SQL.
Combler le « savoir » : trois outils, trois situations
Le contexte direct — le plus simple qui marche. Votre corpus est petit et stable (une doc produit, une FAQ, un règlement) ? Collez-le intégralement dans le prompt système. Avec les fenêtres de contexte actuelles et le prompt caching qui rend les préfixes répétés quasi gratuits (certains parlent de cache-augmented generation), cette approche « bête » bat un RAG mal réglé neuf fois sur dix. Ses limites : la taille du corpus et l’attention du modèle qui se dilue.
Le RAG — la bibliothèque avec documentaliste. Grande base documentaire, contenus qui bougent, questions ouvertes : on découpe, on vectorise, on récupère les passages pertinents au moment de la question. C’est le standard des bases de connaissances ; on le démonte en détail dès demain dans RAG et embeddings : donnez vos documents à l’IA.
Le RIG — le fact-checker en direct. Moins connu : Retrieval-Interleaved Generation. Là où le RAG récupère une fois avant de générer, le RIG laisse le modèle interroger la source pendant qu’il génère : il émet une mini-requête au moment d’écrire un chiffre, et la vraie valeur vient remplacer son estimation. C’est l’approche popularisée par DataGemma (Google) branché sur Data Commons, et elle vise un problème précis : les statistiques et valeurs numériques qu’un RAG classique cite mal. Prometteur, mais jeune : peu d’outillage prêt à l’emploi.
Combler l’« agir » : les outils, et la prise qui les distribue
Le tool calling donne des bras au modèle : vous déclarez des fonctions (requête SQL, appel d’API, calcul, envoi de mail), le modèle choisit laquelle appeler et avec quels arguments, votre code exécute. C’est aussi le remède aux questions exactes : « les commandes du client X en mars » n’est pas une question sémantique, c’est un WHERE. Une question structurée mérite une réponse structurée, pas cinq extraits vectoriels approximatifs.
MCP n’est pas une capacité de plus : c’est une prise standard. Le Model Context Protocol ne rend pas votre modèle plus malin : il emballe vos outils (et ressources, et prompts) derrière un protocole que tous les clients comprennent (IDE, chatbot, agents). La règle de décision est simple : un outil pour une seule application → une fonction native suffit ; le même outil pour plusieurs clients ou équipes → un serveur MCP, écrit une fois, branché partout. Côté développeurs, on a déjà construit un serveur MCP en .NET sur notre blog jumeau.
Combler l’« être » et le « se souvenir »
Le style, le ton, le format ne se règlent pas avec une base vectorielle. L’escalier : d’abord le prompt système et quelques exemples bien choisis (few-shot) ; si, et seulement si, ça ne suffit pas à tenir un format ou un jargon métier très spécifique, le fine-tuning entre en scène. Retenez sa règle d’or : il apprend au modèle comment parler, pas quoi savoir : les connaissances injectées par fine-tuning périment et ne se citent pas.
La mémoire, enfin, comble l’amnésie entre sessions : résumés de conversation, préférences utilisateur, fichiers de notes que l’agent relit. C’est un sujet à part entière ; on y consacre l’article du 27 juillet.
Le tableau de décision
| Situation | Le bon réflexe | Complexité |
|---|---|---|
| Corpus < ~100 pages, stable | tout en contexte + cache | ★ |
| Grande base docs, questions ouvertes | RAG | ★★★ |
| Données structurées (SQL, API) | tool calling | ★★ |
| Chiffres/stats à citer précisément | RIG (à surveiller) | ★★★ |
| Le modèle doit agir | tool calling | ★★ |
| Outils partagés entre plusieurs apps | MCP | ★★ |
| Ton, format, jargon récalcitrants | prompt d’abord, puis fine-tuning | ★★★★ |
| Oubli entre sessions | mémoire | ★★ |
À vous de jouer : le guide interactif
Répondez à deux questions, la boîte vous propose un point de départ, et le lien pour creuser.
Et dans la vraie vie : on combine
Les applications sérieuses cumulent presque toujours plusieurs briques : un RAG plus un outil SQL pour les questions exactes, du contexte direct plus de la mémoire, un fine-tuning léger plus un RAG pour les faits. La règle d’or reste l’escalier de simplicité : prompt → contexte → RAG ou outils → fine-tuning, en ne montant une marche que quand la précédente a prouvé ses limites, preuve chiffrée à l’appui (les évals du 20 juillet vous outilleront). Et pour orchestrer plusieurs briques entre elles, c’est le rôle des agents : notre blog dev jumeau a posé les bases avec le Microsoft Agent Framework.
Le mot d’honnêteté
- Le RIG est le petit jeune de la liste : concept solide, outillage encore confidentiel. Je le présente pour que le terme ne vous surprenne pas en réunion — pas comme un choix par défaut en 2026.
- Les frontières sont poreuses : un « RAG agentique » n’est qu’un RAG piloté par tool calling, la recherche web n’est qu’un outil parmi d’autres. Ne vous battez pas sur les étiquettes, battez-vous sur le manque à combler.
- La boîte interactive donne un point de départ, pas un verdict d’architecte : vos volumes, votre budget et vos évals ont toujours le dernier mot.
En résumé
- Classez par manque comblé : savoir (contexte, RAG, RIG), agir (tools, MCP), être (prompt, fine-tuning), se souvenir (mémoire).
- Petit corpus stable → contexte + cache ; grande base vivante → RAG ; données structurées → SQL par tool calling ; stats au fil du texte → RIG (à surveiller).
- MCP ne rend pas le modèle plus capable : il standardise la prise — réservez-le aux outils partagés.
- Le fine-tuning apprend comment parler, jamais quoi savoir.
- Montez l’escalier de simplicité une marche à la fois, évals en main, et combinez sans complexe.
Demain, justement, Christophe vous emmène sur la marche la plus fréquentée de l’escalier : le RAG et ses embeddings, expliqués simplement. Et ça, franchement… c’est pas sorcier.
