RGPD et IA : ce qui change vraiment pour une PME

En bref. L’IA introduit trois nouvelles exigences RGPD pour une PME : documenter le traitement des données personnelles par les modèles, réaliser une analyse d’impact lorsque le traitement crée un profil ou prend une décision automatisée, et garantir l’explicabilité et le droit d’effacement dans les flux d’IA générative. Ces obligations s’ajoutent au cadre existant du RGPD et ne sont pas couvertes par les seules politiques de confidentialité classiques. Un dirigeant doit les intégrer dès la conception de tout projet d’IA.

Une situation concrète : le chatbot qui connaît trop bien vos clients

Lors du comité de direction du 12 mars, le responsable juridique présente une capture d’écran du chatbot interne, construit avec GPT-4o et connecté à votre CRM HubSpot, qui propose des recommandations produit en se basant sur l’historique d’achat et les échanges mail des trois derniers mois. Le DPO souligne que le bot stocke provisoirement les échanges dans une base de données non chiffrée afin d’améliorer ses réponses. Cette scène illustre le premier point nouveau : la nécessité de documenter précisément quelles données personnelles sont traitées par le modèle, où elles sont stockées et pendant combien de temps.

Sans ce registre, vous êtes en défaut de l’article 30 du RGPD (registre des traitements). La simple mention « nous utilisons un chatbot » ne suffit plus ; il faut détailler chaque flux de données, y compris les logs de conversation qui peuvent contenir des noms, des adresses e‑mail ou des préférences d’achat.

Deuxième exigence : l’analyse d’impact quand le modèle profile ou décide

Le même chatbot, en plus de recommander, oriente automatiquement le client vers une offre premium lorsqu’il détecte un seuil de fréquence d’achat. Cette prise de décision automatisée relève du profilage au sens de l’article 22 du RGPD. Dès lors, une analyse d’impact sur la protection des données (AIPD) devient obligatoire avant la mise en production.

Approche	Points d’attention RGPD
Traitement basé sur des règles métier classiques	Le profilage est explicite, facile à documenter, l’impact sur les personnes peut être évalué via une analyse de risque simple.
Traitement basé sur un modèle d’IA qui apprend à partir des données	La logique est moins transparente, il faut journaliser les entrées/sorties, réaliser une AIPD plus détaillée et prévoir des moyens de contrôle humain.

Réaliser une AIPD implique d’évaluer la probabilité et la gravité d’un effet négatif sur les droits des personnes (ex. discrimination, exclusion), de définir des mesures de mitigation (seuil de décision révisable, possibilité d’opposition humaine) et de consigner le tout dans un document signé par le responsable du traitement. Une PME peut s’appuyer sur un tableau simple dans Excel pour suivre les scénarios de décision et leurs impacts potentiels.

Troisième exigence : explicabilité et droit d’effacement dans les flux d’IA générative

Lorsque le modèle génère une réponse texte à partir d’un prompt qui inclut des données personnelles (par exemple, « rédige un e‑mail de relance à M. Dupont basé sur sa dernière commande »), la sortie peut contenir ou déduire des informations personnelles. Le RGPD impose alors que l’on puisse expliquer comment ces données ont influé le résultat et, sur demande, effacer toute trace de ces données du système.

Avec un modèle fermé comme GPT-4o hébergé en API, vous n’avez pas accès aux poids ni aux états intermédiaires ; l’explicabilité se limite à journaliser le prompt et la réponse, ce qui reste insuffisant pour répondre à une demande d’accès ou de rectification. Une alternative consiste à utiliser un modèle open‑source tel que Mistral 7B déployé sur un serveur interne chiffré, où vous pouvez conserver les embeddings et les supprimer sur demande.

Ce qu’il ne faut pas faire : déployer un modèle sans garde‑fous

Ne le faites pas si vous envisagez d’utiliser un modèle de langage ouvert (comme Llama 3) directement connecté à votre boîte de réception client pour répondre automatiquement aux demandes de support contenant des données personnelles, sans aucune étape de filtrage ou de pseudonymisation. Cette approche viole le principe de minimisation des données (article 5 RGPD) car le modèle reçoit en clair l’intégralité du message, y compris les pièces jointes pouvant contenir des identifiants sensibles.

Le risque concret est une fuite involontaire : le modèle pourrait reproduire dans sa réponse un numéro de carte bancaire ou un numéro de sécurité sociale présent dans le message entrant, exposant l’entreprise à une violation de données et à des sanctions pouvant atteindre 4 % du chiffre d’affaires mondial.

