Guide d'utilisation Annuler

Notes de mise à jour d’Adobe Acrobat Sign

Rechercher

Dernière mise à jour le 5 mars 2026

Adobe Acrobat Sign

Ouvrir sur le Web

Guide Adobe Acrobat Sign

Nouveautés

Commencer

Administration

Présentation d’Admin Console
Gestion des utilisateurs
1. Ajout, modification et examen d’utilisateurs actifs
2. Création d’utilisateurs axés sur les fonctions
  1. Comptes techniques - Pilotés par API
  2. Comptes de service - Pilotés manuellement
3. Examen des utilisateurs qui n’ont pas terminé la vérification
4. Recherche d’utilisateurs présentant des erreurs d’approvisionnement
5. Modification du nom/de l’adresse e-mail
6. Modification de l’appartenance d’un utilisateur à un groupe
7. Modification de l’appartenance d’un utilisateur à un groupe via l’interface de groupe
8. Promotion d’un utilisateur à un rôle d’administrateur
9. Types d’identités des utilisateurs et SSO
10. Changement d’identité d’utilisateur
11. Authentification des utilisateurs avec Microsoft Azure
12. Authentification des utilisateurs avec la fédération Google
13. Profils de produit
14. Expérience de connexion
Paramètres de compte/groupe
1. Présentation des paramètres
2. Paramètres généraux
  1. ID et niveau de compte
  2. Nouvelle expérience pour les destinataires
  3. Workflows de signature automatique
  4. Envoi en masse
  5. Formulaires web
  6. Workflows d’envoi personnalisés
  7. Workflows Power Automate
  8. Documents de bibliothèque
  9. Collecte des données de formulaire avec les accords
  10. Visibilité limitée de documents
  11. Ajout d’une copie PDF de l’accord signé en pièce jointe
  12. Insertion d’un lien dans l’e-mail
  13. Insertion d’une image dans l’e-mail
  14. Fichiers joints à un e-mail nommés
  15. Ajout de rapports d’audit aux documents en pièces jointes
  16. Fusion de plusieurs documents en un seul
  17. Téléchargement de documents individuels
  18. Chargement d’un document signé
  19. Délégation pour les utilisateurs de mon compte
  20. Autorisation de la délégation des destinataires externes
  21. Autorisation de signature
  22. Autorisation d’envoi
  23. Pouvoir d’ajouter des cachets électroniques
  24. Définition d’un fuseau horaire par défaut
  25. Définition d’un format de date par défaut
  26. Utilisateurs dans plusieurs groupes (UMG)
    1. Mise à niveau pour utiliser la fonctionnalité Utilisateurs dans plusieurs groupes
  27. Autorisations d’administrateur de groupe
  28. Remplacement du destinataire
  29. Rapport d’audit
    1. Présentation
    2. Autorisation des accès non authentifiés sur la page de vérification des transactions
    3. Inclusion des rappels
    4. Insertion des événements de consultation
    5. Inclusion du nombre de pages/pièces jointes de l’accord
  30. Pied de page de la transaction
  31. Dans les messages et les conseils sur les produits
  32. PDF accessibles
  33. Client du secteur de la santé
3. Configuration du compte / Paramètres de la marque
  1. Présentation
  2. Ajout d’un logo
  3. Personnalisation du nom d’hôte/de l’URL de la société
  4. Ajout du nom de l’entreprise
  5. Redirection d’URL une fois l’accord complété
4. Préférences de signature
  1. Signatures correctement formatées
  2. Autorisation des destinataires à signer par
  3. Possibilité pour les signataires de modifier leur nom
  4. Autorisation des destinataires à utiliser leur signature enregistrée
  5. Personnalisation des conditions d’utilisation et de la règle concernant la divulgation des informations de l’utilisateur
  6. Navigation des destinataires dans les champs de formulaire
  7. Redémarrage du workflow de l’accord
  8. Refus de signer
  9. Autorisation des processus avec tampons
  10. Ajout de la fonction ou la société obligatoire pour les destinataires
  11. Autorisation des signataires à imprimer et à apposer une signature manuscrite
  12. Affichage des messages lors de la signature électronique
  13. Obligation pour les signataires d’utiliser un appareil mobile pour créer leur signature
  14. Adresse IP des signataires requise
  15. Exclusion du nom de la société et de la fonction des tampons de participation
  16. Application de la mise à l’échelle de signature à main levée adaptative
