Centre d’aide Adobe

Aide Adobe Acrobat Sign

Notes de mise à jour Adobe Acrobat Sign - 2026

Dernière mise à jour le 17 juin 2026

Notes de version Adobe Acrobat Sign 2026

Adobe Acrobat Sign version 17.0

Déploiement en production : 3 février 2026

Déploiement GovCloud : 10 février 2026

Fonctionnalité améliorée

Cases à cocher groupées dans Création et Modèles – Les expéditeurs peuvent désormais créer des groupes de cases à cocher dans l’expérience Demander une signature et les modèles de bibliothèques modernes, et créer ainsi des environnements avec des règles de validation telles que sélectionner exactement, au minimum, au maximum, ou une plage de X options sur Y. L’envoi en masse, les formulaires web et les workflows personnalisés sont pris en charge grâce à l’utilisation des modèles de bibliothèque. Cette amélioration garantit une logique de formulaire cohérente et améliore la précision des données dans tous les processus de signature.

Plages d'adresses IP autorisées – Contrôle étendu de l'accès API et mobile - Les administrateurs peuvent désormais contrôler explicitement si les restrictions IP s'appliquent aux clients basés sur une API, y compris les applications mobiles Acrobat Sign et les intégrations certifiées.

Prise en charge de l'authentification pour la signature électronique moderne – La signature électronique moderne prend désormais en charge trois méthodes d'authentification : l'authentification Acrobat Sign, le mot de passe et la double authentification basée sur le téléphone.

Ajout de groupes de destinataires dans le routage hybride pour la signature de demande moderne – Les groupes de destinataires peuvent désormais être inclus dans le routage hybride, permettant à plusieurs destinataires ou groupes d'agir en parallèle au sein de la même étape de routage. Les modes de groupe permettent qu'un seul ou que tous les membres accomplissent l'action, offrant une plus grande flexibilité pour les workflows d'approbation et de signature complexes.

Copie d’accords dans un état terminal envoyés depuis l’expérience Demander une signature – Les expéditeurs peuvent désormais créer un nouveau brouillon d’accord en copiant un accord précédemment terminé, annulé ou expiré. Tous les destinataires, paramètres, fichiers et champs de formulaire sont automatiquement préremplis. L’accord copié s’ouvre dans la page Composer pour apporter des modifications rapides avant l’envoi, réduisant le temps de configuration, minimisant les erreurs et améliorant la productivité pour les workflows répétitifs tels que les renouvellements ou les corrections.

Désactiver le lien de téléchargement du contrat pour les contrats en cours – Les administrateurs peuvent désormais supprimer le lien « Télécharger une copie » des pages de confirmation après signature au niveau du compte ou du groupe, empêchant les destinataires de télécharger les contrats depuis la page après signature.

Onglet Ressources dans la navigation supérieure – Une nouvelle page Ressources est disponible dans la navigation supérieure pour les administrateurs et les utilisateurs, ce qui offre un accès direct au contenu éducatif d’Acrobat Sign, aux webinaires, aux blogs et aux vidéos de mise à jour des produits. La page organise les tutoriels par niveau d'utilisateur—débutant, expérimenté et administrateur—et renvoie directement vers la documentation d'assistance supplémentaire.

Participation dynamique pour les accords en traitement – Supprimer des destinataires – Les expéditeurs peuvent désormais supprimer des destinataires d’accords déjà en cours sans annuler ni redémarrer la transaction. Lorsqu’un destinataire est supprimé, Acrobat Sign révoque automatiquement son accès, met à jour les rappels et les journaux d’audit, supprime les champs attribués et fait revenir l’accord à son état de signature actif de manière transparente. Cette flexibilité aide les organisations à maintenir la précision dans les workflows de routage en direct — par exemple lorsqu'un signataire devient indisponible — tout en préservant l'intégrité juridique, la conformité et un historique d'audit complet.

Exigence de signatures numériques pour des destinataires individuels lors de la configuration de l’accord – Les expéditeurs peuvent désormais exiger des signatures numériques pour des destinataires sélectionnés, garantissant des exigences de signature plus strictes lorsque c’est nécessaire, sans affecter les autres destinataires. L'expérience de signature s'adapte automatiquement, en appliquant les champs de signature numérique requis et en affichant les vérifications d'identité lorsqu'elles sont prises en charge, réduisant les erreurs et améliorant la conformité pour les workflows réglementés.

Fournisseurs d’identité numérique comme méthodes d’authentification par défaut – Les administrateurs peuvent désormais sélectionner un fournisseur de passerelle d’identités numériques comme méthode d’authentification de signataire par défaut pour les destinataires internes et externes dans les Paramètres d’envoi. La configuration s’applique automatiquement aux accords, formulaires web, envois en masse et workflows, garantissant une vérification cohérente et conforme des destinataires. Cette amélioration simplifie la configuration de l'authentification, applique les politiques d'identité organisationnelles et améliore la prise en charge pour les clients gouvernementaux et d'entreprise qui s'appuient sur l'authentification basée sur l'identité numérique.

Champs de formulaire vérifiés utilisant des données d’identité vérifiées – Les auteurs de formulaires peuvent désormais créer des champs de formulaire vérifiés qui se remplissent automatiquement avec les données renvoyées par un fournisseur d’identité (tel que OneID) lors de l’authentification du signataire. Ces champs peuvent être définis comme en lecture seule ou modifiables, garantissant que les données d'identité vérifiées sont capturées avec précision et éventuellement verrouillées contre les modifications (par exemple, nom, adresse ou numéro de compte). Cela renforce l'assurance d'identité, réduit les erreurs de saisie manuelle et rationalise la conformité pour les processus qui exigent des données de signataire validées.

Groupes de destinataires dans le fichier CSV pour l’envoi en masse – Les expéditeurs peuvent désormais définir des groupes de destinataires directement dans le fichier CSV d’envoi en masse, permettant à plusieurs destinataires d’agir à la même étape de routage. Chaque groupe peut être configuré en mode ONE ou ALL, nécessitant soit un membre, soit tous les membres pour terminer leur action avant que le routage n’avance. Les définitions de groupe, la validation et le suivi des audits sont tous gérés par ligne CSV, avec des erreurs signalées via des fichiers de validation téléchargeables.

Modèle de bibliothèque – Partager avec plusieurs groupes – L’expérience Créer un modèle de bibliothèque moderne prend désormais en charge le partage de modèles avec plusieurs groupes au sein d’un compte, correspondant à la fonctionnalité précédemment disponible dans le workflow classique. Les utilisateurs peuvent sélectionner un ou plusieurs groupes lors de la création ou de la modification d'un modèle, assurant un comportement cohérent entre les groupes. Cette amélioration élimine le recours à l'expérience classique, améliore la collaboration et simplifie la gestion des modèles pour les organisations multi-groupes.

Pièces jointes pour tous les destinataires utilisant des signatures numériques – Tous les destinataires dans un processus signé numériquement peuvent désormais joindre des fichiers (pas seulement le premier signataire). Une nouvelle méthode d’ajout de pièces jointes utilisant les annotations Trombone affiche une icône de trombone visible dans le document et reste compatible avec plusieurs signatures numériques. Chaque pièce jointe est ajoutée avant que la signature numérique du signataire ne soit appliquée, préservant la validité de la signature et fournissant un indicateur visuel clair des fichiers joints. Cette amélioration améliore l'intégrité juridique, la transparence et la cohérence dans tous les processus de signature électronique et de signature numérique.

Nouvelles options TSP pour les signatures Cloud - De nouveaux fournisseurs de services de confiance ont été ajoutés pour prendre en charge les signatures numériques cloud :
- Swisscom

Modifications de l’expérience

Notifications de résiliation de contrat de workflow – Notification de résiliation mise à jour pour refléter le comportement du workflow.
Lors de l’annulation d’un accord créé par un workflow, la case « Informer les destinataires » n’apparaît plus. Les notifications sont toujours envoyées selon les paramètres du workflow. Cette modification ajuste le message pour refléter ce comportement dans la demande de résiliation.

Améliorations sur la page de connexion – La page de connexion Acrobat Sign offre désormais une expérience plus claire et plus cohérente. Dès que vous saisissez votre adresse e-mail, la page détecte automatiquement votre type de compte et vous dirige vers la méthode de connexion appropriée, supprimant les étapes inutiles et les écrans hérités. Cela rend la connexion plus rapide, plus simple et plus intuitive pour tout le monde.
- Nouveau format d’adresse e-mail pour les utilisateurs Acrobat Sign Grands comptes qui se connectent directement à l’interface web - Acrobat Sign applique désormais une limite de 64 caractères à la partie locale d’une adresse e-mail (la portion avant le symbole « @ ») lors de la modification d’une adresse e-mail existante ou de la création d’un nouvel utilisateur.
  Tous les utilisateurs avec une partie locale de plus de 64 caractères ont été évalués et déterminés comme étant inactifs ou des identifiants utilisateur de test.

Notez que cette expérience est fournie par le biais d'un déploiement progressif basé sur l'environnement serveur Acrobat Sign. Le calendrier de déploiement est publié dans la notification technique Expérience de connexion mise à jour.

Activation de la gestion des détails de l’utilisateur pour les utilisateurs inactifs – Les administrateurs peuvent désormais modifier les détails de l’utilisateur pour les utilisateurs inactifs directement dans l’interface utilisateur d’administration et via les téléchargements CSV sans réactiver les comptes. Cela inclut la mise à jour des attributions de groupe (pour les configurations comportant un seul ou plusieurs groupes), la gestion de l’attribut « L’utilisateur peut signer les documents » et l’exécution de modifications en masse pour la conformité et la maintenance des enregistrements. Ce changement rationalise la gestion du cycle de vie des utilisateurs d'entreprise, réduit les frais administratifs et prend en charge une organisation de groupes plus propre et une gestion des enregistrements conforme au RGPD.

Problèmes résolus

