Modèles open-weight : résidence des données et options de déploiement

Table des matières :

1. Pourquoi les modèles open-weight remettent la résidence des données au centre
2. Quatre notions à ne pas confondre avant de choisir une option de déploiement
3. Où « résident » vraiment vos données dans un usage LLM : prompts, logs, embeddings et fine-tuning
4. Panorama des options de déploiement open-weight (et ce que vous gagnez, ce que vous perdez)
5. Sécurité et contrôle opérationnel : clés de chiffrement, isolation, traçabilité
6. Contrats, portabilité et méthode de décision : rendre la résidence des données vérifiable et réversible

Pourquoi les modèles open-weight remettent la résidence des données au centre

Un modèle open-weight est un modèle d’IA dont les poids (les paramètres numériques appris pendant l’entraînement) sont distribués et réutilisables sous licence, même si le code d’entraînement et les données d’origine ne sont pas publiés. Cette ouverture des poids change l’arbitrage : au lieu d’appeler une interface distante imposée par un éditeur, vous pouvez exécuter le modèle là où vos contraintes de résidence des données (le lieu où les données sont stockées et traitées) sont compatibles avec votre politique interne.

Dans la pratique, « open-weight » n’est pas synonyme d’« open source » au sens strict : une licence peut autoriser l’usage des poids tout en encadrant la redistribution, la modification ou certains cas d’usage. C’est un point de gouvernance, pas un détail juridique. Deux organisations peuvent utiliser le même modèle open-weight, mais avec des options de déploiement et des engagements contractuels très différents sur la localisation des traitements, la journalisation ou le support.

Ce regain d’intérêt est aussi économique. À qualité comparable, l’inférence (l’exécution d’un modèle pour produire une réponse) peut être optimisée via la quantification, le batching ou des moteurs spécialisés. Les décideurs y voient une façon de réduire la facture récurrente d’API, mais aussi de reprendre la main sur des flux de données sensibles (documents internes, secrets industriels, données de santé, données RH). L’ouverture des poids ne supprime toutefois ni les risques de fuite ni les obligations de conformité : elle élargit simplement l’éventail des architectures possibles.

Concrètement, la résidence des données redevient un sujet central parce que l’usage des LLM multiplie les « micro-transferts » : un simple assistant interne peut faire transiter, en quelques secondes, des extraits de contrats, des éléments d’identité, des informations RH, des tickets d’incident ou des fragments de code. Si ces données partent vers une API externe (même située dans l’UE), la question n’est pas uniquement « où sont les serveurs ? », mais aussi qui opère, qui a accès, quels sous-traitants interviennent, que deviennent les logs et quelles preuves sont disponibles.

« Les données à caractère personnel doivent être (…) adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités. » (Règlement (UE) 2016/679, art. 5(1)(c), version française sur Eur-Lex, 2016) : Consulter le règlement (UE) 2016/679 sur Eur-Lex

Dans cette logique de minimisation, les modèles open-weight peuvent faciliter une approche plus sobre : exécuter localement, filtrer en amont ce qui est envoyé au modèle et réduire les surfaces de journalisation au strict nécessaire. Cela ne garantit rien par principe, mais peut rendre cet objectif techniquement atteignable.

Quatre notions à ne pas confondre avant de choisir une option de déploiement

L’hébergement est le fait de mettre à disposition une infrastructure (serveurs, stockage, réseau) sur laquelle vos données et vos applications résident et s’exécutent. La juridiction applicable est l’ensemble des lois et autorités susceptibles d’imposer des obligations à un acteur (fournisseur, maison-mère, filiale), indépendamment du seul lieu physique des serveurs. La maîtrise du modèle est votre capacité à choisir la version du modèle, à contrôler sa configuration, ses mises à jour et ses dépendances, ainsi qu’à décider de la manière dont il est appelé (API, bibliothèque locale, service interne). La réversibilité est votre capacité à changer de fournisseur ou d’architecture avec un coût, un délai et une perte de fonctionnalité maîtrisés (export, compatibilité, assistance de sortie).

Ces notions se croisent sans se remplacer. Vous pouvez héberger en France tout en dépendant contractuellement d’un acteur soumis à une autre juridiction. Vous pouvez maîtriser techniquement un modèle open-weight (le faire tourner sur vos GPU) tout en ayant une faible réversibilité si vos applications sont construites autour d’un format de prompts propriétaire, d’un magasin de vecteurs non portable ou d’une chaîne d’outils verrouillée.

