Un pipeline RAG chiffré à quelques centaines d'euros en démo peut atteindre plusieurs dizaines de milliers d'euros par mois en production. La différence tient à des postes que les devis initiaux ignorent presque toujours : réindexation, dérive du contexte, monitoring.
La plupart des chiffrages de pipeline RAG (retrieval-augmented generation) s'arrêtent au coût des tokens : appels d'embedding, appels au LLM de génération, stockage vectoriel de base. Un cas documenté illustre l'écart entre cette estimation et la réalité : une démo RAG facturée 340 dollars par mois est devenue un système de production à 61 000 dollars par mois. L'écart ne provient pas d'un dérapage technique isolé mais d'un changement d'échelle structurel : la démo repose sur quelques centaines de documents et un corpus d'embedding fixe, tandis que la production traite des millions de documents, des milliers de requêtes par jour et un corpus qui change en permanence.
Ce décalage n'est pas anecdotique. Une analyse récente des estimations de projets RAG montre que sur les quatre composants d'infrastructure d'un système RAG standard, deux ont des courbes de coût non linéaires, et un troisième génère un coût de main-d'œuvre caché qui n'apparaît dans aucune ligne d'infrastructure. Les chiffrages réalisés au stade du prototype sont écrits dans la partie plate de ces courbes ; la production les fait basculer dans la partie exponentielle.
Le coût unitaire des embeddings est effectivement faible en apparence. Le modèle text-embedding-3-small à 0,02 dollar par million de tokens fonctionne bien pour la plupart des cas d'usage, contre 0,13 dollar pour text-embedding-3-large, soit un facteur 6,5 sur le coût des embeddings. C'est ce chiffre, souvent seul, qui figure dans les chiffrages initiaux transmis aux directions data.
Mais les appels de génération du LLM restent le poste dominant du budget d'inférence courant : les appels au LLM représentent typiquement 80 à 90 % du coût total, la base de données vectorielle et les embeddings étant mineurs en comparaison. Sur cette seule base, les ordres de grandeur en production varient fortement selon l'usage : une base de connaissances interne coûte entre 500 et 1 000 dollars par mois, un bot de support client entre 5 000 et 15 000 dollars par mois, et la recherche d'entreprise peut dépasser 50 000 dollars par mois.
Le premier angle mort concerne la réindexation. Chaque évolution de la stratégie de découpage des documents (chunking) ou du modèle d'embedding oblige à retraiter l'intégralité du corpus. Une analyse de projets en phase 3 de sprint le formule sans détour : le poste de coût le plus important n'est pas les tokens du LLM, c'est la réindexation des embeddings, car chaque changement de stratégie de chunking refacture l'intégralité du corpus. À cela s'ajoute un effet de seuil : la tarification des bases vectorielles connaît un saut non linéaire autour de 5 à 10 millions de vecteurs, alors que la plupart des estimations de sprint 1 sont écrites en dessous d'un million.
Un cas cité dans une analyse dédiée à la décroissance des vecteurs donne un ordre de grandeur concret pour un corpus volumineux : un utilisateur de Pinecone a rapporté que la réindexation hebdomadaire d'un corpus d'un téraoctet coûtait 12 000 dollars par mois, uniquement pour maintenir la fraîcheur des données. Ce chiffre concerne un cas extrême, mais il montre que le coût de réindexation peut devenir comparable, voire supérieur, au coût d'inférence lui-même.
Le changement de modèle d'embedding n'est pas anodin non plus. Les praticiens recommandent de traiter chaque montée de version comme un projet à part entière : il faut figer les versions du modèle d'embedding et traiter les montées de version comme des événements opérationnels planifiés nécessitant une réindexation complète, avec la même rigueur qu'une migration de schéma de base de données : c'est un événement opérationnel planifié qui doit être versionné, testé en environnement de pré-production et exécuté avec un plan de retour arrière.
Un autre poste rarement budgété est la mise en qualité du corpus source. Une entreprise ayant déployé un RAG en environnement documentaire dense rapporte un ratio significatif : sur un corpus de 10 000 documents internes, il faut s'attendre à ce que 30 à 40 % nécessitent un traitement avant d'être exploitables par un système RAG. Ce traitement — nettoyage, reformatage, enrichissement de métadonnées — mobilise des équipes internes ou des prestataires, sur une durée qui dépasse largement le temps de développement du pipeline lui-même.
Le troisième poste caché est le monitoring en continu, distinct du simple suivi de disponibilité technique. Un système RAG se dégrade naturellement dans le temps : un système RAG en production est un système vivant qui se dégrade naturellement avec le temps, à mesure que les documents deviennent obsolètes, que les modèles d'embedding évoluent et que les besoins des utilisateurs changent. Sans dispositif de surveillance dédié, la qualité du pipeline décline inexorablement.
Ce phénomène porte un nom technique : la dérive de l'embedding (embedding drift). Elle se produit lorsque la distribution des requêtes s'éloigne du contenu indexé — un corpus indexé au premier trimestre peut mal répondre à des requêtes du troisième trimestre portant sur de nouveaux produits ou des procédures modifiées. La détecter suppose un instrument de mesure spécifique : suivre les scores de similarité moyens des documents les mieux classés dans le temps, une tendance baissière durable sans baisse correspondante du volume de requêtes signalant que les requêtes s'éloignent du contenu indexé. Le taux de requêtes sans résultat pertinent est un autre signal clé : un taux de résultats nuls particulièrement révélateur — si 10 % des requêtes ne retournent aucun document pertinent, le corpus présente des lacunes de couverture, et ces utilisateurs n'obtiennent aucune réponse utile.
Ce monitoring a un coût d'infrastructure propre, distinct du coût d'inférence brut. Une analyse chiffrée le confirme : un système RAG correctement monitoré génère des coûts de calcul continus qui peuvent ajouter 15 à 30 % au coût d'inférence de base, ce qui n'est pas un poste optionnel pour les systèmes en production. Sur un pipeline dont le coût d'inférence mensuel atteint déjà 10 000 euros, ce seul poste représente donc 1 500 à 3 000 euros supplémentaires, hors coût humain d'analyse des alertes.
Reprenons les ordres de grandeur disponibles pour un cas d'usage support client, l'un des déploiements RAG les plus fréquents en entreprise. Le budget d'inférence brut se situe, selon les cas documentés, entre 5 000 et 15 000 dollars par mois. À ce socle s'ajoutent, sur la base des ratios identifiés plus haut :
Le total mensuel en régime de croisière peut ainsi facilement dépasser de 40 à 60 % le budget d'inférence brut initialement chiffré, sans compter le temps d'ingénierie interne consacré à l'analyse des dérives détectées. C'est cet écart, invisible dans les premiers devis, qui explique pourquoi des projets validés sur la base d'un prototype convaincant voient leur budget contesté six mois après la mise en production.
La recommandation opérationnelle qui ressort de ces retours d'expérience est de sortir du raisonnement en coût unitaire de token pour raisonner en coût total de possession sur douze mois, intégrant réindexation planifiée, nettoyage récurrent du corpus et instrumentation de la dérive. Les vendeurs et intégrateurs qui présentent des chiffrages plats, sans palier lié au volume de vecteurs ou à la fréquence de mise à jour du corpus, sous-estiment structurellement le coût réel : une revue de cinq chiffrages initiaux de fournisseurs différents a montré que quatre d'entre eux partageaient la même lacune structurelle — un modèle de coût exact pour la charge de démonstration mais faux dès le troisième sprint.
La qualité du corpus source conditionne la fréquence et le coût des cycles de réindexation. Un principe résume cette dépendance : investir dans une architecture sophistiquée avec les meilleurs modèles du marché ne suffit pas si la donnée source n'est pas maîtrisée. Établir un score de qualité par source documentaire en amont, plutôt qu'en réaction à des signaux de dérive, réduit le volume de réindexation correctrice ultérieure.
Le dispositif de monitoring doit être pensé comme une brique native du pipeline et non comme un ajout postérieur. Les indicateurs à suivre en priorité, au-delà de la disponibilité technique, sont la latence de bout en bout, le taux d'erreur du LLM, le score de satisfaction utilisateur, le volume de requêtes par jour et par type, et le coût d'inférence mensuel, complétés par le suivi du score de similarité et du taux de résultats nuls évoqués plus haut. C'est cette discipline de mesure continue, plus que le choix d'un modèle ou d'une base vectorielle en particulier, qui distingue un pipeline RAG durable d'un prototype qui dérive silencieusement.
Pour les directions data qui pilotent ce type de projet, la question n'est donc plus seulement « combien coûte le pipeline » mais « quel est le coût total sur douze mois, réindexation et monitoring inclus ». C'est cette grille de lecture que nous appliquons systématiquement lors des audits de pipelines RAG en production que nous menons pour nos clients, en amont ou en cours de déploiement.
Le coût des tokens n'est que la partie émergée du budget d'un pipeline RAG en production. Réindexation liée aux montées de version, nettoyage récurrent du corpus, instrumentation de la dérive du contexte : ces postes, absents des premiers chiffrages, peuvent représenter une part substantielle du coût mensuel réel. Les intégrer dès la phase de cadrage, plutôt qu'au moment du premier dépassement budgétaire, est la seule manière de piloter ce type de projet avec fiabilité. Notre équipe accompagne les directions data sur ce chiffrage complet ; n'hésitez pas à nous contacter pour en discuter.