Problème	Description
4528600	Résumé : Les paramètres de validation de champ ne fonctionnent pas lorsqu’un calque de champs de formulaire est associé à un workflow personnalisé. Les règles de validation, telles que les expressions régulières ou les limites de plage numérique, sont supprimées lorsque le workflow est démarré, provoquant l’acceptation d’entrées non valides par les champs.
4528600	Correctif : Les règles de validation s’appliquent désormais correctement lorsque les calques de champs de formulaire sont inclus dans les workflows personnalisés. Les champs conservent leur comportement de validation dans les expériences de création classique et nouvelle. Aucune action n’est requise de la part des utilisateurs.
4528748	Résumé : Les administrateurs voient par intermittence une « Erreur non gérée » lors de l’ajout de l’appartenance à un groupe à des utilisateurs nouvellement synchronisés (synchronisation Azure). Certains nouveaux utilisateurs du groupe ont le groupID défini comme null
4528748	Correctif : Si le groupe d’un utilisateur est défini comme « null » après la création, il est placé dans le groupe par défaut du compte.
4529934	Résumé : Dans Gérer > Formulaires web, le chargement de l’option « Télécharger les données des champs du formulaire » est continu et ne se termine jamais, en particulier sur les formulaires web avec de nombreuses soumissions. Les clients Équipe sans accès API ne peuvent pas exporter les données (par exemple, du 1er au 31 mai) pour la création de rapports.
4529934	Correctif : Ajout d’une fonctionnalité d’exportation CSV paginée et plus rapide dans l’interface utilisateur. Les téléchargements de données de formulaire se terminent de manière fiable pour les plages de dates sélectionnées, sans se bloquer.
4532186	Résumé : Dans la nouvelle expérience de création, la mise en surbrillance des couleurs de champ ne correspond pas au comportement de la création classique. Lorsque plusieurs destinataires sont impliqués, tous les champs restent entièrement colorés (les champs des destinataires non sélectionnés ne sont pas atténués). Cela rend difficile la vérification des attributions de champ.
4532186	Correctif : Restauration de la clarté visuelle en atténuant les champs qui appartiennent aux destinataires non sélectionnés (opacité de 20 %). Cela reproduit la clarté de la création classique tout en préservant le système de conception moderne. La mise en surbrillance aide désormais les utilisateurs à identifier facilement les champs du destinataire actuellement sélectionné et réduit le risque d’attribution erronée.
4534061	Résumé : Le lien « Télécharger une copie » apparaît sur la page de confirmation post-signature même lorsque le paramètre de compte ou de groupe est configuré pour le désactiver.
4534061	Correctif : Un nouveau paramètre a été ajouté pour supprimer explicitement l’option de téléchargement pour toutes les pages post-envoi. La page post-signature respecte désormais correctement le paramètre de contrôle de téléchargement, masquant le lien « Télécharger une copie » lorsque le paramètre est désactivé.
4536347	Résumé : Dans l’expérience classique, les expéditeurs ne pouvaient pas ajouter un second fichier (ou réessayer d’ajouter un fichier) lors du démarrage de certains workflows (ce qui bloquait l’envoi dans les workflows comportant plusieurs documents), en raison d’une erreur dans la façon dont le sélecteur de fichiers gérait les modèles partagés entre plusieurs groupes.
4536347	Correctif : Correction de la gestion par le sélecteur de fichiers des modèles partagés entre plusieurs groupes afin que les utilisateurs puissent ajouter des fichiers supplémentaires ou réessayer de sélectionner des fichiers dans l’expérience classique sans erreurs.
4537504	Résumé : Une valeur de liste déroulante conditionnelle manquait dans le document signé même si elle avait été correctement sélectionnée lors de la signature, en raison de la logique de visibilité évaluant un champ dépendant masqué sans conserver la valeur rendue dans le fichier PDF signé final.
4537504	Correctif : Mise à jour du rendu de champ conditionnel pour résoudre correctement les dépendances de visibilité au moment de la signature et conserver la valeur de liste déroulante sélectionnée dans le document signé lorsque les conditions sont remplies.
4537995	Résumé : Dans les groupes de destinataires, la modification de la méthode d’authentification pour les utilisateurs externes revenait à Téléphone après l’enregistrement, ce qui empêchait l’application de l’OTP par e-mail, en raison d’une erreur de gestion d’état front-end qui écrasait la sélection de l’utilisateur.
4537995	Correctif : Correction de la logique d’interface utilisateur du groupe de destinataires pour conserver et réappliquer correctement la méthode d’authentification sélectionnée lors des actions d’enregistrement, garantissant que la valeur choisie est conservée au lieu d’être réinitialisée au paramètre par défaut.
4539214	Résumé : Dans les workflows personnalisés, un libellé de message long provoque le chevauchement du texte du message et masque le lien hypertexte du modèle de message sur la page d’envoi, en raison d’une gestion inappropriée de la mise en page du contenu de libellé excessif.
4539214	Correctif : Mise à jour de la logique de mise en page de la page d’envoi pour contraindre et habiller correctement les libellés de message longs afin que le lien hypertexte du modèle de message reste visible et accessible.
4539854	Résumé : Certains signataires sont redirigés hors de l’expérience de signature lors de l’ouverture de certains accords, en raison d’un champ de lien mal formé dans le document sous-jacent auquel il manque un attribut de nom requis.
4539854	Correctif : Le flux de signature gère désormais correctement les champs de lien sans nom en attribuant un nom valide au moment du traitement, évitant les erreurs et permettant aux signataires de terminer les accords sans redirection.
4539858	Résumé : Sur les appareils iOS, les approbateurs utilisant le clavier d’écriture manuscrite chinoise ne peuvent pas terminer l’approbation car le bouton Approuver reste désactivé après qu’ils ont saisi leur nom, en raison de la page de signature ne détectant pas les événements d’entrée d’écriture manuscrite comme une saisie de texte valide.
4539858	Correctif : Mise à jour de la logique de gestion d’entrée pour reconnaître la saisie de texte basée sur l’écriture manuscrite sur iOS, garantissant que le bouton Approuver s’active correctement une fois que des caractères valides sont saisis.
4540392	Résumé : Les administrateurs voient par intermittence des erreurs HTTP 400 et les groupes de destinataires apparaissent comme manquants dans les workflows, et ce, même si les groupes existent et l’accès est correctement configuré. Cela est dû à des en-têtes de requête dépassant la limite de taille d’en-tête de la plateforme lorsque les utilisateurs appartiennent à un grand nombre de groupes.
4540392	Correctif : La limite de taille d’en-tête de requête côté serveur a été augmentée afin que les recherches de groupe de destinataires n’échouent plus lorsque les utilisateurs appartiennent à de nombreux groupes.
4541258	Résumé : Les administrateurs ne pouvaient voir que les 100 premiers modèles dans l’interface utilisateur de synchronisation Production ou Sandbox. Les modèles supplémentaires étaient absents dans les listes locales et distantes, car la page de synchronisation chargeait un ensemble de données limité et la fonction de recherche filtrait uniquement les modèles déjà chargés dans le navigateur.
4541258	Correctif : L’interface utilisateur de synchronisation a été mise à jour afin que la saisie de texte dans le champ de recherche charge tous les modèles pour l’environnement sélectionné (jusqu’à 5 000), garantissant que les modèles au-delà des 100 premiers puissent être recherchés et sélectionnés.
4541739	Résumé : Les destinataires remplacés n’avaient pas accès à la signature numérique et voyaient le message « L’accord ne peut pas être signé numériquement, car il n’est pas en phase de signature numérique ». Cela était dû à l’échec du workflow à faire passer les futurs signataires remplacés dans la phase de signature numérique lorsque des champs de signature numérique étaient présents.
4541739	Correctif : Le processus de signature a été mis à jour pour faire passer correctement les destinataires remplacés ou délégués dans la phase de signature numérique lorsque des champs de signature numérique existent, leur permettant de signer et de terminer l’accord.
4541849	Résumé : Les champs de texte à taille de police automatique sur une seule ligne préremplis avec des caractères multioctets étaient tronqués dans les fichiers PDF signés, provoquant la coupure d’une partie du texte en raison d’un dimensionnement de texte incorrect lors du rendu PDF.
4541849	Correctif : Correction de la mesure de texte et du comportement de la taille de police automatique pour les caractères multioctets afin que la valeur complète s’adapte dans le champ sans troncature.
4542574	Résumé : La modification d’un modèle de bibliothèque permettait aux champs de liste déroulante requis d’inclure des valeurs non appariées, provoquant l’indisponibilité du bouton Cliquer pour signer lors de la signature lorsque ces valeurs étaient sélectionnées. Cela était dû à l’absence d’une validation qui garantissait que les valeurs d’affichage de liste déroulante et les valeurs d’exportation restaient correctement appariées.
4542574	Correctif : La modification de modèle applique désormais la validation sur les champs de liste déroulante afin que seules les valeurs correctement appariées puissent être enregistrées, évitant les entrées non appariées et garantissant que les sélections de liste déroulante requises ne bloquent pas la signature.
4542942	Résumé : Dans les formulaires web, les champs requis désactivés par la logique conditionnelle continuaient d’afficher l’astérisque obligatoire, induisant en erreur les signataires en leur faisant penser qu’une saisie était encore requise. Cela était dû au fait que l’interface utilisateur ne mettait pas à jour les indicateurs obligatoires lorsque les champs étaient désactivés. Un problème distinct d’alignement de signature mobile a été identifié mais traité dans une portée différente.
4542942	Correctif : L’interface utilisateur du formulaire web masque désormais l’astérisque obligatoire lorsqu’un champ est désactivé par la logique conditionnelle, garantissant que les indicateurs obligatoires reflètent précisément si une saisie du signataire est attendue.
4543157	Résumé : Dans la vue En cours de la page Gérer, la colonne Destinataires continuait d’afficher le nom du délégant après qu’un rôle de signature avait été délégué, même si un signataire différent signait activement, car l’interface utilisateur ne mettait pas à jour le destinataire affiché pour refléter le délégataire actuel.
4543157	Correctif : La logique de la page Gérer a été mise à jour pour que la colonne Destinataires affiche désormais le nom du délégataire actif lorsqu’un rôle de signature est délégué, garantissant que la vue En cours reflète précisément qui signe actuellement.
4543253	Résumé : Dans l’expérience de workflow classique, les champs assignés aux témoins (signature, nom, date) disparaissaient après l’enregistrement d’un accord à l’état de brouillon, même si les champs existaient en arrière-plan, car la logique de rendu du brouillon échouait à restaurer les champs de témoin lorsque la progression était sauvegardée.
4543253	Correctif : La logique de rendu du brouillon a été corrigée pour préserver et afficher tous les champs assignés aux témoins après la sauvegarde de la progression, garantissant que les accords ouverts à l’état de brouillon conservent la même visibilité de champ que pendant la création et la signature.
4543513	Résumé : Les utilisateurs étaient bloqués pour envoyer des accords dans l’interface utilisateur web Sign avec l’erreur « Les paramètres régionaux sont non valides ou manquants », car la validation des paramètres régionaux appliquait incorrectement les règles de paramètres régionaux de niveau de l’API dans l’interface web lorsque les paramètres régionaux du groupe d’envoi différaient des paramètres régionaux du groupe principal hérité de l’utilisateur.
4543513	Correctif : La validation des paramètres régionaux a été corrigée pour que l’interface utilisateur web Sign résolve et accepte correctement les combinaisons valides de paramètres régionaux de groupe et d’utilisateur, empêchant les restrictions de paramètres régionaux API uniquement de bloquer l’envoi d’accords dans l’expérience web.
4543592	Résumé : Certains rapports d’audit affichaient « Destinataire authentifié avec Adobe Acrobat Sign » après « Document signé électroniquement » et « Accord terminé », car les événements étaient stockés avec des horodatages au niveau de la seconde, causant l’apparition dans le désordre des actions d’authentification et de signature se produisant dans la même seconde.
4543592	Correctif : La journalisation des événements d’audit a été mise à jour pour stocker et afficher les horodatages avec une précision à la milliseconde, garantissant que les événements d’authentification, de signature et de finalisation sont séquencés correctement dans le rapport d’audit.
4543617	Résumé : Créer un modèle à partir d’un accord lance l’expérience classique au lieu de la nouvelle expérience, même si la nouvelle expérience est celle définie par défaut, car l’action est encore dirigée vers le flux de création hérité.
4543617	Correctif : L’action « Créer un modèle à partir d’un accord » a été mise à jour pour s’ouvrir dans la nouvelle expérience, alignant le comportement de l’appel à l’action avec l’expérience utilisateur par défaut et évitant les changements de contexte inattendus pour les utilisateurs.
4544564	Résumé : Les champs masqués ajoutés ou mis à jour via l’API (visible:false) s’affichaient comme visibles dans l’expérience de signature électronique moderne. L’interface utilisateur de signature ignorait l’indicateur de visibilité du champ, permettant aux destinataires de voir des champs qui auraient dû rester masqués.
4544564	Correctif : Mise à jour de l’interface utilisateur de signature électronique moderne pour filtrer les champs avec visible:false dans la logique de rendu et de navigation, afin que les champs masqués ne s’affichent jamais et n’affectent pas le comportement de la page.
4544571	Résumé : L’option de diffusion WhatsApp était absente dans les paramètres d’envoi même si WhatsApp était activé pour le compte et disponible pendant l’envoi d’accords, ce qui causait un comportement incohérent et de la confusion pour les administrateurs.
4544571	Correctif : L’option de diffusion WhatsApp a été restaurée dans les paramètres d’envoi partout où la fonctionnalité est disponible, garantissant une visibilité et une configuration cohérentes entre les paramètres administrateur et l’expérience d’envoi d’accord.
4545381	Résumé : La police Roboto était absente dans la nouvelle expérience Demander une signature, même si elle était disponible dans l’expérience classique, car la nouvelle expérience de création n’incluait pas toutes les polices prises en charge par l’ancienne version.
4545381	Correctif : Roboto a été ajoutée à la liste des polices dans la nouvelle expérience Demander une signature, restaurant la parité des polices avec l’expérience classique et permettant un formatage cohérent lors de la création d’accords.
4545484	Résumé : Certains administrateurs ne pouvaient pas accéder à des groupes de destinataires ou en créer depuis Admin > Carnet d’adresses en raison d’un échec de requête d’arrière-plan, ce qui causait une erreur 400 lors du chargement des données de groupe de destinataires. Le problème bloquait la configuration initiale des groupes de destinataires pour les administrateurs affectés.
4545484	Correctif : La gestion des requêtes d’arrière-plan a été corrigée pour que la recherche et la création de groupes de destinataires n’échouent plus avec une erreur 400. Les administrateurs peuvent désormais accéder de manière fiable aux groupes de destinataires et les gérer, quel que soit le réseau ou l’emplacement.
4545547	Résumé : Les accords créés à partir de PDF AutoCAD n’ont pas pu être envoyés lorsqu’un champ de signature numérique a été ajouté, affichant une erreur d’envoi générique, car le système ne gérait pas correctement la rotation de page lors de la validation du placement du champ de signature numérique.
4545547	Correction : Les coordonnées du champ de signature numérique sont désormais ajustées pour tenir compte des pages pivotées, garantissant que les champs sont validés par rapport aux limites de page correctes afin que les PDF générés par AutoCAD puissent être envoyés avec succès avec des signatures numériques.
4545894	Résumé : Lorsqu’un groupe de destinataires est utilisé et qu’aucun champ de signature n’est placé manuellement, le bloc de signature généré automatiquement affiche le texte de l’adresse e-mail dans une taille très petite. La taille du texte réduit progressivement à mesure que davantage de destinataires sont ajoutés au groupe.
4545894	Correctif : Le bloc de signature généré automatiquement affiche désormais correctement les adresses e-mail dans une taille normale et lisible, quel que soit le nombre de destinataires inclus dans le groupe de destinataires.
4546085	Résumé : Lors de l’utilisation de l’option M’ajouter dans la nouvelle expérience Demander une signature, les adresses e-mail contenant une apostrophe ne s’affichent pas correctement. L’adresse mal formée empêche l’envoi de l’accord à moins que l’adresse e-mail ne soit saisie à nouveau manuellement ou que l’Envoi classique ne soit utilisé.
4546085	Correctif : Les adresses e-mail avec des apostrophes sont désormais correctement décodées et affichées lorsque l’option M’ajouter est sélectionnée dans la nouvelle expérience Demander une signature, permettant l’envoi des accords sans correction manuelle.
4546110	Résumé : Dans l’expérience de création Nouveau modèle, l’ajout d’un champ Lien hypertexte attribué à un participant spécifique entraîne l’échec de l’enregistrement du modèle. Le même champ fonctionne lorsqu’il est attribué à tous les participants ou lors de l’utilisation de l’expérience classique.
4546110	Correctif : Les champs de lien hypertexte prennent désormais en charge les attributions d’espace réservé aux participants dans la nouvelle expérience de création de modèle, permettant l’enregistrement correct des modèles lorsque le champ est attribué à un participant spécifique.
4546257	Résumé : Dans l’environnement Sandbox, les accords envoyés via une API d’application personnalisée affichent incorrectement un bouton Retour sur la page de création en raison du chargement par le Sandbox des paramètres d’une application gérée par Adobe avec la création transparente activée, contrairement à l’environnement Swagger ou Production.
4546257	Correctif : Le comportement du Sandbox a été aligné sur les environnements Production et Swagger en s’assurant que la page de création respecte les paramètres d’application prévus, ce qui empêche l’apparition du bouton Retour pour les accords envoyés via les API d’applications personnalisées.
4546547	Résumé : Les formulaires web échouaient à mettre à jour le contre-signataire et renvoyaient une erreur aléatoire en raison d’anciens enregistrements utilisateur auxquels il manquait un indicateur interne obligatoire, ce qui provoquait le traitement d’une valeur nulle lors du remplacement du contre-signataire.
4546547	Correctif : La logique de mise à jour du contre-signataire a été renforcée avec une gestion sécurisée des valeurs nulles afin que les formulaires web puissent remplacer avec succès les contre-signataires même lorsque les anciens enregistrements utilisateur ne disposent pas de l’indicateur interne attendu.
4546553	Résumé : Les utilisateurs attribués à plusieurs groupes pouvaient créer des modèles dans un groupe où la création de modèle était désactivée lorsque la nouvelle expérience Créer un modèle était activée. Cela permettait de contourner les restrictions au niveau du groupe.
4546553	Correctif : La création de modèle applique désormais les autorisations au niveau du groupe de manière cohérente dans les expériences nouvelle et classique. Les utilisateurs ne peuvent plus créer de modèles dans les groupes où la création de modèle est désactivée, même s’ils appartiennent à d’autres groupes dans lesquels cette autorisation est activée.
4547744	Résumé : Les administrateurs de groupe pouvaient attribuer des droits d’administrateur de compte aux utilisateurs via la nouvelle page Gestion des utilisateurs. Cela dépassait leur portée d’autorisation et créait un risque de conformité en permettant l’élévation de privilèges au-delà du rôle d’administrateur de groupe.
4547744	Correctif : Le contrôle de la sélection des rôles n’est plus disponible pour les administrateurs de groupe. Seuls les administrateurs de compte existants peuvent attribuer ou révoquer les droits d’administrateur de compte, garantissant que les changements de rôle sont conformes aux limites d’autorisation.
4547796	Résumé : Certains expéditeurs utilisant l’interface utilisateur polonaise reçoivent occasionnellement un e-mail de confirmation avec un texte « ne peut pas fournir une signature numérique » incorrect, même si l’accord est envoyé et signé normalement.
4547796	Correctif : Correction des traductions polonaises pour les e-mails de confirmation de l’expéditeur afin que le message affiche « envoyé pour signature » au lieu du texte incorrect « ne peut pas fournir une signature numérique ».
4548315	Résumé : Lorsque l’expéditeur est inclus comme destinataire en copie dans le nouveau workflow d’envoi, aucune erreur de validation n’est affichée et les notifications par e-mail en copie ne sont pas envoyées aux destinataires répertoriés après l’expéditeur dans la liste des copies. Cela diffère du comportement du workflow classique et peut faire manquer les notifications aux destinataires en copie.
4548315	Correctif : Mise à jour de la nouvelle logique du workflow d’envoi pour que tous les destinataires en copie, à l’exception de l’expéditeur, reçoivent des notifications par e-mail en copie, quelle que soit leur position dans la liste des destinataires en copie, alignant ainsi le comportement sur les résultats attendus.
4548583	Résumé : PDF/A ne pouvait pas être activé pour un groupe si le groupe par défaut de l’utilisateur avait les signatures manuscrites activées, même lorsque les signatures manuscrites étaient désactivées pour le groupe en cours de modification. Cela bloquait la configuration pdf/A valide pour les groupes non par défaut.
4548583	Correctif : Mise à jour de la validation pour vérifier les paramètres de signature manuscrite du groupe en cours de modification, et non du groupe par défaut de l’utilisateur, permettant d’activer correctement PDF/A lorsque cela est autorisé.
4549337	Résumé : Les notifications SMS pour les accords annulés étaient supprimées lorsque le paramètre Accord par e-mail annulé était désactivé. Cela empêchait les clients qui désactivent les notifications par e-mail d’envoyer les alertes d’annulation par SMS requises.
4549337	Correctif : Découplage des notifications d’annulation par SMS et WhatsApp du paramètre d’e-mail en introduisant un contrôle de notification dédié, permettant l’envoi de SMS pour les accords annulés même lorsque les notifications par e-mail sont désactivées.
4549472	Résumé : Dans Acrobat Sign pour l’administration, les utilisateurs ne pouvaient pas créer de modèles réutilisables en utilisant la nouvelle expérience Créer un modèle. Après avoir téléchargé un document, le workflow se bloquait sur un écran vide, empêchant la création du modèle.
4549472	Correctif : Restauration de la dépendance de création manquante requise par la nouvelle expérience Créer un modèle dans les environnements Administration, permettant de charger l’écran de création correctement et de créer des modèles.
4549862	Résumé : Lorsque la page de destination est définie sur la nouvelle expérience Demander une signature, le message d’avertissement de connexion configuré ne s’affiche pas après la connexion. Cela empêche les organisations d’afficher des avis critiques de maintenance ou de perturbation lorsque les utilisateurs arrivent directement sur la page d’envoi.
4549862	Correctif : Restauration de la prise en charge de l’affichage du message d’avertissement de connexion dans la nouvelle expérience Demander une signature. Lorsque les utilisateurs arrivent sur la page d’envoi après la connexion, le message d’avertissement configuré apparaît maintenant comme une notification, ce qui correspond au comportement précédent et aux attentes des clients.
4550175	Résumé : Appuyer sur Entrée après avoir saisi un numéro de téléphone pour l’authentification téléphonique dans un workflow soumet prématurément le formulaire et déclenche une erreur système, interrompant le flux car le formulaire est soumis alors qu’une confirmation explicite devrait être attendue.
4550175	Correctif : Mise à jour de la boîte de dialogue du destinataire pour empêcher la soumission du formulaire après avoir appuyé sur Entrée pour les champs d’authentification téléphonique, ce qui garantit que les utilisateurs restent sur la boîte de dialogue et doivent cliquer sur Continuer, et élimine l’interruption involontaire du workflow.
4550302	Résumé : Les e-mails allemands de demande de signature et de rappel utilisaient des façons de s’adresser aux destinataires incohérentes, alternant entre l’informel « Du » et le formel « Sie » dans le même message, ce qui causait une formulation déroutante et non professionnelle.
4550302	Correctif : Mise à jour des traductions des e-mails allemands pour utiliser une façon de s’adresser aux destinataires unique et cohérente dans tout le modèle, garantissant un langage uniforme et prévisible dans tous les e-mails de demande de signature et de rappel.
4550556	Résumé : Les accords contenant des PDF volumineux avec des plans architecturaux échouaient à l’envoi lorsque des champs de signature numérique étaient ajoutés, renvoyant une erreur lors de la création en raison de la rotation de page et de la gestion de la taille dans le placement de signature numérique.
4550556	Correctif : Mise à jour du traitement des champs de signature numérique pour gérer correctement les pages pivotées de grand format, permettant aux accords avec des plans architecturaux d’être envoyés avec des signatures numériques appliquées.
4550579	Résumé : Lorsqu’un accord était terminé en supprimant les derniers destinataires restants à l’état de révision, le système ne générait pas l’événement AGREEMENT_WORKFLOW_COMPLETED, donc aucune notification webhook n’était envoyée, interrompant les workflows qui s’appuyaient sur cet événement pour détecter l’achèvement.
4550579	Correctif : Mise à jour de la gestion des événements pour que les accords terminés via la suppression de destinataires en révision génèrent les événements d’achèvement appropriés, garantissant que les webhooks AGREEMENT_WORKFLOW_COMPLETED sont déclenchés comme prévu.
4550998	Résumé : Les cases à cocher préremplies apparaissaient cochées lors de la création mais étaient décochées pour les signataires car les valeurs des cases à cocher étaient stockées comme des chaînes de texte non vides au lieu d’états YES/NO explicites, de sorte que l’expérience de signature les traitait comme décochées.
4550998	Correction : Mise à jour de la gestion des valeurs de case à cocher pour que toute valeur préremplie non vide soit interprétée comme cochée et les valeurs vides ou manquantes comme décochées, garantissant que les états des cases à cocher demeurent cohérents pour les signataires.