5. Signatures numériques
  1. Présentation
  2. Téléchargement et signature d’un document avec Acrobat
  3. Signatures en mode cloud
  4. Exiger des signatures numériques par destinataire
  5. Inclure les métadonnées pour les fournisseurs d’identité
  6. Fournisseurs de signature en mode cloud restreints
6. Cachets électroniques
7. Identité numérique
  1. Passerelle d’identités numériques
  2. Politique de vérification d’identité
8. Paramètres de rapport
  1. Nouvelle expérience de rapport
  2. Paramètres de rapport classiques
9. Paramètres de sécurité
  1. Paramètres d’authentification unique
  2. Paramètres de mémorisation
  3. Politique de mot de passe de connexion
  4. Sécurité du mot de passe de connexion
  5. Durée de la session web
  6. Type de chiffrement PDF
  7. API
  8. Accès aux informations sur les utilisateurs et les groupes
  9. Plages d’adresses IP autorisées
  10. Partage de compte
  11. Autorisations de partage de compte
  12. Commandes de partage d’accords
  13. Vérification de l’identité des signataires
  14. Mot de passe de signature des accords
  15. Sécurité du mot de passe du document
  16. Blocage des signataires par géolocalisation
  17. Authentification téléphonique
  18. Authentification basée sur les connaissances (KBA)
  19. Autorisation de l’extraction de pages
  20. Expiration du lien de document
  21. Chargement d’un certificat client pour les webhooks/rappels
  22. Horodatage
10. Paramètres d’envoi
  1. Affichage de la page Envoyer après la connexion
  2. Expériences de création d’accords
  3. Nom du destinataire requis lors de l’envoi
  4. Verrouillage des valeurs de nom pour les utilisateurs connus
  5. Rôles autorisés du destinataire
  6. Autorisation des témoins électroniques
  7. Groupes de destinataires
  8. En copie
  9. Champs requis
  10. Ajout de documents en pièces jointes
  11. Aplatissement du champ
  12. Modification des accords
  13. Suppression de destinataires des accords en cours
  14. Nom de l’accord
  15. Langues
  16. Messages privés
  17. Types de signature autorisés
  18. Rappels
  19. Protection par mot de passe des documents signés
  20. Envoi d’une notification d’accord par
  21. Options d’identification du signataire
    1. Présentation
    2. Mot de passe de signature
    3. Authentification fondée sur les connaissances
    4. Authentification téléphonique
    5. Authentification par WhatsApp
    6. Mot de passe à usage unique par e-mail
    7. Authentification Acrobat Sign
    8. Signatures numériques basées sur le cloud
    9. Authentification d’identités numériques
    10. Pièce d’identité officielle
    11. Rapports d’identité des signataires
  22. Remplissage de champs de formulaire avec des données d’identité vérifiées
  23. Protection du contenu
  24. Activation des transactions Notarize
  25. Expiration du document
  26. Aperçu, positionnement des signatures et ajout de champs
  27. Ordre de signature
  28. M’ajouter
  29. Télécharger le lien de l’accord
  30. Bordures des champs de formulaire
  31. Liquid Mode
  32. Commandes de workflow personnalisé
  33. Options de chargement pour la page de signature électronique
  34. Redirection de l’URL de confirmation post-signature
  35. Limiter l’accès aux accords partagés
11. Modèles de message
  1. Présentation des modèles de message
  2. Création de nouveaux modèles de message
  3. Modification des modèles de message
  4. Suppression de modèles de message
12. Paramètres bio-pharma
  1. Présentation
  2. Fonction Appliquer l’authentification de l’identité
  3. Motifs de la signature
