Pré-diagnostic des tickets
Pour chaque nouveau ticket, FirstSI vérifie le compte, le poste, les autres tickets et ce qui dépend du type de demande, puis dépose une note privée et propose une catégorie.
Quand un ticket arrive, le pré-diagnostic fait avant le technicien tout ce qui peut se vérifier : le compte de la personne, son poste, ses autres tickets, puis les contrôles liés au type de demande (Wi-Fi du site, VPN, imprimante, Microsoft 365, ligne mobile…). Il dépose le résultat en suivi privé dans le ticket et peut proposer une catégorie.
Comment ça marche
FirstSI relève les nouveaux tickets de l'outil de tickets (GLPI aujourd'hui), à intervalle régulier ou dès qu'un webhook le prévient. Il donne au ticket un type d'après ses mots-clés, ceux du titre comptant double, ou d'après la catégorie déjà posée ; l'IA ne tranche qu'en dernier recours.
Viennent ensuite les vérifications. Le socle vaut pour tous les types : compte de la personne, poste, autres tickets du demandeur. Chaque type ajoute ses contrôles, par exemple NetDiag et les tunnels pour « Réseau », la passerelle VPN pour « VPN / télétravail », Microsoft 365 pour la messagerie, la ligne ou la box et le standard 3CX pour la téléphonie.
L'IA rédige enfin une synthèse : la piste la plus probable et les faits qui l'appuient. Pour une demande (ajout à un groupe, arrivée d'un collaborateur), elle décrit plutôt ce qu'il faut faire. Le tout part en suivi privé, avec la catégorie si le ticket est encore libre.
Mettre en place
- Déclarez l'outil de tickets comme connecteur, avec un compte en lecture.
- Dans Pré-diagnostics → Réglages, choisissez l'Outil de tickets (connecteur), la fréquence (Toutes les … min), le nombre de Tickets par heure au plus, la plage horaire (De / À), et cochez Analyser automatiquement les nouveaux tickets.
- Restez d'abord en Mode brouillon : rien n'est écrit dans l'outil de tickets, et vous lisez les résultats dans Dernières analyses (30 jours).
- Essayez sur de vrais tickets avec Numéro de ticket puis Analyser ce ticket. C'est de la lecture seule, et ça marche aussi sur un ticket déjà traité.
Passer en publication
Dans Publication dans l'outil de tickets :
- Créez dans l'outil de tickets un compte d'écriture qui ne sert qu'à ça : ajouter des suivis, et modifier la catégorie si vous le permettez. Saisissez son Jeton d'API du compte d'écriture.
- Faites une publication sur un ticket de test avec Publier dans GLPI. FirstSI vérifie que le ticket n'a pas bougé (statut, attribution, prise en compte), puis affiche Transparence vérifiée le ….
- Passez en mode Publication automatique.
Les garde-fous sont stricts. Une seule écriture est autorisée par ticket, le suivi privé. La note part sur un ticket « Nouveau » ou « En cours », jamais sur un ticket en attente, résolu ou clos. La catégorie n'est posée que si le ticket est encore « Nouveau » et sans technicien. FirstSI contrôle l'état du ticket avant et après chaque publication, et coupe la publication automatique au moindre écart (message « ANOMALIE : … »).
Republier ajoute un nouveau suivi « Mise à jour » avec l'analyse du moment ; le précédent reste dans le ticket.
Les types de demande
Le tableau Types de demande et contrôles contient une ligne par type : son nom, ses Mots-clés, les Contrôles à lancer et, si besoin, les catégories de l'outil de tickets qui y mènent. Mettez-y votre vocabulaire : noms d'applications, de sites, abréviations maison.
Les Règles de catégorie (prioritaires) disent « si ce mot apparaît, prendre cette catégorie ». Elles passent avant le choix automatique, dans l'ordre de la liste.
Parmi les types par défaut, Départ d'un collaborateur (« sorti des effectifs », « fin de contrat »…) est traité comme une demande : il liste ce qui est rattaché à la personne, compte Microsoft 365, ligne mobile (retrouvée par son nom quand aucun numéro n'est cité) et articles de la base de connaissances.
Ce que le pré-diagnostic repère en plus
| Situation | Ce que dit la note |
|---|---|
| Réponse par e-mail à un ancien ticket qui porte en fait une autre demande | Le ticket est analysé sur le nouveau message, et la note dit « à traiter comme un nouveau ticket ». Un simple « merci » reste la suite du ticket d'origine |
| Nom à corriger (« mon nom est mal orthographié ») | Sans compte au nom exact, un compte au nom proche est proposé et signalé comme tel |
| Tentative d'arnaque (coordonnées bancaires, paiement ou code réclamés par un site ou un message) | Une alerte en tête de note : la personne ne doit rien saisir ni payer |
| Demande rédigée comme une panne (carte SIM, droits dans un logiciel, matériel commandé) | La note suit le format d'une demande : ce qui est demandé, avant d'exécuter, où et comment |
| Même objet chez un autre demandeur | « À lier » : deux demandeurs différents ne sont jamais proposés à la fusion |
Webhook
Webhook GLPI → Générer l'adresse du webhook, puis copiez l'adresse dans GLPI (Configuration → Webhooks, élément Ticket, événement Nouvel élément, méthode POST). Elle ne s'affiche qu'une fois. Le webhook ne fait que prévenir : FirstSI relit toujours le ticket avec son propre compte, et la relève régulière continue en secours.
Base de connaissances
Si le compte de lecture a accès à la base de connaissances de l'outil de tickets, le contrôle base de connaissances cite les articles dont le titre correspond au ticket, avec un lien. Pour que les liens marchent, renseignez l'Adresse publique du connecteur.
Mesurer : le bilan
Bilan : le bot face à l'équipe compare ce que le pré-diagnostic a proposé et ce que l'équipe a fait : catégories gardées ou corrigées, pistes justes, partielles ou fausses au vu de la solution saisie, tickets restés « Nouveau » après 24 h. Il est calculé chaque lundi pour la semaine passée, ou à la demande avec Calculer (7 derniers jours).
Améliorer les pistes
Le moyen le plus efficace reste les directives de l'IA, avec la portée Pré-diagnostic des tickets : organisation des sites, vocabulaire maison, causes fréquentes.
Source : · Docs FirstSI · mis à jour le 10/10/2026