IA dans l’ITSM : ce que les projets menés trop vite disent de la DSI

Quand l’outil rencontre le terrain

Un assistant branché sur une base de connaissances qui n’a pas été révisée depuis la dernière migration fournit des réponses formulées avec aplomb et pourtant erronées, ce que les agents du support découvrent assez vite. Ils relisent chaque suggestion, la corrigent parfois, et le temps censé être gagné part dans cette vérification permanente. Certains finissent par ne plus ouvrir le panneau de suggestions.

Les projets pilotes y sont pour beaucoup; on les lance sur un périmètre restreint, avec des articles retravaillés à la main par deux ou trois personnes motivées, puis on généralise à tous les sites en supposant que les résultats suivront, alors que les conditions de départ n’existent plus.

Trois zones de fragilité

Des données qui reposaient sur des arrangements tacites

Chaque site range ses tickets à sa façon ; la CMDB oublie une partie du parc, des procédures citent des serveurs qui n’existent plus. Les équipes compensaient ces défauts sans y penser. Un modèle, lui, ne devine pas ce qu’un technicien expérimenté savait contourner.

Qui répond d’une décision préparée par une machine

Un agent automatisé propose une modification sur un environnement de production : à qui revient la validation, et selon quelle règle ? Les comités de gestion des changements n’ont souvent pas tranché. Les enjeux de sécurité, de conformité et de fiabilité sont examinés plus en détail dans cet article sur les risques liés à l’IA dans l’ITSM, utile pour mesurer l’écart entre la vitesse d’adoption et la solidité de ce qui la supporte.

Une réversibilité rarement négociée

Si le routage des incidents repose sur un modèle propriétaire, sortir de l’outil suppose de récupérer les paramètres d’apprentissage et l’historique des décisions. Très peu de contrats le prévoient, et la question n’apparaît qu’au moment de renégocier.

Ce que font les équipes qui s’en sortent

Elles ne disposent pas de budgets exceptionnels. Elles ont plutôt accepté de commencer lentement, et on retrouve chez elles des pratiques voisines :

1. un audit préalable des contenus (doublons, articles périmés, champs vides, absence de propriétaire pour chaque rubrique) ;
2. des cas d’usage modestes au départ, comme la catégorisation des demandes entrantes ou la recherche documentaire, avant toute action automatique ;
3. une validation humaine pour tout ce qui touche la production, avec un journal de ce que l’IA a suggéré et de ce qui a été retenu ;
4. des indicateurs qui disent quelque chose de la qualité, par exemple la part de suggestions acceptées sans retouche ou le nombre de tickets rouverts, plutôt que le seul nombre de demandes traitées.

Un enjeu qui déborde le service desk

Le service desk sert souvent de laboratoire à l’IA en entreprise, car les volumes sont importants et les processus déjà écrits. Ce qui s’y passe annonce ce qui se produira ailleurs : données mal tenues, décisions sans propriétaire, dépendance à un fournisseur découverte trop tard. La façon dont une DSI encadre l’IA chez elle donne une bonne idée de ce qu’elle pourra proposer aux métiers, et c’est probablement là que l’écart se creusera dans les prochaines années, entre celles qui savent expliquer ce que leur IA a décidé et celles qui en sont incapables.