Un signalement arrive : un utilisateur ne peut pas se connecter, une imprimante ne fonctionne pas, un serveur affiche des messages d'erreur. Quelqu'un au service desk transforme cela en ticket, choisit une catégorie et détermine l'urgence. L'IA peut-elle reprendre cela ? En grande partie oui, avec une exception importante qui varie selon l'entreprise.
Trois axes sont déterminants : le volume, la marge d'appréciation et le contact client.
Le volume est élevé. Un service desk traite quotidiennement des dizaines à des centaines de signalements, et beaucoup d'entre eux sont des variations d'un petit nombre de problèmes connus : mot de passe oublié, pas d'accès à un partage, ordinateur portable qui ne démarre pas. En cas de volumes élevés et de répétition, une tâche est par définition adaptée à l'automatisation, car un modèle apprend des schémas qui se répètent souvent.
La marge d'appréciation est limitée. L'urgence et la catégorie découlent généralement d'un arbre de décision : combien d'utilisateurs sont touchés, existe-t-il une solution de contournement, quel système est concerné. C'est précisément le genre de travail dans lequel les modèles de texte excellent : lire un signalement, en extraire les caractéristiques et les confronter à un modèle de catégorisation. Ce que l'IA peut gérer aujourd'hui, c'est le texte — les signalements eux-mêmes, souvent rédigés en termes libres par l'utilisateur, et leur traduction en un ticket structuré.
Le contact client est fonctionnel, pas relationnel. Un utilisateur qui signale une panne veut surtout que celle-ci soit prise en charge, pas qu'une conversation s'engage. Il en va autrement dès que les choses tournent mal ou deviennent sensibles — voir à ce sujet comment une panne est communiquée aux utilisateurs, car il s'agit d'une autre tâche avec un autre profil.
La composante physique ne joue aucun rôle : il s'agit d'un travail administratif devant un écran, pas d'une manipulation d'équipement. Le coût des erreurs est moyen. Un signalement mal priorisé entraîne rarement un dommage direct, mais pour les systèmes soumis à la conformité — un système financier, un dossier patient — c'est différent, et l'axe conformité obtient donc ici un score supérieur à la moyenne. Une panne dans un environnement soumis à une obligation légale de signalement exige une raison documentée pour la classification, pas seulement une étiquette.
Le point faible est la créativité, et c'est précisément pour cela qu'il ne s'agit pas d'une reprise complète. Un signalement qui ne correspond pas au schéma connu — une nouvelle combinaison de symptômes, un système qui tombe en panne pour la première fois, un utilisateur qui décrit le problème de manière confuse — exige quelqu'un qui réfléchit plutôt que qui classe. Cela implique un contrôle : l'IA propose une catégorie et une urgence, une personne approuve ou corrige, avec justification. C'est une organisation différente d'une reprise complète, et c'est aussi la pratique la plus courante chez les entreprises qui travaillent déjà de cette manière.
Dans une entreprise dotée d'un paysage applicatif restreint et clair et de quelques centaines d'utilisateurs, quatre-vingt-dix pour cent des signalements sont la répétition de quelque chose qui s'est déjà produit une centaine de fois. Là, un modèle doté d'un bon modèle de catégorisation peut traiter de manière autonome la majeure partie de l'accueil des signalements, une personne ne voyant que les exceptions.
Dans une entreprise disposant de nombreux systèmes hérités, de logiciels sur mesure et d'un historique de fusions, le schéma est moins prévisible. Les signalements sont plus divers, les catégories moins nettement délimitées, et la probabilité qu'un signalement sorte du schéma connu est plus élevée. Là, une plus grande part du travail reste entre les mains d'une personne, non pas parce que l'IA ne voudrait pas s'en charger, mais parce que les données d'entrée sont trop peu structurées pour en tirer automatiquement quelque chose de fiable.
La condition préalable n'est donc pas la technique mais l'accueil des signalements : des formulaires d'accueil structurés et un modèle de catégorisation des incidents bien développé déterminent en grande partie la part de ce travail qui est déjà transférable aujourd'hui. Sans ces deux éléments, la majeure partie reste du travail manuel, l'IA servant d'outil plutôt que d'exécutant.
Ceci n'est pas un conseil en matière de personnel ni une justification pour réduire l'effectif d'une équipe de service desk. Si et comment une organisation tire des conséquences en matière de personnel de l'évolution du travail relève de l'employeur, et des exigences légales propres s'appliquent à cet égard ; voir à ce sujet les points d'attention lors de la suppression de fonctions. Cette page décrit uniquement ce qui arrive à la tâche elle-même.
Il est également utile de ne pas considérer cette tâche isolément du reste de l'exploitation informatique. L'enregistrement des incidents est lié à des travaux tels que la surveillance des performances des systèmes, qui donne souvent les premiers signaux avant même qu'un signalement n'arrive, et à des tâches de gestion telles que l'exécution et le contrôle des sauvegardes ou le maintien à jour des données de référence, qui présentent la même combinaison de volume élevé et de marge d'appréciation limitée. Quiconque souhaite savoir, pour l'ensemble du service informatique, où se situe déjà le glissement, ferait mieux d'examiner toutes les tâches ensemble plutôt qu'un seul processus de tickets.
Le résultat pour votre propre service desk dépend de la proportion de vos signalements qui s'inscrit dans des schémas reconnaissables et du degré de structuration déjà atteint par votre accueil des signalements. Cela varie selon l'entreprise et ne peut être résumé par une règle empirique fixe.
Le scan rapide gratuit de FTE TO AI donne une première indication à ce sujet : douze questions, sans compte, avec une indication de la part des heures de votre profil qui peut être reprise aujourd'hui par l'IA. Le scan de travail complet, qui calcule le travail de toute une entreprise tâche par tâche en équivalents temps plein, est encore en cours de développement.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.