Adobe Acrobat Sign version v17.0.1

Déploiement en production : le 17 mars 2026

Déploiement sur GovCloud : 19 mars 2026

Fonctionnalité améliorée

Créer une copie : points d’accès étendus, réutilisation plus rapide des accords
Créer une copie est maintenant disponible directement depuis les filtres En cours et En attente de votre action sur la page Gérer, ainsi que depuis la page de confirmation post-envoi. Ces points d’entrée supplémentaires facilitent la réutilisation des accords à plus de moments du cycle de vie d’envoi, ce qui réduit le besoin de recommencer depuis le début.
Remarque : avec cette version, les contrôles administratifs pour désactiver cette fonctionnalité seront supprimés du menu administrateur, faisant de Créer une copie une fonctionnalité standard disponible pour tous les utilisateurs éligibles.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Compte et Groupe ; activée par défaut.

Modifications de l’expérience

Visibilité de l'expiration des clés d'intégration – Les dates d'expiration sont maintenant affichées dans l'onglet Jetons d'accès
L'onglet Jetons d'accès, dans le menu Préférences personnelles, affiche la date d'expiration pour chaque clé d'intégration. Cela donne aux utilisateurs et administrateurs une visibilité plus claire sur l’ancienneté des clés et la temporalité de remplacement, facilitant la surveillance des clés existantes et évitant les interruptions inattendues lorsqu’une clé atteint la fin de sa période de validité de 10 ans.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : API

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.

Affichage d’e-mail personnalisé OEM 2.0 : identité plus claire de l’expéditeur et du destinataire dans les expériences intégrées, et diffusion d’e-mails correcte
Pour les partenaires OEM 2.0 utilisant des workflows intégrés, Acrobat Sign peut maintenant afficher l'adresse e-mail personnalisée d'un utilisateur au lieu de l'e-mail enregistré du partenaire dans les surfaces d'interface utilisateur et notifications clés. Les accords, les files d’attente telles que « En attente de votre intervention » et les adresses e-mail « Vérifier et signer » reflètent de manière cohérente l’identité personnalisée tout en préservant l’adresse e-mail enregistrée en interne pour l’authentification et les droits. Cela améliore la clarté pour les expéditeurs et signataires et empêche l'envoi d'e-mails vers des adresses enregistrées non délivrables.

Environnements disponibles : Sandbox, Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de configuration : API - Partenaires OEM 2.0 ; sur demande uniquement

Notification webhook pour les échecs de diffusion de SMS : visibilité en temps réel des échecs d’envoi de SMS, correction automatisée et parité avec les e-mails renvoyés
Acrobat Sign émet maintenant un nouvel évènement webhook, AGREEMENT_PHONE_BOUNCED, lorsqu'un accord envoyé via SMS ne peut pas être livré en raison de problèmes tels que des numéros de téléphone non valides, un rejet de l'opérateur ou des lignes bloquées. Cela permet aux clients de détecter les échecs de diffusion SMS en temps quasi réel et de déclencher automatiquement des actions de suivi comme corriger les numéros de téléphone, reprendre la diffusion ou ouvrir des cas de support, éliminant les angles morts et réduisant les délais dans les workflows de signature axés sur le mobile.

