Pendant l'essentiel de la dernière décennie, être conforme au RGPD signifiait maîtriser les fondamentaux : une base légale documentée, un registre des activités de traitement bien tenu, un bandeau cookies qui fonctionnait réellement, une procédure de notification de violation que personne n'avait à improviser dans l'urgence. Les entreprises qui avaient investi dans ces fondamentaux pouvaient raisonnablement se considérer conformes. En 2026, cela ne suffit plus. L'intelligence artificielle est devenue la première source de risque RGPD, et les régulateurs européens montrent — par des lignes directrices, des enquêtes et des mesures d'application — que les systèmes d'IA ne bénéficient d'aucune dérogation aux principes qui encadrent la protection des données depuis 2018. Si tant est qu'elle change quelque chose, l'IA fait monter les enjeux, car ces systèmes peuvent générer, à partir de données personnelles, de nouveaux résultats préjudiciables d'une manière que les rédacteurs initiaux du règlement n'avaient pas eu à anticiper.

Le RGPD a été rédigé pour être neutre sur le plan technologique, et en principe ses obligations fondamentales s'appliquent autant à un modèle d'apprentissage automatique qu'à un tableur de données clients. En pratique, l'IA complique presque toutes ces obligations. Les données d'entraînement sont souvent collectées à grande échelle, parfois par scraping de sources publiques, et rarement réunies avec une finalité précise et documentée en tête — ce qui s'accorde mal avec la limitation des finalités et la minimisation des données. Les modèles peuvent mémoriser puis reproduire des données personnelles d'une manière que personne ne peut pleinement prévoir ni contrôler. Et une fois déployé, un modèle peut, par ses résultats — recommandations, classifications, images ou textes générés — constituer lui-même un nouveau traitement de données personnelles, porteur de nouveaux risques. Les régulateurs ne traitent pas l'IA comme une question à part ; ils la traitent comme une extension des obligations RGPD existantes, appliquées avec une rigueur particulière. Trois exigences en particulier sont désormais au cœur de l'activité de contrôle : les analyses d'intérêt légitime pour les données d'entraînement, les analyses d'impact obligatoires pour le traitement biométrique, et la preuve que les données d'entraînement ont d'abord été obtenues licitement.

L'intérêt légitime n'est pas un blanc-seing

De nombreuses organisations qui construisent ou affinent des modèles d'IA se sont appuyées sur « l'intérêt légitime » comme base légale pour utiliser des données personnelles dans l'entraînement, en particulier lorsque recueillir le consentement individuel de chaque personne concernée serait impraticable. Les régulateurs n'ont pas rejeté cette approche en bloc — mais ils ont clairement indiqué qu'elle ne constitue pas une justification générale. Elle exige une analyse documentée et défendable.

Une analyse d'intérêt légitime correcte pour des données d'entraînement d'IA doit établir trois choses : que l'intérêt poursuivi est réel et licite, que le traitement est nécessaire pour l'atteindre (sans alternative moins intrusive disponible), et que cet intérêt n'est pas supplanté par les droits et libertés des personnes dont les données sont utilisées. Pour l'IA en particulier, cela signifie pouvoir démontrer pourquoi un jeu de données donné était nécessaire, pourquoi l'anonymisation ou les données synthétiques n'étaient pas des alternatives viables, et quelles garanties limitent l'impact sur les personnes. Les organisations incapables de produire cette documentation lorsqu'on la leur demande se retrouvent de plus en plus souvent dans le viseur d'une enquête. Nous avons détaillé à quel point ce test s'est durci dans notre analyse des nouvelles lignes directrices du CEPD sur le web scraping — les jeux de données anciens n'échappent pas aux règles simplement parce que celles-ci n'existaient pas au moment de leur collecte.

Traitement biométrique et obligation d'AIPD

Les données biométriques — reconnaissance faciale, empreintes vocales, analyse de la démarche et identifiants similaires — relèvent d'une catégorie particulière de données personnelles au sens du RGPD, et l'IA a rendu le traitement biométrique bien plus courant et bien plus puissant. Les systèmes de reconnaissance faciale, les outils de détection d'émotions et les technologies de clonage vocal reposent tous sur le traitement à grande échelle de cette catégorie de données.

