
Le catalogue de services comme contrat entre IT et métiers
Situation illustrative : un lundi matin, les ventes signalent qu’une application critique ralentit. L’IT répond que l’infrastructure respecte ses seuils. Le fournisseur affirme que son contrat exclut les interfaces. Le métier découvre que l’assistance renforcée n’est prévue qu’aux heures ouvrées d’un autre pays. Chacun a techniquement raison, mais l’entreprise reste bloquée. Le problème n’est pas seulement l’incident : personne n’a défini le service attendu de bout en bout. Pour le DSI, le catalogue de services doit précisément combler ce vide. Non comme une vitrine de prestations, mais comme un contrat opérationnel entre ceux qui produisent, utilisent, financent et sécurisent l’IT.
Le vrai service n’est pas un composant
Les équipes techniques raisonnent volontiers en serveurs, applications, réseaux ou tickets. Le métier attend une capacité : encaisser une commande, payer un fournisseur, intégrer un salarié, restaurer une activité. Tant que le catalogue décrit des composants, il laisse ouverte la question essentielle : quel résultat l’IT s’engage-t-elle à rendre possible ?
Le DSI doit donc partir des parcours critiques et nommer des services compréhensibles. « Accès ERP » est trop vague si l’utilisateur ignore les fonctions couvertes, les populations éligibles, les horaires, le support et les dépendances. À l’inverse, « traitement des commandes clients » permet de préciser le périmètre, les exclusions, les responsabilités et les modes dégradés. Ce changement paraît sémantique ; il déplace pourtant la discussion de la disponibilité d’un outil vers la continuité d’une activité.
Rendre visibles les responsabilités et les renoncements
Un catalogue utile dit ce qui est fourni, mais aussi ce qui ne l’est pas. Il précise les bénéficiaires, zones géographiques, plages de service, environnements, volumes de référence, délais de prise en charge, niveaux de priorité et canaux d’escalade. Il distingue l’engagement de l’IT, celui du fournisseur et les prérequis du métier. Sans cette symétrie, le service devient une promesse unilatérale impossible à tenir.
Chaque choix révèle un compromis. Étendre une assistance la nuit augmente la protection d’une activité internationale, mais mobilise des équipes ou renchérit un contrat. Raccourcir un délai de restauration suppose une architecture, des tests et des procédures adaptés. Le catalogue oblige ainsi le dirigeant à faire arbitrer le niveau de service au lieu de laisser l’urgence décider implicitement. Refuser une exigence disproportionnée devient alors une décision gouvernée, non une défaillance cachée.
Construire le catalogue par décisions successives
La première étape consiste à sélectionner quelques services dont l’interruption affecterait directement une opération essentielle. Pour chacun, un atelier réunit responsable métier, exploitation, support, sécurité, architecture et, si nécessaire, achats. Il décrit le parcours normal, les périodes sensibles, les dépendances, les incidents redoutés et le propriétaire de chaque décision.
La deuxième étape formalise une fiche courte : finalité, utilisateurs, demande standard, engagements, exclusions, responsabilités, continuité, escalade et critères d’évolution. La troisième confronte cette fiche aux contrats fournisseurs et aux capacités réelles. Un engagement absent des contrats, non testé ou sans équipe responsable n’est pas un engagement : c’est une dette de gouvernance. Enfin, le DSI fait valider les écarts, avec trois options explicites : investir, réduire la promesse ou accepter temporairement le risque avec une échéance de réexamen.
Mesurer l’expérience plutôt que la seule mécanique
Le respect d’une moyenne de disponibilité ne prouve pas qu’un service remplit sa fonction. Une panne brève pendant une clôture peut peser davantage qu’une interruption longue un dimanche. Les indicateurs doivent donc relier performance technique et effet opérationnel : nombre d’interruptions pendant les périodes critiques, délai de rétablissement de la capacité métier, demandes réouvertes, incidents récurrents, respect des délais par priorité, volume d’exceptions et satisfaction après résolution.
Deux mesures complètent ce tableau. Le taux de services disposant d’un propriétaire réellement actif révèle la qualité de la gouvernance. La part des engagements testés — reprise, escalade, fonctionnement dégradé — distingue les capacités démontrées des déclarations. Le comité de service ne doit pas commenter des courbes abstraites ; il doit décider quelles causes éliminer, quels engagements revoir et quels risques remonter.
Éviter le catalogue encyclopédique et l’accord fictif
L’erreur la plus fréquente consiste à lancer un recensement exhaustif. Le résultat est souvent un document massif, rapidement périmé, que ni le support ni les métiers ne consultent. Mieux vaut un périmètre limité, tenu à jour et relié aux décisions qu’une cartographie parfaite sans usage. Le catalogue métier présente les capacités et engagements ; le catalogue technique détaille les composants nécessaires à l’exploitation. Les confondre rend le premier illisible et le second insuffisant.
Autre piège : copier les SLA du prestataire dans la fiche de service. Le fournisseur peut respecter son obligation alors que l’expérience globale échoue entre plusieurs intervenants. Enfin, l’outil ITSM ne crée ni consensus ni responsabilité. Automatiser une ambiguïté produit seulement des demandes mieux tracées, pas un meilleur service.
Arbitrer sur une promesse soutenable
Au moment de trancher, le DSI ne cherche pas le niveau maximal partout. Il recherche une promesse cohérente avec la criticité, les moyens, les contrats et le risque accepté. Un service vital mérite des exigences fortes et éprouvées ; un service secondaire peut assumer des délais plus longs. L’équité ne consiste pas à offrir le même SLA à tous, mais à appliquer une logique explicite et défendable.
Cette discipline rejoint l’approche de gouvernance exposée dans Révolution Numérique ! : relier les choix technologiques aux enjeux réels, aux coûts, aux risques et aux dépendances. Le catalogue devient alors un instrument de direction. Il rend les attentes négociables, les écarts visibles et les décisions traçables. Surtout, il transforme le dialogue : l’IT ne promet plus que ses composants fonctionnent ; elle s’engage, avec les métiers, sur une capacité comprise, financée et vérifiable.
Pour approfondir
Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon
Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon
#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique





