eIDAS Art. 25.1 — recevable devant tout tribunal européen

La preuve opposable
qui manquait à votre signature

ProofIt produit un dossier de preuve cryptographique indépendant de votre prestataire de signature. Il prouve le contexte humain — qui a cliqué, quand, pour quelle société, après combien de temps de lecture — pas juste l'apposition du sceau.

Démarrer en 5 minutes Lire la doc technique

Compatible DocuSign, Yousign, Universign, Adobe Sign · Bundle ASiC-E ETSI EN 319 162

Le problème

Votre eSeal prouve la signature.
Mais qui a vraiment signé ?

Quand un dirigeant signe 15 contrats en bloc et qu'un salarié conteste l'avenant six mois plus tard, l'eSeal de l'entreprise ne dit rien du parcours humain. Pas de preuve d'OTP, de temps de lecture, de consentement, ni d'identité de la personne ayant cliqué.

🏛️

eSeal corporate

DocuSign, Yousign, Adobe Sign. Prouve que l'organisation a apposé son sceau. Ne prouve pas qui.

🪪

eSign personnelle qualifiée

QES, Certinomis, ChamberSign. Prouve l'identité au moment du clic. Ne prouve pas le contexte.

🔐

ProofIt

Prouve la session humaine qui a précédé : OTP validé, actions enregistrées, hashes croisés, ancrages publics Bitcoin + TSP qualifié.

Cas d'usage

Là où ProofIt vous sauve

📋

1. Le parapheur

Un dirigeant signe 15 contrats en bloc en fin de journée. Six mois plus tard, un salarié conteste l'avenant n°7. Sans ProofIt, l'eSeal de l'entreprise ne dit pas qui a cliqué, ni dans quel ordre, ni après quelle lecture.

Manifest : 15 opérations SIGN_CONTRACT, une par PDF, avec le hash de chaque document.

La preuve : OTP du dirigeant, ordre et horodatage des clics, hash du PDF n°7 figé, verdict MATCH, mail récap DKIM.

→ Lire le cas complet (contestation incluse)

📍

2. L'acte de présence

Prouver qu'une personne identifiée a accompli un acte précis à un instant T : émargement d'une AG, prise de poste, constat sur site, accusé de lecture d'une consigne de sécurité. Pas de document à signer — c'est l'acte lui-même qu'il faut attester.

Manifest : une opération PRESENCE dont le payload fige le contexte (événement, lieu, horodatage attendu).

La preuve : OTP = sole control, et l'ancrage Bitcoin fige l'instant T de façon irréfutable, même contre la base interne de l'organisateur.

🧭

3. Le parcours attesté

Un parcours obligatoire qui doit être prouvé étape par étape : onboarding KYC, souscription assurance, recueil de consentement RGPD. L'enjeu n'est pas une signature finale, mais que chaque étape obligatoire ait été franchie, dans l'ordre, sans saut.

Manifest : la séquence prévue — VERIFY_ID → READ_RISK → ACCEPT_TERMS.

La preuve : verdict MATCH = toutes les étapes franchies ; preuve d'inclusion Merkle qu'une étape précise figurait bien au plan consenti.

Et aussi

👥

RH — Avenants en masse

Promotions, NDA, avenants CDI signés via une plateforme RH. Chaque salarié reçoit un mail de récap DKIM avec le hash de sa session — preuve indépendante de la BD employeur.

🏥

Consentement médical

Preuve que le patient a lu le formulaire, identifié, et validé. Hash du formulaire ancré au moment du consentement. Opposable même en cas de modification du protocole interne.

💼

Transfert bancaire validé

Virement > seuil. Trace cryptographique de l'identification, du compte cible, et de la double validation. Plus solide que les logs internes en cas de fraude interne.

🤝

eSeal partagé (parapheur SaaS)

Votre app appose un eSeal qualifié pour le compte de plusieurs clients. ProofIt atteste cryptographiquement le mandat : "X a délégué à Y pour signer Z, à l'instant T".

⚖️

Litige opposable

Dossier de preuve ASiC-E téléchargeable, vérifiable hors-ligne par n'importe quel huissier ou expert judiciaire. Pas besoin d'accès au service ProofIt — la preuve survit même si le service disparaît.

🚫

Refus & abandon tracés

Un utilisateur qui décline ou trois OTP ratés produisent une entrée REFUSED co-signée dans la chaîne. Aussi opposable qu'une signature acceptée : "le bénéficiaire a explicitement décliné à l'instant T".

Comment ça marche

5 étapes, 5 garanties cryptographiques

Fil rouge ci-dessous : un dirigeant signe 15 contrats dans son parapheur.

