Souveraineté des données à Lyon (28/09) : 7 décisions avant de brancher une GenAI

Pourquoi cette soirée compte si tu veux faire de la GenAI sans te mettre en risque

Brancher une GenAI sur des données internes, c’est rarement “juste” connecter un chatbot à un drive. Tu ouvres des flux. Tu crées des traces. Tu délègues potentiellement des accès à des tiers. Et tu fais rentrer le RGPD, la sécurité et la conformité fournisseur dans la même pièce.

À Lyon, l’événement “Souveraineté des données : cadre, risques et solutions concrètes” (organisé par Lyon Data Science) est annoncé lundi 28 septembre 2026 à 18:30, à Epitech Lyon (source : meetup.com). Le descriptif rappelle un point utile, trop souvent zappé en comité projet : la souveraineté des données ne se réduit pas à la localisation du stockage. C’est exactement le bon prisme si tu bosses en IT, data, sécurité ou conformité.

Objectif de cet article : te donner une checklist de décisions à trancher avant la soirée, pour arriver avec des questions précises, et repartir avec de quoi avancer sur un dossier GenAI entreprise RGPD sans flou. Dans un contexte où les autorités rappellent que l’IA n’échappe pas au RGPD (CNIL) et où le cadre européen se durcit sur les modèles (Opinion 28/2024 du CEPD, AI Act).

SEO local : si tu cherches “souveraineté des données Lyon” ou “conférence Lyon Data Science”, tu es au bon endroit.

Avant de venir : 7 décisions à prendre (sinon tu vas tourner en rond)

1) Ton modèle de déploiement, et le périmètre de données autorisées

Décision à trancher tout de suite : tu pars sur quoi ?

• SaaS (outil clé en main)
• API externe (tu intègres un modèle via API)
• Modèle auto-hébergé (chez toi)
• Modèle hébergé chez un tiers “souverain” (selon ton besoin et ton risque)

Ensuite, tu poses noir sur blanc : quelles données ont le droit d’y passer. Et lesquelles sont interdites, point. La CNIL rappelle que selon les cas, il peut être nécessaire d’interdire la fourniture de certaines données confidentielles et ou personnelles dans un système d’IA générative (voir questions réponses CNIL sur l’usage d’une GenAI).

Livrable simple à préparer : une page “allowed / forbidden” par type de donnée (RH, client, contrat, R&D, support, finance).

2) Ton niveau de souveraineté attendu, et comment tu vas le prouver

Beaucoup d’équipes s’arrêtent à “hébergement en Europe”. Ce n’est pas un niveau de souveraineté, c’est un début.

Décision : tu exiges quoi, au bon niveau de risque ?

• Résidence des données dans l’UE (minimum fréquent)
• Exigences renforcées selon le contexte (secteur régulé, données sensibles, sous-traitance complexe)
• Prestataire qualifié SecNumCloud si ton analyse de risque le justifie

Point de repère opérationnel : l’ANSSI maintient des pages sur les prestataires SecNumCloud et les solutions en cours de qualification. C’est une base de diligence fournisseur, pas une incantation.

3) Ta cartographie des transferts hors UE et des accès extraterritoriaux

Décision : où passent les données, et qui peut y accéder. Pas seulement les prompts. Aussi :

• pièces jointes et documents RAG
• embeddings (vecteurs) et index
• télémétrie et analytics
• sauvegardes
• tickets support, debugging, télémaintenance

L’erreur classique : “datacenter UE” donc “OK”. Non. Ce qui compte, c’est aussi les scénarios d’accès (support, sous-traitants, maison mère, obligations légales selon la juridiction).

À préparer avant l’événement : une carte des flux (même brouillon), et une liste de “zones grises” à éclaircir.

4) Ta stratégie de journalisation : quoi loguer, combien de temps, et qui lit les logs

Une GenAI branchée sur des données internes, c’est une usine à incidents… si tu ne peux pas prouver qui a fait quoi, quand, et avec quelles données.

Décisions à trancher :

• événements à tracer : requêtes, documents consultés, exports, actions admin, appels API, changements de config
• durées de conservation par finalité (sécurité, audit, preuve, amélioration)
• séparation des rôles : qui peut consulter les logs, comment tu limites l’accès “curieux”

