Vos données ne servent pas à l'entraînement

La question fondamentale : que deviennent vos données ?

C’est la première question que pose tout RSSI ou DPO lorsqu’on lui propose d’intégrer une API d’IA : est-ce que mes données seront utilisées pour entraîner le modèle ? La crainte sous-jacente est légitime — personne ne veut retrouver des fragments de ses contrats ou de ses données clients absorbés dans les poids d’un modèle accessible au monde entier. La réponse de xAI est claire : non.

Les données envoyées via l’API Grok — prompts, réponses, images — ne sont pas utilisées pour entraîner les modèles de xAI. Ce principe vaut pour l’API, c’est-à-dire le contexte d’intégration professionnelle. Il est distinct de l’utilisation de Grok sur grok.com ou via l’application, où les paramètres de confidentialité peuvent varier selon les choix de l’utilisateur.

API vs application : deux contextes différents

Cette distinction entre API et application est le point que vous devrez expliquer le plus souvent en interne, car la confusion est fréquente : un collaborateur qui a lu les conditions d’utilisation grand public de l’application en déduira à tort des conclusions sur l’API, et inversement.

Côté API, les règles du jeu sont celles du contrat professionnel : les données ne sont pas utilisées pour l’entraînement, vous contrôlez la rétention via le paramètre store, et les conditions sont définies par le contrat API (ToS Enterprise). C’est ce cadre qui s’applique à toutes vos intégrations.

Côté grok.com et application, les paramètres de confidentialité sont configurables par chaque utilisateur, les Collections — l’historique de conversations sauvegardées — sont gérées séparément, et ce sont les conditions générales d’utilisation qui s’appliquent. Si vos collaborateurs utilisent l’application à titre individuel, c’est ce régime-là qui les concerne, pas celui de votre contrat API.

Le paramètre store : contrôle de la rétention

Ne pas servir à l’entraînement est une chose ; ne pas être conservé du tout en est une autre. L’API Grok propose un paramètre store qui vous donne un contrôle granulaire sur le stockage de vos requêtes :

{
  "model": "grok-4.3",
  "messages": [{"role": "user", "content": "Analysez ce contrat..."}],
  "store": false
}

Avec store: false, la requête et la réponse ne sont pas conservées après le traitement : aucune trace ne subsiste dans les logs de xAI. C’est le réglage adapté aux données sensibles — médicales, financières, juridiques — et il est particulièrement recommandé pour les requêtes contenant des images. Imaginez un cabinet qui fait analyser des contrats confidentiels : avec store: false, le document n’existe chez xAI que le temps de l’inférence, ce qui simplifie radicalement l’analyse de risque.

Avec store: true (ou par défaut), la requête peut être conservée temporairement pour le monitoring de qualité, ce qui permet notamment le debugging via la console xAI. C’est un compromis utile en phase de développement, quand pouvoir rejouer et inspecter les requêtes fait gagner du temps — mais il doit rester cantonné aux données non sensibles.

Les Collections : comprendre la distinction

Les Collections sont une fonctionnalité de l’application Grok — pas de l’API — qui permet de sauvegarder des conversations. Point important, et souvent mal compris : les Collections ne sont pas utilisées pour l’entraînement des modèles. Sauvegarder une conversation dans une Collection signifie la conserver pour l’utilisateur, pas la verser dans un corpus d’entraînement.

Récapitulons la carte complète : l’API n’alimente pas l’entraînement et vous contrôlez la rétention via store ; les Collections de l’application sauvegardent des conversations sans alimenter l’entraînement ; pour l’usage de l’application hors Collections, vérifiez les paramètres de confidentialité de chaque compte.

Implications juridiques et contractuelles

Pour votre DPA au sens du GDPR, le fait que xAI ne réutilise pas vos données pour l’entraînement simplifie considérablement l’analyse : la finalité du traitement est limitée à l’inférence — générer une réponse — et non à l’amélioration du modèle. Cette limitation de finalité est précisément ce que le régulateur attend d’une relation de sous-traitance bien bornée.

L’argument porte aussi secteur par secteur. En santé, les données PHI ne sont pas réutilisées, ce qui, combiné au BAA vu en leçon 1, rend l’usage défendable devant un auditeur HIPAA. En finance, les données de marché ou les données clients ne fuient pas dans le modèle. Dans le juridique, le secret professionnel est préservé : le contenu d’un dossier ne pourra jamais ressortir dans la réponse faite à un autre utilisateur.

Traduire ces garanties en politique interne

Ce que vous venez de lire décrit ce que fait xAI. Reste à décider ce que fait votre organisation, et cela suppose une politique écrite que vos développeurs pourront appliquer sans arbitrage au cas par cas.

Le point de départ est la classification de vos données selon leur niveau de sensibilité : public, interne, confidentiel, secret. Cette échelle n’a rien de théorique, car c’est elle qui commande le réglage de store. Les données confidentielles et secrètes imposent store: false sans exception. Les données internes appellent le même réglage, cette fois à titre de recommandation forte. Seules les données publiques autorisent store: true, notamment pour bénéficier du debugging via la console pendant les phases de mise au point.

Reste à faire vivre cette politique. Formez vos développeurs pour qu’ils comprennent l’impact réel du paramètre : c’est le maillon décisif, car une politique parfaite sur le papier ne vaut rien si un développeur pressé laisse la valeur par défaut sur un flux de données confidentielles. Puis auditez régulièrement les appels réellement émis par vos services, en échantillonnant les requêtes de production — la dérive est silencieuse, et seule une vérification périodique la révèle.

Points clés à retenir

• Les données API ne sont pas utilisées pour entraîner les modèles Grok
• Le paramètre store: false empêche toute conservation des données après traitement
• Les Collections (application Grok) ne servent pas non plus à l’entraînement
• Utilisez store: false systématiquement pour les données sensibles et les images
• Documentez votre politique de gestion des données API pour la conformité