Build vs buy : RAG vs fine-tuning

En 2023, un assureur européen de taille moyenne a monté un « centre d'excellence » GenAI et engagé 4 M€ dans le fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → d'un modèle open-weight sur son historique de sinistres. Dix-huit mois plus tard, le modèle fine-tuné était discrètement mis au rebut. Le problème n'était pas le modèle : leurs règles de gestion des sinistres changeaient chaque trimestre, et chaque changement imposait un cycle de réentraînement qu'ils ne pouvaient pas financer. Un pilote RAGRAGMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète → de trois semaines, construit par deux ingénieurs, a fini par porter la charge de production. Les 4 M€ leur ont acheté une leçon coûteuse : ils avaient résolu un problème de fraîcheur de la connaissance avec un outil de façonnage du comportement.

C'est la décision de build la plus lourde de conséquences et la plus mal comprise que vous prendrez en GenAI d'entreprise. L'écosystème des vendeurs a un intérêt financier à vous vendre l'option la plus lourde. Votre travail est d'aligner le mécanisme sur le problème réel, et de savoir quand la réponse est « aucune des trois, écrivez juste un meilleur prompt ».

Les trois mécanismes, et ce que chacun change réellement

Otez le marketing et il reste trois leviers, classés par coût et complexité.

Le prompting change ce que vous *demandez* au modèle, sur l'instant. Vous fournissez instructions, exemples et contraintes dans la fenêtre de contexte. Rien ne change dans le modèle. C'est votre option par défaut, et elle est plus puissante que ne le supposent la plupart des dirigeants : les modèles frontier actuels, avec un system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → bien conçu et quelques exemples en contexte (« few-shot »), résolvent d'emblée une part surprenante des cas d'usage d'entreprise.

Le Retrieval-Augmented Generation (RAG) change ce que le modèle *sait* au moment de l'inférenceinférenceLe moment où un modèle d'IA entraîné se met au travail : il reçoit une donnée nouvelle et produit une réponse, une prédiction ou un contenu.Voir la définition complète →. Vous récupérez les documents pertinents dans votre propre corpus, vous les injectez dans le prompt, et le modèle raisonne dessus. Les poids du modèle ne sont pas touchés ; vous lui fournissez à la demande un contexte propriétaire et à jour.

Le fine-tuning change la manière dont le modèle *se comporte* : son ton par défaut, son format, sa structure, ses réflexes spécifiques à une tâche. Vous poursuivez l'entraînement du modèle de base sur des exemples sélectionnés pour que ces schémas soient inscrits dans les poids.

Le cadrage le plus utile à emporter dans n'importe quelle revue d'architecture est celui-ci :

Le RAG donne au modèle de la connaissance. Le fine-tuning lui donne des compétences. Le prompting oriente la connaissance et les compétences qu'il possède déjà.

L'erreur de l'assureur devient évidente dans ce langage. Leur problème était *une connaissance qui change*, un problème de RAG. Ils ont choisi le fine-tuning, qui est un outil de *compétences et de comportement*, et ont hérité d'un tapis roulant de réentraînement pour de l'information qui aurait dû vivre dans un index interrogeable.

Le test de décision

Quand un cas d'usage arrive sur votre bureau, passez-le par trois questions, dans l'ordre :

1. Un bon prompt suffit-il ? Si un system prompt bien écrit plus 3 à 5 exemples vous amène à une qualité acceptable, arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez-vous. C'est fini. Mettez en production.
2. La tâche exige-t-elle une connaissance propriétaire ou fraîche que le modèle n'a pas ? Si oui, c'est du RAG. Typiquement : « réponds à partir de nos documents de politique en vigueur », « cite nos contrats », « référence le catalogue produit de ce trimestre ».
3. La tâche exige-t-elle un comportement, un format ou une compétence spécialisée que le prompting ne peut pas imposer de façon fiable ? Si oui, c'est du fine-tuning. Typiquement : « produis toujours du JSON valide dans notre schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → », « adopte le registre d'écriture propre à notre marque », « classe les tickets de support dans nos 40 catégories internes avec une forte cohérence ».

L'essentiel de la valeur GenAI en entreprise sur 2024-2025 se situe aux niveaux 1 et 2. Le fine-tuning est réel et utile, mais c'est le *dernier* outil vers lequel vous allez, pas le premier, et surtout, RAG et fine-tuning ne s'excluent pas. Les systèmes de production les plus aboutis fine-tunent pour le comportement *et* utilisent le RAG pour la connaissance.

RAG : le choix par défaut pour la connaissance d'entreprise

