IA et RGPD : ce que tu as vraiment le droit de faire avec tes données

Tu colles un extrait de ton CRM dans ChatGPT pour rédiger une relance. Tu branches un agent sur ta boîte mail. Tu enrichis des centaines de prospects avec un outil que tu n'as jamais audité. Et quelque part, une petite voix te demande si tu es en train de faire une bêtise.

La question IA et RGPD est mal posée dans la plupart des discussions que j'entends. D'un côté, ceux qui foncent en se disant que personne ne verra rien. De l'autre, ceux qui bloquent tout parce que le juridique a dit non une fois, en réunion, sans expliquer pourquoi. Les deux perdent : le premier prend un risque qu'il ne mesure pas, le second se prive d'un levier de productivité pendant que ses concurrents avancent.

Cet article n'est pas un cours de droit. C'est la grille de lecture opérationnelle que j'utilise avec les PME et scale-ups que j'accompagne, pour trancher vite : ce qui passe, ce qui ne passe pas, et ce qui demande une vraie décision. Ce n'est pas un conseil juridique : sur les sujets sensibles, ton DPO ou un avocat spécialisé aura le dernier mot.

IA et RGPD : la règle en une phrase

Le RGPD ne parle pas d'intelligence artificielle. Il parle de traitement de données personnelles. Un modèle de langage n'est ni interdit ni autorisé en soi : c'est un outil qui, dès qu'il touche une donnée permettant d'identifier une personne (nom, email, téléphone, adresse IP, identifiant client, contenu d'un échange), déclenche exactement les mêmes obligations que ton CRM, ta newsletter ou ton fichier Excel.

Autrement dit : si tu sais déjà répondre à la question « ai-je le droit de mettre cette donnée dans ce fichier ? », tu sais répondre à « ai-je le droit de la donner à ce modèle ? ». Ce qui change avec l'IA, ce ne sont pas les principes, ce sont trois choses très concrètes :

• Le volume. Un prompt peut embarquer en quelques secondes ce qu'un export CSV mettait une semaine à sortir d'un service.
• La destination. Ta donnée quitte ton infrastructure et part chez un fournisseur, souvent hors Union européenne.
• L'opacité. Personne dans l'entreprise ne sait dire précisément ce que le fournisseur fait de la donnée après l'appel API.

C'est là que le vrai risque se loge. Pas dans « l'IA », mais dans une chaîne de traitement que plus personne ne documente parce qu'elle est devenue trop facile à déclencher.

Où partent tes données quand tu prompts un LLM ?

Première question à poser, avant toute autre. Et la réponse dépend entièrement du type d'accès que tu utilises. Il y a trois régimes très différents que beaucoup confondent.

1. Le chat grand public gratuit. Tu es sur une interface web avec un compte perso. Selon le fournisseur et tes réglages, tes conversations peuvent être conservées et utilisées pour améliorer les modèles. C'est le régime le plus permissif pour le fournisseur, donc le plus risqué pour toi. Règle simple : tout ce que tu colles là, considère que ça pourrait être lu par un humain que tu n'as pas choisi.

2. L'offre entreprise ou l'API payante. Les fournisseurs sérieux s'engagent contractuellement à ne pas entraîner leurs modèles sur les données envoyées via ces canaux, avec une durée de rétention limitée pour la détection d'abus. C'est le régime de travail normal pour une entreprise. Encore faut-il que quelqu'un ait lu et signé le contrat, et que l'équipe utilise réellement ce canal plutôt que son compte perso.

3. L'auto-hébergement ou le modèle souverain. Le modèle tourne sur ton infrastructure ou chez un hébergeur européen. La donnée ne sort pas. Coût et complexité plus élevés, mais c'est la seule réponse vraiment confortable pour des données de santé, des dossiers RH sensibles ou du secret industriel.

