🌳 L'arbre de décision : par où commencer ?
Avant de plonger dans les détails techniques, voici la question fondamentale :
Le modèle de base donne-t-il déjà des résultats corrects avec un bon prompt ?
- Oui, mais pas assez précis → Améliorez votre prompting (Section 1)
- Non, il lui manque des connaissances spécifiques → Implémentez du RAG (Section 2)
- Non, il ne comprend pas le style/format/domaine → Envisagez le fine-tuning (Section 3)
Pour prendre cette décision, partez de votre cas d'usage et posez-vous cette première question : le modèle de base comprend-il la tâche ? Si oui, vérifiez si les résultats sont suffisants (dans ce cas, arrêtez-vous là). Si les résultats ne sont pas bons, deux raisons sont possibles : soit il lui manque des connaissances (orientez-vous vers le RAG), soit il ne maîtrise pas le format ou le style (orientez-vous vers le fine-tuning).
La règle d'or : commencez TOUJOURS par le prompting
Le prompting avancé est gratuit (en termes de développement), instantané et souvent suffisant. Ne sautez pas cette étape.
| Approche | Commencez ici si... |
|---|---|
| Prompting | Toujours. C'est votre point de départ. |
| RAG | Le modèle a besoin d'infos qu'il n'a pas (docs internes, données récentes) |
| Fine-tuning | Le modèle doit adopter un style/comportement spécifique à grande échelle |
🎯 Prompting avancé : l'art de bien demander
Pourquoi le prompting est sous-estimé
80% des projets qui pensent avoir besoin de fine-tuning ont en réalité besoin d'un meilleur prompt. Le prompting avancé, c'est bien plus que « pose ta question clairement ». C'est une discipline d'ingénierie à part entière.
System prompt : votre fondation
Le system prompt définit le comportement de base du modèle. C'est le levier le plus puissant et le plus sous-utilisé. Un system prompt efficace doit être structuré en plusieurs sections : le rôle précis (expert en droit fiscal français pour les PME, par exemple), le format de réponse attendu (réponse courte, base légale, recommandation), et les règles strictes à respecter (ne jamais inventer d'information, signaler les incertitudes). Contrairement à un prompt faible comme « Tu es un assistant utile », un prompt structuré encadre fermement le modèle pour des résultats fiables.
Few-shot prompting : apprendre par l'exemple
Le few-shot consiste à donner des exemples de paires input/output pour guider le modèle. Par exemple, pour classifier des tickets support, on fournit deux ou trois exemples comme : le ticket « Mon paiement a été débité deux fois » est classé en catégorie facturation avec une priorité haute, puis on demande au modèle de classifier un nouveau ticket selon ce même schéma.
Chain-of-Thought (CoT) : faire réfléchir le modèle
Le Chain-of-Thought consiste à demander au modèle de décomposer son raisonnement étape par étape avant de donner sa réponse finale. Cette technique réduit considérablement les erreurs de calcul et de logique, car elle force le modèle à expliciter chaque étape intermédiaire plutôt que de sauter directement à la conclusion.
Structured output : contrôler le format
Demander une sortie structurée (JSON, XML) améliore la fiabilité et réduit les tokens de sortie. Pour l'extraction de données d'une facture par exemple, on spécifie le format JSON attendu avec des champs précis : numéro de facture (string), date (YYYY-MM-DD), client (string), montant HT (number), TVA (number) et total TTC (number). Le modèle renvoie alors un JSON directement exploitable par votre code, sans texte superflu.
Quand le prompting ne suffit plus
Le prompting atteint ses limites quand :
- Le modèle n'a tout simplement pas les connaissances nécessaires (données internes, infos post-training)
- Vous avez besoin d'un style très spécifique à grande échelle (milliers de requêtes)
- La latence du few-shot est trop élevée (trop d'exemples = trop de tokens)
- La cohérence sur des milliers de requêtes n'est pas suffisante
C'est là que RAG et fine-tuning entrent en jeu.
📚 RAG : donner des connaissances au modèle
Le principe du RAG
RAG (Retrieval-Augmented Generation) consiste à chercher des informations pertinentes dans une base de données, puis à les injecter dans le prompt avant de générer la réponse.
Le processus se déroule en trois étapes consécutives. D'abord, l'utilisateur pose sa question, qui déclenche une phase de retrieval : le système cherche les documents les plus pertinents dans votre base documentaire. Ensuite, vient la phase d'augmentation : ces documents pertinents sont ajoutés au prompt en tant que contexte. Enfin, la phase de génération : le LLM reçoit ce prompt enrichi et produit sa réponse en s'appuyant sur les informations injectées.
Les embeddings : transformer le texte en vecteurs
Pour chercher efficacement, on convertit les textes en vecteurs (embeddings) — des représentations numériques qui capturent le sens. Chaque texte est transformé en une longue liste de nombres (par exemple 1536 dimensions avec les modèles OpenAI). Deux textes proches sémantiquement auront des vecteurs proches, ce qui permet de retrouver les documents les plus pertinents en calculant la similarité cosinus entre les vecteurs.
Vector databases : stocker et chercher
Les bases de données vectorielles permettent de stocker des millions d'embeddings et de trouver les plus proches en millisecondes :
| Base vectorielle | Type | Prix | Idéal pour |
|---|---|---|---|
| Chroma | Open-source, local | Gratuit | Prototypage, petits projets |
| Pinecone | Cloud managé | $0.33/M vecteurs/mois | Production, scalabilité |
| Weaviate | Open-source + cloud | Gratuit → payant | Multimodal, flexible |
| pgvector | Extension PostgreSQL | Gratuit | Si vous avez déjà PostgreSQL |
| Qdrant | Open-source + cloud | Gratuit → payant | Performance, Rust-based |
| FAISS | Librairie Meta | Gratuit | Recherche brute, gros volumes |
Pipeline RAG complet
Un pipeline RAG se déroule en trois étapes. D'abord, l'indexation : chaque document est découpé en chunks, transformé en embedding via un modèle comme text-embedding-3-small, puis stocké dans une base vectorielle comme ChromaDB. Ensuite, le retrieval : à chaque question utilisateur, on génère l'embedding de la question et on recherche les chunks les plus similaires dans la base. Enfin, la génération : les documents pertinents sont injectés dans le prompt en tant que contexte, et le LLM génère sa réponse en se basant uniquement sur ces informations.
Chunking : découper intelligemment
La qualité du RAG dépend énormément du chunking (découpage des documents). Il existe plusieurs approches : le découpage par taille fixe (simple mais qui peut couper des phrases en deux), le découpage par paragraphes ou sections (qui respecte la structure du document), et le chunking sémantique (qui utilise un modèle pour détecter les changements de sujet et découper aux frontières logiques). Cette dernière méthode offre la meilleure qualité mais est plus complexe à mettre en œuvre.
| Méthode | Qualité | Complexité | Cas d'usage |
|---|---|---|---|
| Taille fixe | ⭐⭐ | Très simple | Prototypage |
| Par paragraphe | ⭐⭐⭐ | Simple | Documents structurés |
| Par section/titre | ⭐⭐⭐⭐ | Moyen | Documentation, articles |
| Sémantique | ⭐⭐⭐⭐⭐ | Complexe | Production, qualité max |
Quand utiliser le RAG
✅ RAG est idéal quand :
- Vos données changent fréquemment (actualités, docs produit)
- Vous avez besoin de citer vos sources (traçabilité)
- Vos documents sont trop volumineux pour le contexte
- Vous voulez garder le modèle de base (pas de fine-tuning)
❌ RAG n'est PAS idéal quand :
- Le problème est le style de réponse, pas les connaissances
- Vous avez besoin de latence ultra-faible
- Vos données sont simples et tiennent dans le prompt
🔧 Fine-tuning : customiser le modèle
Qu'est-ce que le fine-tuning ?
Le fine-tuning consiste à ré-entraîner un modèle pré-existant sur vos propres données pour qu'il adopte un comportement spécifique. C'est comme donner des cours particuliers au modèle.
Concrètement, le processus prend un modèle de base pré-entraîné (comme GPT-4o, Claude ou Llama), puis lui soumet vos données d'entraînement spécifiques lors d'une phase de ré-entraînement. À l'issue de cette étape, vous obtenez un modèle personnalisé qui comprend votre domaine et a adopté le style de réponse attendu. Attention cependant : ce modèle « personnalisé » a un coût de maintenance, puisqu'il faut souvent le re-fine-tuner lorsque le modèle de base est mis à jour.
Données nécessaires
Le fine-tuning nécessite des paires d'exemples (input → output attendu) au format JSONL. Chaque ligne contient un objet messages avec trois rôles : system (qui définit le comportement attendu, comme « Tu es l'assistant de la boutique XYZ »), user (la question ou requête), et assistant (la réponse idéale que le modèle doit apprendre à reproduire). Il faut suffisamment de ces paires pour couvrir les cas d'usage variés sans que le modèle les mémorise par cœur.
Combien de données faut-il ?
| Objectif | Données minimum | Données recommandées | Temps |
|---|---|---|---|
| Style de réponse | 50-100 exemples | 200-500 | 30 min - 2h |
| Domaine spécifique | 200-500 exemples | 1K-5K | 1h - 8h |
| Tâche complexe | 1K+ exemples | 5K-50K | 4h - 48h |
| Nouveau comportement | 5K+ exemples | 10K-100K | 24h+ |
Coûts du fine-tuning
Voici les coûts approximatifs à la mi-2025 :
| Modèle | Coût d'entraînement | Coût d'inférence (input) | Coût d'inférence (output) |
|---|---|---|---|
| GPT-4o mini | 3,00 $ / million de tokens | 0,30 $ / M tokens | 1,20 $ / M tokens (2x le prix de base) |
| GPT-4o | 25,00 $ / million de tokens | 3,75 $ / M tokens | 15,00 $ / M tokens (1,5x le prix de base) |
| Llama 3 (self-hosted) | Coût GPU (1-5 $/h sur A100) | Coût GPU uniquement | Coût GPU uniquement |
Cas d'usage réels du fine-tuning
- Tone of voice d'entreprise : votre chatbot parle exactement comme votre marque
- Classification ultra-rapide : fine-tuner un petit modèle pour classifier en 1 token
- Langue/dialecte spécifique : adapter au jargon médical, juridique, technique
- Réduction de coûts : un petit modèle fine-tuné peut remplacer un gros modèle generic
Les pièges du fine-tuning
⚠️ Attention aux erreurs courantes :
- Catastrophic forgetting : le modèle « oublie » ses capacités générales
- Overfitting : trop peu de données → le modèle mémorise au lieu d'apprendre
- Données biaisées : vos exemples transmettent vos biais au modèle
- Coût de maintenance : il faut re-fine-tuner à chaque mise à jour du modèle de base
- Pas magique : si le modèle de base ne sait pas faire la tâche, le fine-tuning n'aidera probablement pas
📊 Tableau comparatif : Prompting vs RAG vs Fine-tuning
| Critère | Prompting avancé | RAG | Fine-tuning |
|---|---|---|---|
| Coût initial | Quasi nul | Moyen (infra + embeddings) | Élevé (données + entraînement) |
| Coût par requête | Normal | Normal + recherche | Souvent réduit |
| Temps de mise en place | Minutes/heures | Jours/semaines | Semaines/mois |
| Connaissances fraîches | ❌ Limité au training | ✅ Temps réel | ❌ Figé au fine-tuning |
| Style personnalisé | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| Précision domaine | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Traçabilité (sources) | ❌ | ✅ Citations possibles | ❌ |
| Maintenance | Faible | Moyenne (index à jour) | Élevée (re-training) |
| Complexité technique | Faible | Moyenne | Élevée |
| Scalabilité | ✅ Immédiate | ✅ Bonne | ⚠️ Modèle dédié |
Combiner les approches
La meilleure solution est souvent une combinaison : un system prompt optimisé (prompting) auquel on ajoute l'injection de documents internes en temps réel (RAG), le tout sur un modèle fine-tuné pour adopter naturellement le ton de votre marque (fine-tuning). Ces trois couches empilées donnent le meilleur résultat possible.
Exemple concret : un chatbot support client
1. Prompting : system prompt avec les règles de conversation
2. RAG : recherche dans la base de connaissances / FAQ
3. Fine-tuning : le modèle adopte le ton de la marque naturellement
🗺️ Guide pratique : quelle approche pour quel projet ?
| Projet | Recommandation | Pourquoi |
|---|---|---|
| Chatbot FAQ entreprise | RAG + Prompting | Connaissances internes + format contrôlé |
| Rédaction marketing | Prompting (few-shot) | Style contrôlable par exemples |
| Analyse de contrats | RAG + Prompting | Docs longs + extraction structurée |
| Assistant code interne | RAG (codebase) + Prompting | Connaît votre code, style de réponse flexible. Pour choisir le bon modèle, consultez notre guide des meilleurs LLM pour coder. |
| Classification emails (volume) | Fine-tuning (petit modèle) | Volume élevé, coût réduit par requête |
| Traduction domaine spécifique | Fine-tuning | Jargon spécifique à apprendre |
| Veille actualités | RAG (flux RSS) | Données fraîches quotidiennes |
| Agent autonome | Prompting + RAG | Flexibilité max, accès à vos outils. Pour sélectionner le modèle adapté à ce cas d'usage, voir notre comparatif des meilleurs LLM pour les agents IA. |
🚀 Par où commencer concrètement ?
Étape 1 : Optimisez vos prompts (Jour 1)
Pour structurer votre travail de prompting, vérifiez ces points : votre system prompt est-il structuré avec un rôle, des règles et un format de sortie clair ? Avez-vous ajouté 3 à 5 exemples few-shot pour les tâches récurrentes ? Avez-vous précisé les instructions de format (JSON si possible) ? Les guardrails sont-ils en place (« ne fais PAS… », « si incertain, dis-le ») ? Enfin, avez-vous testé sur au moins 20 cas variés ?
Étape 2 : Évaluez si vous avez besoin de plus (Semaine 1)
Posez-vous ces cinq questions d'évaluation : le modèle a-t-il les connaissances nécessaires (si non → RAG) ? Le style de réponse est-il acceptable (si non → fine-tuning) ? Les réponses sont-elles assez précises (si non → RAG ou fine-tuning) ? Le coût par requête est-il acceptable (si non → fine-tuning sur un petit modèle) ? La latence est-elle acceptable (si non → fine-tuning ou mise en cache) ?
Étape 3 : Implémentez progressivement (Semaines 2-4)
- RAG : commencez avec ChromaDB en local, migrez vers un service managé si ça marche
- Fine-tuning : commencez avec 100 exemples sur GPT-4o mini, itérez
L'essentiel
- Commencez toujours par le prompting : c'est gratuit, immédiat, et résout 80 % des cas d'usage.
- Passez au RAG quand le modèle manque de connaissances spécifiques (docs internes, données récentes).
- Envisagez le fine-tuning uniquement pour le style, le ton ou un domaine très spécialisé à grande échelle.
- Combinez les approches pour les projets ambitieux : prompting + RAG + fine-tuning donnent les meilleurs résultats.
Outils recommandés
- Prompting : le playground de votre provider (OpenAI, Anthropic), ou Claude, GPT, Gemini, Llama : quel modèle choisir en 2026 ? pour comparer les modèles.
- RAG : ChromaDB (prototypage), Pinecone (production), pgvector (si vous avez déjà PostgreSQL).
- Fine-tuning : les API de fine-tuning d'OpenAI, ou des modèles open-source comme Qwen3.6 : Alibaba débarque avec une nouvelle famille de modèles LLM pour du self-hosting.
- Modèles gratuits : pour réduire les coûts lors de la phase de test, vous pouvez aussi consulter notre page dédiée aux meilleurs LLM gratuits.
Conclusion
Choisir entre prompting, RAG et fine-tuning n'est pas une question de niveau technique, mais de bon sens stratégique. Trop d'équipes sautent directement au fine-tuning ou au RAG alors qu'un prompt mieux structuré aurait suffi. À l'inverse, d'autres persistent avec du prompting alors que leurs données internes restent inaccessibles au modèle.
La méthode est simple : optimisez vos prompts d'abord, mesurez les lacunes, puis ajoutez uniquement la complexité nécessaire. En 2025, les outils sont matures et les coûts ont baissé — il n'y a plus d'excuse pour ne pas tester itérativement.
Si vous voulez aller plus loin sur la compréhension des coûts (tokens, fenêtre de contexte, facturation), notre article sur la facturation des LLM vous sera utile. Et pour éviter les réponses inventées de votre modèle, la méthode phi_first permet de détecter les hallucinations en un seul token. Enfin, si votre projet implique l'analyse d'images, consultez notre guide sur la vision IA pour analyser des images avec les LLM.
```