Vos données ne peuvent pas sortir : où faire tourner un LLM, et les trois architectures qui tiennent

---

title: "Vos données ne peuvent pas sortir : où faire tourner un LLM, et les trois architectures qui tiennent" seoTitle: "Où faire tourner un LLM sur données sensibles" description: "Le DPO, le client grand compte ou l'audit fournisseur bloque l'appel d'API. Voici comment qualifier ce qui sort réellement, ce que les certifications des fournisseurs couvrent vraiment sur leurs services d'IA, et les trois architectures qui répondent à la contrainte — avec leurs coûts." seoDescription: "Données qui ne peuvent pas sortir : comment qualifier la contrainte, ce que couvrent vraiment les certifications, et les trois architectures LLM qui tiennent." date: "2026-09-29" author: "Équipe Raicode" tags: ["IA", "architecture", "conformité", "sécurité"] category: "IA & Automatisation" keywords: ["où héberger un LLM", "LLM données sensibles", "LLM souverain", "auto-héberger un LLM", "cloud européen IA", "RGPD et LLM", "architecture LLM on-premise", "zero data retention", "reprise projet IA"]

La fonctionnalité tourne depuis quatre mois. Elle est utile, les utilisateurs internes la réclament, et l'équipe s'apprête à l'ouvrir à un premier client. C'est là que la question arrive, et jamais de la technique : le DPO demande où partent les données, le service achats du client fait remplir un questionnaire fournisseur de quarante lignes, ou le contrat-cadre signé il y a deux ans ressort d'un tiroir avec une clause qui interdit tout transfert hors Union européenne. Personne ne conteste que la fonctionnalité marche. On conteste l'endroit où elle fait tourner le modèle.

À ce moment-là, la discussion dérape vers le mauvais sujet. On se met à comparer des modèles — faut-il passer sur un modèle français, lequel est le plus proche de ce qu'on utilise, est-ce que les benchmarks tiennent. La question est réelle, mais ce n'est pas elle qui bloque. Ce qui bloque, c'est une contrainte de circulation de données, et elle se résout par une décision d'architecture : qu'est-ce qui sort du périmètre, vers qui, et sous quel engagement. Le modèle vient après, et c'est souvent la variable la plus facile à changer.

Cet article s'adresse à une équipe qui a déjà une intégration LLM en production ou en fin de POC, et à qui on demande soudain de prouver que les données ne sortent pas. Il décrit comment qualifier la contrainte, ce que les engagements des fournisseurs couvrent réellement, et les trois architectures qui tiennent.

D'abord qualifier la donnée, pas le fournisseur

La première erreur consiste à traiter « nos données sont sensibles » comme un état binaire qui s'applique à toute la fonctionnalité. Dans la quasi-totalité des projets que nous reprenons, la contrainte ne porte pas sur l'ensemble du flux. Elle porte sur une fraction identifiable de ce qui est envoyé au modèle, et cette fraction est souvent plus petite qu'on ne le croit.

Reprenez le prompt réel, pas le schéma d'architecture. Un appel typique contient quatre choses : des instructions système, des données métier structurées, du contenu documentaire injecté par un RAG, et la saisie de l'utilisateur. Les instructions système ne sont jamais le problème. Les données métier le sont parfois. Le contenu documentaire est le vrai risque, parce que personne ne sait exactement ce qu'il y a dans les documents indexés : c'est là qu'on retrouve des contrats, des comptes-rendus d'entretien, des pièces jointes scannées. Et la saisie utilisateur est incontrôlable par construction.

Sortez donc quatre réponses avant de choisir quoi que ce soit.

Quelle catégorie de données transite réellement ? Pas « des données clients » : des noms, des adresses e-mail, des montants, des documents contractuels, des données d'employés. La catégorie détermine le régime applicable.

Qui impose la contrainte ? Le RGPD, un contrat client, une politique interne, ou un audit fournisseur qui recopie un modèle générique. Ces sources n'ont pas la même force : une politique interne se négocie, une clause signée avec un grand compte ne se négocie pas en trois semaines. Beaucoup d'équipes se mettent sous contrainte maximale parce qu'un questionnaire non contextualisé leur a demandé si les données restaient « en France » — alors que le contrat, lui, dit « Union européenne ».

