Ce que votre SaaS envoie réellement à OpenAI quand vos utilisateurs cliquent sur « Résumer »

Le scénario s'est joué dans une grande entreprise au printemps 2023. Un ingénieur d'un constructeur de semi-conducteurs cherchait un bug dans son code. Il a demandé l'aide d'une IA générative grand public. Pour cela, il a copié-collé un fragment de code source propriétaire dans la zone de saisie. La réponse l'a aidé. Le problème, c'est que le code, lui, est parti. Selon Bloomberg, c'est l'un des trois incidents qui ont conduit le groupe Samsung à interdire l'usage des outils d'IA générative externes à ses équipes en mai 2023, après une enquête interne révélant trois fuites de données confidentielles en moins d'un mois.

L'incident a marqué les esprits dans les directions de la sécurité. Mais il a éclipsé une réalité plus discrète, et plus structurelle : dans la majorité des éditeurs SaaS B2B qui ont intégré une IA générative depuis 2023, ce même scénario se rejoue chaque jour, à grande échelle, sans qu'aucun ingénieur ne fasse de copier-coller. C'est l'éditeur lui-même qui transmet le contenu de ses utilisateurs — y compris leurs données personnelles — à un fournisseur d'IA tiers. Souvent hors de l'Union européenne. Presque toujours sans visibilité du DPO du client final.

Cette tribune raconte ce qui se passe vraiment dans le payload envoyé à l'API d'IA, pourquoi c'est la responsabilité de l'éditeur, ce qu'on peut faire pour rétablir la chaîne — et ce que nous venons de déployer chez ESSN sur ce terrain précis.

1. Ce que le payload contient quand l'utilisateur ne s'en doute pas

Imaginez un module de tutorat IA dans une plateforme de formation. Un apprenant tape : « Bonjour, je suis Marie Dupont (marie.dupont@cabinet-x.fr), j'ai du mal à comprendre la séance d'hier sur les déclarations URSSAF. Peux-tu me résumer le chapitre ? » L'éditeur SaaS, dans une implémentation naïve, prend ce message tel quel, l'enveloppe dans une requête HTTPS, et l'envoie à l'API OpenAI, Anthropic, Mistral ou autre. Avec un système prompt qui ajoute typiquement le nom de l'organisation cliente, l'identifiant interne du cours, l'identifiant interne de l'apprenant, et parfois l'historique des conversations précédentes.

Côté juridique, ce message contient au minimum quatre catégories de données personnelles au sens de l'article 4 du RGPD : un nom, un email professionnel, un identifiant interne (apprenant ou cours), et un comportement (« j'ai du mal à comprendre »). Côté technique, ce payload sort du périmètre maîtrisé de l'éditeur : il transite vers un sous-traitant qui n'a pas signé d'accord direct avec le client final.

La question qui se pose alors est simple : qui est responsable de ce transfert ?

2. Le triangle juridique qui rend la responsabilité non délégable

Trois instruments s'appliquent simultanément, et c'est leur convergence qui rend la situation intenable pour l'éditeur qui ne fait rien.

Le Règlement européen général sur la protection des données (RGPD, Règlement (UE) 2016/679) impose à l'article 28 une cascade contractuelle stricte : un sous-traitant qui sous-traite à son tour doit obtenir l'autorisation écrite préalable du responsable de traitement, doit imposer contractuellement les mêmes obligations à son sous-sous-traitant, et reste pleinement responsable en cas de manquement. En pratique, en 2026, peu d'éditeurs SaaS qui intègrent OpenAI, Anthropic ou Mistral via API ont ce contrat propre signé directement par le responsable de traitement (le client). Les conditions générales de service ne suffisent pas.

Le RGPD pose ensuite à l'article 44 et suivants un cadre strict pour les transferts de données personnelles hors de l'Union. La décision Schrems II de la Cour de justice de l'Union européenne (CJUE, affaire C-311/18, 16 juillet 2020) a invalidé le Privacy Shield et imposé aux exportateurs de données la mise en place de garanties supplémentaires effectives. Pour les fournisseurs d'IA américains, la combinaison du CLOUD Act et de la jurisprudence européenne maintient un risque permanent. L'enjeu n'est pas théorique : la Commission nationale de l'informatique et des libertés (CNIL) a publié en juin 2025 ses Recommandations finales sur le développement des systèmes d'IA, qui recommandent expressément l'anonymisation des données d'entraînement et, lorsque l'anonymisation n'est pas possible, une pseudonymisation rigoureuse avec séparation des clés de mapping.

