Les meilleures alternatives à DocuSign : gratuites et auto-hébergées

Vous devez remplacer un processus contractuel, mais la solution retenue ne peut pas envoyer les contrats à un service de signature SaaS. DocuSeal, Documenso et OpenSign méritent de figurer dans votre sélection d’alternatives à DocuSign. Chacun possède un socle auto-hébergeable ; la comparaison utile porte sur l’édition que vous pouvez exploiter, les preuves que vous pouvez exporter et les services que le déploiement continue d’appeler. L’autorisation de louer un serveur et celle d’envoyer des documents à un sous-traitant sont deux décisions distinctes.

Conserver un processus DocuSign déjà approuvé peut rester raisonnable tant que les preuves ou l’exploitation de la solution de remplacement sont incomplètes, à condition que ce processus respecte les exigences de votre organisation. Si votre politique interdit son mode de traitement, le fait de bien le connaître ne lève pas cette restriction. Définissez les critères d’acceptation de la solution de remplacement avant d’y transférer de vrais contrats.

En bref

• DocuSeal : Son édition auto-hébergée gratuite prend en charge plusieurs signataires et votre propre serveur SMTP. Pro ajoute notamment les rappels automatiques, le SSO SAML, les rôles et équipes, ainsi que des fonctions avancées d’API et d’intégration embarquée. Consultez le comparatif des éditions sur site.
• Documenso : Community Edition comprend les fonctions de signature essentielles, les modèles et l’accès à l’API. Les fonctions commerciales incluent le portail d’authentification de l’organisation, la réauthentification lors des actions sur les documents et l’édition embarquée. Consultez le comparatif des éditions.
• OpenSign : Son dépôt documente les modèles réutilisables, l’ordre de signature, les codes envoyés par e-mail aux invités et les certificats d’achèvement. Sa documentation des jetons API distingue les jetons de production payants des jetons de test gratuits. Confirmez les droits d’accès à l’API de la version auto-hébergée choisie ; cette page ne les établit pas clairement.

Comparer les éditions gratuites et leurs exigences d’exploitation

Le tableau ci-dessous compare le périmètre du code gratuit, les exigences de déploiement et les fonctions commerciales de chaque outil.

Une application de signature électronique open source peut proposer un socle gratuit utilisable et des modules commerciaux. Traitez chaque processus envisagé comme une vérification des droits : identifiez l’action, l’édition qui l’autorise et le service qu’elle appelle. Un dépôt public ne prouve pas qu’une fonction nécessaire est gratuite.

Tenez une fiche de sélection succincte : package choisi, processus requis, condition non résolue et personne chargée d’obtenir une réponse. Ne remplissez pas un champ sans réponse par « oui » parce qu’une fonction cloud porte un nom similaire. Une exigence non résolue doit retarder l’adoption du processus concerné, même si le reste de l’application semble convenir.

Choisir un candidat adapté à votre processus de signature

Je commencerais par DocuSeal pour un processus de modèles PDF géré manuellement, par Documenso Community si l’accès gratuit à l’API est indispensable, et par OpenSign si ses modèles et ses codes invités par e-mail correspondent au processus. Ce sont des pistes de départ pour un pilote, fondées sur la documentation officielle ; je n’ai effectué aucun test d’installation ou de signature.

DocuSeal pour un processus fondé sur les PDF et les modèles

DocuSeal constitue un premier pilote pertinent pour préparer des PDF et réutiliser des modèles de signature lorsque son socle gratuit couvre le processus. Sa FAQ sur le certificat d’audit décrit un relevé d’achèvement téléchargeable avec les événements de chaque partie et des champs de vérification conditionnels. Évaluez la méthode enregistrée au regard de votre exigence avant de considérer le certificat comme la preuve d’un niveau d’identification particulier.

Le certificat enregistre les adresses e-mail des parties, les heures des événements, l’adresse IP, l’identifiant de session, les informations du navigateur et le fuseau horaire. La vérification par e-mail ou téléphone dépend de la méthode utilisée ; la présence d’un champ ne prouve pas qu’une méthode plus forte a été exécutée. Demandez un exemple produit par la configuration envisagée, y compris une demande refusée ou déléguée si ces parcours sont pertinents.

Arrêtez la sélection si une authentification ou une intégration nécessaire dépend d’une offre commerciale que vous n’avez pas approuvée. L’éditeur de documents peut satisfaire le besoin visible alors qu’une action essentielle en aval reste non résolue.

