L'IA dans l'outil de ticketing : ce qu'elle peut prendre en charge au service desk

Que peut prendre en charge une IA dans l’outil de ticketing ?

Un service desk écrit et lit toute la journée : les demandes arrivent incomplètes, des questions similaires reviennent, et la solution figure souvent déjà dans un ancien ticket. C’est là qu’une IA aide :

Tâche	Ce que fait l’IA	Qui décide
Trier	propose catégorie, priorité et groupe compétent	service desk
Repérer les doublons	reconnaît les tickets portant sur le même problème, par exemple lors d’une panne	service desk
Proposer une solution	cherche des solutions adaptées dans les tickets résolus et les manuels	la personne qui traite le ticket
Rédiger une réponse	formule une réponse dans un langage compréhensible	la personne qui traite le ticket
Résumer	résume de longs historiques avant le transfert à un autre groupe	–
Construire la base de connaissances	propose un article de connaissance à partir de solutions récurrentes	les responsables de la base de connaissances

Cela vaut pour les service desks informatiques comme pour les demandes de citoyens, d’assurés ou de médecins adresseurs, dès qu’elles arrivent dans un outil de ticketing.

De quoi l’IA a-t-elle besoin pour cela ?

Pour répondre à une description d’erreur que quelqu’un colle dans la conversation, l’IA n’a besoin d’aucune connexion. Pour tout ce qui exige de connaître les tickets existants, si : l’IA lit l’outil de ticketing par son interface. Jira et YouTrack proposent pour cela des interfaces REST ; d’autres systèmes comme Znuny, qui poursuit l’ancienne OTRS Community Edition, sont aussi accessibles par des interfaces.

Ce qui compte, c’est le compte avec lequel l’IA lit. Dans l’outil de ticketing, chaque groupe ne voit pas tous les tickets, par exemple les incidents liés au personnel ou à la sécurité. Si l’IA lit avec un compte collectif qui voit tout, ses réponses peuvent faire tomber ces barrières. Mieux vaut qu’elle lise avec l’accès de la personne qui pose la question. Droits d’accès pour l’IA avec des documents →

Où sont les limites ?

• Erreurs : l’IA peut proposer une mauvaise solution, surtout pour des problèmes rares. La source de la solution, c’est-à-dire l’ancien ticket ou le passage du manuel, doit être visible pour pouvoir la vérifier.
• Instructions injectées : les tickets viennent de l’extérieur. Un expéditeur peut insérer un texte destiné à pousser l’IA à faire autre chose, par exemple à écrire des informations internes dans la réponse. L’accès en lecture seule et la validation par une personne limitent les dégâts. Instructions manipulées dans les documents →
• Déroulés autonomes : un agent qui attribue, répond ou clôture des tickets sans vérification fait gagner du temps, mais rend les erreurs invisibles. Les actions en écriture doivent passer par une validation humaine.
• Évaluation des collaborateurs : analyser qui résout combien de tickets en combien de temps revient à contrôler la performance. Ce n’est pas le rôle de l’IA au service desk ; les droits de codécision du CSE ou des représentants du personnel s’appliquent de toute façon.

Où l’IA doit-elle fonctionner ?

Les tickets contiennent des noms, des numéros de téléphone, des données sur les appareils et, dans les hôpitaux, parfois des indications sur des patients. Si l’IA fonctionne chez un fournisseur extérieur à votre établissement, ces contenus y partent. Vérifiez où le modèle d’IA effectue ses calculs, si le fournisseur conserve les saisies ou les utilise pour l’entraînement, et si un accord de traitement des données existe.

Comment cela fonctionne-t-il avec basebox ?

La bibliothèque de basebox propose les connecteurs pour Jira et YouTrack (« Tickets et projets ») ainsi que pour Zammad (« Tickets et base de connaissances ») ; le connecteur pour Znuny / OTRS est annoncé (« Bientôt disponible »). Les connecteurs de la bibliothèque sont inclus dans la licence. Pour un autre outil de ticketing doté d’une interface, nous construisons le connecteur à prix forfaitaire ; la conception est gratuite.

Chaque accès se fait avec le propre accès de la personne, un compte de service commun uniquement si vous le souhaitez ; chacun ne voit que ce qu’il a de toute façon le droit de voir dans l’outil de ticketing. Par défaut, basebox ne fait que lire, et chaque appel d’un connecteur figure dans le journal d’audit. basebox rédige aussi des réponses à une description d’erreur sans connexion, lorsque quelqu’un saisit le texte. À partir de novembre 2026, des agents d’IA dans l’App Builder transforment une description en apps à plusieurs étapes ; les actions en écriture ne s’exécutent alors qu’après validation par une personne. Le modèle d’IA dans basebox fonctionne dans notre cloud, au centre de données de Munich-Est, ou sur un serveur dans votre établissement, et vos données n’entraînent aucun modèle.