Stockage des requêtes de l'API Gemini activé par défaut : définir store=false par requête et par projet

Contexte : ce qui a changé pour les nouveaux projets Gemini payants

Depuis le 26 octobre 2026, les nouveaux projets payants de l'API Gemini stockent par défaut les prompts et réponses Generate Content. Les projets créés avant cette date conservent le stockage désactivé. Deux projets d'une même organisation, exécutant un code identique, peuvent donc se comporter différemment uniquement en raison de leur date de création.

Rien dans votre code ni dans vos journaux d'erreurs n'indique que la journalisation est active, c'est pourquoi le changement passe inaperçu. Si ces prompts contiennent des données clients, le responsable de la protection des données voudra en être informé, idéalement par vous, avec un état honnête de ce qui reste inconnu. La note de version n'explique pas pourquoi Google a changé la valeur par défaut, ne définit pas la date limite exacte pour les nouveaux projets et ne précise pas si le changement s'étendra plus tard aux projets existants. Organisez-vous en fonction de la répartition actuelle et partez du principe qu'elle pourrait évoluer.

Personne n'a rien divulgué ici ; une valeur par défaut a changé. La journalisation est une fonctionnalité documentée, réellement utile pour le débogage et l'évaluation : l'enjeu est donc de savoir quels projets l'ont activée et pourquoi.

Ce que Google conserve, et pendant combien de temps

La durée de conservation par défaut des journaux est de 55 jours, après quoi ils expirent et sont marqués pour suppression. Les propriétaires de projet peuvent réduire cette durée à 7, 14 ou 28 jours.

Les jeux de données méritent une attention particulière, car ils obéissent à d'autres règles. Les journaux enregistrés dans un jeu de données n'ont aucune durée de conservation et restent en place jusqu'à ce que quelqu'un les supprime. Les jeux de données peuvent être exportés en CSV, en JSONL ou vers Google Sheets, ce qui les rend utiles pour les travaux d'évaluation. Ces exports signifient aussi que des copies peuvent sortir du projet si personne ne les suit.

Par défaut, les prompts et réponses figurant dans les journaux des projets avec facturation activée ne sont pas utilisés pour améliorer ou développer les produits de Google. Le Contributor Tier, abordé dans les réserves ci-dessous, est l'exception à surveiller.

Certains modèles et certaines entrées ne sont pas du tout pris en charge par la journalisation. Le résumé du guide de Google rédigé par BaristaLabs cite les modèles Imagen et Veo, les modèles d'embedding Gemini, le modèle Gemini Robotics, les entrées contenant des vidéos, des GIF ou des PDF, ainsi que les agents en préversion publique.

L'ancrage (grounding) suit un circuit de conservation entièrement distinct. Les données issues de l'ancrage avec la recherche Google et de l'ancrage avec Google Maps sont conservées 30 jours, et cette conservation ne peut pas être désactivée.

Phase 1 (Audit) : inventorier les projets, les SDK et les responsables des données

Commencez par dresser la liste de tous les projets payants de l'API Gemini détenus par votre organisation, avec leur date de création. Considérez tout projet créé à partir du 26 octobre 2026 comme stockant les requêtes tant que vous n'avez pas confirmé le contraire.

Pour chaque service de cette liste, notez le langage du SDK et la version installée dans l'environnement d'exécution, car un README ou un ancien fichier requirements peut être en retard sur ce qui est réellement déployé. Vous ne pouvez définir store sur une requête que si le SDK le prend en charge, et les versions minimales diffèrent selon le langage.

Les services qui appellent aussi Vertex AI méritent une ligne distincte dans l'inventaire. Les notes de version Python et JavaScript qualifient toutes deux l'option store de « Gemini Developer API only ». Si certains services appellent Vertex AI via le même SDK, ne supposez pas que ce guide les couvre. Consultez la documentation de Google Cloud sur la gouvernance des données de Vertex AI pour ces services et consignez cette décision à côté de vos projets Gemini Developer API.

