Skip to main content
Les cachets d’organisation sont disponibles sur tous les plans sans frais supplémentaires. Un crédit par envoi couvre à la fois les signatures des destinataires et les participants de cachet sur la demande.

​
Qu’est-ce qu’un cachet d’organisation

Un cachet d’organisation est un cachet électronique appliqué au nom d’une personne morale (votre entreprise), et non d’une personne physique. Il appose une image de cachet d’entreprise et des métadonnées sur le document signé de manière automatique, sans nécessiter d’action humaine au moment de la signature. Utilisez-le pour automatiser la contresignature de votre entreprise : la plateforme applique le cachet à la position que vous choisissez dans l’ordre de signature, de sorte que personne de votre côté n’a à signer le document à la main. Chaque cachet comprend :
  • Une image de cachet (téléchargée, générée à partir du nom de l’entreprise ou dessinée)
  • Un nom d’affichage et un titre du signataire facultatif
  • Une attestation enregistrée lors de la création, confirmant l’autorité du créateur pour appliquer le cachet au nom de l’entreprise
Le cachet apparaît sur le PDF final aux côtés des signatures humaines. Le certificat de finalisation le répertorie comme participant avec la mention « Appliqué automatiquement », jamais « Signé ».

​
Qui peut créer un cachet

Seuls les propriétaires de l’entreprise (rôle Propriétaire) peuvent créer, remplacer, révoquer ou effacer des cachets d’organisation dans le tableau de bord. Les cachets d’entreprise se gèrent dans Paramètres > Cachets d’organisation ; les cachets d’espace de travail dans Paramètres > Cachets d’organisation de l’espace concerné. Sur l’API, une clé API protégée (la clé de l’espace de travail protégé de l’entreprise) est requise pour les cachets de portée entreprise. Les cachets de portée espace de travail acceptent la clé propre de cet espace ou la clé protégée.

​
La déclaration d’autorité

Chaque cachet nécessite une attestation avant de pouvoir être utilisé. Le créateur lit et accepte une déclaration confirmant qu’il a l’autorité de lier l’entreprise. Cette acceptation est enregistrée avec :
  • L’identité de l’attestant (l’utilisateur du tableau de bord ou la clé API ayant effectué l’appel)
  • Adresse IP et user agent
  • Langue et version de la déclaration
  • Un hash SHA-256 du texte canonique de la déclaration

​
Remplacer un cachet

Depuis le 13 octobre 2026, PATCH /seals/{id} crée une nouvelle version lorsque vous envoyez image, typed, display_name, signatory_title ou statement. Lisez d’abord le cachet avec GET /seals/{id}. Envoyez statement avec accepted: true, version: 1, language, text exactement égal au statement_text renvoyé et signatory_name. Incluez statement.signatory_title si nécessaire. Sans statement, la demande renvoie 400 SEAL_STATEMENT_REQUIRED et n’écrit rien. Chaque version de remplacement enregistre sa propre acceptation : le moment du remplacement (attested_at), l’utilisateur ou la clé API qui l’a effectué et le signataire fourni avec le remplacement (signatory_name et signatory_title_attested). Le texte de la déclaration, le hash SHA-256, la langue, la version de la déclaration et authority_name restent ceux de la version 1 du cachet. Les demandes déjà envoyées conservent la version du cachet figée lors de leur envoi. Les demandes envoyées après le remplacement utilisent la nouvelle version ; leurs certificats affichent le nouveau signataire et la date d’attestation. Le comportement de création de POST /seals reste inchangé. Pour un cachet dont le statement_language vaut fr, envoyez ce corps à PATCH /seals/{id}. Remplacez le texte indicatif de text par le statement_text exact de GET /seals/{id}. Utilisez la langue enregistrée du cachet pour language.
Les objets de cachet renvoyés par POST /seals, GET /seals, GET /seals/{id} et PATCH /seals/{id} incluent statement_text et statement_hash. L’objet seal des webhooks organization_seal.created, organization_seal.updated et organization_seal.deleted les inclut aussi. Les identifiants de l’utilisateur et de la clé API de l’attestant, l’adresse IP et le user agent sont exclus de ces objets de cachet.

​
Portée et valeurs par défaut

Les cachets existent à deux niveaux : Définissez au plus un défaut par portée. L’expéditeur peut toujours choisir un cachet différent dans la portée applicable lors de la création ou de la modification d’une demande de signature.

​
Ajouter un participant de cachet

