RAG, agents, fine-tuning : quelle architecture choisir pour une app IA ?

RAG, agents et fine-tuning sont souvent mis dans le même panier, comme s'il s'agissait de trois options interchangeables. En réalité, ces architectures répondent à des problèmes différents.

Le RAG sert à donner au modèle un accès contrôlé à des connaissances externes. Les agents servent à organiser une suite d'actions et d'appels d'outils. Le fine-tuning sert à modifier le comportement d'un modèle pour un format, un style, une tâche ou une expertise répétable. Une application IA peut utiliser une seule de ces approches, ou les combiner.

Commencer par une question simple

Avant de choisir une architecture, il faut répondre à une question : que manque-t-il au modèle pour produire le bon résultat ?

• S'il lui manque des connaissances fraîches, privées ou spécifiques, le RAG est probablement nécessaire.
• S'il doit agir dans des outils, appeler des APIs ou enchaîner des étapes, une architecture agentique devient pertinente.
• S'il produit toujours le mauvais format, le mauvais style ou une performance insuffisante sur une tâche répétable, le fine-tuning peut devenir utile.
• S'il doit seulement reformuler, classifier ou extraire avec un faible risque, un simple appel modèle avec sortie structurée peut suffire.

Quand choisir le RAG

Le RAG est le bon choix lorsque la réponse dépend de données qui ne sont pas dans le modèle ou qui évoluent régulièrement : documentation interne, catalogue produit, contrats, tickets support, dossiers clients, contenus éditoriaux, procédures, base RH, connaissances métier.

Son avantage est de maintenir les données hors du modèle. On peut ajouter, retirer, mettre à jour et filtrer les documents sans réentraîner. C'est essentiel pour des produits B2B, des SaaS, des outils internes ou des applications avec permissions.

Mais le RAG n'est pas magique. Sa qualité dépend du pipeline : extraction des documents, chunking, embeddings, métadonnées, recherche hybride, reranking, gestion des doublons, citations, droits d'accès et feedback utilisateur.

Les signaux d'un mauvais RAG

• Le modèle répond avec des passages hors sujet.
• Les sources affichées ne justifient pas la réponse.
• Les documents récents ne sont pas pris en compte.
• Les permissions sont gérées après la recherche au lieu d'être intégrées à la recherche.
• Le contexte envoyé est trop long et dilue l'information importante.

Quand choisir les agents

Une architecture agentique devient pertinente quand l'application doit planifier, appeler des outils, vérifier un état, prendre une décision intermédiaire puis continuer. Par exemple : analyser un dossier, chercher des informations, créer un résumé, mettre à jour un CRM, préparer un email et demander validation.

L'agent n'est pas forcément autonome. Dans beaucoup de produits, il doit plutôt être semi-autonome : il prépare, exécute certaines actions simples, demande validation pour les actions sensibles et garde une trace de ce qu'il a fait.

Le risque des agents est la dérive. Plus un système peut appeler d'outils, plus il faut limiter ses permissions, définir ses objectifs, journaliser les actions, tester les scénarios et gérer les erreurs. Un agent sans garde-fous est impressionnant en démo et dangereux en production.

Quand choisir le fine-tuning

Le fine-tuning est souvent mal compris. Il ne sert pas principalement à injecter une base documentaire dans un modèle. Pour cela, le RAG est généralement plus adapté. Le fine-tuning sert plutôt à améliorer un comportement répétable : respecter un format, adopter un style, mieux traiter une tâche spécialisée, réduire la longueur des prompts ou améliorer la performance avec un modèle plus petit.

Il devient pertinent lorsque vous disposez d'exemples de haute qualité : entrées, sorties attendues, corrections, préférences, cas limites. Sans dataset solide, le fine-tuning risque de figer de mauvais comportements.

Il peut aussi avoir un intérêt économique. Si une tâche très fréquente peut être réalisée par un modèle plus petit fine-tuné au lieu d'un grand modèle généraliste, le coût et la latence peuvent baisser. Mais cet arbitrage doit être mesuré.

Les architectures hybrides sont souvent les meilleures

Dans un vrai produit, la réponse est rarement RAG ou agents ou fine-tuning. Elle ressemble plutôt à une combinaison.

• RAG pour récupérer le bon contexte documentaire.
• Sorties structurées pour transformer la réponse en objet exploitable.
• Outils pour lire ou écrire dans les systèmes métier.
• Agent pour orchestrer plusieurs étapes.
• Fine-tuning éventuel pour standardiser une tâche fréquente ou réduire les coûts.

Cette approche hybride demande une bonne séparation des responsabilités. Le retrieval ne doit pas décider seul. L'agent ne doit pas avoir tous les droits. Le modèle fine-tuné ne doit pas remplacer les données fraîches. Chaque couche doit faire ce qu'elle fait le mieux.

L'impact UX du choix architectural

L'architecture se voit dans l'interface. Un produit RAG doit afficher des sources, des passages, des niveaux de confiance et parfois une façon de corriger le contexte. Un produit agentique doit afficher les étapes, les actions préparées, les validations nécessaires et l'historique. Un produit fine-tuné doit surtout donner une expérience rapide, cohérente et prévisible.

Si l'UX ne reflète pas l'architecture, l'utilisateur ne comprend pas ce qui se passe. Il ne sait pas si la réponse vient d'un document, d'une déduction, d'un outil ou d'une règle. C'est là que la confiance se perd.

Une grille de décision simple

• Application de support avec documentation qui change souvent : RAG + citations + escalade humaine.
• Outil interne qui prépare et met à jour des dossiers : RAG + outils + agent semi-autonome.
• SaaS qui génère toujours le même type de livrable : sortie structurée, puis fine-tuning si le volume le justifie.
• Application mobile de coaching : mémoire utilisateur, recommandations, modèle routé et UX très contrôlée.
• Produit très réglementé : RAG permissionné, logs, validation humaine, évaluation stricte et actions limitées.

Le bon choix n'est donc pas le plus avancé techniquement. C'est celui qui donne le meilleur ratio valeur, fiabilité, coût, contrôle et expérience utilisateur.

Une architecture IA n'est réussie que si elle rend le produit plus utile, plus fiable et plus simple à utiliser. Le reste est de la complexité décorative.