Modèle de demande de changement IT

Quel est le modèle de formulaire demande de changement ?

Une demande de changement n’est utile que si elle oblige réellement quelqu’un à réfléchir à ce qui pourrait mal tourner avant d’intervenir sur un système en production — pas seulement à décrire ce qu’il souhaite modifier. Ce modèle de demande de changement repose sur cette idée : il demande d’abord de présenter le changement, puis aborde les risques, les tests, le plan de retour en arrière et le calendrier, afin que l’examinateur dispose de tout ce dont il a besoin pour l’approuver ou le rejeter sans échange d’e-mails supplémentaire.

Gérer les demandes de changement par e-mail ou message instantané signifie que les détails les plus importants — comment effectuer le retour en arrière, si le changement a été testé, qui l’a approuvé jusqu’à présent — sont souvent oubliés jusqu’à ce que quelqu’un les demande. Un formulaire en ligne rend ces questions incontournables : la personne à l’origine du changement ne peut pas ignorer un champ obligatoire, et les questions conditionnelles apparaissent uniquement lorsqu’elles sont pertinentes. Ainsi, un changement standard à faible risque ne demande pas le même niveau de détail qu’un changement d’urgence sur un système en production.

Chaque demande de changement envoyée devient un PDF, automatiquement classé dans votre coffre-fort FileIt, dans le dossier de votre choix. Votre journal des changements reste ainsi au même endroit et dans un format unique, que la demande provienne d’un membre de votre équipe ou d’un prestataire ne disposant pas de son propre compte FileIt.

Qui utilise un formulaire demande de changement ?

• Une petite équipe informatique qui souhaite un processus léger de conseil en changement sans acheter une plateforme ITSM complète
• Un fournisseur de services managés qui uniformise la réception des demandes de changement provenant de différents sites clients
• Une start-up qui formalise ses déploiements après avoir dépassé le stade où les changements étaient simplement discutés dans une messagerie instantanée
• Une équipe des opérations qui documente les changements d’infrastructure à des fins d’audit ou d’assurance
• Un administrateur système indépendant qui souhaite conserver une trace écrite de ce qui a changé, quand et pourquoi, même sans comité de changement officiel
• Une entreprise qui exige l’autorisation d’un responsable ou du propriétaire d’un système avant qu’un changement n’affecte un système en production

Questions de ce formulaire demande de changement

33 questions sur 4 pages · inclut téléversement de fichier, questions conditionnelles, pages multiples, case de consentement, évaluations.

Le formulaire demande de changement, page par page

1 Le changement

Le demandeur commence par indiquer son nom, son adresse e-mail et son équipe, puis saisit un titre court et un type de changement : standard (préapprouvé, à faible risque et courant), normal (nécessitant un examen et une approbation) ou d’urgence (nécessaire rapidement pour rétablir ou protéger un service). Le choix « urgence » fait apparaître une question obligatoire — « Pourquoi ce changement ne peut-il pas attendre le processus normal ? » — afin que les changements urgents soient tout de même accompagnés d’une justification documentée, au lieu d’échapper complètement au contrôle.

Chacun décrit ensuite les systèmes, services ou sites concernés, ce qui va changer et pourquoi le changement est nécessaire. Le fait de poser des questions distinctes, plutôt que de tout regrouper dans une grande zone de texte, permet à l’examinateur d’accéder directement à l’information qui l’intéresse, sans devoir parcourir un long texte pour trouver la raison de la demande.

2 Risques et impact

Cette page commence par une évaluation globale du risque : faible, moyen ou élevé. Tout niveau supérieur à faible déclenche une question complémentaire obligatoire : « Que pourrait-il se passer et comment ce risque est-il réduit ? » Une question matricielle demande ensuite au demandeur d’évaluer l’impact attendu — aucun, faible, moyen ou élevé — séparément pour le personnel, les clients, les données, la sécurité et les autres systèmes. Le résultat est bien plus clair qu’une simple description de l’impact en texte libre.

Le formulaire demande également directement s’il y aura une interruption de service (ce qui fait apparaître un champ consacré à la durée prévue en minutes et une question sur les personnes à prévenir, le cas échéant) et si le changement a été testé hors production. Répondre « oui » aux tests demande de préciser comment ils ont été réalisés ; répondre « non » exige d’expliquer pourquoi et comment le risque sera limité dans ce cas. Un changement non testé peut donc tout de même suivre le processus, mais jamais passer inaperçu.

