Signaturit dans Odoo : ce qu'un module natif apporte et que Zapier n'apporte pas

Réponse courte : Zapier suffit pour déclencher une signature et savoir qu'elle est terminée. Il ne suffit pas pour refléter dans Odoo les statuts intermédiaires par lesquels passe un document, ni pour se rattraper après un webhook perdu, ni pour archiver le PDF signé et sa preuve dans le bon enregistrement. Si votre processus se termine quand le client signe, un Zap suffit et coûte moins cher. Si votre processus commence quand le client signe (facturer, ouvrir un dossier, créer un employé), vous avez besoin des statuts dans l'ERP.

Point de départ : le document circule par e-mail

Le circuit habituel comporte trois étapes manuelles : quelqu'un génère le PDF du devis dans Odoo, le charge dans le panneau de Signaturit et attend ; quand le client signe, le PDF signé arrive dans la boîte d'une personne ; cette personne le recharge dans Odoo, si elle y pense. Les symptômes sont toujours les mêmes : personne ne sait si le client l'a ouvert, le PDF signé finit sur le bureau de quelqu'un, et quand il faut la preuve (le document probatoire, l'audit trail), elle n'est pas à côté de la facture, là où chacun la chercherait.

Avant tout, une condition qui concerne les trois approches de la même façon : votre plan Signaturit doit inclure l'accès à l'API. L'authentification repose sur un token Bearer que l'on récupère dans le panneau, et le sandbox et la production sont deux enregistrements distincts avec deux tokens distincts. Signaturit ne publie pas ouvertement quels plans incluent cet accès : confirmez-le avec eux avant de concevoir quoi que ce soit. Sans token, il n'y a ni Zap, ni n8n, ni module.

Les trois façons de les relier, et où Zapier suffit

L'app Signaturit sur Zapier publie, à ce jour, un seul trigger (« New Signed Document », c'est-à-dire « un document a été signé ») et cinq actions : créer une demande de signature, la créer à partir d'un modèle, l'annuler, envoyer un rappel et créer un e-mail certifié. L'app Odoo auto-hébergé, de son côté, expose des triggers et des actions génériques sur les enregistrements (créer un enregistrement, un lead, une tâche…). C'est toute la matière première disponible.

Où Zapier suffit (et vous pouvez arrêter de lire)

Si vous n'envoyez qu'un seul type de document, en petit nombre chaque mois, et que vous avez seulement besoin qu'une tâche soit créée ou qu'un message soit posté dans le chat à la signature, montez un Zap et n'y réfléchissez plus. Cela suffit aussi si le document ne naît pas dans Odoo (un NDA préparé dans le panneau de Signaturit). La règle est la suivante : si le statut de la signature ne change aucune décision dans l'ERP, l'ERP n'a pas besoin de le connaître.

Quel document sort de quel modèle Odoo

C'est la partie qu'une étape générique « créer un enregistrement » ne peut pas faire : elle ne sait pas rendre le rapport QWeb d'une commande client. Chaque modèle a besoin de trois choses qui lui sont propres : le titre que verra le signataire, le destinataire par défaut et la façon dont le PDF est généré. Dans le connecteur que nous avons construit, chaque pont résout exactement ces trois points.

• Devis et commande client (sale.order) : le rapport standard de commande client, avec le client comme signataire.
• Facture (account.move) et bon de commande fournisseur (purchase.order), pour les acceptations et confirmations de fournisseur.
• Bon de livraison (stock.picking) : le rapport de bon de livraison, qui, une fois signé, sert de preuve de livraison.
• Contrat de travail : hr.contract dans Odoo 17 et 18, et hr.version dans Odoo 19, où le module RH a été refondu. Le genre de détail qui oblige à maintenir trois branches de code, et non une.
• Offre à un candidat (hr.applicant), opportunité CRM (crm.lead), ticket (helpdesk.ticket) et projet et tâche, pour les acceptations de travaux réalisés.

Le cycle complet des statuts, là où tout le reste s'effondre

L'API v3 de Signaturit indique, par document, huit statuts : in_queue, ready, signing, completed, expired, canceled, declined et error. Ses événements de webhook sont encore plus granulaires : e-mail délivré, e-mail rejeté, document ouvert, document signé, pièce d'identité ajoutée, expiration prolongée, audit trail généré…

Dans Odoo, cela doit se traduire en deux choses distinctes. Première : la demande elle-même, avec son propre cycle (brouillon, envoyée, en cours, terminée, refusée, expirée, annulée, erreur). Seconde : un champ sur le document d'origine, pour que le commercial qui ouvre le devis voie le statut sans quitter le devis. Dans notre connecteur, ce champ a sept valeurs : non envoyé, en attente de signature, signé, refusé, expiré, annulé et erreur.

Avec plusieurs signataires, le statut se déduit de l'ensemble : tous terminés, demande terminée ; un seul qui refuse, demande refusée ; certains ont signé et d'autres non, en cours. Et il existe une protection qu'on n'apprend qu'en se trompant : une demande annulée à la main ne doit jamais se laisser écraser par un événement ultérieur, car Signaturit peut signaler error par document sur une demande que vous aviez déjà annulée. Sans elle, une annulation volontaire se transforme toute seule en une erreur inexplicable.

Dernière pièce : les trois statuts terminaux défavorables (refusé, expiré et erreur) ne peuvent pas se limiter à un changement de couleur. Dans le connecteur, ils créent une activité en attente pour la personne qui a créé la demande, avec la consigne de décider s'il faut renvoyer, prolonger le délai ou remplacer. Un refus que personne ne regarde équivaut exactement à ne pas être au courant.

