Conservation des données LLM et ZDR : qui lit vos prompts

Votre prompt n’est pas simplement envoyé à « l’entreprise d’IA ». Dans une stack d’agents, il traverse plusieurs intermédiaires qui le traitent tous en clair. La liste exacte dépend de votre stack : télémétrie du framework d’agents, plateforme de tracing, système de mémoire, outil d’analytics, gateway d’IA et l’un des trois types de fournisseurs d’inférence. Chacun applique ses propres règles de conservation, sa propre région de stockage et ses propres clauses d’entraînement. L’acteur qui conserve vos prompts le plus longtemps se trouve généralement de votre côté de l’API : les fournisseurs de modèles suppriment les logs standards après environ 30 jours, tandis qu’un système de tracing ou de mémoire les garde par défaut jusqu’à ce que vous les supprimiez. La conservation zéro des données (ZDR) est un dispositif réel et utile, mais elle ne fixe qu’un seul des trois axes pour un seul de ces acteurs. Cet article cartographie toute la chaîne : qui conserve quoi, pendant combien de temps, et ce que la ZDR couvre ou non.

TL;DR

• Chaque étape qui voit les données en clair peut les collecter. Le tracing côté agent et les systèmes de mémoire conservent les prompts bien plus longtemps que les fournisseurs de modèles.
• La conservation dépend de chaque fonctionnalité : dans l’API Claude, le caching est compatible avec la ZDR, les batch jobs persistent pendant 29 jours et Fable 5 impose 30 jours.
• La géographie dépend du serveur : l’API officielle de DeepSeek stocke les données en Chine, sans autre option.
• Les endpoints gratuits présentent le plus de risques : les droits d’entraînement sont généralement le prix à payer pour cette capacité gratuite.
• La ZDR a résisté à l’épreuve judiciaire : l’ordonnance de conservation du NYT n’exemptait que les clients API en conservation zéro.

Qui peut lire votre prompt dans une stack d’agents ?

Tous les acteurs présents sur le chemin, qui est plus long que ne le montrent la plupart des schémas d’architecture :

Parcourons le schéma de gauche à droite. La couche agent vous appartient, mais elle est rarement entièrement sous votre contrôle : les frameworks intègrent de la télémétrie, les plateformes de tracing et d’observabilité servent précisément à stocker l’intégralité des prompts et des réponses, les fonctions de mémoire écrivent le contenu des conversations dans des bases vectorielles qui n’expirent jamais seules, et un script d’analytics avec session replay dans votre interface web capture le prompt pendant sa saisie, avant même qu’il n’atteigne votre backend. La gateway représente un acteur si vous l’exécutez vous-même, et deux si elle est fournie en SaaS. Il existe deux types de gateways SaaS. Le premier est l’agrégateur multifournisseur : une API unique qui répartit les requêtes entre les fournisseurs intégrés. Sa politique sur les données est donc toujours la somme de deux éléments, sa propre politique et celle de l’hébergeur ayant traité la requête. Le second vient des éditeurs de sécurité : gateways de prévention des fuites de données (DLP) et de guardrails, dont le produit consiste à inspecter les payloads, à les expurger et à appliquer des règles. Lire chaque prompt fait partie de leur fonctionnement, et les prompts signalés sont généralement conservés comme événements de sécurité.

Derrière la gateway se trouvent trois types de fournisseurs d’inférence : l’API de l’éditeur du modèle, un fournisseur cloud qui héberge le modèle dans votre tenant cloud, et des hébergeurs GPU qui servent des modèles open weights selon leurs propres politiques de logs. La branche de contournement, une inférence auto-hébergée sur un tenant dédié ou vos propres GPU, est la seule voie où aucun tiers ne traite les données en clair. Elle comporte toutefois une contrepartie sur laquelle nous reviendrons.

