Entreprise Service Management (ESM) : quand les silos résistent à l’unification

Sophie est RRH depuis huit ans. Elle a survécu à trois réorganisations, deux fusions et un déménagement de siège. Mais ce qui l’épuise vraiment, ce sont les premiers jours des nouveaux arrivants. Chaque onboarding suit le même feuilleton : un mail à l’IT pour le PC, une relance aux Services Généraux pour le badge, une attente de confirmation de contrat avant de déclencher quoi que ce soit. Résultat : le jour J, le nouveau salarié arrive dans un open space silencieux, sans identifiant, sans bureau attribué, avec ce sentiment qu’on ne l’attendait pas vraiment.

Ce n’est pas un problème de mauvaise volonté, c’est un problème d’organisation du travail. Et c’est exactement ce que l’Enterprise Service Management, l’ESM, est censé résoudre.

L’ESM : étendre la logique de service au-delà de l’IT

L’ESM repose sur une idée simple : les pratiques ITIL qui ont transformé la gestion des services IT (catalogue de services, SLA, workflows d’approbation, portail de demandes, etc.) peuvent être étendues aux autres fonctions de l’entreprise. RH, Juridique, Finance, Services Généraux : tous produisent des services, tous reçoivent des demandes, tous font attendre leurs interlocuteurs dans des boîtes mail surchargées.

Avec Jira Service Management configuré en mode ESM, le scénario change du tout au tout. Le manager remplit un seul formulaire « Nouvel Arrivant ». L’automatisation déclenche simultanément trois sous-tâches : vers les RH, l’IT et les Services Généraux. Avec les dépendances et les SLA associés. Le manager suit l’avancement global sur une seule vue. Le nouveau salarié arrive avec un PC opérationnel et un badge qui fonctionne. C’est cela une expérience d’onbording moderne.

Techniquement, c’est cohérent. D’un point de vue de l’organisation du travail, c’est là que les choses se compliquent.

Les silos ne sont pas des dysfonctionnements

Quand un projet ESM est présenté en comité de direction, la réaction des équipes RH, Juridique ou Finance est rarement l’enthousiasme. On entend parler de « processus qui ne correspondent pas à notre réalité », de « risques de confidentialité ». Ces objections sont souvent perçues comme de la résistance au changement. Elles sont en réalité d’un autre ordre.

Chaque département a construit, au fil du temps, ses propres outils, ses propres processus, son propre langage interne. Cette autonomie est une ressource stratégique. Elle protège des demandes extérieures jugées illégitimes, maintient une expertise exclusive, donne du pouvoir de négociation dans les arbitrages internes. Quand l’IT propose d’unifier tout cela dans JSM, les autres métiers entendent : « Nous allons rendre vos processus visibles, les standardiser, et réduire votre marge de manœuvre. »

La résistance n’est pas irrationnelle. C’est une défense légitime de l’autonomie professionnelle.

Le risque de colonisation numérique

Il y a un angle que les projets ESM évitent souvent de nommer. Les RH n’ont pas demandé à travailler dans « un outil IT ». Ils ont leur propre culture professionnelle : l’entretien individuel, l’accompagnement, la médiation. Ces pratiques ne se décomposent pas naturellement en tickets, SLA et workflows automatisés. Un accompagnement de mobilité interne, une procédure disciplinaire, une négociation délicate : ces réalités résistent à la mise en workflow.

Quand l’IT arrive avec JSM en assurant que « Jira est adapté à vos métiers », les équipes concernées perçoivent souvent une forme de colonisation numérique : l’imposition silencieuse de la rationalité IT à des pratiques qui fonctionnent selon d’autres logiques. Et cette perception n’est pas infondée.

Ce que le travail réel révèle

L’ergonomie du travail fait une distinction fondamentale entre le travail prescrit, le processus formalisé, et le travail réel, ce qui se passe effectivement sur le terrain. Dans le cas de l’onboarding, le workflow prescrit est linéaire : RH d’abord, IT ensuite, Services Généraux en troisième. Le travail réel est différent : les RH attendent la signature du contrat, l’IT attend l’aval budgétaire de la Finance, les Services Généraux se coordonnent avec l’immobilier qui a ses propres contraintes.

Ces interdépendances ne sont pas linéaires. Elles se négocient au cas par cas, par des coups de fil, des arrangements informels, des ajustements de dernière minute. Un workflow JSM rigide ne capture jamais totalement cette réalité. Ce n’est pas un échec de l’outil, c’est une limite structurelle de toute tentative de formalisation du travail humain.

Le paradoxe de la simplification

L’ESM promet de simplifier avec un portail, une vue, un formulaire. Mais pour y arriver, il faut d’abord standardiser : mêmes champs, mêmes SLA, mêmes processus pour tous. Or standardiser, c’est parfois appauvrir. C’est rendre invisibles les spécificités métier, les cas particuliers, les astuces écrites nulle part mais qui contribuent à l’efficacité.

Un onboarding pour un stagiaire n’est pas celui d’un directeur. Une demande juridique sur un NDA standard (Non Disclosure Agreement) n’est pas une opération de fusion-acquisition. En forçant ces réalités dans le même cadre, on risque de produire un outil qui satisfait les indicateurs de suivi tout en appauvrissant la qualité réelle du service rendu.

Déployer l’ESM autrement

Rien de tout cela ne disqualifie l’ESM. Cela invite à le déployer autrement, avec quelques principes qui font la différence entre un outil adopté et un outil contourné.

La co-construction avec les métiers d’abord : partir de leur travail réel pour concevoir les workflows ensemble, pas imposer une logique IT venue d’en haut. Ensuite, accepter les variations : JSM est suffisamment flexible pour gérer des processus différents selon les contextes. Il n’est pas nécessaire de tout uniformiser pour unifier. Enfin, préserver des zones d’autonomie : certains processus sensibles ont des raisons légitimes de rester hors du portail commun. Reconnaître cette limite, c’est aussi une façon de construire la confiance avec les équipes concernées.

Et peut-être le plus important : l’Enterprise Service Management ne doit pas transformer les RH en gestionnaires de tickets. Leur valeur ajoutée reste dans l’écoute, le conseil, l’accompagnement humain, des dimensions qu’aucun SLA ne mesure vraiment.

La vraie question n’est pas technique. Elle est humaine et organisationnelle : votre entreprise est-elle prête à unifier ses services sans uniformiser ses métiers ?

Articles recommandés

Feedback client : au-delà de la data, la question de la reconnaissance

Feedback client : au-delà de la data, la question de la reconnaissance

Dans un atelier avec une équipe produit d'une dizaine de personnes, j'ai posé une question simple : « Qui parmi vous connaît le nom du client qui a signalé le problème de connexion en novembre ? » Personne n'a levé la main. Le ticket existait pourtant, référencé,...

Contact

1 + 15 =