Première notification : août 2024
Dernière mise à jour le
3 juin 2026
Les notifications techniques Adobe Sign sont classées ci-dessous avec la mise à jour la plus ancienne en haut et avancent dans le temps au fur et à mesure que vous faites défiler la page.
|
|
Retrait depuis : janvier 2025 |
|---|
L’en-tête Accept-Charset hérité sera supprimé de toutes les notifications de webhooks et de rappels avec la version de novembre 2024.
Tous les clients qui s’appuient sur cet en-tête pour quelque raison que ce soit doivent refactoriser leur code pour tenir compte de son absence.
|
Première notification : septembre 2024 |
Retrait depuis : janvier 2025 |
|---|
|
Première notification : novembre 2024 |
Retrait depuis : janvier 2025 |
|---|
Avec la version de novembre 2024, les libellés modifiables dans le concepteur de workflow personnalisé ont été limités à 100 caractères. Cette limite est évaluée lors de la création ou de la mise à jour du workflow.
Les workflows préexistants dont les libellés dépassent 100 caractères peuvent toujours être envoyés, mais si le workflow est mis à jour, le libellé doit être ramené à 100 caractères ou moins avant de pouvoir être enregistré. Les libellés concernés sont soulignés en rouge pour faciliter leur détection.
Les nouveaux workflows seront avertis de la limite appliquée aux libellés avant d’être enregistrés.
Action requise
Il est recommandé aux administrateurs ayant le contrôle des workflows personnalisés d’ouvrir et d’examiner chaque workflow pour s’assurer qu’il n’y a pas d’erreurs dans leur modèle.
|
Première notification : novembre 2024 |
Retrait de la liste actuelle : février 2025 |
|---|
La nouvelle expérience du destinataire contient des améliorations de signature pour les navigateurs web de bureau et mobiles.Cette nouvelle expérience sera déployée au cours des premiers mois de 2025, mais sera disponible dans l’environnement Sandbox au cours de la première semaine de décembre 2024.
|
Première notification : décembre 2024 |
Retrait de la liste actuelle : février 2025 |
|---|
Adobe Acrobat Sign changera de certificat SSL le 22 janvier 2025.
De plus, un nouveau certificat SSL est déployé pour prendre en charge les modifications du réseau WAF effectuées en janvier 2025. Ce nouveau certificat a une incidence directe sur l’accès au service Acrobat Sign et doit être installé avant que le réseau WAF ne soit en ligne.
Action requise
- Chaque compte client qui sécurise explicitement l’activité du réseau doit inclure le nouveau certificat SSL WAF dans sa liste de certificats stockés.
- Si vous disposez d’intégrations personnalisées Acrobat Sign utilisant les API SOAP ou REST et si l’une de ces intégrations comprend la clé publique existante, aucune autre action n’est requise.
- Si vous utilisez les certificats SSL d'Acrobat Sign pour l'authentification unique, ou si vous épinglez le certificat lui-même (ou utilisez d'autres méthodes), vous pouvez trouver les nouveaux certificats SSL Acrobat Sign dans la Configuration requise du système Adobe Acrobat Sign.
- Si votre configuration SSO prend en charge plusieurs certificats/chaînes publics, vous pouvez ajouter les nouveaux certificats maintenant et supprimer l’ancien certificat public/l’ancienne chaîne publique de votre configuration après le changement de janvier.
- Si votre authentification unique ne prend pas en charge plusieurs chaînes/certificats publics, vous devrez synchroniser votre changement de SSL avec Acrobat Sign le 22 janvier 2025.
Les nouveaux certificats SSL seront actifs à compter du 22 janvier 2025.
|
Première notification : septembre 2024 - Mise à jour : février 2025 |
Supprimé de la liste actuelle : mars 2025 |
|---|
Pour améliorer la sécurité et la robustesse du service Adobe Acrobat Sign, nous apporterons des modifications au réseau afin d’inclure un pare-feu d’application web (WAF) en février 2025. Ces modifications permettront de router le trafic vers les serveurs d’applications Acrobat Sign via le service WAF. Ce routage sera invisible pour la plupart des clients. Cette modification n’interférera pas avec l’accès à Acrobat Sign des clients ou intégrations Adobe.
Action requise
Aucune.
Cette modification n’affectera pas les intégrations client, car l’API Acrobat Sign et les noms de domaine d’API ne changeront pas. Cette solution est rétrocompatible avec les plages d’adresses IP publiées.
Les clients qui ont mis à jour leurs appareils de sécurité n’ont pas besoin d’effectuer une rétrogradation ou toute autre modification.
Le calendrier actuel des mises à jour est le suivant :
- Mise à jour du sandbox de production le 24 février 2025.
- Partitions de production : mises à jour IN1, JP1, AU1 et SG1 le 3 mars 2025.
- Partitions de production : mises à jour NA2, NA3 et EU2 le 6 mars 2025.
- Partitions de production : mises à jour NA1, NA4 et EU1 le 11 mars 2025.
Accès d’entrée et de sortie à Acrobat Sign
Acrobat Sign ne retire plus la liste des adresses IP d’entrée du serveur comme annoncé précédemment.
Les adresses IP d’entrée et de sortie du serveur, comme indiqué sur la page Configuration requise pour Acrobat Sign, resteront valides.
Pourquoi des modifications sont-elles apportées à Acrobat Sign ?
L’utilisation d’un WAF renforce la protection d’Acrobat Sign contre le trafic nuisible et nous permet de mieux répondre aux exigences de sécurité, de robustesse et de conformité.
Je possède une intégration personnalisée dans Acrobat Sign. Mon application sera-t-elle concernée ?
Non, les intégrations ne devraient pas être affectées.
De nouvelles listes d’adresses IP peuvent-elles être substituées ?
Non.
Les informations sur la page Configuration requise pour Acrobat Sign restent exactes.
Mon organisation a mis en œuvre le filtrage réseau à l’aide de la liste des domaines publiée d’Acrobat Sign pour le trafic à partir de notre réseau d’entreprise. Sommes-nous concernés ?
Non.
Les modifications réseau décrites ici n'impactent pas la liste de domaines d'Acrobat Sign, comme documenté sur la page Configuration requise pour Acrobat Sign. Le filtrage au niveau du domaine n’est pas concerné.
Mon organisation utilise la validation des adresses IP pour la remise d’e-mails à partir des serveurs Acrobat Sign. Sommes-nous concernés ?
Non.
Les plages IP pour les relais de courrier sortant, telles que listées sur la page Configuration requise pour Acrobat Sign, ne changent pas.
Mon organisation a configuré notre compte Acrobat Sign pour limiter l’accès à nos propres adresses IP. Sommes-nous concernés ?
Non.
Acrobat Sign peut être configuré pour valider le trafic entrant contre des adresses IP choisies par le client, comme décrit sur la page Restreindre l'accès à votre compte en utilisant des plages d'adresses IP.Cette modification n’affectera pas cette utilisation.
Mon organisation a mis en œuvre le filtrage réseau à l’aide de la liste publiée des adresses IP d’entrée d’Acrobat Sign. Sommes-nous concernés ?
Non.
La nouvelle configuration du WAF est rétrocompatible avec l’architecture réseau existante. Par conséquent, aucun réglage supplémentaire de vos appareils de sécurité ne devrait être nécessaire.
Annotation
notez que cela concerne le filtrage au niveau des adresses IP pour l’environnement hébergeant votre application. Le filtrage au niveau du domaine n’est pas concerné.
J’utilise l’intégration Salesforce avec une liste autorisée d’adresses IP explicitement configurée. Dois-je faire quelque chose ?
Non.
L’installation du WAF ne nécessite aucune modification des installations Salesforce existantes pour le moment.
La configuration/procédure existante, telle que décrite dans la documentation d’aide, reste inchangée et les administrateurs doivent suivre toutes les étapes relatives à la liste autorisée d’adresses IP.
Les partenaires ISV et intégrés doivent contacter leur Gestionnaire de la réussite client pour toute question supplémentaire.
|
Première notification : novembre 2024 - Mise à jour : janvier 2025 |
Supprimé de la liste actuelle : mars 2025 |
|---|
Les expéditeurs peuvent fournir une vue supplémentaire des accords pour les destinataires mobiles qui répertorie uniquement le champ de l’accord disponible pour le destinataire.
Les expéditeurs peuvent organiser la liste des champs comme ils le souhaitent, et regrouper les champs dans des sections logiques pour aider les signataires à parcourir les entrées de champ avec un minimum de défilement.
Les destinataires ont la possibilité d’afficher la liste des champs mobiles ou la vue PDF d’origine avec les champs placés dans le contenu du document.
La publication de cette fonctionnalité est prévue comme suit :
- Déploiement dans l’environnement Sandbox le 11 décembre 2024
- Déploiement dans l’environnement de production le 4 mars 2025
|
Première notification : mai 2024 |
Supprimé de la liste actuelle : mars 2025 |
|---|
Dans la nouvelle expérience Demander une signature, l’utilisation d’un disque externe pour charger des fichiers sera limitée à OneDrive uniquement.
Nous recommandons aux clients qui utilisent d’autres options pour charger des fichiers d’utiliser l’application spécifique au fournisseur pour fournir un disque réseau accessible via le sélecteur de fichiers natif sur le système local de l’utilisateur.
- Dropbox : https://www.dropbox.com/desktop
- Google Drive : https://support.google.com/drive/answer/10838124
- Box : https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat/Document Cloud : https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
Première notification : mai 2024 |
Supprimé de la liste actuelle : avril 2025 |
|---|
Action requise
Toutes les intégrations et applications utilisant l’API SOAP d’Adobe Acrobat Sign doivent être migrées vers la dernière API REST v6 avant la date de désactivation pour garantir la continuité du fonctionnement.
L’accès à l’API SOAP sera supprimé pour tous les partenaires intégrés à partir du 1er mars 2025.
Pour garantir le fonctionnement continu, tous les partenaires intégrés utilisant l’API SOAP Adobe Acrobat Sign doivent migrer vers la version 6 de l’API REST (dernière version en date) avant le 1er mars 2025.
Pour référence, consultez la documentation REST v6 et la documentation de migration :
- Méthodes de l’API REST d’Adobe Sign version 6
- Migration depuis SOAP
Pour toute question, contactez votre PSM Adobe Acrobat Sign désigné.
Annotation
cette mise à jour s’applique uniquement à la version Commerce du service Acrobat Sign. Les comptes Government Cloud ne sont pas concernés.
Cette mise à jour s'applique uniquement à la page Envoyer (Demander des signatures électroniques). Les workflows de signature automatique structurée ne sont pas encore inclus.
|
Première notification : mars 2024 - Mise à jour : janvier 2025 |
Supprimé de la liste actuelle : avril 2025 |
|---|
À partir de la version d’avril 2025, l’environnement moderne Demander une signature deviendra l’expérience par défaut lors de la création d’un accord.
- Les utilisateurs ne pourront plus basculer entre les environnements nouveau et classique, car les liens de basculement seront désactivés.
- Les administrateurs auront toujours la possibilité d’activer l’expérience classique et de restaurer les liens de basculement via le menu d’administrateur.
- Les clients qui utilisent l’intégration Authentifier ne seront pas concernés par cette modification.
|
Premier signalement : mars 2024 - Mis à jour en avril 2025 |
Supprimé de la liste actuelle : avril 2025 |
|---|
Annotation
cette mise à jour s’applique uniquement à la version Commerce du service Acrobat Sign. Les comptes Government Cloud ne sont pas concernés.
Dès la version d'avril 2025, l'environnement moderne Demander une signature deviendra l'expérience par défaut disponible lors de la création d'un nouveau modèle Envoyer en masse.
- Les utilisateurs ne pourront pas revenir à l'environnement classique.
- Les administrateurs auront la possibilité d'activer l'expérience classique et de restaurer les liens de basculement via le menu d'administration.
|
Première notification : février 2025 |
Supprimé de la liste actuelle : avril 2025 |
|---|
L’onglet Compte, disponible pour les administrateurs de compte Acrobat Sign, sera renommé Administrateur.
- Cette mise à jour s’applique exclusivement à l’environnement autonome Acrobat Sign (Acrobat Sign Solutions et Acrobat Sign pour le gouvernement).
- La mise à jour sera implémentée pour l’environnement commercial en avril 2025 et pour l’environnement gouvernemental en mai 2025.
Cette modification est purement cosmétique : il n’y a aucune modification fonctionnelle, seulement des mises à jour des libellés des onglets.
Annotation
le libellé Groupe pour les administrateurs de groupe ne changera pas.
|
Première notification : mars 2025 |
Supprimé de la liste actuelle : avril 2025 |
|---|
- Amélioration de l’expérience de connexion utilisateur : Acrobat Sign a simplifié le processus de connexion et d’authentification par le biais d’Adobe Identity Management System (IMS).
- Le profil organisationnel des utilisateurs est automatiquement sélectionné lors du processus de connexion pour les personnes autorisées à utiliser le service Acrobat Sign (identifiant la demande comme provenant d’une source Acrobat Sign).
- Les utilisateurs qui rencontrent des erreurs lors de la connexion reçoivent des messages d’erreur contenant des liens pour contacter les administrateurs Acrobat Sign et obtenir de l’aide.
- Toutes les personnes disposant d’un droit actif, mais ne s’étant pas connectées au service recevront jusqu’à deux rappels par e-mail. (Ceci s’applique également aux utilisateurs inactifs existants avant la date de la publication.)
Ces améliorations simplifient la connexion, réduisent les frictions et améliorent l’expérience utilisateur globale.
Environnements disponibles : Commercial | Niveaux de service disponibles : Acrobat Sign Solutions | Portée de la configuration : activée par défaut ; non configurable
|
Première notification : mars 2025 - Mise à jour : avril 2025 |
Supprimé de la liste actuelle : juin 2025 |
|---|
À partir de la version de mai 2025, Acrobat Sign appliquera des limites plus strictes sur le nombre de webhooks créés dans les comptes de niveau développeur.
Ces limites ont été choisies de manière intentionnelle pour garantir la fiabilité de l’infrastructure des webhooks et mieux s’aligner sur les workflows de test.
|
Ce qui change |
Limite précédente |
Nouvelle limite |
Description |
|---|---|---|---|
|
Nombre de webhooks actifs créés par canal |
10 |
1 |
1 webhook est autorisé pour le canal par événement d’abonnement de webhook. |
|
Nombre de webhooks actifs créés pour un compte |
100 |
2 |
2 webhooks au niveau du compte sont autorisés par événement d’abonnement de webhook. |
|
Nombre de webhooks actifs créés par groupe |
100 |
2 |
2 webhooks au niveau du groupe sont autorisés par groupe par événement d’abonnement de webhook. |
|
Nombre de webhooks actifs créés par ressource d’accord |
50 |
1 |
1 webhook est autorisé par accord et par événement d’abonnement de webhook. |
|
Nombre de webhooks actifs créés par utilisateur |
100 |
1 |
1 webhook est autorisé par utilisateur par événement d’abonnement de webhook. |
Environnements disponibles : Commercial | Niveaux de service disponibles : Développeur | Portée de la configuration : activée par défaut ; non configurable
|
Première notification : mars 2025 |
Supprimé de la liste actuelle : avril 2025 |
|---|
Les clients Acrobat Sign peuvent maintenant s'abonner au service Webhook Acrobat Sign pour recevoir des notifications proactives concernant les pannes, les interruptions et les événements de maintenance via le Adobe Status Portal.
Gérez et ajoutez des abonnements ici : Aide pour l'abonnement Adobe Status.
Notez que le service Adobe Acrobat Sign est répertorié sous l’en-tête Document Cloud :
|
Premier signalement : mars 2025 |
Supprimé de la liste actuelle : juin 2025 |
|---|
Dans la version de mai 2025, nous optimisons l’API GET /agreements pour réduire considérablement les temps de réponse : nos tests internes indiquent des performances jusqu’à 10 fois supérieures.
Nouveautés
- Pages plus petites : pour prendre en charge ces améliorations, nous avons réduit le nombre maximal d’accords renvoyés par demande à 500, mais cette limite peut changer dans les versions futures. Chaque réponse inclut les éléments suivants :
- Nombre réel d’accords renvoyés
- Lien vers la page suivante des résultats (si disponible)
- Nombre de résultats dynamiques : vous pouvez toujours demander un nombre spécifique d’accords, mais l’API en renvoie autant que le service peut en fournir. Chaque réponse inclut les éléments suivants :
À quoi s’attendre
Dans certains cas, il peut y avoir un léger délai entre la création d’un accord et sa récupération à l’aide de l’API GET /agreements. Ce délai est généralement très court ; une demande de suivi doit renvoyer le nouvel accord.
Environnements disponibles : Commercial, Gouvernement | Niveaux de service disponibles : Services Acrobat Sign, Gouvernement | Portée de la configuration : activée par défaut ; non configurable
|
Premier signalement : avril 2025 |
Supprimé de la liste actuelle : août 2025 |
|---|
Tous les comptes utilisant le service Acrobat Sign for Government pourront activer le nouvel environnement Request Signature, ainsi que plusieurs fonctionnalités récemment créées qui en dépendent :
- Témoin électronique
- Accès restreint aux accords
- Imposer un type de signature
- Contrôle d’identité
- Nombre de copies par destinataire
- La liste des destinataires et les propriétés des destinataires sont modifiables après la création.
|
Première notification : septembre 2024 |
Supprimé de la liste actuelle : février 2026 |
|---|
Action requise
Tous les clients utilisant l'API doivent mettre à jour leurs API pour utiliser les points d'entrée version 6 dès que possible afin de garantir une disponibilité ininterrompue.
Les versions 1 à 4 de l’API REST Acrobat Sign ont été mises hors service et seront supprimées le 1er décembre 2025.
La mise à jour des API peut nécessiter beaucoup d’efforts. Nous encourageons donc tous les clients à évaluer et à budgétiser leur mise à jour dès que possible afin de pouvoir pleinement bénéficier de l’assistance pour répondre à toutes les questions ou résoudre tous les problèmes qui surgissent avant la date limite de décembre 2025.
Bien que les versions 1 à 4 de l’API REST ne soient plus utilisées, elles continueront de fonctionner, tout comme vos applications, jusqu’au 1er décembre 2025, date à laquelle les versions 1 à 4 de l’API REST seront supprimées.
Après le 1er décembre 2025, les applications créées avec les versions 1 à 4 de l’API REST cesseront de fonctionner.
|
Première notification : avril 2025 |
Supprimé de la liste actuelle : février 2026 |
|---|
Tous les comptes utilisant le service Acrobat Sign for Government pourront activer le nouvel environnement Request Signature, ainsi que plusieurs fonctionnalités récemment créées qui en dépendent :
- Témoin électronique
- Accès restreint aux accords
- Imposer un type de signature
- Contrôle d’identité
- Nombre de copies par destinataire
- La liste des destinataires et les propriétés des destinataires sont modifiables après la création.
|
Première notification : septembre 2024 - Mise à jour : avril 2025 |
Supprimé de la liste actuelle : février 2026 |
|---|
L’infrastructure Webhook 2.0 a été déployée pour tous les clients. Ce processus étant terminé, les notifications de signataires sont désormais obsolètes. Par conséquent, le paramètre webhookNotificationApplicableUsers de la payload du webhook ne fournit plus d’informations utiles et sera supprimé de toutes les payloads du webhook.
L’environnement Sandbox sera mis à jour dans la version de juin.
Les environnements de production seront mis à jour dans la version de juin 2025.
L’ID utilisateur et l’adresse e-mail d’envoi peuvent être identifiés à l’aide des paramètres initiatingUserId et initiatingUserEmail dans la payload de notification.
|
Première notification : août 2025 - Mise à jour : octobre 2025 |
Supprimé de la liste actuelle : février 2026 |
|---|
Pour maintenir la stabilité du système et améliorer les performances, Acrobat Sign introduira un seuil d’interrogation dans la version du 4 novembre 2025 (version 16.2.1). Cette modification limite la fréquence à laquelle les applications clientes peuvent interroger certains points de terminaison d’API.
- Les clients disposent de deux mois après la version 16.2.1 pour implémenter les changements d’interrogation recommandés dans leur code. Pendant cette période, le système CONSIGNERA uniquement les événements de seuil d’intervalle d’interrogation.
- Après décembre 2025, les politiques de protection des interrogations passeront en APPLICATION et les erreurs seront déclenchées pour les utilisateurs.
Une haute fréquence d’interrogation crée une charge inutile sur les systèmes backend, entraînant une dégradation des performances et des temps de réponse plus lents. Les développeurs API sont encouragés à basculer vers les webhooks pour les mises à jour en temps réel.
Nouveautés
Cette politique d’interrogation s’applique à tous les points d’entrée d’API GET.
Exemples de points d’entrée affectés
Récupération de statut :
- GET /agreements/{agreementId) : récupère le statut actuel d’un accord.
- GET /agreements/{agreementId)/documents/{documentId) : récupère le flux de fichier d’un document au sein d’un accord.
Liste :
- GET /agreements : récupère les accords pour l’utilisateur.
- GET /agreements/{agreementId)/events : récupère les informations relatives aux événements d’un accord.
Une limite sera appliquée à la fréquence à laquelle l’utilisateur effectif peut faire le même appel API auprès du service Acrobat Sign. Une erreur est renvoyée si le même appel est fait dans l’intervalle d’interrogation minimum par le même utilisateur effectif.
Détails de la stratégie d’interrogation
- Intervalle minimum d’interrogation d’objet (Minimum Object Polling Interval MOPI) : le MOPI par défaut varie selon le niveau de service et les types d’application :
- Applications partenaires Acrobat Sign : le MOPI d’une application partenaire est déterminé par le niveau du compte de l’utilisateur.
- Niveau GLOBAL/ENTREPRISE : 3 appels par intervalle d’une minute
- Tous les autres niveaux : 1 appel unique par intervalle de dix minutes
- Applications client sous les comptes Global/Entreprise : trois appels identiques par intervalle d’une minute.
- Applications client sous des comptes développeur : un seul appel par intervalle de 10 minutes.
- Applications partenaires Acrobat Sign : le MOPI d’une application partenaire est déterminé par le niveau du compte de l’utilisateur.
- Requêtes en double dans les MOPI : si le même utilisateur effectif fait des requêtes GET identiques (même chemin et en-têtes) plus que ne le permet son niveau dans le MOPI, le système renverra :
- Le code d’état 304 Not Modified aux requêtes HTTP conditionnelles utilisant une balise ETag.
- Le code d’état 429 Too Many Requests avec une nouvelle tentative ultérieure pour les autres requêtes.
- Gestion des balises ETag : cette politique s’applique lorsque les valeurs ETag sont fournies dans l’en-tête If-None-Match pour les points d’entrée qui prennent déjà en charge 304 Not Modified.
Action requise
Webhooks : Si votre Application nécessite des mises à jour en temps quasi réel, utilisez les webhooks plutôt que les enquêtes. Les webhooks offrent un moyen plus efficace et évolutif de recevoir des mises à jour en temps opportun.
Si les webhooks ne peuvent pas être utilisés, les applications doivent mettre en œuvre des mécanismes de cache côté client pour stocker et réutiliser les réponses API. Lorsqu’une réponse 304 Non modifié est reçue, les données en cache doivent être utilisées au lieu d’effectuer un nouvel appel API.
Les clients disposent de deux mois après la version 16.2.1 pour implémenter les changements d’interrogation recommandés dans leur code. Pendant cette période, le système CONSIGNERA les événements de seuil d’intervalle d’interrogation.
Après décembre 2025, les politiques de protection des interrogations passeront en APPLICATION et les erreurs seront déclenchées pour les utilisateurs.
Veuillez contacter votre CSM si vous avez besoin d’aide ou si vous avez des questions.
L’environnement Sandbox activera la politique d’interrogation pour CONDIGNER les erreurs le 17 septembre 2025 et la configurera sur ENFORCE le 25 septembre 2025.
|
Première notification : août 2025 |
Supprimé de la liste Actuel : fév. 2026 |
|---|
Pour répondre aux exigences FedRAMP CSP, nous activons le protocole IPv6 sur notre environnement Acrobat Sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Première notification : septembre 2025 |
Supprimé de la liste actuelle : février 2026 |
|---|
La validation des paramètres de langue a été renforcée lors de la création d’un accord via l’API. Si les paramètres régionaux d’un accord ne sont pas autorisés par les politiques du compte, l’API rejette la demande avec une erreur claire. Cela réduit les incompatibilités linguistiques involontaires et maintient l’expérience des destinataires en accord avec les paramètres approuvés.
Qui est concerné
- Comptes qui définissent les paramètres régionaux de l’accord dans les demandes d’API.
- Comptes qui restreignent les paramètres régionaux disponibles ou interdisent les modifications de paramètres régionaux pendant l’envoi.
Modifications apportées
Lorsque le paramètre DISPLAY_LOCALE_INFO_DURING_SEND est activé (niveau GLOBAL), l’API applique les règles suivantes :
- Les paramètres régionaux de l’accord doivent être inclus dans le paramètre AVAILABLE_LOCALES de l’utilisateur.
- Si ALLOW_LOCALE_SELECTION_DURING_SEND est faux, les paramètres régionaux de l’accord doivent correspondre au paramètre AGREEMENT_LOCALE de l’utilisateur.
Les violations entraînent l’échec de POST /agreements avec l’erreur : « Les paramètres régionaux sont soit non valides, soit manquants. »
Erreur courante et comment la corriger
Erreur : « Les paramètres régionaux sont soit non valides, soit manquants. »
- Vérifiez les paramètres régionaux utilisés dans la demande API (par exemple, en_US).
- Confirmez que les paramètres régionaux apparaissent dans le paramètre AVAILABLE_LOCALES pour l’utilisateur qui effectue l’appel.
- Si ALLOW_LOCALE_SELECTION_DURING_SEND est faux, assurez-vous que les paramètres régionaux de la demande correspondent à AGREEMENT_LOCALE.
- Si une certaine flexibilité entre les régions est nécessaire, activez la sélection des paramètres régionaux au moment de l’envoi (voir Action requise).
Rétrocompatibilité
- Avant ce changement, certaines demandes avec des paramètres régionaux non correspondants pouvaient réussir. Ces demandes échouent maintenant avec une erreur claire lorsque les validations ne passent pas.
- Aucun changement de schéma API ; le comportement de validation change uniquement lorsque DISPLAY_LOCALE_INFO_DURING_SEND est activé.
Action requise
Les administrateurs et les intégrateurs d’API doivent effectuer l’une des actions suivantes :
- Aligner les paramètres régionaux dans les demandes d’API avec les paramètres AVAILABLE_LOCALES, et, si ALLOW_LOCALE_SELECTION_DURING_SEND est faux, correspondre exactement à AGREEMENT_LOCALE
- ou -
- Autoriser la sélection des paramètres régionaux au moment de l’envoi en définissant :
- ALLOW_LOCALE_SELECTION_DURING_SEND = vrai
- CAN_CHANGE_UI_LOCALE = vrai
|
Première notification : décembre 2025 |
Supprimé de la liste actuelle : fév. 2026 |
|---|
Adobe Acrobat Sign changera de certificat SSL le 7 janvier 2026.
Action requise
- Si vous disposez d’intégrations personnalisées Acrobat Sign utilisant les API REST et si l’une de ces intégrations comprend la clé publique existante, aucune autre action n’est requise.
- Si vous utilisez les Certificats SSL d'Acrobat Sign pour l'authentification unique, ou si vous épinglez le certificat lui-même (ou utilisez d'autres méthodes), vous pouvez trouver les nouveaux Certificats SSL d'Acrobat Sign dans la Configuration requise du système Adobe Acrobat Sign.
- Si votre configuration SSO prend en charge plusieurs certificats/chaînes publics, vous pouvez ajouter les nouveaux certificats maintenant et supprimer l’ancien certificat public/l’ancienne chaîne publique de votre configuration après le changement de janvier.
- Si votre authentification unique ne prend pas en charge plusieurs chaînes/certificats publics, vous devrez synchroniser votre changement de SSL avec Acrobat Sign le 7 janvier 2026.
Les nouveaux certificats SSL seront actifs à compter du 7 janvier 2026.
|
Première notification : mars 2026 |
En vigueur Supprimé de la liste actuelle : juin 2026 |
|---|
Une activité de maintenance de base de données planifiée est programmée pour le 11 avril 2026 à 19 h 30, heure du Pacifique. La fenêtre de maintenance devrait durer jusqu’à 30 minutes.
Cette maintenance affectera tous les environnements Acrobat Sign et s’applique uniquement aux comptes gérés par Adobe (IMS). Les comptes qui gèrent leurs utilisateurs directement dans Acrobat Sign ne sont pas affectés.
Pendant cette période :
- La création de nouveaux comptes et l’approvisionnement d’utilisateurs seront retardés.
- Un nombre limité d’utilisateurs peut rencontrer des problèmes de connexion.
- Les demandes de consommation de transactions de compte depuis les interfaces administratives Adobe peuvent échouer, ce qui peut temporairement empêcher l’attribution de droits.
Tous les services affectés devraient reprendre un fonctionnement normal une fois la maintenance terminée.
|
Première notification : mars 2026 |
Supprimé de la liste actuelle : juin 2026 |
|---|
Les ID de document renvoyés par l’API utilisent désormais un format d’encodage de 16 bits au lieu du format de 12 bits précédent, et peuvent inclure des astérisques de fin dans la valeur renvoyée. Acrobat Sign accepte les ID de document avec ou sans ces caractères de fin, mais certaines applications peuvent ne pas gérer correctement le format étendu, ce qui peut affecter la récupération ou l’affichage du document.
Cette mise à jour reflète une modification de la gestion des ID de document dans le service. Si votre intégration récupère des documents en utilisant les ID de document renvoyés par l’API, vérifiez votre logique actuelle pour vous assurer qu’elle prend en charge le format d’ID plus long et qu’elle peut accepter la valeur renvoyée telle qu’elle est fournie. Si nécessaire, les caractères astérisque de fin peuvent être omis avant de relancer la demande.
L’accès direct via Acrobat Sign ne devrait pas être impacté.
|
Première notification : février 2026 - Mise à jour : avril 2026 |
Supprimé de la liste actuelle : juin 2026 |
|---|
La page d’accueil d’Acrobat Sign est en cours de refonte pour faciliter le démarrage d’accords, surveiller l’activité et accéder à des fonctionnalités clés, notamment la possibilité de copier des accords récemment envoyés, d’afficher les vignettes d’action dans un ordre plus intuitif, d’identifier rapidement les éléments En cours et À traiter, et de bénéficier d’une bannière Nouveautés simplifiée qui réduit l’encombrement visuel. Tous ces éléments aident les utilisateurs à aller plus vite, à réduire le nombre d’accords ignorés et à profiter d’une expérience plus ciblée sur la page d’accueil.
La nouvelle page d’accueil sera déployée dans les 10 jours suivant la version :
Date |
Fragments |
5 mai 2026 |
IN1, JP1, AU1, SG1 |
11 mai 2026 |
EU1, EU2, NA4 |
14 mai 2026 |
NA1, NA2, NA3 |
Annotation
Le calendrier de déploiement est fourni à titre indicatif et peut être ajusté au fur et à mesure du déploiement.
|
Première notification : mars 2026 |
Supprimé de la liste actuelle : juin 2026 |
|---|
À partir de la version 17.0.1 du 17 mars, l’onglet Jetons d’accès du menu Préférences personnelles affiche la date d’expiration de chaque clé d’intégration. Cette mise à jour améliore la visibilité de la gestion du cycle de vie des clés en permettant aux détenteurs de clés de voir quand une clé expirera.
Les clés d’intégration ont une période de validité de 10 ans. Après la date d’expiration, la clé ne peut plus être utilisée et doit être remplacée par une nouvelle clé.
Cette modification n’affecte pas le fonctionnement des clés existantes et ne modifie pas le cycle de vie des clés. Elle expose uniquement la date d’expiration dans l’interface afin que les administrateurs puissent surveiller l’ancienneté des clés et planifier les remplacements à l’avance.
Aucune action n’est requise. Les administrateurs doivent périodiquement réviser leurs clés d’intégration et remplacer celles qui approchent de l’expiration pour éviter les interruptions de service.
|
Première notification : mars 2026 |
Supprimé de la liste Actuel : juin 2026 |
|---|
À partir de la version du 5 mai 2026, les rapports d’audit enregistreront la méthode de signature utilisée lorsqu’un signataire appliquera sa signature.
Pour chaque événement ESIGNED et DIGSIGNED, le journal d’audit identifie si le signataire a utilisé une méthode de signature basée sur poste de travail (SAISIE, DESSIN, IMAGE) ou une méthode de signature basée sur mobile (SAISIE_MOBILE, DESSIN_MOBILE, IMAGE_MOBILE).
Cette mise à jour améliore la visibilité de la conformité en permettant aux administrateurs et aux équipes de conformité de vérifier la méthode de signature directement dans le rapport d’audit, réduisant l’ambiguïté et minimisant les rejets d’accords inutiles pendant les processus de révision et d’audit. Cette mise à jour est activée par défaut pour tous les clients, sans option de configuration.
Annotation
L’application d’une signature uniquement avec un tampon n’est pas incluse dans les types de signatures identifiés.
|
Première notification : décembre 2025 - Mise à jour : février 2026 |
Supprimé de la liste Actuel : juin 2026 |
|---|
L’expérience sur la page de connexion Acrobat Sign sera mise à jour pour tous les utilisateurs dans le cadre de la version 17.0, prévue pour le 3 février 2026. La nouvelle procédure de connexion offre une expérience plus claire et plus cohérente en demandant à tous les utilisateurs de fournir leur adresse e-mail, et rien d’autre. Dès que l’adresse e-mail est acceptée, le compte de l’utilisateur est référencé, et la page de suivi affiche les options d’authentification configurées pour le compte. Cela permet de supprimer des étapes inutiles et des écrans hérités. La connexion devient plus rapide, plus simple et plus intuitive pour tout le monde.
- Dans le cadre de la nouvelle expérience de connexion, le format d’e-mail pour les utilisateurs Acrobat Sign Grands comptes qui se connectent directement à l’interface web applique désormais une limite de 64 caractères à la partie locale des adresses e-mail (la portion avant le symbole « @ »).
Cette nouvelle expérience de connexion est déployée par phases par l’environnement serveur Acrobat Sign. Le calendrier de déploiement est présenté ci-dessous :
|
Environnement Acrobat Sign |
Date de déploiement |
|
IN1 (Inde) SG1 (Singapore) |
3 février 2026 |
|
AU1 (Australie) NA3 (Amérique du Nord) |
10 février 2026 |
|
JP1 (Japon) |
17 février 2026 |
|
EU2 (Europe) NA4 (Amérique du Nord) |
2 mars 2026 |
|
EU1 (Europe) NA2 (Amérique du Nord) |
05 mars 2026 |
|
NA1 (Amérique du Nord) |
10 mars 2026 |
Annotation
Le calendrier de déploiement est fourni à titre indicatif et peut être ajusté au fur et à mesure du déploiement.
|
Première notification : février 2026 |
Supprimé de la liste actuelle : juin 2026 |
|---|
