Le vrai coût du RAG en production

Tout le monde pose la mauvaise première question sur l’IA générative. On demande quel modèle. La question intéressante, c’est où vont vraiment l’argent et l’effort une fois la chose en production. On a fait tourner de la génération augmentée par récupération en production chez Chantelle de deux façons, d’abord sur une API hébergée puis sur un modèle qu’on a entraîné et hébergé nous-mêmes, et les deux fois le modèle a été la partie la moins chère de la facture.

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. La production révèle qu’il n’est qu’un composant, et un composant bon marché, posé sur un appareillage bien plus coûteux que personne n’a mis sur la slide. Faire entrer les documents, c’était le vrai projet : les formats sources sont hétérogènes, le contenu est dupliqué, périmé ou se contredit, et décider quoi ingérer, comment le découper et comment le garder à jour quand les données sous-jacentes changent, c’est là que sont passés les mois-ingénieur. Les intégrations ont été le deuxième gouffre. Un système de récupération qui n’atteint pas les outils que les gens utilisent est un projet de labo, alors orchestrer les flux dans n8n, aller chercher dans Magento, gérer les échecs et les reprises, cette plomberie ingrate a été l’essentiel 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é. On est passés à notre propre Gemma fine-tuné pour trois raisons que l’API ne pouvait pas nous donner. La qualité : un modèle fine-tuné sur nos propres exemples de tâches idéales battait le point d’accès générique sur nos vraies questions. Le contrôle : on possédait la latence, le versionnage, et on n’était plus exposés au modèle de quelqu’un d’autre qui change sous nos pieds. Et, honnêtement, pour prouver ce qui était possible en interne, ce qui compte quand on cherche à faire bouger une organisation.

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.

Posséder un modèle n’est pas gratuit. On échange un appel d’API facturé à l’usage contre une facture GPU et le travail de le servir, dans notre cas un fine-tuning en QLoRA et un serving en vLLM sur une flotte d’instances spot. Seul, pour un seul assistant, cet échange se justifie mal. Ce qui l’a justifié, c’est qu’on a cessé de traiter le modèle comme la dépendance d’une seule application pour le traiter comme une plateforme.

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

Une fois le Gemma fine-tuné à nous, l’assistant n’était que la première chose qu’on faisait tourner dessus. On a pointé des agents Playwright vers lui pour parcourir les parcours utilisateurs critiques sur tous nos sites de production, comme l’aurait fait un client, et nous dire quand quelque chose cassait. Et quand un ticket passait en QA dans ClickUp, un workflow n8n faisait rédiger le cas de test par le modèle et Playwright l’exécutait sur la préproduction, puis repostait les résultats en commentaire sur le ticket, ce qu’il avait fait et ce qu’il avait trouvé, avant qu’un testeur humain ne le prenne. Un modèle qu’on possède, plusieurs charges de travail, toutes partageant la même flotte GPU qu’on avait déjà payée.

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 fait que ça marche ?

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 chère. On faisait tourner le Gemma 12B fine-tuné en continu pour environ 150 € par mois : uniquement des instances spot, dans une région AWS disposant d’une forte capacité G4, G5 et G6, avec une image Packer conçue pour tourner sur n’importe laquelle de ces générations de GPU, de sorte qu’on attrapait presque toujours de la capacité spot bon marché, plus du multi-token prediction pour accélérer la génération. 150 € par mois, pour un modèle qui servait aussi bien l’assistant que les agents de test. La partie chère, c’était toujours l’ingestion, la qualité des données, l’évaluation et l’intégration, plus l’ingénierie autour. Posséder le modèle a ajouté un coût GPU et retiré le coût à l’appel, et ça a payé parce qu’on faisait tourner plus d’une chose dessus. La ligne sur laquelle tout le monde se focalise est restée la petite, dans les deux régimes.

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é.

C’est cette discipline que j’apporte aux équipes que je conseille, que ce soit comme leur dirigeant technique ou comme deuxième avis quand elles décident de ce qu’un projet d’IA va vraiment leur coûter.