L’ITSM répond à un problème que nous avons tous connu au moins une fois dans notre vie professionnelle. Un ordinateur qui ne redémarre pas, une demande de réparation envoyée par e-mail (depuis un téléphone) et une réponse trois jours ouvrés plus tard…

Qu’on appelle l’IT Service Management par son acronyme (ITSM) ou par son nom francisé (gestion des services informatiques), la réalité qu’il désigne reste la même : il s’agit de la façon dont une équipe IT organise, fournit et améliore les services qu’elle rend au reste de l’entreprise.

Le sujet concerne autant les DSI de grands groupes que les responsables informatiques de PME qui gèrent 200 postes à deux avec un tableur. Cet article fait le tri entre référentiels, processus et outils, et surtout entre ce qui doit venir en premier et ce qui peut attendre.

ITSM : définition et principe de fonctionnement

L’IT Service Management (ITSM), ou gestion des services informatiques, regroupe les pratiques par lesquelles une équipe informatique conçoit, fournit, exploite et améliore les services qu’elle met à disposition de ses utilisateurs.

Le mot déterminant est « service ».

  • Une approche classique raisonne en composants : serveurs, licences, postes de travail.
  • Une approche ITSM raisonne en prestations rendues : la messagerie, l’accès au CRM, la mise à disposition d’un poste pour un nouvel arrivant. Ce basculement change la mesure de la qualité, puisque l’indicateur n’est plus la disponibilité d’une machine mais la capacité de l’utilisateur à travailler.

Par exemple, une demande de nouvel ordinateur portable suit un chemin balisé : passage par un portail ou un catalogue de services, création d’un ticket, validation hiérarchique si le montant l’exige, préparation puis attribution du matériel, mise à jour de l’inventaire. Le même événement traité sans ITSM produit un mail à une adresse générique et un délai imprévisible. L’ITSM ne se confond donc pas avec le support : celui-ci traite les incidents, l’ITSM organise tout le cycle de vie des services, y compris ce qui précède l’incident.

Tableau : les différents processus de gestion des services informatiques

ProcessusCe qu’il résoutExemple typique
Gestion des incidentsRétablir un service indisponibleServeur de messagerie inaccessible
Gestion des problèmesÉliminer la cause racine récurrentePannes réseau répétées chaque semaine
Gestion des changementsMaîtriser le risque lié aux modificationsMise à jour d’un système d’exploitation
Gestion des demandesTraiter les demandes courantesCréation d’un compte pour un nouvel utilisateur
Gestion des actifs et de la configurationMaintenir à jour l’inventaire informatique et ses relationsEnregistrement des équipements et des licences

Les référentiels qui encadrent l’ITSM

Trois référentiels dominent le domaine :

ITIL (Version 5)

Le référentiel ITIL (« Information Technology Infrastructure Library » en anglais) est né au milieu des années 1980, à la demande de la Central Computer and Telecommunications Agency, une agence du gouvernement britannique, sous la forme d’une collection d’ouvrages de bonnes pratiques. Plusieurs révisions ont suivi. La plus structurante reste ITIL 4, parue en 2019 : elle abandonne la logique de « processus » au profit de 34 « pratiques » de gestion et élargit la lecture de la création de valeur.

PeopleCert, qui édite aujourd’hui le référentiel, a annoncé une nouvelle version, officiellement baptisée ITIL (Version 5), dont les publications s’échelonnent sur 2026. Les premiers éléments rendus publics annoncent un glissement vers la gestion des produits et des services, un nouveau cycle de vie et un module consacré à la gouvernance de l’IA ; les 34 pratiques, elles, restent en place. Pour une entreprise qui démarre, ITIL 4 demeure la base de travail la mieux documentée.

ISO/IEC 20000-1

