Avant de partager : la confidentialité de l’IA exige plus qu’une promesse

Ce que révèlent des incidents bien réels, les règles de relecture humaine et la dernière controverse dans la recherche sur la nécessité d’intégrer la confidentialité à l’infrastructure de l’IA.

Avant de partager

Introduction : la conversation est en train de devenir votre vie

Vous ouvrez un assistant IA pour rédiger une réponse difficile. Vous collez le message, expliquez la relation, et ajoutez quelques détails que vous n’avez partagés nulle part ailleurs. Un autre jour, vous téléversez un contrat, discutez d’une idée encore inachevée, ou connectez votre boîte de réception pour que l’assistant comprenne ce qui requiert votre attention.

Aucune de ces actions ne donne l’impression de publier quoi que ce soit. Vous demandez de l’aide.

Pourtant, ces informations peuvent transiter par une infrastructure, des systèmes de stockage, des processus de relecture et des obligations juridiques largement invisibles depuis la fenêtre de conversation. Un assistant peut sembler personnel bien avant que la manière dont il traite vos données soit à la hauteur de cette attente.

Ma position est simple : la confidentialité de l’IA ne devrait pas dépendre uniquement de ce qu’une entreprise promet de faire après avoir reçu vos informations. Elle devrait aussi dépendre de ce que ses systèmes empêchent d’atteindre le modèle dès le départ. Les politiques comptent. Elles doivent être soutenues par des protections techniques.

J’ai préparé cet article avec le soutien de l’équipe Dvina. Il examine des incidents documentés et les pratiques actuelles chez ChatGPT, Claude, Cursor, Perplexity, Manus, Muse de Meta et Dvina. L’objectif est d’expliquer pourquoi la confidentialité doit devenir une priorité centrale d’ingénierie à mesure que l’IA prend une place plus importante dans nos vies — et comment Dvina aborde cette responsabilité.

Ce que nous apprennent les incidents

L’inquiétude n’est pas hypothétique. Mais différents types de preuves révèlent différents problèmes. Une exposition de données confirmée, une relecture humaine autorisée et une allégation d’usage abusif dans la recherche ne devraient pas être présentées comme s’il s’agissait du même événement.

L’exposition de 2023 chez ChatGPT : une défaillance du système lui-même.

Le 20 mars 2023, un bug logiciel a permis à certains utilisateurs de ChatGPT de voir les titres de l’historique de conversation d’un autre utilisateur actif. OpenAI a indiqué que le premier message d’une conversation nouvellement créée pouvait aussi avoir été visible dans certaines circonstances. Son enquête a identifié une possible exposition d’informations liées au paiement pour 1,2 % des abonnés Plus actifs pendant une période donnée de neuf heures. Les numéros complets de carte n’ont pas été exposés. OpenAI a corrigé le bug et informé les utilisateurs concernés. 1

La leçon n’est pas que la même vulnérabilité est toujours ouverte. C’est qu’un engagement en matière de confidentialité ne peut pas, à lui seul, empêcher un système de renvoyer des informations à la mauvaise personne. L’isolation, les contrôles d’accès et la quantité d’informations identifiables disponibles à exposer comptent tous.

Le contentieux avec le New York Times : la suppression s’est heurtée à une obligation légale.

En 2025, OpenAI a fait l’objet d’une ordonnance judiciaire imposant la conservation de données qui, autrement, auraient été supprimées. Sa mise à jour d’octobre indiquait que l’obligation générale de conserver indéfiniment les nouvelles données avait pris fin le 26 septembre 2025, tandis qu’un ensemble historique limité restait soumis à une conservation légale. L’exigence initiale de conservation excluait certains produits ainsi que les dispositifs de rétention zéro des données. 2

Un développement ultérieur doit être lu séparément : en décembre 2025, Reuters a rapporté qu’un juge avait ordonné à OpenAI de produire 20 millions de journaux de conversations anonymisés dans l’affaire de droit d’auteur, rejetant ses objections et s’appuyant sur la désidentification et des garanties de protection. Il s’agissait d’une mesure de communication de pièces dans le cadre de la procédure, et non de la publication sur internet des conversations privées de tout le monde. 3

