WhatsApp est le canal que votre utilisateur ouvre des dizaines de fois par jour - et GLPI, par défaut, ne sait parler que par e-mail. Le module WhatsApp Bot de NexTool relie GLPI à l'Evolution API (open source, protocole Baileys) et livre la notification de ticket directement sur WhatsApp, avec une file qui retraite les échecs et une connexion sur votre propre infrastructure. Maintenir des centres de services nous a appris que le bon canal change le taux de réponse des validations et des enquêtes de satisfaction - mais l'intégration comporte des pièges de configuration que ce guide montre en coulisses.
Le problème
GLPI notifie par e-mail transactionnel via la file queuednotification. Ça marche, mais l'e-mail d'entreprise tombe dans les spams, l'utilisateur final ne vit pas dans sa messagerie, et le responsable qui doit valider un ticket ne le découvre que lorsque quelqu'un appelle pour relancer. Le résultat au quotidien : des validations bloquées des heures, des enquêtes de satisfaction au taux de réponse proche de zéro et une équipe de support qui passe son temps à relancer manuellement. Remplacer l'e-mail par un canal que les gens lisent vraiment résout l'essentiel - et au Brésil ce canal est WhatsApp.
La voie commerciale (l'API WhatsApp Business officielle) est coûteuse, dépend de la validation des modèles par Meta et vous lie à un contrat externe. Pour qui exploite déjà sa propre infrastructure, l'Evolution API est l'alternative auto-hébergée, et WhatsApp Bot la relie à GLPI en utilisant l'infrastructure native de notifications - sans bidouille dans le cœur.
Comment fonctionne WhatsApp Bot
Le module enregistre son propre mode de notification en réutilisant le canal SMS de GLPI (Notification_NotificationTemplate::registerMode(MODE_SMS)). Quand un événement de ticket se déclenche, GLPI résout le destinataire, le module récupère le numéro, construit le message et l'envoie via l'Evolution API - de façon transparente pour l'opérateur.
- Ses propres notifications par événement - à l'installation, le module crée neuf notifications WhatsApp dédiées (Nouveau ticket, Nouveau suivi, Ticket résolu, Enquête de satisfaction, Demande de validation, Réponse de validation et les trois de mot de passe), chacune avec ses propres destinataires. La création est idempotente par nom : si vous modifiez le texte dans l'interface GLPI, une réinstallation préserve votre édition.
- File avec réessai automatique - un message qui échoue à cause de l'instabilité de la connexion entre dans la table de file et est retraité par lots de 50 maximum toutes les 1 minute, avec au plus 3 tentatives avant d'être marqué
failed. Rien ne disparaît en silence : la raison de l'erreur est enregistrée. - Health check toutes les 5 minutes - une tâche cron interroge l'état réel de la connexion sur l'Evolution API et met à jour le statut dans le panneau, pour que vous sachiez que WhatsApp est tombé avant que l'utilisateur ne se plaigne.
- QR Code dans GLPI - le numéro expéditeur est connecté en scannant le QR généré dans l'onglet Connecteurs, sans quitter l'environnement.
- Auto-hébergé ou géré - pointez vers votre propre Evolution API (URL + clé API) ou, en environnement sous licence, utilisez l'instance gérée par NexTool.
Le numéro du destinataire provient du champ Téléphone portable de l'utilisateur GLPI (glpi_users.mobile), normalisé automatiquement : le module retire le formatage, valide la longueur (10 à 15 chiffres) et préfixe l'indicatif 55 quand un numéro brésilien arrive sans lui. Qui n'a pas de portable enregistré ne reçoit tout simplement rien - l'envoi est silencieux, il ne lève pas d'erreur.
WhatsApp Bot face à la notification native de GLPI
| Fonction | GLPI natif (e-mail SMTP) | WhatsApp Bot + Evolution API |
|---|---|---|
| Canal de livraison | E-mail transactionnel | WhatsApp (message sur le téléphone) |
| Taux de lecture | Faible (spam, personne n'ouvre) | Élevé (canal du quotidien) |
| Renvoi en cas d'échec | File, sans réessai réglable par canal | File propre, 3 tentatives, lots de 50/min |
| Origine du numéro | E-mail de l'utilisateur | Champ Portable (glpi_users.mobile), normalisé |
| Infrastructure | Serveur SMTP | Evolution API auto-hébergée ou gérée |
| Coût par message | Zéro (SMTP propre) | Zéro (pas d'API Meta payante) |
Comment l'activer
- Installez NexTool sur votre GLPI et allez dans Configuration > NexTool > Modules.
- Activez le module WhatsApp Bot et cliquez sur Configurer.
- Dans l'onglet Connecteurs, saisissez l'URL et la clé API de votre Evolution API et générez le QR Code pour connecter le numéro expéditeur.
- Dans Administration > Utilisateurs, remplissez le champ Téléphone portable des destinataires (indicatif+région+numéro, ex. : 5511999998888).
- Vérifiez que le cron externe de GLPI tourne - les CronTasks du module sont
MODE_EXTERNALet ne se déclenchent pas au fil des accès web.
# Les CronTasks du module (healthcheck 5min, file 1min) sont MODE_EXTERNAL.
# Sur GLPI 11 le declencheur est front/cron.php (pas de console glpi:cron):
* * * * * www-data /usr/bin/php /var/www/html/front/cron.php >/dev/null 2>&1
# L'Evolution API recoit l'envoi sur cet endpoint (le module s'en charge):
# POST {URL}/message/sendText/{instance}
# header: apikey: ...votre_cle_api...
# body: { "number": "5511999998888", "text": "..." }
Diagnostic de livraison directement en base
Quand un client dit « le WhatsApp n'est pas arrivé », la réponse est presque toujours dans la table de file. Deux requêtes règlent le tri :
-- Vue d'ensemble de la file : ce qui est bloque et combien de tentatives
SELECT status, COUNT(*) AS total, MAX(attempts) AS max_tentatives
FROM glpi_plugin_nextool_whatsappbot_queue
GROUP BY status;
-- Derniers echecs avec la raison renvoyee par l'Evolution API
SELECT id, phone_number, attempts, last_error, created_at
FROM glpi_plugin_nextool_whatsappbot_queue
WHERE status = 'failed'
ORDER BY created_at DESC
LIMIT 20;
L'erreur la plus fréquente que l'on lit dans last_error n'est pas un bug du module : c'est un numéro mal formaté ou la connexion de l'instance tombée. C'est pourquoi le health check existe - si le statut du panneau affiche déconnecté, le QR a expiré et doit être rescanné.
Le piège que seuls les exploitants connaissent
Deux pièges cassent presque tout premier déploiement. Premier : le canal WhatsApp Bot emprunte le mode SMS de GLPI. Cela signifie que, pour que l'utilisateur reçoive, le « suivre par SMS » doit être actif sur la notification - beaucoup cherchent un mode nommé « WhatsApp » sur l'écran des notifications et ne le trouvent pas, car il apparaît en SMS. Deuxième : GLPI ajoute la signature d'e-mail par défaut (« -- » et le pied de page) au corps du modèle, et sur WhatsApp cela devient du bruit visuel ; le module retire ce bloc à l'envoi, mais si vous créez votre propre modèle, évitez d'y déverser des variables de signature d'e-mail. Et rappelez-vous : comme le numéro provient de glpi_users.mobile, un portable mal saisi est la cause numéro un du « je n'ai rien reçu » - nous normalisons l'indicatif, mais nous ne devinons pas un chiffre inversé.
Pour qui (et quand ne pas l'utiliser)
WhatsApp Bot brille là où l'utilisateur final ne suit pas l'e-mail : commerce, santé, éducation, services et tout centre de services qui sert un public externe. Il est aussi excellent pour les validations de responsables qui se connectent rarement à GLPI. Quand ne pas l'utiliser : si votre exploitation est 100% interne, avec des techniciens qui vivent connectés à GLPI, une cloche de notification in-app convient mieux et ne dépend pas d'une instance WhatsApp. Et si la politique de l'entreprise interdit WhatsApp pour la communication professionnelle, respectez-la - le bon canal est celui que l'équipe peut réellement utiliser.
Compatibilité
- GLPI : 10.0+ et 11.0+
- Offre : FREE
- Plugin : NexTool 4.2.1+
- Prérequis : Evolution API installée et accessible par le serveur GLPI
Étape suivante
WhatsApp Bot fait partie de NexTool. Besoin d'aide pour monter l'Evolution API ou calibrer les événements à notifier par WhatsApp ? Parlez à l'équipe.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.