RAG vs Fine-tuning : quel choix pour votre chatbot ?

Vous dirigez un cabinet d'expertise comptable. Quinze collaborateurs, des centaines de clients, et chaque jour les mêmes questions qui reviennent : "Quelle est la date limite de dépôt de la liasse fiscale ?", "Comment fonctionne le crédit d'impôt recherche ?", "Est-ce que mon client peut déduire ses frais de déplacement ?". Vos équipes passent un temps considérable à répondre manuellement, à chercher dans des bases documentaires, à reformuler les mêmes explications.

Un jour, vous décidez de mettre en place un chatbot. L'idée est séduisante : un assistant qui répond à ces questions récurrentes en s'appuyant sur votre documentation interne. Conventions collectives, notes fiscales, fiches de procédure. Mais dès que vous commencez à creuser, deux approches émergent : le RAG et le fine-tuning. Deux noms techniques, deux logiques très différentes, et un choix qui va déterminer la fiabilité, le coût et l'évolutivité de votre assistant.

Prenons le temps de comprendre ce qui se joue derrière ces acronymes.

Ce que fait un LLM "de base"

Avant de comparer les deux approches, il faut comprendre le problème qu'on essaie de résoudre. Un LLM (Large Language Model) comme GPT-4, Claude ou Mistral est un modèle entraîné sur des milliards de textes publics. Il sait parler, raisonner, structurer. Mais il ne connaît pas vos documents. Il ne sait pas que votre cabinet utilise la convention collective des experts-comptables. Il ne sait pas que votre procédure interne exige une double validation pour les déclarations de TVA au-dessus de 50 000 €.