La règle qui permet de comprendre le reste est simple : voir et conserver sont deux questions distinctes. Chaque bloc peut techniquement collecter les données. Ce qu’il collecte réellement dépend des paramètres par défaut, de la configuration et des contrats. Or, les valeurs par défaut varient énormément d’un maillon à l’autre.

Qui conserve réellement vos prompts ?

Le plus souvent, ce sont vos propres outils, et plus longtemps que tous les autres acteurs. Les durées de conservation des fournisseurs, omniprésentes dans les questionnaires de sécurité, se mesurent en jours. Les systèmes côté agent, sur lesquels personne ne pose de questions, gardent les données indéfiniment.

La couche agent conserve les données par conception. Une plateforme de tracing est une base de données contenant vos prompts et vos sorties. La durée de conservation y est un paramètre de projet, pas une conséquence accidentelle de la politique. Les valeurs par défaut varient selon les outils et méritent d’être vérifiées : l’intégration OpenTelemetry de GitHub Copilot exporte la structure des spans, les timings et le nombre de tokens, mais pas le contenu des prompts, sauf si vous activez explicitement sa capture. Les autres outils d’agents devraient davantage s’inspirer de ce modèle protecteur par défaut. Le mode confidentialité de Cursor existe parce que le mode par défaut partage les données du code. Même si le fournisseur du modèle supprime vos données après 30 jours, elles figurent encore dans votre système de traces au jour 300.

La gateway conserve ce qu’elle décide de conserver. Une gateway doit enregistrer les données d’usage, car la facturation nécessite de connaître le nombre de tokens, les modèles et l’horodatage de chaque requête. En revanche, elle peut tout à fait éviter de stocker les payloads : les corps des prompts et des réponses peuvent transiter en mémoire sans jamais être écrits sur un stockage persistant. Deux fonctionnalités courantes franchissent discrètement cette limite. Une console d’inspection des requêtes ou d’observabilité stocke par définition les payloads, comme une plateforme de tracing SaaS située un cran plus tôt. Le caching au niveau de la gateway stocke aussi le contenu des prompts à cette étape : un cache sémantique conserve un embedding du prompt ainsi que l’intégralité de la réponse mise en cache, tandis qu’un cache de réponses garde les deux côtés à l’identique, sur le disque utilisé par la gateway. Pour évaluer une gateway, en SaaS ou auto-hébergée, il faut poser trois questions distinctes : que contient l’enregistrement de la requête, que conserve la vue d’observabilité et qu’écrit le cache ?

Les fournisseurs définissent la conservation par fonctionnalité, pas au niveau de l’entreprise. La documentation d’Anthropic sur la conservation des données de l’API fournit le bon modèle mental en détaillant l’éligibilité de chaque fonctionnalité : le prompt caching est compatible avec la ZDR, car l’état du cache reste uniquement en mémoire ; le batch processing conserve les jobs pendant 29 jours, car les traitements asynchrones nécessitent du stockage ; les conteneurs d’exécution de code persistent jusqu’à 30 jours ; les fichiers téléversés restent stockés jusqu’à leur suppression. La page le dit clairement : utiliser une fonctionnalité avec état revient à « sortir du dispositif ZDR pour ces données précises ». Côté OpenAI, la documentation sur le contrôle des données indique les endpoints compatibles avec la ZDR, fixe à 30 jours maximum la conservation par défaut des logs de détection des abus et précise que les prompts mis en cache sont stockés sous forme de tenseurs clé-valeur chiffrés sur le stockage local des GPU, avec un TTL limité. Dans l’offre commerciale standard, la suppression via l’API Claude intervient sous 30 jours.

Où les données sont-elles physiquement stockées ?

