La connexion utilise Supabase Auth (GoTrue) avec des sessions JWT. Les jetons sont stockés dans des cookies HTTP-only, Secure, SameSite via le client SSR Supabase. La connexion via Google ou Apple utilise OAuth 2.0 / OIDC ; nous ne voyons jamais les mots de passe du fournisseur.

Les mots de passe (lorsque l’inscription par e-mail/mot de passe est utilisée) sont hachés avec bcrypt selon un coût recommandé par l’industrie. Nous ne consignons ni ne transmettons jamais de mots de passe en clair.

Les actions sensibles (changement de mot de passe, suppression de compte) peuvent exiger une ré-authentification ou un code à usage unique envoyé par e-mail. Une activité suspecte déclenche des limitations de débit et peut entraîner un examen du compte.

Tout le trafic public est exclusivement en HTTPS. Site marketing et application web : TLS terminé par la périphérie de Vercel et de Cloudflare. API et Auth : TLS terminé par notre reverse proxy Caddy à l’aide de certificats Let’s Encrypt automatisés ; Cloudflare se trouve en amont (mode Full Strict).

Le HSTS strict est activé avec une valeur max-age de type preload, et les en-têtes X-Content-Type-Options, Referrer-Policy et Permissions-Policy sont envoyés sur les réponses que nous servons.

Les données au repos résident sur des volumes Hetzner chiffrés en Allemagne. L’accès à la base de données nécessite des identifiants authentifiés limités au moindre privilège.

Les fichiers téléversés par les utilisateurs sont stockés dans un bucket Supabase Storage privé ; les URL signées sont à durée de vie courte et limitées à l’espace de travail de l’utilisateur demandeur.

Le serveur de production (Hetzner, Falkenstein) exécute Ubuntu LTS avec UFW configuré pour refuser par défaut tout trafic entrant ; seuls les ports 22 (SSH), 80 et 443 sont accessibles publiquement. SSH n’accepte que les clés.

Les services internes (PostgreSQL, embeddings, DECIMER, Supabase) sont liés à 127.0.0.1 à l’intérieur de leurs conteneurs et ne sont accessibles aux autres services qu’à travers un réseau Docker privé en pont ; ils ne sont pas exposés à l’internet public.

Le reverse proxy (Caddy 2) route api.cheemly.com vers l’API NestJS et auth.cheemly.com vers la passerelle Kong de Supabase. Cloudflare se trouve en amont pour la mitigation DDoS et le filtrage en périphérie.

Les images de conteneur sont récupérées depuis GitHub Container Registry ; le déploiement passe par un workflow GitHub Actions signé qui pousse les images et déclenche un `docker compose up -d` contrôlé sur le serveur.

La séparation des espaces de travail est appliquée au niveau applicatif : chaque requête API exige un JWT Supabase valide, l’identifiant utilisateur est extrait côté serveur, et les requêtes de base de données filtrent par cet identifiant afin que les utilisateurs ne puissent accéder qu’à leurs propres fils, fichiers, embeddings, références, sessions d’étude et rapports.

La liste d’autorisation CORS est restreinte à https://cheemly.com (production) et à l’origine marketing configurée.

Les entrées sont validées avec class-validator (DTOs NestJS) et Pydantic (FastAPI), prévenant de nombreuses classes d’injection.

Les secrets se trouvent en dehors du code source dans des fichiers d’environnement restreints à root sur le serveur de production, avec un mode de fichier 600. La clé de déploiement de GitHub Actions est limitée à la VM de production et peut être rotée.

Chaque réponse de chimie est soumise à une vérification Python déterministe avant d’atteindre l’utilisateur : les SMILES sont analysés avec RDKit, les comptes d’atomes sont équilibrés pour les réactions, les noms IUPAC font un aller-retour par OPSIN, et les citations sont résolues auprès des API académiques ouvertes.

Si le contrôle échoue, la réponse est régénérée ou signalée comme à faible confiance ; nous ne livrons jamais silencieusement une structure hallucinée.

Les structures en ASCII art sont interdites par règle d’invite et détectées par le critic ; le modèle est forcé de régénérer une véritable structure rendue par RDKit.

