@signpdf

Paquets npm pour signer un PDF par certificat

@signpdf est une famille de paquets npm qui insère une signature numérique par certificat dans un PDF, depuis Node.js. Un helper réserve d'abord dans le document un champ de signature rempli de zéros. @signpdf/signpdf calcule ensuite la plage d'octets à signer, la confie à un signer et écrit le résultat à la place des zéros. Le seul signer publié, @signpdf/signer-p12, produit une signature PKCS#7 détachée avec node-forge à partir d'un certificat P12. Le README revendique un but pédagogique : montrer ce flux « dans un morceau de code lisible », sous licence MIT.

@signpdf signe le fichier qu'on lui passe, sans plus. Envoyer le document à quelqu'un et recueillir son accord relève d'une application comme Documenso ou DocuSeal. Le comparatif des outils de signature électronique open source met en regard ce que chacun appose dans le PDF et ce que cela vaut juridiquement.

Helpers par origine du PDF et signer remplaçable

• Un helper par origine du PDF : placeholder-pdfkit et placeholder-pdfkit010 interviennent pendant la génération avec PDFKit, placeholder-pdf-lib sur un document chargé avec PDF-LIB, placeholder-plain sur un fichier déjà écrit. Un PDF qui porte déjà son champ de signature se signe sans helper.
• Un signer remplaçable : @signpdf/signpdf accepte toute classe qui étend Signer et implémente sign().
• PAdES par une option : subFilter: SUBFILTER_ETSI_CADES_DETACHED remplace la valeur Adobe par défaut, ce que le README donne pour condition d'une signature conforme PAdES.
• Plusieurs signatures par fichier : l'exemple multiple-signatures.js fait signer un contrat par l'acheteur puis par le vendeur, chacun avec son P12.
• Une taille de signature prévisible : en mode détaché, elle dépend du certificat et non du document. On la mesure une fois pour régler signatureLength, et sign() lève une erreur explicite si la place manque.

Pas de recueil du consentement ni d'horodatage par une autorité

Aucune prise en charge du signataire. @signpdf ne fournit ni interface, ni envoi, ni recueil du consentement. La signature est celle du détenteur du P12 : deux signataires, deux certificats. Le signer ne vérifie ni l'émetteur ni l'expiration du certificat, et ce que vaut la signature dépend de qui l'a délivré.

Pas d'horodatage par une autorité. L'heure inscrite dans la signature est l'attribut signingTime, pris sur l'horloge de la machine. Aucun paquet ne demande de jeton à une autorité d'horodatage (TSA) ni n'ajoute les réponses OCSP d'une validation à long terme (LTV). La demande d'horodatage ouverte en 2021 (#124) a été close faute d'activité. Sur LTV (#186), Daniel Hensby, qui fusionne les contributions, rapporte un essai qu'Acrobat ne validait pas.

La clé privée doit être exportable. @signpdf/signer-p12 signe en mémoire avec la clé contenue dans le fichier P12. Une clé enfermée dans un HSM ou un coffre cloud (Azure Key Vault, Google Cloud KMS) oblige à écrire son propre Signer, qui doit renvoyer une structure CMS complète et non la signature brute. Deux tickets sur le sujet (#270, #272) restent ouverts depuis septembre 2024.

La signature est invisible par défaut. Les quatre helpers posent un champ de taille nulle (widgetRect à [0, 0, 0, 0]). Pour l'afficher, il faut fournir le rectangle et dessiner le cadre, comme le fait l'exemple pdfkit010-with-visual.js avec PDFKit. placeholder-plain, le helper le plus utilisé d'après le README, procède par recherche de chaînes : il est fragile, ne gère pas les streams et s'arrête au PDF 1.3.

Aucune version publiée en 2026. La 3.3.0 date du 29 décembre 2025. La branche develop n'a reçu depuis que des mises à jour de dépendances et un correctif, et ses engines exigent Node 22, contre Node 12 pour la version publiée. Valery Buchinsky, propriétaire du dépôt, signe 361 commits, le contributeur suivant (hors robot) 14. L'ancien paquet node-signpdf, figé en 3.0.0 depuis octobre 2023 et marqué déprécié, a encore été téléchargé 34 014 fois la semaine du 28 septembre 2026, contre 308 893 pour @signpdf/signpdf.