Nouveauté dans Firma.dev : la preuve que votre signataire a saisi le code à usage unique, sur chaque certificat

L'API Firma.dev v1.40.3 est sortie le 20 octobre 2026, et elle modifie les traces laissées par le code à usage unique envoyé par e-mail. Lorsqu'une demande de signature requiert ce code, le moment où le signataire le saisit correctement est désormais consigné dans la piste d'audit, avec l'heure et l'adresse IP, et imprimé sur le certificat d'achèvement.

Nouveau : la vérification du code est désormais consignée

Firma.dev enregistre désormais la saisie du code à deux endroits. La piste d'audit s'enrichit d'un nouvel événement otp_verified, consigné lorsque le signataire saisit le code correct. Le certificat d'achèvement affiche, pour chaque signataire, son mode d'authentification et l'heure à laquelle le code a été vérifié. Ces deux éléments s'appliquent aux demandes de signature complétées à partir du 20 octobre. Les certificats émis avant cette date restent strictement identiques.

Ce qu'affiche le certificat d'achèvement

Chaque ligne de signataire sur le certificat comporte désormais une ligne Authentification, libellée de deux manières possibles :

• Lien par e-mail, pour un signataire ayant signé sans code à usage unique

• Lien par e-mail + code à usage unique (code vérifié le <heure>), pour un signataire ayant saisi le code

La ligne Identité située vers le haut récapitule l'ensemble de la demande. Si tous les signataires se sont authentifiés de la même manière, elle affiche cette méthode. Si elles diffèrent, elle indique « Mixte (voir les signataires) », vous invitant à consulter les lignes individuelles.

Voici un aperçu simplifié de la ligne d'un signataire ayant utilisé le code :

Signataire :      Alice Johnson (alice@example.com)
Consulté :        2026-10-21 09:14:11
Authentification: Lien par e-mail + code à usage unique (code vérifié 2026-10-21 09:14:03)

Signataire :      Alice Johnson (alice@example.com)
Consulté :        2026-10-21 09:14:11
Authentification: Lien par e-mail + code à usage unique (code vérifié 2026-10-21 09:14:03)

Signataire :      Alice Johnson (alice@example.com)
Consulté :        2026-10-21 09:14:11
Authentification: Lien par e-mail + code à usage unique (code vérifié 2026-10-21 09:14:03)

Dans cet aperçu, l'heure du code précède l'heure de consultation (« Viewed »), ce qui est tout à fait normal. Le signataire saisit le code avant le chargement du document, la vérification intervient donc avant la première consultation (cela paraîtrait curieux sur papier si l'on n'en connaissait pas la raison).

Ce qu'enregistre la piste d'audit

Le nouvel événement est otp_verified, décrit comme « A saisi le code à usage unique envoyé par e-mail ». Comme chaque événement lié à un signataire, il comporte un horodatage, le nom et l'adresse e-mail du signataire en tant qu'auteur de l'action, ainsi que son adresse IP. Ouvrez n'importe quelle demande de signature dans le tableau de bord et cliquez sur l'onglet Piste d'audit pour le visualiser dans la chronologie, aux côtés des consultations, des saisies de champs et des signatures.

Le code en lui-même n'est jamais inclus. L'événement fait référence à l'enregistrement du code vérifié par son identifiant, reliant ainsi la saisie à un code précis sans jamais exposer le code à quiconque le consulte.

Lorsque le signataire termine, l'événement document_finished reprend cette même référence tant que la session finale était associée à un code vérifié. Cela relie la saisie du code à la signature finalisée, au sein de la même piste d'audit...

Pour en savoir plus sur ce que doit contenir une piste complète, consultez notre guide explicatif sur la piste d'audit de signature électronique et la page dédiée aux fonctionnalités de la piste d'audit.

Pourquoi cela compte en cas de vérification ultérieure

Imaginez un contrat signé il y a six mois... le signataire prétend aujourd'hui ne l'avoir jamais vu, ou un auditeur examinant vos documents fournisseurs souhaite savoir comment vous avez vérifié l'identité du signataire. Ces deux questions portent sur le même document.

Grâce au code à usage unique activé, le certificat y répond sur une seule page. Il atteste que le signataire a prouvé son accès à son adresse e-mail en saisissant le code, et précise à quel moment il l'a fait. La piste d'audit y ajoute l'adresse IP depuis laquelle le code a été saisi. Vous pouvez transmettre le certificat tel quel, sans que personne n'ait à fouiller dans les tableaux de bord ou de vieux fils d'e-mails pour reconstituer la chronologie...

Firma.dev est conforme à l'ESIGN Act, à l'UETA, à eIDAS (SES et AES) ainsi qu'à l'eIDAS britannique, et les signatures générées sont juridiquement contraignantes dans plus de 55 pays. La preuve par code à usage unique couvre le côté signataire du dossier. Si vous souhaitez également faire figurer votre entreprise sur le document final, les cachets d'organisation le permettent, et les deux fonctionnalités se complètent parfaitement.

