ITIL v4 : ce qui change pour la gouvernance IT

Ce n'est pas une mise à jour incrémentale. C'est une refonte complète de la philosophie du framework. Le cycle de vie linéaire — Stratégie, Conception, Transition, Exploitation, Amélioration continue — a été remplacé par un système modulaire où les activités se combinent dans l'ordre qui fait sens pour ton contexte. Le mot "processus" lui-même a été abandonné au profit de "pratiques".

Pourquoi ce virage ? Parce que le monde IT de 2019 n'est plus celui de 2011. Les équipes déploient en continu, travaillent en sprints, et gèrent des infrastructures cloud hybrides. Un framework qui impose une séquence rigide d'étapes n'a plus de sens quand tu fais 50 déploiements par semaine.

Cet article décortique les changements concrets d'ITIL v4 par rapport à la v3, ce que ça change pour ta DSI au quotidien, et comment migrer sans tout casser.

D'ITIL v3 à v4 — le changement de philosophie

Le changement le plus fondamental entre ITIL v3 et v4, c'est l'abandon du modèle linéaire. En v3, un service suivait un parcours séquentiel : tu définissais la stratégie, tu concevais le service, tu le transitionnais en production, tu l'exploitais, puis tu l'améliorais. Chaque étape avait ses processus dédiés. C'était logique sur le papier. En pratique, personne ne travaillait comme ça.

ITIL v4 remplace ce cycle de vie par le SVS — Système de Valeur des Services. Le SVS est un modèle opérationnel qui prend en entrée une demande ou une opportunité, et produit en sortie de la valeur. Il n'y a pas de séquence fixe entre les deux. Le chemin dépend du contexte.

Le SVS contient cinq composants : les principes directeurs, la gouvernance, la Chaîne de Valeur des Services, les pratiques, et l'amélioration continue. Ces composants interagissent de manière fluide. Aucun n'est "premier" ou "dernier". C'est un système, pas un pipeline.

Vue d'ensemble : v3 vs v4 en un tableau

Ce tableau résume le changement de paradigme. Ce n'est pas une évolution — c'est une refondation. Et la bonne nouvelle : ITIL v4 est rétro-compatible. Les certifications v3 restent valides, et la plupart des concepts v3 ont un équivalent direct en v4. Tu ne repars pas de zéro — tu fais évoluer ce qui existe.

Les 26 processus deviennent 34 pratiques

Ce n'est pas qu'un changement de vocabulaire. Un "processus" implique une séquence d'activités avec des entrées et des sorties définies. Une "pratique" est un ensemble de ressources organisationnelles conçues pour atteindre un objectif — ça inclut les processus, mais aussi les personnes, les outils, les informations et les relations avec les partenaires.

Les 34 pratiques d'ITIL v4 se répartissent en trois catégories :

• 14 pratiques de gestion générale : stratégie, gestion des risques, gestion financière, amélioration continue, gestion des fournisseurs, gestion de la sécurité de l'information, etc.
• 17 pratiques de gestion des services : gestion des incidents, des problèmes, des changements, du catalogue de services, du Service Desk, etc.
• 3 pratiques de gestion technique : gestion des déploiements, gestion de l'infrastructure et des plateformes, développement et gestion logicielle.

Les 4P deviennent les 4 Dimensions

ITIL v3 structurait la gestion des services autour des 4P : Personnes, Processus, Produits et Partenaires. ITIL v4 les remplace par les 4 Dimensions :

1. Organisations et personnes — La culture, les compétences, les structures d'équipes.
2. Information et technologie — Les outils, les données, les systèmes d'information.
3. Partenaires et fournisseurs — L'écosystème externe : cloud providers, éditeurs SaaS, sous-traitants.
4. Flux de valeur et processus — Comment le travail circule, du besoin initial à la livraison de valeur.

La différence n'est pas cosmétique. Les 4 Dimensions obligent à considérer chaque aspect simultanément pour chaque décision de service. En v3, les 4P étaient souvent traités séparément. Un projet d'outil (Produits) se faisait sans toujours penser aux compétences (Personnes). ITIL v4 rend cette approche cloisonnée obsolète.

Les 7 principes directeurs : la boussole d'ITIL v4

