Accueil / Niveau Expert

Niveau Expert — Gouvernance et pilotage

SLA, déploiements et versions, amélioration continue, gouvernance et pratiques techniques : le pilotage de la valeur.

E1

Module 9 — SLA et gestion des niveaux de service

+

1. Définitions et objectif

Définition exacte — SLA (accord de niveau de service) : accord documenté entre un fournisseur de services et un client, identifiant les services requis et le niveau de service attendu. Objectif de la pratique : définir des cibles claires basées sur le business pour les niveaux de service, et s'assurer que la fourniture est correctement évaluée, surveillée et gérée.
Pourquoi c'est important : un client paie pour une disponibilité de 99,9 pour cent mais subit trois pannes sans geste ni explication : il résilie et publie un avis dévastateur. Le contrat existait, mais personne ne surveillait, ne mesurait, ni ne revoyait les niveaux. La gestion des niveaux de service transforme une promesse vague en cibles mesurées, surveillées et revues avec le client.
L'analogie qui aide : pense au contrat avec un traiteur de mariage : le SLA dit 200 repas chauds servis avant 21 heures (engagement). Les KPI mesurent en cuisine (température, cadence). La satisfaction (CSAT) dit si les invités se sont régalés. Un traiteur qui annonce tout est vert alors que la salle a faim a raté l'essentiel : l'alignement entre chiffres et ressenti.

2. Les indicateurs : du SLA au ressenti

  • SLA : engagement contractuel (exemple : disponibilité de 99,5 % par mois, rétablissement P1 en 4 h).
  • KPI / métriques : mesures opérationnelles (temps moyen de résolution, taux de respect des SLA).
  • Expérience et satisfaction (XLAs naissants, enquêtes CSAT) : le ressenti utilisateur compte autant que le chiffre — un SLA « vert » avec des utilisateurs mécontents signale des cibles mal définies.

La gestion des niveaux de service est bidirectionnelle : elle capte les exigences business (engager), négocie des cibles réalistes, surveille la fourniture, produit des rapports et organise des revues de service régulières avec le client.

3. Calculs à maîtriser

Taux de respect SLA = (tickets résolus dans les délais / total des tickets) × 100. Disponibilité = (temps de service convenu − temps d'indisponibilité) / temps de service convenu × 100. Exemple : 186 tickets sur 200 résolus dans les délais = 93 %. Indisponibilité de 43 minutes sur un mois de 43 200 minutes = disponibilité de 99,9 %.

Démonstration pas à pas : cas d'un éditeur SaaS à 99,4 pour cent au lieu de 99,9 pour cent après deux P1. Déroulé : calcul du taux (tickets dans les délais sur total) et de la disponibilité ((temps convenu moins indisponibilité) divisé par temps convenu) ; revue de service mensuelle avec le client ; plan d'amélioration (redondance) ; ajustement du calendrier des changements ; geste commercial tracé. Résultat : 99,95 pour cent au trimestre suivant, renouvellement signé. Sans mesure et sans revue, la dérive aurait continué.
Exemple d'entreprise : un éditeur SaaS signe un SLA de 99,9 % avec pénalités. La revue mensuelle montre 99,4 % (2 incidents P1). La gestion des niveaux de service déclenche un plan d'amélioration (redondance), ajuste le calendrier des changements, et communique un geste commercial. Au trimestre suivant : 99,95 %. Le terminal (sla) vous entraîne à ces calculs.
Pièges d'examen : 1) Le SLA est un accord documenté entre fournisseur et client (pas avec l'utilisateur final). 2) L'objectif inclut définir, surveiller, évaluer et gérer les niveaux. 3) Les revues de service servent à aligner en continu la fourniture et les besoins. 4) Un bon SLA repose sur des cibles réalistes et mesurables, liées aux résultats business. 5) Ne confondez pas SLA (client) et accords internes type OLA ou contrats fournisseurs (UC).
Pièges classiques : le SLA est documenté et signé entre fournisseur et client, pas directement avec l'utilisateur final. La pratique couvre définir, surveiller, évaluer et gérer, pas seulement signer. Les revues de service alignent en continu la fourniture et les besoins. Des cibles doivent être réalistes, mesurables et liées au business. Ne confonds pas SLA (client), OLA (interne) et UC (contrat fournisseur).
À vous de jouer : 186 tickets sur 200 résolus dans les délais, mais enquête CSAT à 2 sur 5. Ton SLA est-il sain ? Que fais-tu ?
Voir la réponse

