RGPD et IA - Évitez les erreurs coûteuses, sécurisez vos projets

Les projets d’intelligence artificielle promettent des gains rapides, mais ils deviennent vite fragiles dès qu’ils touchent à des données personnelles, à la sécurité ou à la traçabilité des décisions. Le vrai sujet n’est pas seulement de respecter le RGPD, mais de construire un usage de l’IA qui reste gouvernable, documenté et défendable en cas de contrôle. Dans ce cadre, la rencontre entre RGPD et IA oblige à arbitrer entre innovation, minimisation des données, sécurité et droits des personnes.

Pourquoi l’IA change la lecture du RGPD

Dans un projet d’IA, les données ne circulent pas à un seul endroit. Elles entrent dans les jeux d’entraînement, passent par les prompts, alimentent les logs, reviennent parfois par les retours utilisateurs et transitent souvent chez plusieurs prestataires. Si je ne cartographie pas ces flux dès le départ, je découvre trop tard que le système traite plus de données que prévu, ou qu’il les conserve beaucoup plus longtemps que nécessaire.

Le risque n’est pas seulement juridique. Avec le shadow AI, un collaborateur peut coller un dossier client, un ticket support ou un extrait de contrat dans un outil externe sans circuit validé. Un assistant conversationnel interne peut aussi exposer des informations sensibles si les droits d’accès sont mal définis ou si le modèle reproduit un passage vu pendant l’apprentissage. Ce n’est pas théorique: une violation du RGPD peut conduire à des sanctions pouvant aller jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial.

• Collecte trop large quand l’équipe récupère “au cas où” des données qui ne servent pas au cas d’usage.
• Logs trop détaillés quand les traces techniques deviennent une seconde base de données personnelle.
• Réutilisation secondaire quand les données collectées pour un service sont recyclées pour l’entraînement sans cadre clair.

C’est précisément ce point qui mène à la question suivante: le cadre européen de 2026 ne traite pas l’IA comme un simple outil logiciel, mais comme un objet de gouvernance à part entière.

Ce qui change vraiment avec le cadre européen en 2026

Le règlement européen sur l’IA entre dans son application complète le 2 août 2026, après une montée en charge par paliers. Certaines obligations existent déjà depuis 2025, et les systèmes à haut risque bénéficient encore, selon les cas, d’un délai plus long, jusqu’au 2 décembre 2027 ou au 2 août 2028 selon les familles de systèmes. Pour une organisation, le message est simple: le calendrier réglementaire ne laisse plus la place à des projets “hors cadre” en attendant de voir.

Le point essentiel, c’est que le règlement IA ne remplace pas le RGPD. Il s’y ajoute. Si votre système touche à des données personnelles, vous devez gérer à la fois la logique de protection des données et la logique de sécurité, de transparence et de maîtrise des risques portée par le cadre européen. C’est précisément là que beaucoup de projets se compliquent, parce que les équipes produit, sécurité, juridique et data n’emploient pas toujours les mêmes critères.

En pratique, je regarde trois questions avant d’aller plus loin:

• Le cas d’usage relève-t-il d’un système à risque élevé ou d’un usage plus classique?
• Le modèle est-il autonome, connecté à des données internes, ou branché sur plusieurs prestataires?
• La conformité peut-elle être démontrée par des preuves concrètes, et pas seulement par une promesse de bonne intention?

Une fois ce cadre posé, il devient beaucoup plus simple d’analyser le statut réel du modèle et de ses données.

Savoir si votre modèle manipule réellement des données personnelles

Tout modèle d’IA n’est pas automatiquement soumis au RGPD, mais beaucoup le deviennent dès qu’il mémorise, restitue ou permet d’extraire des informations liées à des personnes physiques. La frontière entre un modèle anonyme et un modèle qui reste traçable n’est pas théorique: elle dépend de sa conception, des données d’entraînement, de la possibilité d’extraction et de la vraisemblance de réidentification.

