L'orientation Produit & Service ITIL 5, transformation de la gestion des changements

« Le projet est un fantasme. Le RUN, c’est la réalité. »

ITIL 5 clarifie enfin ce que beaucoup de DSI vivent sans le nommer. Un service numérique repose sur un produit numérique. Et la valeur ne se joue pas au moment de la livraison, mais dans la durée, au contact des usages.  
En plaçant explicitement le produit au centre, ITIL 5 propose un cadre qui relie conception, transition, exploitation et support dans une même continuité. On ne parle plus d’un passage de relais entre projet et RUN. On parle d’un cycle de vie partagé, où l’exploitation n’est plus un après, mais une obligation de conception.

Cette bascule change profondément la pratique de gestion des changements.  
Dans une lecture encore fréquente d’ITIL 4, le changement ressemble à un guichet de mise en production. On contrôle une date, un périmètre, une conformité.  
ITIL 5 pousse une autre logique. Le changement devient une capacité de pilotage du risque sur l’ensemble du cycle produit et service. Il s’agit d’évaluer, d’arbitrer, d’autoriser et de synchroniser des changements qui impactent réellement la valeur délivrée. Pas uniquement de sécuriser une bascule technique.

Dans cet article, nous proposons une lecture directe de cette importante redéfinition et de ses conséquences concrètes pour organiser la DSI, gouverner les décisions, et concevoir des solutions opérables.  

1. ITIL 4 parlait de produit, mais ne structurait pas l’IT autour de lui

ITIL 4 a ouvert la porte au vocabulaire du produit. Beaucoup d’équipes l’ont vu comme un signe de modernité. Pourtant, sur le terrain, l’ossature restait majoritairement orientée service.

Le service comme unité de pilotage. Le catalogue comme interface. Les engagements (SLA/OLA) comme centre de gravité. Résultat, le produit a souvent été traité comme un arrière-plan technique. Un moyen de construire le service, pas un objet de responsabilité à part entière.

Cette asymétrie a des effets très concrets. Les décisions se concentrent sur la livraison. Les arbitrages se font sur une date et un périmètre. La question de l’exploitabilité arrive tard … trop tard !  
Souvent quand les premières alertes et les premiers incidents tombent. On demande alors au RUN de stabiliser, avec trop peu de marge de manœuvre et avec une dette de conception déjà figée. Dans ce contexte, la gestion des changements dérive vite vers un rôle de contrôle. Un guichet qui protège la production. Un rituel de conformité. Un filet de sécurité placé au mauvais endroit, trop près de la mise en production.

Ces réflexions font alors resurgir les enjeux de Shift Left abordés par DevSecOps.  
Il ne faut pas oublier que parmi les clients / partie-prenantes du projet, il y a les équipes Exploitation et Support. Celles-ci doivent être intégrées dès les phases de conception.

ITIL® 5 – Relations entre ressources technologiques, produits numériques, offres de services et services numériques

C’est précisément ce que ce schéma aide à remettre au clair. Il explicite la relation entre ressources technologiques, produit numérique, offre de service et service numérique. Autrement dit, le service n’est pas un objet flottant. Il repose sur un produit, donc sur des choix d’architecture, de Build, d’exploitation et de support. Cette lecture permet de sortir d’un pilotage uniquement par le catalogue. Elle remet au centre ce qui fabrique réellement la valeur et ce qui porte le risque.  

En ITIL 4, beaucoup de DSI ont adopté le langage du produit sans déplacer la responsabilité. Le produit restait “ chez les projets ”, le service “ à l’exploit’ ”, et la jonction se faisait à coup de changements. Tant que le produit n’est pas l’unité de responsabilité sur la durée, la bascule projet vers RUN reste une fracture. Et la gestion des changements reste un SAS, une énième cérémonie entre 2 mondes qui s’affrontent ... ITIL 5 vient précisément recoller ces morceaux.

2. Clarifier les mots pour arrêter de se battre avec des définitions

Avant de parler organisation, rôles ou gouvernance, il faut verrouiller trois notions. Produit, service, offre. Sans ça, on retombe vite dans un débat de vocabulaire et on rate le sujet réel : le pilotage.

