Cycle de vie d'une demande de signature¶

Une demande de signature suit un parcours bien défini dans VoidSign, de sa création jusqu'à sa complétion ou son annulation. Cette page est conçue pour les utilisateurs de la plateforme comme pour les intégrateurs de l'API.

Vue d'ensemble¶

Une demande de signature a son propre statut, et chaque signataire rattaché a également un statut propre. Ensemble, ils décrivent l'état complet d'une demande à tout instant.

Statuts de la demande¶

• Créée (created) : État initial. La demande a été créée et au moins un signataire n'a pas encore signé.
• Signée (signed) : État final positif. Tous les signataires ont signé le document. Un certificat de signature est généré et la demande est comptabilisée côté facturation.
• Annulée (cancelled) : État final négatif. Un membre de l'entreprise a annulé la demande avant que tous les signataires n'aient signé.

Statuts du signataire¶

• En file d'attente (waiting) : statut réservé à la future fonctionnalité d'ordre de signature. Aucun signataire ne prend ce statut aujourd'hui ; il apparaît dans le schéma de l'API par anticipation.
• En attente (pending) : Le signataire a été invité mais n'a pas encore signé. Il peut recevoir des relances.
• Signé (signed) : Le signataire a signé le document. Ce statut est définitif, même si la demande est annulée par la suite.
• Annulé (cancelled) : La demande a été annulée alors que le signataire n'avait pas encore signé.

Vue combinée des transitions¶

stateDiagram-v2
    state "Demande" as req {
        [*] --> created
        created --> signed : Dernier signataire signe
        created --> cancelled : Annulation
    }
    state "Signataire" as sig {
        [*] --> pending
        sig_signed: signed
        sig_cancelled: cancelled
        pending --> sig_signed : Signe
        pending --> sig_cancelled : Demande annulée
    }

Parcours d'une demande¶

Le diagramme ci-dessous illustre le parcours nominal (happy path) d'une demande avec un seul signataire :

sequenceDiagram
    participant I as Initiateur
    participant V@{ "type" : "entity" } as VoidSign
    participant S as Signataire

    I->>V: Crée la demande
    V->>S: Invite le signataire (e-mail ou iframe selon le flux)
    S->>V: Consulte le document
    S->>V: Signe le document
    V->>I: Notifie la complétion

1. Création: L'initiateur crée une demande depuis la plateforme ou via l'API, avec un ou plusieurs documents PDF et de 1 à 24 signataires, en plaçant les différents champs. La demande a le statut initial created, chaque signataire le statut pending.

2. Invitation: Chaque signataire est invité via le mécanisme correspondant à son flux : un e-mail d'invitation contenant un lien unique et personnel valable 30 jours pour voidsign_mail, ou l'iframe_url retournée à la création de la demande pour caller_embed. Voir Modes d'intégration.

3. Consultation: Lorsqu'un signataire ouvre son lien, il accède au document. Cette consultation est enregistrée et visible par l'initiateur depuis la plateforme.

4. Signature: Le signataire démarre la procédure de signature en accédant au document, puis donne son accord pour signature électronique. Son statut passe à signed. Si le signataire n'est pas le dernier signataire, il peut choisir d'être notifié lorsque tous les signataires auront signé.

5. Complétion: Lorsque le dernier signataire signe, la demande passe au statut signed. Un certificat de signature (nécessaire pour le dossier de preuves de la demande de signature) est généré et les signataires ayant demandé à être notifiés reçoivent un e-mail de confirmation. Pour les demandes créées depuis la plateforme, l'initiateur reçoit également un e-mail l'informant que la demande a été complétée. Les demandes créées via l'API n'ont pas d'initiateur utilisateur : dans ce cas, aucun e-mail de complétion n'est envoyé et vous êtes notifié via le webhook request.completed (voir Configurer les webhooks). D'un point de vue facturation, c'est à ce moment-là que la demande de signature est comptabilisée (voir Facturation pour plus de détails).

Relances¶

Des rappels peuvent être envoyés aux signataires au statut pending pour leur rappeler de signer :

• Relance automatique : si configurée lors de la création, des rappels sont envoyés automatiquement aux signataires n'ayant pas encore signé
• Relance manuelle : depuis la plateforme, un membre de l'entreprise peut envoyer une relance à tout moment

Annulation¶

Un membre de l'entreprise peut annuler une demande tant que son statut est created (c'est-à-dire tant que tous les signataires n'ont pas signé).

Lors de l'annulation :

• Les signataires au statut pending passent au statut cancelled
• Les signataires ayant déjà signé conservent leur statut signed
• La demande passe au statut cancelled

Fonctionnalités à venir¶

FAQ¶