Le piège classique en PME : l'entreprise paie une licence entreprise, et une partie de l'équipe continue d'utiliser son compte gratuit parce que c'est plus rapide. Le contrat existe, la conformité non. Ce qui compte, ce n'est pas ce que tu as acheté, c'est ce que tes gens utilisent réellement le mardi à 16 h.

As-tu le droit d'entraîner un modèle sur tes données clients ?

C'est la question qui revient dès qu'une entreprise veut créer « son » IA maison. Réponse courte : oui, sous conditions, et rarement de la façon dont tu l'imagines.

Réutiliser des données collectées pour une finalité A (gérer une commande, assurer un support) afin d'entraîner un modèle, c'est une finalité B. Le RGPD parle de test de compatibilité : la nouvelle finalité doit rester dans la ligne de ce que la personne pouvait raisonnablement attendre. Entraîner un modèle interne pour mieux router des tickets support à partir d'anciens tickets, c'est défendable. Entraîner un modèle commercialisé à des tiers sur les mêmes données, beaucoup moins.

Trois conditions à réunir avant de lancer :

1. Une base légale identifiée. Le plus souvent l'intérêt légitime, qui suppose un test de mise en balance écrit entre ton intérêt et les droits des personnes. Parfois le consentement, s'il n'y a pas d'alternative.
2. Une information claire. Ta politique de confidentialité doit mentionner cet usage. Si elle date d'avant l'IA générative, elle ne le mentionne pas.
3. La réversibilité. Une personne peut demander la suppression de ses données. Sortir une donnée d'un modèle déjà entraîné est techniquement très difficile, voire impossible. C'est l'argument numéro un pour ne pas entraîner quand tu peux faire autrement.

Et la plupart du temps, tu peux faire autrement. Le besoin réel n'est presque jamais « entraîner un modèle », c'est « donner accès à mes documents au modèle au moment de la question ». C'est exactement ce que fait une architecture RAG : la donnée reste dans ta base, elle est appelée à la volée, et une suppression est une vraie suppression. J'explique le fonctionnement en détail dans construire une base de connaissance interne pour l'IA. Moins glamour que « on a entraîné notre IA », infiniment plus propre juridiquement.

Prospection et enrichissement : que dit vraiment le RGPD ?

C'est le point où je vois le plus d'entreprises dans le flou, parce que la pratique est massive et la règle assez claire.

Quand tu enrichis un fichier de prospects avec un outil qui te sort emails et téléphones professionnels, tu traites des données personnelles que la personne ne t'a jamais transmises. Le RGPD prévoit ce cas : tu dois informer la personne de la collecte, en principe dans le mois ou au plus tard lors du premier contact. En pratique, cela veut dire une phrase dans ton premier email qui explique d'où tu tiens ses coordonnées et comment s'y opposer, plus un lien vers ta politique de confidentialité.

Trois précisions utiles :

