Privacy by design : guide RGPD pour agents IA et chatbots

Un agent IA n'est pas un chatbot au vocabulaire plus riche. Il interprète une demande, appelle des outils, consulte parfois vos documents, garde des traces et déclenche des actions métier. Si vous traitez la confidentialité après avoir choisi le modèle, vous compenserez souvent une architecture trop ouverte par des procédures manuelles.

Privacy by design : ce que le RGPD impose à un agent IA

Le privacy by design consiste à placer la protection des données dans l'architecture, avant la première ligne de code. L'article 25 du RGPD en fait une obligation, pas une bonne pratique. Pour un agent IA, elle porte sur quatre choses : ce que le service collecte, ce qu'il envoie au modèle, ce qu'il conserve et ce qu'il transmet à des tiers.

Le texte n'a rien de récent. Le RGPD a été adopté le 27 avril 2016 et s'applique depuis le 25 mai 2018.⁵ Ce qui a changé, c'est l'objet à protéger. Un agent conversationnel fait circuler des données personnelles dans des composants qui n'existaient pas dans vos anciens outils de relation client.

La CNIL demande de placer la protection de la vie privée au cœur des développements.¹ Elle attend que l'on parte de l'objectif, des méthodes et des sources de données.² Le livrable n'est donc pas un avis juridique. C'est une architecture documentée, avec des réglages par défaut vérifiables dans la configuration et dans le code.

La bonne question n'est pas de savoir comment rendre l'agent conforme après son développement. Elle est de savoir quelles données il doit voir, mémoriser et transmettre pour faire exactement son travail. Un parcours qui explique pourquoi il demande une information rassure mieux qu'une longue politique de confidentialité.

Ce que « par défaut » ajoute à « dès la conception »

L'article 25 pose deux niveaux qui se complètent. Le privacy by design porte sur la construction du système. Le privacy by default porte sur son comportement initial, avant qu'un utilisateur ou un administrateur ne touche aux réglages. Une architecture peut savoir chiffrer, cloisonner et filtrer, tout en démarrant avec une conservation trop longue et des accès trop larges.

Les sept principes formulés par Ann Cavoukian restent une bonne grille, à une condition : chaque principe doit produire un contrôle observable. Un historique désactivé quand il n'est pas utile à la finalité en est un. Une consigne système qui demande poliment au modèle de se retenir n'en est pas un.

Le test est simple : demandez à votre équipe de vous montrer le contrôle à l'écran. Ce qui ne se montre pas ne tiendra pas devant un auditeur.

Les articles du RGPD qui encadrent un agent conversationnel

Trois articles portent l'essentiel du sujet.⁵ L'article 5 fixe les principes : une finalité définie, des données limitées à cette finalité, une conservation bornée, une sécurité adaptée. L'article 6 exige une base légale pour chaque traitement. L'article 25 impose la protection dès la conception et par défaut. Les autres obligations en découlent.

• Base légale (article 6) : nommez, pour chaque finalité de votre agent, ce qui autorise le traitement, du contrat au consentement en passant par l'intérêt légitime.
• Minimisation (article 5) : la limitation aux données nécessaires vise aussi le contexte envoyé au modèle, pas seulement votre base de données.
• Information (article 13) : la personne doit savoir, au moment de la collecte, à quoi servent ses données, combien de temps vous les gardez et quels droits elle exerce.
• Sous-traitance (article 28) : chaque prestataire qui traite des données pour votre compte, fournisseur du modèle compris, relève d'un contrat écrit.
• Sécurité (article 32) : les mesures doivent être adaptées au risque, et le texte cite explicitement la pseudonymisation et le chiffrement.
• Décision automatisée (article 22) : une décision prise sans intervention humaine et produisant des effets juridiques ouvre un droit à un réexamen par une personne.
• Analyse d'impact (article 35) : elle devient obligatoire dès que le traitement risque d'engendrer un risque élevé pour les droits des personnes.

L'article 50 du règlement européen sur l'intelligence artificielle ajoute une obligation de transparence.⁶ La personne doit savoir qu'elle interagit avec un système d'IA. Écrivez cette mention dans le premier message de l'agent, pas dans des conditions générales que personne n'ouvre.

Comment les données circulent dans un agent IA

La minimisation commence par séparer les flux. L'identifiant direct de la personne n'a pas besoin de circuler dans tous les composants. Un service d'identité garde le lien entre la personne et un jeton. Le moteur de conversation, lui, ne voit que ce jeton et les champs utiles à la tâche. La minimisation devient une transformation du flux, pas une amputation du contexte.

Un chemin praticable ressemble à ceci :

