Architecture RAG + LLM self-hosté : comment garder vos données en UE sans sacrifier la performance.

La plupart des projets d’IA d’entreprise commencent par un appel à une API américaine. C’est rapide, ça marche, et c’est souvent la première chose qu’on vous propose. Le problème arrive plus tard, quand quelqu’un pose la vraie question : où partent les données ?

Quand vos documents internes, vos échanges clients ou vos données métier transitent par un service hébergé hors de l’Union européenne, vous perdez le contrôle de deux choses : leur localisation et leur usage. Pour beaucoup de nos clients — secteur public, santé, finance, industrie — ce n’est pas une préférence, c’est une contrainte non négociable.

La bonne nouvelle, c’est qu’on n’a plus à choisir entre souveraineté et performance. Depuis que les modèles open source ont rattrapé les modèles propriétaires sur la grande majorité des usages métier, on peut faire tourner une IA performante entièrement en Europe, sur du matériel qu’on maîtrise. Voici comment on construit ces plateformes, brique par brique, sans jargon.

Le problème qu’on cherche vraiment à résoudre

On nous demande rarement « de l’IA ». On nous demande qu’un collaborateur puisse poser une question en langage naturel et obtenir une réponse fiable, tirée des documents de l’entreprise : contrats, procédures, fiches techniques, historique client, base de connaissances.

Un modèle de langage seul ne sait pas faire ça. Il a été entraîné sur des données générales, figées à une date donnée, et il ne connaît rien de vos documents internes. Si vous lui posez une question sur votre dernière procédure qualité, soit il ne sait pas répondre, soit — pire — il invente une réponse plausible mais fausse. C’est exactement le trou que vient combler le RAG.

Le RAG, expliqué sans buzzword

RAG signifie Retrieval-Augmented Generation : génération augmentée par la recherche. Le principe tient en une phrase : avant de répondre, on va chercher les bons documents, et on les donne au modèle pour qu’il s’appuie dessus.

Concrètement, quand un utilisateur pose une question, il se passe trois choses :

L’analogie la plus simple : c’est la différence entre un examen à livre fermé et un examen à livre ouvert. Sans RAG, le modèle répond de mémoire. Avec RAG, on lui ouvre la bonne page au bon moment. Il répond mieux, il invente beaucoup moins, et surtout il peut citer ses sources — ce qui change tout pour un usage professionnel où la traçabilité compte.

La stack, brique par brique

Voici les composants d’une plateforme RAG souveraine telle qu’on la déploie. Chaque brique a une fonction précise, et chacune existe en version open source, hébergeable en Europe.

1. Le socle matériel : du GPU en UE

Tout part de là. Faire tourner un modèle de langage demande des cartes graphiques (GPU). Plusieurs fournisseurs européens proposent aujourd’hui des instances GPU dans des datacenters situés en France ou en UE, avec des garanties de localisation claires. Si le matériel est en Europe et que rien n’en sort, la conformité RGPD n’est plus un combat : c’est une propriété du système.

2. Le modèle de langage : open source, servi efficacement

On s’appuie sur des modèles open source de premier plan (familles Mistral, Llama, Gemma, Qwen, selon le besoin), qui atteignent aujourd’hui un niveau largement suffisant pour la quasi-totalité des usages métier : synthèse, réponse à partir de documents, classification, extraction. Le modèle est servi via un moteur d’inférence optimisé (type vLLM ou TGI) qui gère la file des requêtes et l’occupation du GPU — la différence entre un prototype qui répond en dix secondes et une plateforme qui répond en une.

3. Les embeddings : transformer le texte en repères

Pour retrouver les bons passages, l’ordinateur transforme vos documents en vecteurs : des suites de nombres qui capturent le sens d’un texte. Deux textes qui parlent de la même chose auront des vecteurs proches, même avec des mots différents. C’est le rôle d’un modèle d’embeddings, lui aussi open source et auto-hébergé (les familles E5 multilingue ou BGE fonctionnent très bien en français).

4. La base vectorielle : la mémoire consultable

Une fois vos documents transformés en vecteurs, il faut les ranger là où on peut les interroger très vite. Selon le volume et l’existant du client, on utilise pgvector (extension de PostgreSQL, idéale pour tout garder dans une base déjà maîtrisée) ou un moteur dédié comme Qdrant pour les très gros volumes. Dans les deux cas : open source, hébergé chez vous, en UE.

5. Le pipeline de recherche : là où se joue la qualité

C’est la brique la moins visible et la plus déterminante. Entre « j’ai des documents » et « je trouve le bon passage », il y a un vrai travail d’ingénierie :

6. L’orchestration et l’exposition

Au-dessus, une couche applicative enchaîne les étapes — recevoir la question, l’enrichir, lancer la recherche, appeler le modèle, renvoyer la réponse et ses sources — et expose le tout via une API. C’est là qu’on branche les droits d’accès : un utilisateur ne doit jamais obtenir une réponse tirée d’un document qu’il n’a pas le droit de lire. Le filtrage se fait au niveau de la recherche, pas après coup. Et cette couche s’intègre naturellement dans la Wapp du client : le RAG n’est pas un outil à part, c’est une brique de la plateforme.

« Sans sacrifier la performance » : ce que ça veut dire

La performance se joue sur deux fronts : la vitesse et la qualité. Côté vitesse, les leviers sont connus et efficaces :

Côté qualité, le secret est contre-intuitif : sur un RAG bien construit, la performance ne dépend pas tant du modèle que du pipeline de recherche.

La réalité des coûts

Un mot d’honnêteté : la souveraineté a un prix. Auto-héberger un LLM demande du GPU, qui coûte qu’il serve ou non. Le calcul bascule en votre faveur dès qu’il y a du volume.

Les API propriétaires facturent à l’usage : imbattable pour un prototype, de plus en plus cher quand l’adoption monte. Une infrastructure dédiée a un coût fixe : élevé au départ, mais stable, prévisible, et qui ne dérive pas avec le nombre d’utilisateurs. À partir d’un certain seuil d’usage, le self-hosting revient moins cher — et vous récupérez au passage la maîtrise de vos données. Notre rôle : dimensionner juste, ni un GPU surdimensionné qui dort, ni une infrastructure qui sature aux heures de pointe.

Quand ça vaut le coup — et quand non

On préfère le dire avant de vendre quoi que ce soit. Une architecture RAG + LLM souveraine est pertinente quand vous avez des données sensibles ou réglementées, un corpus documentaire réel à exploiter, et un usage appelé à monter en charge — le cas typique d’une plateforme métier qui sert chaque jour des dizaines ou des centaines de collaborateurs.

À l’inverse, si vous voulez juste tester une idée, sur des données non sensibles, avec quelques requêtes par jour, commencer par une API propriétaire est parfaitement raisonnable — et nous vous le dirons. L’intérêt du sur-mesure souverain, c’est qu’on peut démarrer simple et faire migrer la brique modèle plus tard, sans tout reconstruire, parce que l’architecture a été pensée pour ça dès le départ.

Ce qu’on retient

Garder ses données en UE n’oblige plus à renoncer à une IA performante. Les modèles open source sont au niveau, le matériel européen existe, et l’essentiel de la qualité se joue dans un pipeline de recherche bien conçu — pas dans la course au plus gros modèle.

C’est précisément le genre de problème pour lequel on existe : assembler des briques éprouvées, hébergées au bon endroit, dans une plateforme qui répond à votre besoin métier. Plus c’est complexe, plus l’avantage de composer au lieu d’additionner se voit.