Migrations
Combien de temps garder deux outils de signature : calculez la date du dernier envoi, puis fermez l’ancien quand quatre critères sont tenus
Pour qui : Responsable des opérations qui prépare une bascule et doit fixer quand ouvrir le nouvel outil, quand cesser d’envoyer dans l’ancien, et sur quels constats le fermer.
Gardez deux outils le temps de finir vos demandes en cours et d’exporter, sans durée forfaitaire. Calculez le gel des envois, c’est-à-dire le jour du dernier envoi dans l’ancien outil : date de gel = date d’effet (le jour où le contrat prend fin) − validité la plus longue (le temps laissé pour signer) − marge d’export et de contrôle. Pour une date d’effet fictive au mercredi 30 juin 2027, une validité de 14 jours et 9 jours de marge, le gel tombe le lundi 7 juin. Fermez ensuite l’ancien outil quand quatre critères sont tenus : aucune demande ouverte, autant de demandes terminées que de documents et de preuves exportés, aucune demande créée depuis le gel, une preuve relue par flux, c’est-à-dire par circuit de signature. Ce protocole est notre méthode, jamais exécutée ni testée par nos soins.
Notre avis
Ne fixez ni un mois ni un trimestre au jugé, et ne fermez pas parce que la date est arrivée. Calculez la date du dernier envoi, puis vérifiez quatre constats.
Pourquoi
- Au-delà de la durée de validité maximale d’une demande, garder les deux outils ne couvre aucune demande en cours : cela n’ajoute qu’un risque d’envoi dans le mauvais outil.
- Le compteur de demandes ouvertes ne suffit pas : une demande expirée, un connecteur qui peut encore créer des demandes ou un document exporté sans sa preuve passent à travers.
- Le coût de l’ancien outil se paie de toute façon jusqu’au terme sur un contrat annuel : l’enjeu est l’erreur d’envoi et la perte d’accès, plus que la facture.
Ce qui change le choix
Si une campagne annuelle tombe dans les semaines qui suivent le dernier envoi prévu, déplacez cette date ou gardez ce flux dans l’ancien outil jusqu’à son terme. Si la date de fin du contrat ne peut pas bouger et qu’un critère restera manquant, demandez par écrit une prolongation d’accès avant cette date.
L’ordre à suivre
- Ouvrir le nouvel outil sur un seul flux pilote
- Geler les envois de l’ancien outil à la date calculée, après avoir raccourci la validité si possible
- Fermer sur quatre critères : aucune demande ouverte, autant de demandes terminées que de documents et de preuves exportés, aucune demande créée depuis le gel, une preuve relue par flux
- Prolonger la cohabitation des deux outils seulement pour couvrir une campagne annuelle
Le calendrier : 37 jours d’ouverture du nouvel outil, dont 14 d’envois simultanés sur un seul flux
Cet exemple suppose un contrat qui s’arrête le mercredi 30 juin 2027, une validité réglée à 14 jours et une marge de 9 jours, que nous avons choisie pour l’illustration : mesurez la vôtre sur un export d’essai. Le préavis de résiliation se place avant ce calendrier : voyez notre page sur ce sujet. Le pilote ouvre 14 jours avant le gel, une durée que nous proposons, à régler sur votre volume.
| Date | Jalon | Ce que vous faites | Condition pour passer à la suite |
|---|---|---|---|
| Lundi 24 mai | Ouverture du pilote | Un seul flux part dans le nouvel outil, tous les autres restent dans l’ancien | Un document signé et son dossier de preuve relus, un refus et une expiration observés |
| Lundi 7 juin | Gel | Dernier envoi dans l’ancien outil, tous les flux passent au nouveau, connecteurs, scripts et modèles partagés qui créent des demandes coupés, création bloquée si un réglage le permet | Pilote validé, règle d’envoi écrite et diffusée |
| Lundi 21 juin | Fin de validité | Les derniers envois arrivent à échéance, les demandes encore ouvertes sont traitées une par une | Critère 1 tenu |
| Du 21 au 25 juin | Export final | Documents et preuves, flux par flux | Critères 2 et 3 tenus |
| Lundi 28 juin | Décision de fermeture | Relecture de chaque flux, décision écrite | Critère 4 tenu |
| Mercredi 30 juin | Date d’effet | Au plus tard ce jour, dernières clés d’API retirées, dont celle de l’export, et connecteurs restants aussi | Rien ne l’appelle plus |
| Validité des derniers envois | Gel sans marge | Gel avec 9 jours de marge | Lecture |
|---|---|---|---|
| 14 jours | 16 juin 2027 | 7 juin 2027 | Défaut lu chez Universign |
| 60 jours | 1er mai 2027 | 22 avril 2027 | Maximum sans transactions longues, lu chez Universign ; 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 |
| 180 jours | 1er janvier 2027 | 23 décembre 2026 | Maximum avec transactions longues, lu chez Universign ; même réserve sur la pause |
| 365 jours | 30 juin 2026, déjà passé | 21 juin 2026, déjà passé | Maximum lu chez Signaturit : à abaisser avant tout calcul |
Quatre critères d’arrêt, à constater flux par flux
Le sort de chaque document en cours se traite sur notre page dédiée. Ces critères répondent à une autre question : l’ancien outil peut-il s’arrêter ? Une demande expirée compte encore tant que vous n’avez pas décidé de son sort, parce que Youtrust documente une réactivation manuelle et que Signaturit émet un événement expiration_extended lors d’une prolongation.
- Critère 1 : aucune demande ouverte. Relisez l’état de chaque demande dans l’outil, sans vous fier aux seuls webhooks, ces messages automatiques que l’outil envoie à vos logiciels. Les demandes en pause comptent, et chaque demande expirée reçoit une décision écrite : abandonnée ou renvoyée dans le nouvel outil.
- Critère 2 : stock égal. Par flux, le nombre de demandes terminées égale le nombre de documents exportés et le nombre de preuves exportées. Un écart d’une unité se cherche avant de fermer.
- Critère 3 : aucune création depuis le gel. Listez les demandes créées après la date de gel : il ne doit y en avoir aucune. Dès le gel, coupez les connecteurs, scripts et modèles partagés qui créent des demandes. Gardez la clé d’API qui sert à l’export jusqu’à la fin de celui-ci, et retirez-la au plus tard à la date d’effet. Si la même clé sert aussi à créer, retirez-la du code qui crée.
- Critère 4 : une preuve relue par flux. Ouvrez un document et son dossier exportés pour chaque flux, depuis votre stockage et sans accès à l’ancien outil, et faites de même pour un document signé dans le nouveau.
Trois solutions si un critère manque
Le pilote n’a pas produit de preuve lisible à la date de gel : ne gelez pas. Vous ne pouvez repousser le gel qu’en raccourcissant d’autant la validité des derniers envois, car la marge d’export mesurée ne se réduit pas. Exemple fictif : avec 10 jours de validité au lieu de 14, le gel passe du 7 au 11 juin. Si cela ne suffit pas, demandez par écrit à l’éditeur une prolongation d’accès, ou prolongez le contrat. Prolonger se décide avant la date de préavis ; passé cette date, seule la demande écrite reste.
Des demandes restent ouvertes après la fin de validité : relancez, puis annulez et renvoyez dans le nouvel outil celles qui ne finiront pas, en suivant la page sur les documents en cours. Universign indique qu’une demande déjà partie peut encore être mise à jour tant que son état est started, stalled ou paused : ne la prolongez que si vous avez encore le temps d’exporter.
Le stock exporté n’égale pas le stock terminé à la date de décision : demandez à l’éditeur une prolongation d’accès par écrit. Les conditions de Youtrust retirent l’accès à la date d’effet, et leur article sur le retour des dossiers de preuve ne dit pas si ce retour reste possible après la fin.
Côté coût, un abonnement annuel couvre sa période : Youtrust écrit ne pas rembourser au prorata. Un outil facturé au mois se compte en mois entamés, ce qui reste le calcul le plus prudent.
Limites de cette page
Le protocole, ses durées et ses critères sont notre méthode, sans changement d’outil observé et sans test. Les 9 jours de marge et les 14 jours de pilote sont choisis pour l’exemple. Nous n’avons lu qu’une partie des références d’API, dans un texte extrait de leurs pages. La phrase d’Universign sur 45 jours figure dans la section sur la pause, sans que la référence dise comment elle s’accorde avec les 60 ou 180 jours : faites-la confirmer par Universign si vous comptez sur une durée longue. Nous n’avons pas lu l’effet d’une baisse de validité sur les demandes déjà parties, sauf la possibilité de mise à jour chez Universign : demandez-le à votre éditeur avant de compter dessus. Nous n’avons pas trouvé la validité par défaut chez Signaturit, Youtrust et Certyneo, et nous n’avons pas lu celle de Docusign : relevez-la dans votre compte. Facturation mensuelle de Youtrust à confirmer.
Prochaine action
Relevez dans l’ancien outil la plus longue durée de validité de vos flux, abaissez-la si possible, mesurez le temps d’un export d’essai, puis écrivez votre propre calendrier et les quatre critères, avec le nom de la personne qui les constate.
Preuves et sources
Références d’API d’Universign et de Signaturit, lues en partie, documentation des webhooks de Youtrust et conditions de Youtrust du 2 juillet 2026, lues le 4 novembre 2026. Le protocole est notre méthode : aucun outil n’a été testé et aucun recouvrement réel n’a été observé.
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 et un maximum de 60 ou 180 jours selon l’activation des transactions longues.
Périmètre : API /v1, partie lue
Réserve : Une phrase de la section sur la pause cite 45 jours après le démarrage, sans conciliation avec ce maximum : divergence à faire confirmer.
Relevé du 4 novembre 2026.
- Universign : Universign API, durée, metadata, anchor, modèles routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- Universign : Universign API reference, durée d'une transaction routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- Universign : Universign API reference routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. La documentation de Signaturit fixe expire_time à 365 jours au plus et prévoit un événement expiration_extended.
Périmètre : API v3
Réserve : Défaut non trouvé.
Relevé du 4 novembre 2026.
- Signaturit : Signaturit API, expiration, relance, annulation, modèles v3 ; modèles aussi en v4. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- Signaturit : Signaturit API, événements, data, word_anchor, téléchargements v3. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. Les conditions de Youtrust ne prévoient aucun remboursement au prorata et 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, 15.1.1 et 15.3
Réserve : Lu en anglais.
Relevé du 4 novembre 2026.
- Youtrust : Youtrust, conditions générales d'utilisation et d'abonnement Latest update: 2 July 2026. Lu le 4 novembre 2026. Document d’origine.
Notre calcul ou déduction. Pour une date d’effet fictive au 30 juin 2027, 14 jours donnent le 16 juin, 60 jours le 1er mai, 180 jours le 1er janvier 2027 et 365 jours le 30 juin 2026 ; avec 9 jours de marge, le 7 juin, le 22 avril, le 23 décembre 2026 et le 21 juin 2026.
Périmètre : Calcul de dates
Réserve : Marge choisie pour l’exemple.
Daté du 4 novembre 2026.
Notre calcul ou déduction. Dans l’exemple fictif, le pilote ouvre le lundi 24 mai 2027, soit 37 jours avant le mercredi 30 juin, le gel tombe le lundi 7 juin et les derniers envois expirent le lundi 21 juin.
Périmètre : Calcul de dates
Réserve : Jours de la semaine calculés à la main.
Daté du 4 novembre 2026.
Déclaration de l’émetteur. La documentation de Youtrust décrit l’événement signature_request.reactivated pour la réactivation manuelle d’une demande expirée.
Périmètre : Webhooks Youtrust
Réserve : Non testé.
Relevé du 4 novembre 2026.
- Youtrust : Youtrust, événements de webhook non daté. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. La référence d’Universign permet de mettre à jour une transaction à l’état draft, started, stalled ou paused.
Périmètre : API /v1, partie lue
Réserve : Non testé. Effet sur la durée lu pour le report d’une transaction en pause.
Relevé du 4 novembre 2026.
- Universign : Universign API, durée, metadata, anchor, modèles routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Notre avis. Un recouvrement au-delà de la validité maximale ne couvre aucune demande en cours, et la validité des derniers envois peut se raccourcir.
Périmètre : Bascule choisie
Réserve : Avis assumé. Réglages à contrôler par éditeur.
Relevé du 4 novembre 2026.
- Universign : Universign API reference, durée d'une transaction routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Notre méthode. Le protocole comprend une date de gel égale à la date d’effet moins la validité la plus longue et la marge d’export, quatre critères d’arrêt et trois solutions si l’un manque. Les connecteurs, scripts et modèles partagés qui créent des demandes se coupent au gel, et la clé d’API de l’export se retire après l’export, au plus tard à la date d’effet.
Périmètre : À exécuter par le lecteur
Réserve : Notre méthode, jamais exécutée par nos soins.
Daté du 4 novembre 2026.
Notre calcul ou déduction. Dans l’exemple fictif, ramener la validité de 14 à 10 jours avec 9 jours de marge repousse le gel du 7 au 11 juin 2027.
Périmètre : Calcul de dates
Réserve : Vaut pour les derniers envois, pas pour les demandes déjà parties.
Daté du 4 novembre 2026.