Rétention des données envoyées à une API d’IA générative

Une requête envoyée à l’API (Application Programming Interface) d’un fournisseur d’IA (intelligence artificielle) générative ne disparaît pas quand la réponse arrive. Elle traverse plusieurs stockages distincts, chacun avec sa durée, son finalité et ses personnes habilitées à le lire. La règle à retenir : « pas d’entraînement sur les données API » est une seule de ces garanties, et souvent celle qui pèse le moins des quatre.

→ Lire l’explication complète de la marmotte

Les quatre destinations d’une requête API d’IA

Le vocabulaire marketing parle « des données du client » au singulier. Le mécanisme réel en distingue au moins quatre destinations, qu’il faut instruire séparément.

Le traitement d’inférence. Le prompt et la réponse transitent en mémoire le temps du calcul. C’est la seule phase réellement éphémère, et la seule que tout le monde décrit.

Les journaux de surveillance des abus. Les fournisseurs conservent en général les entrées et sorties pendant une durée limitée pour détecter les usages contraires à leurs conditions. Des contenus signalés par leurs filtres peuvent être relus par des humains habilités. La durée, le périmètre et la possibilité d’en être exempté dépendent du fournisseur et de l’offre : à vérifier dans les conditions en vigueur, jamais à déduire d’un article de blog.

Les objets stockés à la demande. Fichiers téléversés, états de conversation conservés côté serveur, lots de traitement différé, jeux d’entraînement pour l’ajustement fin, bases vectorielles hébergées. Ces objets n’expirent souvent pas d’eux-mêmes : ils restent jusqu’à suppression explicite. C’est la destination la plus sous-estimée, parce qu’elle est créée par le code de l’application et non par une décision de l’architecte.

L’entraînement de modèles. Pour les offres API des grands fournisseurs, la réutilisation pour l’entraînement est généralement désactivée par défaut, alors que les applications grand public fonctionnent souvent à l’inverse. Ce « généralement » est exactement ce qu’il faut vérifier par écrit pour chaque fournisseur et chaque offre.

Vingt ans d’audits apprennent que la phrase « aucune donnée n’est conservée » signifie presque toujours « aucune donnée n’est conservée dans la base à laquelle pensait l’auteur de la phrase ».

Rétention par défaut, rétention nulle et leurs compromis

Certains fournisseurs proposent, sur demande et sous conditions d’éligibilité, un mode de rétention nulle où même les journaux d’abus ne persistent pas. Le compromis est net : on gagne l’absence de copie chez le tiers, on perd tout ce qui repose sur un état côté serveur. Les conversations conservées par le fournisseur, les fichiers téléversés et certaines fonctions agentiques deviennent indisponibles ou doivent être reconstruits côté client.

Position tranchée : pour des données personnelles sensibles ou des secrets d’affaires, la rétention nulle ou un stockage explicitement désactivé à chaque appel est le seul réglage défendable. Pour des contenus publics ou déjà diffusés, la rétention par défaut est acceptable et évite de réécrire la gestion d’état. Le choix dépend donc d’une seule question : la classification de ce qui part, pas l’enthousiasme de l’équipe produit pour la dernière fonction de mémoire. La classification elle-même relève de la gouvernance des données.

Autre piège : la mise en cache des prompts, proposée pour réduire coût et latence, conserve des préfixes de requête côté fournisseur pendant une durée courte. Elle n’est généralement pas couverte par les mêmes réglages que le stockage des conversations, et se documente séparément.

Exemple : vérifier le stockage côté fournisseur par l’API

L’exemple suivant utilise l’API Responses d’OpenAI, dont le paramètre store contrôle la conservation de la réponse côté serveur. Les noms de paramètres et les valeurs par défaut diffèrent entre fournisseurs et entre versions d’API : les relire dans la documentation en vigueur avant de reprendre ce modèle.

# Prérequis : clé de projet dans OPENAI_API_KEY, modèle choisi dans MODELE
# 1. Requête avec stockage côté serveur désactivé explicitement
REP=$(curl -s https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\": \"$MODELE\", \"input\": \"test de rétention\", \"store\": false}")
ID=$(echo "$REP" | jq -r '.id')

# 2. Tentative de relecture : avec store=false, la réponse ne doit pas être récupérable
#    Un code 200 signale que l'objet a été conservé malgré le réglage
curl -s -o /dev/null -w "%{http_code}\n" \
  https://api.openai.com/v1/responses/$ID \
  -H "Authorization: Bearer $OPENAI_API_KEY"