Enfin, le Règlement européen sur l'intelligence artificielle (AI Act, Règlement (UE) 2024/1689), entré en vigueur le 1^er août 2024, voit ses obligations principales — dont l'article 50 sur la transparence — s'appliquer le 2 août 2026. Cet article impose aux fournisseurs et aux déployeurs d'informer les personnes concernées qu'elles interagissent avec un système d'IA, et de marquer les contenus générés. Or, marquer un contenu généré par IA n'a de sens que si l'on peut documenter ce qui a été envoyé en entrée, par qui, et avec quelle base juridique. Sans pipeline d'anonymisation traçable, la conformité au 2 août 2026 sera très difficile à démontrer en audit.

« La pseudonymisation ne supprime pas le caractère personnel des données et la réglementation actuelle continue de s'appliquer. Mais lorsqu'elle est rigoureuse — détection systématique, séparation des clés, journalisation — elle réduit fortement la surface d'exposition et permet de démontrer la minimisation. » — Synthèse des recommandations CNIL, Développement des systèmes d'IA — Recommandations finales, 2025

3. L'anonymisation côté éditeur : un pattern technique simple, mais à appliquer partout

L'idée tient en trois étapes. Avant l'envoi à l'API, l'éditeur détecte les données personnelles présentes dans le message — par expressions régulières typées (email, SIRET, IBAN, IP, téléphone, etc.) et par injection contrôlée d'identifiants internes (apprenant, cours, organisation). Il les remplace par des tokens opaques dérivés d'un hachage scopé par session conversationnelle. Le mapping token → valeur réelle est stocké en cache court (typiquement Redis, TTL 24 heures) chez l'éditeur. À la réception de la réponse, l'éditeur opère la substitution inverse, transparente pour l'utilisateur.

L'effet est mécanique. Le fournisseur d'IA reçoit, à la place de « Marie Dupont (marie.dupont@cabinet-x.fr) », quelque chose qui ressemble à « Personne#a3f72e (email#7d11bc) ». Le modèle traite cette information comme une variable contextuelle. Il ne peut ni la corréler avec d'autres sessions (car le scoping change le hash), ni la mémoriser durablement (car le mapping reste chez l'éditeur). En cas d'incident côté fournisseur, ce qui fuite est inutilisable sans la table de mapping. Et la table de mapping, elle, ne quitte pas le périmètre de l'éditeur.

Cette approche n'est pas une innovation. C'est l'application directe de la règle de minimisation de l'article 5.1.c du RGPD à l'IA générative. Elle est explicitement recommandée par la CNIL (Recommandations IA juin 2025), et par l'agence européenne de cybersécurité ENISA dans son rapport Securing Machine Learning Algorithms. Mais elle reste rare dans la pratique des éditeurs SaaS B2B. Il y a deux raisons à cela.

La première est que le pipeline est lourd à mettre en place sur une stack qui a grossi par accumulation. L'IA s'est ajoutée par couches : un module de chat, un autre de tutorat, un troisième de génération de contenu, un quatrième d'analyse. Chaque équipe a câblé son propre point d'entrée vers l'API d'IA, sans pipeline central. La seconde est que les décisions ont souvent été prises par les équipes produit, sans implication systématique du DPO ni du responsable sécurité de l'éditeur.

4. Cas pratique — ce que nous avons fait ce week-end chez ESSN

ESSN édite ESSNAuthor, une plateforme de formation professionnelle (LCMS) avec un assistant IA pédagogique embarqué appelé Lyra. Comme beaucoup, notre stack IA s'était étendue par couches : un chatbot d'aide, un tuteur contextuel par cours, un générateur de slides, un moteur de génération de cours par IA, un module de traduction, un assistant de relations clientèle. Six points d'entrée vers l'API d'IA. Six surfaces potentielles à régulariser.

Le pipeline d'anonymisation était déjà en place sur notre Lyra récent — le module qui exécute des actions dans l'application sur instruction conversationnelle — mais pas sur les six autres flux Lyra. Ce week-end, nous avons étendu le pattern à l'ensemble de la stack. Concrètement, nous avons enrichi notre couche d'abstraction du fournisseur d'IA (ai_provider.chat_completion) avec un paramètre opt-in anonymize_workflow_id. Quand il est fourni, les messages et le system prompt passent par notre module d'anonymisation avant l'appel API, et la réponse texte est désanonymisée avant retour. Le mapping est stocké dans Redis avec un TTL de 24 heures, scopé par identifiant de workflow.

