Vos contrats sont chiffrés, signés et vérifiés dans votre navigateur. Le serveur ne conserve que des données chiffrées qu'il est cryptographiquement incapable de déchiffrer.
Demander une démo Voir la crypto en direct →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 lisible par l'opérateur de la plateforme, et par ses sous-traitants.
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, circuits à plusieurs signataires, signature express, vérification… Vous retrouvez 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. Parfait pour ce que vous ne voulez confier à personne.
Chaque signataire ajoute la sienne au PDF sans toucher à celles qui précèdent, par mise à jour incrémentale conforme à 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 par CRL.
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 RSA-OAEP. 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.Le tableau ci-dessous résume ce que le serveur voit réellement. Tout le reste, vous pouvez le contrôler vous-même, avec des outils tiers.
| 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 localement, stockées chiffrées (AES-GCM) par la clé dérivée du 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 Tabellion est un PAdES standard. Il se vérifie avec Adobe Acrobat, le validateur DSS de la Commission européenne, pdfsig (Poppler) ou pyhanko, sans que Tabellion ait son mot à dire.
Tout ce qui suit tourne maintenant, dans votre navigateur, via la Web Crypto API native, exactement les primitives qu'utilise Tabellion. Aucune bibliothèque distante, aucun appel réseau. Ouvrez la console : rien ne sort de cette page.
Comme un parapheur, vos documents suivent un circuit. Des signataires se succèdent, certaines étapes réunissent plusieurs personnes qui signent en parallèle, et une validation finale se déverrouille une fois que tout le monde a signé. Là où un parapheur classique se contente de tracer un visa, chaque étape produit ici une vraie signature PAdES horodatée, et le document reste chiffré de bout en bout du début à la fin.
Deux signataires qui déposent au même moment ? Un verrou optimiste (base_version)
garantit qu'aucune signature n'écrase celle de l'autre. En mode simple, un destinataire et
deux clics suffisent. En mode avancé, vous dessinez le circuit et Tabellion orchestre l'ordre
et l'empilement des signatures.
Un PDF signé avec Tabellion restera vérifiable dans dix ans, même sans Tabellion.
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.
Un jeton d'autorité d'horodatage est embarqué dans la signature. La date reste opposable même après expiration du certificat, et 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. L'enrôlement se fait par CSR, donc la clé privée ne quitte jamais le navigateur et c'est la session qui impose l'identité. Révocation par CRL signée.
Co-signature par mise à jour incrémentale. Chaque signature couvre sa propre révision du document, et celles d'avant restent valides. C'est ce qui rend possible les circuits à plusieurs signataires.
Voici les limites de Tabellion.
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 ».
Tabellion 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.
Un ordinateur quantique suffisamment puissant casserait à terme les signatures ECDSA P-256 (et le chiffrement RSA-OAEP). Les algorithmes de réponse sont normalisés depuis août 2024 par le NIST : ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), FN-DSA (FIPS 206) restant à l'état de projet. Tabellion peut produire une signature reposant sur ces algorithmes, donc résistante au quantique (via une bibliothèque dédiée, ces primitives n'étant pas encore dans la Web Crypto API).
En contrepartie, une telle signature ne serait pas (encore) un PAdES interopérable : les profils AdES de l'ETSI (PAdES, CAdES) pour ces algorithmes ne sont pas publiés, et même les briques sous-jacentes (emploi de ML-DSA dans le CMS et dans les certificats X.509) en sont au stade de projet à l'IETF. Le choix est donc explicite : soit une signature PAdES vérifiable dès aujourd'hui par tout outil PAdES du marché, soit une signature post-quantique, vérifiable par nos outils mais hors du cadre normalisé tant que les spécifications ne sont pas finalisées (horizon 2027 et au-delà).
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, la description et le motif de refus sont chiffrés ; les identités, le circuit et les 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, aucune dépendance servie par un tiers (pas de CDN). Pistes en cours : SRI et build reproductible. Le Zero-Knowledge protège intégralement les données stockées ; l'intégrité du code livré, elle, exige cette vigilance d'exploitation.
Tabellion 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, via OIDC). 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é.