Pour décider, il est utile de relier ces quatre notions à des exigences concrètes : exigences internes (classification, chiffrement, traçabilité), exigences réglementaires (RGPD, secret des affaires, exigences sectorielles) et exigences d’acheteur (SLA, support, conditions de sortie). Sur les aspects contractuels RGPD, l’article interne sur les clauses de sous-traitance est un bon point d’appui : Article 28 RGPD : clauses clés du contrat de sous-traitance.

Un moyen simple d’éviter les confusions, avant même de comparer des fournisseurs ou des architectures, consiste à se poser quatre questions « vérifiables » (donc auditables) :

• Hébergement : dans quelle(s) région(s) et quel(s) datacenter(s) l’inférence, le stockage (documents, vecteurs) et la journalisation sont-ils opérés ?
• Juridiction : quelle(s) entité(s) contractent avec vous (filiale UE, maison-mère), et quelles obligations légales pourraient s’appliquer à elles ?
• Maîtrise du modèle : qui décide quand le modèle est mis à jour (y compris les changements de comportement), et pouvez-vous figer une version en production ?
• Réversibilité : êtes-vous capable, en conditions réelles, de redéployer ailleurs avec (a) vos prompts système, (b) votre index RAG, (c) vos règles de filtrage et (d) vos métriques ?

Cette approche « quatre axes » évite un piège fréquent : considérer la résidence des données comme un attribut binaire (« c’est en France / ce n’est pas en France »), alors qu’elle résulte d’un ensemble de décisions techniques et contractuelles.

Où « résident » vraiment vos données dans un usage LLM : prompts, logs, embeddings et fine-tuning

Dans un système de type grand modèle de langage (LLM), la donnée ne se limite pas au texte que l’utilisateur saisit. Les prompts (requêtes) incluent souvent du contexte ajouté automatiquement : extrait de CRM, ticketing, documents de procédure ou pièces jointes converties en texte. Les réponses peuvent elles-mêmes devenir des données si elles sont réinjectées dans des outils (copilot bureautique, génération de code, rédaction de courriers) et archivées.

Un second flux est la journalisation (logs), c’est-à-dire l’enregistrement technique d’événements d’exécution pour l’exploitation et la sécurité. Certains services conservent des logs de requêtes pour le débogage, l’amélioration du service ou la détection d’abus, avec des durées de rétention variables. Sur un déploiement open-weight dont vous administrez l’infrastructure et les composants, vous pouvez davantage maîtriser ce qui est journalisé, où et pendant combien de temps. Sur un service managé, c’est un point à contractualiser et à vérifier dans la documentation technique et les paramètres de configuration.

Enfin, les architectures modernes utilisent souvent du RAG (génération augmentée par récupération) : vos documents sont découpés, transformés en embeddings (vecteurs numériques représentant leur contenu sémantique) et stockés dans une base de données de vecteurs. Même si un embedding n’est pas un document lisible, il peut être sensible selon le contexte (corrélations, possibilité de reconstruction partielle ou présence de données personnelles). Cette cartographie des flux et des accès est exactement le type de travail recommandé avant de trancher une option de déploiement : Gouvernance IA : cartographie des flux et accès pour données sensibles.

Pour rendre la résidence réellement pilotable, il est utile de matérialiser où la donnée peut se retrouver, y compris « par défaut » (débogage, métriques, caches). Exemple de grille de lecture opérationnelle :

Élément manipulé	Contenu typique	Où ça « vit » souvent	Risque si mal maîtrisé	Contrôle prioritaire
Prompt utilisateur	question + contexte métier	service d’inférence + éventuels proxy/gateway	fuite directe de données sensibles	filtrage / DLP en amont + chiffrement en transit
Prompt système	règles + consignes internes	dépôt de configuration, code, outil d’orchestration	exposition de règles internes (sécurité, processus)	gestion de secrets + contrôle d’accès
Logs applicatifs	métadonnées + parfois contenu	plateforme d’observabilité / SIEM	rétention trop longue, accès trop large	politique de rétention + minimisation + RBAC
Documents RAG	PDF, notes, procédures	stockage objet + moteur d’indexation	accès transverse / erreurs IAM	segmentation + contrôle d’accès par périmètre
Embeddings	vecteurs + identifiants de documents	base vectorielle managée ou self-hosted	extraction indirecte / corrélation	isolement, chiffrement, journalisation des accès
Fine-tuning / SFT / LoRA	exemples annotés	pipeline d’entraînement + artefacts (checkpoints)	persistance longue, réutilisation non voulue	stockage dédié, purge, gestion de versions

