Clé de problème
Dernière mise à jour le
2 avr. 2026
Notes de mise à jour d’Adobe Sign : 2021
Adobe Sign : mars 2021
Fonctionnalité améliorée
Formulaires web multi-signataires
Les comptes qui utilisent les formulaires web ont désormais la possibilité d'autoriser plusieurs destinataires externes dans le processus de signature.
Les destinataires supplémentaires sont définis par le signataire initial :
Utilisez les modèles de bibliothèque pour créer des formulaires web
Les auteurs peuvent désormais utiliser les modèles de bibliothèque existants pour créer de nouveaux formulaires web. Le fichier est importé avec tous les champs intacts :
« Mode fluide » dans Adobe Sign pour l'affichage mobile
Liquid Mode est une fonction facultative permettant de générer une vue réactive afin d’améliorer l’affichage de vos documents selon le type d’appareil du signataire.
Le document signé est stocké dans la version « PDF » standard tandis que les destinataires peuvent voir le mode fluide sur les téléphones mobiles et peuvent basculer pour afficher le document original.
Vous pouvez désormais charger un document HTML et générer une vue Liquid Mode pour les téléphones mobiles.
Vous trouverez plus de détails sur l'option mode fluide ici >
Verrouiller la valeur nom pour les utilisateurs connus lors de la signature via les méthodes de signature par image ou dessinée
Dans certains cas, il n’est pas souhaitable de pouvoir modifier le nom du destinataire pendant le processus de signature. Adobe Sign offre une certaine souplesse à cet égard, par respect de la préférence de nom du signataire. Dans les environnements les plus normalisés, cette flexibilité est inacceptable. Il existe donc une nouvelle commande permettant de verrouiller les noms des destinataires dans l’accord.
Les administrateurs ont désormais la possibilité d'empêcher les destinataires avec des valeurs nom connues de modifier ces valeurs lorsqu'ils appliquent une signature dessinée ou par image .
Cas où la valeur Nom est connue :
- Lors de l’envoi à un destinataire avec un ID Adobe Sign
- Lors de l’envoi du nom via l’API
- Lorsque les champs Informations du signataire sont remplis pendant la saisie du formulaire
- Lorsque le nom est verrouillé pendant la réalisation d'une authentification KBA ou par pièce d'identité officielle
Plus de détails sur cette fonctionnalité sont disponibles ici >
Améliorations de l'authentification basée sur la connaissance
Des contrôles ont été ajoutés à la méthode KBA d'authentification d'identité qui peuvent exiger que l'expéditeur fournisse un nom pour le destinataire et que cette valeur nom soit verrouillée en place tout au long du processus de signature.
Options pour une sécurité e-mail renforcée
Deux nouvelles options sont disponibles pour améliorer la sécurité des emails. Ces deux paramètres sont activés par défaut :
- Ajouter un lien dans les e-mails pour afficher le contrat signé
- Inclure une image de la première page du contrat dans les e-mails
- Option activée par défaut.
- Lorsque cette option est activée, une image de la première page de l'accord est visible dans certaines distributions d'e-mail
Mises à jour de l'API REST v6
EN-TÊTES STANDARD DANS CHAQUE REQUÊTE API REST V6
Par défaut, chaque demande API REST v6 comporte désormais les en-têtes standard suivants :
/AGREEMENTS
Tous les points d'entrée /agreements qui ont un chemin d'accès agreement id renvoient maintenant un code erreur 404 AGREEMENT_DESTROYED si l'accord a été supprimé via les Outils RGPD.
MODÈLES DE BIBLIOTHÈQUE
PUT /libraryDocuments/{libraryDocumentId} - Étendu pour inclure le nouveau champ ownerId
Annotation
Seule l’API REST v6 est affectée.
Tout appel API REST v6 qui n'inclut pas ces en-têtes documentera explicitement cette absence.
- GET /libraryDocuments - Développé pour inclure le nouveau champ ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Développé pour inclure les nouveaux champs : ownerId, ownerEmail, et ownerName
Nouveaux champs dans l'objet LibraryDocumentInfo :
Champs dont le comportement a été mis à jour :
FORMULAIRES WEB (/WIDGETS)
- POST /widgets - L'utilisation d'un libraryDocumentId pour créer un formulaire web est maintenant prise en charge avec un id valide
Code d’état ajouté :
- PUT /widgets - L'utilisation d'un libraryDocumentId pour créer un formulaire web est maintenant prise en charge avec un id valide
Code d’état ajouté :
- PUT /widgets/{widgetId} - Développé pour inclure le nouveau champ ownerId
Code d’état ajouté :
Modifications de l’expérience
- GET /widgets/{widgetId} - Développé pour inclure les nouveaux champs : ownerId, ownerEmail, ownerName, et creatorName
Nouveaux champs dans l'objet WidgetInfo :
Champs dont le comportement a été mis à jour :
/MEGA SIGN
NOUVEAU :
- GET /megaSigns/{megaSignId}/formFields - Récupère les détails des champs de formulaire d'un contrat parent Mega Sign
Paramètres :
Objet de réponse :
- PUT /megaSigns/{megaSignId}/formFields - Met à jour les champs de formulaire d'un contrat Mega Sign
Paramètres :
Objet de réponse :
MISE À JOUR :
- POST /megaSigns - CRÉATION a été ajoutée en tant que valeur d'état pour prendre en charge la création d'un modèle Mega Sign
Paramètre modifié :
- PUT /megaSigns/{megaSignId}/state - CRÉATION a été ajoutée en tant que valeur d'état pour prendre en charge la création d'un modèle Mega Sign.Par conséquent, megaSignCancellationInfo n'est plus un champ obligatoire
Les nouvelles pages Accueil et Gérer ont été activées pour tous les comptes restants.
Tous les comptes ont eu leur ensemble de contrôles mis à jour pour activer les pages Accueil et Gérer modernes pour leurs utilisateurs.
Les contrôles du menu administrateur restent disponibles pour les comptes qui doivent revenir à l'expérience classique :
Niveau de service Adobe Sign et ID de compte exposés dans le menu administrateur
Les administrateurs peuvent maintenant trouver leur ID de compte sur la page Paramètres globaux :
L'ID de groupe se trouve sur la page Paramètres du groupe :
Configuration HIPAA explicite
Une nouvelle page est disponible pour indiquer clairement quand le compte est activé pour gérer les accords soumis aux exigences HIPAA.
- Cette commande est uniquement affichée au niveau du compte. Les administrateurs de groupe n’y ont pas accès.
- Ce contrôle est en lecture seule, pour indiquer clairement quand le compte est configuré
- Contactez votre gestionnaire du succès client ou l’assistance pour activer la configuration HIPAA.
Plus d'informations sur les paramètres HIPAA sont disponibles ici >
Le bouton « Appel à l'action » a changé pour les clients utilisant l'application Outlook pour postes de travail sur les systèmes Windows
Les destinataires qui utilisent un client de messagerie Outlook de bureau verront que le bouton d’appel à l’action a été mis à jour dans les e-mails Adobe Sign.
La nouvelle expérience supprime le bouton HTML bleu et fournit à la place un lien textuel cliquable :
Annotation
Ce changement affecte uniquement les applications Outlook de bureau sur les systèmes Windows.Les autres clients de messagerie et systèmes d’exploitation continuent de recevoir le modèle avec le bouton bleu.
Délégation d'accords avec signatures numériques
La possibilité de déléguer un contrat avec des signatures numériques apposées a été améliorée pour permettre la délégation depuis la notification e-mail originale vers le destinataire, via la délégation automatique lorsqu'elle est configurée par un utilisateur, et via l'action Remplacer le signataire actuel sur la page Gérer.
Interface mise à jour pour l'intégration Paiements
L'interface Paiements a été mise à jour pour mieux exposer les contrôles d'authentification, créant un processus de configuration plus facile.
La valeur maximale pour la gouvernance des données a été augmentée à 5 475 jours (15 ans)
Les clients qui utilisent des règles de gouvernance des données pour supprimer automatiquement les accords du système Adobe Sign peuvent désormais définir cette date de suppression à un maximum de 15 ans (contre dix auparavant).
Le libellé textuel au niveau du champ pour valider le numéro de sécurité sociale américain a été mis à jour :
Le libellé textuel au niveau du champ pour valider le numéro de sécurité sociale américain a été mis à jour pour clarifier que le numéro de sécurité sociale est propre aux États-Unis :
Rappel : L'authentification sociale a été supprimée
Comme annoncé en novembre, la méthode d'authentification utilisant l'identité sociale a été supprimée de la liste des méthodes d'authentification dans le menu Administrateur.
Rappel : L'intégration Twitter personnelle a été supprimée
Comme annoncé en décembre, la possibilité pour les utilisateurs d’établir des connexions personnelles authentifiées avec Twitter a été supprimée.
Les utilisateurs inactifs recevront une notification par e-mail lorsqu'ils seront inclus dans un accord
Les utilisateurs définis avec un statut inactif reçoivent désormais une notification par e-mail demandant au destinataire de déléguer l'accord à un autre utilisateur.
Problèmes résolus
Adobe Sign : mai 2021
Fonctionnalité améliorée
Transfert de la propriété des modèles de bibliothèque et des formulaires web à un autre utilisateur
La modification du propriétaire d’une ressource peut être effectuée par n’importe quel administrateur du compte qui y a accès.
L'administrateur peut attribuer la propriété du fichier à tout utilisateur sous son autorité.
- Les administrateurs de compte ont accès à toutes les ressources partagées et à tous les utilisateurs. Par conséquent, ils peuvent réattribuer la propriété de n’importe quel modèle de bibliothèque ou formulaire web à n’importe quel autre utilisateur de leur compte.
- Si la ressource est configurée pour n’être disponible que pour un seul utilisateur (le propriétaire), elle n’est pas partagée et, par conséquent, il n’est pas possible de la réaffecter à un nouveau propriétaire.
- Les administrateurs de groupe peuvent uniquement accéder aux modèles de bibliothèque et aux formulaires web des groupes pour lesquels ils disposent de droits d’administration.
- Les administrateurs de groupe peuvent seulement réattribuer un fichier à un utilisateur dont le groupe principal relève de leur autorité administrative
POINTS D'ENTRÉE API MIS À JOUR PRENANT EN CHARGE LE TRANSFERT DE FICHIERS
Les points de terminaison décrits ci-dessous sont uniquement disponibles dans l’API REST v6.
Étendu pour prendre en charge la mise à jour du propriétaire d’un document de bibliothèque.
LibraryDocumentInfo:
Codes d’état d’erreur supplémentaires :
Étendu pour prendre en charge la mise à jour du propriétaire d’un widget.
WidgetInfo:
Codes d’état d’erreur supplémentaires :
Nouveaux champs dans l’objet LibraryDocument :
Nouveaux champs dans l'objet LibraryDocumentInfo :
Champs avec comportement mis à jour :
Nouveaux champs dans l'objet WidgetInfo :
Champs avec comportement mis à jour :
Modifications de l’expérience
La valeur de retour par défaut de l'API v6 REST GET /workflows{workflowId} a changé
L'appel API v6 REST GET /workflows{workflowId} a été mis à jour pour renvoyer la version actuelle du WorkflowID (par rapport à l'ID de version d'origine, qui était la valeur renvoyée avant la version de mai)
Cette mise à jour aligne l'expérience API par défaut avec l'expérience Webhook, fournissant le même WorkflowID, ce qui devrait améliorer le développement et la gestion des applications.
Si, pour une raison quelconque, votre compte nécessite que l'API renvoie l'ID d'origine (comme c'était le cas avant la version de mai), contactez l'assistance pour demander que votre compte renvoie les ID de version de base pour les processus
Problèmes résolus
Adobe Sign : juin 2021
Utilisateurs dans plusieurs groupes (UMG)
Les administrateurs de plusieurs comptes de groupe peuvent désormais accorder aux utilisateurs de leur compte l’accès à plusieurs groupes, ce qui ouvre la possibilité d’utiliser des groupes comme modèle de workflow, en appliquant des contrôles d’envoi et de signature spécifiques pour les modèles de bibliothèque disponibles pour le groupe.
Les comptes Grands comptes et Entreprises existants qui souhaitent effectuer la mise à niveau peuvent consulter la procédure de mise à niveau ici >
Un résumé des différences importantes est disponible ici >
Introduction du Liquid Mode dans Sign
Activez la vue Liquid Mode pour les téléphones mobiles pour les fichiers HTML envoyés via la page Envoyer ou l’API sendAgreement. L’option permettant d’activer Liquid Mode dans Sign pour les fichiers HTML est désormais disponible dans la liste du menu Administrateur au niveau du compte et du groupe.
Des informations supplémentaires sur les documents Liquid Mode sont disponibles ici >
Annotation
Liquid Mode est actuellement disponible uniquement dans les environnements NA1, NA2 et NA4.
Mises à jour transparente des formulaires web
Les formulaires web au statut Brouillon peuvent être modifiés pour éditer les éléments suivants :
- Nom du formulaire web
- de modifier l’adresse e-mail du ou des contre-signataires
- l'adresse e-mail des parties en copie
- Fichiers joints à modifier
- Champs du formulaire web (précédemment disponibles)
La mise à jour d’un formulaire web actif permet de modifier les éléments de formulaire sans modifier l’URL d’origine, ce qui permet un processus fluide si vous devez mettre à jour le contenu d’un formulaire web déjà incorporé ou envoyé à votre audience. Les éléments qui peuvent être modifiés sont :
- Fichiers (documents) et champs appliqués pour les destinataires
- Contre-signataires (à partir de la page Gérer)
- Parties en copie (à partir de la page Gérer)
Annotation
Pour activer la fonctionnalité transparente des formulaires web, vous devez activer l’option Autoriser des participants supplémentaires dans le menu Paramètres généraux :
Tampon Participation : contrôle de l’affichage du titre et de la société
Des contrôles ont été ajoutés pour autoriser ou supprimer le Titre et la Société (dérivé du profil utilisateur) sur le champ de tampon du participant.
Pour plus de détails, consultez la page Types de champs >
Options de recherche améliorées : correspondances de préfixe et d’expression
Des options de recherche avancées ont été introduites pour permettre des modèles de recherche plus spécifiques qui permettent de réduire la liste des accords renvoyés.
Pour plus de détails sur le fonctionnement de la recherche dans Adobe Sign, cliquez ici >
Nouvelle norme OAuth 2.0
Une nouvelle version (améliorée) du point d’entrée OAuth a été ajoutée pour éviter les erreurs d’utilisation. Avec cette version :
- api_access_point / web_access_point renvoie uniquement dans la requête de jeton d’accès (dans le corps)
- Adobe Sign n’accepte pas la clé secrète comme paramètre de requête.
- La rotation du secret client est prise en charge
Le point d’entrée OAuth v1 continuera de fonctionner pour les connexions existantes au cours des prochains mois pour éviter toute interruption de service.
L'abandon d'OAuth v1 sera annoncé sur la page des notifications techniques une fois programmé.
Alternance de la clé secrète du client
Les clés secrètes du client d’application peuvent être alternées par n’importe quel administrateur ayant accès à l’ID d’application dans l’interface utilisateur Adobe Sign :
Modifications de l’expérience
Les administrateurs de groupes peuvent uniquement afficher les applications API qui relèvent de leur autorité d’administration
La visibilité des applications associées au compte est désormais limitée pour afficher uniquement les applications qui relèvent du périmètre d’administration de l’utilisateur. Seuls les administrateurs de groupe verront le changement de comportement :
- Les utilisateurs voient les applications qu’ils possèdent.
- Les administrateurs de groupe voient les applications des groupes qui relèvent de leur autorité d’administration.
- Les administrateurs de compte voient toutes les applications du compte.
L’e-mail envoyé à l’expéditeur lorsqu’un accord est terminé a été mis à jour
La notification électronique finale d’un accord envoyée à l’expéditeur a été mise à jour pour fournir une liste complète de toutes les parties notifiées au sujet de l’accord terminé.
Seul l’expéditeur d’origine reçoit ce modèle d’e-mail.
Résultat de l’API REST v6 mis à jour pour GET /agreements/{agreementId}/signingUrls
Avant la version de juin, lors de l’appel de GET /agreements/{agreementId}/signingUrls, l’API renvoyait une valeur 404 immédiatement après la création de l’accord.
Pendant une courte période après la suppression de l’erreur 404, une autre réponse était renvoyée, mais incluait uniquement les URL de signature de l’expéditeur. (La participation du signataire était encore en cours de définition.)
Après le lancement de la version de juin 2021, un code 404 : AGREEMENT_NOT_EXPOSED est renvoyé jusqu’à ce que la liste complète des URL de signature soit terminée. Un code 200 est alors renvoyé.
Les clients qui ne souhaitent pas continuer à essayer l’appel d’API jusqu’à ce que la réponse 200 soit renvoyée sont invités à utiliser Webhooks et à répondre à l’événement AGREEMENT_CREATED.
Problèmes résolus
Adobe Sign : Août 2021
Modification de l’expérience
- Prise en charge du service Aadhaar International : les clients de toutes les instances d’Adobe Sign peuvent désormais utiliser le service Aadhaar en option comme fournisseur de signature numérique. Auparavant, il était uniquement mis à disposition des comptes sur l’instance IN1. Le module complémentaire Aadhaar est facturé à la transaction de signature.
- Mise à jour de l’API REST v6 : POST /users : l’appel API REST v6 POST /users a été mis à jour pour créer l’utilisateur dans le groupe Par défaut du compte si le paramètre facultatif primaryGroupId n’est pas défini. Seule la version 6 de l’API REST est affectée par cette modification.
Problèmes résolus
|
|
Description |
|---|---|
|
4299495 |
Correction d'un problème dans le concepteur de processus qui empêchait le fonctionnement d'une URL définie par le client dans les instructions. |
|
4308294 |
Correction d'un problème dans le fichier CSV (valeurs séparées par des virgules) de rapport où les champs À et Nom du destinataire pouvaient rester vides lorsque la même adresse e-mail de destinataire était utilisée plusieurs fois dans le contrat. |
|
4310569 |
Les modèles Adobe Sign ont été retirés des options de sandbox. |
|
4311098 |
Correction d'un problème où les administrateurs de groupe ne pouvaient pas mettre à jour les utilisateurs d'un groupe par chargement CSV. |
|
4311723 |
Correction d'un problème où l'appel API GET /groups/ID/users échouait si l'utilisateur se trouvait sur une instance Adobe Sign différente. |
|
4312103 |
Correction d'un problème où les utilisateurs SAML créés via un chargement en masse seraient dans un état Créé (au lieu de Principal). |
|
4312309 |
Correction d'un problème où les administrateurs de groupe ne pouvaient pas réaffecter la propriété des formulaires web si d'autres utilisateurs de leur groupe les avaient créés. |
|
4312840 |
Correction d'un problème lié à l'activation de nouveaux utilisateurs lorsqu'un second e-mail d'activation était envoyé au nouvel utilisateur et que le lien de ce second e-mail était utilisé. |
|
4314751 |
Correction d'un problème où l'option pour refuser l'accord n'était pas visible lors de la signature au nom d'un autre utilisateur. |
|
4315033 |
Correction d'un problème où les administrateurs de compte ne pouvaient pas réinitialiser les mots de passe lorsque le mode SAML était défini sur Obligatoire. |
|
4315605 |
Correction d'un problème où les images de pièce d'identité officielle n'étaient pas traitées correctement. |
|
4316057 |
Correction d'un problème où la pièce d'identité officielle produisait une erreur indiquant que les quatre coins du document ne pouvaient pas être détectés. |
|
4316474 |
Correction d'un problème où « Signer au nom de » était visible dans les comptes où cette option n'était pas activée. |
|
4316659 |
Correction d’un problème en raison duquel l’adresse e-mail pour « actingUserEmail » dans un appel GET /agreements/id renvoyait un e-mail généré par le système une fois l’accord entièrement signé. |
|
4317095 |
Correction d'un problème où un nom de destinataire était importé dans le libellé Participant 1 lorsque l'authentification basée sur les connaissances était utilisée pour le premier signataire. |
|
4317221 |
Correction d'un problème où les e-mails de notification automatique pour les webhooks défaillants étaient envoyés au créateur du webhook malgré une configuration censée ne pas le notifier. |
|
4317347 |
Correction d'un problème où l'authentification OAuth dans Power Automate redirigeait l'utilisateur vers la page d'accueil. |
|
4317429 |
Correction d'un problème où les administrateurs ne pouvaient pas mettre à jour la propriété Peut envoyer pour les utilisateurs lors de la mise à jour via le chargement CSV. |
|
4317548 |
Correction d'un problème où certains clients utilisant l'iPad voyaient la page web au lieu de la page optimisée pour les appareils mobiles. |
|
4317629 |
Correction d'un problème d'affichage avec les noms contenant une apostrophe qui affichaient le code HTML de l'apostrophe. |
|
4318175 |
Correction d’un problème en raison duquel les utilisateurs obtenaient une erreur lors de l’archivage d’un compte via le lien de l’e-mail. |
|
4319012 |
Correction d’un problème en raison duquel les utilisateurs créés via le POST /users REST v5 et v6 n’étaient pas créés dans le groupe par défaut. |
|
4320197 |
Correction d'un problème où le rapport d'identité du signataire ne pouvait pas être téléchargé depuis la page Gérer parce que le bouton était inactif. |
Adobe Sign : septembre 2021
Fonctionnalité améliorée
- Sandbox : les clients de niveau Grands comptes ont la possibilité d’acheter l’accès à un environnement Sandbox pour tester des modèles, des workflows clients, des applications API, etc. Ces objets peuvent être déplacés de la production vers le sandbox pour effectuer des mises à jour dans un environnement sécurisé, puis replacés en production une fois les mises à jour vérifiées et prêtes pour le déploiement.
- Prise en charge de la signature numérique ECDSA - Adobe Sign prend désormais en charge des signatures numériques plus sécurisées et efficaces basées sur le format ECDSA, qui utilise la cryptographie à courbe elliptique telle que définie dans la norme ANS X9.62-2005.
Les courbes NIST dotées de fonctions de hachage SHA-2, telles que définies par les normes FIPS, sont désormais prises en charge. Ainsi, nos fournisseurs partenaires de services de confiance (TSP) du Cloud Signature Consortium ont la possibilité de fournir aux signataires des informations d’identification de courbe elliptique plus rapides et plus sûres, y compris celles qui satisfont aux exigences recommandées pour l’utilisation par le gouvernement fédéral américain et le gouvernement de Singapour.
- Liquid Mode mis à jour : l’expérience de signature en Liquid Mode a été étendue au-delà des accords pour inclure des formulaires web. Les formulaires en Liquid Mode peuvent considérablement améliorer l’expérience du signataire : il a moins de pincer-zoomer à effectuer, et il bénéficie d’une meilleure mise au point sur les champs à remplir.
De plus, le mode Liquid n'est plus limité aux serveurs nord-américains.Tous les comptes d'entreprise et professionnels ont désormais accès quel que soit l'emplacement.
- Nouveaux TSP : Cleverbase (Pays-Bas), PrimeSign (Autriche) et TrustPro (Irlande) sont les nouveaux fournisseurs de services de confiance du Cloud Signature Consortium. Ils fournissent des certificats pour appliquer des signatures numériques sécurisées répondant aux normes et aux exigences de conformité les plus élevées.
- Personnaliser les champs À et Cc dans les en-têtes d'e-mail aux destinataires - Les clients préoccupés par la fuite d'adresses e-mail via les en-têtes d'e-mail aux destinataires peuvent choisir de masquer les valeurs d'adresse e-mail dans les champs À et Cc.
- Cette option est disponible pour les comptes Grands comptes et Entreprises et peut être configurée aux niveaux du compte et du groupe.
- Les contrôles de fonctionnalité sont accessibles en accédant à Paramètres du compte > Paramètres d'e-mail > Personnaliser les champs À et Cc.
Modifications de l’expérience
- Conditions d’utilisation Adobe - Acceptation des conditions d’utilisation sur la page eSign : pour se conformer aux exigences juridiques d’Adobe, Adobe Sign met à jour le comportement d’acceptation des conditions d’utilisation sur la page eSign. Dans la nouvelle expérience, tous les destinataires « inconnus » doivent accepter les conditions d’utilisation et la politique de confidentialité d’Adobe Sign en cliquant sur le bouton Continuer avant d’interagir avec l’accord. Il s’agit d’une acceptation distincte des autres conditions d’utilisation personnalisées qui pourraient avoir été configurées pour le compte client, lesquelles continueront d’être déterminées par la configuration du compte relative à l’acceptation des conditions d’utilisation/de la divulgation des informations du client.
- Un destinataire « inconnu » est toute adresse e-mail qui n'est pas un e-mail d'utilisateur actif et enregistré dans un compte de confiance.
- Les utilisateurs « connus » ont accepté les conditions d’utilisation d’Adobe Sign lors du processus d’enregistrement quand ils ont vérifié leur compte utilisateur. Ils n’ont donc pas besoin de les accepter à nouveau.
Voici un exemple du flux de consentement implicite pour un accord avec des conditions d’utilisation personnalisées configurées par le client :
- Acceptez les conditions d’utilisation d’Adobe Sign en sélectionnant le bouton Continuer (après avoir ouvert l’accord).
- Remplissez les champs de l’accord comme requis.
- Acceptez la divulgation client et les conditions d'utilisation personnalisées en sélectionnant le bouton Cliquer pour signer .
- Verrouillage des valeurs de nom étendu aux signatures tapées : la version de mars intégrait un nouveau paramètre permettant d’activer/de désactiver la possibilité pour un destinataire de modifier la valeur de son nom lors de la signature, à condition que ce nom ait été fourni ou soit connu (via l’API ou le profil utilisateur). Cette fonctionnalité n’incluait pas les signatures tapées, ce qui permettait à certains signataires de modifier la valeur de leur nom au cours du processus de signature. Cette fonctionnalité est mise à jour dans la version de septembre afin de respecter le paramètre de verrouillage du nom pour tous les types de signature, y compris les signatures tapées.
- Les clients qui ont activé Saisir leur nom et leurs initiales et désactivé Les signataires peuvent modifier leur nom ou leurs initiales verront un changement de comportement – la valeur du nom n'est plus modifiable pendant le processus de signature pour les signatures saisies.
- Les clients qui souhaitent autoriser la modification de la valeur du nom au cours du processus de signature doivent activer le paramètre Les signataires peuvent modifier leur nom ou paraphe (dans le menu Préférences de signature).
- Les utilisateurs inactifs peuvent signer des accords : Adobe Sign traite désormais les utilisateurs inactifs comme s’ils étaient inconnus du système (afin de signer des accords liés). Lorsqu’un utilisateur inactif est invité à signer un accord, un nouvel ID utilisateur à usage unique est créé spécifiquement dans le but de signer cet accord. L’ID utilisateur à usage unique est indépendant de l’ID utilisateur inactif et du compte qui le régit. Cela a plusieurs conséquences :
- Les accords envoyés à un utilisateur inactif peuvent être signés, car l’état Inactif ne s’applique pas à l’ID utilisateur à usage unique généré pour l’accord.
- Les accords signés par l’ID utilisateur à usage unique ne sont pas des ressources de l’ID utilisateur inactif et ne résident pas dans le compte de l’ID utilisateur inactif.
- Les partages de l’ID utilisateur inactif ne reflèteront pas les accords signés par des ID utilisateur à usage unique.
- Les rapports générés pour l’ID utilisateur inactif ne reflèteront pas les accords signés par l’ID utilisateur à usage unique.
- Si l’ID utilisateur inactif est réactivé, les utilisateurs ne verront pas les enregistrements des accords signés par les ID utilisateur à usage unique sur leur page de gestion.
Il existe deux exceptions au comportement ci-dessus :
- Les accords envoyés à l’utilisateur avant qu’il ne soit marqué comme inactif peuvent ne pas être signés (l’accord était déjà lié à l’ID utilisateur inactif).
- Les utilisateurs explicitement configurés pour ne pas être autorisés à signer des accords continueront à se voir interdire toute action de signature.
Les utilisateurs inactifs ne peuvent toujours pas se connecter au système Adobe Sign ni envoyer d’accords sous leur autorité (par quelque moyen que ce soit).
- Amélioration de la sécurité pour l’accès aux formulaires web par mot de passe : les formulaires web incluent désormais un délai après plusieurs tentatives infructueuses d’accès à une URL protégée par mot de passe.
- Prise en charge du service Aadhaar International : les clients de toutes les instances d’Adobe Sign peuvent désormais utiliser le service Aadhaar en option comme fournisseur de signature numérique. Auparavant, il était uniquement mis à disposition des comptes sur l’instance IN1. Le module complémentaire Aadhaar est facturé à la transaction de signature.
- Partage limité des accords - Le partage d'accord a été plafonné lors du partage de l'accord vers une adresse e-mail externe.
- Les comptes à licences multiples peuvent partager un accord jusqu’à dix fois.
- Les comptes individuels peuvent partager un contrat jusqu'à 5 fois.
- Le partage d’un accord avec des utilisateurs internes est illimité.
- Les comptes à licences multiples peuvent partager un accord jusqu’à dix fois.
- Le nom d’entreprise personnalisé dans l’authentification par téléphone a été supprimé du service : la valeur de nom d’entreprise personnalisable qui pouvait être insérée dans la méthode d’authentification par téléphone a été supprimée du service comme annoncé dans la notification technique de juin.
- Les comptes activés HIPAA peuvent désormais accéder aux commandes des images et des liens contenus dans les e-mails des destinataires sur la page Paramètres généraux/de groupe.
Consultez les configurations associées à la réglementation HIPAA ici >
- L'ordre dans lequel les pièces jointes sont incluses dans le PDF final a été mis à jour pour trier d'abord par numéro de page, puis par position du champ ensuite (lors de la lecture de gauche à droite ; de haut en bas)
- La fonction Remplacer le destinataire de la nouvelle page Gérer permet désormais à l’expéditeur d’inclure un message facultatif pour le nouveau destinataire.
Pour plus d’informations, voir la fonction Remplacer le destinataire >
- Les signataires externes qui accèdent aux accords terminés doivent maintenant passer par un processus d’authentification (au lieu de se connecter à Adobe Sign) si l’authentification à plusieurs facteurs a été configurée pour l’accord.
- Les formulaires web signalent désormais les valeurs de champ des formulaires web non vérifiés lors de l’accès aux données de champ à l’aide de la fonction Télécharger les données de champ de formulaire de la page Gérer.
Mises à jour API
- Option Lire l’accord pour les formulaires web : deux nouveaux appels de l’API REST v6 sont disponibles pour permettre d’accéder à la consultation des formulaires web :
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} renvoie désormais le rôle de participant dans la réponse.
Problèmes résolus
| 4292343 | Amélioration de la clarté de la signature lors de l’utilisation de l’option Taper la signature sur les appareils mobiles. |
| 4295123 | Correction d’un problème bloquant l’affichage des signatures numériques lors de l’ouverture dans un navigateur. |
| 4299289 | Amélioration de l’expérience Remplacer le destinataire, permettant désormais à l’expéditeur d’inclure un message au nouveau destinataire. |
| 4299857 | Correction d’un problème qui pouvait empêcher l’accord signé d’appliquer un sceau de certification. |
| 4304261 | Correction d’un problème qui pouvait empêcher le remplissage de l’option Lire l’accord dans le menu Options. |
| 4308516 | Correction d’un problème en raison duquel les utilisateurs étaient continuellement invités à obtenir le consentement de l’administrateur lors de l’utilisation de OneDrive. |
| 4310225 | Résolution d’un problème avec les accords contenant plusieurs signatures qui risquait de déclencher une erreur du serveur. Message d’erreur : La signature appliquée à ce document n’est pas valide. Effacez-la et resignez. |
| 4310416 | Mise à jour de l’API REST v5 afin de créer des utilisateurs à l’état actif à l’aide de POST /users. |
| 4311287 | Correction d’un problème en raison duquel le bouton de navigation du groupe disparaissait sur les comptes UMG après la suppression d’un utilisateur d’un groupe. |
| 4311956 | Correction d’un problème en raison duquel la taille de police désignée pour un champ ne se reflétait pas dans l’expérience du signataire. |
| 4312302 | Correction d’un problème qui supprimait l’option Réinitialiser le mot de passe si le mode SAML était défini sur Obligatoire. |
| 4312735 | Correction d’un problème en raison duquel les notifications d’événements partagés étaient envoyées lorsque les notifications partagées étaient désactivées. |
| 4313025 | Correction d’un problème en raison duquel un rôle Chargé du remplissage des formulaires ne pouvait pas remplir des rôles non attribués lorsque l’acheminement hybride était activé. |
| 4313030 | Correction d’un problème en raison duquel les comptes UMG activés déclenchaient une erreur selon laquelle un workflow personnalisé était utilisé si le groupe principal de l’expéditeur n’était pas autorisé à effectuer l’envoi. |
| 4313264 | Mise à jour du paramètre d’activation HIPAA afin d’autoriser l’accès aux paramètres des images/liens des e-mails sur la page Paramètres généraux. |
| 4315839 | Correction d’un problème lié aux workflows personnalisés qui n’autorisaient pas le préremplissage des champs lorsque l’expéditeur était également le deuxième destinataire. |
| 4316058 | Mise à jour du comportement des champs de rapport afin de permettre l’utilisation de zéros non significatifs dans les champs de texte. |
| 4317382 | Correction d’un problème lié aux cases d’option affichant le code HTML des apostrophes dans l’info-bulle. |
| 4317978 | Mise à jour de l’ordre des pièces jointes dans le fichier PDF final, permettant de les regrouper en fonction du numéro de page du champ en premier et de la position relative du champ en second (en lisant de gauche à droite et de haut en bas). |
| 4318598 | L’appel de l’API REST v6 GET/workflows/{workflowId} renvoie désormais le rôle de participant dans la réponse. |
| 4318606 | La fonction Télécharger les données du champ de formulaire de la page Gérer renvoie désormais des valeurs de champ pour les formulaires web qui ne sont pas encore vérifiés. |
| 4318617 | Correction d’un problème en raison duquel les comptes UMG activés ne permettaient pas à un administrateur de groupe de renvoyer une invitation. |
| 4318679 | Correction d’un problème intermittent susceptible de provoquer l’échec du chargement des documents de signature écrits. |
| 4318926 | Correction d’un problème qui pouvait déclencher une erreur (Les cookies sont désactivés dans votre navigateur) lors de la génération d’un accord à partir d’un appareil mobile. |
| 4318991 | Correction d’un problème selon lequel le paramètre du nombre maximal d’échecs de connexion était ignoré si SAML était défini sur Autorisé. |
| 4319068 | Les destinataires externes doivent maintenant passer par un processus d’authentification à deux facteurs (au lieu de se connecter à Adobe Sign) pour accéder aux accords terminés lorsque l’authentification à plusieurs facteurs est configurée. |
| 4319422 | Correction d’un problème en raison duquel un destinataire pouvait être remplacé sans confirmation du mot de passe (pour un accord authentifié par mot de passe). |
| 4319455 | Correction d’un problème de partage avancé où les paramètres pouvaient ne pas être persistants après l’enregistrement. |
| 4320123 | Correction d’un problème qui pouvait déclencher une erreur lors de la tentative d’affichage et d’approbation d’un accord sur la page Gérer. |
| 4320205 | Correction d’un problème qui pouvait empêcher l’enregistrement de la progression lors du préremplissage d’un accord à l’aide du partage avancé. |
| 4320542 | Correction d’un problème pour les comptes UMG dans lesquels toutes les affiliations de groupe d’un utilisateur pouvaient être supprimées si un groupe était supprimé à l’aide de la recherche. |
| 4321357 | Correction d’un problème qui pouvait déclencher une erreur sur la page d’envoi avec authentification fondée sur les connaissances (KBA), lorsque l’option Demander un nom à l’envoi est activée. |
| 4322445 | Amélioration de la création, assurant la cohérence de la couleur d’arrière-plan. |
| 4322956 | Correction d’un problème lié aux modèles d’e-mails personnalisés en raison duquel les destinataires ne voyaient pas l’adresse électronique réelle du signataire. |
| 4323609 | En développement - Correction d’un problème en raison duquel les accords complétés par le chargement d’un document signé ne déclenchaient pas la notification du webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | Amélioration de la fonction de verrouillage de signature permettant d’inclure les signatures saisies lorsque la valeur du nom est fournie par le biais d’un profil ou d’une API. |
Adobe Sign : Octobre 2021
Fonctionnalité améliorée
- Liens Signaler un abus : les comptes PME et Indépendants et particuliers incluent désormais un lien permettant aux destinataires d’accéder à une méthode pour signaler les activités potentiellement abusives concernant les demandes d’accord entrantes.
- Intégration de Notarize : l’intégration d’Adobe Sign avec la plateforme Remote Online Notarization (RON) de Notarize, Inc permet aux clients d’ajouter un service d’authentification notariale en ligne à distance dans le cadre de leurs transactions Adobe Sign. Disponible à l’activation pour les clients américains des niveaux Grands comptes et Entreprises, ce service est vendu directement par Adobe via le programme ETLA. Les transactions d’authentification notariale peuvent être achetées sous forme de module complémentaire et moyennant un coût supplémentaire, pour ces clients uniquement.
- Mises à jour de la page Envoyer : les clients pour lesquels l’authentification notariale est activée peuvent sélectionner l’option Nécessite une authentification notariale sur l’enregistrement du destinataire, juste à droite de la méthode d’authentification :
- Mises à jour de la page Envoyer : les clients pour lesquels l’authentification notariale est activée peuvent sélectionner l’option Nécessite une authentification notariale sur l’enregistrement du destinataire, juste à droite de la méthode d’authentification :
Annotation
Les clients qui utilisent la page Envoyer intégrée dans leurs applications ou intégrations auront également accès à la fonctionnalité d’authentification notariale.
Une fois que l’accord est configuré et que l’expéditeur clique sur Suivant, ce dernier dispose d’options de configuration supplémentaires pour le processus d’authentification notariale :
- Mises à jour des API : des mises à jour importantes ont été apportées aux API afin de prendre en charge l’intégration de Notarize :
POST /agreements
L’API POST /agreements a été mise à jour pour prendre en charge l’envoi d’un accord pour authentification notariale.
- Un nouveau rôle, NOTARY_SIGNER, doit être utilisé pour les participants à une session d’authentification notariale.
- Un nouvel attribut NotaryInfo a été ajouté à la définition AgreementInfo pour contenir toutes les options associées à la création d’un nouvel accord nécessitant une authentification notariale.
|
Nom du paramètre |
Objet REST |
Description |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Tableau d’objets ParticipantInfo contenant des données spécifiques au participant (adresse électronique, par exemple). Tous les participants du tableau appartiennent au même ensemble. |
||||||||||||||||
|
role |
|
Rôle assumé par tous les participants de l’ensemble (Signer, Approver, etc.) |
Extension FileInfo
La définition FileInfo doit être développée pour indiquer les documents qui doivent être authentifiés par un notaire.
|
Nom du paramètre |
Type |
Par défaut |
Obligatoire |
Description |
|---|---|---|---|---|
|
document |
Document |
|
facultatif |
Un document qui est associé au contrat. |
|
label |
Chaîne |
|
facultatif |
Valeur d’étiquette unique d’un élément FileInfo. Dans le cas d’un workflow personnalisé, un fichier est mappé à l’élément de fichier correspondant dans la définition du workflow. |
|
libraryDocumentId |
Chaîne |
|
facultatif |
ID d’un document de bibliothèque existant qui sera ajouté à l’accord |
|
transientDocumentId |
Chaîne |
|
facultatif |
ID d’un document temporaire qui sera ajouté à l’accord |
|
notarize |
true |
false |
facultatif |
Indique que ce document doit être authentifié par un notaire |
Extension ParticipantInfo
La définition ParticipantInfo a été étendue pour pouvoir spécifier la méthode d’authentification notariale.
|
Nom du paramètre |
Type |
Par défaut |
Obligatoire |
Description |
|---|---|---|---|---|
|
|
Chaîne |
s.o. |
obligatoire |
Adresse électronique du participant |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
facultatif |
MULTI_FACTOR_AUTHENTICATION : l’authentification notariale est effectuée à l’aide d’une méthode d’authentification à deux facteurs |
NotaryInfo
Un nouveau champ notaryInfo facultatif a été ajouté à la définition AgreementInfo pour contenir l’objet NotaryInfo qui spécifie des options supplémentaires associées à l’authentification notariale.
|
Nom du paramètre |
Type |
Par défaut |
Obligatoire |
Description |
|---|---|---|---|---|
|
notaryType |
Enum |
Si seul le Service d’authentification notariale à la demande Notarize est activé sur le compte, |
obligatoire |
NOTARIZE_NOTARY : le service Notarize fournit le notaire |
|
payment |
Enum |
BY_SENDER |
facultatif |
S’applique uniquement si le type == NOTARIZE_NOTARY |
|
appointmentStart |
Chaîne |
"" |
facultatif |
Chaîne au format ISO_DATE_TIME Voir ISO_ZONED_DATE_TIME |
|
note |
Chaîne |
S/O |
facultatif |
Notes pour la séance d’authentification notariale |
|
notaryEmail |
Chaîne |
"" |
facultatif |
Adresse électronique de votre propre notaire |
Exemple /agreement
PUT|GET /agreements/{aid}
L’API PUT /agreements/{aid} prend en charge la mise à jour d’un accord avec des options d’authentification notariale. L’API GET /agreements/{aid} renvoie toutes les options définies pour l’authentification notariale de l’accord. Voir la section POST /agreements pour afficher les attributs mis à jour.
Codes d’erreur
Les codes d’erreur existants pour POST /agreements restent inchangés. Nous avons défini un nouveau code d’erreur comme indiqué ci-dessous :
|
Code d’erreur REST |
Code d’état HTTP |
Message |
Scénario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
Le paramètre utilisateur ou le jeton de portée OAuth n’autorisent pas l’envoi de l’accord pour l’authentification notariale. |
Cette erreur est renvoyée lorsque le rôle est défini sur NOTARY_SIGNER et que l’appelant d’API (c’est-à-dire l’expéditeur potentiel) n’a pas activé la fonctionnalité d’authentification notariale et/ou si le fournisseur de l’authentification notariale n’est pas défini. |
Impact sur la documentation
Dans l’objet AgreementInfo de la requête, l’élément « status » inclut le nouveau statut de l’accord WAITING_FOR_NOTARIZATION.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
L’API peut être utilisée par les clients (signataires de l’authentification notariale) pour obtenir un jeton de signature qui leur permet de terminer la phase de signature électronique du flux.
- Une nouvelle fonctionnalité de signature a été ajoutée pour capturer le nouveau rôle : ACCEPT_BEFORE_NOTARIZATION.
- Les jetons de signature ne doivent pas être obtenus pour terminer la phase d’authentification notariale.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
L’API peut être utilisée par les clients (signataires authentifiés) pour terminer la phase de signature électronique du flux. Pour s’adapter au nouveau rôle, une nouvelle valeur de statut d’énumération a été introduite : ACCEPTED_BEFORE_NOTARIZATION.
|
Attribut |
Type |
Description |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
État |
Enum<String>
|
|
||||||||||||||
Le notaire signataire peut suivre la séquence d’appels API ci-dessous pour terminer la phase de signature électronique :
- GET /agreements/{agreementId}/Members : pour récupérer l’ID de participant et l’ID de l’ensemble de participants du notaire signataire
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens : pour demander un jeton de signature pour le notaire signataire avec la fonctionnalité ACCEPT_BEFORE_NOTARIZATION
- POST /transientDocuments : pour charger un document révisé
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status : pour soumettre un document révisé et terminer la phase de signature électronique
Nouvel événement webhook
Les clients peuvent s’abonner à un nouvel événement webhook, AGREEMENT_READY_FOR_NOTARIZATION, pour être informés lorsque l’accord est prêt pour l’authentification notariale. L’événement n’est pas visible sur l’interface utilisateur de webhooks et on peut s’y abonner via un appel API POST /webhooks.
Impact sur la documentation
Les API suivantes ne sont pas modifiées mais leur documentation a été mise à jour pour inclure le nouveau statut de l’accord « WAITING_FOR_NOTARIZATION » ou le nouveau rôle « NOTARY_SIGNER ».
GET /agreements
En réponse à l’objet UserAgreements/UserAgreement, l’élément « status » inclut désormais le statut correspondant « WAITING_FOR_NOTARIZATION ».
GET /agreements/{agreementId}
En réponse à l’objet AgreementInfo, l’élément « status » inclut désormais le statut correspondant « WAITING_FOR_NOTARIZATION ».
GET /agreements/{agreementId}/events
L’API est mise à jour pour prendre en charge les nouveaux événements READY_TO_NOTARIZE et NOTARIZED.
En réponse à l’objet Event
- L’élément « participantRole » inclut désormais un nouveau rôle NOTARY_SIGNER.
- L’élément « type » inclut les nouveaux événements READY_TO_NOTARIZE et NOTARIZED. L’élément « description » sera « Document sent for notarization » et « Notarized document received », respectivement.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
En réponse à l’objet DetailedParticipantSetInfo, l’élément « status » inclut désormais le statut correspondant « WAITING_FOR_NOTARIZATION ».
PUT /agreements/{agreementId}
L’objet AgreementInfo de la requête inclut désormais le statut « WAITING_FOR_NOTARIZATION ».
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
Le statut WAITING_FOR_NOTARIZATION est l’une des valeurs de l’élément « status » de l’objet DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
L’état WAITING_FOR_NOTARIZATION a été ajouté en tant que l’une des vues autorisées.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Si le participant spécifié dans le chemin de la requête a un rôle de notaire signataire, l’API renvoie la configuration de signature ACCEPT_BEFORE_NOTARIZATION, en ligne avec toutes les autres configurations de signature pour cet accord/ce participant.
Problèmes résolus
| Problème | Description |
| 4308901 | Correction d’un problème en raison duquel la délégation d’un accord avec authentification par téléphone entraînait une erreur si le numéro de téléphone délégué avait le même code de pays. |
| 4314113 | Correction d’un problème en raison duquel les dates d’expiration par défaut ne pouvaient pas être modifiées par les utilisateurs lors de l’envoi d’un nouvel accord. |
| 4318558 | Correction d’un problème en raison duquel le remplacement d’un destinataire avec authentification téléphonique provoquait l’erreur « L’ID spécifié pour l’ensemble de participants n’est pas valide ». |
| 4319038 | Correction d’un problème en raison duquel l’expéditeur n’obtenait pas l’option pour la vérification de l’identité des destinataires externes lors de l’envoi par le workflow « Envoi en masse ». |
| 4319798 | Correction d’un problème en raison duquel la sélection d’une case d’option pouvait faire basculer le curseur sur un autre champ. |
| 4320154 | Correction d’un problème qui pouvait empêcher l’enregistrement d’un modèle de bibliothèque dans une nouvelle relation de groupe. |
| 4323013 | Correction d’un problème en raison duquel l’ouverture d’un formulaire web sur la page Gérer déclenchait une erreur : « Le document n’est pas encore disponible ou il ne contient aucune page à afficher ». |
| 4323554 | Correction d’un problème en raison duquel les horodatages d’événement (date/heure) pour la mise à jour des droits d’administration pouvaient produire deux enregistrements avec les mêmes valeurs temporelles. |
| 4323609 | Correction d’un problème en raison duquel le chargement d’un accord signé dans la page Gérer ne déclenchait pas le webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | Correction d’un problème en raison duquel les modèles d’e-mail personnalisés ne reflétaient pas la valeur de nom correcte pour un participant s’il annulait l’accord. |
| 4326747 | Correction d’un problème en raison duquel la page Envoyer en masse ne terminait pas le processus de chargement, omettant les actions Télécharger et Envoyer. |
| 4326855 | Correction d’un problème qui pouvait empêcher les destinataires de refuser l’approbation d’un accord. |
| 4327000 | Correction d’un problème susceptible d’entraîner l’échec d’authentification avec des informations d’identification Smart-Id, l’erreur indiquant qu’aucun algorithme n’avait été trouvé. |