Documenso dans un environnement d’exploitation PostgreSQL existant

Documenso mérite un pilote si vous pouvez exploiter ensemble sa base de données, son service de messagerie et ses certificats. Ses prérequis d’auto-hébergement signalent un piège précis : l’application peut démarrer sans certificat de signature alors que toute signature de document échoue. Une interface qui répond ne peut donc pas servir de test d’acceptation pour ce déploiement.

Les prérequis décrivent une signature numérique X.509 utilisant un certificat .p12 fourni ou généré, et le stockage des journaux d’audit dans la base de données. Cela décrit l’infrastructure de signature ; cela n’établit ni le justificatif d’identité utilisé par un destinataire ni le contenu d’un export donné.

Le cycle de vie des documents de Documenso décrit un PDF signé achevé auquel est joint un journal d’audit. Son journal des modifications v2.14.0 documente aussi le téléchargement séparé, par API, du certificat et du journal d’audit au format PDF. Pendant le pilote, exportez ces éléments depuis la version installée, examinez leur contenu et validez le PDF signé indépendamment.

OpenSign pour les modèles et l’ordre de signature

OpenSign est un candidat lorsque les modèles réutilisables et l’ordre de participation sont des exigences centrales. Le README du projet documente plusieurs signataires, les séquences de signature et les codes invités par e-mail. Testez ces parcours avec le backend complet et votre configuration de stockage ; un code par e-mail atteste l’accès à une boîte de réception, pas une identité personnelle ou une autorité dans l’organisation vérifiées indépendamment.

Ses instructions d’installation pour le développement précisent que le parcours limité au frontend utilise le backend de test du projet, y compris pour les téléversements de documents. Excluez ce parcours d’un déploiement de contrats privés. Exécuter un frontend sur votre machine n’établit pas où son backend traite les documents.

Examiner les preuves derrière une signature achevée

Un PDF finalisé et un rapport d’événements répondent à des questions différentes. Recueillez les preuves des actions de signature, de l’intégrité du document, de l’identité et de l’autorité du signataire, ainsi que du moment de la signature. La FAQ eSignature de la Commission européenne et la loi ESIGN distinguent la reconnaissance de la signature électronique des exigences plus larges. Aucun export ni champ technique ne détermine à lui seul l’issue juridique d’un contrat donné.

Pour les transactions américaines relevant du commerce interétatique ou international ou l’affectant, ESIGN §7001 limite le refus d’effet juridique fondé uniquement sur la forme électronique d’une signature ou d’un enregistrement. Cette loi sur les signatures électroniques préserve les autres obligations et n’impose pas à chacun d’accepter les enregistrements électroniques. Des conditions de communication aux consommateurs s’appliquent dans certaines circonstances. Les exceptions de la section 7003 comprennent des documents testamentaires ou de droit de la famille, certaines matières du code de commerce, des documents judiciaires et certaines notifications ; ces exclusions n’interdisent pas en elles-mêmes l’usage électronique.

La FAQ eSignature de la Commission distingue la signature électronique de sa mise en œuvre numérique et cryptographique. Selon le règlement européen eIDAS, la forme électronique ou non qualifiée ne peut à elle seule justifier le refus d’effet juridique d’une signature. Les signatures qualifiées ont un effet équivalent à celui des signatures manuscrites. Les signatures avancées exigent un lien avec l’identité, le contrôle du signataire et la détection des modifications ; les signatures qualifiées ajoutent un certificat qualifié et un dispositif de création qualifié. Ces règles ne tranchent pas la formation du contrat, l’autorité, les formalités documentaires ou un litige individuel, et ne classent pas un outil donné.

Effectuez quatre contrôles lorsque vous examinez un exemple de dossier de preuves :

