RAG, fine-tuning, prompt engineering : que choisir pour votre cas d'usage

Vous voulez connecter un modèle de langage à vos données métier. Trois approches reviennent systématiquement : le prompt engineering, le RAG et le fine-tuning. Chacune a ses forces, ses limites et son contexte d'usage. Le choix de la mauvaise approche coûte des mois et des milliers d'euros pour un résultat décevant.

Ce guide vous aide à trancher sans jargon inutile, en partant de vos contraintes réelles : budget, délai, compétences disponibles et niveau de confidentialité requis.

Le prompt engineering : le point de départ

De quoi parle-t-on ?

Le prompt engineering consiste à formuler les instructions envoyées au modèle pour obtenir la réponse souhaitée. Pas de modification du modèle, pas d'infrastructure supplémentaire : vous travaillez uniquement sur le texte d'entrée.

Concrètement, cela inclut :

• Le system prompt — les instructions permanentes qui définissent le comportement du modèle (rôle, ton, format de sortie, contraintes)
• Le few-shot learning — des exemples de paires entrée/sortie inclus dans le prompt pour guider le modèle
• Le chaînage de prompts — décomposer une tâche complexe en plusieurs appels successifs, chacun avec un prompt spécialisé
• Le formatage de sortie — demander au modèle de répondre en JSON, en tableau ou dans un format structuré exploitable par le code

Quand le prompt engineering suffit

Pour beaucoup de cas d'usage, un prompt bien conçu avec un modèle performant (GPT-4o, Claude, Mistral Large) donne des résultats suffisants sans infrastructure supplémentaire :

• Classification de texte (sentiment, catégorie, intention)
• Résumé de documents courts (emails, tickets, commentaires)
• Extraction d'entités (noms, dates, montants) à partir de texte libre
• Génération de texte avec un format et un ton définis
• Traduction et reformulation

Les limites

Le prompt engineering atteint ses limites quand :

• Le modèle a besoin d'informations qu'il ne possède pas (données internes, documents récents, base de connaissances)
• Le contexte dépasse la fenêtre du modèle (même les fenêtres de 128k tokens ont un coût et une dégradation de performance)
• La tâche exige une terminologie métier très spécifique que le modèle ne maîtrise pas naturellement

Le RAG : connecter un LLM à vos données

Le principe

Le RAG (Retrieval-Augmented Generation) consiste à enrichir le prompt avec des informations pertinentes extraites de vos propres données, au moment de la requête. Le modèle ne stocke pas vos données : il les reçoit en contexte à chaque appel.

L'architecture en quatre étapes

Un pipeline RAG suit un flux bien défini :

• Indexation — vos documents sont découpés en morceaux (chunks), puis transformés en vecteurs numériques (embeddings) par un modèle d'embedding. Ces vecteurs sont stockés dans une base vectorielle (Pinecone, Weaviate, pgvector, Qdrant)
• Recherche — quand un utilisateur pose une question, celle-ci est transformée en vecteur et comparée aux vecteurs indexés pour trouver les passages les plus pertinents
• Augmentation — les passages trouvés sont injectés dans le prompt, avec la question de l'utilisateur et les instructions du system prompt
• Génération — le modèle produit une réponse en s'appuyant sur le contexte fourni, pas sur ses seules connaissances

Les cas d'usage naturels

Le RAG excelle quand le modèle doit répondre en s'appuyant sur des données spécifiques et potentiellement volumineuses :

• Documentation interne — permettre aux équipes de poser des questions en langage naturel sur des procédures, manuels ou wikis internes
• Support client — répondre aux questions en s'appuyant sur la base de connaissances existante, les FAQ et l'historique des tickets
• Analyse de contrats — interroger un corpus de documents juridiques pour trouver des clauses spécifiques
• Veille et recherche — synthétiser des informations dispersées dans de nombreuses sources

Les points d'attention

Un RAG mal conçu produit des résultats médiocres. Les erreurs courantes :

• Un découpage trop grossier ou trop fin des documents (le chunking est un art)
• Un modèle d'embedding inadapté à la langue ou au domaine
• L'absence de métadonnées (date, source, catégorie) qui permettraient de filtrer les résultats
• Pas de mécanisme pour gérer les documents obsolètes ou contradictoires

Le fine-tuning : spécialiser un modèle

Le principe

Le fine-tuning consiste à ré-entraîner un modèle existant sur un jeu de données spécifique pour modifier son comportement. Contrairement au RAG, les connaissances sont intégrées dans les poids du modèle, pas fournies au moment de la requête.

Quand le fine-tuning est pertinent

Le fine-tuning se justifie dans des cas bien précis :