Elles résident là où se trouve l’infrastructure qui sert le modèle, et la réponse varie selon le type de fournisseur. Un modèle hébergé dans le cloud offre le cas le plus clair : sur Amazon Bedrock, le fournisseur cloud agit comme sous-traitant des données et l’inférence reste dans la région choisie. C’est pourquoi les entreprises soumises à des contraintes réglementaires privilégient cette voie. L’API d’un éditeur de modèles s’exécute là où celui-ci opère : OpenAI propose un traitement régional aux États-Unis et dans l’UE pour la plupart des endpoints, tandis que les fournisseurs plus petits ne publient souvent aucune information. Le cas extrême, mais sans ambiguïté, est DeepSeek. Sa politique de confidentialité précise que les données personnelles sont collectées, traitées et stockées en République populaire de Chine, sans option américaine ou européenne dans l’API officielle. Servir les mêmes open weights chez un hébergeur GPU américain change complètement cette géographie. Cela montre clairement que la destination des données dépend de l’acteur qui sert le modèle, pas du modèle lui-même.

Deux prolongements subsistent au-delà de la copie principale. Les caches et les fichiers de batch restent dans la région de traitement pendant leur propre durée de vie, indépendamment des logs de requêtes. Chaque fournisseur s’appuie également sur des sous-traitants, ainsi que sur des sauvegardes : les engagements de suppression concernent généralement les systèmes actifs, puis prévoient un délai de propagation dans les sauvegardes. Si votre schéma de flux de données s’arrête au logo du fournisseur de l’API, il manque au moins ces deux blocs.

Qui impose la conservation, et qui entraîne ses modèles sur vos prompts ?

Trois mécanismes distincts prolongent la conservation au-delà des valeurs par défaut. Un seul apparaît dans la communication commerciale du fournisseur.

Exigences de politique interne. Certains modèles imposent une durée de conservation pour des raisons de sécurité. Claude Fable 5 et Mythos 5 exigent une conservation de 30 jours, même pour les clients ZDR. Le système échoue explicitement : lorsqu’une organisation ne respecte pas cette exigence dans sa configuration de conservation, la requête est rejetée avec une erreur 400 au lieu d’être acceptée silencieusement. L’escalade des abus constitue un autre cas particulier : les contenus signalés pour violation des règles d’utilisation suivent un calendrier totalement différent. La politique grand public d’Anthropic prévoit jusqu’à 2 ans pour les entrées et sorties signalées, et jusqu’à 7 ans pour les scores des classifieurs.

Obligations de conservation judiciaire. Le litige NYT v. OpenAI a fourni le meilleur test grandeur nature des promesses de conservation. Une ordonnance de conservation de mai 2025 a contraint OpenAI à préserver des logs de sortie qui auraient normalement été supprimés, y compris des conversations effacées par les utilisateurs, pour les offres grand public. L’ordonnance a été restreinte en septembre, puis un tribunal a ordonné la communication de 20 millions de logs de conversation dans le cadre de la procédure de discovery. Pour les acheteurs d’API, un détail compte particulièrement : les clients entreprise et ceux en conservation zéro ont été exclus, car aucune donnée conservée ne pouvait faire l’objet de l’ordonnance. Une obligation judiciaire peut suspendre une politique de suppression. Elle ne peut pas faire apparaître des données que l’architecture n’a jamais stockées.

Intermédiaires qui exploitent les données. Certains acteurs au milieu de la chaîne se font effectivement prendre à monétiser des données en clair. Le cas documenté le plus important se trouvait au plus près de l’utilisateur. En décembre 2025, des chercheurs en sécurité ont montré qu’une extension VPN présentée comme respectueuse de la vie privée et installée des millions de fois injectait des scripts dans les pages de chat IA. Elle interceptait chaque prompt et chaque réponse dans ChatGPT, Claude, Gemini et cinq autres assistants, puis envoyait les conversations à une société affiliée de courtage de données. La collecte avait lieu que le VPN soit activé ou non et concernait environ 8 millions d’utilisateurs des extensions de cet éditeur. L’incident impliquait un intercepteur côté client, pas une gateway API, mais la leçon vaut pour chaque bloc du schéma : tout intermédiaire qui traite les données en clair peut les collecter, son intérêt économique peut être de les monétiser, et l’interception reste invisible depuis les deux extrémités. Faire confiance à un intermédiaire revient à parier sur son modèle économique, pas sur sa liste de fonctionnalités.

