Signature électronique open source : quel outil choisir

Pour faire signer des PDF sans DocuSign, depuis son propre serveur, trois applications libres couvrent tout le parcours : envoi du document par e-mail, signature dans le navigateur, journal d'audit et PDF final scellé par un certificat. Documenso exige PostgreSQL et un certificat fourni par l'administrateur, quand DocuSeal démarre dans un seul conteneur et fabrique son propre certificat auto-signé. OpenSign tourne sur MongoDB, et sa configuration par défaut contient un certificat expiré dont la clé privée est publique. @signpdf est une bibliothèque Node.js sous MIT : elle pose la signature dans le PDF et laisse l'interface et l'envoi à l'application qui l'intègre. Dans les trois applications, le certificat par défaut est celui du serveur et non celui de chaque signataire. Documenso et DocuSeal font payer la signature qualifiée au sens d'eIDAS, et OpenSign ne documente aucune voie vers elle.

Application complète ou bibliothèque à intégrer

Documenso, DocuSeal et OpenSign suivent le même parcours. On dépose un PDF, on place les champs dans un éditeur visuel, puis chaque destinataire reçoit par e-mail un lien pour remplir et signer sa part dans le navigateur. Quand tous ont signé, l'instance produit le PDF final, le signe avec son certificat et garde un journal d'audit de chaque étape, avec l'heure et l'adresse IP. Documenso peut imposer un ordre de signature et un code d'accès. DocuSeal peut envoyer au signataire un code à usage unique par e-mail, et réserve la vérification par SMS à son édition Pro. OpenSign peut exiger un code par e-mail et imposer un ordre strict, et accepte un DOCX, qu'il convertit en PDF avec LibreOffice.

Documenso et DocuSeal exposent une API REST et des webhooks. Celle de Documenso, en v2, est décrite en OpenAPI. Celle de l'édition libre de DocuSeal crée des demandes de signature à partir d'un modèle et suit chaque signataire, mais n'a aucune route pour créer un modèle depuis un fichier : les modèles se préparent dans l'interface, et leur création par API fait partie de l'édition Pro. Chez OpenSign, l'API et les webhooks sont ceux du cloud : un jeton ou un webhook « Live » exige la formule Professional ou Teams, et le code public ne contient ni cette API ni l'envoi de webhooks.

@signpdf travaille un niveau plus bas, et c'est elle qu'OpenSign emploie pour signer. Un helper réserve un champ de signature dans le PDF, puis @signpdf/signpdf y écrit la signature calculée par un signer ; le seul publié, @signpdf/signer-p12, signe avec un certificat P12. La bibliothèque n'a ni interface, ni envoi, ni recueil du consentement, et la signature reste invisible tant que l'application ne dessine pas son cadre. La signature est celle du détenteur du P12 : faire signer deux personnes demande deux certificats.

Ce que chaque outil appose dans le PDF

Le format d'une signature PDF se lit dans son sous-filtre. Documenso écrit par défaut ETSI.CAdES.detached, celui des signatures PAdES, et garde adbe.pkcs7.detached en option pour les lecteurs anciens. DocuSeal signe avec la bibliothèque Ruby HexaPDF sans toucher à son type de signature par défaut, une signature CMS en adbe.pkcs7.detached. @signpdf pose aussi adbe.pkcs7.detached par défaut, et son option subFilter passe à ETSI.CAdES.detached, que son README donne pour condition d'une signature conforme PAdES. OpenSign garde ce réglage par défaut. Dans les quatre cas, la signature couvre les octets du fichier : une retouche après coup la casse.

Le certificat identifie celui qui signe. Chez Documenso, c'est celui de l'instance, appliqué par la plateforme et non par chaque signataire, et aucun n'est livré : sans fichier .p12 protégé par mot de passe, l'application démarre mais toute signature échoue. Documenso accepte aussi une clé gardée dans Google Cloud HSM. DocuSeal fabrique au premier lancement sa propre chaîne de certificats, « DocuSeal Self-Host Autogenerated », valable cent ans. On peut la remplacer par un certificat importé (.p12, .pfx) ou, en Pro, par la « DocuSeal Trusted Signature » : l'instance envoie alors l'empreinte du PDF à DocuSeal, qui la signe. OpenSign lit le sien dans la variable PFX_BASE64. Le fichier .env.local_dev, que la commande d'installation du README copie en .env.prod, en contient déjà un : auto-signé au nom d'OpenSign Labs, expiré depuis le 16 novembre 2024, avec sa phrase de passe, opensign. Sa clé privée est donc à la portée de quiconque lit le dépôt. @signpdf prend le P12 qu'on lui donne sans en vérifier l'émetteur ni l'expiration, et la clé doit être exportable : une clé gardée dans un HSM ou un coffre cloud oblige à écrire son propre Signer.

