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.

Annotation

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.

Annotation

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.

21 juillet 2026 (Version mineure) v17.1.2

Adobe Acrobat Sign version v17.1.2

Déploiement du sandbox : 16 juin 2026

Déploiement en production : 21 juillet 2026

Déploiement GovCloud : 23 juillet 2026

Fonctionnalité améliorée

Préserver les signatures numériques existantes dans les PDF chargés : les administrateurs peuvent activer Acrobat Sign pour préserver les signatures numériques existantes dans les fichiers PDF chargés, permettant aux documents pré-signés de passer par les workflows d’accord pris en charge sans aplatir la signature originale. Cela aide les organisations à utiliser des documents qui ont été signés numériquement avant le chargement tout en protégeant le document des modifications qui invalideraient la signature préservée.

Environnements disponibles : Sandbox, Commercial, Administration | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : Compte et groupe
Consultez la configuration pour conserver les signatures numériques >
Consultez la procédure pour envoyer un PDF avec une signature numérique existante >

Modification de documents en ligne lors de la création : modifiez 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.

La fonctionnalité de modification de documents en ligne sera déployée progressivement, comme indiqué dans la notification technique.

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.

La modification de documents en ligne n’est pas disponible dans Acrobat Sign pour l’administration ou pour les comptes utilisant le système de gestion des utilisateurs existant.

Environnements disponibles : Commercial | Niveaux de service disponibles : comptes clients Acrobat Sign Solutions VIP et VIPMP | 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 >

Erreurs de version - Éléments supprimés

Vous trouverez ci-dessous les éléments de ligne annoncés comme faisant partie de cette version, mais dont la publication a depuis été reportée.

Clés de chiffrement gérées par le client pour les fichiers d’accord : les clients Acrobat Sign éligibles peuvent configurer une clé gérée par le client AWS KMS pour protéger les fichiers d’accord au repos pris en charge. Une fois la fonctionnalité activée pour un compte, les fichiers d’accord pris en charge sont chiffrés à l’aide de la clé gérée par le client, donnant aux organisations plus de contrôle sur la gestion des clés tout en préservant les processus d’accord Acrobat Sign pris en charge.

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

Problèmes résolus

