Comment structurer un projet pilote d’IA en ITSM : maîtriser les risques et déployer l’automatisation par étapes

Aujourd’hui, la quasi-totalité des grandes organisations a lancé au moins un projet pilote d’intelligence artificielle visant à améliorer la gestion des services informatiques. Pourtant, nombre d’entre elles l’abandonnent après quelques mois, faute de résultats à la hauteur des attentes, en attribuant l’échec à la technologie elle-même. Dans la majorité des cas, la véritable cause se situe ailleurs : dans la manière dont le projet a été conçu dès son lancement.

Deux facteurs reviennent systématiquement. Le premier est une ambition excessive, qui pousse les organisations à déployer d’emblée des agents IA capables d’agir de façon autonome alors même que les mécanismes de gouvernance nécessaires pour les encadrer ne sont pas encore en place. Le second est l’absence de cadre structuré et de gouvernance partagée : aucun responsable clairement identifié, aucun indicateur de succès défini avant le démarrage, aucun critère précis permettant de décider de la poursuite ou de l’arrêt de l’initiative.

Cet article présente une méthode pour construire un projet pilote IA en ITSM capable de produire des résultats vérifiables et de générer, dès les premières semaines, des données exploitables pour étayer et valider un business case.

Commencer par des cas d’usage à faible risque

Le choix du cas d’usage constitue l’un des principaux facteurs de réussite d’un projet pilote. Un cas d’usage à faible risque présente trois caractéristiques : ses résultats peuvent être validés par un collaborateur en quelques secondes, les erreurs produisent des conséquences limitées et réversibles, le volume de demandes traité est suffisamment élevé pour générer des données significatives en quelques semaines.

Trois activités répondent particulièrement bien à ces critères :

Qualification des tickets

Le système propose une catégorie, un niveau de priorité et une équipe de traitement pour chaque demande entrante. L’opérateur visualise la recommandation et peut la valider ou la modifier en un seul clic. Chaque interaction produit une donnée exploitable permettant de mesurer précisément le taux de recommandations correctes. ‌

Synthèse des incidents

Pour les incidents comportant un grand nombre de notes et d’échanges, le système génère un résumé de la situation actuelle ainsi que des actions déjà réalisées. Cette capacité est particulièrement utile lors des changements d’équipe ou des relais d’astreinte, où la reconstitution manuelle de l’historique d’un incident complexe mobilise un temps précieux qui pourrait être consacré à sa résolution. ‌

Ébauches d’articles de la base de connaissances

À partir des tickets résolus, le système produit une première version d’un article qui est ensuite relue, enrichie et validée par un éditeur. L’alimentation de la base de connaissances fait partie des activités les plus fréquemment sacrifiées sous la pression opérationnelle. Toute contribution permettant d’accélérer cette production libère du temps qualifié pour des tâches à plus forte valeur ajoutée.

Ces trois activités présentent une caractéristique particulièrement intéressante dans le cadre d’un projet pilote IA en ITSM : la validation humaine fait déjà naturellement partie du processus opérationnel. Le contrôle n’introduit donc aucune étape artificielle supplémentaire. À l’inverse, les workflows entièrement autonomes ne devraient être envisagés qu’après que le système a démontré sa fiabilité de manière constante dans la durée.

Définir les indicateurs avant le lancement

Avant même le démarrage du projet pilote, trois éléments doivent être définis pour chaque indicateur retenu : la valeur de référence issue des données historiques, l’objectif attendu à l’issue de la phase d’expérimentation, la traduction de cette amélioration dans des termes compréhensibles par la direction générale et les équipes financières.

Des formulations génériques telles que « amélioration de l’efficacité opérationnelle » ou « meilleure qualité de support » ne résistent généralement pas à un premier échange avec les parties prenantes financières.

Un critère de décision doit également être établi en amont : quel niveau de résultat justifie un passage à l’étape suivante et, à l’inverse, à partir de quel seuil le projet doit être arrêté ? Définir ces règles avant le lancement évite que l’évaluation finale ne se transforme en débat sur l’interprétation des résultats obtenus.

Quels indicateurs suivre et sur quelle période ?

Les indicateurs réellement pertinents sont spécifiques et mesurables : réduction du volume de tickets parasites (noise tickets), délai d’affectation vers l’équipe la plus adaptée, taux de bonne affectation dès la première tentative, temps moyen de résolution, qualité de prise en charge des incidents critiques ou encore perception des équipes concernées.