Dans ce cas, la réponse appropriée est de mettre en place un pré‑traitement qui extrait et pseudonymise les champs personnels avant d’envoyer le texte au modèle, puis de restaurer les informations uniquement après validation humaine.

Quand il vaut mieux s’abstenir : l’IA non maîtrisée pour le droit d’accès

Essayer de faire tourner un modèle GPT-4o sur un serveur cloud non certifié ISO 27001 afin d’automatiser la réponse aux demandes d’accès (article 15 RGPD) est une fausse bonne idée. Même si le modèle peut générer un résumé des données détenues, il ne garantit pas l’exhaustivité ni l’exactitude requises par le règlement, et le transfert de données personnelles vers un tiers non soumis au RGPD crée un sous‑traitant non conforme.

La réponse est donc n’y allez pas tant que vous ne disposez pas d’un contrat de sous‑traitance incluant les clauses RGPD standards et d’un environnement d’exécution certifié. En attendant, privilégiez un processus manuel appuyé sur votre CRM ou un outil de gestion des demandes tel que n8n ou Make pour extraire les données nécessaires et les remettre au demandeur sous forme lisible.

Mettre en place les trois obligations dès le départ

Pour répondre aux nouvelles exigences, commencez par cartographier chaque flux d’IA : quelles données personnelles entrent, où elles sont stockées, combien de temps elles sont retenues, et quel est le sort des sorties. Documentez ce flux dans un registre vivant (par exemple une feuille Excel partagée ou une base Airtable).

Ensuite, déterminez si le modèle effectue du profilage ou prend des décisions automatisées. Si oui, lancez une AIPD simplifiée : listez les scénarios de décision, évaluez le risque pour chaque scénario, définissez des mesures de mitigation (seuil de révision humaine, journalisation des décisions) et faites valider le document par votre DPO.

Enfin, choisissez une architecture qui permet l’explicabilité et l’effacement : privilégiez les modèles déployés sur votre infrastructure ou sur un cloud européen avec possibilité de supprimer les embeddings et les logs sur demande. Conservez les prompts et les réponses dans un système de journalisation chiffré, et prévoyez une procédure permettant de retirer ces données sur simple demande de la personne concernée.

Questions fréquentes

Dois-je nommer un DPO externe pour gérer l’IA ?

La désignation d’un DPO n’est pas obligatoire uniquement parce que vous utilisez de l’IA ; elle dépend de vos activités de traitement de données à grande échelle ou de votre catégorie de données sensibles. Toutefois, si vos traitements d’IA impliquent un suivi régulier et systématique de personnes, désigner un DPO (interne ou externe) devient fortement recommandé pour assurer la conformité.

Puis-je utiliser un modèle de langage hébergé aux États‑uniens tant que je chiffrer les données en transit ?

Non. Le chiffrement en transit ne suffit pas : le transfert de données personnelles vers un pays hors de l’UE nécessite des garanties équivalentes au RGPD (clauses contractuelles types, décision d’adéquation ou règles d’entreprise contraignantes). Sans ces garanties, le traitement reste non conforme même si les données sont chiffrées pendant le transfert.

Quel outil simple puis‑je utiliser pour journaliser les prompts et les réponses de mon chatbot ?

Vous pouvez mettre en place un workflow n8n ou Make qui intercepte chaque appel à l’API du modèle, enregistre le prompt et la réponse dans une base de données chiffrée (comme PostgreSQL avec pgcrypto) et déclenche une alerte si une donnée personnelle détectée dépasse un seuil de rétention prédéfini.

Est‑ce que je dois refaire une AIPD à chaque mise à jour du modèle ?

Une nouvelle AIPD est nécessaire lorsqu’une modification substantielle change la finalité, la nature ou les risques du traitement (par exemple ajout de nouvelles sources de données personnelles, changement de seuil de décision automatisée, ou passage à un modèle avec une architecture différente). Une simple correction de bug ou une mise à jour de version mineure ne déclenche généralement pas une nouvelle évaluation, mais il convient de vérifier que le risque n’a pas évolué.

Puis‑je compter sur le consentement de mes clients pour couvrir l’utilisation de leurs données par l’IA ?

Le consentement peut servir de base légale uniquement lorsqu’il est libre, spécifique, éclairé et unambigu. Dans le cadre d’un profil automatisé ou d’une décision qui produit des effets juridiques, le consentement est souvent insuffisant ; il faut alors s’appuyer sur une autre base légale (exécution d’un contrat, intérêt légitime après évaluation) et garantir les droits d’opposition et d’effacement.