13. Intégration des workflows
14. Paramètres d’authentification notariale
15. Intégration des paiements
16. Messages pour les signataires
17. Paramètres SAML
  1. Configuration SAML
  2. Installation des services Microsoft Active Directory Federation Services
  3. Installation d’Okta
  4. Installation de OneLogin
  5. Installation d’Oracle Identity Federation
18. Gouvernance des données
19. Paramètres d’horodatage
20. Archive externe
21. Langues du compte
22. Paramètres de messagerie
  1. Images d’en-tête et de pied de page d’e-mail
  2. Autorisation de pieds de page dans l’e-mail d’un utilisateur individuel
  3. Personnalisation de l’e-mail « Signature requise »
  4. Personnalisation des champs « À » et « Cc »
  5. Activation des notifications sans lien
  6. Personnalisation des modèles de courrier électronique
23. Migration d’echosign.com vers adobesign.com
24. Configuration des options pour les destinataires
Conseils relatifs aux exigences réglementaires
1. Accessibilité
2. HIPAA
3. RGPD
4. 21 CFR Part 11 et EudraLex Annexe 11
5. Clients du secteur de la santé
6. Prise en charge du service fiscal Income Verification Express Service (IVES)
7. Accords « placés dans le coffre »
8. Considérations relatives à l’Union européenne et au Royaume-Uni
Téléchargement d’accords en masse
Dépôt de votre domaine
Liens Signaler un abus
Exigences et limites système
1. Configuration requise
2. Limites des transactions

Envoi, signature et gestion des accords

Options du destinataire
1. Annulation d’un rappel par e-mail
2. Options de la page de signature électronique
Envoyer les accords
1. Page Envoyer (Composition)
  1. Présentation des points de repère et des fonctionnalités
  2. Sélecteur de groupe
  3. Ajout de fichiers et de modèles
  4. Nom de l’accord
  5. Message global
  6. Échéance
  7. Rappels
  8. Protection du PDF par mot de passe
  9. Type de signature
  10. Localisation du destinataire
  11. Ordre/flux de signature des destinataires
  12. Rôles du destinataire
  13. Authentification du destinataire
  14. Message privé pour le destinataire
  15. Accès du destinataire à l’accord
  16. Parties en copie
  17. Contrôle d’identité
2. Envoi d’un accord uniquement à vous-même
3. Envoi d’un accord à d’autres utilisateurs
4. Signatures manuscrites
5. Ordre de signature des destinataires
6. Envoi en masse
Création de champs dans des documents
1. Environnement de création intégré à l’application
  1. Détection automatique des champs
  2. Glisser-déposer des champs à l’aide de l’environnement de création
  3. Affectation des champs de formulaire aux destinataires
  4. Rôle de préremplissage
  5. Application de champs à l’aide d’un modèle de champ réutilisable
  6. Transfert de champs vers un nouveau modèle de bibliothèque
  7. Mise à jour de l’environnement de création lors de l’envoi d’accords
2. Création de formulaires avec des balises de texte
3. Création de formulaires avec Acrobat (AcroForms)
  1. Création d’un formulaire AcroForm
  2. Création de fichiers PDF accessibles
4. Champs
  1. Types de champ
    1. Types de champs communs
    2. Champs Signature électronique
    3. Champ Paraphe
    4. Champ Nom du destinataire
    5. Champ E-mail du destinataire
    6. Champ Date de signature
    7. Champ Texte
    8. Champ Date
    9. Champ Nombre
    10. Case à cocher
    11. Groupe de cases à cocher
    12. Bouton radio
    13. Menu déroulant
    14. Superposition de lien
    15. Champ Paiement
    16. Pièce jointe
    17. Tampon Participation
    18. Numéro de transaction
    19. Image
    20. Société
    21. Titre
    22. Tampon
  2. Apparence du contenu d’un champ
  3. Validations des champs
  4. Valeurs des champs masqués
  5. Définition des conditions d’affichage/de masquage
  6. Champs calculés
  7. Formulaires vérifiés
