Aller au contenu principal
Quelle Signature

Migrations

Documents en cours de signature quand vous changez d’outil : laissez-les finir sur l’ancien et fixez une date de dernier envoi

Pour qui : Responsable des opérations qui change d’outil de signature alors que des documents attendent encore des signatures sur l’ancien.

Laissez finir sur l’ancien outil tout document déjà envoyé, et ne renvoyez rien aux signataires tant que cet outil reste accessible. Fixez une date de dernier envoi : dernier envoi = date d’effet (le jour où le contrat prend fin) − durée de validité (le temps laissé pour signer) − temps d’export. La validité est un paramètre à lire chez votre éditeur : 14 jours par défaut chez Universign, jusqu’à 365 jours chez Signaturit, défaut non trouvé chez Youtrust. Relancez sur l’ancien outil ce qui traîne. Si l’accès s’arrête avant la fin, annulez la demande et refaites signer tous les signataires dans le nouvel outil. Aucun changement d’outil réel n’a été observé.

Notre avis

Une relance sur l’ancien outil ne pose aucun problème. C’est le renvoi du même acte dans le nouvel outil qui en crée.

Pourquoi

  • Un signataire qui reçoit deux demandes peut signer les deux, ou celle qu’on ne suivait plus. Vous devrez alors expliquer laquelle compte.
  • Les signatures successives et le dossier de preuve se constituent dans l’outil de départ : sur les pages que nous avons lues, aucune fonction ne reprend une demande à moitié signée dans un autre outil.
  • La date de dernier envoi se calcule : aucune raison de l’improviser le dernier jour.

Ce qui change le choix

Si l’accès s’arrête avant la fin des demandes, l’ordre s’inverse : relancez fort, annulez ce qui ne pourra pas finir et refaites signer tous les signataires dans le nouvel outil, en leur expliquant pourquoi.

L’ordre à suivre

  1. Fixer la date de dernier envoi à partir de la date d’effet
  2. Relancer sur l’ancien outil les documents qui traînent
  3. Annuler puis refaire signer seulement si l’accès va s’arrêter avant la fin

Dernier envoi au 17 mars, moins votre temps d’export, pour une date d’effet au 31 mars et une validité de 14 jours

Exemple fictif : contrat Universign avec date d’effet au 31 mars 2027, validité laissée à 14 jours, export final le dernier jour au plus tard. 31 mars − 14 jours = 17 mars 2027. Avancez cette date du temps que vous estimez nécessaire pour exporter et contrôler : nous ne le chiffrons pas, faute d’export observé. Si certains de vos flux, c’est-à-dire de vos circuits de signature, ont une validité plus longue, c’est la plus longue qui commande, ou raccourcissez-la pour les derniers envois.

La documentation technique d’Universign fait partir le décompte de l’état started, c’est-à-dire du démarrage de la demande, et précise qu’une pause ne suspend pas l’expiration. Elle indique un maximum de 60 ou 180 jours selon l’activation des transactions longues. Une phrase de sa section sur la pause limite à 45 jours la durée après le démarrage, sans dire comment cela s’accorde avec ce maximum : faites-la confirmer par Universign si vous comptez sur une durée longue.

Lectures du 4 novembre 2026, déclarations d’éditeurs non testées. Sélection, sans valeur de classement. POST et PATCH désignent des appels d’API, l’accès technique de vos logiciels à l’outil. « Non lue » : nous n’avons pas lu ce point, demandez-le à l’éditeur.
ÉditeurValidité lueRelanceAnnulation
Universign14 jours par défaut ; maximum de 60 ou 180 jours, sous réserve d’une phrase sur 45 joursNon trouvée dans la partie luePossible à l’état brouillon (draft), démarré (started) ou en pause (paused)
Signaturitexpire_time en jours, 365 au plus ; défaut non trouvéAutomatique par destinataire, ou par POST .../reminder.jsonPATCH .../cancel.json ; une demande en cours ne peut pas être supprimée
Youtrust, ex-YousignDate d’expiration réglable ; défaut et maximum non trouvésRelances réglables à la configurationNon lue
CertyneoDurée non trouvée ; champ expiresAt sans définition luePOST .../remind, selon la documentation de l’APIPOST .../void selon la documentation de l’API ; la fiche du connecteur mise à jour le 2 octobre 2026 écrit qu’aucune annulation n’existe dans l’API : faites confirmer
DocusignNon lue : consultez vos réglages de compteNon lueNon lue

Que faire de chaque document, selon son état

  1. Listez les demandes ouvertes à la date de dernier envoi. Par statut, date d’envoi, date d’expiration, signataires restants, responsable. C’est votre liste de suivi jusqu’à zéro.
  2. Aucune signature encore. Si la demande peut finir avant la date d’effet, laissez finir et relancez. Sinon, annulez, informez le signataire, puis renvoyez dans le nouvel outil. Annulez d’abord : c’est ce qui évite deux versions ouvertes.
  3. Au moins une signature déjà posée. Laissez finir sur l’ancien outil et concentrez vos relances ici, car une annulation oblige à faire signer de nouveau ceux qui ont déjà signé.
  4. L’accès s’arrête avant que la demande puisse finir. Annulez, expliquez au signataire pourquoi il reçoit une nouvelle demande, et conservez la trace de l’annulation avec l’ancien dossier. Demandez aussi à l’éditeur une prolongation par écrit.
  5. Terminé. Exportez le document et sa preuve, et mettez à jour votre fichier de contrôle, la liste qui compare les demandes terminées aux fichiers exportés (voyez notre page sur la récupération des preuves). Un document fini après votre dernier export n’en fait pas partie : refaites un export des derniers jours.

