Face à un ticket, une IA de service desk peut aujourd’hui résumer, classifier, répondre, clôturer ou même déclencher une action technique. La vraie question n’est pas de savoir si l’IA « doit » intervenir, mais, pour une action donnée dans un workflow ITSM précis, si elle peut agir seule, si elle doit se contenter de proposer une action, ou si une validation humaine doit être imposée avant toute exécution.

C’est cette question, répétée action par action, qui structure une gouvernance de l’IA réellement opérationnelle. Le raisonnement suit toujours la même chaîne : niveau d’autonomie, impact potentiel, contrôle humain, approbation, traçabilité. Une politique de gouvernance qui ne redescend pas jusqu’à ce niveau de détail reste un document de principe, rarement consulté au moment de traiter une demande.

La distinction entre trois niveaux d’autonomie reste le point de départ le plus utile. L’IA assistive résume un ticket, effectue une recherche dans la base de connaissances ou suggère une réponse : elle n’agit pas, elle éclaire une décision que l’agent garde entièrement. L’IA décisionnelle va plus loin en classifiant une demande, en priorisant un ticket ou en sélectionnant un workflow ; elle commence à orienter le traitement sans qu’un humain valide systématiquement chaque choix. L’IA agentique franchit un seuil supplémentaire : elle déclenche une action réelle dans un système, qu’il s’agisse de clôturer un ticket, d’activer un droit d’accès ou d’ouvrir un changement.

Ces trois niveaux n’appellent pas le même degré d’autonomie, et pour une raison simple : ils ne produisent pas le même effet si l’IA se trompe. Mais l’autonomie technologique ne suffit pas à fixer le niveau de contrôle nécessaire. Une deuxième dimension doit s’y ajouter : le rayon d’impact de l’action. Résumer un ticket isolé et clôturer ce même ticket peuvent reposer sur exactement le même modèle d’IA, mais l’un ne produit aucun effet sur le système tandis que l’autre en produit un, potentiellement irréversible. À l’inverse, une action en apparence mineure peut avoir un rayon d’impact large si elle touche un CI critique, plusieurs utilisateurs à la fois, ou un service métier sensible. C’est le croisement entre le niveau d’autonomie et ce rayon d’impact qui doit déterminer le contrôle à appliquer, pas la seule nature de la technologie utilisée.

Une matrice pour relier chaque action IA à son niveau de contrôle

Une fois ces deux dimensions posées, l’exercice le plus utile consiste à les appliquer à des cas d’usage réels de service desk plutôt qu’à en rester à une distinction théorique. La matrice suivante illustre cette logique sur les situations les plus fréquentes.

Ce tableau ne remplace pas une politique de gouvernance, il la rend exploitable. Il montre en particulier que deux actions apparemment proches, comme générer une réponse et l’envoyer automatiquement, n’appellent pas le même contrôle dès que la seconde produit un effet visible pour l’utilisateur. Il montre aussi qu’une action à faible impact individuel, comme la classification d’un ticket, peut rester largement autonome tant que le score de confiance reste élevé, alors qu’une action à impact potentiellement irréversible, comme une demande d’accès, doit rester sous validation humaine quel que soit ce score.

Traduire cette matrice dans les faits suppose de la relier aux workflows ITSM eux-mêmes : rôles habilités à valider, permissions associées à chaque étape, règles d’escalade concrètes. Un expert ITSM en Belgique et en France confrontera généralement cette matrice à l’outil déjà en place avant de l’activer, pour vérifier que chaque case correspond à un rôle réellement configurable et à une permission qui existe dans le système, plutôt qu’à une intention documentée sans traduction opérationnelle.

Placer le contrôle humain au bon endroit, pas à chaque étape

La chaîne analyser → classifier → proposer peut, dans une majorité de contextes, rester largement automatisée : elle produit une recommandation, pas encore un effet sur le système ou sur l’utilisateur. La chaîne suivante — communiquer → approuver → modifier → exécuter — concentre en revanche le risque réel, puisque c’est à ce stade qu’une décision commence véritablement à produire une conséquence. C’est donc à ce point précis que le contrôle humain doit se concentrer, plutôt que d’être réparti uniformément sur l’ensemble du processus.