Non. 93 pour cent de respect peut coexister avec des cibles mal définies si les utilisateurs restent mécontents. Tu analyses le ressenti, tu revois les cibles avec le métier en revue de service, et tu ajustes les indicateurs pour refléter l'expérience réelle, pas seulement le chiffre.

E2

Module 10 — Gestion des déploiements et des versions

+

1. Deux pratiques complémentaires

Gestion des déploiements (deployment management) : pratique qui déplace les composants nouveaux ou modifiés vers les environnements de production (ou autres environnements). Gestion des versions (release management) : pratique qui rend disponibles les services et fonctionnalités nouveaux ou modifiés pour leur utilisation.

En clair : le déploiement installe techniquement, la version (release) rend disponible aux utilisateurs. Une version peut regrouper plusieurs déploiements ; un déploiement peut rester invisible (feature flag) jusqu'à la release.

Pourquoi c'est important : une banque pousse une mise à jour mobile un vendredi soir sans environnement de test ni retour arrière : l'application plante pour 100 000 clients, la presse s'en mêle, le retour en arrière prend deux jours. Distinguer déploiement et version, imposer des environnements et des approches progressives, c'est éviter ce scénario catastrophe.
L'analogie qui aide : pense au théâtre : le déploiement, c'est monter le décor la nuit (installer techniquement). La version (release), c'est lever le rideau devant le public (rendre disponible). Tu peux monter le décor sans ouvrir la salle (feature flag), répéter en costume (pré-production), tester devant un public réduit (canary), et revenir à l'ancienne pièce si la première est mauvaise (retour arrière).

2. Environnements, approches et gestion des actifs

  • Chaîne d'environnements : développement → test → pré-production → production, avec promotion contrôlée et possibilité de retour arrière (rollback).
  • Approches : big bang (tout d'un coup), phased (par vagues), pilote, blue-green / canary (bascule progressive avec retour rapide).
  • La gestion des actifs IT (IT asset management) suit le cycle de vie des actifs (acquisition, utilisation, maintenance, retrait) pour maximiser la valeur et maîtriser coûts et risques ; la gestion de la configuration (service configuration management) maintient les informations sur les éléments de configuration (CI) et leurs relations dans la CMDB.
Démonstration pas à pas : cas de la version 4.2 d'une application bancaire. Déroulé : promotion contrôlée développement vers test vers pré-production vers production ; déploiement canary à 5 pour cent avec supervision renforcée 48 heures ; mise à jour de la CMDB (nouvelle version du CI liée aux serveurs) ; généralisation à 100 pour cent après validation ; retour arrière 4.1 prêt et testé. Résultat : zéro incident majeur. Chaque mise en production est tracée par un changement autorisé.
Exemple d'entreprise : une banque déploie la version 4.2 de son application. Déploiement canary : 5 % des clients la reçoivent, supervision renforcée 48 h, aucun incident majeur, généralisation à 100 %. La CMDB est mise à jour (nouvelle version du CI « app-mobile » liée aux serveurs). En cas de régression, le rollback vers la 4.1 est prêt et testé.
Pièges d'examen : 1) Déploiement = déplacer vers l'environnement ; version = rendre disponible pour utilisation. 2) La CMDB stocke les CI et leurs relations (configuration management). 3) Les actifs IT couvrent tout le cycle de vie (asset management). 4) Les approches progressives (phased, canary) réduisent le risque. 5) Tout déploiement en production passe par un changement autorisé.
Pièges classiques : déploiement égale déplacer vers l'environnement, version égale rendre disponible pour utilisation. La CMDB stocke les CI et leurs relations (configuration), les actifs IT suivent tout le cycle de vie (asset management). Les approches phased, pilote, blue-green et canary réduisent le risque. Tout déploiement en production passe par un changement autorisé.
À vous de jouer : tu déploies un correctif invisible derrière un feature flag sans l'activer aux utilisateurs. As-tu fait un déploiement, une version, ou les deux ?
Voir la réponse

Un déploiement seul : le composant est installé techniquement mais non rendu disponible. La version n'aura lieu qu'à l'activation du flag pour les utilisateurs, après changement autorisé et tests.

E3

Module 11 — Amélioration continue : le modèle en 7 étapes

+

1. Principe et objectif

Définition exacte — Amélioration continue : pratique organisationnelle récurrente, exécutée à tous les niveaux, pour s'assurer que la performance répond en permanence aux attentes des parties prenantes. Objectif : aligner en permanence les pratiques et les services sur l'évolution des besoins business.

