Techtok

Documenso : la signature électronique open source, self-host et sans baratin

  • 4 min
Documenso : la signature électronique open source, self-host et sans baratin

Vous en avez marre des outils de signature opaque qui se gavent de données et vous imposent leur cadence ? Documenso arrive avec une promesse simple : la signature électronique que vous pouvez lire, auditer et auto-héberger, sous licence AGPLv3. Le dépôt GitHub affiche une activité soutenue et une dernière release v1.12.1 publiée début juillet 2025. Oui, ça bouge vite — et chez nous, on aime quand ça bouge du bon côté.

Le pitch officiel est clair : construire “l’infrastructure de confiance ouverte” de la signature. Dans la pratique, cela veut dire que vous pouvez déployer Documenso chez vous, garder la main sur les métadonnées et vérifier ce que fait réellement le logiciel. Pas de magie noire, pas de boîte fermée. C’est vous le patron, point.

Côté fonctionnalités, vous retrouvez tout le nécessaire : création / envoi / signature, modèles, workflows, intégrations (Zapier & co), API publique pour automatiser, webhooks, et même embedding pour intégrer l’expérience de signature directement dans vos applis React/Vue/Svelte/Angular. L’embedding gère les templates “lien direct” ou les tokens de signature et propose du white-label (logo, couleurs, domaine) pour une expérience vraiment à votre image.

Sur la conformité eIDAS, mettons les pieds dans le plat. Aujourd’hui, Documenso délivre des signatures SES (niveau 1) et scelle cryptographiquement tous les PDF signés pour prévenir toute altération. Les niveaux AES/QES restent planifiés dans leur feuille de route publique (désormais annoncés pour H1 2026), avec une page “compliance” qui détaille les étapes. Traduction : pour les besoins courants, ça passe ; pour le bancaire/réglementé, gardez un œil sur la roadmap.

Petit bonus “privacy first” : Documenso documente comment générer ou acheter votre certificat de signature (format .p12). Un certificat auto-signé suffit pour de nombreux usages internes, mais les lecteurs PDF grand public n’afficheront pas forcément le petit “tick” vert tant convoité — pour ça, prenez un certificat d’une autorité reconnue par Adobe. C’est transparent, assumé et expliqué noir sur blanc.

Vous voulez l’intégrer en profondeur dans votre stack ? L’API est exposée via un OpenAPI public, et les SDK d’embed existent pour tous les frameworks front modernes. En gros, collez l’expérience de signature dans votre app sans renvoyer les utilisateurs ailleurs.

Pour l’auto-hébergement, on reste sur des briques classiques. La doc “Self-Hosting” et le Quickstart sont propres : Postgres, SMTP, stockage S3-compatible en option, et démarrage via Docker. Rien d’exotique, juste ce qu’il faut pour un déploiement reproductible.

Comme d’habitude sur Techtok, je vous mets le démarrage minimal (à adapter chez vous) :

# Image officielle (Docker Hub ou GHCR)
docker pull ghcr.io/documenso/documenso:latest

# Run minimal (à adapter : secrets, DB, URL publique, SMTP)
docker run -d --name documenso \
  -e NEXTAUTH_SECRET="change-me" \
  -e NEXT_PUBLIC_WEBAPP_URL="https://sign.example.com" \
  -e NEXT_PRIVATE_DATABASE_URL="postgresql://user:pass@db:5432/documenso" \
  -e NEXT_PRIVATE_SMTP_FROM_NAME="SignBot" \
  -e NEXT_PRIVATE_SMTP_FROM_ADDRESS="sign@example.com" \
  -p 3000:3000 \
  ghcr.io/documenso/documenso:latest

Version compose ultra-succincte (certificat local en lecture seule). Lisez la doc “Signing Certificate” avant, c’est important :

services:
  documenso:
    image: ghcr.io/documenso/documenso:latest
    ports: ["3000:3000"]
    environment:
      NEXTAUTH_SECRET: "change-me"
      NEXT_PUBLIC_WEBAPP_URL: "https://sign.example.com"
      NEXT_PRIVATE_DATABASE_URL: "postgresql://user:pass@db:5432/documenso"
      NEXT_PRIVATE_SMTP_FROM_NAME: "SignBot"
      NEXT_PRIVATE_SMTP_FROM_ADDRESS: "sign@example.com"
      NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH: "/certs/signing.p12"
      NEXT_PRIVATE_SIGNING_PASSPHRASE: "change-me"
    volumes:
      - ./certs:/certs:ro

Deux rappels d’ami : 1) pour un “check vert” dans Adobe Reader et des exigences fortes, achetez un certificat auprès d’une autorité reconnue (Adobe Trust List) ; 2) une partie de la communauté signale des frictions lors du montage du .p12 en conteneur : testez en staging, contrôlez les permissions et le passphrase, puis passez en prod.

Pour l’embedding, vous avez des SDK dédiés. Exemple express en React pour intégrer la signature d’un document via token (côté serveur, vous générez le token avec l’API) :

import { EmbedSignDocument } from '@documenso/embed-react';

export default function SignPane() {
  const token = "VOTRE_TOKEN";
  return <EmbedSignDocument token={token} />;
}

La doc couvre aussi les templates “lien direct”, le thème (variables CSS) et le mode sombre. Bref, de quoi livrer une UX clean et brandée, sans bricolage.

Pourquoi je vous recommande Documenso ? Parce que vous ne devriez pas avoir à choisir entre conformité et souveraineté technique. C’est un projet jeune, franc dans sa com’ sur eIDAS, et honnête sur les compromis actuels. Et franchement, vu les abus récurrents des gros SaaS sur la donnée, reprendre la main sur la chaîne de signature, ça fait du bien — et pas qu’au RGPD.

Allez lire la source, testez, et dites-moi si vous basculez vos contrats là-dessus. Commencez par le site, la doc d’auto-hébergement et le repo GitHub (notes de version incluses).