Il y a trois manières honnêtes de rendre un LLM utile avec vos données. La plupart des équipes choisissent la mauvaise parce que le choix est cadré par les vendeurs d'outils, pas par les arbitrages d'ingénierie. On a vu sur la dernière année au moins six équipes passer trois à neuf mois sur un fine-tune qui aurait dû être une pipeline RAG, ou construire un prompt de 60 000 tokens de "context window" qui aurait dû être un fine-tune. Voici l'arbre de décision réel, avec les chiffres qui le pilotent.
Les trois approches en un paragraphe chacune
Prompt seul
Vous passez tout ce que le modèle doit savoir dans le prompt lui-même. Quelques exemples few-shot, des instructions, du contexte. Pas de récupération externe, pas d'entraînement de modèle.
Idéal pour : des connaissances stables qui tiennent dans le contexte, des cas d'usage à faible volume, des prototypes, tout ce où la "connaissance" est en réalité du conditionnement de comportement (ton, format de sortie, verbes autorisés).
RAG (Retrieval-Augmented Generation)
Vous gardez vos données dans une vector store, ou un index full-text, ou les deux. À chaque requête, vous récupérez les fragments pertinents et les injectez dans le prompt avant que le modèle réponde.
Idéal pour : des bases de connaissances larges et évolutives, des besoins de citation et d'auditabilité, des situations où le coût du réentraînement dépasse celui de la récupération. La plupart des cas d'usage production "assistant IA" atterrissent ici.
Fine-tuning
Vous prenez un modèle de base et entraînez une fine couche dessus avec des milliers de paires entrée-et-sortie-attendue. Le modèle apprend les patterns plutôt que de les lire à l'inférence.
Idéal pour : des formats de sortie constants, du jargon domaine-spécifique, de la réplication de ton, des situations où vous avez au moins 1 000 paires d'exemples de haute qualité et où les patterns sous-jacents sont stables pendant des mois.
L'arbre de décision réel
Connaissance stable + assez petite pour tenir dans le contexte ? -> Prompt seul.
Connaissance large, évolutive, ou auditable ? -> RAG.
Le problème est le FORMAT ou le TON (pas la connaissance) ? -> Fine-tune.
Aucun ? -> Combinez.
RAG + formatter fine-tuné,
c'est la stack de prod la plus
courante en 2026.
Le piège dans lequel la plupart des équipes tombent, c'est traiter ces trois approches comme exclusives. Elles ne le sont pas. La vraie stack production dans les produits IA sérieux est presque toujours RAG pour les connaissances, plus un petit fine-tune pour le formatage de sortie ou le registre de domaine. Anthropic, OpenAI et Cohere vendent tous des composants pour les deux moitiés de cette stack.
La réalité des coûts, avec les chiffres actuels
Les chiffres ci-dessous sont les prix publics de mi-2026, arrondis pour la lisibilité. Votre taux contractuel est probablement 10 à 30 pour cent inférieur à n'importe quel volume significatif.
Coût d'inférence par million de tokens (entrée / sortie)
| Modèle | Entrée | Sortie | Entrée en cache |
|---|---|---|---|
| GPT-4o | 2,50 $ | 10,00 $ | 1,25 $ |
| GPT-4o-mini | 0,15 $ | 0,60 $ | 0,075 $ |
| o1 (reasoning) | 15,00 $ | 60,00 $ | 7,50 $ |
| o1-mini | 3,00 $ | 12,00 $ | 1,50 $ |
| Claude Sonnet 4 | 3,00 $ | 15,00 $ | 0,30 $ (-90%) |
| Claude Haiku 4.5 | 1,00 $ | 5,00 $ | 0,10 $ (-90%) |
| Gemini 1.5 Pro | 1,25 $ | 5,00 $ | varie par région |
| Gemini 1.5 Flash | 0,075 $ | 0,30 $ | n/a |
Deux choses comptent dans ce tableau pour votre choix d'architecture :
-
L'entrée en cache est beaucoup moins chère que l'entrée fraîche. Le prompt caching d'Anthropic offre environ 90 pour cent de réduction sur la portion en cache après la première lecture. L'entrée en cache d'OpenAI est à moitié prix de l'entrée fraîche. Si vous envoyez le même system prompt ou les mêmes documents récupérés au modèle sur de nombreux appels dans une fenêtre, le cache est le levier de coût le plus important que vous ayez.
-
Les tokens de sortie dominent la facture, pas l'entrée. Une réponse de 4 000 tokens au tarif sortie GPT-4o coûte la même chose que 16 000 tokens d'entrée. Les designs qui "économisent les tokens" en compressant le prompt mais en acceptant des réponses plus longues sont net-négatifs.
Coût initial pour mettre chaque approche en production
| Approche | Coût initial | Par requête | Coût de mise à jour |
|---|---|---|---|
| Prompt seul | Effectivement zéro | Élevé (prompts longs à chaque appel) | Éditer le prompt, redéployer |
| RAG | Provisionnement vector store, pipeline de chunking, set d'éval : 1 à 3 semaines-ingénieur | Modéré (la récupération coûte peu, le contexte reste gros) | Réindexer à chaque changement |
| Fine-tune | Labellisation des données : 1 à 4 semaines-ingénieur. Run d'entraînement : 500 $ à 10 000 $ | Plus faible par requête (prompts plus courts) | Nouveau run à chaque mise à jour significative, 500 $ à 10 000 $ à chaque fois |
Pour la plupart des produits, RAG gagne sur le coût total de possession parce que les connaissances évoluent plus vite que les fine-tunes ne peuvent suivre, et l'économie par requête du fine-tuning ne compense que rarement le coût par mise à jour.
RAG, la partie que les cookbooks survolent
Le RAG "vanille" que montre la plupart des articles de blog, c'est : chunker chaque document en morceaux de 1 000 caractères, embedder chaque chunk, les stocker dans une vector database, récupérer les top 3 par similarité cosine, les injecter dans le prompt. Ça marche pour un démo. Ça ne marche pas en production. Six choses comptent :
Taille des chunks et chevauchement
Des chunks trop petits perdent le contexte (vous récupérez "nous recommandons X" sans les conditions qui suivent). Des chunks trop grands incluent du matériel hors sujet qui dégrade la précision de la récupération. Pour des documents en prose, on finit généralement entre 400 et 800 tokens avec 50 à 100 tokens de chevauchement. Pour des données structurées (FAQ, clauses de politique, code), chunkez par unité sémantique (une clause = un chunk) pas par compte de caractères.
Choix du modèle d'embedding
| Modèle | Dimensions | Prix par 1M tokens | Notes |
|---|---|---|---|
| OpenAI text-embedding-3-small | 1 536 | 0,02 $ | Défaut de départ. Bon. |
| OpenAI text-embedding-3-large | 3 072 | 0,13 $ | Meilleur rappel, 6x plus cher, 2x le stockage |
| Voyage voyage-3-large | 1 024 | 0,18 $ | Souvent en tête du MTEB. Fort sur code et technique. |
| Cohere embed-v4 | jusqu'à 1 536 | 0,10 $ | Le meilleur pour le multilingue dont l'arabe |
| Open weights (BGE, E5) | 384 à 1 024 | auto-hébergé | Gratuit, environ 2x le temps de votre équipe à opérer |
Si votre corpus est du texte technique anglais seulement, OpenAI-small est le bon défaut jusqu'à ce que vous ayez une raison mesurée d'en changer. Si vous servez arabe ou français + anglais depuis le même index, Cohere embed-v4 est le choix nettement meilleur. Si vous stockez du code source, Voyage-3-large est ce qu'on a fini par utiliser.
La recherche hybride bat la recherche vectorielle pure
La similarité sémantique pure rate les requêtes exactes. Un utilisateur qui cherche "code d'erreur E_TIMEOUT_5023" veut le document qui contient cette chaîne littérale, pas celui qui est sémantiquement le plus proche. Le RAG en production fait tourner recherche vectorielle et BM25 (ou votre index full-text préféré) en parallèle, puis fusionne. Postgres avec pgvector gère les deux nativement. Weaviate a l'hybride intégré. Si vous êtes sur Pinecone, vous boulonnez BM25 vous-même.
Le reranker, la plus économique des améliorations qualité de 20 points
Après avoir récupéré les top 20 à 50 candidats, un reranker score chacun contre la requête et garde les top 3 à 5. Cohere Rerank 3.5 coûte environ 2 $ pour 1 000 recherches et améliore de façon fiable la pertinence des réponses de 15 à 30 pour cent sur nos benchmarks internes. Voyage et Jina vendent des rerankers compétitifs. Il y a aussi bge-reranker en open weights. Le reranker est la chose unique la moins chère que vous puissiez ajouter à une pipeline RAG qui améliore vraiment la qualité.
Choix de la vector store
| Store | Hébergé ? | Forme de coût | Quand c'est le bon |
|---|---|---|---|
| pgvector | Auto ou Supabase/Neon | Gratuit si vous avez déjà Postgres | Jusqu'à ~10M vecteurs avec HNSW. Le défaut pragmatique. |
| Qdrant | Auto ou cloud | Gratuit auto-hébergé, 20 $+/mois cloud | Quand pgvector commence à fatiguer. Excellent sur le filtrage. |
| Weaviate | Auto ou cloud | Gratuit auto-hébergé, ~25 $+/mois cloud | La recherche hybride out-of-the-box est imbattable. |
| Pinecone | Hébergé seulement | 70 $+/mois starter, croît vite | Quand vous voulez zéro infra et acceptez de payer. |
| LanceDB | Embarqué ou serveur | Gratuit | Quand vous voulez les vecteurs comme fichiers (versionnés via Git LFS). |
Le défaut pour les nouveaux projets en 2026 devrait être pgvector, à moins d'avoir mesuré que ça ne suffit pas. La promesse des "vector databases managées", c'est surtout qu'elles vous économisent la courbe d'apprentissage opérationnelle. C'est un coût ponctuel. La facture, elle, est éternelle.
Où vivent les métadonnées
Chaque chunk a besoin de métadonnées : document source, auteur, date de dernière mise à jour, permissions d'accès, langue, type de document. Sans ça, vous ne pouvez pas filtrer ("ne récupérez que dans les documents que l'utilisateur courant a le droit de voir"), vous ne pouvez pas évincer les entrées obsolètes, et vous ne pouvez pas déboguer "pourquoi cette réponse a-t-elle utilisé un document de 2019". Construisez ça dans votre pipeline de chunking dès le jour un, pas en rétrofit.
Quand fine-tuner vraiment
Le fine-tuning gagne ses lettres dans trois scénarios. Hors de là, préférez RAG avec un prompt plus net.
1. Format de sortie constant. Vous voulez chaque réponse dans une forme JSON spécifique, ou dans une structure markdown spécifique, ou comme un langage de balisage spécifique. Les solutions prompt-seul fuient sur les cas limites, contrairement aux fine-tunes. Coût horaire : peut-être 2 jours-ingénieur pour assembler 200 à 500 exemples, 50 $ à 200 $ pour un petit fine-tune.
2. Registre de domaine et ton. Votre audience, c'est par exemple les praticiens juridiques marocains francophones et vous avez besoin que le texte atterrisse dans ce registre. Les instructions de prompt vous emmènent loin. Le fine-tune verrouille les 15 derniers pour cent. Vous avez besoin de 1 000 exemples réels du monde, pas synthétiques, pour que ça marche.
3. Réduction de latence ou coût à fort volume. Un petit modèle fine-tuné peut remplacer un grand modèle avec instructions de prompt, avec 5 à 10x de réduction de coût et 2 à 3x de réduction de latence. Ça ne paye qu'au-dessus de roughly 100 000 requêtes par jour par cas d'usage. En-dessous, le temps d'ingénierie coûte plus que l'économie d'inférence.
L'API fine-tune d'OpenAI facture environ 25 $ par million de tokens d'entraînement pour GPT-4o-mini (données d'entraînement, pas d'inférence). Le fine-tuning Claude d'Anthropic est disponible via AWS Bedrock pour Haiku. Pour les open weights, Together AI, Fireworks et Anyscale offrent du fine-tuning de Llama, Mistral et Qwen à des tarifs compétitifs avec endpoints déployables.
L'exemple concret qu'on remet à chaque équipe
Une équipe vient nous voir avec : "On a 800 documents internes de politique produit. Notre équipe support veut poser des questions en langage naturel et récupérer des réponses ancrées et citables. Les documents changent toutes les semaines. L'équipe fait 30 utilisateurs quotidiens."
La mauvaise réponse : "Fine-tunons un modèle sur vos politiques."
La bonne réponse :
- pgvector sur l'instance Postgres existante, un index HNSW
- Cohere embed-v4 pour les embeddings (le corpus mélange français et anglais)
- Chunks de 600 tokens avec 100 tokens de chevauchement, un chunk par clause logique quand possible
- Récupération hybride (vector + BM25), top 40 candidats
- Cohere Rerank 3.5 jusqu'aux top 5
- Claude Haiku 4.5 pour la réponse, avec les 5 chunks injectés et une obligation de citation structurée
- Prompt caching sur le system prompt et les instructions de rendu de politique
Coût d'infrastructure total : environ 40 $ par mois à cette échelle (une instance Postgres, quelques milliers de reranks, quelques milliers de réponses). Temps de construction : 6 jours ouvrés pour une v1 utilisable, deux semaines de plus d'itération pilotée par les évaluations pour passer la qualité de réponse au-dessus de 85 pour cent sur le golden set de l'équipe.
Un fine-tune pour le même problème aurait coûté entre 2 000 $ et 8 000 $, pris huit semaines, et aurait commencé à devenir obsolète le lendemain de chaque mise à jour hebdomadaire de politique. Cette comparaison n'est pas inhabituelle.
Ce que les équipes font mal, encore
La plus grande erreur, c'est de fine-tuner quand le vrai problème est une mauvaise récupération. Vous pouvez fine-tuner un modèle pour mémoriser 200 faits sur votre produit, mais vous ne pouvez pas le fine-tuner pour connaître la politique que votre équipe a publiée hier. Si vos données changent plus vite que votre cadence d'entraînement, vous voulez RAG.
La deuxième plus grande erreur, c'est de livrer du RAG vanille (chunks de 1 000 caractères, top 3 vectoriel, pas de rerank, pas de filtre) et de conclure que "le RAG ne marche pas" quand les réponses sont médiocres. Le chunking par défaut n'est presque jamais la bonne configuration. Passez une semaine concentrée sur la taille des chunks, la recherche hybride et le reranking, et la qualité de votre RAG grimpe plus que le passage de GPT-4o-mini à GPT-4o ne le ferait.
La troisième erreur, c'est de construire tout ça sans un set d'évaluation. Sans mesures, chaque changement a l'air d'une amélioration quand il est livré lundi, et d'une régression jeudi. Le set d'évaluation n'est pas négociable.
Ce qu'on a couvert, ce qui suit
Cet article est volontairement opinionné. Les arbitrages sont réels et le coût de choisir mal est élevé. Pour un traitement plus approfondi, les cookbooks d'Anthropic et OpenAI ont de bons exemples, mais ni l'un ni l'autre ne vous dira quand ne pas utiliser leur outil, et ni l'un ni l'autre n'a d'analyse directe du coût total de possession.
Prochainement dans la série production : comment on fait tourner les évaluations rapidement, pourquoi ROC, précision et rappel mentent sur la qualité des LLM, et les trois techniques d'évaluation auxquelles on fait confiance. Pour être prévenu de la sortie, le formulaire d'abonnement est en bas de la page d'accueil.