Un produit numérique, c’est un ensemble cohérent de ressources technologiques et de composants, conçu pour fournir une (des) capabilité(s).  
Un service numérique, c’est la valeur rendue accessible à l’utilisateur, largement portée par ces produits et l’accompagnement à l’adoption de celui-ci.  
L’offre de service, c’est la manière dont cette valeur est packagée et présentée. Conditions, niveaux de service, modalités de support.  

En clair, l’offre décrit la promesse. Le service, lui, se juge à l’usage.

ITIL® 5 – Différents rôles organisationnels dans le management, delivery et consommation des produits et services

Cette figure est utile parce qu’elle ajoute une dimension souvent oubliée. Les rôles. Elle montre que selon le contexte, une organisation peut être fournisseur et consommateur en même temps. Et qu’un produit numérique peut être consommé tel quel, intégré dans une offre, ou servir de brique pour produire un autre service.  

C’est exactement ce qui se passe dans une DSI. Nous consommons des produits externes. Nous assemblons des produits internes. Nous exposons des offres de service aux métiers. Et nous opérons la valeur dans la durée. Clarifier ces rôles évite deux erreurs classiques. Confondre produit et catalogue. Croire qu’un produit se résume à une application. Un produit est un objet de responsabilité, avec des dépendances, des arbitrages, et une trajectoire. La suite de l’article s’appuie sur cette base pour montrer pourquoi la gestion des changements ne peut plus rester un simple passage obligé avant mise en production.

3. Ce qu’ITIL 5 change vraiment, la dualité produit et service et la valeur sur tout le cycle

ITIL 5 ne se contente pas de remettre le mot Produit en haut de l’affiche.  

Il change la façon dont produit et service sont pensés ensemble. Le produit n’est plus seulement un support technique. Il devient l’objet qui porte des capacités, se transforme dans le temps, et conditionne directement la qualité du service rendu. Dit autrement, la valeur perçue par les métiers ne dépend pas uniquement de ce que le service promet, mais de la robustesse du produit qui le rend possible, et de la manière dont il est piloté dans la durée.  

La deuxième rupture est la vision de la valeur.  
ITIL 5 élargit explicitement ce qui compte dans l’appréciation de la valeur. L’utilité et la garantie restent centrales, mais l’expérience et la durabilité prennent une place assumée. Concrètement, une solution peut répondre au besoin fonctionnel et rester un échec si l’expérience est dégradée, si l’usage réel n’est pas compris, ou si l’exploitation devient fragile et coûteuse.  

La troisième rupture est opérationnelle.  
ITIL 5 fournit un modèle de cycle de vie produit et service qui rend visibles, au même niveau, la découverte, la conception, la construction, la transition, l’exploitation, la délivrance et le support. Ce modèle ferme la porte à une lecture en silos. Il ne s’agit plus d’optimiser une phase au détriment des autres, mais de piloter un ensemble d’activités qui coexistent et s’influencent.  

ITIL® 5 – La nouvelle chaine de valeur (Value Chain)

C’est là que la gestion des changements bascule. Si la valeur se joue sur tout le cycle, alors le changement ne peut plus être réduit à une validation de mise en production. Il devient un mécanisme de maîtrise du risque et de synchronisation des évolutions qui impactent le produit et, par ricochet, le service. La suite du modèle ITIL 5 permet de le démontrer sans discours. Par la structure même.

4. Le cycle de vie Produit et Service dans ITIL 5, une lecture continue et non séquentielle

ITIL 5 propose un modèle de cycle de vie Produit et Service qui casse la frontière implicite entre construire et opérer. Le modèle décrit huit activités qui coexistent plus qu’elles ne s’enchaînent. Découvrir, concevoir, acquérir, construire, transiter, opérer, délivrer, supporter. L’intérêt n’est pas la liste. C’est le message. Ces activités se mobilisent en fonction du contexte, avec des allers retours, des boucles, des ajustements. La livraison n’est pas une fin. C’est un passage.

ITIL® 5 – Mapping des pratiques de gestion avec la chaîne de valeur ITIL