Activer le code à usage unique

Vous pouvez exiger le code pour l'ensemble d'un espace de travail dans ses paramètres (un propriétaire doit effectuer cette modification), ou par demande via l'API avec settings.require_otp_verification :

{
  "settings": {
    "require_otp_verification": true
  }
}

{
  "settings": {
    "require_otp_verification": true
  }
}

{
  "settings": {
    "require_otp_verification": true
  }
}

La vérification s'effectue uniquement par e-mail. Les signataires reçoivent le code dans leur boîte de réception et le saisissent avant que le document ne s'ouvre. Pour en savoir plus sur le parcours du signataire, consultez la page dédiée à la fonctionnalité OTP par e-mail.

Le code n'engendre aucun frais supplémentaire. Vous payez 0,049 € par enveloppe (~0,05 $ USD), à l'usage, sans minimum mensuel ni frais par utilisateur. Retrouvez tous les détails sur la page des tarifs.

Pour les développeurs : récupérer les preuves depuis l'API

GET /signing-requests/{id}/audit renvoie la liste complète des événements sous results. Filtrez sur event égal à otp_verified, puis lisez timestamp, ip_address et details.otp_code_id. Un événement se présente ainsi :

{
  "id": "a1b2c3d4-0000-0000-0000-000000000007",
  "timestamp": "2026-10-21T09:14:03.000Z",
  "source": "signer",
  "event": "otp_verified",
  "description": "A saisi le code à usage unique envoyé par e-mail",
  "actor": { "name": "Alice Johnson", "email": "alice@example.com" },
  "ip_address": "203.0.113.42",
  "details": {
    "channel": "email",
    "otp_code_id": "5f0c9e2a-0000-0000-0000-000000000001"
  }
}

{
  "id": "a1b2c3d4-0000-0000-0000-000000000007",
  "timestamp": "2026-10-21T09:14:03.000Z",
  "source": "signer",
  "event": "otp_verified",
  "description": "A saisi le code à usage unique envoyé par e-mail",
  "actor": { "name": "Alice Johnson", "email": "alice@example.com" },
  "ip_address": "203.0.113.42",
  "details": {
    "channel": "email",
    "otp_code_id": "5f0c9e2a-0000-0000-0000-000000000001"
  }
}

{
  "id": "a1b2c3d4-0000-0000-0000-000000000007",
  "timestamp": "2026-10-21T09:14:03.000Z",
  "source": "signer",
  "event": "otp_verified",
  "description": "A saisi le code à usage unique envoyé par e-mail",
  "actor": { "name": "Alice Johnson", "email": "alice@example.com" },
  "ip_address": "203.0.113.42",
  "details": {
    "channel": "email",
    "otp_code_id": "5f0c9e2a-0000-0000-0000-000000000001"
  }
}

Les événements document_finished contiennent également details.otp_code_id lorsque la session finale a été associée à un code vérifié, ce qui vous permet de faire correspondre la finalisation à la saisie du code. Ces événements s'appliquent aux demandes de moins de 1 000 lignes de suivi. Les demandes plus volumineuses conservent la troncature actuelle.

Les réponses verify-signing-otp ont également gagné en précision dans cette version :

• 404 SIGNING_USER_NOT_FOUND pour un signataire inconnu

• 404 SIGNING_REQUEST_NOT_FOUND lorsque la demande a été supprimée

• 400 INVALID_INPUT pour un signingUserId mal formé

• 200 avec code: "SIGNING_STATE_CHANGED" et un state lorsque la demande ne peut plus être signée (annulée, refusée, expirée, déjà signée, etc.)

• 500 INTERNAL en cas d'erreur de base de données

Un code correct qui rencontre une erreur temporaire ne consomme plus l'une des tentatives du signataire. Il n'y a aucun changement de schéma OpenAPI, et event reste une chaîne de texte libre.

Les descriptions administrateur ont également changé. Une annulation depuis le tableau de bord indique désormais « Signing Request Cancellation requested », une suppression indique « Signing Request Deletion requested », et une nouvelle tentative de certificat ajoute « Certificate regeneration requested ». Firma.dev écrit chaque ligne avant que la modification n'intervienne ; « requested » consigne donc la demande sans confirmer qu'elle a abouti. Vérifiez le statut de la demande avant d'agir sur l'une de ces lignes. Les lignes enregistrées avant la v1.40.3 conservent l'ancien libellé.

La liste complète est disponible dans le journal des modifications de l'API et dans le guide de la piste d'audit.

Résumé

Activez le code à usage unique et chaque demande complétée à partir du 20 octobre en portera la preuve : un événement otp_verified avec son heure et son adresse IP dans la piste d'audit, ainsi qu'une ligne Authentification sur la ligne de chaque signataire sur le certificat.

Commencez gratuitement avec Firma.dev, sans carte de crédit requise.