Chiffrement de bout en bout : que signifie-t-il vraiment ?

Le chiffrement de bout en bout (end-to-end encryption, ou E2EE) est une promesse séduisante : seuls l'émetteur et le destinataire peuvent lire le contenu échangé, pas même le prestataire qui transporte les messages. C'est vrai dans WhatsApp ou Signal. Mais appliqué à un service de signature électronique, la réalité est plus nuancée — et parfois plus marketing que technique. Voici ce qu'il faut comprendre pour poser les bonnes questions à votre fournisseur.

Définition stricte du E2EE

Le chiffrement de bout en bout au sens strict (celui de Signal ou iMessage) implique que le contenu est chiffré sur l'appareil de l'émetteur, transite chiffré, et n'est déchiffré que sur l'appareil du destinataire. Le prestataire — qui héberge les serveurs — ne possède jamais les clés de déchiffrement. Techniquement, c'est implémenté avec des protocoles comme Signal Protocol, qui combine cryptographie asymétrique, échange de clés Diffie-Hellman et double rotation (Double Ratchet).

Chiffrement TLS vs E2EE

Beaucoup de services prétendent offrir du E2EE alors qu'ils ne font que du chiffrement en transit (TLS 1.2/1.3). La différence est fondamentale : en TLS, le contenu est chiffré entre le navigateur et le serveur, puis déchiffré côté serveur pour traitement. Le prestataire voit donc les données en clair sur ses serveurs. Ce n'est pas un défaut — c'est souvent nécessaire pour faire le travail — mais ce n'est pas du E2EE. Restez vigilant face aux arguments marketing.

Pourquoi le E2EE pur est rare en signature

Un service de signature électronique doit, par nature, traiter le contenu du document : afficher les pages au signataire, détecter les zones de signature, apposer l'empreinte cryptographique, générer le PDF final avec piste d'audit. Tout cela nécessite de déchiffrer le document côté serveur. Un E2EE strict (comme Signal) rendrait ces traitements impossibles. Donc la plupart des solutions de signature (y compris Certyneo) ne font pas de E2EE pur — elles font du chiffrement en transit TLS et du chiffrement au repos AES-256.

Ce qui compte vraiment

À défaut de E2EE pur, la sécurité d'un service de signature repose sur plusieurs couches : TLS 1.3 en transit (ce que tout le monde voit dans le cadenas du navigateur), AES-256 au repos sur les bases de données et les buckets de stockage, isolation des environnements (prod séparé de staging), gestion des secrets via un vault (HashiCorp, AWS KMS), rotation régulière des clés, journalisation d'accès. Ces mesures, combinées, offrent un niveau de protection très élevé.

Hébergement et souveraineté

La question de l'hébergeur est tout aussi importante. Un service qui dit chiffrer ses données mais les héberge aux États-Unis reste théoriquement accessible aux autorités américaines via le Cloud Act, même sans accès technique direct du prestataire. Pour des enjeux de souveraineté (secteur public, santé, défense), l'hébergement en UE — idéalement en France sur des infras certifiées SecNumCloud ou HDS — est un critère souvent plus déterminant que la couche E2EE.

Les questions à poser

Face à un fournisseur qui met en avant le chiffrement comme argument, posez ces questions : où sont hébergées les données ? quelles sont les certifications (ISO 27001, HDS, SecNumCloud) ? qui a accès aux clés de chiffrement (vault managé, KMS client) ? quelle est la politique de gestion des sauvegardes ? quelles sont les mesures en cas de demande des autorités étrangères ? Les réponses distinguent un fournisseur sérieux d'un discours marketing.

La position Certyneo

Chez Certyneo, nous ne prétendons pas faire du E2EE pur — ce serait incompatible avec notre service. Nous appliquons TLS 1.3 en transit, AES-256 au repos (documents et base de données), hébergement 100 % en France chez OVHcloud, isolation des environnements, et journalisation systématique des accès administrateurs. Les clés de chiffrement sont gérées via un vault interne dédié. C'est un modèle transparent, documenté dans notre politique de sécurité publique.