En raison du risque accru, une analyse d'impact relative à la protection des données (AIPD) n'est pas optionnelle pour ces systèmes — elle est obligatoire avant le début du traitement. Une AIPD doit décrire les opérations de traitement et leurs finalités, évaluer si le traitement est nécessaire et proportionné, identifier les risques pour les personnes, et exposer les mesures prises pour y répondre. Pour l'IA biométrique, cette analyse doit affronter honnêtement des questions qu'il est facile d'esquiver dans la précipitation d'un lancement : quelle est la précision du système selon les différents groupes démographiques ? Que se passe-t-il en cas d'erreur d'identification ? Les personnes peuvent-elles refuser, et quelle alternative leur est-elle proposée si elles le font ? Les régulateurs demandent de plus en plus ces analyses comme première étape de toute enquête sur un déploiement d'IA biométrique — et leur absence est traitée comme un manquement de conformité significatif en soi, indépendamment de ce que fait réellement le système sous-jacent.

17 févr. 2026
L'autorité irlandaise de protection des données ouvre une enquête RGPD formelle contre X pour les deepfakes de Grok
4 %
Du chiffre d'affaires annuel mondial — l'amende RGPD maximale encourue dans cette enquête
0
Période de grâce pour une IA biométrique déployée sans AIPD
6
Pratiques qui distinguent les entreprises préparées de celles exposées

Origine licite des données d'entraînement

Le troisième pilier du risque RGPD spécifique à l'IA est plus basique, mais sans doute plus difficile à corriger après coup : les données d'entraînement ont-elles été licitement obtenues au départ ? Les grands modèles de langage et les générateurs d'images sont fréquemment entraînés sur des données collectées par scraping du web ouvert, sur des jeux de données sous licence, ou sur des archives d'entreprise historiques collectées à des fins totalement différentes. Chaque source pose ses propres questions de conformité. Les données scrapées ont pu être collectées sans aucune base légale pour le scraping lui-même, sans même parler de sa réaffectation à l'entraînement de l'IA. Les jeux de données sous licence n'ont peut-être pas été collectés avec un consentement suffisamment éclairé pour justifier un usage ultérieur en IA. Et des archives internes réunies il y a des années pour une finalité commerciale précise peuvent aujourd'hui ne plus disposer d'une base valable pour être réaffectées en jeu d'entraînement.

C'est un problème difficile à corriger rétroactivement — un modèle déjà entraîné sur des données obtenues illicitement ne peut pas simplement voir ces données « retirées » comme on supprimerait un enregistrement de base de données. C'est précisément pourquoi les régulateurs poussent les organisations à documenter la provenance des données avant le début de l'entraînement, et non après réception d'une plainte : une traçabilité claire montrant d'où vient chaque jeu de données, quelle base légale s'appliquait à sa collecte, et si cette base couvre également son usage pour l'entraînement de l'IA.

💬
Produit GDPRGard
Un outil d'IA conçu pour répondre aux questions des régulateurs

GDPRChat fonctionne avec les FAQ, politiques et informations produit de votre propre entreprise — jamais avec des données tierces collectées par scraping ni avec les conversations de vos clients. Quand on vous demande quelles données l'ont entraîné et sur quelle base légale, vous avez une réponse documentée, pas une esquive.

Découvrir GDPRChat →

Quand les sorties de l'IA deviennent elles-mêmes l'infraction

Le changement peut-être le plus important dans l'application du RGPD en 2026 est la reconnaissance que les infractions peuvent naître non seulement de la façon dont les données personnelles sont collectées ou utilisées pour entraîner un modèle, mais aussi de ce que produit un modèle déjà déployé. Ce n'est pas une hypothèse d'école. Le 17 février 2026, la Commission irlandaise de protection des données — qui dirige l'application du RGPD à l'égard de X en raison du siège européen de l'entreprise à Dublin — a ouvert une enquête statutaire formelle sur le chatbot Grok de la plateforme, après des signalements selon lesquels des utilisateurs lui demandaient de générer des images truquées, sexualisées et non consenties de personnes réelles, y compris, selon certains signalements, d'enfants.

