1. Notes de distribution 5.5.0
1.1 Nouvelles fonctionnalités
Ajout d'approbateurs
eSignatures 5.5 offre la possibilité d'ajouter un ou plusieurs approbateurs au flux de signature. De cette façon, les documents sont d'abord envoyés à un approbateur, et ne sont transmis aux signataires requis qu'après l'approbation du document.
Il est également possible d'attribuer un rôle d'approbateur à un groupe de contacts. Le premier membre du groupe de contacts à ouvrir le document pourra l'approuver pour l'ensemble du groupe de contacts.
Réattribution d'un document à un autre signataire ou approbateur
Si un approbateur ou un signataire estime que ce n'est pas à lui de traiter un document, il peut le réattribuer à un autre approbateur ou signataire.
Notez que l'administrateur doit activer cette fonction dans l'Index de configuration avant que les approbateurs ou les signataires ne puissent réattribuer un document.
itsme® comme signature électronique avancée
itsme® était déjà disponible en tant que signature électronique qualifiée (QES). Les signatures QES constituent le type le plus avancé et sécurisé des signatures électroniques mais aussi le plus cher.
Depuis eSignatures 5.5, les clients qui n'ont pas nécessairement besoin de signatures QES peuvent utiliser itsme® comme signature électronique avancée via OpenID Connect.
Notez que vous devez vous adresser à itsme® pour demander le service de connexion itsme® et démarrer la configuration.
Possibilité de désactiver les URL à usage unique
Dans eSignatures 5.5, les administrateurs peuvent décider de désactiver l'utilisation des URL à usage unique. En désactivant les URL à usage unique, les URL de signature et d'approbation n'expirent pas après un seul clic d'un utilisateur.
Notez toutefois qu'il est vivement conseillé de continuer à utiliser les URL à usage unique. Il s'agit d'une mesure de sécurité qui permet de renforcer la sécurité d'eSignatures lors de son utilisation.
Notez aussi qu'à chaque utilisation d'une URL non sécurisée pour la signature d'un document, une mention sera ajoutée aux preuves d'audit (pour autant que le paramètre Audit Proof soit activé).
Langues d'interface configurables
Les administrateurs peuvent désormais configurer les langues possibles de l'interface eSignatures dans l'Index de configuration.
Six nouvelles langues d'interface
L'interface eSignatures est désormais disponible dans six nouvelles langues :
- Norvégien (sami et bokmal)
- Finnois
- Suédois
- Danois
- Polonais
- Letton
Ces langues ne sont pas activées par défaut, mais les administrateurs peuvent les activer comme mentionné ci-dessus.
1.2 Améliorations
Tri logique des approbateurs, des signataires et des destinataires
Les approbateurs, signataires et destinataires sont désormais affichés selon un ordre logique dans la section Détails du document du Portail Web.
- Les destinataires sont toujours classés par ordre alphabétique, d'abord par nom de famille, puis par prénom.
- Les approbateurs / signataires sont classés selon un flux d'approbation / signature défini par l'initiateur, soit dans le Portail Web, soit dans l'API :
- Parallèle : les approbateurs/signataires sont toujours classés par ordre alphabétique (nom de famille puis prénom).
- Séquentiel : les approbateurs/signataires sont classés selon l'ordre défini.
- Complexe : les approbateurs/signataires sont d'abord classés selon l'ordre défini. Si plusieurs approbateurs/signataires peuvent approuver/signer au cours de la même étape du flux, ils sont classés par ordre alphabétique (nom de famille puis prénom).
Les signataires sont également organisés selon la même logique dans la fenêtre de signature en personne.
1.3 Problèmes résolus
Code Jira | Code du problème | Description |
---|---|---|
CEP-6978 | 31867 | Le problème de suppression des notifications lors de la révocation d'un document dans l'API v2 a été résolu. |
CEP-6893 | / | Lorsque vous apportiez des modifications aux noms de fichier des documents téléchargés sur le Portail Web, puis que vous ajoutiez des documents supplémentaires, l'application rétablissait les noms d'origine des documents déjà téléchargés. |
CEP-6943 | 31830 | Le code DocumentGroupCode n'était pas récupéré par l'appel Get Package Status. |
CEP-6983 | / | Après la signature d'un document par le premier des signataires, le suivant ne voyait que les champs qu'il devait signer dans la page WYSIWYS et n'avait plus une vue d'ensemble de tous les champs de signature. |
CEP-7070 | / | Le problème lié à l'ajout de signataires lorsque le choix de signatures est désactivé a été résolu. |
CEP-6995 | / | Le problème de signature rapide avec iDIN a été résolu. |
CEP-6954 | 31897 | Le message d'erreur affiché lors de la saisie d'une valeur mandatedSignerValidation non valide a été amélioré. |
CEP-6931 | / | Le problème de vitesse lors de la création de contacts en double a été résolu. |
CEP-6884 | / | Une icône de groupe de personnes incorrecte était affichée dans le champ de signature. |
CEP-6840 | / | Le problème lié au rétablissement des valeurs par défaut dans les thèmes a été résolu. |
CEP-6815 | / | Lors de la définition d'une date d'expiration, les zones de saisie n'étaient pas alignées. |
CEP-6651 | / | La signature rapide (QuickSign) avec plusieurs champs de signature entraînait un blocage à la fin du package. |
CEP-4632 | / | Le problème de pagination a été résolu. |
CEP-6870 | / | L'agencement de la configuration du champ OpenID Connect a été amélioré. |
CEP-6736 | / | Le problème lié à Google Drive pendant le chargement a été résolu. |
CEP-6854 | / | La méthode de signature n'était pas visible dans la version brouillon du package en cas d'utilisation d'OpenID Connect. |
CEP-6859 | / | Les fichiers svg WYSIWYS des groupes de contacts / groupes de personnes étaient introuvables lors de l'utilisation du type de référentiel azurefilestorage. |
1.4 Problèmes connus
eSignatures 5.5.0
Code Jira | Code du problème | Description |
---|---|---|
CEP-7078 | / | Il est actuellement impossible de signer avec FranceConnect si vous utilisez eIDAS3. |
CEP-6352 | / | Problème de migration des traductions. |
CEP-6422 | / | Il faut ajouter un message d'erreur en cas de tentative de signature par code mail d'un document déjà supprimé. |
CEP-7170 | / | Les signataires devraient être affichés par ordre alphabétique dans la fenêtre de signature en personne. |
eSignatures 5.4.3
Code Jira | Code du problème | Description |
---|---|---|
CEP-6897 | / | Lors de l'utilisation des preuves d'audit, un problème lié au Worker survenait lorsque les packages étaient définis sur la valeur « terminé ». |
eSignatures 5.4.2
Code Jira | Code du problème | Description |
---|---|---|
CEP-6874 | / | Casse incohérente du paramètre de requête « SessionId » en cas de jeton non valide. |
CEP-6288 | / | Problème de personnalisation (branding) : l'enregistrement d'une modification dans l'un des sous-onglets redirige vers un onglet de niveau supérieur. |
CEP-6865 | / | Lors d'une mise à niveau à partir d'une version 5.0.7, la page Environment Settings (Paramètres d'environnement) vous invite à sauvegarder sans que vous ayez apporté de modification. |
Signatures 5.3.0
Code Jira | Code du problème | Description |
---|---|---|
CEP-5944 | / | Le défilement itsme n'est pas aussi fluide que prévu dans Safari sur un iPhone. |
eSignatures 5.2.4
Code Jira | Code du problème | Description |
---|---|---|
CEP-5564 | / | Lorsqu'un package contient à la fois une méthode de signature synchrone et asynchrone, et que la signature asynchrone échoue, il est impossible de restaurer la session de signature. |
eSignatures 5.2.0
Code Jira | Code du problème | Description |
---|---|---|
CEP-4817 | / | Bogues d'affichage lors de l'utilisation de la signature complexe sur Safari et Chrome |
eSignatures 5.1.1
Code Jira | Code du problème | Description |
---|---|---|
CEP-4719 | / | Le délai d'expiration de la session est actuellement absolu. Les utilisateurs sont déconnectés même s'ils sont restés actifs. |
Problèmes connus plus anciens
Code Jira | Code du problème | Description |
---|---|---|
/ | / | L'installation allemande de Chrome peut générer des erreurs pendant la signature. |
1.5 Limitations connues
Général
- Un package ne peut pas excéder 150 Mo.
- Un seul document à l'intérieur d'un package ne peut pas excéder 30 Mo.
- Un package peut contenir un maximum de 15 documents.
- Un fichier .xml ne peut pas contenir plus de 2 millions de caractères par fichier. Un package ne peut pas contenir plus de 15 fichiers .xml.
- Les fichiers volumineux peuvent affecter les performances de signature selon la connexion Internet de l'utilisateur.
- Les documents qui font plus de 3,99 m sur 3,99 m ne sont pas pris en charge.
- Les porte-documents PDF ne sont pas pris en charge. C'est dû au fait qu'un porte-documents PDF peut contenir un large éventail de types de fichier non pris en charge par eSignatures. Un porte-documents PDF peut, par exemple, contenir des emails, des feuilles de calcul, des dessins CAO, des présentations PowerPoint, etc. Par conséquent, un signataire pourra uniquement voir et signer la page de garde du PDF, et non les fichiers contenus dans le porte-documents, ce qui invalide tout le porte-documents PDF.
- Le chargement des documents PDF/A est uniquement autorisé si le format est PDF/A_2A ou PDF/A_1A.
- Lorsque vous chargez des documents PDF contenant déjà des champs de signature (créés dans une solution PDF telle qu'Adobe Acrobat Pro DC), assurez-vous que les noms des champs de signature contiennent uniquement des lettres et des nombres ou une combinaison des deux. Tous les caractères spéciaux, notamment les lettres accentuées, les points, les barres, etc. ne sont pas pris en charge et ne peuvent pas être utilisés. Les mêmes restrictions s'appliquent au chargement de documents PDF contenant des champs texte.
- L'ajout de plusieurs initiateurs dans un même package n'est pas pris en charge.
- L'application ne prend pas toujours en charge la combinaison des méthodes de signature eID et BeLawyer comme choix de signature : lorsque le paramètre MandatedSigningType a la valeur nameandbirthdate dans l'Index de configuration, ces deux méthodes ne peuvent pas être combinées.
- À l'heure actuelle, les packages ne peuvent pas contenir à la fois des documents XML et PDF sur lesquels des signatures seront apposées. Le type de package est déterminé par le premier document chargé.
- Les groupes par défaut « administrateurs » et « groupe d'utilisateurs par défaut » ne peuvent pas être utilisés comme signataires dans les templates (modèles).
- L'insertion d'une tabulation devant un marqueur texte dans Word n'est pas prise en charge. Aux tabulations préférez les tableaux, colonnes ou zones de texte. Si vous voulez néanmoins utiliser des tabulations, convertissez votre document Word au format PDF avant de le charger.
- Si vous utilisez Safari : après la mise à niveau d'une version antérieure, vous serez invité à fermer votre navigateur. Lorsque vous le rouvrez et que vos onglets précédents ne s'ouvrent pas automatiquement, ne réutilisez pas votre lien d'origine vers la page de signature. Sélectionnez plutôt History > Reopen All Windows From Last Session (Historique > Rouvrir toutes les fenêtres de la session précédente).
- Les applications de conception natives pour le DTP, CAO, etc. peuvent générer des documents très complexes (nombre important d'éléments, vecteurs, images, etc.) Il est dès lors possible que l'application ne puisse pas préparer le document dans un délai raisonnable. Il sera donc impossible d'ajouter ces fichiers à l'environnement de signature (via l'API ou le Portail de documents) en raison de l'expiration du délai imparti. Il n'est pas possible de savoir à l'avance si un document complexe va entraîner ou non une expiration dans la mesure où cela dépend d'un nombre trop important de facteurs. Les applications générant ces types de PDF disposent généralement d'une option pour créer un PDF adapté à une utilisation en ligne. Nous recommandons vivement d'utiliser cette option pour limiter la complexité du document avant son chargement.
Signature itsme
(Notez que ces limitations ne s'appliquent pas à l'utilisation d'itsme via OpenID Connect)
- Lorsque vous utilisez itsme comme méthode de signature, le type cible de vos documents doit être le format PDF/A-1 ou PDF/A-2. C'est à l'administrateur de vérifier que ces formats de sortie sont disponibles dans la solution eSignatures de l'utilisateur et c'est à l'utilisateur de sélectionner le format de sortie correct. Connective ne vérifie pas si le format de sortie correct a été sélectionné pour itsme.
- Lors de l'utilisation de la signature itsme dans des packages, chaque document du package doit être signé individuellement. En d'autres termes, la méthode de signature rapide (QuickSign) n'est pas prise en charge.
- À l'heure actuelle, la signature itsme n'est pas prise en charge par un système macOS Mojave v10.14 exécutant Safari v12.0.
Preuves d'audit
- La fonction Audit Proof (Preuve d'audit) a une incidence importante sur la base de données eSignatures. Plus les documents sont volumineux, plus ils utiliseront d'espace. Cet impact est proportionnel à la taille des documents.
- La fonction Audit Proof (Preuve d'audit) a aussi un impact sur la vitesse de signature d'eSignatures. Plus les documents sont volumineux, plus il faudra de temps pour la signature. Les petits documents (< 1 Mo) se semblent pas avoir d'impact sur la vitesse de signature.
2. Informations de mise à niveau
Pour les clients signant avec des jetons physiques (eID, biométrique avec tablette de signature Wacom, etc.), le package Connective Browser Package doit être mis à niveau vers la version 2.0.6. La mise à niveau sera demandée automatiquement lorsque vous tenterez de signer un document.
Si vous disposez d'une version eSignatures antérieure à la version 5.5.0, consultez la documentation Connective - eSignatures 5.5.0 - Installation pour savoir comment effectuer une mise à niveau vers la version 5.5.