C’est là que notre phrase « choc » prend son sens : « Le projet est un fantasme, le RUN est la réalité ».  
Un projet peut se croire terminé le jour où ça passe en production. La réalité, elle, commence quand les utilisateurs s’en servent, quand les incidents arrivent, quand la performance varie, quand l’organisation change et que la solution doit suivre. Dans ITIL 5, Operate et Support ne sont donc pas des conséquences. Ce sont des contraintes de conception. Les décisions prises en Design et en Build doivent intégrer ce qui sera maintenu, surveillé, sécurisé, patché, supporté demain.  

La gouvernance prend alors une autre forme. On ne gouverne plus uniquement des jalons de projet. On gouverne un produit et le service qu’il rend possible, sur la durée, avec des arbitrages continus entre vitesse, risque, qualité et coût. Et c’est précisément ce qui rend la comparaison avec ITIL 4 éclairante.  
Là où beaucoup d’organisations ont utilisé la chaîne de valeur comme une lecture séquentielle, ITIL 5 rend explicite une continuité. Le changement n’est plus un SAS entre deux mondes. Il devient un mécanisme qui accompagne les évolutions tout au long du cycle, y compris en exploitation.  

5. La gestion des changements devient un mécanisme de pilotage du risque produit et service

Avec l’orientation produit d’ITIL 5, la gestion des changements ne peut plus rester un simple poste de contrôle avant mise en production. Le cadre devient plus large, et plus exigeant. Un changement est défini comme toute modification pouvant avoir un effet direct ou indirect sur un ou plusieurs produits ou services. Dit autrement, ce n’est pas seulement une question de déploiement. C’est une question d’impact sur la valeur rendue et sur la capacité à opérer dans la durée.

Dans cette logique, la pratique Change enablement vise à maximiser le nombre de changements réussis en évaluant les risques, en autorisant les changements, et en pilotant un calendrier de changements au service des produits et services. Le centre de gravité se déplace. On ne cherche plus à faire “passer” un changement. On cherche à décider du bon changement, au bon moment, au bon niveau de risque, avec les bonnes conditions d’exploitation.

Concrètement, cela transforme trois réflexes DSI.

Premier réflexe, rattacher chaque changement à un produit, pas à un projet. Un projet est un véhicule. Le produit est l’objet qui reste, qui porte le risque, et qui doit être opéré.

Deuxième réflexe, intégrer l’exploitation comme critère d’autorisation. Observabilité, sécurité, réversibilité, capacité de support. Ce ne sont pas des features Should have. Ce sont des Must de conditions de réussite.

Troisième réflexe, piloter un flux continu plutôt qu’un SAS. Une organisation orientée Produit génère des changements en continu. Petits, fréquents, maîtrisés. La gestion des changements ne doit donc pas ralentir par principe. Elle doit différencier, adapter les contrôles, et protéger la production sans casser l’apprentissage : DevSecOps nous tend alors les bras.

C’est à ce moment que la promesse d’ITIL 5 devient tangible. Le changement n’est plus un rituel. C’est un levier de pilotage du produit et du service, sur tout le cycle de vie.

6. Ce que cela change pour l’organisation de la DSI, rôles, modèles opérationnels, interfaces métier

Une DSI orientée Produit ne peut pas fonctionner avec les mêmes découpages implicites projet d’un côté, RUN de l’autre. ITIL 5 pousse une logique de responsabilité sur la durée. Si un produit numérique soutient un service numérique, alors quelqu’un doit en porter la cohérence, les arbitrages, la trajectoire, y compris après la mise en production. C’est un déplacement net. On ne cherche plus un responsable de livraison. On cherche un responsable de résultat en exploitation.

Cela se traduit d’abord dans les rôles. Le product owner ou product manager côté DSI ne peut pas être seulement une voix métier en phase de Build. Il devient un rôle qui arbitre entre valeur, risque et coût d’exploitation, avec une relation structurée aux équipes Operate et Support. À l’inverse, les équipes RUN ne sont plus des récepteurs. Elles deviennent contributrices dès le Design, garantes de l’opérabilité, de l’observabilité, de la sécurité et de la capacité de support.  