Environnements disponibles : Sandbox, Commercial, Government | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de configuration : API

Charges utiles de webhook : ajout du champ conditionnel extendedStatus pour les participants pour des mises à jour de participation dynamiques et une amélioration de la visibilité de l’état des participants
Les notifications webhook incluent désormais un champ extendedStatus dans chaque objet participant (memberInfos[]) lorsque l'expéditeur modifie un accord en cours à l'aide de la participation dynamique. Ce champ fournit des détails supplémentaires sur le cycle de vie des participants tout en laissant le champ de statut existant inchangé pour la compatibilité descendante.

Valeurs de status (inchangées) : ACTIVE, REPLACED.
Valeurs d’extendedStatus : ACTIVE, REPLACED, REMOVED, COMPLETED.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : API

Problèmes résolus

Problème	Description
4543515	Résumé : un évènement de renvoi d’e-mail webhook peut être généré de manière incorrecte pour un signataire valide après que le signataire a signé et que l’accord passe à l’étape suivante. Cela peut se produire lorsqu’un délégataire dans le même groupe de signature a une adresse e-mail non valide et que l’expéditeur remplace le délégant d’origine. Dans ces cas, le système peut attribuer de manière incorrecte l’évènement de renvoi « signé au nom de… » au signataire valide au lieu du participant dont l’e-mail est vraiment renvoyé.
4543515	Correctif : la logique d’attribution d’évènement a été corrigée afin que les évènements de renvoi d’e-mail soient associés uniquement au participant dont l’e-mail est vraiment renvoyé. Un évènement de renvoi n’est plus généré pour un signataire valide qui a déjà terminé la signature, et les notifications webhook reflètent désormais le participant et l’adresse e-mail corrects.
4544548	Résumé : les clés d’intégration créées via l’interface d’utilisation web peuvent expirer après 10 ans, même si la page de création indique que la clé fournit un « accès permanent ». Lorsqu’une clé atteint sa durée de vie de 10 ans, les appels API commencent à renvoyer une erreur de jeton expiré, ce qui peut interrompre les intégrations existantes de manière inattendue.
4544548	Correctif : les messages de l’interface d’utilisation ont été mis à jour pour supprimer la formulation « accès permanent » et afficher clairement la date d’expiration des clés d’intégration. Le texte mis à jour indique maintenant que la clé conserve l’accès jusqu’à la date d’expiration ou jusqu’à ce qu’elle soit révoquée manuellement, offrant une transparence sur la durée de vie par défaut de 10 ans.
4546301	Résumé : la diffusion d’évènements webhook peut être retardée de plusieurs heures pour les accords avec des documents très volumineux, même lorsque la création de l’accord est terminée et que les premières étapes de traitement semblent s’effectuer en quelques minutes. Pendant ce délai, le service de diffusion webhook peut recevoir de manière répétée des réponses DOCUMENT_NOT_AVAILABLE lors de la tentative de récupération des documents d’accord, et l’évènement webhook peut ne pas être diffusé jusqu’à ce que le service arrête les tentatives ou que les documents deviennent disponibles.
4546301	Correctif : la gestion de la disponibilité des documents a été corrigée afin que les accords volumineux passent de manière fiable à un état où les documents sont récupérables sans réponses DOCUMENT_NOT_AVAILABLE prolongées. En conséquence, les événements webhook sont diffusés sans retards de plusieurs heures causés par les tentatives de récupération de documents contre des documents indisponibles.
4547823	Résumé : le message privé d’un destinataire peut ne pas s’afficher pour certains signataires lorsqu’un accord est créé dans l’état En création via l’API puis modifié depuis l’expérience Gérer. Dans ce scénario, l’interface d’utilisation peut afficher la valeur Message privé comme « Aucun » ou une valeur vide même si les données de l’accord incluent la valeur de message privé correcte. Ce comportement apparaît dans les scénarios de compte partagé où un utilisateur bascule sur le compte d’un autre utilisateur pour modifier le brouillon, et cela peut affecter uniquement des destinataires spécifiques tandis que d’autres s’affichent correctement.
4547823	Correctif : une vérification a été ajoutée pour récupérer le contexte de partage en cours et renvoyer le message privé pour les utilisateurs partagés autorisés. Par conséquent, la valeur Message privé s’affiche maintenant correctement lors de la consultation ou de l’envoi d’un brouillon créé par API depuis le flux En création.
4548274	Résumé : la date de modification pour les modèles de bibliothèque peut ne pas se mettre à jour après qu’un modèle est modifié et enregistré dans la nouvelle expérience de modèle. Les utilisateurs peuvent voir les champs nouvellement ajoutés ou mis à jour sur le modèle, mais la date de modification reste inchangée dans l’interface d’utilisation Gérer et dans les vues administratives. Par conséquent, il semble que le modèle n’a pas été modifié récemment. Cela se produit parce que la nouvelle expérience met à jour les champs de formulaire via un chemin d’accès qui ne met pas également à jour la date et l’heure de modification du modèle.
4548274	Correctif : le comportement de mise à jour de la date de modification a été aligné sur la nouvelle expérience de modèle et les opérations API associées. Le chemin d’accès au code qui enregistre les modifications de champ de modèle met maintenant également à jour la date de modification du modèle afin qu’elle reflète le moment réel de la modification la plus récente.
4548564	Résumé : les signatures et les champs de formulaire peuvent apparaître invisibles dans le PDF signé lorsqu’ils sont placés sur des annotations de tampon préexistantes dans le document source. Dans les modèles affectés, les annotations de tampon se chevauchent ou masquent les champs interactifs pendant le traitement, ce qui fait que les signatures terminées et les autres champs sont masqués dans le document signé final.
4548564	Correctif : la gestion des annotations de tampon a été mise à jour pour traiter et aplatir en toute sécurité les annotations de tampon préexistantes afin qu’elles ne masquent plus les champs de formulaire ou les signatures. Les champs placés sur les zones tamponnées restent désormais visibles tout au long de la signature et dans le PDF entièrement exécuté.
4549103	Résumé : un évènement de renvoi d’e-mail peut être enregistré à nouveau pour un destinataire précédemment incorrect après que l’expéditeur remplace ce destinataire par une adresse e-mail valide. Dans certains cas, le journal d’audit peut afficher un second évènement de renvoi pour l’ancien e-mail, et le statut de l’accord peut indiquer « E-mail renvoyé » même si le nouveau destinataire reçoit, consulte ou signe l’accord. Ce comportement peut laisser penser que l’accord cible encore les anciennes et nouvelles adresses e-mail.
4549103	Correctif : le processus de remplacement de signataire a été mis à jour pour empêcher l’envoi d’e-mails de notification supplémentaires à un destinataire remplacé dont l’e-mail a déjà été renvoyé. Le système vérifie maintenant l’historique des renvois avant d’envoyer des notifications liées au remplacement, s’assurant qu’aucun nouvel évènement de renvoi n’est généré pour l’ancienne adresse e-mail après le remplacement.
4549306	Résumé : les utilisateurs dont les adresses e-mail contiennent certains caractères spéciaux (par exemple, une apostrophe) peuvent être incapables de se connecter depuis les pages de connexion publiques génériques adobesign.com ou echosign.com. Après avoir saisi l'adresse e-mail et cliqué dans le champ mot de passe, la page peut se charger à nouveau et effacer le champ e-mail au lieu de rediriger l'utilisateur vers le fragment correct ou la page de connexion SSO. Cela empêche les utilisateurs affectés de terminer l'authentification et bloque les intégrations qui s'appuient sur le point d'entrée de connexion publique.
4549306	Correctif : la logique de résolution de fragment de connexion a été corrigée pour gérer et décoder correctement les adresses e-mail contenant des caractères spéciaux avant de créer l’URL de redirection inter-fragment. Les utilisateurs avec des formats d’e-mail affectés sont maintenant correctement redirigés vers leur fragment dédié et leur page de connexion SSO sans que le champ d’e-mail soit effacé.
4549331	Résumé : les signatures et autres champs de formulaire peuvent apparaître comme manquants ou invisibles dans le fichier PDF signé lorsque certaines fonctionnalités de traitement de document sont activées et que le PDF source contient des coordonnées de zone de page non valides (par exemple, des valeurs CropBox ou MediaBox incorrectes). Dans ce scénario, les champs qui dépendent des coordonnées de page peuvent s’afficher en dehors de la zone de page visible, faisant apparaître les signatures complétées comme manquantes même si la signature a bien été effectuée.
4549331	Correctif : la gestion des zones de page du fichier PDF a été corrigée pour normaliser en toute sécurité les valeurs CropBox et MediaBox non valides pendant le traitement de document. Par conséquent, l'emplacement des signatures et des champs de formulaire s'aligne maintenant sur la zone de page visible, et les PDF signés affichent les signatures comme prévu.
4550367	Résumé : la création d’un formulaire web peut échouer avec une erreur générique « Erreur de serveur » après avoir sélectionné Aperçu et Ajouter des champs lorsque l’authentification du signataire par défaut du groupe de l’expéditeur est définie sur Téléphone et que le compte ne dispose pas de quota d’authentification téléphonique disponible. Cela se produit même si la méthode d’authentification du signataire du formulaire web n’est pas le téléphone (par exemple, Adobe Sign). Par conséquent, tous les utilisateurs du compte affecté peuvent être bloqués dans la création de formulaires web sur tous les documents.
4550367	Correctif : la création de formulaires web évalue maintenant le quota uniquement pour la méthode d’authentification réellement configurée pour le signataire du formulaire web, et n’applique plus de vérifications de quota d’authentification téléphonique basées uniquement sur le paramètre d’authentification par défaut du groupe. Cela empêche les erreurs d’épuisement de quotas erronés et permet de créer des formulaires web normalement.
4551011	Résumé : lorsqu’un expéditeur charge certains fichiers PDF numérisés, ajoute des champs de signature et envoie l’accord, le PDF signé peut n’afficher aucune signature visible après la fin de l’étape de signature. Ce comportement peut se produire lorsque le PDF chargé contient des métadonnées de limites de page non valides (les coordonnées MediaBox et CropBox apparaissent inversées), ce qui peut faire que les calques d'apparence de signature et d'autres champs s'affichent en dehors de la zone de page visible.
4551011	Correctif : la gestion des limites de page des fichiers PDF est mise à jour pour traiter correctement les PDF avec des valeurs de coordonnées MediaBox et CropBox non valides ou inversées, de sorte que le contenu des signatures et des champs de formulaire s’affiche dans la zone de page visible et reste visible dans le PDF signé final.
4551427	Résumé : certains destinataires qui ont déjà des comptes actifs correctement approvisionnés reçoivent des accords en tant que destinataires « pseudo-utilisateur », de sorte que l’accord n’apparaît pas dans leur vue Gérer normale. Cela se produit lorsque les adresses e-mail des destinataires incluent des espaces au début ou à la fin, ce qui empêche le système de faire correspondre l’e-mail à l’utilisateur existant et provoque la création d’un enregistrement de pseudo-utilisateur.
4551427	Correctif : l’analyse d’e-mail et la recherche d’utilisateur ont été mises à jour pour normaliser les adresses e-mail des destinataires (suppression des espaces au début et à la fin), avant de les faire correspondre aux utilisateurs existants. Par conséquent, les accords adressés aux utilisateurs existants se résolvent vers le compte enregistré au lieu de créer un destinataire pseudo-utilisateur, même si l’e-mail a été saisi avec des espaces (dans les charges utiles d’API et les listes de destinataires des workflows).
4553198	Résumé : lorsqu’un accord inclut au moins un destinataire configuré pour la diffusion par SMS et au moins un destinataire configuré pour la diffusion par e-mail uniquement, l’annulation de l’accord via l’API n’entraîne pas d’envoi de notification d’annulation par SMS au destinataire des SMS. L'accord est annulé avec succès, et les notifications par e-mail sont diffusées, mais les destinataires SMS ne reçoivent pas de message d'annulation.
4553198	Correctif : le processus d’annulation a été corrigé pour s’assurer que les notifications d’annulation par SMS sont envoyées à tous les destinataires configurés pour la diffusion par SMS lorsqu’un accord est annulé, indépendamment des méthodes de diffusion des autres destinataires.
4554463	Résumé : lorsque les accords incluent des boutons radio clonés qui partagent le même nom de champ sur des documents combinés, seule une instance de l’option sélectionnée reste sélectionnée dans le PDF signé final. Bien que les champs apparaissent visuellement comme des cases à cocher, ils sont implémentés comme des boutons radio. Après la signature, la valeur sélectionnée ne se propage pas de manière cohérente sur toutes les instances clonées, causant un mappage incorrect ou incomplet de la sélection attendue.
4554463	Correctif : la logique de gestion des champs de formulaire a été corrigée pour que les boutons radio clonés stockent et propagent la valeur d’export sélectionnée plutôt qu’une valeur d’index interne. Cela garantit que toutes les instances clonées du même champ de bouton radio reflètent la sélection correcte dans le PDF signé.
4554593	Résumé : certaines intégrations de partenaires qui utilisent les points d’entrée OAuth hérités pour actualiser les jetons d’accès ont commencé à échouer avec des erreurs HTTP 401. Le service a refusé les demandes d’actualisation de jeton avec une erreur indiquant que l’application n’était pas autorisée à utiliser les points d’entrée OAuth hérités et qu’elle devait utiliser les points d’entrée OAuth v2. Cela a empêché les clients d’authentifier Acrobat Sign via les applications partenaires, même pour les intégrations qui fonctionnaient auparavant.
4554593	Correctif : le service d’authentification a été corrigé pour que les applications partenaires configurées pour utiliser le flux OAuth hérité puissent actualiser les jetons à nouveau, au lieu d’être incorrectement forcées vers les points d’entrée OAuth v2.
4554614	Résumé : lorsqu’un signataire utilise l’expérience de signature électronique moderne sur un accord qui nécessite une authentification du signataire et que sa configuration exige d’accepter les conditions d’utilisation avant la signature, cliquer sur Cliquer pour signer déclenche une redirection de 5 secondes vers l’expérience de signature classique. Le message de redirection avertit que les signatures et paraphes saisis dans la signature moderne seront effacés, forçant le signataire à les saisir à nouveau et à signer deux fois.
4554614	Correctif : le flux d’actualisation du jeton de signature a été corrigé pour que le jeton de signature réémis conserve les détails d’authentification du signataire lorsque le signataire accepte les conditions d’utilisation avant la signature. Cela empêche l’échec de l’authentification lors de l’étape finale de signature et élimine le basculement forcé de la signature moderne vers l’expérience classique.
4555656	Résumé : dans des conditions de temporalité spécifiques, une transition de l’état de l’accord peut sembler s’effectuer mais n’entraîne pas réellement de modification de l’état de l’accord. Lorsqu’une notification webhook est reçue avant que le traitement d’arrière-plan soit terminé, les appels API suivants peuvent utiliser des données de statut d’accord obsolètes. Dans cette fenêtre, certaines méthodes de transition d’état renvoient HTTP 200 OK même si l’accord ne présente pas un état valide pour la transition demandée. En conséquence, les workflows d’automatisation peuvent supposer que la transition a réussi alors que l’accord conserve l’état initial.
4555656	Correctif : la logique de transition d’état de l’accord a été mise à jour pour appliquer une validation stricte avant d’appliquer une transition. Si l’accord ne présente pas un état valide, l’API renvoie maintenant une réponse d’erreur claire au lieu de laisser penser que la transition est réussie. Cela garantit que les transitions non valides sont explicitement refusées, permettant aux systèmes appelants de réessayer de manière appropriée et empêchant les accords de rester dans un état non désiré sans visibilité sur ce dernier.

