Chatbot dans Telegram pour recevoir et acheminer les demandes d'incidents avec intégration de Jira Service Management et SSO

Situation de départ : le service informatique interne de l’entreprise reçoit les demandes des salariés via le chat général et l’email. De ce fait, les détails sont perdus, les candidatures sont dupliquées et il n’existe pas de statistiques uniformes. Il existe Jira Service Management (Cloud) en tant que Service Desk, l'authentification des employés via le SSO d'entreprise (Azure AD). Nous voulons que les employés créent des demandes via un bot Telegram, et les demandes seront automatiquement incluses dans JSM avec la catégorie, la priorité et le routage corrects.

Environnement technique et limitations : API Telegram Bot. API REST Jira Service Management Cloud. Azure AD pour vérifier l’appartenance au domaine utilisateur. Déploiement en Docker dans notre infrastructure (Linux VM). Restriction : le bot ne doit pas disposer d'un stockage permanent de données personnelles ; il est autorisé de stocker un ensemble minimum (identifiant utilisateur Telegram, identifiant de hachage d'employé, jetons uniquement sous forme cryptée ou pas du tout). Les journaux ne doivent contenir aucun contenu de requête (uniquement des événements techniques et des identifiants). Le langage de communication du bot est RU.

Ce que le bot doit faire : 1) Autorisation - l'utilisateur associe Telegram à un compte d'entreprise via un flux sécurisé : le bot émet un lien vers un jeton de courte durée, l'utilisateur se connecte à Azure AD, après quoi le bot reçoit une confirmation et autorise le travail. 2) Création d'une demande - la boîte de dialogue collecte les champs obligatoires : type de demande (incident, accès, équipement, logiciel), brève description, détails, criticité, service concerné dans la liste, pièces jointes (captures d'écran). 3) Classification automatique - basée sur des mots-clés/modèles (tableau de règles personnalisable) suggère une catégorie/composant et une file d'attente (type de demande) dans JSM, l'utilisateur confirme ou modifie. 4) Création d'un ticket dans JSM - crée une demande avec les champs personnalisés nécessaires, joint des fichiers, renvoie un numéro et un lien. 5) Statut et commentaires - sur commande affiche les 5 dernières demandes des utilisateurs, la statistique actuelle
nous, pouvons envoyer un commentaire à un ticket et recevoir des notifications sur les changements de statut/commentaires dans Telegram (webhook de JSM ou interrogation périodique avec déduplication). 6) Anti-doublons - avant de créer un ticket, le bot effectue une recherche rapide des demandes d'utilisateurs ouvertes similaires au cours des 7 derniers jours (par mots-clés/service) et propose de créer un lien vers une demande existante.
Résultat attendu : un référentiel avec le code source (de préférence Python 3.11+ ou Node.js 20+), Dockerfile et docker-compose pour le lancement, la configuration via des variables d'environnement, la migration/initialisation des règles de classification, les instructions d'installation et d'exploitation (RU), un ensemble minimum d'autotests pour les scénarios clés, le mode Telegram du webhook configuré.

Critères d'acceptation (mesurables) : 1) Un nouvel utilisateur sans lien ne peut pas créer d'applications, mais après autorisation réussie, il le peut. 2) La création d'un incident avec une pièce jointe entraîne l'apparition d'une requête dans JSM avec des champs remplis et un fichier joint, le bot renvoie la bonne clé de requête. 3) La notification d'un changement de statut dans JSM arrive dans Telegram au plus tard 2 minutes (dans un environnement de test). 4) Les journaux ne contiennent pas le texte des demandes et les données personnelles à l'exception des identifiants techniques. 5) Le redémarrage du conteneur n'interrompt pas le fonctionnement du bot et ne nécessite pas d'actions manuelles pour restaurer le webhook/les abonnements.

Pas à pas : d'abord un prototype du dialogue et création d'un ticket, puis la liaison SSO, puis les notifications et commentaires, puis les anti-doublons et règles de classification, puis le packaging dans Docker et la documentation.

Accès : nous fournirons un projet de test JSM, un enregistrement d'application de test Azure AD, un jeton de bot Telegram et une liste de champs/files d'attente JSM.