Ensuite, cela impacte le modèle opérationnel. Un modèle opérationnel orienté Produit s’organise autour de flux de valeur et de capacités, pas autour de silos techniques. Les pratiques ITSM restent indispensables, mais elles doivent être “branchées” sur les activités du cycle de vie produit et service, avec des règles adaptées au type de changement, au niveau de risque et au contexte d’usage.  

Kheops Conseil – Les 3 modèles opérationnels de la DSI

Enfin, l’interface avec les métiers se simplifie et se durcit à la fois. Elle se simplifie parce que l’objet de dialogue devient le produit et ses résultats à l’usage, pas une succession de projets. Elle se durcit parce que les arbitrages deviennent explicites.  
Une demande métier n’est pas un ticket à livrer. C’est un changement Produit à assumer, à opérer, et à mesurer dans la durée.

7. Pièges classiques quand on dit produit sans changer la réalité

Le premier piège est de confondre produit et catalogue. Un catalogue décrit des offres et des services. Il ne dit rien, à lui seul, de la responsabilité sur le Produit qui rend ces services possibles. Quand la DSI se contente de renommer des éléments de catalogue en produits, elle obtient surtout un changement de vocabulaire. Pas un changement de pilotage.

Le deuxième piège est de repeindre l’existant sans bouger les pratiques. On garde les mêmes frontières projet puis RUN, les mêmes comités, les mêmes critères de validation, et on ajoute une couche de discours Produit. Dans ce schéma, la gestion des changements reste un SAS. Elle continue à traiter la mise en production comme l’événement central, au lieu de piloter un flux d’évolutions sur la durée.

Le double diamant du Design Thinking

Le troisième piège est de sous-estimer l’impact culturel. L’orientation Produit exige des arbitrages explicites entre vitesse, risque, qualité et coût d’exploitation. Elle oblige à accepter que tout changement n’a pas la même criticité, que les contrôles doivent être proportionnés, et que l’exploitation a voix au chapitre dès la conception. Sans cette maturité, on bascule vite dans deux extrêmes. Soit le laisser faire, avec une production instable. Soit l’hyper contrôle, avec une organisation figée.

Le quatrième piège est organisationnel. Créer des rôles Produit sans leur donner la responsabilité réelle en exploitation. Un produit sans responsabilité bout en bout devient une façade. Et quand la façade craque, c’est toujours le RUN qui récupère la dette.

Si nous voulons éviter ces pièges, il faut une règle simple. À chaque produit, une responsabilité claire dans la durée, et des décisions de changement prises avec l’exploitation, pas contre elle.

Conclusion

L’orientation Produit d’ITIL 5 n’est pas un changement de vocabulaire. C’est un changement de centre de gravité. Le produit devient l’objet de responsabilité dans la durée. Le service devient la valeur constatée à l’usage. Et le cycle de vie proposé par ITIL 5 rend visible une évidence souvent contournée.  
Concevoir, construire, transiter, opérer et supporter ne sont pas des mondes séparés. Ce sont des activités qui se conditionnent mutuellement.  

Dans ce cadre, la gestion des changements ne peut plus rester un guichet de mise en production. Un changement est toute modification susceptible d’impacter produits et services : en somme, le projet, l’évolution, le fix EST le changement.  
La pratique Change enablement vise à sécuriser un flux continu de changements en évaluant le risque, en arbitrant, en autorisant, en synchronisant. L’enjeu n’est plus de faire passer un changement. L’enjeu est de décider des bons changements, avec les bonnes conditions d’exploitation, au rythme que le Produit peut absorber.

« Le projet est un fantasme. Le RUN est la réalité. » tient alors comme une règle de pilotage ! Un projet termine une activité. Un produit continue d’exister, d’évoluer, de produire des incidents, des usages, des coûts, de la valeur. ITIL 5 nous donne un langage et une structure pour aligner conception, exploitation et gouvernance. À nous d’en tirer une conséquence simple. Piloter par produit. Gouverner par le risque. Concevoir pour opérer.

Les DSI les plus matures ont déjà opérées cette transformation. Elles vendent leurs services : refacturation des métiers, édition de logiciel, intégration …
Directement soutenu par l’outil socle de la DSI : la CMDB !

‍

Envie de vous former à ITIL® 5 ? C'est par ici : 👇

https://kheops-academie.eu/formation/itil-5-foundation

‍