Pourquoi une contrainte réglementaire oriente-t-elle le choix d'un modèle de langage ?
Une contrainte réglementaire oriente le choix d'un modèle de langage parce qu'elle ne porte pas sur le modèle en tant que tel, mais sur les données qu'il traite et sur l'endroit où ce traitement a lieu. Or un modèle de langage traite précisément des données, souvent sensibles, et son inférence, c'est-à-dire la production de chaque réponse, s'exécute quelque part, sous une juridiction donnée. La règle qui encadre la donnée encadre donc, par ricochet, l'architecture du modèle.
C'est ce ricochet qui pousse vers le souverain. Un petit modèle de langage (SLM, small language model), modèle compact de 3 à 20 milliards de paramètres dans le vocabulaire retenu sur ce site, se déploie sur une infrastructure maîtrisée, ce qui permet d'exécuter le traitement là où la règle l'exige. Un service d'IA générique distant, à l'inverse, fait sortir les données de ce périmètre, ce qui expose à un écart réglementaire.
En quoi le RGPD pousse-t-il vers un petit modèle de langage souverain ?
Le RGPD, Règlement général sur la protection des données, applicable dans l'Union européenne, pousse vers un petit modèle de langage souverain parce qu'il encadre le traitement des données à caractère personnel, leur localisation et leur transfert hors de l'Union. Faire traiter des données personnelles par un service distant soulève la question du sous-traitant, du lieu de traitement et du transfert international, autant de points que le règlement encadre.
Un modèle compact déployé sur une infrastructure maîtrisée répond à ces points en gardant le traitement dans un périmètre connu. Les données restent dans l'environnement de l'organisation, l'inférence s'exécute dans une juridiction choisie, et la question du transfert hors de l'Union ne se pose plus dans les mêmes termes. Le souverain n'est pas ici un supplément, mais une manière directe de rester dans le cadre.
En quoi NIS2 contraint-elle le choix d'un modèle de langage ?
NIS2, la directive (UE) 2022/2555 sur la cybersécurité des réseaux et des systèmes d'information, à transposer au droit du marché visé, contraint le choix d'un modèle de langage par ses exigences de sécurité et de maîtrise de la chaîne d'approvisionnement numérique. Elle vise les entités jugées essentielles ou importantes, et étend leur responsabilité aux prestataires qu'elles emploient, dont les services d'IA.
Cette responsabilité sur la chaîne d'approvisionnement joue en faveur du souverain. Un modèle exécuté sur une infrastructure maîtrisée réduit la surface de dépendance à des tiers difficiles à auditer, et rend contrôlables l'accès et la localisation du traitement. Un petit modèle déployé sur site ou sur cloud privé s'inscrit dans cette logique de maîtrise, là où un service distant ajoute un maillon à sécuriser et à justifier.
En quoi DORA contraint-elle le déploiement d'un modèle de langage ?
DORA, le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier, applicable dans l'Union européenne, contraint le déploiement d'un modèle de langage par ses exigences sur le risque lié aux prestataires de services informatiques. Le secteur financier doit maîtriser ses dépendances numériques, documenter ses prestataires critiques et assurer la continuité de ses traitements.
Un modèle de langage entrant dans un processus financier devient l'un de ces maillons. Le déployer sur une infrastructure maîtrisée facilite la démonstration de résilience, la localisation du traitement et la réversibilité, quand un service distant concentre le risque sur un prestataire externe. Un petit modèle souverain, exécuté dans une juridiction choisie, s'accorde avec l'exigence de maîtrise du risque numérique portée par le règlement.
En quoi la certification HDS impose-t-elle un déploiement souverain ?
La certification HDS, hébergement de données de santé, prévue en droit français par l'article L. 1111-8 du Code de la santé publique, impose des exigences sur l'hébergement des données de santé à caractère personnel. Un traitement de ces données par un modèle de langage suppose que l'hébergement sous-jacent réponde à ce cadre, ce qu'un service distant non certifié ne garantit pas.
Le déploiement souverain répond directement à cette exigence. Un petit modèle compact exécuté sur une infrastructure certifiée pour l'hébergement de données de santé maintient le traitement dans le périmètre attendu, sans export vers un tiers hors cadre. La contrainte de santé illustre le principe général : la règle sur la donnée commande l'architecture du modèle.
Comment chaque contrainte oriente-t-elle le mode de déploiement ?
Chaque contrainte réglementaire oriente le mode de déploiement selon l'exigence qu'elle porte sur le traitement. Le tableau ci-dessous relie la contrainte, ce qu'elle exige du traitement, et le mode de déploiement adapté, parmi le mode partagé, le cloud privé et le déploiement sur site.
| Contrainte | Ce qu'elle exige du traitement | Mode de déploiement adapté |
|---|---|---|
| RGPD (applicable dans l'UE) | localisation et maîtrise des données personnelles | cloud privé ou sur site, juridiction choisie |
| NIS2 (à transposer au droit visé) | maîtrise de la chaîne d'approvisionnement et de la sécurité | sur site ou cloud privé, accès contrôlé |
| DORA (applicable dans l'UE) | maîtrise du risque prestataire et résilience | cloud privé ou sur site, réversibilité documentée |
| HDS (droit français, L. 1111-8 CSP) | hébergement certifié des données de santé | infrastructure certifiée, traitement local |
La concession qui clarifie tout : quand la donnée sort de tout périmètre réglementé
Une donnée sort de tout périmètre réglementé quand elle n'entre dans le champ d'aucun texte applicable : une information déjà publique, une donnée agrégée sans caractère personnel, un contenu sans valeur de conformité. Sur ce terrain, un service d'IA générique distant traite la demande sans exposer l'organisation à un écart, puisqu'il n'y a pas de règle à tenir.
Situer cette zone est ce qui donne son poids à la contrainte ailleurs. Le partage se lit à l'entrée d'un régime : dès qu'une donnée relève du RGPD, de NIS2, de DORA ou de la certification HDS, la question n'est plus la commodité mais la démonstration de conformité, et la localisation maîtrisée du traitement devient une obligation, pas une préférence.
Comment vérifier l'alignement d'un modèle de langage sur ces contraintes ?
Vérifier l'alignement d'un modèle de langage sur ces contraintes suppose de partir de la donnée, pas du modèle. Les critères ci-dessous se lisent dans l'ordre.
- Qualifier la donnée traitée. Personnelle, sensible, de santé, financière : la nature de la donnée fixe le cadre applicable.
- Identifier les cadres en jeu. RGPD, NIS2, DORA, HDS ou un autre régime selon le secteur et la juridiction du traitement.
- Localiser l'inférence. Établir où et sous quel droit le calcul s'exécute, et vérifier la cohérence avec le cadre.
- Contrôler la chaîne de prestataires. Documenter les tiers impliqués et leur maîtrise, exigence commune à NIS2 et DORA.
- Prévoir la preuve et la revue. Conserver de quoi démontrer l'alignement, et réviser à chaque évolution du cadre ou de l'architecture.
Sur la plateforme Optivalue.ai, qui édite ce site, l'hébergement est possible dans plus de 80 pays, dans la juridiction choisie.
Questions fréquentes
Un petit modèle de langage hébergé sur site est-il conforme au RGPD ?
Un petit modèle hébergé sur site facilite la conformité au RGPD, car il garde le traitement des données personnelles dans un périmètre maîtrisé et une juridiction choisie. La conformité ne découle pas du seul hébergement : elle suppose aussi les bases légales, la minimisation et les droits des personnes, qui relèvent de l'organisation.
NIS2 et DORA imposent-elles un modèle souverain ?
NIS2 et DORA n'imposent pas nommément un modèle souverain, mais leurs exigences de maîtrise de la chaîne d'approvisionnement et du risque prestataire orientent vers une infrastructure maîtrisée. Un modèle souverain facilite la démonstration de cette maîtrise, sans être l'unique voie de conformité.
La certification HDS concerne-t-elle le modèle ou l'hébergement ?
La certification HDS concerne l'hébergement des données de santé, donc l'infrastructure sous-jacente au modèle, pas le modèle lui-même. Un traitement de données de santé par un modèle de langage suppose que cet hébergement soit certifié, ce qu'un déploiement sur infrastructure adaptée permet d'assurer.
Ces contraintes s'appliquent-elles hors de l'Union européenne ?
Le RGPD et DORA sont des textes de l'Union européenne, applicables dans l'Union ; NIS2 est une directive à transposer au droit de chaque marché visé ; la certification HDS relève du droit français. Sur un marché hors de l'Union, il faut identifier les équivalents locaux, car un texte cité vaut pour sa seule juridiction.
La contrainte réglementaire suffit-elle à choisir un petit modèle plutôt qu'un grand modèle ?
La contrainte réglementaire pousse vers un traitement maîtrisé et localisé, ce qu'un petit modèle compact facilite par son déploiement sur site. Le choix entre petit et grand modèle dépend aussi de la tâche et des ressources ; la conformité fixe le cadre du déploiement, pas à elle seule la taille du modèle.