Catalogue des services ICT

Quoi, pourquoi?

Pascal Kotté
Mar 28 · 11 min read

Ce n’est pas limitatif aux grosses organisations

Que vous soyez une startup de 3 personnes, une association de 5, une PME micro-entreprise de moins de 10, une petite de moins 50, une moyenne de moins de 250, et encore plus utile, si bien plus. Il est nécessaire de gérer la liste des applications, matériels et des savoirs requis pour faire fonctionner la partie numérique de votre organisation.

C’est le “(IT) Service catalog” ou “catalogue des services” (numériques)

Dans les associations que je soutiens, c’est un simple document texte avec l’énumération des services mis en oeuvre, par chapitre et paragraphes (Y compris pour des ébauches ou propositions de services à venir).

Quand on y inclue des “services proposées ou à venir”, cela devient un “project portfolio” en plus d’être un “catalogue des services”. Dans des grosses structures, on sépare cela (“Service portfolio” et “service catalog”). Mais dans les structures plus réduites ce sont les mêmes acteurs, et donc profitons-en pour “réduire les infobésités”.

Bien trop de petites structures, ne disposent pas de ce document ou l’information est disséminée dans multiples espaces, ou pire, dans l’historique d’emails de multiples personnes…

Mais quelles informations avec cette liste des services, pour quels usages, et comment ne pas se créer une surcharge de travail inutile?

Car si on fait un tableau, pénible à maintenir, que personne ne va utiliser, est-ce donc bien utile?

Les usages du catalogue des services numériques

Au-delà des recommandations des “cabinets de conseils” Gartruc, CapMachin, McBidule, et l’usage des “meilleures pratiques” ITIL, FitSM, ISO, SPICE et autres, inutilisables en Micro/PME; Cette table des services est avant tout une simple “check-list”.

Qu’est-ce que je dois gérer?

Et est-ce que je le fais (assez) bien?

Rendre visible l’invisible

La fourniture de services parfois “simples”, nécessitent des infrastructures complexes, surtout pour assurer une bonne disponibilité et sécurité.

Questionner l’utilité et la criticité, tout en gardant la finalité à l’esprit: Par exemple: L’accès à l’annuaire téléphonique! Qui est généralement inclus dans le service “Accès à l’Internet”, alors que peut-être certains postes (utilisateurs) ne l’utilisent que pour cela et de façon critique. Il va falloir donner un accès à Internet, mais si c’est critique, il faut une redondance (si nombreuses personnes), tout en protégeant les postes clients et le réseau… Or un abonnement à un CDROM annuel (Twixtel) peut réduire la nécessité de redondance, en plus de réduire le traffic des données. Un abonnement data depuis un mobile et un câble USB peut aussi suffire...

Visibilisations

Infra to Business: En listant les services “sous-jacents” nécessaires pour le bon fonctionnement du service “pour le métier” demandé, on donne une visibilité aux métiers sur des “objets” méconnus à part le terme “réseau”, éternel coupable de leurs difficultés à utiliser leurs propres services… (Et en général, ce n’était pas notre réseau le coupable!)

Business to IT: Mais c’est aussi un moyen pour l’IT de mieux comprendre les attentes des “métiers” (l’accès à un annuaire/bottin, n’est pas la même demande que d’accéder à Internet). Ce dernier aspect est souvent “oublié” dans le catalogue de services. Clarifier les pourquoi au niveau des usages, et d’en définir la criticité:

  • On peut vivre, ou survivre, sans pendant: 2h, 4h, 8h, 24h, 2 jours, 1 semaine, 1 mois ou toujours (via un plan B, ou car non vital)?
  • Quelle est la perte en cas de dépassement, en équivalent financier de préférence (et malheureusement): Chômage technique, dégâts d’image, pertes de ventes, frais juridiques, surcharges et mandats de “récupérations”… Si possible, par unité de dépassement: Si prévu 4h, combien va coûter +4h de dépassement de dysfonctionnement? (La réalité est rarement “linéaire”, mais on simplifie…)

En explicitant les impacts métiers, on peut mieux dimensionner les moyens de réduction des risques, ou réduction des délais de reprise…

