Sécurité et confiance
Des informations de sécurité vérifiables.
Cette page documente les contrôles et limites actuellement reflétés dans le produit et les politiques publiques.
Nous ne revendiquons pas de certification, résidence des données ou disponibilité sans documentation indépendante.
Le parcours d'une requête
Chaque requête protégée passe par les mêmes points de contrôle avant que les données du workspace ne soient accessibles.
Requête
Tout accès aux zones protégées commence sans identité et sans accès aux données.
Identité
Clerk vérifie l'identité et la session. Sans utilisateur connecté, la requête s'arrête ici.
Frontière d'organisation
Le contexte d'organisation est dérivé côté serveur de la session authentifiée — jamais de valeurs fournies par le client.
Données du workspace
Ce n'est qu'après les contrôles d'organisation et de workspace que le serveur renvoie les données de cet espace de travail.
Authentification
L'application authentifiée utilise Clerk pour l'identité et les sessions. L'accès protégé exige un utilisateur connecté.
Accès par organisation
Les données sont limitées par des contrôles d'organisation et d'espace. Le contexte d'organisation vient de l'accès authentifié.
Rôles et permissions
L'accès au sein d'une organisation est régi par des rôles gradués — des rôles propriétaire et administrateur aux rôles restreints d'édition et de lecture. Les contrôles côté serveur font autorité ; les éléments d'interface ne constituent pas une frontière de sécurité.
Téléversements et données client
Les documents téléversés et les contenus qui en sont dérivés sont rattachés à leur workspace et ne sont pas accessibles aux autres comptes.
Traitement par IA
Les fonctions d'IA passent par une couche interne contrôlée qui lie chaque appel au contexte utilisateur, organisation et workspace et rend la portée et le coût traçables. Le code produit ne communique pas directement avec les modèles.
Données et services
Contextter utilise des prestataires pour authentification, stockage, bases, facturation, analytics et certains workflows de données. Les catégories sont dans la politique de confidentialité.
Voir les prestatairesSecrets et journalisation
Les identifiants et clés d'API restent côté serveur. La couche de journalisation caviarde automatiquement les champs sensibles ; le contenu des demandes de contact n'est pas journalisé.
Développement sensible à la sécurité
Les changements touchant l'authentification, les permissions, la facturation et les interfaces publiques passent par une revue dédiée. Les évolutions du modèle de données sont additives et rétrocompatibles ; les tests protègent les frontières d'authentification et de facturation selon le risque.
Ce que nous n'affirmons délibérément pas
Cette page ne mentionne ni certifications, ni rapports de tests d'intrusion, ni garanties de disponibilité, ni labels de conformité. Si cela change, nous le documenterons ici avec des preuves.
Signaler un problème de sécurité
Indiquez l'URL ou la zone, une reproduction concise, l'impact et un moyen sûr de vous joindre. N'envoyez pas de secrets ni de données client au premier message.
Envoyer un signalementQuestions et demandes
Les demandes de sécurité, confidentialité, suppression et accès peuvent être envoyées via le contact public.