NexTool Solutions

Les documents à signer circulent encore par courriel et WhatsApp — sans traçabilité, sans statut connu et déconnectés des tickets qui les ont fait naître. Le module Digital Signature de NexTool, avec Autentique, ramène ce flux dans GLPI.

Mise à jour : depuis octobre 2026 (version 2.0 du module), Autentique se souscrit comme fournisseur : le produit Digital Signature (Autentique) inclut déjà le module. Cette révision ajoute aussi le lien de signature par WhatsApp, l'envoi en masse et ce qui a changé dans le webhook. La comparaison avec DocuSeal, DocuSign et TOTVS se trouve dans Signature électronique dans GLPI : DocuSeal, Autentique, DocuSign et TOTVS.

Le problème

Contrats de prestation, conditions d'acceptation, autorisations d'accès, procès-verbaux et résiliations naissent d'un processus déjà enregistré dans un ticket. Mais la signature se fait en dehors : quelqu'un exporte le PDF, l'envoie par courriel, relance le client sur WhatsApp et, quelques jours plus tard, essaie de se souvenir où la version signée a été rangée. GLPI natif stocke bien le fichier (onglet Documents, table glpi_documents) et le lie au ticket, mais n'a aucune notion de signature : il ne sait pas qui doit signer, si la personne a signé, et ne conserve aucune piste de preuves. Quand quelqu'un demande « ce contrat a-t-il été signé ? », la réponse consiste encore à fouiller les courriels en espérant que la bonne pièce jointe y soit toujours.

GLPI natif ou Digital Signature avec Autentique

Il vaut la peine de séparer ce que GLPI fait seul de ce que l'intégration ajoute. Le cœur de GLPI excelle pour joindre et versionner des fichiers, mais la signature électronique n'a jamais fait partie de son périmètre :

