RGPD à l'ère de l'IA : comment rester conforme sans bloquer les cas d'usage ?

La scène se répète dans la plupart des organisations qui veulent industrialiser l'IA. Un cas d'usage métier prometteur est identifié, les équipes data commencent à explorer les données disponibles, le POC est convaincant, et c'est à la veille de la mise en production que le sujet arrive : « On a regardé avec le DPO, et il y a un problème RGPD. » Le projet se met en pause, des jours deviennent des semaines, des semaines deviennent des mois.

Cette séquence n'est pas une fatalité. Elle traduit un défaut de méthode : le RGPD a été convoqué en fin de course, comme un filtre de conformité, alors qu'il aurait dû structurer le cadrage du projet dès le départ. À l'inverse, dans les organisations qui ont intégré le RGPD au cycle de vie des projets IA, la conformité ne bloque presque jamais : elle accompagne, elle oriente, parfois elle interdit, mais elle ne surprend pas.

Le RGPD n'est pas un obstacle à l'IA. C'est un cadre qui exige de penser autrement le rapport aux données : avec une finalité explicite, une base légale arbitrée, des droits préservés et une réversibilité possible. Cet article reprend la question concrètement : quelles obligations s'appliquent, comment cadrer un projet pour qu'elles ne deviennent pas un problème, qui pilote la conformité, et comment la maintenir dans la durée.

‍

Le RGPD interdit-il vraiment l'IA en entreprise ?

La réponse courte est non. Le RGPD ne prohibe aucune technologie, ni aucun cas d'usage par principe. Il pose un cadre qui s'applique dès qu'un traitement implique des données personnelles : finalité explicite, base légale identifiée, minimisation des données, transparence vis-à-vis des personnes, sécurité, et respect des droits (accès, rectification, opposition, effacement). Tout cela s'applique à l'intelligence artificielle comme à n'importe quel autre traitement.

Ce que le RGPD impose en revanche, c'est une discipline. Une organisation qui veut utiliser des données personnelles dans un projet IA doit pouvoir répondre à six questions précises : pourquoi traite-t-on ces données, sur quelle base légale, de qui parle-t-on, qu'est-ce qu'on en fait exactement, combien de temps les garde-t-on, et comment les personnes peuvent-elles exercer leurs droits. Si ces six réponses sont claires et documentées en amont, le projet avance. Si elles arrivent en fin de chaîne, le projet recule.

Le piège, c'est que beaucoup d'équipes interprètent le RGPD comme une interdiction quand elles tombent sur la première contrainte. Un Data Scientist qui voulait utiliser un export brut du CRM pour entraîner un modèle de scoring s'entend dire « ça ne passera pas le DPO » et conclut que « le RGPD bloque l'IA ». En réalité, ce n'est pas le RGPD qui bloque : c'est le fait d'avoir pris le problème dans le mauvais sens, en partant des données disponibles plutôt que de la finalité. Cette confusion est si fréquente qu'elle mérite qu'on s'y arrête.

Pourquoi le RGPD bloque autant les projets IA aujourd'hui ?

Si le RGPD bloque autant en pratique, ce n'est pas parce qu'il serait incompatible avec l'IA. C'est parce que la culture des projets IA s'est construite à rebours de ce que le RGPD demande. Trois écarts structurels expliquent l'essentiel des blocages observés.

Le premier écart est culturel. La data science s'est développée dans une logique d'exploration ouverte : on prend toutes les données disponibles, on regarde ce qu'on peut en faire, on découvre des signaux intéressants, on construit un modèle. Cette démarche est puissante en R&D, mais elle est radicalement incompatible avec le RGPD, qui impose de définir la finalité avant de collecter les données. Une démarche exploratoire qui rencontre le RGPD en fin de chaîne est presque toujours en infraction par construction.

Le deuxième écart est organisationnel. Dans la plupart des entreprises, les équipes data et les équipes DPO ne travaillent pas ensemble en amont. La data fait son cadrage technique, le DPO traite les sujets RGPD en parallèle, et les deux mondes se croisent au moment du go/no-go, soit trop tard pour ajuster l'architecture du projet. Cette séparation n'est pas une fatalité, mais elle est encore la norme.

Le troisième écart est technique. Beaucoup d'architectures IA ont été pensées dans une logique d'efficacité maximale, sans intégrer des exigences fondamentales du RGPD : la capacité à supprimer la trace d'une personne, à expliquer pourquoi un modèle a pris telle décision, à isoler les données d'une catégorie spécifique. Quand ces exigences arrivent après coup, elles obligent à refondre des pans entiers du système, ce qui coûte cher et fait dérailler les calendriers.

