Quand une entreprise doit intégrer son propre savoir dans un modèle de langage —son catalogue, ses manuels, son historique de tickets— le même débat revient presque toujours : RAG, fine-tuning, ou tout simplement tout mettre dans le contexte ? La conversation tourne d’ordinaire autour de la qualité : lequel répond le mieux, lequel hallucine le moins, lequel est le plus facile à maintenir.
C’est la mauvaise question pour commencer. Dans la plupart des projets que nous voyons, la décision ne se joue pas sur la qualité —les trois peuvent offrir une qualité acceptable— mais sur le coût par tâche. Et là, les trois options se comportent radicalement différemment selon votre volume. Celle qui paraît la moins chère en démo devient la plus chère en production, et inversement.
Les trois options, en une phrase de coût
Contexte long. Vous mettez le savoir pertinent directement dans le prompt à chaque requête. Zéro infrastructure, zéro préparation. Mais vous payez ces tokens à chaque fois que vous posez la question. C’est le « copier-coller le manuel entier » avant chaque requête.
RAG (génération augmentée par récupération). Au lieu d’envoyer tout le savoir, un moteur de recherche récupère uniquement les fragments pertinents pour chaque requête, et ceux-là —et eux seuls— voyagent dans le prompt. Le contexte par requête reste petit. En échange, vous montez et maintenez une chaîne : découper les documents, générer des embeddings, une base vectorielle, la logique de récupération.
Fine-tuning. Vous ajustez le modèle lui-même avec vos données. Vous payez un coût d’entraînement en amont, mais ensuite le savoir (ou le style, ou le format) vit à l’intérieur du modèle, si bien que le prompt de chaque requête peut être bien plus court : plus besoin de renvoyer instructions ni exemples.
Où se paie chacune
La clé est de distinguer le coût de mise en place (une fois) du coût par tâche (chaque requête, pour toujours). C’est la même logique que le coût par tâche : ce qui plombe votre budget n’est pas le prix affiché, c’est ce que vous multipliez par votre volume mensuel.
Le contexte long a un coût de mise en place quasi nul et le coût par tâche le plus élevé des trois. Si vous traînez 8 000 tokens de manuel à chaque requête et traitez cent mille requêtes par mois, vous avez payé ce manuel cent mille fois. Peu coûteux à monter, cher à exploiter.
Le fine-tuning inverse la répartition : coût de mise en place élevé (préparer le jeu de données, entraîner, et réentraîner chaque fois que le savoir change), mais le coût par tâche le plus bas, car le prompt s’amincit. C’est l’option « payer beaucoup une fois pour payer peu de nombreuses fois ».
Le RAG se situe au milieu sur les deux dimensions : une mise en place modérée (la chaîne de récupération) et un coût par tâche bas, car vous n’envoyez que les fragments nécessaires, pas tout. Il a aussi un coût que les deux autres montrent moins clairement : chaque requête paie aussi la récupération (embedding de la question, recherche dans la base vectorielle), même si c’est généralement faible face aux économies de tokens du modèle.
Un exemple chiffré
Prenons une tâche qui doit s’appuyer sur une base de connaissances. Réponse de 300 tokens dans les trois cas. Prix indicatifs de 2 $ par million en entrée et 12 $ par million en sortie.
| Approche | Tokens en entrée par tâche | Coût par tâche |
|---|---|---|
| Contexte long (manuel entier) | 8 000 | 0,0196 $ |
| RAG (uniquement fragments pertinents) | 1 500 | 0,0066 $ |
| Fine-tuning (prompt minimal) | 500 | 0,0046 $ |
À première vue, le fine-tuning l’emporte. Mais il manque l’autre moitié. Si vous faites mille tâches par mois, l’écart entre contexte long et fine-tuning est d’environ 15 $ par mois : loin de justifier le coût de préparer et maintenir un modèle ajusté. Si vous en faites un million, ce même écart représente environ 15 000 $ par mois —180 000 $ par an— et soudain le fine-tuning se rembourse en quelques semaines.
Le point d’équilibre n’est pas fixé par l’option « meilleure », mais par le nombre de fois où vous allez répéter la tâche.
Comment décider sans instrumenter la moitié de l’équipe
Trois questions tranchent presque tous les cas :
Quel est votre volume ? À faible volume, le contexte long l’emporte presque toujours : le coût par tâche est négligeable face au temps d’ingénierie économisé. Ne montez pas une chaîne RAG pour traiter mille requêtes par mois.
À quelle fréquence le savoir change-t-il ? Si votre base change tous les jours —prix, stock, politiques—, le fine-tuning est un piège : réentraîner sans cesse est coûteux et lent. Le RAG brille précisément ici, car mettre à jour revient simplement à changer les documents indexés. Le fine-tuning convient quand ce que vous enseignez est stable : un ton, un format de sortie, un jargon métier.
Que mettez-vous, du savoir ou du comportement ? Le RAG sert à savoir des choses (faits, documents, données que l’on consulte). Le fine-tuning sert à se comporter d’une certaine façon (répondre dans un style, suivre une structure, parler votre langage technique). Les confondre est l’erreur la plus coûteuse : tenter d’intégrer une base de connaissances changeante par fine-tuning, ou forcer un format rigide à coups d’allongement du prompt à chaque requête.
Et ils ne s’excluent pas. La combinaison la plus courante en production est fine-tuning pour le comportement + RAG pour le savoir : un modèle ajusté pour répondre comme vous le voulez, alimenté par des fragments récupérés à la volée. On paie la mise en place du fine-tuning une fois, on garde le savoir bon marché avec le RAG, et le prompt par tâche reste court des deux côtés.
Une mise en garde honnête
Les chiffres de cet article sont un exemple pour illustrer le mécanisme, pas une mesure de votre cas. Le point d’équilibre réel dépend de votre volume, de la quantité de contexte que traîne aujourd’hui chaque requête et de la fréquence à laquelle votre savoir change. Il peut se situer à dix mille tâches par mois ou à dix millions.
Ce qui ne change pas, c’est l’ordre de la décision : mesurez d’abord combien vous coûte aujourd’hui une tâche et combien vous en faites, et choisissez seulement ensuite une architecture. Choisir selon la mode —« tout le monde fait du RAG »— plutôt que selon vos chiffres est la façon la plus courante de finir par surpayer une architecture que votre volume ne justifie pas.
Cet article fait partie du cluster sur le coût par tâche de l’IA, le guide qui ancre tout le reste.
Chez e-ficient, nous mesurons le coût par tâche d’entreprises qui exploitent déjà l’IA en production, y compris ce que chaque architecture vous coûterait à votre volume réel. L’audit initial est gratuit si vous souscrivez un forfait avec un engagement de trois mois et rend un diagnostic sous 72 heures.