Quand un tableau de bord Power BI affiche un indicateur calculé à partir de trois sources SaaS différentes, personne ne voit les étapes intermédiaires. Les données ont transité par un connecteur cloud, été transformées dans un modèle sémantique, parfois enrichies par une brique d’IA, puis mises en cache.
À chaque étape, des traces subsistent : logs, fichiers temporaires, copies en mémoire. Le RGPD, lui, continue de s’appliquer à chacune de ces copies, même celles qu’on ne voit jamais dans l’interface finale.
Traitements intermédiaires dans un plan BI connection : où se cachent les données personnelles
Vous avez déjà remarqué qu’un rapport Power BI met parfois quelques secondes à s’actualiser, puis s’affiche instantanément ensuite ? Ce délai révèle l’existence d’un cache. Le système stocke temporairement les résultats de requêtes pour accélérer l’affichage.
Ce cache contient souvent des données brutes, pas uniquement des agrégats. Si votre source inclut des noms, des adresses ou des identifiants utilisateur, ces informations personnelles se retrouvent dans une couche technique que la plupart des équipes métier ignorent.
Le problème ne se limite pas au cache. Un plan BI connection classique relie plusieurs sources de données : un CRM en mode SaaS, un ERP cloud, parfois un data lake sur Azure. Chaque connecteur génère ses propres logs de requêtes. Les logs de requêtes conservent des fragments de données personnelles, y compris les filtres appliqués par chaque utilisateur, ce qui peut révéler des informations sur les personnes concernées.
Un exemple concret : un commercial filtre un rapport par client, par ville, par montant de commande. Le log enregistre ces paramètres. Pris isolément, ils semblent anodins. Croisés avec d’autres informations, ils permettent de réidentifier une personne physique.
Non-réidentification des données dans un modèle BI connecté à l’IA
L’ajout de briques d’IA dans une plateforme décisionnelle complique la question de la conformité RGPD. L’EDPB a clarifié fin 2024 qu’un modèle d’IA entraîné sur des données personnelles ne peut pas être présumé anonyme par défaut. Autrement dit, pseudonymiser les données avant de les injecter dans un modèle ne suffit pas à garantir la non-réidentification.
Pourquoi ? Parce qu’un modèle d’IA peut mémoriser des patterns issus des données d’entraînement. Si votre modèle sémantique Power BI utilise un service d’IA pour enrichir des segments clients, ce service a potentiellement « appris » des corrélations qui permettraient, dans certaines conditions, de retrouver l’identité d’une personne.
Ce que la conformité exige comme preuve documentaire
Le RGPD impose de pouvoir démontrer que les mesures de protection sont effectives, pas seulement déclarées. Pour un système BI connecté à des sources SaaS et à de l’IA, cela signifie documenter trois éléments précis :
- La cartographie complète des flux de données, incluant chaque copie intermédiaire, chaque cache et chaque log généré par les connecteurs cloud et les services Microsoft Azure utilisés
- Les techniques de minimisation appliquées à chaque étape de transformation du modèle (agrégation avant stockage, suppression des identifiants directs dans les tables de faits, limitation de la rétention des logs)
- Une analyse de risque de réidentification spécifique aux sorties du modèle d’IA, tenant compte des données auxiliaires accessibles dans l’environnement de la plateforme BI
Sans cette documentation, toute affirmation de conformité reste une déclaration d’intention.
Coexistence AI Act et RGPD : ce qui change pour la sécurité des rapports décisionnels
La CNIL rappelle explicitement que l’AI Act ne remplace pas le RGPD mais s’y ajoute. Les deux cadres coexistent. Pour une équipe qui gère un plan BI connection intégrant des composants d’IA, cela crée une double exigence de gouvernance.
L’AI Act introduit des obligations spécifiques pour les systèmes d’IA à haut risque : traçabilité des données d’entraînement, justification des choix de collecte, gestion des biais dans les jeux de données. Un modèle décisionnel qui utilise de l’IA pour scorer des clients ou prédire des comportements d’achat tombe potentiellement dans cette catégorie.
En pratique, cela signifie qu’un rapport Power BI alimenté par un modèle prédictif doit répondre simultanément aux exigences RGPD (base légale, droits des personnes, minimisation) et aux exigences AI Act (qualité des données, documentation technique, surveillance post-déploiement). La gouvernance des données doit couvrir les deux cadres dans un seul processus, pas dans deux silos.
Droits RGPD des utilisateurs face aux caches et modèles BI
Le droit d’accès et le droit à l’effacement posent un problème technique concret dans un environnement BI cloud. Quand une personne exerce son droit à l’effacement, il faut supprimer ses données non seulement de la source d’origine, mais aussi de chaque copie intermédiaire.
Dans un plan BI connection typique, ces copies existent à plusieurs niveaux :
- Le dataset importé dans le service Power BI, qui conserve un snapshot des données sources
- Les caches de requêtes générés par le moteur d’analyse pour accélérer l’affichage des rapports
- Les logs d’activité utilisateur stockés par la plateforme Microsoft, qui peuvent contenir des paramètres de filtre révélateurs
- Les embeddings ou résultats intermédiaires produits par une brique d’IA connectée au modèle
Supprimer la donnée à la source ne suffit pas si les caches conservent des copies. Il faut forcer un rafraîchissement complet du dataset et vérifier que les logs antérieurs sont purgés ou anonymisés dans les délais prévus par la politique de rétention.
Automatiser la propagation des demandes d’effacement
La gestion manuelle de ces suppressions est irréaliste à l’échelle d’une plateforme décisionnelle qui connecte plusieurs dizaines de rapports à des sources multiples. La solution passe par une identification claire des flux de données dans le système, couplée à des scripts de purge qui ciblent chaque couche de stockage intermédiaire.
Le point de départ reste le registre des traitements. Si ce registre ne mentionne pas explicitement les caches BI et les logs de connecteurs comme des traitements à part entière, les demandes d’exercice de droits RGPD ne seront jamais propagées jusqu’à ces couches.
Documenter chaque point de persistance des données dans l’architecture BI n’est pas un exercice théorique. C’est la seule manière de répondre à une demande de la CNIL avec un dossier solide, où chaque flux est tracé du connecteur source jusqu’au rapport affiché à l’écran, en passant par les modèles d’IA et leurs résidus en mémoire.