La classification va donc devoir intégrer les données suivantes:

  • Métier/Infra: classiquement, une information “binaire”. Est-ce que c’est associé à des “clients” ou purement géré en interne par l’IT? (Sauf que parfois, c’est plus subtil, et du coup, il m’arrive de mettre 100 si purement “business” et “0” si pure IT, et 20, 40, 50 ou 80 si plus nuancé…)

Nous faisons souvent des choix binaires, et un catalogue de services exposé aux métiers n’affichera souvent pas les éléments “Infra”. On peut par exemple convenir que 60%+ c’est métier et dessous, ce sera infra… Mais ma préférence, est d’expliquer aux “business” les services infras, et de les leur afficher! Comment leur expliquer les coûts sinon.

  • Importance+Criticité: L’importance d’une chose n’est pas proportionnelle à son coût, mais au prix de son arrêt/période de durée. Par exemple: Le renouvellement d’un nom de domaine. On peut éclater en 2 critères: Importance et durée de tolérance d’incident avant que cela devienne réellement insupportable.

Car l’importance et la résistance aux pannes, ne sont pas nécessairement corrélées, et parfois, c’est plus subtil: La paye peut rester en panne 3 semaines, si c’est en début de mois, mais pas 24h en fin de mois… Basiquement, si le service met au chômage technique partiellement ou complètement une partie du personnel, facile d’en calculer le coût horaire/journalier. Mais il est nécessaire d’évaluer l’impact sur les services à la clientèle: Cela va se voir, générer de la “grogne”, ou pas?

  • Dépendances: les codes/désignations (courtes) des services d’infrastructures (ou pas) requis “up & run” pour que cela fonctionne

Cela peut faire 1 grosse liste, les coder avec 1, 2 ou 3 lettres mnémonique est une de mes stratégies préférées pour tenter de garder cela “simple”: ex. “INT,NET,DNS,DHCP”).

  • Cloud, ou pas: 0 = Même pas besoin d’Internet (ex. Twixtel), 1 = Pas nécessaire pour fonctionner, mais il reçoit infos et mise à jour par le Net, 2 = hybride, l’application a toutefois besoin d’internet pour fonctionner, même avec une application locale, 3 = Totalement cloud, rien sur le poste.

Faciliter l’accès à la documentation et au support

Pour reconstruire une nomenclature compréhensive par les usagers, le business, il est intéressant de regarder les dossiers et outils de partage de la documentation technique. Si l’entreprise dispose d’un helpdesk ou d’un service desk assisté par ordinateur, alors son catalogue et catégorisation des services mis à disposition, devrait être le reflet du catalogue des services.

L’idéal sera de ne pas le limiter à l’IT, et l’étendre aux services généraux et RH.

Quand le département informatique n’a pas (encore) de plateforme logiciel pour gérer les demandes et les incidents, il centralise la documentation technique, et les informations de configuration, dans un dossier partagé, rarement accessible par les usagers (ou avec leur propre dossier/intranet).

On y place aussi les codes d’accès aux équipements, aux consoles de gestion et de configuration. Parfois avec un coffre à mot de passe correctement sécurisé.

Le catalogue de service peut pointer vers les informations essentielles:

  • Le dossier de la documentation technique interne (et sa désignation)
  • Le dossier/page web de la documentation utilisateur
  • Les procédures d’escalades et de traitements des incidents, avec les bons contacts et les bonnes marches à suivre.

Planifier les droits d’accès

Le catalogue des services permet d’identifier les “destinataires” (utilisateurs, postes clients, terminaux) et les “sponsors” (payeurs), définis pour chaque service. Et donc, de planifier les “droits d’accès” pour les utilisateurs, et les administrateurs (ceux qui savent qui est censé avoir accès à quoi!).

  • Du coup, le catalogue de service est censé être en relation avec le nom des groupes dans un annuaire de comptes utilisateurs (Active Directory, LDAP)

Cela est oublié bien trop souvent, car mis “de facto” dans l’AD. OK, super, et comment je valide que l’AD ne comprend bien “que” les bonnes personnes?

Autre point à surveiller, utiliser les mêmes termes: C’est déjà assez le bazar sans avoir des noms différents entre les groupes, le budget, le catalogue des services et le nom des dossiers dans la documentation technique…

Y associer mes groupes de données

L’idéal est de pouvoir connecter ou y intégrer mon inventaire des données, afin d’en extraire les volumes de données associées, et leurs criticités, qui n’est pas nécessairement celles du service qui opère ces données… Mais souvent quand même :)

