Adobe Acrobat Sign déploie au moins trois mises à jour par an, majeures ou mineures. Des mises à jour mineures supplémentaires peuvent être réalisées si nécessaire pour résoudre les problèmes de système ou de clientèle.

Les versions majeures offrent des mises à jour importantes, de nouvelles fonctionnalités et plusieurs améliorations.
Les versions mineures mettent l’accent sur les améliorations mineures et les ajustements de l’expérience utilisateur. Elles se produisent entre les mises à jour majeures, généralement une ou deux fois par cycle.

Pour éviter toute interruption, les nouvelles fonctionnalités sont désactivées par défaut et doivent être activées manuellement par un administrateur de compte ou de groupe.

Pour les clients de la santé et des sciences de la vie nécessitant une validation de conformité, Acrobat Sign collabore avec un tiers afin de fournir un package de validation pour chaque version majeure contenant des fonctionnalités pour minimiser votre facteur de risque.

Remarque :

Cette page Notes des versions préliminaires est régulièrement mise à jour à mesure que de nouvelles informations sont disponibles, de sorte que son contenu change assez souvent.

Bien que cette page soit localisée, le processus prend du temps et il se peut que les versions localisées diffèrent légèrement de la version en anglais (États-Unis) officielle.

Pour obtenir les informations les plus précises et les plus récentes, nous vous recommandons de consulter uniquement la page en anglais (États-Unis).

Le planning et les notes de la version préliminaire sont répertoriés ci-dessous.

Adobe Acrobat Sign suit un planning structuré pour la publication des mises à jour des notes de mise à jour et de la documentation :

Huit semaines avant la mise en production

La page de version préliminaire publie un résumé des fonctionnalités et des mises à jour attendues généralement quatre semaines avant le lancement de Sandbox.
Toute modification de fonctionnalité après ce point est signalée dans la section Errata.
Les problèmes résolus ne sont pas inclus à cette étape.

Quatre semaines avant la mise en production (lancement de Sandbox)

La page de version préliminaire est mise à jour avec une documentation détaillée sur les nouvelles fonctionnalités et les mises à jour.
Des liens vers la documentation de support de la version préliminaire, uniquement disponible en anglais (États-Unis), sont ajoutés si nécessaire.
La section initiale Problèmes résolus est publiée, avec des mises à jour continues au cours des quatre semaines suivantes.

Jour de lancement

Les notes de mise à jour officielles sont mises à jour avec des détails sur les fonctionnalités finales et des liens vers la documentation de support de production.
La page de version préliminaire est actualisée pour mettre en évidence le cycle de publication de la version suivante.
La documentation est publiée après vérification de la version dans le système en direct, généralement après 19 h, même si les mises à jour complexes peuvent prendre plus de temps.
La liste finale de la section Problèmes résolus est ajoutée aux notes de mise à jour en anglais (États-Unis), les versions localisées étant mises à jour ultérieurement.

Version de Government Cloud

L’environnement Government Cloud est généralement mis à jour entre deux jours et plusieurs semaines après la mise en production, car certaines fonctionnalités peuvent nécessiter une évaluation supplémentaire avant le déploiement.

Remarque :

La documentation sur le Sandbox est conçue pour l’environnement de production. Les liens trouvés dans le contenu de la version préliminaire ciblent les URL de production. En d’autres termes, ces liens peuvent mener à une ancienne documentation existante ou à des résultats 404 si la page cible est nouvelle et n’a pas encore été publiée (par exemple, lorsque le lien pointe vers une nouvelle fonctionnalité dans la même version).

Les nouvelles pages seront publiées lors de la sortie de la version et les liens redirigeront correctement vers leurs URL de production.

Disponibilité du sandbox

Les clients qui ont accès à l’environnement Acrobat Sign Sandbox peuvent généralement accéder aux fonctionnalités de la nouvelle version quatre semaines avant le lancement.

L’environnement Sandbox passera toutes les procédures d’assurance qualité de la production au même niveau de qualité que l’environnement de production normal.
Adobe s’efforce d’assurer une disponibilité de 99,9 % dans l’environnement Sandbox, mais il convient de noter que l’accord de service unifié d’Adobe ne couvre pas formellement l’environnement Sandbox.
L’environnement Sandbox utilise la même page de statut et les mêmes procédures d’interruption que l’environnement de production normal.

Versions

Alerte :

Cet article contient des informations sur les versions préliminaires. Les dates de publication, les fonctionnalités et d’autres informations peuvent être modifiées sans préavis.

16 juin 2026 (version mineure) v17.1.1

Adobe Acrobat Sign version v17.1.1

Déploiement Sandbox : 12 mai 2026

Déploiement en production : 16 juin 2026

Déploiement 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 Accord et Transaction et 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 Expéditeur existant. Il 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
Consulter la vue d’ensemble des rapports >
Consulter le document Création d’un rapport mis à jour >
Consulter la documentation mise à jour relative à la création d’un export de données >

