La maîtrise des changements, installations et mises à jour est cruciale pour la fiabilité des systèmes, mais beaucoup d’entreprises n’ont cependant pas mis en place des procédures sécurisées de gestion des changements, notamment un Change Advisory Board (CAB).
« On ne touche pas à un système qui fonctionne ! » : cette devise de prudence des DSI est justifiée par le fait que plus de 80 % des incidents et dysfonctionnements des systèmes opérationnels sont consécutifs à un changement, un ajout de système ou une mise à jour logicielle. Selon la dernière étude publiée par le Clusif (Club de la sécurité de l’information français), les erreurs d’utilisation (saisie, exploitation d’un système…) et les pannes internes (plantage système et/ou logiciel entraînant l’indisponibilité d’un système) figurent en seconde place dans le classement des incidents subis par les entreprises françaises, derrière les infections virales. En moyenne, chaque année, une entreprise est confrontée à six pannes et à une dizaine d’erreurs d’utilisation.
Certes, par définition, si l’on ne touche à rien, les systèmes fonctionnent et ne posent guère de problème. On minimise ainsi les risques de dysfonctionnement, mais au prix d’une contrepartie qui n’est guère acceptable : les systèmes et les applications n’évoluent pas… Le changement fait partie intégrante du cycle de vie d’un système d’information : le Change Advisory Board (comité de gestion des changements) constitue le garde-fou indispensable de l’exploitation, car, si les équipes d’études ont pour objectif que le nouveau système « tombe en marche », celui de l’équipe d’exploitation est qu’il ne tombe pas en panne lorsqu’il est en fonctionnement opérationnel.
Un comité… et des procédures
Le Change Advisory Board est une instance qui se réunit, dans l’idéal, sur un rythme hebdomadaire et applique des procédures sécurisées pour gérer chaque type de changement. En s’appuyant sur les processus Itil, le CAB a pour objectif de coordonner les changements pour en minimiser les risques et les conséquences pour les utilisateurs.
Pour atteindre cet objectif, le CAB doit avoir le pouvoir de refuser ou différer une mise en production, si le changement n’est pas opportun ou si toutes les conditions du succès ne sont pas réunies. D’où la nécessité de veiller à ce que le CAB se voit attribuer les bonnes responsabilités et les bonnes compétences, avec une palette suffisamment large.
Ainsi, il est présidé par le directeur technique et regroupe tous les responsables des études (un changement dans une application peut avoir un impact sur une autre), l’équipe d’exploitation, le responsable sécurité et le responsable du support.
Concrètement, chaque modification, mise en production, mise à jour logicielle ou installation d’équipement est validée et planifiée, en fonction du calendrier business, de manière à éviter des « collisions » malheureuses et sources potentielles de dysfonctionnement, par exemple lorsqu’une migration de version d’un ERP est prévue le même jour que la clôture de l’exercice fiscal…
Dans ce calendrier sont en effet consignés tous les évènements métiers à prendre en considération pour planifier un changement au moment le plus opportun : opération d’inventaire, clôture de fin de période, ouvertures de nouveaux magasins, opérations de soldes, mise à jour tarifaire, lancement d’une ligne de production, etc.
Pour les changements majeurs, le rôle du CAB est de vérifier que tous les préalables au changement sont validés, notamment les éléments suivants :
- Les tests utilisateurs
- Les tests de charge
- La formation des utilisateurs
- La formation des équipes de support
- Les mises à jour des dossiers d’exploitation
- Les procédures de retour arrière en cas de problème
- …
Dans le cadre du CAB, sont analysés, en particulier, tous les impacts et les conséquences que peut avoir la mise en place du nouveau système sur les autres composants du système d’information. Chaque changement est donc formellement validé par tous les acteurs concernés, seul moyen de conserver la cohérence des changements, de limiter les risques de dysfonctionnements et, surtout, d’effets en chaîne dévastateurs pour l’image de la DSI, vis-à-vis des métiers et des utilisateurs ou, pire, des clients.
Une fois un changement acté et planifié, le CAB s’assure que chacun dispose de la bonne information, y compris les utilisateurs, et de la bonne coordination de tous les acteurs concernés. Après la mise en place opérationnelle, le CAB suit également la « clôture » du changement.
Des procédures différenciées selon le type de changement
En fonction de la nature du changement et du niveau de risque, différents types de changement sont définis, donnant lieu à des procédures et des grilles de responsabilités différentes.
Classiquement, on différencie plusieurs catégories de changements :
- Les changements standards, récurrents, qui suivent un processus prédéfini, dont les impacts sont bien identifiés et les risques maîtrisés, par exemple : remplacement d’un équipement défectueux, mise à jour logicielle mineure, historisation de données, etc. Dans ce cas la procédure est très simplifiée.
- Les changements normaux, qui nécessitent une analyse d’impact et une analyse des risques.
- Les changements opérationnels, actes standards d’administration, pour lesquels la procédure est automatique.
- Les changements urgents, qui nécessitent une mise en production le plus rapidement possible.
Pour les changements normaux, qui suivent le processus complet de gestion du changement, plusieurs variantes du processus sont proposées selon qu’il s’agit, par exemple, de la mise en place d’un nouveau module logiciel, de la modification d’un flux de données (API, Web Service, interfaces…), d’une intervention physique sur les serveurs ou d’une importante opération planifiée.
Changement urgent = changement bâclé ? Non…
Les changements urgents sont généralement consécutifs à un changement mal maîtrisé ou un accident, ayant provoqué un traitement erroné et une corruption des données. Une nouvelle mise en place et un traitement correctif des données sont souvent nécessaires le plus tôt possible. Minimiser le temps d’intervention est d’autant plus crucial si les équipes techniques s’aperçoivent qu’elles ont commis une erreur : elles ont alors tendance à chercher à la corriger le plus rapidement possible, sans publicité… mais en confondant parfois vitesse et précipitation.
Le cas de la modification dans l’urgence est celui qui nécessite les procédures sécurisées les plus strictes et les plus contrôlées, afin d’éviter de nouvelles erreurs (surtout si elles ont été commises une première fois…) et une corruption des données encore bien plus compliquée à récupérer. Dans l’urgence, il n’est pas facile de réunir le comité CAB. Il faut alors prévoir des procédures de consultation, de validation et de coordination par e-mail ou par chat, dans le cadre d’un « e-CAB ».
Même si des procédures formelles de gestion du changement peuvent paraître lourdes à mettre en place pour des sociétés de taille moyenne, elles sont pourtant indispensables pour garantir la fiabilité des systèmes opérationnels. Il faut cependant être conscient que ces procédures ne seront efficaces que si un certain nombre de préalables sont opérationnels.
- En effet, une analyse d’impact d’un nouveau système nécessite par exemple :
- Une cartographie des systèmes, à jour.
- Une cartographie des flux de données, à jour.
- Une documentation d’exploitation complète et bien tenue.
- Un dictionnaire des données complet, avec le recensement de tous les systèmes utilisant chaque famille de données.
- Un outil et des jeux de tests.
- Un calendrier business formalisé.
La maîtrise des changements, et le CAB en particulier, s’inscrivent donc dans le plan global de gouvernance du système d’information.
Cet article a été écrit par Pascal de La Faye, conseil en stratégie et gouvernance des systèmes d’information. www.delafaye.eu
L’avis de Best Practices
En matière de management des systèmes d’information, on parle beaucoup de gestion du changement, pour les utilisateurs. Certes, c’est fondamental et un projet ne peut réussir si cette composante n’est pas prise en compte et gérée correctement. Mais il est un autre type de changement, tout aussi fondamental mais souvent oublié, car peu visible : celui du changement technique ou fonctionnel.
Tous les systèmes d’information y sont confrontés : on imagine mal, en effet, conserver à l’état statique un système d’information. Même les DSI et les métiers les plus conservateurs doivent gérer ce type de changement. Dès lors, trois approches sont possibles. La première consiste à ne rien faire, en colmatant les brèches lorsqu’elles se forment, en s’adaptant aux ruptures dès qu’elles deviennent trop voyantes ou en externalisant lorsque la situation devient ingérable en interne.
La seconde consiste à agir de façon ponctuelle, projet par projet, application par application. Cette approche fonctionne lorsque l’ampleur des changements techniques et fonctionnels ne submerge les équipes. La troisième, la plus judicieuse, correspond à la prise en compte du changement comme élément clé du cycle de vie du système d’information, avec un Change Advisory Board.
Les trois mots sont importants : « Change » parce que le SI est un organisme vivant ; « Advisory » parce que l’on ne peut pas tout faire et qu’il faut prioriser ; « Board » pour positionner le changement au niveau qui lui revient : un élément stratégique de perfomance et de création de valeur.