Quelle proportion du volume est concernée ? Si 5 % des requêtes touchent des documents sensibles et 95 % traitent du contenu public ou déjà anonyme, l'architecture qui répond n'est pas la même que si tout le flux est contraint.

Que se passe-t-il en cas de fuite ? Une amende, la perte d'un client, une obligation de notification, ou rien de mesurable. Cette réponse décide de ce que vous êtes prêt à payer.

Ces quatre réponses tiennent en une page et se produisent en une demi-journée. Elles font souvent plus pour débloquer le projet que trois semaines de comparaison de fournisseurs. C'est d'ailleurs l'un des premiers livrables que nous produisons dans une reprise de projet IA : quand la contrainte n'est pas écrite, chaque interlocuteur se fabrique sa propre version, et la décision d'architecture devient impossible à trancher.

Ce que les engagements des fournisseurs couvrent vraiment

Une fois la contrainte écrite, vient l'examen des engagements. C'est là que se trouve le piège le plus fréquent, et il est simple à énoncer : la certification d'un cloud ne s'étend pas automatiquement à ses services d'IA.

Un hébergeur peut disposer d'une certification ou d'un agrément sur son offre d'infrastructure — machines virtuelles, stockage, base de données — sans que son service d'inférence managé soit couvert par le même périmètre. Ces périmètres sont nominatifs : ils listent des services, région par région, et un service d'IA sorti il y a huit mois est souvent en dehors de l'audit, parfois marqué comme en cours d'intégration. La question à poser n'est donc pas « êtes-vous certifié », à laquelle la réponse est toujours oui, mais « fournissez l'attestation en cours de validité, et montrez-moi la ligne qui nomme le service d'inférence dans la région que nous utilisons ».

Le deuxième point à vérifier est la rétention. Les principaux fournisseurs d'API proposent un mode sans conservation des données — les requêtes ne sont pas stockées au-delà du traitement et ne servent pas à l'entraînement. L'engagement est réel, mais presque toujours conditionné : il faut le demander, parfois signer un avenant, parfois être sur une offre entreprise. Il est aussi fréquemment incompatible avec des fonctionnalités confortables comme la journalisation côté fournisseur. Vérifiez ce que vous perdez avant de l'activer, et que votre code ne repose pas dessus.

Le troisième point est la chaîne de sous-traitance. Un fournisseur européen peut faire tourner l'inférence sur une infrastructure qui ne l'est pas, ou recourir à un support hors UE qui accède aux journaux. La liste des sous-traitants ultérieurs est un document contractuel : demandez-la, ainsi que le préavis en cas de modification. C'est la ligne qui fait échouer les audits six mois après la signature.

Le quatrième point est la localisation effective du traitement, à distinguer de celle de la société. Une entreprise de droit français peut opérer dans une région qui ne l'est pas ; un service peut basculer sur une région de secours en cas d'incident. Demandez si ce basculement est contractuellement borné.

Tant que ces quatre éléments ne sont pas écrits noir sur blanc, le débat « souverain ou pas » n'a pas d'objet. Une fois qu'ils le sont, trois architectures seulement restent en lice.

Architecture 1 — API publique, avec minimisation en amont

Le principe : vous continuez d'appeler une API d'inférence hors de votre périmètre, mais rien de ce qui est contraint ne l'atteint. Une couche de transformation, dans votre infrastructure, retire ou remplace les éléments identifiants avant l'appel, et les réintroduit dans la réponse.

Concrètement, cela veut dire une passerelle maison qui détecte les entités à protéger — noms, e-mails, téléphones, identifiants internes — les remplace par des jetons stables le temps de la requête, puis fait le chemin inverse sur la sortie du modèle. La détection combine des règles déterministes sur ce qui est structuré et un modèle de reconnaissance d'entités local sur le texte libre.