C'est probablement l'ajout le plus utile de la v4. Sept principes qui guident toutes les décisions, indépendamment des pratiques choisies :

1. Se concentrer sur la valeur — Chaque action doit créer de la valeur pour quelqu'un. Si tu ne peux pas expliquer la valeur d'une activité, supprime-la.
2. Commencer là où tu es — Ne repars pas de zéro. Évalue ce qui existe avant de transformer.
3. Progresser itérativement avec du feedback — Petits pas mesurables, pas de big bang.
4. Collaborer et promouvoir la visibilité — Transparence sur les décisions et les progrès.
5. Penser et travailler de manière globale — Pas de silos, vision d'ensemble.
6. Rester simple et pratique — Éliminer tout ce qui ne crée pas de valeur.
7. Optimiser et automatiser — D'abord optimiser le flux, ensuite automatiser ce qui peut l'être.

Les 3 changements concrets qui impactent ta DSI au quotidien

La théorie c'est bien. Mais concrètement, qu'est-ce qui change pour tes équipes le lundi matin ? Trois transformations majeures.

1. Change Management devient Change Enablement

C'est le changement qui a le plus d'impact opérationnel immédiat. En v3, le Change Management était un processus de contrôle. Chaque changement devait être documenté, évalué et approuvé — souvent par un CAB (Change Advisory Board) qui se réunissait une fois par semaine.

Le résultat dans beaucoup d'organisations : un goulot d'étranglement massif. Les équipes DevOps qui veulent déployer 10 fois par jour se retrouvent bloquées par un comité qui se réunit le jeudi matin. Les développeurs contournent le processus. Le CAB perd sa légitimité. Tout le monde est frustré.

ITIL v4 renomme la pratique Change Enablement — et le changement de nom reflète un changement de posture. L'objectif n'est plus de contrôler les changements, mais de les faciliter en gérant les risques de manière proportionnée.

Concrètement, les changements sont classés en trois catégories :

• Changements standard (faible risque, bien documentés) : pré-approuvés et automatisés. Un déploiement via pipeline CI/CD qui passe tous les tests automatisés est un changement standard. Pas besoin du CAB.
• Changements normaux (risque modéré) : revue par les pairs ou par un délégué. Le CAB complet n'est pas nécessaire.
• Changements d'urgence : procédure accélérée avec validation post-implémentation.

2. La Chaîne de Valeur des Services remplace le cycle de vie linéaire

En v3, un nouveau service suivait un parcours linéaire : Stratégie, Conception, Transition, Exploitation, Amélioration. Le problème : une panne critique et un nouveau projet logiciel ne suivent évidemment pas le même parcours. Mais le modèle v3 ne reflétait pas cette réalité.

ITIL v4 introduit la Chaîne de Valeur des Services (SVC) avec 6 activités :

• Planifier — Définir la direction et allouer les ressources.
• Améliorer — Identifier et prioriser les opportunités d'amélioration.
• Engager — Comprendre les besoins des parties prenantes et maintenir la relation.
• Concevoir et transitioner — Construire le service et le mettre en production.
• Obtenir/construire — Acquérir ou développer les composants nécessaires.
• Livrer et soutenir — Opérer le service et traiter les incidents.

La différence clé : ces 6 activités se combinent dans n'importe quel ordre pour créer des "flux de valeur" adaptés au besoin. Un incident critique va traverser Engager, puis Livrer et soutenir, puis éventuellement Améliorer. Un nouveau projet va traverser Planifier, Engager, Concevoir et transitioner, Obtenir/construire, puis Livrer et soutenir.

Le même framework, deux parcours totalement différents. C'est cette flexibilité qui rend ITIL v4 compatible avec les réalités opérationnelles.

3. Intégration native Agile, DevOps et Lean

En v3, Agile et ITIL étaient souvent perçus comme incompatibles. D'un côté, les équipes agiles voulaient de la vitesse et de la flexibilité. De l'autre, ITIL imposait des processus et des comités. La guerre de tranchées était réelle dans beaucoup de DSI.

ITIL v4 met fin à ce conflit. Le framework intègre explicitement les concepts Lean, Agile et DevOps comme des approches complémentaires. Ce n'est pas un ajout cosmétique — c'est structurel.