Un participant de cachet est un emplacement dans l’ordre de signature que le système remplit automatiquement. Ajoutez des participants de cachet aux modèles et aux demandes de signature aux côtés des destinataires humains. Destinataires et cachets partagent un même espace d’ordre.

​
Dans les éditeurs

Dans l’éditeur de modèles, ouvrez le panneau Utilisateurs du modèle de la barre latérale ; dans l’éditeur de demandes de signature, ouvrez le panneau Signataires. Cliquez sur Ajouter un cachet, choisissez le cachet dans la liste déroulante de la ligne et faites glisser la ligne pour définir sa position. La ligne indique S’applique à l’envoi en première position et S’applique après le précédent partout ailleurs. Sélectionnez la ligne du cachet et placez au moins un champ de cachet sur le document. Tant qu’une ligne de cachet est sélectionnée, la palette de champs se limite aux champs cachet, texte et date.

​
Via l’API

Sur POST /signing-requests et POST /signing-requests/create-and-send, envoyez un tableau seal_participants. Chaque entrée comprend :
  • temp_id est un identifiant choisi par le client pour affecter des champs au cachet (seal_participant_temp_id sur le champ)
  • seal_id est le cachet d’organisation à appliquer ; il doit être dans la portée de l’espace de travail de la demande. Sur les routes de création, vous pouvez l’omettre pour utiliser le cachet par défaut
  • order est la position dans l’espace d’ordre partagé. Ordre 1 (première position) : le cachet est appliqué à l’envoi, avant qu’un destinataire ne soit invité ou qu’un crédit ne soit facturé. Après le destinataire N : le cachet est appliqué automatiquement une fois que tous les participants d’ordre inférieur ont terminé
Sur PATCH /signing-requests/{id} et PATCH /templates/{id}, envoyez à la place un seul objet seal_participant. Sans id, il ajoute un participant de cachet (seal_id, order) ; avec l’id d’un participant existant, il le déplace (order) ou change son cachet (seal_id). Sur les demandes de signature, id avec swap_to_seal_id échange un participant en pause (voir Échanger ci-dessous). PUT /templates/{id} accepte un tableau seal_participants et remplace l’ensemble complet des participants de cachet du modèle. Il applique chaque entrée de users et de deleted_users séparément ; les entrées appliquées avant un échec le restent, donc relisez le modèle après toute réponse non 2xx. Pour les entrées d’un tableau seal_participants sur les routes de création, un cachet d’une autre entreprise ou limité à un autre espace de travail renvoie 404 NOT_FOUND ; un cachet révoqué, supprimé ou remplacé (qui n’est pas la version actuelle) renvoie 409 SEAL_UNAVAILABLE ; omettre seal_id lorsqu’il n’existe aucun cachet par défaut renvoie 400 SEAL_UNAVAILABLE. Si les cachets d’organisation ne sont pas activés, une création avec des cachets renvoie 503 SEALS_DISABLED. À la création : sans cachet résolu, les destinataires sont numérotés dans l’ordre du tableau lorsque use_signing_order est false ou qu’un destinataire omet order. Une création à partir d’un document avec des cachets exige un order sur chaque destinataire et un espace d’ordre contigu. Les participants de cachet possèdent des champs de cachet (au moins un), un champ de date facultatif et des champs de texte renseignés à partir de display_name et signatory_title. Tous les champs de cachet sont générés par le serveur et en lecture seule ; les valeurs fournies par le client sur ces champs sont ignorées. Donnez à chaque cachet au moins un champ tampon : l’envoi d’une demande de signature dont le cachet n’en a aucun renvoie 400 SEAL_NO_IMAGE_FIELD. Sur POST /signing-requests et POST /signing-requests/create-and-send, un champ de texte appartenant à un cachet peut utiliser seal_attribute (display_name ou signatory_title) pour déterminer quelle propriété du cachet le champ imprime. Toute autre valeur non nulle renvoie 400 VALIDATION_ERROR ; null est accepté. POST /templates n’accepte pas seal_participants. Il ignore la clé et renvoie une entrée warnings dans le 201. Ajoutez des cachets avec PATCH /templates/{id} ou PUT /templates/{id}. Pour retirer un participant de cachet et ses champs d’une demande non envoyée, appelez DELETE /signing-requests/{id}/seal-participants/{participant_id}. Les participants restants sont renumérotés pour combler l’écart.

​
Création à partir d’un modèle

