Dernière mise à jour le
19 juin 2026
Annotation
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.2
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 >
Problèmes résolus
| Problème | Description |
|---|---|
| 4487069 | Résumé : La notification non remise sur la page Gérer pouvait disparaître pendant que les utilisateurs faisaient défiler la liste des contrats car cette liste réutilisait les composants de ligne et n’actualisait pas l’état de notification pour chaque contrat. |
| Correctif : La page Gérer actualise désormais l’état des notifications de non-remise lorsque les lignes d’accord sont réutilisées, de sorte que les notifications restent visibles pendant le défilement de la liste. | |
| 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ées lors de la conversion de modèle, tandis que les liens URL exposés restaient cliquables. |
| Correctif : Le traitement PDF a été mis à jour pour préserver les données de lien hypertexte intégrées lors de la conversion de modèle réutilisable, de sorte que les liens intégrés et URL exposés restent cliquables dans l’aperçu de modèle. | |
| 4555107 | Résumé : Les téléchargements d’API de documents combinés pouvaient omettre le rapport d’audit même lorsque attachAuditReport=true était utilisé, car certaines demandes étaient incorrectement traitées comme non authentifiées lorsque la génération d’ID d’action API échouait. |
| 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 de Safari pouvaient être renvoyés vers la page de connexion après s’être connectés, car les mécanismes de protection de la confidentialité introduits dans les versions récentes de Safari empêchaient la conservation correcte des cookies de session d’Adobe Acrobat Sign lors du processus d’authentification Adobe. |
| 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é. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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 vide et échouer à générer un jeton porteur car la page de redirection OAuth rejetait les URL de domaine de document Acrobat valides lors de la validation de redirection. |
| Correctif : La validation de redirection OAuth de Swagger a été mise à jour pour autoriser 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. |
| Correctif : Le processus de fusion PDF ignore désormais les champs de signature lors de l’application des valeurs de formulaire, empêchant les valeurs de workflow internes d’être écrites dans les champs de signature et préservant la structure de document multi-signature valide. | |
| 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. |
| Correctif : Le rendu des tampons a été mis à jour afin que les réglages de mise en page des motifs 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. |
| 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 contrats copiés pouvaient inclure des destinataires qui avaient été supprimés via Modifier le contrat, car le processus de copie n’excluait pas entièrement les destinataires supprimés lors de la reconstruction de la liste des destinataires et des groupes de routage. |
| Correction : Le workflow de copie filtre désormais les destinataires supprimés via Modifier le contrat 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 contrats finalisé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 rendu lors du traitement final du PDF. |
| Correction : Le traitement PDF ignore désormais les champs de case à cocher invisibles lors du rendu du contrat finalisé, de sorte que les sélections de cases à cocher visibles restent affichées dans le document signé final. | |
| 4569490 | Résumé : Certains e-mails de notification Adobe Acrobat Sign pouvaient être marqués comme spam car le balisage de pré-en-tête des e-mails incluait des motifs de style masqués ou à faible contraste que certains filtres de courrier traitent comme suspects. |
| 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 au groupe pouvait échouer avec une erreur non gérée lorsque la validation du statut utilisateur rencontrait un enregistrement d’appartenance à un groupe incomplet. |
| 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. |
| 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. |
| Correction : Le traitement des documents valide désormais les destinations de lien 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. |
| 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. |
| 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. |
| Correction : La gestion des noms de destinataire conserve désormais les noms fournis par l’expéditeur lorsque la modification du nom du signataire est désactivée, de sorte que le nom est renvoyé dans la réponse du contrat 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. |
| Correction : Le traitement de signature en masse restaure désormais les accords ayant échoué ou ignorés à la version du document précédente, de sorte que les accords peuvent être ouverts et prévisualisés depuis Gérer. | |
| 4572223 | Résumé : Les accords créés à l’aide d’un workflow pouvaient être automatiquement annulés lors du traitement du document lorsque la génération des miniatures n’était que partiellement terminée, ce qui provoquait un échec de la finalisation lorsque le système tentait d’utiliser une miniature de page manquante. |
| 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. |
| 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. |
| 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. |
| 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 de Safari dans l’environnement Sandbox d’Adobe Acrobat Sign pouvaient être redirigés vers la page de connexion après s’être connectés, car la session du navigateur n’était pas correctement conservée après l’authentification. |
| Correctif : La gestion des sessions a été mise à jour afin qu’Acrobat Sign préserve 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. |
Simplifiez votre travail avec Acrobat Sign
Gérez et signez des documents en ligne rapidement et facilement.
