IA et RGPD : ce que vous avez vraiment le droit de faire avec vos données

Vous collez un extrait de votre CRM dans ChatGPT pour rédiger une relance. Vous branchez un agent sur votre boîte mail. Vous enrichissez des centaines de prospects avec un outil que vous n'avez jamais audité. Et quelque part, une petite voix vous demande si vous êtes 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, votre 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 votre CRM, votre newsletter ou votre fichier Excel.

Autrement dit : si vous savez déjà répondre à la question « ai-je le droit de mettre cette donnée dans ce fichier ? », vous savez 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. Votre donnée quitte votre 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 vos données quand vous promptez un LLM ?

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

1. Le chat grand public gratuit. Vous êtes sur une interface web avec un compte perso. Selon le fournisseur et vos réglages, vos 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 vous. Règle simple : tout ce que vous collez là, considérez que ça pourrait être lu par un humain que vous n'avez 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 votre 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 vous avez acheté, c'est ce que vos gens utilisent réellement le mardi à 16 h.

Avez-vous le droit d'entraîner un modèle sur vos 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 vous l'imaginez.

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 votre intérêt et les droits des personnes. Parfois le consentement, s'il n'y a pas d'alternative.
2. Une information claire. Votre 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 vous pouvez faire autrement.

Et la plupart du temps, vous pouvez 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 votre 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 vous enrichissez un fichier de prospects avec un outil qui vous sort emails et téléphones professionnels, vous traitez des données personnelles que la personne ne vous a jamais transmises. Le RGPD prévoit ce cas : vous devez 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 votre premier email qui explique d'où vous tenez ses coordonnées et comment s'y opposer, plus un lien vers votre 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.
• Votre fournisseur d'enrichissement est un maillon de votre chaîne. S'il a collecté illégalement, votre fichier est contaminé. Vérifiez qu'il documente ses sources et qu'il vous fournit un contrat de sous-traitance.
• Le droit d'opposition doit être réellement opérationnel. Un désabonnement qui ne remonte pas dans votre CRM et dans votre 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 à vos usages IA

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

La minimisation. Vous n'envoyez 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 à votre usage de l'IA, vous n'avez pas de base légale, vous avez 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 votre compte, il vous 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 vous 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, vous créez du shadow IT, pas de la conformité.
3. Le registre des traitements mis à jour. Vous en avez un (c'est obligatoire au-delà de certains seuils, et recommandé partout). Ajoutez 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 vous attrapez 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 vos 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érez par défaut que vous pseudonymisez. C'est déjà très utile, mais ça ne vous 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 : vous avez vérifié votre fournisseur principal, mais pas les outils no-code intercalés dans votre workflow, dont chacun voit passer la donnée. La conformité se juge sur la chaîne complète, pas sur le maillon que vous avez 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ù vous n'avez plus aucune visibilité ni aucun contrat. Le RGPD n'a jamais interdit d'utiliser un outil : il impose de savoir ce que vous faites, 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 vous envoie un questionnaire sécurité avant de signer, chaque fois qu'un service achats demande où sont hébergées les données, vous gagnez ou vous perdez des semaines de cycle de vente selon votre 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 vous cartographiez ce qui existe déjà, et vous serez surpris du nombre d'outils IA déjà en circulation chez vous. Ensuite vous posez le canal officiel et les contrats. Puis vous documentez. Enfin vous ouvrez largement l'usage, parce que vous savez ce qui circule. Sur les 285 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, vous pouvez enfin vous 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 vous traitez des données sensibles, si vous opérez dans la santé, la finance ou le secteur public, ou si vous envisagez d'entraîner un modèle, faites valider votre 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 votre CRM, seuls le volume, la destination et l'opacité changent. Avant tout, sachez où partent vos données (chat grand public, offre entreprise ou hébergement souverain, ce sont trois régimes très différents). Appliquez quatre principes : minimisation, base légale identifiée, transparence, contrat de sous-traitance signé. Posez une règle de non-collage en une page, un canal officiel unique, un registre à jour. Méfiez-vous de trois pièges : la pseudonymisation prise pour de l'anonymisation, les transferts hors Union européenne cachés dans votre chaîne d'outils, et la paralysie qui pousse vos équipes vers leurs comptes perso.

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