1. Canal d'entrée : le message arrive du web, du mobile, de la voix ou de l'e-mail, et un premier contrôle repère les données sensibles.
2. Masquage : noms, coordonnées, éléments de santé ou références financières sont remplacés par des valeurs contrôlées avant d'atteindre le modèle.
3. Routage : l'agent identifie l'objectif et le niveau d'autorisation requis, puis déclenche une vérification dès qu'un dossier individuel est en jeu.
4. Recherche documentaire cloisonnée : le moteur applique les permissions avant de générer, car un document interdit ne doit pas entrer dans le contexte du modèle.
5. Outils métier : chaque appel ne renvoie que les champs nécessaires, un statut et une date plutôt que le dossier entier.
6. Sortie et journal : la réponse est contrôlée avant envoi, et le journal garde l'intention, la décision et l'autorisation, pas le texte sensible.

Le quatrième point mérite qu'on s'y arrête. Le RAG, c'est la recherche documentaire : l'assistant va chercher la réponse dans vos documents avant de répondre. Les droits s'appliquent au moment de cette recherche. Demander au modèle d'ignorer un document sensible qu'on lui a déjà donné ne protège personne.

La CNIL cite aussi la généralisation et la randomisation comme mesures de minimisation adaptées aux systèmes d'IA. La première change l'échelle ou l'ordre de grandeur des attributs. La seconde ajoute du bruit pour réduire la précision et le lien entre une donnée et une personne. Le choix dépend de l'état de l'art, des coûts, du contexte et des risques pour les droits des personnes.³

Cette discipline se réutilise d'un parcours à l'autre. Les briques de filtrage, de cloisonnement et de traçabilité servent à plusieurs agents, ce qui évite de reconstruire les contrôles à chaque nouvelle fonction. C'est la logique d'un agent IA conversationnel bâti autour de contrôles intégrés plutôt que de corrections successives.

Ce que le privacy by design coûte, et où l'effort se concentre

L'essentiel du coût est du temps de décision, pas une ligne de licence. Cartographier les flux, écrire les finalités, choisir ce qui reste hors du modèle. Quelques ateliers avec la DSI (la direction des systèmes d'information), le métier et le juridique suffisent à cadrer un premier parcours. Le reste relève de l'ingénierie ordinaire, à condition de la faire avant la mise en service.

Prenons une hypothèse, à refaire avec vos chiffres : un service client qui reçoit 10 000 demandes par mois. Si un tiers d'entre elles portent sur un dossier individuel, les deux autres tiers se traitent sans aucune donnée nominative. Vous avez alors deux régimes à construire, pas un : un parcours documentaire ouvert, et un parcours identifié qui exige une vérification d'accès.

La formule tient en quatre grandeurs.

• Le volume total de demandes.
• La part qui exige une identification.
• Les champs strictement nécessaires à cette part.
• La durée de conservation par finalité.

Multipliez la part identifiée par le nombre de champs que vous laissez passer, et vous obtenez votre surface d'exposition. Le chiffre dépend de vos parcours, et vous ne le connaîtrez qu'en comptant dans vos journaux.

Reprendre ce travail après la mise en production coûte plus cher, et pas pour des raisons techniques. Il faut alors purger des historiques déjà constitués et renégocier un contrat signé. Il faut aussi réexpliquer aux utilisateurs un changement de comportement, et parfois suspendre une fonction pendant la correction. Le même travail fait avant le lancement ne se voit pas.

Trois arbitrages, dans la banque, la santé et les ressources humaines

Le secteur ne change pas les principes, il change l'endroit où l'effort se concentre. En banque, le sujet principal est la traçabilité des accès à un dossier. En santé, c'est la collecte progressive et le consentement. Aux ressources humaines, c'est la purge des candidatures et la séparation des dossiers.

Une conservation de 30 jours pour des données de candidats ne se décrète pas dans un article de blog. Elle s'inscrit dans la politique applicable, se vérifie techniquement et reste compatible avec vos obligations. Une durée écrite nulle part est une durée infinie.

Un agent IA dédié à la relation client s'évalue sur sa capacité à résoudre la demande avec le minimum de données. La qualité de sa langue vient ensuite.

Ce qui casse après la mise en service

Ce qui échoue le plus souvent, c'est la confiance dans la consigne système. Une instruction peut interdire au modèle de répéter un numéro de compte. Elle ne bloque ni un journal applicatif bavard, ni un connecteur mal réglé, ni une recherche trop large. Les contrôles qui comptent se placent hors du modèle, dans des composants prévisibles et testables.

Cinq causes reviennent dans les incidents.