5. FAQ sur la création
Signature d’accords
Gérer les accords
Rapport d’audit
Rapports et exportations de données
1. Présentation
2. Octroi aux utilisateurs d’un accès aux rapports
3. Graphiques de rapports
4. Exportations de données
5. Attribution d’un nouveau nom à un graphique/une exportation
6. Duplication d’un rapport/d’une exportation
7. Planification d’un rapport/d’une exportation
8. Suppression d’un rapport/d’une exportation
9. Vérification de l’utilisation des transactions

Fonctionnalités et workflows d’accord avancés

Formulaires web
Modèles réutilisables (modèles de bibliothèque)
Transfert de la propriété des formulaires web et des modèles de bibliothèque
Workflows Power Automate
1. Présentation de l’intégration Power Automate et des droits inclus
2. Activation de l’intégration Power Automate
3. Actions contextuelles sur la page Gérer
4. Suivi de l’utilisation de Power Automate
5. Création d’un flux (exemples)
6. Déclencheurs utilisés pour les flux
7. Importation de flux depuis l’extérieur d’Acrobat Sign
8. Gestion des flux
9. Modification des flux
10. Partage des flux
11. Désactivation ou activation des flux
12. Suppression des flux
13. Modèles utiles
  1. Administrateur uniquement
  2. Archivage des accords
    1. Enregistrement des documents terminés dans SharePoint
    2. Enregistrement des documents terminés dans OneDrive Entreprise
    3. Enregistrement de vos documents terminés dans Google Drive
    4. Enregistrement de vos documents terminés dans Dropbox
    5. Enregistrement des documents terminés dans Box
  3. Archivage des accords de formulaire web
    1. Enregistrement des documents de formulaire web terminés dans une bibliothèque SharePoint
    2. Enregistrement des documents de formulaire web terminés dans OneDrive Entreprise
    3. Enregistrement des documents terminés dans Google Drive
    4. Enregistrement des documents de formulaire web terminés dans Box
  4. Extraction des données d’accord
    1. Extraction des données des champs de formulaire de votre document signé et mise à jour de la feuille Excel
  5. Notifications d’accord
    1. Envoi de notifications personnalisées par e-mail avec le contenu de votre accord et l’accord signé
    2. Obtention des notifications Adobe Acrobat Sign dans un canal Teams
    3. Obtention des notifications Adobe Acrobat Sign dans Slack
    4. Obtention des notifications Adobe Acrobat Sign dans Webex
  6. Génération d’un accord
    1. Génération d’un document à partir d’un formulaire Power Apps et d’un modèle Word et envoi pour signature
    2. Génération d’un accord à partir d’un modèle Word dans OneDrive et obtention d’une signature
    3. Génération d’un accord pour la ligne Excel sélectionnée, envoi pour révision et signature
Workflows d’envoi personnalisés
Partage d’utilisateurs et d’accords
1. Partage d’un utilisateur
2. Partage d’accords

Intégration à d’autres produits

Développeur Acrobat Sign

Assistance et dépannage

Remarque :

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 anglaise américaine de la page comme la version la plus récente et la plus précise.

Adobe Acrobat Sign version v17.0.1

Déploiement en production : 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.
La fonction Créer une copie est désormais disponible directement à partir des filtres En cours et En attente de votre intervention sur la page Gérer, ainsi qu’à partir de la page de confirmation après l’envoi. Ces points d’entrée supplémentaires facilitent la réutilisation des accords à davantage d’étapes du cycle de vie d’envoi, réduisant ainsi le besoin de redémarrer à zéro.
Remarque : Avec cette version, les contrôles administratifs permettant de désactiver cette fonctionnalité seront supprimés du menu d’administration, établissant Créer une copie comme une capacité 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é par défaut.