Adobe Acrobat Sign version v17.1

Déploiement en production : 5 mai 2026

Déploiement sur GovCloud : 12 mai 2026

Fonctionnalité améliorée

Signature en personne – Activez les sessions de signature hébergées dans l’application web
La Signature en personne permet à un expéditeur de désigner un hôte interne qui facilite une session de signature en personne à l’aide d’un navigateur web. L’hôte lance une session de signature contrôlée depuis la page Gérer ou une notification par e-mail, remet temporairement l’appareil au signataire pour qu’il effectue les actions requises, puis reprend le contrôle une fois terminé. La création et l'achèvement de session sont enregistrés dans la piste d'audit, et les signataires peuvent facultativement fournir une adresse e-mail pour recevoir une copie de l'accord.

Signature numérique en bloc depuis la page Gérer – Appliquez une signature numérique à plusieurs accords avec une seule autorisation
Les signataires peuvent sélectionner plusieurs accords dans la vue À traiter et appliquer des signatures numériques en tant qu’action groupée à l’aide d’une seule autorisation de signature. Cela réduit les étapes de signature répétitives pour les processus à volume élevé tout en préservant la sécurité, l’authentification et les contrôles d’audit de signature cloud existants. La signature en bloc nécessite que les signataires révisent ou ignorent tous les accords avant de finaliser l’action groupée.

Envoyer uniquement aux destinataires internes – Limitez l’envoi des accords aux destinataires du même compte Acrobat Sign.
Le paramètre Envoyer uniquement aux destinataires internes empêche les utilisateurs d’envoyer des accords à des destinataires extérieurs à leur compte Acrobat Sign. Lorsqu’il est activé, les accords ne peuvent être envoyés qu’aux destinataires dont les ID de compte correspondent à celui de l’expéditeur. Ce contrôle prend en charge les exigences de sécurité internes et empêche le partage externe des accords.

Rapports d’utilisation des transactions téléphoniques – Rapports étendus avec visibilité au niveau du groupe et accès aux rapports planifiés
Les rapports de transactions téléphoniques offrent désormais une visibilité sur les quantités achetées, les dates de début de quota et la consommation détaillée des transactions SMS et WhatsApp. Les clients peuvent suivre l’utilisation au niveau du groupe et accéder aux rapports CSV programmés via une expérience de création de rapports unifiée, permettant une budgétisation plus précise, une affectation interne et une surveillance proactive pour éviter les interruptions de service lorsque les limites de transaction sont atteintes.
La création de rapports est désormais générée par le biais de rapports planifiés dans l'interface de création de rapports, avec un accès API disponible pour récupérer la dernière sortie de rapport.

Nouveau point d'entrée : POST /api/rest/v6/reportDownload
Ce point d'entrée accepte un scheduleId et retourne l'URL de téléchargement pour le rapport CSV le plus récemment généré associé à cette planification.

Modifications de l’expérience

Apparence de signature dans les rapports d’audit – Enregistre la méthode de saisie de signature utilisée par chaque signataire, améliorant la visibilité de la conformité et réduisant la vérification manuelle
Les rapports d’audit enregistrent désormais la méthode d’apparence de signature utilisée lorsqu’un signataire applique sa signature. Pour chaque évènement ESIGNED, le journal d’audit indique si le signataire a utilisé une signature tapée, une signature manuscrite, une image chargée ou une capture d’image/de signature manuscrite sur mobile. Cette amélioration permet aux équipes de conformité et d’opérations de vérifier les méthodes de signature directement depuis le rapport d’audit, réduisant ainsi toute ambiguïté et évitant les rejets d’accords inutiles.
Types d’apparence de signature :
- Saisir : le signataire saisit son nom et sélectionne un style de signature fondé sur une police.
- Tracer : le signataire trace sa signature à l’aide d’une souris ou d’un pavé tactile sur un poste de travail.
- Image : le signataire charge un fichier image de signature depuis le poste de travail.
- Tracer sur mobile : le signataire trace sa signature en utilisant la fonction tactile sur un appareil mobile.
- Image mobile : le signataire charge ou capture une image de signature sur un appareil mobile.

Signatures sauvegardées pour les URL de signature API – Permet l’utilisation des signatures de profil sauvegardées lors de la signature basée sur l’API
Permet aux utilisateurs enregistrés d’appliquer leurs signatures de profil sauvegardées lors de la signature d’accords via des URL de signature générées par API (GET /agreements/{agreementId}/signingUrls). Les signatures enregistrées apparaissent pour les signataires internes et pour les signataires externes qui s’authentifient à l’aide d’un mot de passe à usage unique par e-mail ou d’Adobe ID. Cette capacité rationalise les processus de signature pour les intégrations backend tout en maintenant les contrôles de sécurité au niveau du compte.
Activé par Adobe sur une base par compte après examen de sécurité.

Gestion du carnet d'adresses personnel dans l'expérience moderne – Les utilisateurs peuvent supprimer les adresses e-mail sauvegardées directement depuis leur carnet d'adresses personnel dans l'expérience moderne Demander une signature , facilitant le maintien de listes de destinataires personnelles précises et à jour.

Fenêtre d’expiration des accords – Période d’expiration par défaut étendue à 365 jours
La date limite maximale d’achèvement des accords a été étendue de 180 jours à 365 jours. Lorsque l’expiration de document est activée, les accords se voient désormais automatiquement attribuer une date d’expiration de 365 jours qui ne peut pas être supprimée. Ce changement garantit que tous les accords ont un cycle de vie défini, améliore le suivi à long terme et la conformité, et réduit le risque que les accords restent ouverts indéfiniment tout en permettant aux utilisateurs de fixer des échéances plus précoces lorsque nécessaire.

Page Accueil remaniée – Améliore l’accès aux workflows, met en évidence les actions critiques
La page Accueil a été repensée pour faciliter le démarrage des accords, surveiller l’activité et accéder aux fonctionnalités clés, notamment la possibilité de copier les accords récemment envoyés, d’afficher les vignettes d’action dans un ordre plus intuitif, d’identifier rapidement les éléments En cours et À traiter, et de bénéficier d’une bannière Nouveautés rationalisée qui réduit l’encombrement visuel, aidant les utilisateurs à aller plus vite, à réduire les accords manqués et à naviguer dans une expérience Accueil plus ciblée.

La nouvelle page Accueil sera déployée sur 10 jours après la publication de la nouvelle version. Consultez l'avis technique pour le planning.

Améliorations de la version d’essai - La dernière expérience d’intégration a été ajoutée à la version d’essai de Sign.
L'essai Sign inclut désormais l'expérience d'intégration améliorée et les fonctionnalités introduites dans les versions payantes récentes.

Le nouveau concepteur de processus personnalisé devient par défaut – Promouvoir le concepteur moderne, supprimer les contrôles de commutation utilisateur, conserver la flexibilité administrateur
L'expérience du nouveau concepteur de processus personnalisé est désormais par défaut pour tous les comptes. Les utilisateurs ne voient plus les liens de bascule permettant de revenir au concepteur classique, tandis que les administrateurs conservent la capacité de réactiver l’accès à l’expérience précédente si nécessaire. Cette mise à jour fait progresser la transition vers l'interface de conception de workflow moderne tout en préservant le contrôle administratif pendant la période de transition.

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.

Gestion des clés mTLS pour les webhooks – Ajoutez l’option de clé générée par Acrobat Sign, activez le workflow de signature de certificat, améliorez la conformité de sécurité
Les développeurs peuvent maintenant choisir la façon dont les clés privées sont gérées pour l’authentification mTLS des webhooks dans Acrobat Sign. En plus du modèle existant où les clients génèrent et chargent leur propre clé privée et certificat, Acrobat Sign peut maintenant générer la clé privée et une CSR. Les clients peuvent utiliser la CSR pour obtenir un certificat de leur autorité de certification et le charger pour compléter la configuration. Cette option améliore la sécurité en conservant les clés privées dans Acrobat Sign tout en maintenant la compatibilité avec le comportement mTLS des webhooks existants.

Initialisation d’identité numérique via le paramètre login_hint – Permet aux expéditeurs d’API d’initialiser l’authentification d’identité numérique avec un identifiant de connexion spécifique au destinataire.
Plusieurs points d'entrée /agreements de l'API REST v6 prennent désormais en charge un paramètre loginHint qui permet aux expéditeurs d'API d'initialiser l'authentification Digital Identity Gateway à l'aide d'un identifiant de connexion connu, tel qu'une adresse e-mail ou un numéro d'ID utilisateur. Le fournisseur d’identité contrôle l’expérience client, mais l’identifiant pré-remplit généralement l’écran de connexion pour renforcer les workflows d’authentification à haut niveau de confiance et réduire le risque d’usurpation d’identité. L’identifiant apparaît sous forme masquée sur la page de destination Digital Identity Gateway et dans le rapport d’audit pour préserver la traçabilité tout en protégeant les données sensibles.
Les points d’entrée suivants ont été mis à jour pour inclure le paramètre loginHint :
- POST /agreements
- PUT /agreements/{agreementId}
- PUT /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}
- GET /agreements/{agreementId}/members/participantSets/{participantSetId}
- GET /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}/members

Améliorations de la limite d'identité et de confiance OEM 2.0 – La fonctionnalité « Afficher l'adresse e-mail personnalisée/OEM partout » donne désormais la priorité aux utilisateurs provisionnés par le même partenaire et crée automatiquement un destinataire lorsqu'aucune correspondance n'est trouvée
Lorsque la fonctionnalité Afficher l'adresse e-mail personnalisée/OEM partout est activée, la résolution des participants aux accords donne la priorité aux utilisateurs provisionnés par le même partenaire et crée automatiquement un enregistrement de destinataire lorsqu'aucun utilisateur correspondant n'existe, garantissant une gestion cohérente de l'identité sur tous les comptes.