Le RAG est devenu la bête de somme pour une raison : les entreprises croulent sous le texte propriétaire, contrats, politiques, tickets, wikis, travaux de recherche, qu'aucun modèle de base n'a jamais vu et qui change en permanence. Le RAG vous permet d'exposer ce corpus au modèle sans réentraînement, sans déplacer vos données dans les poids d'un tiers, et avec une capacité de mise à jour quasi temps réel.

Mais « on fera du RAG » est précisément là où la plupart des programmes échouent en silence, parce que le difficile n'est pas le LLM, c'est le retrieval. Un CDO doit interroger une proposition RAG sur trois dimensions :

Qualité du chunking et du retrieval. Comment le corpus est-il découpé, indexé, interrogé ? Un chunking naïf à taille fixe détruit le contexte ; un paragraphe coupé en deux renvoie n'importe quoi. C'est un problème de data engineering que vous connaissez déjà, c'est de l'ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète → pour du texte non structuré. La qualité de vos réponses est plafonnée par la qualité de votre retrieval, point final.

Grounding et citation. Le système peut-il montrer *quelle source* a produit chaque affirmation ? Pour une entreprise régulée, une réponse non sourcée est un risque, pas une fonctionnalité. Exigez que le retrieval renvoie des références de source que le modèle doit citer.

Fraîcheur et contrôle d'accès. Qui a le droit de voir quels documents ? Le RAG doit respecter vos habilitations existantes : un système de retrieval qui expose les données salariales RH à un analyste junior parce que « c'était dans l'index » est un incident de gouvernance en devenir. Vos contrôles d'accès doivent vivre dans la couche de retrieval, pas être rajoutés après coup.

Un modèle mental utile du pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → de retrieval :