Je vais pouvoir aussi localiser ces données, et vérifier que leurs réplications (mes sauvegardes, s’il en est) ne va pas dans le même datacentre que l’application qui les exploite et les stockerait, au même endroit! Cela arrive… Et quand le datacentre brûle on pleure de le découvrir…

Mesurer les performances, les consommations

Quand le catalogue de service est connecté à une plateforme de service-desk, il est possible de mesurer les demandes, et les incidents, associés à un service donné, va permettre de mesurer les évolutions dans le temps (les années) et de repérer d’éventuels points d’amélioration: Préventions et réductions d’incidents, ou automatisation d’opérations répétitives en volume suffisant.

Sans Service-desk, il est possible de mesurer les incidents, en complétant manuellement un incrément dans ce catalogue des services. Idem pour les demandes

La mesure des “disponibilités” des services, est difficilement géré de façon efficiente avec un service-desk, il sera préféré un “monitoring” automatisé, si celui-ci est facilement accessible et mis en oeuvre.

Vérifier mes budgets

Requis: Si la compta le permet, établir des comptes, ou des étiquettes (tags) qui reprennent le code du service.

Ce catalogue peut servir d’interface entre la finance, les métiers et l’IT, non seulement au niveau des services visibles, mais aussi pour rendre visible les infrastructures incomprises et méconnues. Pour la finance, mais aussi pour les métiers, surtout si ce sont eux qui décident leurs propres budgets, le challenge est de rendre transparent les coûts des services exploités, ou demandés. Pour chaque service:

  • Est-ce que je vais devoir planifier une mise à niveau (couteuse) dans les années à venir?
  • Est-ce que mes frais de maintenance (OPEX) effectifs sont-ils conformes à ce qui était prévu? Et est-ce que je dois ajuster les réserves opérationnelles pour les années suivantes?
  • Est-ce que j’ai bien distribué mes coûts des services “sous-jacents” (infra) aux services “métiers” dans le catalogue des services “visibles” pour eux, afin de bien rendre visible “les vrais coûts” de leurs services?
    (C’est optionnel, mais je le recommande)

Normalement, une migration, c’est un projet, mais quand le projet remplace ou améliore un service existant, il entre dans la planification des services. En ajoutant dans ce même catalogue, les services “envisagés” ou “prévus” dans les années à venir, on triche un peu avec les standards pour établir un véritable “tableau de bord” des services ICT.

Photo by Rodion Kutsaev on Unsplash

Comment construire un catalogue de service simple?

Regroupement et granularité

C’est la principale difficulté: Votre “code de service” doit regrouper dans un même service la totalité des composants nécessaires pour assurer le “service” concerné. Si des composants matériels ou immatériels, servent à soutenir plusieurs services différents, alors cela devient une entrée de service à part entière, de type “infra”.

Est-ce que je peux regrouper 3 applications différentes, qui sont utilisées par les même personnes? Oui! Facturations+Compta+Paye, peuvent devenir “compta” et regrouper les 3 logiciels, et c’est même vivement recommandé.

Est-ce que je peux regrouper mes services DNS, DHPC car ils sont associés à la même liste de services “business”? Oui! Et même mieux, si tous les éléments “Réseaux LAN” sont concernés, on peut regrouper les matériels avec. Si une ventilation des coût est toutefois maintenu par département, spécifiquement, il sera probablement nécessaire de séparer un par département. Toutefois, il sera préférable de laisser la reventilation par département à un outil financier externe, que de le gérer dans le catalogue de services.

Est-ce que je sépare en deux le même service utilisé par 2 départements? De préférence, Non! Mais si ma structure de données ne me permet pas de distribuer les coûts pour chaque département, et que j’ai besoin de les séparer, alors OUI, faire 2 entrées dans le service catalogue, et réfléchir à améliorer la structure des données pour l’éviter.

De façon générale, si un service est identique pour multiples groupes différents, il peut être très tentant de faire une ligne par groupe, et un service avec le code du groupe destinataire concaténé. Ce n’est pas faux, mais si le service tourne sur les mêmes ressources, fonctionne avec le même groupe de données, avec les mêmes sauvegardes, alors, c’est que c’est un seul et même service, distribués à plusieurs groupes de personnes qui ensemble, sont les destinataires du même service.