Pris ensemble, ces événements montrent pourquoi un paramètre de suppression ne règle pas toutes les questions liées aux informations conservées. Une fois qu’une copie existe, des obligations échappant au contrôle de l’utilisateur peuvent influer sur ce qu’il advient de cette copie. Réduire la conservation inutile modifie cette exposition avant même qu’un litige ne commence.

Examen humain : un accès peut être autorisé sans qu’il y ait violation.

La documentation grand public d’OpenAI autorise explicitement un accès limité par du personnel autorisé et des prestataires de services à des fins précises, notamment les enquêtes de sécurité, l’assistance, les questions juridiques et l’amélioration admissible des modèles. Les indications d’Anthropic pour les consommateurs autorisent du personnel désigné à examiner des conversations pour faire respecter les règles d’usage, avec un accès distinct associé aux retours fournis avec consentement. 4, 8

Il s’agit de voies d’accès documentées, pas de rumeurs. Elles n’établissent pas que des employés lisent chaque conversation. Elles établissent en revanche qu’une interface de chat à l’apparence privée ne constitue pas nécessairement une barrière technique contre l’accès du fournisseur.

La documentation actuelle d’Anthropic ajoute un exemple important côté entreprise. Ses Covered Models désignés imposent une conservation de 30 jours dans certains déploiements qui utilisaient auparavant une rétention zéro des données, avec examen humain encadré et exceptions. Cette règle comporte des limites liées au modèle, à la plateforme et à l’éligibilité ; il ne s’agit pas d’un changement généralisé à tous les produits Claude. Les offres grand public sont décrites comme non affectées, car ces interfaces conservent déjà les entrées et les sorties. 9

La surveillance de la sécurité a une finalité légitime. Le défi d’ingénierie consiste à répondre à cette finalité tout en réduisant au minimum les informations sensibles accessibles aux systèmes de surveillance et aux examinateurs. Une justification fondée sur la sécurité ne fait pas disparaître la question de la vie privée.

La controverse mathématique : une allégation non résolue, un vrai problème de confiance

La controverse de septembre 2026 autour de l’annonce d’OpenAI sur Navier–Stokes a soulevé une autre inquiétude : que se passe-t-il lorsque l’assistant qui aide dans une recherche privée appartient à une entreprise qui mène elle-même ses propres recherches ?

Le différend portait sur des travaux mathématiques inédits et sur l’attribution du mérite. Des reportages ont décrit les mathématiciens Tristan Buckmaster et Levent Alpöge utilisant des outils d’IA dans leurs travaux, et Buckmaster s’interrogeant sur le fait de savoir si leurs documents privés avaient contribué au résultat d’OpenAI. 10

OpenAI conteste cette version. Dans sa réponse publiée, l’entreprise affirme que ni ses chercheurs ni ses agents n’ont vu le travail du duo avant la publication. Dans une mise à jour datée du 10 septembre, elle a en outre déclaré qu’une enquête avait exclu toute influence des prompts Codex de Buckmaster au cours des deux mois précédents, y compris par l’entraînement. Cette déclaration, limitée dans le temps, est plus précise que le récit antérieur figurant dans certains reportages. 11

Les récits publics restent contestés. Les sources examinées ici n’établissent pas de manière indépendante qu’OpenAI a utilisé ces conversations privées pour produire son résultat.

Le différend met néanmoins en lumière une question à laquelle il vaut la peine de répondre clairement : lorsque des personnes confient un travail inachevé à l’IA, qu’est-ce qui protège la valeur informationnelle de ce travail ? Retirer le nom d’un auteur d’une démonstration ne supprime pas la démonstration. Désidentifier une stratégie commerciale ne transforme pas cette stratégie en bien public.

C’est pourquoi une protection forte de la vie privée doit couvrir à la fois l’identité et le contenu. Les utilisateurs devraient pouvoir comprendre si leurs contenus peuvent entrer dans des flux de travail d’entraînement, de recherche, d’évaluation ou de revue — et quels contrôles techniques font respecter ces limites.

