FAQ sécurité et checklist de mise en production

FAQ sécurité xAI

Avant de conclure ce cours par la revue de mise en production, répondons aux questions qui reviennent le plus souvent en formation — celles que vous vous poserez tôt ou tard, et dont certaines réponses surprennent.

Comment activer le MFA sur mon compte ? Le MFA (Multi-Factor Authentication) se configure sur accounts.x.ai, page Sécurité. L’activation vous remet une série de codes de récupération : déposez-les immédiatement dans un gestionnaire de mots de passe sécurisé, avant de faire quoi que ce soit d’autre. La suite de cette FAQ vous explique pourquoi ce réflexe n’est pas optionnel.

Que faire si j’ai perdu mes codes de récupération MFA ? C’est la réponse qui surprend le plus : xAI ne peut pas supprimer ni réinitialiser le MFA sans les codes de récupération. Il n’y a pas de procédure de secours par vérification d’identité, pas d’exception. La seule option restante est de contacter [email protected] pour demander la suppression de votre compte — imaginez perdre ainsi l’accès au compte qui porte vos clés de production parce qu’un téléphone est tombé dans l’eau.

Comment supprimer mon compte ? Sur accounts.x.ai/account. La suppression n’est pas immédiate : le compte reste restaurable pendant 30 jours, il suffit de vous reconnecter pour le récupérer. Passé ce délai, la suppression est définitive. Pour les demandes relevant de la confidentialité des données, l’adresse dédiée est privacy.x.ai.

Puis-je utiliser le même compte pour Grok et l’API ? Oui : les comptes sont partagés entre grok.com et console.x.ai. En revanche, la facturation est séparée — l’API se gère sur la console, tandis que les abonnements Grok se gèrent sur grok.com ou via Apple/Google. Ne cherchez donc pas vos coûts API dans votre abonnement Grok, ni l’inverse.

Comment détecter une connexion non autorisée ? La localisation affichée dans la console est une approximation basée sur l’adresse IP : une session apparue dans une ville voisine n’est pas forcément suspecte. Si le doute persiste, agissez dans cet ordre : réinitialisez votre mot de passe, effacez toutes les sessions actives, activez le MFA si ce n’est pas déjà fait, puis vérifiez l’historique d’utilisation de vos clés API — c’est là qu’une compromission laisse des traces mesurables.

Les crédits prépayés sont-ils remboursables ? Non, sauf obligation légale. Et un détail administratif qui coûte cher aux étourdis : les factures ne peuvent pas être régénérées rétroactivement avec de nouvelles informations. Vérifiez donc vos informations de facturation dans la console avant l’achat, pas après.

La revue de mise en production, pilier par pilier

Ce qui suit récapitule tout ce que le cours a abordé, organisé en six domaines à passer en revue avant chaque mise en production — pas seulement la première.

Le premier domaine est contractuel et réglementaire. C’est le seul qui ne dépend pas de votre code, et celui que votre juriste ou votre DPO doit pouvoir produire sur demande :

• Le DPA (Data Processing Agreement) est signé avec xAI
• Le BAA est signé si vous traitez des données de santé (HIPAA)
• Votre registre des traitements GDPR est mis à jour
• Une DPIA est réalisée si le traitement présente un risque élevé
• Votre politique de confidentialité mentionne xAI comme sous-traitant
• La résidence régionale des données est configurée si nécessaire

Tant qu’une de ces pièces manque, aucun réglage technique ne rattrapera la situation : un DPA absent est une non-conformité en soi.

Vient la gestion des clés API — statistiquement, c’est là que se produisent le plus d’incidents évitables. Vérifiez qu’aucune clé n’est exposée dans le code frontend et que toutes vivent dans des variables d’environnement serveur ou un gestionnaire de secrets. Chaque clé doit porter des ACLs restrictives, sans wildcard en production, une date d’expiration définie et des limites de débit (QPS, QPM, TPM) configurées. Les clés de développement et de production doivent être distinctes, un processus de rotation doit exister, et le fichier .env doit figurer dans le .gitignore — cette dernière ligne, triviale, est celle qu’on oublie le plus souvent.

Le troisième domaine est l’architecture, c’est-à-dire le chemin que prennent réellement vos requêtes. Tous les appels API doivent passer par un proxy backend ; les connexions WebSocket doivent utiliser des tokens éphémères, avec une durée réduite au minimum que votre cas d’usage supporte ; et l’authentification de l’utilisateur doit être vérifiée avant que votre serveur ne consente à proxier quoi que ce soit, sinon votre endpoint devient un relais gratuit vers l’API.