Pensez data! Et flux de données…

Mon service de backup comprend 2 serveurs, 3 lecteurs de bandes, et plusieurs logiciels dont de nombreux agents sur multiples machines. Il traite de nombreux jeux (groupes) de données, issu de multiples services. Des logiciels Windows et Macs, assurent des images de machines critiques sur un NAS, et de plus, j’ai plusieurs outils qui assure des réplications sur un NAS de sauvegardes, lequel est aussi mis sur cartouches et sauvegardé par le backup. Malgré la disparité des systèmes et multiplicité des solutions, est-ce que je peux considérer mon backup comme un seul et même service de type “infra”?

Oui! Bien évidemment… Plus on réduit le nombre de services, mieux cela sera, surtout pour les éléments d’infra. Ainsi, le service “LAN” (Local Area Network) peut inclure la totalité des Switchs et routeurs matériels, les serveurs virtuels DC, DNS et DHCP avec leurs logiciels, le système de câblage UTP et fibres, les alimentations électriques avec onduleurs secourus, les firewalls…

Etendre le service catalogue

Dans l’objectif de simplexifier l’intégration des autres objets nécessaires dans le pilotage de l’IT.

Budgets

Le catalogue de service ne sert pas à gérer le budget, mais en y intégrant les coûts on peut en surveiller l’adéquation au budget prévu. Il est toutefois probable que la compta soit difficile à recoller avec l’inventaire. Ne pas essayer si c’est le cas, à moins d’y voir un réel intérêt (contrôler les factures?). Cependant, si on peut intégrer une étiquette “service” ou bien dédier un compte pour chaque, alors il sera possible d’extraire les frais effectifs de l’année en cours, et de l’année précédente, la somme pour chaque service. S’il est possible d’avoir les distinctions entre OPEX et CAPEX, ce sera bien, sinon, il faudra s’en passer. En IT nous devons gérer une base des contrats, et abonnements, avec date et délais de renouvellements, et de résiliation. Ils représentent nos OPEX et nous sommes censés les connaître en amont. En y ajoutant le code du service, le fichier des contrats pourra s’intégrer dans le catalogue des services et aider à préparer le budget des années à venir (3 max?).

On peut alors intégrer, les frais totaux observés par service, l’année précédente, et la somme des OPEX prévu cette année pour ce service. La soustraction peut donner une proposition de CAPEX. Mais c’est l’inventaire et la vérification des renouvellements prévus d’acquisitions, qui va donner le ton. Ensuite, c’est l’expérience qui ajustera avec du bon sens…

Sauf, qu’il faut aussi intégrer les changements, issus des projets.

Intégration des projets, pour les budgets à venir.

Le catalogue de service peut suppléer d’autres éléments qui seraient absents de l’organisation, afin de planifier les budgets futurs. Un onglet projets, confirmés ou probable, avec l’année de mise en service et un budget prévisionnel: Avec l’affectation à un service existant, à modifier, ou bien la création d’un nouveau service. Le projet doit donner les frais CAPEX prévus, mais aussi l’ajustement de l’OPEX à venir, en plus ou en moins suite à ce changement.

Extensions aux autres départements

Des services généraux, des services juridiques, des services graphistes et rédacteurs, RP, etc, peuvent aussi proposer leurs services qui utilisent souvent un outil numérique partagé (email), ou dédié (formulaire). L’exposition d’un catalogue de services n’est pas nécessairement une affaire complexe et lourde, et peut passer par une plateforme simplifiée de service-desk. Cela permet aux utilisateurs de disposer d’un seul espace pour introduire ses demandes.

Cela reste une couche supplémentaire au-dessus du catalogue de services de l’IT, englobant d’autres départements. Cette surcouche n’exposera qu’une petite partie des services gérés par l’IT, où l’utilisateur, ou bien le demandeur, doit généralement simplement remplir un formulaire/questionnaire (qui génère un simple email par exemple) et qui permet de qualifier correctement la demande pour permettre à l’IT de la servir sans devoir faire d’autres “aller-retours”. Certaines requêtes avec des services externalisés sont émises directement et en copie l’IT.

Bref le catalogue de service, est la brique fondamentale d’une organisation IT organisée.

Photo by Ibrahim Boran on Unsplash

Conseillers Numériques Suisses Romands

Le réseau des experts indépendants du digital pour des…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store