• Terminologie métier — quand votre domaine utilise un vocabulaire très spécifique que les modèles généralistes ne maîtrisent pas (médical, juridique, industriel)
• Style et ton — quand le modèle doit reproduire un style rédactionnel précis (marque, documentation technique, communication interne)
• Tâche répétitive et bien définie — classification selon une taxonomie interne, extraction d'entités dans un format métier spécifique
• Réduction de coût — un petit modèle fine-tuné peut remplacer un gros modèle généraliste pour une tâche spécifique, à moindre coût par appel

Les contraintes

Le fine-tuning a un coût d'entrée significatif :

• Il faut un jeu de données d'entraînement de qualité (centaines à milliers d'exemples annotés)
• Le processus d'entraînement demande des compétences en machine learning et des ressources de calcul
• Chaque mise à jour des données nécessite un nouvel entraînement
• Le modèle fine-tuné est figé : il ne connaît pas les informations postérieures à l'entraînement

Comparaison sur six critères

Coût de mise en place

Le prompt engineering est le moins coûteux : quelques jours de travail, pas d'infrastructure. Le RAG demande une base vectorielle et un pipeline d'indexation, mais reste accessible. Le fine-tuning est le plus onéreux : préparation des données, entraînement, évaluation.

Délai de mise en oeuvre

Prompt engineering : quelques jours. RAG : deux à six semaines pour un pipeline fonctionnel. Fine-tuning : un à trois mois, données comprises.

Qualité des réponses

Sur des tâches génériques, le prompt engineering avec un bon modèle donne d'excellents résultats. Le RAG améliore la précision factuelle en s'appuyant sur des sources vérifiables. Le fine-tuning optimise la cohérence sur des tâches très spécialisées.

Maintenance

Le prompt engineering demande peu de maintenance. Le RAG nécessite de maintenir l'index à jour quand les données sources évoluent. Le fine-tuning impose un ré-entraînement à chaque évolution significative.

Confidentialité

Le prompt engineering et le RAG envoient les données au fournisseur d'API à chaque requête. Le fine-tuning permet d'utiliser un modèle local, sans transfert de données vers un tiers. Le RAG peut aussi fonctionner en local avec un modèle auto-hébergé.

Compétences requises

Le prompt engineering est accessible à un développeur expérimenté. Le RAG demande des compétences en architecture de données et en recherche vectorielle. Le fine-tuning nécessite une expertise en machine learning.

Matrice de décision

Un arbre de décision simple pour orienter votre choix :

• Le modèle a-t-il besoin de données qu'il ne possède pas ? Non → prompt engineering. Oui → question suivante.
• Ces données changent-elles fréquemment ? Oui → RAG (les données sont mises à jour sans ré-entraînement). Non → question suivante.
• La tâche exige-t-elle un style ou un vocabulaire très spécifique ? Oui → fine-tuning (ou fine-tuning + RAG). Non → RAG.
• Avez-vous des centaines d'exemples annotés et des compétences ML en interne ? Oui → fine-tuning envisageable. Non → RAG + prompt engineering.

Les approches combinées

Dans la pratique, ces trois techniques ne s'excluent pas. Elles se combinent.

Prompt engineering + RAG : le sweet spot

C'est la combinaison la plus courante et la plus rentable pour 80 % des projets. Un système RAG bien conçu avec des prompts optimisés couvre la majorité des besoins : accès aux données internes, réponses factuelles, format de sortie contrôlé.

Le prompt engineering structure la sortie du modèle. Le RAG lui fournit le contexte pertinent. Ensemble, ils produisent des réponses précises, sourçables et adaptées à votre domaine.

RAG + fine-tuning : pour les cas avancés

Quand le domaine est très spécialisé (médical, juridique, industriel), un modèle fine-tuné sur la terminologie métier combiné à un RAG pour les données factuelles donne les meilleurs résultats. Mais le coût et la complexité sont significatifs. Ce niveau se justifie rarement en première intention.

Notre recommandation

Commencez toujours par le prompt engineering. Si les résultats ne suffisent pas parce que le modèle manque de contexte, passez au RAG. Si le modèle ne maîtrise pas votre vocabulaire métier malgré un bon RAG, envisagez le fine-tuning. Chaque étape est un investissement croissant : ne montez en complexité que si le niveau précédent a atteint ses limites.

Passer à l'action

Le choix entre prompt engineering, RAG et fine-tuning dépend de votre cas d'usage, pas d'une préférence technique. Un mauvais choix initial se paie en mois de développement et en résultats décevants.

Nous aidons les PME et ETI à identifier la bonne approche, concevoir l'architecture adaptée et déployer un système qui produit de la valeur dès les premières semaines. Pas de sur-ingénierie, pas de technologie pour la technologie : la solution la plus simple qui résout votre problème.

Découvrez notre accompagnement en intégration IA ou contactez-nous pour un premier échange.