Le délai de signature n’est pas un délai de décision
Quand on mesure le temps entre l’envoi d’un devis et sa signature, on croit mesurer l’hésitation du client. On mesure surtout du temps mort.
Le document arrive, il est lu, il est mis de côté — pas refusé, mis de côté. Il faudrait le rouvrir, vérifier un point, en parler à quelqu’un. La semaine passe. De votre côté, la relance dépend de quelqu’un qui doit se souvenir, retrouver la date d’envoi et trouver le ton juste. Elle a lieu tard, ou pas.
Rien de tout cela ne porte sur le fond. C’est de la friction pure, et la friction se supprime.
Et il y a le risque inverse, plus embarrassant : relancer un client qui a déjà signé, ou envoyer une deuxième copie d’un contrat déjà retourné. Cela arrive quand le suivi est tenu à la main, et cela abîme plus que la relance tardive.
Ce qu’on automatise
La production du document à partir de vos données et de votre modèle, avec son numéro de version.
L’identification du signataire. Qui signe, avec quelle adresse, et s’il faut plusieurs signatures — dans quel ordre.
L’envoi, accompagné d’un message qui dit en une phrase ce qui est demandé et pour quand.
Le suivi d’état. Envoyé, ouvert, signé, refusé, expiré. En temps réel, et visible sans ouvrir le portail du prestataire.
Les relances, selon votre séquence, arrêtées immédiatement par toute réponse ou toute signature.
La récupération et l’archivage de l’exemplaire signé avec son dossier de preuve, rangé dans le dossier client.
La suite. Le document signé est un événement : il peut ouvrir un dossier de production, planifier une intervention, déclencher une facture d’acompte, prévenir l’équipe.
Comment ça marche techniquement — pour qui veut le détail
L’intégration au prestataire. Les plateformes sérieuses — Yousign, Docusign, Universign, ou une brique ouverte comme Documenso en auto-hébergé — exposent une API REST et des webhooks. Le flux dépose le document et les signataires, reçoit un identifiant d’opération, puis écoute les événements plutôt que d’interroger en boucle. On garde malgré tout une réconciliation quotidienne : un webhook peut se perdre, et découvrir trois jours plus tard qu’un contrat était signé n’est pas acceptable.
La sécurité des webhooks. Les notifications entrantes sont signées — en-tête HMAC-SHA256 avec un secret partagé — et la signature est vérifiée avant tout traitement, avec une comparaison à temps constant. Un webhook accepté sans vérification est un point d’entrée par lequel n’importe qui peut déclarer un contrat signé. L’horodatage de l’événement est également contrôlé, contre le rejeu.
L’idempotence des événements. Les plateformes réémettent en cas de doute. Chaque événement porte un identifiant stocké en base avec contrainte d’unicité : le second passage est ignoré silencieusement. Sans cela, un contrat signé une fois déclenche deux factures d’acompte.
La machine à états. Le document vit dans un état explicite, en PostgreSQL : brouillon → envoyé → ouvert → signé | refusé | expiré. Les transitions autorisées sont contraintes en base, pas seulement dans le code. Chaque changement est horodaté, ce qui donne gratuitement les statistiques de délai par étape — et c’est ainsi qu’on découvre où le temps se perd réellement.
L’ordonnanceur de relances. Pas de minuterie en mémoire : une table relances avec une date d’échéance, consommée par un travailleur régulier via SELECT … FOR UPDATE SKIP LOCKED. L’état survit à un redémarrage, plusieurs travailleurs peuvent tourner, et une relance manquée pendant une coupure est rattrapée. Une annulation est une simple mise à jour de ligne, ce qui garantit qu’une réponse du client stoppe bien la séquence même si elle arrive une seconde avant l’envoi.
La détection de réponse. L’arrêt de séquence est déclenché par trois signaux : événement de signature du prestataire, réponse du client dans le fil de discussion — repérée par l’en-tête In-Reply-To ou le Message-ID d’origine, pas par le sujet —, ou intervention manuelle. Se fier au sujet du message est ce qui fait relancer un client qui vient de répondre.
L’archivage probant. On conserve trois choses ensemble : le PDF signé, le dossier de preuve fourni par le prestataire — traces d’identification, horodatages, adresses —, et l’empreinte SHA-256 de l’ensemble. Le tout dans un stockage non modifiable, avec la version du modèle qui a servi à produire le document. C’est ce triplet qui permet de répondre, deux ans plus tard, à la question de savoir exactement ce qui a été signé.
Les rappels de validité. Un devis a une durée de validité ; le flux la connaît, prévient avant l’échéance plutôt qu’après, et propose la reconduction. C’est une ligne de code et cela évite des situations commerciales désagréables.