Tous les détails de paiement (numéro de carte, CVC, identifiants bancaires) sont gérés par Stripe, un prestataire certifié PCI-DSS niveau 1. Cheemly ne stocke que le statut d’abonnement, la formule, les métadonnées de facture et les identifiants client/abonnement Stripe.

Les événements webhook envoyés par Stripe sont vérifiés à l’aide du secret de signature de webhook avant d’être traités. Le rapprochement de facturation est consigné à des fins d’audit.

Les journaux opérationnels couvrent les erreurs, la latence, les tâches en échec, les événements d’authentification et la comptabilisation des quotas. Les données personnelles sont minimisées dans les journaux ; les corps complets des invites et le contenu des fichiers ne sont pas consignés en routine.

Les événements d’authentification stockent l’adresse IP, le user-agent et une empreinte d’appareil analysée pour aider les utilisateurs à vérifier « où je suis connecté ».

Nous tenons un journal d’activité interne pour les événements pertinents pour la sécurité (connexion, déconnexion, changement de mot de passe, téléversement de fichier, création de fil, changement de formule). Les utilisateurs peuvent demander une copie de leur propre journal d’activité via privacy@cheemly.com.

PostgreSQL est sauvegardé selon un calendrier quotidien rotatif. Les sauvegardes sont chiffrées et conservées sur un volume Hetzner distinct.

Objectif de temps de reprise (RTO) : 4 heures pour une restauration complète de la base de données. Objectif de point de reprise (RPO) : 24 heures.

Nous effectuons périodiquement des exercices de restauration et exploitons un environnement de pré-production distinct pour les tests non destructifs.

Chaque agent reçoit une invite de garde-fou : Moll ne révèle jamais le nom du modèle sous-jacent ni du fournisseur, refuse les demandes hors domaine et décline les flux de travail qui violent la politique d’usage acceptable.

Le mode recherche approfondie exige une confirmation explicite de l’utilisateur avant exécution ; la planification, la récupération et la synthèse se déroulent en phases que l’utilisateur peut observer et interrompre.

Le quota est appliqué côté serveur ; les clients ne peuvent pas contourner le compteur.

Nous suivons un processus de réponse aux incidents documenté : détecter, contenir, éradiquer, restaurer, notifier et mener un examen post-incident.

Lorsqu’une violation de données personnelles est susceptible d’engendrer un risque pour les droits des utilisateurs, nous notifions l’autorité de contrôle compétente dans un délai de 72 heures (art. 33 du RGPD) et, lorsque le risque est élevé, nous informons les utilisateurs concernés sans retard injustifié (art. 34 du RGPD). L’article 12(5) de la KVKK est traité avec le même objectif de 72 heures.

Les notifications incluent ce qui s’est produit, les données concernées, les actions entreprises et les étapes recommandées aux utilisateurs.

Les chercheurs en sécurité sont les bienvenus. Veuillez écrire à security@cheemly.com en indiquant les étapes de reproduction, les URL concernées, l’évaluation de l’impact et vos coordonnées. Un résumé lisible par machine est également publié à l’adresse /.well-known/security.txt.

Veuillez ne pas accéder aux données des autres utilisateurs, ni les modifier, supprimer ou exfiltrer ; n’exécutez pas de tests destructifs, de spam, de phishing, d’ingénierie sociale ou d’attaques par déni de service. Nous accuserons réception des rapports valides sous 5 jours ouvrés et viserons à remédier aux problèmes critiques sous 30 jours. Nous n’exploitons pas actuellement de programme de bug bounty rémunéré ; nous créditerons les chercheurs dans les notes de version sur demande.

Les recherches menées de bonne foi conformément à cette politique ne feront pas l’objet de poursuites judiciaires de notre part.

Cheemly est conçu pour s’aligner sur les obligations du RGPD, du UK GDPR, de la KVKK turque, de la FADP suisse et du CCPA/CPRA pertinentes pour un petit opérateur de produit IA.

Nous ne détenons pas actuellement de certifications SOC 2, ISO 27001 ou HIPAA. Les clients entreprise qui requièrent des attestations formelles de tiers peuvent discuter de leurs besoins avec sales@cheemly.com.

Si vous avez besoin d’un accord de traitement des données, d’un export de la liste des sous-traitants, d’une réponse à un questionnaire de sécurité ou d’une analyse d’impact de transfert, veuillez contacter legal@cheemly.com.