RAG on-premise vs cloud UE : matrice de décision pour l'hébergement

RAG on-premise vs cloud désigne le choix d'hébergement d'un système de génération augmentée par récupération : en on-premise (auto-hébergé), la base de données vectorielle, le modèle d'embedding et le modèle de langage tournent sur du matériel propre ou dédié, avec un contrôle maximal des données (CapEx). Avec le cloud UE, tu utilises des services managés dans des centres de données de l'UE, avec des coûts à l'usage (OpEx) et une mise à l'échelle rapide. Le bon choix découle de la sensibilité des données, de la conformité, des coûts, de la latence et du savoir-faire d'exploitation.

• L'on-premise/auto-hébergé convient en cas de forte sensibilité des données, d'exigences strictes de souveraineté et de savoir-faire d'exploitation disponible. Le prix à payer : du CapEx et une charge interne.
• Le cloud UE convient pour un déploiement rapide, un OpEx prévisible et une mise à l'échelle élastique. Avec les fournisseurs américains, il reste toutefois un risque résiduel lié au Cloud Act à évaluer.
• L'hybride combine les deux : données sensibles on-prem, charges de travail génériques dans le cloud UE. C'est la voie standard pour les grands groupes aux classes de données mixtes.

Les six critères de décision

Une décision d'hébergement RAG solide repose sur six dimensions interdépendantes.

Sensibilité des données

Les embeddings ne sont pas une protection sûre : selon l'interprétation actuelle, transformer des documents contenant des données personnelles en embeddings ne constitue pas une pseudonymisation sûre. À l'aide de décodeurs adaptés, on peut reconstruire des éléments à partir des embeddings. Les contenus personnels ou classifiés doivent donc être traités comme des données personnelles jusqu'à ce que l'autorité de contrôle ou la jurisprudence en décide autrement. Plus le corpus est sensible, plus l'argument en faveur de l'on-premise ou au moins d'un hébergement souverain dans l'UE est fort.

Conformité (RGPD et réglementation sectorielle)

