Par où commencer avec l’IA · Premier workflow n° 6

Le tri et le routage des tickets IT

Un assistant de tri des tickets de support interne, introduit en deux étapes : il prépare d’abord le tri pour le technicien, puis oriente seul les demandes standards autorisées.

Un premier usage de l’IA n’a pas besoin d’être spectaculaire. Il doit surtout être suffisamment délimité pour être testé, mesuré et amélioré.

Télécharger la fiche de cadrage (PDF, 2 pages) Voir le carrousel (PDF)

Un faible risque, dans un périmètre strict seulement

Les tickets de support interne réunissent les quatre critères d’un bon premier workflow : ils sont répétés souvent, ont un porteur clair, appellent un livrable net — un ticket bien classé et attribué — et constituent un irritant déjà ressenti, côté support comme côté collaborateurs.

Le cas n’est à faible risque que dans un périmètre strict :

un catalogue de services écrit catégories, priorités et équipes à jour ;
aucun droit d’administration ni action sur un compte confiée à l’IA ;
mots de passe et accès standards par les parcours sécurisés existants ;
les incidents, cas de sécurité ou ambigus transmis aux techniciens.

L’assistant s’appuie sur un catalogue de services et une base de connaissances que l’entreprise possède déjà. Le risque ne disparaît pas. Il devient plus visible, mesurable et gouvernable lorsque les catégories, le périmètre et les règles de transmission sont définis.

Une démarche en trois temps

Préparer le catalogue

Clarifier catégories, matrice de priorité et équipes, retirer les articles périmés, attribuer un propriétaire à chaque article et dater sa version. L’outil vient ensuite.

L’assistant prépare le tri, le technicien décide

L’assistant propose une catégorie, une priorité calculée par la matrice, une équipe et l’article de la base de connaissances qui s’applique. Le technicien confirme, corrige ou réattribue. Chaque correction est notée, catégorie par catégorie.

L’assistant oriente les demandes standards

Il oriente seul les tickets d’une catégorie autorisée vers l’équipe prévue, ou répond avec un article à jour et le lien vers le parcours libre-service sécurisé. Il transmet aux techniciens les incidents, les demandes urgentes ou ambiguës, les cas de sécurité et les accès à privilèges.

Passer de l’étape 1 à l’étape 2

Le passage à l’étape 2 ne devrait pas être décidé à l’avance. Il dépend de ce que le support observe durant l’étape 1 : la justesse du tri proposé, les corrections nécessaires et la capacité du système à reconnaître les tickets qui sortent de son périmètre.

justesse du tri et de l’article citéréattributions nécessaires, par catégorietransmission correcte des exceptionsaucun incident significatif sur le périmètre testédes articles à jour, chacun avec un propriétaire

Les demandes d’imprimante peuvent passer à l’étape 2 pendant que les accès applicatifs restent à l’étape 1.

Architecture de référence : comment le dispositif reste contrôlé

Classification du ticket avec score de confiance, priorité calculée par une matrice de règles fixes, recherche hybride dans les articles, proposition par un LLM instruit de citer l’article retenu, garde-fous d’entrée et de sortie avec transmission aux techniciens. Aucune action sur un compte. Une boucle d’apprentissage relie le journal, la revue du support et le jeu d’évaluation.

Cliquer sur le schéma pour l’ouvrir en grand.

Les contrôles nécessaires avant toute réponse autonome :

Évaluation. Jeu de référence d’environ 300 tickets passés, minimisés, avec catégorie, équipe et priorité attendues. Métriques : justesse du tri, taux de réattribution, article cité correct, taux de détection et de bonne transmission des exceptions. Rejoué à chaque changement de modèle, de catalogue ou de consignes.

Observabilité. Chaque ticket traité journalisé : catégorie, priorité, article proposé, score de confiance, décision de routage. Les tickets pouvant contenir des données personnelles ou des secrets, le journal est minimisé, accessible aux seules personnes autorisées et conservé pour une durée définie.

Identité et droits. SSO (SAML ou OIDC). L’assistant n’a aucun droit d’administration : réinitialisations et accès passent par les parcours existants, MFA et approbations comprises.

Données. Hébergement et transferts de données vérifiés selon la solution retenue ; conditions contractuelles de non-utilisation des données pour l’entraînement ; chiffrement ; durée de conservation et accès au journal définis ; analyse nLPD documentée avant le lancement.

Sécurité applicative. Mesures contre l’injection de prompt dans les tickets ; pièces jointes analysées, le cas échéant, dans un environnement isolé. Quatre issues : proposer, orienter, répondre par un article ou transmettre ; aucune commande sur un système.

Les corrections servent d’abord à améliorer les articles, les règles, les consignes et le jeu d’évaluation. Le réentraînement du modèle n’est ni le point de départ ni un substitut à ce travail.

Ce que l’on cherche

L’objectif n’est pas de remplacer les techniciens. Il est de réduire le délai de prise en charge des demandes simples, d’éviter que les mêmes tickets soient triés et réattribués à la main et de consacrer le temps du support aux incidents qui demandent du diagnostic et un jugement.

Télécharger la fiche de cadrage (PDF) Voir le carrousel (PDF)

Cas illustratif : société fictive, chiffres donnés comme ordres de grandeur. Sergio Castagna Consulting est membre de l’OpenAI Partner Network et partenaire enregistré du Google Cloud Partner Network ; le choix d’un outil intervient après le choix du problème.