Quatre questions qu’il ne faut jamais réduire à une seule

Une grande partie de la confusion vient du fait qu’on traite le terme « privé » comme une propriété unique. En pratique, quatre questions distinctes déterminent ce qu’il advient d’une conversation.

Entraînement : Le contenu peut-il aider à développer ou à améliorer un modèle ? Une option de retrait modifie un usage autorisé de l’information. Elle ne modifie pas nécessairement le fait que l’information a été transmise ou stockée.

Accès : Quels systèmes et quelles personnes peuvent l’examiner ? Le chiffrement pendant la transmission et le stockage est important, mais il n’empêche pas automatiquement un service autorisé de déchiffrer le contenu pour le traiter ou l’examiner.

Conservation : Qu’est-ce qui reste, où, et pendant combien de temps ? Retirer une conversation de l’interface, supprimer des enregistrements de production, faire expirer des sauvegardes et exclure des données des futurs entraînements sont des opérations différentes.

Actions : que peut lire, modifier ou envoyer un assistant connecté ? Une fois qu’il peut agir via vos comptes, la confidentialité dépend aussi des autorisations et des contrôles appliqués aux données sortantes.

Une comparaison utile en matière de confidentialité garde ces questions distinctes. Un abonnement payant, un bouton de désactivation de l’entraînement ou une étiquette de tâche privée ne peuvent pas répondre à eux seuls aux quatre questions.

Comment les services se comparent

Le tableau ci-dessous se concentre sur l’usage individuel, sauf indication contraire. Il résume la documentation examinée, et non les résultats d’un audit de sécurité indépendant.

Service Position sur l’entraînement La frontière distincte à comprendre
ChatGPT Le contenu individuel peut être utilisé à des fins d’amélioration ; les contrôles excluent les nouvelles conversations et les tâches Codex. Temporary Chat est exclu. 4, 5 L’accès autorisé et la conservation restent des questions distinctes. Codex dispose aussi d’un paramètre d’entraînement distinct pour l’environnement complet.
Claude L’amélioration du modèle grand public dépend du choix de l’utilisateur ; les retours et les usages liés à la sécurité obéissent à des règles distinctes. Incognito est exclu de l’amélioration générale. 6 Des exceptions de revue et de conservation s’appliquent toujours. Certains Covered Models commerciaux ont des exigences supplémentaires en matière de conservation. 79
Cursor Le Privacy Mode exclut les données client de l’entraînement de Cursor et décrit des dispositions de non-conservation chez les fournisseurs, sous réserve des exceptions indiquées. 12 Les requêtes transitent toujours par le backend de Cursor. Les enquêtes sur les abus, la mise en cache et les avis propres à certains modèles comptent aussi.
Perplexity La collecte pour l’entraînement de l’IA grand public est activée par défaut, y compris sur Pro et Max ; les utilisateurs peuvent s’y opposer pour l’avenir. 13 Le refus n’empêche pas le traitement nécessaire au fonctionnement du service ou au respect des obligations légales. Les conditions Enterprise sont différentes.
Manus La documentation Team mentionne une option de refus de l’entraînement ; cet examen n’a pas pu vérifier la règle définitive d’entraînement pour le forfait individuel. 15 Le fait que les tâches individuelles soient privées par défaut décrit la visibilité du partage, pas une restriction complète de l’usage par le fournisseur. 14
Meta’s Muse La documentation de lancement décrit un entraînement sur des données d’interaction assainies par défaut, avec une option de refus. 16 Assainir avant l’entraînement n’est pas la même chose que masquer avant l’inférence. Les restrictions imposées aux opérateurs au lancement diffèrent de la Confidential VM prévue.
Dvina Les conversations, fichiers, prompts et données d’espace de travail ne sont pas utilisés pour entraîner des modèles d’IA. 17, 18 Le masquage automatique agit sur une frontière plus en amont : les identifiants personnels détectés sont remplacés avant le traitement par le modèle.

