Architecture de sécurité
Comment fonctionnent réellement les engagements de confidentialité de PDF Pro.
Tout ce qui figure sur cette page est vérifiable dans les DevTools de votre navigateur. La règle fondamentale : nous ne devons pas être en mesure d'accéder à vos fichiers — même si nous le voulions. Voici comment cette règle est appliquée au niveau de la cryptographie, du stockage et des requêtes.
memoryWebAssembly et JS côté client
lockAES-256-GCM
verifiedECDSA P-256
cloud_offStockage chiffré côté client
Quatre piliers architecturaux
Quatre choix techniques définissent la posture de sécurité. Ils sont appliqués par le code qui s'exécute dans votre navigateur — pas par un document de politique.
1. Traitement local en priorité
L'affichage, l'annotation, le remplissage de formulaires, la compression, la fusion, la conversion et la signature de PDF s'exécutent entièrement dans votre navigateur via WebAssembly et JavaScript. Pour ces outils, aucune donnée de fichier ne quitte jamais votre appareil — vérifiable dans votre onglet Réseau.
2. Clés générées côté client
Lorsque vous devez partager un fichier, la clé de chiffrement est générée par l'API Web Crypto à l'intérieur de votre onglet. Elle réside en mémoire, dans le fragment d'URL ou (en mode phrase secrète) est dérivée sur l'appareil du destinataire via PBKDF2. Le serveur ne la voit jamais.
3. Stockage chiffré côté client
Seul le texte chiffré AES-256-GCM accompagné d'un vecteur d'initialisation (et, en mode phrase secrète, d'un sel PBKDF2) est stocké. Sans la clé, ces données sont cryptographiquement indiscernables d'octets aléatoires. Un accès root à la base de données ne nous aiderait pas à les déchiffrer.
4. Une frontière IA honnête
Les outils d'IA (chat, résumé, traduction) ont besoin de texte lisible pour fonctionner. Nous extrayons le texte côté client et n'envoyons que celui-ci au fournisseur du modèle — jamais le fichier PDF lui-même, jamais les images, jamais les pièces jointes intégrées. Voir la section IA ci-dessous pour tous les détails.
Flux de chiffrement (Transfert sécurisé)
Une description octet par octet de ce qui se passe lorsque vous déposez un PDF dans Transfert sécurisé et partagez le lien généré. Chaque étape ci-dessous s'exécute dans le navigateur, sauf le stockage du texte chiffré.
Expéditeur — dans le navigateur
// 1. generate a fresh 256-bit key
key = crypto.subtle.generateKey({name:"AES-GCM", length:256})
// 2. random 96-bit IV per file
iv = crypto.getRandomValues(new Uint8Array(12))
// 3. encrypt the PDF bytes locally
ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes)
// 4. upload ciphertext + iv — nothing else
id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}})
// 5. build the share link with the key in the URL fragment (#)
link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
Serveur — ne stocke que du texte chiffré
ciphertext = opaque bytes // cannot be decrypted without the key
iv = 12-byte nonce
expiry = 24 h (free) / 30 d (Pro)
// the URL fragment (#...) is NEVER sent to the server by browsers
▼
Destinataire — dans le navigateur
// 1. browser loads the page; the "#..." fragment stays client-side
rawKey = location.hash.slice(1)
// 2. fetch the ciphertext
ct = await fetch("/api/transfer/" + id)
// 3. decrypt locally using Web Crypto
pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct)
// 4. file ends up in the recipient's Downloads folder
La garantie de sécurité repose entièrement sur l'étape 5 (expéditeur) et l'étape 1 (destinataire) : le fragment d'URL après # n'est transmis au serveur par aucun navigateur conforme. C'est ce qui fait du lien lui-même l'identifiant de déchiffrement.
Le mode phrase secrète remplace l'étape 1 (expéditeur) par PBKDF2-SHA256(phrase, sel, 310_000). Le sel est stocké côté serveur ; la phrase secrète est partagée avec le destinataire hors bande.
Flux de signature (ECDSA P-256)
La signature PDF utilise ECDSA sur la courbe NIST P-256. La clé privée est générée dans votre navigateur ; le document ne quitte jamais votre appareil.
Génération de la clé privée
Une paire de clés ECDSA P-256 est générée via
crypto.subtle.generateKey dans votre navigateur. La clé privée est exportée vers une JSON Web Key (JWK) protégée par mot de passe, que vous pouvez stocker localement.Hachage SHA-256 et signature
Les octets du PDF sont hachés en SHA-256 côté client. Ce hachage est signé par la clé privée. La signature est intégrée au PDF dans un conteneur CMS (profil PAdES-B-B).
Vérifiable hors ligne
Toute personne disposant de la clé publique (distribuée avec le document ou sous forme d'empreinte) peut vérifier la signature hors ligne. Aucun aller-retour vers le serveur n'est nécessaire.
Ce que ce n'est pas
Nos signatures sont cryptographiquement vérifiables, mais ne sont pas des signatures électroniques qualifiées (SEQ) au sens du règlement eIDAS. Ce sont des preuves d'intégrité résistantes à la falsification, adaptées aux flux internes et non à une valeur juridique de niveau réglementaire.
Fonctionnalités IA — où nous sommes honnêtes sur la limite
AI Chat, Résumé IA et Traduction ont besoin de texte lisible. Voici exactement ce qui quitte votre appareil et ce qui n'en sort pas.
Texte extrait dans le navigateur
Le PDF est analysé localement via pdf.js. Seul le texte extrait (ou, pour les PDF numérisés, le résultat de l'OCR) est conservé en mémoire — le fichier original reste sur votre appareil.
Seul le texte va au fournisseur
Nous envoyons cette chaîne de texte au fournisseur d'IA (Anthropic / OpenAI). Le PDF lui-même, les images intégrées, les polices et les données de formulaire ne sont jamais transmis à un modèle d'IA.
Aucun entraînement sur votre contenu
Nos contrats avec les fournisseurs désactivent l'entraînement sur le contenu client. Les requêtes sont sans état — chacune est limitée à votre session.
Quand cela importe
Si votre document contient des informations réglementées (PHI, classifiées, secret professionnel) pour lesquelles même l'extraction de texte est sensible, n'utilisez pas les fonctionnalités IA et privilégiez les outils locaux (consultation, annotation, signature, compression, conversion) — ceux-ci fonctionnent à 100 % dans le navigateur.
Modèle de menaces — ce contre quoi nous protégeons, et ce que nous ne pouvons pas empêcher
Être clair sur le modèle de menaces est plus utile que le marketing. Voici ce que l'architecture arrête réellement, et où elle s'arrête.
shieldCe contre quoi l'architecture protège
- Le personnel de PDF Pro lisant vos fichiers sur nos serveurs (nous ne détenons jamais la clé).
- Une violation au niveau de la base de données du stockage de transfert (l'attaquant voit du texte chiffré, pas des fichiers).
- La divulgation judiciaire du contenu des fichiers (nous ne pouvons remettre que du texte chiffré — c'est tout ce dont nous disposons).
- La conservation par le serveur de messagerie de pièces jointes sensibles (rien ne touche jamais votre serveur de messagerie).
- L'altération d'un PDF signé (la vérification de la signature ECDSA détecte toute modification d'octet).
warningCe contre quoi aucun outil basé sur un navigateur ne peut protéger
- Un terminal compromis (logiciel malveillant sur votre appareil) — les clés résident en mémoire sur un appareil qui doit être de confiance.
- Quelqu'un qui observe le fragment d'URL par-dessus votre épaule — traitez le lien de partage comme le fichier lui-même.
- Une phrase secrète faible en mode phrase secrète — PBKDF2 ralentit l'attaque par force brute mais ne rend pas sûre une phrase de 6 caractères.
- Un destinataire qui transfère un fichier déchiffré — la sécurité du transport prend fin lorsque le destinataire enregistre le PDF.
- Une compromission du navigateur lui-même ou une extension malveillante injectant du code dans la page.
Aucune prétention d'« inviolabilité ». Le chiffrement de bout en bout augmente significativement le coût d'une violation — il n'élimine pas tout risque, en particulier au niveau du terminal. Pour les cas les plus sensibles, combinez le Transfert sécurisé avec une phrase secrète distincte et un échange de clé par canal de confiance.
Lectures associées
Questions fréquentes
PDF Pro peut-il déchiffrer mes fichiers ?
Non. Les clés de chiffrement sont générées et conservées dans le navigateur de l'utilisateur. Pour le Transfert sécurisé, le serveur ne stocke que du texte chiffré AES-256-GCM accompagné d'un vecteur d'initialisation (et d'un sel en mode phrase secrète). La clé n'atteint jamais notre infrastructure. Même avec un accès complet à la base de données, nos opérateurs ne peuvent pas déchiffrer votre fichier.
Qu'est-ce qui s'exécute localement et qu'est-ce qui s'exécute sur le serveur ?
La consultation, l'annotation, le remplissage de formulaires, la compression, la fusion, la conversion et la signature s'exécutent à 100 % dans votre navigateur via WebAssembly et JavaScript — aucune donnée de fichier ne quitte votre appareil. Les fonctionnalités d'IA (chat, résumé, traduction) extraient le texte localement et n'envoient que ce texte (jamais le PDF lui-même) au fournisseur du modèle.
Quels algorithmes PDF Pro utilise-t-il ?
AES-256-GCM pour le chiffrement symétrique (Transfert sécurisé), PBKDF2-SHA256 avec 310 000 itérations pour les clés dérivées d'une phrase secrète, ECDSA sur NIST P-256 pour les signatures numériques et SHA-256 pour le hachage de documents. Tous s'exécutent via l'API Web Crypto native du navigateur, qui est auditée, standardisée et non implémentée par nos soins.
S'agit-il d'une signature électronique juridiquement contraignante ?
Les signatures de PDF Pro sont cryptographiquement vérifiables (ECDSA P-256 sur un hachage SHA-256, profil PAdES-B-B), mais ne sont pas des signatures électroniques qualifiées (SEQ) au sens du règlement eIDAS ou de réglementations équivalentes. Pour une valeur juridique de niveau SEQ, un prestataire de services de confiance certifié est nécessaire.
Que se passe-t-il si j'oublie une phrase secrète ou si je perds un lien de partage ?
Le fichier est définitivement irrécupérable. C'est le compromis du chiffrement de bout en bout — il n'y a pas de procédure de récupération, car nous n'avons jamais détenu la clé. Conservez la phrase secrète dans un gestionnaire de mots de passe et enregistrez le lien dans un endroit durable.
Conservez-vous des journaux côté serveur de l'activité des fichiers ?
Nous conservons des journaux opérationnels (temps des requêtes, codes d'erreur, adresses IP pour la limitation de débit) mais jamais le contenu en clair des fichiers ni les clés de chiffrement. Les journaux sont conservés selon un calendrier court — consultez notre politique de confidentialité pour les durées de rétention actuelles.
Une décision de justice peut-elle vous contraindre à révéler mes fichiers ?
Nous ne pouvons remettre que ce que nous avons : du texte chiffré. Sans la clé de déchiffrement — qui reste sur l'appareil de l'expéditeur ou dans le fragment d'URL détenu par le destinataire — ce texte chiffré n'est pas déchiffrable. Une réquisition judiciaire ne peut pas récupérer rétroactivement une clé que nous n'avons jamais stockée.
Où puis-je vérifier moi-même les affirmations cryptographiques ?
Ouvrez les DevTools de votre navigateur → onglet Réseau et observez ce qui quitte la page pendant un téléversement Transfert sécurisé. Vous verrez du texte chiffré envoyé via PUT au serveur, pas le PDF original. Le code de chiffrement appelle l'API Web Crypto, intégrée à votre navigateur — pas à notre code — et auditable par quiconque.
La confidentialité comme architecture, pas comme argument marketing.
Essayez un Transfert sécurisé et inspectez vous-même l'onglet Réseau. Aucun fichier n'est jamais téléversé en clair.
lockEssayer le Transfert sécurisé