C’est la voie à suivre dès qu’une certification d’entreprise est exigée, dans un appel d’offres par exemple. La norme ISO/IEC 20000-1:2018, déclinée en France sous la référence NF ISO/IEC 20000-1, fixe les exigences applicables à un système de management des services : planification, conception, transition, fourniture, amélioration. Héritée de la norme britannique BS 15000, elle fait l’objet d’audits menés par des organismes accrédités, parmi lesquels AFNOR Certification.

COBIT et autres cadres de référence

Publié par l’ISACA depuis 1996, COBIT (Control Objectives for Information and Related Technologies) se situe du côté de la gouvernance et du contrôle du système d’information, pas de l’exécution quotidienne. Il intéresse avant tout les entreprises soumises à de fortes exigences d’audit. D’autres cadres circulent selon les contextes, du Microsoft Operations Framework aux approches SIAM pour les environnements multi-fournisseurs. Le choix, d’ailleurs, est rarement exclusif : beaucoup d’entreprises s’appuient sur ITIL pour l’opérationnel, sur COBIT pour la gouvernance, et visent la certification ISO/IEC 20000-1 quand le marché l’impose.

Ce que l’ITSM apporte, et ce qu’il ne règle pas

Retours d’expérience et littérature professionnelle convergent sur un point : les premiers gains sont opérationnels.

Les processus ITSM au quotidien

Les processus ITSM couvrent tout le cycle de vie d’un service, de la demande initiale jusqu’au retrait. L’ITSM n’impose pas de liste fermée : les pratiques retenues, et le degré de formalisme appliqué, dépendent de la taille de l’organisation et de ses besoins réels. ITIL 4 ne parle d’ailleurs plus d’un nombre fixe de « processus ITSM » mais d’un catalogue de 34 pratiques de gestion (management practices).

Cela dit, 5 d’entre elles reviennent dans presque toutes les mises en œuvre. La plupart sont formalisées dans ITIL ; nous les résumons ici sous l’angle de ce que chacune permet de régler.

Gestion des incidents et des demandes de service

Ce processus se déclenche dès qu’un service cesse de fonctionner comme prévu : une application tombée, une imprimante réseau injoignable, un VPN qui refuse de se connecter. L’objectif est de rétablir le service au plus vite, en priorisant selon l’impact sur l’activité plutôt que sur la cause racine, traitée ensuite par la gestion des problèmes. Le détail des étapes se trouve dans notre guide sur la gestion des incidents.

Gestion des problèmes

Ce processus s’attaque à la cause sous-jacente quand plusieurs incidents partagent une même origine. Par exemple, si la messagerie d’entreprise tombe à répétition, la gestion des incidents rétablit le service à chaque coupure ; la gestion des problèmes, elle, cherche à comprendre pourquoi le phénomène se produit et à supprimer la cause pour de bon.

Gestion des changements

Ce processus fixe la marche à suivre pour valider, tester et déployer toute modification sur un système critique : mise à jour logicielle, changement de configuration réseau, migration de serveur. L’enjeu est d’éviter qu’un changement mal préparé ne provoque de nouvelles interruptions.

Gestion des demandes de service

Ce processus prend en charge les demandes courantes des utilisateurs, celles qui ne relèvent pas de l’incident : arrivée d’un nouveau collaborateur, demande de licence logicielle, réinitialisation d’un mot de passe. Il s’appuie généralement sur un catalogue de services et un portail en libre-service, qui accélèrent le traitement des demandes répétitives.

Gestion des actifs informatiques et des configurations

Ce point recouvre en réalité deux disciplines liées, mais distinctes :

  • La gestion des actifs informatiques (ITAM), traite le cycle de vie du matériel, des logiciels et des licences : ce qui existe, où ça se trouve, qui l’utilise.
  • La gestion des configurations de service, elle, documente les relations entre ces éléments et les services qu’ils font tourner. Quels serveurs, quelles licences et quels postes précis soutiennent l’application de facturation, par exemple.

La gestion des actifs informatiques, une condition préalable mais souvent négligée