C'est l'architecture la moins chère et la plus rapide à mettre en place : quelques jours de développement, aucun changement de fournisseur, aucune perte de qualité sur le modèle. Elle convient quand la contrainte porte sur des identifiants et non sur le contenu — aide à la rédaction, classification de tickets, extraction sur des documents dont le corps n'est pas confidentiel.

Ses limites sont sérieuses. La pseudonymisation n'est pas de l'anonymisation : un contrat dont on a retiré les noms reste souvent réidentifiable par son contenu. La détection d'entités en texte libre n'atteint jamais 100 %, et un taux de 97 % sur 50 000 requêtes mensuelles laisse passer 1 500 fuites potentielles. Enfin, le masquage dégrade parfois la réponse, et les équipes finissent par assouplir les règles sous la pression des utilisateurs. Si vous retenez cette architecture, faites du taux de détection une métrique surveillée, pas une case cochée à la recette.

Cette voie ne tient pas quand la contrainte est contractuelle plutôt que réglementaire. Une clause qui interdit tout transfert de données client hors UE ne fait pas de distinction entre données identifiantes et contenu : c'est le flux entier qui est interdit.

Architecture 2 — modèle managé dans un périmètre contractuel maîtrisé

Le principe : vous appelez toujours une API, mais opérée par un fournisseur dont la localisation et les engagements satisfont la contrainte — service d'inférence d'un hébergeur européen, déploiement dédié chez un éditeur de modèles dans une région choisie, ou offre d'inférence d'un grand cloud dans une région européenne avec un avenant de traitement des données.

C'est l'architecture qui convient à la majorité des situations que nous rencontrons, et elle est sous-considérée parce que moins spectaculaire que l'auto-hébergement. Le modèle d'exploitation reste identique : une API proche de ce que votre code appelle déjà, la mise à l'échelle assurée par le fournisseur, la facturation à l'usage, aucune équipe d'infrastructure à monter. Le surcoût par million de jetons est réel, mais il se compte en dizaines de pourcents, pas en multiples.

Le travail à faire est contractuel plus que technique : les quatre vérifications de la section précédente s'appliquent ici. Comptez deux à six semaines pour obtenir les documents et les faire valider par le juridique — c'est le vrai chemin critique, pas l'intégration.

Côté technique, la seule précaution qui compte est de ne pas s'attacher au fournisseur. Si votre code appelle directement le SDK d'un éditeur, avec ses noms de paramètres et son format d'outils, chaque changement devient un chantier. Une interface d'appel unique avec un adaptateur par fournisseur coûte deux jours au départ et vous évite de choisir entre la conformité et la réécriture. C'est la même discipline que celle qui permet de faire baisser une facture en routant les requêtes vers plusieurs modèles : nous l'avons détaillée dans l'article sur ce qui fait exploser une facture d'API LLM, et elle sert exactement autant ici.

Sur la qualité, il faut être honnête : les modèles disponibles dans ce cadre ne sont pas toujours les meilleurs du marché. L'écart s'est réduit sur les tâches courantes — extraction, classification, synthèse, réponse sur documents — et reste sensible sur le raisonnement long et le code. Ne tranchez pas sur des benchmarks publics : reprenez cinquante cas réels de votre production, faites-les passer sur les deux modèles, comparez sur vos critères. Deux jours de travail, et une décision défendable en comité.

Architecture 3 — modèle ouvert auto-hébergé

Le principe : le modèle tourne sur des machines que vous contrôlez, dans votre cloud privé ou sur votre propre matériel. Aucune donnée ne quitte le périmètre, la question du transfert disparaît. C'est la réponse qui satisfait toutes les contraintes — et celle qui coûte le plus cher, d'une manière que les équipes sous-estiment systématiquement.

Le coût visible est celui du GPU. Un modèle ouvert de taille moyenne, quantifié, tient sur une carte de 48 Go ; les modèles plus gros demandent 80 Go ou plusieurs cartes. À la location chez un hébergeur européen, une carte de cette gamme se situe dans l'ordre de grandeur de 1 à 3 € l'heure, soit 800 à 2 000 € par mois et par carte en réservation continue — et il en faut au moins deux pour rester disponible pendant une mise à jour ou une panne.