Une fois que vous savez quels projets et SDK sont actifs, la dernière question de l'audit relève de la politique : quelles charges de travail peuvent conserver la journalisation ? Tranchez-la avec votre responsable des données et consignez la réponse projet par projet. Le débogage interne et les travaux d'évaluation sont des candidats raisonnables. Les requêtes contenant des données personnelles de clients ne le sont généralement pas. À titre d'illustration, imaginez une équipe disposant de deux projets Gemini : un assistant de support qui résume des tickets contenant les noms et les détails de compte des clients, et un script d'évaluation interne qui rejoue des prompts synthétiques pour comparer des versions de modèles. Le projet de support reçoit la journalisation de projet désactivée et store=false dans le code. Le projet d'évaluation peut conserver la journalisation avec une courte durée de conservation, car les requêtes stockées y aident l'équipe à déboguer les régressions et à constituer des jeux de données, et aucun de ces contenus ne soulèverait de question de confidentialité.

Phase 2 (Upgrade) : passer chaque service à un SDK qui prend en charge store

Le paramètre store par requête nécessite au minimum les versions de SDK suivantes :

La version Python 2.33.0 et la version JavaScript 2.31.0 sont toutes deux sorties le 22 octobre 2026, et toutes deux ajoutent store à GenerateContentConfig. Pour Java et Go, les versions minimales indiquées sont google-genai 1.79.0 et google.golang.org/genai 1.76.0.

Mettez à niveau chaque service et figez la version dans votre fichier de verrouillage. Si la version n'est pas figée, un retour arrière ou un nouvel environnement pourrait discrètement faire perdre la prise en charge du champ.

Phase 3 (Configure) : définir d'abord la journalisation au niveau du projet dans AI Studio

Le paramètre de projet rattrape les requêtes que quelqu'un oublie de marquer, alors définissez-le avant de toucher au code.

Pour les projets qui ne doivent jamais stocker de requêtes, désactivez la journalisation au niveau du projet dans AI Studio, en suivant les étapes de la documentation Logs and datasets. Là où la journalisation reste active pour le débogage ou les évaluations, réduisez la conservation des 55 jours par défaut à 7, 14 ou 28 jours, selon ce qui convient à votre politique de données. Les jeux de données existants nécessitent un passage dédié, car modifier la conservation des journaux ne les nettoie pas : supprimez ceux dont personne n'a besoin et consignez tout export CSV, JSONL ou Google Sheets afin qu'il relève de votre gestion habituelle des données.

Quel paramètre l'emporte lorsque la requête et le projet divergent ? Nous conseillons de vérifier la règle de priorité dans la documentation actuelle sur les journaux avant de vous fier à l'un ou l'autre paramètre seul. Définir les deux enlève l'essentiel de l'urgence à la question. Si le projet est désactivé et que la requête indique store=false, un futur changement de valeur par défaut ou un paramètre oublié ne réactivera pas discrètement le stockage.

Phase 3, suite : désactiver le stockage par requête avec store=false

Étape 1 : définir store sur false dans GenerateContentConfig

Le paramètre est un champ nommé store dans GenerateContentConfig. Les extraits Python et JavaScript suivent la forme décrite dans les notes de version. Considérez les extraits Java et Go comme non vérifiés : nous n'avons pas confirmé la méthode du builder Java ni le type de son paramètre, ni si le champ Store en Go est un bool ou un *bool, avec les versions v1.79.0 et v1.76.0. Consultez les notes de version et la documentation du paquet Go avant de les déployer.

Python :

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="YOUR_MODEL_ID",
    contents="Summarize this support ticket...",
    config=types.GenerateContentConfig(store=False),
)

JavaScript :

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "YOUR_MODEL_ID",
  contents: "Summarize this support ticket...",
  config: { store: false },
});

Java :

// Unverified shape: confirm the builder method and parameter type in 1.79.0.
GenerateContentConfig config = GenerateContentConfig.builder()
    .store(false)
    .build();

