DocuSeal

Remplir et signer un PDF à plusieurs, téléphone compris

DocuSeal est une application Ruby on Rails qui fait remplir et signer des PDF. On place les champs (signature, date, case à cocher, pièce jointe...) sur le document dans un éditeur visuel, puis on l'envoie par e-mail à un ou plusieurs signataires, qui remplissent leur part dans le navigateur, téléphone compris. DocuSeal génère ensuite le PDF rempli, le signe avec un certificat X.509 et garde un journal d'audit : adresse IP, navigateur, heure de chaque étape.

Documenso vise le même usage avec une pile TypeScript, OpenSign avec Node.js et MongoDB. @signpdf ne fait que la dernière étape, poser la signature dans le PDF depuis Node.js, et laisse l'interface et l'envoi à l'application qui l'intègre.

Le comparatif des outils de signature électronique open source confronte la signature que DocuSeal appose sur le PDF à celle des autres outils.

Un conteneur suffit, détection des champs en local

• Un conteneur pour démarrer : docker run suffit. Sans DATABASE_URL, les données vont dans SQLite ; sans REDIS_URL, le serveur Puma lance son propre Redis et fait tourner Sidekiq dans son processus. Le docker-compose.yml du dépôt ajoute PostgreSQL 18 et Caddy pour le HTTPS.
• Détection des champs en local : un modèle de vision par ordinateur, livré dans l'image Docker, repère les zones à remplir d'un PDF. Il demande au moins 1 Go de RAM, selon les notes de la 2.2.0.
• Éditeur de pages : depuis la 3.1.0, on ajoute, retire, pivote ou recadre des pages, et on caviarde des passages.
• API REST et webhooks dans l'édition libre : l'API liste, clone et modifie les modèles, crée des demandes de signature et suit chaque signataire. Un serveur MCP, arrivé avec la 2.3.7, laisse un agent IA créer un modèle depuis l'URL d'un PDF ou d'un DOCX, puis l'envoyer.
• Certificat et horodatage au choix : on importe son propre certificat (.p12, .pfx), on désigne un serveur d'horodatage RFC 3161, et la page des réglages vérifie la signature de n'importe quel PDF déposé.
• Interface en français : sept langues d'interface, dont le français, et quatorze pour la page de signature.

Certificat auto-signé et AGPL avec clause d'attribution

Le certificat par défaut est auto-signé. Au premier lancement, une instance auto-hébergée fabrique sa propre chaîne de certificats, valable cent ans, baptisée « DocuSeal Self-Host Autogenerated ». Cette autorité est créée sur le serveur même : aucun lecteur PDF ne la connaît d'avance. La page de documentation sur les certificats ne qualifie de « trusted by Adobe » que le certificat de DocuSeal Cloud. Sur son propre serveur, il reste à importer un certificat, ou à prendre Pro pour la « DocuSeal Trusted Signature » : l'instance envoie l'empreinte du PDF à DocuSeal, qui la signe, et d'après l'écran des réglages le document ne quitte pas le serveur.

Ce que réserve l'édition Pro. Logo et marque blanche, rôles utilisateurs, relances automatiques, vérification d'identité par SMS, champs conditionnels et formules, envoi en masse depuis un fichier CSV ou XLSX, SSO et SAML, création de modèles par API depuis du HTML, un PDF ou un DOCX, formulaires intégrables en React, Vue, Angular ou JavaScript. L'API REST de l'édition libre n'a aucune route pour créer un modèle depuis un fichier : les modèles se préparent dans l'interface. À défaut de SMS, un signataire peut recevoir un code à usage unique par e-mail. Sur site, Pro coûte 20 $ par utilisateur et par mois, facturés 240 $ à l'année, plus 0,20 $ par document signé via l'API ou l'intégration.

AGPL-3.0, avec une clause d'attribution. Le dépôt ajoute à l'AGPLv3 un terme prévu par sa section 7(b) : toute copie, modifiée ou non, garde l'attribution DocuSeal d'origine dans ses interfaces. La marque blanche, elle, figure dans la liste Pro. Exposer une version modifiée en service réseau oblige en outre à en proposer le code source à ses utilisateurs.

Le dimensionnement est chiffré. La documentation compte 1 vCPU et 1 Go de RAM pour des documents de 500 Ko, 2 vCPU et 4 Go pour des fichiers de 100 Mo. Sous 1 000 documents par an, SQLite, MySQL et PostgreSQL conviennent ; au-delà, et pour l'API ou l'intégration en production, elle recommande PostgreSQL.

Une version par semaine, deux auteurs principaux. Le dépôt compte 173 versions depuis juillet 2023, dont 40 en 2026, presque toutes publiées un lundi ; la 3.3.1 date du 5 octobre 2026. Deux comptes signent 3 146 des 3 154 commits de la branche principale. Les notes de la 3.3.0, qui annoncent un durcissement de la sécurité, recommandent à toutes les instances auto-hébergées de se mettre à jour, et le docker-compose.yml du dépôt tire l'image latest.