Consulter la documentation d’actions utilisateur mise à jour >

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’adresse e-mail personnalisée OEM 2.0 – Identité de l’expéditeur et du destinataire plus claire dans les expériences intégrées, et diffusion d’adresse e-mail correcte.
Pour les workflows intégrés OEM 2.0, Acrobat Sign affiche désormais l’adresse e-mail personnalisée d’un utilisateur au lieu de l’adresse e-mail enregistrée par le partenaire sur les principales surfaces de l’interface utilisateur et les notifications. 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 les signataires et empêche l’envoi d’e-mails vers des adresses enregistrées non distribuables.

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

Notification webhook pour les échecs de distribution de SMS – Visibilité en temps réel des échecs d’envoi de SMS, correction automatisée et parité avec les renvois d’e-mail.
Acrobat Sign émet désormais un nouvel événement webhook, AGREEMENT_PHONE_BOUNCED, lorsqu’un accord envoyé par SMS ne peut pas être distribué en raison de problèmes tels que des numéros de téléphone non valides, le rejet par l’opérateur ou des lignes bloquées. Cela permet aux clients de détecter les échecs de distribution de SMS en temps réel et de déclencher automatiquement des actions de suivi comme la correction des numéros de téléphone, les nouvelles tentatives de distribution ou l’ouverture de dossiers de support, éliminant les angles morts et réduisant les retards dans les workflows de signature via mobile.

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

Charges utiles Webhook : ajout du champ conditionnel extendedStatus des participants pour les mises à jour dynamiques de la participation, améliorant ainsi la visibilité du statut 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 informations supplémentaires sur le cycle de vie des participants tout en laissant le champ de statut existant inchangé pour la rétrocompatibilité.

        {
          &quot;participantSets&quot;: [
            {
              &quot;id&quot;: &quot;&quot;,
              &quot;memberInfos&quot;: [
                {
                  &quot;company&quot;: &quot;TestCo&quot;,
                  &quot;email&quot;: &quot;signer2@someDomain.dom&quot;,
                  &quot;id&quot;: &quot;CBJCHBCAABAAJiZV9cH&quot;,
                  &quot;name&quot;: &quot;Signer Two&quot;,
                  &quot;status&quot;: &quot;ACTIVE&quot;,
                  &quot;extendedStatus&quot;: &quot;REMOVED&quot;
                }
              ],
              &quot;order&quot;: ,
              &quot;role&quot;: &quot;&quot;,
              &quot;status&quot;: &quot;&quot;
            }
          ]
        }

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

