Confidentialité des données dans les collections

Vos documents restent vos documents

C’est la question que pose systématiquement le premier interlocuteur sérieux d’un projet RAG, direction juridique ou RSSI : si nous envoyons nos contrats chez xAI, servent-ils à entraîner Grok ? La réponse est non. xAI garantit que les données stockées dans les collections ne sont pas utilisées pour l’entraînement des modèles. Cette garantie couvre trois aspects distincts qu’il vaut la peine de séparer, parce qu’ils ne répondent pas aux mêmes inquiétudes.

L’absence d’entraînement d’abord : les fichiers uploadés dans les collections ne nourrissent ni Grok ni aucun autre modèle de xAI. L’isolation ensuite : vos collections ne sont accessibles qu’à travers vos propres clés API. La suppression enfin : lorsque vous supprimez un fichier ou une collection, les données et les index correspondants sont effectivement supprimés, ce qui est la condition technique pour honorer une demande d’effacement.

En pratique, cela ouvre les collections à des documents que vous n’auriez pas confiés à un service grand public : contrats et documents juridiques, rapports financiers internes, documentation technique propriétaire, données RH et politiques internes, correspondance confidentielle.

La sécurité repose sur vos clés

Chaque couple de clés — API Key et Management API Key — délimite un périmètre d’accès. Un tiers qui connaîtrait l’identifiant col_rh_policies ne peut rien en faire sans vos clés : il n’existe pas de chemin d’accès public à une collection. La conséquence est directe et sans nuance : la confidentialité de vos documents vaut exactement ce que vaut la protection de vos clés.

Stockez-les donc dans des variables d’environnement, jamais en dur dans le code, où elles finiraient dans votre historique Git.

import os

client = Client(
    api_key=os.getenv("XAI_API_KEY"),
    management_api_key=os.getenv("XAI_MANAGEMENT_API_KEY")
)

Le reste relève de l’hygiène classique et se néglige avec la même régularité. Faites tourner vos clés périodiquement, et impérativement après le départ d’un collaborateur qui y avait accès — une clé oubliée sur un poste rendu est un accès permanent à votre base documentaire. N’accordez à chaque clé que les permissions dont elle a besoin : un service qui ne fait que lire n’a rien à faire avec une clé capable de supprimer une collection. Surveillez enfin l’utilisation de vos clés dans la console xAI, où un pic d’appels inexpliqué reste le signal d’alerte le plus simple à repérer.

Ce que réclament les entreprises régulées

Avant de déposer des données soumises à réglementation — RGPD, HDS, SOC 2 —, la vérification porte moins sur la technique que sur le contrat. Il vous faut connaître les conditions d’utilisation de xAI concernant la localisation des données, l’état des certifications de sécurité de la plateforme, et les garanties contractuelles disponibles, notamment le DPA ou le BAA selon votre secteur. Ce travail se fait une fois, en amont, avec votre juridique ; le refaire après la mise en production coûte infiniment plus cher.

Établissez en parallèle une politique interne de classification qui dise clairement ce qui peut entrer dans une collection. Quatre niveaux suffisent en général, chacun associé à une règle de stockage sans ambiguïté :

L’intérêt d’un tel tableau n’est pas bureaucratique : il évite qu’un développeur pressé verse le référentiel de prix négociés dans la même collection que la FAQ publique, parce que personne n’avait jamais tranché la question.

Les données personnelles méritent un traitement à part. Dès que vos documents contiennent des noms, des adresses e-mail ou des numéros de téléphone, vous devez disposer de la base légale nécessaire à ce traitement, l’inscrire dans votre registre RGPD, et être capable de supprimer les documents concernés si une personne exerce son droit à l’effacement. Ce dernier point suppose de savoir dans quel fichier et dans quelle collection se trouve la donnée : tenez la correspondance à jour dès l’indexation, la reconstituer après coup sur plusieurs milliers de documents est un exercice pénible.

Une architecture en couches pour les exigences élevées

Une garantie de non-entraînement ne règle pas la question de savoir quel salarié peut lire quel document. C’est votre application qui porte cette responsabilité, à travers quatre couches successives. Elle authentifie l’utilisateur, détermine ensuite selon son rôle quelles collections lui sont ouvertes, n’interroge l’API que sur ces collections-là, et filtre enfin les résultats avant affichage. Un commercial pose une question sur les grilles tarifaires : sa requête ne part que vers col_docs_produit, jamais vers col_rh_policies, même si les deux collections vivent sous les mêmes clés. C’est cette discipline côté application, et non le stockage chez xAI, qui détermine ce que chacun finit par voir.

Points clés à retenir

• xAI garantit que les données des collections ne sont pas utilisées pour l’entraînement des modèles
• L’isolation des accès repose sur les clés API : chaque compte a son propre périmètre
• Stockez les clés dans des variables d’environnement et faites-les tourner régulièrement
• Classifiez vos documents avant de les stocker dans les collections
• Pour les données personnelles, respectez les obligations RGPD (consentement, registre, droit à l’effacement)