RAG, fine-tuning ou agents : quelle archi IA choisir pour ton SaaS en 2026

En 18 mois, on a déployé l’IA dans 12 produits clients. La majorité voulait au départ “un GPT-4 fine-tuné sur notre data”. À la sortie, on a fine-tuné 2 fois. Le reste est passé en RAG, ou en agents. Voilà la grille qu’on applique pour ne pas se planter d’archi IA.

RAG : pour des données qui bougent

Retrieval-Augmented Generation = on indexe vos données dans une base vectorielle (Pinecone, Qdrant, pgvector), à chaque question utilisateur on cherche les chunks pertinents, et on les injecte dans le prompt du LLM.

Avantages : data toujours à jour (réindexation en temps réel), zéro entraînement, citations sources possibles, coût marginal faible. Idéal pour : helpdesk produit, search interne entreprise, copilote sur documentation, Q&A sur catalogue.

Limite : le LLM “voit” vos données mais ne devient pas votre data. Le style des réponses reste celui du modèle de base.

Fine-tuning : pour un style ou un format propriétaire

Fine-tuning = on prend un modèle de base, on l’entraîne sur vos exemples pour qu’il adopte votre ton, votre structure de sortie, votre jargon.

Avantages : sortie structurée fiable, ton de marque cohérent, réduction du prompt (donc latence + coût). Idéal pour : génération de copy à votre style, classification ultra-spécifique, sortie JSON avec un schéma propriétaire complexe.

Limites majeures : il faut 500 à 5 000 exemples annotés, ça coûte du temps humain (le vrai coût caché), et les données de base sont figées au moment du fine-tuning. Et l’évaluation est dure : comment mesure-t-on “c’est mieux écrit qu’avant” ?

Agents : pour orchestrer plusieurs actions

Un agent = un LLM qui peut décider d’appeler des outils (function calling), enchaîner plusieurs étapes, et auto-corriger ses sorties. Au lieu de “répondre”, il “fait”.

Exemples concrets de nos projets : un agent de research qui fait 6 recherches Tavily, lit 20 pages web, rédige une note de synthèse avec sources. Un agent de support qui lit un ticket, requête la base produit, propose une réponse, escalade si besoin.

Limites : latence (3-12 secondes par cycle), coût (10-50× un appel LLM simple), et la fragilité — un agent qui se perd en boucle coûte cher et frustre l’utilisateur.

Comparatif d’usage

Notre stack IA 2026 par défaut

• LLM : Claude Opus 4.7 / Sonnet 4.6 (Anthropic), GPT-5 (fallback), Llama 3.3 70B (souveraineté)
• Embeddings : Voyage AI ou OpenAI text-embedding-3-large
• Vector DB : pgvector (si Postgres déjà en place), Qdrant Cloud sinon
• Orchestration : Vercel AI SDK + Anthropic SDK pour les agents
• Observability : Langfuse pour tracer les agents en prod
• Eval : Promptfoo pour les tests offline, A/B tests en prod via feature flags

Quand combiner les trois

Le pattern le plus puissant qu’on a déployé : agent qui orchestre des outils, dont un de ces outils est un RAG, et le LLM de base est fine-tuné pour adopter le ton de la marque. C’est complexe à débugger, cher à scaler, mais ça produit les expériences IA les plus différenciantes du marché.

La règle : commence simple, mesure, complexifie quand le problème le justifie. La majorité des projets IA qui échouent ne le font pas par manque d’archi sophistiquée — ils le font par manque de données propres et d’éval rigoureuse.