Clauses d’entraînement. Les API professionnelles des principaux fournisseurs n’utilisent pas vos données pour l’entraînement par défaut. Les produits grand public le font de plus en plus souvent si vous ne vous y opposez pas, ce qui justifie aussi de faire passer le trafic des agents par des clés API plutôt que par des comptes grand public. De plus en plus de produits placent le consentement à l’entraînement derrière une option que vous devez trouver vous-même : abonnements grand public avec entraînement activé par défaut et opt-out enfoui dans les paramètres, outils de développement où le réglage de télémétrie ou de partage de code vaut aussi consentement à l’entraînement, programmes fournisseurs qui échangent un opt-in au partage de données contre des remises ou du quota gratuit, et tableaux de bord d’agrégateurs avec des options distinctes pour les offres payantes et gratuites. Chaque option s’applique à un compte, parfois à un workspace, et sa valeur par défaut peut changer lors d’une mise à jour des conditions. Une vérification ponctuelle ne suffit pas. L’audit de ces options doit figurer dans la même checklist récurrente que la rotation des clés.

Les modèles gratuits méritent une mention à part. Tous les avertissements précédents se concentrent au même endroit : l’offre gratuite. Le lancement d’un modèle gratuit est généralement subventionné par l’acteur qui tire profit du trafic, le plus souvent l’éditeur du modèle. Les prompts envoyés à la variante gratuite lui sont donc transmis selon sa propre politique, souvent avec des droits d’entraînement, et sont traités là où il exerce ses activités. Pour les fournisseurs chinois, cela signifie la Chine. Les gateways d’agrégation publient des politiques de données par endpoint et proposent une option permettant d’exclure les fournisseurs qui entraînent leurs modèles précisément parce que ces clauses sont fréquentes sur les routes gratuites. La règle est directe : considérez un endpoint gratuit comme une transmission de données, pas comme un simple appel API. L’inférence gratuite a toujours un coût, et vos prompts servent généralement de monnaie d’échange.

Que signifie réellement la ZDR ?

La ZDR fixe un seul des trois axes, pour un seul acteur de la chaîne et uniquement pour les fonctionnalités éligibles. Ce n’est pas une critique, mais sa définition. Il faut en connaître les limites pour l’utiliser correctement.

• Les trois axes. L’utilisation pour l’entraînement, la durée de conservation et l’accès humain sont indépendants. Les API professionnelles n’entraînent déjà pas leurs modèles sur vos données. La ZDR ramène à zéro la conservation des payloads. L’accès humain relève de processus distincts de traitement des abus. Confondre ces axes conduit à surestimer la portée de la ZDR.
• Ce qui subsiste avec la ZDR. Les métadonnées d’usage et les enregistrements de facturation, les sorties des classifieurs de sécurité et l’état lié aux fonctionnalités avec état que vous activez. Les deux principaux fournisseurs conçoivent désormais leurs systèmes pour contourner l’exception liée à la détection des abus plutôt que pour l’utiliser : signaux de sécurité sans payload chez l’un, conservation limitée aux résultats des classifieurs chez l’autre.
• Ce que la ZDR ne couvre pas. Tout ce qui se trouve en amont du fournisseur : votre système de tracing, les logs de votre gateway et votre mémoire vectorielle. Le cas le plus courant, et le moins cohérent, associe un accord ZDR avec le fournisseur du modèle à une plateforme de tracing SaaS qui conserve indéfiniment chaque prompt.
• La limite de l’auto-hébergement. Exécuter des open weights sur vos propres GPU élimine tous les tiers. Votre infrastructure hérite alors de l’intégralité du problème : logs de requêtes du serveur d’inférence, logs d’accès et fichiers de traces. L’auto-hébergement déplace la surface de conservation. Seule une gestion volontaire et rigoureuse des logs permet de la réduire.

