Sécurité chez LangReply

Ce que nous chiffrons, ce que nous détruisons, et ce que nous ne pouvons honnêtement pas garantir. Écrit sans jargon marketing.

1. Chiffrement au repos

Les données sensibles (comptes utilisateurs, historiques de traduction, messages OTT, préférences) sont chiffrées au repos avec AES-256-GCM. La clé maîtresse réside hors du dépôt Git, sur un volume à accès restreint (permissions 600, propriétaire dédié).

Chaque enregistrement sensible embarque son propre IV (nonce aléatoire 96 bits) et son tag d'authentification GCM. Une altération du texte chiffré est détectée au déchiffrement (échec cryptographique, pas de corruption silencieuse).

Exception documentée : le fichier languages.json (liste publique des langues supportées) est explicitement exclu du chiffrement : c'est un catalogue public, pas une donnée personnelle.

2. Effacement irréversible (crypto-shredding)

Principe

Chaque conversation OTT, chaque lot de messages sensibles et chaque compte utilisateur possèdent une DEK (Data Encryption Key) dédiée — une clé AES-256 unique, générée aléatoirement. Les données sont chiffrées avec cette DEK ; la DEK elle-même est chiffrée par la clé maîtresse (KEK).

Pour effacer irréversiblement les données, nous détruisons la DEK. Les octets chiffrés peuvent rester présents en base ou sur disque : sans la clé, ils sont indistinguables de bruit aléatoire.

Garantie mathématique

Une DEK AES-256 a un espace de 2256 valeurs possibles — environ 1,16 × 1077. Retrouver une clé détruite par force brute est, en l'état des connaissances publiques en cryptographie et de la puissance de calcul disponible (y compris post-quantique projetée avec Grover, qui ramène à 2128), infaisable.

Ce qui est réellement détruit

  • La DEK en RAM (zéroïsation immédiate).
  • La DEK chiffrée en base (UPDATE ... SET encrypted_dek = NULL + VACUUM Postgres quand applicable).
  • Les copies en cache applicatif.

3. Messages qui disparaissent automatiquement

Chaque conversation OTT peut activer un délai d'auto-purge : au-delà, les messages sont détruits par crypto-shredding de leur DEK de conversation.

Durées configurables

En l'absence de réglage, aucune durée par défaut ne s'applique : les messages sont conservés jusqu'à suppression manuelle.

La durée s'applique au message dès qu'il est lu par le destinataire (par défaut) ou dès qu'il est envoyé (option). Un balayeur serveur passe toutes les 10 minutes et purge ce qui a expiré.

La modification du délai est visible dans la conversation (message système horodaté). Ni l'expéditeur ni le destinataire ne peut « prolonger » un message déjà expiré : la clé est détruite.

4. Purge extrême du compte

Dans le portail utilisateur, le bouton « Détruire tous mes messages » déclenche la destruction immédiate de toutes les DEK associées à votre compte : conversations OTT, historique de traduction, brouillons, pièces jointes chiffrées.

L'opération est :

Une purge du compte ne supprime pas le compte lui-même (identifiant, courriel, préférences de facturation) : pour ça, utilisez la suppression complète du compte, distincte.

5. Isolation par compte

Chaque compte a sa propre DEK. Une compromission d'une DEK n'expose que les données de ce compte, pas celles des autres. La clé maîtresse (KEK) est nécessaire pour déchiffrer les DEK, mais elle ne suffit pas à lire un compte sans la DEK correspondante encore présente en base.

Les requêtes API sont scopées par account_id. Aucune route ne prend l'identifiant d'un compte en paramètre libre sans vérification d'appartenance de la session.

6. Moteur de traduction auto-hébergé

La traduction principale utilise NLLB-200 1.3B (202 langues) hébergé sur notre propre serveur, dans un microservice interne, non exposé sur Internet. Le contenu ne quitte pas notre infrastructure pour être traduit.

Secours : en cas d'indisponibilité, un repli automatique peut solliciter Claude (Anthropic) uniquement. Ce repli est désactivable par compte pour les usages sensibles ; quand il est utilisé, le contenu est transmis à Anthropic et nous le signalons dans la réponse d'API.