La principale aide à l'interprétation en langue allemande est le guide d'orientation sur les systèmes RAG de la Conférence des autorités allemandes de protection des données (DSK), publié en octobre 2025. Comme toutes les positions de la DSK, il n'est pas juridiquement contraignant, pas même en Allemagne, et il lie encore moins les autorités autrichiennes et suisses. Il montre toutefois comment les autorités de contrôle allemandes appliquent le RGPD au RAG. Parmi les bonnes pratiques pour la base de données vectorielle, il cite par exemple le cloisonnement des tenants et une gestion des droits et des rôles. Sont particulièrement pertinents : l'article 5 du RGPD (principes tels que la limitation des finalités, la minimisation des données et la limitation de la conservation), l'art. 6 (base juridique, généralement art. 6, paragraphe 1, points b/f) et l'art. 17 (droit à l'effacement ; selon la DSK, les entrées de la base de données vectorielle sont directement adressables et donc supprimables de manière ciblée).

Concernant le règlement européen sur l'IA : le règlement omnibus numérique sur l'IA, le règlement (UE) 2026/1744, est entré en vigueur le 27 juillet 2026 et a reporté les règles applicables aux systèmes à haut risque. Selon le calendrier de la Commission européenne, elles s'appliquent à partir du 2 décembre 2027 aux systèmes relevant de l'annexe III et à partir du 2 août 2028 à l'IA intégrée dans des produits relevant de l'annexe I. Les obligations de transparence de l'art. 50 s'appliquent depuis le 2 août 2026. Les fournisseurs de systèmes génératifs déjà présents sur le marché auparavant ont jusqu'au 2 décembre 2026 pour le marquage lisible par machine. Pour un RAG servant de couche de connaissances à un système à haut risque, les exigences de qualité des données (art. 10), de journalisation (art. 12) et de transparence (art. 13) s'appliquent à partir de ces dates. Ces informations sont fournies à titre indicatif et ne constituent pas un conseil juridique.

Coûts : CapEx vs OpEx, tokens vs matériel

Le cloud UE est piloté par l'OpEx : les principaux postes de coûts sont l'API d'embedding, l'hébergement de la base vectorielle, les appels au LLM et, en option, un reranker. Ordres de grandeur d'après les recherches : indexation d'environ 0,02-0,13 USD pour 1 million de tokens, une requête d'environ 0,001-0,05 USD selon le modèle ; indexation Contextual Retrieval chez Anthropic d'env. 1,02 USD pour 1 million de tokens de document avec le prompt caching (situation en 2026). L'on-premise est piloté par le CapEx : GPU, stockage, exploitation. Avec un volume faible ou fluctuant, le cloud l'emporte ; avec un volume élevé et constant, l'auto-hébergement peut devenir moins cher après amortissement.

Mise à l'échelle

Les bases de données vectorielles montent en charge via l'index. HNSW (Malkov et Yashunin) est l'index standard de Qdrant, Weaviate, Milvus, pgvector, OpenSearch, Elasticsearch et d'autres. Il tient jusqu'à environ 100 millions de vecteurs avec un bon rapport recall/vitesse. Pour les très grands index sous contrainte de RAM, on utilise IVF_PQ ou DiskANN/BBQ. Les services cloud UE (Qdrant Cloud, Weaviate Cloud) offrent de l'élasticité sans planification matérielle ; l'on-premise exige un dimensionnement anticipé des GPU et du stockage.

Latence

Un pipeline associant retrieval hybride et rerank se situe généralement autour de 100-800 ms. L'on-premise permet de contrôler entièrement la latence et les chemins de données (pas de saut Internet vers des API externes) ; les services cloud proposent des régions UE à faible latence ; Qdrant et Pinecone sont réputés pour leur très faible latence.

Charge d'exploitation et savoir-faire

L'on-premise concentre la responsabilité en interne : réglage de l'index (M, ef_construction, ef_search), réindexation en cas de changement de modèle d'embedding, monitoring et évaluation. Le cloud UE en transfère une partie au fournisseur. Sans évaluation RAGAS/TruLens, les deux modèles risquent une régression silencieuse de la qualité.

Matrice de décision : on-premise vs cloud UE vs hybride

Options souveraines DACH (Allemagne, Autriche, Suisse) et UE (situation en 2026) : base de données vectorielle Qdrant (Berlin, Apache 2.0) et Weaviate (Amsterdam, BSD-3) ; framework Haystack/deepset (Berlin) ; embeddings Aleph Alpha (Heidelberg, compatible on-prem) et jina-embeddings-v3 (Berlin) ; LLM Mistral (FR/UE), Aleph Alpha Pharia et Teuken-7B (OpenGPT-X) ; hébergement STACKIT (groupe Schwarz), IONOS, OVHcloud et Open Telekom Cloud.

Pour l'auto-hébergement, BGE-M3 est le premier choix, même s'il ne s'agit pas d'un modèle européen : il provient de la Beijing Academy of Artificial Intelligence (BAAI). Mais il est publié sous licence MIT et fonctionne entièrement sur ton propre matériel, les données ne quittent donc pas l'entreprise. Les poids de jina-embeddings-v3 sont en revanche sous CC BY-NC 4.0 : pour un usage commercial au sein de ta propre entreprise, il te faut une licence selon la fiche du modèle. De plus, Jina AI appartient à Elastic depuis octobre 2025. En septembre 2026, Aleph Alpha a signé un accord de fusion avec le fournisseur canadien Cohere. La finalisation doit encore être approuvée par les autorités. Vérifie donc comment l'hébergement et le traitement des données seront encadrés par la suite.

Recommandation par scénario

PME

Pour les PME au volume modéré et sans équipe MLOps dédiée, le cloud UE est généralement le choix rationnel : déploiement rapide, OpEx prévisible, aucun investissement matériel. Stack pragmatique : Qdrant Cloud ou Weaviate Cloud dans la région UE, un modèle d'embedding multilingue (par exemple Cohere Embed v4 ou jina-embeddings-v3) et un LLM d'un fournisseur européen comme Mistral. Restent essentiels le cloisonnement des tenants, les filtres ACL et un pipeline de suppression capable de retirer des entrées individuelles de manière ciblée.

Secteur réglementé

La santé, la finance, l'administration publique ou la défense, avec des données hautement sensibles ou classifiées, tendent vers le mode on-premise/souverain. Point de référence issu des recherches : l'architecture secunet x NVIDIA x Haystack pour les informations classifiées ainsi que le déploiement on-prem de la plateforme Aleph Alpha Pharia pour les grands groupes et l'administration publique. Ici, le contrôle total des données compte davantage que le confort du cloud ; les citations de sources dans la réponse sont pratiquement indispensables pour les secteurs réglementés, car auditeurs et autorités de contrôle attendent de la traçabilité.

Grand groupe

Les grandes entreprises adoptent généralement un modèle hybride : embeddings sensibles à caractère personnel on-premise ou dans un cloud privé souverain, charges de travail de connaissances génériques (documentation produit, FAQ) dans le cloud UE. Des utilisateurs connus de Haystack comme Airbus, Lufthansa Industry Solutions, Infineon ou LEGO montrent que les frameworks souverains tournent en production dans de grands environnements. Les classes de données sont séparées, et mise à l'échelle et contrôle restent conciliables.

Exemple pratique chiffré

Une PME de la région DACH envisage un RAG de connaissances interne avec 5 millions de tokens de documents et 50 000 requêtes par mois.

• Indexation (unique/incrémentale) : 5 millions de tokens à env. 0,02-0,13 USD pour 1 million de tokens donnent environ 0,10-0,65 USD par réindexation complète. Avec Contextual Retrieval et le prompt caching (env. 1,02 USD pour 1 million de tokens), un index contextualisé complet revient à environ 5 USD.
• Requêtes (récurrentes) : 50 000 requêtes à env. 0,001-0,05 USD donnent environ 50-2 500 USD par mois, avec de fortes variations selon le modèle.

Dans le cloud UE, cela génère uniquement de l'OpEx, sans investissement initial. À ce volume, c'est clairement rentable. Ce n'est qu'avec un volume de requêtes nettement plus élevé et constant, ou en cas d'obligation de stocker les données on-prem, que le calcul bascule en faveur du matériel amorti. Repère qualitatif : un pipeline RAG est environ 30-60 fois plus rapide et environ 1 250 fois moins cher par requête que des requêtes naïves en contexte long de 1 million de tokens (ordre de grandeur, situation en 2026). C'est un argument supplémentaire pour exploiter les connaissances via le RAG plutôt que via de coûteux prompts en contexte complet, indépendamment de l'hébergement.

Pour les agences et les décideurs B2B

La question de l'hébergement n'est pas une simple décision informatique, c'est un levier de conformité et de coûts. Les agences qui conçoivent des solutions RAG pour des clients en Europe devraient utiliser la matrice ci-dessus comme outil de discovery : clarifier d'abord la sensibilité des données et la réglementation sectorielle, puis le profil de coûts et de mise à l'échelle, et enfin le modèle d'exploitation. Chez Blck Alpaca, nous évaluons pour chaque cas d'usage la bonne combinaison de cloud UE et de briques souveraines on-prem, et nous livrons dans la foulée l'architecture conforme au RGPD (cloisonnement des tenants, pipeline de suppression, citations de sources). Les notions juridiques, numéros d'articles et délais mentionnés dans ce texte sont fournis à titre indicatif et ne remplacent pas un conseil juridique. L'évaluation juridique définitive relève de juristes spécialisés en protection des données et dans le secteur concerné.