Le quatrième domaine couvre les données elles-mêmes. Confirmez que store: false est configuré par défaut pour les données sensibles et systématiquement appliqué aux images, que les données personnelles sont anonymisées avant envoi quand la fonctionnalité le permet, qu’une politique de classification des données est documentée, et que la rétention des logs côté application est définie — vos propres journaux peuvent conserver ce que xAI, lui, ne garde pas.

Le cinquième domaine réunit la modération et le monitoring. Les couches de pré-modération des entrées et de post-modération des sorties doivent être en place, un système de signalement offert aux utilisateurs, des alertes déclenchées sur les seuils de consommation, les limites de dépenses définies dans la console, et vos logs applicatifs doivent capturer les métadonnées sans jamais enregistrer de contenu sensible.

Le sixième domaine revient au compte, point d’entrée de tout le reste. Le MFA doit être activé sur tous les comptes administrateurs, avec les codes de récupération rangés dans un coffre-fort. Le SAML SSO doit être configuré si votre organisation le supporte, les équipes structurées par environnement et par projet, et les accès des anciens employés effectivement révoqués — vérifiés, pas supposés.

Une dernière série de tests transforme ces vérifications en certitudes : un test de charge avec les limites de débit configurées, un test de fallback en cas d’indisponibilité de l’API, un test de renouvellement des tokens éphémères, un test de la modération avec des cas limites, et la vérification que les clés de staging ne sont pas utilisées en production.

Le processus de revue sécurité récurrent

Une revue validée le jour du lancement se périme vite : les clés vieillissent, les équipes changent, xAI publie de nouvelles fonctionnalités. La sécurité doit donc s’installer dans votre calendrier à trois rythmes. Chaque mois, auditez les clés API actives et leurs permissions, passez en revue les alertes de consommation déclenchées et vérifiez les limites de dépenses — trente minutes suffisent quand c’est régulier. Chaque trimestre, effectuez la rotation des clés API, revoyez la politique de modération à la lumière des signalements reçus, mettez à jour la DPIA si le traitement a évolué, et formez les développeurs arrivés entre-temps. Chaque année, enfin, menez la revue complète du DPA et du BAA, l’audit de conformité SOC 2 / HIPAA, un test de pénétration incluant les flux API, et la mise à jour de votre référentiel avec les nouvelles fonctionnalités xAI. C’est ce dernier point qui garantit que votre documentation vit au même rythme que la plateforme.

Points clés à retenir

• Le MFA protège votre compte, mais les codes de récupération sont irremplaçables : sans eux, seule la suppression du compte reste possible
• La suppression de compte est réversible pendant 30 jours, définitive ensuite
• La revue couvre six domaines : conformité, clés, architecture, données, modération, compte — plus les tests pré-déploiement
• Planifiez des revues de sécurité mensuelles, trimestrielles et annuelles
• La sécurité est un processus continu, pas un état : mettez à jour votre référentiel à chaque évolution de la plateforme

Testez vos connaissances

Certifications, données, clés : la sécurité xAI avant la mise en production.

1. Quelles garanties de conformité xAI offre-t-il ?

Réponse : SOC 2 Type II, options HIPAA, GDPR avec résidence régionale des données — et l’engagement que vos données API ne servent pas à l’entraînement des modèles.

2. Comment protège-t-on la clé API dans une application ?

Réponse : Jamais côté client : la clé vit sur le serveur ; le temps réel côté navigateur passe par des tokens éphémères — courts, limités, révocables.

3. Que permettent les ACLs sur les clés ?

Réponse : Le moindre privilège : restreindre chaque clé aux endpoints et modèles nécessaires — une clé compromise n’expose que son périmètre.

4. Que règle store:false ?

Réponse : La non-persistance des données sensibles côté API : les contenus ne sont pas stockés — le réglage des applications qui traitent du confidentiel.

5. Que couvre la checklist de mise en production ?

Réponse : Clés protégées et tournées, ACLs posées, modération et politique d’usage actives, audit logs surveillés, données sensibles cadrées — la conformité en liste vérifiable.

Certifications en amont, clés bordées, données maîtrisées, audit en continu : la sécurité est un système — la checklist du cours en est le contrat.