Limites de cette page

Aucun changement d’outil observé. Références d’Universign et de Signaturit lues en partie : le reste peut contenir d’autres règles. Divergence interne de la référence d’Universign entre 60 ou 180 jours et 45 jours, non résolue. Défauts de Youtrust et de Signaturit non trouvés. Docusign : expiration non lue. L’absence de reprise d’une demande à moitié signée est un constat de lecture : aucune documentation lue n’en décrit, sans que cela prouve l’impossibilité. Certyneo : contradiction non résolue entre sa documentation d’API et la fiche de son connecteur sur l’annulation. Exemple fictif, décompte non vérifié.

Prochaine action

Relevez la durée de validité de chacun de vos flux dans l’ancien outil, calculez votre date de dernier envoi (date d’effet − validité la plus longue − temps d’export), puis notez-la avec le nom de son responsable dans votre liste de suivi.

Preuves et sources

Références d’API d’Universign et de Signaturit (lues en partie), documentation de Youtrust et de Certyneo, conditions de Youtrust du 2 juillet 2026, lues le 4 novembre 2026. Aucun changement d’outil n’a été réalisé. Nous n’avons pas pu lire le contenu des pages de Docusign sur l’expiration.

Chaque élément ci-dessous indique s’il s’agit d’un fait lu dans une source, d’une déclaration de son auteur, de notre calcul, de notre méthode ou de notre avis. Vérifiez sur le document toute source marquée à vérifier ou non tranchée avant de vous y fier. Notre méthode

  • Déclaration de l’émetteur. La référence d’Universign indique une durée par défaut de 14 jours, un maximum de 60 ou 180 jours selon l’activation des transactions longues, un décompte à partir de l’état started, et qu’une pause ne suspend pas l’expiration.

    Périmètre : API /v1, partie lue

    Réserve : Une phrase de la section sur la pause limite à 45 jours la durée après le démarrage, sans conciliation avec ce maximum ; à faire confirmer.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. La référence d’Universign limite l’annulation aux états draft, started ou paused, et aucune fonction de relance n’a été trouvée dans la partie lue.

    Périmètre : API /v1, partie lue

    Réserve : Reste de la référence non relu sur ce point.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. La documentation de Signaturit fixe expire_time à 365 jours au plus, décrit des relances automatiques et manuelles, une annulation par PATCH et l’impossibilité de supprimer une demande en cours.

    Périmètre : API v3, partie lue

    Réserve : Défaut non trouvé.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. La documentation de Youtrust permet de fixer une date d’expiration et des relances à la configuration ; défaut et maximum n’ont pas été trouvés sur la page lue.

    Périmètre : Page Electronic Signature

    Réserve : Référence détaillée non lue.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. La documentation de l’API de Certyneo décrit une relance par POST .../remind et une annulation par POST .../void, alors que la fiche de son connecteur, mise à jour le 2 octobre 2026, écrit qu’aucune annulation n’existe dans l’API ; aucune durée de validité d’une enveloppe n’a été trouvée, et un champ expiresAt figure sans définition lue.

    Périmètre : Connecteur et documentation

    Réserve : Documentation non datée. Contradiction non résolue, non testé.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Les conditions de Youtrust retirent l’accès à la date d’effet de la résiliation ; un utilisateur peut demander le retour de ses dossiers de preuve, au tarif de la grille de prix de Youtrust, sans que le texte dise si cela reste possible après la fin.

    Périmètre : Conditions du 2 juillet 2026, art. 9.4 et 15.3

    Réserve : Lu en anglais.

    Relevé du 4 novembre 2026.

  • Notre calcul ou déduction. Exemple fictif : 31 mars 2027 − 14 jours = 17 mars 2027, avant déduction du temps d’export.

    Périmètre : Calcul

    Réserve : Décompte non vérifié.

    Relevé du 4 novembre 2026.

  • Notre calcul ou déduction. Aucune documentation lue ne décrit la reprise, dans un autre outil, d’une demande déjà partiellement signée.

    Périmètre : Pages lues

    Réserve : Absence non établie.

    Relevé du 4 novembre 2026.

  • Notre avis. Laisser finir sur l’ancien outil, relancer, et ne renvoyer que ce qui ne peut pas finir.

    Périmètre : Changement d’outil choisi

    Réserve : Avis assumé, sans changement d’outil observé.

    Relevé du 4 novembre 2026.

  • Notre méthode. La formule du dernier envoi et le traitement par état.

    Périmètre : À exécuter par le lecteur

    Réserve : Temps d’export à estimer par le lecteur.

    Daté du 4 novembre 2026.