Lyon Data Science (28/09) : cadrer la souveraineté des données avant de lancer une IA

Tu veux lancer une IA. Un copilote interne, un RAG sur ta GED, un agent branché sur ton CRM. Et tu veux aller vite. Normal. Le mur, c’est presque toujours le même. Personne n’est 100% capable de répon...

Jimmy Manin Publié le 10 octobre 2026 11 min de lecture

Lyon Data Science (28/09) : cadrer la souveraineté des données avant de lancer une IA

Tu veux lancer une IA. Un copilote interne, un RAG sur ta GED, un agent branché sur ton CRM. Et tu veux aller vite. Normal.

Le mur, c’est presque toujours le même. Personne n’est 100% capable de répondre, preuves à l’appui, à trois questions basiques : où sont les données, qui y accède, qu’est-ce que tu peux prouver en audit. Tant que ces trois points sont flous, ta “souveraineté” est un slogan. Et ton projet IA finit en POC vitrine ou en stop net côté RSSI, DPO, achats.

Le 28 septembre 2026, la communauté Lyon Data Science organise une conférence à Lyon, orientée cadre, risques et options concrètes. Si tu dois recaler une décision d’hébergement IA (France, UE, hybride, on-prem) et sortir d’un débat stérile “cloud vs souverain”, c’est typiquement le bon moment.

Rappel de l’événement (pratique, factuel)

Conférence : “Souveraineté des données : cadre, risques et solutions concrètes”
Date : lundi 28 septembre 2026
Horaires : accueil 18h30, conférence 19h00
Lieu : Epitech Lyon, 2 rue du Professeur Charles Appleton, 69007
Prix : gratuit sur inscription
Source : page Meetup Lyon Data Science (meetup.com)

La communauté affiche environ 4 600 membres sur Meetup et l’événement indique 62 participants au moment de la consultation. C’est un bon signal : tu peux t’attendre à des échanges concrets, pas juste une salle de débutants.

Qui doit y aller (et pourquoi tu les veux dans la même salle)

Objectif : éviter le classique “la data veut, la sécu bloque, le juridique temporise, la DSI arbitre à l’aveugle”. Là, tu veux aligner tout le monde sur une grille de choix commune.

DSI, architectes, responsables cloud

Tu viens pour trancher entre localisation et maîtrise. C’est rarement la même chose. Tu peux avoir des données en France et quand même être incapable d’exclure certains accès (support, KMS managé, chaîne de sous-traitance). Et tu peux avoir une infra UE bien maîtrisée mais des flux qui partent ailleurs via des outils d’observabilité.

RSSI, GRC, équipes IAM

Tu viens pour parler contrôles réels. Pas des promesses. IAM, MFA, PAM, logs, segmentation, chiffrement, gestion des clés, procédures d’incident. Et surtout : ce que tu peux démontrer quand quelqu’un demande “prouve-le”.

Responsables data et IA (CDO, Head of Data, ML/GenAI lead)

Tu viens pour relier souveraineté et architecture IA concrète : RAG, fine-tuning, vector DB, MLOps, monitoring, évaluation, logs. En pratique, la souveraineté se joue dans les détails : ce qui part dans le prompt, où se stockent les embeddings, combien de temps tu gardes les traces.

DPO, juristes, achats

Tu viens pour “bétonner” ce qui casse les projets en entreprise : rôles RGPD (responsable de traitement, sous-traitant, sous-traitants ultérieurs), transferts hors UE, droit d’audit, réversibilité, responsabilités en cas d’incident, et clauses sur l’usage des données (prompts, logs, entraînement).

Le sujet réel : souveraineté = preuves, pas drapeau

Dans les boîtes lyonnaises, le mot “souveraineté” sert souvent à désigner trois choses différentes. Mélange-les et tu pars au carton.

Localisation : où sont stockées et traitées les données (prod, sauvegardes, PRA, analytics).
Contrôle : qui peut y accéder (toi, tes prestas, le fournisseur, son support), comment, avec quelles traces.
Conformité : sur quelles bases légales, avec quelles clauses, quelles durées de conservation, quels droits des personnes.

La conférence est intéressante si elle t’aide à faire une chose : transformer “on pense que” en “on peut prouver que”.

Les points de friction qui font mal (cloud, GenAI, audit)

1) “Où sont nos données ?” Spoiler : tu n’as pas une réponse unique

Ton SI est un empilement : ERP, CRM, M365/Google, data warehouse, exports, outils métiers, prestataires, sauvegardes, environnements de test. Et maintenant tu ajoutes une brique IA.

La question utile n’est pas “on est dans le cloud ou pas”. C’est :

Où sont les données sources ?
Où vont les données dérivées (extraits, features, embeddings, index) ?
Où se trouvent les journaux (logs applicatifs, traces, observabilité) ?
Où sont les sauvegardes et le PRA ? Même pays ? Même fournisseur ?