Je fais ici une distinction utile entre le statut du modèle et le statut de l’usage. Un même modèle peut être relativement neutre dans un contexte, puis devenir problématique une fois branché sur des dossiers clients, des bases RH, des historiques de tickets ou des contenus internes sensibles.

Cas d’usage	Lecture RGPD	Point de vigilance
Assistant RH interne connecté aux dossiers salariés	Données personnelles quasi certaines	Accès restreint, information des salariés, durée de conservation, audit des réponses
Chatbot de support relié à une base clients	Données personnelles probables	Minimisation, journalisation limitée, gestion des demandes d’exercice des droits
Modèle entraîné sur un corpus large avec traces identifiables	Analyse au cas par cas	Tester la mémorisation, la régurgitation et la possibilité d’extraction
Système pseudonymisé pour scoring ou recommandation	Reste souvent dans le champ du RGPD	Ne pas confondre pseudonymisation et anonymisation
Modèle présenté comme anonyme, mais sans preuve d’absence de réidentification	Risque de qualification RGPD	Documenter les tests et la vraisemblance de réidentification

La règle pratique est simple: si je peux raisonnablement extraire, recouper ou réidentifier, je ne traite pas le système comme anonyme. Et si le système est anonyme uniquement “sur le papier”, il faut le considérer comme non conforme à l’esprit du texte. Cette étape détermine ensuite la base légale acceptable.

Choisir une base légale qui tient en cas d’audit

Une base légale bancale est l’une des causes les plus fréquentes d’échec. Sur l’IA, la tentation est grande d’attraper l’intérêt légitime par défaut, puis de l’étirer pour couvrir l’entraînement, les tests, l’exploitation et les améliorations produit. Je déconseille cette approche. Elle devient fragile dès qu’on demande pourquoi telle donnée est vraiment nécessaire et pourquoi le traitement ne pouvait pas être fait autrement.

En pratique, je me pose trois questions: l’intérêt poursuivi est-il réel, le traitement est-il nécessaire, et la balance des intérêts et des droits reste-t-elle favorable? C’est ce filtre qui évite les bases juridiques trop larges ou trop théoriques.

Base légale	Quand elle tient	Vigilance principale
Consentement	Fonctionnalités optionnelles, cas grand public clairement séparés	Le consentement doit être libre, spécifique et révocable sans pénaliser tout le service
Contrat	Quand le traitement est indispensable à l’exécution du service demandé	Ne pas l’utiliser pour justifier un entraînement secondaire sans lien direct
Obligation légale	Conservation ou transmission imposées par le droit	Le périmètre est étroit, il ne couvre pas un usage d’innovation plus large
Intérêt légitime	Cas de support conversationnel, d’amélioration de cybersécurité ou de prévention de fraude	Il faut démontrer la nécessité et l’équilibre des intérêts
Mission d’intérêt public	Surtout dans le secteur public, dans le cadre exact d’une mission	La mission doit être juridiquement cadrée

Pour un agent conversationnel ou un outil d’aide à la cybersécurité, l’intérêt légitime peut fonctionner si le traitement est strictement nécessaire et si l’équilibre des droits reste acceptable. En revanche, plus le projet touche à des données sensibles, à des salariés ou à des décisions à effet fort, plus je resserre le cadre ou j’explore une autre base.

Une base légale correcte n’épuise pas le sujet. Il faut encore transformer cette décision en architecture, en sécurité et en preuves exploitables.

Faire de la conformité une exigence d’architecture

Sur un projet sérieux, la conformité ne tient pas dans une note juridique isolée. Elle se retrouve dans la manière de collecter, de stocker, de journaliser, d’entraîner et de servir le modèle. C’est la partie la plus concrète du dossier, et celle qui évite la majorité des incidents.

