NexTool Solutions

Les documents à signer circulent encore par e-mail et WhatsApp - sans traçabilité, sans statut connu et totalement déconnectés des tickets qui les ont fait naître. Le module Autentique de NexTool ramène ce flux à l'intérieur de GLPI.

Le problème

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

GLPI natif face au module 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 est excellent pour joindre et versionner des fichiers, mais la signature électronique n'a jamais fait partie de son périmètre :

Comment ça marche

Le module Autentique intègre GLPI à la plateforme de signature numérique Autentique et concentre tout dans un onglet Signature numérique à l'intérieur du ticket. À partir d'un document déjà joint, vous montez l'enveloppe de signature sans changer de système :

• Envoi direct depuis le ticket - le PDF déjà joint part à la signature sans copier de fichiers entre systèmes.
• Plusieurs signataires avec rôles - ajoutez-en autant que nécessaire avec des actions distinctes : Signer, Approuver, Témoigner, Reconnaître ou Accuser réception.
• Ordre de signature - définissez si les signataires signent en séquence ou simultanément, selon le processus de l'organisation.
• Suivi en temps réel - le statut de chaque signataire est mis à jour par webhook, sans consulter le tableau de bord Autentique.
• Téléchargement du document signé - après la dernière signature, le PDF final est disponible sur le ticket lui-même.
• Authentification supplémentaire - validation par SMS, selfie et autres méthodes selon la criticité du document.
• Mode sandbox - un environnement de test pour valider le flux sans générer de facturation sur la plateforme.

Comment le module dialogue avec Autentique

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

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

# Variables, construites à partir de l'onglet Signature numérique du ticket :
# {
#   "doc":     { "name": "Contrat de prestation de services - Ticket #1042" },
#   "signers": [
#     { "email": "client@entreprise.com", "action": "SIGN"    },
#     { "email": "manager@nextool.com",   "action": "APPROVE" }
#   ]
# }

Le champ action correspond directement aux rôles choisis dans l'onglet : SIGN (Signer), APPROVE (Approuver), SIGN_AS_A_WITNESS (Témoigner), RECOGNIZE (Reconnaître) et ACKNOWLEDGE (Accuser réception). Le public_id renvoyé pour chaque signature est l'identifiant qui relie le signataire au ticket dans les événements suivants.

Le webhook, et ce que l'exploitation nous a appris

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

• L'erreur la plus courante n'est pas dans GLPI, elle est dans Autentique. Qui oublie d'enregistrer l'URL du webhook dans le tableau de bord de la plateforme voit le document s'envoyer et se signer normalement, mais le statut ne revient jamais - et le ticket qui arrive au support est "pourquoi GLPI ne montre-t-il pas que c'est signé ?".
• Les webhooks se répètent. Si Autentique ne reçoit pas un 200 rapide, il renvoie le même événement. Sans idempotence, le même "signé" entre deux fois dans l'historique. C'est pourquoi le traitement identifie l'événement par le public_id de la signature, et non par l'ordre d'arrivée.
• Entité du document. En réécrivant le PDF signé dans un ticket qui vit dans une sous-entité, GLPI exige que le document appartienne à la même entité que le ticket ; sinon le lien Document_Item échoue en silence et le fichier "se signe, mais disparaît". Le module hérite de l'entité du ticket lorsqu'il enregistre le document final.

Et, avant de passer en production, nous confirmons toujours que le sandbox est désactivé. Le laisser actif fait accepter le flux par la plateforme sans produire de signature à valeur réelle - le pire type de faux positif dans un processus juridique, car tout semble fonctionner jusqu'à ce que quelqu'un ait besoin du document opposable.

Comment l'activer

1. Installez ou mettez à jour NexTool sur votre GLPI (10 ou 11).
2. Allez dans Configuration > NexTool > Modules.
3. Activez Autentique et cliquez sur Configurer.
4. Renseignez le jeton de l'API Autentique et le secret du webhook.
5. Enregistrez l'URL du webhook dans le tableau de bord Autentique.
6. Faites tourner un document de bout en bout en mode sandbox avant de passer en production.

Pour qui - et quand ne pas l'utiliser

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

Quand ne pas l'utiliser :

• Si vous avez seulement besoin d'un paraphe à l'écran lors d'un service en présentiel, sans plateforme externe ni coût par document, un module de signature manuelle (signature pad) convient mieux.
• Si le document exige une signature qualifiée avec un certificat ICP-Brasil (A1/A3) - certains actes réglementés l'imposent - une signature avancée peut ne pas suffire ; validez l'exigence légale d'abord.
• Si l'entreprise a standardisé une plateforme autre qu'Autentique, le module ne s'applique pas.
• Si le document ne naît pas d'un ticket, l'intégration n'apporte pas la traçabilité qui constitue sa plus grande valeur.

Compatibilité

• GLPI : 10.0+ et 11.0+
• Offre : Sur demande
• Plugin : NexTool 3.x+

Étape suivante

Autentique fait partie de NexTool, un écosystème de modules pour étendre GLPI sans personnalisations de code. Parlez à l'équipe pour une démonstration dans votre contexte.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe NexTool Solutions.