Notes de mise à jour d'Adobe Acrobat Sign : 2025
Déploiement en production : mercredi 11 février 2025
Déploiement sur GovCloud : mercredi 18 février 2025
Fonctionnalité améliorée
- Amélioration de l’interface utilisateur pour les workflows d’envoi personnalisés : le Concepteur de workflows personnalisés a été mis à jour pour offrir à l’expéditeur une meilleure expérience, alignée sur l’aspect de l’outil Demander une signature.
Environnements disponibles : Sandbox, Commercial, Gouvernement | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Groupe, Compte
Modifications de l’expérience
- L’expiration d’un accord peut être retardée jusqu’à 12 heures : à partir de cette version, l’expiration automatique d’un accord se produira en dehors des heures de pointe pour l’environnement qui gère l’accord. En pratique, tout accord qui expire pendant les périodes de trafic de pointe d’un environnement Acrobat Sign donné sera mis en attente pour être exécuté une fois que l’environnement se trouvera en dehors des heures de pointe.
- Workday : prise en charge de la signature numérique pour le fournisseur d'identité Aadhaar - Les clients utilisant l'intégration Workday peuvent désormais utiliser le fournisseur d'identité Aadhaar comme méthode pour authentifier leurs destinataires.
Mises à jour API/Webhook REST
Les mises à jour d’API et de webhook pour cette version sont disponibles dans la documentation de l’API Acrobat Sign.
- Un nouvel attribut ID de compte est ajouté à toutes les payloads de notification d’événement.
- Les partenaires OEM Embed 2.0 pourront désormais configurer un webhook pour leur canal et écouter toutes les notifications d’actif de chacun de leurs comptes clients individuels.
- API des nouveaux paramètres
- POST /accounts/{accountId|me}/settings/search : prend le compte identifié (accountId) ainsi qu’une liste de noms de paramètres et renvoie la liste des noms de paramètres avec leurs valeurs pour le compte spécifié. Seules les valeurs au niveau du compte sont renvoyées.
- Disponible pour les utilisateurs non-administrateurs.
- PUT /accounts/{accountId|me}/settings : applique une liste fournie de noms de paramètres et leurs valeurs au compte identifié (accountId).
- POST /accounts/{accountId|me}/settings/search : prend le compte identifié (accountId) ainsi qu’une liste de noms de paramètres et renvoie la liste des noms de paramètres avec leurs valeurs pour le compte spécifié. Seules les valeurs au niveau du compte sont renvoyées.
- API des nouveaux logos
- POST /accounts/{accountId|me}/logo : charge le fichier CoBrandingLogo.
- GET /accounts/{accountId|me}/logo : renvoie les données d’image du fichier d’image CoBrandingLogo au même format que celui dans lequel il a été chargé.
- Disponible pour les utilisateurs non-administrateurs.
- DELETE /accounts/{accountId|me}/logo : efface l’image CoBrandingLogo du compte.
- API des motifs de signature
- GET /accounts/{accountId|me}/signingReasons : renvoie une liste des motifs de signature pour le compte identifié (accountId).
- Disponible pour les utilisateurs non-administrateurs.
- POST /accounts/{accountId|me}/signingReasons : crée un motif de signature pour le compte identifié (accountId).
- GET /accounts/{accountId|me}/signingReasons/{signingReasonId} : récupère le texte du motif de signature identifié (signingReasonId) à partir du compte identifié (accountId). Motif de signature identifié du compte.
- Disponible pour les utilisateurs non-administrateurs.
- PUT /accounts/{accountId|me}/signingReasons/{signingReasonId} : met à jour le motif de signature identifié (signingReasonId) à partir du compte identifié (accountId).
- DELETE /accounts/{accountId|me}/signingReasons/{signingReasonId} : supprime le motif de signature identifié (signingReasonId) du compte identifié (accountId).
- GET /accounts/{accountId|me}/signingReasons : renvoie une liste des motifs de signature pour le compte identifié (accountId).
- Mise à jour des pages Swagger pour désigner me comme abréviation pour l’accountId.
Problèmes résolus
| Problème | Description |
|---|---|
| 4479949 | Résumé : les appels API OIDC à un fournisseur d’identités contiennent le paramètre « charset=UTF-8 » dans l’en-tête « Content-type:application/x-www-form-urlencoded ». Cela génère une erreur au lieu d’une réponse valide. |
| Correction : le jeu de caractères a été supprimé, car aucun jeu de caractères ne doit être spécifié. | |
| 4490523 | Résumé : aucun bouton permettant d’imprimer le fichier PDF n’est disponible dans la vue Lire l’accord. |
| Correction : un bouton Imprimer a été ajouté à la vue Lire l’accord. | |
| 4494248 | Résumé : délais d’expiration de l’accord incorrects, car le client ne transmet pas les informations de fuseau horaire. |
| Correction : le client a été mis à jour pour prendre en compte les fuseaux horaires. | |
| 4494297 | Résumé : lorsqu’un utilisateur délègue un accord au nom d’un autre utilisateur (à l’aide du partage de compte avancé), le rapport d’audit peut ne pas afficher l’événement de délégation en fonction des paramètres configurés qui omettent ou incluent des données. |
| Correction : la fonction qui omet des données a été améliorée pour prendre en compte les cas où des événements suppriment un contenu tout en conservant l’événement. | |
| 4495537 | Résumé : lorsque des modèles d’e-mail personnalisés sont utilisés et qu’un accord est envoyé via un workflow, puis annulé sans demande de notification de toutes les parties, les destinataires reçoivent des e-mails d’annulation en tant que participants en copie. |
| Correction : le CSS des modèles CEMT a été mis à jour pour gérer les scénarios d’annulation comme le font les modèles non personnalisés. | |
| 4495963 | Résumé : si la délégation est interdite pour les utilisateurs du compte, les options permettant d’activer la signature ou le cachet électronique pour un profil utilisateur sont verrouillées. |
| Correction : la dépendance de la délégation est supprimée dans l’interface utilisateur et le paramètre peut être mis à jour. | |
| 4496084/4510358 | Résumé : un mauvais bouton radio sélectionné est défini à la place de celui attendu lors de l’utilisation d’une liste d’options. |
| Correction : nous obtenons désormais l’index du bouton radio sélectionné à partir de la liste d’options lorsque celle-ci est présente dans un bouton radio. | |
| 4497823 | Résumé : le message utilisateur (« ID d’accord non valide ») s’affiche pour une session d’utilisateur non participant dans le navigateur pour GET/SigningUrls pour un accord valide. |
| Correction : reformulation de la notification utilisateur (« ID d’accord non valide ») en un message plus significatif. | |
| 4498914/4501065 | Résumé : les utilisateurs ne peuvent pas signer le document lorsque le type d’authentification est Acrobat Sign avec les paramètres bio-pharma activés en raison d’un délimiteur incorrect. |
| Correction : le délimiteur utilisé a été corrigé. | |
| 4499847 | Résumé : les paramètres numériques ne respectent pas les paramètres de l’interface utilisateur, indiquant un nombre de fournisseurs supérieur à celui sélectionné en raison d’entrées en double dans la liste des fournisseurs. |
| Correction : un code de nettoyage a été ajouté pour s’assurer que les doublons sont nettoyés avant de récupérer la valeur du paramètre et avant de la mettre à jour. | |
| 4500637 | Résumé : les données de création d’un fichier PDF sont représentées par une valeur longue, correspondant à une date en millisecondes, au lieu d’utiliser le format de chaîne de date PDF. |
| Correction : si la date de création est représentée par un code CosNumeric, convertissez-la en ASDate en obtenant le code CosNumeric comme chaîne, puis en la convertissant en date longue, puis en objet Date. | |
| 4500649 | Résumé : l’ajustement automatique de la taille de police ne fonctionne pas en raison d’un bug dans une bibliothèque en amont. |
| Correction : la bibliothèque a été mise à jour. | |
| 4501939 | Résumé : une « Erreur inattendue » ou une « Erreur d’autorisation » s’affiche lorsque le signataire effectue un paiement via Braintree en raison d’une configuration AVS non prise en charge. |
| Correction : du code a été ajouté pour ignorer AVS lorsque cela est possible. Les clients sont avertis que la configuration AVS est incompatible avec Acrobat Sign. | |
| 4502497 | Résumé : par défaut, le champ de paraphe n’est pas défini sur Obligatoire dans la nouvelle mise en page de création. |
| Correction : l’option par défaut a été modifiée pour être Obligatoire. | |
| 4502759 | Résumé : les dénominations japonaises apparaissent en doublon pour les signataires dans le rapport d’audit. |
| Correction : nous utilisons désormais la chaîne de liste utilisateur dans tous les cas dans createSignatureRequestedAuditEvent(). Cette mesure s’accompagne d’une modification de chaîne dans laquelle les dénominations sont supprimées de toutes les chaînes d’événement d’audit utilisées dans la fonction. | |
| 4503010 | Résumé : l’action GET/agreements/ID échoue avec l’erreur serveur 500 pour certains accords après le 17 septembre en raison d’une vérification d’origine. |
| Correction : la vérification d’origine a été supprimée. | |
| 4503107 | Résumé : lorsqu’un destinataire de partage avec les autorisations ENVOYER et SIGNER bascule sur le compte de la personne qui partage et lance un workflow dans lequel le destinataire de partage est le premier signataire, l’utilisateur est redirigé vers la page POST SIGNATURE au lieu de la page de SIGNATURE ÉLECTRONIQUE. |
| Correction : la vérification en place a été mise à jour pour s’assurer que le destinataire de partage dispose d’autorisations SIGNER pour le groupe à partir duquel l’accord a été envoyé. | |
| 4503112 | Résumé : annulation automatique de l’accord - l’erreur AUTO_AUTHOR_FAIL se déclenche en raison d’une erreur iText. |
| Correction : iText a été supprimé là où la fonction n’était pas obligatoire, ce qui a corrigé l’erreur. | |
| 4503640 | Résumé : la personne chargée de remplir le formulaire ne peut pas envoyer le document. Une erreur de serveur s’affiche lorsque l’utilisateur clique sur « Envoyer » dans les documents XFA. |
| Correction : la bibliothèque qui évalue les fichiers PDF pour XFA a été améliorée pour identifier et supprimer correctement XFA. | |
| 4504309 | Résumé : impossible d’envoyer des accords du dossier Brouillon via le Partage de compte avancé en raison d’un point d’entrée manquant dans le filtre. |
| Correction : ajout de l’URL /account/requestSignatures/authoring à allowListedEndPointsBasedOnSendPermissions dans filter.xml | |
| 4504567 | Résumé : les valeurs des boutons de radio sont modifiées lorsque les accords sont générés via l’envoi en masse. |
| Correction : remplacement de la table de hachage par une table de hachage liée pour conserver l’ordre d’insertion lors de la création d’accords enfants SiB. | |
| 4504631 | Résumé : message d’erreur du workflow de traitement : Erreur non gérée en raison de caractères non pris en charge dans un fichier iText. |
| Correction : iText a été mis à jour. | |
| 4504822 | Résumé : la recherche d’utilisateur est effacée si la liste d’utilisateurs prend trop de place et qu’une recherche est demandée avant que la recherche précédente ne soit terminée (par exemple, le chargement initial des utilisateurs lorsque la page est ouverte). |
| Correction : lors de la réception de données, nous vérifions si l’ID de demande correspond à la demande la plus récente. Si c’est le cas, nous traitons la réponse ; si ce n’est pas le cas, nous l’ignorons. | |
| 4504831/4507199 | Résumé : l’accord signé génère un fichier PDF non valide d’une taille 1 Ko en raison d’un objet PDFFont mal formé qui ne spécifie pas le sous-type obligatoire de l’objet de police. |
| Correction : la bibliothèque de génération de PDF a été mise à jour pour mieux gérer les objets mal formés et fournir un résultat plus correct. | |
| 4506230 | Résumé : le processus de reconnaissance automatique des champs ne fonctionne pas dans l’environnement Sandbox en raison d’une annotation incorrecte ou inexistante là où nous la recherchons. |
| Correction : nous parcourons chaque page et chaque annotation de cette page afin de rechercher l’annotation du champ de formulaire pour nous assurer que nous obtenons la page correcte. | |
| 4506959 | Résumé : la page d’entrée post-signature affiche des caractères codés HTML. |
| Correction : modèle source corrigé. | |
| 4508950 | Résumé : les champs dont le nom contient une apostrophe créent une erreur dans la nouvelle expérience. |
| Correction : le code d’analyse du champ a été amélioré pour gérer les apostrophes. | |
| 4509503 | Résumé : les utilisateurs ne peuvent pas signer des documents via l’application Acrobat Sign pour iOS en raison d’une zone de données vide et d’une exception de pointeur NULL. |
| Correction : une vérification du pointeur NULL a été ajoutée pour gérer correctement ce cas de figure. | |
| 4509713 | Résumé : le paramètre « Autoriser tous les utilisateurs à partager des documents de la bibliothèque avec plusieurs groupes » est activé automatiquement lors de la tentative d’activation de l’option « Autoriser l’administrateur à partager des documents de la bibliothèque avec plusieurs groupes » dans les paramètres généraux en raison de la transmission d’une valeur incorrecte. |
| Correction : la valeur correcte est maintenant utilisée. | |
| 4510812 | Résumé : l’authentification Aadhaar dans Workday empêche les signatures. |
| Correction : la prise en charge de l’authentification Aadhaar a été ajoutée à Workday. | |
| 4512044 | Résumé : la signature électronique moderne génère une erreur si le nom du champ comporte un caractère spécial. |
| Correction : l’analyse des noms de champ a été améliorée pour gérer correctement les caractères spéciaux dans les noms de champ. | |
| 4516231 | Résumé : le libellé du rapport d’audit concernant le lien de signature « Signature électronique hébergée par (nom de l’expéditeur) » est considéré comme trop vague. |
| Correction : la chaîne du rapport d’audit a été mise à jour pour afficher « Le lien de signature est créé par (nom de l’expéditeur) ». |
Déploiement en production : 17 mars 2025
Déploiement sur GovCloud : 20 mars 2025
Modifications de l’expérience
- Nouvel environnement de signature électronique pour les partenaires OEM - Le nouvel environnement de signature électronique a été activé pour les partenaires OEM Acrobat Sign. Cet environnement offre un environnement de signature supérieur pour les destinataires et inclut l'option de définir un calque de champ vers lequel les clients mobiles peuvent basculer, améliorant considérablement le processus de remplissage des champs.
Problèmes résolus
| Problème | Description |
|---|---|
| 4501733 | Résumé : la définition d’une valeur d’affichage d’adresse e-mail personnalisée pour un groupe ne s’applique pas aux e-mails de rappel et d’annulation. |
| Correction : les modèles d’e-mail de rappel et d’annulation ont été mis à jour pour refléter correctement la valeur d’affichage d’adresse e-mail. | |
| 4502251 | Résumé : l’authentification Acrobat Sign échoue lorsque la norme HIPAA est activée pour le compte d’envoi et que l’expéditeur et le destinataire disposent d’ID utilisateur sur différents shards Acrobat Sign, ce qui entraîne une erreur de jeton d’accès non valide. |
| Correction : la méthode d’authentification Acrobat Sign a été améliorée pour gérer correctement les destinataires ayant des ID utilisateur sur différents shards. | |
| 4504338 | Résumé : une erreur non traitée est déclenchée lorsque la première personne signe un accord, mais que le deuxième destinataire est délégué deux fois. |
| Correction : le code de délégation a été réajusté pour garantir que l’autorité appropriée à l’accord est transmise lors de la délégation de chaîne. | |
| 4504648 | Résumé : les cases à cocher ajoutées via l’API et activées par défaut peuvent conserver leur statut « coché » sur l’accord final, même si elles sont décochées pendant le processus de signature. |
| Correction : l’héritage de la valeur de la case à cocher a été mis à jour pour veiller à ce que les nouvelles valeurs après l’opération d’un destinataire soient correctement stockées et reflétées dans le PDF résultant. | |
| 4506085 | Résumé : erreur lors de la copie de modèles volumineux du sandbox vers la production. Modèle créé sans champs en raison de dépassements de délais dans le processus. |
| Correction : le seuil de temps a été étendu pour les actions de synchronisation. | |
| 4507500 | Résumé : les utilisateurs d’Acrobat (DC Web) ne peuvent pas charger de pièces jointes lors de l’application d’une signature en raison d’un chemin manquant dans la fonction de chargement. |
| Correction : le chemin permettant aux utilisateurs Acrobat d’accéder à la fonctionnalité de chargement a été inclus. | |
| 4508102 | Résumé : le processus de suppression de pages d’un document d’accord combiné peut échouer, car un service interne peut générer une exception lors de la suppression d’objets liés à la page tels que les signets, la structure, les destinations, ce qui entraîne l’échec de l’ensemble de l’opération de suppression d’une page d’un PDF. |
| Correction : le service interne a été amélioré pour mieux gérer les signets, ainsi que pour formater correctement les PDF à la norme attendue d’Acrobat Sign. | |
| 4508673 | Résumé : lorsqu’un motif de signature est requis et qu’un champ de signature est attribué à un rôle non signataire (par exemple, Approbateur), si la signature électronique moderne est activée, l’utilisateur est redirigé vers la page de signature électronique moderne et n’a pas la possibilité de saisir le motif de signature. |
| Correction : une vérification a été ajoutée pour une demande de motifs de signature, et si elle est présente, le destinataire est redirigé par défaut vers la page de signature électronique classique. | |
| 4508674 | Résumé : les accords signés avec des destinations mal formatées ne peuvent pas être téléchargés. |
| Correction : la bibliothèque interne a été corrigée pour mieux gérer les signets et destinations mal formatés. | |
| 4508934 | Résumé : dans l’intégration Salesforce, le nom du fichier est coupé après « . » dans la notification par e-mail du PDF signé. |
| Correction : la fonction de découpe de chaîne a été améliorée pour identifier les chaînes après un point qui ne sont pas des extensions. | |
| 4509274 | Résumé : dans l’environnement MS Teams, si l’expéditeur est le premier (ou le seul) signataire, l’accord n’est pas ouvert dans un nouvel onglet après l’envoi en raison d’une valeur vide transmise dans la redirection de l’API. |
| Correction : la redirection de l’API a été améliorée en transmettant les valeurs correctes lors du déclenchement du processus de signature et lors de l’ouverture du nouvel onglet. | |
| 4509485 | Résumé : la suppression de pages d’un document d’accord combiné peut échouer, car un service interne peut générer une exception lors de la suppression d’objets liés à la page tels que les signets, la structure et les destinations, ce qui entraîne l’échec de l’ensemble de l’opération. Les utilisateurs peuvent ne pas pouvoir télécharger leur accord au format PDF avec le message d’erreur suivant : « Le document n’est pas encore disponible ou il ne contient aucune page à afficher ». |
| Correction : le service interne a été mis à jour pour habiller le processus de suppression dans les tests afin de mieux gérer les PDF mal formés. | |
| 4509562 | Résumé : les accords volumineux peuvent présenter un problème en raison duquel seules les premières pages de l’accord peuvent être imprimées au format PDF lors de l’ouverture de l’accord sur la page Gérer dû à une ancienne offre groupée SDK. |
| Correction : l’offre groupée SDK a été mise à jour, ce qui résout le problème. | |
| 4509684 | Résumé : lors de l’appel de GET /agreements/{agreementId}/documents/{documentId}) à partir de l’API REST, l’erreur suivante est déclenchée : « Le serveur ne peut pas envoyer la réponse dans un format demandé dans l’en-tête Accept » en raison d’un type de contenu incorrect. |
| Correction : la valeur du type de contenu a été corrigée. | |
| 4509712 | Résumé : seulement 100 groupes s’affichent lors de la tentative de partage de modèles avec plusieurs groupes. |
| Correction : le nombre de groupes extraits de l’API est passé à 1 000. | |
| 4509989 | Résumé : si un champ Nom s’affiche en regard du champ Signature sur la page de signature électronique du formulaire web, après avoir appliqué la signature, le champ Nom ne comporte pas le nom du signataire et il n’est pas visible. |
| Correction : une fonction supplémentaire a été ajoutée pour vérifier la valeur du nom dans le champ Nom et la comparer à la valeur existante. Si elle a changé, le champ est renseigné avec la nouvelle valeur. | |
| 4510498 | Résumé : la suppression des notifications par e-mail envoyées aux destinataires échoue pour les accords avec signature manuscrite en raison de l’absence de paramètres configurables pour les contrôler. |
| Correction : un nouveau paramètre a été ajouté pour gérer explicitement ce type de distribution par e-mail. | |
| 4511386 | Résumé : lorsqu’un signataire disposant d’une signature numérique sélectionne l’option de téléchargement et de signature, le compteur de participation augmente avant que la signature ne soit appliquée. |
| Correction : la logique qui met à jour le système a été améliorée pour mieux refléter le statut actuel de l’accord. | |
| 4511390 | Résumé : les administrateurs de groupe ne sont pas autorisés à établir entièrement un partage avec leurs utilisateurs de groupe. |
| Correction : la fonction de partage pour les administrateurs de groupe a été mise à jour pour corriger le problème. | |
| 4511902 | Résumé : la balise de date personnalisée ne fonctionne pas avec la nouvelle expérience lorsque le format d’affichage inclut des annotations de devis (en raison de l’encodage). |
| Correction : Acrobat décode désormais la valeur avant de l’enregistrer. | |
| 4517094 | Résumé : le lien vers les conditions d’utilisation ne fonctionne pas en raison du déplacement de la page vers une nouvelle URL source. |
| Correction : le code a été mis à jour pour récupérer correctement l’URL actuelle. |
Déploiement en production : 22 avril 2025
Déploiement sur GovCloud : 24 avril 2025
Fonctionnalité améliorée
- Envoi en masse : Téléchargement en masse : les expéditeurs peuvent désormais télécharger tous les accords enfants terminés à partir d’une transaction Envoi en masse directement via la page Gérer. Le fichier ZIP inclut uniquement les accords terminés, nommés en fonction de leur ID de transaction ; les accords en cours, annulés, refusés ou expirés sont exclus.
Chaque demande de téléchargement prend en charge jusqu'à 100 Mo de données, offrant un moyen rapide et efficace d'accéder aux documents finalisés en une seule étape.
- Expérience de signature mobile améliorée : les expéditeurs peuvent désormais activer et configurer une expérience de signature mobile optimisée, afin de fournir aux destinataires deux options d’affichage :
- Affichage PDF : affiche l’ensemble de l’accord pour consultation et signature.
- Affichage de champs uniquement : met l’accent sur les champs de formulaire, ce qui facilite le remplissage et la signature d’accords sur des appareils mobiles.
Cette mise à jour simplifie le processus de signature de façon à améliorer les taux d’achèvement des formulaires et l’expérience mobile globale.
- Parties en copie pour les destinataires individuels dans le concepteur de workflows personnalisés : le concepteur de workflows personnalisés permet désormais à chaque destinataire de mettre en copie des parties dédiées. Lorsque cette option est activée, les parties en copie reçoivent les notifications en même temps que le destinataire prévu de façon à optimiser la visibilité et à simplifier la communication. Cette fonctionnalité est disponible si le compte est configuré pour l'autoriser.
- Champs Case à cocher et Bouton d’option : option Afficher la bordure du champ : les champs Case à cocher et Bouton d’option incluent désormais une option permettant d’afficher la bordure du champ lors de la consultation et de l’impression de l’accord. Cette option peut être désactivée lorsque le document chargé contient déjà des bordures préimprimées, ce qui garantit un document final plus propre en empêchant les doubles bordures.
L'option est activée par défaut et configurée au niveau du champ.
- Amélioration de la détection automatique des champs de formulaire : la fonctionnalité de détection automatique des champs de formulaire place désormais automatiquement les champs détectés, ce qui simplifie le processus de création de formulaires. Les utilisateurs conservent un contrôle total et peuvent modifier, supprimer ou retirer tous les champs placés en une seule action.
- Nouvelle option pour définir le type de signature du destinataire : les expéditeurs peuvent désormais définir le type de signature des destinataires lors de l’envoi d’accords via le processus Demander une signature moderne. Lorsque cette option est activée, une liste déroulante Type de signature s’affiche dans la section Paramètres du destinataire de la page Composer, indiquant les options autorisées par les paramètres de groupe.
- Il est possible de configurer les paramètres par défaut au niveau du groupe.
- Si l’expéditeur sélectionne un type de signature, le destinataire doit l’utiliser.
- L’expéditeur peut sélectionner plusieurs options pour le destinataire.
- Le destinataire peut choisir son type de signature de choix si aucune sélection n’est effectuée.
Cette fonctionnalité offre un contrôle accru sur les méthodes de signature tout en maintenant la flexibilité lorsque nécessaire.
- Amélioration de la gestion des utilisateurs dans Acrobat Sign : la vue d’administration des utilisateurs d’Acrobat Sign a été mise à jour pour améliorer la visibilité sur le statut des utilisateurs. L’interface améliorée facilite l’accès aux invitations en attente et fournit des indicateurs clairs pour identifier les problèmes de configuration. La nouvelle interface met également en évidence les principales actions que les administrateurs peuvent effectuer pour chacune des catégories de statut (Ajouter un utilisateur, Envoyer un rappel et Contacter l’assistance) afin de simplifier le processus de configuration des utilisateurs.
- Amélioration de la sécurité des données des destinataires en configurant des destinataires avec accès restreint : la fonctionnalité Accès restreint aux accords renforce la confidentialité en empêchant les utilisateurs d’associer des accords à l’ID utilisateur Acrobat Sign d’un destinataire (s’il en possède un). Lorsque l’option Accès restreint aux accords est activée, elle est disponible dans la section Paramètres du destinataire de la page Composer. Les administrateurs peuvent configurer ce paramètre pour l’activer par défaut et faire en sorte que les expéditeurs puissent le modifier.
Lorsqu’un destinataire est marqué comme restreint, il est traité comme s’il ne disposait pas d’un compte d’utilisateur Acrobat Sign actif. Par conséquent, l’accord ne figure pas sur sa page Gérer. Cela empêche les fuites accidentelles de données dues aux relations de partage au niveau du groupe.
- Envoi de mots de passe à usage unique via WhatsApp : Acrobat Sign prend désormais en charge WhatsApp pour envoyer les mots de passe à usage unique aux destinataires. Cette fonctionnalité est similaire à l’envoi par SMS, mais elle utilise la technologie et l’infrastructure de WhatsApp pour offrir une stabilité supplémentaire et une option de communication pratique. L'authentification OTP WhatsApp est un type d'authentification Premium disponible lors de la composition de nouveaux contrats.
- Examen de la configuration des destinataires à partir de la page de création : les expéditeurs qui utilisent la nouvelle expérience Demander une signature peuvent désormais revenir à la page Composer à partir de l’environnement de création pour reconfigurer les destinataires et leurs propriétés sans perdre leur travail. Ils peuvent ainsi modifier l’ordre et les détails des destinataires tout en préservant les affectations de champs existantes (par exemple, le signataire 1 reste le signataire 1). (Si un participant est supprimé, ses champs associés seront également supprimés.)
- Nouvel environnement de création pour les modèles de bibliothèque : l’environnement de création de modèles de bibliothèque offre désormais une expérience de création moderne pour le placement des champs, afin de faciliter la création et la personnalisation des modèles. Les améliorations sont les suivantes :
Ces mises à jour rationalisent la création de modèles et garantissent une expérience fluide pour les expéditeurs et les destinataires.
- Ajout de nouveaux fournisseurs d’identité (IdP) à Acrobat Sign : Acrobat Sign étend sa liste de fournisseurs d’identité (IdP) pris en charge pour améliorer les options d’authentification des destinataires. Les nouveaux fournisseurs d’identité suivants sont désormais disponibles :
- OneID ID Check
- OneID ID Proof
- OneID ID Assure
- OneID Sign-Up Plus
Ces ajouts étendent la compatibilité d'Acrobat Sign avec les normes mondiales de vérification d'identité, prenant en charge une authentification fluide et sécurisée dans plusieurs secteurs.
- Nouveaux pays pris en charge pour l’authentification par téléphone : l’authentification par téléphone et l’envoi d’accords par SMS prennent désormais en charge ces pays et codes téléphoniques supplémentaires :
- Île de Man (+44)
- Guernesey (+44)
- Jersey (+44)
Modifications de l’expérience
- L’environnement Demander une signature moderne est devenue l’expérience par défaut lors de la création d’un nouvel accord. Tous les comptes existants ont été basculés vers l’environnement moderne.
- Les utilisateurs ne peuvent plus accéder aux liens pour basculer entre les environnements nouveau et classique.
- Les administrateurs auront toujours la possibilité d’activer l’expérience classique via le menu d’administration.
- Les clients qui utilisent l’intégration Authentifier ne seront pas concernés par cette modification.
- Les administrateurs système d’un compte VIP dans Admin Console reçoivent automatiquement un droit d’accès à Acrobat Sign : lorsqu’un compte acquiert initialement le service Acrobat Sign sous licence VIP, les utilisateurs disposant des privilèges Administrateur système reçoivent automatiquement une licence Acrobat Sign.
- Dans les nouvelles organisations, tous les administrateurs système affectés existants disposent d’un droit d’accès à Acrobat Sign de niveau administrateur.
- Dans les organisations existantes qui achètent une licence Acrobat Sign, tous les administrateurs système existants disposent d’un droit d’accès à Acrobat Sign de niveau d’administrateur de compte.
La licence Acrobat Sign est automatiquement attribuée uniquement lors de l’achat initial des services Acrobat Sign pour l’organisation. Aucun droit d’accès n’est accordé aux administrateurs système successivement nommés.
- Amélioration des communications et de la liste de contrôle d’intégration pour les administrateurs : les administrateurs d’Acrobat Sign bénéficient désormais d’un support amélioré pour la gestion de l’intégration des comptes, y compris de nouveaux outils et des communications par e-mail améliorées.
Voici les fonctionnalités d’intégration améliorées :- Liste de contrôle d’intégration : un nouvel onglet Commencer a été ajouté sous la page Administration. Il fournit une courte liste de contrôle des actions clés aux nouveaux administrateurs lorsqu’ils prennent le contrôle d’un compte pour la première fois.
- E-mails de bienvenue et de rappel mis à jour : les notifications par e-mail initiales envoyées aux nouveaux administrateurs ont été révisées pour prendre en charge la liste de contrôle d’intégration, offrant des conseils plus clairs sur les prochaines étapes de la configuration d’un compte.
- E-mail de présentation mensuelle : les administrateurs recevront un résumé mensuel détaillant les points suivants :
- Visibilité sur les statuts de tous les utilisateurs et sur les actions requises de la part des administrateurs.
- Nombre de transactions/licences utilisées depuis le début du contrat. Les administrateurs n’ont plus besoin d’accéder à Admin Console uniquement pour obtenir ces informations.
- Aperçu du contrat, y compris la date anniversaire.
- Détection intelligente des droits existants et notification : si un droit Acrobat Sign précédent d’un utilisateur est détecté, l’utilisateur concerné est inclus dans un e-mail de notification hebdomadaire envoyé à tous les administrateurs de compte. Chacun de ces utilisateurs peut apparaître dans trois notifications au maximum.
Ces améliorations aident les administrateurs à gérer leurs comptes plus efficacement et à rester informés de l’activité du système et des problèmes potentiels.
- Amélioration de l’expérience de connexion utilisateur : Acrobat Sign a simplifié le processus de connexion et d’authentification par le biais d’Adobe Identity Management System (IMS).
- Le profil organisationnel des utilisateurs est automatiquement sélectionné lors du processus de connexion pour les personnes autorisées à utiliser le service Acrobat Sign (identifiant la demande comme provenant d’une source Acrobat Sign).
- Les utilisateurs qui rencontrent des erreurs lors de la connexion reçoivent des messages d’erreur contenant des liens pour contacter les administrateurs Acrobat Sign et obtenir de l’aide.
- Toutes les personnes disposant d’un droit actif, mais ne s’étant pas connectées au service recevront jusqu’à deux rappels par e-mail. (Ceci s’applique également aux utilisateurs inactifs existants avant la date de la publication.)
Ces améliorations simplifient la connexion, réduisent les frictions et améliorent l’expérience utilisateur globale.
Environnements disponibles : Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : disponible par défaut ; non configurable
- Onglet Compte renommé Administrateur : l’onglet Compte, accessible aux administrateurs de niveau compte Acrobat Sign, a été renommé Administrateur. Il s’agit d’une modification apportée à l’étiquette de l’onglet dans la version web autonome de l’application. Cette mise à jour est implémentée pour l'environnement commercial en avril 2025 et l'environnement gouvernemental en mai 2025.
Mises à jour des applications mobiles
- Mise à jour de la gestion des fichiers de modèle : la liste des modèles dans l’application mobile Acrobat Sign suit désormais un format structuré, ce qui facilite la recherche de modèles spécifiques. La structure s’aligne sur la version web, en organisant les modèles en sections, notamment :
- Mes modèles
- Modèles de groupe
- Modèles de compte
Cette mise à jour améliore la navigation et garantit la cohérence entre les expériences mobiles et web.
- Accessibilité améliorée dans les applications mobiles Acrobat Sign : les applications mobiles Acrobat Sign proposent désormais des fonctionnalités d’accessibilité améliorées, garantissant ainsi une meilleure conformité aux normes d’accessibilité. Les mises à jour incluent :
- Amélioration du contraste des couleurs pour une meilleure visibilité.
- Prise en charge des raccourcis clavier pour faciliter la navigation.
- Amélioration de la compatibilité du lecteur d’écran pour une expérience utilisateur plus inclusive.
Ces améliorations rendent l’application mobile plus accessible afin que vous puissiez bénéficier d’une expérience plus fluide et plus conviviale.
Environnements disponibles : application mobile iOS | Niveaux de service disponibles : Acrobat Standard, Acrobat Pro, Acrobat Sign Solutions | Portée de la configuration : disponible par défaut
Mises à jour d’intégrations
- Mise à jour des connecteurs Acrobat Sign pour Microsoft Power Automate : les connecteurs Acrobat Sign pour Power Automate prennent désormais en charge un processus amélioré d’envoi des accords qui permet de charger les documents sur la page Composer en vue de modifier les informations sur les destinataires, puis d’envoyer les accords à l’environnement de création pour placer d’autres champs.
En outre, les connecteurs Acrobat Sign prennent désormais en charge deux méthodes d’authentification avancées :- Passerelle d’identités numériques
- Mot de passe à usage unique par e-mail
- Intégration Workday : signatures numériques avec Aadhaar e-Sign : l’intégration Workday prend désormais entièrement en charge Aadhaar e-Sign, un service de signature électronique en ligne disponible en Inde qui facilite la signature numérique d’accords basés sur l’authentification par mots de passe à usage unique et la vérification e-KYC.
Mises à jour API/Webhook REST
Les mises à jour d’API et de webhook pour cette version sont disponibles dans la documentation de l’API Acrobat Sign.
- Conformité au RGPD : suppression des informations utilisateur via l’API : les partenaires peuvent désormais utiliser l’API pour effacer les informations utilisateur lors de la suppression des données d’un utilisateur conformément aux exigences du RGPD. Cette amélioration rationalise la gestion des données et garantit la conformité réglementaire.
- Nouveau champ de webhook : eventDateTimezoneOffset : Adobe Acrobat Sign introduit le nouveau champ eventDateTimezoneOffset dans la payload du webhook pour l’événement souscrit AGREEMENT_ACTION_COMPLETED.
Ce champ enregistre le décalage de fuseau horaire du destinataire lors de la mise à jour de l’accord, ce qui permet de mieux connaître l’heure de signature locale.- eventDateTimezoneOffset enregistre le décalage de fuseau horaire du destinataire, en minutes, par rapport à l’heure UTC (par exemple, eventDateTimezoneOffset : « UTC-300 »).
- Le champ eventDate existant reste inchangé et continue à stocker l’horodatage UTC de l’action. Le décalage de fuseau horaire ne modifie pas la valeur eventDate.
Cette mise à jour améliore le suivi des activités de signature sur différents fuseaux horaires.
- Migration de la documentation pour les développeurs Acrobat Sign : la documentation pour les développeurs Acrobat Sign, auparavant disponible sur la page opensource.adobe.com/acrobat-sign, est désormais disponible sur developer.adobe.com/acrobat-sign. Cette migration garantit une meilleure intégration avec les ressources Adobe pour les développeurs, en vue d’offrir à ces derniers une expérience simplifiée et centralisée.
Problèmes résolus
| Problème | Description |
|---|---|
| 4490799 | Résumé : le code pays par défaut ne peut pas être modifié avec la page Envoi de nouvelle expérience. |
| Correction : le code a été amélioré pour s’assurer que les propriétés de groupe héritées sont transférées via tous les processus pour terminer la création d’accords. | |
| 4501927 | Résumé : divergence dans la gestion des PDF entre les modes de création classique et nouveau après la publication |
| Correction : amélioration du code pour mieux accéder et utiliser toutes les propriétés des champs dans les transformations des fichiers PDF. | |
| 4503970 | Résumé : message final inapproprié lorsque le premier destinataire est l’expéditeur. |
| Correction : mise à jour du message pour tenir compte des rôles afin d’afficher le bon message. | |
| 4505208 | Résumé : le champ CC [Demander une signature] n’affiche pas les options de remplissage automatique à partir du carnet d’adresses. |
| Correction : fonctionnalité de carnet d’adresses ajoutée au champ CC. | |
| 4507982 | Résumé : lorsque plusieurs groupes partagent avec un utilisateur par le biais du partage de compte avancé, un problème de performance peut survenir lorsque l’on essaie d’accéder à un modèle sous l’onglet Gérer, filtre Modèles. |
| Correction : remaniement de plusieurs fonctionnalités afin d’optimiser la recherche de groupes multiples. | |
| 4508227 | Résumé : une erreur non gérée se produit lors de la signature d’accords générés par la nouvelle expérience de création avec les champs de paiement. |
| Correction : mise à jour du point final pour gérer le champ avec moins d’ambiguïté. | |
| 4508929 | Résumé : erreur déclenchée pour les étiquettes de champs du Concepteur de tâches personnalisées qui sont inférieures à 100 caractères en raison de l’encodage de caractères spéciaux. |
| Correction : les caractères spéciaux sont décodés lors de la validation de la limite de caractères. | |
| 4509141 | Résumé : une erreur non informative se déclenche lors de l’envoi d’un accord avec un témoin, alors que le groupe est configuré pour exiger une méthode d’authentification, mais que le témoin est configuré pour ne pas être authentifié. |
| Correction : le processus de configuration inclut désormais un message d’erreur indiquant que l’authentification à deux facteurs pour tous les destinataires est configurée et qu’un témoin est utilisé. | |
| 4509366 | Résumé : la mise à jour du nom du client FedRAMP a échoué avec des caractères spéciaux car les caractères n’ont pas été remplacés par leur numéro d’entité HTML. |
| Correction : mise à jour du processus pour gérer correctement les caractères spéciaux dans l’environnement FedRAMP. | |
| 4509680 | Résumé : ajout des pays Île de Man, Guernesey et Jersey pour l’indicatif de pays +44. |
| Correction : ajout des constantes COUNTRY_CODE pour l’Île de Man, Guernesey et Jersey. | |
| 4510255 | Résumé : la tentative de création d’un utilisateur qui existe déjà dans un autre groupe semble créer l’utilisateur dans le groupe sans utilité. |
| Correction : l’erreur a été améliorée pour indiquer que l’utilisateur a été déplacé vers le nouveau groupe (et non créé). | |
| 4510309 | Résumé : lorsqu’un bloc de signature est ajouté via l’API avec un type d’entrée autre que BLOC, le processus de signature est renvoyé à l’expérience classique car le BLOC n’est pas identifié correctement. |
| Correction : amélioration de la condition pour qu’elle renvoie des informations supplémentaires afin d’identifier correctement l’objet BLOC. | |
| 4510652 | Résumé : les champs des formulaires signés numériquement doivent être aplatis avant de modifier le PDF pour le signataire suivant. |
| Correction : les champs du formulaire de signature numérique qui ont été signés sont invalidés lorsqu’ils sont soumis à un workflow d’accord écrit. | |
| 4511819 | Résumé : la ligne bleue de la signature s’affiche dans le document PDF pour les champs de signature non signés. |
| Correction : les champs de signature non signés sont ignorés lors du rendu des champs de signature dans le document PDF. | |
| 4511965 | Résumé : la Passerelle d’identités numériques ne fonctionne pas en raison de la vérification de l’ID appliquée lors de l’extraction des critères d’ID. |
| Correction : la vérification de correspondance entre les adresses e-mail et les noms lors de la récupération des critères d’authentification pour DIG_ID a été supprimée. | |
| 4513228 | Résumé : valeur de champ manquante dans un document PDF lorsque le nom du champ contient des espaces supplémentaires en raison de la réduction du nom du champ dans le backend. |
| Correction : découpage du nom du champ dans la partie principale afin d’assurer la cohérence du nom du champ. | |
| 4513358 | Résumé : problème de traitement des fichiers dans les instances Adobe Sign Sandbox pour les champs de formulaire sans référence à des pages. Dans ce cas, la page est nulle et un pointeur nul est généré. |
| Correction : ajout d’une vérification de la nullité de cet événement afin de le gérer correctement. | |
| 4513464 | Résumé : l’administrateur rencontre plusieurs erreurs lors de l’interaction avec les modèles via le partage de compte avancé car l’API est évaluée avec les autorisations de l’utilisateur de la session (par exemple, Editor_User) au lieu des autorisations de l’utilisateur commuté (par exemple, Creator_User). |
| Correction : ajout de l’en-tête x-on-behalf-of-user à la demande d’API pour s’assurer que la demande est évaluée avec les autorisations de l’utilisateur commuté (Creator_User). | |
| 4513575 | Résumé : les données des champs de formulaire ne sont pas redimensionnées pour les champs multilignes. |
| Correction : Code mis à jour pour autoriser le dimensionnement automatique. | |
| 4513914 | Résumé : lorsque le nombre d’utilisateurs ACTIFS du compte est égal à la valeur MAX_ACTIVE_USERS, la modification d’un mot de passe n’est pas autorisée en raison de la vérification de MaxActiveUsers. |
| Correction : amélioration de la fonctionnalité afin d’ignorer correctement cette vérification lorsque l’utilisateur est ACTIF. | |
| 4514839 | Résumé : l’utilisateur ne peut pas signer un accord avec plusieurs signatures numériques si le premier champ signé n’est pas le premier champ de signature en haut du document. |
| Correction : ajout d’une méthode permettant d’itérer sur tous les champs et d’extraire un ticket valide qui est ensuite utilisé pour l’en-tête X-JWT-Assertion. | |
| 4515343 | Résumé : la taille de la police du champ de saisie multiligne change sur la page de signature électronique. La taille de la police est multipliée par le facteur de zoom, de sorte que la taille de l’entrée varie en fonction de ce facteur : plus précisément, il s’agit d’ajuster les dimensions d’une page. |
| Correction : la méthode permettant d’obtenir la taille de police du champ multiligne renvoie la taille de police en px, sans la multiplier par un facteur de zoom. | |
| 4515735 | Résumé : après la signature d’un accord, le bouton Gérer de la page de post-signature renvoie une page incorrecte. |
| Correction : la page post-signature a été corrigée afin de récupérer correctement les informations nécessaires au rendu de la page. | |
| 4516641 | Résumé : il est possible que l’annotation d’un champ de formulaire ne soit pas jointe à une page. |
| Correction : une vérification nulle a été ajoutée à la liste des annotations de la page. | |
| 4517113 | Résumé : e-mail de problème de document reçu lors de l’envoi d’un accord par API via un compte de développeur en raison d’erreurs de pointeur nul lors de la vérification des champs de formulaire. |
| Correction : nous vérifions maintenant si la liste des champs du formulaire est nulle avant de demander si la liste est vide. | |
| 4517156 | Résumé : lorsqu’il existe des champs de formulaire dans un ensemble de PDF d’entrée, les générateurs de champs de formulaire ne sont pas autorisés à produire des champs de formulaire supplémentaires. |
| Correction : lorsqu’il existe une liste de générateurs de champs de formulaire à traiter, nous ajoutons cette tâche à la liste des tâches à exécuter après la tâche ReadPDFTask. |
Version Adobe Acrobat Sign 16.0.1
Déploiement en production : 20 mai 2025
Déploiement sur GovCloud : 22 mai 2025
Fonctionnalité améliorée
- Amélioration de la sécurité des données des destinataires en configurant des destinataires avec accès restreint : la fonctionnalité Accès restreint aux accords renforce la confidentialité en empêchant les utilisateurs d’associer des accords à l’ID utilisateur Acrobat Sign d’un destinataire (s’il en possède un). Lorsque l’option Accès restreint aux accords est activée, elle est disponible dans la section Paramètres du destinataire de la page Composer. Les administrateurs peuvent configurer ce paramètre pour l’activer par défaut et faire en sorte que les expéditeurs puissent le modifier.
Lorsqu’un destinataire est marqué comme restreint, il est traité comme s’il ne disposait pas d’un compte d’utilisateur Acrobat Sign actif. Par conséquent, l’accord ne figure pas sur sa page Gérer. Cela empêche les fuites accidentelles de données dues aux relations de partage au niveau du groupe.
Environnements disponibles : Sandbox, Commercial, Government | Niveaux de service disponibles : Solutions Acrobat Sign | Portée de configuration : Compte et Groupe
- Ajout de la prise en charge de l’API pour la fonctionnalité Accès restreint aux accords : les organisations qui utilisent l’API pour composer et envoyer des accords peuvent désormais utiliser la fonctionnalité Accès restreint aux accords dans le cadre de la configuration de leurs destinataires. La mise en œuvre de cette fonctionnalité via l’API présente une particularité en ce qui concerne l’accès au document si le type d’authentification est défini sur « Aucun » :
- Dans l’interface d’Acrobat Sign, le destinataire ne peut pas consulter ou télécharger l’accord tant qu’il n’a pas été signé. Même si aucune authentification n’est configurée, l’accès à l’accord est désactivé en supprimant les actions Afficher et Télécharger.
- Lorsque vous utilisez l’API, l’accord peut être consulté et téléchargé avec le jeton une fois l’authentification terminée. Si aucune authentification n’est configurée, l’accord peut être consulté ou téléchargé avant qu’il soit signé.
Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Compte et Groupe
- Nouveaux pays pris en charge pour l’authentification par téléphone : l’authentification par téléphone et l’envoi d’accords par SMS prennent désormais en charge ces pays et codes téléphoniques supplémentaires :
- Îles Malouines ou Falkland (+500)
Environnements disponibles : Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Compte et Groupe
Modifications de l’expérience
- Une connexion est désormais nécessaire pour soumettre un incident à l’assistance via un formulaire web pour les anciens comptes d’entreprise : les utilisateurs disposant d’anciens comptes d’entreprise doivent désormais se connecter avec leurs informations d’identification Acrobat Sign avant d’utiliser le formulaire web en ligne pour soumettre un incident à l’assistance. Cette étape d'authentification garantit que le cas est lié au bon compte et acheminé vers l'équipe d'assistance appropriée.
Environnements disponibles : Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de configuration : Activé par défaut ; Non modifiable
Mises à jour API/Webhook REST
Les mises à jour d’API et de webhook pour cette version sont disponibles dans la documentation de l’API Acrobat Sign.
- API GET /agreements maintenant disponible à partir d’un microservice : le point de terminaison GET /agreements migre de l’application Acrobat Sign centrale vers un microservice dédié. Dans le cadre de cette transition, les demandes de recherche récupèrent les données du service de recherche (espace de stockage secondaire) et non de la base de données principale. Cette modification renforce la stabilité du service et empêche les appels API atypiques d’avoir un impact sur l’expérience Acrobat Sign.
- Le format de page maximal pour l’appel API GET/agreements est désormais de 500 accords par demande. Traditionnellement, le service de recherche ne récupérait pas plus de 100 accords par page. Si d’autres accords sont requis, plusieurs requêtes ayant une portée plus étroite peuvent être nécessaires.
- Étant donné que les recherches ont lieu désormais dans l’espace de stockage secondaire, une latence supplémentaire mineure peut être observée lors de l’appel du point de terminaison GET /agreements.
- Mise à jour de la limitation d'API - Après la version de mai 2025, de nouvelles règles de limitation d'API seront appliquées :
- Lorsque la charge globale du système est élevée, Acrobat Sign réduit un sous-ensemble de demandes d’API dans l’ensemble du système.
- Lorsque des clients à forte consommation sont identifiés comme contribuant à la lenteur générale du système, Acrobat Sign restreint un sous-ensemble de demandes d’API spécifiques à ce client.
Lorsqu’une demande d’API est restreinte, elle est rejetée avec un code d’état 429 HTTP, ainsi que les éléments suivants :
Texte de la réponse
En-tête de réponse
Une fois la réponse ci-dessus reçue, vous pouvez utiliser l’en-tête Retry-After ou retryAfter dans le corps de la réponse pour déterminer à quel moment tenter de nouveau la demande.
Pénalité de réessai
Pour tous les nouveaux comptes créés après la version de mai 2025, une pénalité sera appliquée si le compte ne respecte pas l’intervalle de réessai spécifié.
Si la même demande est réessayée pendant cet intervalle, la demande est à nouveau restreinte et l’intervalle de réessai est réinitialisé.
Problèmes résolus
| Problème | Description |
|---|---|
| 4477748 | Résumé : les utilisateurs ne peuvent pas créer de OAUTH ACCESS-TOKEN en raison d’un domaine incorrect dans l’appel API. |
| Correctif : la liste de domaines du contrôleur Swagger a été mise à jour. | |
| 4480357 | Résumé : la manipulation du clavier dans la boîte de dialogue « Démarrer depuis la bibliothèque » ne fonctionne pas correctement lorsque des lecteurs d’écran sont exécutés. |
| Correctif : plusieurs correctifs ont été apportés à la navigation des lecteurs d’écran afin de garantir que toutes les pages démarrées sont lues comme prévu. | |
| 4498103 | Résumé : attribution incorrecte des rôles dans la fonctionnalité Envoi en masse. Attribution systématique d’un rôle de « Signataire » lorsque vous vous ajoutez en tant que dernier destinataire. |
| Correctif : suppression des options d’attribution d’autres rôles à l’expéditeur lorsqu’il est ajouté en position de dernier participant, étant donné que l’expéditeur est toujours censé être un signataire. | |
| 4501417 | Résumé : le placement d’un champ de signature de cachet avec un modèle de champ entraîne une erreur qui bloque la création. |
| Correctif : ajout d’un code pour traiter les éléments de la balise de texte « signer1 ». | |
| 4506667 | Résumé : si un expéditeur a besoin que le premier signataire d’un formulaire web vérifie son adresse e-mail, les notifications du webhook sont retardées jusqu’à ce que le premier signataire vérifie son adresse e-mail. Si l’adresse e-mail du premier signataire est rejetée, la notification du webhook est retardée de 2 heures, car on s’attend à ce que le paramètre documentsInfo soit rempli. |
| Correctif : si l’expéditeur a besoin que le premier signataire d’un formulaire web vérifie son adresse e-mail, le paramètre documentsInfo ne sera pas renseigné dans la payload de notification du webhook pour les événements d’accord (jusqu’à ce que le premier signataire vérifie son adresse e-mail). Si l’adresse e-mail du premier signataire est rejetée, le paramètre documentsInfo ne sera pas renseigné dans la payload de notification du webhook pour les événements d’accord. | |
| 4511940 | Résumé : la taille de police par défaut d’un champ de texte multiligne ne s’adapte pas à la taille de l’écran, de sorte que le texte est coupé lors de la signature d’un accord à l’aide d’un téléphone portable. |
| Correctif : le champ de texte multiligne ne peut plus remplacer la méthode de la classe de base. | |
| 4513457 | Résumé : problème d’analyse JSON lorsque le nom du groupe contient des guillemets doubles. |
| Correctif : amélioration du code d’analyse des noms de groupe afin de gérer les guillemets doubles. | |
| 4515610 | Résumé : les valeurs des champs calculées sont modifiées lorsque le formulaire web est envoyé à des participants supplémentaires en raison de la façon dont les nombres à virgule flottante sont traités dans le backend et le frontend. |
| Correctif : changement de l’implémentation sur le backend pour utiliser BigDecimal comme type pour les nombres. | |
| 4516504 | Résumé : lorsque vous créez un modèle réutilisable et que vous utilisez la vue Nouvelle expérience, les cases à cocher et les boutons radio ont des bordures roses au lieu de bordures noires, car la valeur de la couleur a été tronquée. |
| Correctif : la valeur hexadécimale a été corrigée pour contenir la valeur correcte. | |
| 4520149 | Résumé : le statut de certains accords n’est pas mis à jour après la signature en raison d’une condition de concurrence rare lors de la définition de l’indicateur next_to_sign. |
| Correctif : un enregistrement supplémentaire a été ajouté pour détecter cette condition et la résoudre avant que les destinataires n’interagissent avec l’accord. | |
| 4521246 | Résumé : le partage de modèles au sein de plusieurs groupes ne fonctionne pas et génère des erreurs lorsque le partage de compte avancé est activé et que le processus d’envoi commence sur la page d’accueil. |
| Correctif : le sélecteur de modèle provenant de la page d’accueil a été mis à jour pour récupérer correctement le modèle partagé. |
Version Adobe Acrobat Sign 16.1
Déploiement en production : 22 juillet 2025
Déploiement GovCloud : 5 août 2025
Fonctionnalité améliorée
- Utilisez WhatsApp pour envoyer des liens de contrat directement sur l'appareil mobile d'un destinataire - L'intégration WhatsApp dans Acrobat Sign a été étendue pour inclure l'option d'envoyer des liens de notification et de rappel de contrat directement sur l'appareil compatible WhatsApp d'un destinataire.
- Prise en charge native du format PDF/A pour la conservation à long terme des documents : Acrobat Sign prend désormais en charge la validation et l’exportation de documents au format PDF/A-2b (ISO 19005), ce qui permet aux entreprises de se conformer à des normes d’archivage et des exigences réglementaires strictes. Les documents conservent leur conformité PDF/A tout au long du cycle de vie complet du contrat : chargement, signature et stockage.
- Empêcher l'intégration d'Adobe Acrobat Sign dans des sites Web tiers - La protection contre le détournement de clic ajoute une protection iframe aux pages Acrobat Sign accessibles via l'API REST v5+. Le framing n'est autorisé que lors de l'utilisation de la connexion automatique avec un domaine parent déclaré, aidant à prévenir l'intégration trompeuse ou non autorisée.
- Amélioration du contrôle du partage basé sur le groupe : les organisations qui utilisent le partage de compte avancé peuvent désormais restreindre la vue partagée de leurs accords aux seuls accords envoyés par le groupe de l’utilisateur. Les accords envoyés à un utilisateur à partir d’un groupe externe seront filtrés afin de protéger les communications potentiellement privées de l’utilisateur qu’il serait inapproprié de partager de manière générale. Ce filtre s'applique uniquement aux partages au niveau du groupe (partage d'un groupe avec un autre groupe ou utilisateur), et ne s'applique pas aux partages basés sur l'utilisateur (partage d'un utilisateur avec un groupe ou un autre utilisateur).
- Mises à jour pour les clients sous licence VIP :
- Configuration d'administrateur simplifiée depuis la page d'accueil - Acrobat Sign présente une nouvelle section Gestion de compte pour aider les administrateurs de compte à accéder rapidement aux outils de configuration clés.Ajoutez des utilisateurs, organisez des groupes, connectez des intégrations et migrez des modèles directement depuis la page d'accueil, sans avoir à chercher.
- Ajouter des utilisateurs à Admin Console depuis Acrobat Sign – Les administrateurs peuvent désormais ajouter des utilisateurs directement depuis la page Users dans Acrobat Sign, mettant automatiquement à jour Adobe Admin Console.
- Attribution des rôles clés d'Admin Console désormais disponible via Acrobat Sign - Pour simplifier la configuration, Acrobat Sign permet désormais aux administrateurs de compte d'attribuer les rôles clés d'Admin Console — Administrateur produit et support — sans quitter l'interface du produit.
- Accès facilité à la suite d'intégrations tierces - Une nouvelle page Intégrations a été ajoutée au menu administrateur, fournissant des liens directs et intuitifs vers les fichiers de configuration des intégrations individuelles.
- Intégration HIPAA facilitée grâce aux conseils intégrés au produit - Les organisations soumises à HIPAA peuvent désormais commencer le processus d'activation dans Acrobat Sign via un nouveau processus libre-service à travers le menu administrateur Commencer.Le système envoie une demande automatisée au support et suit la progression en fonction de la signature du BAA et de la configuration du système.
- Accélérez la migration de vos modèles vers Acrobat Sign avec la conversion automatisée de modèles - La nouvelle fonctionnalité de migration de modèles aide les administrateurs de compte à intégrer rapidement leurs modèles dans Acrobat Sign.Téléchargez un fichier ZIP de modèle, convertissez-le automatiquement et examinez les résultats dans l'environnement de création, sans expertise technique nécessaire.
- Chatbot Assistant intelligent Acrobat Sign - Le nouvel Assistant intelligent vous fournit des réponses intégrées aux questions courantes comme l'ajout d'utilisateurs, la vérification de l'utilisation ou la mise à jour des paramètres.Posez votre question en langage naturel et obtenez des instructions étape par étape, des articles HelpX pertinents ou des liens vers des pages d’assistance.
- Acrobat Sign for Government passe à l'expérience moderne :
- Acrobat Sign for Government : accès à l'interface moderne « Demander une signature » - Les administrateurs GovernmentCloud peuvent désormais permettre à leur compte ou à leurs groupes d'utiliser l'interface moderne « Demander une signature ».
- Acrobat Sign for Government : mise à niveau axée mobile pour les destinataires - Les utilisateurs gouvernementaux peuvent désormais accéder à l'interface moderne, conçue pour simplifier la signature sur les appareils mobiles grâce à une interface facile à configurer, uniquement basée sur les champs de formulaire.
- Acrobat Sign for Government : nouvelle interface Créer un modèle disponible - Les utilisateurs gouvernementaux ont désormais accès à l'interface moderne Créer un modèle, qui rationalise le processus de conception de modèles et améliore la facilité d'utilisation.
- Nouveau fournisseur de services de confiance (TSP) : Acrobat Sign élargit sa liste de fournisseurs de services de confiance (TSP) pris en charge pour améliorer les options d’authentification du destinataire. Le nouveau TSP suivant est désormais disponible :
- eID Easy
Cet ajout étend la compatibilité d'Acrobat Sign avec les standards mondiaux, prenant en charge les signatures numériques fluides et sécurisées dans de multiples secteurs.
Modifications de l’expérience
- Expérience de signature numérique améliorée - Le processus d'application d'une signature numérique basée sur le cloud a été affiné pour réduire le nombre d'interactions que le signataire doit effectuer lors de l'application d'une signature numérique.
- La limite de caractères pour les libellés dans le Concepteur de processus a été augmentée à 500 caractères - Lors de la création ou modification d'un processus personnalisé dans le Concepteur de processus, les libellés utilisés pour décrire les champs peuvent désormais accepter jusqu'à 500 caractères (amélioré par rapport aux 100 caractères).
- Le contrôle de la nouvelle expérience de processus personnalisé a été déplacé vers le menu Paramètres globaux- L'option configurable pour Définir le nouveau processus personnalisé comme expérience par défaut a été déplacée de la page Paramètres d'envoi vers la page Paramètres globaux.
Un nouveau contrôle a été ajouté pour exposer les « liens de basculement » permettant aux utilisateurs de passer de la nouvelle expérience à la version classique.
Problèmes résolus
| Problème | Description |
|---|---|
| 4501772 | Résumé : Pour l'expérience moderne de demande de signature, le message du destinataire ne se met pas à jour lorsque la langue est modifiée dans les paramètres de l'accord. |
| Correction : Le code pour accepter la nouvelle préférence de langue a été mis à jour pour prendre en compte le changement de messages lorsqu'une nouvelle langue est sélectionnée. | |
| 4503504 | Résumé : Dans de rares cas, les nouvelles tentatives effectuées pendant la création d’un accord peuvent entraîner la génération de plusieurs copies du même accord enfant lors de l’utilisation de la fonctionnalité Envoyer en masse. |
| Correctif : Plusieurs mises à jour ont été apportées à la façon dont les accords enfants sont générés et répertoriés en interne avec des vérifications pour s’assurer qu’aucun doublon ne peut être créé. | |
| 4511072 | Résumé : Les e-mails du rapport de consommation de transactions ne sont pas reçus après avoir utilisé l'option « Envoyer maintenant ». |
| Correction : Le système de messagerie a été mis à jour pour résoudre un problème de livraison. | |
| 4511224 | Résumé : Les fichiers PDF définis sur le zoom « Hérité » avant l’envoi passent par défaut à « Page entière » après la signature. |
| Correctif : La gestion des annotations a été améliorée pour garantir que les propriétés sont correctement confirmées dans le PDF obtenu. | |
| 4512546 / 4522458 |
Résumé : Les workflows partagés n’affichent pas les modèles de champs comme prévu pour le partage des comptes effectué via la fonctionnalité Partage de compte avancé. |
| Correctif : La requête GET /libraryDocuments/id/formFields a été mise à jour pour l’en-tête x-on-behalf-of-user requis pour le cas d’usage de partage de compte avancé. | |
| 4515020 | Résumé : L’appel API PUT /users/{id}/groups renvoie une erreur 403 lorsqu’un administrateur de groupe essaie de déplacer un utilisateur qui ne figure pas dans le groupe par défaut. |
| Correctif : L’autorité a été étendue aux administrateurs de groupe, qui peuvent désormais ajouter des utilisateurs à leur groupe, même si l’utilisateur affecté se trouve actuellement dans un autre groupe que celui par défaut. | |
| 4516121 | Résumé : Lorsqu’un groupe de boutons radio possède des infobulles individuelles, seule la première s’affiche pour toutes les options lors de la signature. |
| Correctif : Le code des boutons radio n’utilisait qu’une seule infobulle pour l’ensemble des boutons. Il a été mis à jour pour permettre une représentation individuelle. | |
| 4516129 | Résumé : Les accords expirent en fonction de l'équivalent UTC de l'heure locale de l'expéditeur, et non de l'heure locale prévue. |
| Correctif : La logique qui vérifie l’heure d’expiration n’est plus basée sur l’heure du navigateur, ce qui permet à l’application principale d’effectuer la validation. | |
| 4518192 | Résumé : les signataires ne peuvent parfois pas terminer le processus de signature lors de l’utilisation de l’authentification Adobe Sign avec Okta SSO. |
| Correctif : suppression de l’attribut crossShardLoginPage de la session après une connexion réussie. | |
| 4521018 | Résumé : Lors de l’utilisation de l’expérience de signature moderne, les champs déroulants configurés avec des valeurs d’exportation renvoient le libellé visible au lieu de la valeur d’exportation dans la réponse de l’API /formData. |
| Correctif : Les valeurs (d’exportation) masquées sont maintenant envoyées à la place des valeurs visibles. | |
| 4521111 | Résumé : Dans la nouvelle expérience de création, les utilisateurs ne peuvent pas faire défiler et voir tous les modèles de champs disponibles dans le menu déroulant Modèles de champs. |
| Correctif : L'expérience de création moderne a été mise à jour pour charger plus que la première page des modèles de champs. | |
| 4521311 | Résumé : En raison d’un délai connu de 12 heures dans le mécanisme d’expiration des accords, des rappels sont envoyés après l’heure d’expiration effective, entraînant des tentatives de signature infructueuses et perturbant les utilisateurs. |
| Correctif : Pour les rappels récurrents « Jusqu’à la signature », le système vérifie désormais la date limite de signature et n’enverra plus le rappel, mais ce dernier restera actif pour permettre une récupération si l’expéditeur modifie la date limite de signature avant l’expiration effective pendant la période de grâce de 12 heures. | |
| 4522059 | Résumé : Lorsqu’un signataire charge un fichier en utilisant un champ de pièce jointe, puis appose une signature numérique, le lien de téléchargement du document génère une erreur « Page introuvable ». |
| Correctif : La somme de contrôle a été éliminée de la détection des doublons, car il s'agit d'une propriété facultative dans la spécification PDF. Acrobat Sign continue d'utiliser le nom et la taille du fichier pour identifier les doublons. | |
| 4522382 | Résumé : Les utilisateurs ne peuvent pas effectuer de transactions lors de l’utilisation de Cliquer pour signer avec l’authentification activée. Après la connexion, la transaction ne se termine pas et doit être réessayée |
| Correctif : Le paramètre d'URL crossShardLandingPage a été supprimé de la session après la connexion. | |
| 4522384 / 4523594 / 4523900 |
Résumé : Lors de l'utilisation de la fonction d'envoi en masse, aucun accord n'est envoyé à la première tentative, mais une deuxième tentative fonctionne comme prévu en raison de la mise en file d'attente des tâches sur le fragment local. |
| Correctif : La mise en file d'attente des tâches a été affinée pour garantir que les tâches ne soient pas retardées. | |
| 4522497 | Résumé : Le format d'horodatage sur les accords passe de HH:MM:SS à HH:MM après la signature du document, entraînant la perte des secondes dans la piste d'audit finale. |
| Correctif : Les secondes ont été ajoutées au timePattern. | |
| 4522509 | Résumé : Les destinataires en copie ne peuvent pas voir le tableau contextuel de l’accord lorsqu’ils accèdent aux accords avec visibilité limitée des documents via le lien de l’e-mail. À la place, ils reçoivent une erreur « Document pas encore visible ». |
| Correctif : Le code a été modifié pour fournir l’accès nécessaire pour afficher le tableau contextuel. | |
| 4522547 | Résumé : Lors de l’utilisation d’un modèle, le PDF final peut présenter des données de champ de formulaire mal alignées ou manquantes après la signature en raison de la rotation de la page appliquée après chaque annotation. |
| Correctif : La rotation de la page a été corrigée. | |
| 4522914 | Résumé : Lors de l’utilisation de la nouvelle fonctionnalité Envoyer en masse, les clients peuvent rencontrer une erreur pendant le téléchargement du fichier CSV si les valeurs des colonnes Agreement_Message ou Private_Message dépassent une limite de caractères spécifique. |
| Correctif : La limite de caractères a été documentée dans les supports destinés aux clients. | |
| 4522945 | Résumé : Lorsqu’un administrateur de compte/groupe essaie de modifier le document réutilisable et d’appliquer un modèle de champ, une erreur NullPointerException se produit lors de la vérification de la participation d’origine. |
| Correctif : Une méthode a été ajoutée pour permettre d’identifier la participation d’origine lorsqu’un administrateur de compte/groupe modifie des documents de bibliothèque. | |
| 4523043 | Résumé : Lors de la modification d’un formulaire web incluant un participant dont le rôle est défini sur Délégant, la page de modification du formulaire web ne se charge pas. Une erreur de console est déclenchée, empêchant toute modification. |
| Correctif : Une vérification a été ajoutée pour garantir que, si ROLE_MAP est indéfini, le code ne lit pas className comme indéfini et ne génère pas d’erreur. Au lieu de cela, il renvoie la valeur undefined. | |
| 4523061 | Résumé : Les documents signés joints aux e-mails conservent leur extension de fichier d’origine dans le nom de fichier, ce qui entraîne une redondance dans la dénomination. |
| Correctif : Le nom de fichier n’est plus tronqué s’il commence par « . » et s’il est différent de l’extension. | |
| 4524122 | Résumé : Dans la nouvelle expérience, le fait d’essayer de démarrer un accord à partir d’un workflow enregistré entraîne une erreur système en raison d’un dépassement de limite de caractères. |
| Correctif : Les limites des libellés ont été mises à jour pour accepter 500 caractères. | |
| 4524162 | Résumé : La validation des liens empêche l’envoi des accords dans la nouvelle expérience de création. |
| Correctif : Un paramètre a été ajouté à la nouvelle expérience pour vérifier le hook relatif aux erreurs, afin de permettre une gestion plus souple des validations de liens hypertexte. | |
| 4524356 | Résumé : Les utilisateurs rencontrent un message « Erreur serveur : une erreur s’est produite lors du traitement de votre demande » lorsqu’ils essaient de signer des accords en raison de l’interprétation incorrecte de la largeur de bordure -1. |
| Correctif : La valeur -1 est désormais interprétée comme une bordure par défaut de 1 pt, et une bordure n’est ajoutée que si la valeur est supérieure à zéro. | |
| 4524410 | Résumé : Dans la nouvelle expérience d’envoi, lors de l’utilisation d’un workflow et du chargement d’un nouveau fichier après la suppression du nom d’accord prédéfini, le champ Nom de l’accord ne se met pas à jour automatiquement. |
| Correctif : Un correctif a été ajouté pour supprimer la valeur par défaut pour l’événement onBlur et une logique a été ajoutée pour indiquer le nom du premier document chargé dans le champ de texte du nom du document. | |
| 4524614 | Résumé : La police utilisée par les champs de formulaire de texte du PDF ne correspond pas à la police choisie sur la page de création. La police du champ de texte est toujours SourceSansPro-Regular. |
| Correctif : ExternalFont.getFontReplacementMapping a été étendu pour inclure les polices normal, gras et italique. | |
| 4525098 | Résumé : L’e-mail de demande de signature n’est pas envoyé au signataire 2 lorsque l’expéditeur est le signataire 2 et que l’expéditeur remplace le signataire 1. |
| Correctif : Les listes de destinataires parallèles ont été améliorées pour gérer le cas d’usage où un destinataire existant est utilisé pour en remplacer un autre dans le même ensemble de destinataires. | |
| 4525377 | Résumé : Les cachets électroniques ne fonctionnent pas avec l’expérience moderne de demande de signature. |
| Correctif : Un scénario de test a été ajouté pour vérifier le destinataire du cachet électronique dans un workflow hors Utilisateurs dans plusieurs groupes avec une restriction d’accès au cachet par groupe. | |
| 4525491 | Résumé : Les noms d’accords contenant des caractères non latins (par exemple, chinois, japonais, thaï, coréen) apparaissent comme ?????? dans l’onglet Gérer du destinataire et les notifications par e-mail lors de l’envoi via la fonctionnalité Envoyer en masse. |
| Correctif : La documentation a été mise à jour pour indiquer que le format UTF-8 est requis. | |
| 4525653 | Résumé : Les contrats envoyés via l’API avec des fichiers JPEG sont automatiquement annulés en raison d’une erreur de traitement du document. Le problème survient après que les fichiers ont été chargés avec succès, mais avant que le contrat ne soit envoyé. |
| Correctif : La prise en charge du marqueur SOI pour app0-15 dans les fichiers JPEG a été ajoutée. | |
| 4526153 | Résumé : Le comportement du champ de tampon diffère entre l’ancien et le nouvel écran de création. |
| Correctif : Le nouvel environnement de création a été mis à jour pour redimensionner le champ de tampon comme dans la version classique. | |
| 4527031 | Résumé : Lorsque l’option « Autoriser les expéditeurs à sélectionner l’ordre de signature » est décochée dans la nouvelle expérience, l’option « Les destinataires doivent signer dans l’ordre » reste visible. |
| Correctif : Le code relatif à l’accès à cette commande a été amélioré pour supprimer correctement l’option lorsque le paramètre l’exige. | |
| 4527284 | Résumé : Les accords qui incluent certains fichiers PDF numérisés ou aplatis échouent lors de la création et sont automatiquement annulés avec l’erreur AUTO_AUTHOR_FAIL en raison d’une bibliothèque interne non gérée. |
| Correctif : Une méthode a été mise en place pour intercepter toute exception et l’enregistrer, mais elle n’interrompt pas la génération d’un accord. | |
| 4527948 | Résumé : Lorsqu’un champ Acroform calculé est importé dans Sign, l’API REST renvoie un champ contenant { calculated: true, valueExpression: '' }, ce qui entraîne l’affichage du champ avec une erreur de validation. |
| Correctif : Les champs identifiés dans ce cas d’usage ont été mis à jour pour être saisis manuellement, et non plus calculés. | |
| 4528062 | Résumé : L’appel API GET /users échoue pour les utilisateurs Salesforce avec un très grand nombre d’utilisateurs. |
| Correctif : Une nouvelle version de l’intégration Salesforce améliore le processus d’obtention de la liste des utilisateurs pour le rendre plus efficace. | |
| 4528284 | Résumé : Le code pays des îles Caïmans est incorrect pour l’authentification par téléphone dans la nouvelle expérience. |
| Correctif : Le code pays a été mis à jour. | |
| 4529259 / 4529319 |
Résumé : Les noms des signataires facultatifs et l’authentification à deux facteurs sont exigés malgré la configuration du workflow dans la nouvelle expérience d’envoi du workflow personnalisé. |
| Correctif : Une vérification a été ajoutée pour les destinataires facultatifs afin que, lorsqu’aucun ID d’e-mail n’est présent, la vérification d’identité (téléphone, mot de passe, KBA) ne génère pas d’erreur de validation. De même, le nom ne sera pas obligatoire pour les destinataires facultatifs, sauf si une valeur a été saisie dans le champ de l’ID d’e-mail. | |
| 4530084 | Résumé : Certains utilisateurs constatent un écran vide lorsqu’ils accèdent aux paramètres du destinataire dans la nouvelle expérience d’envoi. Le problème est dû à une traduction manquante pour un libellé de code pays spécifique, et il affecte toutes les langues sauf l’anglais américain. |
| Correctif : Les traductions correctes ont été publiées et épinglées aux fonctions appropriées. | |
| 4530537 | Résumé : Une exception NPE se produit lorsque l’utilisateur essaie de convertir une destination nommée en un emplacement, empêchant ainsi l’envoi des accords. |
| Correctif : Une nouvelle vérification a été mise en place pour déterminer si la destination est une destination nommée et l’ignorer. |
Déploiement du sandbox : 19 août 2025
Déploiement en production : 16 septembre 2025
Déploiement GovCloud : 18 septembre 2025
Fonctionnalité améliorée
- Modèles d'e-mail personnalisés disponibles pour Acrobat Sign for Government- Les clients sur la plateforme GovCloud peuvent désormais créer des modèles d'e-mail personnalisés pour leurs notifications d'accord et rappels.
- Bannière Nouveautés de la page d’accueil : une nouvelle bannière Nouveautés peut être activée au niveau du compte ou du groupe pour informer les utilisateurs des nouvelles notifications de produits telles que les notes de mise à jour, les formations et les événements système. Cela aide à davantage sensibiliser aux nouvelles fonctionnalités et options, à améliorer l’engagement et à s’assurer que les mises à jour importantes ne sont pas manquées. Cette fonctionnalité sera activée pour tous les comptes après la publication et pourra être désactivée par l’administrateur au niveau du compte. Il y a quelques exceptions à la règle « activé par défaut » :
- Le fragment australien (AU1) aura la fonctionnalité désactivée par défaut.
- Tout compte identifié comme un compte « Administration » sera désactivé.
Modifications de l’expérience
- Changement de conception de l’intégration Notarize en Proof : l’intégration au service d’authentification notariale en ligne a été mise à jour pour refléter la nouvelle image de marque du service, Proof, dans toutes les communications destinées aux clients.
Des mises à jour de l’interface d’utilisation d’Acrobat Sign sont prévues dans la prochaine version (v16.2) en octobre.
- Validation plus stricte des paramètres régionaux lors de la création d’accords via l’API : la validation des paramètres de langue pour les accords créés via l’API a été renforcée.Lors de l'utilisation de l'API pour créer un contrat, et si l'option « Permettre aux utilisateurs de votre compte de sélectionner une langue de signature différente » est désactivée, l'API rejettera toute requête où les paramètres régionaux du contrat ne correspondent pas à la « Langue de signature » sélectionnée par l'administrateur.
Notez que l'envoi via l'interface web n'est pas impacté.
Problèmes résolus
| Problème | Description |
|---|---|
| 4511940 | Résumé : lorsqu’un expéditeur crée un champ de texte avec l’option Entrée de données multiligne activée et la police définie sur Auto, les signataires utilisant un navigateur mobile voient le texte coupé au bas du champ. |
| Correction : remplacement de la méthode de base pour que la taille du champ prenne en charge la taille de police < 0 (auto) au moyen d’une formule modifiée spécifique aux champs multiligne. | |
| 4516038 | Résumé : lors de l’envoi d’accords avec Envoi en masse, les utilisateurs voient une erreur : « Vous avez atteint le nombre de jours maximum autorisé pour l’expiration du document. » même si les paramètres d’expiration du document sont désactivés au niveau du groupe et du compte. |
| Correction : correction du code pour évaluer correctement les valeurs d’expiration de l’accord pour le groupe/compte. | |
| 4522265 | Résumé : lorsqu’un PDF contient à la fois des champs à remplir et des balises de texte, les balises de texte ne sont pas traitées. |
| Correction : création d’une tâche dans le mode aplati, indépendamment de la présence de générateurs de champs de formulaire. Permet à un PDF avec des champs de formulaire de traiter un artefact de formulaire si nécessaire. | |
| 4522645 / 4527073 |
Résumé : le PDF signé inclut une troisième page vierge après que l’expéditeur a chargé un document au nom du signataire final. |
| Correction : amélioration de la fonction de gestion pour traiter correctement les petits flux. Les chargements de signatures manuscrites utilisent le document réparé et non le chargement original si un problème est détecté avec le document chargé. | |
| 4524437 | Résumé : les nouveaux utilisateurs ne sont pas connectés à Adobe Sign après avoir accepté l’invitation en raison d’une URL erronée. |
| Correction : correction de l’URL. | |
| 4525093 | Résumé : le lien de divulgation au consommateur n’est pas cliquable. Le lien est présent, mais cliquer dessus ne fait que basculer la case à cocher au lieu d’ouvrir le lien. |
| Correction : modification du CSS du lien pour permettre au lien d’ouvrir une nouvelle page. | |
| 4525099 | Résumé : les clients qui exigent une diffusion par SMS mais ont désactivé les notifications par e-mail ne peuvent pas envoyer d’accords par SMS. |
| Correction : la diffusion par SMS/WhatsApp n’est plus dépendante des paramètres de l’adresse e-mail. | |
| 4525328 | Résumé : l’utilisation de deux modèles ou plus contenant des liens hypertextes portant le même nom génère une erreur serveur lors de la tentative de signature. |
| Correction : si des noms de liens hypertextes en double sont trouvés, les noms des liens seront modifiés pour garantir qu’ils sont identifiés de manière unique. | |
| 4525510 | Résumé : le champ de formulaire de paiement ne conserve pas le type de devise USD dans la nouvelle expérience de création, ce qui entraîne une erreur « Erreur inattendue ». |
| Correction : les conversions pour les champs de paiement ont été mises à jour. | |
| 4525544 | Résumé : impossible de modifier les formulaires web Actif ou Brouillon. |
| Correction : nous préservons désormais les paramètres existants et les envoyons au serveur, au lieu d’utiliser les données de l’interface utilisateur. | |
| 4525901 / 4532254 |
Résumé : l’accord n’est pas attribué au signataire restant en raison d’un rôle de workflow incorrect lorsque de nouveaux participants sont ajoutés après la création des champs. |
| Correction : amélioration du code pour mieux évaluer les rôles des participants lorsque de nouveaux participants sont ajoutés après la création. | |
| 4526300 | Résumé : impossible de créer une URL d’accord personnalisée avec l’ID du workflow dans la nouvelle expérience. |
| Correction : lorsque des URL personnalisées sont créées uniquement avec l’ID du workflow, le formulaire de création d’accord se recharge et appelle le serveur principal pour récupérer à nouveau le workflow et le brouillon d’accord pendant le chargement du formulaire. | |
| 4526756 | Résumé : la documentation de la page Swagger de l’API GovCloud est incorrecte concernant la création de nouvelles applications. |
| Correction : ajout d’une phrase supplémentaire pour éviter toute confusion pour les clients FedRAMP. | |
| 4527340 | Résumé : lorsque les utilisateurs appliquent Remplir et signer dans Acrobat web puis sélectionnent Inviter à signer électroniquement, les valeurs saisies pendant Remplir et signer n’apparaissent pas lorsque l’accord passe à la page de création d’Acrobat Sign. La vue de création affiche des champs vides au lieu des valeurs remplies. |
| Correction : la valeur par défaut de la taille de police a été corrigée, permettant ainsi au contenu de s’afficher correctement. | |
| 4528835 | Résumé : erreur « MISC_SERVER_ERROR for GET formData - Une erreur s’est produite. » lors de l’appel GET /formData pour un Curseur spécifique en raison d’une erreur de pointeur nul. |
| Correction : ajout d’une vérification NPE et d’un journal. | |
| 4528902 | Résumé : lorsqu’un accord est envoyé pour signature séquentielle à deux participants, le champ « Nom du destinataire » attribué au premier participant est perdu lors du traitement du modèle PDF. Lors de la définition du rôle du champ « Nom du destinataire », le rôle de l’ensemble de participation stocké dans le modèle PDF ne parvient pas à être converti. |
| Correction : de nombreuses fonctions ont été mises à jour pour gérer correctement ce type de conversion. | |
| 4531278 | Résumé : certaines adresses e-mail ajoutées en Cc sont supprimées automatiquement après l’envoi de la transaction si elles ont été créées avant qu’Acrobat Sign n’ajoute la mise en minuscules automatique des adresses e-mail lors de la création d’utilisateurs. |
| Correction : mise à jour de la recherche/comparaison d’adresses e-mail dans le code de suppression des Cc pour être insensible à la casse. | |
| 4531669 | Résumé : impossible d’envoyer des accords à partir de documents PDF lorsque les champs de formulaire ont des noms dépassant les limites de la spécification PDF. |
| Correction : ajout de vérifications NPE pour l’apparence d’une annotation. | |
| 4531998 | Résumé : impossible d’accéder aux accords enfants via l’API - Erreur « ID de document non valide » due à un titre de signet nul. |
| Correction : suppression de l’instruction de débogage qui peut échouer avec une NPE si le titre du signet est nul. | |
| 4532642 | Résumé : lors de la tentative de remplacement de l’un des contre-signataires dans un formulaire web qui inclut des signataires supplémentaires inconnus et un groupe de destinataires pour les contre-signataires, la méthode de mise à jour tente de lire l’e-mail des participants inconnus (signataires supplémentaires inconnus), qui n’ont pas de données utilisateur/e-mail, provoquant une NullPointerException. |
| Correction : ajout d’une condition de filtre pour exclure les participations inconnues du flux de collecte d’e-mails, évitant ainsi une NPE lors du traitement des participations qui n’ont pas encore de données utilisateur/e-mail. |
Version Adobe Acrobat Sign 16.2
Déploiement en production : 7 octobre 2025
Déploiement sur GovCloud : 14 octobre 2025
Fonctionnalité améliorée
- La demande de signature introduit plusieurs améliorations de l’expérience utilisateur conçues pour réduire le nombre de clics et améliorer l’efficacité : ces mises à jour répondent aux retours des clients, rendant la nouvelle expérience de demande de signature plus rapide, plus facilement repérable et mieux alignée avec le processus classique.
- Tous les types de signature sont développés par défaut dans l’environnement de création
- Le rôle de pré-remplissage est toujours visible dans l’environnement de création
- Les boutons intégrés d’ajout de destinataire remplacent les menus masqués
- Ajout automatique d’une nouvelle ligne de destinataire lors de l’ajout d’une adresse
- Prise en charge du copier/coller pour plusieurs adresses de destinataires
- Commandes d’administration pour configurer l’expérience client lors de la rédaction de nouveaux accords. Choisissez entre un processus guidé ou l’affichage de toutes les sections dès le début.
- Prise en charge de l’API pour les groupes de cases à cocher, permettant aux expéditeurs de définir des options à sélection multiple dans un formulaire : les groupes de cases à cocher permettent aux expéditeurs de spécifier combien d’options les destinataires doivent sélectionner, apportant une nouvelle flexibilité pour les accords qui nécessitent une saisie structurée à choix multiples.
Notez que l’option des cases à cocher à sélection multiple n’est disponible que pour les accords créés via l’API.- Définir des groupes de cases à cocher à sélection multiple.
- Configurer des règles pour des sélections exactes, minimales, maximales ou par plage.
- La validation est appliquée pendant la signature dans le cadre de l’expérience de signature électronique classique.
- Les sélections des destinataires sont conservées dans les accords signés et les données de formulaire téléchargeables.
- Invitation des utilisateurs à leur organisation Acrobat Sign : invitez des coéquipiers directement depuis l’interface Acrobat Sign avec des workflows contrôlés par l’administrateur pour une adoption plus rapide par l’équipe. Selon la configuration, les utilisateurs invités peuvent être automatiquement provisionnés, acheminés via le provisionnement Just-In-Time (JIT), ou nécessiter l’approbation de l’administrateur. Ce flux simplifié améliore l’expérience des équipes de PME et du segment intermédiaire, accélère l’adoption des workflows partagés et donne aux administrateurs une meilleure visibilité sur la demande réelle de licences.
- Nouveau bouton Inviter sur les pages Accueil et Gérer pour les utilisateurs finaux
- Les utilisateurs invités reçoivent un e-mail de bienvenue et sont facilement ajoutés à l’organisation
- Les invitations respectent les règles de provisionnement automatique existantes
- Les administrateurs peuvent examiner les demandes en attente dans la section Demandes d’accès
- Si le provisionnement automatique est désactivé, les demandes sont acheminées vers les administrateurs pour approbation
- Page Utilisateurs réorganisée : la page Utilisateurs a été réorganisée pour mieux gérer les utilisateurs dans leurs différents états et pour offrir une meilleure visibilité aux nouveaux collaborateurs invités. Cela permet d'isoler les utilisateurs qui ont des difficultés à activer leurs comptes et accélère l'intégration pour l'ensemble de l'équipe.
- Les plages d’adresses IP autorisées pour l’accès à Acrobat Sign ont été étendues aux groupes et aux API : une plus grande flexibilité a été fournie pour les contrôles de restrictions d’adresse IP lors de la sécurisation de l’accès à Acrobat Sign. Les restrictions d’adresse IP peuvent désormais être configurées au niveau du groupe par les administrateurs de groupe. De plus, les restrictions s’appliquent désormais à l’accès des API : si un compte ou un groupe spécifie un ensemble d’adresses IP autorisées, l’interface utilisateur d’Acrobat Sign et les API ne sont accessibles que depuis ces adresses.
- Les restrictions d’adresse IP s’appliquent désormais à l’accès à l’interface utilisateur et aux API.
- Les administrateurs de groupe peuvent configurer les restrictions d’adresse IP pour leurs groupes.
- Les utilisateurs appartenant à plusieurs groupes sont évalués par rapport à la politique d’adresses IP de leur groupe par défaut.
- Les intégrations et les applications partenaires sont autorisées par défaut et ne sont pas limitées par le blocage d’adresse IP.
- Les administrateurs peuvent travailler avec le support Adobe pour bloquer des applications au niveau du groupe ou du compte. Si l’accès est bloqué, l’application doit utiliser des adresses IP autorisées pour se connecter à Acrobat Sign.
- Améliorations de l’expérience utilisateur pour les clients titulaires d’une licence ETLA : les récentes mises à jour publiées pour les clients sous licence VIP sont étendues aux clients sous licence ETLA d’une valeur inférieure à 100 000 $ US (contactez votre responsable de compte ou le support si vous avez des questions) :
- Configuration d'administration simplifiée depuis la page d'accueil - Acrobat Sign présente une nouvelle section de gestion de compte pour aider les administrateurs de compte à accéder rapidement aux outils de configuration clés. Ajoutez des utilisateurs, organisez des groupes, connectez des intégrations et migrez des modèles directement depuis la page d'accueil, sans avoir à chercher.
- Ajouter des utilisateurs au Admin Console depuis Acrobat Sign – Les administrateurs peuvent désormais ajouter des utilisateurs directement depuis la page Utilisateurs dans Acrobat Sign, mettant automatiquement à jour Adobe Admin Console.
- Cet élément doit être déployé dans la première semaine de novembre 2025.
- Attribution des rôles Admin Console désormais disponible via Acrobat Sign - Pour simplifier la configuration, Acrobat Sign permet désormais aux administrateurs de compte d'attribuer les rôles Admin Console essentiels — Administrateur produit et support — sans quitter l'interface du produit.
- Accès facilité à la suite d'intégrations tierces - Une nouvelle page Intégrations a été ajoutée au menu administrateur, fournissant des liens directs et intuitifs vers les fichiers de configuration des intégrations individuelles.
- Intégration HIPAA facilitée grâce aux conseils intégrés au produit - Les organisations soumises à HIPAA peuvent désormais commencer le processus d'activation dans Acrobat Sign via un nouveau processus libre-service à travers le menu administrateur Commencer.Le système envoie une demande automatisée au support et suit la progression en fonction de la signature du BAA et de la configuration du système.
- Accélérez la migration de vos modèles vers Acrobat Sign grâce à la conversion automatisée de modèles - La nouvelle fonctionnalité de migration de modèles aide les administrateurs de compte à transférer rapidement leurs modèles dans Acrobat Sign. Téléchargez un fichier ZIP de modèle, convertissez-le automatiquement et examinez les résultats dans l'environnement de création, sans expertise technique nécessaire.
- Suppression des signatures de certification et de verrouillage des accords signés numériquement : les organisations qui doivent passer par des services tiers de validation de signatures peuvent désormais demander à l’assistance Adobe de configurer les paramètres de leur compte ou de leur groupe pour ignorer l’application du certificat Adobe et empêcher les signatures de verrouillage sur les accords signés numériquement. Lorsque cette option est activée, les accords ne contiennent que les signatures numériques du destinataire, réduisant ainsi les taux de rejet dans les outils de validation régionaux stricts.
- Les administrateurs de compte peuvent demander à l’assistance Adobe d’exclure les signatures de verrouillage et de certification Adobe au niveau du compte et/ou du groupe.
- Les accords ne contiennent que les signatures numériques du destinataire, améliorant l’acceptation par les validateurs tiers.
- Le rapport d’audit enregistre quand la certification est ignorée, y compris une empreinte numérique SHA-256 du document
- S’applique à tous les points de contact d’exportation : pièces jointes des e-mails, téléchargements depuis la page Gérer, API et données utiles des webhooks
- Résout les écarts de conformité soulevés par les clients nécessitant une validation dans le cadre de modèles de confiance régionaux - Description
- PDF/A amélioré pour prendre en charge la conformité PDF/A-3B et convertir tous les fichiers chargés vers la norme PDF/A sélectionnée : les administrateurs peuvent désormais activer la conversion et la normalisation des fichiers chargés, y compris les PDF, les formats Microsoft Office et les images raster, en PDF/A-2b ou PDF/A-3b. Les fichiers PDF/A existants sont validés, réparés si nécessaire, ou normalisés au niveau cible configuré.
- Les administrateurs peuvent configurer les workflows PDF/A au niveau du compte ou du groupe.
- Niveaux de conformité pris en charge : PDF/A-2b (par défaut) et PDF/A-3b.
- Les documents non PDF et les PDF non conformes sont automatiquement convertis en PDF/A.
- Les fichiers PDF/A endommagés sont réparés ou normalisés au niveau cible.
- Pièces jointes autorisées selon les règles PDF/A : PDF/A-2b (uniquement PDF/A), PDF/A-3b (tout type de fichier).
- Les accords sont revalidés pour la conformité PDF/A à la fin de la signature.
- Les rapports d’audit sont générés en option au format PDF/A et incluent les résultats de validation/conversion PDF/A en lien avec le niveau de conformité.
- Événements de méthode d’authentification mise à jour dans les rapports d’audit : les modifications apportées aux méthodes d’authentification des destinataires peuvent désormais être incluses dans le rapport d’audit en tant qu’événements distincts. Lorsqu’un expéditeur (ou un délégué autorisé) modifie la méthode d’authentification d’un destinataire — par exemple, en passant d’un mot de passe à usage unique par SMS à un mot de passe à usage unique par e-mail — la mise à jour est capturée et enregistrée dans le rapport d’audit de l’accord, le journal d’activité et la liste des événements de l’API.
- Un nouvel événement, Méthode d’authentification mise à jour, apparaît dans le rapport d’audit, montrant :
- le destinataire concerné ;
- l’utilisateur qui a effectué la modification ;
- la méthode d’authentification d’origine ;
- la nouvelle méthode d’authentification ;
- la date et l’heure de la modification.
- Les événements sont également exposés via l’API GET /agreements/{agreementId}/events.
- Les journaux d’activité affichent l’événement avec les détails du destinataire, de l’initiateur et des date et heure.
- Un nouvel événement, Méthode d’authentification mise à jour, apparaît dans le rapport d’audit, montrant :
Modifications de l’expérience
- Accès IPv6 pour Acrobat Sign pour le gouvernement : les organisations qui utilisent IPv6 sur le service Acrobat Sign pour le gouvernement ont désormais accès aux adresses Acrobat Sign IPv6 :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
- L'expérience moderne Destinataire pour la signature électronique est désormais l'environnement par défaut pour tous les comptes - Tous les comptes ont été mis à jour pour utiliser l'environnement moderne de signature électronique. Les contrôles administrateur restent dans le menu Administration pour activer l'environnement classique si nécessaire.
- L'expérience moderne Demander une signature est désormais l'environnement par défaut pour tous les comptes - Tous les comptes ont été mis à jour pour utiliser l'environnement moderne Demander une signature. Les commandes d'administration restent dans le menu Administration pour activer l'environnement classique si nécessaire.
- L'expérience moderne Créer un modèle est désormais l'environnement par défaut pour tous les comptes d'entreprise - Tous les comptes ont été mis à jour pour utiliser l'environnement moderne Créer un modèle de bibliothèque. Les contrôles administrateur restent dans le menu Administration pour activer l'environnement classique si nécessaire.
- L'expérience moderne Concepteur de processus personnalisé est désormais l'environnement par défaut pour tous les comptes - Tous les comptes ont été mis à jour pour utiliser l'environnement moderne Concepteur de processus. Les contrôles administrateur restent dans le menu Administration pour activer l'environnement classique si nécessaire, et les liens de basculement restent disponibles pour permettre aux utilisateurs de passer de l'expérience classique à l'expérience moderne (si activée)
Mises à jour API/Webhook REST
Les mises à jour d’API et de webhook pour cette version sont disponibles dans la documentation de l’API Acrobat Sign.
- Seuil d'interrogation API pour les points d'entrée GET API concernant la récupération de statut ou les objectifs de liste- Un nouveau seuil d'interrogation limite désormais la fréquence à laquelle les applications clientes peuvent interroger des points d'entrée GET /agreement spécifiques.
- Rôle de Super administrateur de groupe pour les partenaires OEM : un nouveau rôle de Super administrateur de groupe est disponible sur la plateforme OEM 2.0. Ce rôle permet aux partenaires d’octroyer à leurs clients des capacités administratives limitées pour créer et gérer des groupes sans exposer tous les privilèges d’administrateur de compte.
- Le client du partenaire peut créer et gérer ses propres groupes.
- Le créateur d’un groupe devient automatiquement l’administrateur de ce groupe.
- Les administrateurs de compte contrôlent quels paramètres de groupe sont exposés.
- Les administrateurs de groupe ne voient que les paramètres pertinents, tels que les modèles de message, les paramètres de messagerie, les paramètres d’envoi et l’état de partage.
- La fonctionnalité nécessite que l’option Utilisateurs dans plusieurs groupes soit activée.
- Les administrateurs de compte restent le seul rôle ayant accès aux paramètres au niveau du compte et la capacité d’attribuer le rôle de Super administrateur de groupe.
Problèmes résolus
| Problème | Description |
|---|---|
| 4505635 | Résumé : la portée agreement_retention n’est pas disponible dans l’API GovCloud. |
| Correctif : la portée a été configurée pour fonctionner dans l’environnement GovCloud avec l’intégration Okta. | |
| 4515686 | Résumé : les propriétaires de formulaires web ne peuvent pas remplacer le contre-signataire sur les formulaires web existants dans des circonstances de validation spécifiques. La tentative de mise à jour de l’adresse e-mail du contre-signataire renvoie une erreur : « Impossible d’ajouter ou de supprimer votre adresse e-mail dans l’état actuel de l’accord. » |
| Correctif : la validation est mise à jour pour que l’adresse e-mail correcte de l’expéditeur ou du contre-signataire soit reconnue. Les propriétaires de formulaires web peuvent maintenant remplacer le contre-signataire comme prévu. Les utilisateurs n’ont pas besoin de prendre de mesures particulières. | |
| 4519727 | Résumé : le format moderne des numéros de téléphone au Bénin n’est pas reconnu (10 caractères). |
| Correction : Acrobat Sign prend désormais en charge le nouveau format de numéro de téléphone à 10 chiffres pour le Bénin. Les utilisateurs peuvent saisir des numéros valides avec l’indicatif pays +229 sans erreurs. Aucune action n’est requise de la part des utilisateurs. | |
| 4525532 | Résumé : le rôle de préremplissage n’est pas disponible par défaut dans la nouvelle expérience de création. |
| Correctif : le rôle de préremplissage est maintenant affiché par défaut dans la liste de contexte des destinataires lors de la rédaction des accords. | |
| 4526142 | Résumé : lors de l’application d’un calque de champs de formulaire à partir d’un modèle existant dans la nouvelle expérience de création, certains champs ne sont pas copiés. |
| Correctif : de nouvelles vérifications ont été ajoutées pour garantir que le modèle complet est transféré. | |
| 4527772 | Résumé : les accords avec un routage séquentiel perdent parfois le champ du nom du destinataire lorsqu’ils sont attribués à un participant chargé de remplir de formulaire. Le champ ne s’affiche pas pour ce destinataire, laissant l’accord incomplet. |
| Correctif : des mises à jour importantes de l’API REST ont été établies pour garantir que tous les champs sont conservés. | |
| 4527945 | Résumé : l’utilisation d’un modèle de champ de formulaire dans un accord qui a un groupe de destinataires ne fonctionne pas - le code de validation du modèle élimine le participant du groupe de destinataires et les champs associés sont perdus. |
| Correctif : le code a été remanié pour utiliser un paramètre de membre différent au lieu de la valeur d’adresse e-mail. | |
| 4528619 | Résumé : lors de la modification du nom d’un groupe de destinataires dans la nouvelle expérience d’envoi, le curseur saute automatiquement à la fin du texte après chaque modification. Cela rend difficile la modification du nom en une seule fois. |
| Correctif : le suivi des demandes est mis à jour pour garantir que toutes les méthodes d’authentification se chargent correctement avant l’envoi. Les accords sont maintenant traités correctement une fois que tous les détails d’authentification requis sont fournis. Aucune action n’est requise de la part des utilisateurs. | |
| 4531835 / 4537898/ 4541002 |
Résumé : les clients rencontrent des erreurs lors de l’utilisation de certains certificats tiers car les certificats racine mis à jour ne sont pas approuvés, ce qui cause des problèmes avec les webhooks et les notifications. |
| Correctif : les autorités de certification racine sont en cours de mise à jour. | |
| 4532798 | Résumé : lors de l’application d’un calque de champs de formulaire, Acrobat Sign crée un nouveau document pour capturer les informations du calque. En raison de problèmes de contrôle de version dans ces nouveaux documents, certains workflows de modification des accords échouent. |
| Correctif : nous avons modifié notre approche en passant de l’extraction des informations source via une API à la publication d’un événement lorsqu’un modèle de calque de champs de formulaire est appliqué et en le consommant afin de remplir les informations source pour les accords. | |
| 4534813 | Résumé : les utilisateurs dans plusieurs groupes ne peuvent pas utiliser la reconnaissance automatique des champs lors de la création de modèles ou d’accords. |
| Correctif : ajout d’un nouveau test pour vérifier la détection des champs dans la V5 de l’environnement de création pour un utilisateur avec de nombreux groupes. | |
| 4535639 | Résumé : dans certains accords, les champs d’image requis sont manquants dans le PDF signé. Bien que le fichier FormFields.csv affiche des URL d’images, les images n’apparaissent pas dans l’accord final. |
| Correctif : l’ordre de quelques fonctions a été modifié pour garantir que les champs d’image intégrés sont traités que le formulaire soit présent ou non, et maintenant les images s’affichent correctement pour tous les signataires. | |
| 4535828 | Résumé : les liens hypertextes dans les documents sont modifiés lorsque l’accord est envoyé. |
| Correctif : lorsque l’URL est déjà encodée spécifiquement avec : /, qui est un caractère réservé pour les URL, decodeURI ne les décode pas. Modifié en decodeURIComponent pour vérifier la condition avant l’encodage. | |
| 4536354 | Résumé : le chargement des documents PDF volumineux (~150 pages) échoue avec l’erreur « Format non pris en charge ou protégé par mot de passe » en raison d’un délai d’expiration frontend insuffisant pour les vérifications de disponibilité des images. |
| Correctif : augmentation du paramètre max_retries de 7 (par défaut) à 13, prolongeant le délai d’expiration d’environ 30 s à environ 60 s. Cela fournit un temps suffisant pour le traitement des documents volumineux. | |
| 4538897 | Résumé : les modèles IText originaux avec du contenu de page pivoté provoquent une rotation incorrecte des signatures aplaties sur la page. |
| Correctif : avant d’aplatir les signatures dans le contenu de la page, le contenu de la page est enveloppé avec un push/pop gstate pour empêcher la matrice de rotation d’affecter les signatures ajoutées. | |
| 4539304 | Résumé : la documentation Swagger est par défaut en mode « Essayer » et les consommateurs d’API ont du mal à parcourir le schéma de demande. |
| Correctif : la documentation est maintenant par défaut en mode de visualisation au lieu de « Essayer », de sorte que les schémas sont visibles par défaut. Les performances sont améliorées en éliminant les appels API redondants pour les types de données primitifs. | |
| 4542576 | Résumé : les charges utiles des webhooks pour l’événement AGREEMENT_ACTION_COMPLETED renvoient différentes valeurs de statut des participants dans la version Sandbox 16.2. Auparavant, les entrées memberInfos affichaient « ACTIVE » ou « REPLACED » même après la signature. Dans la version 16.2, elles affichent « COMPLETED » lorsque la participation dynamique n’est pas activée. |
| Correctif : l’utilisation des nouveaux statuts de participants ne sera effective que si la fonctionnalité de participation dynamique pour les accords en cours est activée. |
Version Adobe Acrobat Sign 16.2.1
Déploiement en production : 4 novembre 2025
Déploiement sur GovCloud : 6 novembre 2025
Mises à jour API/Webhook REST
Les mises à jour d’API et de webhook pour cette version sont disponibles dans la documentation de l’API Acrobat Sign.
- Seuil d'interrogation API pour les points d'entrée GET API concernant la récupération de statut ou les objectifs de liste- Un nouveau seuil d'interrogation limite désormais la fréquence à laquelle les applications clientes peuvent interroger des points d'entrée GET /agreement spécifiques.
- Rôle de Super administrateur de groupe pour les partenaires OEM : un nouveau rôle de Super administrateur de groupe est disponible sur la plateforme OEM 2.0. Ce rôle permet aux partenaires d’octroyer à leurs clients des capacités administratives limitées pour créer et gérer des groupes sans exposer tous les privilèges d’administrateur de compte.
- Le client du partenaire peut créer et gérer ses propres groupes.
- Le créateur d’un groupe devient automatiquement l’administrateur de ce groupe.
- Les administrateurs de compte contrôlent quels paramètres de groupe sont exposés.
- Les administrateurs de groupe ne voient que les paramètres pertinents, tels que les modèles de message, les paramètres de messagerie, les paramètres d’envoi et l’état de partage.
- La fonctionnalité nécessite que l’option Utilisateurs dans plusieurs groupes soit activée.
- Les administrateurs de compte restent le seul rôle ayant accès aux paramètres au niveau du compte et la capacité d’attribuer le rôle de Super administrateur de groupe.
Problèmes résolus
| Problème | Description |
|---|---|
| 4509452 / 4526158 |
Résumé : la recherche de modèles lors de la création d’accords ou de l’utilisation d’Envoi en masse ne filtre pas correctement les autres modèles en raison d’un composant qui ne gère pas correctement l’indexation et le défilement. |
| Solution : le composant problématique a été corrigé pour garantir la disponibilité des résultats de recherche. | |
| 4525233 | Résumé : les accords impliquant une validation de devise n’apparaissent pas comme prévu dans le champ dans l’expérience de signature moderne. |
| Solution : les champs avec validation de devise affichent désormais correctement le symbole monétaire une fois que le champ n’est plus actif dans l’expérience de signature moderne. La mise à jour assure un formatage cohérent des symboles dans les vues classique et moderne. | |
| 4530694 | Résumé : l’URL du lien « Modifier le mot de passe » intégrée dans l’interface utilisateur est incorrecte. |
| Solution : l’URL a été corrigée. | |
| 4532664 | Résumé : les PDF signés générés à partir de documents source contenant des annotations de liens web peuvent afficher « Le document a été modifié après signature » dans Acrobat, et le statut de certification apparaître comme non valide en raison d’annotations de lien en double ou incorrectes. |
| Solution : Acrobat Sign détecte et traite désormais correctement les liens web pendant le processus de signature, ce qui permet d’avoir un statut de certification valide sur le document signé. | |
| 4535715 | Résumé : la taille des PDF avec des liens web est multipliée par deux à chaque signature, car la fonction d’impression réimprime une copie de l’annotation de lien web. |
| Solution : les PDF sont maintenant aplatis pour garantir qu’il n’y a aucun lien en double avant la fusion des annotations dans le PDF. | |
| 4535760 | Résumé : lors de l’utilisation de champs calculés faisant référence à des champs de saisie de texte, certains PDF signés affichaient des nombres incorrects ou aléatoires au lieu de la valeur de texte attendue, car le moteur de champs tentait de convertir la saisie texte en formats de nombres ou de dates. |
| Solution : la logique de conversion du moteur de champs calculés a été mise à jour pour reconnaître les saisies texte et ignorer la conversion en nombres ou en dates pour ces champs. | |
| 4536385 | Résumé : les champs de formulaire déroulants comportant plusieurs annotations de type widget ne peuvent pas être utilisés comme clé FT, sinon la génération de l’apparence est perturbée et les considère comme des champs de formulaire. |
| Solution : la clé FT a été supprimée des annotations de type widget. | |
| 4537356 | Résumé : les modèles partagés avec plusieurs groupes n’étaient pas affichés sur la page Envoi en masse. |
| Solution : la logique Envoi en masse a été mise à jour pour récupérer et afficher correctement les modèles partagés entre plusieurs groupes. | |
| 4537648 | Résumé : le point d’entrée GET /agreements/{agreementId}/events répertoriait un type d’événement hérité « DOWNLOADED » dans la documentation Swagger de l’API REST Acrobat Sign. |
| Solution : le type d’événement « DOWNLOADED » a été supprimé des valeurs autorisées dans la documentation de l’API. | |
| 4537885 | Résumé : un espace superflu apparaît sur la page Préférences de signature. |
| Solution : l’élément spacer/div inutile a été supprimé du conteneur de mise en page pour Préférences de signature. | |
| 4538113 / 4538586 / 4543131 |
Résumé : les données de formulaire des champs de saisie automatique de texte multilignes deviennent très petites et illisibles. |
| Solution : la mise à l’échelle a été corrigée pour éviter de réduire automatiquement la taille de la police jusqu’à la rendre illisible. | |
| 4538340 | Résumé : les métadonnées de signature sont ajoutées sans vérifier le nom du champ. |
| Solution : une vérification du champ de signature a été ajoutée pour contrôler l’affichage des métadonnées. | |
| 4538902 | Résumé : le point d’entrée GET /agreements/memberSetInfo de l’API REST renvoie des informations incorrectes sur le statut de l’accord et le signataire. Dans certains cas, l’expéditeur apparaît plusieurs fois dans la réponse, et des doublons dans les données des participants entraînent l’échec des intégrations en aval. |
| Solution : l’API renvoie désormais correctement le statut de l’accord et les détails des participants sans doublons. Chaque adresse e-mail apparaît une seule fois pour chaque accord, et les informations relatives au signataire correspondent au bon participant en attente. Aucune action n’est requise de la part des utilisateurs. | |
| 4543085 | Résumé : les anciennes versions de l’intégration Salesforce (inférieures à la version 25.5) ne reconnaissent pas les nouvelles énumérations de statut (COMPLETED et REMOVED) renvoyées dans les données utiles de webhook. |
| Solution : l’API REST Acrobat Sign a été mise à jour pour exclure les nouveaux statuts des participants et les énumérations associées lors des réponses aux anciens clients utilisant l’intégration Salesforce. | |
| 4543951 | Résumé : lors de la modification d’un champ de lien hypertexte sans titre, l’enregistrement de la modification crée un nouveau champ de lien hypertexte vide au lieu de mettre à jour celui d’origine. Chaque enregistrement ajoute des champs vides supplémentaires, faisant apparaître les modèles comme inchangés. |
| Solution : la logique de mise à jour fait désormais la distinction entre les titres de lien hypertexte vides et nuls, évitant ainsi les champs en double. | |
| 4544118 | Résumé : lorsque la visibilité limitée des documents est activée dans la nouvelle expérience pour les destinataires, le participant 2 pouvait voir les champs de lien hypertexte du document du participant 1, car les liens hypertexte n’étaient pas attribués. |
| Solution : Modern eSign attribue et valide désormais les champs de lien hypertexte comme les autres champs et les filtre par page et par destinataire. |