Comment Synthorai gère les données

La gateway est notre maillon de la chaîne, nos engagements sont donc précis. En mode conservation zéro, les corps des requêtes et des réponses transitent en mémoire sans être écrits sur un stockage persistant. Seul l’enregistrement nécessaire à la facturation subsiste : horodatage, modèle, nombre de tokens et hash du contenu. Ce hash permet de rapprocher une requête d’un litige sans conserver ce qui a été dit. En amont, les fournisseurs sont filtrés avant même le routage : Synthorai n’intègre que ceux qui s’engagent à ne conserver aucune donnée issue de notre trafic, à une exception documentée près, Claude Fable 5. Sa conservation de 30 jours est imposée par l’éditeur du modèle et ne peut pas être écartée contractuellement. Choisir un fournisseur revient à choisir une politique de conservation. Le rôle de la gateway est de rendre cette propriété explicite pour chaque route plutôt que de l’enfouir dans un PDF : une route Fable 5 expose son exigence de conservation dans ses métadonnées documentées, sans mauvaise surprise.

FAQ

Les fournisseurs de LLM entraînent-ils leurs modèles sur les données API par défaut ?

Non. Par défaut, les principaux fournisseurs n’entraînent pas leurs modèles sur les données de leurs clients professionnels. Cet engagement figure dans leur documentation sur le contrôle des données. Les exceptions se concentrent dans la longue traîne : produits grand public fonctionnant en opt-out plutôt qu’en opt-in, certains hébergeurs GPU qui servent des open weights et endpoints gratuits où les droits d’entraînement font partie du prix.

La ZDR signifie-t-elle que le fournisseur ne stocke absolument rien ?

Non. La ZDR signifie que les payloads des prompts et des réponses ne sont pas conservés pour les fonctionnalités éligibles. Les métadonnées d’usage, les enregistrements de facturation et les sorties des classifieurs de sécurité persistent. Les fonctionnalités avec état, comme les batch jobs ou le téléversement de fichiers, stockent nécessairement des données et sortent donc du périmètre de la ZDR. Consultez le tableau d’éligibilité par fonctionnalité, pas seulement le titre de l’offre.

Peut-on envoyer des données de production à des modèles gratuits en toute sécurité ?

Considérez un endpoint gratuit comme une transmission de données, pas comme un simple appel API. La capacité gratuite est subventionnée par l’acteur qui bénéficie du trafic. Les droits d’entraînement font souvent partie de l’accord, et les données sont traitées là où cet acteur opère. Ce compromis convient aux expérimentations sans enjeu. Il est rarement acceptable dès que les données contiennent des informations client, du code ou des identifiants.

L’auto-hébergement est-il automatiquement l’option la plus confidentielle ?

Il retire effectivement tous les tiers du chemin où les données circulent en clair. Il ne supprime pas la conservation : les serveurs d’inférence, les reverse proxies et les outils de tracing produisent tous des logs par défaut. Une stack auto-hébergée avec sa configuration de logs par défaut peut conserver davantage de prompts qu’une API sous ZDR. La confidentialité dépend de la configuration des logs, pas du modèle d’hébergement.

Sources vérifiées le 2026-08-29 : chaque affirmation sur un fournisseur renvoie à sa propre documentation ou à des pièces judiciaires de première source. Les politiques du secteur ont changé deux fois au cours du mois précédant la publication. Considérez donc les liens comme la source de vérité à jour. Il s’agit d’une analyse d’ingénierie, pas d’un avis juridique.

À lire aussi : l’exigence de conservation de 30 jours de Fable 5, le fonctionnement du prompt caching, le comparatif des caches des fournisseurs.

← Retour au blog