GenerateContentResponse response = client.models.generateContent(
    "YOUR_MODEL_ID", "Summarize this support ticket...", config);

Go :

// Unverified shape: confirm whether Store is bool or *bool in v1.76.0.
config := &genai.GenerateContentConfig{
    Store: genai.Ptr(false),
}

resp, err := client.Models.GenerateContent(ctx, "YOUR_MODEL_ID",
    genai.Text("Summarize this support ticket..."), config)

Étape 2 : centraliser le paramètre dans un seul wrapper client

Les désactivations échouent généralement au seul point d'appel que personne n'a fait passer par le wrapper. Faites passer chaque appel Gemini par un unique helper interne qui applique store=false par défaut et n'autorise la journalisation que lorsqu'un appelant la demande explicitement et que la politique du projet le permet. La règle réside alors dans un seul fichier relu, au lieu de dizaines. Si vous centralisez déjà les appels aux fournisseurs derrière une passerelle, cette couche de routage est un emplacement judicieux pour la règle. Vérifiez simplement que l'indicateur de chaque fournisseur est bien transmis.

Étape 3 : l'imposer par un test ou une règle de lint

Un test unitaire sur la configuration produite par votre wrapper, ou une règle de lint qui signale les appels directs de génération sans valeur store explicite, permet de repérer le point de terminaison que quelqu'un ajoutera au prochain trimestre en oubliant de le router correctement.

Streaming, batch et autres fournisseurs

La nouvelle valeur par défaut est décrite pour les requêtes Generate Content. Avant de supposer que les chemins de streaming ou de batch se comportent de la même manière, consultez la documentation Logs and datasets de Google et les notes de version de l'API Gemini.

Les équipes qui utilisent plusieurs fournisseurs peuvent partager une seule politique. L'API Responses d'OpenAI conserve elle aussi l'état applicatif pendant 30 jours par défaut et accepte store: false.

Phase 4 (Verify) : prouver la désactivation par un test à marqueur

Le code montre ce que vous avez demandé. Le tableau de bord des journaux montre ce qui a réellement été stocké. Vérifier ce second point ne prend que quelques minutes.

1. Générez une chaîne de marqueur unique, par exemple un identifiant aléatoire suivi de la date du jour.
2. Depuis le projet testé, envoyez une requête contenant le marqueur avec store=false.
3. Depuis le même projet, envoyez une requête témoin avec un marqueur différent et la journalisation autorisée, si votre politique permet de stocker un prompt de test inoffensif.
4. Dans le tableau de bord des journaux AI Studio de ce projet, filtrez ou parcourez les journaux récents par horodatage et recherchez les deux marqueurs.
5. Réussite : seule la requête témoin apparaît. Échec : la requête store=false apparaît ; revérifiez alors la version du SDK, le wrapper ou le paramètre du projet.
6. Supprimez l'entrée de journal de la requête témoin si votre politique l'exige.

Si la journalisation au niveau du projet est déjà désactivée

Dans ce cas, la requête témoin n'apparaîtra pas non plus, et ne voir aucun des deux marqueurs est le résultat attendu. Cela montre que rien n'a atteint les journaux. Cela ne prouve pas que store=false fonctionne à lui seul, car le paramètre du projet bloque la requête dans tous les cas. Pour isoler l'indicateur, répétez le test depuis un projet de test dédié avec la journalisation activée, en utilisant la même version de SDK et le même wrapper, et uniquement des prompts inoffensifs.

Relancez le test après chaque mise à niveau de SDK, chaque modification du wrapper et chaque nouveau projet. Tenez un registre daté : projet, version du SDK, paramètre de journalisation du projet, paramètre de la requête, résultat. Lorsqu'une revue de conformité demande ce qui a été testé et quand, ce registre constitue votre réponse. Gardez à l'esprit que le test ne couvre que la fonction de journalisation ; la surveillance des abus et la conservation liée à l'ancrage en sont exclues.

Erreurs fréquentes lors de la désactivation du stockage des requêtes Gemini