En audit, tu ne seras pas jugé sur ton storytelling. Tu seras jugé sur ta capacité à cartographier et à justifier.

2) “Qui y accède ?” L’angle mort, c’est le support et les services managés

Tu peux verrouiller tes comptes internes. Et perdre la main sur le reste via :

le support éditeur ou cloud (accès encadré, mais accès quand même),
des sous-traitants en chaîne,
des comptes de service,
des outils d’observabilité et de sécurité qui aspirent des métadonnées.

Autre point de friction classique : la gestion des clés. La CNIL rappelle un truc que beaucoup découvrent trop tard : si tu utilises un service de gestion de clés fourni par le cloud provider, ça peut impliquer qu’il ait la capacité d’accéder aux données selon l’implémentation et les conditions d’exploitation. Ce n’est pas un détail. C’est central pour la souveraineté “réelle” et pour ce que tu peux soutenir en audit. Source : recommandations sécurité cloud CNIL (cnil.fr).

3) “On a anonymisé.” Non. Tu as peut-être réduit le risque, mais prouve-le

Côté RGPD et IA, la doctrine se précise. La CNIL a consolidé ses recommandations “IA et RGPD” et renvoie à l’avis du CEPD/EDPB du 18 décembre 2024 sur les modèles d’IA : un modèle entraîné avec des données personnelles n’est pas automatiquement anonyme. L’anonymat s’apprécie au cas par cas. Source : CNIL (cnil.fr).

Donc, si ton projet IA repose sur “t’inquiète, c’est anonymisé”, prépare-toi : l’audit va te demander comment tu qualifies les données et pourquoi (entraînement, RAG, fine-tuning, prompts, logs, monitoring). Pas juste une phrase dans un slide.

4) Les transferts hors UE : possible, mais tu dois être carré

Les transferts de données personnelles hors UE/EEE restent possibles, mais doivent être encadrés (décision d’adéquation, clauses contractuelles types, BCR, etc.). La CNIL rappelle que les SCC mises à jour le 4 juin 2021 restent la référence contractuelle standard. Source : CNIL (cnil.fr).

Dans les projets GenAI, le piège c’est que tu crois “envoyer juste du texte”. En réalité, tu envoies potentiellement :

des données (le contenu),
des métadonnées,
des logs (parfois conservés),
des éléments de contexte (fichiers, extraits, embeddings).

Si tu n’as pas une cartographie des flux et une liste des garanties de transfert, tu joues à pile ou face.

Les questions à préparer avant d’y aller (celles qui débloquent vraiment)

Va à cette conférence comme tu irais à un rendez-vous d’arbitrage. Avec des questions précises. Sinon tu rentres avec des idées, pas avec une décision.

Bloc 1 : localisation vs maîtrise (arrête de confondre)

Où sont physiquement tes données : prod, sauvegardes, PRA, analytics ?
Où transitent-elles : CDN, support, outils d’observabilité, SOC externe ?
As-tu une liste à jour des accès : humains, comptes de service, prestataires ?
Quels justificatifs tu peux sortir : logs, revues d’habilitation, MFA, PAM ?

Bloc 2 : GenAI et zones grises (là où les audits tombent)

Qu’est-ce qui part dans les prompts : données clients, RH, secrets industriels ?
As-tu des réglages “no training” et des règles de conservation des logs ?
Quels sous-traitants sont impliqués, y compris en chaîne ?
Ta doctrine “données personnelles oui/non” est-elle documentée, usage par usage, cohérente avec CNIL et CEPD ? (source CNIL : cnil.fr)

Bloc 3 : cloud et maîtrise cryptographique (le sujet qui fâche)

Qui gère les clés : toi, un tiers, le fournisseur cloud ?
Qu’est-ce que tu peux démontrer sur l’accès aux clés et aux données chiffrées ?
Quels services managés imposent de “faire confiance” au fournisseur (KMS, ETL, search, observabilité) ?
Quelles alternatives sont réalistes (techniquement et financièrement) ?

Pour le contexte, la CNIL pointe explicitement l’enjeu des services de gestion de clés et de la capacité d’accès du fournisseur. Source : CNIL sécurité cloud (cnil.fr).

Bloc 4 : sous-traitants et réversibilité (souveraineté opérationnelle)

Quels sous-traitants ont accès aux données (y compris support), dans quels pays ?
Quelles clauses encadrent les transferts (SCC, BCR, adéquation) ?
As-tu un plan de sortie : export data, portabilité, remplacement des briques IA, délais, coûts ?
As-tu déjà testé une restauration ou une migration “comme si tu devais partir” ?

Repartir avec une grille de choix actionnable (hébergement, flux, sous-traitants, risques)

Le livrable que tu vises après l’événement, ce n’est pas “on va faire du souverain”. C’est une grille de décision que tu peux poser sur la table en comité projet, puis en audit.