Sur la validité au Brésil : la mesure provisoire 2.200-2/2001 (art. 10, § 2) admet la signature électronique sans certificat ICP-Brasil lorsque les parties l'acceptent comme valable, et la loi 14.063/2020 qualifie d'avancée la signature qui utilise un autre moyen de prouver l'auteur et l'intégrité du document. La signature qualifiée, avec certificat ICP-Brasil, est une autre chose (voir « Quand ne pas l'utiliser », plus bas).

Fonctionnement

Le module Digital Signature relie GLPI à Autentique (l'un des quatre fournisseurs du module, avec DocuSeal, DocuSign et TOTVS Assinatura Eletrônica) et regroupe tout dans l'onglet Digital Signature du ticket. À partir d'un document déjà joint, vous préparez l'envoi sans changer de système :

• Envoi direct depuis le ticket — le PDF déjà joint part en signature sans copier de fichiers entre systèmes. Vous pouvez aussi envoyer un modèle de l'entreprise créé dans Word et rempli avec les données du ticket, l'ordre de service (avec le module Order Service ; voir comment générer l'ordre de service en PDF dans le ticket) ou un PDF envoyé sur le moment.
• Plusieurs signataires avec des rôles — utilisateurs GLPI, un groupe entier ou des adresses externes, chacun avec son action : Signer, Approuver, Signer comme témoin, Reconnaître ou Accuser réception.
• Ordre de signature — avec Exiger l'ordre de signature activé pour l'envoi, chaque signataire reçoit son tour dans la séquence définie ; désactivé, tout le monde signe en même temps.
• Suivi en temps réel — le statut de chaque signataire est mis à jour par la notification d'Autentique, sans ouvrir son tableau de bord.
• Lien de signature par WhatsApp — chaque signataire en attente dispose d'un bouton qui ouvre le WhatsApp de la personne qui a cliqué, avec le message et le lien prêts ; si le signataire est un utilisateur GLPI avec un mobile renseigné, la conversation s'ouvre directement avec lui. L'envoi est consigné dans l'historique du document.
• PDF signé dans le ticket — après la dernière signature, le PDF final est joint au ticket et à chaque élément lié, comme l'ordinateur du bon de remise et la fiche de la personne qui a signé.
• Authentification supplémentaire — photo d'une pièce d'identité, CPF du signataire et validation par SMS, selon la criticité du document et la formule du compte Autentique.
• Mode sandbox — un environnement de test pour valider le flux sans facturation.

Envoi en masse avec Autentique

Pour recueillir la signature de nombreuses personnes sur le même document, comme l'acceptation d'une politique par tous les collaborateurs, Autentique prend en charge l'envoi en masse du module : un document individuel pour chaque membre d'un groupe GLPI, avec le nom et le matricule de chacun, plus les signataires fixes qui signent tout, comme les RH. Les documents partent via une file d'attente et le panneau du lot affiche les envoyés, signés, refusés et échecs.

L'envoi en masse exige un webhook opérationnel, avec une notification reçue au cours des 30 derniers jours, et reste désactivé tant qu'une personne autorisée ne l'active pas dans Configuration. Si l'exigence du CPF est activée dans Autentique, il n'est pas disponible.

Comment le module dialogue avec Autentique

L'API d'Autentique est en GraphQL. Lors de l'envoi d'un document, le module construit une mutation équivalente à celle-ci, en joignant le PDF et la liste des signataires avec l'action de chacun :

# L'API d'Autentique est en GraphQL. Lors de l'envoi d'un document du ticket,
# le module construit une mutation comme celle-ci (le PDF est joint à la requête) :
mutation CreateDocument($document: DocumentInput!, $signers: [SignerInput!]!, $file: Upload!, $sandbox: Boolean) {
  createDocument(document: $document, signers: $signers, file: $file, sandbox: $sandbox) {
    id
    name
    signatures {
      public_id
      email
      action { name }
    }
  }
}

# Variables, construites à partir de l'onglet Digital Signature du ticket :
# {
#   "document": { "name": "Contrat de prestation de services - Ticket #1042" },
#   "signers":  [
#     { "email": "[email protected]", "action": "SIGN"    },
#     { "email": "[email protected]",  "action": "APPROVE" }
#   ],
#   "sandbox":  false
# }

Le champ action correspond directement aux rôles choisis dans l'onglet : SIGN (Signer), APPROVE (Approuver), SIGN_AS_A_WITNESS (Signer comme témoin), RECOGNIZE (Reconnaître) et ACKNOWLEDGE_RECEIPT (Accuser réception). Le public_id renvoyé pour chaque signature est l'identifiant qui rattache le signataire au document dans GLPI. Un détail qui nous a coûté du temps : l'envoi par courriel ne renvoie pas le lien de signature. Quand quelqu'un clique sur Copier le lien ou sur le bouton WhatsApp, le module demande à Autentique le lien de ce signataire (createLinkToSignature).

Le webhook, et ce que nous avons appris en assurant le support

L'envoi n'est que la moitié du travail. La pièce qui assure la traçabilité est le webhook : à chaque événement (signé, consulté, refusé), Autentique envoie un POST à GLPI et l'onglet du ticket se met à jour tout seul. En exploitant cela pour des clients, quelques détails nous ont déjà coûté du diagnostic :

• L'erreur la plus fréquente n'est pas dans GLPI, mais dans Autentique. Si vous oubliez de déclarer l'URL du webhook dans le tableau de bord d'Autentique, le document est envoyé et signé normalement, mais le statut ne revient jamais. Aujourd'hui, l'onglet Intégrations affiche, sous l'URL du webhook, la date de la dernière notification reçue et le motif de la dernière notification refusée : après la déclaration, envoyez un document de test et signez-le.
• Le secret va dans le tableau de bord, pas dans l'URL. Autentique signe chaque notification avec HMAC dans l'en-tête X-Autentique-Signature ; le même secret doit figurer dans le tableau de bord d'Autentique et dans le champ Secret du webhook de GLPI. Un secret collé dans l'URL est refusé par défaut, car l'URL finit dans les journaux.
• Les notifications arrivent en rafale. À la finalisation d'un document, trois notifications arrivent en quelques secondes. Le module verrouille le document pendant le traitement et relit son état avant d'enregistrer, pour que le PDF signé ne soit joint qu'une seule fois.
• Entité du document. Le PDF signé est enregistré dans l'entité de la fiche de signature, la même que l'élément d'où est parti l'envoi, et joint au ticket et aux éléments liés.

Ce webhook, c'est Autentique qui notifie GLPI. Les webhooks natifs de GLPI 11 font le chemin inverse, de GLPI vers d'autres systèmes : voir comment configurer les webhooks natifs de GLPI 11.

Et avant le passage en production, nous vérifions toujours que le sandbox est désactivé. D'après la documentation des tarifs de l'API d'Autentique, les documents créés en sandbox ne sont pas facturés, mais ne servent qu'aux tests : ils sont supprimés automatiquement au bout de quelques jours et ne génèrent aucun enregistrement d'audit. Laisser le sandbox activé donne l'impression que tout fonctionne jusqu'au jour où quelqu'un a besoin du document avec sa valeur.

Comment l'activer

1. Souscrivez le fournisseur Autentique dans l'espace client du portail : le produit Digital Signature (Autentique) inclut déjà le module.
2. Installez ou mettez à jour NexTool sur votre GLPI 11 ou 12 et activez le module Digital Signature.
3. Dans l'onglet Intégrations, section Autentique, saisissez le jeton de l'API d'Autentique et le secret du webhook, puis utilisez Tester : la réponse indique le compte, l'organisation et les crédits.
4. Déclarez l'URL du webhook dans le tableau de bord d'Autentique, avec le même secret.
5. Faites passer un document de bout en bout en mode sandbox, désactivez le sandbox et passez en production.

Pour qui — et quand ne pas l'utiliser

Le module s'adresse aux services informatiques et aux équipes opérationnelles qui gèrent des contrats de prestation, des conditions d'utilisation de systèmes, des autorisations d'accès et tout document nécessitant une signature à valeur probante — en particulier à ceux qui utilisent déjà Autentique et veulent supprimer le décalage entre la signature et le ticket qui l'a fait naître.

Quand ne pas l'utiliser :

• Si vous avez seulement besoin d'une signature à l'écran lors d'une intervention sur place, sans plateforme externe ni coût par document, la signature à l'écran du module Order Service convient mieux.
• Si le document exige une signature qualifiée avec certificat ICP-Brasil (A1/A3) — certains actes réglementés l'exigent — une signature sans certificat peut ne pas suffire ; vérifiez d'abord l'exigence légale. Avec une formule payante d'Autentique, le module peut aussi exiger que les signataires signent avec un certificat ICP-Brasil.
• Si votre entreprise a standardisé un autre fournisseur, vérifiez s'il fait partie de ceux que le module prend aussi en charge (DocuSeal, DocuSign et TOTVS Assinatura Eletrônica) ; en dehors d'eux, le module ne s'applique pas.
• Si le document ne naît d'aucun enregistrement de GLPI (ticket, contrat, actif, fournisseur et autres), l'intégration n'apporte pas la traçabilité qui fait sa principale valeur.

Compatibilité

• GLPI : 11 et 12
• Formule : Sous licence, avec le produit Digital Signature (Autentique)
• Plugin : NexTool 6.35.0 ou supérieur

Prochaine étape

Autentique est l'un des fournisseurs du module Digital Signature, qui fait partie de NexTool, un écosystème de modules pour étendre GLPI sans développement spécifique. Prenez rendez-vous pour une démonstration adaptée à votre cas.

Sources : documentation de l'API d'Autentique, tarifs et sandbox, mesure provisoire 2.200-2/2001 et loi 14.063/2020. GLPI est une marque déposée de Teclib'. NexTool n'est pas affiliée à Teclib'. Autentique est une marque de son titulaire.

Revu par l'équipe NexTool Solutions. Les captures d'écran proviennent de GLPI avec le plugin NexTool, avec des données fictives.