ENFR

Tag : Transparence

Tous les articles du blog avec ce tag.

AI Act et analytics : quand faut-il signaler une fonctionnalité IA dans un tableau de bord ?

AI Act et analytics : quand faut-il signaler une fonctionnalité IA dans un tableau de bord ?

Les outils analytics intègrent de plus en plus de fonctionnalités assistées par IA : résumé automatique d’un mois de trafic, détection d’anomalies, génération de commentaires de reporting, assistant conversationnel dans un tableau de bord, ou suggestions d’optimisation. Depuis le 2 août 2026, une partie des obligations de transparence de l’AI Act s’applique. Le sujet ne concerne donc plus seulement les grands modèles, les chatbots publics ou les plateformes grand public. Il peut aussi concerner les éditeurs de logiciels qui ajoutent des interfaces IA à des produits professionnels, selon le système et le cas d’usage. La bonne question n’est pas : « tout ce qui utilise de l’IA doit-il afficher une alerte ? ». La bonne question est : la personne interagit-elle directement avec un système d’IA, ou est-elle exposée à un contenu généré ou manipulé par IA dans un contexte visé par l’article 50 ? Cet article propose une lecture opérationnelle pour les équipes produit, marketing, analytics et conformité. Ce qui s’applique depuis le 2 août 2026 La Commission européenne a publié le 20 juillet 2026 des lignes directrices sur les obligations de transparence applicables à certains systèmes d’IA. Ces obligations commencent à s’appliquer le 2 août 2026. Elles visent notamment à permettre aux personnes de reconnaître qu’elles interagissent avec un système d’IA ou qu’un contenu a été généré ou modifié par IA. Dans les grandes lignes, les fournisseurs doivent concevoir certains systèmes pour informer les personnes lorsqu’elles interagissent directement avec une IA, et prévoir des marquages lisibles par machine pour certains contenus générés ou manipulés. Les déployeurs ont aussi des obligations d’information dans certains cas, notamment pour les deepfakes, certains contenus sur des sujets d’intérêt public sans revue humaine, et certains systèmes de reconnaissance émotionnelle ou de catégorisation biométrique. Pour un outil analytics professionnel, tout ne tombe pas mécaniquement dans le même cas. Un calcul statistique, une règle d’alerte ou un modèle de détection d’anomalies en arrière-plan ne produisent pas nécessairement la même obligation qu’un assistant conversationnel visible par l’utilisateur. Premier cas : l’assistant conversationnel intégré au dashboard C’est le cas le plus simple à analyser. Si un utilisateur peut poser une question à un assistant intégré au tableau de bord - par exemple « pourquoi le trafic a baissé cette semaine ? » - il interagit directement avec une IA. Lorsque les conditions de l’article 50 sont réunies et que le caractère IA n’est pas évident, l’interface doit informer l’utilisateur de façon claire, distincte et accessible dès le début de la première interaction qu’il dialogue avec un système d’IA, et non avec un analyste humain ou une règle métier purement déterministe. Une formulation sobre suffit souvent :Assistant IA : les réponses sont générées automatiquement à partir des données disponibles dans ce workspace. Vérifiez les conclusions importantes avant décision.La transparence ne doit pas devenir un écran anxiogène. Elle doit être claire, accessible et proportionnée. Deuxième cas : le résumé automatique d’un rapport analytics Un résumé automatique peut prendre plusieurs formes. S’il reste interne à une équipe et sert à préparer une lecture mensuelle, l’enjeu principal est la gouvernance : qui peut le générer, quelles données il utilise, s’il est relu, et comment éviter qu’il invente des causes non démontrées. S’il est publié à des clients, à un comité, à des investisseurs ou au public, l’analyse change. Le texte devient potentiellement un contenu informationnel produit à partir d’un système d’IA. Dans certains cas, notamment lorsqu’il porte sur un sujet d’intérêt public sans revue humaine ou contrôle éditorial, l’article 50 prévoit une information spécifique. Pour un éditeur analytics B2B, la règle opérationnelle peut être simple :un brouillon interne généré par IA doit être identifié comme tel dans l’interface ; un rapport externe généré automatiquement doit conserver une trace de génération ; un rapport publié sans revue humaine est à éviter lorsqu’il peut influencer une décision importante ; pour un contenu publié afin d’informer le public sur un sujet d’intérêt public, une revue humaine invoquée au titre de l’exception de l’article 50 doit être réelle et documentée.Le point critique est la réalité de la revue. Une simple validation superficielle ne doit pas être présentée comme un contrôle éditorial complet. Troisième cas : la détection d’anomalies Un système qui signale automatiquement une variation inhabituelle du trafic n’est pas toujours une interaction directe avec une IA. Il peut s’agir d’un modèle statistique, d’une règle de seuil ou d’un traitement automatisé en arrière-plan. Cela ne veut pas dire qu’il n’y a aucune obligation. Si le système utilise des données personnelles, le RGPD, la minimisation, la documentation et la gouvernance restent pertinents. Mais l’obligation de transparence de l’article 50 ne se déclenche pas simplement parce qu’un algorithme existe. La bonne pratique produit consiste à nommer honnêtement la fonctionnalité. « Anomalie détectée » est parfois plus exact que « IA a découvert un problème ». Si une explication est générée par un modèle, il faut distinguer le signal mesuré de l’interprétation générée. Exemple :Signal mesuré : baisse de 34 % des sessions organiques sur sept jours. Hypothèse générée : la baisse pourrait être liée à une variation sur trois pages d’acquisition. Statut : hypothèse à vérifier, non conclusion automatique.Cette séparation réduit les hallucinations analytiques. Quatrième cas : les recommandations automatiques Les recommandations produites par IA sont séduisantes : « améliorez cette page », « réduisez ce canal », « augmentez ce budget ». Elles sont aussi risquées si elles masquent les limites de la donnée. Dans un contexte analytics, une recommandation devrait afficher :les données utilisées ; la période analysée ; les exclusions connues ; le niveau de confiance ou au moins le degré d’incertitude ; la différence entre constat, hypothèse et recommandation.L’AI Act pose la question de la transparence vis-à-vis des personnes. La crédibilité analytics ajoute une question plus large : l’utilisateur comprend-il pourquoi la recommandation existe ? Un bon design ne se contente pas de dire « généré par IA ». Il donne les éléments nécessaires pour contester ou vérifier la recommandation. Fournisseur ou déployeur : pourquoi la distinction compte La Commission distingue les fournisseurs, qui développent ou mettent sur le marché un système d’IA, et les déployeurs, qui l’utilisent sous leur autorité dans un contexte professionnel ou organisationnel. Un éditeur SaaS qui intègre une fonctionnalité IA dans son produit peut être fournisseur de cette fonctionnalité vis-à-vis de ses clients. Une entreprise qui active cette fonctionnalité pour ses équipes peut être déployeur. Dans certains scénarios, les deux rôles coexistent. Cette distinction est importante pour les équipes produit : il ne suffit pas de supposer que le fournisseur du modèle sous-jacent porte toute la responsabilité. L’éditeur qui conçoit l’expérience utilisateur, choisit les données, affiche le résultat et définit les usages doit documenter ses propres choix. Checklist pour une fonctionnalité IA dans un outil analytics Avant de lancer une fonctionnalité IA, vérifiez :la fonctionnalité implique-t-elle une interaction directe entre l’utilisateur et un système IA ? l’utilisateur peut-il croire qu’il interagit avec une personne ou avec une analyse humaine ? le contenu généré peut-il être exporté, partagé ou publié ? une revue humaine réelle est-elle prévue avant publication externe ? l’interface indique-t-elle clairement ce qui est généré automatiquement ? le résultat sépare-t-il données mesurées, hypothèses et recommandations ? les prompts, modèles, versions et sources de données nécessaires sont-ils journalisés, avec filtrage des données personnelles, accès contrôlé et rétention définie ? les limites connues sont-elles compréhensibles par un utilisateur métier ? l’équipe support sait-elle expliquer le fonctionnement de haut niveau ? les traitements de données personnelles associés sont-ils documentés séparément ?Ce qu’il vaut mieux éviter Évitez les libellés qui rendent l’IA invisible : « analyse automatique » peut être trop vague si l’utilisateur dialogue réellement avec un système génératif. Évitez aussi l’excès inverse : un bandeau juridique lourd sur chaque graphique rend l’interface moins lisible sans améliorer forcément l’information. Évitez surtout les conclusions causales non vérifiées. Un modèle peut repérer une corrélation ou proposer une hypothèse, mais il ne doit pas inventer une cause business sans preuve. Dans un dashboard analytics, la transparence ne doit pas être seulement réglementaire. Elle doit aider l’utilisateur à décider correctement. Conclusion L’AI Act ne signifie pas que chaque fonctionnalité algorithmique d’un outil analytics doit devenir un avertissement permanent. Il impose en revanche de traiter sérieusement les situations où l’utilisateur interagit directement avec une IA ou reçoit un contenu généré dans un contexte visé par l’article 50. Pour les éditeurs SaaS, la bonne réponse n’est pas seulement juridique. C’est une discipline produit : nommer l’IA lorsqu’elle est utilisée, expliquer ses limites, journaliser ce qui compte, et séparer les faits mesurés des interprétations générées. C’est aussi une opportunité de crédibilité. Une analytics utile ne doit pas seulement produire plus de commentaires. Elle doit produire des commentaires vérifiables. FAQ Toutes les fonctionnalités automatisées d’un outil analytics sont-elles concernées ? Non. Une règle statistique, un calcul de tendance ou une alerte seuil ne devient pas automatiquement une fonctionnalité visée par les obligations de transparence de l’AI Act. Le point de départ consiste à qualifier le système et à regarder s’il interagit directement avec une personne ou génère un contenu qui doit être signalé. Faut-il afficher un bandeau pour chaque résumé généré par IA ? Pas nécessairement. Il faut surtout que l’information soit claire, compréhensible et visible au bon moment. Une mention stable dans l’interface, associée au module de résumé, peut être plus utile qu’une alerte intrusive répétée. Un rapport relu par un humain doit-il encore être marqué ? La réponse dépend du contexte, de l’usage du rapport et du niveau réel de revue éditoriale. L’article propose de documenter la chaîne de validation plutôt que de supposer que la relecture supprime toujours toute obligation. SourcesCommission européenne - Guidelines on transparency obligations for providers and deployers of AI systems Commission européenne - Transparency obligations under Article 50 of the AI Act Commission européenne - Publication des lignes directrices le 20 juillet 2026

