Gouvernance, souveraineté et conformité

Introduction

Déployer un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire en local — sur des GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire on-premise ou dans un cloud dit « souverain » — répond souvent à une préoccupation de confidentialité. Mais l'auto-hébergement ne suffit pas, à lui seul, à garantir la conformité. Un modèle exécuté dans un datacenter français peut malgré tout exposer l'entreprise à des risques juridiques si les flux annexes (télémétrie, mises à jour, supervision, support éditeur) transitent par des pays tiers, ou si le traitement de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire personnelles n'a pas été correctement qualifié en amont.

Ce chapitre ne remplace pas un avis juridique. Il donne au responsable technique le vocabulaire et les points de vigilance nécessaires pour dialoguer efficacement avec le DPO, le RSSI et la direction juridique, et pour ne pas découvrir un blocage réglementaire après la mise en production.

L'auto-hébergement d'un LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire réduit certains risques (fuite vers un tiers, entraînement sur vos données) mais ne dispense d'aucune obligation RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire ni AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire. La conformité se construit en amont du projet, pas après coup.

Souveraineté numérique : de quoi parle-t-on précisément

Le terme « souveraineté » est employé de façon très large dans le marketing des offres cloud. Il recouvre en réalité plusieurs niveaux distincts :

• Souveraineté juridique : le fournisseur et l'infrastructure ne sont soumis à aucune loi extraterritoriale (CLOUD Act américain ou équivalent) permettant à une autorité étrangère d'accéder aux données hors du droit européen.
• Souveraineté opérationnelle : l'entreprise garde la capacité de changer de fournisseur, d'exporter ses données et modèles fine-tunés sans dépendance technique bloquante.
• Localisation géographique : les données et traitements restent physiquement dans un périmètre défini (UE, France), condition nécessaire mais non suffisante pour les deux points précédents.

Un cloud « localisé en France » mais opéré par une filiale d'un groupe soumis au droit extraterritorial américain ne répond pas à la souveraineté juridique, même s'il répond à la localisation géographique — une distinction que beaucoup de fournisseurs entretiennent volontairement floue.

Un GPU physiquement situé dans un datacenter européen ne garantit rien si l'éditeur du logiciel d'orchestration, le support technique ou les mises à jour du modèle impliquent des transferts de métadonnées, de logs ou de prompts vers un pays tiers. Vérifiez la chaîne complète, pas seulement la localisation du calcul.

Grille de lecture pour qualifier une offre

Transferts de données hors UE

Même avec un déploiement local, des transferts peuvent survenir indirectement : téléchargement des poids du modèle depuis un registre hors UE, télémétrie d'un outil d'orchestration, recours à un service tiers de supervision hébergé hors UE.

Le RGPD encadre ces transferts via le chapitre V (articles 44 à 50). En l'absence de décision d'adéquation, l'entreprise doit s'appuyer sur des garanties appropriées — le plus souvent des clauses contractuelles types (CCT) — et documenter une analyse des risques liés au droit du pays tiers (mesures supplémentaires post-arrêt Schrems II).

Une entreprise déploie Ollama en interne avec un modèle open source. Les poids sont téléchargés depuis Hugging Face, hébergé aux États-Unis. Ce téléchargement ne constitue pas un transfert de données personnelles (ce sont des paramètres de modèle), mais si l'outil d'orchestration envoie des logs de prompts à un service de monitoring non-UE, cela devient un transfert dès lors que ces prompts contiennent du contenu personnel. La distinction doit être vérifiée service par service.

Checklist minimale avant mise en production :

1. Cartographier tous les flux sortants (mises à jour de modèle, télémétrie, support, sauvegardes).
2. Identifier ceux qui contiennent des données à caractère personnel.
3. Pour chaque flux hors UE, vérifier une décision d'adéquation ou mettre en place des CCT.
4. Désactiver la télémétrie par défaut des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire d'inférence lorsque possible et non justifiée par un besoin métier.

RGPD : base légale et analyse d'impact

Un LLM interne qui traite des données de collaborateurs, de clients ou de candidats constitue un traitement de données personnelles au sens de l'article 4 du RGPD, dès lors que des informations identifiantes transitent par les prompts, les documents indexés (RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire) ou les sorties générées.

Déterminer la base légale