Chaque indicateur doit par ailleurs être relié à une conséquence métier concrète, identifiable au-delà du périmètre IT. Par exemple, le délai d’affectation se traduit directement par le temps d’attente perçu par l’utilisateur. De même, la qualité des ébauches d’articles de la base de connaissances influence la capacité du Service Desk à résoudre les demandes sans solliciter les équipes expertes.

Il est préférable de se limiter à deux ou trois indicateurs, pas davantage. Chaque indicateur nécessite une définition partagée, une mesure initiale fiable et une interprétation rigoureuse à l’issue de la phase d’expérimentation. Un projet pilote IA en ITSM qui cherche à suivre six indicateurs simultanément réduit inévitablement l’attention portée à chacun d’eux, au risque de diluer la valeur des enseignements obtenus.

Par ailleurs, les volumes d’activité fluctuent souvent fortement au cours de l’année. La période de mesure doit donc être suffisamment longue pour intégrer à la fois les périodes de forte sollicitation et les phases plus calmes.

Responsabilité et gouvernance

Un projet pilote IA en ITSM sans responsable clairement identifié se heurte rapidement à des blocages. La responsabilité du projet doit être confiée à une personne nommément désignée, à la fois comptable des résultats obtenus et habilitée à décider des actions correctives nécessaires.

Au-delà de cette responsabilité opérationnelle, trois outils de pilotage sont indispensables :
Le premier consiste en une cartographie technique décrivant les outils de supervision impliqués, les sources de données utilisées, les relations de services issues de la CMDB, les mécanismes de sécurité appliqués, les limites fixées à l’automatisation ainsi que les points d’intégration existants.

Le deuxième est un registre des risques dédié, dans lequel sont consignés les risques identifiés, leur niveau de priorité et les actions prévues pour les maîtriser.

Le troisième est un modèle opérationnel définissant précisément les responsabilités : qui maintient les données, qui contrôle la qualité des recommandations produites par le système et selon quelle fréquence les performances sont examinées.

La cartographie technique, le registre des risques et le modèle opérationnel ne produisent toutefois de valeur que s’ils s’inscrivent dans un cadre de gouvernance partagé pour l’usage de l’intelligence artificielle. En l’absence de règles communes, chaque équipe finit par adopter ses propres outils et ses propres pratiques, ce qui multiplie les incohérences au lieu de les réduire.

Mettre en place des mécanismes de supervision humaine

La supervision humaine doit être intégrée aux étapes où le niveau de risque est le plus élevé, plutôt qu’appliquée systématiquement à chaque décision prise par le système. Avant le lancement du projet, trois éléments doivent être définis et documentés : les recommandations nécessitant une validation humaine avant exécution, les personnes habilitées à effectuer cette validation, l’emplacement où cette validation est tracée et enregistrée.

Il est également essentiel de formaliser la gestion des erreurs du système. L’organisation doit déterminer qui est chargé de détecter l’anomalie, comment restaurer l’état précédent et dans quels délais cette restauration doit intervenir. Définir cette procédure durant la phase expérimentale, lorsque les impacts restent limités, évite de devoir improviser une réponse une fois la solution déployée en production.

Pourquoi le taux d’approbation peut être trompeur

Un point mérite une attention particulière : l’effort nécessaire pour rejeter une recommandation. Si la validation d’une suggestion nécessite une seule action, par exemple un clic, mais que sa correction impose de renseigner manuellement plusieurs champs, les opérateurs soumis à une forte pression auront naturellement tendance à valider des recommandations pourtant imparfaites.

Dans ce contexte, les données censées mesurer la qualité des recommandations reflètent davantage la charge de travail du Service Desk que les performances réelles du système. Si le taux de suggestions approuvées est utilisé comme indicateur de précision, alors que l’approbation est quasi instantanée tandis que la correction demande davantage d’efforts, ce taux augmentera mécaniquement lors des périodes de forte activité et diminuera lorsque la charge retombera.

La solution consiste à rendre les corrections aussi simples et rapides que les validations. Par exemple, en proposant plusieurs alternatives sélectionnables plutôt qu’un champ libre à compléter manuellement.

Introduire l’autonomie de manière progressive

Dans un projet pilote IA, l’extension du niveau d’autonomie doit s’effectuer par étapes successives, chacune étant conditionnée par les résultats obtenus lors de la phase précédente.

V1 – Recommandations soumises à validation humaine

Le système formule des recommandations ; le responsable du processus prend la décision finale. Chaque recommandation produite par l’agent IA est comparée à la décision effectivement prise par l’opérateur. Cette comparaison permet de calculer un taux de concordance entre la recommandation du système et le choix humain.