Environnements disponibles : Sandbox, Commercial, Gouvernement | 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 rejet d’e-mail webhook peut être généré de manière incorrecte pour un signataire valide après que le signataire a signé avec succès 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égateur d’origine. Dans ces cas, le système peut incorrectement attribuer l’événement de rejet « signé au nom de… » au signataire valide au lieu du participant dont l’e-mail est réellement rejeté.
4543515	Correction : La logique d’attribution d’événement a été corrigée afin que les événements de rejet d’e-mail soient associés uniquement au participant dont l’e-mail est réellement rejeté. Un événement de rejet n’est plus généré pour un signataire valide qui a déjà terminé la signature, et les notifications webhook reflètent maintenant le participant et l’adresse e-mail corrects.
4544548	Résumé : Les clés d’intégration créées via l’interface utilisateur 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	Correction : Les messages de l’interface utilisateur 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 de très gros documents, même lorsque la création d’accord se termine et que les premières étapes de traitement semblent se terminer en quelques minutes. Pendant le délai de retard, 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 de réessayer ou que les documents deviennent disponibles.
4546301	Correction : La gestion de la disponibilité des documents a été corrigée afin que les gros accords 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 de création via l’API puis modifié depuis l’expérience de gestion. Dans ce scénario, l’interface utilisateur peut afficher la Valeur Message privé comme « Aucun » ou vide même si les données d’accord incluent la Valeur Message privé correcte. Ce comportement apparaît dans les scénarios de compte partagé où un utilisateur bascule dans 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	Correction : Une vérification a été ajoutée pour récupérer le contexte de partage actif 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 l’affichage ou de l’envoi d’un brouillon créé par API depuis le flux de 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 utilisateur Gérer et dans les vues administratives, ce qui fait paraître 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 l’horodatage de modification du modèle.
4548274	Correction : Le comportement de mise à jour de la date de modification a été aligné entre la nouvelle expérience de Modèle et les opérations API associées. Le chemin d’accès de code qui enregistre les modifications de champs de Modèle met maintenant également à jour la date de modification du Modèle afin qu’elle reflète l’heure réelle 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 concernés, les annotations de tampon se chevauchent ou masquent les champs interactifs pendant le traitement, ce qui entraîne le masquage des signatures terminées et d’autres champs 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 rejet d’adresse e-mail peut être consigné à nouveau pour un destinataire précédemment incorrect après que l’expéditeur a remplacé ce destinataire par une adresse e-mail valide. Dans certains cas, la piste d’audit peut afficher un second événement de rejet pour l’ancienne adresse e-mail, et le statut de l’accord peut indiquer « adresse e-mail rejetée » même si le nouveau destinataire reçoit, consulte ou signe l’accord avec succès. Ce comportement peut donner l’impression 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’adresses e-mail de notification supplémentaires à un destinataire remplacé dont l’adresse e-mail a déjà été rejetée. Le système vérifie désormais l’historique de rebond antérieur avant d’envoyer les notifications liées au remplacement, garantissant qu’aucun nouvel événement de rebond 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 charger à nouveau et effacer le champ adresse e-mail au lieu de rediriger l’utilisateur vers la partition correcte ou la page de connexion SSO. Cela empêche les utilisateurs concernés de terminer l’authentification et bloque les intégrations qui s’appuient sur le point d’entrée de connexion public.
4549306	Correctif : La logique de résolution de partition 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 construire l’URL de redirection inter-partition. Les utilisateurs avec des formats d’e-mail concernés sont désormais correctement redirigés vers leur partition désignée et leur page de connexion SSO sans que le champ adresse e-mail soit effacé.
4549331	Résumé : Les signatures et autres champs de formulaire peuvent apparaître manquants ou invisibles dans le PDF signé lorsque certaines fonctionnalités de traitement de document sont activées et que le PDF source contient des coordonnées de boîte de page non valides (par exemple, des valeurs CropBox ou MediaBox incorrectes). Dans ce scénario, les champs qui s’appuient sur les coordonnées de page peuvent générer le rendu en dehors de la zone de page visible, faisant apparaître les signatures terminées comme manquantes même si la signature se termine avec succès.
4549331	Correctif : La gestion des boîtes de page PDF a été corrigée pour normaliser en toute sécurité les valeurs CropBox et MediaBox non valides pendant le traitement du document. Par conséquent, le placement des signatures et des champs de formulaire s’aligne désormais 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 de serveur » générique après avoir sélectionné Aperçu et Ajouter des champs lorsque l’authentification de 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, même si l’authentification de signataire du formulaire web est définie sur une méthode non téléphonique (par exemple, Adobe Sign). Par conséquent, tous les utilisateurs du compte concerné peuvent être empêchés de créer des formulaires web sur tous les documents.
4550367	Correctif : La création de formulaire web évalue désormais le quota uniquement pour la méthode d’authentification réellement configurée pour le signataire du formulaire web, et n’applique plus les 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 quota fausses et permet aux formulaires web d’être créés normalement.
4551011	Résumé : Lorsqu’un expéditeur télécharge certains 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 la signature. Ce comportement peut se produire lorsque le PDF téléchargé contient des métadonnées de limite de page non valides (les coordonnées MediaBox et CropBox apparaissent inversées), ce qui peut entraîner le rendu des couches d’apparence de signature et d’autres champs en dehors de la zone de page visible.
4551011	Correctif : La gestion des limites de page 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 d’apparence de signature et de champ de formulaire génère le rendu dans la zone de page visible et reste visible dans le PDF signé final.
4551427	Résumé : Certains destinataires qui possèdent déjà des comptes actifs correctement provisionnés reçoivent les accords en tant que destinataires « pseudo-utilisateur », de sorte que l’accord n’apparaît pas dans leur vue Gérer habituelle. Cela se produit lorsque les adresses e-mail des destinataires incluent des espaces en début ou en fin, ce qui empêche le système de faire correspondre l’adresse e-mail à l’utilisateur existant et provoque la création d’un enregistrement de pseudo-utilisateur.
4551427	Correctif : L’analyse des adresses e-mail et la recherche d’utilisateurs ont été mises à jour pour normaliser les adresses e-mail des destinataires (rogner les espaces en début et en fin) avant de les faire correspondre aux utilisateurs existants. Par conséquent, les accords adressés aux utilisateurs existants sont résolus vers le compte enregistré au lieu de créer un destinataire pseudo-utilisateur, même si l’adresse e-mail a été saisie avec des espaces (dans les charges utiles d’API et les listes de destinataires de workflow).
4553198	Résumé : Lorsqu’un accord inclut au moins un destinataire configuré pour la diffusion SMS et au moins un destinataire configuré pour la diffusion par adresse e-mail uniquement, l’annulation de l’accord via l’API n’envoie pas de notification d’annulation par SMS au destinataire SMS. L’accord est annulé avec succès et les notifications par adresse 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 SMS lorsqu’un accord est annulé, indépendamment des méthodes de diffusion des autres destinataires.
4554463	Résumé : Lorsque les accords incluent des cases d’option clonées qui partagent le même nom de champ dans 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 cases d’option. Après signature, la Valeur sélectionnée ne se propage pas de manière cohérente dans toutes les instances clonées, provoquant un mappage incorrect ou incomplet de la sélection attendue.
4554463	Correctif : La logique de gestion des champs de formulaire a été corrigée de sorte que les cases d’option clonées 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 case d’option reflètent la sélection correcte dans le PDF signé.
4554593	Résumé : Certaines intégrations de partenaires qui utilisent les points de terminaison OAuth hérités pour actualiser les jetons d’accès ont commencé à échouer avec des erreurs HTTP 401. Le service a rejeté les demandes d’actualisation de jeton avec une erreur indiquant que l’application n’est pas autorisée à utiliser les points de terminaison OAuth hérités et doit utiliser les points de terminaison OAuth v2 à la place. Cela a empêché les clients d’authentifier Acrobat Sign via les applications partenaires, même pour les intégrations qui fonctionnaient auparavant.
4554593	Correction : Le service d’authentification a été corrigé de sorte que les applications partenaires configurées pour utiliser le flux OAuth hérité peuvent à nouveau actualiser les jetons avec succès, au lieu d’être incorrectement forcées vers les points de terminaison 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 est configuré pour exiger l’acceptation des 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	Correction : Le flux d’actualisation du jeton de signature a été corrigé de sorte que lorsque le signataire accepte les conditions d’utilisation avant de signer, le jeton de signature réémis conserve les détails d’authentification du signataire. Cela empêche l’étape finale de signature d’échouer à l’authentification et élimine le basculement forcé de la signature moderne vers l’expérience classique.
4555656	Résumé : Dans des conditions de synchronisation spécifiques, une transition d’état d’accord peut sembler réussir mais ne modifie pas réellement l’état de l’accord. Lorsqu’une notification webhook est reçue avant que le traitement backend soit terminé, les appels d’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 n’est pas dans un état valide pour la transition demandée. Par conséquent, les processus d’automatisation peuvent supposer que la transition a réussi alors que l’accord reste dans l’état d’origine.
4555656	Correction : La logique de transition d’état d’accord a été mise à jour pour appliquer une validation stricte avant d’appliquer une transition. Si l’accord n’est pas dans un état valide, l’API renvoie désormais une réponse d’erreur claire au lieu de renvoyer silencieusement un succès. Cela garantit que les transitions non valides sont explicitement rejetées, permet aux systèmes appelants de réessayer de manière appropriée et empêche les accords de rester dans un état non souhaité sans visibilité.