1. Événements et contrôle. Une piste d’audit de signature électronique doit permettre d’examiner qui a agi, ce que cette personne a vu ou accepté, quelle vérification a été effectuée et quand le processus s’est terminé. Consignez les preuves de consentement pertinentes pour ce processus. Identifiez qui peut modifier ou supprimer des événements, si ces modifications sont enregistrées et ce qui protège la copie conservée indépendamment de l’administrateur de l’application. Un journal d’événements seul ne prouve pas sa résistance à l’altération.
2. Intégrité du document. Conservez le PDF finalisé original et validez toute signature numérique, sa chaîne de certificats et les octets qu’elle couvre. La définition d’une fonction de hachage du NIST décrit une représentation condensée des données d’entrée. Un contrôle par hachage capable de révéler une altération nécessite une référence authentifiée : une empreinte dont vous pouvez établir l’origine et la protection. Remplacer à la fois un PDF et son empreinte adjacente déjoue une simple comparaison. Une empreinte seule n’établit pas l’identité du signataire. Demandez si le relevé d’audit distinct est également protégé.
3. Identité et autorité. Consignez la méthode de vérification et son lien avec la personne désignée. L’accès à une boîte e-mail ou un code à usage unique n’établit pas à lui seul l’identité de cette personne ni son autorisation d’engager une entreprise. La définition d’une signature numérique du NIST associe l’authentification de l’origine et l’intégrité à une mise en œuvre correcte. Le certificat de signature d’un serveur ne doit pas devenir implicitement une affirmation selon laquelle chaque destinataire détenait un justificatif individuel.
4. Heure et émetteur. Distinguez une date d’événement de l’application d’un jeton d’horodatage émis indépendamment. RFC 3161 définit un protocole d’horodatage utilisant une empreinte de message, c’est-à-dire une empreinte des données horodatées. Vérifiez le jeton par rapport au document conservé et examinez son émetteur. Le statut d’horodatage qualifié constitue une distinction supplémentaire : la Commission décrit des présomptions d’exactitude de la date et de l’heure et d’intégrité des données associées, les services qualifiés figurant dans les listes de confiance. La prise en charge de RFC ne suffit pas à établir ce statut ni à garantir une issue pour le document.

Cartographier la destination des documents, métadonnées et empreintes

Une application de signature électronique auto-hébergée peut néanmoins envoyer des PDF finalisés par un relais externe, comme l’illustrent les paramètres des e-mails d’achèvement de DocuSeal. L’auto-hébergement indique qui exploite l’application ; chaque service configuré nécessite son propre examen. Distinguez le contenu contractuel, les métadonnées personnelles et les empreintes, puis consignez le point de terminaison et les traitements autorisés pour chaque parcours avant d’introduire de vrais documents dans le système.

Si la restriction interdit un SaaS de signature mais autorise une infrastructure louée approuvée, le matériel de l’entreprise et un VPS ou cloud privé approuvé restent possibles. Un VPS loué est une infrastructure tierce. Une interdiction littérale de toute infrastructure tierce ne peut pas être satisfaite en en achetant une ; utilisez une infrastructure contrôlée par l’entreprise et examinez chaque service de soutien au regard de cette limite.

Notre VPS DocuSeal en un clic est livré avec DocuSeal préinstallé : vous pouvez ainsi éviter l’installation manuelle de l’application et vous concentrer sur la configuration de votre processus de signature. Choisissez parmi nos emplacements VPS mondiaux en fonction de vos besoins de localisation des données.

Un service de confiance explicitement approuvé peut rester utile lorsque le traitement des documents par SaaS est interdit. Évaluez sa charge utile et sa finalité au regard de la politique, au lieu de supposer qu’une application que vous administrez fournit automatiquement des preuves plus solides.

Appliquez le même inventaire des appels externes que pour les autres applications métier : suivez chaque connexion au-delà de l’interface utilisateur. Examinez les points de terminaison configurés et les charges utiles avec des fichiers synthétiques. Une connexion locale réussie ne prouve rien sur les parcours sortants non examinés.

Budgéter l’édition et le travail qui reste à votre charge

Un déploiement sans frais de licence nécessite tout de même du stockage, l’envoi des e-mails et une personne responsable de la récupération. Le guide Pro de DocuSeal et le comparatif des éditions de Documenso distinguent les droits logiciels de la propriété de l’infrastructure. Budgétez le processus exact, y compris les actions payantes et les services de soutien, puis attribuez les responsabilités d’exploitation. La mention « illimité » pour les documents ou les utilisateurs ne fournit ni une capacité serveur illimitée ni une exploitation gratuite.

Budgétez le calcul, le stockage de la base et des documents, les sauvegardes, l’envoi des e-mails, les certificats ou services de confiance, les licences commerciales, les frais d’utilisation et le temps d’administration.

Estimez les besoins selon la taille de vos documents, la durée de conservation et les pics de signature. Évitez de comparer un abonnement SaaS au seul coût de calcul de son remplaçant ; ils couvrent des tâches différentes. Si une condition commerciale ou un service requis reste inconnu, le budget est incomplet même si la licence de l’application est gratuite.

