Un salarié ouvre l’assistant interne de son entreprise à 23 h 40 et écrit une question qu’il ne poserait pas à un collègue. Elle porte sur un congé, et sur la crainte que son responsable apprenne pourquoi il le demande. Pour la formuler correctement, il doit donner quelques détails : que depuis six mois il dort quatre heures par nuit, qu’il ne trouve plus de raison de se lever, qu’il arrive de plus en plus tard le matin.
Cet assistant tourne sur un contrat API avec Zero Data Retention. Cela veut dire que la conversation n’est pas conservée après le traitement, qu’aucune personne du fournisseur ne pourra la lire, qu’elle ne finira dans aucun jeu de données d’entraînement. Une demi-seconde plus tard, il ne reste plus rien. Du point de vue de la conservation, nous sommes très près de la condition idéale : la donnée est passée et n’a laissé aucun résidu.
Et pourtant, en passant, le système a conclu quelque chose sur lui.
Je ne dis pas encore quoi, car c’est exactement le point. La question que nous avons appris à poser en trente ans de protection des données est : qui peut voir cette conversation ? La réponse, ici, est personne. C’est une excellente réponse, et elle est insuffisante.
Le 19 août, hier, OpenAI a annoncé quelque chose qui rend cette insuffisance concrète au lieu de philosophique.
Ce qui a été annoncé hier
Le 19 août, OpenAI a communiqué deux choses distinctes, et mieux vaut les tenir séparées, car la première est une confirmation commerciale et la seconde une idée architecturale.
La première : Zero Data Retention continuera d’être proposé aux clients API éligibles, y compris sur les modèles de frontière. En ZDR, selon la définition de l’entreprise, prompts et réponses ne sont pas conservés après le traitement de la requête, le contenu des clients n’est pas disponible au personnel pour révision, et les données des clients enterprise ne servent pas à entraîner les modèles sauf opt-in explicite. C’est une promesse adressée aux entreprises, pas aux utilisateurs grand public, et la différence compte : qui écrit à un chatbot public n’achète pas cette garantie.
La seconde : l’avant-première de Private Safety Processing. Elle naît d’un problème réel, que les entreprises de frontière n’ont pas inventé pour le marketing. À mesure que les modèles prennent en charge des travaux plus longs et plus autonomes, les systèmes de sécurité doivent reconnaître des risques invisibles dans une requête isolée mais lisibles dans la forme d’une séquence. Une question isolée est presque toujours inoffensive. Trente questions en deux jours, prises ensemble, peuvent ne pas l’être. Sauf que, pour regarder une séquence, il faut la conserver, et la conserver est précisément ce que le ZDR promet de ne pas faire.
Private Safety Processing tente de séparer les deux. Dans les configurations ZDR, le contenu reste sur l’infrastructure contrôlée par le client, ou réside sur des serveurs OpenAI sous forme chiffrée avec des clés que le client détient et dont le fournisseur n’a pas de copie. L’analyse des motifs a lieu là-dedans. Quand quelque chose se déclenche, ce qui sort du périmètre est un signal restreint, indiquant le type et la gravité de l’activité sans exposer les prompts et les réponses sous-jacents. Le client instruit l’alerte sur ses propres systèmes ; il peut ensuite décider de remettre volontairement du matériel, pour contester une décision ou pour collaborer à une enquête sur un abus.
Le déploiement est annoncé pour septembre, accompagné d’un white paper technique. Tant que ce document n’est pas publié, il serait incorrect d’en tirer des conclusions fortes : nous ne savons pas où tourne exactement le classificateur, quelle est la granularité du signal, ce qu’il advient des faux positifs. Qui évalue des fournisseurs a appris à distinguer une architecture d’un communiqué, et ceci se tient pour l’instant à mi-chemin.
Même ainsi, la chose intéressante est déjà lisible. Le fournisseur peut savoir : cette séquence appartient probablement à la catégorie X. Sans savoir : voici les phrases que l’utilisateur a écrites. Les deux connaissances ne sont pas la même chose, et c’est la seconde que la réglementation sur la protection des données a appris à bien gouverner.
Il vaut la peine de noter que l’industrie se divise sur ce point. Anthropic conserve pendant trente jours prompts et sorties de ses Covered Models, la catégorie à laquelle elle applique les politiques les plus strictes, déclarant le faire pour soutenir son travail sur la sécurité, et cela sur toutes les plateformes où ces modèles sont proposés. Ce sont deux réponses différentes à la même tension, et aucune des deux n’est évidente.
Concédons tout à l’objection
Avant de soutenir qu’il se passe quelque chose de nouveau, il faut éviter une exagération très courante : raconter comme découverte d’aujourd’hui une chose que le droit connaît depuis longtemps.
L’inférence ne naît pas avec les modèles de langage. La publicité comportementale déduit des intérêts depuis vingt ans. Le credit scoring déduit une fiabilité économique. Les algorithmes antifraude déduisent une probabilité de comportement illicite. Le profilage est par définition la production de caractéristiques personnelles à partir de comportements distincts de ces caractéristiques.
Le RGPD a été écrit assez large pour comprendre tout cela. L’article 4, point 4, définit le profilage comme toute forme de traitement automatisé visant à évaluer des aspects personnels, et les lignes directrices européennes distinguent depuis des années entre données fournies par la personne concernée, données observées et données dérivées ou inférées, c’est-à-dire produites par le responsable en analysant d’autres données.
Mais la défense la plus forte du droit en vigueur ne tient pas aux définitions. Elle tient à trois arrêts de la Cour de justice, plus radicaux qu’on ne les résume d’habitude.
Le 4 juillet 2023, dans Meta contre Bundeskartellamt, la Cour a établi que l’interdiction sur les données sensibles n’exige aucune déclaration explicite. Si un opérateur collecte les visites d’un utilisateur à des sites et applications liés à des catégories particulières de données et les rattache à son compte, il traite des données sensibles, indépendamment du fait que ces informations aient été déclarées. Révéler, pour la Cour, comprend déduire. C’est exactement le principe dont le monde de l’inférence a besoin, et il a été écrit il y a trois ans.
Le 7 décembre 2023, dans l’affaire SCHUFA, la Cour est allée encore plus au fond. Le calcul automatisé d’un taux de probabilité sur la capacité d’une personne à honorer des engagements de paiement futurs constitue lui-même un processus décisionnel automatisé au sens de l’article 22, quand de ce taux dépend de façon décisive la conclusion, l’exécution ou la cessation d’un rapport contractuel par le tiers auquel il est communiqué. Pas la délibération de la banque : le score. Le droit européen a déjà reconnu que l’inférence peut être le véritable acte décisoire, et que celui qui la produit ne peut pas se cacher derrière celui qui l’utilise.
Le 4 octobre 2024, dans Schrems contre Meta, la Cour a établi que le principe de minimisation empêche d’agréger, d’analyser et de traiter à des fins publicitaires les données collectées dans et hors de la plateforme sans limite de temps et sans distinction de type. Et elle a ajouté qu’avoir déclaré publiquement son orientation sexuelle en une occasion n’autorise pas à traiter d’autres données relatives à cette orientation.
Il y a enfin l’avis 28/2024 du CEPD, adopté le 17 décembre 2024, qui contient une intuition semblable appliquée aux modèles. Pour qu’un modèle entraîné sur des données personnelles puisse être dit anonyme, dit le Comité, doivent être insignifiantes tant la probabilité d’en extraire directement des données personnelles, en tenant compte d’attaques comme la membership inference et l’inversion du modèle, que la probabilité que les interrogations restituent des données personnelles identifiables, même involontairement.
Il serait donc faux d’écrire que nous avons soudainement découvert une catégorie inconnue du droit. Le droit européen possède les outils conceptuels et les a déjà utilisés. Qui soutient le contraire n’a d’ordinaire pas lu les arrêts.
Le changement est ailleurs, et il est plus inconfortable parce qu’il ne se résout pas en légiférant.
Ce qui change vraiment
Trois choses changent ensemble : l’échelle, le coût et la temporalité.
L’échelle. Un système de credit scoring infère une chose. Un système publicitaire infère quelques dizaines d’attributs issus d’un catalogue défini à l’avance. Un foundation model n’a pas de catalogue. Une seule conversation peut simultanément suggérer niveau d’instruction, état émotionnel, profession, capacité économique, zone géographique probable, orientation politique, condition médicale, situation familiale et intentions futures, et non parce que quelqu’un aurait construit neuf classificateurs. La capacité de produire ces catégories existe dans le modèle même qui répond à une question sur les congés. Elle n’a pas besoin d’être activée : elle devrait, à la rigueur, être empêchée.
Le coût. Pendant des années, la protection des données a pu compter sur une hypothèse implicite et raisonnable : savoir coûte. Il fallait accumuler des observations, construire un profil, le tenir à jour, et chaque étape laissait des traces que l’on pouvait réguler. Avec des modèles très capables, cette relation s’affaiblit. Dix signaux faibles peuvent produire une inférence forte. Une photographie révèle plus que ce qu’elle montre. Un motif temporel révèle une routine. Une phrase permet d’estimer bien davantage que son contenu sémantique explicite.
La temporalité, qui est la partie vraiment nouvelle. Le profilage classique produisait un profil, c’est-à-dire un état : un enregistrement quelque part disant « cette personne appartient au segment 47 ». Cet état pouvait être inspecté, contesté, effacé. Un modèle généraliste peut ne jamais archiver la proposition « cette personne appartient à la catégorie X ». Il peut la reconstruire, identique, chaque fois qu’on la lui demande.
Cette formulation mérite d’être retenue, car elle est le centre de tout le raisonnement : la connaissance cesse d’être un état persistant et devient une capacité persistante de produire un état.
Ce n’est pas une subtilité philosophique. Elle a des conséquences pratiques immédiates sur l’effacement, la rectification et la conservation.
Le paradoxe de la pièce vide
Imaginons une machine idéale, construite par quelqu’un de parfaitement bonne foi.
Elle reçoit le journal intime d’une personne. Elle le traite. Aucun être humain ne peut le lire. Il n’est pas écrit sur disque. Il ne sert à entraîner quoi que ce soit. Aussitôt après, il est effacé de façon irréversible, et l’effacement est vérifiable.
Avant de l’effacer, pourtant, la machine produit une ligne : probabilité 92 % que cette personne appartienne à la catégorie A. Et elle ne conserve que celle-là.
Avons-nous protégé la donnée ? Techniquement oui, et pas de façon cosmétique : presque toutes les métriques de risque que nous utilisons aujourd’hui donneraient un résultat positif. Avons-nous protégé la personne ? Cela dépend entièrement de ce qu’est A et de ce qui se passe ensuite.
Un système peut minimiser de façon excellente la possession de la donnée et maximiser simultanément la connaissance qu’il en extrait. Ce sont deux minimisations différentes, et nous les avons traitées comme une seule parce que, dans le monde des bases de données, elles l’étaient presque toujours.
Supposons qu’un assureur ne reçoive jamais un dossier médical. Il reçoit seulement un score de santé, calculé localement sur le téléphone de la personne, avec une architecture qu’aucun cryptographe ne critiquerait. L’assureur ne possède pas de données cliniques. Il possède la seule information qui l’intéressait vraiment, et sous la forme la plus commode possible.
Et c’est là que l’inférence devient, dans certains cas, plus dangereuse que la donnée. Un historique d’achats demande une interprétation, et l’interprétation coûte, peut se tromper, peut se discuter. L’étiquette « difficulté financière probable » est déjà prête à être utilisée par n’importe qui, sans compétence et sans frottement. Un ensemble de messages est ambigu. Un score de « propension à quitter son poste » transforme cette ambiguïté en décision, et la livre sous une forme que le destinataire n’a aucun intérêt à remettre en question.
Une inférence, très souvent, est une donnée déjà convertie en pouvoir opérationnel.
Une inférence fausse ne se corrige pas
Il y a un second problème : les inférences n’ont même pas besoin d’être exactes pour produire des effets.
Quand une base de données contient une adresse erronée, le droit a une réponse simple et efficace : on corrige l’adresse. Le droit de rectification suppose un fait enregistré, identifiable, remplaçable.
Quand un système conclut, en combinant des milliers de variables, qu’une personne a une probabilité élevée d’insolvabilité, que rectifie-t-on ? Quel champ ? Quel poids ? Quelle corrélation ? Quelle représentation latente ? Il n’y a pas de case fausse. Il y a un jugement produit, et un jugement produit n’a pas la structure grammaticale d’une erreur matérielle.
Le droit européen s’en est aperçu et prend une autre voie, qui passe par la contestabilité plus que par la correction. Le 27 février 2025, dans l’affaire Dun & Bradstreet, la Cour de justice a établi que l’article 15, paragraphe 1, sous h du RGPD oblige le responsable à expliquer, de façon concise, transparente et intelligible, la procédure et les principes effectivement appliqués pour obtenir un résultat déterminé à partir des données personnelles de cette personne. Pas la formule, pas le code source : le procédé réellement suivi. Et elle a ajouté que le secret des affaires n’est pas une objection absolue, car cette information sert à permettre à la personne d’obtenir l’intervention humaine, d’exprimer son point de vue et de contester la décision.
C’est une réponse sérieuse, et elle reste bien plus difficile à appliquer à un modèle généraliste qu’à un système de scoring. Un système de scoring a des variables, des poids et un seuil. On peut expliquer, péniblement, ce qui a pesé. Un modèle qui produit une classification comme effet secondaire de sa compréhension linguistique n’a pas de procédure en ce sens, et la tentation de répondre par une description générique de l’architecture sera très forte.
J’ajoute un élément qui complique encore. Le droit à l’effacement est construit sur l’idée qu’il existe quelque chose à effacer. Si le système n’a jamais archivé la proposition à mon sujet, mais qu’il est capable de la reproduire sur demande, il n’y a rien à supprimer, et rien non plus qui soit resté. Effacer un état est possible. Effacer une capacité, non.
Apple avait déjà déplacé la frontière
Qui a regardé Private Cloud Compute au moment de sa présentation a vu la même frontière arriver d’une autre direction.
Apple a fixé cinq exigences pour PCC, et il vaut la peine de les lire comme un document d’ingénierie politique plus que de sécurité. Les données personnelles doivent servir exclusivement à satisfaire la requête et ne doivent être disponibles à personne d’autre que l’utilisateur, pas même au personnel d’Apple, ni conservées, y compris par le logging ou le débogage. Les garanties doivent pouvoir être imposées techniquement, ce qui signifie que tous les composants doivent pouvoir être contraints et analysés. Il ne doit exister aucune interface privilégiée permettant au personnel opérationnel de contourner les garanties. Un attaquant ne doit pas pouvoir viser une personne précise sans tenter de compromettre le système entier. Et les chercheurs en sécurité doivent pouvoir vérifier que les garanties correspondent aux promesses publiques.
La conséquence technique la plus éloquente est celle que l’on cite d’ordinaire en passant : les nœuds PCC n’incluent ni shells distants ni mécanismes de débogage interactif, et le système ne contient même pas de mécanisme de logging general-purpose. Seuls des logs et des métriques prédéfinis, structurés et soumis à audit peuvent sortir du nœud.
Arrêtons-nous un instant sur cette phrase, car elle contient toute la nouveauté. Apple n’a pas promis de ne pas regarder. Elle a retiré les instruments avec lesquels on regarde d’ordinaire, et a fait de l’ensemble des choses qui peuvent sortir du nœud une liste fermée, décidée à l’avance et vérifiable.
La frontière de confiance s’est déplacée. Avant, je devais faire confiance à l’administrateur système qui promettait de ne pas lire. Maintenant, je fais confiance à une architecture qui établit quels calculs sont admis et quelles informations peuvent traverser le périmètre. C’est une promesse bien plus forte que n’importe quelle politique de confidentialité, parce qu’elle est falsifiable.
OpenAI, avec une architecture différente et pour un problème différent, explore la même frontière conceptuelle : à l’intérieur du périmètre on calcule, à l’extérieur sort une liste fermée de signaux.
La privacy, sous cette forme, cesse d’être une promesse et devient une propriété du système. Et si elle devient une propriété du système, elle devient aussi vérifiable, négociable, certifiable. Pour qui travaille sur la compliance comme architecture, c’est une nouvelle énorme, et pour une fois c’est une bonne nouvelle.
Avec une conséquence que personne n’a encore bien affrontée : la liste de ce qui peut sortir de l’enclave est le véritable document de gouvernance de toute l’architecture, et c’est la partie dont nous parlons le moins.
De la confidentialité à la calculabilité
La sécurité informatique a toujours parlé de confidentialité : un sujet non autorisé ne doit pas pouvoir lire la donnée. C’est une propriété claire, définie sur un objet.
Avec les systèmes qui calculent à l’intérieur d’un périmètre fermé, il faut une propriété plus subtile, définie non sur l’objet mais sur les opérations : un sujet non autorisé ne doit pas pouvoir obtenir certains calculs sur la donnée.
Posséder un dossier médical et posséder un oracle auquel je peux poser des questions sur le dossier médical ne sont pas la même chose. Mais les résultats peuvent se ressembler bien plus qu’il ne nous arrange de l’admettre.
Si je ne peux pas télécharger la table des salaires de l’entreprise mais que je peux interroger un système en demandant si une certaine personne gagne plus de 80 000 euros, puis plus de 90 000, puis plus de 95 000, après quelques questions j’ai reconstruit une part significative de l’information sans avoir jamais reçu un seul enregistrement. C’est le vieux problème du contrôle statistique de la divulgation, celui qui a produit la confidentialité différentielle, et les modèles de langage l’aggravent immensément : parce que l’interrogation n’a plus besoin d’être numérique, parce qu’il n’est pas nécessaire de connaître le schéma de la base, et parce que le nombre de questions sensées que l’on peut poser n’est plus énumérable à l’avance.
La propriété à gouverner, alors, n’est pas seulement l’accès. C’est la calculabilité : quelles fonctions peuvent être calculées sur ces données, avec quelle précision, combien de fois, avec quelles sorties, pour le compte de qui.
C’est une question que presque aucune checklist de compliance ne pose aujourd’hui, et que n’importe quel architecte de systèmes reconnaît immédiatement comme la bonne question.
La finalité appliquée à ce que l’on peut savoir
Ici, le RGPD redevient étonnamment contemporain, car le principe qui résiste le mieux au choc est aussi l’un des plus anciens : la limitation des finalités.
Les données se collectent pour un but. Le problème, c’est qu’un foundation model est précisément une machine capable de réutiliser le même input pour un nombre énorme de finalités différentes, et de le faire sans que personne l’ait programmé pour cela.
Une conversation fournie pour une assistance client peut techniquement servir à inférer le sentiment. Le sentiment peut devenir propension à l’abandon. La propension peut devenir priorité commerciale. La même conversation peut suggérer une vulnérabilité économique, et la vulnérabilité économique est le genre d’information sur laquelle se construisent des prix différents pour des personnes différentes. Aucune de ces étapes n’exige une nouvelle collecte, et la capacité technique existe même quand l’organisation n’a aucune intention de l’utiliser.
Il s’ensuit que la privacy by design doit déplacer son objet. Non plus seulement empêcher que les données finissent dans le mauvais système, mais empêcher que des calculs non autorisés soient exécutés à l’intérieur du bon système.
Appelons cela, avec prudence, minimisation des inférences. Ce n’est pas une catégorie autonome du RGPD et il n’est pas utile de l’inventer comme telle. C’est une exigence architecturale qui découle de la combinaison de principes déjà existants, et elle a le mérite d’être une question que l’on peut poser dès la conception : quelles inférences sont strictement nécessaires ?
Un assistant de prise de rendez-vous médicaux a besoin de la spécialité demandée, de la disponibilité et de l’identité nécessaire pour finaliser le rendez-vous. De la conversation, il peut déduire l’état d’anxiété de la personne, sa situation économique, la gravité perçue du problème, la probabilité qu’elle annule. Il ne devrait pas le faire, et la différence pratique tient tout entière ici : il ne suffit pas de ne pas utiliser ces inférences. Certains classificateurs, sorties, couches de persistance et outils devraient être inaccessibles à la fonction applicative, pas simplement désactivés par une politique que quelqu’un peut changer en un après-midi.
Qui pense qu’il s’agit d’une fantaisie réglementaire devrait relire l’article 5 de l’AI Act, applicable depuis le 2 février 2025. Il interdit les systèmes qui infèrent les émotions d’une personne sur le lieu de travail et dans les établissements d’enseignement à partir de données biométriques, sauf exceptions médicales et de sécurité restreintes. Et il interdit la catégorisation biométrique qui déduit la race, les opinions politiques, l’appartenance syndicale, les convictions religieuses ou philosophiques, la vie sexuelle ou l’orientation sexuelle.
Ce sont deux interdictions qui ne concernent pas la collecte. Elles concernent ce qu’il est licite de déduire, et elles valent indépendamment de la façon dont les données sont arrivées là et du temps qu’elles y restent. Le législateur européen a déjà écrit, en un seul article, la première norme qui interdit des inférences déterminées en les nommant. À la même conclusion, la Cour de justice était arrivée par voie interprétative ; ici, c’est du texte. Il a choisi le périmètre le plus étroit possible, et il a bien fait, car interdire l’inférence en général rendrait inutilisable une bonne part de l’intelligence artificielle. Mais le précédent conceptuel existe.
La bonne question, alors, n’est pas de savoir si une inférence est interdite. C’est : cette inférence était-elle nécessaire, prévisible et légitime au regard de la finalité pour laquelle la donnée a été fournie ? C’est la limitation des finalités appliquée à l’espace des connaissances productibles.
Ce n’est pas être reconnu, c’est être classé
On pourrait penser que le problème se dissout en retirant l’identité. C’est une illusion confortable et il faut la démonter.
Un système peut ne pas savoir qui je suis et en savoir assez pour me traiter différemment. Un algorithme publicitaire n’a pas besoin de mon nom s’il possède un identifiant pseudonyme accroché à un profil suffisamment précis. Un agent peut ne pas connaître mon identité d’état civil et conclure que j’appartiens à une catégorie de risque, modifiant le service en conséquence : réponses plus prudentes, limite plus basse, une vérification supplémentaire, un prix différent.
L’anonymat répond à la question : savent-ils qui je suis ? La privacy inférentielle répond à une autre : que peuvent-ils décider que je suis ?
Il y a enfin une dernière asymétrie temporelle qui rend la conservation une métrique insuffisante. La donnée peut vivre deux cents millisecondes. La conséquence peut durer des années.
La conversation n’est pas conservée. Pendant le traitement, elle génère un score. Le score modifie une décision. La décision entre dans le CRM, dans le système de ticketing, dans le dossier, dans l’historique de la relation. Le prompt a disparu au moment prévu par le contrat. Sa conséquence est devenue histoire institutionnelle, et personne ne pourra plus remonter à la façon dont elle y est arrivée.
Si nous dessinons cette chaîne, la donnée la plus sensible de tout le processus n’est pas le premier élément. C’est le second.
Safety et privacy tirent en sens opposés
Revenons à OpenAI, car le conflit qu’elle tente de résoudre est authentique et ne doit pas être imputé à l’entreprise comme une faute.
Plus les modèles deviennent capables, plus ceux qui les construisent ont besoin de s’apercevoir que quelqu’un tente de les utiliser pour nuire. Pour s’en apercevoir, il faut observer des comportements. Mais plus on observe, plus on accumule d’information sur les personnes. La sécurité pousse vers la surveillance, la protection des données vers la minimisation, et c’est une tension que les bonnes intentions d’aucune des deux parties ne dissolvent.
La réponse intéressante n’est pas de choisir entre privacy et safety. C’est de transformer le choix en problème architectural : exécuter une partie de la surveillance à l’intérieur d’un périmètre où le fournisseur ne reçoit pas le contenu, et ne faire sortir de ce périmètre que ce qui sert à la fonction de sécurité. C’est la même logique que les secure enclaves, le confidential computing, le private information retrieval et, en général, les privacy-enhancing technologies. Elles n’éliminent pas le compromis : elles en changent la forme, et une forme différente suffit parfois.
Il y a un détail de l’annonce qui mérite plus d’attention qu’il n’en reçoit, et c’est qui reçoit l’alerte. Dans le dessin d’OpenAI, le signal restreint arrive à l’entreprise, le client instruit sur ses propres systèmes, et décide éventuellement de partager du matériel. Ce n’est pas seulement un choix de privacy. C’est une réallocation de la responsabilité : le fournisseur garde la classification, le client garde l’enforcement. Qui achète ces services ferait bien de s’en apercevoir avant la signature, car cela signifie qu’une partie du travail de sécurité qu’il pensait avoir acheté reste la sienne.
Ne pas voir ne signifie pas ne pas décider
Voici le contrepoids, sans lequel tout ce que j’ai écrit jusqu’ici devient un argument de vente.
Il est très facile de transformer ces architectures en une nouvelle génération de privacy washing, et même ceux qui les ont construites de bonne foi seront tentés, car la phrase est trop belle pour ne pas être utilisée : nous ne voyons jamais vos données.
Cela peut être littéralement vrai. Et cela peut être sans rapport avec ce qui arrive à la personne. Si le système peut classer, filtrer, refuser, limiter, signaler ou modifier un service en fonction de ce qu’il a déduit, l’entreprise continue d’exercer un pouvoir substantiel sur cette personne. Le fait qu’aucun être humain n’ait lu la phrase ne réduit pas d’un gramme l’effet de la catégorie qui en est sortie.
La question ne peut donc pas s’arrêter à la confidentialité. Elle doit arriver à : quels effets l’inférence peut-elle produire ?
Un système privacy-preserving qui discrimine reste discriminatoire. Un système cryptographiquement irréprochable qui déduit à tort une condition sensible reste un problème, et pour qui le subit, c’est exactement le même problème qu’avant. Une secure enclave protège la donnée des administrateurs. Elle ne protège pas la personne de la fonction exécutée dans l’enclave.
C’est la distinction qui tient ensemble les deux moitiés du problème : la sécurité du traitement ne coïncide pas avec sa licéité.
Imaginons la machine parfaite. Personne ne peut en observer les entrées, personne ne peut en altérer le code, personne ne peut en extraire les données. Et la machine prend des décisions injustes. Sa perfection cryptographique ne résout rien, et rend même la contestation plus difficile, car toute demande de regarder à l’intérieur rencontrera une réponse techniquement irréprochable : regarder à l’intérieur est précisément ce que le système a été conçu pour empêcher.
La privacy des prochaines années devra donc tenir ensemble deux propriétés que nous traitons séparément parce qu’elles tirent en sens opposés. Confidentialité des entrées, qui exige de l’opacité. Responsabilité sur les inférences, qui exige de la transparence. Nous devons empêcher des sujets non autorisés de voir la donnée, et savoir en même temps quelles inférences sont produites, dans quelle finalité et avec quelles conséquences. C’est une tension formidable et je ne connais personne qui l’ait résolue.
Cela vaut aussi pour le transfert de confiance qu’impliquent ces architectures, et il faut le dire honnêtement. Avant, je devais faire confiance à l’administrateur. Maintenant, je dois faire confiance au matériel, à l’attestation, au code, à la chaîne d’approvisionnement, à la fonction exécutée, à la justesse de la sortie et à la politique qui établit ce qui peut sortir. La confiance n’a pas disparu. Elle s’est distribuée sur une surface plus large et, c’est la bonne partie, sur une surface que l’on peut inspecter.
Du diagramme des données au diagramme des inférences
De là vient la partie utile à ceux qui travaillent, et c’est un changement de forme avant d’être un changement de contenu.
J’ai écrit en avril que l’AIPD est un genre, pas un formulaire, c’est-à-dire une forme d’écriture avec une structure reconnaissable et non un questionnaire à remplir. Si c’est un genre, alors il peut évoluer, et pour les systèmes d’IA il le doit.
Une AIPD pour un système d’intelligence artificielle ne peut pas se limiter à décrire catégories de données, base légale, destinataires, durées de conservation, sous-traitants et transferts internationaux. Tout cela est nécessaire et tout cela est construit autour de l’idée que le risque habite une archive.
Elle doit commencer à modéliser le flux des inférences. Sur l’entrée : qui peut la lire, où elle est déchiffrée, combien de temps elle survit. Sur les représentations : si des embeddings sont créés, s’ils persistent, s’ils sont rattachables à une personne, ce qui est tout sauf évident puisqu’un embedding n’est ni une donnée brute ni une inférence déclarée. Sur l’inférence : quelles classifications sont produites, lesquelles sont nécessaires à la finalité déclarée, lesquelles constituent des données personnelles et lesquelles touchent des catégories particulières. Sur l’action : si l’inférence modifie le comportement du système, si elle produit une décision, si elle est montrée à une personne. Et enfin sur la conservation, à la fin et non au début : quelle partie de la chaîne survit à la requête.
Du diagramme de flux des données au diagramme de flux des inférences. Ce n’est pas un exercice académique : c’est le seul moyen de s’apercevoir que le risque d’un système peut tenir entièrement dans un élément qu’aucun modèle d’AIPD en circulation aujourd’hui ne demande de décrire.
Il s’ensuit aussi une évaluation des fournisseurs différente, et c’est la partie immédiatement utilisable par qui achète du logiciel. La question classique, utilisez-vous nos données pour entraîner le modèle, reste nécessaire et ne suffit plus.
Il faut y ajouter au moins trois familles de questions. Où l’inférence est exécutée et qui peut accéder à l’entrée pendant le traitement, ce qui est une question d’architecture et non d’intentions. Quelles données sont enregistrées, quelles représentations dérivées persistent et pour combien de temps, et si elles sont associables à une identité. Et enfin quelles classifications automatiques sont produites, quels signaux peuvent quitter le périmètre de traitement, s’ils alimentent des décisions ou des activités d’enforcement, et par quel mécanisme une personne peut contester une inférence erronée.
La dernière est celle que presque aucun contrat ne prévoit aujourd’hui, et celle sur laquelle, si les arrêts des trois dernières années indiquent une direction, on se disputera.
Dire génériquement « nous ne conservons pas les données » devient ambigu si nous n’avons pas défini ce que nous considérons comme une donnée. Entrée brute, représentations dérivées, inférences, classifications de sécurité, télémétrie, logs lisibles par un humain, sorties, état persistant : ce sont huit choses différentes, elles peuvent avoir huit destins différents, et dans presque tous les contrats que j’ai lus deux d’entre elles sont nommées.
Le second territoire
Il y a un dernier endroit où cette distinction change le tableau, et c’est la souveraineté numérique.
Nous parlons continuellement de souveraineté sur la donnée : où elle est conservée, dans quelle juridiction, sur quel cloud, gérée par quelle société. Ce sont des questions indispensables et j’ai passé des mois à écrire qu’elles ne suffisent pas, car la souveraineté n’habite pas dans le data center.
Faisons l’expérience. Toutes les données d’un hôpital européen restent physiquement en Europe, dans un environnement de confidential computing géré par un fournisseur européen. Un modèle américain y est exécuté. Les entrées ne quittent jamais le territoire, le fournisseur du modèle ne peut pas les lire, l’attestation est vérifiable et le registre des calculs admis est public.
Avons-nous atteint la souveraineté ? Sur la donnée, plausiblement oui. Sur la logique qui transforme cette donnée en catégorie clinique et cette catégorie en priorité de liste d’attente, pas nécessairement.
Car cinq questions restent ouvertes qu’aucune localisation ne résout : qui contrôle le modèle, qui établit les catégories que le modèle peut produire, qui peut mettre à jour la fonction et avec quel préavis, qui vérifie que les inférences sont correctes sur une population européenne, et qui décide de ce qui peut sortir du périmètre.
Appelons cela souveraineté sur les inférences, et plaçons-la à côté de celle sur les données plutôt qu’à sa place. Ces dernières années, nous avons construit toute une politique technologique européenne autour de la localisation, du contrôle et de la disponibilité de la donnée, et ce n’était pas une erreur. L’intelligence artificielle ajoute un second territoire, qui est celui de la production du jugement.
Un modèle reçoit des faits et produit des interprétations. Il reçoit des signaux et produit des catégories. Il reçoit une histoire et produit une prévision. C’est là qu’une part croissante du pouvoir numérique sera exercée, et ce pouvoir peut exister même quand aucun être humain n’a jamais vu la donnée d’origine.
Ce n’est pas seulement où vit la donnée qui compte. C’est là où naît le jugement.
Ce que nous ne lui avons jamais dit
Quelqu’un, arrivé jusqu’ici, pourrait objecter que je construis un problème trop abstrait, et que tout cela n’est que le RGPD existant appliqué avec plus de précision.
Il aurait en bonne partie raison, et mieux vaut le concéder jusqu’au bout car c’est la position la plus solide de toutes. Il ne faut pas un nouveau droit à la privacy. Il ne faut pas un RGPD pour les inférences. Limitation des finalités, minimisation, exactitude, transparence, nécessité, régime du profilage et des décisions automatisées, privacy by design : les outils existent, et les arrêts que j’ai cités montrent qu’ils fonctionnent mieux que nous ne le pensions. Qui réclame une nouvelle loi demande d’ordinaire, sans le savoir, de recommencer de zéro une discussion que l’Europe a déjà gagnée.
La lacune n’est probablement pas normative. Elle est architecturale.
Nous continuons à concevoir compliance et systèmes d’information autour des bases de données, alors que la valeur informationnelle s’est déplacée dans des calculs qui durent deux cents millisecondes et ne laissent rien derrière eux. Nous continuons à demander où sont les données à des systèmes dont le risque principal est ce qu’ils savent déduire. Le problème n’est pas d’écrire une nouvelle loi. C’est de mettre à jour ce que nous considérons comme une surface de traitement.
Je reviens au salarié de 23 h 40.
Pendant des années, nous avons pensé la privacy avec la métaphore de la porte. Nos données sont dans une pièce, et la question est de décider qui a la clé. La cryptographie a rendu la porte plus résistante. La minimisation a tenté de mettre moins de choses dans la pièce. Le RGPD a établi qui pouvait entrer, pour combien de temps et pour quel motif. Ce sont de vraies conquêtes et il ne faut pas les brader par effet de mode.
L’intelligence artificielle met une machine dans la pièce. Nous pouvons fermer la porte parfaitement et ne laisser entrer personne. Nous pouvons détruire tout ce qui s’y trouvait quelques millisecondes plus tard, et nous pouvons le prouver. Mais avant de le faire, nous pouvons demander à la machine qui s’y trouve de nous dire ce qu’elle a compris.
Et ce qui en sort peut être plus important que tout ce que nous avions cherché à protéger.
Cela ne rend pas inutiles les conquêtes de la privacy traditionnelle. Cela les rend insuffisantes si nous les interprétons de façon purement matérielle, comme si le risque était fait de fichiers.
La privacy du monde des bases de données protégeait surtout ce que nous avions révélé. La privacy de l’intelligence artificielle devra protéger aussi ce qu’une machine peut déduire sans que nous le lui ayons jamais dit. C’est un passage de la possession de la donnée au gouvernement de la connaissance, et cela change qui doit répondre de quoi.
Le salarié a demandé comment fonctionne un congé. Le système, dans la demi-seconde où sa phrase a existé, a établi une probabilité sur une condition qu’il n’avait pas déclarée, et personne n’a demandé si cette probabilité servait à quelque chose.
Personne ne l’a lue. Elle n’a pas été conservée. Elle n’entraînera rien.
Et maintenant, c’est la seule chose qui reste de cette conversation.
Ce qu'il faut retenir
Le 19 août 2026, OpenAI a confirmé Zero Data Retention sur les modèles de frontière et présenté en avant-première Private Safety Processing. En ZDR, le contenu reste sur l’infrastructure du client ou chiffré avec des clés que le client détient ; quand l’analyse automatique repère un motif d’abus, OpenAI reçoit un signal restreint portant le type et la gravité de l’activité, tandis que le client instruit l’alerte sur ses propres systèmes. Le déploiement et un white paper technique sont annoncés pour septembre, le jugement définitif doit donc être suspendu.
L’inférence n’est pas une découverte récente et le droit européen la gouverne déjà. En juillet 2023, dans Meta contre Bundeskartellamt, la Cour de justice a établi que l’interdiction sur les données sensibles s’applique même quand la caractéristique protégée n’a pas été déclarée mais reste déductible des données collectées et rattachées au compte. En décembre 2023, dans l’affaire SCHUFA, que le calcul d’un taux de probabilité est lui-même un processus décisionnel automatisé quand de ce taux dépend de façon décisive la conclusion, l’exécution ou la cessation d’un rapport contractuel par le tiers auquel il est communiqué. En février 2025, dans Dun & Bradstreet, que l’accès doit fournir la procédure et les principes effectivement appliqués, pas une formule.
Ce qui change avec les foundation models, c’est l’échelle et surtout la temporalité. Le profilage traditionnel construisait un profil persistant en accumulant des observations ; ici l’inférence peut naître au moment où la donnée traverse le système et être produite de nouveau, identique, à la requête suivante. La connaissance n’est plus un état archivé : c’est une capacité à le reconstruire. On n’efface pas une capacité.
Le paradoxe pratique : un système peut parfaitement minimiser la possession de la donnée et maximiser la connaissance qui en est extraite. Un assureur qui ne reçoit jamais un dossier médical mais seulement un score de santé calculé sur le téléphone ne possède pas les données cliniques et possède la seule chose qui l’intéressait. Une inférence est souvent une donnée déjà convertie en pouvoir opérationnel : un historique d’achats demande une interprétation, l’étiquette « difficulté financière probable » est prête à l’emploi.
La conséquence opérationnelle, c’est qu’une AIPD pour un système d’IA ne peut pas s’arrêter au diagramme de flux des données. Il faut un diagramme des inférences : quelles représentations dérivées persistent, quelles classifications sont produites, lesquelles sont nécessaires à la finalité, quels signaux quittent le périmètre de traitement, s’ils sont associés à une identité, s’ils déclenchent une décision et comment contester une inférence erronée. La question « utilisez-vous nos données pour entraîner le modèle ? » reste nécessaire et ne suffit plus.
Questions & réponses
Qu’a exactement annoncé OpenAI le 19 août 2026 ?
Deux choses distinctes. La première est la confirmation que Zero Data Retention restera disponible pour les clients API éligibles, y compris sur les modèles de frontière : prompts et réponses ne sont pas conservés après le traitement, ne sont pas accessibles au personnel pour révision, et les données des clients enterprise ne servent pas à entraîner les modèles sauf opt-in explicite. La seconde est l’avant-première de Private Safety Processing, un mécanisme conçu pour reconnaître des motifs d’abus à travers plusieurs interactions liées sans donner au personnel d’OpenAI l’accès au contenu sous-jacent. Dans les configurations ZDR, le contenu reste sur l’infrastructure du client ou sur des serveurs OpenAI, chiffré avec des clés que le client détient ; quand l’analyse automatique détecte quelque chose, OpenAI reçoit un signal restreint indiquant le type et la gravité de l’activité, et l’alerte est instruite par le client sur ses propres systèmes. Le déploiement et un white paper technique sont attendus en septembre.
Le RGPD ne couvre-t-il pas déjà les inférences et le profilage ?
Si, et plus solidement qu’on ne le croit. L’article 4, point 4, définit le profilage comme un traitement automatisé visant à évaluer des aspects personnels ; les lignes directrices européennes distinguent depuis des années les données fournies, observées et dérivées ou inférées. La jurisprudence est allée plus loin. Le 4 juillet 2023, dans Meta contre Bundeskartellamt, la Cour de justice a établi que l’interdiction sur les données sensibles s’applique même quand la caractéristique protégée est seulement déductible. Le 7 décembre 2023, dans l’affaire SCHUFA, que le calcul automatisé d’un taux de probabilité est déjà un processus décisionnel automatisé au sens de l’article 22 quand de ce taux dépend de façon décisive la conclusion, l’exécution ou la cessation d’un rapport contractuel. Le 4 octobre 2024, dans Schrems contre Meta, que la minimisation empêche d’agréger des données sans limite de temps et sans distinction de type. La lacune, s’il y en a une, n’est pas dans les normes. Elle est dans la façon dont nous concevons les systèmes et rédigeons les analyses d’impact.
Que signifie « minimisation des inférences » ?
Ce n’est pas une catégorie autonome du RGPD et le terme demande de la prudence. Il exprime une exigence architecturale qui découle des principes existants : si la limitation des finalités lie l’usage des données à la finalité de leur collecte, et si la minimisation impose de ne traiter que le nécessaire, alors un système capable de produire vingt classifications sur une personne quand la finalité en demande une est déjà en tension avec les deux. La différence pratique, c’est qu’il ne suffit pas de ne pas utiliser les dix-neuf autres : elles devraient être inaccessibles à la fonction applicative, pas seulement désactivées par une politique. L’AI Act contient déjà un exemple de cette logique, puisque son article 5 interdit certaines inférences indépendamment de la façon dont les données ont été collectées.
Si une inférence est fausse, comment exercer le droit de rectification ?
C’est le point le plus difficile techniquement. Rectifier suppose un fait enregistré : une adresse erronée se corrige. Un jugement probabiliste produit en combinant des milliers de variables n’a pas de champ à corriger, et dans un modèle généraliste il peut même ne pas exister comme état mémorisé, puisqu’il est reconstruit à chaque interrogation. La voie que prend le droit européen passe par la contestabilité plutôt que par la correction : l’arrêt Dun & Bradstreet du 27 février 2025 a établi que l’article 15, paragraphe 1, sous h impose d’expliquer la procédure et les principes effectivement appliqués, de façon concise et intelligible, et que le secret des affaires n’est pas une excuse absolue, car cette information doit permettre à la personne d’obtenir l’intervention humaine et d’exprimer son point de vue.
Une architecture comme Private Cloud Compute ou Private Safety Processing résout-elle le problème ?
Elle en résout une part importante et en laisse une autre à découvert. Apple a conçu Private Cloud Compute en supprimant les shells distants et le logging general-purpose des nœuds, en n’admettant que des logs et des métriques prédéfinis, structurés et vérifiés, et en rendant le logiciel inspectable par les chercheurs. C’est une promesse bien plus forte qu’une politique de confidentialité, car elle déplace la confiance de l’opérateur qui promet de ne pas regarder vers une architecture qui techniquement ne le lui permet pas. Mais la fonction exécutée dans l’enclave continue de calculer sur la donnée : c’est son but. Une secure enclave protège la donnée des administrateurs, elle ne protège pas la personne de la fonction qui tourne à l’intérieur. La sécurité du traitement ne coïncide pas avec sa licéité, et c’est pour cela que confidentialité de l’input et responsabilité sur l’inférence doivent être tenues ensemble.
L'auteur