1

Open

Votre app ouvre une session via le SDK, en y joignant la liste des opérations prévues — le manifest prévisionnel.

Ex. « 15 contrats à signer » : un op_id + le hash de chaque PDF.

2

OTP

Le bénéficiaire valide par code SMS ou application TOTP. C'est la preuve du sole control exigée par eIDAS Art. 26.

Ex. code reçu sur le mobile du dirigeant, saisi en 40 s. Le manifest est alors scellé dans la chaîne.

3

Actions

Chaque acte réel est ajouté à la chaîne, co-signé Ed25519 (organisation + master). Personne, pas même nous, ne peut le réécrire après coup.

Ex. contrat #7 signé à 18 h 42 ; le hash du PDF lu est figé dans l'entrée.

4

Close

À la clôture, on compare le prévu au réalisé et on émet un verdict, puis un mail récapitulatif signé DKIM au bénéficiaire.

Ex. 15 prévus / 15 signés → verdict MATCH. 14 sur 15 → PARTIAL, tracé.

5

Bundle

Un dossier de preuve ASiC-E téléchargeable, vérifiable hors-ligne par n'importe quel tiers — même si ProofIt n'existe plus.

Ex. l'huissier glisse le .asice dans notre vérificateur, sans compte ni connexion.

⛓ Chaîne append-only

Triggers Postgres + rôle SQL réduit. Le service lui-même ne peut pas modifier le passé.

⏱ Ancrage Bitcoin + TSP qualifié

OpenTimestamps (gratuit, irrévocable) + TSP qualifiés eIDAS RFC 3161 en parallèle.

📧 Emails témoins DKIM

Copies indépendantes des hashes dans des boîtes tierces. Constatables par huissier.

Au cœur de la preuve

Le manifest prévisionnel

Avant l'OTP, votre app déclare ce qui est censé se passer. ProofIt le scelle, puis compare au réalisé à la clôture. C'est la différence entre « un sceau a été apposé » et « voici exactement le périmètre qui a été consenti, ni plus ni moins ».

Une liste d'opérations, scellée à l'OTP

Chaque opération prévue porte un identifiant, son type et le hash de son contenu. La liste entière est résumée en une racine Merkle (RFC 9162) inscrite dans la chaîne d'audit au moment de la validation — l'entrée SESSION_PLAN_COMMITTED.

{
  "op_id":        "contrat-7",
  "type":         "SIGN_CONTRACT",
  "payload_hash": "9f86d081…",   # sha256 du PDF
  "metadata":     { "titre": "Avenant CDI" },
  "salt":         "a3f1…"        # feuille Merkle
}

Le payload_hash verrouille le contenu exact ; la metadata reste lisible mais hors hash. Le salt permet une preuve d'inclusion en O(log n) : prouver qu'une opération précise figurait au plan, sans révéler les autres.

Un verdict à la clôture

On recalcule la racine du réalisé et on la confronte au prévu. Le verdict est inscrit dans la preuve :

MATCHtout le prévu a été exécuté, rien de plus.
PARTIALune partie du prévu manque (signature abandonnée à mi-parcours).
DIVERGENTdes actes hors périmètre sont apparus — signal d'alerte fort.
EMPTYaucun manifest fourni : session libre, sans contrôle de périmètre.

En mode strict, un verdict autre que MATCH peut bloquer la clôture côté métier. Sinon, il est simplement attesté — le juge tranche.

Ce qui se déclenche, en asynchrone

L'appel d'ouverture vous rend la main immédiatement. En arrière-plan, ProofIt enchaîne :

À l'ouverture

→ Webhook session.opened (signé HMAC-SHA256, rejouable 5× avec back-off)
→ Envoi de l'OTP (SMS ou TOTP)
→ En mode async : magic-link + URL de callback générés

À la validation OTP

→ Webhooks session.validated, plan_committed, signing_context_attested
→ Emails témoins DKIM dans des boîtes tierces
→ Têtes de chaîne co-signées par VOS soins — la réécriture, même par nous, devient prouvable
→ Email d'ouverture au bénéficiaire (si manifest)

En lot, peu après

→ Les entrées sont regroupées en un arbre Merkle
→ Ancrage parallèle OpenTimestamps (Bitcoin) + TSP qualifié eIDAS
→ Webhook anchor.confirmed dès le premier jeton qualifié

Tous les webhooks sont signés (en-tête X-Signature-SHA256) avec le secret HMAC de votre organisation, horodatés et protégés contre le rejeu — votre serveur vérifie l'authenticité sans nous appeler.

Tarification