Le principe "Progresser itérativement avec du feedback" vient directement de l'agilité. Le principe "Optimiser et automatiser" est du Lean pur. La pratique Change Enablement est conçue pour coexister avec les pipelines CI/CD. La notion de flux de valeur est empruntée au Value Stream Mapping du Lean.

Ce qu'ITIL v4 fait mieux que v3 (et ce qu'il ne résout pas)

Soyons honnêtes : ITIL v4 est une nette amélioration. Mais ce n'est pas une baguette magique. Voici le bilan lucide.

Ce que v4 fait mieux

La flexibilité. Le SVS et la Chaîne de Valeur des Services permettent d'adapter le framework à n'importe quel contexte. Une startup SaaS de 50 personnes et un groupe industriel de 10 000 collaborateurs peuvent tous les deux utiliser ITIL v4 — en sélectionnant les pratiques pertinentes.

L'intégration DevOps. Ce n'est plus un ajout après coup. DevOps, Lean et Agile sont intégrés dans l'ADN du framework.

La co-création de valeur. ITIL v3 avait un modèle fournisseur-consommateur : l'IT fournit des services, le business les consomme. ITIL v4 remplace ça par un modèle de co-création : la valeur n'existe que si le business participe activement.

La modularité des 34 pratiques. En v3, les 26 processus étaient interdépendants. En v4, les pratiques sont modulaires. Tu peux commencer par 3 ou 4 pratiques et en ajouter progressivement.

Les principes directeurs. Les 7 principes donnent un cadre de décision clair, indépendant des pratiques spécifiques. Quand une équipe hésite, "Rester simple et pratique" et "Se concentrer sur la valeur" tranchent la plupart des débats.

Ce que v4 ne résout pas

La résistance culturelle reste le vrai bloqueur. ITIL v4 a beau être plus flexible, si les équipes ne veulent pas changer leurs habitudes, aucun framework ne fera de miracle.

Le coût de recertification. Si tes équipes sont certifiées ITIL v3, elles doivent repasser des certifications pour la v4. La certification ITIL 4 Foundation coûte entre 400 et 700 euros par personne. Pour les niveaux supérieurs, c'est plusieurs milliers d'euros.

Les petites structures sont souvent mieux servies par la simplicité. 72% des organisations déclarent pratiquer ITIL, mais pour une équipe IT de moins de 50 personnes, le formalisme d'ITIL v4 est souvent surdimensionné. 3-4 pratiques bien exécutées avec un Kanban board et un outil ITSM simple suffisent largement. Le principe "Rester simple et pratique" s'applique aussi au choix d'adopter ITIL lui-même.

La feuille de route de migration v3 vers v4

Tu es en v3 et tu veux migrer vers v4 ? La bonne nouvelle : tu n'as pas besoin de tout changer d'un coup.

1. 1

   Mapper tes processus v3 sur les 34 pratiques v4

   Commence par un exercice de correspondance. La plupart de tes processus v3 ont un équivalent direct en v4. Ne tombe pas dans le piège de "tout recommencer". Si ta gestion des incidents fonctionne bien, garde-la. Aligne la terminologie sur v4, mais ne casse pas ce qui marche.

2. 2

   Former les équipes sur les principes directeurs d'abord

   La tentation classique : envoyer tout le monde en certification Foundation v4 dès le premier mois. Résiste à cette tentation.

   Commence par les 7 principes directeurs. Ce sont eux qui changent la mentalité, pas les pratiques individuelles. Organise des ateliers internes de 2 heures, pas des formations de 3 jours. Prends des cas concrets de ton organisation et passe-les au filtre des principes.

3. 3

   Commencer par Change Enablement

   Si tu ne devais changer qu'une seule chose, commence par la migration de Change Management vers Change Enablement. C'est le quick win avec le meilleur ratio effort/impact.

   • Semaine 1-2 : Analyser tes changements des 3 derniers mois. Classifier chacun en standard, normal ou urgence.
   • Semaine 3-4 : Définir les critères de pré-approbation pour les changements standard.
   • Semaine 5-8 : Automatiser l'approbation des changements standard dans ton outil ITSM. Connecter au pipeline CI/CD si applicable.
   • Semaine 9-12 : Mesurer l'impact. Temps moyen de déploiement, nombre de changements par semaine, taux d'échec.