• Le journal garde le texte intégral des échanges, parce que c'était pratique pendant les tests, et personne n'a changé le réglage avant l'ouverture au public.
• La recherche documentaire ignore les habilitations, donc un utilisateur obtient la réponse contenue dans un document qu'il n'aurait jamais pu ouvrir lui-même.
• Le connecteur métier renvoie le dossier entier alors que l'agent avait besoin d'un statut et d'une date, et tout ce qui remonte finit dans le contexte du modèle.
• L'environnement de test tourne sur une copie de la production, sans masquage, avec des accès plus larges que le service réel.
• La mise à jour du modèle passe sans revue, et le nouveau comportement rend caduques les tests écrits pour l'ancien.

Aucune de ces causes n'est exotique. Elles viennent toutes du même réflexe : garder les données au cas où elles serviraient. Un agent utile fait l'inverse, il demande ce dont il a besoin au moment où il en a besoin.

Les erreurs de conception les plus fréquentes

Choisir le modèle avant de décrire les flux reste l'erreur la plus fréquente. Elle enferme le projet dans une architecture qu'il faudra corriger par des procédures. Trois autres se répètent, et coûtent moins cher à éviter qu'à réparer.

Confier la conformité au seul juridique produit un dossier propre et un service non conforme, parce que les décisions qui comptent sont prises dans le code. Promettre l'effacement sans savoir le faire expose à une demande que vous ne saurez pas honorer, et il faut tester ce parcours avant l'ouverture. Mesurer la satisfaction sans mesurer la minimisation donne un service apprécié dont personne ne sait quelles données il accumule.

Une dernière erreur mérite d'être dite, parce qu'elle rassure à tort : croire qu'un hébergement en France règle la question. Le lieu du serveur ne dit rien de ce que vous envoyez au modèle, ni de qui peut lire vos journaux. Pour cadrer un chatbot sécurisé et contextualisé, partez des flux et des droits, puis choisissez le modèle adapté à la tâche.

Les questions à poser à votre fournisseur

Six questions écrites suffisent à séparer un fournisseur qui a construit des contrôles d'un fournisseur qui les improvise. Posez-les dans l'appel d'offres, demandez des réponses écrites, et comparez-les côte à côte. Une réponse vague sur l'hébergement ou sur les journaux est déjà une réponse, et elle vous renseigne.

• Où sont hébergées les données, et qui peut y accéder ? Une bonne réponse nomme le pays, l'hébergeur, les personnes habilitées côté fournisseur, et dit si un prestataire situé hors de l'Union européenne intervient à un moment quelconque.
• Qu'envoyez-vous exactement au modèle ? Attendez un exemple réel de contexte transmis et ce qui a été masqué avant l'envoi. Elle précise aussi si l'éditeur du modèle conserve ces données ou les réutilise.
• Comment les droits d'accès s'appliquent-ils à la recherche documentaire ? Une bonne réponse décrit un filtrage appliqué avant la génération de la réponse, et non une consigne demandant au modèle d'ignorer certains documents.
• Que contiennent vos journaux, et combien de temps les gardez-vous ? La réponse utile distingue le journal technique du contenu des échanges, donne une durée par type de trace, et explique comment la purge est vérifiée.
• Comment traitez-vous une demande d'effacement ? Une bonne réponse couvre la conversation, les traces, les documents dérivés et les sauvegardes, avec un délai et une preuve remise au client.
• Que se passe-t-il quand vous changez de modèle ? Une bonne réponse prévoit une information écrite et une période de test sur vos propres scénarios. Elle laisse aussi la possibilité de rester sur la version précédente le temps de la vérification.

Demandez enfin le contrat de sous-traitance et la liste des prestataires suivants. Un fournisseur qui ne sait pas nommer l'éditeur de son modèle ne saura pas davantage vous prévenir le jour où il en changera.

Gouverner l'agent après sa mise en service

Un agent change après son lancement. Le modèle évolue, la base documentaire grossit, un nouvel outil se connecte, et les utilisateurs posent des questions que personne n'avait prévues. Le privacy by design devient alors une gouvernance : des responsables nommés, des preuves conservées, une date de revue inscrite au calendrier.

L'analyse d'impact suit quatre étapes dans le manuel de la CNIL : étude du contexte, étude des contrôles, étude des risques, validation.⁴ Pour un agent, l'AIPD, c'est-à-dire l'analyse d'impact relative à la protection des données, se rejoue à chaque changement lourd. Trois cas la déclenchent en particulier : des données sensibles, un profilage à grande échelle, le croisement de plusieurs sources.

