Le change manager ITIL protège la production des modifications mal préparées, sans bloquer les équipes qui livrent. Il qualifie les demandes, fixe le niveau d'approbation selon le risque, anime le CAB, arbitre les conflits de calendrier et pose les gels. Les questions d'entretien de change manager ITIL supposent une offre qui parle bien de gestion des changements en production. Sur les sites d'emploi, le même titre désigne souvent un poste de conduite du changement auprès des utilisateurs, qui n'a rien à voir.
Beaucoup de CV présentent le CAB comme une réunion hebdomadaire dont la personne tenait l'ordre du jour. Un change manager confirmé parle d'autre chose : autorités déléguées pour les changements à faible risque, critères de retour arrière fixés avant l'intervention, changements non autorisés détectés, taux d'échec suivi par type de changement. Les équipes qui déploient par CI/CD posent aussi une question nouvelle : comment garder la trace sans exiger une demande manuelle à chaque livraison.
Le candidat raconte un changement qui a mal tourné, la décision prise et ce qui a changé ensuite dans le processus. Le PDF ajoute un cas de 20 minutes sur le remplacement des commutateurs principaux d'un datacenter.
Le cadre et les outils de la gestion des changements
ITIL 4 Change Enablement et ITIL (Version 5)
ITIL 4 appelle la pratique change enablement, avec un module Practitioner dédié ; les offres françaises disent gestion des changements. Elle distingue trois types : standard, normal et urgent. PeopleCert a publié ITIL (Version 5) début 2026, en parallèle d'ITIL 4, et les deux versions gardent ce socle.
CAB, ECAB et autorités de changement
Le CAB (Change Advisory Board) examine les changements normaux à risque moyen ou élevé et conseille l'autorité qui décide. L'ECAB se réunit en urgence pour un correctif qui ne peut pas attendre. ITIL 4 recommande de confier les changements à faible risque à une autorité proche de l'équipe, pour que le CAB ne devienne pas un goulet.
Évaluation du risque et de l'impact
Un questionnaire de risque donne un niveau à partir de quelques critères : criticité des composants, interruption prévue, retour arrière testé, nouveauté de l'opération. L'impact se lit dans la CMDB, qui relie les serveurs aux services métier. Le niveau de risque fixe le circuit d'approbation.
Calendrier des changements, fenêtres et gels
Le calendrier montre tout ce qui est prévu, par composant et par date. Les fenêtres de maintenance fixent les créneaux autorisés, les gels bloquent les changements pendant une période sensible pour les métiers. Les conflits entre deux interventions sur la même infrastructure se repèrent à cet endroit.
Outil ITSM
ServiceNow, Jira Service Management, EasyVista ou BMC Helix portent les demandes de changement, les modèles, les approbations et la détection de conflits. Jira Service Management peut créer des demandes de changement à partir des déploiements d'une chaîne CI/CD. Le change manager configure rarement l'outil lui-même, mais il définit les états, les modèles et les règles d'approbation.
CI/CD et changements automatisés
Les équipes qui livrent plusieurs fois par jour s'appuient sur les tests automatisés, la revue de code et le déploiement progressif. Le changement standard pré-autorisé et la demande générée par le pipeline gardent la trace sans passer par un CAB. Les indicateurs DORA (DevOps Research and Assessment), dont le taux d'échec des changements, servent de langage commun avec ces équipes.
Plan de retour arrière
Il décrit comment revenir à l'état précédent, en combien de temps, avec quels prérequis (sauvegarde, snapshot, ancienne version). Il fixe aussi le point de non-retour et les critères qui déclenchent le retour. Un changement sans retour possible, comme certaines migrations de schéma de base, demande un plan alternatif écrit et un risque accepté.
Revue post-implémentation
Après un changement échoué ou suivi d'un incident, la revue compare le plan et la réalité. Elle conduit à corriger le questionnaire de risque, un modèle de changement ou les tests demandés. Un change manager qui ne fait jamais ces revues voit les mêmes échecs revenir.
Le poste se trouve dans les DSI qui ont une production lourde, chez les infogérants et dans les centres de services partagés. Il est parfois cumulé avec la gestion des incidents ou des mises en production, et beaucoup d'offres l'associent à ServiceNow. Le change manager n'intervient pas sur les serveurs, mais il doit comprendre ce qu'un changement touche : réseau, stockage, base de données, application. La certification ITIL 4 Foundation, ou ITIL Foundation (Version 5), est presque toujours demandée ; le module ITIL 4 Practitioner Change Enablement montre une spécialisation. La qualité des décisions de risque se vérifie en entretien, sur des cas.
Six points attendus d'un change manager ITIL
- Types de changements et autorités d'approbation
- Évaluation du risque et de l'impact
- Animation du CAB et de l'ECAB
- Calendrier, fenêtres et gels
- Retour arrière et revue post-implémentation
- Changements automatisés et CI/CD
Cinq questions sur le risque, le CAB et la mise en production
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une équipe veut migrer jeudi à 14 h le serveur de base de données qui porte trois applications. Comment évaluez-vous le risque ?
Une bonne réponseL'impact d'abord : services dépendants dans la CMDB, nombre d'utilisateurs, activité métier ce jour-là. Puis la probabilité d'échec : complexité, opération déjà faite ou non, tests en recette, expérience de l'équipe. Il exige un plan de retour arrière testé avec sa durée, vérifie les conflits du calendrier, consulte les responsables des trois applications et déconseille un créneau en pleine journée. Le niveau de risque obtenu fixe qui approuve.
Signal d'alerteApprouver parce que l'équipe est sérieuse, ou tout refuser par principe. Aucune question sur les applications qui dépendent du serveur.
Question 2 · junior à confirmé
Changement standard, normal, urgent : quelle différence, et quel exemple donnez-vous pour chacun ?
Une bonne réponseLe standard est pré-autorisé : faible risque, procédure rodée, par exemple l'ajout de mémoire à une VM selon un modèle. Le normal est évalué puis autorisé par l'autorité qui correspond à son risque, comme une migration de serveur. L'urgent doit être fait au plus vite, pour un correctif de sécurité exploité ou la réparation d'un incident majeur, avec un circuit court et une documentation complétée ensuite.
Signal d'alerte« Urgent » pour un projet en retard, « standard » pour un petit changement sans procédure validée.
Question 3 · confirmé
À 23 h, un changement se passe mal : l'application démarre mais des erreurs apparaissent. Le retour arrière prend deux heures. Qui décide de revenir en arrière, et sur quels critères ?
Une bonne réponseLes critères ont été écrits dans la demande avant l'intervention : tests de vérification à réussir, heure limite pour décider, point de non-retour. Le responsable de l'intervention décide avec le change manager ou l'astreinte désignée, en comparant le temps restant dans la fenêtre et la durée du retour arrière. La décision est tracée, les métiers prévenus, et si le retour échoue, un incident est ouvert.
Signal d'alerteCorriger en direct jusqu'au matin sans limite, ou découvrir les critères au moment de décider.
Question 4 · confirmé
Le CAB de la semaine compte soixante changements pour une heure de réunion. Comment organisez-vous la séance ?
Une bonne réponseLe CAB ne revoit que les changements normaux à risque moyen ou élevé ; les autres sont approuvés en amont par l'autorité déléguée. L'ordre du jour part à l'avance et les dossiers incomplets sont renvoyés avant la séance. Il prévoit un temps par changement, traite les conflits de calendrier, revient sur les changements échoués de la semaine passée et trace chaque décision dans l'outil.
Signal d'alerteLire les soixante demandes une par une, ou tout approuver en bloc faute de temps.
Question 5 · senior
Une équipe déploie quinze fois par jour par sa chaîne CI/CD et refuse de remplir une demande de changement à chaque fois. Que proposez-vous ?
Une bonne réponseLe pipeline porte le contrôle : tests automatisés, revue de code, déploiement progressif, retour arrière automatisé. Ces déploiements deviennent des changements standard ou approuvés automatiquement, avec une demande créée par le pipeline dans l'outil ITSM pour garder la trace. Les changements à risque, comme une modification de schéma ou d'une infrastructure partagée, restent des changements normaux. Il suit le taux d'échec pour vérifier que le choix tient.
Signal d'alerteImposer un passage au CAB hebdomadaire pour chaque déploiement, ou exempter l'équipe sans aucune trace.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Change manager ITIL : questions fréquentes
Change manager ITIL ou conduite du changement : comment éviter la confusion ?
Le change manager ITIL gère les modifications techniques en production : serveurs, réseaux, applications, avec un CAB et un calendrier. Le chargé de conduite du changement accompagne les utilisateurs lors d'un nouveau logiciel ou d'une réorganisation. Les deux portent souvent le même titre en anglais. L'offre mentionne « gestion des changements ITIL », « CAB » et « mise en production », et sur le CV, les expériences doivent citer des interventions techniques et un outil ITSM.
Quelle certification pour un change manager ?
ITIL 4 Foundation reste le minimum courant. Le module ITIL 4 Practitioner Change Enablement porte précisément sur la pratique. PeopleCert propose aussi depuis début 2026 ITIL (Version 5), sans avoir retiré ITIL 4, et une passerelle permet aux certifiés ITIL 4 de passer à la nouvelle version. Une certification ne dit pas comment la personne évalue un risque ou décide un retour arrière : l'entretien la fait raisonner sur un changement réel de son dernier poste.
Un change manager doit-il avoir un passé technique ?
Il ne fait pas les interventions, mais il doit comprendre ce qu'elles touchent. Sans notions de réseau, de stockage, de bases de données et de déploiement applicatif, il ne peut pas juger un plan de retour arrière ni contester un risque annoncé comme faible. Les profils venus de la production ou de l'exploitation ont cet acquis. Pour un profil venu de la qualité ou du pilotage de projet, l'entretien porte sur des composants précis.
Comment se passe l'évaluation d'un change manager en entretien ?
Un test technique classique n'a pas grand sens pour ce poste. Mieux vaut soumettre deux ou trois demandes de changement réelles et anonymisées, dont une incomplète et une à risque sous-évalué. La personne les classe, dit qui approuve et ce qui manque. En quinze minutes, on voit si elle lit un plan de retour arrière, repère un conflit de calendrier et sait refuser une urgence qui n'en est pas une.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