Si vous lui posez une question métier, il répondra avec assurance (c'est sa nature) mais souvent avec des approximations, des informations obsolètes, ou pire, des inventions. C'est ce qu'on appelle l'hallucination : le modèle génère une réponse qui semble correcte mais qui ne l'est pas. Dans un contexte comptable, médical ou juridique, une hallucination, c'est votre responsabilité professionnelle qui est en jeu.

Le RAG et le fine-tuning sont deux stratégies pour combler ce fossé entre la compétence linguistique du modèle et la connaissance spécifique de votre métier.

Le RAG : donner au modèle une bibliothèque

Le RAG (Retrieval-Augmented Generation) ne touche pas au modèle lui-même. Il lui donne accès à vos documents au moment où il en a besoin. Concrètement, quand un utilisateur pose une question, le système effectue trois opérations :

1. Recherche : il cherche dans votre base documentaire les passages les plus pertinents par rapport à la question (c'est la phase de retrieval, qui repose sur la recherche sémantique et les embeddings vectoriels).
2. Injection : il injecte ces passages dans le contexte du modèle, comme si vous colliez des extraits de documents avant de poser votre question.
3. Génération : le modèle génère une réponse en s'appuyant à la fois sur ses capacités linguistiques et sur les documents récupérés.

Pour rendre l'idée plus concrète : pensez à un consultant brillant et cultivé, mais qui n'a jamais travaillé dans votre secteur. Avec le RAG, vous lui donnez accès à votre bibliothèque de procédures avant chaque réunion client. Il ne les connaît pas par cœur, mais il sait les lire, les comprendre et les synthétiser à la volée.

La recherche documentaire dans un pipeline RAG ne repose pas sur des mots-clés comme un moteur de recherche classique. Elle utilise des embeddings, des représentations numériques du sens de chaque passage de texte, stockées dans une base vectorielle. Quand un utilisateur pose une question, cette question est elle aussi convertie en vecteur, et le système cherche les passages dont le sens est le plus proche. C'est ce qu'on appelle la recherche sémantique : elle comprend que "Comment déclarer la TVA d'un assujetti mixte ?" et "Procédure de déclaration TVA pour les entreprises à activités mixtes" parlent de la même chose, même si les mots diffèrent.

Cette mécanique est élégante, mais elle est aussi fragile. La qualité de vos embeddings, le découpage de vos documents en chunks, le choix du modèle d'embedding : tout cela influence directement la pertinence de ce que le RAG récupère. On a tous eu cette tentation de croire qu'il suffisait de "brancher des documents" pour que ça marche. En réalité, un pipeline RAG se conçoit, se teste et s'affine.

Les atouts du RAG sont considérables. Pas besoin de réentraîner le modèle : vous branchez votre documentation et c'est opérationnel. La mise à jour est immédiate : vous modifiez un document, le chatbot en tient compte dès la prochaine question. Et surtout, le RAG permet la traçabilité. Chaque réponse peut citer le document source, ce qui est vital dans les métiers réglementés.

Le revers : la qualité de la réponse dépend directement de la qualité de la recherche documentaire. Si le système récupère les mauvais passages, le modèle produira une réponse cohérente mais fondée sur le mauvais contexte. Les travaux d'Anthropic sur le Contextual Retrieval ont montré que des améliorations ciblées de la phase de recherche réduisent les échecs de récupération de 49 %, et jusqu'à 67 % avec un reranking. Le RAG fonctionne bien, mais soigner le pipeline de récupération compte autant que le choix du modèle lui-même.

Le fine-tuning : réécrire les réflexes du modèle

Le fine-tuning procède d'une logique inverse. Au lieu de donner des documents au modèle à chaque requête, on modifie le modèle lui-même. On le réentraîne sur un dataset spécifique (vos données métier, vos échanges clients, vos documents internes) pour qu'il intègre ces connaissances dans ses poids, les paramètres internes qui déterminent son comportement.

Pour reprendre notre analogie : le fine-tuning, c'est envoyer le consultant faire un MBA spécialisé dans votre domaine. Après sa formation, il n'a plus besoin de consulter la bibliothèque à chaque question. Il a internalisé les concepts, le vocabulaire, les raisonnements. Il pense comme un expert du secteur.

Le fine-tuning excelle quand il s'agit de modifier le comportement du modèle. Lui apprendre un ton (formel, technique, empathique), un format de réponse (toujours structurer en diagnostic, puis recommandation, puis références), un jargon métier. Les modèles fine-tunés sur des données médicales, juridiques ou financières surpassent souvent les modèles génériques, même augmentés par RAG, pour les tâches de raisonnement spécialisé.

Mais les contreparties sont lourdes. Le fine-tuning nécessite un dataset d'entraînement propre, annoté et représentatif. Le constituer est souvent le poste de dépense le plus élevé du projet. L'entraînement lui-même consomme des ressources GPU significatives. Et surtout, le modèle fine-tuné est figé dans le temps : il ne connaît que ce qu'il a appris lors de l'entraînement. Un changement de réglementation fiscale en janvier ? Il faudra relancer un cycle de fine-tuning pour que le modèle l'intègre. Il y a aussi le risque de catastrophic forgetting : en apprenant votre domaine, le modèle peut oublier une partie de ses compétences générales.

Et si on mettait tout dans le contexte ?

Avec des fenêtres de contexte qui atteignent 200 000 tokens chez certains fournisseurs en 2026, une question revient souvent : pourquoi ne pas simplement coller tous vos documents dans le prompt et laisser le modèle chercher lui-même ?

C'est une question légitime, et la réponse est nuancée. Pour des bases de connaissances de moins de 200 000 tokens, le prompting complet avec cache peut être plus rapide et moins coûteux qu'un pipeline RAG. Pour une vingtaine de documents de quelques pages, c'est effectivement une option qui fonctionne bien.

Mais au-delà de ce seuil, les limites deviennent structurelles. Le coût par requête augmente linéairement avec la taille du contexte. La latence aussi. Et les modèles perdent en précision sur les passages situés au milieu du contexte, un phénomène documenté appelé "lost in the middle". Pour un cabinet avec des centaines de documents régulièrement mis à jour, le full-context ne tient pas la route. Le RAG reste l'architecture de référence dès que le volume de connaissances dépasse le seuil d'un prompt raisonnable.

Quand choisir l'un ou l'autre ?

Choisissez le RAG si : vos données changent régulièrement, la traçabilité est non négociable, vous souhaitez démarrer rapidement sans phase d'entraînement longue, et votre volume de documents est important mais évolue dans le temps.

Choisissez le fine-tuning si : vous avez besoin d'un comportement constant et spécialisé qui va au-delà de ce qu'un prompt peut exprimer, vos données de référence sont stables et changent rarement, la latence est critique, et vous disposez d'un dataset d'entraînement de qualité.

Dans la plupart des cas réels, les deux se combinent. En 2026, la frontière entre RAG et fine-tuning s'estompe dans les systèmes en production. Le RAG garantit que votre système dit vrai aujourd'hui ; le fine-tuning garantit qu'il se comporte correctement demain. Les architectures hybrides, un modèle fine-tuné pour le ton et le raisonnement, connecté à un pipeline RAG pour les données fraîches, sont devenues la norme dans les déploiements sérieux.

Ce qui compte vraiment

Si vous retenez trois choses de cet article, que ce soit celles-ci :

• Le RAG ne modifie pas le modèle. Il lui donne de quoi répondre. C'est la solution la plus rapide, la plus flexible et la plus traçable. C'est aussi celle qui demande le plus de soin dans la phase de recherche documentaire.
• Le fine-tuning modifie le modèle. Il change sa manière de penser. C'est la solution la plus puissante pour les comportements spécialisés, mais la plus rigide et la plus coûteuse à maintenir dans le temps.
• Le bon choix dépend de vos données (stables ou vivantes), de vos exigences de traçabilité, de votre budget, et du niveau de spécialisation attendu. La plupart des projets réels combinent les deux, et c'est normal.

L'IA conversationnelle est une architecture qui se conçoit autour de vos contraintes, de vos données et de vos utilisateurs. Et quand c'est bien fait, vos équipes ne se demandent même plus comment elles faisaient avant.