Modification de documents en ligne lors de la création : modifier le texte du document directement dans l’expérience de création
Les expéditeurs peuvent modifier le texte du document directement dans l’environnement de création sans télécharger ni charger à nouveau le fichier. L’option Modifier le document préserve les champs existants et la configuration de l’accord, réduisant les perturbations lors des mises à jour avant envoi. La modification est disponible uniquement lorsque l’accord est à l’état de brouillon et n’est pas disponible après l’envoi de l’accord.

Cette fonctionnalité est activée par défaut pour tous les utilisateurs des comptes pris en charge, ce qui permet aux expéditeurs de modifier les documents envoyés via Demander une signature. Les administrateurs de compte et de groupe peuvent désactiver la modification de document via les paramètres d’envoi.

Cette fonction n’est pas disponible dans Acrobat Sign for Government ou pour les comptes utilisant le système de gestion des utilisateurs existant.

Environnements disponibles : Sandbox, Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : compte et groupe ; activé par défaut
Activer ou désactiver la modification de documents en ligne >
Comment modifier du texte pendant la création de champs >

Support Bio-Pharma (CFR) dans Modern eSign – Ajoute la capture de motif de signature et la réauthentification forcée au moment de la signature
Adobe Acrobat Sign finalise le support Bio-Pharma dans l’expérience de signature électronique moderne en ajoutant la capture de motif de signature et la réauthentification forcée pendant la signature. Les organisations opérant dans des environnements réglementés peuvent exiger un motif de signature, forcer la réauthentification pour chaque signature ou au clic final pour signer, et maintenir la création de rapports d’audit conforme — le tout dans l’interface Modern.

Environnements disponibles : Sandbox, Commercial, Government | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Le support des paramètres Bio Pharma dans Modern eSign est activé par défaut.
Consultez la liste des fonctionnalités prises en charge mise à jour pour Modern e-sign >

Modifications de l’expérience

Mises à jour API/Webhook REST

Les mises à jour ci-dessous sont présentées dans les notes préliminaires à des fins de divulgation. Une documentation complète sur les mises à jour d’API et de webhook est disponible dans la documentation du développeur Acrobat Sign lorsque la mise à jour de version est fournie aux serveurs de production.

Supprimer les notifications d’accord via l’API : ajoutez un contrôle granulaire sur les messages des destinataires
En utilisant l’API REST v6 POST /agreements, contrôlez quelles notifications sont envoyées lors de la création d’accords en supprimant des types d’e-mails spécifiques pour les participants, les destinataires en copie ou l’expéditeur. Les e-mails inutiles sont ainsi réduits et les expériences de signature plus propres et mieux contrôlées sont prises en charge dans les workflows intégrés.

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

Errata de version