Les détails ci-dessous expliquent où ces distinctions deviennent importantes dans l’usage quotidien.

ChatGPT et Claude : l’action que vous effectuez change la règle.

OpenAI permet aux utilisateurs de désactiver l’entraînement sans supprimer l’historique de chat ordinaire. Temporary Chat modifie encore davantage le traitement d’une conversation, mais sa documentation autorise toujours la revue des abus et décrit un délai de suppression de 30 jours. Les utilisateurs de Codex doivent aussi distinguer le paramètre de contenu à l’échelle du compte de son paramètre distinct pour l’environnement complet. 4, 5

Avec Claude, les retours méritent une attention particulière. Anthropic indique qu’un pouce levé, un pouce baissé ou un signalement de bug peut impliquer la conservation de la conversation associée pendant jusqu’à cinq ans et son utilisation à des fins incluant l’entraînement du modèle. L’activation de l’amélioration générale du modèle permet aussi à certains contenus admissibles et désidentifiés de rester dans les pipelines d’entraînement pendant jusqu’à cinq ans. Ce ne sont pas les mêmes règles que pour la suppression d’un chat ordinaire. 6, 7

Une même personne peut donc prendre plusieurs décisions de confidentialité au sein d’un seul produit sans se rendre compte qu’il s’agit de décisions distinctes. La conception du produit devrait rendre ces différences claires au moment de l’usage.

Cursor et Perplexity : une étiquette produit n’est pas une frontière de traitement.

Le Privacy Mode de Cursor impose des restrictions significatives sur l’entraînement et la conservation par les fournisseurs. Il ne transforme pas l’éditeur en outil local uniquement : Cursor indique que les requêtes transitent toujours par son backend, même avec une clé API fournie par l’utilisateur. Sa documentation décrit aussi une mise en cache temporaire et chiffrée des fichiers, ainsi que des exceptions liées aux enquêtes sur les abus ou à des modèles désignés. 12

Perplexity illustre une distinction différente. Ses comptes Free, Pro et Max relèvent des contrôles d’entraînement grand public, avec une collecte activée par défaut. L’option de refus publiée s’applique aux données collectées par la suite, et non à la suppression rétroactive de données d’entraînement antérieures. Souscrire un abonnement personnel n’en fait pas un compte Enterprise. 13

Dans les deux cas, la vraie question est de savoir ce que changent le mode et le type de compte sélectionnés — et non ce que le nom du produit semble laisser entendre.

Manus et Muse : même des espaces de travail privés ont besoin de frontières explicites.

Manus indique que les tâches individuelles sont privées sauf si elles sont partagées. Sa documentation Team explique aussi que les propriétaires peuvent accéder au contenu des sessions d’équipe. Ce sont des règles de visibilité utiles, mais elles n’établissent pas la politique d’entraînement applicable aux comptes individuels. La page complète de confidentialité de Manus n’a pas pu être récupérée pour cet examen ; cette question reste donc non vérifiée, plutôt que d’être comblée à partir d’un autre forfait. 14, 15

La documentation de lancement de Muse est inhabituellement explicite sur la différence entre restrictions opérationnelles et prévention technique. Meta indique que la Secure VM au lancement limite l’accès du personnel par des politiques, mais ne l’empêche pas lorsque cet accès est nécessaire pour exploiter, assister ou sécuriser le service. Une Confidential VM destinée à empêcher cryptographiquement l’accès des opérateurs était présentée comme à venir et en phase de test limitée. Une protection prévue ne doit pas être comptée comme déjà disponible pour tout le monde. 16

Muse tient aussi les véritables identifiants des connecteurs à l’écart de son agent principal et place les approbations d’action sous une autorité d’autorisation distincte. Cela illustre un principe précieux : un agent ne devrait pas recevoir un secret ou une autorisation simplement parce que cela pourrait être pratique. 16

Déplacer la protection au point situé avant l’exposition