Le résultat est mécanique. Quand le DPO arrive en fin de course sur un projet pensé sans lui, il n'a pas d'autre choix que de freiner. Ce n'est pas le RGPD qui bloque : c'est le décalage entre une démarche conçue en silo et un cadre légal qui demande une approche intégrée. La solution n'est pas de retirer le RGPD du chemin. C'est de le mettre au cœur du cadrage.

Comment cadrer un projet IA conforme au RGPD dès le départ ?

Cadrer un projet IA conforme demande de changer l'ordre des étapes. Trois inversions par rapport à la pratique courante suffisent à régler la grande majorité des problèmes.

Fixer la finalité avant de choisir les données

Le principe de finalité est la pierre angulaire du RGPD. Il impose que les données personnelles soient collectées pour des finalités déterminées, explicites et légitimes, et qu'elles ne soient pas traitées ultérieurement d'une manière incompatible avec ces finalités. En pratique, cela signifie qu'on ne peut pas réutiliser des données collectées pour A afin d'entraîner une IA qui sert à B, sans une nouvelle base légale.

C'est précisément ce qui pose problème dans les démarches exploratoires. Un export du CRM a été collecté pour la gestion de la relation client. L'utiliser pour entraîner un modèle de scoring d'attrition n'est pas automatiquement permis : il faut vérifier que cette nouvelle finalité est compatible avec la finalité initiale, ou qu'elle dispose de sa propre base légale. Cette vérification doit intervenir avant que les données ne soient extraites pour le projet IA.

Concrètement, le cadrage d'un projet IA conforme commence par trois questions, dans cet ordre :

• Quelle est la finalité métier précise ? Pas « améliorer la connaissance client », mais « prédire la probabilité d'attrition à 90 jours pour cibler les actions de rétention ». Plus la finalité est précise, plus la suite est facile à arbitrer.
• Quelles données sont strictement nécessaires à cette finalité ? C'est le principe de minimisation. On ne prend pas tout ce qu'on a, on prend ce qui est nécessaire et proportionné. Cette liste est documentée et justifiée.
• Comment les personnes concernées sont-elles informées de ce traitement ? Si l'information initiale ne couvre pas le nouvel usage, il faut soit l'enrichir, soit s'appuyer sur une base légale qui n'exige pas d'information préalable (rare en pratique).

