La signature papier reste exigée sur de nombreux bons d'intervention et engagements de responsabilité. Le module SignaturePad de NexTool intègre cette étape dans GLPI : l'utilisateur signe à la souris ou au toucher, le système appose la signature sur le PDF et archive le document signé lié au ticket, sans imprimer, numériser ni quitter le flux de support.
Le problème
Les équipes de centre de services qui émettent des bons d'intervention rencontrent toujours le même goulot au moment de recueillir une signature : générer le PDF, l'imprimer, signer sur papier, numériser et archiver. Chaque étape manuelle est un point de défaillance - un document égaré, un scan de travers, un fichier enregistré sur le bureau du technicien et déconnecté du ticket qui l'a produit. En support à distance, la signature physique n'a tout simplement pas lieu, et le client ne peut pas signer sans certificat numérique ni logiciel supplémentaire.
Résultat : une lacune d'audit. Le ticket est clos, mais la preuve de la prestation vit en dehors de GLPI. Quand quelqu'un a besoin du bon signé des mois plus tard, la chasse au fichier commence.
Comment fonctionne SignaturePad
Tout le flux se déroule dans GLPI, sans dépendance externe :
- PDF de base configurable - l'administrateur téléverse le modèle de PDF dans la configuration du module ; il est stocké comme Document natif de GLPI.
- Capture par canvas - sur la page de signature, l'utilisateur signe à la souris sur ordinateur ou au doigt sur tablette et mobile, sans rien installer.
- Apposition automatique - le système appose la signature capturée sur la dernière page du PDF via FPDI + TCPDF, générant un nouveau fichier.
- Archivage lié - le PDF signé est enregistré comme Document et lié au document source par une relation native, préservant la traçabilité.
- Accès contrôlé - la page de signature exige une connexion GLPI, le signataire est donc un utilisateur identifié dans le système.
Combiné au module OrderService, le bouton Signer le PDF apparaît directement dans l'onglet Bon d'intervention du ticket. Après signature, le document est joint au ticket via Document_Item automatiquement, sans aucune étape manuelle.
En pratique, le technicien termine l'intervention, recueille la signature sur place - avec le client présent ou via un lien envoyé - et le ticket est clos avec la preuve déjà jointe. Pas de PDF isolé dans un e-mail ou perdu dans un dossier réseau que personne ne retrouve ensuite.
Le gain est net pour les équipes travaillant avec des SLA terrain : la signature au moment de la livraison sert de jalon d'acceptation, et comme le document reste rattaché au ticket, tout audit ultérieur retrouve la preuve sans dépendre de la mémoire de celui qui a traité l'appel.
SignaturePad vs GLPI natif
| Besoin | GLPI natif | Avec SignaturePad |
|---|---|---|
| Signature manuscrite sur le ticket | N'existe pas | Canvas à la souris ou au toucher |
| Apposition de la signature sur le PDF | Manuelle, hors GLPI | Automatique (FPDI + TCPDF) |
| Lien du document au ticket | Pièce jointe manuelle | Document_Item automatique |
| Signature en support à distance | Impossible | Lien interne de signature |
| Traçabilité et audit | Dépend de la rigueur du technicien | Document toujours sur le ticket |
Comment l'activer
- Installez le plugin NexTool dans votre GLPI.
- Accédez à Configuration > NexTool > Modules.
- Activez le module Signature Manuscrite (PDF) et cliquez sur Configurer.
- Téléversez le PDF de base et définissez la catégorie du document généré.
- Pour l'intégration aux bons d'intervention, activez aussi le module OrderService et activez Intégration au Bon d'intervention dans la configuration de SignaturePad.
Comment confirmer que le document est bien lié
Après une signature de test, une requête simple confirme que le PDF signé est bien joint au ticket - pratique pour valider le déploiement :
-- Documents liés à un ticket (remplacez 12345 par l'ID du ticket)
SELECT d.id, d.filename, di.itemtype, di.items_id
FROM glpi_documents_items di
JOIN glpi_documents d ON d.id = di.documents_id
WHERE di.itemtype = 'Ticket'
AND di.items_id = 12345;Le détail qui n'apparaît qu'en maintenance
En déploiement chez des clients multi-entités, l'erreur la plus fréquente n'est pas dans la capture de la signature, mais dans le lien. GLPI exige que le Document ait la même entities_id que le ticket pour que le Document_Item soit accepté et que la pièce jointe s'affiche dans l'onglet. Quand le PDF signé est généré dans une entité différente de celle du ticket (par héritage de configuration du module), le fichier est créé mais disparaît de la vue du technicien, comme si la signature avait échoué. La règle que nous vérifions désormais à chaque déploiement : confirmer que la catégorie et l'entité du document généré suivent l'entité du ticket. C'est un détail de configuration, pas de code, et cela résout la « disparition » du premier coup.
Pour qui (et quand ne pas l'utiliser)
SignaturePad convient aux équipes qui émettent des bons d'intervention et ont besoin de l'acceptation du client ou du technicien, à ceux qui veulent supprimer le cycle imprimer-signer-numériser-archiver et aux organisations exigeant une piste auditable avec le document signé toujours joint au ticket.
Ce n'est pas le bon outil quand l'exigence est une signature à valeur juridique pleine sous une PKI nationale ou un certificat numérique : SignaturePad capture la signature manuscrite et la lie à l'enregistrement GLPI (qui, quand, quel ticket), ce qui est solide comme preuve interne et acceptation opérationnelle, mais ne remplace pas une signature qualifiée. Pour ce scénario, intégrez une plateforme de signature électronique dédiée.
Compatibilité
- GLPI : 10.x et 11.x
- Plan : Sur demande (PAID)
- Plugin : NexTool 3.x+
Prochaine étape
SignaturePad fait partie de NexTool, le plugin modulaire pour GLPI. Pour le flux complet de bon d'intervention avec signature, combinez-le au module OrderService. Envie de le voir fonctionner dans votre environnement ? Contactez l'équipe.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.
