Poussés par l’évolution effrénée des technologies et sous la pression de la mondialisation des affaires, les changements sont devenus une exigence récurrente. Aussi, comment ce fait-il que les directions des services informatiques adhérent, presque spontanément, aux services de support technique et aux services de soutien aux utilisateurs (help desk), parmi les apports issus de ITIL, mais négligent régulièrement les bonnes pratiques en termes de gestion des changements?
La problématique
Toutes les offres de services, de la part des directions informatiques, reposent en général sur l’exploitation d’un système. Système qui peut être un système interne ou un système en impartition. Un tel système se compose d’un ensemble d’applications qu’il a fallu développer et mettre en exploitation. À tous les stades de sa vie, de sa conception à sa mise en exploitation, en passant par son développement, un système devra faire face à des « incidents ». C’est-à-dire des circonstances involontaires présentant un fonctionnement inadéquat ou inattendu. Cela peut-être simplement un bogue informatique, une incompatibilité des logiciels, mais aussi une demande de l’utilisateur, une modification ou une innovation. Le traitement impératif de chacun des incidents sera à l’origine d’un changement. Lequel est une source potentielle d’introduction de nouveaux éléments initiateurs d’autres incidents futurs, pour le système. Il en ressort que les incidents qui affectent, par exemple, les applications d’affaires sont fréquemment un « effet secondaire » des changements pratiqués antérieurement.
Les faits
Le lien entre les incidents survenus et les changements opérés est évident. Le lien entre les changements pratiqués et les incidents futurs est logique et confirmé par l’expérience. Les sources d’incidents sont multiples et nombreuses. Elles ne sont pas toutes inexorables. La plupart pourraient être anticipées. Parmi ces sources d’incidents se trouvent : la négligence; le manque de ressources; une préparation insuffisante; une mauvaise analyse d’impacts; des tests mal adaptés; une analyse des besoins non exhaustive; la maturité informatique des utilisateurs; des résultats de pilotages; des évolutions conjoncturelles; de nouveaux besoins; les glissements des pratiques; des nouveautés technologiques. Toutes créeront un incident et nécessiteront un changement.
L’évolution
Tout fournisseur de services informatiques, y compris la direction informatique pour l’interne, se doit de prendre rapidement le contrôle sur le chapelet d’incidents résultants des changements. Une opération critique et sûrement pas triviale qui, si elle échoue, risque de se propager à l’ensemble de l’organisation, comme une réaction en chaîne. Il est facile d’anticiper que toute cette série de changements doit être gérée. C’est ce que propose ITIL, dans un de ses fascicules. La gestion des changements est par conséquent un processus dans son ensemble.
• L’étendue du processus
L’étendue du processus est extrêmement vaste, puisque tous les changements en relèvent. Cependant, son périmètre est tout aussi important, et principalement sa frontière commune avec le processus de gestion des configurations et de sa CMBD (configuration management database). En effet, afin de garantir une synergie efficace et nécessaire entre le processus de gestion des configurations et celui de la gestion des changements, tous les incidents doivent être répertoriés dans la CMDB.
Les traitements de certains événements simples, fonctionnels et répétitifs sont bien maîtrisés. Ainsi, leurs impacts en sont amoindris. C’est les cas par exemple du changement régulier des bandes magnétiques des systèmes de sauvegarde. Bien qu’il s’agisse d’un incident dans sa définition, une telle opération sera plutôt classifiée comme une demande de service de base, dans le processus de gestion des incidents. Aussi, l’organisation devrait procéder à une analyse de ses actions de routine, principalement dans les opérations, pour reclassifier certains événements. Et éviter que la gestion des changements ne devienne un écheveau inextricable de bureaucratie.
• Les activités du processus
Le processus de gestion des changements, comme tout processus, est composé de plusieurs activités :
Tout d’abord, l’enregistrement. C’est l’activité initiale du processus. Pour qu’un changement puisse exister, il faut qu’une demande préliminaire soit enregistrée et consignée dans la base de données, avec toutes les informations afférentes.
Ensuite l’acceptation. Le processus de gestion des changements se poursuit par une analyse et une acceptation des demandes. Toutes les demandes incomplètes, imprécises, non justifiées, irréalisables, sont rejetées, avec une justification de cette décision.
Puis la classification. Cette activité a deux livrables, dont la priorité accordée aux changements, par le processus. Cette priorité est choisie parmi 4 niveaux qui sont : faible, normale, élevée et maximale. Le second livrable est la catégorie dans laquelle est rangé le changement. Les catégories du processus sont au nombre de trois, établies suivant le type d’impact anticipé, soit impact faible, impact important ou impact majeur.
Également la planification. Le processus de gestion des changements dispose d’une classification chronologique prévue de la réalisation des changements autorisés. Ce calendrier des changements contient toutes les informations relatives à chaque changement et à leur planification. C’est un véritable livre de bord. Les changements les plus importants devront passer par le Comité consultatif afin de tenir compte des diverses contraintes que sont la disponibilité du personnel, des personnes ressources, des budgets, des fournisseurs et des clients.
La coordination. C’est en quelque sorte la gestion de projet de la réalisation des changements prévus.
Puis l’évaluation. C’est l’étape qui conduira à l’autorisation nécessaire pour permettre la réalisation du changement. C’est une des étapes à laquelle intervient le Comité consultatif, si l’ampleur du changement le nécessite.
Enfin, la mise en œuvre. C’est-à-dire la réalisation, la production du changement concerné, afin qu’il puisse être par la suite mis en opération.
• La structure organisationnelle
Le processus de gestion des changements proposé par ITIL rassemble deux niveaux fonctionnels d’autorités. Tout d’abord, le gestionnaire des changements, qui est l’organisateur en chef de tous les changements. Il a pour prérogatives l’acceptation et la classification de toutes les demandes de changements. Il est également responsable de l’attribution des autorisations requises. Il lui incombe également la planification et de la coordination de la mise en œuvre des changements réalisés. C’est un réel directeur de projets spécialisés.
Ensuite, un Comité consultatif des changements. Cet élément structurel consultatif est réuni régulièrement, à dates fixes et planifiées, pour évaluer les demandes de changements et en planifier la réalisation. Pour des raisons d’efficacité, le Comité ne traite que les demandes de changements importants, en temps, en budget ou en risques inhérents pour l’organisation. En outre, ce Comité devra parfois siéger sur des réunions extraordinaires d’urgence, lorsqu’il sera nécessaire pour l’organisation de prendre des décisions urgentes relativement aux changements.
Le Comité consultatif est de composition assez libre, il comprend généralement le gestionnaire des changements, comme président, et des représentants de la direction informatique; de la gestion des incidents; du développement des applications; des infrastructures; de la gestion des niveaux de services; des logiciels et des systèmes; des utilisateurs; de la direction concernée des affaires; du groupe responsable de la clientèle; et des fournisseurs, si l’organisation a recourt à des services externes.
• Les coûts du processus
Comme tout processus, la gestion des changements n’est pas gratuite, mais offrira, après son implantation, son lot de compensations qui la feront basculer de poste de coûts en centre de profits. Les coûts de la gestion des changements sont généralement de deux ordres, les coûts d’acquisitions des outils et les coûts en personnel. Ces deniers incluant les coûts relatifs à l’acquisition de compétences nécessaires.
Les coûts des outils concernent souvent l’acquisition de logiciels de gestion des changements qui sont principalement des applications qui exploitent une base de données spécifique. Les coûts en personnel doivent être comptabilisés globalement, mais sont en partie compensés par le fait que l’organisation coordonne déjà les changements qu’elle réalise. Même si cela ne se fait pas au sein d’un processus structuré.
La conclusion
Ce qui différencie les multiples aspects du support et de la gestion des changements est une différence de paradigme. En effet, les différents aspects du support sont des opérations qui se réalisent en mode réactif, suite à un événement intervenu dans les opérations ou dans la consommation d’un service alors que la gestion des changements se réalise en mode proactif et investigateur.
La gestion des changements vise à identifier et à anticiper tous les problèmes risquant de provoquer, dans un futur proche ou lointain, un incident aussi minime soit-il. Si les interventions dans un des processus du support sont un travail de redressement, celles réalisées dans le processus de gestion des changements sont un travail prospectif. Le résultat des interventions de support a une action immédiate et visible de tous, alors que les résultats des interventions en gestion des changements ont des actions ultérieures, voire supprimées, et, par conséquent ne sont que peu visible.
Certes, il est compréhensible que les directions des services informatiques, souvent à court de budgets et de temps, priorisent le court terme et le visible. Cependant, il n’est pas certain qu’il s’agisse d’un choix judicieux pour l’organisation. Pour garder frais en mémoire les impacts de la gestion des changements, retenons cette citation dont l’auteur n’est pas spécifié : « Si chacun des changements perpétrés ne constitue pas une amélioration en soi, cependant chaque amélioration est inéluctablement un changement par essence… »
Gérard Blanc est associé principal d’une firme conseil en gestion et en systèmes d’information.