Un Human-in-the-Loop ajouté trop tôt, avant que l’IA ne s’approche du point où l’action produit un effet, perd rapidement sa valeur : l’agent en charge de la validation approuve mécaniquement une proposition qu’il n’a plus le temps ni la raison d’examiner en détail. Le contrôle existe formellement, mais il n’exerce plus de fonction réelle de filtrage. À l’inverse, avant qu’une IA ne puisse automatiser les processus du service desk de bout en bout sur une action donnée, le point de vigilance doit porter sur l’instant précis de l’exécution, pas sur l’étape d’analyse qui la précède et qui, dans la plupart des cas, ne présente pas le même niveau de risque.

Voir n’est pas agir : deux périmètres à distinguer

Un cadre de gouvernance qui se limite à la question de l’autonomie manque une distinction tout aussi structurante : autoriser une IA à consulter une information n’est pas la même chose que l’autoriser à agir sur cette information. Une IA peut avoir un accès large en lecture — tickets, pièces jointes, base de connaissances, fiches de CI, historique, y compris des données sensibles — sans que cet accès en lecture justifie une capacité équivalente à modifier ou déclencher quoi que ce soit sur ces mêmes éléments.

Le second périmètre, celui de l’action, doit être défini séparément : modifier une priorité, changer un statut, envoyer une réponse, activer un workflow, accorder un droit, ouvrir un changement ou exécuter une action technique. Une entreprise qui confond ces deux périmètres se retrouve souvent avec une IA capable d’agir sur tout ce qu’elle peut voir, ce qui revient à supprimer de fait la logique de contrôle construite par ailleurs. Documenter séparément ce que l’IA peut lire et ce qu’elle peut modifier permet, à l’inverse, d’élargir l’accès en lecture — utile pour la qualité des réponses — sans élargir mécaniquement sa capacité d’action.

Cinq dimensions pour décider d’une escalade

Les critères qui déclenchent une escalade vers un humain gagnent à être pensés comme la combinaison de cinq dimensions plutôt que comme une liste plate de signaux isolés : la confiance du modèle dans sa propre recommandation, la criticité du service ou du CI concerné, la sensibilité des données impliquées, la réversibilité de l’action, et son rayon d’impact.

Ces dimensions s’évaluent ensemble, pas séparément. Un score de confiance élevé ne suffit pas à autoriser automatiquement une action si celle-ci touche plusieurs utilisateurs ou un CI critique : la confiance du modèle porte sur la justesse de sa recommandation, pas sur l’acceptabilité de ses conséquences si elle se trompe malgré tout. À l’inverse, une action très réversible et à faible rayon d’impact, comme reformuler une réponse déjà validée pour un seul ticket, peut rester autonome même avec un score de confiance modéré, précisément parce qu’une erreur reste sans conséquence durable. Une demande touchant un service métier critique dans une filiale donnée illustre bien cette logique combinée : la criticité du service et le rayon d’impact suffisent à justifier une validation humaine, même si la nature de la demande semble par ailleurs standard.

Une piste d’audit qui permet de rejouer la décision, pas seulement de la constater

Une piste d’audit efficace ne se limite pas à enregistrer qu’une action a eu lieu ; elle doit permettre de rejouer la décision après coup. Cela suppose de pouvoir répondre à quatre questions dans l’ordre où elles se sont posées : quel était le contexte dont disposait l’IA au moment de la recommandation, qu’a-t-elle proposé, qu’un humain a-t-il validé, modifié ou refusé, et quelle action a finalement été exécutée dans le système.

Cette dernière distinction, entre la recommandation produite par l’IA et l’action réellement exécutée, est souvent celle qui manque le plus dans les journaux existants. Une IA peut recommander une action qu’un agent modifie avant validation ; si seule la recommandation initiale est journalisée, l’audit reconstitue une décision qui n’a jamais été prise telle quelle. Ces champs peuvent être organisés simplement : horodatage et ticket ou CI concerné, contexte utilisé par l’IA, recommandation produite, décision humaine et identité du validateur, action réellement exécutée. L’essentiel n’est pas la longueur de cette liste, mais sa capacité à répondre, plusieurs semaines après les faits, à la question de savoir qui a décidé quoi.

Modifier les règles de l’IA est déjà un changement opérationnel