La CNIL rappelle que la journalisation des actions (accès, création, modification, suppression) fait partie des mesures attendues au titre du principe de sécurité (recommandation CNIL sur la journalisation).

Astuce terrain : si tes logs contiennent des prompts, ils peuvent contenir des données personnelles. Donc ils deviennent eux-mêmes un sujet RGPD.

5) Ta gestion des secrets et des clés : qui maîtrise quoi, et comment ça tourne

Décision : comment tu gères les API keys, tokens, certificats, clés de chiffrement, identités de service. Et comment tu évites qu’un “petit pilote” devienne un accès permanent et incontrôlé.

• stockage des secrets (pas dans un fichier de config, pas dans un repo)
• rotation et révocation
• clés client managed ou non (si chiffrement côté cloud)
• environnements séparés (dev, recette, prod) avec permissions distinctes

Pour cadrer ça proprement, tu peux t’appuyer sur le guide ANSSI “Recommandations de sécurité pour un système d’IA générative”, très orienté mesures concrètes (IAM, cloisonnement, secrets, durcissement).

6) Ta gouvernance des prompts et du RAG : propriété, réutilisation, fuite, qualité

Décision : tu traites les prompts comme quoi ? Un simple “texte utilisateur” ? Ou une donnée sensible (souvent, oui) parce qu’ils contiennent :

• des infos internes (process, incidents, prix, roadmaps)
• des données perso (client, salarié)
• des extraits de documents

Questions à trancher :

• est-ce que les prompts sont conservés ? où ? combien de temps ?
• est-ce qu’ils sont réutilisés (fine-tuning, amélioration du service) ? autorisé ou interdit ?
• comment tu gères les sources RAG : quels dépôts, quelles ACL, quels niveaux de classification, quels filtres ?

Point conformité : la CNIL insiste sur le fait que l’IA reste soumise au RGPD, avec des risques spécifiques, dont la mémorisation et régurgitation (recommandations CNIL sur le développement des systèmes d’IA). Donc “on anonymise vite fait” ne suffit pas toujours, et “on verra plus tard” non plus.

7) Tes clauses fournisseurs : DPA, sous-traitants, audit, support, réversibilité

Décision : tu acceptes quoi dans le contrat, et tu refuses quoi.

Checklist contractuelle minimale :

• DPA clair : rôles, finalités, instructions documentées
• liste des sous-traitants et conditions de changement
• lieux de traitement et encadrement des transferts
• support : accès aux données, conditions, traçabilité
• réversibilité : export, suppression, délais, format
• audit et preuves (certifications, rapports, attestations)

Le sujet devient encore plus concret avec l’AI Act : le règlement (UE) 2024/1689 est publié au JOUE le 12 juillet 2024 et entre en vigueur le 1er août 2024 (EUR-Lex). Et la Commission européenne indique que les obligations AI Act pour les fournisseurs de modèles GPAI sont entrées en application à l’échelle de l’UE au 1er août 2025 (digital-strategy.europa.eu). Si ton fournisseur est un acteur GPAI, tu veux comprendre ce qu’il te doit en pratique.

Pour aller plus loin côté contrat, garde une ressource sous la main : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses.

Sur place : quoi écouter (pour éviter la discussion “cloud Europe” en boucle)

Vu le thème “cadre, risques et solutions concrètes”, tu veux surtout capter du pratico-pratique, pas des slogans.

• Définition opérable de la souveraineté : quelles dimensions au-delà du stockage (accès, contrôle des clés, sous-traitants, support, logs) et comment on les mesure.
• Méthodes de cartographie des flux GenAI : prompts, embeddings, télémétrie, sauvegardes. Comment documenter sans y passer 3 mois.
• Arbitrages coût / risque : quand “API externe” suffit, quand l’auto-hébergement devient rationnel, quand un cloud qualifié fait sens.
• Mesures techniques qui changent vraiment le risque : chiffrement, clés maîtrisées, segmentation, IAM, séparation des environnements, durcissement.
• Trace et preuve : quelles attentes réalistes en audit et incident, et comment la journalisation est pensée dès le design.