4. 4

   Étendre progressivement sur 6 à 18 mois

   • Mois 1-3 : Principes directeurs + Change Enablement. C'est la fondation.
   • Mois 4-6 : Aligner la gestion des incidents et des problèmes sur les pratiques v4. Intégrer la notion de flux de valeur.
   • Mois 7-12 : Déployer le catalogue de services v4 avec la co-création de valeur. Former les équipes métier.
   • Mois 12-18 : Optimiser. Ajouter des pratiques supplémentaires selon les besoins identifiés. Automatiser ce qui peut l'être.

ITIL v4 et la suite — ce qui arrive après

ITIL 4 n'est pas figé. Contrairement à v3 qui a été un "release" monolithique, v4 est conçu comme un framework modulaire qui évolue en continu.

Un modèle d'évolution par modules

PeopleCert (qui a racheté Axelos en 2021) publie régulièrement de nouveaux Practice Guides — des guides détaillés pour chacune des 34 pratiques. Le parcours certifiant v4 est structuré en modules :

• Foundation — Les bases du framework.
• Managing Professional (MP) — 4 modules pour les praticiens : Create Deliver & Support, Drive Stakeholder Value, High-velocity IT, Direct Plan & Improve.
• Strategic Leader (SL) — 2 modules pour les dirigeants : Digital & IT Strategy, Direct Plan & Improve.
• Practice Manager — Certifications spécifiques par pratique.

ITIL v5 — ce qu'on sait

PeopleCert a confirmé le développement d'ITIL v5. La direction est claire : IA-native, automation-first, cloud-native.

La gouvernance des services IA. C'est le sujet brûlant. Quand un chatbot IA résout un incident automatiquement, qui est responsable si la résolution est mauvaise ? Quand un agent IA prend une décision de routage, comment tu le traces ? ITIL v5 devra répondre à ces questions.

L'automatisation comme norme. En v4, l'automatisation est un principe directeur. En v5, elle sera probablement la baseline : les pratiques seront conçues automation-first, avec des variantes manuelles pour les exceptions.

L'architecture cloud-native. Les pratiques spécifiques au cloud-native (gestion des microservices, observabilité distribuée, chaos engineering, FinOps) seront intégrées comme des pratiques de première classe.

Rester à jour sans tout recertifier

Privilégie la veille active sur les Practice Guides. Quand un nouveau guide sort, organise un atelier interne de 2 heures pour le décrypter avec les équipes concernées. C'est plus efficace et moins cher qu'une recertification formelle.

Concentre les recertifications sur les rôles clés. Le responsable ITSM, le responsable des changements, le Service Desk Manager — ces profils doivent être à jour.

Applique le principe "Rester simple et pratique". Tu n'as pas besoin de maîtriser les 34 pratiques dans leur dernière version. Tu as besoin de maîtriser les 5 ou 6 pratiques que tu utilises.

Le budget et le calendrier de migration

Calendrier type

• Mois 1-2 : Ateliers principes directeurs + mapping v3→v4
• Mois 3-4 : Migration Change Enablement (quick win)
• Mois 5-8 : Alignement gestion incidents/problèmes + formation Foundation v4
• Mois 9-12 : Catalogue de services + co-création de valeur
• Mois 12-18 : Optimisation, automatisation, ajout de pratiques

Ce qu'il faut retenir

ITIL v4 n'est pas une mise à jour — c'est une refonte de la façon de penser la gestion des services IT. Le tableau comparatif est clair : cycle de vie linéaire → SVS flexible, 26 processus → 34 pratiques modulaires, contrôle → facilitation, SLA techniques → co-création de valeur.

L'impact est concret. Change Enablement libère la vélocité de déploiement. L'intégration native Agile/DevOps/Lean met fin à la guerre entre frameworks. La co-création de valeur transforme la relation IT-business.

La migration est progressive. Commence par les principes directeurs, puis Change Enablement, puis étends sur 6 à 18 mois. Budget : 50 000 à 300 000€ selon la taille. Ne tombe pas dans le piège du big bang.

Les limites existent. La résistance culturelle reste le vrai bloqueur. Le coût de recertification (500-700€/personne minimum) est réel. Les petites structures (<50 personnes) doivent être sélectives. Et ITIL v5 arrive avec la gouvernance IA comme sujet central.