Pourquoi ce vocabulaire existe
Une équipe informatique de trois personnes se comprend sans vocabulaire commun. À dix, avec des prestataires et des utilisateurs qui demandent des choses, les mêmes phrases cessent de vouloir dire la même chose.
« Il y a un problème avec la messagerie » peut signifier : elle est en panne pour tout le monde, elle est lente pour une personne, ou quelqu'un voudrait une nouvelle boîte partagée. Trois situations, trois traitements, trois urgences.
Le vocabulaire qui suit ne sert donc pas à paraître sérieux. Il sert à ce que deux personnes qui lisent la même phrase fassent la même chose.
Le service, et pourquoi partir de là
Un service est ce que l'informatique rend à quelqu'un d'autre. La messagerie, la sauvegarde des postes, l'accès au logiciel de gestion, l'impression.
Ce n'est pas une machine, ni un logiciel. C'est une capacité vue depuis l'utilisateur. Cette distinction paraît abstraite et elle a une conséquence immédiate : personne n'appelle pour signaler qu'un serveur a redémarré, on appelle parce qu'on ne peut plus travailler.
Raisonner en services change ce qu'on mesure, ce qu'on surveille et ce qu'on écrit dans un ticket.
L'actif, et l'actif de configuration
Un actif est un bien que vous possédez : un portable, une licence, un commutateur. La question qu'il porte est comptable : combien, où, acheté quand, amorti comment.
Un actif de configuration, souvent abrégé CI dans la littérature, est un élément qui participe à un service et dont la panne ou la modification a un effet. La question qu'il porte est opérationnelle : de quoi dépend le service, et qu'est-ce qui casse si j'y touche.
Le même portable est les deux à la fois, mais pas pour les mêmes raisons. Un contrat de maintenance, lui, est un actif de configuration sans être un objet physique. Une base de données aussi.
Les quatre choses qui arrivent
Quatre objets, et la distinction se fait par un test simple : quelle est la question posée ?
L'incident : quelque chose ne marche plus. La question est « comment rétablir vite », pas « pourquoi ». Un contournement est une réussite.
La demande de service : quelqu'un veut quelque chose de prévu. Un accès, un matériel, une boîte partagée. Rien n'est cassé, la question est « selon quelle procédure et avec quelle autorisation ».
Le problème : la cause d'incidents qui reviennent. La question est « pourquoi », et elle se traite en jours ou en semaines.
Le changement : une modification volontaire de ce qui existe. La question est « qu'est-ce que cela risque de casser, et comment revient-on en arrière ».
Confondre incident et demande est l'erreur la plus coûteuse. Elles n'ont ni le même délai attendu, ni la même urgence, et les mélanger dans une seule file rend toute mesure fausse : un délai moyen calculé sur un mélange de pannes et de commandes de matériel ne décrit rien.
ITSM et ITIL, en deux phrases
ITSM (gestion des services informatiques) désigne la façon de gérer l'informatique comme un ensemble de services rendus, plutôt que comme un stock de machines. C'est une posture, pas un produit.
ITIL (le recueil public où ces pratiques sont décrites, écrit et réédité depuis les années 1980) est le référentiel le plus utilisé pour y parvenir. Il contient plusieurs dizaines de pratiques, et une PME en utilise utilement quatre ou cinq.
Retenez ceci, qui vous évitera des réunions inutiles : ITIL est une boîte à outils, pas un règlement. Personne n'est obligé de tout appliquer, et une équipe qui essaie s'épuise avant d'avoir rendu un service.
À retenir
Un service est ce que vous rendez, pas ce que vous possédez. Un actif se compte, un actif de configuration participe à un service. Quatre objets, distingués par la question posée : rétablir, fournir, comprendre, modifier. Et ITIL est une boîte à outils dans laquelle on pioche.