Une exclusion de l’entraînement régit un usage des données. Le masquage modifie les données disponibles pour le traitement. Une conservation restreinte réduit le nombre de copies qui subsistent. Les contrôles d’autorisation limitent ce qu’un agent peut faire. Ces protections sont complémentaires, et l’étape à laquelle chacune intervient compte.

Prenons une demande illustrative : rédiger un message de relance à un client à une adresse e-mail donnée. Le modèle peut avoir besoin de l’objectif, du ton et des engagements pertinents. Il peut ne pas avoir besoin du vrai nom ni de l’adresse du client pour rédiger le message. Remplacer ces identifiants détectés par des espaces réservés avant l’inférence réduit ce que le modèle reçoit tout en préservant la structure utile de la tâche.

C’est différent d’envoyer le texte original en promettant de supprimer les identifiants avant un usage ultérieur.

Le même principe s’étend au-delà des identifiants personnels. La recherche confidentielle exige des contrôles sur le contenu de la recherche lui-même ; les comptes connectés exigent des autorisations strictement limitées ; les enregistrements conservés exigent des durées de conservation définies et des restrictions d’accès applicables. Le masquage de l’identité est un élément de cette conception, et non un substitut à la protection de la substance d’une invention ou d’un document.

Il existe des travaux pertinents dans l’ensemble du secteur. OpenAI a publié un Privacy Filter exécutable localement en avril 2026, et la documentation de Meta sur Muse décrit une isolation technique ainsi qu’une architecture de confidential computing plus robuste en cours de développement. Ces efforts renforcent l’argument en faveur d’une confidentialité intégrée au système. Une publication d’outil ou une feuille de route, toutefois, ne constitue pas en soi la preuve que chaque conversation d’un consommateur bénéficie déjà de la protection correspondante. 16, 19

La norme devrait être la protection dont une personne bénéficie dans le produit qu’elle utilise aujourd’hui.

Dvina : faire de la confidentialité une composante normale de l’interaction

L’approche de Dvina intègre cette protection en amont dans l’expérience de l’assistant. Sa conception documentée détecte localement les informations personnelles sensibles pendant que les personnes saisissent ou téléversent du contenu, chiffre les données personnelles détectées et remplace celles-ci par des espaces réservés avant le traitement par le modèle. Le modèle travaille avec ces espaces réservés plutôt qu’avec les identifiants détectés d’origine. 17, 18

La différence est concrète. Un utilisateur ne devrait pas avoir à interrompre chaque tâche pour supprimer manuellement des noms et des coordonnées, ni à se fier uniquement à une promesse sur ce qui se passera après que le modèle les aura reçus. La protection devrait accompagner l’interaction.

Dvina exclut également les conversations, fichiers, prompts et données d’espace de travail des utilisateurs de l’entraînement du modèle. Cette combinaison est importante : un engagement de non-entraînement limite la réutilisation, tandis que la protection en prétraitement réduit dès le départ les informations personnelles exposées au modèle. 17, 18

D’autres couches soutiennent cette approche. Dvina décrit un stockage chiffré des conversations, une séparation entre les messages stockés et l’identité de l’utilisateur, ainsi que des données hébergées dans l’UE avec des protections de niveau GDPR. Chacune traite une partie différente du processus de traitement, au lieu de demander à une seule préférence d’entraînement de porter toute la charge. 17, 18

La distinction technique est précise : les identifiants personnels détectés sont remplacés dans l’entrée du modèle tandis que la tâche environnante reste disponible pour le traitement. La confidentialité devient une partie du flux de données, plutôt qu’une simple préférence que les utilisateurs doivent penser à gérer.

Pour moi, c’est la direction la plus utile pour l’IA : permettre aux personnes d’apporter un contexte significatif à leur travail tout en concevant le système de manière à révéler moins de leur identité que la tâche ne l’exige.

Conclusion : la confidentialité déterminera jusqu’où les gens laisseront l’IA entrer dans leur vie