De plus, avec Afficher l'e-mail personnalisé/OEM partout activé, les rapports d'audit indiquent si un expéditeur est provisionné par un partenaire ou un compte personnel, et les flux de signataires guident les utilisateurs pour changer de compte lorsque des adresses e-mail identiques existent sur différents types de comptes, réduisant la confusion et empêchant l'accès non intentionnel.

Problèmes résolus

4520028	Résumé : la colonne Groupe de la page Gérer affichait des valeurs incorrectes ou incohérentes lorsque les utilisateurs appartenaient à plusieurs groupes. Modifier le groupe principal de l’utilisateur entraînait l’affichage du mauvais groupe pour les accords, y compris le dernier groupe principal sélectionné ou plusieurs groupes, au lieu du groupe à partir duquel l’accord avait été initialement envoyé.
Problème	Description
4520028	Correctif : mise à jour de la logique de la page Gérer pour utiliser le groupe d’envoi de l’accord (agreement_group_id) au lieu du groupe principal actuel de l’utilisateur lors du rendu de la colonne Groupe.
4532690	Résumé : les utilisateurs ne pouvaient pas modifier les projets d’accord créés à partir de workflows personnalisés lorsque les options « Activer l’envoi des accords uniquement à l’aide d’un workflow » et « Activer le nouvel environnement d’envoi du workflow personnalisé » étaient activées. Le système a bloqué à tort l’accès à la page de composition lors de la modification d’un brouillon existant, le traitant comme une nouvelle action d’envoi au lieu d’une modification de brouillon.
4532690	Correctif : mise à jour de la logique de la page Composer pour détecter les scénarios de modification de brouillon et contourner la vérification de restriction de workflow, permettant aux utilisateurs de modifier les projets d’accord existants créés à partir de workflows personnalisés.
4536764	Résumé : l’envoi d’accords via un workflow personnalisé a entraîné une erreur serveur due à un échec du traitement de certains modèles PDF. L’erreur a été causée par des données d’apparence d’annotation non valides ou manquantes dans un ou plusieurs documents source, ce qui a déclenché une exception de rendu pendant le préremplissage. Le problème n’était pas reproductible de manière cohérente et n’a pas pu être répliqué en dehors des workflows affectés.
4536764	Correctif : amélioration de la gestion des exceptions de rendu dans la couche de traitement des PDF.
4537197	Résumé : lors de l’utilisation de la nouvelle expérience Envoi en masse avec des noms de destinataire saisis manuellement, le deuxième champ de nom était supprimé pendant la signature en raison de la gestion incorrecte des données de nom de destinataire requises d’un document à l’autre.
4537197	Correctif : mise à jour de la logique de traitement des documents pour conserver correctement tous les champs de nom de destinataire lors de l’envoi d’accords en masse.
4538172	Résumé : la copie de workflows incluant des groupes de destinataires échouait pendant la synchronisation sandbox avec le message « Erreur d’exécution de la demande » en raison de références de groupe de destinataires non valides. Le workflow utilisait des ID de groupe de destinataires spécifiques à l’environnement, qui ne sont pas portables entre les environnements, ce qui a provoqué l’échec de la validation pendant la synchronisation.
4538172	Correctif : mise à jour de la gestion de la synchronisation Sandbox pour valider et traiter correctement les références de groupe de destinataires pendant les opérations de copie de workflow, empêchant les échecs lorsque les groupes de destinataires existent dans les deux environnements.
4538251	Résumé : dans la nouvelle expérience Envoi en masse, les champs d’informations de nom complet et d’e-mail du signataire n’apparaissaient pas lors de la signature ni dans le document final lorsque le fichier source contenait des champs AcroForm existants. Le problème était causé par une gestion incorrecte des données de champs de fusion lors de la combinaison des champs d’informations du signataire avec des champs de formulaire préexistants, ce qui entraînait le non-affichage des champs dans les accords enfants.
4538251	Correctif : mise à jour de la logique de traitement des champs de fusion et de formulaire pour appliquer correctement les champs d’informations de signataire dans les documents incluant des champs AcroForm existants.
4545485	Résumé : la création d’accord échouait par intermittence lorsque la génération de miniatures rencontrait des champs de formulaire PDF malformés. L’échec était provoqué par des documents source contenant des champs de formulaire sans noms valides et des structures de champs imbriqués non valides, ce qui déclenchait des erreurs de traitement pendant la génération de PDF.
4545485	Correctif : ajout de validation et de vérifications de valeurs nulles pendant le traitement PDF pour gérer les champs de formulaire malformés et empêcher les échecs pendant la génération de miniatures et la création d’accords.
4545814	Résumé : les champs son mal alignés et les balises de texte restent visibles lors du traitement de documents au format paysage générés à partir de workflows basés sur XDP. Des calculs de coordonnées incorrects dans les mises en page paysage entraînent un placement incorrect des champs et empêchent l’analyse et la suppression correctes des balises de texte.
4545814	Correctif : mise à jour de la logique de rendu des champs pour calculer et placer correctement les champs de formulaire dans les documents au format paysage, assurant un alignement approprié et la suppression des balises de texte pendant le traitement.
4545978	Résumé : les caractères accentués des noms de signataire s’affichent de manière incorrecte dans le bloc de signature visible lors de l’utilisation de la signature numérique locale. Le problème se produit parce que la police par défaut intégrée dans le document ne dispose pas d’un encodage approprié pour les caractères d’Europe occidentale, causant une substitution de caractères incorrecte pendant le rendu de l’apparence de signature.
4545978	Correctif : mise à jour de la configuration des polices incorporées pour inclure un encodage approprié pour les caractères accentués, assurant le rendu correct des noms de signataire dans l’aspect de la signature
4547100	Résumé : les champs de texte multilignes clonés s’affichent de manière incohérente dans le PDF signé. Les champs clonés multilignes sont manquants dans le dictionnaire d’aspect par défaut, ce qui provoque l’affichage de moins de lignes dans les champs clonés que dans le champ source même si les deux champs utilisent la même taille et les mêmes paramètres.
4547100	Correctif : ajout du dictionnaire d’aspect par défaut aux champs clonés multilignes pour que les champs clonés et source s’affichent de manière cohérente dans les documents signés.
4548305	Résumé : la liste de contrôle d’intégration affiche « Demander un BAA pour la conformité à la loi HIPAA » défini sur En attente même lorsque la fonctionnalité HIPAA est activée. La logique d’évaluation de la liste de contrôle traite incorrectement les paramètres liés à HIPAA hérités comme incomplets, causant le maintien du statut de tâche En attente malgré l’activation de la fonctionnalité.
4548305	Correctif : mise à jour de la logique d’évaluation de la liste de contrôle pour interpréter correctement les paramètres liés à HIPAA, y compris les valeurs héritées, afin que la tâche d’intégration reflète l’état terminé lorsque HIPAA est activé.
4550731	Résumé : un grand espace apparaît entre le soulignement de la signature et la date et heure lors de la signature de documents à l’aide de l’outil Remplir et signer. Le problème se produit lorsque le champ de signature n’est pas assez large pour accueillir le contenu de signature généré, provoquant un espacement incorrect dans l’apparence de la signature
4550731	Correctif : mise à jour du rendu de signature pour respecter les dimensions de champ définies et ajuster l’espacement de manière appropriée, réduisant l’écart entre le soulignement et la date et heure.
4550906	Résumé : le lien Modifier le mot de passe pointe vers une URL non valide pour certains utilisateurs, provoquant une erreur de navigateur. Le problème se produit lorsque l’application lit un point d’entrée obsolète depuis la configuration au lieu de l’URL correcte, entraînant un comportement incohérent dans les environnements.
4550906	Correctif : mise à jour du point d’entrée de modification de mot de passe configuré pour utiliser l’URL correcte dans les environnements concernés.
4550992	Résumé : la modification de certains modèles dans la nouvelle expérience redirige vers la page Créer un modèle au lieu d’ouvrir le modèle en mode d’édition. Le problème se produit car le système détermine l’expérience en fonction des paramètres du propriétaire du modèle plutôt que des paramètres de l’utilisateur actuel, provoquant un routage incorrect lors de la modification de modèles partagés.
4550992	Correctif : mise à jour de la logique de modification de modèle pour utiliser les paramètres d’expérience de l’utilisateur actuel à la place des paramètres du propriétaire du modèle, assurant ainsi que les modèles s’ouvrent dans le mode de modification correct.
4551756	Résumé : les e-mails de demande d’approbation affichent des variables de modèle non résolues dans le champ de destinataire, provoquant une mise en forme incorrecte de l’e-mail. Le problème se produit en raison d’un échec dans la logique de rendu du modèle d’e-mail lors de la génération de notifications de conflit de droits.
4551756	Correctif : mise à jour du rendu des modèles d’e-mail pour résoudre et remplir correctement les champs de destinataire, garantissant que les adresses e-mail valides sont affichées dans les e-mails de demande d’approbation.
4551768	Résumé : les signataires rencontrent une erreur non gérée lors de l’ouverture ou de la finalisation des accords en raison d’un échec dans le traitement de l’aspect des champs de formulaire. Un objet d’aspect mal formé provoque une ClassCastException pendant la génération du document, entraînant un échec de rendu de l’accord.
4551768	Correctif : mise à jour de la logique de traitement des champs de formulaire pour valider les types d’objets d’aspect avant la conversion, empêchant ainsi les exceptions et garantissant que les accords s’affichent correctement pour la signature.
4552272	Résumé : les accords annulés ou abandonnés apparaissent sous À traiter sur la page Gérer. Le problème se produit lorsqu’un événement de redémarrage de workflow ne nettoie pas correctement les données de statut de participant, laissant des données de visibilité et d’indexation obsolètes qui font apparaître l’accord dans des vues incorrectes
4552272	Correctif : mise à jour de la logique d’indexation et de gestion de redémarrage de workflow pour effacer correctement les données de statut de participant antérieures et garantir que les accords n’apparaissent que dans leur état correct.
4553158	Résumé : dans les environnements de langue RTL sur iOS, le panneau de signature ne répond pas correctement lors du tracé d’une signature. Le panneau fait défiler au lieu de capturer la saisie, obligeant les utilisateurs à faire défiler manuellement pour dessiner et appliquer la signature, ce qui empêche le comportement de signature normal lorsque la nouvelle expérience de signature de destinataire est activée.
4553158	Correctif : mise à jour de la gestion d’interaction du panneau de signature pour les mises en page RTL sur iOS afin de capturer correctement le tracé sans défilement non intentionnel, permettant la création et l’application normales de la signature.
4553583	Résumé : les workflows autorisent les adresses e-mail contenant des espaces de début ou de fin, ce qui provoque l’échec silencieux des accords lors de l’envoi dans la nouvelle expérience. Le système ne valide ni ne normalise la saisie, et aucun message d’erreur n’est affiché pour indiquer le problème.
4553583	Correctif : mise à jour de la gestion de saisie pour rogner automatiquement les espaces des adresses e-mail et empêcher l’enregistrement de valeurs non valides, et ajout de la gestion pour les workflows existants afin que les accords puissent être envoyés avec succès.
4553676	Résumé : les liens hypertexte s’affichent de manière incorrecte dans la vue Gérer, où le titre de l’accord est ajouté à l’URL, ce qui entraîne des liens rompus. Le problème se produit en raison d’une analyse d’URL incorrecte lors du rendu des liens hypertexte dans l’interface Gérer.
4553676	Correctif : mise à jour du rendu des liens hypertexte pour utiliser une analyse d’URL appropriée, garantissant que les liens restent inchangés et fonctionnent correctement dans toutes les vues.
4555021	Résumé : la validation du mot de passe à usage unique échoue avec une erreur « expiré » même lorsque le code est saisi immédiatement. Le problème se produit en raison d’une condition de concurrence dans le flux d’authentification, où plusieurs événements de soumission entraînent l’invalidation prématurée de l’OTP.
4555021	Correctif : mise à jour du flux de validation du mot de passe à usage unique pour gérer correctement les événements de soumission en double ou rapides, empêchant l’expiration prématurée et permettant aux saisies de mot de passe à usage unique valides d’aboutir.
4555028	Résumé : la suppression du destinataire signataire suivant peut échouer avec une erreur système et entraîner le blocage de l’accord à l’état de révision en attente. Le problème se produit lorsque le destinataire a un rappel actif, ce qui empêche l’exécution de la mise à jour de l’accord.
4555028	Correctif : mise à jour de la logique de suppression des destinataires pour gérer les cas dans lesquels le signataire suivant a des rappels actifs, permettant l’exécution de la mise à jour de l’accord sans erreurs.
4555319	Résumé : les créateurs de formulaires web ne voient que les options de signature Saisir et Tracer lors de la prévisualisation du formulaire, tandis que les signataires voient toutes les options disponibles (Saisir, Tracer, Image, Mobile). Le problème se produit, car le mode Aperçu n’applique pas correctement les paramètres de saisie de signature activés lorsque le créateur n’agit pas en tant que signataire.
4555319	Correctif : mise à jour du comportement de prévisualisation des formulaires web pour appliquer l’ensemble complet des types de saisie de signature activés, garantissant ainsi que les créateurs voient les mêmes options de signature que les signataires.
4555345	Résumé : les accords comptant plusieurs destinataires Signataire avec témoin ne parviennent pas à s’ouvrir dans Aperçu depuis Brouillon avec l’erreur « ParticipantSetsInfo ne peut pas être modifié ». Le problème se produit en raison d’une logique d’ordre des participants et des témoins incorrecte dans les workflows personnalisés, ce qui empêche l’accord de revenir à l’état de création
4555345	Correctif : mise à jour de la logique d’ordre des participants et des témoins dans les workflows personnalisés pour calculer correctement l’ordre d’exécution, permettant aux accords de revenir à l’état de création et de se dérouler normalement.
4555615	Résumé : les payloads d’événement de webhook pour les destinataires délégués et remplacés n’incluent pas le champ privateMessage. Le problème se produit, car le message privé n’est pas propagé à l’état du destinataire utilisé pour générer les payloads de webhook, ce qui entraîne des données manquantes pour les événements concernés.
4555615	Correctif : mise à jour de la gestion des données des participants pour garantir que les messages privés sont inclus dans les payloads de webhook pour les destinataires délégués et remplacés.
4555687	Résumé : les accords peuvent être automatiquement annulés et déplacés vers un état masqué après signature en raison d’un échec de validation de visibilité du document. Lorsqu’un participant est délégué ou remplacé, le mappage de visibilité du document n’est pas correctement transféré, causant une incompatibilité entre les champs attribués et les documents visibles, ce qui peut déclencher une résiliation automatique.
4555687	Correctif : la logique de délégation et de remplacement clone maintenant correctement les mappages de visibilité de document pour les nouveaux participants, empêchant les échecs de validation et la résiliation non intentionnelle d’un accord.
4556516	Résumé : les champs de formulaire peuvent ignorer les tailles de police configurées et générer un rendu incohérent dans les accords générés. Le problème se produit dans les champs multilignes lorsque le moteur de traitement de document ajuste la taille de police pour empêcher le découpage du texte, remplaçant les paramètres de taille de police fixes.
4556516	Correctif : mise à jour du comportement de rendu de police pour que les champs multilignes respectent les paramètres de taille de police fixes, alignant le comportement avec la sortie attendue et empêchant les ajustements de taille non intentionnels.
4556967	Résumé : les cases à cocher sélectionnées peuvent apparaître comme non sélectionnées dans le PDF signé finalisé pour les formulaires web. Le problème se produit lorsque certaines valeurs masquées (par exemple, « non », « faux », « 0 », « désactivé », « non coché ») sont utilisées, ce qui peut causer une mauvaise interprétation des états de case à cocher pendant le traitement du document lorsque Gibson est activé.
4556967	Correctif : mise à jour du traitement des cases à cocher pour interpréter correctement les valeurs masquées et préserver les états sélectionnés dans le document finalisé, garantissant ainsi la cohérence entre la signature et le PDF signé.
4557222	Résumé : les champs de lien des modèles de champ peuvent disparaître de la page de création lorsqu’ils sont utilisés dans un workflow. Le problème se produit car les champs de lien ne sont pas inclus dans les données de champ de formulaire de contrat renvoyées lors de la création basée sur un workflow, ce qui entraîne des champs manquants.
4557222	Correctif : Mise à jour de la gestion des champs de formulaire pour inclure les champs de lien des modèles de champ lors du traitement du workflow, garantissant qu’ils sont correctement fusionnés et affichés sur la page de création.
4557272	Résumé : le champ Date de signature peut ne pas apparaître dans le PDF signé finalisé. Le problème se produit lorsque le rendu du champ de texte échoue lors du traitement du document, empêchant l’affichage du champ de date dans le document de sortie.
4557272	Correctif : mise à jour du rendu des champs de texte pour gérer correctement les valeurs nulles ou vides, garantissant ainsi que le champ Date de signature s’affiche de manière cohérente dans les documents signés.
4557282	Résumé : les champs de case d’option dans les formulaires web peuvent afficher une valeur d’infobulle inattendue (« object Object ») lorsqu’ils sont créés à l’aide de la nouvelle expérience de modèle. Le problème se produit en raison d’une gestion incorrecte des valeurs d’infobulle vides, provoquant l’affichage des données d’espace réservé au lieu de les masquer.
4557282	Correctif : mise à jour de la logique de gestion des infobulles pour ignorer correctement les valeurs vides, empêchant ainsi l’affichage inattendu de texte d’espace réservé dans les formulaires web.
4557589	Résumé : les champs de case à cocher préremplis peuvent apparaître décochés lorsque l’accord est envoyé pour signature. Le problème se produit lorsque des valeurs masquées dupliquées ou conflictuelles sont définies pour les entrées de case à cocher ou de bouton radio, ce qui peut provoquer une interprétation incorrecte de l’état sélectionné lors du traitement du document.
4557589	Correctif : mise à jour de la gestion des valeurs de champ pour traiter correctement les valeurs masquées et préserver les sélections préremplies, garantissant que les états des cases à cocher restent cohérents lorsque les accords sont générés et envoyés.
4557672	Résumé : la nouvelle expérience de demande de signature peut afficher une erreur générique (« La demande indiquée n’est pas valide. ») lors de l’envoi d’un accord, sans identifier le champ spécifique à l’origine de l’échec. Cela peut se produire lorsque les détails du destinataire (comme le format du numéro de téléphone) échouent à la validation, mais l’erreur n’est pas clairement remontée à l’utilisateur.
4557672	Correctif : mise à jour de la gestion de la validation pour fournir des messages d’erreur spécifiques au niveau du champ, aidant les utilisateurs à identifier et corriger les entrées non valides avant d’envoyer l’accord.
4557680	Résumé : les mappages de cases à cocher ou de cases d’option peuvent échouer dans certains accords lors de la combinaison de plusieurs documents, entraînant la non-application des valeurs attendues. Le problème se produit lorsque les valeurs par défaut ne correspondent pas exactement aux valeurs d’export définies, ce qui peut entraîner le traitement des champs comme des groupes séparés et interrompre le comportement de mappage.
4557680	Correctif : mise à jour de la logique de mappage des champs pour ignorer les valeurs par défaut incompatibles et associer correctement les champs entre les documents, améliorant la cohérence du comportement des cases à cocher et des cases d’option.
4557902	Résumé : un espace supplémentaire peut s’afficher entre la signature et le tampon de date et heure dans les accords Remplir et signer. Le problème se produit en raison d’un calcul d’espacement incorrect dans les signatures bien formatées, entraînant une mise en page incohérente par rapport aux autres flux de signature.
4557902	Correctif : mise à jour du calcul de mise en page de signature pour positionner correctement la signature et la date et l’heure, supprimant l’espacement non prévu et garantissant une mise en forme cohérente.
4557947	Résumé : les champs de case à cocher peuvent s’afficher décochés dans le PDF signé finalisé lors de l’utilisation de modèles de bibliothèque, même si le signataire les a sélectionnés. Le problème peut se produire lorsque les champs de case à cocher sont mal configurés ou utilisent certaines valeurs masquées, ce qui entraîne une interprétation incorrecte de l’état sélectionné lors du traitement du document.
4557947	Correctif : mise à jour du traitement des cases à cocher pour interpréter correctement les valeurs masquées et préserver les états sélectionnés, garantissant que les sélections de case à cocher sont conservées dans le document signé.
4558295	Résumé : les valeurs de case d’option requises peuvent être manquantes dans le PDF signé finalisé. Le problème peut se produire lorsque les valeurs de champ contiennent des caractères spéciaux (par exemple, des guillemets ou des symboles) qui ne sont pas correctement traités, ce qui empêche le rendu de la valeur sélectionnée dans la sortie du document.
4558295	Correctif : mise à jour du traitement des valeurs de champ pour gérer correctement les caractères spéciaux, garantissant que les valeurs sélectionnées sont préservées et affichées dans le PDF signé.
4558307	Résumé : les champs de formulaire peuvent ignorer les tailles de police configurées et générer un rendu incohérent dans les accords générés. Le problème peut survenir dans les champs multilignes lorsque le moteur de traitement des documents ajuste la taille de police pour éviter la coupure de texte, remplaçant les paramètres de taille de police fixes.
4558307	Correctif : mise à jour du comportement de rendu de police afin que les champs multilignes respectent les paramètres de taille de police fixes, évitant le redimensionnement non prévu et garantissant un résultat cohérent.
4558554	Résumé : les signataires peuvent terminer des accords sans interagir avec le bloc de signature. Le problème peut se produire dans les comptes compatibles Gibson lorsque le bloc de signature n’est pas correctement rendu ni appliqué pendant la signature, permettant la finalisation avec seulement le champ de signature.
4558554	Correctif : mise à jour de la logique de rendu et de validation de signature pour garantir que les blocs de signature sont correctement affichés et requis avant la finalisation de l’accord.
4558725	Résumé : les balises de texte peuvent échouer à générer le rendu ou à se convertir en champs de formulaire pendant l’aperçu. Le problème peut survenir lorsque le PDF chargé contient des éléments non pris en charge ou non valides (par exemple, des annotations nulles ou des champs remplissables existants), qui empêchent le traitement des balises de texte de se terminer avec succès.
4558725	Correctif : mise à jour du traitement des balises de texte pour gérer plus efficacement les PDF contenant des annotations non valides ou non prises en charge, permettant aux champs d’être générés comme prévu pendant l’aperçu.
4559285	Résumé : l’authentification téléphonique peut échouer pour certaines zones géographiques lors de la sélection d’un indicatif de pays dans la nouvelle expérience de demande de signature. Le problème survient lorsque l’interface utilisateur affiche un indicatif de pays incomplet ou incorrect (par exemple, « +1 » au lieu de « +1246 » pour la Barbade), ce qui peut causer des erreurs de validation lors de l’envoi de l’accord.
4559285	Correctif : mise à jour de la gestion des indicatifs de pays pour utiliser les codes de numérotation complets appropriés, garantissant que les numéros de téléphone sont validés et traités correctement dans la nouvelle expérience.
4560119	Résumé : le texte des champs de formulaire peut être mal aligné ou se chevaucher dans les accords générés. Le problème peut survenir dans les champs de texte multilignes lorsque des différences de rendu sont introduites par le moteur de traitement de document, entraînant des décalages de mise en page par rapport à la vue de création.
4560119	Correctif : mise à jour du rendu de texte et de la gestion de la mise en page pour les champs multilignes afin d’améliorer l’alignement et d’éviter le chevauchement, garantissant un affichage plus cohérent entre la création et les documents finaux
4562058	Résumé : le nom du destinataire peut rester inchangé lors de la sélection d’une adresse e-mail différente de celle indiquée dans le carnet d’adresses sur la page Envoyer. Le problème survient parce que le champ nom ne s’actualise pas lorsqu’un nouveau contact est sélectionné, causant une discordance entre le nom affiché et l’adresse e-mail sélectionnée.
4562058	Correctif : mise à jour du comportement de sélection des destinataires afin que le champ Nom s’actualise toujours lorsqu’un nouveau contact est sélectionné, garantissant que le nom et l’adresse e-mail restent synchronisés.
4566339	Résumé : des états de case à cocher incorrects peuvent apparaître lors du traitement de PDF XFA statiques dont les valeurs de champ sont malformées. Le problème peut survenir lorsque des données XFA non prises en charge ou non valides (par exemple, des valeurs de chaîne dans des champs numériques) sont gérées de manière incohérente, particulièrement dans les environnements compatibles Gibson où les paramètres par défaut de case à cocher peuvent être mal interprétés.
4566339	Correctif :mise à jour de la gestion XFA dans le pipeline de traitement de documents pour normaliser ou ignorer plus systématiquement les valeurs mal formées, empêchant les états de case à cocher incorrects et alignant le comportement entre les environnements.
4567278	Résumé : les champs de texte en lecture seule peuvent ne pas apparaître sur la page de signature lorsque les participants dynamiques sont activés. Le problème se produit en raison d’incohérences de rendu des champs pendant la résolution des participants, ce qui peut entraîner l’omission des champs non modifiables de la vue du signataire.
4567278	Correctif : mise à jour de la logique de rendu de champ pour les participants dynamiques afin de garantir que les champs en lecture seule sont systématiquement inclus et affichés lors de la signature.
4568023	Résumé : les options de signature Image et Mobile peuvent ne pas s’afficher dans les formulaires web lors de la signature. Le problème peut se produire en raison du chargement incohérent des options de signature dans le flux d’entrée du formulaire web, où certaines méthodes de signature ne sont pas présentées jusqu’à ce que la session soit rechargée ou accessible par un autre chemin d’accès.
4568023	Correctif : mise à jour de l’initialisation de signature des formulaires web pour charger systématiquement toutes les options de signature activées, garantissant que les méthodes Image et Mobile sont disponibles sur tous les points d’entrée.