En toile de fond, garde le cadre : la position du CEPD (Opinion 28/2024) souligne que l’“anonymat” s’évalue au cas par cas et qu’un entraînement sur données traitées illicitement peut avoir des conséquences. Dit autrement : si ton dossier data est fragile, ton dossier GenAI l’est aussi.

Avec quoi repartir : tes questions à poser, et les livrables à exiger en interne

Les 12 questions à poser pendant les échanges

• Flux : “Quelles données sortent vraiment de notre SI dans un setup GenAI standard, y compris logs et support ?”
• Accès : “Qui a accès, techniquement et contractuellement ? Support ? Sous-traitants ? Maison mère ?”
• Chiffrement : “Est-ce qu’on maîtrise les clés ? Qu’est-ce que ça change en incident ou réquisition ?”
• Logs : “Qu’est-ce qu’on logue exactement, et qui a le droit de lire ces logs ?”
• Durées : “Qu’est-ce qu’on conserve, combien de temps, et pourquoi ?”
• Prompts : “Les prompts sont-ils stockés ? Servent-ils à améliorer le service ? Peut-on l’interdire ?”
• RAG : “Comment éviter qu’un utilisateur récupère des documents hors de son périmètre via l’IA ?”
• Secrets : “Comment on gère la rotation des clés et les identités de service dans la durée ?”
• Incident : “À quoi ressemble un plan de réponse à incident spécifique GenAI (fuite via prompt, export massif, régurgitation) ?”
• Fournisseurs : “Quelles clauses contractuelles font vraiment la différence sur la souveraineté ?”
• Preuves : “Quelles preuves minimales vous demandez à un fournisseur (audit, qualification, annexes) ?”
• AI Act : “Qu’est-ce que vous demandez concrètement à un fournisseur GPAI depuis l’entrée en application des obligations ?”

Les 5 livrables internes à viser dès la semaine suivante

• Une politique “données autorisées” pour la GenAI (1 page, opposable).
• Une cartographie des flux (même simple) : prompts, RAG, embeddings, logs, support.
• Un standard de journalisation : événements, conservation, contrôle d’accès, revue périodique.
• Une fiche fournisseur : localisation, sous-traitants, transferts, support, chiffrement, réversibilité.
• Un mini dossier de conformité GenAI entreprise RGPD : base légale, minimisation, information, sécurité, droits, analyse de risques selon le cas.

Si tu veux cadrer proprement la partie “documentation”, garde aussi un lien utile côté Lyon IA sur le registre et la documentation : https://lyon-ia.com/blog/ai-act-documenter-vos-usages-dia-en-entreprise-registre-pret-a-copier-exemple-pme-lyon.

Raccourci utile : si tu n’as que 45 minutes avant le 28/09

Tu prends ton cas d’usage GenAI (support, RH, copilote interne, recherche documentaire), et tu réponds à ces 7 items en une phrase chacun : déploiement, données autorisées, hébergement, transferts, logs, secrets, clauses. Tu vas arriver à la conférence Lyon Data Science avec des angles clairs. Et tu vas éviter le piège du “on veut du souverain” sans définition.

Pour une version orientée “check-up rapide”, tu peux aussi lire : https://lyon-ia.com/blog/souverainete-des-donnees-a-lyon-2809-ton-check-up-cloud-ia-et-conformite-en-45-min.

Plan d’action concret avant l’événement (et ce que tu valides après)

Avant le 28/09, vise simple et exécutable :

• 1 owner côté IT/data, 1 owner côté conformité/sécurité.
• Un brouillon de cartographie des flux (même à la main).
• Une liste des 3 scénarios de déploiement possibles (pas 12).
• Un premier jet de règles prompts et RAG (ce qui est interdit, ce qui est autorisé).

Après la soirée, tu ne cherches pas “la solution parfaite”. Tu cherches une décision : quel déploiement, quel niveau d’exigence, quel fournisseur short-list, et quel paquet minimum sécurité et RGPD tu mets dans le run.

La souveraineté des données à Lyon, en 2026, ce n’est pas un débat abstrait. C’est une série d’arbitrages. Le 28/09 est une bonne date pour les trancher proprement, avant que la GenAI ne se branche toute seule dans un coin de l’entreprise.