3 Plan et retour en arrière

Ici, le demandeur détaille les étapes de mise en œuvre (le texte indicatif l’oriente vers une liste numérotée), explique comment il vérifiera que le changement a fonctionné et renseigne — le champ autour duquel tout le formulaire est véritablement construit — le plan de retour en arrière : comment annuler exactement le changement et quels éléments déclencheront la décision de revenir en arrière. Deux questions complémentaires facultatives demandent combien de temps prendrait un retour en arrière et si une sauvegarde ou un instantané sera réalisé au préalable. Ce sont des informations utiles pour la personne qui approuvera ou, pire encore, exécutera un retour en arrière d’urgence.

4 Calendrier et approbations

La dernière page définit la date prévue, l’heure de début et la durée estimée, puis demande si l’intervention se déroulera pendant une fenêtre de maintenance convenue. Elle indique qui effectuera le changement et qui l’approuvera, avec son adresse e-mail, ainsi qu’une liste des approbations déjà obtenues : responsable hiérarchique, propriétaire du système ou du service, sécurité, responsable métier, comité consultatif des changements ou aucune pour le moment. Un espace consacré aux documents justificatifs (procédures d’exploitation, schémas, notes du fournisseur) complète les éléments fournis. Enfin, une déclaration obligatoire demande au demandeur de confirmer qu’il ne commencera pas l’intervention avant l’approbation effective du changement.

Personnalisez le modèle

• Ajoutez vos propres types de changement ou catégories de risque si les catégories standard/normal/urgence et faible/moyen/élevé ne correspondent pas à votre processus
• Rendez les champs consacrés aux détails du risque ou au retour en arrière obligatoires pour chaque changement, et pas uniquement pour ceux à risque moyen/élevé, si votre équipe le souhaite quel que soit le niveau
• Orientez les changements d’urgence vers une autre liste de notification en dupliquant le formulaire et en ajustant ses paramètres, afin que les demandes urgentes parviennent plus rapidement aux bonnes personnes
• Ajoutez une liste déroulante de vos systèmes ou environnements réels à la place du champ de texte libre « systèmes concernés », si la liste de votre infrastructure est stable
• Classez les changements approuvés et rejetés dans des dossiers distincts du coffre-fort en utilisant deux versions du formulaire, ou ajoutez un champ de statut que vous remplirez après l’examen
• Activez un nombre maximal de réponses ou une date de clôture si vous utilisez ce formulaire pour un projet ponctuel de migration plutôt que pour des demandes de changement continues

Conseils pour un meilleur formulaire demande de changement

• Exigez un véritable plan de retour en arrière, et non « nous verrons bien » : si le formulaire rend ce champ obligatoire, ce n’est pas sans raison
• Veillez à ce que l’évaluation du risque reste honnête : un changement marqué comme présentant un risque faible ignore les questions de contrôle supplémentaires. Encouragez donc les utilisateurs à choisir un niveau supérieur plutôt qu’inférieur en cas de doute
• Examinez les changements d’urgence a posteriori, même lorsqu’ils ont été approuvés oralement sur le moment, afin de conserver une trace écrite
• Demandez aux utilisateurs de préciser les systèmes concernés : des réponses vagues rendent plus difficile la détection de changements incompatibles planifiés pendant la même période
• Tenez à jour la liste de vos approbateurs dans les cases à cocher et les listes déroulantes afin que les demandes n’attendent pas une personne qui a quitté l’équipe
• Utilisez régulièrement l’exportation CSV pour analyser le volume des changements et les tendances en matière de risques dans votre équipe, plutôt que de vous fier à votre mémoire

Formulaire Demande de changement : questions fréquentes

Plus de modèles de formulaires

Tous les modèles Informatique et opérations · Tous les modèles de formulaires

Les modèles sont un point de départ. Vérifiez que les questions et les formulations concernant le consentement, la confidentialité ou les conditions conviennent à votre situation et aux règles en vigueur dans votre région. Page révisée le 2026-09-26.