Quand on intervient en mission Pôle IA chez une PME ou une ETI, la question architecturale arrive presque systématiquement : on fait du RAG, on fait du fine-tuning, on reste sur du prompt engineering ? La réponse n’est jamais binaire et dépend du cas d’usage. Ce papier décrit comment on tranche.
Les trois approches en deux phrases chacune
Le prompt engineering. Vous gardez le modèle tel quel et vous l’utilisez via une API. Vous écrivez des prompts précis, vous structurez les entrées et les sorties, vous chaînez si nécessaire. C’est la base. C’est ce qui marche pour 80 % des cas d’usage en PME.
Le RAG (Retrieval-Augmented Generation). Vous gardez le modèle tel quel, mais vous lui donnez accès à votre propre corpus documentaire au moment de la requête. Une couche de recherche sémantique récupère les documents pertinents, le modèle s’en sert pour répondre. Vous obtenez des réponses qui citent vos documents, sans avoir à entraîner quoi que ce soit.
Le fine-tuning. Vous prenez un modèle de base et vous le ré-entraînez sur vos données pour qu’il intègre votre vocabulaire, votre style, vos règles métier. C’est plus coûteux, plus long, et ça nécessite des données d’entraînement de qualité. Réservé à des cas très précis.
Le critère d’arbitrage qu’on applique
On commence toujours par la question : est-ce que la connaissance dont le modèle a besoin pour répondre est figée ou évolutive ?
Si c’est figé (votre méthode, votre ton, votre cadre réglementaire), le fine-tuning est envisageable. Si c’est évolutif (votre catalogue produit, votre base de connaissances, vos données clients), le RAG est la bonne réponse parce qu’il interroge les sources en temps réel.
Si la réponse est : « ni l’un ni l’autre, on veut juste de l’IA générique sur du texte », c’est du prompt engineering, et c’est très bien.
Pourquoi le RAG gagne dans 70 % des missions PME
Dans nos missions, c’est le RAG qui ressort le plus souvent comme bonne réponse. Trois raisons.
D’abord parce qu’il s’adapte à votre corpus existant sans demander de pré-traitement lourd. Vous lui pointez votre documentation produit, vos comptes-rendus de réunion, vos contrats types. Il les indexe, et il s’en sert. Pas besoin de transformer vos données en jeux d’entraînement.
Ensuite parce qu’il est traçable. À chaque réponse, vous pouvez voir quels documents ont été utilisés pour la générer. C’est précieux pour la conformité, pour l’audit, et pour la confiance utilisateur. Le fine-tuning n’offre pas cette traçabilité.
Enfin parce qu’il évolue avec vos données. Vous ajoutez un nouveau document, le RAG le prend en compte dès la prochaine indexation. Avec du fine-tuning, vous devriez re-entraîner le modèle à chaque mise à jour majeure.
Quand le fine-tuning vaut quand même le coup
On a fait du fine-tuning dans environ 15 % de nos missions. Trois cas typiques :
- Quand le modèle de base se trompe systématiquement sur un point très spécifique de votre métier, et qu’aucun prompt même très détaillé ne corrige cette erreur. Le fine-tuning lui apprend la règle correcte une bonne fois.
- Quand vous avez besoin que le modèle produise des sorties dans un format très précis (un schéma JSON métier, un style éditorial cohérent), et qu’il faut une fiabilité de 99 % pour intégrer en production sans validation humaine.
- Quand vous travaillez sur des données très sensibles et que vous voulez héberger le modèle entier sur votre infrastructure, sans dépendance API. Vous fine-tunez un petit modèle open source que vous opérez vous-même.
Dans tous ces cas, on commence quand même par du RAG ou du prompt engineering pour valider que le besoin est réel. Si le résultat ne suffit pas, on passe au fine-tuning. Pas l’inverse.
Le piège du fine-tuning précipité
Le piège classique en PME, c’est de partir directement sur du fine-tuning parce que c’est ce qui « semble sérieux ». Vous engagez plusieurs dizaines de milliers d’euros, vous mobilisez votre équipe data pendant des mois, et vous découvrez à la mise en production que les performances ne sont pas meilleures qu’un bon prompt engineering bien fait.
Notre règle : on commence toujours par le moins coûteux. Si le prompt engineering suffit, on s’arrête là. Si ça ne suffit pas, on monte au RAG. Si ça ne suffit toujours pas, on évalue le fine-tuning, et on chiffre honnêtement le ROI attendu. Dans la moitié des cas, l’évaluation conclut qu’il faut rester en RAG et affiner la qualité du corpus.
Pour aller plus loin
Lire pourquoi 8 projets IA sur 10 en PME ne passent jamais en production pour les pièges les plus fréquents, et comment mettre un agent IA en production sans casser la conformité RGPD pour la dimension juridique. Et si vous voulez qu’on regarde votre cas concret, un quart d’heure suffit pour qualifier.