Deux points sont souvent sous-estimés :

• Les caches : certaines chaînes d’inférence mettent en cache des sorties (ou des prétraitements) pour accélérer. C’est utile, mais à encadrer : où est le cache, combien de temps est-il conservé et est-il « tenant-aware » ?
• Les données de personnalisation : dès qu’on fait du fine-tuning (même « léger » via LoRA), on crée de nouveaux artefacts (adaptateurs, checkpoints) qui doivent être gouvernés comme des données sensibles : stockage, accès et cycle de vie. Ils peuvent notamment mémoriser des informations issues des données d’entraînement.

Enfin, pour les risques applicatifs propres aux LLM (prompt injection, exfiltration via outils, etc.), un point de repère non commercial est le projet OWASP dédié : OWASP Top 10 pour les applications de grands modèles de langage (utile pour cadrer des contrôles techniques, indépendamment du modèle choisi).

Panorama des options de déploiement open-weight (et ce que vous gagnez, ce que vous perdez)

Option 1 : consommer un modèle open-weight via une API opérée par un tiers. C’est souvent le plus rapide pour démarrer (temps de mise en œuvre faible, pas de GPU à gérer), mais la résidence des données devient une question de localisation des régions, de sous-traitance et de paramètres de conservation. La maîtrise du modèle est partielle : vous dépendez de la version exposée, des limites de débit et de la politique de logs. Cette option peut convenir à des données peu sensibles, des prototypes ou des charges irrégulières, sous réserve des contrôles et conditions applicables.

Option 2 : déployer le modèle open-weight sur une infrastructure cloud que vous administrez, dans une région choisie. Vous gagnez en maîtrise (réseau privé, segmentation, politiques IAM, observabilité) et en capacité à imposer des contrôles (chiffrement, filtrage des sorties, red teaming). Vous perdez du temps d’exploitation : gestion des images, des correctifs, mise à l’échelle GPU et continuité d’activité. Techniquement, beaucoup d’organisations standardisent via des conteneurs et des orchestrateurs, avec des serveurs d’inférence (par exemple vLLM, TGI, Triton) et des optimisations (quantification 8 bits/4 bits, batching dynamique) pour réduire le coût par million de tokens.

Option 3 : déployer on-premise ou dans un cloud qualifié pour des données sensibles, au prix d’un effort matériel et opérationnel plus élevé. C’est l’option la plus exigeante en ingénierie (approvisionnement en GPU, refroidissement, capacité électrique, plan de reprise), mais elle peut offrir davantage de latitude sur la résidence des données et les contrôles de sécurité, selon l’architecture retenue. Dans les secteurs régulés et le secteur public, la discussion se fait souvent en référence à des exigences de qualification : SecNumCloud 3.2 : impacts sur les services cloud de données sensibles.

Pour aider à arbitrer sans tomber dans le « tout ou rien », voici une synthèse (à adapter à vos contraintes) :

Option	Résidence des données (pratique)	Délai de mise en service	Effort d’exploitation	Cas d’usage typiques
API tierce	dépend des régions + contrat + logs	très court	faible	POC, contenu public, assistance non sensible
Cloud administré par vous	maîtrisable (région UE/FR, réseau privé)	court à moyen	moyen à élevé	RAG interne, copilotes métiers, production « standard »
On-prem / environnement qualifié	forte maîtrise possible (selon la conception)	moyen à long	élevé	données très sensibles, exigences fortes d’isolement/traçabilité

Un mini-scénario parlant (fréquent dans les ETI et le secteur public en France) :