Le coût invisible est celui de l'exploitation, et c'est lui qui décide. Il faut quelqu'un qui sache dimensionner le débit en jetons par seconde, configurer un serveur d'inférence et son traitement par lots, gérer la mémoire cache du contexte, surveiller la latence au 95e centile aux heures de pointe, et refaire l'exercice à chaque changement de modèle. Ce n'est pas une compétence qu'on improvise, et rarement une demi-journée par semaine. Sur un an, cette charge dépasse souvent la facture de matériel.

La règle empirique que nous appliquons : l'auto-hébergement devient rationnel quand la facture d'API dépasse plusieurs dizaines de milliers d'euros par mois, ou quand la contrainte ne laisse aucune autre option. Entre les deux, c'est un choix de confort qui se paie en temps d'équipe. Beaucoup de projets basculent parce qu'un développeur a fait tourner un modèle sur son portable et en a conclu que c'était simple — un portable sert une requête à la fois, sans concurrence, sans astreinte et sans engagement de latence.

Quand cette architecture est la bonne, elle l'est vraiment : sous contrainte forte, avec un volume prévisible et une équipe d'infrastructure existante, le coût marginal devient très bas et le budget, prévisible comme aucune API ne le permet.

Choisir, et écrire pourquoi

Le tableau de décision tient en quatre lignes.

| Contrainte dominante | Architecture qui tient | | --- | --- | | Identifiants sensibles, contenu banal, volume modéré | API publique avec minimisation en amont | | Clause contractuelle ou RGPD sur la localisation | Modèle managé dans un périmètre contractuel vérifié | | Interdiction absolue de sortie, ou volume très élevé | Modèle ouvert auto-hébergé | | Contrainte sur une fraction du flux seulement | Routage : le flux contraint sur l'architecture lourde, le reste sur l'API |

La dernière ligne mérite qu'on s'y arrête : elle est presque toujours la meilleure réponse et presque jamais celle qu'on envisage. Si 10 % de vos requêtes touchent des documents contraints, faire tourner 100 % du trafic sur une infrastructure dédiée revient à payer dix fois le prix de la contrainte réelle. Une classification en amont, qui oriente chaque requête vers l'un ou l'autre chemin, est un composant simple — et c'est la décision qui divise le budget.

Quel que soit le choix, écrivez-le : une page qui dit quelle catégorie de données transite, quelle source impose la contrainte, quelle architecture a été retenue et quels engagements fournisseurs ont été vérifiés, avec leurs dates. C'est ce document qui évite de refaire l'analyse au prochain audit, et c'est celui qu'on cherche en vain dans huit projets sur dix quand on en reprend l'audit technique. Sa longueur n'a aucune importance ; son existence, si.

Une dernière chose, parce qu'elle revient dans tous les audits : maîtriser l'endroit où tourne le modèle ne règle pas la question de ce qu'il peut atteindre. Un modèle auto-hébergé qui interroge un index vectoriel mal cloisonné fera sortir un document d'un client vers un autre, sans qu'aucune donnée n'ait quitté votre infrastructure. Localisation et cloisonnement sont deux problèmes distincts ; le second est traité à part dans notre article sur la sécurisation d'un LLM avant l'ouverture aux clients.

La prochaine action

Si le sujet est ouvert chez vous, ne commencez pas par comparer des fournisseurs. Prenez une demi-journée, ouvrez le code qui construit le prompt, écrivez ce qui part réellement dans chaque appel, puis allez chercher le texte qui impose la contrainte — le contrat, pas le résumé qu'on vous en a fait. Dans la moitié des cas, cette demi-journée montre que la contrainte est plus étroite que supposé, et que l'architecture en place peut rester moyennant une couche de minimisation et un avenant fournisseur. Dans l'autre moitié, elle donne une base pour chiffrer la bascule au lieu de la subir.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.