ChatGPT en entreprise : les risques RGPD et nLPD, et comment les couvrir vraiment
ChatGPT en entreprise pose un vrai sujet RGPD et nLPD. Le risque n'est pas l'outil, c'est le shadow AI. Les garde-fous concrets à poser avant de déployer.
La question revient dans presque chaque comité de direction qu'on accompagne : « Peut-on utiliser ChatGPT en entreprise sans se mettre en faute au regard du RGPD et de la nLPD ? » La réponse honnête tient en une phrase : oui, à condition de cesser de raisonner sur l'outil et de commencer à raisonner sur l'usage. Le risque numéro un n'est pas ChatGPT. C'est le fait que vos collaborateurs l'utilisent déjà, sans cadre, avec leurs comptes personnels, sur des données qui ne devraient jamais quitter votre périmètre. C'est ce qu'on appelle le shadow AI, et c'est lui qui crée l'exposition réelle.
L'erreur classique est binaire : soit on interdit, soit on laisse faire. L'interdiction ne tient pas, parce que l'outil est trop utile et trop accessible — le shadow AI revient par la fenêtre dès qu'on ferme la porte. Le laisser-faire expose à des fuites de données personnelles et à des manquements de conformité dont vous n'avez même pas connaissance. La troisième voie, la seule qui tienne en pratique, consiste à fournir un usage conforme et une couche de données maîtrisée. Voici comment on instruit ce sujet, dans la pratique BUMPSLAB, pour une PME ou ETI franco-suisse.
Le vrai risque, ce n'est pas l'outil, c'est le shadow AI
Prenons un cas anonymisé représentatif : une fiduciaire romande dont plusieurs collaborateurs collaient des extraits de comptes clients, des noms et des montants dans ChatGPT grand public pour accélérer la rédaction de notes de synthèse. Aucune décision interne, aucune charte, aucune visibilité de la direction. Du point de vue de la donnée, c'est exactement le scénario à proscrire : des données personnelles (et potentiellement des données financières sensibles) transmises à un service tiers, hors UE et hors Suisse, sous des conditions que personne n'a lues.
Ce n'est pas un cas isolé. Le shadow AI est la norme silencieuse dans la plupart des organisations en 2026. Les collaborateurs ne sont pas malveillants : ils cherchent à gagner du temps, et l'outil le permet. Le problème est que cet usage se fait dans un angle mort de gouvernance. La direction croit que « on n'utilise pas l'IA », alors que des dizaines de prompts contenant des données clients partent chaque jour vers des serveurs sur lesquels l'entreprise n'a aucune visibilité.
Takeaway : le risque RGPD et nLPD d'un usage non cadré de ChatGPT n'est pas théorique ni futur. Il est déjà actif dans votre organisation, et son ampleur est proportionnelle à votre absence de cadre.
Qui est responsable, qui est sous-traitant : la grille à poser d'abord
Avant tout choix d'outil, il faut clarifier la qualification juridique du traitement. Le RGPD et la nLPD reposent sur la même distinction structurante.
Votre entreprise est responsable de traitement : c'est vous qui décidez de la finalité (pourquoi vous traitez des données) et des moyens (comment). Quand un collaborateur soumet une donnée client à un assistant IA dans le cadre de son travail, c'est l'entreprise qui en répond, pas le collaborateur.
Le fournisseur de l'IA (OpenAI pour ChatGPT) agit comme sous-traitant dès lors qu'il traite ces données pour votre compte. Cette qualification n'est valide que si elle est encadrée par un accord de sous-traitance — un DPA (Data Processing Agreement) au sens du RGPD, ou son équivalent au sens de la nLPD. Sans DPA signé, vous n'avez aucune base contractuelle pour confier des données personnelles au service. C'est précisément ce qui manque dans le scénario du shadow AI : un compte personnel sur ChatGPT grand public n'est couvert par aucun DPA professionnel.
À cela s'ajoutent les questions classiques du RGPD, qu'on retrouve à l'identique côté nLPD :
- La base légale. Sur quel fondement traitez-vous ces données via l'IA ? Intérêt légitime, exécution contractuelle, obligation légale, consentement. Si elle n'est pas écrite, elle n'existe pas.
- La finalité. L'usage de l'IA est-il compatible avec la finalité pour laquelle les données ont été collectées ? Réutiliser des données client commercial pour entraîner ou alimenter un assistant peut constituer un détournement de finalité.
- La minimisation. Vos collaborateurs transmettent-ils le strict nécessaire, ou collent-ils le dossier entier « pour que l'IA ait du contexte » ? La minimisation est l'un des leviers les plus efficaces et les plus simples à activer.
- Les transferts hors UE / hors Suisse. OpenAI traite des données aux États-Unis. Un transfert hors de l'EEE ou hors de Suisse nécessite un encadrement : clauses contractuelles types, mécanisme d'adéquation, ou option de résidence des données quand le fournisseur la propose.
Nous détaillons ces garde-fous, y compris l'articulation avec l'AI Act, dans notre guide dédié AI Act, RGPD, nLPD : les garde-fous à poser avant le premier pilote IA. Le présent article ne constitue pas un conseil juridique : il pose les garde-fous opérationnels que la direction peut instruire avant de mobiliser un DPO ou un conseil.
Grand public, Team, Enterprise : ce qui change vraiment pour la donnée
C'est le point que la plupart des décideurs comprennent de travers, et c'est aussi le plus important. Toutes les versions de ChatGPT ne traitent pas les données de la même façon. La distinction est décisive du point de vue du RGPD et de la nLPD.
| Version | Données utilisées pour l'entraînement | Encadrement contractuel | Résidence des données | Niveau de risque |
|---|---|---|---|---|
| Grand public (gratuit / Plus) | Potentiellement oui, selon les réglages du compte | Aucun DPA professionnel | Hors UE / hors Suisse par défaut | Élevé en usage pro |
| Team | Non par défaut (entrées non utilisées pour l'entraînement) | DPA disponible | Options selon offre, à vérifier | Modéré, à encadrer |
| Enterprise | Non par défaut | DPA, engagements renforcés | Options de data residency (dont UE) | Maîtrisable si bien cadré |
Trois précisions s'imposent. D'abord, sur le grand public : selon les réglages, les conversations peuvent être utilisées pour améliorer les modèles. C'est désactivable, mais cela suppose que le collaborateur connaisse et active le bon paramètre — ce qui n'arrive jamais à l'échelle d'une organisation. C'est la raison structurelle pour laquelle le shadow AI est dangereux.
Ensuite, sur Team et Enterprise : par défaut, les données soumises ne sont pas utilisées pour entraîner les modèles, un DPA est disponible, et des options de rétention et de résidence existent. C'est ce qui rend un usage professionnel défendable.
Enfin, et c'est essentiel : les conditions exactes évoluent et doivent être vérifiées contractuellement. Ne vous fiez pas à une page marketing ni à un article de blog (y compris celui-ci) pour qualifier votre exposition. La source de vérité est le DPA et les conditions de service que vous signez, à la date où vous les signez.
AI Act : où se situe un assistant IA généraliste
L'AI Act européen ajoute une couche de classement par niveau de risque, distincte du RGPD. Un assistant IA généraliste de type ChatGPT, utilisé pour rédiger, résumer ou rechercher, relève dans la plupart des cas du risque limité : les obligations principales sont des obligations de transparence — informer les utilisateurs qu'ils interagissent avec une IA, et marquer certains contenus générés.
Le sujet devient autre dès que l'usage bascule dans une catégorie haut risque au sens de l'AI Act : tri de candidatures et gestion RH, scoring crédit, certains usages dans l'accès à des services essentiels. Ce n'est plus l'outil qui détermine le régime, c'est l'usage. Le même ChatGPT mobilisé pour reformuler un e-mail (risque limité) et pour pré-filtrer des CV (potentiellement haut risque) ne relève pas des mêmes obligations.
Takeaway : pour qualifier votre exposition AI Act, ne regardez pas le logo de l'outil, regardez la finalité métier. Un assistant généraliste est rarement haut risque par nature — il le devient par l'usage qu'on en fait.
Les garde-fous concrets à poser AVANT de déployer
C'est ici que se joue la vraie conformité. Voici les sept garde-fous que nous posons systématiquement avant qu'un assistant IA touche une donnée de production. Aucun n'est technique en premier lieu : ce sont des décisions de gouvernance.
- DPA signé. Pas de donnée personnelle sans accord de sous-traitance en vigueur avec le fournisseur, et vérification de la chaîne de sous-traitance ultérieure.
- Charte d'usage. Un document court, lu et signé par les collaborateurs, qui dit ce qui est autorisé et ce qui ne l'est pas. C'est le levier le plus efficace contre le shadow AI.
- Périmètre de données autorisées. Lister explicitement les catégories de données que l'on peut soumettre et celles que l'on ne peut jamais soumettre (données sensibles, secret bancaire, données de santé, données identifiantes non nécessaires).
- Pseudonymisation. Avant de soumettre un dossier, retirer ou remplacer les identifiants directs. Souvent, l'IA n'a pas besoin du nom du client pour reformuler une note.
- Journalisation et traçabilité. Savoir qui a soumis quoi, quand, dans quel cadre. C'est ce qui transforme une affirmation (« on est conforme ») en preuve.
- Registre des traitements. Inscrire l'usage de l'assistant IA dans le registre du responsable de traitement, comme tout autre traitement de données personnelles.
- Formation. Un cadre non expliqué est un cadre contourné. La formation est ce qui fait passer la charte du statut de document au statut de réflexe.
Takeaway : six de ces sept garde-fous ne demandent aucun développement. Ils demandent une décision, un document et une communication. Le mur de la conformité IA est méthodologique et organisationnel avant d'être technique.
Souveraineté CH / UE : quand la donnée ne doit pas quitter le périmètre
Pour certaines organisations — fiduciaires, assureurs, banques, industries sous contraintes contractuelles — la question dépasse le DPA : la donnée ne doit tout simplement pas sortir d'un périmètre UE ou suisse. C'est là que la souveraineté entre en jeu.
Deux leviers existent. Le premier : les options de résidence des données proposées sur les offres Enterprise, qui permettent de localiser le traitement dans l'UE. Le second, plus radical : recourir à un modèle hébergeable en UE ou en Suisse. Mistral, par exemple, propose des modèles performants en français avec des options d'hébergement souverain, ce qui en fait une alternative pertinente quand la résidence des données est non négociable. Claude et GPT restent d'excellents modèles, mais le critère souveraineté peut, dans certains dossiers, primer sur la pure performance.
Le choix n'est pas binaire. On peut très bien réserver l'assistant généraliste aux usages sans données sensibles, et router les traitements sensibles vers un modèle souverain via une couche de données maîtrisée. Nous comparons ces options dans Mistral vs Claude : le bon choix pour le français et la Suisse, et nous traitons le cadre réglementaire spécifique au secteur financier suisse dans Souveraineté IA en Suisse et attentes FINMA 2026.
Takeaway : la souveraineté n'est pas un absolu binaire. C'est un curseur, à régler par catégorie de données, pas par dogme « tout souverain » ou « tout cloud US ».
Cadrer un usage conforme, vite : ce qui marche en pratique
Bonne nouvelle pour les décideurs pressés : cadrer un usage conforme ne prend pas des mois. Un assureur que nous avons accompagné est passé d'un usage shadow AI non maîtrisé à un usage cadré et défendable en trois semaines. Le chemin n'a rien d'exotique : licence Team/Enterprise avec DPA, charte d'usage diffusée et signée, périmètre de données autorisées défini avec le métier, formation d'une demi-journée par équipe, et journalisation activée.
La séquence qui fonctionne tient en quatre temps. Constater l'usage réel (le shadow AI existant, qu'on cartographie sans culpabiliser). Cadrer : choisir la version, signer le DPA, écrire la charte, définir le périmètre de données. Outiller : fournir l'accès officiel et, si la sensibilité l'exige, une couche de données maîtrisée qui filtre et pseudonymise avant l'envoi au modèle. Former : transformer le cadre en réflexe.
C'est exactement le travail qu'instruit notre AI Use Case Audit en 5 jours : il identifie les usages réels, qualifie l'exposition RGPD et nLPD, et produit le cadre opérationnel sans le transformer en analyse juridique exhaustive. Pour les organisations qui veulent aller au-delà de l'assistant générique et bâtir une couche de données maîtrisée — connecter l'IA à leurs propres documents et systèmes de façon contrôlée — c'est l'objet de notre solution Atlas, qui s'appuie sur des standards d'intégration ouverts (voir MCP expliqué simplement).
Takeaway : trois semaines suffisent à passer d'un usage interdit-mais-pratiqué à un usage autorisé-et-tracé. Le facteur limitant n'est jamais la technique, c'est la décision de cadrer.
Ce qu'il faut éviter
Trois écueils reviennent systématiquement.
Interdire et croire le problème réglé. Une note interne « ChatGPT est interdit » ne supprime pas l'usage, elle le rend invisible. Le shadow AI ne disparaît pas, il se cache mieux. Vous perdez la seule chose qui vous protégeait : la visibilité.
Acheter Enterprise et croire la conformité achetée. La licence Enterprise pose une bonne base contractuelle, mais elle ne pose ni la charte, ni le périmètre de données, ni la traçabilité, ni la formation. L'outil n'est pas la conformité.
Reporter le cadrage « après le déploiement ». Les choix de cadrage — version, périmètre de données, pseudonymisation, journalisation — déterminent votre exposition. Les poser après coup, c'est devoir reprendre l'usage déjà installé, avec des collaborateurs qui ont déjà pris leurs habitudes.
Si vos collaborateurs utilisent déjà ChatGPT — et ils l'utilisent — la vraie question n'est pas « faut-il l'autoriser ? » mais « comment fournir un cadre conforme avant que le shadow AI ne crée une exposition que vous découvrirez trop tard ? ». L'AI Use Case Audit en 5 jours pose ce cadre : usages réels cartographiés, exposition RGPD et nLPD qualifiée, garde-fous opérationnels prêts à déployer. Sans verbiage juridique, sans interdiction stérile, sans hype.
