Question 1

Où les clés de chiffrement sont-elles stockées ?

Accepted Answer

Les DEK par utilisateur sont stockées chiffrées par une KEK dans un KMS dédié (actuellement soutenu par un service avec matériel isolé). Le KMS est le seul composant qui détient jamais des KEK en mémoire ; les serveurs applicatifs ne les voient jamais. La rotation des clés s'effectue automatiquement selon un calendrier glissant sans aucune interruption de service.

Question 2

Comment AI Emaily se connecte-t-il à Gmail ou Google Workspace ?

Accepted Answer

Gmail et Google Workspace se connectent via IMAP + SMTP standard en utilisant un mot de passe d'application que vous générez dans votre compte Google — pas Google OAuth. Ce mot de passe n'accorde que l'accès à la boîte mail (lecture, envoi, gestion des dossiers), jamais les contacts, Drive ou données d'administration, et vous pouvez le révoquer à tout moment depuis vos paramètres de sécurité Google. Il est chiffré par enveloppe au repos, exactement comme tout autre identifiant.

Question 3

Comment mes tokens OAuth et mots de passe sont-ils stockés ?

Accepted Answer

Chaque identifiant — tokens OAuth, mots de passe IMAP/SMTP, clés BYOK — est chiffré par enveloppe. Chaque valeur est enveloppée avec une DEK par utilisateur, elle-même chiffrée par une KEK conservée dans un KMS dédié. La DEK n'est jamais stockée à côté du texte chiffré qu'elle protège, et les identifiants en texte clair n'atteignent jamais les journaux applicatifs, les rapports d'erreurs ou les pipelines d'analyse. Ils ne sont déchiffrés qu'à l'intérieur d'un worker isolé au moment de leur utilisation.

Question 4

Mes e-mails sont-ils chiffrés en transit et au repos ?

Accepted Answer

Oui, dans les deux cas. Le trafic entre votre appareil et nos serveurs utilise TLS 1.2 ou supérieur avec des suites de chiffrement modernes ; les replis vers un TLS plus ancien sont rejetés au répartiteur de charge. Au repos, les corps des messages, les métadonnées et les résumés sont chiffrés avec AES-256 au niveau de la couche de stockage, et les blobs de corps de messages portent une clé supplémentaire par objet gérée par KMS — de sorte qu'une couche de stockage seule compromise ne peut pas produire de texte clair sans violer également le KMS.

Question 5

Qu'est-ce que le chiffrement par enveloppe et pourquoi l'utiliser ?

Accepted Answer

Le chiffrement par enveloppe signifie qu'un secret est chiffré avec une clé (la DEK), et cette clé est elle-même chiffrée par une autre (la KEK) conservée dans un KMS. L'avantage : le secret chiffré et la clé qui le déverrouille ne sont jamais stockés ensemble, et vous pouvez faire tourner la KEK sans rechiffrer chaque enregistrement. Cela limite le rayon d'impact — voler la base de données ne révèle pas les identifiants, car la KEK ne vit que dans le KMS.

Question 6

Comment AI Emaily empêche-t-il un utilisateur de lire les données d'un autre ?

Accepted Answer

Par l'autorisation au niveau objet. Chaque ligne de base de données, blob de stockage et invocation de fonction porte un identifiant de propriétaire, et les requêtes sans JWT vérifié correspondant sont rejetées au niveau de la couche de données — pas seulement au niveau de la couche API. Ainsi, même un bug dans le routage API ne peut pas divulguer les données d'un compte à un autre, car la requête en base de données filtre elle-même sur l'identifiant utilisateur authentifié et la politique de stockage refuse les lectures de blobs inter-comptes.

Question 7

À quelle fréquence les clés de chiffrement sont-elles renouvelées ?

Accepted Answer

La rotation des clés s'exécute automatiquement selon un calendrier glissant sans interruption de service. Les KEK sont renouvelées au sein du KMS, et les DEK par utilisateur peuvent être ré-enveloppées sans rechiffrer le texte chiffré sous-jacent, ce qui rend la rotation économique et continue plutôt qu'une migration de masse risquée. Les serveurs applicatifs ne détiennent jamais de KEK en mémoire — seul le KMS le fait — ce qui maintient la surface de rotation petite et maîtrisée.

Question 8

Comment évitez-vous les envois dupliqués sur une connexion instable ?

Accepted Answer

Chaque appel API mutatif — envoyer, archiver, étiqueter, déléguer — accepte une clé d'idempotence. Si une connexion est interrompue après que le serveur a accepté la requête, réessayer avec la même clé est une opération nulle plutôt qu'une seconde action. C'est particulièrement important pour l'envoi : une réponse perdue ne peut pas se transformer en un e-mail dupliqué, car le serveur reconnaît la clé répétée et renvoie le résultat original plutôt que d'agir à nouveau.

Question 9

AI Emaily stocke-t-il les données de ma carte bancaire ?

Accepted Answer

Non. Les données de carte ne touchent jamais les serveurs d'AI Emaily. La facturation passe par le checkout hébergé et les Elements de Stripe, qui gèrent la carte directement sous leur infrastructure conforme PCI. Nous ne stockons que l'identifiant client Stripe et le statut de votre abonnement — suffisant pour gérer votre offre, et rien qui pourrait exposer vos données de paiement si nos systèmes étaient compromis.

Question 10

Comment les webhooks entrants sont-ils sécurisés ?

Accepted Answer

Les webhooks de Stripe, Gmail Push Notifications et Microsoft Graph sont validés par des signatures HMAC avant qu'une charge utile ne soit traitée ; les requêtes rejouées ou falsifiées sont silencieusement ignorées et consignées. L'application web fournit également une Politique de Sécurité du Contenu stricte qui bloque les scripts en ligne, restreint les cibles de fetch à nos propres domaines et hôtes API connus, et interdit le cadrage tiers, avec un CORS par route limité aux origines de production et de staging.

Chiffrement et gestion des clés

Chiffrement en transit et au repos

Privilège minimal partout

Webhooks, CORS et CSP

Idempotence et nouvelles tentatives sécurisées

Frequently asked