L'IA dans le management des ESN : le bilan après la bulle

Le moment est venu de compter

Pendant deux ans, toute conversation sur l'organisation d'un service IT finissait par la même phrase : « de toute façon, l'IA va s'en occuper ». Les feuilles de route ont été reportées, les recrutements gelés, les projets de structuration mis en attente d'un outil qui allait rendre la question caduque.

Le recul est désormais suffisant pour regarder ce qui s'est passé sans enthousiasme ni ricanement. Ce texte est un bilan de terrain, pas une prédiction.

Ce qui a tenu

Trois usages se sont installés durablement, parce qu'ils résolvent un problème réel et mesurable.

La qualification et le routage des demandes. Classer un ticket entrant, lui attribuer une catégorie et l'envoyer au bon niveau : c'est mécanique, répétitif, et l'IA le fait mieux qu'un humain pressé un lundi matin. Le gain n'est pas spectaculaire ticket par ticket, il est considérable en cumulé.

La synthèse des historiques. Reprendre un ticket de quarante échanges ouvert depuis trois semaines prenait un quart d'heure. En résumer l'état en trois lignes est devenu instantané. C'est le gain le plus sous-estimé, parce qu'il ne se voit dans aucun indicateur : il se voit dans la fatigue des équipes.

Le premier jet documentaire. Transformer une résolution en article de base de connaissances, rédiger une procédure à partir d'une suite de commandes. L'IA produit un brouillon honnête qu'un technicien corrige en deux minutes — au lieu d'un article jamais écrit.

Ce qui n'a pas tenu

La résolution autonome. La promesse était un assistant qui traite seul les demandes de niveau 1. La réalité est un assistant qui traite seul les demandes dont la réponse était déjà écrite quelque part. Ce n'est pas la même chose, et la différence se nomme : documentation.

La réduction d'effectif. Les organisations qui ont réduit leurs équipes en anticipant les gains ont découvert que le volume absorbé par l'IA était précisément celui qui coûtait le moins cher à traiter. Ce qui reste — l'incident singulier, l'utilisateur en difficulté, la panne qui touche plusieurs services — est exactement ce qui demande un humain expérimenté.

L'estimation et la planification de charge. Promesse récurrente, résultat nul. Prévoir la charge d'une équipe suppose de connaître le contexte, les dépendances, l'historique des dérapages et la politique interne. Aucun de ces éléments n'est dans les données.

L'effet que personne n'avait anticipé

Le niveau 1 était l'école du métier.

C'est le constat le plus préoccupant de ce bilan, et il ne figurait dans aucune feuille de route.

Un technicien ne devient pas N2 en lisant de la documentation. Il le devient en traitant cinq cents incidents simples, en se trompant sur les trente premiers, en développant progressivement l'intuition de ce qui cloche. Ce volume d'apprentissage était un sous-produit gratuit de l'activité quotidienne.

En absorbant la part répétitive, l'IA a supprimé le terrain d'entraînement sans supprimer le besoin de personnes formées. Les organisations qui ont le plus automatisé leur N1 commencent à constater qu'elles ne produisent plus de N2 — et qu'il faut désormais les recruter à l'extérieur, sur un marché où tout le monde fait le même calcul.

C'est un problème de management, pas de technologie. Il se traite en reconstituant délibérément ce qui était auparavant accidentel : rotation sur des incidents que l'IA aurait pu prendre, binômage sur les cas complexes, revue des résolutions assistées plutôt qu'acceptation silencieuse.

Le second effet, plus discret

Une recommandation produite par un assistant arrive avec une assurance de ton qui n'a aucun rapport avec sa fiabilité. Un technicien junior la suit. Un technicien expérimenté la vérifie.

La compétence qui distingue les deux — savoir qu'une réponse plausible peut être fausse — n'est acquise que par l'expérience du terrain. Nous venons de réduire cette expérience tout en augmentant le nombre de réponses plausibles à évaluer.

Ce que le bilan révèle vraiment

L'IA n'a pas nivelé les écarts entre organisations : elle les a creusés.

Un service dont les processus étaient écrits, les tickets correctement catégorisés et la base de connaissances vivante a obtenu des gains immédiats, parce que l'outil avait de la matière. Un service dont tout reposait sur la mémoire de trois personnes n'a rien obtenu du tout — l'IA n'avait rien à exploiter.

Autrement dit, l'IA a récompensé exactement ce qu'elle était censée rendre inutile : la structuration. Les organisations qui attendaient qu'elle les dispense de s'organiser ont perdu deux ans.

Ce qu'il faut en faire maintenant

Pour un responsable de service ou un dirigeant, la conduite à tenir n'a rien de spectaculaire :

1. Reprendre la structuration là où elle a été suspendue. Catégorisation, base de connaissances, processus écrits. C'est le préalable qui conditionne tout gain, et non l'inverse.
2. Mesurer ce que l'IA absorbe réellement. Non pas en nombre de requêtes à l'assistant, mais en évolution du volume sur les motifs concernés. Les deux chiffres n'ont aucun rapport.
3. Reconstituer le parcours d'apprentissage. Décider explicitement quelle part des incidents simples reste traitée par des humains en formation, et l'assumer comme un coût de production de compétences.
4. Vérifier les recommandations assistées sur les sujets à risque. Sauvegardes, identités, réseau. Une réponse fausse énoncée avec aplomb y coûte beaucoup plus cher qu'ailleurs.

L'IA est devenue un outil ordinaire du service IT, utile et sans mystère. Comme tous les outils, elle amplifie l'organisation qu'elle trouve. C'est précisément pour cette raison qu'elle ne dispense jamais d'en avoir une.