Un processus approuvé de périmètre réduit constitue un point de départ raisonnable. Reportez l’automatisation facultative jusqu’à ce que ses droits, son parcours de données et son responsable soient clairement définis.

Effectuer un pilote avec des données synthétiques avant de transférer les contrats

Utilisez un accord fictif et des destinataires de test pour évaluer l’édition choisie avant de transférer les contrats. Les prérequis de Documenso et le guide Docker d’OpenSign identifient les dépendances ; votre pilote doit tester ensemble la signature, l’export des preuves et la récupération. Il s’agit d’un plan d’acceptation, pas d’un compte rendu de tests effectués. Consignez les échecs et les questions sans réponse avec la configuration évaluée.

1. Fixez la version ou l’image et consignez l’édition, la licence et la version installée. Définissez les actions requises et les preuves acceptables avant l’installation. Conservez ces éléments avec la configuration du déploiement afin de pouvoir répéter les mêmes contrôles après une mise à jour.
2. Approuvez les points de terminaison et les destinations de stockage. Incluez les parcours externes dans la fiche, puis examinez les e-mails synthétiques d’invitation et d’achèvement, leurs pièces jointes et les charges utiles observées. Vérifiez que le parcours OpenSign choisi inclut votre backend, le cas échéant.
3. Effectuez une invitation représentative avec des destinataires de test externes. Testez la méthode de vérification requise, l’ordre de signature, le refus ou l’expiration, et l’achèvement. Confirmez l’accessibilité pour les destinataires hors du réseau de l’entreprise et examinez les échecs de livraison.
4. Exportez le PDF finalisé et le relevé d’audit dans la forme requise. Validez les signatures, les certificats et tout jeton d’horodatage indépendamment de l’écran de réussite de l’application. Comparez l’intégrité à la référence authentifiée conservée ; modifiez une copie distincte et vérifiez ce que la validation détecte. Il s’agit d’un contrôle technique, pas d’un test de résultat juridique.
5. Redémarrez le déploiement et confirmez que les enregistrements restent accessibles. Restaurez dans un environnement isolé et répétez la récupération et la validation. Donnez aux cibles de sauvegarde et responsabilités de récupération des critères d’acceptation explicites ; un rapport de sauvegarde réussi ne suffit pas.
6. Prévoyez une transition contrôlée. Conservez les PDF finalisés et leurs preuves originales séparément des nouveaux modèles. Décidez comment les demandes ouvertes se termineront. Ne considérez pas l’importation d’un PDF dans une nouvelle application comme une reconstitution de son historique de signature original.

Notre déploiement DocuSeal en un clic facilite la configuration initiale de l’application lorsqu’une infrastructure louée approuvée convient à l’accès des destinataires ; l’installation manuelle sur le matériel de l’entreprise ou chez tout fournisseur approuvé reste possible. Choisissez parmi nos emplacements VPS mondiaux en fonction de vos besoins de localisation des données.

Questions fréquemment posées

Les unités de facturation, les licences des packages et les versions installées doivent être consignées séparément, même après le choix du processus.

Les destinataires signataires sont-ils facturés comme utilisateurs de la plateforme ?

Non. L’explication de la facturation de Pro de DocuSeal distingue les utilisateurs de la plateforme des destinataires signataires. L’unité d’utilisation de son API et de son intégration embarquée est une soumission achevée, qui peut contenir plusieurs fichiers et plusieurs parties. Consignez à la fois les droits des utilisateurs de la plateforme et les frais d’utilisation applicables ; n’appliquez pas ce modèle de facturation à un autre projet.

Une seule licence couvre-t-elle tous les composants du dépôt ?

Examinez les fichiers et packages choisis. Documenso possède une licence distincte pour le répertoire commercial ; les exceptions de la licence racine d’OpenSign excluent un répertoire de routes serveur précis lorsqu’il est présent. Pour une version personnalisée, consignez les composants inclus et leurs licences avant de supposer que la licence principale du dépôt décrit chaque composant.

Une version publiée en amont identifie-t-elle ma version installée ?

Non. Une version publiée en amont identifie le logiciel amont, tandis qu’une installation possède sa propre version déployée et sa propre édition. Consignez la version exposée par l’application en cours d’exécution ou ses métadonnées de déploiement avant le pilote. Ne déduisez pas cette correspondance d’une annonce de version et répétez les contrôles d’acceptation lorsque la version installée change.