ITIL, c'est quoi concrètement ?

Lundi matin. Un utilisateur appelle : « Je n’arrive plus à me connecter à l’application. » Il obtient trois réponses différentes de trois personnes différentes. Personne ne sait qui traite quoi. Deux jours plus tard, le même problème revient, et tout le monde a oublié comment il avait été réglé la première fois.

ITIL, c’est le recueil de bonnes pratiques qui existe précisément pour éviter ce genre de lundi matin.

Une bibliothèque, pas un logiciel

ITIL signifie Information Technology Infrastructure Library. Le mot important est le dernier : bibliothèque. Historiquement, ITIL est un ensemble structuré de bonnes pratiques en matière de gestion des services informatiques, dont les premières publications remontent à la fin des années 1980. Le cadre a été développé à l’initiative du gouvernement britannique, afin de formaliser et d’améliorer les pratiques de gestion des services informatiques, y compris chez ses prestataires.

Ce n’est donc ni un logiciel, ni une norme, ni une obligation réglementaire. C’est un livre de recettes : on y pioche ce qui sert, on adapte au contexte, on laisse le reste de côté.

Deux versions coexistent aujourd’hui. ITIL 4, publiée en 2019, est encore massivement déployée dans les organisations. ITIL Version 5 est sortie début 2026, avec une publication échelonnée sur l’année. Aucune date de retrait n’a été annoncée pour ITIL 4, et l’ossature est commune aux deux : ce qui suit reste valable dans les deux cas, je signale au passage ce qui bouge. Un article complet est dédié aux changements entre les deux versions.

L’idée centrale : l’informatique existe pour rendre un service

ITIL part d’un constat simple. Une direction informatique n’existe pas pour faire tourner des serveurs, mais pour permettre à quelqu’un de faire son travail.

Un radiologue ne se lève pas le matin en pensant au serveur d’imagerie. Il veut voir une image, vite et bien. Si le serveur est en parfait état de marche mais que l’image met quatre minutes à s’afficher, le service n’est pas rendu, même si tous les voyants sont au vert.

ITIL ajoute une nuance intéressante : cette valeur se co-crée. Le fournisseur ne la produit pas tout seul dans son coin. Si l’utilisateur ne déclare jamais ses incidents, ou contourne systématiquement le circuit prévu, le meilleur dispositif du monde ne servira à rien.

Ce qu’il y a dans la boîte

Quatre grands éléments structurent ITIL.

7 principes directeurs, qui constituent des repères de bon sens applicables dans de nombreuses situations : se concentrer sur la valeur, commencer là où vous êtes, progresser par itérations avec des retours, collaborer et promouvoir la visibilité, penser et travailler de façon holistique, rester simple et pratique, optimiser et automatiser. Ces sept principes, déjà centraux dans ITIL 4, sont conservés dans ITIL 5.

4 dimensions à ne jamais oublier quand on conçoit un service : les organisations et les personnes, l’information et la technologie, les partenaires et fournisseurs, les flux de valeur et processus. Autrement dit : un projet purement technique qui ignore les personnes échouera. Elles sont conservées elles aussi dans ITIL 5.

Un système de valeur, qui décrit comment l’organisation transforme les opportunités et les demandes en valeur. C’est ici que se situe le principal changement de la version 5 : le système de valeur des services (Service Value System) devient le système de valeur ITIL (ITIL Value System), et la chaîne de valeur et ses six activités laisse place au modèle de cycle de vie des produits et services (Product and Service Lifecycle Model) et ses huit activités. Le modèle fonctionne désormais comme une boucle plutôt que comme une chaîne : ce qu’on apprend en exploitation et au support remonte directement vers la conception, sans attendre une revue formelle.

34 pratiques, dont les noms sont inchangés d’une version à l’autre. Une petite dizaine constitue le quotidien de la plupart des équipes : gestion des incidents, centre de services, gestion des demandes de service, gestion des changements, gestion des problèmes, gestion des niveaux de service, gestion des actifs informatiques.

Un exemple vaut mieux qu’une définition

Trois sollicitations arrivent le même matin :

« Ma messagerie ne s’ouvre plus. » C’est un incident : un service est dégradé ou interrompu. L’objectif est de rétablir le service le plus vite possible, quitte à passer par une solution de contournement.
« J’ai besoin d’un accès à l’application de gestion documentaire. » C’est une demande de service : rien n’est cassé, c’est une prestation prévue et cataloguée, avec un circuit de validation connu et un délai annoncé.
« On veut monter la version du serveur applicatif ce week-end. » C’est un changement, traité par la pratique de gestion des changements : on évalue le risque, on planifie, on prévoit une procédure de retour arrière.

Trois natures, trois traitements, trois niveaux d’urgence. Sans cette distinction, tout atterrit dans la même boîte mail, et le changement risqué passe aussi vite qu’une demande d’accès. C’est là que les incidents naissent.

Et l’intelligence artificielle ?

C’est l’autre grande nouveauté d’ITIL 5, conçue nativement autour de l’IA (« AI-native » dans la documentation officielle). Là où ITIL 4 mettait notamment en avant le principe directeur « optimiser et automatiser », ITIL 5 introduit une gouvernance de l’IA et un modèle de capacités dédié. Le périmètre s’élargit au passage : on ne parle plus seulement de gestion des services informatiques, mais de gestion des produits et services numériques.

Pour une équipe qui débute, ce n’est pas nécessairement le sujet prioritaire : les fondamentaux de la gestion des services restent indispensables. En revanche, pour une organisation qui commence à intégrer des assistants IA, des agents ou de l’automatisation dans ses produits, ses services ou son support, cette évolution apporte un cadre pour réfléchir non seulement à ce que l’IA peut automatiser, mais aussi à la manière de la gouverner et de créer de la valeur avec elle.

Ce qu’ITIL n’est pas

Quatre malentendus reviennent systématiquement.

ITIL n’est pas un logiciel. Un outil peut être certifié comme supportant certaines pratiques mais cette certification porte sur ses fonctionnalités, pas sur votre organisation. Les règles de traitement, les engagements et les responsables de service restent à définir.

Une entreprise ne se certifie pas ITIL. Seules les personnes passent des certifications. L’organisation qui veut une certification auditable se tourne vers la norme ISO/IEC 20000.

ITIL n’est pas un carcan. La devise consacrée est « adopter et adapter ». Déployer les 34 pratiques d’un bloc serait une très mauvaise idée, et personne ne le fait.

ITIL n’est pas réservé aux grandes DSI. Une équipe de trois personnes gagne déjà énormément à séparer incidents et demandes, et à écrire noir sur blanc ce qu’elle s’engage à faire.

Pour résumer

ITIL est un vocabulaire commun et une boîte à outils. Son intérêt principal n’est pas la conformité, c’est de permettre à une équipe d’arrêter de réinventer la même solution tous les six mois, et de dire clairement à ses utilisateurs ce qu’ils peuvent attendre.

Reste une question que je n’ai fait qu’effleurer ici : ces fameux « services » dont ITIL parle en permanence, qu’est-ce que c’est exactement ? C’est le sujet du prochain article, consacré à l’ITSM.