Une vue d'ensemble neutre, sources citées, des outils de signature de code et de documents disponibles pour les développeurs Delphi et C++ Builder en 2026 : sgcSign, Microsoft SignTool, osslsigncode, Azure Trusted Signing, DigiCert Software Trust Manager, jsign, Adobe Acrobat et les SDK PDF iText / Apryse. Chaque affirmation de fonctionnalité renvoie à la documentation officielle du projet.
Un résumé d'un paragraphe pour chaque option, avec un lien vers la documentation officielle ou le dépôt. La comparaison détaillée se trouve dans la matrice ci-dessous.
eSeGeCe · Commerciale
Suite commerciale de signature numérique pour Delphi / C++ Builder / .NET. Livrée sous deux formats complémentaires qui partagent le même cœur de signature. La bibliothèque de composants produit des signatures XAdES, PAdES, CAdES et ASiC en cours de processus de Delphi 7 jusqu'à Delphi 13. sgcSign Server ajoute un daemon REST de signature auto-hébergé qui signe l'Authenticode (binaires PE), les manifestes ClickOnce, les paquets NuGet, les bundles VSIX et les scripts PowerShell par-dessus les formats de document. Dix fournisseurs de clés couvrent PFX/PEM locaux, le magasin de certificats Windows, les tokens matériels PKCS#11, AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault, Certum SimplySign et tout QTSP distant CSC v2. Vingt et un profils par pays pré-configurés pilotent la facturation électronique européenne et la signature de contrats de travail eIDAS.
Microsoft · EULA Windows SDK (gratuit pour le développement)
Outil en ligne de commande de signature de code de Microsoft livré avec le SDK Windows 10 / Windows 11. Signe et horodate les fichiers Windows Portable Executable (.exe, .dll, .sys, .cab, .cat) ainsi que les paquets AppX/MSIX, les manifestes ClickOnce et les projets Microsoft Office Visual Basic for Applications via le mécanisme SIP (Subject Interface Package). Lit les certificats depuis le magasin de certificats Windows, les fichiers PKCS#12, les cartes à puce et les fournisseurs Cloud Signing Service (CSP). La signature PDF, XML et ETSI XAdES / PAdES / CAdES ne fait pas partie du périmètre de SignTool.
Michał Trojnara et contributeurs · GPL-3.0-or-later (open source)
Outil de signature Authenticode open-source multiplateforme construit sur OpenSSL. Signe les binaires Microsoft PE (.exe, .dll, .sys, .cab, .cat), les archives CAB, les paquets AppX/MSIX, les paquets NuGet et les fichiers de script. Fonctionne sur Linux, BSD et macOS en plus de Windows, ce qui est la raison historique du projet — il permet aux build farms Linux de signer des binaires Windows sans exécuter SignTool sous Wine. Horodatage RFC 3161 et Authenticode hérité ; les sources de certificats incluent les fichiers PKCS#12 et les tokens matériels PKCS#11.
Microsoft · Commerciale (abonnement Azure, mensuel)
Service de signature de code entièrement géré de Microsoft sur Azure (anciennement Azure Code Signing). Les clients ne possèdent pas le certificat de signature — Microsoft émet un certificat à durée de vie courte tous les trois jours et stocke la clé privée dans un HSM Azure. Des intégrations sont fournies pour SignTool, GitHub Actions, Azure Pipelines, Trusted Signing PowerShell et un dlib dédié (Trusted Signing CSP) qui expose les clés à tout outil compatible CSP. Signe Windows PE, MSIX, AppX, ClickOnce, scripts VBScript / JScript / PowerShell ; la signature PDF / XML n'est pas dans le périmètre.
DigiCert · Commerciale (abonnement)
Plateforme cloud de signature de code de DigiCert. Les clés privées résident dans un HSM FIPS 140-2 / 140-3 hébergé par DigiCert. Signe Windows PE, Java JAR, Android APK, Linux RPM / DEB, images de conteneur, NuGet, binaires Apple Mach-O et plus encore à travers une flotte d'outils dédiés : le client de signature smctl, le plug-in DigiCert KSP / CSP pour SignTool, les intégrations natives Jenkins / GitHub Actions / Azure Pipelines et une API REST. Les documents (PDF, XAdES) sont signés via le produit séparé DigiCert Document Trust Manager.
Emmanuel Bourg · Apache 2.0 (open source)
Outil de signature Authenticode open-source basé sur Java. Fonctionne comme commande autonome, plug-in Maven / Gradle / Ant ou API Java programmatique. Signe les binaires Microsoft PE, les installateurs MSI, les fichiers de script Microsoft (.ps1, .vbs, .js), les paquets MSIX / AppX, les archives CAB et les catalogues CAT. Prend en charge une large liste de HSM cloud via une seule CLI : AWS KMS, Azure Key Vault, Azure Trusted Signing, Google Cloud KMS, DigiCert ONE, HashiCorp Vault, Oracle Cloud KMS, Yubico YubiHSM, AWS CloudHSM (via PKCS#11) et tout appareil PKCS#11.
Adobe · Commerciale (abonnement)
Adobe Acrobat Pro et Adobe Acrobat Sign sont des produits destinés à l'utilisateur final pour la signature de documents PDF. Acrobat Pro applique des signatures numériques et des signatures certifiées avec horodatage et valide les signatures PDF entrantes ; Acrobat Sign (anciennement EchoSign) est un service cloud pour collecter des signatures électroniques auprès de parties externes. Aucun n'est une bibliothèque pour développeurs : il n'y a pas de SDK Delphi / C++ Builder ni d'outil de signature en ligne de commande dans la boîte. La validation à long terme PAdES est prise en charge côté validation via l'Adobe Approved Trust List (AATL) et l'European Union Trusted List (EUTL).
iText Group / Apryse Software (PDFTron) · Commerciale (licence AGPL ou commerciale)
Deux SDK PDF commerciaux largement utilisés pour la signature PDF non assistée dans les applications côté serveur. iText Core (anciennement iTextSharp) est disponible pour Java et .NET sous AGPL-3.0 ou licence commerciale ; le namespace com.itextpdf.signatures couvre PAdES-B-B / B-T / B-LT / B-LTA, les certifications MDP (détection de modification) et les apparences visibles. Apryse PDFTron est un SDK commercial multiplateforme (Java, .NET, C++, Node.js, Python, Go, iOS, Android, web) avec une API PDF.SignatureHandler et la prise en charge de PAdES. Aucun des deux fournisseurs ne livre de liaison Delphi native.
Une coche () signifie que le projet documente la prise en charge native. Un tiret (—) signifie que le projet ne le fournit pas nativement. Un tilde (~) signifie partiel / via extension / non explicitement documenté — consulte la section Sources pour ce que nous avons pu vérifier.
| Fonctionnalité | sgcSign | Microsoft SignTool | osslsigncode | Azure Trusted Signing | DigiCert Software Trust Manager | jsign | Adobe Acrobat / Adobe Sign | iText / Apryse |
|---|---|---|---|---|---|---|---|---|
| Signer les binaires Windows Authenticode pour .exe / .dll / .sys / .ocx | — | — | ||||||
| Signer les manifestes ClickOnce Fichiers .application / .manifest | ~ | ~ | — | — | ||||
| Signer les paquets NuGet / VSIX Conteneurs .nupkg / .vsix | ~ | ~ | ~ | ~ | — | — | ||
| Signer les paquets mobiles (APK / IPA) Bundles Android APK ou iOS IPA | — | — | — | — | — | — | — | |
| Signer les documents PDF (PAdES) ETSI EN 319 142, compatible Adobe | — | — | — | ~ | — | |||
| Signer les documents Office Word / Excel / PowerPoint docx / xlsx / pptx | — | ~ | — | — | — | — | — | — |
| Signer les documents XML (XAdES) ETSI EN 319 132 | — | — | — | ~ | — | — | ~ | |
| API Delphi / C++ Builder native Composants VCL / FMX de premier ordre | — | — | — | — | — | — | — | |
| Outils multiplateformes Fonctionne sur Windows, Linux et macOS | ~ | — | ~ | |||||
| Prise en charge HSM cloud AWS / Azure / GCP / HashiCorp / CSC v2 | ~ | ~ | ~ | ~ | ||||
| Préréglages eIDAS / profils par pays Préréglages de signature par pays (VeriFactu, KSeF, etc.) | — | — | — | ~ | — | ~ | ~ | |
| CLI autonome Client en ligne de commande inclus | ~ | — | — | |||||
| Bibliothèque / SDK API programmatique appelable par une application | — | — | ~ | ~ | ~ | — | ||
| Maintenance active Version ou activité taguée dans les 12 à 18 derniers mois | ||||||||
| Modèle de licence Type de licence | Commerciale | EULA Windows SDK | GPL-3.0-or-later | Commerciale (abonnement Azure) | Commerciale (abonnement) | Apache 2.0 | Commerciale (abonnement) | AGPL ou Commerciale (iText) / Commerciale (Apryse) |
Chaque option ici a un public réel. Le bon choix dépend de si tu signes du code, des documents ou les deux, du runtime qui héberge la logique de signature, de ta préférence en matière de conservation des clés et de ta préférence de licence.
Choisis sgcSign quand tu construis l'application en Delphi 7–13, C++ Builder ou .NET et que tu veux une seule suite de composants qui produit à la fois des signatures de document (XAdES, PAdES, CAdES, ASiC) et des signatures de code (Authenticode, ClickOnce, NuGet, VSIX, PowerShell) à partir de la même abstraction de fournisseur de clés. Les 21 profils par pays pré-configurés couvrent la facturation électronique européenne et la signature de contrats de travail eIDAS ; le format serveur centralise la conservation des clés pour les build farms.
Choisis Microsoft SignTool quand les artefacts que tu signes sont tous des binaires Windows (PE / .cab / AppX / MSIX) et que l'hôte de build est Windows. SignTool est l'interface en ligne de commande de référence qui s'associe à chaque service de signature cloud livré avec un CSP / KSP (DigiCert KeyLocker, Azure Trusted Signing, GlobalSign Atlas, etc.), et l'installation du SDK Windows est gratuite.
Choisis osslsigncode quand ton hôte de build fonctionne sous Linux, BSD ou macOS et que les artefacts à signer sont des binaires Windows — archives CAB, fichiers PE, paquets MSIX ou paquets NuGet. La licence GPL-3.0 s'intègre naturellement dans les pipelines CI qui utilisent déjà OpenSSL et les tokens matériels PKCS#11.
Choisis Azure Trusted Signing quand tu veux un service de signature de code Windows entièrement géré où Microsoft possède le certificat et le HSM, quand ton équipe opère déjà sur Azure et quand les artefacts à signer sont Windows PE, MSIX, AppX, ClickOnce ou PowerShell. Le modèle de certificat à courte durée de vie supprime la charge de renouvellement et de vérification d'identité liée à la possession d'un certificat Code Signing.
Choisis DigiCert Software Trust Manager quand tu achètes déjà le certificat de signature de code DigiCert et que tu veux qu'il soit stocké dans leur HSM validé FIPS avec un panneau central pour les renouvellements, les révocations et l'audit. Le client smctl natif et le plug-in SignTool KSP couvrent les binaires Windows, les Java JAR, les images de conteneur et les paquets mobiles depuis un seul workflow.
Choisis jsign quand le pipeline de build fonctionne déjà sur une chaîne d'outils JVM (Maven, Gradle, Ant ou Jenkins sur JDK), quand tu veux une seule CLI qui pilote chaque HSM cloud grand public et quand les artefacts à signer sont des fichiers Windows PE / MSI / MSIX / script. La licence Apache 2.0 s'intègre proprement dans les flux de build à code fermé.
Choisis Adobe Acrobat / Adobe Sign quand le workflow de signature est interactif et piloté par l'humain — une personne ouvre un PDF dans Acrobat, place une signature visible et envoie le fichier. Acrobat Sign étend ce schéma aux flux de signature multipartites collectés par e-mail. Aucune automatisation au moment du build ou côté serveur n'est requise.
Choisis iText ou Apryse PDFTron quand l'application est construite sur Java, .NET, C++ ou l'un des autres runtimes pris en charge et que PDF est le format de document dominant. Les deux SDK ont un support PAdES mature, une forte couverture de fonctionnalités PDF en dehors de la signature (formulaires, biffage, rendu) et des références entreprise bien connues.
Notes brèves sur les différences si tu passes de l'une des options ci-dessus. Sans antagonisme — juste la correspondance pratique.
SignTool couvre uniquement la signature de code Windows. Si ton application appelle déjà SignTool depuis un script de build, sgcSign Server expose un point de terminaison REST de signature qui prend un binaire et un nom de fournisseur et renvoie l'artefact signé — le même workflow, mais l'opération Authenticode s'exécute de manière centralisée et la piste d'audit, le workflow d'approbation et les quotas par projet qui en résultent résident à un seul endroit. La signature de document (XAdES / PAdES / CAdES / ASiC) est alors disponible depuis le même daemon.
Si ton pipeline de build utilise osslsigncode pour signer Authenticode des binaires Windows depuis des agents de build Linux, sgcSign Server te donne le même flux via une API HTTPS et ajoute des pilotes de premier ordre pour AWS KMS, Azure Trusted Signing, Google Cloud KMS et HashiCorp Vault par-dessus le chemin PKCS#11 que tu utilises peut-être déjà. Les formats de document (PDF / XML / CMS) sont alors disponibles depuis le même point de terminaison.
sgcSign expose Azure Trusted Signing comme l'un de ses dix fournisseurs de clés (TsgcAzureTrustedSigningProvider), donc une application Delphi ou C++ Builder peut piloter Azure Trusted Signing directement — la même clé privée, le même certificat de confiance publique émis par Microsoft, mais le signataire s'exécute en cours de processus. Si tu as aussi besoin de signature de document PDF / XAdES / CAdES, le même fournisseur de clés sert les signataires de document.
Si tu signes aujourd'hui des binaires Windows avec smctl, sgcSign Server peut piloter le même certificat de signature de code via le fournisseur PKCS#11 que DigiCert expose, et ajoute par-dessus la signature de document XAdES / PAdES / CAdES de premier ordre — utile quand une application a besoin de signatures de code et de document depuis un seul daemon.
jsign couvre la signature de code Windows à travers une large gamme de HSM cloud. sgcSign Server se chevauche sur la matrice HSM cloud (AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault) et ajoute la signature de document ETSI (PAdES, XAdES, CAdES, ASiC) plus les 21 profils par pays — utile quand la même clé doit produire à la fois des signatures de code et de document.
Adobe Acrobat est un outil pour l'utilisateur final, pas une bibliothèque pour développeurs. Si tu demandes actuellement aux utilisateurs finaux de signer des PDF dans Acrobat et que tu veux maintenant des signatures PAdES non assistées côté serveur, sgcSign fournit le signataire PDF (TsgcPAdESSigner) plus les clients d'horodatage et OCSP pour produire des signatures PAdES-T et PAdES-LT depuis un pipeline de build ou un service backend.
iText et Apryse ne fournissent pas de liaison Delphi native, donc les applications Delphi enveloppent généralement leur SDK .NET ou Java derrière un pont fin. sgcSign produit des signatures PAdES-B-B / B-T / B-LT depuis du code Delphi et C++ Builder natif — la couche pont disparaît, et la même chaîne de fournisseurs de clés qui signe les PDF signe également les artefacts XML, CMS et Authenticode.
Chaque cellule de la matrice ci-dessus renvoie à l'une de ces pages de documentation officielles, dépôts ou notes de version. Toutes les URL ont été vérifiées en HEAD au moment de la rédaction.