Supposer qu'un ancien SDK respectera store. En dessous des versions minimales de la phase 2, le champ n'est pas disponible dans GenerateContentConfig.

Corriger un projet et oublier le suivant. Les nouveaux projets payants démarrent avec la journalisation active : ajoutez donc le paramètre de projet à votre checklist de création de projet.

Confondre désactivation et conservation nulle. Selon un article publié sur DEV Community, la surveillance des abus distincte de Google conserve toujours les prompts et les sorties pendant 55 jours, uniquement pour l'application des règles d'utilisation. Désactiver la journalisation n'y change rien, et la conservation liée à l'ancrage échappe elle aussi à ces paramètres.

Laisser d'anciens jeux de données en place. Les jeux de données n'expirent pas, et réduire la conservation des journaux ne les affecte pas.

Supposer que l'indicateur couvre Vertex AI. Les notes de version des SDK limitent store à la Gemini Developer API. Appliquez l'étape Vertex AI de la phase 1.

Checklist pour votre revue de stockage AUCV

• [ ] Audit : inventorier les projets payants de l'API Gemini et signaler ceux créés à partir du 26 octobre 2026
• [ ] Audit : consigner le langage du SDK et la version installée pour chaque service, et identifier les appels Vertex AI
• [ ] Audit : convenir avec le responsable des données des charges de travail autorisées à journaliser
• [ ] Upgrade : passer à Python 2.33.0, JavaScript 2.31.0, Java 1.79.0 ou Go 1.76.0 ou ultérieur, et figer les versions
• [ ] Configure : désactiver la journalisation au niveau du projet là où le stockage n'est pas autorisé, ou réduire la conservation à 7, 14 ou 28 jours
• [ ] Configure : examiner les jeux de données obsolètes, consigner leurs exports et les supprimer
• [ ] Configure : définir store=false dans un wrapper central, imposé par un test ou une règle de lint
• [ ] Configure : vérifier la couverture du streaming et du batch dans la documentation de Google
• [ ] Verify : exécuter le test à marqueur et conserver un registre daté
• [ ] Verify : documenter la conservation liée à l'ancrage et à la surveillance des abus dans les mentions de confidentialité

Réserves et questions ouvertes

Google n'a pas indiqué si les projets existants passeront à la nouvelle valeur par défaut. Cela suffit à justifier de définir store=false dans le code des projets plus anciens également. La couverture des points de terminaison et les règles de priorité figurent sur les pages de journaux et de changelog de Google, qui peuvent changer sans préavis : revérifiez-les donc à chaque mise à niveau de SDK.

Le chiffre de 55 jours pour la surveillance des abus provient d'une publication communautaire et non de la documentation de Google elle-même ; confirmez-le donc au regard des conditions d'utilisation des données de Google avant de l'intégrer à un document de politique.

Les tarifs réduits peuvent tirer dans la direction opposée. Google décrit un Contributor Tier sur invitation, en préversion privée, dans lequel les développeurs éligibles bénéficient d'une réduction allant jusqu'à 50% sur le coût des tokens de certains modèles, en échange de l'autorisation d'utiliser les données de ces modèles selon les conditions des Unpaid Services (services non payants). Cela inverse la protection par défaut des journaux des projets payants : impliquez donc le responsable de la confidentialité avant de vous inscrire.

Rien de tout cela ne fait de la journalisation un mauvais choix. Les requêtes stockées aident à déboguer les incidents de production et à constituer des jeux de données d'évaluation. Lorsque la journalisation du fournisseur est désactivée, vos propres traces deviennent la référence pour le débogage. Notre guide de traçage GenAI avec OpenTelemetry couvre cette mise en place, et la même décision du responsable des données doit encadrer tout contenu de prompt que vous y capturez. L'objectif est une décision claire par projet, car une désactivation généralisée peut priver les ingénieurs des données dont ils ont besoin.

Si un regard extérieur vous serait utile, Optijara peut mener cette revue de stockage avec votre équipe, sur Gemini et sur les autres fournisseurs d'IA que vous utilisez.