Politique de confidentialité analytics : les formulations utiles et celles à éviter

Politique de confidentialité analytics : les formulations utiles et celles à éviter

Une politique de confidentialité peut être juridiquement dense et techniquement fausse. Le cas est fréquent : le texte affirme que « seules des données anonymes » sont utilisées, tandis que le site transmet une URL complète, un identifiant de campagne et une adresse IP à plusieurs prestataires. À l’inverse, certaines politiques listent vingt catégories abstraites sans permettre au lecteur de comprendre ce que fait réellement l’analytics. La qualité ne vient pas du nombre de paragraphes. Elle vient de l’alignement entre :la collecte déployée ; les finalités ; les rôles des acteurs ; le consentement ou l’autre cadre applicable ; les durées ; les droits ; les mots utilisés.Le RGPD exige une information concise, transparente, compréhensible et aisément accessible. Les articles 12, 13 et 14 encadrent notamment le contenu de cette information. Une politique analytics utile doit donc rester lisible tout en décrivant les éléments importants avec assez de précision. Cet article propose une méthode éditoriale et opérationnelle. Il ne fournit pas une clause universelle et ne remplace pas une validation adaptée à l’organisation. Partir de la réalité, pas d’un modèle téléchargé Avant de rédiger, rassemblez quatre sources internes :l’inventaire des outils et traceurs ; le data collection summary ; les contrats, DPA et listes de sous-traitants ; la configuration du consentement et de la rétention.La politique doit être la vue publique de faits vérifiés. Elle ne doit pas servir à deviner le fonctionnement du site. Un modèle juridique peut aider à structurer les rubriques. Il ne peut pas savoir :si vous collectez l’URL complète ou seulement le chemin ; si l’adresse IP est stockée ; si un identifiant visiteur existe ; si le fournisseur réutilise des données ; si les événements contiennent du texte libre ; si une fonctionnalité étendue est activée après consentement ; si un export part vers un entrepôt ; si plusieurs sites partagent le même identifiant.Ces réponses doivent venir de l’audit. Utiliser une information en plusieurs niveaux Une politique unique de dix pages n’est pas toujours le meilleur point d’entrée. Une approche en couches améliore la lisibilité. Niveau 1 : information au moment pertinent À proximité du choix ou de la collecte, indiquez l’essentiel :finalité ; responsable ; caractère nécessaire ou optionnel ; lien vers le détail ; moyen d’accepter, refuser ou retirer lorsque le consentement s’applique.Pour une mesure strictement limitée ne nécessitant pas de consentement dans le contexte évalué, une mention courte peut renvoyer vers la section analytics de la politique. Niveau 2 : section analytics dédiée Cette section explique :ce qui est mesuré ; pourquoi ; comment les données sont réduites ; quel fournisseur intervient ; combien de temps les informations sont conservées ; comment exercer les droits ou poser une question ; quelles fonctionnalités dépendent du consentement.Niveau 3 : documentation approfondie Une page technique, une fiche fournisseur ou une documentation de collecte peut détailler les champs et transformations. Elle ne remplace pas l’information RGPD, mais permet aux lecteurs concernés de comprendre le système sans surcharger la première couche. Les niveaux doivent raconter la même histoire. Les rubriques à couvrir 1. L’identité du responsable de traitement Indiquez l’entité qui détermine les finalités et moyens du traitement, avec ses coordonnées. Lorsque le site appartient à un groupe, ne supposez pas que la marque visible est l’entité juridique responsable. Ajoutez les coordonnées du DPO lorsqu’il existe, ou un point de contact privacy clairement identifiable. Formulation utileLe responsable du traitement des données de mesure d’audience de ce site est [entité], joignable à [adresse ou formulaire]. Pour toute question relative à la protection des données, vous pouvez contacter [DPO ou contact].À éviterNous respectons votre vie privée.Cette phrase exprime une intention mais n’identifie personne. 2. Les finalités précises Séparez les finalités au lieu de tout regrouper sous « améliorer l’expérience ». Exemples :mesurer la fréquentation et les pages consultées ; détecter les erreurs de navigation ; comprendre les sources d’acquisition ; mesurer les demandes de démonstration ; produire des statistiques agrégées ; personnaliser des contenus ; mesurer des campagnes publicitaires.Les trois dernières ne relèvent pas nécessairement du même cadre. Si une mesure minimale fonctionne par défaut et une analytics étendue après consentement, dites-le clairement. Formulation utileNous utilisons une mesure d’audience limitée pour comprendre le volume de visites, les pages consultées et les principales sources de trafic. Les fonctionnalités d’attribution enrichie et [autre fonctionnalité] ne sont activées qu’après votre choix lorsqu’elles requièrent le consentement.À éviterNous collectons des données afin d’améliorer nos services et nos offres.La finalité est trop large pour être informative. 3. Les catégories de données et signaux La politique n’a pas besoin de reproduire chaque clé technique, mais elle doit donner une vision concrète. Selon la configuration :chemin de page ; heure de visite ; domaine référent ; paramètres de campagne autorisés ; type d’appareil et de navigateur réduit ; pays ou région approximative ; événement de conversion ; identifiant pseudonyme éventuel ; adresse IP reçue temporairement ; choix de consentement.Distinguez les données directement stockées des données utilisées seulement pour produire une information agrégée. Formulation utilePour chaque visite, nous enregistrons le chemin de la page, l’heure, le domaine référent lorsqu’il est transmis, une catégorie d’appareil et les paramètres de campagne autorisés. L’adresse IP est [décrire exactement le traitement]. Nous n’envoyons pas le contenu des formulaires à l’outil analytics.À éviterNous ne collectons aucune donnée personnelle.Cette affirmation est souvent trop absolue. Une adresse IP, un identifiant ou une combinaison de signaux peut relever des données personnelles selon le traitement. 4. La base légale et le cadre des traceurs Ne mélangez pas deux questions :l’opération de stockage ou d’accès sur le terminal au titre d’ePrivacy et du droit national ; la base légale du traitement de données personnelles au titre du RGPD.La checklist sur le consentement analytics décrit cette distinction. La formulation doit refléter l’analyse réelle. Elle peut mentionner, selon le cas :consentement ; intérêt légitime, après analyse adaptée ; mesure d’audience limitée entrant dans un cadre national d’exemption sous conditions ; fonctionnalité strictement nécessaire.N’utilisez pas la base légale comme un label marketing. Expliquez aussi comment le choix est recueilli ou comment l’analyse est documentée. À éviterNotre outil est conforme à la CNIL, aucun consentement n’est donc nécessaire.La CNIL précise que l’exemption dépend de la configuration et des conditions. Elle interdit également de présenter une solution comme « certifiée » ou « validée par la CNIL » sur la base de son auto-évaluation. 5. Les destinataires et fournisseurs Identifiez les catégories de destinataires et, lorsque cela améliore la transparence, les fournisseurs principaux. Précisez les rôles :équipes internes habilitées ; prestataire analytics ; hébergeur ; support technique ; agence ; entrepôt de données.« Partenaires de confiance » n’est pas une description suffisante. Pour chaque fournisseur, vérifiez s’il agit comme sous-traitant, responsable indépendant ou dans un autre schéma. La qualification dépend des faits et du contrat. 6. Les transferts internationaux Si des données sont accessibles ou transférées hors de l’Espace économique européen, expliquez les pays ou catégories de transferts, les mécanismes invoqués et les moyens d’obtenir plus d’informations, selon ce qui s’applique. Ne confondez pas :région d’hébergement ; siège du fournisseur ; lieux d’accès du support ; sous-traitants ; transfert juridique.Évitez d’écrire « données hébergées en Europe, donc aucun transfert » sans vérifier la chaîne complète. 7. Les durées de conservation Une durée vague telle que « aussi longtemps que nécessaire » doit être complétée par des critères ou périodes concrètes. Séparez :traceur ou identifiant ; événements bruts ; rapports agrégés ; logs de sécurité ; sauvegardes ; exports.Formulation utileLes événements analytics sont conservés pendant [durée]. Les statistiques agrégées sont conservées pendant [durée ou critère]. Les journaux techniques suivent une durée distincte de [durée]. Les exports manuels sont supprimés selon [procédure].Pour une mesure relevant du cadre français décrit par la CNIL, les recommandations de treize mois pour la durée de vie de certains traceurs et de vingt-cinq mois pour les informations collectées sont des repères à examiner. Elles ne doivent pas être copiées si votre configuration utilise une autre durée sans justification. 8. Les droits et moyens d’exercice Expliquez les droits applicables et fournissez un moyen simple de contact. Selon la base et le traitement, les droits peuvent inclure accès, rectification, effacement, limitation, opposition ou portabilité. Une analytics réellement anonyme peut ne pas permettre d’identifier une personne pour répondre à une demande individuelle. Dites-le avec précision, sans utiliser l’anonymat comme formule de dispense générale. Indiquez aussi la possibilité d’introduire une réclamation auprès de l’autorité de contrôle compétente. 9. Le retrait du consentement ou l’opposition Lorsque le consentement s’applique, fournissez un contrôle accessible pour le retirer aussi facilement qu’il a été donné, selon les règles applicables. Lorsque le traitement repose sur une autre base et qu’un droit d’opposition s’applique, expliquez la procédure. Le lien « gérer mes cookies » doit fonctionner sur mobile, rester visible et mettre à jour le comportement réel des tags. 10. La date et les changements Ajoutez une date de dernière mise à jour et un processus pour les modifications importantes. La politique doit être revue lorsqu’une équipe :ajoute un outil ; active une nouvelle finalité ; modifie un identifiant ; change la rétention ; ajoute un export ; change de fournisseur ; ouvre une propriété dans un nouveau pays ; modifie le consentement.Un historique concis des changements significatifs peut aider les lecteurs réguliers. Un exemple de section courte à adapter Le texte suivant est un squelette éditorial, pas une clause prête à publier.Mesure d’audience Nous utilisons [outil] afin de mesurer la fréquentation du site, les pages consultées et les principales sources de visite. Cette mesure nous aide à détecter les problèmes de navigation et à évaluer l’utilité de nos contenus. Selon notre configuration, les données traitées comprennent [liste concrète]. [Décrire le traitement de l’adresse IP et des identifiants]. Le contenu des formulaires et les paramètres d’URL non autorisés ne sont pas envoyés. [Fournisseur] intervient en qualité de [rôle] et traite les données dans [lieux et transferts pertinents]. Les données sont conservées pendant [durées par couche]. [Expliquer le cadre ePrivacy et la base RGPD retenus, avec les conditions et le fonctionnement du consentement le cas échéant]. Vous pouvez exercer vos droits ou poser une question à [contact]. Vous pouvez [retirer votre consentement / exercer votre opposition] via [moyen].Chaque crochet exige une réponse vérifiée. Les formulations qui fragilisent la crédibilité « Données totalement anonymes » Utilisez cette expression uniquement si l’équipe peut expliquer la méthode et démontrer que les données ne permettent plus raisonnablement d’identifier ou d’individualiser une personne. Sinon, préférez :données agrégées ; identifiants supprimés ; données pseudonymisées ; granularité réduite ; adresse IP non conservée dans les événements.Ces termes ne sont pas interchangeables. « Aucune donnée n’est partagée » Si un prestataire héberge ou traite la collecte, il reçoit des données en tant qu’acteur du traitement. La bonne phrase peut être « aucune donnée n’est vendue » ou « les données ne sont pas utilisées à des fins publicitaires », si c’est exact, mais pas « aucun partage » par réflexe. « Conforme au RGPD » Une conformité dépend du traitement, du responsable, de la configuration, du contrat et des opérations. Présentez les mesures concrètes plutôt qu’un verdict global. « Cookies nécessaires » Expliquez nécessaires à quoi. Un tracker publicitaire n’est pas nécessaire parce que l’équipe marketing le juge utile. « Nous pouvons modifier cette politique à tout moment » Cette clause n’explique ni l’information des personnes ni la gestion des changements significatifs. Ajoutez une date et un mécanisme raisonnable de notification lorsque nécessaire. Aligner la politique avec le produit Une incohérence apparaît souvent lorsqu’une équipe édite la politique une fois par an, alors que la stack change chaque semaine. Intégrez un contrôle dans le cycle de livraison :toute demande de nouveau tag indique finalité, données et fournisseur ; le propriétaire privacy ou analytics examine l’impact ; le data collection summary est mis à jour ; la politique et la CMP sont modifiées si nécessaire ; le déploiement est testé ; la preuve est conservée.Pour les paramètres d’URL, appliquez l’allowlist de collecte avant que le texte ne promette une collecte réduite. Audit éditorial en douze questions Relisez la section analytics et demandez :le responsable est-il identifiable ? les finalités sont-elles séparées ? les données sont-elles décrites concrètement ? la réception temporaire est-elle distinguée du stockage ? la base RGPD est-elle indiquée ? le régime des traceurs est-il expliqué sans raccourci ? les fournisseurs et rôles sont-ils clairs ? les transferts ont-ils été vérifiés ? les durées sont-elles concrètes ? les droits et moyens d’exercice sont-ils accessibles ? le retrait ou l’opposition fonctionne-t-il ? le texte correspond-il au réseau et à la configuration actuels ?Une réponse négative déclenche une correction de la stack ou du texte. Parfois des deux. Conclusion Une bonne politique de confidentialité analytics ne cherche pas à rassurer par des adjectifs. Elle donne des faits compréhensibles. Elle explique qui mesure, pourquoi, avec quels signaux, pour combien de temps, avec quels prestataires, sous quel cadre et avec quels contrôles pour les personnes. Le meilleur processus consiste à partir de l’inventaire technique, à rédiger en couches, à faire valider les qualifications nécessaires et à lier toute évolution de la stack à une mise à jour documentaire. La transparence n’est pas un exercice séparé du produit. C’est la description publique de sa gouvernance. FAQ Faut-il citer le nom de l’outil analytics dans la politique ? Le RGPD impose notamment d’informer sur les destinataires ou catégories de destinataires. Citer le fournisseur principal améliore souvent la clarté, mais la forme exacte dépend du traitement et de la structure de la notice. Peut-on écrire que les données sont anonymes ? Seulement si l’anonymisation est réellement démontrée. Une donnée pseudonymisée, agrégée ou privée d’adresse IP n’est pas automatiquement anonyme. La politique remplace-t-elle la bannière de consentement ? Non. La politique fournit l’information détaillée. Lorsqu’un consentement préalable est requis, le mécanisme doit permettre un choix valable avant le déclenchement des traceurs concernés. Faut-il lister chaque événement analytics ? Pas nécessairement dans la première couche. Décrivez des catégories concrètes et rendez une documentation plus détaillée accessible si elle est utile. Les événements sensibles ou inattendus doivent être explicitement analysés. Que faire lorsqu’un fournisseur change ses sous-traitants ? Évaluer l’impact sur les destinataires, transferts, contrats et risques, puis mettre à jour la documentation et l’information lorsque nécessaire. SourcesRèglement (UE) 2016/679, articles 12, 13 et 14 CNIL, RGPD : exemples de mentions d’information CNIL, Informer les personnes CNIL, Cookies : solutions pour les outils de mesure d’audience CEPD, Lignes directrices sur la transparence au sens du règlement 2016/679