OpenAI a présenté le 19 août 2026 son offre Zero Data Retention pour les déploiements de modèles de pointe auprès de clients API éligibles, ainsi qu’un dispositif en préversion nommé Private Safety Processing. Ces notions sont importantes pour les projets sensibles, mais elles ne doivent pas être réduites à la formule « les données ne sont pas stockées ».
1. Qu’est-ce que le Zero Data Retention ?
Dans le cadre annoncé, les clients API éligibles peuvent utiliser certains modèles avec des requêtes et réponses non conservées après le traitement. OpenAI indique également que ces contenus ne sont pas accessibles à son personnel et rappelle que les données des entreprises ne sont pas utilisées pour entraîner les modèles sans choix explicite du client.
Cette option répond à une contrainte fréquente : éviter qu’un contenu métier, un document confidentiel ou une donnée personnelle reste dans les journaux du fournisseur au-delà du temps nécessaire à l’appel.
Le terme « éligible » est essentiel. Il faut vérifier le modèle, l’endpoint, le contrat, la région, les fonctions utilisées et les éventuelles exceptions. La documentation officielle montre que la compatibilité dépend de chaque endpoint et de sa configuration : conversations, assistants, fichiers, vector stores, traitements batch, vidéo et certains modes asynchrones demandent notamment une vérification séparée. Une politique déclarée au niveau d’un compte ne s’applique pas nécessairement à chaque outil, fichier, cache ou service annexe.
Au 2 septembre 2026, la documentation officielle distingue aussi les régimes « Eyes Off » et « Safety Retention ». OpenAI indique pouvoir rendre certains modèles inéligibles au Zero Data Retention pour un client donné, avec notification écrite. Selon le régime appliqué, des contenus peuvent alors être conservés et, pour Safety Retention, examinés afin d’enquêter sur une activité présentant un risque sévère. Cette réserve doit apparaître dans l’analyse contractuelle.
La même documentation précise que le mode background de l’API Responses peut écrire temporairement des données pour permettre l’interrogation du résultat, que le cache de prompts peut conserver des tenseurs chiffrés sur le GPU pendant une durée limitée et que les services tiers, notamment les serveurs MCP distants, appliquent leur propre politique de conservation.
2. Ce que cela ne signifie pas
Zéro rétention ne veut pas dire zéro traitement. La donnée doit être transmise et chargée en mémoire pour produire une réponse. La sécurité du transport, l’isolation de l’infrastructure, les accès techniques et la gestion des incidents restent donc déterminants.
Cela ne signifie pas non plus que l’application cliente ne conserve rien. Les prompts peuvent apparaître dans les journaux applicatifs, les traces APM, les files de messages, les sauvegardes, le navigateur ou un outil d’observabilité. Le maillon le plus bavard se trouve souvent du côté de l’intégrateur.
Enfin, la non-utilisation pour l’entraînement, la durée de conservation et la localisation sont trois sujets distincts. Ils doivent être documentés séparément dans l’analyse de risques et le registre des traitements.
3. Le rôle de Private Safety Processing
OpenAI présente Private Safety Processing comme un moyen de détecter des schémas de risque apparaissant à travers plusieurs interactions sans donner au personnel accès aux contenus sous-jacents. Selon l’architecture annoncée, le contenu peut rester sous contrôle du client. OpenAI développe également une option de traitement sur une infrastructure chiffrée avec des clés contrôlées par le client ; elle ne doit pas être considérée comme généralement disponible à ce stade.
Le fournisseur recevrait alors un signal de risque étroitement défini, et non le détail des conversations. Le mécanisme cherche à concilier confidentialité et détection d’abus coordonnés, notamment lorsque l’analyse d’un appel isolé serait insuffisante.
Il s’agit encore d’une préversion testée avec des premiers clients. OpenAI annonçait un début de déploiement et un livre blanc technique en septembre. Au 2 septembre 2026, aucune annonce distincte de disponibilité générale n’a été trouvée : les détails d’implémentation, les garanties vérifiables et les conditions d’accès doivent être examinés au cas par cas.
4. Une architecture à plusieurs niveaux de contrôle
Un projet robuste doit distinguer au moins cinq couches. La première est la minimisation : ne jamais envoyer au modèle une donnée inutile. La deuxième est la pseudonymisation ou le masquage avant l’appel. La troisième couvre le transport et le traitement chez le fournisseur. La quatrième concerne la conservation. La cinquième porte sur les journaux et contrôles de l’application cliente.
Private Safety Processing ajoute une sixième couche : la production éventuelle d’un signal de risque distinct du contenu. Cette couche doit être documentée comme un flux à part entière, avec sa finalité, ses destinataires, sa durée et ses conséquences possibles.
Le chiffrement avec clé contrôlée par le client peut renforcer la maîtrise, mais il ne suffit pas à lui seul. Il faut savoir à quel moment la donnée est déchiffrée, quel composant peut l’utiliser, comment les clés sont renouvelées et ce qui se passe en cas de révocation.
5. Les questions à poser avant de contractualiser
Commencez par établir une matrice des fonctions utilisées : texte, fichiers, images, outils, recherche, cache et traitements asynchrones. Pour chacune, demandez la durée de conservation, les exceptions, la région, les sous-traitants et la méthode d’effacement.
Vérifiez ensuite les conditions d’éligibilité au Zero Data Retention, la preuve disponible, le traitement des incidents et les mécanismes d’audit. Demandez comment sont gérés les abus, les obligations légales et les catégories particulières de contenus. L’annonce mentionne notamment une exception liée aux images d’abus sexuels sur mineurs ; les équipes doivent connaître précisément les règles applicables à leur service.
Pour Private Safety Processing, demandez la définition exacte du signal, sa persistance, les décisions qu’il peut déclencher et les moyens de contestation ou d’investigation disponibles.
6. Les contrôles à conserver côté client
Une option de confidentialité fournisseur ne remplace pas le contrôle d’accès. Chaque appel doit être rattaché à un utilisateur, un cas d’usage et une politique de données. Les documents récupérés doivent respecter les droits de la personne qui interroge le système.
Mettez en place un filtre de données sensibles avant l’envoi, un schéma de sortie strict, des délais, des quotas et une capacité à couper rapidement le fournisseur. Les journaux doivent privilégier des identifiants, hachages et métriques plutôt que les contenus complets.
Les tests de sécurité doivent inclure les injections de prompt, l’exfiltration indirecte, les outils mal configurés et les erreurs de cloisonnement. Ces thèmes sont développés dans notre guide sur la gouvernance opérationnelle de l’IA.
7. Les cas d’usage adaptés
Le Zero Data Retention est particulièrement pertinent pour le résumé de documents confidentiels, l’assistance interne, l’analyse de contrats, le support technique ou l’extraction de données lorsque le fournisseur satisfait les autres exigences du projet.
Il ne rend pas automatiquement acceptable l’envoi de données médicales, financières ou judiciaires. Pour ces catégories, une analyse approfondie, une base légale, des mesures renforcées et parfois une infrastructure dédiée restent nécessaires.
Les cas d’usage à forte autonomie demandent aussi davantage que la confidentialité. Un agent pouvant écrire dans le SI doit avoir des permissions minimales, des validations et une traçabilité de chaque action.
8. Comment conduire un pilote
Sélectionnez un corpus de test représentatif mais désensibilisé. Cartographiez tous les flux, y compris les logs, sauvegardes et outils de support. Activez l’option contractuelle adaptée, puis vérifiez le comportement réel de chaque endpoint.
Simulez les erreurs, les interruptions et la révocation de clé. Mesurez les données visibles dans l’observabilité et contrôlez que personne ne peut retrouver le contenu à partir d’un identifiant ou d’une trace.
Enfin, faites valider la documentation par la sécurité, le DPO et le métier. Le pilote est réussi lorsque l’organisation peut expliquer où passe chaque donnée, qui peut y accéder et comment arrêter le service.
L’annonce du 19 août constitue une avancée intéressante pour les entreprises exigeantes. Sa valeur dépendra de la documentation technique annoncée, des conditions contractuelles et de la capacité des intégrateurs à appliquer la même discipline dans leur propre architecture.
Partitech accompagne la conception de services IA sécurisés : cartographie des flux, choix d’architecture, minimisation des données, contrôle d’accès, observabilité et documentation de conformité.