Problème	Description
4487069	Résumé : Une notification de non-remise affichée sur la page Gérer pouvait disparaître lorsque les utilisateurs parcouraient la liste des accords, car la liste réutilisait les composants de ligne sans actualiser l’état de la notification pour chaque accord.
4487069	Correctif : La page Gérer actualise désormais l’état de notification non remise lorsque les lignes de contrat sont réutilisées, de sorte que la notification reste visible pendant que les utilisateurs font défiler la page.
4541319	Résumé : Les liens hypertexte intégrés dans les aperçus de modèles réutilisables pouvaient devenir inactifs car le traitement PDF supprimait les données de lien intégré pendant la conversion de modèle, tandis que les liens URL exposés restaient cliquables.
4541319	Correctif : Le traitement des fichiers PDF a été mis à jour afin de préserver les données des hyperliens intégrés lors de la conversion en modèle réutilisable, de sorte que les liens URL intégrés et visibles restent cliquables dans l’aperçu du modèle.
4555107	Résumé : Les téléchargements de documents combinés via l’API pouvaient omettre le rapport d’audit même lorsque le paramètre attachAuditReport=true était utilisé, car certaines requêtes étaient traitées à tort comme non authentifiées lorsqu’un échec survenait lors de la génération de l’identifiant d’action de l’API.
4555107	Correctif : L’API de document combiné préserve désormais la pièce jointe de rapport d’audit demandée lorsque la génération d’ID d’action API n’est pas disponible, de sorte que les téléchargements incluent le rapport d’audit lorsque attachAuditReport=true est utilisé.
4555473	Résumé : Les utilisateurs Safari pouvaient être renvoyés à la page de connexion après s’être connectés, car la nouvelle gestion de la confidentialité de Safari empêchait les cookies de session Adobe Acrobat Sign d’être conservés correctement pendant le flux de connexion d’identité Adobe.
4555473	Correctif : La gestion de la compatibilité des cookies de session a été mise à jour pour les versions récentes de Safari et de macOS, afin qu’Acrobat Sign maintienne les utilisateurs connectés après l’authentification.
4555620	Résumé : Les chargements de fichiers volumineux pouvaient être rejetés lors de l’envoi depuis un groupe autorisant une taille maximale de chargement plus élevée, car la validation du chargement des documents transitoires ne chargeait pas le paramètre de taille de chargement du groupe sélectionné.
4555620	Correctif : Les chargements de document transitoire transmettent désormais l’ID de groupe sélectionné afin qu’Acrobat Sign applique la taille de chargement maximale du groupe lors de la validation des fichiers chargés.
4560927	Résumé : Les destinataires d’un accord finalisé pouvaient recevoir des e-mails de finalisation inattendus lorsque l’expéditeur demandait un nouveau lien à partir d’un e-mail d’accord expiré, car le processus de reconduction de l’URL classait par erreur l’e-mail de confirmation destiné à l’expéditeur comme un modèle de notification de signataire.
4560927	Correctif : Le processus de reconduction de l’URL envoie désormais le lien d’accès demandé uniquement à l’utilisateur qui en a fait la demande et n’envoie plus d’e-mails de finalisation aux autres participants de l’accord.
4561378	Résumé : Lorsque les utilisateurs créaient une copie d’un accord et ouvraient la création, Acrobat Sign pouvait envoyer un e-mail de mise à jour d’échéance incorrect car l’échéance automatiquement appliquée de l’accord copié était traitée comme une expiration mise à jour par l’expéditeur avant l’envoi de l’accord.
4561378	Correctif : Le workflow de copie bloque désormais l’e-mail de mise à jour d’échéance initial avant l’envoi de l’accord copié, tout en préservant les notifications de mise à jour d’échéance pour les modifications ultérieures de l’expéditeur.
4562055	Résumé : Dans la nouvelle expérience d’envoi, les workflows personnalisés au niveau du compte pouvaient rétablir la valeur Envoyer depuis le groupe sur le groupe principal de l’expéditeur, car le groupe sélectionné n’était pas préservé lors de l’actualisation de la page du workflow et ils recréaient le brouillon d’accord.
4562055	Correctif : Le flux d’envoi de workflow personnalisé préserve désormais le groupe sélectionné pendant l’actualisation de la page et la création du brouillon d’accord, ainsi les utilisateurs peuvent envoyer depuis un autre groupe que le groupe principal dans la nouvelle expérience.
4562242	Résumé : Les valeurs de champs préremplis pouvaient disparaître après le redémarrage d’un accord par un destinataire ultérieur, car le workflow de redémarrage utilisait le document redémarré comme source au lieu du document prérempli qui conservait les valeurs par défaut de champ d’origine.
4562242	Correctif : Le workflow de redémarrage utilise désormais le document prérempli comme base pour l’accord redémarré, de sorte que les valeurs préremplies d’origine sont préservées lorsque l’accord est renvoyé pour signature.
4562338	Résumé : L’authentification de l’API Swagger pouvait s’arrêter sur une page de redirection vierge et échouer à générer un jeton porteur, car la page de redirection OAuth rejetait les URL de domaine de document Acrobat valides pendant la validation de redirection.
4562338	Correctif : La validation de redirection OAuth Swagger a été mise à jour pour permettre les domaines de document Acrobat pris en charge, de sorte que l’authentification renvoie les utilisateurs vers Swagger et charge le jeton porteur généré.
4565965	Résumé : Les documents comportant plusieurs signatures numériques pouvaient échouer à la validation dans les validateurs stricts de signatures PDF, car Acrobat Sign écrivait temporairement une valeur interne du workflow de signature dans un champ de signature à un emplacement où la spécification PDF exige un dictionnaire de signature.
4565965	Correctif : Le processus de fusion des PDF ignore désormais les champs de signature lors de l’application des valeurs de formulaire, empêchant ainsi l’écriture de valeurs internes de workflow dans les champs de signature et préservant la validité de la structure des documents comportant plusieurs signatures.
4567496 / 4567841	Résumé : Les signatures par tampon pouvaient s’afficher dans une taille inférieure à la taille configurée lorsque les paramètres du motif de signature étaient activés, car la logique de mise en page associée au motif de signature réservait à tort de l’espace à côté des champs de tampon.
4567496 / 4567841	Correctif : Le rendu des tampons a été mis à jour afin que les ajustements de mise en page liés au motif de signature ne redimensionnent pas les champs de tampon, préservant ainsi la taille de tampon configurée.
4568666	Résumé : Les notifications webhook pouvaient ne pas être envoyées pour certains accords comportant des témoins, car la logique de recherche des participants ne gérait pas correctement les enregistrements de témoins lors de la génération de la charge utile du webhook.
4568666	Correctif : La génération des charges utiles des webhooks gère désormais correctement les participants témoins, ce qui permet de continuer à générer et à envoyer les notifications webhook pour les accords concernés.
4568798	Résumé : Les accords copiés pouvaient inclure des destinataires qui avaient été supprimés via la fonction Modifier l’accord, car le workflow de copie n’excluait pas complètement les destinataires supprimés lors de la reconstruction de la liste des destinataires et des groupes de routage.
4568798	Correctif : Le workflow de copie exclut désormais les destinataires supprimés via la fonction Modifier l’accord et reconstruit les groupes de routage en utilisant uniquement les destinataires actifs.
4569478	Résumé : Les sélections de cases à cocher pouvaient disparaître dans les accords terminés lorsqu’un PDF interactif contenait un champ de case à cocher invisible superposé à un champ de case à cocher visible, car le champ invisible était toujours généré lors du traitement final du PDF.
4569478	Correctif : Le traitement des PDF ignore désormais les champs de type case à cocher invisibles lors du rendu de l’accord finalisé, de sorte que les sélections visibles de cases à cocher restent affichées dans le document signé final.
4569490	Résumé : Certains e-mails de notification Adobe Acrobat Sign pouvaient être signalés comme spam, car le balisage du pré-en-tête des e-mails contenait des styles masqués ou à faible contraste que certains filtres de messagerie considèrent comme suspects.
4569490	Correctif : L’annotation des e-mails de notification a été mise à jour afin de supprimer les styles masqués et à faible contraste, réduisant ainsi les faux positifs de détection de spam tout en préservant le comportement normal de prévisualisation des e-mails.
4569491	Résumé : Le flux Attribuer des utilisateurs à un groupe pouvait échouer avec une erreur non gérée lorsque la validation du statut utilisateur rencontrait un enregistrement d’appartenance à un groupe incomplet.
4569491	Correctif : La validation du statut des utilisateurs ignore désormais les enregistrements d’appartenance à un groupe incomplets au lieu d’interrompre le workflow d’affectation, ce qui permet à la fonction Affecter des utilisateurs au groupe de s’ouvrir correctement.
4569747	Résumé : Les accords créés via l’API REST avec le statut de création pouvaient afficher toutes les cases à cocher comme sélectionnées, car les valeurs des champs de fusion de type case à cocher n’étaient pas correctement interprétées lors du chargement de l’accord pour création.
4569747	Correctif : La gestion des champs de fusion de type case à cocher a été mise à jour afin que le mode de création tienne correctement compte des valeurs cochées et non cochées provenant de la charge utile de l’API, et n’affiche que les sélections de cases à cocher prévues.
4570171	Résumé : Adobe Acrobat Sign pouvait ne pas parvenir à traiter certains PDF pourtant valides lorsque le document contenait une destination de lien mal formée, car le traitement du document s’interrompait au lieu d’ignorer le lien défectueux.
4570171	Correction : Le traitement des documents valide désormais les destinations de liens avant de les lire et ignore les liens malformés, de sorte que les PDF concernés peuvent être traités et envoyés avec succès.
4571060	Résumé : Les champs conditionnels liés à des sélections dans une liste déroulante pouvaient ne pas fonctionner lorsque la liste déroulante utilisait des valeurs d’exportation différentes des libellés d’option affichés, car Acrobat Sign évaluait la condition à partir de la mauvaise valeur de la liste déroulante.
4571060	Correctif : La gestion des conditions associées aux listes déroulantes a été mise à jour afin d’associer les libellés d’option affichés à leurs valeurs d’exportation correspondantes. Les champs conditionnels s’affichent désormais correctement et conservent leurs valeurs lorsque le signataire sélectionne l’option correspondante dans la liste déroulante.
4571362	Résumé : Les e-mails de finalisation pouvaient ne pas être envoyés lorsque toutes les tentatives d’envoi par SMS associées à un accord avaient échoué, car l’événement indiquant l’épuisement des tentatives de remise par SMS provoquait un échec de la génération du rapport d’audit lors du traitement de finalisation.
4571362	Correctif : Le traitement de finalisation gère désormais les événements indiquant l’épuisement des tentatives de remise par SMS sans interrompre la génération du rapport d’audit. Les e-mails de finalisation destinés à l’expéditeur et au signataire sont ainsi envoyés une fois l’accord signé.
4571642	Résumé : Les noms des signataires fournis via l’API pouvaient être absents de la réponse de l’accord et rester modifiables lors de la signature alors que la modification du nom du signataire était désactivée, car le nom fourni par l’expéditeur n’était pas conservé pour les destinataires ne disposant pas d’un nom de profil.
4571642	Correctif : La gestion des noms des destinataires conserve désormais les noms fournis par l’expéditeur lorsque la modification du nom du signataire est désactivée. Le nom est ainsi renvoyé dans la réponse de l’accord et apparaît prérempli et verrouillé sur la page de signature.
4571797	Résumé : Certains accords de signature en masse ayant échoué ou ayant été ignorés ne pouvaient pas être prévisualisés depuis la page Gérer, car l’aperçu de l’accord utilisait un document Portfolio intermédiaire au lieu de revenir au document d’accord d’origine.
4571797	Correctif : Le traitement des signatures en masse rétablit désormais les accords ayant échoué ou ayant été ignorés vers leur version précédente du document, ce qui permet de les ouvrir et de les prévisualiser depuis la page Gérer.
4572223	Résumé : Les accords créés par un workflow pouvaient être automatiquement annulés pendant le traitement du document lorsque la génération de vignettes se terminait seulement partiellement, ce qui entraînait l’échec de la finalisation lorsque le système essayait d’utiliser une vignette de page manquante.
4572223	Correctif : La finalisation des documents est désormais plus robuste et traite correctement les données de miniatures manquantes ou incomplètes, évitant ainsi l’annulation automatique des accords créés via un workflow concernés par ce problème.
4572763	Résumé : Les accords de signature en personne créés via l’API pouvaient ne pas s’ouvrir lorsque le participant hôte ne disposait pas du paramètre d’authentification requis. En outre, la documentation de l’API ne décrivait pas clairement la configuration requise pour le signataire en personne et l’hôte.
4572763	Correctif : La documentation de l’API a été mise à jour afin de décrire les rôles requis IN_PERSON_SIGNER et HOST, les libellés d’ensemble de participation correspondants, ainsi que les paramètres d’authentification de l’hôte nécessaires pour créer correctement des accords de signature en personne via l’API.
4575098	Résumé : Les champs de type case à cocher renseignés via des données de fusion pouvaient apparaître comme cochés dans l’interface de création moderne, même lorsque la valeur fournie était « 0 », car Acrobat Sign interprétait les valeurs de chaîne « 0 » et « 1 » comme des cases cochées.
4575098	Correctif : La gestion des champs de fusion de type case à cocher a été mise à jour afin que l’interface de création moderne interprète correctement « 0 » comme non coché et « 1 » comme coché, conformément au comportement de l’interface de création classique.
4578199	Résumé : Le téléchargement du rapport d’audit pouvait échouer pour certains accords, car un événement d’audit n’était pas correctement traité lors de la génération du rapport d’audit, ce qui amenait Adobe Acrobat Sign à renvoyer une erreur générique.
4578199	Correctif : La génération du rapport d’audit gère désormais correctement l’événement d’audit concerné, ce qui permet de générer et de télécharger les rapports d’audit sans provoquer l’erreur générique.
4578567	Résumé : Les utilisateurs Safari dans l’environnement Adobe Acrobat Sign Sandbox pouvaient être redirigés vers la page de connexion après s’être connectés car la session du navigateur n’était pas conservée correctement après l’authentification.
4578567	Correctif : La gestion des sessions a été mise à jour afin qu’Acrobat Sign conserve la session Safari authentifiée après la connexion. Après le déploiement de cette version, les utilisateurs devront peut-être effacer leur session de navigateur existante une fois.