Aucun élément n’a été reporté hors de cette version à ce jour.

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 peut pas reconnaître » après avoir chargé un PDF signé numériquement lorsque le certificat d’identité numérique n’incluait pas une valeur de nom de signataire attendue, telle que commonName, givenName ou pseudonym. L’accord n’a pas pu être finalisé même si le PDF signé a été chargé.
4545881	Correctif : 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 des 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 du compte exigeaient OTP par e-mail comme méthode d’authentification par défaut. L’authentification des destinataires internes était appliquée correctement, mais l’authentification des destinataires externes ne l’était pas.
4547132	Correctif : Acrobat Sign applique désormais correctement la méthode d’authentification par défaut configurée pour le compte lorsque les accords créés par API incluent des destinataires avec une valeur securityOption null. 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	Correctif : La nouvelle expérience Créer un modèle maintient désormais l’alignement entre le nom du modèle réutilisable et le nom de l’accord pour le comportement de filigrane du compte développeur. Les utilisateurs peuvent modifier le nom complet du modèle, y compris le préfixe [DEMO USE ONLY], sans passer à l’expérience classique
4554947	Résumé : Dans l’expérience de composition moderne, les utilisateurs ne pouvaient pas supprimer les adresses e-mail incorrectes ou obsolètes des suggestions de saisie automatique personnelles lors de l’ajout de destinataires, de copies, de copies par destinataire ou de membres de groupe. L’option de suppression était toujours disponible dans l’expérience classique, mais tous les utilisateurs ne pouvaient pas revenir au mode classique.
4554947	Correctif : L’expérience de composition moderne permet désormais aux utilisateurs de supprimer les suggestions de saisie automatique personnelles des champs d’e-mail pris en charge, notamment les champs destinataire, copie, copie par destinataire et membre de groupe. Les contacts organisationnels ne peuvent pas être supprimés des suggestions de saisie automatique.
4556731	Résumé : après qu’un expéditeur ait remplacé un destinataire par lui-même puis délégué l’accord à un autre destinataire, l’accord revenait à En cours, mais l’option Charger le document signé restait 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	Correctif : Acrobat Sign restaure désormais correctement l’option Charger le document signé après qu’un destinataire soit 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 attribué à un groupe de destinataires avec plusieurs membres, la valeur d’e-mail dans le bloc de signature pouvait être coupé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.
4558445	Résumé : les modèles créés dans l’expérience classique pouvaient inclure des groupes de cases d’option avec une seule option. Lorsque ces modèles étaient ouverts ou réutilisés dans la nouvelle expérience Créer un modèle, la validation bloquait le workflow avec l’erreur Un groupe de cases d’option doit contenir plusieurs éléments, empêchant les utilisateurs d’enregistrer ou d’appliquer les modèles existants.
4558445	Correctif : les nouvelles expériences de création et Créer un modèle s’alignent désormais sur l’expérience classique pour les modèles existants qui contiennent des groupes de cases d’option à option unique. La validation a été assouplie pour préserver la rétrocompatibilité et permettre aux modèles concernés d’être ouverts, enregistrés et réutilisés sans bloquer le workflow.
4559171	Résumé : dans la nouvelle expérience Créer un modèle, les modèles créés à partir de PDF balisés pouvaient être enregistrés avant la fin du traitement des balises de texte. Si les utilisateurs sélectionnaient Créer immédiatement après le chargement de l’aperçu, le modèle enregistré pouvait ne contenir aucun champ de formulaire converti, même si le même workflow réussissait dans l’expérience classique.
4559171	Correctif : la nouvelle expérience Créer un modèle empêche désormais les utilisateurs de créer le modèle tant que le traitement des balises de texte n’est pas terminé. Le bouton Créer devient disponible uniquement après que tous les champs et détails associés sont entièrement chargés, garantissant que les balises de texte sont converties et appliquées avant l’enregistrement du modèle.
4561898	Résumé : certains destinataires pouvaient rencontrer une erreur de serveur après l’authentification ou lors de la finalisation de la signature d’accords qui utilisaient des documents PDF spécifiques. L’échec était causé par un problème de gestion des données de structure PDF lors de la génération du document signé, ce qui empêchait 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 documents. Le correctif empêche les conflits d’arborescence de structure de bloquer l’achèvement, permettant aux destinataires de s’authentifier, de signer et de finaliser avec succès les accords concernés.
4562041	Résumé : certaines notifications webhook pouvaient être retardées ou ne pas être publiées lorsque Acrobat Sign recevait une erreur de serveur interne lors de la création du payload du webhook. Pour le compte concerné, plusieurs événements du 19 mars 2026 ont été impactés, notamment AGREEMENT_WORKFLOW_COMPLETED et d’autres événements d’accord, ce qui a retardé les workflows clients en aval
4562041	Correctif : Acrobat Sign gère désormais les échecs de génération de payload du webhook de manière plus fiable afin que les réponses internes en échec ne soient pas mises en cache d’une manière qui bloque ou retarde la distribution d’événements. Le correctif a été validé par des tests de régression et vise à empêcher que les événements webhook concernés soient retardés par le même chemin d’échec de génération de payload.
4562458	Résumé : les destinataires pouvaient recevoir une erreur ID 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 telle que OTP par e-mail ou Authentification par mot de passe était utilisée. Le flux de signature créait un utilisateur en attente à 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	Correctif : Acrobat Sign récupère désormais les données de participation d’accord actuelles lors de l’ouverture d’URL de signature authentifiées dans ce workflow. Cela empêche les données d’accord en cache obsolètes de causer 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 depuis la page Gérer. Lorsque les utilisateurs sélectionnaient Créer une copie, l’opération de copie échouait avec le message « Impossible de copier l’accord ». Veuillez réessayer ultérieurement » car la validation d’accès au modèle échouait lors de la copie d’accords avec plusieurs accords.
4566894	Correctif : 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 backend.
4568666	Résumé : les notifications webhook pouvaient échouer de manière intermittente pour les accords qui incluaient des participants témoins sans ID utilisateur attribué. L’événement d’accord principal était créé, mais la génération du payload du webhook pouvait échouer lorsque les données des participants étaient traitées dans un ordre imprévisible, empêchant la livraison de certains événements 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. Cela empêche les participants témoins avec espace réservé de provoquer des échecs de payload du webhook et permet la distribution cohérente des événements webhook d’accord attendus.
4571682	Résumé : dans certains accords où Power Automate modifiait les groupes de destinataires avant le tour d’un remplisseur de formulaire ultérieur, les champs en lecture seule pouvaient ne pas s’afficher pour le remplisseur de formulaire suivant. Lorsque le remplisseur de formulaire remplissait ses champs modifiables, ces derniers pouvaient également disparaître de l’accord, même si les champs étaient toujours attribués correctement et marqués comme visibles via l’API.
4571682	Correctif : Acrobat Sign préserve désormais la visibilité des champs pour les groupes de destinataires suivants après les modifications d’appartenance à un groupe 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.
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 était appliquée et l’accord passait 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 la version correcte du document signé 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.