La base la plus fréquente pour un usage interne est l'intérêt légitime (art. 6.1.f) ou l'exécution du contrat (art. 6.1.b) pour les traitements liés à la relation client. Le consentement est rarement adapté en contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire professionnel car il doit être libre, ce qui est discutable pour un salarié face à un outil imposé par son employeur.

Si le LLM évalue, note ou influence des décisions concernant des collaborateurs (tri de CV, évaluation de performance), l'article 22 du RGPD sur les décisions automatisées et l'AI Act (systèmes à haut risquehaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire) s'appliquent conjointement, avec intervention humaine significative documentée.

Quand réaliser une DPIA

Une analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire (DPIA) est obligatoire lorsque le traitement engendre un risque élevé pour les personnes. Les critères qui déclenchent généralement l'obligation :

• traitement à grande échelle (base clients complète, ensemble du personnel) ;
• usage de données sensibles, même incident, par exemple si le RAG indexe des dossiers RH ;
• profilage ou évaluation de personnes ;
• croisement de sources de données multiples.

Un chatbot interne de FAQ RH sans accès à des dossiers individuels n'exige probablement pas de DPIA, mais un assistant indexant l'intégralité des dossiers du personnel franchit ce seuil. Dans le doute, engager la démarche coûte peu comparé au risque d'un traitement non conforme découvert a posteriori.

Faites réaliser la DPIA en amont du choix technique. Les mesures identifiées (anonymisation, minimisation du contexte transmis au modèle, durée de rétention des logs) doivent influencer l'architecture du RAG, pas être ajoutées en rustine sur un système déjà en production.

AI Act : provider ou deployer

Le règlement européen sur l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire (AI Act, application progressive depuis 2024) distingue deux rôles :

• Le provider développe un système d'IA, ou le fait développer, puis le met sur le marché sous sa propre marque.
• Le deployer utilise un système d'IA sous sa propre autorité, dans le cadre de son activité professionnelle.

Une entreprise qui déploie un modèle open source (Llama, Mistral, Qwen) via Ollama ou vLLM pour un usage interne est, dans l'immense majorité des cas, deployer — même si elle fine-tune le modèle, tant qu'elle ne le met pas à disposition de tiers sous sa propre marque. Si elle propose ensuite ce modèle comme produit à des clients externes, elle peut basculer côté provider pour cette diffusiondiffusionIAFamille de modèles génératifs qui synthétisent une image (ou autre signal) en dénisant progressivement un bruit.Voir dans le glossaire, avec des obligations plus lourdes (documentation technique, gestion des risques, enregistrement pour les systèmes à haut risque).

Le statut de deployer n'exonère pas d'obligations : registre d'usage, information des personnes concernées, surveillance humaine, et vérification que le provider du modèle a respecté ses obligations de transparence (fiche modèle, données d'entraînement dans la mesure du raisonnable).

Classification par niveau de risque

L'AI Act structure ses obligations selon quatre niveaux : risque inacceptable (interdit), risque élevé, risque limité (transparence), risque minimal. Un LLM d'assistance rédactionnelle interne relève généralement du risque limité ou minimal. Il bascule en risque élevé s'il intervient dans des décisions relatives à l'emploi, au crédit, à l'accès à des services essentiels, ou à l'évaluation de personnes dans un cadre réglementé. La classification doit être faite cas d'usage par cas d'usage : le même modèle peut servir un usage à risque minimal (résumé de documents) et un usage à risque élevé (présélection de candidatures).

SecNumCloud : quand est-ce pertinent

