Agents IA
Prompt engineering pour entreprises : les bases qui font la différence
Maîtrisez le prompt engineering pour obtenir des résultats professionnels avec GPT-4 et Claude. Techniques, templates et exemples concrets pour les équipes métier.
“Comment faire en sorte que mon IA connaisse nos produits, nos procédures internes, notre jargon métier ?” C’est la question que nous posent le plus souvent les DSI et dirigeants de PME qui franchissent le cap de l’IA générative. La réponse n’est pas simple, car elle dépend de votre cas d’usage, de votre budget et de la nature de vos données.
Il existe trois grandes stratégies pour qu’un modèle de langage (LLM) s’appuie sur vos données spécifiques. Chacune a ses atouts, ses limites et son contexte d’application optimal. Ce guide vous donne les clés pour choisir — ou combiner — ces approches en toute connaissance de cause.
Les 3 approches pour qu’un LLM connaisse vos données
1. Le context stuffing (in-context learning)
La méthode la plus simple : vous injectez directement vos données dans le prompt, avant la question de l’utilisateur.
Voici notre catalogue produits : [contenu de votre catalogue]
Question : Quel est le délai de livraison pour le modèle X500 ?Avantages : zéro infrastructure, zéro réentraînement, résultats immédiats.
Limites : la fenêtre de contexte est finie. GPT-5 accepte 128 000 tokens (environ 100 000 mots), ce qui peut sembler large — mais un catalogue de 500 produits avec descriptions détaillées dépasse facilement cette limite. Et chaque token injecté est facturé à chaque requête, ce qui devient vite coûteux à grande échelle.
Le context stuffing convient pour des prototypes, des usages ponctuels ou des bases de données très réduites. Pour une mise en production sérieuse, vous aurez besoin de l’une des deux approches suivantes.
2. RAG — Retrieval-Augmented Generation
Le RAG est aujourd’hui la solution la plus déployée en entreprise pour connecter un LLM à une base de connaissances volumineuse et évolutive.
Principe : au lieu d’injecter toutes vos données dans chaque prompt, le système recherche dynamiquement les passages les plus pertinents au moment de la question, puis les fournit au modèle comme contexte ciblé.
Le pipeline RAG en détail
Phase 1 — Indexation (offline)
Vos documents (PDF, pages web, Notion, Confluence, ERP…) sont découpés en morceaux (chunks), puis convertis en vecteurs numériques via un modèle d’embedding. Ces vecteurs sont stockés dans une base de données vectorielle.
# Exemple simplifié avec LlamaIndex
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
documents = SimpleDirectoryReader("./ma_base_docs").load_data()
index = VectorStoreIndex.from_documents(documents)Phase 2 — Recherche (online, à chaque requête)
La question de l’utilisateur est elle aussi convertie en vecteur. Le système calcule la similarité cosinus entre ce vecteur et tous ceux de votre base, puis récupère les K passages les plus proches sémantiquement.
Phase 3 — Génération
Les passages récupérés sont injectés dans le prompt avec la question originale. Le LLM génère une réponse contextualisée et peut citer ses sources.
Avantages du RAG
- Données toujours à jour : mettez à jour votre base documentaire, les nouvelles informations sont disponibles immédiatement sans réentraînement.
- Sources citables : le modèle peut indiquer d’où vient l’information, ce qui est crucial pour les usages juridiques, médicaux ou réglementaires.
- Pas de fuite de données dans les poids du modèle : vos informations sensibles restent dans votre infrastructure.
- Coût maîtrisé : vous ne réentraînez pas un modèle à plusieurs milliers d’euros.
Limites du RAG
- Latence : chaque requête implique une recherche vectorielle avant la génération, ce qui ajoute 100 à 500 ms selon votre infrastructure.
- Qualité dépendante du chunking : si vos documents sont mal découpés, le retrieval sera médiocre — “garbage in, garbage out”.
- Le modèle n’a pas “appris” votre style : il connaît vos faits, pas votre ton éditorial.
- Coût d’infrastructure : vous devez maintenir un vector store (Qdrant, Weaviate, Pinecone…).
3. Le fine-tuning — Modifier les poids du modèle
Le fine-tuning consiste à reprendre un modèle pré-entraîné (GPT-5 mini, Mistral 7B, Llama 3…) et à le réentraîner sur vos données spécifiques pour modifier ses poids. Le modèle “mémorise” durablement des connaissances, un style ou un comportement.
Le processus de fine-tuning
Étape 1 — Préparer le dataset
Le format standard est le JSONL : chaque ligne contient un échange question/réponse représentatif de ce que vous voulez enseigner au modèle.
{"messages": [{"role": "system", "content": "Tu es l'assistant commercial d'AutomateIA."}, {"role": "user", "content": "Quels sont vos délais d'intervention ?"}, {"role": "assistant", "content": "Nous intervenons sous 48h pour les missions de conseil et sous 5 jours ouvrés pour les déploiements complets."}]}
{"messages": [{"role": "system", "content": "Tu es l'assistant commercial d'AutomateIA."}, {"role": "user", "content": "Travaillez-vous avec les PME ?"}, {"role": "assistant", "content": "Absolument. Nous sommes spécialisés dans l'accompagnement des PME françaises, avec des offres adaptées à partir de 1 500 €."}]}Un bon dataset de fine-tuning comprend généralement entre 50 et 500 exemples de haute qualité pour un cas d’usage ciblé.
Étape 2 — Lancer l’entraînement
Via l’API OpenAI, c’est une opération de quelques lignes :
from openai import OpenAI
client = OpenAI()
job = client.fine_tuning.jobs.create(
training_file="file-abc123",
model="gpt-4o-mini-2024-07-18"
)Mistral propose une API similaire, et Hugging Face permet le fine-tuning de modèles open source (Llama 3, Mistral 7B) sur vos propres serveurs.
Étape 3 — Évaluer
Comparez les sorties du modèle fine-tuné vs le modèle de base sur un jeu de test. Mesurez la précision factuelle, la cohérence stylistique et l’absence d’hallucinations.
Avantages du fine-tuning
- Style et ton intégrés : le modèle écrit exactement comme vous le souhaitez, sans instructions système longues.
- Latence réduite : les connaissances étant dans les poids, pas besoin de retrieval — réponses plus rapides.
- Prompts plus courts : vous n’injectez plus de contexte volumineux à chaque requête, ce qui réduit les coûts d’inférence.
- Comportement cohérent : idéal pour les cas où le ton et le format doivent être constants (newsletters, fiches produits, réponses SAV standardisées).
Limites du fine-tuning
- Données statiques : une fois entraîné, le modèle ne sait pas ce qui a changé dans votre catalogue ou vos procédures. Toute mise à jour implique un nouvel entraînement.
- Coût d’entraînement : compter de 50 € à plusieurs centaines d’euros selon la taille du dataset et le modèle (GPT-5 mini est nettement moins cher que GPT-5).
- Catastrophic forgetting : en apprenant vos données, le modèle peut “oublier” certaines capacités générales — un risque à surveiller.
- Expertise requise : préparer un dataset de qualité et évaluer correctement un modèle fine-tuné demande de la méthode.
Comparatif décisionnel RAG vs fine-tuning
| Critère | RAG | Fine-tuning |
|---|---|---|
| Coût initial | Faible (infra vectorielle) | Moyen à élevé (entraînement) |
| Données dynamiques | Oui, mises à jour instantanées | Non, réentraînement nécessaire |
| Données volumineuses | Oui, illimité | Limité (dataset d’exemples) |
| Style/ton appris | Non | Oui |
| Sources citables | Oui | Non (connaissances intégrées) |
| Latence par requête | +100 à +500 ms | Identique au modèle de base |
| Complexité de mise en oeuvre | Moyenne | Élevée |
| Risque de données obsolètes | Faible | Élevé |
| Contrôle des hallucinations | Élevé (grounding documentaire) | Moyen |
| Cas d’usage typique | Chatbot documentaire, FAQ, support | Rédaction, ton de marque, classification |
Arbre de décision : RAG ou fine-tuning ?
Suivez ces questions pour orienter votre choix :
1. Vos données changent-elles régulièrement (catalogue, procédures, prix) ?
- Oui → RAG
- Non → continuer
2. Cherchez-vous à apprendre un style d’écriture ou un comportement spécifique ?
- Oui → Fine-tuning (éventuellement + RAG)
- Non → continuer
3. Avez-vous besoin de citer les sources dans les réponses ?
- Oui → RAG obligatoire
- Non → continuer
4. Votre base de connaissances dépasse-t-elle 50 000 tokens ?
- Oui → RAG (le context stuffing ne suffit plus)
- Non → context stuffing peut suffire pour un prototype
5. Avez-vous des contraintes de latence très strictes (< 200 ms) ?
- Oui → Fine-tuning (sans retrieval) ou optimisation RAG agressive
- Non → RAG standard
L’approche hybride : RAG + fine-tuning
Dans les cas d’usage les plus exigeants, les deux approches se complètent plutôt qu’elles ne s’opposent.
Comment ça fonctionne :
- Fine-tuner le modèle pour qu’il adopte votre style, votre jargon métier et votre comportement général.
- Lui connecter un pipeline RAG pour les connaissances factuelles qui changent (catalogue, jurisprudence, documentation technique…).
Résultat : un assistant qui parle exactement comme votre entreprise ET qui accède aux informations les plus récentes de votre base documentaire.
Exemple concret : un assistant juridique fine-tuné sur le droit français pour adopter le style de vos avocats, avec un RAG connecté à une base de jurisprudence mise à jour quotidiennement. Le fine-tuning donne le style ; le RAG donne les faits actuels.
Les outils disponibles en 2026
Pour mettre en oeuvre un RAG
- LlamaIndex : framework Python de référence, très modulaire. Idéal pour des pipelines RAG avancés (reranking, agents, query routing).
- LangChain : écosystème plus large, nombreux connecteurs (Notion, Confluence, S3, bases SQL…). Adapté aux LLM orchestrés.
- Flowise : interface visuelle no-code/low-code pour construire des pipelines RAG par glisser-déposer. Parfait pour une première mise en oeuvre rapide.
- N8N : automatisation de workflows incluant des noeuds RAG. Idéal pour connecter votre RAG à vos outils métier existants (CRM, ERP, Slack…).
Pour le vector store : Qdrant (auto-hébergeable, excellent rapport qualité/prix), Weaviate, Pinecone (SaaS), ou pgvector si vous êtes déjà sous PostgreSQL.
Pour le fine-tuning
- OpenAI Fine-tuning API : le plus simple pour GPT-5 mini. Interface web + API bien documentée. Prix transparents.
- Mistral Fine-tuning API : excellent pour des modèles performants à moindre coût, données hébergées en Europe.
- Hugging Face + PEFT/LoRA : fine-tuning de modèles open source (Llama 3.1, Mistral 7B, Phi-3…) sur vos propres GPU ou via des services cloud (RunPod, Lambda Labs). Coût maîtrisé sur le long terme, données sous votre contrôle.
Coûts indicatifs en 2026
Coûts RAG
| Composant | Coût indicatif |
|---|---|
| Embeddings (text-embedding-3-small) | 0,02 $ pour 1 million de tokens |
| Vector store Qdrant cloud (1 Go) | ~10 €/mois |
| Inférence GPT-5 mini | ~0,15 $ / million tokens input |
| Flowise self-hosted | Gratuit (infrastructure propre) |
Pour un chatbot SAV traitant 1 000 requêtes/jour, comptez 50 à 150 €/mois tout compris.
Coûts fine-tuning
| Composant | Coût indicatif |
|---|---|
| Fine-tuning GPT-5 mini (100K tokens dataset) | ~3 $ |
| Fine-tuning GPT-5 (100K tokens) | ~25 $ |
| Inférence modèle fine-tuné (GPT-5 mini) | ~0,30 $ / million tokens input |
| Fine-tuning Mistral 7B (Hugging Face) | 5 à 20 $ selon la taille |
Le coût d’entraînement est relativement faible — c’est le coût d’inférence répété et la nécessité de réentraîner régulièrement qui font monter la facture.
Trois cas concrets pour guider votre décision
Cas 1 — Chatbot SAV e-commerce : RAG recommandé
Votre catalogue de 2 000 produits évolue chaque semaine. Les clients posent des questions sur la disponibilité, les délais, les garanties.
Pourquoi le RAG ? Vos données changent trop souvent pour un fine-tuning viable. Avec un RAG connecté à votre base produits, chaque mise à jour est immédiatement disponible. Les réponses peuvent citer la fiche produit source. Un fine-tuning serait obsolète en quelques semaines.
Stack recommandée : N8N ou Flowise + Qdrant + GPT-5 mini.
Cas 2 — Rédacteur de contenu “à la voix de la marque” : fine-tuning recommandé
Vous produisez 50 articles, fiches produits et newsletters par mois. Le ton doit être identique à celui de votre équipe éditoriale.
Pourquoi le fine-tuning ? Ici, ce n’t pas l’accès à des données récentes qui compte, mais la reproduction d’un style. Un modèle fine-tuné sur 200 exemples de vos meilleurs contenus produira des textes cohérents avec votre charte éditoriale sans prompt système de 2 000 tokens à chaque requête.
Stack recommandée : Fine-tuning GPT-5 mini ou Mistral. Réentraînement trimestriel.
Cas 3 — Assistant juridique interne : approche hybride
Vos juristes ont besoin d’un assistant qui connaît le droit français, raisonne comme un avocat d’affaires ET accède à la jurisprudence récente.
Pourquoi l’hybride ? Le fine-tuning encode le style de raisonnement juridique et votre jargon interne. Le RAG connecte l’assistant aux bases de jurisprudence (Légifrance, bases privées) mises à jour en temps réel. Ni l’un ni l’autre ne suffit seul.
Stack recommandée : Mistral fine-tuné + LlamaIndex RAG sur base Légifrance + pgvector.
Conclusion
Le choix entre RAG et fine-tuning n’est pas une question de technologie supérieure, mais d’adéquation avec votre besoin :
- Données qui changent, sources citables, déploiement rapide → RAG
- Style à apprendre, comportement constant, latence critique → Fine-tuning
- Cas d’usage complexe, exigences élevées → Approche hybride
Dans tous les cas, la qualité de vos données d’entrée reste le facteur déterminant. Un RAG mal configuré ou un dataset de fine-tuning médiocre produiront des résultats décevants, quelle que soit la puissance du modèle sous-jacent.
Si vous souhaitez évaluer quelle approche correspond à votre situation spécifique, nos experts peuvent réaliser un audit gratuit de votre cas d’usage et vous proposer une architecture adaptée à votre budget et vos contraintes techniques.
Découvrez nos réalisations d’agents IA ou explorez notre offre de création de chatbot IA pour aller plus loin.