L'amélioration continue s'applique partout (chaîne de valeur, pratiques, services) et à tous les niveaux. Elle est aussi une activité de la chaîne de valeur qui irrigue les 5 autres.

Pourquoi c'est important : un support stagne à 82 pour cent de respect SLA depuis un an : chacun bricole dans son coin, aucune baseline, aucun plan, les mêmes causes reviennent. Sans modèle en 7 étapes ni registre, l'amélioration reste un slogan. Avec eux, tu transformes les constats en cycles mesurés qui s'enchaînent et qui tiennent dans la durée.
L'analogie qui aide : pense à un coach sportif : quelle est la vision (courir le marathon), où en sommes-nous (10 km en une heure), où voulons-nous être (42 km en quatre heures), comment y parvenir (plan d'entraînement), agir (courir trois fois par semaine), avons-nous atteint le but (chronomètre), comment maintenir la dynamique (nouveau cycle, rituels conservés). Sauter la baseline ou la vérification, c'est s'entraîner à l'aveugle.

2. Le modèle d'amélioration continue (question d'examen classique)

  1. Quelle est la vision ? (vision, mission, objectifs business)
  2. Où en sommes-nous ? (évaluation de l'état actuel, baseline)
  3. Où voulons-nous être ? (cibles mesurables)
  4. Comment y parvenir ? (plan d'amélioration)
  5. Agir (exécuter le plan)
  6. Avons-nous atteint notre but ? (vérifier les résultats)
  7. Comment maintenir la dynamique ? (pérenniser, communiquer, nouveau cycle)

Le modèle est itératif : la fin d'un cycle alimente le suivant. On y associe le registre des améliorations (continual improvement register) qui centralise les idées, les priorise et suit leur avancement.

Démonstration pas à pas : cas d'un support à 82 pour cent visant 95 pour cent en six mois. Déroulé : baseline à 82 (où en sommes-nous), cible 95 (où voulons-nous être), plan KEDB plus formation plus deux recrutements (comment y parvenir), exécution trimestrielle (agir), mesure à 93 (avons-nous atteint le but), rituels conservés et second cycle ciblant les P1 (maintenir la dynamique). Résultat : progression durable au lieu d'un coup d'éclat suivi d'une rechute. Le registre centralise et priorise chaque idée.
Exemple d'entreprise : le taux de respect des SLA du support est de 82 % (où en sommes-nous), la vision est 95 %. Cible : 95 % en 6 mois. Plan : KEDB + formation + 2 recrutements. Action : exécution trimestrielle. Vérification : 93 % à 6 mois — proche mais pas atteint. Pérennisation : on conserve les rituels qui marchent et on lance un second cycle ciblant les P1.
Pièges d'examen : 1) L'ordre des 7 étapes, surtout les 3 premières : vision → état actuel → cible. 2) L'amélioration continue concerne tous les niveaux et s'exécute en permanence. 3) Le registre centralise et priorise les opportunités. 4) Chaque cycle se termine par « comment maintenir la dynamique ». 5) Ne confondez pas le modèle d'amélioration (7 étapes) et les principes directeurs.
Pièges classiques : retiens l'ordre des trois premières étapes : vision, puis état actuel, puis cible. L'amélioration concerne tous les niveaux et s'exécute en permanence, pas une fois par an. Le registre centralise et priorise les opportunités. Le cycle se termine par comment maintenir la dynamique et alimente le suivant. Ne confonds pas modèle en 7 étapes et principes directeurs.
À vous de jouer : ton équipe propose cinq idées d'amélioration en même temps avec un budget pour une seule. Quel outil ITIL utilises-tu et sur quel critère tranches-tu ?
Voir la réponse

Le registre d'amélioration continue (continual improvement register). Tu y centralises les cinq idées, tu les évalues contre la vision et les cibles mesurables (impact business, coût, risque), tu priorises une seule action, puis tu lances le cycle en 7 étapes avec vérification.

E4

Module 12 — Gouvernance et pratiques techniques

+

1. Gouvernance : diriger et contrôler

Définition exacte — Gouvernance : moyens par lesquels une organisation est dirigée et contrôlée. Dans le SVS, la gouvernance assure que les activités soutiennent la stratégie, avec évaluation, direction et surveillance.
  • La gouvernance définit les politiques, les autorités de décision (qui autorise quoi : changements, budgets, risques) et les cadres de conformité (réglementaire, sécurité).
  • Elle se distingue du management (qui exécute au quotidien) : la gouvernance évalue, dirige et surveille.
  • Exemple : un comité de gouvernance valide la politique « aucun changement en production le vendredi après 16 h » ; le change manager l'applique.
