ITIL 4 - Fiche essentielle
Les concepts indispensables pour un responsable technique d'applications - sans la théorie inutile, avec le lien vers votre expérience ISO 9001.
Incidents
Qualifier, prioriser, résoudre
Problèmes
Cause racine, récurrence
Changements
Déploiements maîtrisés
SLA
Engagements de disponibilité
CMDB
Inventaire des composants
Release Management
Livraisons en production
Indispensable
Gestion des incidents
Toute interruption ou dégradation non planifiée d'un service
Un incident est tout événement qui interrompt ou dégrade un service. OmekaS qui ne répond plus, Sinchro qui plante, les chercheurs qui ne peuvent plus saisir leurs feuilles de temps - c'est un incident. L'objectif ITIL est de restaurer le service le plus rapidement possible, même par un contournement temporaire.
Le processus en 5 étapes
-
01
Détecter – signalement utilisateur, monitoring, log d'erreur dans
catalina.out. - 02 Qualifier – c'est quoi exactement ? Qui est impacté ? Depuis quand ?
- 03 Prioriser – impact × urgence. Les chercheurs bloqués en clôture = critique. Bug d'affichage mineur = bas.
- 04 Résoudre ou contourner – redémarrage Tomcat, ticket éditeur, workaround temporaire.
- 05 Documenter – ce qui s'est passé, ce qui a été fait, le temps de résolution.
Priorité = Impact × Urgence
Les chercheurs qui ne peuvent plus saisir leurs feuilles de temps avant une clôture = critique. Un bug d'affichage qui touche un seul utilisateur = bas. La DSI a généralement une grille de priorité formalisée dans son outil de ticketing (GLPI ou équivalent).
Indispensable
Gestion des problèmes
La cause racine derrière les incidents récurrents
Un problème est la cause inconnue d'un ou plusieurs incidents. Si Tomcat redémarre tous les lundis matin, c'est un incident récurrent - il y a un problème sous-jacent à investiguer. La gestion des problèmes vise à éliminer la cause racine, pas juste l'effet.
Incidents vs Problèmes - la distinction clé
- IIncident - "Tomcat est tombé ce matin, je l'ai redémarré." → Service restauré.
- PProblème - "Tomcat tombe tous les lundis. Pourquoi ?" → Investigation de la heap JVM, fuite mémoire, script de batch nuit du dimanche...
Erreur connue (Known Error)
Quand la cause est identifiée mais pas encore corrigée, ITIL parle d'erreur connue. On documente un contournement standard pour que l'équipe sache quoi faire la prochaine fois - sans chercher à nouveau. C'est la base d'une bonne base de connaissance.
Indispensable
Gestion des changements
Tout déploiement est un changement géré, documenté, réversible
En Ops, chaque déploiement est un événement formalisé. Pas de mise à jour en production sans avoir suivi le processus. L'objectif est de livrer les changements utiles tout en protégeant la continuité de service.
Types de changements ITIL
- N Normal – suit le processus complet. Demande → évaluation risque → validation → déploiement → bilan. Ex : mise à jour Omeka S.
- S Standard – procédure pré-approuvée, risque faible et répétitif. Ex : redémarrage planifié de Tomcat.
- U Urgence – processus accéléré en cas de crise majeure. Validation a posteriori. Ex : patch de sécurité critique.
Fenêtres de changement à l'université
Ne jamais déployer pendant les inscriptions étudiantes, les examens, la clôture budgétaire ou la saisie des feuilles de temps des projets de recherche. Ces périodes sont à identifier dès votre arrivée et à intégrer dans votre calendrier.
Indispensable
Niveaux de service - SLA
Les engagements de disponibilité formalisés avec les métiers
Un SLA (Service Level Agreement) est un accord entre la DSI et les services métiers qui définit ce qu'on s'engage à fournir : disponibilité, temps de réponse en cas d'incident, plages horaires de support. C'est le contrat de confiance entre l'IT et ses utilisateurs.
Ce que contient un SLA pour une application
- → Disponibilité – ex : 99% hors maintenance planifiée, du lundi au vendredi 8h–19h.
- → Temps de réponse incidents – critique : 2h / majeur : 4h / mineur : 72h.
- → Plage de maintenance – fenêtre autorisée pour les déploiements (souvent nuit ou week-end).
- → Catalogue des services – liste de ce que couvre le SLA (support, formation, déploiements...).
Indispensable
Amélioration continue
Le PDCA que vous connaissez déjà - même logique, vocabulaire différent
ITIL 4 intègre explicitement le cycle Plan-Do-Check-Act de votre expérience ISO 9001. La philosophie est identique : mesurer, améliorer, vérifier, recommencer. La différence est que le périmètre est le service IT, pas le processus industriel.
ISO 9001Non-conformité
ISO 9001Action corrective
ISO 9001Maîtrise des processus
ISO 9001Audit interne
ISO 9001Amélioration continue (PDCA)
→
→
→
→
→
ITIL 4Incident / Problème
ITIL 4Problem Management
ITIL 4Service Design
ITIL 4Service Review
ITIL 4Continual Improvement
Votre avantage concret
En entretien ou en prise de poste, vous pouvez dire : "Je connais la démarche d'amélioration continue par l'ISO 9001 - ITIL applique la même logique au service IT." C'est exact, et ça montre que vous n'êtes pas démuni face au référentiel.
Utile à comprendre
CMDB - Inventaire des composants
Configuration Management Database
La CMDB est la base de données qui recense tous les composants du SI et leurs relations : serveurs, applications, bases de données, dépendances. C'est la carte du territoire. Quand un serveur tombe, la CMDB permet de savoir immédiatement quelles applications sont impactées.
Ce que vous y trouverez concrètement
- →La liste des serveurs Linux qui hébergent vos applications
- →Quelle version de Tomcat tourne sur quel serveur
- →Les dépendances entre OmekaS, sa datasource, et l'instance Oracle correspondante
- →Les contrats de maintenance et propriétaires de chaque composant
Utile à comprendre
Release Management
Structurer les livraisons - de la recette à la production
Le Release Management encadre comment on passe d'une nouvelle version d'une application en recette à sa mise en production. C'est le cadre ITIL qui donne du sens à la procédure de déploiement en 6 étapes que vous connaissez déjà : préparer, sauvegarder, recette, valider, prod, documenter.
Plan
Planification de la release
Quoi, quand, qui valide, quel rollback si ça échoue. Lire les notes de version de l'éditeur.
Build
Préparation
Récupérer le WAR, les scripts SQL, les fichiers de config. Vérifier la compatibilité Tomcat / Oracle.
Test
Recette
Déployer en environnement de recette. Valider avec les utilisateurs métier référents. Ne pas passer en prod sans feu vert.
Prod
Mise en production
Même séquence exacte qu'en recette. Hors heures ouvrées. Surveillance catalina.out immédiate.
Ce qu'il faut retenir
ITIL n'est pas une certification à passer - c'est un vocabulaire commun pour parler de la gestion des services IT. Vous pratiquez déjà la plupart de ces concepts via votre expérience. Ce qui change, c'est que tout est formalisé, nommé, documenté.
Le réflexe à acquérir : pour chaque intervention, se demander - est-ce un incident ou un problème ? Un changement standard ou normal ? Le SLA est-il respecté ? Et toujours documenter.
Incidents - restaurer vite
Problèmes - éliminer la cause
Changements - maîtriser le risque
SLA - tenir ses engagements
Amélioration - PDCA continu
CMDB - cartographier
Release - structurer les livraisons