Le RGPD n’interdit pas l’usage de l’intelligence artificielle. Il encadre le traitement de données à caractère personnel, quel que soit l’outil employé. Lorsqu’une IA reçoit, analyse ou produit des informations relatives à des personnes identifiées ou identifiables, ce traitement entre dans le champ du règlement et doit en respecter les principes. La difficulté pratique n’est pas de savoir si le RGPD s’applique (il s’applique presque toujours), mais d’identifier ce qui est licite et ce qui ne l’est pas.
Une base légale est nécessaire, avant tout traitement
Tout traitement de données personnelles suppose une base légale identifiée en amont. Le règlement en prévoit plusieurs : le consentement de la personne, l’exécution d’un contrat, le respect d’une obligation légale, l’intérêt légitime du responsable de traitement, entre autres. Le recours à une IA ne crée pas une base nouvelle. Si l’on souhaite faire analyser des dossiers clients ou des courriels par un modèle, il faut pouvoir rattacher cet usage à l’une de ces bases, et vérifier qu’il reste compatible avec la finalité initiale pour laquelle les données ont été collectées.
Le principe de limitation des finalités est ici central. Des données collectées pour gérer une relation commerciale ne peuvent pas être réutilisées librement pour entraîner ou alimenter un système d’IA si cette finalité n’était ni prévue ni compatible. La réutilisation se justifie, elle ne se présume pas.
Minimisation : ne traiter que le nécessaire
Le principe de minimisation impose de limiter les données traitées à ce qui est strictement nécessaire à la finalité poursuivie. Appliqué à l’IA, il invite à une question simple et souvent éludée : le modèle a-t-il besoin de connaître l’identité réelle des personnes pour produire le résultat attendu ? Dans de nombreux cas, la réponse est non. Synthétiser un document, classer une demande, rédiger une réponse type ne requiert pas, en soi, de transmettre le nom, l’adresse ou le numéro de dossier d’un individu.
Cette observation a une conséquence pratique : plus on réduit les données personnelles réellement exposées au traitement, plus on se rapproche du standard attendu par le règlement, et plus on réduit l’exposition au risque.
Les données de santé : une interdiction de principe
Le RGPD distingue une catégorie particulière de données dites sensibles, parmi lesquelles les données concernant la santé, mais aussi les opinions, l’origine, les convictions ou les données biométriques. Pour ces catégories, le principe n’est pas l’encadrement mais l’interdiction. Leur traitement est prohibé, sauf à relever d’une exception strictement définie, comme le consentement explicite de la personne ou une obligation dans le domaine de la santé.
Concrètement, exposer des données de santé à un modèle d’IA sans base d’exception solide n’est pas un risque parmi d’autres : c’est un traitement interdit par défaut. C’est pourquoi une approche prudente consiste à traiter ces données comme devant être bloquées, et non simplement encadrées, lorsqu’aucune exception ne s’applique clairement.
Il faut distinguer deux situations très différentes. Des données personnelles « ordinaires » peuvent être traitées si l'on dispose d'une base légale et que l'on respecte les principes du règlement. Des données sensibles, comme la santé, sont interdites de traitement par défaut. La première situation se gère ; la seconde se ferme tant qu'aucune exception ne la rouvre.
La pseudonymisation ne rend pas un traitement licite en soi
Remplacer des noms par des codes est une mesure utile, mais il faut en comprendre la portée exacte. Le RGPD reconnaît la pseudonymisation comme une mesure de sécurité, qui réduit le risque sans faire sortir les données du champ du règlement, car la réidentification reste possible. La position exprimée par le Comité européen de la protection des données (EDPB) va dans ce sens : pseudonymiser un traitement ne suffit pas, à lui seul, à le rendre licite. Une base légale demeure nécessaire, et les principes continuent de s’appliquer.
La pseudonymisation est donc un moyen, pas une absolution. Elle renforce une conformité par ailleurs établie ; elle ne la remplace pas. L’anonymisation au sens strict, qui exclut toute réidentification, fait sortir les données du champ du RGPD, mais elle est plus exigeante et rarement atteinte de manière absolue. Mieux vaut décrire avec honnêteté ce que l’on met en œuvre que de qualifier d’anonyme ce qui reste pseudonyme.
Le transfert hors de l’Union européenne
Un autre point appelle la vigilance : la localisation du traitement. Faire appel à un fournisseur d’IA dont les serveurs sont hors de l’Union européenne constitue un transfert de données, soumis à des règles spécifiques (décision d’adéquation, clauses contractuelles types, garanties appropriées). Le fait qu’un service soit largement utilisé ne dispense pas de cette analyse. Beaucoup d’usages quotidiens d’IA reposent sur des infrastructures situées hors de l’UE, ce qui doit être documenté et encadré, et non supposé conforme.
Le piège du « conforme RGPD »
C’est sans doute la confusion la plus fréquente, et la plus lourde de conséquences. La mention « conforme RGPD » ne signifie pas que les données restent chez vous. Elle indique qu’un traitement est encadré selon les règles : base légale, durée de conservation, droits des personnes, mesures de sécurité. Mais un traitement parfaitement conforme peut tout à fait faire sortir la donnée réelle vers un tiers.
Il est donc utile de séparer deux familles de cas. D’un côté, les données qui peuvent être traitées et transmises, sous réserve d’un cadre conforme : appelons-les « RGPD-acceptable, mais qui sort ». De l’autre, les données qu’une organisation, par décision interne, contrainte sectorielle ou nature sensible, considère comme ne devant jamais quitter son périmètre : « interdites de sortie ». Pour la première famille, un bon contrat et une bonne documentation suffisent. Pour la seconde, aucune clause contractuelle ne remplace le fait, technique, que la donnée ne soit pas sortie.
Le cas « interdit de sortie » : répondre par la technique
C’est précisément ce second cas qui a guidé la conception de CLEVYA. Lorsqu’une donnée ne doit pas quitter le serveur, la réponse ne peut pas être un engagement : elle doit être une mesure technique vérifiable. L’approche consiste à détecter et remplacer en local les identifiants sensibles avant tout appel à un modèle, de sorte que le modèle ne reçoive jamais le réel, et à journaliser chaque envoi pour que le DPO puisse vérifier ce qui est, ou n’est pas, sorti.
Il faut rester précis sur ce qui est établi et ce qui ne l’est pas. La détection d’identifiants a été mesurée : elle atteint 94,2 % de recall sur notre corpus maison (206 documents synthétiques multi-métiers en français, écrits pour le test) et environ 75 % sur un benchmark public français, dans notre périmètre de types. Aucune détection automatique n’atteint 100 %, et nous ne le prétendons pas. C’est pourquoi le dispositif repose sur plusieurs couches (formats connus, reconnaissance d’entités, listes propres à l’organisation) et sur un principe de prudence : en cas de doute, la donnée ne sort pas. La sécurité tient par du code déterministe et un contrôle humain, jamais par la seule appréciation du modèle.
Pour aller plus loin
La lecture conformité complète est détaillée sur la page RGPD & souveraineté. Pour comprendre la différence entre un engagement contractuel et une preuve technique, voir Souveraineté IA : contrat vs preuve. Sur les obligations à venir, voir EU AI Act 2026 : ce qu’il faut préparer, dont l’application est échelonnée : premières obligations (pratiques interdites, littératie IA) en vigueur depuis 2025, échéance majeure au 2 août 2026. Enfin, sur les usages d’IA invisibles déjà présents dans les organisations, voir Shadow AI : le risque invisible.
Vous avez un cas concret de données interdites de sortie ? Parlez-nous-en : on regarde ensemble ce que le dispositif couvre, et ce qu’il ne couvre pas.