Pour détecter un usage dangereux d’une intelligence artificielle, il faut souvent regarder plus d’une requête. Un prompt isolé peut sembler banal ; une succession de demandes révèle parfois une tentative de contourner les protections, de préparer une attaque ou de pousser un agent à poursuivre une action qu’on lui a pourtant demandé d’arrêter. Mais conserver cette séquence expose précisément les données que les entreprises les plus sensibles refusent de confier à un fournisseur externe.
OpenAI affirme avoir trouvé une manière de desserrer ce nœud. Le 19 août 2026, l’entreprise a présenté Private Safety Processing, un mécanisme destiné à repérer des schémas de risque entre plusieurs interactions tout en restant compatible avec son offre Zero Data Retention — ou ZDR, pour rétention zéro des données.
L’annonce est importante pour la banque, la santé, la recherche et toutes les organisations qui veulent utiliser les modèles les plus avancés sans laisser leurs prompts et leurs réponses dans les journaux du fournisseur. Elle doit toutefois être lue comme une préversion technique, et non comme une preuve achevée. OpenAI teste encore le dispositif avec quelques clients et promet un livre blanc en septembre. Pour l’instant, son fonctionnement détaillé, ses performances et les garanties vérifiables restent largement à documenter.
Zero Data Retention ne signifie pas seulement « pas d’entraînement »
La confusion la plus fréquente consiste à assimiler rétention, entraînement et accès humain. Ce sont trois questions différentes.
OpenAI indique que les données de ses clients professionnels et de son API ne servent pas à entraîner ses modèles par défaut, sauf choix explicite de leur part. Cette règle ne signifie pas automatiquement que les entrées et les sorties disparaissent aussitôt. Dans la configuration standard de l’API, des journaux de surveillance des abus peuvent contenir du contenu client et être conservés jusqu’à 30 jours.
Le mode Zero Data Retention va plus loin pour les organisations éligibles : les prompts et les réponses sont exclus des journaux de surveillance, et les fonctionnalités compatibles ne conservent pas d’état applicatif. Le paramètre de stockage des API de réponses et de conversations est alors forcé à false, même si une requête tente de l’activer.
Cette différence est déterminante pour un hôpital qui traite des données de santé, une banque qui analyse des opérations ou une entreprise qui envoie du code propriétaire. « Ne pas entraîner le modèle » limite une réutilisation ultérieure ; « ne pas conserver » réduit la présence même du contenu chez le fournisseur après traitement.
Mais ZDR n’est ni une propriété universelle de tous les produits OpenAI ni un bouton grand public. L’offre vise des clients API éligibles, après approbation et exigences supplémentaires. Elle ne décrit pas la conservation des conversations ordinaires dans ChatGPT Free, Plus ou Pro.
Le problème : les abus sérieux se lisent dans la durée
Les protections compatibles avec ZDR analysent aujourd’hui chaque interaction séparément. Cette approche peut repérer une demande directement interdite, mais elle perd la continuité d’une stratégie répartie sur plusieurs étapes.
Un attaquant peut, par exemple, envoyer des centaines de variantes afin de découvrir celle qui contourne un refus. Des comptes distincts peuvent coordonner des fragments d’une même opération. Un agent autorisé à utiliser des outils peut aussi dériver progressivement de son mandat : chaque action paraît acceptable seule, alors que leur enchaînement révèle une perte de contrôle.
Ce besoin de contexte augmente avec les modèles de longue durée. Les systèmes ne se contentent plus de répondre en quelques lignes : ils planifient, appellent des logiciels, manipulent des fichiers et poursuivent un objectif pendant des dizaines d’étapes. La sécurité doit donc porter sur la trajectoire, pas seulement sur le dernier message.
OpenAI a déjà reconnu ce changement d’échelle en renforçant ses environnements de recherche et en ralentissant certaines activités après des alertes cyber — un contexte détaillé dans notre article sur la pause d’entraînement des modèles de frontière. Private Safety Processing déplace la même question vers les déploiements professionnels : comment observer une séquence sans créer une nouvelle copie exploitable des secrets qu’elle contient ?
Un signal de risque doit sortir, pas le contenu
Selon l’annonce d’OpenAI, le nouveau mécanisme étend l’analyse automatisée à plusieurs interactions liées. Le contenu client reste inaccessible au personnel d’OpenAI, même lorsqu’un risque est détecté. Le fournisseur ne recevrait qu’un signal limité indiquant le type d’activité concerné, comparable aux signaux de ses systèmes de sécurité actuels.
Ce signal pourrait servir à décider d’une mesure d’application des règles. Le client conserverait, dans ses propres systèmes, les informations nécessaires pour enquêter sur l’alerte ou contester une décision. S’il veut expliquer un usage légitime, faire appel ou coopérer à une investigation, il pourrait choisir de transmettre lui-même les éléments pertinents à OpenAI.
L’architecture annoncée cherche donc à séparer trois fonctions :
- l’analyse automatisée du contenu nécessaire pour détecter un risque ;
- l’exposition du contenu aux employés du fournisseur ;
- la conservation durable des prompts et des réponses.
Cette séparation est plus précise qu’une promesse générale de « confidentialité ». Un traitement peut avoir lieu sans qu’un humain lise les données et sans qu’une copie permanente soit conservée. Inversement, un contenu chiffré et stocké reste bien un contenu retenu, même si le fournisseur ne possède pas la clé.
Deux modes de stockage, une technique encore peu décrite
OpenAI décrit deux configurations. Dans un déploiement ZDR, le contenu resterait sur une infrastructure contrôlée par le client. Une seconde option, encore en développement, permettrait de stocker le contenu chez OpenAI en le chiffrant avec des clés détenues par le client. Les employés d’OpenAI n’auraient pas de copie de ces clés.
Dans les deux cas, des systèmes automatisés pourraient analyser les interactions et produire un signal de sécurité restreint. L’annonce ne précise toutefois pas suffisamment où s’exécute chaque calcul, comment les interactions sont reliées, quelles métadonnées accompagnent le signal, combien de temps celui-ci subsiste ni comment le client peut vérifier que seul le résultat autorisé quitte son périmètre.
Il serait donc prématuré d’attribuer au système une technique cryptographique particulière. OpenAI ne dit pas publiquement, à ce stade, qu’il repose sur du chiffrement homomorphe, du calcul multipartite ou une enclave confidentielle déterminée. Le livre blanc promis devra établir le modèle de menace, la gestion des clés, l’isolation de l’exécution, les journaux d’audit et les protections contre un signal trop révélateur.
La rétention zéro comporte des frontières très concrètes
Le nom ZDR donne l’impression d’une règle absolue. La documentation de l’API montre plutôt un périmètre à vérifier fonction par fonction.
Les API de chat et de réponses peuvent être compatibles lorsque le stockage est désactivé. En revanche, les conversations persistantes, les assistants, les fils de discussion, les magasins vectoriels, les fichiers, les travaux de fine-tuning, les évaluations et les traitements par lots peuvent conserver un état applicatif et ne sont pas tous éligibles à la rétention zéro. Le mode d’exécution en arrière-plan des réponses stocke temporairement des données afin de permettre le suivi du travail ; il n’est donc pas compatible avec ZDR.
Les outils tiers créent une autre limite. Lorsqu’une requête envoie des informations à un serveur MCP externe, la politique de conservation de ce service s’applique. Une organisation peut ainsi sécuriser le lien avec OpenAI tout en laissant des traces chez un connecteur, un moteur de recherche, une base documentaire ou un outil métier.
Les images et fichiers font également l’objet d’une exception légale et opérationnelle : les contenus détectés comme pouvant relever de matériel pédopornographique peuvent être retenus pour vérification humaine et signalement. OpenAI mentionne explicitement cette exception dans son annonce. La rétention zéro reste donc soumise à certaines obligations de sécurité et de droit.
Résidence, chiffrement et rétention répondent à des questions différentes
Une entreprise doit encore distinguer trois contrôles souvent regroupés sous le mot « souveraineté » :
- la résidence des données indique la région où certaines données sont stockées ou traitées ;
- la gestion de clés par le client limite qui peut déchiffrer un contenu conservé ;
- la rétention zéro vise à empêcher la persistance du contenu après la requête pour les fonctions éligibles.
Ces protections peuvent se compléter, mais aucune ne remplace les autres. Héberger des données en Europe ne signifie pas qu’elles ne sont pas journalisées. Chiffrer une base avec une clé client ne signifie pas qu’elle n’existe plus. Supprimer les prompts après traitement ne garantit pas, à lui seul, que chaque connecteur ou chaque journal technique est soumis au même régime.
OpenAI et Anthropic choisissent deux réponses opposées
Le calendrier de l’annonce n’est pas anodin. Anthropic impose depuis juin une conservation de 30 jours pour ses modèles dits « couverts », notamment Claude Fable 5 et Mythos 5, y compris dans des environnements qui utilisaient auparavant ZDR. Le laboratoire estime que certains abus ne deviennent visibles qu’en agrégeant de nombreuses requêtes et préfère conserver les entrées et les sorties afin de les examiner avec ses systèmes de sécurité.
OpenAI soutient au contraire qu’une surveillance sur plusieurs interactions peut rester compatible avec la non-conservation du contenu sous-jacent. Axios a présenté cette divergence comme une nouvelle ligne de concurrence entre les deux laboratoires : non pas seulement la puissance ou le prix des modèles, mais le compromis qu’ils imposent entre confidentialité et visibilité sur les abus.
Il ne s’agit pas encore de deux solutions comparables sur preuves. Anthropic publie une politique de conservation opérationnelle et un cadre d’accès ; OpenAI présente un système en test dont le déploiement doit commencer et dont la documentation technique n’est pas encore disponible. La promesse d’OpenAI est plus attractive pour les données sensibles. Sa solidité ne pourra être évaluée qu’avec des détails sur l’architecture, les audits et les taux d’erreur.
Les entreprises devront auditer le trajet complet de leurs données
Private Safety Processing pourrait supprimer un obstacle important à l’usage des modèles de frontière. Une organisation n’aurait plus à choisir entre un modèle récent, doté d’une surveillance contextuelle, et une politique interdisant la conservation de ses données chez le fournisseur.
Cette possibilité ne dispense pas d’une analyse technique et contractuelle. Avant un déploiement, l’équipe sécurité devra cartographier les endpoints utilisés, les outils connectés, les états persistants, les exceptions, les signaux transmis à OpenAI et les mécanismes de recours. Elle devra aussi définir sa propre conservation : ZDR chez le fournisseur n’efface pas les journaux que le client décide de garder dans son application.
Quatre éléments mériteront une attention particulière lorsque le livre blanc paraîtra :
- la preuve que les prompts et réponses ne sortent pas du périmètre annoncé ;
- la quantité d’information contenue dans le signal de risque et sa durée de conservation ;
- la possibilité d’un audit indépendant de l’exécution et de la gestion des clés ;
- les faux positifs, notamment pour la recherche en cybersécurité, en biologie ou en sûreté, qui peut ressembler à un usage hostile.
Un système trop permissif manquerait les attaques réparties. Un système trop sensible bloquerait des professionnels légitimes sans leur donner les éléments nécessaires pour comprendre l’alerte. La confidentialité du contenu ne doit pas devenir l’opacité de la décision.
La confiance se jouera dans le livre blanc, pas dans le slogan
L’annonce d’OpenAI pose une bonne question : la surveillance de sécurité exige-t-elle nécessairement de conserver les conversations les plus sensibles ? Private Safety Processing avance une réponse ambitieuse — analyser les schémas, isoler le contenu, transmettre un signal minimal — qui pourrait devenir une architecture de référence pour l’IA d’entreprise.
Mais la proposition demeure asymétrique. OpenAI connaît aujourd’hui le dispositif ; les clients et observateurs disposent surtout d’une description fonctionnelle. Ils ne peuvent pas encore vérifier le modèle de menace, l’étanchéité entre contenu et signal, la résistance aux attaques internes ou la précision de la détection.
Le déploiement annoncé pour septembre et le livre blanc promis seront donc plus importants que le nom du produit. La rétention zéro ne sera crédible que si elle peut être traduite en limites techniques, contractuelles et auditables. Pour les entreprises, le progrès ne consiste pas à faire confiance à une nouvelle promesse, mais à obtenir enfin les preuves qui permettent de ne plus en dépendre.
Références
- OpenAI — « Offering Zero Data Retention for frontier models », 19 août 2026.
- OpenAI — contrôles de données et compatibilité Zero Data Retention par endpoint.
- OpenAI — confidentialité des données d’entreprise.
- OpenAI — sécurité, confidentialité et gestion des clés d’entreprise.
- Anthropic — pratiques de conservation des données pour les modèles couverts, juillet 2026.
- Anthropic — liste et règles applicables aux modèles couverts.
- Axios — analyse du choix opposé d’OpenAI et d’Anthropic sur la conservation, 19 août 2026.