Lorsque vous créez avec template_id, la clé seal_participants détermine ce qu’il advient des cachets du modèle :
  • Absente ou null : la demande hérite des cachets du modèle et de leurs champs.
  • Un tableau : le tableau remplace les cachets du modèle. Les champs de cachet du modèle ne sont pas copiés.
  • [] : la demande est créée sans cachet.
  • Tout autre type renvoie 400 VALIDATION_ERROR.
Les champs du corps ne font que remplacer ceux du modèle : sur un modèle qui a des champs, les cachets d’un tableau de remplacement ne peuvent donc obtenir aucun champ tampon dans cet appel, et l’envoi renvoie 400 SEAL_NO_IMAGE_FIELD. Pour utiliser vos propres cachets avec leurs champs, créez à partir d’un document (ou, sur POST /signing-requests uniquement, utilisez un modèle sans champs et affectez les champs du corps avec seal_participant_temp_id). Sinon, héritez des cachets du modèle. Un cachet hérité utilise la version actuelle du cachet. Si le cachet n’a pas de version actuelle, ou si cette version est révoquée ou supprimée, la création renvoie 409 SEAL_UNAVAILABLE et rien n’est créé. Si au moins un cachet hérité est conservé et que les cachets d’organisation ne sont pas activés, la création renvoie 503 SEALS_DISABLED. Un cachet hérité limité à un autre espace de travail est écarté avec ses champs, et la réponse le liste avec dropped: true ; toutes les autres entrées conservées portent dropped: false. Lorsqu’au moins un cachet est résolu lors d’une création à partir d’un modèle, la demande est renumérotée de 1 à n. Les cachets hérités conservent leur position par rapport aux destinataires du modèle ; les cachets d’un tableau de remplacement sont placés selon leur order. Un cachet passe en premier lorsqu’il est à égalité avec un destinataire. Depuis le 13 octobre 2026, sur POST /signing-requests et POST /signing-requests/create-and-send avec template_id, si le modèle n’a pas de destinataires propres et que seal_participants est absent ou vaut null, les cachets hérités conservent l’ordre du modèle aux positions 1..k ; les destinataires de la demande suivent à partir de k+1. Les tableaux de remplacement explicites, les modèles avec destinataires et les demandes sans cachets conservent leur comportement d’ordre existant. POST /templates/{id}/duplicate rattache telle quelle la version de cachet enregistrée (un cachet remplacé, révoqué ou supprimé échoue à l’envoi) et ne renvoie pas seal_participants en fonctionnement normal, quelle que soit l’entreprise. Tant que la modification multi-documents est suspendue, la duplication d’un modèle sur le chemin multi-documents en lecture seule renvoie 409 MULTI_DOCUMENT_READ_ONLY. Pour les autres modèles pendant cette suspension, elle copie les cachets du modèle de la même façon : version actuelle, 409 SEAL_UNAVAILABLE, 503 SEALS_DISABLED, et cachets limités à un autre espace de travail que l’espace de travail cible listés avec dropped: true ; elle renvoie seal_participants.

​
Lecture des cachets d’un modèle

GET /templates/{id} et PUT /templates/{id} renvoient seal_participants, triés par order, ou [] lorsque le modèle n’en a aucun.

​
Modification de l’ordre

Les signataires, les approbateurs et les cachets partagent un seul espace d’ordre ; les destinataires CC sont séparés. Sur une demande non envoyée, avec PATCH /templates/{id} ou PATCH /signing-requests/{id} :
  • Déplacez un participant vers une position dans [1..n]. Les participants situés entre l’ancienne et la nouvelle position sont décalés d’un cran. Une cible supérieure à n renvoie 400 INVALID_SIGNING_ORDER.
  • Insérez un nouveau destinataire à une position dans [1..n+1], ou omettez order pour l’ajouter en dernier. Pour un nouveau destinataire, order: 0 ou une position hors de cette plage renvoie 400 INVALID_SIGNING_ORDER. Un nouveau participant de cachet exige un entier positif pour order ; une valeur absente ou nulle (zéro) renvoie 400 VALIDATION_ERROR, tandis qu’une position hors de [1..n+1] renvoie 400 INVALID_SIGNING_ORDER.
  • Si les participants sont modifiés simultanément, une écriture peut renvoyer 409 PARTICIPANTS_CHANGED. Rechargez et réessayez.
Dès qu’une demande de signature est envoyée (y compris terminée ou annulée), PATCH /signing-requests/{id} renvoie 409 ALREADY_SENT. Une seule exception : un appelant protégé peut échanger un participant de cachet en pause sur une demande ni terminée ni annulée (voir Échanger ci-dessous). DELETE /signing-requests/{id}/seal-participants/{participant_id} renvoie 409 SEAL_MUTATION_NOT_ALLOWED sur une demande envoyée, et 409 ALREADY_FINISHED ou 409 ALREADY_CANCELLED sur une demande terminée ou annulée.