Le repli MyMemory a été retiré le 28 juillet 2026 : il transmettait le contenu en clair dans l'URL, sans contrat de sous-traitance. Il n'existe pas de troisième recours : si aucun moteur n'est disponible, la traduction échoue plutôt que d'être confiée à un tiers non contractualisé.

7. Authentification

Mots de passe hachés avec scrypt (N=16384, r=8, p=1). Sessions par cookie HttpOnly signé HMAC. 2FA disponible : TOTP (Google Authenticator, Aegis, 1Password) et OTP par SMS (Twilio, messages localisés dans la langue du destinataire).

Limitation de débit sur les endpoints d'authentification (429 après tentatives répétées). Aucun mot de passe n'est envoyé par courriel ; les réinitialisations utilisent un lien à usage unique.

8. Sauvegardes

Sauvegardes chiffrées quotidiennes du volume de données. Rétention : 14 jours glissants, puis suppression.

Une copie chiffrée hors-site (AES-256) est conservée chez GitHub et Backblaze (États-Unis). Les messages OTT/SMS et leurs clés en sont exclus et ne quittent jamais l'Union européenne.

9. Vos droits (RGPD / Loi 25 / CCPA)

Droit d'accès, de rectification, d'effacement, de portabilité et d'opposition. Les demandes se font par courriel à privacy@langreply.com et sont traitées sous 30 jours. L'effacement utilise la purge par crypto-shredding décrite plus haut.

10. Certifications — honnête

Nous ne sommes pas certifiés SOC 2, ISO 27001 ni HIPAA aujourd'hui. Nous ne le prétendrons pas tant que ce ne sera pas vrai. Les mesures décrites ici sont réellement en place ; les audits externes correspondants ne le sont pas encore.

11. Ce que nous ne garantissons pas honnêtement

Nous préférons dire la vérité plutôt que vendre une illusion. Voici ce que le crypto-shredding ne fait pas :

  • Sauvegardes : nos sauvegardes excluent les tables de messages et de clés — une restauration ne peut pas ré-exposer un message détruit. Contrepartie assumée : en cas de perte de la base, l'historique OTT/SMS n'est pas récupérable.
  • Capture d'écran côté destinataire : si vous envoyez un message qui disparaît à quelqu'un, cette personne peut prendre une photo de son écran avec un autre appareil. Aucun logiciel au monde ne peut empêcher cela. Signal ne le peut pas non plus.
  • WAL, journaux, réplicas : Postgres écrit des journaux de transactions (WAL). Un octet chiffré peut y avoir séjourné avant d'être effacé. Ces journaux sont rotés, mais pas instantanément.
  • SSD et wear-levelling : les disques SSD répartissent les écritures physiquement. Un DELETE logique n'écrase pas nécessairement le secteur physique. C'est justement pour cette raison que le crypto-shredding est plus fiable qu'un effacement physique — mais l'octet chiffré peut subsister physiquement quelque temps. Sans la clé, il reste illisible.
  • Métadonnées d'audit : nous conservons des métadonnées minimales (horodatage d'une purge, IP) pour l'audit et la lutte contre l'abus. Ces métadonnées ne contiennent pas le contenu détruit.
  • Chiffrement de bout en bout : la messagerie OTT est chiffrée au repos côté serveur, mais elle n'est pas E2EE au sens de Signal (où même le serveur ne peut pas lire). LangReply est capable, techniquement, de déchiffrer un message tant que sa DEK existe. Nous ne le faisons pas — mais nous ne pouvons pas prétendre l'inverse.

12. Signaler un problème de sécurité

Divulgation coordonnée à security@langreply.com avec objet [SECURITY]. Nous accusons réception sous 72 h et publions un correctif ou une atténuation dans un délai raisonnable selon la gravité. Aucun bug bounty formel pour l'instant ; nous mentionnons les rapporteurs qui le souhaitent.

Dernière mise à jour : 6 août 2026.