Relances et échecs : pourquoi un webhook perdu est pire qu'une erreur visible

Une erreur visible vous arrête. Un webhook perdu vous laisse croire que le document est toujours en attente alors qu'il est signé depuis des jours : ou l'inverse. La seconde situation coûte bien plus cher, car personne ne la cherche.

Les relances doivent être asymétriques. Dans le connecteur, chaque appel a un délai d'attente maximal de 30 secondes par défaut, configurable. Une lecture (GET) est relancée jusqu'à deux fois, avec une attente croissante, en cas de 429, 500, 502, 503 ou 504. Une écriture (POST, PATCH, DELETE) n'est jamais relancée : relancer une création qui n'est pas idempotente revient à envoyer le même contrat deux fois au même signataire. Mieux vaut une erreur visible qu'un doublon silencieux. Et une règle qui manque souvent : une redirection de l'API est traitée comme une erreur dure et n'est jamais suivie, car la suivre avec l'en-tête d'autorisation, c'est remettre votre token à l'adresse que désigne le Location.

Le webhook n'est pas la vérité : c'est une sonnette. Signaturit ne signe pas cryptographiquement ses webhooks (pas de HMAC) et sa documentation ne décrit aucune politique de relance automatique ; il propose en revanche un endpoint pour relancer un événement à la main. Dans ces conditions, l'événement entrant dans le connecteur est authentifié par un token propre à chaque compte, placé dans l'URL elle-même, éventuellement restreint à l'IP d'origine que Signaturit publie (une seule, la même en sandbox et en production), enregistré avec une clé de déduplication SHA-256 du JSON canonisé, et alors (et seulement alors) on interroge à nouveau l'API authentifiée. Une livraison en double répond 200 et n'est pas traitée deux fois.

Et si l'événement n'arrive jamais, il y a un filet de sécurité : un cron horaire parcourt jusqu'à 200 demandes en attente et les interroge à nouveau. Cette ligne est la vraie différence avec un Zap. Le Zap dépend du webhook ; si le webhook se perd, il n'y a rien d'autre.

La pièce jointe qui revient : où elle est stockée, sous quel nom et avec quelle traçabilité

Quand la demande passe à terminée, deux fichiers reviennent, pas un. Le PDF signé est archivé sous <nombre>.signed.pdf et le document probatoire sous <nombre>.audit_trail.pdf, tous deux en pièces jointes de l'enregistrement de la demande, qui pointe à son tour vers le devis, la facture ou le bon de livraison dont elle est issue. Aucun des deux n'atterrit dans la boîte de quelqu'un.

Un détail qui n'apparaît qu'en production : le document probatoire n'est pas toujours prêt au moment de la signature. Signaturit le génère à part et émet un événement propre quand il est disponible. Si le téléchargement échoue, il ne faut pas laisser de trou : il faut demander explicitement sa génération et le récupérer au cycle suivant. Un connecteur qui télécharge le PDF signé et oublie la trace vous laisse avec la moitié de la preuve. Et si vous avez demandé au signataire de téléverser des pièces (pièce d'identité, justificatif de domicile), ces fichiers sont téléchargés à part, dans un ZIP, vers le même enregistrement.

Ce qu'il faut examiner avant de choisir l'approche

1. Combien de types de document envoyez-vous en signature ? Un seul, un Zap. Quatre ou plus, chacun avec son PDF et son destinataire, et maintenir quatre Zaps coûte déjà plus cher qu'un module.
2. Le statut de la signature change-t-il une décision dans Odoo ? S'il faut facturer, planifier ou créer quelqu'un à la signature, l'ERP a besoin du statut. S'il suffit de prévenir quelqu'un, non.
3. Avez-vous besoin du document probatoire archivé ? Si vous devez le présenter lors d'un contrôle ou d'un litige, mieux vaut qu'il soit à côté de la facture.
4. Que se passe-t-il si personne ne regarde le panneau pendant deux semaines ? Demandez à qui revient une tâche quand un contrat expire sans être signé. Si la réponse est « à personne », vous n'avez pas encore d'intégration.
5. Combien de versions d'Odoo devez-vous maintenir ? Un Zap ne dépend pas de la version ; un module, si, et le passage de hr.contract à hr.version en est le coût réel.
6. Votre plan Signaturit inclut-il l'API ? Sans token, aucune des trois options ne fonctionne. Vérifiez-le avant tout.

D'où vient tout cela

Nous avons construit sept modules sur cette intégration : le noyau, qui gère comptes, demandes, destinataires, événements et archivage, et six ponts pour le CRM, l'assistance, les RH, les projets, le recrutement et l'entrepôt. Au total, 270 tests automatisés sur la branche Odoo 19, 262 sur la 18 et 266 sur la 17 : le même code est maintenu simultanément pour les trois versions.

Aucune des décisions de cet article ne vient de la lecture de la documentation. Elles viennent de séries de QA successives contre le connecteur réel : en une seule série, 23 défauts trouvés en le testant en conditions réelles ont été corrigés, plus 5 issus d'un audit adverse contre la documentation de l'API ; à la suivante, 17 de plus. Le journal des modifications du module les énumère un par un, avec la date. Une fiche autogénérée « produit A × produit B » n'a aucune de ces cicatrices, parce que personne ne s'en est jamais servi.

Liens utiles chez FlexigoTech

Questions fréquentes

Ce que nous faisons à ce sujet