​
Ce que le certificat affiche

Le certificat de finalisation comprend une ligne par participant de cachet :
La colonne Identité affiche l’une des trois valeurs : Si un cachet a été mis en pause puis échangé, les deux événements apparaissent sur le certificat. Aucune adresse IP n’est enregistrée pour les participants de cachet.

​
Révoquer, arrêter les applications en cours et échanger

​
Révoquer

La révocation d’un cachet est prospective : les nouveaux envois ne peuvent pas l’utiliser, mais les participants déjà liés sur des demandes envoyées continuent d’appliquer leur version liée. Révoquez depuis le menu du cachet dans le tableau de bord, ou avec DELETE /seals/{id}. Choisissez arrêter les applications en cours (DELETE /seals/{id}?stop_pending=true) pour mettre également en pause chaque participant en transit qui ne s’est pas encore appliqué. Chaque participant mis en pause :
  • Déclenche un webhook signing_request.seal.paused
  • Envoie un e-mail à l’expéditeur expliquant quelle demande est concernée
  • Bloque la progression de la signature jusqu’à ce que l’expéditeur résolve le problème

​
Échanger

Un participant de cachet mis en pause peut être échangé contre un autre cachet de la portée applicable, par un propriétaire de l’entreprise depuis la vue de la demande, ou via l’API avec une clé protégée :
Chaque échange enregistre une ligne de suivi en ajout seul. Après l’envoi, les seules issues pour un participant de cachet sont échanger (sur un participant en pause) ou annuler la demande entière.

​
Consulter un cachet

  • GET /seals liste les cachets visibles dans la portée de la clé ; GET /seals/{id} en renvoie un
  • GET /seals/{id}/image renvoie le PNG canonique. Chaque lecture d’image est inscrite au journal d’accès du cachet
  • GET /seals/{id}/applications liste les demandes de signature auxquelles le cachet a été appliqué
  • GET /seals/{id}/access-log liste les événements de cycle de vie et de lecture d’image du cachet

​
Effacement et conservation

Les versions de cachets, les attestations et les lignes de journal d’accès sont conservées tant qu’une demande de signature envoyée ou finalisée (y compris les demandes de test) fait référence à la version. Cela a le même statut que les documents signés. Un lignage de cachet révoqué qui n’est référencé par aucune demande et aucun modèle peut être effacé par un propriétaire de l’entreprise 90 jours après la révocation, dans le tableau de bord ou avec DELETE /seals/{id}/erase. La réponse énumère les modèles et demandes qui bloquent l’effacement le cas échéant. L’effacement est enregistré en ajout seul.

​
Webhooks

Les cachets d’organisation génèrent sept types d’événements :

​
Événements du cycle de vie du cachet

  • organization_seal.created : un nouveau cachet a été créé
  • organization_seal.updated : l’image d’un cachet a été remplacée (nouvelle version), il a été renommé ou son statut par défaut a changé
  • organization_seal.deleted : un cachet a été révoqué
  • organization_seal.erased : un lignage de cachet révoqué a été définitivement effacé

​
Événements de cachet dans les demandes de signature

  • signing_request.seal.applied : un cachet a été appliqué à un document
  • signing_request.seal.paused : un participant de cachet a été mis en pause (cachet révoqué avec arrêt des applications en cours, ou incohérence d’intégrité)
  • signing_request.seal.swapped : un participant de cachet en pause a été échangé contre un cachet différent
Abonnez-vous à ces événements via la configuration des Webhooks. Lors de la création d’un cachet, préférez un nom d’entreprise saisi ou un logo d’entreprise plutôt qu’une reproduction d’un autographe manuscrit réel. Une image manuscrite sur un cachet d’organisation est trompeuse (elle implique qu’une personne a signé) et peut constituer un support de contrefaçon. Les modes texte et dessin produisent une marque nette et reconnaissable qui représente honnêtement l’entreprise.

​
Mode test

Les clés API de test peuvent créer et gérer des cachets actifs. Les demandes de signature de test peuvent les appliquer. Chaque document de test porte un filigrane, de sorte qu’aucun artefact de test n’est jamais sans marque. Le sceau numérique PAdES est appliqué aux documents de test lorsqu’il est activé dans l’espace de travail.

​
Guides connexes