Un certificat auto-signé prouve que le fichier n'a pas changé, mais Acrobat affiche un avertissement. Selon la documentation de Documenso, la coche verte d'Adobe exige un certificat émis par une autorité de l'Adobe Approved Trust List, et celle d'OpenSign renvoie aussi à un certificat acheté auprès de l'une d'elles. DocuSeal réserve la mention « trusted by Adobe » au certificat de son offre cloud : celui qu'une instance auto-hébergée génère n'est connu d'aucun lecteur PDF.

L'horodatage par une autorité (TSA) est en option dans Documenso et DocuSeal. Documenso, une fois l'autorité déclarée, ajoute aussi à la signature les données de validation à long terme (LTV) et un horodatage d'archivage. DocuSeal accepte un serveur d'horodatage RFC 3161, mais dans son code, la méthode prévue pour la LTV (maybe_enable_ltv) rend le fichier sans le modifier. OpenSign n'appelle aucune autorité dans son code public : l'heure qu'il inscrit vient de l'horloge du serveur. @signpdf ne demande aucun jeton d'horodatage : l'heure inscrite est l'attribut signingTime, pris sur l'horloge de la machine, et la demande d'horodatage ouverte en 2021 a été close faute d'activité.

Signature simple, avancée ou qualifiée : ce que dit eIDAS

Le règlement européen eIDAS distingue trois niveaux. Une signature électronique, même simple, ne peut se voir refuser d'effet juridique ni être écartée comme preuve en justice au seul motif qu'elle est électronique ou qu'elle n'est pas qualifiée (article 25). La signature avancée doit en plus être liée au signataire de manière univoque et permettre de l'identifier, être créée avec des données qu'il garde sous son contrôle, et être liée au document de sorte que toute modification ultérieure soit détectable (article 26). La signature qualifiée est une signature avancée créée avec un dispositif qualifié et fondée sur un certificat qualifié ; son effet juridique équivaut à celui d'une signature manuscrite. La FAQ eSignature de la Commission européenne reprend ces définitions.

Avec leurs réglages par défaut, Documenso, DocuSeal et OpenSign signent avec la clé du serveur. Le document est scellé et toute retouche se voit, mais l'identité du signataire repose sur l'accès à sa boîte e-mail, renforcé au besoin par un code. La documentation de Documenso classe ce résultat en signature électronique simple au sens d'eIDAS. DocuSeal n'indique pas, dans sa documentation ni dans ses pages sur la sécurité, le niveau eIDAS de sa signature par défaut. OpenSign se dit conforme à l'ESIGN Act, à UETA et au règlement eIDAS, sans préciser de niveau.

Pour les niveaux avancé et qualifié, Documenso et DocuSeal font signer chaque personne par un prestataire de confiance ou avec son propre certificat. Documenso le fait depuis sa v2.13.0 (18 juin 2026) par son mode csc : la signature passe par un prestataire compatible avec l'API du Cloud Signature Consortium, chez qui chaque destinataire s'authentifie. Ce mode exige la licence Enterprise et une autorité d'horodatage, n'accepte qu'un prestataire par instance et impose une signature dans l'ordre ; la page « Signature Levels » de la documentation donne pourtant encore AES et QES pour « prévues ». DocuSeal facture sa signature qualifiée à l'unité : 0,20 dollar avec un lecteur de carte d'identité ou un certificat local du signataire, 2 dollars par un prestataire de confiance, sans dire quelle formule y donne accès. OpenSign ne documente aucune voie vers ces deux niveaux. Avec @signpdf, ce que vaut la signature dépend du certificat remis à chaque signataire et de l'autorité qui l'a délivré.

Ce que chaque outil demande pour tourner

Relevé dans les dépôts et les documentations le 7 octobre 2026.