Le DPO, le délégué à la protection des données, ne devrait pas arriver à la fin du projet. La DSI décrit les flux, l'équipe IA documente les modèles et les outils, le juridique qualifie les finalités, et le métier vérifie que la minimisation ne casse pas le service.

Un rythme trimestriel suffit :

• Début de trimestre : la DSI et l'équipe IA recensent les changements de modèles, de consignes, de connecteurs et de bases documentaires.
• Milieu de trimestre : le juridique réexamine les finalités, les droits, les durées de conservation et les risques.
• Fin de trimestre : le métier et la sécurité testent des scénarios de fuite, de mauvaise autorisation, de réidentification et d'escalade humaine.
• Après la revue : le comité accepte le risque, impose un correctif ou suspend la fonction.

Suivez la part de données pseudonymisées, dont l'identité a été remplacée par un code, la couverture des journaux et la conformité des permissions de recherche. Ces indicateurs ne prouvent pas la conformité, mais ils révèlent les dérives assez tôt pour agir.

La base documentaire demande la même discipline que le reste. Une base de connaissance IA pour le service client se gouverne comme un composant vivant. Elle a des versions, un propriétaire par domaine et une règle de retrait pour les documents périmés.

Ce que je ferais cette semaine

Trois décisions demandent une semaine, pas un budget. Cartographiez les flux de vos agents déjà en service, et remettez l'état des écarts au délégué à la protection des données. Choisissez un cas pilote à faible risque, définissez son architecture cible, puis testez-la sur des scénarios de données sensibles et d'autorisation. Planifiez l'analyse d'impact avec un responsable nommé, un périmètre écrit et une date de revue avant la mise en production.

Je pense que la plupart des projets d'agent IA se trompent d'ordre. Ils choisissent le modèle, puis cherchent comment le rendre conforme. Prenez le problème par les flux : dessinez ce qui entre, ce qui sort et ce qui reste. Vous saurez alors quel modèle vous pouvez vous permettre, et vous éviterez une refonte plus tard.

Le contrôle des droits est une décision d'entreprise, pas un réglage de prompt : l'IA prépare, l'humain valide. Si vous industrialisez un service client augmenté par l'IA, mesurez à chaque itération la minimisation réelle, la qualité des réponses et votre capacité à expliquer chaque décision.

FAQ sur le privacy by design des agents IA

Le privacy by design s'applique-t-il à un simple chatbot de questions courantes ?

Oui, dès que le service traite des données personnelles, même une adresse e-mail laissée dans un formulaire. L'obligation porte sur le traitement, pas sur la sophistication de l'outil. Un chatbot qui ne demande aucune donnée et ne conserve aucune trace nominative reste possible, et c'est souvent le bon point de départ.

Faut-il une analyse d'impact pour chaque agent IA ?

Non, elle s'impose quand le traitement risque d'engendrer un risque élevé pour les droits des personnes. Des données de santé, un profilage à grande échelle ou le croisement de plusieurs sources la rendent nécessaire. Dans le doute, la CNIL publie une méthode en quatre étapes qui sert aussi de cadre de discussion interne.⁴

Peut-on envoyer des données personnelles à un modèle hébergé hors d'Europe ?

C'est possible, mais cela demande un encadrement contractuel, une information des personnes et une analyse du risque. La question la plus utile reste en amont : avez-vous besoin d'envoyer ces données ? Un masquage avant l'appel au modèle règle souvent le sujet mieux qu'un montage juridique.

Un prompt système suffit-il à protéger les données ?

Une consigne système oriente le comportement du modèle, elle ne constitue pas une frontière technique. Elle ne s'applique ni aux journaux, ni aux connecteurs, ni à la recherche documentaire. Les contrôles qui tiennent devant un audit sont ceux que vous pouvez montrer dans le code et vérifier dans un test.

Combien de temps garder les conversations d'un agent IA ?

Le RGPD ne fixe pas de durée générale : vous la déduisez de la finalité. Gardez le temps de traiter la demande et de gérer une réclamation, puis purgez, en distinguant le contenu de l'échange des traces techniques. Une durée écrite dans la politique et vérifiée dans le système vaut mieux qu'une durée choisie au moment de la question.

Sources et references

1. [1]CNIL, Préparer son développement
2. [2]CNIL, Data protection when designing a system
3. [3]CNIL, Data protection in data collection and management
4. [4]CNIL, Privacy impact assessments: the CNIL publishes its manual
5. [5]EUR-Lex, Règlement (UE) 2016/679 du 27 avril 2016 (RGPD), articles 5, 6, 13, 22, 25, 28, 32 et 35
6. [6]EUR-Lex, Règlement (UE) 2024/1689 du 13 juin 2024 sur l'intelligence artificielle, article 50