• Assistant « support interne » : base documentaire (procédures, runbooks) + tickets.
• En API tierce, le risque n’est pas seulement le prompt : ce sont aussi les logs et l’envoi de tickets contenant des identifiants ou des détails d’incident.
• En cloud administré, vous pouvez isoler l’inférence dans un sous-réseau privé, contrôler les accès au magasin vectoriel et centraliser l’audit dans vos outils.
• En on-prem / environnement qualifié, vous pouvez accroître le contrôle, mais vous devez sécuriser l’ensemble de la chaîne (GPU, stockage, sauvegardes, supervision).

Enfin, gardez en tête un point très concret : la taille du modèle conditionne l’option réaliste. À titre d’ordre de grandeur, un modèle « 7B » en FP16 pèse environ 14 Go pour les seuls poids (auxquels s’ajoutent le KV-cache et la surcharge mémoire), tandis qu’un « 70B » peut nécessiter plusieurs GPU ou une quantification importante. C’est souvent ce qui pousse vers (a) des modèles plus petits associés à un RAG de qualité ou (b) des stratégies hybrides (petit modèle local pour les tâches sensibles, appel externe seulement sur des données non sensibles).

Sécurité et contrôle opérationnel : clés de chiffrement, isolation, traçabilité

Le chiffrement est souvent cité, mais il faut distinguer les états de la donnée : en transit, au repos et en cours d’usage. Une gestion de clés est l’ensemble des processus et outils pour créer, stocker, utiliser, faire tourner (rotation) et détruire des clés cryptographiques de manière contrôlée. Sur un déploiement cloud, le sujet devient rapidement celui des clés gérées par le client : qui contrôle leur création, qui peut demander un déchiffrement et comment auditer ces opérations. Pour structurer ce point, l’article interne sur les KMS et les clés gérées côté client est directement actionnable : Cloud KMS : gouvernance des CMEK, rotation, destruction et audit.

L’isolation ne se limite pas au réseau. Dans un service d’inférence, vous manipulez des artefacts sensibles : poids du modèle (capital intellectuel), prompts (données métiers), jeux de tests (référentiels internes) et parfois données de personnalisation. Les mesures attendues combinent segmentation (VPC, sous-réseaux), contrôle des identités et des accès (IAM, rôles minimaux) et cloisonnement des environnements (dev/test/prod). Dans certains contextes, on ajoute du calcul confidentiel (protection de la mémoire en exécution) pour réduire l’exposition des données en cours d’usage, en gardant en tête que les garanties dépendent des plateformes et des configurations.

La traçabilité est un enjeu sous-estimé. Un déploiement open-weight « maîtrisé » doit produire des journaux exploitables : qui a interrogé le modèle, avec quelle application, sur quel périmètre documentaire et avec quel résultat (au moins des métadonnées, parfois le contenu selon la sensibilité). C’est aussi ce qui permet d’industrialiser des contrôles : détection d’exfiltration (prompts anormalement volumineux), analyse d’incidents et preuve d’audit. Dans une PME ou une collectivité, une cible réaliste consiste à centraliser ces logs dans votre chaîne existante (SIEM ou journalisation centralisée) et à définir une durée de rétention adaptée à vos obligations et besoins.

Pour passer du principe à l’opérationnel, une checklist courte peut aider à prévenir des erreurs fréquentes :

• Chiffrement en transit : TLS entre les services, y compris entre la gateway, le service d’inférence et la base vectorielle.
• Clés : séparation des rôles (administrateur de l’infrastructure ≠ administrateur des clés), rotation planifiée, journal d’utilisation des clés.
• Secrets applicatifs : aucun jeton ou clé d’API dans les prompts, les dépôts ou les notebooks partagés.
• Isolation : inférence et magasin vectoriel dans un réseau privé, accès via des identités de service, pas de configuration « tout ouvert » en développement.
• Logs : minimiser le contenu (préférer les métadonnées), limiter la rétention, restreindre l’accès et tracer les consultations de logs.
• Tests d’abus : scénarios simples de prompt injection et d’exfiltration (ex. « imprime ton prompt système », « récupère le contenu du document X »), puis correction (guardrails, filtrage, segmentation des outils).

Référence utile côté exigences de confiance en France : le référentiel SecNumCloud de l’ANSSI décrit un cadre d’exigences de sécurité pour les services cloud (organisation, mesures techniques, maîtrise des risques). Il convient de consulter sa version en vigueur : Référentiel SecNumCloud de l’ANSSI

