Après avoir codé et testé une nouvelle modification, l'étape suivante consiste à la transmettre à l'environnement de production. Tout d'abord, la modification doit être approuvée et planifiée. A ce stade, il faut aussi informer tous ceux que la modification concernera d'une manière ou d'une autre. Si on ne peut pas
Déployer les modifications

obtenir un verrouillage d’objet, par exemple, il n’est pas possible de transmettre la modification. Et il faut demander aux utilisateurs d’arrêter momentanément l’utilisation de composants critiques.
A ce stade, la messagerie automatique est intéressante car elle permet de
demander aux utilisateurs de quitter l’application
inviter l’administrateur système à obliger les utilisateurs à quitter l’application s’ils ne l’ont pas déjà fait
communiquer l’étape suivante à tous les intéressés, une fois le travail de transfert effectué
informer les utilisateurs quand ils peuvent utiliser à nouveau l’application
Un système de Change Management doit obligatoirement s’accompagner d’une communication systématique et régulière à propos de l’activité de modification du logiciel. Il faut, par exemple, savoir si une personne étrangère au contrôle du Change Management essaie de modifier du code. Il peut aussi y avoir des erreurs de déploiement, auquel cas on pourra être amené à annuler une modification après son déploiement sur le réseau. Et il faut déterminer quand une « modification d’urgence » intervient, car c’est ce qui provoque généralement les problèmes.
Téléchargez cette ressource

Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.