Tous les modèles

Demande de changement IT

Documentez les modifications prévues, évaluez les risques et obtenez les approbations avant d’agir. Essayez-le dans Elium.

Exemple : contenu fictif à titre d’illustration

CHG-2026-0063 : Migration Active Directory vers Entra ID (phase 2)


Type de changement
Normal
Niveau de risque
Eleve
Demandeur
PGPhilippe Gerard
Date cible
15/03/2026 (samedi 01:00–05:00 CET)

Justification metier

La phase 2 de la migration concerne les 850 comptes utilisateurs du site de Bruxelles. Le passage d'Active Directory on-premise vers Entra ID permet d'activer l'authentification sans mot de passe (Windows Hello for Business) et de reduire les couts d'infrastructure AD de 35 % par an. Le support etendu d'AD DS expire en octobre 2026.

Périmètre et impact

  • Systèmes : Controleurs de domaine AD (DC-BRU-01, DC-BRU-02), Azure AD Connect, serveur RADIUS
  • Services concernes : Authentification SSO, VPN, acces aux partages réseau (indisponibles pendant la fenetre de 4 heures)
  • Utilisateurs : 850 collaborateurs du site de Bruxelles (Finance, RH, Opérations)

Évaluation des risques

RisqueProbabiliteMesure d'attenuation
Migration depasse la fenetre de maintenanceMoyennePhase 1 (Lille) terminee en 2h50 ; fenetre de 4h offre 30 % de marge
Echec de l'authentification SSO post-migrationFaibleTests automatises sur 15 applications critiques ; retour arriere si >2 echouent

Plan de retour arriere

Snapshot complet des contrôleurs de domaine pris a T-30 min. Si les tests d'authentification echouent dans les 60 premières minutes post-migration, restauration depuis le snapshot (estimation : 50 minutes). Le serveur RADIUS de secours reste configure sur l'AD on-premise jusqu'a validation complete et sert de chemin de retour arriere

Ceci est un exemple. Créez le vôtre dans Elium

Le modèle de demande de changement IT standardise la façon dont votre équipe propose, examine et approuve les modifications d’infrastructure. Chaque changement est documenté avec sa justification, son évaluation d’impact et son plan de retour arrière avant que quiconque touche à la production. C’est le processus qui garde vos systèmes stables et votre comité consultatif serein.

Catégorie

IT & Technologie

Essayer ce modèle dans Elium

Qu’est-ce que c’est ?

Une demande de changement IT est une proposition structurée visant à modifier un système informatique, une application ou un composant d’infrastructure. Elle documente la modification, sa justification métier, les risques et le circuit de validation avant mise en œuvre. Sans modèle formalisé, les modifications passent par des échanges informels.

Quand un incident survient, impossible de savoir ce qui a changé ou comment revenir en arrière. Un modèle structuré impose la rigueur ITIL : chaque modification est justifiée, évaluée et réversible avant d’atteindre la production.

À qui s’adresse ce modèle ?

Ce modèle de demande de changement s’adresse aux équipes qui gèrent des environnements IT contrôlés. Les responsables du centre de services IT acheminent les demandes vers le bon circuit de validation selon le risque. Les administrateurs systèmes documentent les modifications et le retour arrière avant d’intervenir en production. Les membres du CAB examinent les demandes sur la base d’informations homogènes. Les DSI maintiennent un registre auditable des changements pour la conformité

Ce qui est inclus

Le modèle se compose de deux parties : des champs de métadonnées structurés et le corps de la demande. Les champs de métadonnées classifient chaque demande : Intitulé et numéro de référence Demandeur et responsable de mise en œuvre Type de changement (standard, normal, urgent) Priorité, niveau de risque et date cible Statut (soumis, approuvé, planifié, déployé, rejeté) Le corps de la demande détaille le changement : Justification métier (pourquoi cette modification est nécessaire) Périmètre et impact (systèmes, services et utilisateurs concernés) Plan de mise en œuvre (actions avec calendrier et responsables) Évaluation des risques (scénarios et probabilités) Plan de retour arrière (comment annuler si la mise en œuvre échoue)

Comment créer ce modèle dans Elium

Ouvrir le constructeur de modèles. Rendez-vous dans votre menu profil et sélectionnez l’onglet Constructeur de modèles, ou cliquez sur "+ Créer" puis choisissez "Créer un nouveau modèle". Définir le périmètre. Choisissez une icône, activez le modèle et décidez s’il s’applique à l’ensemble de la plateforme ou à des espaces spécifiques (par ex. votre espace Gestion des changements IT ou Infrastructure).

Ajouter les champs structurés. Cliquez sur "Champ" pour ajouter les métadonnées : champs texte pour l’intitulé et le numéro, champs utilisateur pour le demandeur et le responsable, champs étiquette pour le type et le risque, un champ date et un champ statut. Rendez obligatoires l’intitulé, le demandeur et le risque. Construire la structure de la demande. Utilisez le bouton "+" pour ajouter des blocs : justification métier, périmètre, liste numérotée pour la mise en œuvre, évaluation des risques et plan de retour arrière.

Prévisualiser et enregistrer. Vérifiez la mise en page du modèle, puis enregistrez. Les membres de l’équipe peuvent désormais le sélectionner lors de la création d’articles, et vous pouvez l’appliquer au contenu existant en masse.

Pourquoi les équipes utilisent Elium pour ça

Une demande de changement n’est efficace que si le circuit de validation y a accès et si l’historique est consultable. Elium rend cet historique accessible : modèles structurés pour un format uniforme, étiquettes pour filtrer par système ou risque, et recherche par IA pour retrouver les changements associés. VINCI Energies (97 000 collaborateurs dans 61 pays) utilise Elium pour centraliser ses procédures IT.

Avec plus de 4 000 articles et 1 000 utilisateurs quotidiens, les équipes accèdent aux processus documentés depuis une plateforme unique.

FAQ

Questions fréquentes sur les demandes de changement IT

Une demande de changement est une proposition formelle de modification d’un système informatique, documentant justification, périmètre, risques et retour arrière. Elle prévient les modifications non documentées, crée une piste d’audit et fournit au comité de validation les informations nécessaires.

Un modèle complet comprend des métadonnées (intitulé, demandeur, type, risque, date cible, statut) et un corps couvrant la justification métier, le périmètre, le plan de mise en œuvre, l’évaluation des risques et le retour arrière. Les changements urgents utilisent une variante simplifiée.

Les demandes structurées réduisent les incidents car chaque modification est évaluée avant mise en œuvre. Elles accélèrent les validations car le comité reçoit des informations cohérentes. Elles améliorent l’analyse des causes racines car chaque changement est documenté avec périmètre, calendrier et responsable.

Commencez par la justification métier : pourquoi ce changement est nécessaire. Soyez précis sur le périmètre : nommez les systèmes et utilisateurs concernés. Incluez un plan de retour arrière réaliste. Précisez la fenêtre de mise en œuvre et les personnes qui doivent être disponibles.

Une demande de changement est proactive : elle documente une modification planifiée avant mise en œuvre. Un rapport d’incident est réactif : il documente une perturbation imprévue. Les demandes préviennent les incidents ; les rapports les analysent. Les deux alimentent la base de connaissances.

Retour à tous les modèles

Essayer ce modèle dans Elium

Voyons ce que cela donne sur vos connaissances.

Adaptez-le au workflow de votre équipe. Commencez gratuitement.