Un indicateur de permission PDF n'est pas une serrure. C'est une requête que le fichier adresse à ce qui l'ouvre, et une visionneuse est libre de l'ignorer. Ce seul fait décide de la façon dont il faut raisonner sur tous les autres choix de cette page. La vraie confidentialité vient d'un seul endroit : le chiffrement AES-256 dérivé d'un mot de passe que le lecteur n'a pas. Tout le reste, les cases "pas d'impression" et "pas de copie", relève d'une politique que les logiciels conformes acceptent d'honorer et que les logiciels hostiles n'honorent pas. Mélangez ces deux couches et vous livrez quelque chose qui paraît sûr en démonstration et qui fuit sur le terrain
HotPDF est un composant PDF VCL natif pour Delphi et C++Builder, et il expose le modèle de protection ISO 32000 par un petit jeu de propriétés. Les propriétés sont faciles à poser. Le difficile est de savoir laquelle vous achète une protection cryptographique et laquelle vous achète une suggestion polie, puis de poser les affectations dans le bon ordre pour que le chiffrement demandé soit réellement celui obtenu
Ce que les deux mots de passe promettent vraiment
Le chiffrement PDF définit deux informations d'identification aux rôles différents, et les confondre est l'erreur de conception la plus courante dans le code de sortie protégée. Le mot de passe utilisateur commande le déchiffrement. Sans lui, ou sans le mot de passe propriétaire, un lecteur conforme ne peut pas reconstruire la clé du fichier et le contenu reste cryptographiquement illisible. Le mot de passe propriétaire commande au contraire les réglages de permission : un lecteur qui reçoit le mot de passe propriétaire obtient un accès complet quoi que disent les indicateurs de restriction
Les bits de permission reposent sur un terrain plus faible. Impression, extraction de contenu, remplissage de formulaire : chacun est un indicateur qu'une visionneuse lit et choisit de respecter (ISO 32000-2 §7.6.4). Le chiffrement protège les octets. Les indicateurs de permission ne font qu'instruire les logiciels conformes, et ils les instruisent après coup. Quiconque ouvre le document avec le mot de passe utilisateur tient déjà le contenu déchiffré en mémoire, si bien que "pas de copie" et "pas d'impression" veulent dire quelque chose pour une visionneuse bien élevée et rien pour une visionneuse déterminée. Construisez le modèle de menace autour de cette ligne. La confidentialité vit dans le mot de passe utilisateur. Les permissions façonnent ce que les visionneuses grand public proposent, et c'est tout ce qu'elles font
Ordre de configuration : tout avant BeginDoc
HotPDF construit le dictionnaire de chiffrement et dérive la clé du fichier au moment où BeginDoc s'exécute. Ce que contiennent les propriétés de protection à cet instant est ce que le document reçoit, et les changer ensuite ne change rien. La propriété qui compte le plus ici est CryptKeyLength, qui choisit le schéma parmi les valeurs THPDFKeyType k40, k128, aes128 et aes256. Affectez-la après BeginDoc et vous n'obtenez ni exception ni avertissement, juste un fichier qui a discrètement gardé ce avec quoi il avait démarré. Cette sorte de divergence silencieuse est la pire : elle passe tous les tests locaux et ressurgit des mois plus tard en constat de conformité sur le bureau d'un client
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'statement.pdf';
Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256; // doit être posé avant BeginDoc
Pdf.UserPassword := 'open-secret';
Pdf.OwnerPassword := 'admin-secret';
Pdf.UseAES256R6 := False; // R=5 : compatibilité maximale des visionneuses
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 720, 0, 'Account statement, June 2026');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Les mots de passe sont en UTF-8 et plafonnés à 127 octets, ce qui est la limite ISO 32000-2 pour les schémas AES-256. Si votre politique de mots de passe vous remet des secrets plus longs, faites la troncature vous-même, de votre côté, là où vous maîtrisez exactement l'endroit de la coupe. Laissez faire le hasard et la bibliothèque et telle visionneuse future pourront diverger sur la limite, ce qui produit un fichier qui s'ouvre chez vous et refuse le même mot de passe ailleurs
Révision 5 ou révision 6 : un booléen, deux écosystèmes
UseAES256R6 choisit entre les deux poignées de main AES-256, et le choix porte plus à conséquence que ne le laisse croire son type booléen. Laissez-le à False et HotPDF écrit la révision 5, le schéma AES-256 arrivé en extension de PDF 1.7 et que quelque chose comme quinze ans de visionneuses savent ouvrir. Mettez-le à True et vous obtenez la révision 6, la dérivation de clé durcie normalisée dans l'ISO 32000-2 pour PDF 2.0, qui referme une faiblesse connue dans la façon dont la révision 5 vérifie le mot de passe
La révision 6 est donc la meilleure histoire du point de vue cryptographique. C'est aussi celle qui casse des choses. Un fichier en révision 6 réclame une visionneuse conçue pour PDF 1.7 Extension Level 3 ou PDF 2.0, et bien des logiciels déployés ne sont ni l'un ni l'autre : archives de gestion documentaire, moteurs de rendu embarqués dans d'autres produits, outils métier que personne n'a touchés depuis des années. Ceux-là refuseront le fichier tout net, et le feront sur la machine du client, jamais sur la vôtre. Le défaut pratique est donc la révision 5. Ne recourez à la révision 6 que lorsqu'une politique de sécurité nomme l'ISO 32000-2 par révision, et lorsque vous avez réellement confirmé que tous les consommateurs savent la lire. Dans les deux cas, notez laquelle vous avez choisie et pourquoi, car la prochaine personne à toucher ce code se posera la question
Les anciens types de clés méritent une phrase pour que vous sachiez les éviter. THPDFKeyType liste encore k40, k128 et aes128, mais ils existent pour reproduire des archives historiques, pas pour protéger les nouvelles. Le RC4 40 bits tombe devant du matériel grand public, et les schémas 128 bits sont antérieurs aux révisions AES-256 que toute revue de sécurité actuelle attendra. Pour un document que vous créez en 2026, la vraie question est seulement révision 5 contre révision 6 ; si vous vous surprenez à saisir les types hérités dans une conception neuve, quelque chose a mal tourné en amont
Des indicateurs de permission sans mot de passe à l'ouverture
L'exigence est souvent l'inverse du secret. Tout le monde doit pouvoir lire le document, mais l'impression ou l'extraction doit être limitée. Cela s'exprime par un mot de passe utilisateur vide et un mot de passe propriétaire non vide, ce que le PDF appelle le mode mot de passe à l'ouverture, et vous listez les opérations que vous voulez autoriser dans ProtectOptions
Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := ''; // tout le monde peut ouvrir le fichier
Pdf.OwnerPassword := 'rotate-me-quarterly'; // garde le jeu de permissions
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... contenu de page ...
Pdf.EndDoc;L'ensemble THPDFProtectOptions correspond aux bits de permission ISO : prPrint et prPrint12bit pour l'impression haute résolution, prInformationCopy pour la copie et l'extraction générales, prExtractContent pour l'extraction par technologies d'assistance, plus prModifyStructure, prEditAnnotations, prFillAnnotations et prAssemble. Deux d'entre eux méritent un avertissement. Laissez prExtractContent actif dans presque tous les profils que vous construisez. C'est le bit dont un lecteur d'écran a besoin pour atteindre le texte, et l'effacer convertit discrètement une décision de droits en un défaut d'accessibilité qu'une personne en situation de handicap rencontre et que vous ne voyez jamais. L'autre piège est prPrint tout seul, sans prPrint12bit : plusieurs visionneuses répondent en dégradant la qualité d'impression, et vos utilisateurs signaleront cela comme un bug de rendu plutôt que comme le réglage de permission que c'est réellement
La vérification prend cinq minutes et a sa place dans votre liste de contrôle de livraison. Ouvrez un échantillon de chaque profil dans Acrobat, ouvrez les propriétés du document et lisez l'onglet Sécurité, qui énonce l'algorithme ("AES 256 bits") et liste une à une les opérations autorisées. Ouvrez ensuite le même fichier dans la plus ancienne visionneuse que vos clients utilisent réellement, pas la plus récente de votre machine. Cette seconde ouverture est l'assurance bon marché contre un fichier en révision 6 qui traverse le développement sans encombre et meurt chez un client qui n'a jamais mis à jour
Retirer la protection de fichiers existants
Le déchiffrement fait tourner le même modèle de propriétés à l'envers. Chargez le document avec une information d'identification valide, désactivez la protection et enregistrez le résultat sans elle
var
Pdf: THotPDF;
PageCount: Integer;
begin
Pdf := THotPDF.Create(nil);
try
PageCount := Pdf.LoadFromFile('encrypted.pdf', 'open-secret');
if PageCount > 0 then
begin
Pdf.ActivateProtection := False; // abandonner le chiffrement à l'enregistrement
Pdf.SaveLoadedDocument('plain.pdf');
end;
finally
Pdf.Free;
end;
end;Cette voie analyse tout le document en mémoire, ce qui convient aux fichiers ordinaires et gaspille sur les énormes. Quand l'entrée atteint des centaines de mégaoctets, DecryptFile est l'option la moins chère : il déchiffre pendant une copie au niveau du fichier, en empruntant un chemin de réécriture AES-256 direct qui évite de construire l'arbre d'objets complet chaque fois que l'entrée le permet. Il fait partie de la Direct File API traitée dans l'article compagnon sur le traitement des gros PDF depuis Delphi
Des contraintes qui interagissent avec le chiffrement
Deux limites méritent d'être connues avant de concevoir autour du chiffrement plutôt qu'après. La première est la conformité archivistique. L'ISO 19005 interdit le chiffrement en PDF/A, si bien que tout flux qui chiffre un document et revendique aussi la conformité PDF/A est contradictoire par construction ; HotPDF ne vous laissera pas avoir les deux dans un même fichier. Quand vous avez vraiment besoin des deux, la réponse est deux artefacts : une copie chiffrée pour la diffusion et une copie non chiffrée distincte pour l'archive
La seconde limite est plus brutale. Le chiffrement PDF n'a ni séquestre ni récupération. Perdez le mot de passe utilisateur d'un fichier R5 ou R6 et vos options sont la force brute ou l'abandon. Traitez donc les secrets propriétaire et utilisateur comme n'importe quelle information d'identification de production. Générez-les, rangez-les dans un coffre, faites-les tourner selon un calendrier. La seule chose à ne jamais faire est de les coder en dur comme constantes dans une unité, où ils filent tout droit dans le contrôle de version et restent pour toujours dans la copie de travail de chaque développeur
Un dernier réflexe à cultiver. Changer la protection d'un fichier que vous n'avez pas créé relève de la même machinerie que le déchiffrement, ce n'est pas une fonctionnalité distincte : chargez-le avec son mot de passe par LoadFromFile, modifiez ProtectOptions ou les mots de passe sur place, et réécrivez-le avec SaveLoadedDocument. Si vous savez déchiffrer un fichier, vous savez lui redonner des permissions, et le code ressemble presque trait pour trait à l'exemple ci-dessus
Les propriétés de protection présentées ici font partie du composant HotPDF pour Delphi standard, pour Delphi et C++Builder ; la page produit porte la référence complète du chiffrement, énumération complète des permissions comprise