Adobe Acrobat Sign version v17.1.1

Déploiement en production : 16 juin 2026

Déploiement sur GovCloud : 18 juin 2026

Fonctionnalité améliorée

Filtre de destinataire dans la création de rapports – Ajoutez un filtrage basé sur le destinataire aux rapports et aux exports de données.
Ajoutez un filtre Destinataire à la création de rapports moderne pour les rapports d’accord et de transaction ainsi que les exports de données. Les administrateurs peuvent filtrer par adresse e-mail du destinataire pour retourner tous les accords qui incluent le destinataire spécifié, quel que soit le rôle ou l’ordre de signature. Le filtre prend en charge la saisie semi-automatique et le comportement de sélection multiple cohérent avec le filtre d'expéditeur existant et s'applique aux rapports visuels et aux exportations CSV.

Modifications de l’expérience

Prise en charge de Bio-Pharma (CFR) dans la signature électronique moderne - Ajoute la capture du motif de signature et la réauthentification obligatoire au moment de la signature
Les paramètres de signature Bio-Pharma, notamment la capture du motif de signature et la réauthentification au moment de la signature, sont désormais pris en charge dans l’expérience de signature électronique moderne. Les accords utilisant ces paramètres ne font plus appel à l’expérience de signature classique. Aucune action du client ou modification de paramètre par l’administrateur n’est requise.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : la prise en charge des paramètres Bio Pharma dans la signature électronique moderne est activée par défaut.

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.

