Imaginons que votre VPN ne fonctionne plus demain matin.
Dans beaucoup d'entreprises, le processus commence encore par vous. Vous constatez le problème, ouvrez un portail, décrivez la situation et créez un ticket. Quelqu'un le lit, demande éventuellement des informations supplémentaires, consulte les logs et cherche une solution.
Nous sommes tellement habitués à ce fonctionnement qu'il paraît presque naturel.
Pourtant, il repose sur une hypothèse assez étrange : l'utilisateur doit d'abord constater le problème avant que l'IT puisse agir.
C'est précisément là que les prochaines années peuvent changer les choses en profondeur.
L'IA dans le support IT ne servira probablement pas uniquement à fermer les tickets plus vite. Elle peut surtout faire en sorte que certains incidents n'aient plus besoin d'être signalés par un utilisateur.
Le marché regarde déjà plus loin qu'un chatbot devant le formulaire de ticket
L'IA appliquée à l'IT Service Management n'est plus considérée comme une petite fonctionnalité annexe. Gartner lui consacre désormais une catégorie de marché spécifique : AI Applications in IT Service Management.
L'étude publiée en août 2026 couvre des solutions qui utilisent l'IA pour le self-service utilisateur, l'assistance aux équipes IT et des actions ITSM autonomes.
Le changement est important. La question n'est plus seulement de savoir si une IA peut rédiger une réponse. On commence à se demander quelles étapes de l'incident, de la request, du problem management ou du change management peuvent être préparées ou exécutées directement par un système.
La plupart des organisations sont encore dans une phase plus simple. L'IA résume les tickets, propose une catégorie, retrouve des articles de connaissance et prépare une première réponse. C'est utile et cela fait gagner du temps.
Mais le modèle opérationnel reste presque identique.
Un utilisateur signale un problème. Un ticket est créé. Quelqu'un le traite.
C'est plus rapide qu'avant, mais ce n'est pas encore une nouvelle manière de faire du support.
L'étape suivante commence avant même le ticket
Reprenons le problème de VPN.
Cette fois, le monitoring détecte lui-même des échecs de connexion. Un agent vérifie l'état des endpoints, les changements récents et les logs. Il constate que le même pattern est déjà apparu sur plusieurs machines ce matin et le rapproche d'un problème connu.
Une action de remédiation à faible risque a été approuvée à l'avance. L'agent l'exécute, vérifie que la connexion fonctionne à nouveau et enregistre ce qui s'est passé.
Pour l'utilisateur, toute l'expérience peut se limiter à une notification :
Nous avons détecté un problème de connexion et rétabli le service.
Pas de portail. Pas de file d'attente. Pas d'échange d'e-mails.
Et parfois, aucune interruption réellement visible.
C'est beaucoup plus intéressant qu'un chatbot qui aide simplement quelqu'un à remplir un formulaire plus vite.
Le ticket ne disparaîtra pas complètement. Son rôle peut changer.
Il faut rester nuancé.
Dans un environnement IT mature, il faut toujours garder une trace de ce qui s'est produit. L'audit, le reporting, le problem management, la conformité et l'analyse des tendances restent nécessaires, même lorsqu'un agent a résolu l'incident de manière autonome.
Un enregistrement ITSM peut donc toujours être créé.
Mais il ne doit plus forcément jouer le même rôle qu'aujourd'hui.
Actuellement, un ticket sert souvent à trois choses à la fois : signalement de l'utilisateur, tâche de travail pour l'IT et preuve administrative après résolution. Dans un environnement plus autonome, il peut devenir avant tout une trace fiable d'un événement et de l'action exécutée.
Le ticket comme enregistrement système reste utile. Le ticket comme file de travail manuelle peut, lui, perdre une grande partie de son importance.
La différence est essentielle.
La meilleure interaction de support est parfois celle qui n'a jamais été nécessaire
Les service desks suivent aujourd'hui des indicateurs classiques et légitimes : volume de tickets, First Contact Resolution, temps de résolution, backlog et respect des SLA.
Mais imaginons que l'année prochaine un environnement génère 30 % de tickets en moins parce que davantage de problèmes sont détectés plus tôt, corrigés automatiquement ou évités grâce à un meilleur problem management.
Le service desk est-il devenu moins performant ?
Évidemment non.
C'est peut-être même sa meilleure année.
Une autre question devient alors plus intéressante que "À quelle vitesse fermons-nous les tickets ?" :
Combien de perturbations les utilisateurs subissent-ils réellement ?
Cela rapproche le service management de la réalité du business. On ne mesure plus seulement des enregistrements administratifs, mais le temps de travail perdu, les incidents récurrents et les problèmes qui ont pu être évités.
Les premiers chiffres vont déjà dans cette direction
Début octobre 2026, ServiceNow a publié une étude menée auprès de 285 responsables IT de grandes organisations. Le help desk est le domaine où les répondants déclarent l'impact positif le plus fort de l'IA, à 53 %.
La même étude montre aussi à quel point l'autonomie réelle reste limitée. 39 % explorent ou pilotent des agents, et 39 % supplémentaires les utilisent principalement pour assister les collaborateurs. Seuls 5 % déclarent avoir réellement repensé les rôles, workflows et contrôles pour permettre une exécution autonome.
Il s'agit d'une étude fournisseur et il faut la lire comme telle. Mais le signal reste intéressant : l'IA est ajoutée plus vite que les processus ne sont repensés.
On le voit dans beaucoup d'environnements IT. Une couche intelligente vient se poser au-dessus d'un mode de fonctionnement conçu il y a dix ans. Cela apporte des gains, mais probablement pas les gains les plus importants.
Le support L1 changera en premier
Une grande partie du support de première ligne repose sur des tâches prévisibles. C'est là que l'automatisation peut apporter le plus vite une différence concrète.
Bons candidats à l'automatisation
- Réinitialisations de mots de passe et déverrouillages de comptes.
- Logiciels standards, demandes d'accès simples, erreurs connues et remédiations à faible risque.
Là où le jugement humain reste important
- Incidents qui touchent plusieurs systèmes ou dont la cause n'est pas claire.
- Problèmes utilisateurs urgents, exceptions mal documentées et décisions à impact plus élevé.
Cela ne signifie pas que le L1 disparaît. Cela signifie que les humains passeront moins de temps sur des actions répétées des centaines de fois par mois presque de la même façon.
Ce qui reste demande justement davantage d'expérience, de communication et de jugement.
Moins de volume peut rendre le rôle humain plus utile
Si l'IA et l'automatisation absorbent le travail prévisible, le service desk recevra proportionnellement davantage de situations complexes.
Le rôle peut alors évoluer du traitement de tickets vers la surveillance du service, les major incidents, le problem management, l'expérience utilisateur, l'amélioration de la connaissance et le continuous improvement.
Le service desk ressemble moins à un guichet et davantage à une control room.
Il ne se contente plus de réagir à ce qui arrive. Il cherche en permanence où la friction se crée et quelles interruptions peuvent être évitées.
C'est en réalité beaucoup plus proche de ce que le bon Service Delivery a toujours cherché à faire.
Qui supporte l'agent de support ?
Davantage d'autonomie crée évidemment un nouveau problème.
Un agent peut se tromper.
Imaginons qu'il interprète mal un incident, lance une remédiation et constate que le problème n'est pas résolu. Il tente alors automatiquement une deuxième action, puis une troisième.
Avant qu'un humain ne s'en rende compte, plusieurs changements ont été effectués pour résoudre un seul incident.
Le support a été automatisé, mais l'automatisation est devenue elle-même une source d'incidents.
C'est pourquoi des principes classiques comme least privilege, logging, rollback et change control restent pleinement d'actualité. Ils deviennent même probablement plus importants.
Un humain commet souvent une erreur une fois. Un agent peut répéter très vite la même erreur à grande échelle.
Toutes les actions automatiques n'ont pas besoin d'une validation humaine
Il existe aussi un piège inverse.
Si chaque étape d'un agent doit être approuvée manuellement, une grande partie du bénéfice disparaît. On a construit un système plus rapide qui attend toujours le même clic humain.
Une réinitialisation de mot de passe sous conditions claires peut être totalement automatisée. Même chose pour l'installation d'un logiciel approuvé ou une remédiation connue et peu risquée. Une modification en production, une élévation de privilèges ou une modification de firewall appartient à une autre catégorie.
Nous préférons donc trois niveaux clairs plutôt que de parler d'"autonomie complète" sans contexte :
- Assist : l'IA recherche l'information, analyse le problème et propose une action. Un collaborateur l'exécute.
- Advise : l'IA prépare une action concrète et montre les éléments de preuve, l'impact et le chemin de restauration. Un humain décide.
- Act : l'IA exécute seule des actions à faible risque préalablement autorisées, dans des limites claires. Dès qu'elle sort de ce cadre, elle s'arrête.
L'avenir ne sera donc pas vraiment une opposition entre humain et IA. Il s'agira de décider, action par action, quel niveau d'autonomie est raisonnable.
C'est moins spectaculaire qu'un service desk totalement autonome, mais beaucoup plus crédible opérationnellement.
Les SLA devront eux aussi évoluer
Beaucoup de contrats de service sont aujourd'hui très orientés sur les temps de réponse et de résolution. Cela reste utile lorsqu'un utilisateur signale un incident et qu'une personne doit ensuite intervenir.
Mais que signifie le temps de réponse quand un système détecte lui-même le problème ?
Et à quoi sert un temps de résolution excellent si le même incident revient chaque semaine ?
Dans un environnement plus automatisé, d'autres mesures deviennent importantes : minutes réelles de perturbation, recurrence rate, nombre d'incidents évités de manière proactive, taux de succès des actions automatiques et temps nécessaire pour reprendre la main lorsqu'une automatisation échoue.
Les SLA ne deviennent pas inutiles. Ils peuvent enfin se rapprocher davantage de l'expérience réelle de l'utilisateur.
Un rapport rempli de cases vertes ne vaut pas grand-chose si les collaborateurs ne peuvent toujours pas travailler correctement.
Le service desk ne va probablement pas disparaître
Mais sa raison d'être peut évoluer.
Aujourd'hui, le service desk est souvent l'endroit où un problème arrive avant d'être réparti.
Demain, il peut devenir le point où expertise humaine, automatisation et monitoring se rejoignent.
L'IA prend en charge le répétitif. Les humains gèrent le contexte et les exceptions. Les service managers regardent moins le volume et davantage les perturbations récurrentes, le risque et l'expérience.
Et le ticket ?
Il restera probablement utile comme preuve, donnée et audit trail. Il ne devra simplement plus être le début d'une file de travail humaine pour chaque problème.
Le KPI le plus intéressant du service desk de demain ne sera peut-être pas le nombre de tickets clôturés.
Mais le nombre de tickets que personne n'a jamais eu besoin d'ouvrir.
Sources et lectures complémentaires
- Gartner, Magic Quadrant for AI Applications in IT Service Management (17 août 2026) : https://www.gartner.com/en/documents/8270821
- Gartner, Critical Capabilities for AI Applications in IT Service Management (17 août 2026) : https://www.gartner.com/en/documents/8272821
- ServiceNow, The New CIO Mandate / publication de recherche (5 octobre 2026) : https://newsroom.servicenow.com/press-releases/details/2026/Report-CIOs-have-the-AI-mandate-and-the-budget-but-few-organizations-are-well-positioned-for-true-autonomous-work/default.aspx