Les assistants IA deviennent plus utiles à mesure qu’ils comprennent davantage notre situation. Cela crée une responsabilité : protéger les informations qui sous-tendent cette compréhension. Demander aux gens un accès plus large tout en n’offrant qu’une page de paramètres supplémentaire n’est pas une réponse suffisante.

Les éléments disponibles pointent vers plusieurs risques distincts. Les logiciels peuvent exposer des données d’un compte à l’autre. Les conversations stockées peuvent devenir soumises à des demandes légales. Un examen autorisé peut exister sans faille de sécurité. Des litiges autour de recherches privées peuvent miner la confiance même lorsque l’allégation n’a pas été établie de manière indépendante.

Ces risques exigent un travail d’ingénierie, pas seulement une meilleure formulation. La détection des données sensibles, la protection en prétraitement, la séparation de l’identité, la conservation limitée et des autorisations applicables devraient faire l’objet d’une attention soutenue en tant que capacités fondamentales de sécurité de l’IA. L’utilité d’un assistant et la protection de son utilisateur doivent progresser ensemble.

Avec Dvina, nous contribuons à mener ce changement en faisant de la protection avant le traitement par le modèle une partie des fondations du produit. L’ambition n’est pas de demander davantage de confiance au moyen d’affirmations plus fortes. Elle est de réduire la part de confiance qui doit reposer sur une simple promesse.

Les gens devraient pouvoir demander de l’aide, développer une idée et partager le contexte nécessaire pour avancer sans considérer chaque conversation comme un abandon potentiel de leur vie privée. Construire cette confiance est l’une des tâches les plus importantes qui attendent l’IA.

Sources et périmètre

Sources examinées le 22 September 2026. Cet article s’appuie sur la documentation des fournisseurs et sur des reportages attribués ; il ne constitue pas un audit de sécurité indépendant. Les offres individuelles constituent le principal périmètre de comparaison. Les exceptions commerciales, API et propres à certains modèles sont identifiées séparément. La section sur les mathématiques distingue les préoccupations rapportées de la réponse mise à jour d’OpenAI ; aucune des deux n’est présentée comme une conclusion indépendante. La règle de Manus concernant l’entraînement dans l’offre individuelle reste non vérifiée, car l’intégralité de sa politique de confidentialité n’a pas pu être récupérée.

  1. OpenAI : divulgation de l’incident ChatGPT de mars 2023
  2. OpenAI : l’ordonnance de conservation de 2025 et la mise à jour d’octobre
  3. Reuters : ordonnance de décembre 2025 concernant 20 millions de journaux anonymisés
  4. OpenAI : entraînement sur les données des consommateurs, accès autorisé et suppression
  5. OpenAI : contrôles pour ChatGPT, Codex et Temporary Chat
  6. Anthropic : entraînement sur les données des consommateurs, retours et mode Incognito
  7. Anthropic : conservation et suppression des données des consommateurs
  8. Anthropic : restrictions d’accès pour les employés et exceptions
  9. Anthropic : exigences de conservation pour les Covered Models et périmètre de déploiement
  10. Andrew Cullen / The Conversation, republié par Singularity Hub : la controverse mathématique
  11. OpenAI : annonce sur Navier–Stokes et mise à jour de réponse du 10 septembre
  12. Cursor : modes d’utilisation des données, traitement côté backend et exceptions
  13. Perplexity : collecte de données des consommateurs et distinctions pour Enterprise
  14. Manus : visibilité des tâches pour les comptes individuels et Team
  15. Manus : fonctionnalités des offres, y compris l’exclusion de l’entraînement pour Team
  16. Meta : architecture de lancement de Muse, pratiques d’entraînement et projets de Confidential VM
  17. Dvina : politique de confidentialité
  18. Dvina : conception de la confidentialité et protections de prétraitement
  19. OpenAI : lancement de Privacy Filter et usages prévus

La confidentialité doit faire partie des fondations

Découvrez l’approche de Dvina pour protéger les informations personnelles avant leur traitement par le modèle.

À découvrir aussi

Nous recueillons uniquement les données d’analyse indispensables au bon fonctionnement de nos services.