L'enquête examine si X a traité licitement les données des utilisateurs de l'UE et de l'EEE en déployant les outils de génération d'images de Grok, si des garanties appropriées étaient en place, et si les risques de détournement avaient été correctement évalués avant le lancement. La théorie juridique sous-jacente est significative : utiliser la photographie d'une personne réelle comme base pour générer une image synthétique sexualisée ou autrement préjudiciable peut constituer en soi un traitement illicite des données personnelles de cette personne — indépendamment de toute infraction pénale ou violation des règles de la plateforme distincte qui pourrait aussi exister. Autrement dit, le préjudice ne survient pas seulement en amont, dans la façon dont les données d'entraînement ont été collectées. Il peut aussi survenir en aval, au moment même de la génération, dans ce que le système déployé fait de l'image d'une personne. X a restreint la génération d'images de Grok aux abonnés payants après ces signalements, mais l'enquête — qui expose à des amendes potentielles pouvant atteindre 4 % du chiffre d'affaires annuel mondial de X — se poursuit malgré tout.

Pour toute organisation qui construit ou déploie de l'IA générative, c'est une distinction essentielle. Les garanties ne peuvent pas s'arrêter au pipeline d'entraînement ; elles doivent aussi couvrir ce que le modèle est capable de produire au moment de l'inférence, et ce qui se passe lorsqu'un utilisateur cherche délibérément à en détourner l'usage.

Six bonnes pratiques pour anticiper le risque

À travers les lignes directrices réglementaires, les mesures d'application et les analyses sectorielles, six pratiques distinguent constamment les organisations qui gèrent bien le risque RGPD lié à l'IA de celles qui restent exposées.

  1. Intégrer la protection de la vie privée dès le départ, pas après coup. La protection de la vie privée dès la conception est une obligation du RGPD, pas une suggestion — pour l'IA, cela signifie des revues de confidentialité dès la sélection du jeu de données et la conception de l'architecture du modèle, pas seulement avant la mise en production.
  2. Cartographier réellement le parcours des données personnelles dans le système. De l'ingestion, à l'entraînement ou l'affinage, jusqu'à l'inférence et la sortie. Sans cette cartographie, la plupart des organisations ne peuvent pas répondre à la question de base d'un régulateur : où sont passées les données de cette personne, et qu'en a-t-on fait ?
  3. Documenter une finalité précise pour chaque activité de traitement. « Améliorer nos modèles d'IA » n'est pas assez précis. Les régulateurs attendent une finalité déclarée pour un jeu de données donné, avec un usage limité à cette finalité.
  4. Traiter les AIPD comme un point de passage obligé, pas une formalité. En particulier pour les systèmes biométriques, le profilage à grande échelle et les décisions automatisées ayant des effets juridiques ou significatifs similaires — achever l'analyse avant que les décisions de déploiement ne soient figées, pas après.
  5. Être capable d'expliquer la décision, pas seulement qu'une décision a été prise. Le RGPD confère aux personnes des droits réels face à la prise de décision automatisée. Les organisations doivent de plus en plus pouvoir expliquer, en langage clair, comment un système est parvenu à une décision qui affecte quelqu'un.
  6. Surveiller en continu, pas une fois par an. Les systèmes d'IA dérivent, sont détournés d'une manière que leurs concepteurs n'avaient pas anticipée, ou produisent des résultats préjudiciables qui n'apparaissent qu'une fois déployés à grande échelle — comme l'illustre l'enquête sur Grok. Un contrôle de conformité annuel est bien trop rare pour repérer cela avant que cela ne devienne un incident réglementaire.

L'IA ne va pas devenir moins centrale dans la façon dont les organisations traitent les données personnelles, et les régulateurs ne vont pas devenir moins attentifs à son usage. Les organisations qui s'en sortent bien sont celles qui traitent la conformité RGPD comme une discipline d'ingénierie et de gouvernance continue, intégrée aux systèmes d'IA dès le départ — pas comme une liste de contrôle juridique appliquée après coup. Les régulateurs ont désormais montré qu'ils agiraient non seulement contre la façon dont les données sont collectées pour l'entraînement, mais aussi contre ce que les systèmes déployés génèrent réellement. Ce changement d'état d'esprit n'est plus optionnel.

Réservez une consultation gratuite avec GDPRGard →

Sources

À lire également :

Partager cet article
⚠️ Cet article est fourni à titre purement informatif et ne constitue pas un conseil juridique. Pour les situations de conformité complexes, consultez un professionnel qualifié de la protection des données. Les exigences du RGPD et de l'AI Act européen font l'objet d'orientations réglementaires continues — vérifiez vos obligations actuelles avec votre conseiller juridique.