Étape 1 : classer tes données par criticité (simple, utilisable)

Publiques : données déjà publiques, communication.
Internes : procédures, documentation interne non sensible.
Sensibles : clients, finances, RH, contrats.
Très sensibles : santé, secrets industriels, sécurité, R&D, dossiers contentieux.

Sans ce classement, tu n’as pas de politique. Tu as des opinions.

Étape 2 : cartographier les flux IA bout en bout (pas juste “l’outil”)

Pour chaque cas d’usage, dessine le flux :

source (GED, CRM, ERP, emails),
transformation (nettoyage, extraction),
stockage (data lake, index, vector DB),
inférence (API, modèle local, service managé),
traces (logs, monitoring, évaluations),
sauvegarde et PRA.

Tu veux finir avec un schéma que la DSI, le RSSI et le DPO lisent pareil. Et que tu peux réutiliser en dossier RGPD, en revue sécurité, en appel d’offres.

Étape 3 : poser des options d’hébergement IA qui matchent tes données

Tu n’as pas “une” option. Tu en as plusieurs, selon la criticité et la tolérance au risque :

IA en SaaS (rapide) : acceptable pour données publiques ou internes bien filtrées, à condition de maîtriser prompts et logs.
Cloud en France / UE : souvent le meilleur compromis pour industrialiser, mais tu dois vérifier accès, clés, sous-traitants, réversibilité.
Hybride : données sensibles on-prem ou cloud privé, inférence sur une brique contrôlée, et services externes sur des données “dégraissées”.
On-prem / auto-hébergé : pertinent si très sensible, si contraintes fortes, ou si tu veux une maîtrise maximale. Mais tu payes en exploitation et compétences.

Le but n’est pas d’être “puriste”. Le but est d’être défendable en audit.

Étape 4 : verrouiller la chaîne de sous-traitance (sinon ta souveraineté fuit)

liste des sous-traitants et sous-traitants ultérieurs,
pays de traitement,
clauses de transfert (si hors UE),
droits d’audit et exigences de preuve,
clauses sur entraînement et conservation des données,
process de notification incident.

Oui, c’est chiant. Mais c’est là que les projets GenAI se font démonter.

Étape 5 : construire ton dossier “audit-ready” (la différence entre contrôle et panique)

Tu veux pouvoir sortir :

ta cartographie des flux,
ta qualification des données (personnelles ou non) et ton raisonnement,
tes mesures techniques (IAM, chiffrement, clés, logs, revues d’accès),
tes contrats et annexes (sous-traitance, transferts, SCC si nécessaire),
ton plan de réversibilité et tes tests.

Et tu veux que ça tienne même quand le projet change de modèle, de fournisseur, ou de mode de déploiement.

À Lyon, le vrai enjeu : arrêter la Shadow AI avant qu’elle définisse ta souveraineté

Pendant que tu “réfléchis”, les équipes testent déjà des outils. Elles collent des extraits de contrats, des tickets support, des CV, des tableaux de marge, des procédures internes.

Résultat : tu te retrouves avec une souveraineté théorique côté COMEX, et une fuite opérationnelle côté terrain.

Si tu veux cadrer ce point en parallèle, tu peux recouper avec ces lectures Lyon IA :

Mini plan de match pour le 28/09 (tu viens, tu poses, tu repars avec une décision)

Avant

Choisis un cas d’usage IA précis (pas “on veut une GenAI”).
Liste 3 types de données que l’IA va manipuler (ex : tickets support, docs qualité, mails commerciaux).
Note 2 contraintes non négociables (ex : pas de transfert hors UE, ou logs conservés 30 jours max).
Prépare une question “preuve” : qu’est-ce que je dois pouvoir montrer à un auditeur ?

Pendant

Force la discussion sur les flux complets (données, métadonnées, logs, sauvegardes).
Demande des exemples de mesures démontrables (et pas “on est certifié”).
Challenge le sujet clés et accès support.

Après

Rédige une grille de choix 1 page : options d’hébergement, risques, preuves attendues, décisions à prendre.
Ouvre un chantier “audit-ready” : cartographie, accès, logs, contrats, réversibilité.
Si tu n’as pas de doctrine prompts et logs, traite ça en priorité. C’est là que la souveraineté s’évapore.

Ce que tu dois viser en sortant

À la fin, tu veux être capable de dire, sans langue de bois :

“Nos données critiques sont ici, nos données moins critiques là.”
“Voici qui peut accéder, et voici les preuves.”
“Voici nos flux IA bout en bout, y compris logs et sous-traitants.”
“Voici notre position RGPD, documentée usage par usage.”
“Voici notre plan de sortie si le fournisseur ne convient plus.”

C’est ça, la souveraineté des données en entreprise. Pas un label. Pas une posture. Une capacité à décider, à contrôler, et à prouver.