Cette inversion (finalité d'abord, données ensuite) suffit à régler la grande majorité des blocages observés en fin de chaîne.

Arbitrer la base légale au démarrage

Le RGPD prévoit six bases légales possibles pour un traitement (consentement, contrat, obligation légale, intérêts vitaux, mission d'intérêt public, intérêt légitime). Toutes ne sont pas équivalentes, et le choix n'est pas neutre pour la suite du projet.

• Le consentement est la base la plus protectrice pour la personne, mais c'est aussi la plus contraignante : il doit être libre, spécifique, éclairé, et la personne peut le retirer à tout moment. Pour un projet IA, le retrait du consentement implique de pouvoir retirer la contribution de cette personne à l'entraînement du modèle, ce qui est techniquement complexe.
• L'exécution d'un contrat s'applique quand le traitement est nécessaire à l'exécution du contrat conclu avec la personne. Elle est solide quand le lien est direct, plus contestable quand le projet IA est annexe au cœur du contrat.
• L'intérêt légitime est souvent retenu en IA, mais il exige un test de mise en balance : l'intérêt poursuivi par l'organisation doit être proportionné au regard de l'impact sur les personnes. Ce test doit être documenté, et le résultat doit être révisé en cas d'évolution du projet.

Le choix de la base légale doit être arbitré dès le cadrage, avec le DPO. Le faire trop tard contraint le projet à se replier sur la base légale la plus restrictive, qui n'est pas toujours celle qui correspond le mieux au cas d'usage.

Prévoir la réversibilité dès l'architecture

Le RGPD donne aux personnes des droits qu'elles peuvent exercer à tout moment : accès à leurs données, rectification, opposition, effacement, portabilité. Ces droits s'appliquent aussi aux projets IA, ce qui pose un problème technique non trivial : comment effacer la trace d'une personne dans un modèle qui a été entraîné sur ses données ?

La réponse pragmatique tient en trois principes d'architecture, à prévoir dès la conception :

• Tracer chaque enregistrement par individu identifié, pour pouvoir retrouver la contribution d'une personne donnée dans les jeux d'entraînement, de validation et de test. Sans cette traçabilité, l'exercice du droit à l'effacement devient un cauchemar.
• Documenter et planifier les réentraînements, parce que le retrait d'une personne nécessite, en pratique, un réentraînement du modèle sur le jeu de données nettoyé. Cette périodicité doit être prévue dans le cycle de vie du modèle, en lien avec les pratiques d'industrialisation MLOps.
• Anticiper les techniques de désapprentissage ou d'apprentissage différentiel quand le réentraînement complet est trop coûteux. Ces techniques sont encore peu matures, mais elles entrent dans la palette de réponses possibles.

Une architecture qui rend la réversibilité impossible n'est pas une architecture conforme, quelle que soit la qualité du modèle qui tourne dessus.

Quels acteurs piloter la conformité RGPD sur un projet IA ?

La conformité RGPD d'un projet IA n'est pas l'affaire d'une seule fonction. Elle se construit dans la coopération entre trois rôles qui apportent chacun une part irremplaçable du dispositif. C'est leur articulation qui fait la conformité, pas leur addition.

Le DPO traduit les obligations en règles opérationnelles

Le Data Protection Officer est l'interface entre le cadre juridique et le projet. Son rôle n'est pas de dire oui ou non en fin de chaîne, mais de traduire les obligations du RGPD en règles applicables au projet : quelle finalité est documentée, quelle base légale est mobilisable, quelles données sont strictement nécessaires, quels droits doivent être garantis, quelle DPIA (analyse d'impact relative à la protection des données) est nécessaire.

Le DPO intervient idéalement à trois moments :

• Au cadrage, pour valider la finalité, arbitrer la base légale et identifier les besoins de DPIA. C'est là que sa contribution évite le plus de problèmes en aval.
• Pendant la conception, pour relire l'architecture (minimisation, durée de conservation, droits des personnes, sécurité) et formaliser les documents (registre des traitements, DPIA, mentions d'information).
• En production, pour vérifier que les engagements pris au cadrage sont tenus et instruire les éventuelles demandes d'exercice de droits.

Le DPO ne décide pas à la place du responsable de traitement, mais il alerte, conseille et documente. Sa valeur est d'autant plus grande qu'il est mobilisé tôt.

Le Data Owner garantit la légitimité de la donnée

Le Data Owner du domaine concerné est responsable des données utilisées par le projet. Sa responsabilité dans la conformité RGPD est triple :

• Vérifier que les données mobilisées proviennent d'un cadre légitime : quelle collecte initiale, quelle finalité, quelle base légale, quelle information donnée aux personnes. Si le projet IA introduit une finalité nouvelle, c'est lui qui alerte.
• Garantir la qualité et la traçabilité des données d'entraînement : la conformité RGPD croise ici les pratiques de qualité des données. Une donnée d'entraînement dont on ne connaît ni la provenance ni la fraîcheur est aussi un problème de conformité, pas seulement de performance du modèle. C'est précisément le type de sujet couvert par un audit qualité des données rigoureux.
• Arbitrer les conflits d'usage quand le projet IA entre en tension avec d'autres usages des mêmes données, ou avec les droits des personnes.

Le Data Owner est le pendant métier du DPO : l'un porte la règle, l'autre porte la donnée. Sans cette articulation, la conformité reste théorique.

Le métier porte la finalité du cas d'usage

Le sponsor métier du projet IA n'est pas un acteur passif de la conformité. C'est lui qui définit la finalité, et c'est cette finalité qui conditionne tout le reste : base légale, données nécessaires, durée de conservation, dispositif d'information. Un sponsor métier qui ne sait pas formuler précisément à quoi sert son IA condamne le projet à une conformité bricolée.

Sa responsabilité concrète tient en trois points :

• Formuler la finalité de manière précise et stable. Pas en termes vagues (« mieux comprendre nos clients »), mais en termes opérationnels (« décider quelle action commerciale déclencher sur quel segment dans quel délai »).
• Arbitrer les compromis entre performance et conformité. Quand le DPO alerte sur un usage borderline, c'est le sponsor métier qui tranche, en assumant le risque ou en modifiant le périmètre. Cette responsabilité ne se délègue pas.
• Maintenir la finalité dans la durée. Quand le projet évolue, c'est lui qui décide si l'on reste dans le périmètre initial ou si l'on bascule sur une nouvelle finalité (qui demandera alors un nouveau cadrage RGPD).

Cette répartition à trois rôles (DPO, Data Owner, métier) s'inscrit dans une logique plus large de rôles et responsabilités en gouvernance des données. La conformité RGPD n'est qu'une dimension parmi d'autres de ce dispositif, mais c'est l'une de celles qui exige la coopération la plus serrée.

Comment suivre la conformité RGPD dans la durée sur un projet IA ?

La conformité RGPD n'est pas un état qu'on atteint à la mise en production. C'est un dispositif qui vit avec le projet, qui se révise quand le projet évolue, et qui s'use si on ne l'entretient pas. Trois pratiques structurent un suivi qui tient dans la durée.

Mettre la conformité dans le backlog du projet

La pratique la plus simple, et la plus négligée, est d'inscrire les exigences RGPD dans le backlog du projet, au même titre que les exigences fonctionnelles ou techniques. Concrètement, cela signifie qu'à chaque sprint, l'équipe projet vérifie l'état de quelques items récurrents : la documentation des traitements est-elle à jour, les mentions d'information sont-elles cohérentes avec ce qui est effectivement fait, les durées de conservation prévues sont-elles tenues, les droits des personnes sont-ils traités dans les SLA prévus.

Cette intégration dans le backlog produit un effet mécanique : la conformité cesse d'être un sujet « du DPO » pour devenir un sujet de l'équipe projet. C'est la condition pour qu'elle survive aux changements de Product Owner, aux turn-over dans l'équipe data, et aux pivots du métier.

Suivre les indicateurs de conformité au même rythme que les indicateurs techniques

Un projet IA en production suit habituellement des indicateurs techniques (latence, taux d'erreur, dérive du modèle) et des indicateurs métier (impact business, satisfaction utilisateur). Trop souvent, ces indicateurs n'incluent rien sur la conformité. Cinq indicateurs supplémentaires suffisent à couvrir l'essentiel :

• Le nombre et le délai de traitement des demandes d'exercice de droits (accès, rectification, effacement, opposition). Si ces demandes s'accumulent ou dérivent en délai, c'est le signal d'un problème opérationnel.
• Le taux de complétude des champs d'information aux personnes dans les outils de production. Une mention manquante sur un formulaire client est une non-conformité concrète.
• L'âge de la dernière DPIA pour les projets qui y sont soumis. Une DPIA de plus de 18 mois sur un système qui a évolué est probablement obsolète.
• Le taux de couverture des durées de conservation effectives par rapport aux durées prévues. Les données sont-elles effectivement supprimées ou anonymisées dans les délais ?
• Le nombre d'incidents de sécurité notifiés au DPO concernant le périmètre du projet, sur une période glissante.

Ces indicateurs ne sont pas exotiques. Ils peuvent être suivis dans le même tableau de bord que les autres indicateurs du projet, et revus aux mêmes rituels. C'est ce parallélisme qui fait que la conformité reste vivante.

Réviser la DPIA à chaque évolution du modèle

La DPIA (analyse d'impact relative à la protection des données) est obligatoire pour les traitements présentant un risque élevé pour les droits des personnes, ce qui inclut la plupart des projets IA à haut risque. Elle n'est pas un document figé : elle doit être révisée quand le traitement évolue de manière significative.

Or les projets IA évoluent en permanence : le modèle est réentraîné, le périmètre d'utilisation s'élargit, de nouvelles données sont ajoutées, l'architecture technique change, les usages aval se multiplient. Chacune de ces évolutions peut modifier les risques pour les personnes et donc invalider la DPIA initiale.

Une bonne pratique consiste à associer la révision de la DPIA aux étapes structurantes du cycle de vie du modèle :

• Avant chaque réentraînement majeur, pour vérifier que les nouvelles données mobilisées ne modifient pas le profil de risque.
• À chaque extension d'usage, quand le modèle est déployé sur un nouveau public, dans un nouveau contexte ou pour une nouvelle finalité.
• Au moins une fois par an, même sans évolution majeure, pour vérifier que les risques identifiés sont toujours d'actualité et que les mesures de mitigation sont effectivement en place.

Cette routine de révision donne à la DPIA une valeur réelle. Sans elle, le document devient un artefact administratif que personne ne consulte, et qui ne protège plus personne (à commencer par l'organisation elle-même en cas de contrôle).

👉 À lire aussi : Gouverner l'IA en entreprise : ce qu'il faut vraiment faire

👉 À lire aussi : L'IA générative et ses impacts sur la gouvernance des données