Chiffrement

Ce que le SDK chiffre pour vous, et ce qui reste de votre responsabilité.

Ce que le SDK fait pour vous

Avant l'envoi, le SDK chiffre le corps du message et les fichiers dans votre application (AES-256), avec une clé générée pour chaque envoi. Le serveur qui conserve vos messages ne reçoit jamais cette clé. Vous ne manipulez aucune clé.
Pour dialoguer avec l'API, le SDK établit avec Secure Exchanges, à chaque opération, une clé de session distincte, par un échange de clés post-quantique (ML-KEM-1024) authentifié par une signature ML-DSA-87, en plus de HTTPS. Elle protège les paramètres des appels, comme les destinataires, l'objet et les noms de fichiers, que Secure Exchanges lit pour acheminer le message. Elle ne chiffre pas le contenu.
En transit, toutes les connexions passent par HTTPS, avec validation des certificats.
À la lecture, le SDK déchiffre le message et les fichiers pour votre application.

Vous n'avez donc rien à chiffrer vous-même pour envoyer, recevoir ou faire signer un document.

Sujet	Ce qu'il faut faire
Identifiants	Les conserver dans un gestionnaire de secrets. Voir Identifiants et environnements.
Contenu déchiffré	Ce que votre application lit ou télécharge est en clair chez vous : stockez-le chiffré, limitez qui y accède, et supprimez-le dès qu'il n'est plus nécessaire.
Contenus les plus sensibles	Protégez le message par un mot de passe que vous transmettez au destinataire par un autre canal : Secure Exchanges ne le reçoit jamais.
Objet et noms de fichiers	Secure Exchanges les lit pour acheminer le message : n'y mettez pas de renseignements personnels.
Journaux	N'y écrivez jamais de contenu déchiffré, de mot de passe de message, de code SMS ni de lien sécurisé.
Certificats TLS	Ne désactivez jamais leur validation. Voir Sécurité et bonnes pratiques.