Pourquoi c'est important : après une fuite de données clients, l'enquête montre que chacun a fait au mieux : chiffrement partiel, règles floues, aucune autorité claire pour interdire les changements risqués. Sans gouvernance, les bonnes pratiques techniques partent dans tous les sens. La gouvernance évalue, dirige et surveille pour que sécurité, infrastructure et développement jouent la même partition.
L'analogie qui aide : pense à un orchestre symphonique : la gouvernance, c'est le chef qui fixe le tempo, désigne les solistes et fait respecter la partition (politiques, autorités, conformité). Le management, ce sont les musiciens qui jouent chaque jour. La sécurité, l'infrastructure et le développement sont des pupitres : excellents isolément, faux ensemble sans direction.

2. Les pratiques techniques à connaître

PratiqueEssentiel examen
Gestion de la sécurité de l'informationProtéger confidentialité, intégrité, disponibilité (triade CIA) ; gérer risques, contrôles, incidents de sécurité
Gestion des infrastructures et plateformesSuperviser serveurs, réseaux, infonuagique ; assurer disponibilité et capacité
Développement et gestion des logicielsS'assurer que les applications répondent aux besoins de fonctionnalité, fiabilité, maintenabilité, auditabilité

3. Panorama des 15 pratiques du syllabus Foundation

Gestion générale : gestion des relations, des fournisseurs, de la stratégie, de l'architecture, de la connaissance, mesure et rapports, gestion organisationnelle du changement, gestion de portefeuille, gestion de projet, gestion financière. Gestion des services : disponibilité, capacité et performance, continuité, centre de services, incidents, problèmes, requêtes, surveillance et gestion des événements, gestion des changements, versions, déploiements, configuration, actifs IT, niveaux de service, catalogue, conception. Techniques : déploiement, infrastructure, développement logiciel, sécurité de l'information.

Pour Foundation, maîtrisez surtout : incidents, problèmes, changements, requêtes, centre de services, niveaux de service, amélioration continue, sécurité de l'information, configuration, déploiements, versions — les autres n'exigent qu'une compréhension générale de leur but.

Démonstration pas à pas : cas d'une fuite de données dans une mutuelle. Déroulé : la gouvernance impose la politique de chiffrement systématique et l'interdiction de changement non chiffré ; la sécurité déploie les contrôles CIA (confidentialité, intégrité, disponibilité) ; les infrastructures chiffrent les baies ; les changements encadrent chaque déploiement ; le centre de services informe les utilisateurs. Résultat : audit conforme en trois mois, zéro récidive, responsabilités claires entre diriger (gouvernance) et exécuter (management).
Exemple d'entreprise : après une fuite de données, la gouvernance impose le chiffrement systématique (politique). La pratique sécurité de l'information déploie les contrôles, la gestion des infrastructures chiffre les baies, la gestion des changements encadre le déploiement, et le centre de services informe les utilisateurs. Chaque pratique joue sa partition sous la direction de la gouvernance.
Pièges d'examen : 1) Gouvernance = diriger et contrôler (évaluer, diriger, surveiller), pas exécuter. 2) Sécurité de l'information = triade confidentialité, intégrité, disponibilité. 3) La gestion des fournisseurs pilote les contrats et la performance des tiers. 4) La surveillance et gestion des événements détecte et traite les alertes avant qu'elles deviennent des incidents. 5) La gestion de la disponibilité vise à garantir que les services tiennent leurs engagements de disponibilité.
Pièges classiques : gouvernance égale évaluer, diriger, surveiller ; management égale exécuter au quotidien. Sécurité égale triade confidentialité, intégrité, disponibilité. La surveillance et gestion des événements détecte les alertes avant l'incident, la disponibilité garantit les engagements, les fournisseurs pilotent les tiers. Pour Foundation, maîtrise à fond incidents, problèmes, changements, requêtes, centre de services, niveaux de service, amélioration continue et sécurité.
À vous de jouer : qui décide de la règle aucun changement en production le vendredi après 16 heures : la gouvernance ou le management, et qui l'applique ?
Voir la réponse

La gouvernance décide : elle évalue le risque, dirige par la politique et surveille la conformité. Le management l'applique : le change manager refuse ou reporte les RFC concernées et organise le calendrier.

Tester mes connaissances avec le Quiz