SecNumCloud est une qualification ANSSI répondant à un référentiel de sécurité renforcé, avec des exigences de protection contre les lois extraterritoriales (l'opérateur et ses actionnaires de contrôle doivent être soumis exclusivement au droit européen). Elle concerne principalement :

• les administrations, OIV et OSE soumis à des obligations réglementaires spécifiques ;
• les entreprises traitant des données sensibles (santé, défense, secrets d'affaires stratégiques) souhaitant une garantie contractuelle forte contre l'extraterritorialité.

Pour une PME déployant un LLM d'assistance interne sans données hautement sensibles, exiger SecNumCloud est souvent disproportionné : le coût et la rareté des offres qualifiées ne se justifient pas toujours face au risque réel. À l'inverse, pour un acteur de santé ou un sous-traitant de défense, la qualification devient un argument contractuel solide, voire une exigence indirecte via des donneurs d'ordre.

SecNumCloud qualifie l'infrastructure cloud, pas le modèle d'IA lui-même. Un hébergeur SecNumCloud exécutant un LLM ne garantit rien sur la qualité, les biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire ou la sécurité du modèle : sujet complémentaire mais distinct de l'évaluation du modèle.

Documentation du système : ce qu'il faut tenir à jour

Que ce soit pour un audit RGPD, un contrôle CNIL, ou un appel d'offres, une documentation vivante du système doit couvrir au minimum :

1. Fiche de traitement : finalité, base légale, catégories de données, durées de conservation, destinataires.
2. Cartographie technique : modèle utilisé, version, origine, infrastructure d'hébergement, flux entrants et sortants.
3. Analyse de risque AI Act : classification des cas d'usage, mesures de supervision humaine.
4. Registre des incidents : dysfonctionnements significatifs et actions correctives.
5. Preuves de conformité fournisseur : attestations, certifications, CCT signées.

Répartition des rôles : RSSI, DPO, métier

Un déploiement de LLM échoue rarement pour des raisons techniques pures ; il échoue souvent parce que les responsabilités n'ont pas été clarifiées entre les parties prenantes. Une répartition qui fonctionne en pratique :

• Le RSSI porte la sécurité de l'infrastructure : durcissement des serveurs d'inférence, gestion des accès aux API internes, chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire, détection d'exfiltration via les logs, plan de réponse à incident. Il valide aussi les clauses de sécurité des contrats fournisseurs GPU.
• Le DPO porte la conformité RGPD : qualification des traitements, conduite des DPIA, registre, réponse aux droits des personnes, y compris lorsque la donnée a pu être mémorisée indirectement par un modèle fine-tuné.
• Le métier porte la définition du cas d'usage et la supervision opérationnelle : validation que les réponses générées sont exploitées avec discernement, remontée des incidents, respect des procédures de supervision humaine exigées par l'AI Act.

Confier la totalité du sujet conformité à la seule DSI, sans impliquer le DPO en amont, conduit régulièrement à devoir refaire une DPIA après coup, voire à revoir l'architecture RAG pour limiter l'exposition de données sensibles. Le DPO doit être associé dès le cadrage, pas au moment de la mise en production.

Cette gouvernance à trois voix doit être formalisée, même légèrement (un comité de suivi trimestriel suffit souvent pour une PME), avec un point de contact clair pour chaque famille de décision : qui valide un nouveau cas d'usage, un changement de modèle, un changement de fournisseur.

Clauses contractuelles avec un fournisseur GPU « souverain »

L'appellation « cloud souverain » n'est pas juridiquement protégée. Avant de signer, il convient d'exiger contractuellement :

1. Localisation garantie et auditable des données au repos, en transit et des sauvegardes, avec notification en cas de changement.
2. Absence de soumission à une législation extraterritoriale de l'entité contractante et de sa chaîne de sous-traitance, support compris.
3. Engagement de non-accès aux prompts et sorties du modèle, sauf demande explicite et documentée.
4. Réversibilité contractuelle : délais d'export des données et modèles fine-tunés en cas de résiliation, formats ouverts garantis.
5. Notification d'incident dans un délai défini (idéalement 24 à 72h).
6. Liste exhaustive des sous-traitants avec obligation de notification préalable de tout changement.
7. Clause d'audit permettant de vérifier la conformité effective des engagements pris.

Une ETI industrielle négocie un contrat GPU avec un fournisseur français. Le contrat initial mentionne « hébergement en France » sans détail sur la supervision. Après relecture par le RSSI et le DPO, une clause est ajoutée précisant que l'outil de monitoring des GPU doit lui aussi être hébergé en UE, et qu'aucune donnée de promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire ne doit transiter par ce système — seules des métriques d'usage agrégées et anonymisées sont autorisées.

Synthèse

La gouvernance d'un projet LLM local ne se limite pas au choix technique de l'hébergement. Elle suppose une qualification précise des traitements (RGPD), une classification du rôle et du niveau de risque (AI Act), une décision proportionnée sur le niveau de garantie infrastructure (SecNumCloud ou non), une documentation vivante et partagée, et une répartition claire des responsabilités entre RSSI, DPO et métier. Traités en amont, ces éléments transforment un risque de blocage réglementaire en argument commercial et en facteur de confiance vis-à-vis des clients et partenaires.

Le chapitre suivant aborde la mise en œuvre opérationnelle du monitoring et de l'observabilité pour ces systèmes, qui s'appuie directement sur les exigences de traçabilité posées ici.