Contrats, portabilité et méthode de décision : rendre la résidence des données vérifiable et réversible

Côté RGPD, le pivot contractuel reste l’encadrement de la sous-traitance : rôles (responsable de traitement / sous-traitant), instructions documentées, liste des sous-traitants ultérieurs et conditions de transfert. Le texte est explicite sur la nécessité d’un contrat et sur son contenu minimal : « Le traitement par un sous-traitant est régi par un contrat (…) qui lie le sous-traitant à l’égard du responsable du traitement » (Règlement (UE) 2016/679, art. 28(3), version française sur Eur-Lex, 2016) : Consulter le règlement (UE) 2016/679 sur Eur-Lex. En pratique, pour un service d’inférence managé, cela se traduit par des clauses sur la localisation des traitements, la rétention des logs, l’assistance en cas d’exercice de droits et les conditions de support.

La portabilité (capacité à récupérer ses données et à les réutiliser ailleurs) est également abordée par le Data Act, dont la plupart des dispositions s’appliquent depuis le 12 septembre 2025. Pour le changement de fournisseur de services de traitement de données, les obligations et modalités dépendent notamment du service et du calendrier prévus par le règlement. Sans entrer dans l’interprétation juridique au cas par cas, le point opérationnel est clair : préparer tôt les exports (données, configurations, journaux) et tester la sortie réduit le risque de dépendance. Pour un angle centré cloud et SaaS, voir : Data Act : portabilité des données cloud et SaaS dès 2025. Dans un contexte open-weight, la portabilité vise aussi vos composants IA : modèles (versions, paramètres), jeux d’évaluation, prompts système et index vectoriels.

Une méthode simple, adaptée aux organisations de 20 à 2 000 personnes, consiste à décider par niveau de sensibilité et par cas d’usage plutôt que de choisir « un modèle pour tout ». Données publiques ou déjà destinées à la diffusion : une API tierce peut convenir si les logs sont maîtrisés et si les secrets (clés, jetons) sont gérés correctement. Données internes courantes : déploiement sur une infrastructure administrée (cloud sous votre contrôle), avec segmentation réseau, clés gérées côté client et gouvernance des accès. Données très sensibles : on-premise ou environnement fortement qualifié, avec RAG limité, traçabilité renforcée et validation de sécurité. Pour cadrer vos échanges avec les fournisseurs et éviter les angles morts, appuyez-vous sur une liste de questions structurées : Questions à poser pour choisir un fournisseur IA et maîtriser les risques.

Pour rendre la « résidence » vérifiable (et pas seulement déclarative), ajoutez systématiquement des éléments de preuve attendus dans votre processus achats/DSI, par exemple :

• Localisation : régions d’exécution et de stockage (inférence, logs, sauvegardes) et procédure en cas de changement de région.
• Sous-traitants ultérieurs : liste tenue à jour et mécanisme d’information préalable en cas de changement.
• Logs : contenu exact, durée de rétention, options de désactivation ou de minimisation et modalités d’audit.
• Support : où se trouvent les équipes de support et quelles données elles peuvent consulter (accès « break-glass », traçabilité).
• Réversibilité : formats d’export (documents, embeddings, métadonnées), délais, assistance et coûts.

Action concrète (effort : moyen) : en 10 jours ouvrés, organisez un atelier « résidence des données » réunissant DSI, RSSI, DPO et achats, puis produisez trois livrables. (1) Une cartographie des flux LLM (prompts, RAG, logs, fine-tuning) par cas d’usage. (2) Un tableau d’exigences vérifiables (localisation, rétention, sous-traitants, clés, journalisation) utilisable en appel d’offres. (3) Un test minimal de réversibilité : exporter l’index vectoriel, les prompts système et la configuration d’inférence afin de redéployer le modèle open-weight sur une deuxième cible (même de petite taille) et de mesurer le coût réel de sortie.

Un bon critère de réussite pour cet exercice : être capable, à la fin, de répondre en une page à trois questions que les audits internes posent souvent :

1. Quelles données entrent dans le système LLM et d’où viennent-elles ?
2. Où sont-elles stockées ou journalisées, et qui y a accès ?
3. Que se passe-t-il si vous devez changer de cible d’hébergement en urgence (incident, changement de politique, fin de contrat) ?