Documenso n'accepte que PostgreSQL, qui garde par défaut les documents et la file de tâches ; S3 et Redis sont optionnels. Sa documentation compte 1 Go de RAM pour un essai et 2 Go ou plus en production. DocuSeal se contente d'un conteneur : sans base déclarée, il écrit dans SQLite, et sans Redis, son serveur Puma lance le sien et fait tourner Sidekiq dans son processus. Sa documentation recommande PostgreSQL au-delà de 1 000 documents par an ou pour l'API en production, et chiffre la mémoire selon la taille des fichiers, jusqu'à 2 vCPU et 4 Go pour des PDF de 100 Mo. OpenSign démarre en quatre conteneurs, MongoDB, le serveur Node.js, le client React et Caddy, et sa documentation ne chiffre pas la mémoire. Sa base tourne sans authentification, et la documentation demande de ne pas exposer son port. D'après le fichier de configuration du dépôt, le serveur ne s'initialise pas sans Mailgun ou SMTP. @signpdf n'a rien à héberger, mais sa branche de développement exige Node 22, quand la version publiée accepte Node 12.

Où en sont les projets

DocuSeal publie presque chaque semaine, le plus souvent un lundi : 173 versions depuis juillet 2023, dont 40 en 2026. Deux comptes signent 3 146 des 3 154 commits de sa branche principale, et les notes de la 3.3.0, qui annoncent un durcissement de la sécurité, demandent à toutes les instances auto-hébergées de se mettre à jour. Documenso a publié seize versions mineures en 2026, de la v2.4.0 en janvier à la v2.19.0 du 29 septembre. Depuis juin 2026, il ne fusionne plus les pull requests externes, sauf celles d'un petit groupe de contributeurs qu'il sollicite.

OpenSign a publié 83 versions depuis novembre 2023, dont 11 en 2026. La 2.41.3 date du 21 août 2026, et rien n'a été poussé sur le dépôt depuis. Ses fusions récentes viennent de branches sync-to-public_repo du compte nxglabs, et les notes de la 2.39.0 renvoient au dépôt nxglabs/OpenSign-Enterprise, qui n'est pas public. Les notes de version décrivent aussi cette édition : le code d'accès par destinataire annoncé dans la 2.41.0 est absent du code public.

@signpdf n'a rien publié en 2026 : sa 3.3.0 date du 29 décembre 2025, et la branche develop n'a reçu depuis que des mises à jour de dépendances et un correctif. Valery Buchinsky, propriétaire du dépôt, signe 361 commits, le contributeur humain suivant 14. La bibliothèque reste beaucoup téléchargée : 308 893 fois pour @signpdf/signpdf la semaine du 28 septembre 2026, et encore 34 014 fois pour l'ancien paquet node-signpdf, déprécié et figé depuis octobre 2023.

Licences et offres payantes

Documenso, DocuSeal et OpenSign sont sous AGPL-3.0, @signpdf sous MIT, sans offre payante ni cloud.

Chez Documenso, le dossier packages/ee/ relève d'une licence commerciale, utilisable en production avec un abonnement Enterprise seulement. Il contient la signature avancée et qualifiée par prestataire, le SSO d'organisation (SAML, OIDC), la réauthentification par passkey ou 2FA avant une action sur un document, la conformité 21 CFR Part 11, les domaines d'envoi des e-mails et l'éditeur intégrable. Son prix n'est pas public. La documentation précise qu'un usage interne sans modification, ou l'appel de l'API depuis une application fermée, reste dans l'édition communautaire gratuite. Le cloud va d'une formule gratuite limitée à 5 documents par mois à 250 dollars par mois pour la marque blanche, et l'offre Enterprise est sur devis.

DocuSeal ajoute à l'AGPL un terme prévu par sa section 7(b) : toute copie garde l'attribution DocuSeal d'origine dans ses interfaces, et la marque blanche fait partie de l'édition Pro. Sur site, Pro coûte 20 dollars par utilisateur et par mois, facturés 240 dollars à l'année, plus 0,20 dollar par document signé via l'API ou l'intégration. L'édition Pro réserve aussi les rôles, les relances automatiques, la vérification par SMS, les champs conditionnels, l'envoi en masse depuis un fichier CSV ou XLSX, le SSO et SAML, la création de modèles par API et les formulaires intégrables en React, Vue, Angular ou JavaScript.

Le fichier LICENSE d'OpenSign excepte de l'AGPL le dossier cloud/customRoute de son serveur (conversion DOCX, déchiffrement des PDF protégés, suppression de compte), soumis à « la licence définie » dans ce dossier, qui n'en contient aucune. Son cloud gratuit n'a pas de limite de signatures. Les formules Professional et Teams ouvrent l'API et les webhooks, et chaque document créé par l'API y consomme des crédits ; le sous-domaine personnalisé est réservé à l'offre Enterprise. L'instance auto-hébergée gère plusieurs utilisateurs, ce que le cloud réserve aux formules Teams et Enterprise.