Suppressions des notifications d’accord via l’API - Ajout d’un contrôle granulaire des messages aux destinataires
En utilisant l’API REST v6 POST /agreements, contrôlez les notifications envoyées lors de la création d’accords en supprimant des types d’e-mail spécifiques pour les participants, les destinataires en copie ou l’expéditeur. Cela réduit les e-mails inutiles et favorise des expériences de signature plus claires et mieux contrôlées dans les workflows intégrés.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de configuration : API REST v6

Problèmes résolus

Problème	Description
4545881	Résumé : les signataires utilisant Télécharger et Signer dans Acrobat pouvaient recevoir une erreur « Adobe Acrobat Sign ne reconnaît pas » après avoir chargé un PDF signé numériquement lorsque le certificat d’identité numérique ne contenait pas une valeur de nom attendue (telle que commonName, givenName ou pseudonym). L’accord ne pouvait pas être finalisé même si le PDF signé était chargé.
4545881	Correction : Acrobat Sign gère désormais les certificats d’identité numérique avec des valeurs de nom de signataire manquantes sans générer d’erreur pendant le processus de validation du chargement. La signature peut se terminer avec succès, bien que le nom du signataire puisse ne pas s’afficher si le certificat n’en inclut pas.
4547132	Résumé : lorsque les accords étaient créés via la requête API POST /agreements et que securityOption était défini sur null, les destinataires externes pouvaient se voir attribuer la méthode d’authentification Aucune, même lorsque les paramètres de compte exigeaient la méthode d’authentification OTP par e-mail par défaut. L’authentification des destinataires internes était appliquée correctement, mais l’authentification des destinataires externes ne l’était pas.
4547132	Correction : Acrobat Sign applique désormais correctement la méthode d’authentification par défaut configurée pour le compte lorsque les accords créés via l’API incluent des destinataires avec une valeur securityOption nulle. Les destinataires externes reçoivent désormais la méthode d’authentification par défaut requise au lieu d’Aucune.
4553171	Résumé : dans les comptes développeur utilisant la nouvelle expérience Créer un modèle, les modèles réutilisables pouvaient afficher le préfixe [DEMO USE ONLY] sur la page Gérer, mais le préfixe n’était pas disponible lors de la modification du nom du modèle. Les utilisateurs ne pouvaient pas supprimer le préfixe du nom de modèle existant à moins de remplacer le nom complet ou de passer à l’expérience de modèle classique.
4553171	Correction : la nouvelle expérience Créer un modèle maintient désormais l’alignement entre le nom de modèle réutilisable et le nom d’accord pour le comportement du filigrane de compte développeur. Les utilisateurs peuvent modifier le nom de modèle complet, y compris le préfixe [DEMO USE ONLY], sans passer à l’expérience classique
4556731	Résumé : après qu’un expéditeur a remplacé un destinataire par lui-même puis délégué l’accord à un autre destinataire, l’accord est revenu à En cours, mais l’option Télécharger un document signé est restée indisponible. Cela empêchait l’expéditeur de charger une copie signée pour les accords en cours éligibles après cette séquence de délégation.
4556731	Correction : Acrobat Sign restaure désormais correctement l’option Télécharger le document signé lorsqu’un destinataire est remplacé par l’expéditeur puis délégué à un autre destinataire, lorsque l’accord est éligible pour le chargement de document signé.
4557576	Résumé : lorsqu’un bloc de signature était assigné à un groupe de destinataires avec plusieurs membres, l’adresse e-mail dans le bloc de signature pouvait être tronquée au lieu de s’afficher clairement. Cela pouvait rendre les informations du groupe de destinataires difficiles à lire avant qu’un membre du groupe termine la signature.
4557576	Correctif : Acrobat Sign affiche désormais les informations e-mail du groupe de destinataires dans les blocs de signature sans couper brusquement le texte visible. Les longues valeurs e-mail de groupe de destinataires sont gérées de sorte que les informations affichées restent lisibles dans le bloc de signature.
4561898	Résumé : certains destinataires pouvaient rencontrer une erreur de serveur après l’authentification ou lors de la finalisation de la signature pour les accords qui utilisaient des documents PDF spécifiques. L’échec a été causé par un problème de gestion des données de structure PDF lors de la génération du document signé, ce qui a empêché le signataire de terminer l’accord.
4561898	Correctif : Acrobat Sign gère désormais les données de structure PDF de manière plus défensive lors de la signature et de la génération de document. La correction évite que les conflits d’arbre de structure bloquent la finalisation, permettant aux destinataires de s’authentifier, de signer et de finaliser avec succès les accords concernés.
4562041	Résumé : la publication de certaines notifications de webhook pouvait échouer ou être retardée lorsque Acrobat Sign recevait une erreur de serveur interne lors de la création de la charge utile du webhook. Pour le compte concerné, plusieurs événements du 19 mars 2026 étaient impactés, notamment AGREEMENT_WORKFLOW_COMPLETED et d’autres événements d’accord, ce qui retardait les workflows clients en aval
4562041	Correction : Acrobat Sign gère désormais les échecs de génération de charge utile de webhook de manière plus fiable afin que les réponses internes ayant échoué ne soient pas mises en cache d’une manière qui bloque ou retarde la diffusion d’événements. La correction a été validée par des tests de non-régression et vise à empêcher que les événements de webhook concernés soient retardés par le même problème de génération de charge utile.
4562458	Résumé : les destinataires pouvaient recevoir une erreur d’identifiant d’accord non valide spécifié lors de l’ouverture d’une URL de signature pour des accords envoyés à des utilisateurs inactifs sur des domaines de compte revendiqués, lorsque l’authentification du destinataire était utilisée, par exemple OTP par e-mail ou l’authentification par mot de passe. Le flux de signature a créé un utilisateur temporaire à usage unique pour continuer le processus de signature, mais la demande d’informations de signature pouvait lire des données d’accord obsolètes qui n’incluaient pas la participation nouvellement créée, bloquant l’accès jusqu’à ce que le lien de signature soit régénéré ou que les données soient actualisées.
4562458	Correction : Acrobat Sign récupère désormais les données de participation d’accord actuelles lors de l’ouverture des URL de signature authentifiées dans ce workflow. Ceci évite que des données d’accord mises en cache périmées causent des erreurs d’ID d’accord non valide et permet aux destinataires de finaliser l’authentification et d’accéder à la page de signature électronique avec succès.
4566894	Résumé : certains accords expirés créés à partir de plusieurs modèles ne pouvaient pas être copiés à partir de la page Gérer. Lorsque les utilisateurs sélectionnaient Créer une copie, l’opération de copie échouait avec Impossible de copier l’accord. Réessayez ultérieurement, car la validation d’accès au modèle échouait lors de la copie d’accords avec plusieurs modèles.
4566894	Correction : Acrobat Sign valide désormais correctement les informations de modèle lors de la copie d’accords qui ont été créés à partir de plusieurs modèles. Les accords concernés peuvent désormais être copiés sans déclencher l’erreur de session du serveur.
4568666	Résumé : les notifications de webhook pouvaient échouer par intermittence pour les accords qui incluaient des participants témoins sans identifiant utilisateur attribué. L’événement d’accord principal était créé, mais la génération de charge utile du webhook pouvait échouer lorsque les données de participant étaient traitées dans un ordre imprévisible, entraînant la non-diffusion de certains événements de webhook attendus après AGREEMENT_CREATED.
4568666	Correctif : Acrobat Sign gère désormais en toute sécurité les données des participants webhook avec des ID utilisateur manquants lors de la génération de la charge utile. Ceci évite que les participants témoins de substitution entraînent des échecs de charge utile de webhook et permet la diffusion cohérente des événements de webhook d’accord attendus.
4571682	Résumé : dans certains accords où Power Automate modifiait des groupes de destinataires avant le tour d’une personne ultérieure chargée de remplir le formulaire, l’affichage des champs en lecture seule pouvait échouer pour la personne suivante. Lorsque la personne chargée de remplir le formulaire complétait ses champs modifiables, ces champs pouvaient également disparaître de l’accord, même si les champs étaient encore attribués correctement et marqués comme visibles via l’API.
4571682	Correction : Acrobat Sign préserve désormais la visibilité des champs pour les groupes de destinataires suivants après les changements d’appartenance aux groupes de destinataires. Les champs en lecture seule, les blocs de signature, les sélections de listes déroulantes et autres valeurs de champs complétées restent disponibles pour les destinataires ultérieurs et dans le PDF téléchargé pour les scénarios corrigés.
4571845	Résumé : la signature en personne peut échouer avec une erreur de serveur lorsque l’e-mail du signataire en personne correspond à un compte d’utilisateur existant sur une partition différente, empêchant la finalisation de l’accord.
4571845	Correction : mise à jour du traitement du signataire en personne pour créer et utiliser correctement un enregistrement de signataire temporaire, évitant les conflits d’utilisateur inter-partition et permettant à la session de signature de se terminer avec succès.
4573019	Résumé : l’ordre des groupes de destinataires peut être calculé incorrectement après des mises à jour dynamiques de participants qui suppriment un mélange de destinataires et de groupes de destinataires, ce qui entraîne l’affichage d’un ordre de routage incorrect pour le groupe restant.
4573019	Correction : mise à jour du recalcul de l’ordre des participants afin que les groupes de destinataires conservent l’ordre correct après des suppressions dynamiques complexes de participants, y compris les cas où un groupe est réduit à un seul membre restant.
4572455	Résumé : certains signataires pouvaient voir un message Erreur non gérée ou Une erreur s’est produite après avoir terminé la signature, même si la signature avait été appliquée et que l’accord était passé au destinataire suivant. Le problème se produisait lorsque les participants dynamiques étaient activés et que le flux de signature tentait de préparer le document pour le signataire suivant mais ne pouvait pas trouver la version signée attendue du document.
4572455	Correctif : Acrobat Sign vérifie désormais que la version du document signé est correcte lors de la préparation d’un accord pour le signataire suivant. Cela empêche le flux de signature d’afficher une erreur après une signature réussie lorsque les participants dynamiques sont activés.

Notes de mise à jour d'Adobe Acrobat Sign - 2023

Suiv.

Notes de mise à jour d'Adobe Acrobat Sign - 2022

Comprendre

Apprenez avec des didacticiels vidéo étape par étape et des conseils pratiques directement dans l’application.

Communauté

Participez aux discussions, trouvez des réponses, apprenez auprès d'experts et partagez vos connaissances.

Accueil Adobe

Accédez à vos applications et services Creative Cloud préférés, à la gestion des fichiers et plus encore.