query → embed → vector search (filtered by user's access rights)
      → rerank top-k → assemble context + citations
      → LLM generates grounded answer

La vérité peu glamour : 80 % de l'effort d'ingénierie RAG porte sur le retrieval et le pipeline de données, pas sur le modèle. C'est une bonne nouvelle pour un CDO, il s'agit largement d'une discipline que votre organisation maîtrise déjà. Les équipes qui réussissent en RAG sont celles qui l'ont traité comme un problème de search et de qualité de données, pas comme un problème d'IA.

Quand le RAG est du sur-engineering

Si votre base de connaissances est petite, stable et tient confortablement dans la fenêtre de contexte d'un modèle récent, vous n'avez peut-être pas besoin d'un système de retrieval du tout, vous pouvez simplement inclure les documents pertinents dans le prompt. Monter une base vectorielle, un pipeline d'embeddings et un reranker pour servir un manuel salarié de 30 pages qui change deux fois par an, c'est du théâtre d'infrastructure. Ajustez la machinerie à l'échelle.

Fine-tuning : puissant, étroit, et souvent mal employé

Le fine-tuning justifie sa place dans exactement trois situations, et vous devez être sceptique face à toute proposition qui n'entre pas clairement dans l'une d'elles :

1. Un comportement et un format que le prompting ne garantit pas. Quand vous avez besoin que le modèle produise *toujours* une sortie dans une structure stricte, adopte une voix constante, ou suive une convention métier qu'aucun prompt n'impose à l'échelle. Le fine-tuning inscrit le schéma.

2. Latence et coût à fort volume. Un petit modèle fine-tuné peut égaler la qualité d'un grand modèle sur une tâche *étroite* tout en étant nettement moins cher et plus rapide par appel. À des millions d'appels par jour, cette arithmétique domine. Vous échangez un coût d'entraînement initial et de la rigidité contre de l'efficacité par inférence.

3. Une compétence spécialisée ou une classification que le modèle de base réussit mal. Des tâches très spécifiques à un domaine, codage médical, classification de clauses juridiques, langue de niche, où l'entraînement généraliste du modèle de base ne suffit tout simplement pas.

Ce à quoi le fine-tuning ne sert *pas* : apprendre des faits au modèle. C'est l'idée fausse la plus coûteuse du secteur. Le fine-tuning est un moyen médiocre et peu fiable d'injecter de la connaissance : le modèle en mémorisera une partie, hallucinera sur les bords, et vous devrez réentraîner à chaque fois qu'un fait change. C'est un travail pour le RAG. À chaque fois.

La réalité parameter-efficient

Le fine-tuning moderne signifie rarement réentraîner le modèle entier. Des techniques comme LoRA (Low-Rank Adaptation) entraînent un petit ensemble de poids d'adaptation au-dessus d'un modèle de base gelé, réduisant le coût de plusieurs ordres de grandeur et vous permettant de maintenir plusieurs adapters spécifiques à des tâches sur une seule base. Quand un vendeur ou une équipe propose du « fine-tuning », votre première question est : *full fine-tune ou parameter-efficient ?* S'ils proposent un full fine-tune d'un grand modèle pour une tâche étroite, c'est généralement un signal de sur-engineering.

L'économie qui compte vraiment pour un CDO :

Regardez la ligne auditabilité. En environnement régulé, la capacité du RAG à citer ses sources n'est pas un raffinement technique, c'est souvent ce qui rend le déploiement défendable devant vos fonctions risque et conformité. Le raisonnement d'un modèle fine-tuné est inscrit dans des poids que vous ne pouvez pas inspecter.

Trancher lundi matin

Voici comment cela se traduit en gouvernance réellement applicable.

Instaurez un mandat « prompt-first ». Exigez que chaque cas d'usage GenAI démontre que le prompting seul est insuffisant *avant* d'approuver un budget RAG, et que le RAG est insuffisant avant d'approuver une dépense de fine-tuning. Cette seule règle vous évitera l'erreur de 4 M€ de l'assureur. Faites gagner aux équipes chaque barreau de l'échelle de complexité.

Séparez le problème de connaissance du problème de comportement, explicitement, par écrit. Pour chaque cas d'usage, obligez l'équipe à écrire une phrase : « Ceci exige que le modèle *sache* X et *se comporte* comme Y. » Dès que vous décomposez ainsi, l'architecture se choisit d'elle-même. Connaissance → RAG. Comportement → fine-tuning. Les deux → les deux.

Traitez le RAG comme un data product, pas comme un projet d'IA. Il doit relever du même régime de gouvernance, de lineage et de contrôle d'accès que vos autres data products. L'index de retrieval hérite des habilitations des sources sous-jacentes, vous savez déjà faire cela. Le mode de défaillance, ce sont des équipes qui construisent des index fantômes contournant entièrement votre gouvernance.

Budgétez le fine-tuning comme une optimisation, pas comme un socle. La séquence correcte pour la plupart des produits à forte valeur est : prouver la valeur avec prompting + RAG, mesurer coût et latence en production, *puis* fine-tuner un modèle plus petit pour faire baisser le coût par appel une fois que le volume le justifie. Le fine-tuning comme premier geste est de la spéculation ; le fine-tuning comme optimisation d'une charge éprouvée est de l'ingénierie saine.

Surveillez le coût total de possession, pas la démo. Le coût du fine-tuning n'est pas la session d'entraînement, c'est le tapis roulant de réentraînement, le MLOps pour versionner et évaluer les adapters, et le muscle organisationnel nécessaire pour maintenir les jeux de données d'évaluation. Le coût du RAG n'est pas la base vectorielle, c'est l'hygiène continue du pipeline de données. Demandez aux vendeurs et aux équipes internes de modéliser le coût à *18 mois*, maintenance incluse, pas celui du pilote.

Le point stratégique : le marché continuera de vous pousser vers le mécanisme le plus complexe et le plus cher, parce que c'est là que sont les marges. Votre avantage de CDO est la discipline de demander « de quoi ce cas d'usage a-t-il réellement besoin ? » et de l'orienter vers le mécanisme le moins cher qui atteint le niveau requis. La plupart du temps, c'est un bon prompt au-dessus d'un retrieval solide, et le savoir vaut plus que n'importe quel modèle.

Points clés

1. Faites passer chaque cas d'usage par l'échelle, prompt, puis RAG, puis fine-tuning, et exigez que les équipes méritent chaque barreau. Un mandat « prompt-first » est la règle de gouvernance au meilleur ROI que vous puissiez installer.
2. Ne résolvez jamais un problème de connaissance par du fine-tuning. L'information fraîche, propriétaire ou changeante appartient à une couche de retrieval RAG. Le fine-tuning est pour le comportement, le format et les compétences spécialisées, pas pour les faits.
3. Traitez le RAG comme un data product sous votre gouvernance existante. 80 % de l'effort porte sur le retrieval et la qualité du pipeline ; les contrôles d'accès doivent vivre dans la couche de retrieval, et chaque réponse doit citer sa source pour l'auditabilité.
4. Budgétez le fine-tuning comme une optimisation de coût/latence d'une charge éprouvée, et exigez par défaut des méthodes parameter-efficient (LoRA), pas comme un premier geste spéculatif ni comme un réentraînement complet d'un grand modèle pour une tâche étroite.
5. Évaluez sur le coût total de possession à 18 mois, pas sur la démo. Le tapis roulant de réentraînement et l'hygiène du pipeline sont là où les budgets meurent, modélisez la maintenance, pas seulement le build.