• Le B2B n'est pas une zone franche. L'email nominatif d'un salarié est une donnée personnelle. Ce qui change en B2B, c'est la règle de prospection par email (le consentement préalable n'est pas exigé si le message est en rapport avec la fonction professionnelle de la personne), pas les obligations RGPD de transparence et de droit d'opposition.
• Ton fournisseur d'enrichissement est un maillon de ta chaîne. S'il a collecté illégalement, ton fichier est contaminé. Vérifie qu'il documente ses sources et qu'il te fournit un contrat de sous-traitance.
• Le droit d'opposition doit être réellement opérationnel. Un désabonnement qui ne remonte pas dans ton CRM et dans ton outil de séquence, c'est une non-conformité qui se voit tout de suite.

La bonne nouvelle : ces contraintes n'empêchent pas de performer. Le système d'acquisition décrit dans notre retour d'expérience sur 180 leads B2B en 7 jours tourne avec ces règles, pas contre elles. Et côté outillage, je détaille les garde-fous d'un pipeline propre dans enrichissement de données automatisé.

Les quatre principes RGPD à appliquer à tes usages IA

Tu n'as pas besoin de connaître le règlement par cœur. Quatre principes couvrent l'immense majorité des situations IA en entreprise.

La minimisation. Tu n'envoies au modèle que ce dont il a besoin pour produire la réponse. Pour rédiger une relance commerciale, le modèle a besoin du contexte de l'échange, pas du numéro de téléphone personnel, ni du montant du contrat précédent, ni du nom complet. Pseudonymiser un prompt prend quelques secondes et supprime l'essentiel du risque.

La base légale. Chaque traitement doit reposer sur un fondement : exécution d'un contrat, obligation légale, intérêt légitime, consentement. Si personne dans l'entreprise ne sait dire lequel s'applique à ton usage de l'IA, tu n'as pas de base légale, tu as une habitude.

La transparence. Les personnes concernées (clients, prospects, salariés) doivent savoir que leurs données passent par des outils d'IA. Une ligne dans la politique de confidentialité, une mention dans un contrat, une information au CSE quand ça touche les salariés. C'est le principe le moins coûteux à respecter et le plus souvent oublié.

La sous-traitance. Dès qu'un fournisseur traite des données pour ton compte, il te faut un contrat de sous-traitance (le fameux DPA, pour Data Processing Agreement) qui précise les finalités, la durée de conservation, les mesures de sécurité, la localisation des serveurs et les sous-traitants ultérieurs. Les grands fournisseurs d'IA en proposent un standard, téléchargeable en deux clics. Le télécharger et le classer, c'est l'affaire d'une demi-heure. Ne pas l'avoir, c'est la première chose qu'on te demandera en cas de contrôle ou d'audit client.

Comment mettre son usage de l'IA en conformité : la checklist

Passons à l'opérationnel. Voici ce que je fais poser en priorité, par ordre d'impact sur effort.

1. Une règle de non-collage, écrite en une page. Ce qui ne va jamais dans un chat public : données de santé, données bancaires, identifiants, documents RH nominatifs, contrats clients, code propriétaire, listes de clients complètes. Une page, pas un règlement que personne ne lira.
2. Un canal officiel unique. Une licence entreprise ou un accès API, avec le contrat signé, et une consigne claire : on n'utilise pas son compte perso pour le travail. Sans canal officiel simple d'accès, tu crées du shadow IT, pas de la conformité.
3. Le registre des traitements mis à jour. Tu en as un (c'est obligatoire au-delà de certains seuils, et recommandé partout). Ajoute une ligne par usage IA : finalité, données concernées, fournisseur, base légale, durée de conservation. Une heure de travail qui vaut une assurance.
4. Un choix d'hébergement gradué. Tout ne mérite pas la même exigence. Contenu marketing public : n'importe quel outil sérieux fait l'affaire. Données clients ou RH : privilégie un hébergement européen ou un fournisseur avec des garanties solides. Sur la logique de stack européenne, voir migrer sa stack vers l'Europe.
5. Une revue trimestrielle. Une demi-heure pour lister les nouveaux outils IA arrivés dans l'entreprise, vérifier les contrats et supprimer ce qui ne sert plus. C'est là que tu attrapes les dérives avant qu'elles ne deviennent des incidents.

Et pour que tout ça tienne dans le temps, un préalable qui n'a rien de juridique : documenter tes process avant de les automatiser. On ne sécurise bien que ce qu'on a déjà écrit.

Les trois pièges IA et RGPD qui coûtent le plus cher

Piège 1 : croire que l'anonymisation suffit toujours. Il y a une différence de nature entre pseudonymiser (remplacer un nom par un identifiant, opération réversible, la donnée reste personnelle et reste soumise au RGPD) et anonymiser (rendre la ré-identification impossible, la donnée sort du champ du règlement). Or l'anonymisation réelle est difficile : un jeu de données croisant secteur, taille d'entreprise, ville et poste peut ré-identifier une personne sans jamais citer son nom. Considère par défaut que tu pseudonymises. C'est déjà très utile, mais ça ne t'exonère de rien.

Piège 2 : ignorer le transfert hors Union européenne. Beaucoup d'outils IA traitent les données aux États-Unis ou ailleurs. Un transfert hors UE n'est pas interdit, mais il doit être encadré (décision d'adéquation, clauses contractuelles types, mesures complémentaires). Le point aveugle typique : tu as vérifié ton fournisseur principal, mais pas les outils no-code intercalés dans ton workflow, dont chacun voit passer la donnée. La conformité se juge sur la chaîne complète, pas sur le maillon que tu as regardé.

Piège 3 : confondre conformité et paralysie. C'est le plus coûteux, et paradoxalement le plus fréquent. Interdire l'IA à toute l'entreprise « en attendant d'y voir clair » ne supprime pas le risque, il le déplace vers les comptes personnels des collaborateurs, où tu n'as plus aucune visibilité ni aucun contrat. Le RGPD n'a jamais interdit d'utiliser un outil : il impose de savoir ce que tu fais, de le documenter et de le dire. Ce sont des exigences de rigueur, pas d'abstention.

Conformité IA : pourquoi c'est devenu un argument commercial

Traiter le sujet IA et RGPD comme une contrainte défensive, c'est passer à côté de l'essentiel. Dans le B2B, la conformité est en train de devenir un argument commercial mesurable.

Chaque fois qu'un client grand compte t'envoie un questionnaire sécurité avant de signer, chaque fois qu'un service achats demande où sont hébergées les données, tu gagnes ou tu perds des semaines de cycle de vente selon ta capacité à répondre vite plutôt qu'après trois relances. Une entreprise qui sait dire précisément quels outils IA elle utilise, sur quelles données, avec quels contrats, ferme des deals que ses concurrents traînent.

Le bon ordre des opérations est simple. D'abord tu cartographies ce qui existe déjà, et tu seras surpris du nombre d'outils IA déjà en circulation chez toi. Ensuite tu poses le canal officiel et les contrats. Puis tu documentes. Enfin tu ouvres largement l'usage, parce que tu sais ce qui circule. Sur les 280 entreprises que nous avons accompagnées depuis 2012, celles qui avancent le plus vite sur l'IA ne sont jamais les plus permissives : ce sont celles qui ont posé ce cadre au début, une bonne fois.

Et une fois le cadre en place, tu peux enfin te concentrer sur la vraie question, celle que la conformité masque souvent : est-ce que ces outils produisent un résultat mesurable ? C'est le sujet de mesurer le ROI de l'IA en entreprise. Parce que le pire scénario, ce n'est pas d'être non conforme. C'est d'être parfaitement conforme sur des outils qui ne servent à rien.

Dernier rappel, et il est important : tout ce qui précède est une grille de lecture opérationnelle, pas un avis juridique. Si tu traites des données sensibles, si tu opères dans la santé, la finance ou le secteur public, ou si tu envisages d'entraîner un modèle, fais valider ton dispositif par un DPO ou un avocat spécialisé. Le coût de cette validation est ridicule comparé à celui d'un incident.

À retenir. Le RGPD ne régule pas l'IA, il régule le traitement de données personnelles : les principes sont les mêmes que pour ton CRM, seuls le volume, la destination et l'opacité changent. Avant tout, sache où partent tes données (chat grand public, offre entreprise ou hébergement souverain, ce sont trois régimes très différents). Applique quatre principes : minimisation, base légale identifiée, transparence, contrat de sous-traitance signé. Pose une règle de non-collage en une page, un canal officiel unique, un registre à jour. Méfie-toi de trois pièges : la pseudonymisation prise pour de l'anonymisation, les transferts hors Union européenne cachés dans ta chaîne d'outils, et la paralysie qui pousse tes équipes vers leurs comptes perso.

Ce contenu n'est pas un conseil juridique. Sur les traitements sensibles, fais valider ton dispositif par un DPO ou un avocat spécialisé.