Vos contrats sont chiffrés, signés et vérifiés dans votre navigateur. Notre serveur ne stocke que des données chiffrées qu'il est cryptographiquement incapable de déchiffrer.
Demander une démo Voir la preuve →Chez la plupart des prestataires, votre document transite et est traité en clair sur leurs serveurs. Sa confidentialité repose sur une clause de contrat, pas sur une impossibilité technique.
Contrats, dossiers RH, données médicales, propriété intellectuelle : tout ce que vous signez est exposé à l'opérateur de la plateforme et à sa chaîne de sous-traitance.
Un serveur qui concentre les documents en clair de milliers d'organisations est une cible idéale. Une seule compromission expose tout l'historique.
« Vos données sont en sécurité » est une phrase de page marketing. Nous avons préféré une architecture où le serveur n'a tout simplement rien à protéger.
Envoi de documents à signer, circuits à plusieurs signataires, signature rapide, vérification : l'expérience d'une solution moderne, avec une différence invisible mais fondamentale. Le serveur ne participe jamais au secret.
Déposez un PDF, signez, téléchargez. Le fichier ne quitte jamais votre machine : idéal pour les documents que vous ne voulez confier à personne.
Chaque signature s'ajoute par mise à jour incrémentale du PDF : les signatures précédentes restent intactes et vérifiables, conformément à la norme.
Certificats émis par l'autorité de certification de votre organisation
(O=Votre Société), avec chaîne de confiance complète et révocation.
Toute la cryptographie s'exécute via la Web Crypto API, dans votre navigateur. Le document en clair ne quitte jamais votre machine.
| Donnée | Le serveur la voit ? | Pourquoi |
|---|---|---|
| Contenu de vos documents | ✕ Jamais | Chiffré AES-256-GCM dans le navigateur avant tout envoi |
| Votre code PIN | ✕ Jamais | Transformé localement en clé (PBKDF2 ×600 000), il ne quitte pas le navigateur |
| Vos clés privées | ✕ Jamais en clair | Générées dans le navigateur, stockées uniquement chiffrées par votre PIN |
| Nom et description des fichiers | ✕ Jamais | Chiffrés comme le contenu : le serveur ne stocke que des identifiants opaques |
| Qui échange avec qui, et quand | ✓ Oui | Nécessaire pour acheminer les documents (voir le modèle de menace) |
Un PDF signé avec PrivaSign est un PAdES standard : il se vérifie avec Adobe Acrobat, le validateur DSS de la Commission européenne, pdfsig (Poppler) ou pyhanko, sans aucune dépendance à PrivaSign.
Chaque utilisateur possède une hiérarchie de clés dont la racine est son PIN, connu de lui seul. Le serveur n'est qu'un dépôt de blobs chiffrés et un annuaire de clés publiques.
DK), chiffre le PDF en
AES-256-GCM, puis chiffre cette clé pour vous et pour le destinataire avec
vos clés publiques respectives. Le serveur ne reçoit que des blobs opaques.PAdES-B avec sa clé ECDSA, obtient un horodatage RFC 3161
(seul un hash sort), puis rechiffre. Les signataires peuvent s'enchaîner : chaque
signature s'ajoute sans invalider les précédentes.Comme un parapheur, vos documents suivent un circuit : des signataires qui se succèdent, des étapes où plusieurs personnes signent en parallèle, et une validation finale qui se déverrouille quand tout le monde a signé. À la différence d'un parapheur classique, chaque étape produit une vraie signature PAdES horodatée, et le document reste chiffré de bout en bout pendant tout le circuit.
Mode simple : un destinataire, deux clics. Mode avancé : dessinez le circuit, PrivaSign orchestre l'ordre, les déblocages d'étapes et l'empilement des signatures sur le même PDF.
Un PDF signé avec PrivaSign restera vérifiable dans dix ans, même sans PrivaSign.
CMS ETSI.CAdES.detached avec attributs signés complets : content-type,
message-digest, signing-time, signing-certificate-v2 (ESS). Reconnue par le validateur
DSS de la Commission européenne.
Jeton d'autorité d'horodatage embarqué dans la signature : la date est opposable même après expiration du certificat. Seul un hash est transmis à la TSA, jamais le document.
Chaîne de confiance complète signataire → CA intermédiaire → racine au nom de votre organisation. Enrôlement par CSR : la clé privée ne quitte jamais le navigateur. Révocation par CRL signée.
Co-signature par mise à jour incrémentale : chaque signature couvre sa révision du document, les précédentes restent intactes et vérifiables. La base des circuits de validation à plusieurs signataires.
Une architecture de sécurité honnête énonce ses limites. Voici les nôtres, sans détour.
Même un attaquant, ou un administrateur indélicat, disposant d'un accès complet au serveur (base de données, stockage, mémoire) n'obtient que des blobs chiffrés, des clés publiques, et des clés privées elles-mêmes chiffrées par des PIN qu'il ne possède pas. Le déchiffrement des documents est cryptographiquement hors de sa portée.
Si nous pouvions restaurer votre accès sans votre PIN, nous pourrions aussi lire vos documents. Personne ne le peut, pas même nous : un PIN oublié rend les documents déjà chiffrés définitivement illisibles. Un nouveau PIN permet de repartir pour les documents suivants. C'est la contrepartie directe, et assumée, du « le serveur ne peut pas déchiffrer ».
PrivaSign produit des signatures électroniques avancées au format PAdES, approuvées au sein de votre organisation via sa PKI interne. La signature « qualifiée » au sens eIDAS exige un prestataire qualifié (QTSP) et une clé détenue dans un dispositif certifié (QSCD), un modèle incompatible avec la génération des clés dans le navigateur, donc avec le Zero-Knowledge. Nous avons choisi : confidentialité d'abord. L'horodatage, lui, peut être rendu qualifié en pointant vers une TSA qualifiée.
Le serveur sait qui échange avec qui, et quand : c'est inhérent à tout service qui achemine des documents entre comptes. Le contenu, le nom du fichier et sa description sont chiffrés ; les identités et horodatages ne le sont pas. L'adresse IP des signataires n'est pas enregistrée.
Les clés privées sont chiffrées par une clé dérivée du PIN (PBKDF2-SHA256, 600 000 itérations minimum imposées par le serveur). Un vol complet de la base permettrait une attaque hors-ligne sur le PIN : la politique par défaut impose un secret alphanumérique de 8 caractères minimum, configurable par déploiement.
Le chiffrement s'exécute dans votre navigateur, mais le JavaScript qui le réalise est distribué par la plateforme. Un serveur compromis qui parviendrait à modifier ce code pourrait capter le PIN ou un document au moment où il est en clair chez vous. C'est la limite de toute cryptographie web, et nous la réduisons activement : politique CSP stricte (aucun script externe ni inline), aucune dépendance servie par un tiers (pas de CDN). Le Zero-Knowledge protège intégralement les données stockées ; l'intégrité du code livré, elle, exige cette vigilance d'exploitation.
PrivaSign protège ce qui transite et ce qui est stocké côté serveur. Si votre machine est compromise (logiciel malveillant, enregistreur de frappe), l'attaquant voit ce que vous voyez : le PIN saisi, le document déchiffré à l'écran. Aucune architecture serveur, Zero-Knowledge ou non, ne protège un poste compromis.
L'authentification est déléguée à votre annuaire d'entreprise (SSO). Un administrateur de cet annuaire qui réinitialise le mot de passe d'un utilisateur peut se connecter à sa place, réinitialiser son PIN et obtenir un nouveau certificat : il devient alors capable de signer de futurs documents en son nom. En revanche, sans le PIN, il ne peut déchiffrer aucun document, passé ou présent, ni falsifier les signatures antérieures (horodatées). L'attaque est de plus très visible : l'utilisateur légitime perd l'accès à ses documents et son ancien certificat dès la réinitialisation. Ce risque est commun à tout service adossé à un SSO ; il se traite par la gouvernance de l'annuaire (MFA obligatoire, audit des actions d'administration) et par la révocation immédiate du certificat usurpé.