API et intégrations
Signature dans votre logiciel de gestion (ERP) : vérifiez le niveau du module intégré et, si besoin, branchez un prestataire sur un seul circuit de signature
Pour qui : Responsable technique ou financier de PME à qui l’on propose d’intégrer la signature à son ERP pour tous ses bons de commande et contrats.
Vérifiez d’abord le niveau de signature : si notre guide retient la signature simple pour cet acte (aucun niveau imposé, enjeu faible, signataire déjà identifié et coordonnées confirmées), le module de votre ERP, votre logiciel de gestion, peut suffire. La documentation d’Odoo 19.0 écrit « Odoo generates the first type, simple electronic signatures », alors que sa page commerciale annonce « Compliant with eIDAS Qualified Electronic Signatures » : demandez que le niveau soit écrit au contrat. Sinon, branchez un prestataire sur un seul circuit de signature et écrivez trois choses avant tout développement : l’événement qui clôt la pièce (le bon de commande ou le contrat dans l’ERP), l’identifiant qui la retrouve, les deux fichiers qui reviennent (le document signé et le dossier de preuve). SAP n’est pas traité ici.
Notre avis
Commencez par le niveau de signature et par le circuit qui revient le plus. Ne signez aucun projet d’intégration tant que personne n’a rempli, pour ce circuit, le tableau des quatre cas de cette page.
Pourquoi
- Une signature simple peut suffire à un acte : la question est de savoir si aucun niveau n’est imposé et si elle convient à son enjeu et à son signataire, et d’obtenir par écrit ce que le module livre.
- Le champ de rattachement, qui relie une signature à sa pièce dans l’ERP, décide du coût pour rapprocher les deux : Youtrust, Universign, Signaturit et Docusign en décrivent un, et nous n’en avons pas lu chez Certyneo.
- Une pièce close sur le mauvais événement crée une commande lancée sans document signé disponible.
Ce qui change le choix
Une clôture automatique à fort volume fait passer ce circuit à l’API dès le départ. Un acte pour lequel nous retenons plus que la signature simple écarte le module intégré d’Odoo, tant que son niveau n’est pas écrit au contrat.
L’ordre à suivre
- Module intégré à l’ERP, si notre guide pour choisir le niveau de signature retient la signature simple et que le niveau du module est écrit
- Un seul circuit de signature par connecteur ou API, avec la table de sortie remplie
- Une intégration globale, une fois que ce circuit a fait ses preuves
Odoo : la documentation écrit simple, la page commerciale écrit qualifiée
Sur sa page Validity, Odoo écrit générer des signatures simples, et ajoute « You may need to bring supporting evidence of a signature’s validity » : vous pourriez devoir apporter des éléments qui prouvent la validité de la signature. Sa page commerciale annonce une conformité aux signatures qualifiées, et sa page de fonctions parle d’« a Qualified Electronic Signature through itsme® » : la signature qualifiée dépend donc au moins de ce parcours itsme, à faire décrire par Odoo. Tenez le module pour une signature simple tant qu’un contrat n’écrit pas autre chose.
Deux points concernent directement un ERP. Si la demande part d’une fiche de l’ERP (un enregistrement), le certificat d’achèvement s’ajoute à son fil, et il reste téléchargeable depuis le module Sign. Et l’authentification demandée peut disparaître : « If you do not have any credits left, authentication is skipped. » Autrement dit, sans crédits restants, cette étape est sautée. Une règle interne qui exige un code SMS doit donc surveiller ce solde de crédits.
Sur SAP, nous n’avons rien pu ouvrir : le titre d’une page indique une offre portant le nom de Docusign, dont nous n’avons pas lu le contenu. La table de sortie ci-dessous s’y remplit de la même façon.
Notre table de sortie : quatre cas à écrire avant de développer
Cette table est notre méthode : pour chaque issue d’une demande, elle dit ce qui doit revenir de l’outil de signature dans l’ERP. Remplissez-la pour un seul circuit de signature, puis testez chaque ligne sur l’environnement d’essai.
| Cas | Ce qui doit arriver de l’outil | État de la pièce dans l’ERP | Ce qui revient et où |
|---|---|---|---|
| Toutes les signatures posées | L’événement de fin de la demande, jamais celui d’un signataire | Close, sans geste manuel ni double validation | Document signé et dossier de preuve, rattachés à la pièce |
| Refus d’un signataire | L’événement de refus | État clair, alerte à une personne nommée | Motif si l’éditeur le fournit, aucun document signé |
| Pièce modifiée après l’envoi | Votre annulation, puis l’événement d’annulation | Ancienne demande rattachée et close, nouvelle demande reliée | Trace de l’annulation dans la pièce |
| Délai dépassé ou appel perdu (notification non reçue) | L’événement d’expiration, ou l’état que vous allez relire vous-même chez l’éditeur | Pièce rouverte, alerte | Rien tant que la relecture n’a pas confirmé l’état |
Par éditeur : l’événement, l’identifiant et les fichiers lus
| Éditeur | Fin de la demande | Refus, annulation, expiration | Identifiant de votre pièce | Fichiers à récupérer |
|---|---|---|---|---|
| Youtrust, ex-Yousign | signature_request.done | declined, canceled, expired, rejected | external_id, ajouté aux webhooks | Audit trail par GET /v3/signature_requests/{id}/audit_trails/download, une fois la demande done |
| Universign | transaction.lifecycle.completed | cancelled, expired ; aucun refus dans la liste du cycle de vie lue | metadata : clés de 20 caractères, valeurs de 200, 15 entrées | Attestation via /transactions dans les 60 jours suivant la fin, ou via /archives |
| Signaturit | document_completed, puis audit_trail_completed | document_declined, document_canceled, document_expired | data en clé et valeur, recherche possible par ce champ | .../download/signed et .../download/audit_trail |
| Certyneo | envelope.completed, pas recipient.signed | envelope.declined, voided, expired | Aucun champ lu : gardez la correspondance avec envelopeId | /v1/envelopes/id/signed-document et /audit-trail ; lien de l’événement valable 7 jours |
| Docusign | envelope-completed | Non lu | Envelope custom field de 100 caractères, visible dans le certificat d’achèvement | Route non lue |
Trois règles de mise en place, et un second circuit seulement après mesure
Écrivez le numéro de pièce dans le champ de rattachement dès la création de la demande. N’y mettez aucune donnée que le signataire ne doit pas voir, puisque le champ de Docusign apparaît dans le certificat d’achèvement. Chez Certyneo, notez l’identifiant retourné à la création dans votre propre table.
Copiez les fichiers chez vous dès l’événement de fin : le lien de Certyneo expire au bout de 7 jours, et la fenêtre de 60 jours d’Universign impose ensuite un passage par les archives. Rattachez-les à la pièce, puis vérifiez-les après un changement de version de l’ERP.
Faites passer tous les appels au prestataire par une seule fonction ou un seul service interne, comme le décrit notre page API ou interface. Tenez pendant un mois le relevé décrit sur cette même page, qui note chaque envoi, avant d’ajouter un second circuit. Le suivi des événements et la relecture d’état se trouvent sur notre page sur les webhooks.
Limites de cette page
Aucun ERP ni connecteur testé, aucun événement reçu : les quatre cas et la table de sortie sont une méthode. Seul Odoo est traité parmi les ERP, sans comparaison. Nous avons lu 100 000 des 105 248 caractères de sa page Security, ses pages commerciales ne sont pas datées, et le lien entre la signature qualifiée annoncée et le parcours itsme reste à faire préciser par Odoo. SAP : la page a renvoyé une erreur 403 (accès refusé), et nous ne disons rien de son offre au-delà de son titre. Pour Docusign et l’external_id de Youtrust, nous n’avons lu que des extraits de résultats de recherche : faites confirmer ces points par l’éditeur. Chez Signaturit, la génération de l’audit trail est décrite en POST dans son titre et en GET dans son exemple. Goodflag, Namirial et Oodrive ne figurent pas dans la table : leurs événements n’ont pas été relus ici.
Prochaine action
Prenez le document que vous faites signer le plus souvent et déterminez son niveau avec notre guide pour choisir le niveau de signature. Demandez par écrit à l’éditeur de votre ERP le niveau que livre son module. Remplissez ensuite la table de sortie et testez ses quatre cas sur l’environnement d’essai.
Preuves et sources
Documentation Sign d’Odoo 19.0 avec ses pages Validity et Security, pages commerciales d’Odoo, documentations de Youtrust, Universign, Signaturit et Certyneo, extraits de recherche pour Docusign et pour une référence de Youtrust, lus le 4 novembre 2026. Pages de SAP non ouvertes. Aucun ERP n’a été testé.
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 page Validity d’Odoo 19.0 écrit « Odoo generates the first type, simple electronic signatures » et ajoute qu’une preuve complémentaire peut être nécessaire.
Périmètre : Odoo 19.0
Réserve : Niveau non vérifié par un test.
Relevé du 4 novembre 2026.
- Odoo : Validity of electronic signatures, Odoo 19.0 19.0. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. La page commerciale d’Odoo Sign annonce « Compliant with eIDAS Qualified Electronic Signatures (for all European Countries) », et sa page de fonctions « a Qualified Electronic Signature through itsme® ».
Périmètre : Pages commerciales d’Odoo
Réserve : Non datées. Service et entité non nommés sur les pages lues.
Relevé du 4 novembre 2026.
- Odoo : Odoo Sign, pages commerciales non datée. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. La documentation d’Odoo prévoit un certificat d’achèvement envoyé avec le document signé, ajouté au fil de l’enregistrement dont part la demande et téléchargeable depuis Sign, et précise « If you do not have any credits left, authentication is skipped. »
Périmètre : Odoo 19.0
Réserve : 100 000 caractères sur 105 248 lus. Non testé.
Relevé du 4 novembre 2026.
- Odoo : Security and authentication, Odoo 19.0 19.0. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. Youtrust décrit signature_request.done, declined, canceled, expired et rejected ; selon des extraits de sa référence, external_id est ajouté aux webhooks et l’audit trail se télécharge une fois la demande done.
Périmètre : API v3
Réserve : Référence lue par extraits ; route du document non relue ici.
Relevé du 4 novembre 2026.
- Youtrust : Youtrust, événements de webhook non daté. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- Youtrust : Youtrust, référence API, external_id, modèle et audit trail v3. Lu le 4 novembre 2026. Vue en extrait, à vérifier.
Déclaration de l’émetteur. Universign décrit transaction.lifecycle.completed, cancelled et expired, avec metadata limitées à des clés de 20 caractères, des valeurs de 200 et 15 entrées, et une attestation accessible via /transactions dans les 60 jours suivant la fin ou via /archives.
Périmètre : API /v1
Réserve : Référence lue en partie. Refus non vu dans le cycle de vie lu.
Relevé du 4 novembre 2026.
- Universign : Universign, événements non daté. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- 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 routes /v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. Signaturit décrit document_completed, audit_trail_completed, document_declined, document_canceled et document_expired, un champ data en clé et valeur sur lequel filtrer les signatures, et des routes de téléchargement du document signé et de l’audit trail.
Périmètre : API v3
Réserve : Titre POST et exemple GET incohérents pour la génération de l’audit trail. Non testé.
Relevé du 4 novembre 2026.
- 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. Certyneo décrit envelope.completed, declined, voided et expired, indique que le PDF scellé n’existe pas encore à recipient.signed, donne un lien valable 7 jours à la fin et aucun champ de référence métier sur les pages lues.
Périmètre : API v1
Réserve : OpenAPI non ouverte : absence du champ non établie.
Relevé du 4 novembre 2026.
- Certyneo : Certyneo, webhooks non daté. Lu le 4 novembre 2026. Déclaration de l’émetteur.
- Certyneo : Certyneo, placement des champs et modèles Public API v1. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Déclaration de l’émetteur. Selon des extraits de sa documentation, Docusign émet envelope-completed, et ses envelope custom fields, limités à 100 caractères, sont visibles dans Connect et dans le certificat d’achèvement.
Périmètre : Docusign Connect
Réserve : Extraits de recherche, page de détail non restituée.
Relevé du 4 novembre 2026.
- Docusign : Docusign, Auto-Place, event triggers et custom fields, extraits non daté. Lu le 4 novembre 2026. Vue en extrait, à vérifier.
Notre calcul ou déduction. Rien n’a été lu sur le contenu de l’offre de signature de SAP.
Périmètre : État de notre lecture
Réserve : Page en erreur 403. Pas un constat sur SAP.
Daté du 4 novembre 2026.
Notre avis. Décider le niveau, puis brancher un seul flux avec table de sortie remplie, reste notre avis, faute de source comparative.
Périmètre : PME avec ERP
Réserve : Aucune donnée d’usage.
Relevé du 4 novembre 2026.
- Odoo : Validity of electronic signatures, Odoo 19.0 19.0. Lu le 4 novembre 2026. Déclaration de l’émetteur.
Notre méthode. La table de sortie, ses quatre cas et les règles de pose forment notre méthode.
Périmètre : À exécuter par le lecteur
Réserve : Non testée.
Daté du 4 novembre 2026.