Toutefois, la concordance ne constitue pas en elle-même une preuve d’exactitude. Un échantillon de décisions doit être contrôlé séparément afin de vérifier que les choix effectués étaient réellement corrects.

V2 – Automatisation des cas présentant un niveau de confiance élevé

Une fois identifiées les catégories pour lesquelles le système atteint de manière constante un niveau de confiance suffisamment élevé, l’exécution automatique n’est activée que pour ces cas précis. Toutes les autres demandes continuent de suivre un processus de validation humaine.

Le seuil de confiance doit être défini individuellement pour chaque type d’action. Les garanties attendues pour l’affectation automatique d’un ticket ne sont pas nécessairement les mêmes que pour une modification de priorité.

V3 – Extension de l’autonomie

L’élargissement du périmètre automatisé se poursuit au rythme de l’amélioration de la fiabilité du système et, par conséquent, de la confiance accordée par les équipes. Le suivi des performances reste permanent et l’organisation conserve à tout moment la possibilité de revenir à un niveau d’automatisation inférieur si les résultats se dégradent.

Cette approche repose sur une logique de transition progressive entre expérimentation et exploitation opérationnelle : une phase d’observation initiale, suivie d’un déploiement dans un périmètre contrôlé, puis, seulement après validation, d’une intégration dans les opérations quotidiennes.

Du projet pilote à la démonstration de la valeur

Le lien entre expérimentation et retour sur investissement (ROI) se construit tout au long du projet. Autrement dit, les données nécessaires pour démontrer la valeur de l’investissement doivent être collectées pendant l’exécution du projet pilote, et non une fois celui-ci terminé.

Les données historiques recueillies avant le lancement constituent le point de référence servant à évaluer les résultats obtenus. Les données produites durant la phase V1 permettent de vérifier et d’ajuster le comportement du système. Enfin, les améliorations constatées en V2 deviennent les éléments de preuve qui justifient l’allocation d’un budget supplémentaire pour étendre l’initiative.

Les recommandations les plus souvent citées pour l’adoption de l’intelligence artificielle dans la gestion des services IT reposent sur des principes largement convergents : privilégier des cas d’usage à forte valeur ajoutée, garantir la qualité des données, s’appuyer sur des outils adaptés, accompagner les équipes, expérimenter à petite échelle et progresser de manière graduelle.

Structuré de cette façon, un projet pilote IA en ITSM reste utile quel que soit son résultat. Si l’initiative est concluante, l’organisation dispose de données factuelles pour justifier son déploiement à plus grande échelle. Si les résultats ne sont pas au rendez-vous, l’investissement demeure limité et l’organisation identifie clairement les points de maturité à renforcer avant de relancer une nouvelle expérimentation.

Au final, la véritable question que doivent se poser les décideurs ne concerne pas tant les limites de la technologie que le niveau de maturité de leur propre organisation pour l’adopter, l’encadrer et en tirer durablement de la valeur.

FAQ

• Combien de temps doit durer un projet pilote d’IA ?
  Le projet doit durer suffisamment longtemps pour permettre la collecte d’un volume d’observations représentatif du cas d’usage étudié. Pour des activités à fort volume, comme la qualification des tickets, quelques semaines peuvent suffire. Une période plus courte ne permet généralement pas de distinguer une tendance durable d’une variation ponctuelle.

• Pourquoi éviter les agents autonomes lors de la phase initiale ?
  Parce que les mécanismes de contrôle, les seuils de confiance et les responsabilités nécessaires à leur gouvernance se construisent progressivement avec l’expérience. Commencer par des recommandations soumises à validation humaine permet de recueillir les données indispensables pour calibrer ces mécanismes avant d’étendre le niveau d’autonomie.

• Qui devrait piloter le projet ?
  Une seule personne doit être désignée comme responsable du projet. Cette personne s’appuie sur des référents identifiés pour les données, la gouvernance et les équipes opérationnelles concernées. À l’inverse, une responsabilité partagée entre plusieurs fonctions tend à ralentir la prise de décision précisément aux moments où réactivité et arbitrages rapides sont essentiels.

• Comment démontrer le retour sur investissement à l’issue de l’expérimentation ?
  En comparant les indicateurs mesurés avant le lancement avec ceux observés pendant le projet pilote, sur la base des critères définis dès le départ. Les gains obtenus peuvent ensuite être traduits en heures de travail économisées, en productivité supplémentaire ou en coûts évités afin de démontrer l’impact métier réel de l’initiative.