Treize points d'appel ont été migrés en une journée : chat conversationnel, tuteur IA, génération de slides, création de cours par IA en trois variantes (sujet libre, RNCP, document source), pipeline interne de structure et de contenu, génération de flashcards, extraction de charte visuelle, traduction multilingue, analyse Qualiopi, suggestions CRM, rédaction d'outreach, préparation TTS, parcours adaptatifs. Cinq tests unitaires dédiés ont été ajoutés à la suite existante (87 tests verts au total après migration, en parallèle xdist 4 workers).

La validation end-to-end a été faite avec un cas réel. Une demande de génération de cours sur le thème « Cours d'introduction Python pour Pierre Durand (pierre@example.com), niveau débutant, 3 sections » a été soumise via l'API. Le pipeline a tourné en 97 secondes sur le worker dédié, a consommé 26 969 tokens, et a produit un cours structuré avec un titre normalisé (« Introduction à Python pour débutants »), trois sections cohérentes (Découverte de Python — Structures de contrôle — Fonctions et listes), des contenus pédagogiques HTML riches, et des quiz par section. L'inspection automatique du contenu généré a confirmé l'absence de tout token résiduel non désanonymisé et, plus intéressant, l'absence des données personnelles d'entrée dans le contenu pédagogique de sortie : l'IA a normalisé le sujet en cours générique sur Python, ce qui est exactement le comportement attendu pour un système qui ne mémorise pas l'identité de la personne qui a formulé la demande.

5. Le bonus que nous n'avions pas anticipé : la liberté du choix de l'IA

L'effet collatéral le plus utile de ce travail est commercial. Lorsqu'un acheteur B2B en formation professionnelle évalue un éditeur, l'une des premières questions est aujourd'hui : « Avec quelle IA ? Hébergée où ? Conforme à quelle juridiction ? » Sans pipeline d'anonymisation, la réponse est piégeuse. Choisir un fournisseur européen rassure le DPO mais peut limiter les capacités du modèle. Choisir un fournisseur américain ouvre les capacités mais soulève les questions Schrems II et CLOUD Act.

Avec un pipeline d'anonymisation côté éditeur, et — c'est un point important — sans RAG (Retrieval-Augmented Generation) opéré sur les données nominatives privées des clients, ce dilemme se réduit. Les données utilisateurs ne sortent jamais en clair du périmètre de l'éditeur. Le choix du modèle devient un choix d'efficacité technique et de coût, plus un choix juridique forcé. C'est la position dans laquelle nous nous trouvons aujourd'hui : nous pouvons, pour un cas d'usage donné, utiliser Claude (Anthropic), Mistral, GPT, ou un modèle open weights hébergé en propre, sans réécrire le fond juridique de l'offre. Et c'est ce que nous communiquons désormais à nos prospects.

6. Trois actions pour un éditeur qui veut s'aligner avant le 2 août 2026

Pour un éditeur SaaS B2B qui n'a pas encore engagé ce travail, l'application de l'article 50 de l'AI Act le 2 août 2026 est une échéance utile pour structurer le chantier. Trois actions, dans l'ordre.

D'abord, cartographier les points d'entrée de la stack vers l'API d'IA. Il y en a presque toujours plus que ce que les équipes produit imaginent — entre les chats, les générateurs, les transformations de texte automatiques, les analyses de logs avec IA, les classifications, etc. Chaque point d'entrée est une surface RGPD à documenter.

Ensuite, centraliser le pipeline d'anonymisation au niveau de la couche d'abstraction du fournisseur d'IA, pas au niveau de chaque appelant. C'est le seul moyen d'éviter qu'un nouveau module ajouté dans six mois oublie de l'utiliser. Le coût en lignes de code est faible. Le coût en discipline architecturale est réel : il faut interdire les appels directs au SDK du fournisseur en dehors de cette couche.

Enfin, rendre le pipeline visible. Du côté de l'utilisateur final (par un bandeau « Vos données sont anonymisées avant tout envoi à notre fournisseur d'IA »), du côté du DPO du client (par une documentation technique fournie à l'onboarding), et du côté de l'auditeur AI Act (par une journalisation horodatée des appels). La conformité ne se prouve pas par les intentions. Elle se prouve par les traces.

« La promesse de l'IA générative B2B était simple : transformer la productivité de chaque collaborateur. La promesse implicite était plus discrète : ne pas le faire au prix d'une fuite silencieuse des données de l'entreprise vers un sous-traitant que personne n'a explicitement choisi. Tenir cette seconde promesse n'est pas optionnel. C'est la condition pour que la première soit acceptable. »