Bon nombre de projets ITSM butent sur le même point : personne ne sait exactement ce que l’entreprise possède. Postes non déclarés, licences payées pour des salariés partis, matériel prêté sans trace de retour. Tant que ce socle n’est pas fiable, la gestion des changements travaille à l’aveugle et la gestion des incidents perd du temps à identifier la configuration concernée.

Reconstituer cet inventaire suppose trois choses : une identification physique des actifs informatiques (via étiquettes à QR-code ou codes-barres), une saisie possible depuis le terrain plutôt que depuis un bureau, et un historique par actif regroupant l’attribution, la maintenance et la fin de vie.

C’est le champ couvert par un logiciel de gestion des actifs informatiques comme Timly, qui centralise le parc informatique et matériel, associe à chaque équipement son utilisateur, son emplacement et ses interventions, et intègre un système de ticketing pour les demandes de maintenance. Il ne remplace pas une suite ITSM complète avec catalogue de services et gestion des changements, mais il fournit la donnée d’inventaire fiable sans laquelle ces processus tournent à vide.

Les 6 étapes pour mettre en place une démarche ITSM

  1. Recenser les services rendus : une liste de dix à quinze lignes suffit pour commencer, formulée du point de vue de l’utilisateur, pas de la technique.
  2. Faire l’inventaire du parc informatique : ordinateurs, licences logicielles, contrats, garanties, attributions etc.
  3. Créer un point d’entrée unique : un portail ou une adresse unique, avec suppression progressive des demandes par messagerie directe.
  4. Formaliser deux processus, pas dix : les incidents et demandes de service d’abord ; les problèmes et les changements viennent ensuite.
  5. Fixer des engagements réalistes : mieux vaut un délai tenu à 90 % qu’un délai ambitieux tenu à 40 %.
  6. Mesurer, puis élargir : les indicateurs orientent la suite du projet plus sûrement qu’un plan sur trois ans.

Faut-il structurer sa gestion des services informatiques, et à partir de quand ?

Ni la taille ni le secteur ne déclenchent la démarche : c’est la perte de traçabilité. Le jour où plus personne ne sait de mémoire répondre à « où en est cette demande ? » ou « qui utilise ce portable ? », l’informel coûte plus cher que la structuration. Pour une petite structure sans contrainte réglementaire forte, un inventaire fiable et un canal unique de demande suffisent souvent à démarrer.

Au-delà, l’ordre dans lequel on avance compte davantage que le choix de l’outil. Un inventaire fiable, deux processus formalisés et cinq indicateurs suivis donnent plus de résultats en six mois qu’une suite complète déployée sur des données bancales. C’est d’ailleurs pour cette raison qu’une solution de gestion des actifs comme Timly se met en place avant la brique ITSM à proprement parler : elle règle la question des données pendant que les processus se stabilisent.

Foire aux questions

Non. Les certifications ITIL sont individuelles et attestent d’une compréhension du référentiel, pas d’une conformité de l’entreprise. Elles servent surtout à partager un vocabulaire commun, notamment lors du recrutement d’un responsable de service desk. Pour une reconnaissance de l’entreprise, c’est vers ISO/IEC 20000-1 qu’il faut se tourner.

Ils poursuivent des objectifs différents plutôt que contradictoires : le DevOps optimise la vitesse de livraison entre développement et exploitation, l’ITSM la fiabilité et la qualité de service rendue aux utilisateurs. La plupart des entreprises combinent les deux, avec des processus de changement allégés pour les déploiements à faible risque et un cadre plus strict pour les modifications sensibles.

Les usages les plus matures concernent la catégorisation et le routage automatiques des tickets, les agents conversationnels de premier niveau et l’aide à la rédaction d’articles de base de connaissances. La détection prédictive des pannes progresse, mais sa qualité dépend directement de la propreté des données historiques : un historique d’incidents mal catégorisé produit des prédictions sans valeur.