9 min de lecture - RAG vs fine-tuning : quelle architecture pour vos systèmes de connaissance

Si vous avez récemment assisté à une réunion de planification IA, vous avez sûrement déjà entendu une variante de ceci :

• « Il faudrait fine-tuner un modèle sur notre documentation. »
• « Non, faisons du RAG, le fine-tuning est disproportionné. »
• « On peut livrer quelque chose en un mois ? »
• « Autre chose : la sécurité s'inquiète de savoir où vont les données. »

C'est là le vrai problème derrière le choix entre RAG et fine-tuning. Ce n'est pas un débat de recherche. C'est une décision d'architecture, avec un budget, un calendrier et des risques associés.

Ce guide s'adresse aux décideurs techniques, architectes solutions, fondateurs et consultants qui ont besoin d'une décision claire, pas d'un cours magistral.

Ce que vous allez apprendre

• Une règle de décision en 60 secondes, utilisable en réunion
• Quand le RAG est le choix par défaut (et où cela tourne généralement mal)
• Quand le fine-tuning justifie son coût (et ce qu'il ne résout pas)
• Les patterns hybrides que les équipes déploient réellement
• Une fiche d'une page pour choisir une approche et aligner les parties prenantes

L'essentiel

Le RAG est généralement le choix par défaut pour les systèmes de connaissance, car il conserve votre source de vérité dans votre base de données et permet de mettre à jour les réponses sans réentraînement. Le fine-tuning vaut son coût lorsque vous avez besoin d'un comportement cohérent (format, politique, ton) ou d'une latence plus faible à grande échelle, et que vous pouvez contrôler la qualité des données d'entraînement. La plupart des équipes gagnent avec une approche hybride : commencer par le RAG associé à une évaluation, puis ajouter du fine-tuning ciblé une fois l'écart mesurable.

La décision en 60 secondes (RAG vs fine-tuning)

Si vous ne devez retenir qu'une chose, retenez celle-ci :

• Si vos connaissances évoluent souvent (au quotidien, chaque semaine), commencez par le RAG. Le fine-tuning ne suivra pas le rythme de fraîcheur nécessaire.
• Si vous avez besoin de citations, de traçabilité et de « montrer vos sources », commencez par le RAG.
• Si vous avez besoin d'un format de sortie ou d'un comportement conforme à une politique cohérents, envisagez le fine-tuning, mais n'attendez pas de lui qu'il « apprenne votre documentation ».
• Si vous avez besoin des deux : faites du RAG + une petite couche de comportement (prompting, routage ou fine-tuning ciblé).

Rendez ensuite la décision explicite en écrivant noir sur blanc la contrainte sur laquelle vous ne pouvez transiger :

• Périmètre des données et contrôle d'accès
• Fraîcheur et fréquence de mise à jour
• SLA de latence
• Exigence de citations et de piste d'audit
• Schéma de sortie requis (JSON, tickets, checklists, formulations de conformité)

Une fois la contrainte nommée, le choix d'architecture devient plus simple.

Quand le RAG est le choix par défaut (et comment le faire vraiment fonctionner)

Le RAG est populaire parce qu'il correspond à la façon dont les systèmes de connaissance se comportent réellement en entreprise :

• vos documents source évoluent,
• les règles d'accès sont complexes (équipes, régions, périmètres clients),
• et vous avez besoin que le système « reste honnête » sous le regard critique des utilisateurs.

Les erreurs de RAG qui coûtent cher aux équipes sont prévisibles :

1. Une recherche (retrieval) qui ignore les permissions. Si un utilisateur ne doit pas voir un document, il ne doit pas pouvoir le récupérer. Le contrôle d'accès doit faire partie intégrante de la recherche, pas être traité comme un simple sujet d'interface.
2. Un découpage (chunking) qui détruit le sens. Si vous coupez un texte juridique en plein milieu de phrase ou supprimez tableaux et structure, la recherche a l'air « correcte », mais les réponses deviennent fausses.
3. L'absence de dispositif d'évaluation. Les équipes livrent sur la base d'un « ça a l'air bien », puis passent des mois à débattre des cas limites sans référence chiffrée.
4. Le bourrage de contexte. Vous pouvez forcer n'importe quel modèle à « répondre » en y déversant plus de tokens, mais la qualité comme le coût s'en trouvent dégradés.

Des recommandations pratiques de mise en œuvre du RAG, valables tous secteurs confondus :

• Constituez un petit « golden set » de questions par workflow (support, conformité, onboarding, sales enablement). Notez les réponses dans la durée.
• Exploitez les métadonnées sans retenue (type de source, département, date d'effet, juridiction). Les filtres comptent souvent plus que la qualité des embeddings.
• Privilégiez un nombre restreint de sources propres plutôt que de « tout indexer dans l'entreprise ». Commencez avec un périmètre maîtrisé, puis élargissez.
• Faites en sorte que le système cite ses sources par défaut pour les questions de connaissance. Cela réduit les frictions avec les parties prenantes et accélère le débogage.

Quand le fine-tuning trouve sa place (et ce qu'il ne résout pas)

Le fine-tuning séduit parce qu'on a l'impression d'« apprendre » quelque chose au modèle. En pratique, on le considère surtout comme du façonnage de comportement :

• Vous voulez un ton et une structure cohérents (réponses support, synthèses juridiques, rapports d'incident).
• Vous avez besoin d'un schéma strict ou d'une fiabilité de tool-calling.
• Vous voulez réduire la latence en envoyant moins de contexte.
• Vous disposez d'exemples de haute qualité et pouvez maintenir un jeu de données dans le temps.

Ce que le fine-tuning ne fait pas bien à lui seul :

• Il n'ajoute pas de connaissances fraîches par magie. Si les faits sous-jacents changent, un modèle fine-tuné dérive.
• Il ne résout pas le contrôle d'accès. Il vous faut toujours un modèle de permissions.
• Il ne remplace pas l'évaluation. Il en renforce plutôt le besoin, car les changements sont moins visibles.

Dans un contexte fortement réglementé, la question la plus importante est souvent la gouvernance : où vivent les données d'entraînement, comment elles sont assainies, et qui peut approuver les mises à jour.

Les patterns hybrides que les équipes déploient réellement

La plupart des systèmes en production finissent par être hybrides, même si le pitch deck dit le contraire.

Les patterns qui fonctionnent :

1. RAG pour les faits + fine-tuning pour le format. La recherche fournit la vérité ; une couche de comportement rend la sortie cohérente (par exemple, « toujours répondre dans ce format de checklist »).
2. Routage par intention. Les questions de connaissance partent vers le RAG ; les tâches de classification ou d'extraction partent vers un composant fine-tuné ou basé sur des règles.
3. Génération en deux temps. Rédigez une première réponse, puis faites tourner une étape de vérification qui contrôle les citations et signale les sources manquantes.

L'hybride n'est pas « de la complexité gratuite ». C'est ce que vous faites lorsque vous avez deux impératifs non négociables, comme les citations et un formatage strict.

Trois exemples de décisions (pour repérer le schéma)

Parfois, la façon la plus simple de trancher consiste à rapprocher votre cas d'usage d'un schéma familier :

• Assistant de politiques internes : commencez par le RAG. Les politiques changent, vous avez besoin de citations, et la gestion des permissions compte. Ajoutez une petite couche de comportement pour le format et les règles de refus.
• Rédaction de réponses support : le fine-tuning n'est souvent pas nécessaire au départ. Commencez par une simple ébauche accompagnée d'une grille d'évaluation. Ajoutez la recherche documentaire quand les réponses doivent s'appuyer sur des documents.
• Synthèse de conformité (sortie structurée) : envisagez le fine-tuning quand vous avez besoin d'un formatage cohérent et d'une formulation stricte, mais gardez le RAG pour la fraîcheur et la traçabilité.

Le schéma est constant : le RAG maintient la vérité fraîche et auditable ; le fine-tuning façonne le comportement. La plupart des équipes ont besoin des deux, à des niveaux différents.

Fiche à copier-coller : trancher entre RAG et fine-tuning

Utilisez cette fiche d'une page en réunion de lancement, et vous vous éviterez des semaines de débats qui tournent en rond.

Use case name:
Primary users:
What the system must do (one sentence):

Non-negotiable constraints (pick 1-3):
- Freshness requirement:
- Citation/audit requirement:
- Data boundary (PII, customer data, regulated docs):
- Latency SLA:
- Required output schema:

Data reality check:
- Source systems:
- Update frequency:
- Permissions model exists? (yes/no)
- Can we create 50-200 high-quality examples? (yes/no)

Decision:
- Start with: RAG / Fine-tuning / Hybrid
- Why this is the safest first step:

Evaluation plan:
- Golden set owner:
- Scoring method:
- Ship threshold:
- Regression threshold:

Si vous voulez un script simple pour vos parties prenantes, utilisez celui-ci : « Qu'avons-nous livré, qu'avons-nous appris, qu'est-ce qui a cassé, et quelle décision devons-nous prendre cette semaine ? »

Modes d'échec courants (et mitigations rapides)

• Choisir le fine-tuning pour éviter le travail de recherche documentaire. Mitigation : commencez par le RAG et l'évaluation ; ne passez au fine-tuning qu'une fois l'écart identifié et explicable.
• Livrer du RAG sans contrôle d'accès. Mitigation : intégrez la gestion des permissions dans la recherche dès le départ, pas après coup.
• Aucun « golden set » et aucun seuil défini. Mitigation : choisissez 30 à 100 questions réelles et notez-les à chaque version.
• Tout indexer. Mitigation : partez d'un périmètre documentaire restreint, démontrez la valeur, puis élargissez.

Pour les chantiers sensibles en matière de cybersécurité, ajoutez modélisation des menaces, politiques de journalisation des sorties, gestion des secrets et revue des risques fournisseurs avant de passer à l'échelle.

Séparer les deux objectifs

La décision entre RAG et fine-tuning devient plus simple dès lors que vous séparez deux objectifs : préserver la fraîcheur des connaissances et rendre le comportement cohérent. Le RAG est généralement la première étape des systèmes de connaissance, car il préserve la fraîcheur et la traçabilité. Le fine-tuning devient précieux lorsque vous savez exactement quel comportement vous recherchez, que vous pouvez constituer un véritable jeu de données, et que vous disposez d'un dispositif d'évaluation pour le garder honnête.

Si vous êtes bloqués, ne débattez pas pendant des semaines. Choisissez le plus petit workflow RAG livrable, mesurez les échecs, puis n'ajoutez du fine-tuning que là où il comble clairement l'écart. Besoin d'aide pour choisir la bonne architecture pour votre système de connaissance ? Parlons-en.