Ce document présente les nouvelles fonctionnalités, les modifications de l’expérience et les problèmes résolus dans l’application destinée aux clients pour la version la plus récente.

Les mises à jour orientées développeur de l’API et des webhooks sont documentées dans le Guide du développeur Acrobat Sign.

Il n’est pas garanti que toutes les fonctionnalités/modifications soient activées à la sortie de la version. Consultez toujours la version en anglais américain de la page, car c’est la version la plus récente et la plus précise.

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 automatique et le comportement de sélection multiple conforme au filtre Expéditeur existant et s’applique aux rapports visuels et aux exports CSV.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : activé avec la création de rapports moderne
Consultez la présentation de la création de rapports >
Consultez le document Création d’un rapport mis à jour >
Consultez la documentation mise à jour pour la création d’un export de données >

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.
Consultez la liste des fonctionnalités prises en charge mise à jour pour Modern e-sign >

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.