store:false et gestion des données sensibles

Le paramètre store : votre levier de confidentialité

Parmi tous les réglages de l’API Grok, le paramètre store est celui qui a l’effet le plus direct sur la confidentialité : il détermine le devenir de vos données après traitement. Avec store: false, aucune trace de votre requête ni de la réponse n’est conservée par xAI une fois la génération terminée. La donnée transite, elle est traitée, elle disparaît. Pour un responsable conformité, cette garantie change la nature du risque : une donnée qui n’est pas stockée chez le sous-traitant ne peut ni fuiter de chez lui, ni être réclamée, ni compliquer votre registre des traitements. C’est un mécanisme essentiel pour la protection des données sensibles, et cette leçon vous montre quand l’utiliser, quand vous en dispenser, et comment le rendre systématique.

Quand store:false s’impose

Le premier cas est celui des données de santé, encadrées par HIPAA. Si votre application soumet à l’API des comptes-rendus cliniques, des diagnostics, des prescriptions ou toute donnée patient, la règle est sans exception : ces informations ne doivent jamais être conservées par un tiers non essentiel au traitement.

{
  "model": "grok-4.3",
  "messages": [
    {"role": "system", "content": "Vous êtes un assistant médical."},
    {"role": "user", "content": "Résumez ce compte-rendu clinique..."}
  ],
  "store": false
}

Le même raisonnement vaut pour les données financières — analyse de résultats trimestriels non publiés, rapports d’audit, données de marché confidentielles : la valeur de ces documents tient précisément à leur confidentialité, et un stockage tiers en constitue une brèche potentielle. Il vaut aussi pour les données juridiques : contrats, avis juridiques, correspondances avocat-client, où c’est le secret professionnel lui-même qui impose store: false — un avocat qui laisserait un tiers conserver ses échanges avec son client trahirait son obligation, quelle que soit la qualité de ce tiers.

Un quatrième cas mérite une vigilance particulière : les images et documents scannés. Le paramètre store: false est particulièrement recommandé dès que vos requêtes contiennent des images, pour une raison simple : une image peut contenir des informations sensibles qu’aucun scan textuel ne détectera. La photo d’identité qui traîne dans un coin du document scanné, le numéro de compte lisible sur la capture d’écran, le nom du patient sur l’en-tête du courrier photographié — vos filtres textuels ne les voient pas, mais ils sont bien là.

Quand store:true est acceptable

Faut-il alors bannir store: true (la valeur par défaut) ? Non — il a sa place, à condition de savoir laquelle. En phase de développement, la conservation des requêtes est même précieuse : elle vous permet de débugger via la console xAI, d’analyser les patterns d’utilisation et d’optimiser vos prompts en relisant ce qui a réellement été envoyé. Tant que vos jeux de test ne contiennent que des données fictives, aucun problème. De même, si votre application ne traite que des données publiques — articles de presse, documentation technique, données ouvertes — store: true ne pose aucun problème de conformité : on ne protège pas ce qui est déjà public.

Rendre store:false systématique

La vraie difficulté n’est pas de connaître la règle, c’est de garantir qu’elle est appliquée sur chaque appel, y compris celui qu’un développeur ajoutera dans six mois. Deux mécanismes s’en chargent. Le premier est un middleware de classification, qui décide automatiquement de la valeur de store en fonction du type de données :

def classify_and_set_store(request_data, data_classification):
    """
    Définit store en fonction de la classification des données.
    """
    sensitive_classifications = [
        "confidentiel",
        "secret",
        "medical",
        "financier",
        "juridique",
        "personnel"
    ]

    if data_classification in sensitive_classifications:
        request_data["store"] = False
    else:
        request_data["store"] = True

    return request_data

Le second est plus radical : forcer store: false par défaut en production via une variable d’environnement. Ainsi, l’oubli devient sans conséquence — il faut une action explicite pour activer la conservation, et non l’inverse.

import os

DEFAULT_STORE = os.environ.get("XAI_DEFAULT_STORE", "false") == "true"

def make_api_call(messages, store=None):
    if store is None:
        store = DEFAULT_STORE

    return {
        "model": "grok-4.3",
        "messages": messages,
        "store": store
    }

Au-delà de store : les pratiques complémentaires

Gardez-vous d’une illusion confortable : store: false ne fait pas de votre application une application conforme. Il empêche la conservation chez xAI, rien de plus. La première pratique complémentaire est l’anonymisation avant envoi : remplacez les noms propres par des identifiants génériques, les numéros de sécurité sociale par des placeholders, les adresses par des localisations génériques, les numéros de compte par des identifiants masqués. Une donnée qui ne part jamais n’a pas besoin d’être protégée à l’arrivée. Vient ensuite le chiffrement en transit : l’API xAI utilise TLS, mais vérifiez que votre client force HTTPS et refuse les connexions non sécurisées — la protection ne vaut que si elle est activée des deux côtés.

Enfin, le point aveugle le plus fréquent : votre propre rétention. Même si xAI ne conserve rien, votre application, elle, peut garder des copies — logs de requêtes, caches de réponses, exports de debug. Définissez des politiques claires : 30 jours maximum pour les logs contenant des données sensibles, suppression des réponses en cache à l’expiration de la session, et conservation des données d’audit alignée sur vos obligations réglementaires. Il serait paradoxal de payer le prix de store: false côté xAI tout en accumulant les mêmes données dans un fichier de logs non purgé.

Installer la règle chez vous

La mise en œuvre suit un ordre logique que je vous recommande de respecter, car chaque étape rend la suivante possible. Commencez par inventorier vos cas d’usage en identifiant le type de données que manipule chaque application : sans cette cartographie, toute règle reste abstraite. Posez ensuite la règle par défaut — store: false sauf exception documentée — puis implémentez le middleware de classification qui l’applique sans intervention humaine.

Deux exigences complètent le dispositif, et ce sont celles qu’on saute le plus volontiers. La première relève de la revue de code plutôt que de la documentation : imposez que chaque nouvel endpoint écrive store noir sur blanc, au lieu de s’en remettre au défaut. Une valeur explicite se relit et se discute en revue ; un défaut implicite, lui, passe inaperçu le jour où quelqu’un modifie la variable d’environnement. La seconde est la preuve : échantillonnez les requêtes que vos services émettent réellement et confrontez-les à votre classification. C’est ce relevé, et non votre document de politique, que retiendra un auditeur qui vous demandera non pas ce que vous avez décidé, mais comment vous savez que c’est appliqué.

Points clés à retenir

• store: false empêche toute conservation des données par xAI après le traitement
• Utilisez-le systématiquement pour les données médicales, financières, juridiques — et pour les images, qui échappent aux scans textuels
• Forcez store: false par défaut en production via une variable d’environnement : l’oubli devient inoffensif
• Combinez avec l’anonymisation avant envoi : la meilleure donnée protégée est celle qui ne part pas
• store ne remplace pas le reste : chiffrement en transit, rétention limitée côté application, contrôle des accès