Mesure	Ce qu’elle apporte au RGPD	Effet côté cybersécurité
Cartographie des flux	Savoir qui traite quoi, où et pourquoi	Réduit les zones d’ombre et les dépendances cachées
Minimisation des entrées	Limiter les données collectées au strict nécessaire	Réduit la surface d’attaque et la valeur d’une fuite
Isolation des environnements	Éviter le mélange entre tests, entraînement et production	Limite la propagation d’un accès compromis
Journalisation maîtrisée	Conserver assez de traces pour prouver, sans surcollecter	Évite que les logs deviennent eux-mêmes un jeu de données sensible
Gestion des droits des personnes	Répondre à l’accès, à la rectification, à l’effacement et à l’opposition	Impose des circuits internes clairs et testables
Encadrement des prestataires	Contrats, sous-traitance, transferts, conservation	Réduit les risques de chaîne de confiance opaque

À ce stade, je regarde aussi l’analyse d’impact dès qu’un cas d’usage peut produire un risque élevé, par exemple dans les ressources humaines, la santé, la biométrie, le profilage ou la surveillance à grande échelle. Je vérifie aussi les sujets de transferts hors UE, car le meilleur cadre légal du monde ne sert à rien si les données circulent sans garde-fous vers des zones mal maîtrisées.

Enfin, je ne sépare pas sécurité et conformité. Les attaques par injection de prompt, l’extraction de données, la fuite via connecteurs ou la mauvaise gestion des secrets sont des problèmes techniques, mais leurs effets sont aussi juridiques. C’est là que le projet gagne ou perd en crédibilité.

C’est précisément pour cela que les erreurs les plus courantes sont rarement spectaculaires au départ, mais très coûteuses ensuite.

Les erreurs qui font échouer un projet en production

Je retrouve presque toujours les mêmes angles morts quand un projet IA se dégrade. Ils ne sont pas toujours visibles en phase de prototype, mais ils réapparaissent dès que l’usage se diffuse ou que les volumes augmentent.

• Collecter “au cas où” au lieu de collecter ce qui est utile. La promesse d’efficacité masque souvent une surcollecte qui complique la base légale et la sécurité.
• Confondre pseudonymisation et anonymisation. Le simple remplacement d’un identifiant ne retire pas le caractère personnel d’une donnée.
• Oublier les logs et les rétentions. Un projet peut être propre en entrée et trop bavard en sortie, surtout avec des journaux conservés trop longtemps.
• Externaliser sans lire la chaîne. Le sous-traitant direct n’est pas le seul sujet, il faut aussi regarder les sous-traitants de rang 2 et les transferts.
• Tester le modèle sans tester les attaques. Sans simulation d’extraction, de fuite ou d’abus de prompt, on sous-estime souvent le risque réel.
• Attendre la mise en production pour impliquer le DPO et la sécurité. À ce moment-là, les compromis sont déjà figés et les corrections coûtent beaucoup plus cher.
• Présumer que des données synthétiques sont automatiquement sûres. Elles peuvent réduire le risque, mais elles ne le font pas disparaître par magie.

Plus le cas d’usage est sensible, plus ces erreurs deviennent difficiles à rattraper. C’est pour cela que je préfère un cadrage strict au départ plutôt qu’une correction tardive après incident ou remontée interne.

Ce que je verrouille avant de passer en production

Avant de valider un système d’IA, je passe toujours par la même séquence, parce qu’elle réduit les angles morts sans alourdir inutilement le projet.

1. Je définis le cas d’usage exact, les données utilisées et la finalité opérationnelle.
2. Je choisis la base légale la plus solide, puis je documente pourquoi elle tient.
3. Je vérifie si le modèle ou le système peut réellement être considéré comme anonyme.
4. Je lance une analyse d’impact dès que le niveau de risque le justifie.
5. Je verrouille les accès, les logs, les durées de conservation et les transferts.
6. Je teste les scénarios d’abus, de fuite, de réidentification et d’exercice des droits.

Si un point reste flou à ce stade, je ne le traite pas comme une formalité. Je le traite comme un risque de production. Je préfère lancer un périmètre réduit et défendable plutôt qu’une fonctionnalité large qui oblige ensuite à réécrire la politique de données. C’est souvent cette discipline-là, plus que n’importe quel outil, qui fait la différence entre un projet d’IA utile et un projet d’IA difficile à défendre.