# 3. Inventaire des fichiers laissés chez le fournisseur par les applications du projet
curl -s https://api.openai.com/v1/files \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.data[] | [.id, .filename, .purpose, (.created_at | todate)] | @tsv'

# 4. Suppression explicite d'un fichier devenu inutile
# curl -s -X DELETE https://api.openai.com/v1/files/<id_du_fichier> -H "Authorization: Bearer $OPENAI_API_KEY"

L’inventaire de l’étape 3 est à planifier, pas à exécuter une fois. Un fichier oublié par une preuve de concept reste chez le fournisseur bien après la fin du projet, sans propriétaire et sans date de fin.

Ce que la vérification technique ne prouve pas

L’API prouve ce qu’elle expose : un objet récupérable ou non, un fichier listé ou non. Elle ne prouve rien sur les journaux d’abus, les sauvegardes, ni sur la suppression effective des supports. Un code 404 dit que l’objet n’est plus servi, pas qu’il n’existe plus nulle part. Ces points relèvent de la preuve documentaire : conditions de service, engagements écrits sur la rétention, rapports d’audit tiers. Le détail des clauses de l’accord de traitement fait l’objet d’une page dédiée de la rubrique IA.

La vérification technique a aussi un angle mort côté client. Les journaux applicatifs, les traces d’observabilité et les outils de débogage enregistrent souvent les prompts complets. Une rétention nulle négociée chez le fournisseur pendant que la plateforme de traces interne garde tout pendant un an, c’est blinder la porte du voisin. Les règles de rétention de la télémétrie sont décrites dans observer un modèle de langage en production.

Conditions d’exploitation de la rétention

Un projet ou une clé par niveau de sensibilité. Les réglages de rétention s’appliquent souvent au niveau de l’organisation ou du projet chez le fournisseur ; mélanger données publiques et sensibles dans le même projet aligne tout sur le réglage le plus permissif.
Le paramètre de stockage fixé dans le code, pas hérité. Une valeur par défaut qui change entre deux versions d’API change silencieusement la rétention.
Une revue à chaque nouvelle fonction activée. Téléversement de fichiers, traitement par lots ou mémoire de conversation créent chacun un nouvel objet stocké.
Une procédure de suppression testée. La demande d’effacement d’une personne concernée doit pouvoir atteindre les objets stockés chez le fournisseur, ce qui suppose de savoir lesquels contiennent ses données.

🐝 Ce qui arrive si on s’en passe

Sans inventaire des objets stockés ni paramètre de stockage fixé, une demande d’effacement ne peut pas être exécutée de bout en bout : les fichiers et états de conversation conservés chez le fournisseur ne sont rattachés à aucune personne ni à aucun traitement, donc personne ne sait lesquels supprimer. La révocation d’une clé API ne supprime pas ces objets ; ils restent en général attachés au projet et lisibles par toute nouvelle clé émise sur ce même projet. En cas de compromission, le périmètre de ce qui a pu être consulté s’étend alors à tout l’historique stocké, et non aux seules requêtes de la période d’exposition.

🦫 Explication de la marmotte 🍫

Quand une application envoie un texte à un service d’intelligence artificielle sur Internet, ce texte ne sert pas qu’une fois. D’abord, le service le lit pour calculer une réponse, puis il l’efface de sa mémoire de travail. Mais il peut aussi en garder une copie pendant quelques semaines, pour repérer les personnes qui utilisent le service de façon interdite ; des employés du fournisseur peuvent relire les textes jugés suspects. Ensuite, si l’application a envoyé des fichiers ou demandé à conserver la conversation, ces éléments restent chez le fournisseur jusqu’à ce que quelqu’un les supprime volontairement. Enfin, le fournisseur peut, selon son contrat, se servir des textes pour améliorer ses futurs modèles. Pour savoir ce qui est gardé, on combine deux méthodes. La première est technique : on envoie une demande en précisant qu’il ne faut rien conserver, puis on essaie de la relire ; si on y arrive, le réglage ne fonctionne pas. On liste aussi les fichiers restés chez le fournisseur. La seconde est écrite : les copies de contrôle et les sauvegardes ne se voient pas de l’extérieur, donc seuls le contrat et les rapports d’audit en parlent. Il faut aussi vérifier ses propres journaux, qui gardent souvent les mêmes textes plus longtemps que le fournisseur.

Pages voisines

La citent

Rétention des données envoyées à une API d'IA générative

Elle cite

: les deux pages se citent l’une l’autre.