Une gouvernance centrée sur les actions de l’IA laisse souvent de côté un point pourtant déterminant : la configuration de l’IA elle-même doit être gouvernée. Modifier un prompt, ajuster un seuil de confiance, ajouter une source de connaissance ou autoriser une nouvelle action peut faire basculer le comportement du service desk aussi nettement qu’une modification directe d’un workflow ITSM.

Le parallèle avec le Change Management est direct : une entreprise n’autorise pas n’importe quel technicien à modifier un workflow de production sans traçabilité ni évaluation d’impact ; la même exigence devrait s’appliquer à quiconque peut abaisser un seuil de confiance ou connecter l’IA à une nouvelle source de données. Sans ce niveau de gouvernance sur la configuration, la matrice construite en amont perd une grande partie de sa valeur : les règles peuvent rester intactes sur le papier tandis que les paramètres qui déterminent leur application réelle évoluent sans contrôle équivalent.

Le registre des cas d’usage comme outil de pilotage

À mesure que les cas d’usage IA se multiplient dans un service desk, il devient difficile de garder une vision d’ensemble sans un registre structuré. Ce registre ne doit pas être traité comme une simple liste administrative, mais comme l’outil qui permet de piloter l’ensemble du dispositif : pour chaque cas d’usage, il doit être possible de retrouver rapidement son propriétaire, son niveau d’autonomie, les données auxquelles il a accès, l’action maximale qu’il est autorisé à exécuter, son niveau d’impact potentiel, les validations requises, le mécanisme permettant de le désactiver, et la date de sa dernière revue.

Sans ce registre, chaque nouveau cas d’usage est évalué isolément, sans visibilité sur les règles déjà appliquées ailleurs dans l’équipe IT — au risque de traiter deux situations comparables avec des niveaux de contrôle incohérents.

Une automatisation IA doit pouvoir être arrêtée sans arrêter le service desk

La gouvernance ne se limite pas au fonctionnement nominal ; elle doit aussi couvrir le moment où l’IA se trompe ou agit de façon inattendue. Cela commence par la capacité à revenir immédiatement à un traitement manuel sur le cas d’usage concerné, sans que cela n’exige d’arrêter l’ensemble des automatisations du service desk. Cette capacité suppose d’avoir désigné, en amont, qui détient le droit de désactiver une automatisation donnée — un rôle qui doit être clair avant qu’un incident ne survienne, pas défini dans l’urgence.

Il faut ensuite pouvoir retrouver les actions déjà réalisées par l’IA avant la désactivation, notamment celles concernant des tickets encore ouverts au moment de l’incident. C’est précisément ce que permet une piste d’audit correctement construite : elle indique quelles actions ont été exécutées, sur quels tickets, et si elles nécessitent une correction. Enfin, une défaillance de l’IA gagne à être traitée comme n’importe quel autre incident : rattachée au processus de gestion des incidents pour le traitement immédiat, puis, si le comportement se reproduit, au processus de gestion des problèmes pour en traiter la cause plutôt que ses seuls symptômes.

Une gouvernance commune, des règles d’application distribuées

Le sujet se pose avec une acuité particulière pour une entreprise présente dans plusieurs pays ou disposant de plusieurs entités, comme c’est fréquemment le cas dans une zone Benelux où filiales, langues et responsabilités IT, Sécurité et métier peuvent différer d’un pays à l’autre. Un cadre de gouvernance de l’IA au service desk peut tout à fait rester unique au niveau du groupe, tout en laissant varier, selon l’entité, le pays, le service ou le propriétaire du CI concerné, les personnes réellement habilitées à valider ou à recevoir une escalade.

C’est là que les workflows ITSM prennent tout leur sens : ils permettent de traduire une politique commune en règles d’approbation concrètes et différenciées, sans dupliquer la gouvernance elle-même à chaque entité. La matrice reste identique pour tout le groupe ; seuls les rôles rattachés à chaque case changent selon la structure réelle de chaque équipe IT.

Ce qu’il faut retenir

La gouvernance de l’IA au service desk consiste, pour chaque action, à définir jusqu’où l’IA peut aller seule, à partir de quel niveau d’impact un humain doit reprendre la main, et quelle trace permettra ensuite de comprendre exactement ce qui s’est passé. Une matrice reliant action, autonomie et impact rend ce cadre exploitable au quotidien ; un registre des cas d’usage et une piste d’audit fiable lui donnent la capacité de durer sans perdre le contrôle sur ce que l’IA déclenche réellement.