Le vrai coût du RAG en production

La première question sur l’IA générative concerne souvent le choix du modèle. Une question plus utile consiste à comprendre où vont l’argent et le travail d’ingénierie une fois le système en production. Chez Chantelle, nous avons exploité un système RAG d’abord sur une API hébergée, puis sur un modèle affiné et hébergé par nos soins. Dans les deux cas, le modèle représentait la plus petite part du coût total.

Voici la réponse courte, parce que c’est tout le sujet : les coûts dominants d’un RAG en production sont l’ingestion, la qualité des données, l’évaluation et l’intégration. Le modèle, qu’il s’agisse d’un appel d’API facturé à l’usage ou d’un fine-tune auto-hébergé, est la plus petite ligne récurrente. Le modèle est resté la ligne la moins chère jusqu’au jour où on a choisi de le posséder, et même là, le vrai coût n’a jamais été le modèle.

Où part vraiment l’argent dans un RAG en production ?

Dans le fait de faire entrer les documents, de les garder propres, d’évaluer les réponses et de brancher la chose sur les systèmes que les gens utilisent déjà. L’inférence brute du modèle est en général le plus petit coût récurrent, pas le plus gros.

Une démo fait passer le modèle pour le produit. En production, il n’est qu’un composant d’un système plus vaste d’ingestion, d’évaluation et d’intégrations. Faire entrer les documents constituait le vrai projet : les formats sources sont hétérogènes, le contenu est dupliqué, périmé ou contradictoire, et les ingénieurs consacrent l’essentiel de leur temps à décider quoi ingérer, comment le découper et comment le garder à jour. Les intégrations représentaient le deuxième coût majeur. Orchestrer les flux dans n8n, connecter Magento et gérer les échecs et les reprises a constitué une grande partie du travail.

On a commencé sur une API hébergée, et le modèle était la ligne la moins chère

En 2025, la stack était volontairement sobre : PostgreSQL avec pgvector pour la récupération, Gemini pour la génération, n8n pour orchestrer l’ingestion et les workflows, Valkey pour le cache. L’inférence était un appel d’API facturé à l’usage. On peut le prévoir, le plafonner et mettre du cache autour, et on a placé Valkey devant la charge pour ne pas payer à répondre deux fois à la même question. Ça a aplati la facture et accéléré les réponses en même temps.

À côté, l’ingestion et la qualité des données sont des coûts humains, récurrents, bien plus difficiles à plafonner. Un ingénieur qui maintient un pipeline d’ingestion ne devient pas moins cher comme un appel d’API. Si vous budgétez un projet d’IA et que la ligne du modèle est la grosse, soit vous n’avez pas encore livré, soit vous mesurez la mauvaise chose.

Alors pourquoi construire et héberger notre propre modèle ?

Pas parce que l’API était chère. Elle était bon marché. Nous sommes passés à notre propre Gemma affiné pour trois raisons. D’abord, un modèle affiné sur nos exemples de tâches idéales répondait mieux à nos vraies questions que le modèle générique accessible par API. Ensuite, nous maîtrisions la latence et le versionnage sans dépendre des changements d’un fournisseur. Enfin, ce choix permettait de montrer en interne ce que nous pouvions exploiter nous-mêmes.

Choisir le modèle a été un exercice en soi, celui de ne pas courir après la taille. J’ai benchmarké Gemma contre Qwen et contre des Gemma plus gros sur le travail qu’on avait vraiment, naviguer des sites e-commerce multilingues, et le 12B l’a emporté : un meilleur comportement multilingue que Qwen, là où les modèles plus gros ne valaient pas leur prix pour notre charge. La taille est la chose la plus facile à sur-acheter dans ce domaine.

Auto-héberger un modèle n’est pas gratuit. On échange un appel d’API facturé à l’usage contre une facture GPU et le travail nécessaire à son exploitation. Dans notre cas, nous utilisions QLoRA pour l’affinage et vLLM pour servir le modèle sur une flotte d’instances spot. Pour un seul assistant, ce choix se justifie mal. Il est devenu pertinent lorsque le modèle a servi de plateforme à plusieurs usages.

Posséder le modèle en a fait une plateforme

Une fois notre Gemma affiné en place, l’assistant n’était que le premier usage. Des agents Playwright parcouraient les parcours critiques de nos sites de production comme l’aurait fait un client et signalaient les pannes. Lorsqu’un ticket passait en QA dans ClickUp, un processus n8n demandait au modèle de rédiger un cas de test, Playwright l’exécutait sur la préproduction, puis les résultats étaient ajoutés au ticket avant l’intervention d’un testeur. Plusieurs usages partageaient ainsi la même flotte GPU.

C’est ça que vous ne pouvez pas louer à l’appel. Une API facturée à la requête ne devient pas moins chère quand vous lui trouvez un deuxième et un troisième usage ; posséder le modèle, si. L’équation bascule dès que la chose que vous possédez est une capacité partagée plutôt qu’une fonctionnalité isolée. C’est aussi la réponse honnête à « l’auto-hébergement en valait-il la peine » : pour un seul chatbot, sans doute pas ; pour une plateforme sur laquelle trois équipes construisent, largement.

Qu’est-ce qui a vraiment permis au système de fonctionner ?

La qualité de la récupération et une évaluation honnête, pas l’astuce du prompt. Et ça n’a pas changé quand le modèle a changé.

Un prompt médiocre sur une excellente récupération bat un prompt brillant sur une récupération médiocre, à chaque fois. Si le système remonte les bons passages, le modèle fait son travail ; s’il remonte les mauvais, aucun prompt engineering ne vous sauve, et vous avez construit une machine sûre d’elle à se tromper. L’évaluation était l’autre moitié. On mesurait la qualité de la récupération et des réponses contre un jeu de test au lieu de se fier au ressenti d’une bonne démo, et on faisait tourner cette évaluation en CI : un changement qui dégradait les réponses cassait le build. Le ressenti, c’est comme ça que les projets d’IA sont validés, et comme ça qu’ils échouent en silence six mois plus tard.

Alors, combien ça a coûté au juste ?

Même auto-hébergé, le modèle n’était pas la partie la plus chère. Nous faisions tourner le Gemma 12B affiné en continu pour environ 150 € par mois, uniquement sur des instances spot. Une image Packer compatible avec les générations G4, G5 et G6 nous permettait de profiter de la capacité disponible, tandis que la prédiction de plusieurs jetons accélérait la génération. Le même modèle servait l’assistant et les agents de test. L’ingestion, la qualité des données, l’évaluation, les intégrations et le travail d’ingénierie restaient les principaux coûts.

Si vous êtes fondateur ou dirigeant technique à qui l’on demande de « faire quelque chose avec l’IA », budgétez votre effort et votre argent là où ils vont vraiment. Partez du principe que le modèle est la partie la moins chère. Mettez vos équipes sur l’ingestion, la qualité des données, l’évaluation et l’intégration, car c’est ce qui décide si vous livrez quelque chose de fiable ou quelque chose qui ne brille qu’en démo. Et si vous décidez de posséder un modèle, faites-le parce que vous en avez plus d’un usage, car un modèle que vous possédez est une plateforme et un modèle que vous louez est une fonctionnalité.

La leçon pratique est simple : il faut budgéter l’ensemble du système, pas seulement l’inférence.