Contrôles de la gestion du changement et des patchs : Un ...€¦ · ments fondamentaux concourant à la maîtrise du processus de gestion des changements informa-tiques, à savoir

Contrôles de la gestion du

changement et des patchs :

Un facteur clé de la réussite

pour toute organisation

2ème édition

Mars 2012

Copyright © 2012 par l’Institute of Internal Auditors, 247 Maitland Ave., Altamonte Springs, Floride, 32701-4201,États-Unis. Tous droits réservés. Imprimé aux États-Unis. Aucune partie de cette publication ne peut être reproduite,stockée dans un système de consultation ou transmise sous quelque forme que ce soit, ni par aucun moyen (électro-nique, mécanique, reprographie, enregistrement ou autre) sans autorisation écrite préalable de l’éditeur.

L’IIA publie ce document à titre informatif et pédagogique. Cette publication entend donner des informations, maisne se substitue en aucun cas à un conseil juridique ou comptable. L’IIA ne fournit pas ce type de service et ne garantit,par la publication de ce document, aucun résultat juridique ou comptable. En cas de problèmes juridiques ou comp-tables, il convient de recourir à l’assistance de professionnels.

Contenu

3

Résumé ............................................................................................................................................................. 4

1. Introduction ........................................................................................................................................... 5

2. Pourquoi se préoccuper de la manière dont son organisation gère les changements ? ................ 11

3. Définir la gestion des changements informatiques .......................................................................... 15

4. Quelles questions dois-je poser à propos de la gestion des changements et des patchs ? .......... 26

5. Par quoi les auditeurs internes doivent-ils commencer ? ................................................................ 31

Annexe A : Exemple d’étude de cas pour la gestion des changements .................................................... 35

Annexe B : Exemple de programme d’audit ............................................................................................... 37

A propos du CRIPP ....................................................................................................................................... 40

Résumé

4

Résumé

Chaque risque informatique induit un certainniveau de risque opérationnel. C’est pourquoi lesresponsables d’audit interne (RAI) doivent possé-der une connaissance approfondie des problèmesliés à la gestion des changements et des patchsdans les systèmes d’information (SI).

La gestion des changements et des patchs dans lesSI peut se définir comme l’ensemble des processusexécutés au sein du département informatiquedans le but de gérer les évolutions, les mises à jour,les correctifs incrémentaux, et les patchs appliquésaux systèmes de production, ce qui comprend :• La maintenance du code applicatif.• Les montées en version de systèmes (parexemple les applications, les systèmes d’ex-ploitation, et les bases de données).

• Les changements dans l’infrastructure (parexemple les serveurs, le câblage, les routeurs etles pare-feux).

Pour obtenir un environnement informatique pro-ductif stable et bien géré, il est nécessaire que lamise en œuvre des changements soit prévisible etreproductible et qu’elle respecte un processus maî-trisé, c’est-à-dire défini, piloté et effectivementappliqué. La séparation des fonctions (par exem-ple, la séparation des tâches de préparation, detest, d’exécution et d’approbation) et des contrôlesréguliers atténueront le risque de fraude et d’er-reur dans le processus.

Les auditeurs internes devraient connaître les élé-ments fondamentaux concourant à la maîtrise duprocessus de gestion des changements informa-tiques, à savoir notamment que : • Seuls les collaborateurs chargés de mettre enœuvre les changements dans les systèmesd’information devraient avoir accès à l’envi-ronnement de production ; leur nombredevrait être réduit au minimum (mesure deprévention).

• les processus d’autorisation devraient associerles parties prenantes concernées afin qu’ellesévaluent les risques générés par les change-

ments envisagés et définissent les mesurespour les réduire (mesure de prévention).

• Les processus de supervision devraient inciterle management et le personnel informatiquesà prendre pleinement conscience de la respon-sabilité de leurs tâches (mesure de prévention)et à détecter des performances insatisfaisantes(mesure de détection).

Ce guide pratique d’audit des technologies de l’in-formation (GTAG) est conçu pour aider les audi-teurs internes à poser les bonnes questions à laDSI afin d’évaluer la capacité de cette direction àgérer les changements, d’évaluer le niveau derisque global du processus et de déterminer si unexamen plus détaillé du processus est nécessaire.

Ce guide permettra aux auditeurs internes :• D’acquérir une connaissance opérationnelledes processus de gestion des changementsinformatiques.

• De distinguer rapidement les processus effi-caces de gestion des changements de ceux quine le sont pas.

• De reconnaître rapidement les indicateurs etsignaux d’alerte signalant une défaillance descontrôles liés à la gestion des changementsdans les environnements informatiques.

• De prendre conscience que l’efficacité de lagestion des changements repose sur la mise enplace de contrôles préventifs, détectifs et cor-rectifs qui assurent la séparation des fonctionset la supervision appropriée du management.

• De recommander les meilleures pratiquesconnues pour remédier aux défaillances, afinde vérifier que les risques sont maîtrisés (etque les contrôles sont bien effectués) et d’ac-croître l’efficacité et l’efficience.

• De faire passer plus efficacement les recom-mandations auprès du directeur des systèmesd’information, du directeur général et/ou dudirecteur financier.

GTAG – Introduction

5

1. Introduction

Ce guide présente la gestion des changements etdes patchs informatiques comme un outil de ges-tion et aborde les questions suivantes : • Pourquoi la gestion des changements et despatchs informatiques est-elle importante ?

• Comment la gestion des changements et despatchs informatiques permet-elle de mieuxcontrôler les coûts et les risques liés aux SI ?

• Comment des indicateurs peuvent identifier cequi fonctionne et ce qui ne fonctionne pasdans le processus de changement ?

• Comment juger du succès ou de l’échec de lagestion des changements et des patchs infor-matiques ?

• Comment réduire les risques associés auxchangements informatiques ?

• Les responsabilités de l’audit interne.

Dans ce GTAG, le terme « Conseil » est utilisé ausens du glossaire des Normes : « Le niveau le plusélevé des organes de gouvernance, responsable dupilotage, et/ou de la surveillance des activités et dela gestion de l'organisation. Habituellement, leConseil (par exemple, un conseil d’administration,un conseil de surveillance ou un organe délibé-rant) comprend des administrateurs indépen-dants. Si une telle instance n’existe pas, le terme« Conseil », utilisé dans les Normes, peut désignerle dirigeant de l’organisation.Le terme « Conseil » peut renvoyer au comitéd’audit auquel l’organe de gouvernance a déléguécertaines fonctions ».

1.1 Pourquoi la gestion deschangements et des patchsinformatiques est-elleimportante ?

Des études récentes ont démontré qu’une mau-vaise gestion des patchs et des changements infor-matiques entraînait une augmentation des coûtset des périodes d’indisponibilité du service. Au fildu temps, les activités informatiques dans diverses

organisations ont vu des changements occasion-ner des interruptions majeures et prolongées. Maispar où commencer pour évaluer les coûts liés à desproblèmes d’une telle ampleur ?

On peut considérer que les organisations bénéfi-ciant d’une meilleure gestion des changements etdes patchs informatiques : • consacrent moins de temps et d’énergie dansles SI pour des interventions non program-mées,

• consacrent davantage d’argent et d’énergiedans les SI pour exécuter de nouvelles tâcheset atteindre les objectifs de l’entreprise,

• connaissent moins de périodes d’indisponibi-lité,

• installent des patchs avec un minimum de per-turbations,

• sont plus focalisées sur les améliorations quesur les réparations en urgence.

Si les organisations ont besoin de mesures incita-tives supplémentaires, il existe dans plusieurs paysdes lois qui requièrent que la direction généralecomprenne et avalise les contrôles portant sur lereporting financier, y compris les contrôles infor-matiques. Sans une gestion efficace des change-ments informatiques, on voit mal comment lemanagement pourrait répondre aux exigences dela loi et certifier l’intégrité de l’information finan-cière.

1.2 Comment la gestion deschangements et des patchsinformatiques permet-elle demieux contrôler les coûts et lesrisques liés aux SI ?

Chaque risque lié aux SI peut être amplifié par unemauvaise gestion des changements informatiques.À l’inverse, les risques peuvent être contrôlés àl’aide de processus de gestion des changements etdes patchs informatiques appropriés et bienconçus. De manière peut-être moins évidente, unegestion appropriée des changements et des patchs


6

informatiques peut contribuer à réduire les coûts.

Faute des contrôles et de la visibilité appropriés,une organisation risque de consacrer des finance-ments et des efforts à des changements inutiles ounon prioritaires, tout en négligeant des initiativesplus importantes. Des changements mal conçusou mal évalués sont susceptibles de créer des pro-blèmes qu’il faudra résoudre a posteriori, ou d’en-traîner un « retrait » de changements. Deschangements informatiques apportés à une seulecomposante peuvent perturber l’exploitation d’au-tres composantes. Ces perturbations sont coû-teuses en temps et en argent, mais elles peuventêtre atténuées grâce à des processus appropriés degestion des changements et des patchs informa-tiques.

Au terme du processus, plusieurs facteurs liés àune gestion des changements informatiques inef-ficiente ou inefficace peuvent pénaliser une orga-nisation de différentes manières : • Départ de personnel informatique très qualifié,en raison de la frustration suscitée par unequalité médiocre des résultats.

• Systèmes de mauvaise qualité, qui rendent lepersonnel inefficient et inefficace ou qui pro-voquent le mécontentement des clients.

• Occasions manquées pour proposer auxclients des produits et services innovants ouplus efficients.

Des processus de gestion des changements infor-matiques bien conçus et installés avec rigueurpeuvent produire les effets inverses. Il est possiblede concentrer les efforts informatiques sur lespriorités du métier l’entreprise. Le nombre dedépannages en urgence peut être réduit au mini-mum. On peut s’efforcer de retenir le personnelinformatique et de le motiver pour qu’il excelle. Ilest possible d’équiper le personnel d’outils quiaccroîtront sa productivité. Enfin, les clients peu-vent être satisfaits par des systèmes qui répondentà leurs besoins.

1.3 Qu’est-ce qui fonctionne etqu’est-ce qui ne fonctionne pas ?

Pour que la gestion des changements informa-tiques soit efficace, elle doit procurer à la directionde l’organisation de la visibilité sur les problèmessuivants : • ce qui a été changé, pourquoi et quand ;• l’efficience et l’efficacité de l’installation deschangements ;

• les problèmes qui sont causés par les change-ments et leur degré de gravité ;

• le coût des changements ;• les effets positifs des changements.

Une telle visibilité est possible à travers desmesures et des indicateurs examinés de manièrerégulière et objective. Ils constituent les compteursdu tableau de bord, nécessaires pour assurer unebonne visibilité au management. Les changements informatiques sont l’accéléra-teur, le frein et le volant (et la marche arrière pourle retour à une configuration antérieure) qui per-mettent de contrôler les SI et ce, par différentsmoyens : • une implication précoce et régulière du mana-gement et des utilisateurs finaux afin d’adapterles changements informatiques aux besoins del’entreprise ;

• un processus défini, prévisible et reproductible,avec des résultats définis, prévisibles et repro-ductibles ;

• la coordination et la communication avec lesintervenants affectés par les changements.

1.4 Comment juger du succès ou del’échec de la gestion deschangements et des patchsinformatiques ?

Le management, y compris le management infor-matique, peut se faire une bonne idée du succèsou de l’échec de la gestion des changements et despatchs en étudiant les réponses données aux ques-tions simples qui suivent :


7

• Le processus de gestion des changements est-il efficace ? La réponse nie-t-elle l’importancedes changements informatiques ou la recon-naît-elle en soulignant les progrès en cours ?

• Quels sont les contrôles en place dans le cadrede notre processus de gestion des change-ments ? Des contrôles sont-ils en place et encours d’amélioration ou sont-ils simplementévalués et différés jusqu’à ce que les dépan-nages en urgence se raréfient ?

• Avons-nous observé des bénéfices liés au pro-cessus de gestion des changements ? Existe-t-il des bénéfices mesurables ou l’accent est-ilmis sur les coûts induits par le processus degestion des changements informatiques ?

• Qu’en est-il de l’interruption de service due àun changement et qui a touché l’ensemble dusite la semaine dernière ? Que s’est-il passé ?À quel point le management est-il informé surles causes des interruptions de service ? Quelest le niveau de contrôle du management surla récurrence du problème ?

• Quel processus a été utilisé pour déterminer lacause de l’interruption de service ? S’agit-ild’une démarche improvisée ou méthodique ?Le diagnostic du problème a-t-il permis dedéterminer rapidement si c’est un changementqui a provoqué l’interruption de service ? Sioui, quel changement est à l’origine du pro-blème ?

• De quelle manière l’informatique contribue-t-elle au suivi du bon fonctionnement du pro-cessus ? Les mesures et les indicateurs sont-ilsobjectifs et vraiment révélateurs ou sont-ilssubjectifs et sujets à caution ?

• Quel est l’objectif de notre processus de ges-tion des changements ? Est-il axé sur la fiabi-lité, la disponibilité et l’efficience ou surd’autres priorités, moins cruciales ? Est-il toutsimplement axé sur une priorité ?

• À quel point notre processus de gestion despatchs est-il perturbateur ? La gestion despatchs est-elle intégrée dans un processus dechangement et de mise en production défini etreproductible, ou s’inscrit-elle dans unedémarche improvisée, informelle et reposantsur l’urgence ?

Les cinq principaux indicateurs d’une mauvaisegestion des changements : • Changements non autorisés (plus de zéro est un

résultat inacceptable). • Interruptions de service non programmées. • Faible taux de réussite des changements. • Nombre élevé de changements en urgence. • Retards dans le déploiement des projets.

Voici quelques symptômes et indicateurs decontrôles déficients aisément repérables, qui révè-lent des changements informatiques mal maîtri-sés : • Indisponibilité de services ou de fonctions cri-tiques, même pendant un bref laps de temps.

• Indisponibilité non programmée de réseaux oude systèmes, induisant une interruption del’exécution de processus critiques, tels que lacoordination des plannings avec les fournis-seurs ou le traitement des commandes desclients.

• Indisponibilité d’applications critiques, debases de données ou de serveurs Internet, quia pour effet d’empêcher les utilisateurs d’exé-cuter les tâches critiques qu’ils ont à accomplir.

• Publicité négative et interrogation non souhai-tée de la part des organes dirigeants.

Au niveau organisationnel, voici quelques indica-teurs révélant d’éventuels problèmes systémiquesde maîtrise du processus de gestion des change-ments : • La DSI consacre la majorité de son temps àl’exploitation et à la maintenance (> 70 %)plutôt qu’à contribuer au développement desactivités.

• Des projets et des tâches programmées ne sontpas menés à terme (en raison du nombre élevéde dépannages en urgence et d’interventionsnon programmées).

• Interventions de nuit du management infor-matique pour résoudre des problèmes.

• Forte rotation du personnel informatique. • Relations conflictuelles entre le personneld’assistance, les développeurs et les clients(internes ou externes), généralement en raison


8

d’une qualité de service médiocre ou d’unretard dans la livraison d’une fonctionnalité.

• Le management informatique a besoin debeaucoup de temps pour répondre aux auditsinformatiques et pour mettre en œuvre lesrecommandations.

Les organisations qui améliorent leurs processusde gestion des changements et des patchs ontbesoin de moins en moins d’administrateurs sys-tème. Quand la gestion des changements et despatchs dans les SI fonctionne bien, les informati-ciens sont plus efficaces et productifs.Des mesures plus formelles et plus rigoureusespeuvent et doivent être examinées afin d’assurerune visibilité maximale sur l’efficacité de la gestiondes changements et des patchs informatiques,telles que : • Le nombre de changements autorisés parsemaine.

• Le nombre de changements installés parsemaine.

• Le nombre de changements non autorisés quicontournent le processus de changement.

• Le taux de réussite des changements (pour-centage de changements effectifs qui n’ont pasdonné lieu à une interruption de service, à unedétérioration du service ou à une charge detravail non programmée).

• Le nombre de changements en urgence (ycompris les patchs).

• Le pourcentage de patchs déployés au coursdes mises en production programmées de ver-sions de logiciels.

• Le pourcentage de temps consacré à destâches non programmées.

• Le pourcentage de projets livrés en retard.

1.5 Comment réduire les risques liésaux changementsinformatiques ?

Ce guide présente les meilleures pratiques de ges-tion des changements qui permettent de réduireles risques opérationnels et d’accroître l’efficacité

et l’efficience des SI. Afin d’améliorer leurs proces-sus de gestion des changements, les organisationspeuvent immédiatement appliquer cinq mesuresessentielles : • Faire preuve d’exemplarité (tone at the top), enincitant à adopter une culture de la gestion deschangements dans toute l’entreprise, en s’ap-puyant sur une déclaration du managementdes SI qui précise que le nombre acceptable dechangements non autorisés ne peut êtrequ’égal à zéro. Des contrôles préventifs etdétectifs peuvent ensuite être mis en place afind’atteindre cet objectif, et de le maintenir dura-blement, en garantissant que tout changementdans la production peut être rapproché d’ordrede production autorisé.

• Surveiller en permanence le nombre d’inter-ruptions de service non programmées, celui-ciétant un excellent indicateur des changementsnon autorisés et des défaillances dans la miseen œuvre des changements.

• Réduire le nombre de changements à risqueen déterminant clairement et faisant respecterdes périodes de gel et des plages de tempsouvertes à la maintenance. Cela a pour effetd’optimiser la stabilité et la productivité pen-dant les heures de production. Les interrup-tions de service non programmées constituentde bons indicateurs d’un contournement duprocessus.

• Utiliser le taux de réussite des changementscomme un indicateur clé de la performance enmatière de gestion des SI. Les changementsnon gérés, non pilotés et non contrôlés affi-chent généralement un taux de réussite infé-rieur à 70 %. Chaque changement ayantéchoué est potentiellement à l’origine depériodes d’indisponibilité, de travail non pla-nifié et réalisé en urgence, d’écarts par rapportaux programmes établis et de risques pourl’entreprise. Une hausse du taux de réussitedes changements passe nécessairement pardes contrôles préventifs, détectifs et correctifs.

• Utiliser le nombre de tâches non planifiéescomme un indicateur de l’efficacité des proces-sus de gestion et de contrôle des changementsinformatiques. Là où les organisations perfor-


9

mantes consacrent moins de 5 % de leurtemps à des tâches non programmées (eturgentes), la plupart des organisations yconsacrent, en moyenne, de 45 à 55 % de leurtemps.

1.6 Ce que l’audit interne devraitfaire

Ce GTAG traite de la gestion des risques quiconstituent une préoccupation croissante des par-ties prenantes au processus de gouvernance. Àl’instar de la sécurité informatique, la gestion deschangements informatiques est un processus fon-damental qui, s’il n’est pas exécuté correctement,peut nuire à l’entreprise dans son ensemble. C’estpourquoi cet aspect intéresse de nombreux comi-tés d’audit et, par conséquent, la direction géné-rale.

Ce guide propose des outils pour aider les audi-teurs internes à obtenir des preuves attestant lesaffirmations du management informatique (per-formance, efficacité, efficience) et à en évaluerl’exactitude. Tout comme pour le processus d’auditfinancier1, les auditeurs informatiques doiventobtenir des données d’autorisation sous-jacentes(par exemple, des rapports d’autorisation deschangements) et des informations de recoupe-ment (par exemple, des rapports de changementsdans la production issus des contrôles détectifs,des rapprochements de changements dans la pro-duction et de changements autorisés, des inter-ruptions de service, etc.). En agissant ainsi, lesauditeurs internes sont en mesure d’émettre uneopinion sur les affirmations du management infor-matique concernant ses processus de gestion deschangements et sa capacité à atténuer les risquesliés aux informations financières.

Les auditeurs internes peuvent aider le manage-ment et le Conseil en : • appréhendant les objectifs de l’organisation enmatière de confidentialité, d’intégrité et de dis-ponibilité du traitement informatique.

• aidant à identifier les risques potentiellement

induits par les changements et déterminer sices derniers correspondent au goût pour lerisque et à la tolérance au risque de l’organi-sation.

• aidant à définir un ensemble de mesures degestion du risque appropriées.

• recherchant et en encourageant une culture degestion des changements disciplinée, et enpromouvant notamment les bienfaits d’unebonne gestion des changements.

• comprenant les contrôles qui sont cruciauxdans le cadre d’une approche solide de la ges-tion des changements informatiques. - Prévention- Autorisations appropriées. - Séparation des fonctions. - Supervision.

- Détection- Détection des changements non autori-sés.

- Suivi des indicateurs valides et objectifsde la gestion des changements.

- Correction- Revue après installation. - Intégration de l’information sur les chan-gements lors des premières étapes dudiagnostic des problèmes.

• se tenant informé des principaux processusactuels de gestion des patchs et des change-ments informatiques et établissant des recom-mandations en vue de leur adoption parl’organisation.

• démontrant comment le management peuttirer parti d’une meilleure gestion des risques,d’une plus grande efficacité et d’une réductiondes coûts.

• aidant le management à identifier desapproches pratiques et efficaces de la gestiondes changements informatiques.

1 Overview of Auditing / O’Reilly et al. - in Montgomery’s Auditing:12e edition. – 1998.


10

1.7 La gestion du changement selonles Normes et les lignesdirectrices de l’IIA

Les lignes directrices suivantes de l’Institute ofInternal Auditors (IIA) décrivent les rôles et respon-sabilités des auditeurs internes afférents à la ges-tion du changement et des patchs au sein del’organisation : • Norme 2120 : Management des risques• MPA 2120-1 : Evaluer la pertinence des pro-cessus de management des risques

• Norme 2130 : Contrôle• MPA 2130-1 : Evaluer la pertinence des pro-cessus de contrôle

• MPA 2130.A1-1 : Fiabilité et intégrité de l’in-formation

Les guides pratiques de l’IIA sont également dis-ponibles : • GTAG 1 : Les contrôles et le risque des sys-tèmes d’information – 2nde édition

• GTAG 3 : Audit continu – répercussions surl’assurance, le pilotage et l’évaluation desrisques

• GTAG 9 : Gestion des identités et des accès• GTAG 17 : Audit de la gouvernance des sys-tèmes d’information

• Guide pratique : Auditer l’environnement decontrôle

• Guide pratique : Evaluer l’adéquation dumanagement des risques

GTAG – Pourquoi se préoccuper de la manièredont son organisation gère les changements ?

11

2. Pourquoi se préoccuperde la manière dont sonorganisation gère leschangements ?

Les auditeurs internes et les professionnels des SIdisposent de multiples recommandations au sujetde la gestion des changements et de leur contrôleappliqués à l’exploitation informatique. La publi-cation de référence de l’Institute of Internal Audi-tors, Systems Auditability and Control (1977), a étéréactualisée en 1994 et montre bien l’importancede ce sujet pour les managers et les auditeursinternes :

La gestion des changements et des problèmesest cruciale si l’on veut obtenir un fonctionne-ment stable, fiable et correctement maîtrisé.Elle implique un suivi des problèmes, des pro-cédures d’escalade, un examen des problèmeset des changements par le management, unehiérarchisation des ressources, des mises enproduction maîtrisées et un contrôle des chan-gements applicatifs.

Cependant, ce n’est que depuis peu que l’on s’at-tache véritablement à comprendre de quelles pra-tiques informatiques et de quels environnementsdépendent les résultats de l’entreprise. Ces effortsmontrent une culture de gestion du changementeffective qui fait l’une des différences fondamen-tales entre les organisations ayant un SI perfor-mant et sécurisé et les autres. En d’autres termes,la gestion des changements n’est pas seulementun dispositif de contrôle essentiel mais égalementune source potentielle de bénéfices pour l’entre-prise.

2.1 Les changements sont source derisque : pourquoi faut-ilconsidérer les patchs commen’importe quel autrechangement ?

Les auditeurs sont conscients de l’étroite relationqui existe entre changements et risques. Les actifs

informatiques semblent être en constante évolu-tion. Le management des SI doit donc traiter : • Des changements réguliers (classiquement, lesmontées de version planifiées concernant lesapplications, le middleware, les systèmes d’ex-ploitation ou les matériels et les logicielsréseau).

• Les patchs (changements visant à remédier àdes codes défectueux ou à d’autres vulnérabi-lités décelées dans la production).

• Les changements à opérer en urgence pourrésoudre des problèmes immédiats à l’origined’interruptions du service.

Grâce à une gestion efficace des changementsinformatiques, l’organisation peut passer en toutesécurité d’un état connu et défini à un autre, quelleque soit la motivation du changement.

Les actifs informatiques sont plus faciles à gérer età contrôler en l’absence de pression pour mettreen œuvre les changements. Ainsi, il peut être bonde définir des plages sans aucun changement : leniveau de service et la disponibilité sont alors àleur maximum, et le département informatiqueconsacre l’essentiel de son temps à des tâches pla-nifiées. Mais que se passe-t-il lorsque des vulné-rabilités critiques sont mises en évidence et quedes changements deviennent plus urgents ? Quese passe-t-il lorsque nombre de vos fournisseursdéploient régulièrement des patchs pour réparerdes failles critiques ? Le nombre de patchs urgentsà appliquer et l’absence de procédure ad hoc estun problème critique pour beaucoup d’entreprises.

Dans les organisations peu performantes, ledéploiement des patchs se fait au cas par cas, demanière chaotique et urgente. Lorsqu’un patch estproposé pour remédier à une vulnérabilité desécurité critique, il peut en résulter des perturba-tions et, souvent, le transfert d’un nombre impor-tant de ressources vers ces patchs non prévus, audétriment des tâches initialement planifiées. Pireencore, même le déploiement réussi d’un patchpeut poser des problèmes inattendus, comme alté-rer le fonctionnement des serveurs et de ce faitempêcher la fourniture de services critiques.


12

Les organisations performantes sont plus enclinesà traiter les nouveaux patchs comme des change-ments prévisibles et planifiés, soumis au processusnormal de gestion des changements. Le patch estajouté à la liste, il est évalué, testé et intégré auxdéploiements déjà programmés. Le respect d’unprocessus bien défini pour l’intégration des chan-gements aboutit à un taux de réussite du change-ment très supérieur. Il est intéressant de noter quenombre d’organisations performantes appliquentdes patchs bien moins fréquemment que lesautres, parfois jusqu’à dix voire cent fois moinssouvent. Elles considèrent que le risque associé àdes vulnérabilités est plus faible que le risque lié àla disponibilité, qui découle des répercussions nonanticipées d’un mauvais changement ou d’unchangement intervenant en dehors du cycle. Al’inverse, les organisations performantes qui choi-sissent de déployer un patch constituant un chan-gement prioritaire sont à même de le faire demanière prévisible et reproductible en recourant àun processus efficace de gestion des changements.

Tout au long de ce GTAG, les patchs seront traitéscomme un type de changement qui relève du pro-cessus normal de gestion des changements. Il endécoule deux grandes implications : la gestion despatchs est une fonction subordonnée à la gestiondes changements, et souvent, un processus effi-cace de gestion des changements peut permettrede s’assurer que les technologies utilisées pouréviter le « patch and pray » (le fait d’appliquer rapi-dement les correctifs proposés par les différentséditeurs, en espérant qu’ils ne créeront pas d’inci-dent de production ni d’altérations de fonctions)ne feront pas naître de nouveaux problèmes.

2.2 Nous disposons déjà d’unprocessus de gestion deschangements ; en quoi celui-ciest-il différent ?

Pour que le management soit efficace, il faut avanttout que l’organisation ait mis en place un ensem-ble complet et bien défini de contrôles préventifs,

détectifs et correctifs, et qu’elle ait clairementdéfini la séparation des fonctions. Les contrôles degestion des changements permettent au manage-ment de répondre à de nouveaux besoins (projetsde développement, réglementation…) sans avoirà augmenter les moyens. De manière générale,une gestion efficace des changements atténue lesrisques, réduit les coûts et procure des ressourcespour des services additionnels.

À l’inverse, une gestion inefficace des change-ments constitue un risque considérable. Dans laplupart des organisations, la question n’est pas desavoir s’il existe un processus de gestion des chan-gements mais bien si celui-ci est aussi efficace etefficient que possible, et s’il est utilisé pour l’en-semble des changements apportés aux SI. Lors dudéploiement des changements urgents, il estextrêmement difficile de prévenir les erreurs, lesirrégularités ainsi que les interruptions non pro-grammées. Les ruptures dans la disponibilité desSI (source d’une médiocre qualité de service etd’une insatisfaction de la clientèle) poussent sou-vent les organisations à prendre en considérationles contrôles et les processus de gestion des chan-gements et à les mettre en œuvre. D’après lesrecherches, les départements informatiques per-formants sont constamment en quête de moyensdans le but d’améliorer leurs processus opération-nels, et notamment la gestion des changements.Par l’amélioration des contrôles et de la prévisibi-lité des changements appliqués aux systèmes etaux réseaux, votre département informatique peutespérer se classer parmi les meilleurs de sa caté-gorie. Les auditeurs internes sont très bien placéspour aider le management à améliorer ces proces-sus et ces contrôles.

Si la direction des SI n’est pas en mesure de décriretous les changements et leur niveau d’avancement,il ne peut pas non plus décrire ce qui est actuelle-ment géré ni assurer que les changements se dérou-lent comme prévu.

S’il est facile d’en parler, la gestion des change-ments est l’une des disciplines les plus difficiles à


13

mettre en œuvre. Elle nécessite une collaborationentre une équipe pluridisciplinaire, composée dedéveloppeurs d’applications, du personnel d’ex-ploitation informatique, des auditeurs et desmembres du personnel chargés des services debout en bout. Il importe de souligner que chaquegroupe a un rôle spécifique à jouer et que ces rôlesdoivent être définis dans les procédures de gestiondes changements.

Les auditeurs internes savent parfaitement établirun diagramme de circulation pour les processus del’entreprise et évaluer les contrôles. Ils sont lesmieux placés pour aider leurs organisations à per-cevoir les avantages qui découleraient d’uneappréhension globale des processus clés.

La direction des SI doit être en mesure, à toutmoment, de procéder à des évaluations de tous leschangements et d’indiquer leur état d’avance-ment. La direction des SI devrait publier un calen-drier des changements, qui recense aussi bien tousles changements approuvés que les dates de miseen œuvre planifiées. Des processus efficaces degestion des changements procurent l’informationet l’assurance nécessaires pour suivre tous leschangements pendant les diverses phases de leurréalisation.

Enfin, l’amélioration de la gestion des change-ments apportés aux SI dans une organisation apour objectifs de réduire le risque (qui découleessentiellement d’une incapacité à mener à bienles missions en raison de pannes), diminuer levolume des tâches non planifiées (ce qui libère desressources déjà limitées) et améliorer la qualité duservice pour tous les clients internes et externes.

2.3 Les avantages d’une procédurerobuste de gestion deschangements

Les demandes de changements découlent du sou-hait d’obtenir des avantages pour l’entreprise, parexemple une réduction des coûts ou une amélio-

ration des services, ou de la nécessité de résoudredes problèmes. Le processus de gestion des chan-gements vise à étayer et à améliorer le fonction-nement de l’organisation. Il s’agit de faire en sorteque soient utilisées des méthodes et procéduresstandardisées, qui permettront un traitement effi-cace et efficient de tous les changements et quiminimiseront l’effet des incidents liés aux change-ments sur la qualité et la disponibilité des services.

Si l’on veut protéger l’environnement de produc-tion, les changements doivent être gérés d’unemanière reproductible, définie et prévisible. Il fautveiller à ce que les changements appliqués pourcorriger une application, un serveur ou un dispo-sitif réseau n’induisent pas de problème non prévudans d’autres dispositifs ou applications. Ce pointest particulièrement important pour les actifsinformatiques (logiciels, matériel, données) quisoutiennent les processus métiers critiques del’entreprise ou les gisements de données.

De solides processus de gestion des changementspeuvent également aider l’organisation à resterconforme aux obligations réglementaires, sanscesse plus nombreuses. La gestion des risques etles étapes d’approbation, par les départementsconcernés, du processus de changement doiventinclure les activités qui traitent les répercussionspotentielles des changements sur la conformité àla réglementation. Ainsi, aux États-Unis, lorsquel’on applique des changements à une technologiequi intervient dans le processus de communicationfinancière, il faut faire attention à continuer debien respecter la loi Sarbanes-Oxley. De même, enEurope, des changements apportés au traitementd’informations susceptibles de conduire à l’iden-tification de personnes risquent d’enfreindre lesdirectives européennes sur la protection des don-nées à caractère personnel.

Des processus efficaces de gestion des change-ments doivent être formalisés, ce qui limite lesefforts nécessaires pour repérer, valider et certifierles changements apportés au processus de com-munication financière afin d’assurer la conformité.La section 404 de la loi Sarbanes-Oxley impose au


14

management de donner son aval et d’évaluer lescontrôles portant sur le processus de communica-tion financière, en particulier sur les contrôles desSI. Des changements non contrôlés dans l’envi-ronnement de production risquent d’induire deserreurs qui, si elles se propagent ou sont critiques,pourraient être considérées comme des insuffi-sances significatives qu’il convient de signaler aucomité d’audit de l’organisation. Aux États-Unis,les dysfonctionnements graves, ce que les expertscomptables appellent des « déficiences impor-tantes » doivent être portés par l’entreprise à laconnaissance du grand public, par référencementauprès de la Securities and Exchange Commission(SEC). La divulgation de déficiences peut avoir unimpact sur la réputation de l’organisation, soncours de Bourse et sa capacité à continuer d’opé-rer.

Normalement, les déficiences relevées dans lecadre de contrôles informatiques généraux,comme la gestion des changements, doivent êtreévalués en termes d’effets sur les contrôles appli-catifs. Plus précisément, une déficience dans lescontrôles généraux des SI est considérée commeune « déficience importante » ou une « faiblessesignificative » si elle remplit au moins l’une desconditions suivantes1 : • Une lacune dans un contrôle applicatif, causéepar, ou en relation avec, une déficience dansles contrôles généraux des SI est considéréecomme une déficience importante.

• La propagation et l’importance d’une défi-cience dans les contrôles généraux des SI amè-nent à conclure qu’il existe une déficienceimportante dans l’environnement de contrôlede l’organisation.

• Une déficience dans les contrôles généraux desSI considérée comme importante n’est pascorrigée après un délai raisonnable.

Dans les années précédentes, de nombreusesorganisations ont fait état de graves déficiencesliées à la gestion des changements dans lescontrôles généraux des SI qui portent sur unepartie de leur environnement de communicationfinancière. S’il s’avérait que cette déficience n’était

pas corrigée sous un an, ces organisations étaienten danger. Les auditeurs internes peuvent aider lemanagement en identifiant ces problèmes et enveillant à ce qu’ils soient résolus en temps utile.

Un modèle communément accepté pour l’évalua-tion du contrôle interne est La Nouvelle Pratique duContrôle Interne (Internal Control - Integrated Frame-work), un référentiel édité par le Committee ofSponsoring Organizations of The Treadway Com-mission (COSO) en 1992. En 2004, ce modèle a étéamélioré afin de proposer un cadre de référencelargement accepté pour la gestion des risques del’entreprise. Ce modèle présente des principesclés, des concepts, une terminologie communerelative aux risques et des recommandationsclaires pour la mise en œuvre. Cette nouvellepublication, intitulée Le Management des risques del’entreprise : Cadre de référence, Techniques d’applica-tion [COSO, 2004], décrit quatre catégories d’ob-jectifs pour l’organisation et huit composantesinterdépendantes d’une gestion du risque efficace.

Les organisations performantes accueillent géné-ralement bien les contrôles. En effet, un processusefficace de gestion des changements réduit lerisque de mauvaises performances, ainsi que lenombre de problèmes soulevés par un expert-comptable extérieur, un organisme de réglemen-tation ou une autorité de contrôle. Enconséquence, le conseil d’administration de l’en-treprise est davantage satisfait et l’on observeparallèlement un allègement de la pression pesantsur le management de la direction des SI. Enfin,les organisations qui considèrent la gestion deschangements comme un catalyseur pour laconduite efficace des affaires enregistrent de meil-leurs résultats. Le point essentiel à garder enmémoire est que la gestion des changements estcentrée sur les processus avec un axe managérialet humain, et s’appuie sur des contrôles tech-niques et automatisés.

1 A Framework for Evaluating Control Exceptions and Deficiencies, ver-sion 3 / BDO Seidman LLP, et al.- 2003.[développé par les organisations suivantes : BDO Seidman LLP,Crowe Chizek and Company LLC, Deloitte & Touch LLP, Ernst &Young LLP, Grant Thornton LLP, Harbinger PLC, KPMG LLP,McGladrey & Pullen LLP, PricewaterhouseCoopers LLP]

GTAG – Définir la gestiondes changements informatiques

15

3. Définir la gestion deschangementsinformatiques

Dans la plupart des entreprises, le départementinformatique a essentiellement deux rôles : 1) fairefonctionner et maintenir les services existants etles engagements, et 2) fournir de nouveaux pro-duits et/ou services pour aider l’entreprise à attein-dre ses objectifs. Cette section décrit le champ dela gestion des changements venant étayer ces deuxrôles, les caractéristiques respectives d’une gestiondes changements efficace et inefficace, la fonctionde l’audit dans la gestion des changements et lesindicateurs qui peuvent contribuer à la gestionefficace des changements.

3.1 Quelle est la portée de la gestiondes changements ?

Ce guide est axé sur la gestion des changementsopérationnels dans les SI. Cette gestion com-mence dès lors que l’on a établi l’applicabilité desmontées de version ou des mises à jour d’actifsinformatiques (infrastructures, applications) auniveau de la production (via, par exemple, uneéquipe de développement d’applications ou uneéquipe de recherche et développement - R&D) ets’achève quand ces actifs sont retirés de l’environ-nement de production. Elle englobe donc la main-tenance des applications et les contrôles deschangements en urgence. Les changements quiinterviennent au moment de la conception et dudéveloppement de logiciels en sont spécifique-ment exclus.

Dans ce guide, le terme « gestion des change-ments » n’inclut pas le processus de gestion desconfigurations. ITIL (Information TechnologyInfrastructure Library) définit la gestion de confi-guration comme consistant à « identifier, vérifiertoutes les versions des composantes informatiques(matériels, logiciels, documentation associée) et àen assurer la maintenance ». Cependant, le pro-cessus de gestion des changements doit interagir

avec celui de la gestion des configurations (et lescontrôles qui s’y rapportent) lorsque des change-ments sont apportés aux configurations.

Sources de changements À peu près chaque décision dans l’entrepriseappelle un changement dans les SI. Voici plusieursfacteurs qui constituent des sources de change-ments devant être traités et gérés efficacementdans l’environnement informatique : • L’environnement externe (marché concurren-tiel, parties prenantes / actionnaires, évolutiondes risques).

• L’environnement réglementaire. • Les buts, objectifs, stratégies, besoins, proces-sus et changements de priorités de l’entreprise.

• Les fournisseurs (nouveaux produits, nouvellesversions, patchs et vulnérabilités).

• Les partenaires et prestataires. • Les résultats d’un audit, d’une évaluation desrisques et d’autres types d’évaluations.

• Les problèmes opérationnels. • Les variations dans les performances ou lescapacités nécessaires.

Portée des changements Un processus efficace de gestion des changementsconcerne la totalité des modifications apportées àn’importe quel actif informatique dont dépendentdes services de l’entreprise. Parmi les actifs devantfaire l’objet d’une gestion des changements,citons :• Matériel : grands systèmes, serveurs, postes detravail, routeurs, commutateurs et appareilsmobiles.

• Logiciel : systèmes d’exploitation et applica-tions.

• Informations, données, structure des données :fichiers et bases de données.

• Contrôles de sécurité : logiciels anti-virus,pare-feux et systèmes détectifs des intrusions(IDS), ou systèmes anti-intrusion, ou systèmespréventifs des intrusions (IPS).

• Processus, politiques et procédures. • Rôles / responsabilités : autorisation, pouvoird’action et contrôles d’accès.


16

Processus de gestion des changementsLe processus de gestion des changementsimplique généralement : • D’identifier la nécessité d’un changement. • De préparer le changement : - Détailler par écrit la demande de change-ment.

- Présenter par écrit le plan permettant detester le changement.

- Prévoir, par écrit, un plan de restauration,pour le cas où les changements ne réussi-raient pas.

- Rédiger une procédure, étape par étape, quiincorpore le changement, le plan de test etle plan de restauration.

- Soumettre la procédure de changementsous la forme d’une demande de change-ment.

• D’élaborer une justification et d'obtenir lesautorisations nécessaires : - Évaluer l’impact, le coût et les avantagesassociés au changement demandé.

- Examiner et évaluer les risques et les réper-cussions associés au changement requis, ycompris les implications du point de vue dela réglementation.

• De donner son aval à la demande de change-ment. - Autoriser, rejeter ou solliciter des informa-tions supplémentaires sur la demande dechangement.

- Hiérarchiser la demande de changementpar rapport aux autres requêtes en cours.

• De programmer, coordonner et mettre enœuvre le changement. - Planifier l’intervention de la personne char-gée de déployer le changement et lui assi-gner la mission.

- Planifier l’intervention de la personne char-gée de tester le changement et lui assignerla mission.

- Tester le changement dans un environne-ment de pré-production.

- Informer du changement toutes les partiesprenantes susceptibles d’être concernées.

- Avaliser le changement en vue de sa miseen œuvre.

- Mettre en œuvre le changement commerequis.

• De vérifier et d’examiner le changement misen œuvre (étape critique, le plus souvent négli-gée). - Le changement a-t-il réussi ? - La procédure de changement a-t-elle étérespectée ?

- Quel écart observe-t-on entre le change-ment prévu et celui effectivement mis enœuvre ?

- Les contrôles internes, les opérations et lesimpératifs de conformité à la réglementationont-ils été préservés ?

- Quels enseignements peut-on en tirer pouraméliorer le processus ?

• De revenir à l’état initial si le changement neréussit pas.

• De clôturer la demande de changement et decommuniquer avec les parties concernées.

• D’apporter les changements dont il a étéconvenu à la procédure de gestion des chan-gements.

• De publier le plan du changement.

Les auditeurs reconnaîtront immédiatementqu’une gestion efficace des changements appelleà la fois des contrôles préventifs, détectifs et cor-rectifs, et que l’indépendance des contrôles esttoujours plus cruciale à mesure que l’environne-ment informatique de production devient plusdynamique et complexe. Au nombre des contrôlespréventifs nécessaires figurent la séparation desfonctions, l’autorisation des changements, ainsique la supervision et la vérification. Cependant,pour surveiller et veiller efficacement à la mise enœuvre du processus, il faut que des contrôlesdétectifs soient en place pour permettre le suivides changements dans l’environnement de pro-duction, faire le rapprochement avec les change-ments approuvés et détecter tout écart nonautorisé. Une gestion efficace des changements aégalement un rôle correctif vis-à-vis de la gestiondes SI au cours des pannes et des perturbations deservice, car elle permet d’exclure en priorité leschangements lors de la phase de dépannage,réduisant ainsi le temps de réparation.


17

3.2 À quoi reconnaît-on une gestioninefficace des changements ?

Comment savoir si le processus de gestion deschangements en place dans une organisation estefficace ou non ? Quels comportements ou autressignes constituent des indicateurs utiles de lacapacité de l’organisation, ou de son incapacité ?

Une gestion des changements inefficace ou inexis-tante est révélée par un dysfonctionnement à dif-férents niveaux de l’organisation.

Au niveau du marché : • Les opportunités manquées. L’entreprise neparvient pas systématiquement à déployer lesnouveaux produits et services programmés, enparticulier lorsqu’elle doit, à la suite de chan-gements non gérés, engager des ressourcespour des tâches non planifiées. Celles-ci peu-vent se traduire par du temps perdu / non bud-gété, des ressources perdues / non budgétées(personnel, capitaux) et des travaux non bud-gétés.

• Les projets de développement accusent duretard et dépassent souvent le budget prévu,se traduisant par des produits et services pluscoûteux que ceux des concurrents.

Au niveau des clients / consommateurs / partiesprenantes : • Les produits et services n’affichent pas les per-formances annoncées ou attendues, ou sontdéfectueux. Il s’ensuit une qualité de produitou de service faible, non fiable. Si les clientsont la possibilité de changer facilement defournisseur, ils le feront.

Au niveau de l’organisation : • Des changements non autorisés, non suivisinduisent des risques de fraude.

• Les changements informatiques découlant desbesoins de l’entreprise peuvent être mal inter-prétés et donc se révéler insuffisants ou êtreappliqués de manière inadéquate.

• Il existe peu de capacité, voire aucune, pourprévoir les répercussions d’un changement sur

les processus qui sont en place. • Étant donné la faible probabilité que les chan-gements soient évalués les uns par rapport auxautres, on observe un manque de hiérarchisa-tion, ce qui conduit soit à ne pas travailler surce qu’il faudrait, soit à travailler sur quelquechose de moins important. Les tâches peuventêtre effectuées en dehors de la séquenceprévue, d’où, éventuellement, la nécessité derevenir sur un travail ou des efforts redon-dants.

• De nombreux changements correctifs sonteffectués sans autorisation, échouent ou sontréalisés en urgence.

• Les systèmes de patchs induisent d’impor-tantes interruptions découlant d’échecs dansles changements, et qui se traduisent par despannes, des dégradations du service, destâches non planifiées, ou qui nécessitent derevenir sur un travail. Les relations de travailmédiocres ou conflictuelles entre la sécurité etl’exploitation informatiques sont alors exacer-bées.

• Un grand nombre de cycles (temps, ressources,capital) sont consacrés à corriger des activitésou des infrastructures en projet non autorisées,ce qui empêche de mener à bien les activitésqui ont reçu un feu vert.

• Des ressources sont régulièrement consacréesà des retraitements faisant suite aux consé-quences non prévues des changements malgérés.

• On observe une forte rotation du personneltechnique, ainsi que des signes d’épuisementparmi les intervenants clés.

Au niveau de l’infrastructure informatique : • Un comportement au cas par cas, chaotique etdans l’urgence qui appelle des interventionsrégulières d’experts techniques; une propor-tion considérable de temps est consacrée auxsituations d’urgence.

• Il y a une incapacité à suivre les changements,à rendre compte de l’avancement des change-ments et des coûts, et la présence de change-ments non autorisés.

• Une augmentation des ressources consacrées


18

à traiter les tâches non planifiées, aux dépensdes tâches planifiées. C’est ce que l’on peutdécrire comme un faible taux de réussite duchangement. Ce taux mesure la quantité detravaux nouveaux qui découlent de la mise enœuvre d’un changement. Un taux élevé signi-fie que les changements sont appliquéscomme prévu et qu’ils n’ont généré aucunetâche supplémentaire. À l’inverse, un tauxfaible indique qu’un changement a, contretoute attente, généré des tâches supplémen-taires non planifiées, qui viennent quelquefoiss’ajouter aux travaux nécessaires à la mise enœuvre du changement initial. Un faible taux deréussite peut être à l’origine d’un cercle vicieuxqui consomme beaucoup trop de ressources.

• Les interfaces informatiques avec les pairs(R&D, développeurs d’applications, audit,sécurité, exploitation) sont inefficaces, d’où desbarrières et des délais injustifiés.

• De nombreux changements non documentésinterviennent au fil du temps, entraînant unedérive de la configuration de production, d’oùun taux de réussite du changement moinsélevé et une plus grande difficulté à déployerdes patchs sans échec et un accroissement destâches non planifiées.

3.3 À quoi reconnaît-on une gestionefficace des changements ?

Comment reconnaître une gestion efficace deschangements ? Est-il possible lors d’une visitedans une organisation de déterminer si elle dis-pose d’un processus efficace de gestion des chan-gements ?

Une gestion efficace des changements apparaîtsous la forme d’une capacité mature (prévisible,reproductible, maîtrisée et mesurée) à différentsniveaux de l’organisation.

Au niveau du marché : • L’entreprise est en position pour agir lorsquese présentent de nouvelles opportunités d’af-

faires qui nécessitent des capacités informa-tiques supplémentaires ou des montées enversion. Chaque opportunité est planifiée etgérée de manière prévisible. Des ressourcesadéquates peuvent être engagées et l’on saitqu’elles seront suffisantes et qu’elles reposentsur un suivi des performances antérieures.

• Les produits et services reposant sur les SI sontcommercialisés comme prévu selon le calen-drier défini.

Au niveau des clients / consommateurs / partiesprenantes : • Les produits et services donnent des résultatsconformes à la publicité et affichent un niveaude qualité de service et de produit fiable etconstant. Les problèmes et plaintes des clientssont traités rapidement. Les clients sont géné-ralement satisfaits et fidèles à l’organisation.

• La demande de ressources destinées au centred’assistance / service de dépannage est enbaisse.

• L’évaluation des risques associés aux change-ments proposés et la hiérarchisation de miseen œuvre de ces changements sont confiées àdes parties prenantes qui ont la capacité demener à bien ces missions.

• Les participants au processus de changementcomprennent les types de changements, leurdegré de priorité, ainsi que les niveaux de for-malisation et de rigueur requis pour mettre enœuvre chaque changement.

• S’assurer de la conformité aux réglementationsdemande moins d’efforts, car la gestion duchangement fait partie des fondements de l’or-ganisation. Quasiment toutes les réglementa-tions posent des exigences vis-à-vis des SI.Lorsque les contrôles sont bien documentés,la mise en conformité avec une nouvelle loi ouréglementation ne constitue pas un nouveauprojet, mais simplement une activité de carto-graphie.

Au niveau de l’organisation : • La gestion du changement fait à l’évidencepartie de la culture, comme en témoignent unecompréhension approfondie, une bonne sen-


19

sibilisation, une adhésion visible et une capa-cité à agir.

• On effectue régulièrement des arbitrages effi-caces, mettant en regard les coûts et risquesassociés au changement et les opportunitésqui en découlent. Les changements sont pro-grammés et hiérarchisés en conséquence. L’or-ganisation est en mesure de prévoir l’impactdu changement sur l’activité.

• Les ressources (temps, efforts, argent, capital)sont utilisées pour mettre en œuvre certainschangements, avec aussi peu de gaspillagesd’efforts que possible (taux de réussite duchangement élevé) ; les ressources sont rare-ment orientées vers des tâches non planifiées.

• L’organisation peut, en toute confiance, répon-dre à des questions comme : - « Est-ce que je fais ce qu’il faut ? » (capacitéà sélectionner et à hiérarchiser) et

- « Fais-je les choses comme il faut ? » (avecune qualité et des performances accepta-bles).

• L’efficacité du processus de gestion des chan-gements est mise en évidence par une disci-pline et une adhésion / un respect rigoureuxdes règles, une autorité décisionnaire centrali-sée, ainsi qu’une collaboration et une commu-nication entre les départements.

• Les projets ayant reçu un feu vert sont mis encorrespondance avec les ordres de production.

• Les investissements axés sur la sécurité et surla conformité sont encouragés, car les configu-rations de production ne dérivent pas vers desétats non conformes ou instables. Par consé-quent, le coût de la sécurité et de la conformitéest bien moindre.

• De plus en plus de temps et de ressources sontconsacrés aux questions informatiques straté-giques, car l’organisation maîtrise les aspectstactiques (activité au jour le jour).

• Une gestion efficace des changements consti-tue un contrôle essentiel du pilotage des SI.

Au niveau de l’infrastructure informatique : • Les contrôles de la gestion des changements(intégrés dans des processus informatiquesbien définis) contribuent à la cohérence et à la

prévisibilité, nécessaires pour la réalisation desobjectifs de l’entreprise qui dépendent de cesprocessus. En d’autres termes, le personnelinformatique comprend en quoi une gestionefficace des changements permet à l’entreprised’atteindre ses objectifs.

• Une culture de la gestion des changements estperpétuée à la fois par la hiérarchie et par descontrôles préventifs, détectifs et correctifs quidissuadent d’effectuer des changements sansqu’ils aient obtenu l’aval de la hiérarchie. Lemanagement indique explicitement qu’il n’estpas envisageable que le nombre de change-ments non autorisés soit autre que zéro.

• L’organisation affiche un taux de réussite duchangement élevé, ce qui se traduit par l’ab-sence de tâches non planifiées, ou tout dumoins en quantité minime. S’il n’y a pas d’ur-gences et que le processus d’intégration deschangements est bien défini, le taux de réussitedu changement sera bien plus élevé.

• Des contrôles efficaces des changements sonten place, font l’objet de comptes rendus régu-liers et sont faciles à auditer. Les contrôles pré-ventifs sont correctement formalisés etdéployés systématiquement, et les contrôlesdétectifs servent à superviser, piloter et opérerdes rapprochements avec les ordres de mis-sion. Les contrôles sont propices à un sondagede corroboration par les auditeurs et requièrentpeu, voire pas d’informations supplémentairesde la part du responsable des SI.

• Les écarts dans les configurations de produc-tion sont détectés rapidement, si bien que leurscoûts et leurs répercussions sont les plus fai-bles possible.

• L’entreprise fait régulièrement la preuve de sonexcellence en matière de gestion des change-ments.

• Des niveaux de service plus élevés (forte dis-ponibilité / disponibilité / temps moyen entreles pannes, faible délai moyen pour détecter lesproblèmes / incidents, faible délai moyen deréparation) sont observés en présence de pro-cessus bien définis qui introduisent des chan-gements programmés et prévisibles.

• Les SI permettent de revenir rapidement à un


20

état opérationnel connu, fiable et dont on saitqu’il fonctionne, lorsque des problèmes appa-raissent après la réalisation d’un nouveauchangement ou la mise en place d’une nou-velle configuration.

• Les SI affichent des structures de coûts corres-pondant à une efficience inhabituelle (ratiod’administration serveurs / systèmes de 100:1ou plus, alors qu’il est au moins 10 fois moin-dre dans les organisations peu performantes).

• Les SI sont capables d’identifier et de résoudrerapidement des problèmes opérationnels, ycompris des incidents de sécurité.

• Les organisations disposant de processus etcontrôles efficaces de gestion des change-ments traitent les patchs de manière planifiéeet prévisible, en leur appliquant la même pro-cédure et la même analyse qu’à tous les autreschangements. Des patchs critiques sont ajou-tés à la liste des changements envisagés, et ilssont évalués, testés et insérés dans le pro-gramme de déploiement déjà établi.

• Les contrôles préventifs et détectifs sont auto-matisés, ce qui permet une communicationplus simple et plus précise aux auditeurs,nécessite moins d’inspections manuelles etfont ressembler les sondages de corroborationà de l’archéologie.

• Les organisations les plus efficaces appliquentdes patchs moins fréquemment que lamoyenne, peut-être dix fois moins souvent,acceptant que le risque d’exposition à une vul-nérabilité soit moins important que le risquede non-disponibilité lié aux répercussions nonanticipées d’un mauvais changement ou d’unchangement hors cycle. Cependant, dans le casd’une mise à jour critique, les organisationsperformantes sont à même d’appliquer unpatch hors cycle avec un risque minime.

Pour qu’un processus soit efficace, il ne suffit pasque les parties prenantes soient simplement asso-ciées à l’évaluation des risques induits par deschangements proposés et par leur hiérarchisation.Le manque d’intérêt, d’implication et d’adhésiondes collaborateurs est l’un des obstacles auxquelsse heurtent les départements informatiques

lorsqu’ils tentent de mettre en œuvre un solideprocessus de gestion des changements. Il faut faireen sorte que les responsables de département par-ticipent activement à l’ensemble du processus,depuis l’identification initiale de leurs besoinsjusqu’à la vérification de l’acceptation par unemajorité d’utilisateurs et à l’agrément des change-ments à apporter au niveau de la production. Cespoints critiques sont davantage susceptibles deposer problème lorsque le rôle du responsable estintégré dans les politiques et procédures corres-pondantes et que les membres de la direction met-tent l’accent qu’il faut sur la nécessité d’être« copropriétaires » du processus, plutôt que desimples observateurs. La communication et la col-laboration entre l’informatique et les autres fonc-tions sont essentielles à l’efficacité des processus.

3.4 Indicateurs de la gestion deschangements

Les auditeurs internes doivent déterminer si, pourévaluer l’efficacité du processus et en augmenterla valeur pour l’entreprise, on utilise bien les prin-cipaux indicateurs de la gestion des changements.Les indicateurs, énumérés dans le tableau 1, sontutiles pour indiquer la présence d’un processusefficace de gestion des changements.


21

Tableau 1 : Les indicateurs de la gestion des changements

Indicateurs Observations

Nombre de changements autorisés par semaine,mesuré dans le journal de gestion des changementsautorisés.

En général, des changements plus nombreux sont lesigne d’une productivité plus grande, tant que le tauxde réussite du changement reste élevé. La tendance(amélioration, recul, situation inchangée) doit êtreappréhendée dans le contrat de l’activité.

Nombre de changements effectifs par semaine, mesurépar les contrôles détectifs, par exemple grâce à un logi-ciel de pilotage.

Le nombre de changements effectivement mis enœuvre par semaine ne doit pas dépasser le nombre dechangements autorisés.

Nombre de changements non autorisés. Il s’agit de changements qui contournent les processusde changements. On les mesure par soustraction dunombre de changements autorisés au nombre dechangements effectifs. En l’absence de contrôles détectifs, il est impossible demesurer avec fiabilité les changements effectifs. Dansce cas, on peut prendre, comme indicateur de substitu-tion, le nombre d’interruptions non planifiées.

Plus ce nombre est faible, mieux c’est, mais classique-ment, le seul nombre acceptable de changements nonautorisés est zéro ; un seul changement « périlleux »peut anéantir toute l’opération ou induire un risqueélevé. Un nombre élevé de changements non autorisés est lesigne que le « véritable moyen choisi pour procéder àdes changements » consiste à contourner le processusde gestion des changements.

Taux de réussite du changement, c’est-à-dire la propor-tion de changements mis en œuvre avec succès(n’ayant pas entraîné de panne, de dégradation du ser-vice ni de tâches non planifiées) par rapport aux chan-gements effectivement réalisés.

Plus ce taux est élevé, mieux c’est. Lorsque les changements ne sont pas gérés ou pastestés correctement, le taux de réussite tourne généra-lement autour de 70 %. Dans les organisations performantes, non seulement letaux de réussite ressort régulièrement à 99 %, mais leschangements ratés entraînent rarement une interrup-tion de service ou des tâches non planifiées.

Nombre de changements urgents (patchs compris),que l’on détermine en dénombrant les changementsayant nécessité un agrément en urgence durant lasemaine, en faisant appel au comité d’examen deschangements ou au processus de changement urgents.

Généralement, plus ce nombre est faible, mieux c’est.Un nombre élevé de changements urgents est le signeque le « véritable moyen choisi pour procéder à deschangements » consiste à recourir à la procédure d’ur-gence, parce que c’est plus commode ou plus rapide. Les changements urgents affichent généralement untaux de défaillance plus élevé, et génèrent des tâchesnon planifiées ou nécessitent de revenir sur un travail.Si le nombre de changements urgents augmente, d’au-tres problèmes de gestion des changements peuventen être à l’origine.

Proportion de patchs déployés dans le cadre de la dif-fusion programmée d’une nouvelle version logicielle.Lorsque les patchs sont déployés dans ce cadre, ils n’in-duisent pas de perturbation de la production et pré-sente un taux de réussite bien supérieur.

En général, plus cette proportion est élevée, mieuxc’est. Paradoxalement, les organisations SI performantes affi-chent généralement le taux de patching le plus faible.Certaines de ces organisations performantes choisis-sent d’installer des patchs une fois par an, même si ellesprocédaient à des milliers de changements parsemaine. Elles réussissent souvent à atténuer lesrisques de vulnérabilité sans avoir besoin de procéder àdes changements dans les systèmes de production (parexemple en bloquant les vulnérabilités au niveau dupare-feu).


22

Indicateurs Observations

Proportion du temps consacré à des tâches non plani-fiées. Les tâches planifiées correspondent à des projetset travaux autorisés. Les tâches non planifiées incluentles cycles de réparation, de reprise et les changementsurgents.

Plus cette proportion est faible, mieux c’est (par exem-ple 5%, ou moins).

Proportion des projets livrés en retard par rapport àl’échéance prévue même si une mauvaise gestion deprojet peut également impacter la mesure.

Typiquement, plus cette proportion est faible, mieuxc’est. Quand les organisations passent du temps sur destâches non planifiées, le temps passé pour des tâchesplanifiées n’est plus suffisant, comme pour les nou-veaux projets et services, ce qui engendre des retardsde livraison du projet.

Organisationperformante

>1000changementspar semaine

< 1% Quelques minutes < 5% du temps

Moyenne Centaines ~ 30-50% enmoyenne Heures et jours 35-45% du temps

Figure 1 : Les tâches non planifiées, indicateurs d’un processus de gestion efficace des changements

Nombre dechangements dans

la productionX

Pourcentage dechangements défaillants

ou non autorisésX

Pourcentage de tempsconsacré à des tâches

non planifiées

Duréemoyenne de

reprise=

MOYENNE : 35 à 45 % du temps (et des dépenses d’exploitation) consacré à des tâches non planifiées ! IMPACT : Projets en retard, nécessité de revenir sur un travail, problèmes de conformité, écarts non maîtri-sés, etc.


23

La figure 1 et la figure 2 présentent les indicateursd’une gestion efficace des changements et desprincipaux contrôles qui les améliorent ou les fontbaisser. Ces indicateurs1 sont : • Le nombre de changements appliqués auniveau de la production.

• La proportion de ces changements ayantéchoué ou qui ne sont pas autorisés.

• Le délai nécessaire à la restauration après unchangement qui a échoué.

Lorsque l’on multiplie ces trois variables, onobtient les tâches non planifiées.

Ce modèle, simplifié à l’extrême, ne prétend pasêtre mathématiquement exact. Il entend simple-ment montrer les variables dominantes et les prin-

cipaux indicateurs d’une gestion efficace des chan-gements informatiques, et donc de SI efficaces : • C’est lorsqu’une organisation informatiquen’applique aucun changement ou se situe dansune période de gel des changements que ladisponibilité est la plus grande et que lestâches non planifiées sont les moins nom-breuses.

• Lorsqu’une organisation SI ne met pas enœuvre une politique de gestion des change-ments (contrôles préventifs et détectifs inadé-quats), des changements non autorisés etdéfaillants causent de longues interruptions,qui alourdissent le volume des tâches non pla-nifiées.

• Lorsque les organisations informatiques affi-chent un ratio tâches non planifiées / tâchesplanifiées élevé, elles ont moins de temps dis-ponible pour réaliser les travaux qu’ellesétaient chargées d’effectuer, par exemple four-nir de nouveaux produits et services.

Figure 2 : Variables clés influençant les processus de gestion des changements

Nombre dechangements dans

la productionX

Pourcentage dechangements défaillants

ou non autorisésX

Pourcentage de tempsconsacré à des tâches

non planifiées

Duréemoyenne de

reprise=

COMPORTEMENTS QUI AMÉLIORENT LE TAUX DE RÉUSSITE DUCHANGEMENT :

• Test efficace du changement• Examen du risque efficace lors de l’autorisation d’un changement• Identification efficace des parties prenantes au changement• Programmation efficace des changements

COMPORTEMENTS QUI RÉDUISENT LES CHANGEMENTS NONAUTORISÉS :

• Culture de la gestion des changements• Approbation, par le management, du processus de changement• Pilotage efficace des infrastructures grâce à des contrôles détec-

tifs en vue de vérifier la bonne application des processus dechangement

• Recours, par le management, à des mesures correctives lorsqueles processus de changement ne sont pas respectés

• Séparation des tâches efficace, grâce à la limitation du nombrede personnes susceptibles de mettre en œuvre les changements

COMPORTEMENTS QUI RÉDUISENT LEMTTR :

• Culture des incidents : volonté d’ex-clure en priorité le changement lorsde la phase de résolution des pro-blèmes

• Processus de gestion des change-ments efficace, à même de faire étatdes changements autorisés et plani-fiés

• Capacité à distinguer les interrup-tions planifiées de celles qui ne lesont pas

• Communication efficace des chan-gements programmés

• Pilotage efficace de l’infrastructurepour les changements au niveau dela production

1 D’après le benchmark de l’ITPI, qui a étudié 11 organisations SI per-formantes et enquêté auprès de centaines d’autres.


24

Les organisations SI performantes peuvent faireencore mieux que ne le suggère ce modèle.Lorsque les changements sont gérés de manièreadéquate, même les changements planifiéséchoués conduisent rarement à des pannes, si bienque leur MTTR (mean time to repear) est égal à zéro.À l’autre extrémité, les organisations peu perfor-mantes sont souvent incapables de mesurer autrechose que les pannes et tâches non planifiées évi-dentes.

3.5 Intégration de la gestion despatchs dans la gestion deschangements

Bien qu’il faille souvent appliquer des patchs logi-ciels en urgence, dans l’idéal, le déploiement despatchs devrait être intégré à un processus de pré-production, dans lequel les patchs peuvent êtrecorrectement testés dans un environnement desimulation. Dans l’idéal, ils seront égalementdéployés lors de la diffusion programmée de lanouvelle version d’un logiciel.

La mise en œuvre d’un patch est souvent risquée,et ce pour plusieurs raisons. Les patchs ont ten-dance à affecter de nombreuses bibliothèques sys-tème critiques, ainsi que d’autres logiciels utiliséspar de nombreux programmes d’application. Lespatchs constituent généralement des change-ments de grande ampleur, souvent assortis d’unemaigre documentation qui décrit ce qu’ils sontcensés changer. Ils représentent des opérationsvastes et complexes. Même de petits écarts deconfiguration peuvent induire des résultats nette-ment différents. En conséquence, le taux de réus-site du changement concernant les patchs est bieninférieur à celui des changements classiques, sibien qu’ils nécessitent des tests plus complets. Enl’absence de tests et de planification suffisantsapparaît invariablement une attitude qui consisteà appliquer le patch et à prier pour que tout fonc-tionne bien (« patch and pray »).

Il est souvent fait référence à cette attitude : ni

l’application d’un patch, ni le fait de l’éviter nesemble aboutir à l’objectif visé, à savoir créer uneplateforme de calcul sécurisée et disponible.Comme indiqué plus haut, les organisations SIperformantes appliquent des patchs bien moinsfréquemment que les autres, et néanmoins, ellesparviennent au niveau de sécurité désiré. Il est fauxde supposer qu’en agissant ainsi, elles menacentla sécurité. Au contraire, elles gèrent activement lerisque résiduel et, au lieu d’appliquer des patchs,elles déploient des contrôles. Elles créent aussi unprogramme de déploiement de nouvelles versionsqui regroupe les patchs et les montées de versiondans le déploiement de nouvelles versions, au lieud’appliquer les patchs un par un dans chacun dessystèmes.

Les risques associés aux changements ne se limi-tent pas à l’application de patchs et peuvent sur-venir avec n’importe quelle technologieautomatisée de déploiement d’un changement.

Le recours simultané aux technologies de gestiondes patchs et de déploiement des changementsrend l’environnement informatique de productionplus dynamique et plus complexe : le nombre devecteurs de changements augmente, de même quele nombre de changements susceptibles d’êtreréalisés. Ces environnements requièrent :• des contrôles préventifs supplémentairesvisant à réduire la probabilité de changementsnon autorisés et

• des contrôles détectifs indépendants visant àsimplifier les fonctions de pilotage, de rappro-chement et de reporting.

3.6 Principes directeurs : commentdécider s’il faut appliquer deschangements, quand et commentprocéder ?

Les principes qui guident de bonnes décisions degestion des changements supposent de se poserles questions suivantes : • Ces changements sont-ils véritablement


25

nécessaires ? C’est durant les périodes de geldes changements que les organisations SIenregistrent le plus faible volume de tâchesnon planifiées et d’interventions en urgence.C’est pourquoi tout changement doit justifier,d’une part, les efforts de préparation et de miseen œuvre et, d’autre part, les conséquences(souvent imprévues) qui peuvent s’ensuivre.

• A-t-on défini des périodes de gel des change-ments, durant lesquelles aucun changementn’est autorisé ? Ces périodes étant non seule-ment les plus stables, mais aussi les plus pro-ductives, il faut impérativement en prévoir etles appliquer.

• Si des changements doivent être effectués,comment s’assurer qu’ils seront couronnés desuccès ? Des changements non testés affichentrarement un taux de réussite supérieur à 70%.Les organisations qui veulent que leurs chan-gements soient réussis doivent investir dutemps et des ressources pour tester correcte-ment ces changements.

• Lorsque des changements doivent être mis enœuvre, sont-ils programmés par lots ? Lavariance est source de risque, et on peut laréduire en regroupant plusieurs changements,de sorte qu’ils pourront être testés et appliquéssimultanément. Il s’ensuit des périodes pluslongues sans changements opérationnels, ainsique des périodes de mise en œuvre des chan-gements plus courtes et plus productives.

• Les variances sont-elles communiquées régu-lièrement au responsable des SI ? Les change-ments dans la production sont-ils comparésaux travaux autorisés ? Les interruptions nonplanifiées et variances associées aux change-ments sont-elles documentées et cherche-t-onà y remédier ? Le management et les auditeurspeuvent-ils facilement accéder à des rapportsmontrant les effets des contrôles préventifs etdétectifs ? Lorsque les contrôles continus et dereporting fonctionnent correctement, le mana-gement informatique a les informations néces-saires pour identifier de façon efficace etefficiente les problèmes et est davantage sus-ceptible de réaliser ses objectifs.

GTAG – Quelles questions dois-je poser à proposde la gestion des changements et des patchs ?

26

4. Quelles questions dois-jeposer à propos de lagestion deschangements et despatchs ?

Ce chapitre propose aux auditeurs un ensemble dequestions qu’ils peuvent utiliser afin de se faireune idée sur l’efficacité de la gestion des change-ments. L’objectif est de poser les bonnes questionset de savoir interpréter les réponses habituelle-ment fournies par différents responsables des SIqui peuvent ne pas accorder la même importanceà une gestion efficace du changement.

Les archétypes que l’on rencontre le plus fréquem-ment sont : • Les responsables des SI qui disposent d’unprocessus efficace de gestion des change-ments.

• Les responsables des SI qui disposent d’unprocessus inefficace de gestion des change-ments, mais qui cherchent à l’améliorer (selonune approche de résolution des problèmes).

• Les responsables des SI qui disposent d’unprocessus inefficace de gestion des change-ments, mais qui ne prévoient rien pour yremédier (déni de la réalité).

Tableau 2 : Questions à poser à propos de la gestion des changements, en fonction du profil

Question à poser auresponsable des SI

Responsable des SIdont le processus degestion des change-

ments est efficace

Responsable des SIadoptant une

approche de résolu-tion des problèmes

Responsable des SIen déni potentiel

« La gestion des change-ments est cruciale.Pensez- vous que votreprocessus de gestion deschangements soit effi-cace ? »

« Il est irréprochable. Noussommes même prêts pourune mise en conformité àla section 404 de la loi Sar-banes-Oxley parce quetous les contrôles sontdéjà en place. Il nous afallu produire quelquesrapports supplémentairespour montrer les cartogra-phies des contrôles, maistout est en ordre. »

« C’est drôle que vousposiez la question, noussommes justement entrain d’y travailler, maisc’est le cas de tous ceuxqui doivent se conformerà la section 404 de la loiSarbanes-Oxley. Nous ensaurons plus au fur et àmesure. »

« Notre processus semblefonctionner. Je n’ai rienentendu dire de négatif àson sujet, et notammentde la part de l’audit. Nousne pouvons pas nous per-mettre la surcharge d’unprocessus lourd pourréparer quelque chose quifonctionne déjà. »

« Combien de change-ments non autorisés vousparaissent acceptables ? »

« Zéro, et pas un de plus.Le moindre changementnon programmé peutréduire à néant tous lesefforts, et c’est pourquoinous opérons quotidien-nement des rapproche-ments concernant leschangements. Nous fai-sons confiance, mais nousvérifions. »

« Eh bien, si vous posez laquestion comme ça, biensûr que le seul nombreacceptable de change-ments non autorisé estzéro. Mais je parie quevous ne trouverez per-sonne qui serait prêt àjouer sa prime trimes-trielle là-dessus. Surtoutaprès le dernier trimestrequ’on a eu. »

« Écoutez, nous nesommes pas payés pourne pas appliquer de chan-gements. Il faut parfoissavoir s’écarter des règles.Ici, c’est comme ça si l’onveut que les choses soientfaites. La gestion deschangements, c’est labureaucratie à l’œuvre, ettout ce qu’ils veulent, c’estralentir les choses. »


27



ments est efficace




« Décrivez les contrôlesdont vous avez besoindans votre processus degestion deschangements. »

« Il nous faut des contrôlespréventifs, détectifs et cor-rectifs, afin que le mana-gement puisse disposerd’une vision exacte de lasituation. Nous avonsdéfini quelques indica-teurs du changement etidentifié quelques autresparties prenantes qu’ilnous faut intégrer dans lecomité de gestion deschangements. Nousn’avions pas pensé que lagestion des changementspouvait intéresser lescomptables, mais désor-mais, ils assisteront à nosréunions. »

« Nous avons toute uneéquipe d’auditeursinternes et de consultantsqui travaillent au projetSarbanes-Oxley. Ils sonten train de concevoir etde mettre sur pied un planpermettant de tester lescontrôles spécifiques. Toutce projet Sarbanes-Oxleya fait apparaître la néces-sité d’une surveillanceintégrée et d’une visiondu changement à l’échellede l’entreprise. Nousavons aussi déceléquelques processus quiont besoin d’une meil-leure gestion des change-ments, et on y travailleaussi. »

« Nous en sommes encoreà la phase d’analyse. Onest tellement pris partoutes les autres tâchesurgentes que tout ce àquoi nous avons puconsacrer un peu detemps, ce sont lescontrôles imposés par laloi Sarbanes-Oxley. Maisnous savons que c’estimportant, et nous nous ymettrons dès que nous lepourrons. De plus, actuel-lement, nous n’avonsaucun budget réservéspécialement à ce travail.Mon expérience me faitdire que ce dont nous dis-posons est probablementsuffisant, puisque per-sonne ne m’a spécifique-ment fait savoir que leprocessus actuel était ina-déquat. »

« Avons-nous observé desavantages découlant duprocessus de gestion deschangements ? »

« Absolument. De fait, lesavantages que nous avonspu observer sont telle-ment évidents que nousavons créé une cultureinterne de la gestion deschangements. Nousn’avons plus l’impressiond’avoir embrassé une car-rière de pompier. Nousavons considérablementamélioré nos perfor-mances, la disponibilité etle degré de satisfaction,aussi bien de nos clientsque du personnel eninterne, et de toute la hié-rarchie jusqu’au sommetde l’entreprise. »

« Oui, mais nous n’avonspas encore atteint nosobjectifs. Nous avonsréduit le nombre total depannes et significative-ment amélioré notre tauxde réussite du change-ment. Désormais, leschangements se dérou-lent à l’intérieur de laplage définie, même sinous avons encore, à l’oc-casion, quelques « cow-boys » qui ne prennentpas la peine de respecterla procédure. »

« En ce moment, notrerythme d’activité est sieffréné que nous n’avonstout simplement pas letemps d’examiner de plusprès un processus de ges-tion des changementslourd et qui ralentit leschoses, réduit la producti-vité et crée un environne-ment bureaucratique. Jeme refuse à réclamer descomptes à chacun concer-nant le respect du proces-sus de changements, caron leur en demande déjàbien assez. Mais despannes liées aux change-ments se produisent occa-sionnellement, et noussavons que nous ne pou-vons pas continuer à lais-ser le système de gestiondes commandes planté. »


28



ments est efficace




« Vous souvenez-vous dela panne sur tout le sitequi s’est produite lasemaine dernière à caused’un changement ? Ques’est-il passé ? »

« Nous avons pu détermi-ner que le changementqui a causé cette pannede 10 minutes avait étéautorisé. Cependant, nousn’avons pas su en antici-per les conséquences enaval sur un système sanslien direct. Mais cela ne sereproduira plus. »

« Nous avons trouvé : undéveloppeur avait pro-cédé à un changementsans suivre le processusdont nous étionsconvenu. Il n’aurait jamaisdû avoir autorité pourdonner son accord à deschangements sur ce sys-tème précis. Nous noussommes dépêchés de rec-tifier cela, et ce dévelop-peur n’a même plus ledroit de se connecter auxserveurs de production. »

« Nous avons constatéque l’un de nos fournis-seurs faisait de la mainte-nance et procédait à desmontées en version surdes logiciels. Le problème,c’est qu’ils ont écrasé unebibliothèque de pro-grammes que nous avionspersonnalisés. Or, ils sontcensés garder la trace denos adaptations : il s’agitdonc d’un non-respect denotre contrat de mainte-nance. »

« Lorsque vous avez tra-vaillé sur cette panne,quel processus avez-vousemployé pour trouver cequi n’a pas fonctionné ? »

« La première chose quenous faisons systémati-quement, c’est d’exclureen priorité les change-ments lors de la phase dedépannage. Nous savionssur-le-champ que lapanne n’était pas due à unchangement programmé.Ensuite, nous avons vérifiétous les changementsurgents au niveau de laproduction. Nous avonstrouvé quatre change-ments effectués deuxminutes avant la panne,puis nous avons trouvéqui les avait réalisés. Ilsont procédé à un retourarrière, et tout a pu repar-tir en quelques minutes. »

« Nous sentions bien quece problème ne pouvaitpas venir de nos change-ments autorisés. Nous tes-tons et déployons noschangements unique-ment à l’intérieur d’uneversion spécifique. Nousavons donc commencé àfaire des recherches, àregarder les journaux, enremontant à partir de lapanne et en examinanttout ce qui s’est passé endehors de la version. Nousavons finalement trouvéqui avait réalisé le change-ment en cause, mais paspourquoi. Je pense quel’administrateur en a tirétous les enseignementsnécessaires ce jour-là. »

« N’ayant pas de processuscentralisé, nous avonsmobilisé différenteséquipes pour qu’ellesessaient de trouver ce quine fonctionnait pas. Nousavons finalement consti-tué une équipe de choc.Elle a rapidement concluque la panne était due à lamontée de version dufournisseur, mais il nous afallu nous réunir avec cedernier pour déceler quela cause était notre biblio-thèque. Ils n’avaientaucun moyen de la restau-rer dans son état préala-ble, si bien qu’il nous afallu réinstaller l’ensembledu répertoire de logicielsd’origine. »


29



ments est efficace




« Comment surveillez-vous l’état général du pro-cessus ? »

« Par le taux de change-ments, le taux de réussitedu changement, la duréemoyenne de reprise(MTTR), la durée moyennede bon fonctionnement(MTBF), le décompte deschangements non autori-sés qui contournent leprocessus. Nous avonségalement un indicateurde la couverture quipermet de montrer quelspans de l’entreprise neparticipent pas au proces-sus. Le nombre de tâchesnon planifiées constitueun indicateur clé. Nouscherchons toujours àdétecter les écarts et àcomprendre comment lesréduire à la source. »

« Nous mesurons en com-bien de temps nous pou-vons appliquer unchangement, ainsi que ledélai moyen entre unedemande de changementet sa finalisation. Nousallons bientôt aussi mesu-rer le taux de réussite duchangement ainsi que leschangements urgents etles changements non pla-nifiés. »

« Nous n’utilisons pas d’in-dicateurs fantaisistes,même si l’excellence desprocessus est pour nousune priorité. Je sais quenous avons beaucoupd’urgences à régler, mais iln’y a pas moyen d’yéchapper quand on tra-vaille avec certaines deces personnes. »

« Quel est l’objectif devotre processus de ges-tion des changements ? »

« Fiabilité, disponibilité etréduction des coûts. Lesdeux premières doiventaugmenter et les coûtsbaisser. Si l’on se contentede n’optimiser que l’un deces trois éléments, on nesera pas dans les clous. »

« Nous voulons faireautant de changementsque l’activité le nécessite.Et nous voulons qu’ilssoient rapides et précis. »

« Nous voulons que toutesles parties prenantes clésparticipent à nos réunionssur la gestion des change-ments, et que tout lemonde ait bienconscience de ce qui sepasse et pourquoi. Pournous, tant que nos auditssont favorables, tout vabien. »


30

4.1 Faire évoluer les capacités degestion des changements

La gestion des changements est un processus évo-lutif. Les groupes ne doivent pas se découragerlorsqu’ils commencent à développer leur proces-sus de gestion des changements. Les solutionspeuvent consister à changer les gens, les processusou la technologie. Voici les attitudes classiques vis-à-vis de la gestion des changements : 1. Oublier le changement : « Est-ce que le com-mutateur vient de se réinitialiser ? »

2. Avoir conscience du changement : « Quivient de réinitialiser le commutateur ? »

3. Annoncer le changement : « Je réinitialise lecommutateur, dites-moi si ça pose un pro-blème. »

4. Autoriser le changement : « J’ai besoin deréinitialiser le commutateur. Qui peut m’endonner l’autorisation ? »

5. Programmer le changement : « Quand serala prochaine plage de maintenance ? J’aimerais

bien réinitialiser le commutateur à cemoment-là. »

6. Vérifier le changement : « En regardant lesjournaux d’erreurs, je vois que le commutateura été réinitialisé comme prévu. »

7. Gérer le changement : « Programmons la réi-nitialisation du commutateur sur la semaine45, comme ça, nous pourrons faire la montéede version et la réinitialisation en mêmetemps. »



ments est efficace




« Votre processus de patchentraîne-t-il des perturba-tions ? »

« Non, pas du tout. Noussavons bien que la dispo-nibilité est capitale pourles métiers. Il nous fauttrouver comment réduireles risques sécurité sansles dangers associés auxchangements. Enmoyenne, nous appli-quons un seul lot impor-tant de patchs par an. »

« Auparavant, la gestiondes patchs induisait beau-coup de perturbations,mais après la grossepanne que nous avonssubie il y a six mois, noussommes revenus surtoutes les certitudes quenous avions à propos despatchs à déployer et dumoment le plus adéquatpour les appliquer. Nous yconsacrons moins detemps : avant, c’étaittoutes les semaines, main-tenant, c’est tous les mois,et nous envisageons depasser à une fois par tri-mestre. »

« Étant donné la piètrequalité des logiciels quesortent les fournisseurs,nous continuons deconsacrer beaucoup tropde temps à appliquer despatchs. C’est une situationinextricable. Si nous n’ap-pliquons pas de patchs,nos systèmes seront pira-tés, mais si nous les pat-chons, nous risquons decrasher nos systèmes deproduction. Enfin, puisquenous ne pouvons pasnous permettre d’être «descendus en flammes »dans la presse, nousn’avons pas d’autre choixque d’appliquer lespatchs. »


31

5. Par quoi les auditeursinternes doivent-ilscommencer ?

D’après le cadre de référence du COSO, c’est lemanagement qui définit les objectifs stratégiques,qui choisit les stratégies et qui assure la diffusiondes objectifs dans toute l’entreprise, après les avoirharmonisés. La gestion des risques de l’entrepriseest orientée vers la réalisation de ces objectifs, surquatre axes : stratégie, exploitation, reporting etconformité à la législation. Les contrôles préven-tifs, détectifs et correctifs doivent être conçus etmis en œuvre de façon à permettre un traitementefficace du risque. L’audit peut aider le manage-ment informatique à disposer d’une procédureefficace pour gérer les risques liés à la réalisationdes objectifs. Au nombre des objectifs de gestiondes changements que le management informa-tique doit définir figurent ceux qui ont trait à larevue et à la validation des demandes de change-ments, afin que la mise en œuvre des change-ments soit appropriée et efficiente, ainsi qu’aurétablissement rapide du SI en cas d’échec deschangements.

Les contrôles préventifs, détectifs et correctifs doi-vent être définis d’après les objectifs fixés par lahiérarchie pour la gestion des changementsapportés aux SI.

Pour réussir, le management doit répondre auxpréoccupations des actionnaires, qui sont repré-sentés par le Conseil. Les objectifs de l’entreprisesont généralement exprimés en termes de chiffred’affaires / part de marché, de croissance de l’acti-vité / du cours de Bourse, ou de maîtrise du coûtdes ressources humaines et des opérations. Leplan d’action qui doit permettre d’atteindre cesobjectifs devra être formulé et déployé efficace-ment dans toute l’organisation pour avoir unechance de succès. Le Conseil doit notamments’assurer que le management a identifié et évaluéles risques qui pourraient faire obstacle à la réali-sation des objectifs. Des procédures solidesdevraient être mises en place afin de réduire, de

gérer, d’accepter et de transférer les risques effica-cement. Les variations par rapport au plan définiconstituent un autre risque, qui nécessite une ges-tion active. Les auditeurs internes sont les yeux etles oreilles du management : ils recherchent leszones de l’environnement de gestion des risquesqui doivent être renforcés.

Pour la plupart des entreprises, l’indisponibilité deservices ou de fonctions critiques, même pendantune courte période, est l’un des facteurs qui com-promet le plus rapidement les avancées dans laréalisation des objectifs clés. Ainsi, une panne inat-tendue du réseau peut interrompre des processuscritiques, tels que la coordination des livraisonsavec les fournisseurs et le traitement rapide descommandes de la clientèle. Le dysfonctionnementd’un serveur Internet, d’un serveur d’application,d’une base de données critique peut être tout aussidommageable. Avec le management, les auditeursinternes doivent s’assurer que ces risques, et lesrisques connexes, ont été identifiés, et qu’ils sontmesurés et gérés correctement. Mais comment lesrisques peuvent être gérés si leurs causes n’ont pasété détectées et analysées ?

Au nombre des responsabilités les plus impor-tantes du service informatique figurent la protec-tion de l’environnement de production et lesoutien de l’organisation dans la réalisation de sesobjectifs. Il incombe aux auditeurs internes de veil-ler à ce que des processus adéquats de gestion durisque soient en place, y compris au niveau des SI.À cette fin, il ne faut pas sous-estimer l’importanced’un dispositif efficace de gestion du risque, quidoit être régulièrement revu par les auditeursinternes.

5.1 Rôle de l’audit dans la gestiondes changements

Les auditeurs internes n’ayant généralement pasle temps d’examiner toutes les facettes des orga-nisations dans lesquelles ils travaillent, ils doiventélaborer leurs programmes d’audit en se fondantsur une évaluation des risques. Pour aider à l’éva-


32

luation du risque métier dans le cadre informa-tique, ils devront rassembler des informations pré-liminaires. Pour déterminer l’ampleur des risquesinduits par les pratiques de gestion des change-ments au sein de l’organisation et pour décider deprocéder à une revue à un haut niveau ou appro-fondie, les auditeurs devraient : • Comprendre les composantes de base de lagestion des changements. Le concept de ges-tion des changements utilisé ici n’englobe pasl’ensemble du cycle de développement dessystèmes, tel que le développement d’applica-tions ou la gestion des configurations. Néan-moins, la gestion des changements doitrefléter le cycle de développement des sys-tèmes (et les contrôles qui y sont associés) eten faire partie intégrante. La compréhensiondu contenu de ce guide procure des connais-sances suffisantes pour permettre de poser lesquestions difficiles concernant l’activité des SI,afin de déterminer le niveau des éventuellesaméliorations à apporter à la gestion des chan-gements et aux contrôles (voir le tableau 2,page 26, pour les questions utiles à poser).

• Recourir aux indicateurs de processus de ges-tion des changements efficace et inefficacepour évaluer l’efficacité relative des processusde gestion des changements au sein de votreorganisation. Analyser le processus de gestiondes changements et rechercher les élémentsclés énumérés dans ce guide. Déterminer com-ment le management informatique mesure ceprocessus et si ce dernier répond véritablementaux besoins de l’entreprise.

• Obtenir le tableau de bord du managementinformatique, afin de mesurer les résultats etl’efficacité du processus. Déterminer si desindicateurs appropriés sont utilisés pour lepilotage et l’amélioration continue (tableau 1,page 21).

• Déterminer si le management informatique aconfié la gestion des changements à des inter-venants autres que les développeurs de logi-ciels ou les personnes chargées de préparer leschangements. Le management a-t-il sécurisél’environnement de production, de sorte queles responsables de la mise en place des chan-

gements peuvent mener à bien leur mission ? • Procéder à une brève revue pour déterminers’il existe des pistes d’audit des changementsapportés à l’environnement de production etpour vérifier que les pistes d’audit ne peuventpas être manipulées ou détruites.

• Dans le cadre des audits de contrôle des chan-gements, rechercher les indicateurs d’efficacitéde la gestion des changements. Se concentrersur les risques pour l’entreprise qui résultentd’une éventuelle incapacité à atteindre lesobjectifs de contrôle.

• Aider le management à identifier des modèlesqui lui permettront de mieux gérer les change-ments.

• Lorsque l’organisation envisage d’externaliserles fonctions informatiques, vérifier que sesattentes sont clairement définies dans descontrats et accords de niveau de service.Concernant le processus de gestion des chan-gements, il importe de s’assurer de : - Qui est responsable, en interne, de la ges-tion des changements demandés au jour lejour.

- Comment l’organisation peut déterminerque des changements effectués par le pres-tataire extérieur sortent du cadre défini.

- Quels moyens l’organisation dispose pourvérifier que le prestataire extérieur ne lui fac-ture pas des changements non autorisés oudéraisonnables. Comment peut-elle déter-miner que de tels changements ont étéeffectués ?

- Ce qui empêche le prestataire extérieur dedonner son aval à des changements horsdes plages de temps définies, ce qui a desrépercussions importantes sur l’organisation(applications indisponibles au moment oùl’on en a besoin) et sur les coûts (manque àgagner).

- Qui est chargé de veiller à l’adéquation ducalcul, du chiffrage, de la validation, de laplanification, du contrôle, de la mise enœuvre et de la revue périodique des chan-gements qui affectent l’informatique.

- Si le prestataire a pris en compte les réper-cussions sur l’infrastructure (système et


33

réseau), ainsi que sur la sécurité informa-tique.

- Si l’organisation a identifié qui, parmi sesmembres, siège dans les comités de contrôledes changements.

- Qui veille au respect des accords de niveaude service.

- Pour les systèmes qui relèvent de la section404 de la loi Sarbanes-Oxley, ou d’autresdispositions réglementaires, l’accord deniveau de service doit également décrire lespratiques requises, les procédures de valida-tion, le calendrier des tests nécessaires, lesactions correctives, les nouveaux tests à réa-liser, et d’autres aspects encore.

• Lors de l’analyse et de la rédaction des obser-vations d’audit, présenter toute la valeur ajou-tée pour l’entreprise des processus de gestiondes changements efficaces, ainsi que lesrisques découlant de processus inefficaces.Exposer clairement les risques opérationnels,financiers et réglementaires qui ne sont pascorrectement gérés, et mettre en relation lesconstats et les tolérances au risque que lemanagement a définies conformément à sesobjectifs. Éviter de se concentrer sur la techno-logie, sauf dans les cas où certains contrôlesdes processus de gestion des changementssont automatisés. Rappeler plutôt au manage-ment que la gestion des changements s’inscritdans le cadre d’un processus mettant l’accentsur les aspects managériaux et humains, etqu’il s’accompagne de contrôles techniques etautomatisés.

GTAG – Auteurs et réviseurs

34

Auteurs et réviseurs

AuteursSajay Sajay Rai, CISSP, CISMGregory Wilson, CISSP, CISM, CGEITDuy Nguyen

RéviseursPhilip Chukwuma, CISSPSteve Hunt, CIASteve Jameson, CIA, CCSA, CFSA, CRMA

Réviseurs en françaisHervé MolinaBéatrice Ki-Zerbo, CIA

GTAG – Annexe A : Exemple d’étude de caspour la gestion des changements

35

Annexe A : Exemple d’étude de cas pour la gestion deschangements Les organisations performantes utilisent leurs processus de gestion des changements informatiques pourréduire leurs risques, ainsi que pour accroître leur efficacité et leur efficience. Les effets positifs qui sontassociés à un contrôle efficace des changements sont donc significatifs et mesurables. La capacité à ledémontrer, plutôt que de se contenter de « faire plaisir aux auditeurs » facilite l’élaboration d’une étudede cas destinée à améliorer ces contrôles. Comme nous l’avons vu dans les sections précédentes, les prin-cipaux indicateurs sont le taux de réussite ou d’échec des changements, le délai de rétablissement aprèsdes changements échoués et le nombre de tâches non planifiées qui en résulte. Le tableau 3 synthétiseles indicateurs d’une gestion inefficace des changements. Le tableau 4 décrit les solutions à mettre enœuvre d’après l’expérience sur le terrain.

Tableau 3 : Problèmes et indicateurs d’une gestion inefficace des changements

Symptômes Causes sous-jacentes

« Comme de nombreuses grandes organisations recou-rant à des SI, nous subissions les effets des change-ments non formalisés. Nous savions quand ceschangements survenaient, mais, comme il était difficiled’en faire un suivi, et dans le contexte actuel, axé sur lasécurité, ce n’était pas acceptable. »

Faibles niveaux de service et de disponibilité. Nombre inconnu de changements opérationnels. Taux de changements non contrôlé. Faible taux de réussite du changement (inférieur à70%). Proportion élevée de tâches non planifiées.

« Dans les scénarios de panne des systèmes de négo-ciation sur le marché obligataire, le service d’assistanceétait le premier informé. Il faisait remonter l’informationjusqu’au management informatique, qui constituaitune équipe d’intervention pour procéder auxrecherches nécessaires afin de découvrir ce qui s’étaitpassé. »

Si les changements ont échoué, la recherche descauses et la gestion des problèmes représentent plusde 25% de la charge de travail. Un diagnostic inexact aboutit à un faible taux de réso-lution des problèmes du premier coup (inférieur à50%).

« On se serait cru au Far West. Les intervenants ne noti-fiaient pas les changements qu’ils effectuaient, etdemandaient encore moins l’autorisation de les réali-ser. C’étaient nos statistiques sur la disponibilité quinous en informaient ! »

En l’absence de contrôles détectifs portant sur les pro-cessus de gestion des changements, les performancessont médiocres. En l’absence de contrôles portant sur les changements,les auditeurs ne disposent pas des éléments de preuvede contrôles préventifs et détectifs qui leur auraientpermis de confirmer l’efficacité des contrôles.

GTAG – Annexe A : Exemple d’étude de caspour la gestion des changements

36

Tableau 4 : Effets positifs d’une transformation efficace (d’après les résultats effectifs notifiés)

Solution adoptée Effets positifs

« Nous nous sommes aperçus que les tâches non plani-fiées étaient le plus souvent dues aux conséquencesinattendues de changements. Nous avons donc pré-senté par écrit la procédure d’autorisation requise pourapporter des changements dans la production et pourconsolider les processus. Nous avons également « élec-trifié la clôture » pour que la procédure de gestion deschangements soit respectée. »

Visibilité accrue de la gestion des changements propo-sés. Les changements opérationnels sont uniquement ceuxautorisés par le processus de gestion des changements. Le renforcement du contrôle du taux de changementspeut porter le taux de réussite du changement à plusde 95 %, grâce à la visibilité et aux tests.

« Nous avons commencé à instaurer un système impo-sant réellement à tout le monde de respecter le proces-sus de gestion des changements. Nous avons établi unplanning de réunions journalières sur la gestion de ladisponibilité, sous la supervision de Kenny, notre vice-président chargé de l’exploitation. Avec l’aide des per-sonnes chargées de la mise en œuvre, Kenny examinetous les changements échoués, et a une discussionavec toute personne qui a contourné la procédure degestion des changements. Précisons simplement queles changements non autorisés ou sauvages sont,depuis, bien moins fréquents ! »

(Cette entreprise chiffre le coût des pannes à 7 000 USDpar minute) Le nombre de changements non autorisés a diminué :on dénombre aujourd’hui « plusieurs changementsnon autorisées par an », et non plus « plusieurs change-ments non autorisés par jour ». Étant donné quechaque panne nécessite deux heures de travail pour lareprise de l’activité (estimation prudente), 5 000 heuresont ainsi été économisées sur une base annualisée. Tous les changements sont entièrement formalisés, cequi permet de commencer par les éliminer commecause possible d’une panne, et d’exprimer le délai dereprise d’activité non plus en « heures » mais en« minutes ». Pour les 11 pannes survenues au troisièmetrimestre, on a ainsi pu éviter environ 13 heures d’indis-ponibilité.

« Nous nous sommes aperçus que les tâches non plani-fiées étaient le plus souvent dues aux conséquencesinattendues de changements. Nous entendions fairemieux respecter nos normes et ne plus passer dutemps sur des contrôles détectifs. »« De plus, pour préparer les audits, nous disposionsdésormais, chaque année, de moins d’une demi-jour-née par projet, contre, auparavant, quatre semaines ! »« Nous faisions appel à trois équipes différentes pourvérifier la conformité à la législation : une pour la sec-tion 404 de la loi Sarbanes-Oxley, une pour la loiGramm-Leach Billey et une pour la loi Health InsurancePortability and Accountability. Lorsque nous avons com-pris que toutes les trois imposaient une bonne informa-tion sur les contrôles relatifs aux changements, nousavons remplacé ces trois équipes par une seule etunique équipe. »

La conformité à la réglementation est aujourd’huigérée au jour le jour, et non plus dans la précipitation àla dernière minute.Des preuves de l’efficacité des contrôles relatifs auxchangements étant produites périodiquement, lesauditeurs externes n’ont pas eu à rédiger de lettre decommentaires au management (alors que, l’année pré-cédente, il y avait eu 130 heures de tâches non plani-fiées et d’honoraires d’audit). La mise en correspondance entre les contrôles deschangements et les obligations réglementaires habi-tuelles réduit le nombre d’activités menées en doublepar différentes équipes. Douze membres du personnelinformatique ont été réaffectés dans l’équipe chargéede l’exploitation informatique.

« Outre le fait qu’aucun d’entre nous n’a besoin d’ame-ner son pager à la maison, nous constatons que nousavons davantage de temps à consacrer aux projets pla-nifiés, et que nous n’avons plus besoin de gérer desurgences à tout moment. »

La proportion des tâches non planifiées est tombée deplus de 40 % à 15 %.Le taux de livraison des projets dans les délais est passéde 0 à 60 %. Le directeur des systèmes d’information a chargé lemanagement informatique des grands projets straté-giques pour l’année à venir.

GTAG – Annexe B : Exemple de programme d’audit

37

Annexe B : Exemple de programme d’audit

Objectifs decontrôle Risques Contrôles Etapes de travail

Processus de gestion du changement

Communiquer lesobjectifs, les besoins,les rôles et les res-ponsabilités.

Erreurs provenantd’une mauvaise com-préhension du pro-cessus.

Le processus de gestion deschangements est défini etcommuniqué à ceux quisont impliqués dans le pro-cessus, notamment au per-sonnel et aux prestataires deservice.

Déterminer si le processus estdocumenté et l’endroit où il estsitué.Déterminer comment les change-ments apportés au processus sontcommuniqués. À partir de discussions avec unéchantillon des personnes impli-quées, évaluer leur compréhen-sion des procédures et desobjectifs du processus, ainsi quel’importance de leur rôle dans leprocessus. Vérifier qu’elles ontaccès à la documentation et auxoutils nécessaires.

Séparation des tâches

Déléguer les respon-sabilités de façon àce que les erreursinvolontaires ouvolontaires soientdétectées.

Résultats inattendusou défavorables.

Au minimum, des personnesdifférentes doivent assumerles responsabilités de l’auto-risation des changements etde leur mise en œuvre. Dansl’idéal, la conception et letest des changements serontégalement effectués par despersonnes différentes.

Valider que les changements sontrevus et approuvés par un niveauapproprié du management. Valider que ceux qui autorisent leschangements ne peuvent lesmettre en œuvre dans l’environ-nement de production. Déterminer comment les change-ments sont testés afin de s’assurerqu’ils fonctionnent comme prévuet ne portent pas atteinte à l’inté-grité, la disponibilité ou la confi-dentialité des données.


38


Procédures de gestion du changement

Veiller à ce qu’unchangementréponde aux besoinsde l’entreprise.


Un processus standard etcentralisé de traitement detous les changements existe.

Sélectionner un échantillon deschangements et valider le fait queles contrats ont été réalisés, del’initiation à la mise en œuvre dechaque changement.

Veiller à ce qu’unchangement n’af-fecte pas la disponi-bilité, l’intégrité et laconfidentialité dessystèmes et des don-nées.

Tous les changements sontapprouvés au niveau appro-prié du management.

Tous les changements sontcatégorisés et leur impactest évalué.

Tous les changements sontsoumis à un test réussi par lepersonnel informatique etles opérationnels avantd’être mis en production.

Tous les changements sontprogrammés et communi-qués aux intéressés avantleur mise en œuvre.

Tous les changements rela-tifs à la production sontassociés à un plan de restau-ration.

Changements urgents

Veiller à ce que lesbesoins de l’entre-prise soient satisfaits.

Incapacité à répon-dre efficacement auxchangementsurgents devant êtreréalisés.

Il existe des procédures pouridentifier, évaluer et approu-ver des changements vérita-blement urgents.

Sélectionner un échantillon dechangements urgents et validerqu’ils répondent à la définitiond’un changement véritablementurgent, et que les contrôlesappropriés ont été exécutés dulancement à la mise en place dechaque changement.

Veiller à ce qu’unchangement n’af-fecte pas la disponi-bilité, l’intégrité et laconfidentialité dessystèmes et des don-nées.


Une revue après la mise enplace est réalisée afin devalider que les procéduresd’urgence ont été convena-blement suivies, et de déter-miner l’impact duchangement.


39


Surveillance et reporting

Veiller à ce que leprocessus fonctionnecomme prévu et à sabonne compréhen-sion par ceux quisont concernés etimpactés.

Problèmes inconnus. Les indicateurs sont recueil-lis, analysés et communi-qués au management et àceux impliqués dans le pro-cessus

Identifier les indicateurs existants,la façon dont ils sont calculés etqui les calcule. Identifier à qui ilssont communiqués.Déterminer si les indicateurs sontappropriés, complets et exacts. Les indicateurs communs recueil-lis dans le cadre du processus degestion des changements com-prennent : • Le nombre total de change-

ments sur une période donnée.• Les changements couronnés

de succès.• Les changements qui ont

échoué.• La réussite ou l’échec des plans

de reprise.• Les changements qui ont dévié

du processus de gestion deschangements.

• Le pourcentage de change-ments urgents.

• Le nombre d’interventions deservice non programmées surune période donnée.

• Le pourcentage d’interventionsnon programmées par rapportà l’ensemble des travaux réali-sés par le personnel informa-tique.

GTAG – A propos du CRIPP

40

Eléments Définition

Les dispositions obligatoires. Le respect de ces éléments est exigé et la ligne directrice est élaborée selon le processus requis qui inclut uneconsultation publique. La conformité aux principes mis en exergue dans les lignes directrices obligatoires estindispensable pour la pratique professionnelle de l'audit interne. Les trois composantes des dispositions obliga-toires sont la définition de l’audit interne, le Code de Déontologie et les Normes internationales pour la pratiqueprofessionnelle de l’audit interne (Normes).

Définition La Définition de l’Audit Interne établit l’objectif fondamental, la nature et lechamp d'application de l’audit interne.

Code de déontologie Le Code de déontologie établit les principes et attentes régissant le compor-tement des individus et des organisations dans la conduite de l’audit interne.Il décrit les règles minimales de conduite ainsi que des comportementsattendus plutôt que des activités spécifiques.

Normes internationales pour lapratique professionnelle del’audit interne (Normes)

Les Normes sont des principes qui fournissent un cadre pour la réalisationdes missions et la promotion de l’audit interne. Elles se composent deNormes de qualification, de Normes de fonctionnement et de Normes demises en œuvre. Les Normes sont des exigences obligatoires constituées :

· de déclarations sur les exigences fondamentales pour la pratique pro-fessionnelle de l’audit interne et pour l’évaluation de sa performance.Elles sont internationales et applicables au niveau du service et auniveau individuel.

· d’interprétations clarifiant les termes ou les concepts utilisés dans lesdéclarations.

Il est nécessaire de considérer le texte dans sa totalité (c’est-à-dire les déclara-tions et les interprétations) afin de comprendre et d’appliquer correctementles Normes. Les termes spécifiques utilisés dans les Normes sont explicitésdans le Glossaire.

A propos du CRIPP

GTAG – A propos du CRIPP

41

Ce GTAG est un guide pratique du CRIPP.

Eléments Définition

Les dispositions fortement recommandées. La conformité à ces lignes directrices, approuvées par l’IIA, est fortement recommandée. Elles proposent des pra-tiques pour la mise en œuvre effective de la définition de l’audit interne, du Code de Déontologie de l’IIA et desNormes internationales pour la pratique professionnelle de l’audit interne (Normes). Les trois composantes desdispositions fortement recommandées sont les prises de position, les modalités pratiques d’application (MPA) etles guides pratiques.

Prises de position Les Prises de Position aident l’ensemble des parties prenantes, y compriscelles qui ne sont pas des professionnels de l’audit interne, à comprendre lesprincipaux enjeux en matière de gouvernance, de risque ou de contrôle. Ellesprécisent également le rôle et les responsabilités de l’audit interne.

Modalités pratiques d’applica-tion (MPA)

Les Modalités Pratiques d’Application fournissent une approche et uneméthodologie mais ne précisent pas les processus et les procédures détail-lées. Ce sont des lignes directrices qui aident les auditeurs internes dans l'applica-tion du Code de déontologie et des Normes ainsi que la promotion des meil-leures pratiques.Ces pratiques concernent notamment :

• des problématiques internationales, nationales ou spécifiques à cer-tains secteurs d'activité ;

• des missions d'audit spécifiques ;• des questions légales ou réglementaires.

Guides pratiques Les guides pratiques sont des lignes directrices détaillées pour la conduitedes activités d’audit interne. Ce sont des processus et des procédures détaillés tels que des outils, destechniques, des programmes, des approches séquentielles (par exemple, desmodèles de livrables).

A PROPOS DE L’INSTITUTE OF INTERNAL AUDITORS

Fondé en 1941, The Institute of Internal Auditors (IIA) est une organisation professionnelle internationale dont lesiège mondial se situe à Altamonte Springs, en Floride, aux États-Unis. L’Institute of Internal Auditors est la voixmondiale, une autorité reconnue, un leader incontesté et le principal défenseur de la profession d’auditeur interne.C’est également un acteur de premier plan pour la formation des auditeurs internes. Il est représenté en Francepar l’IFACI.

A PROPOS DES GUIDES PRATIQUES

Les guides pratiques détaillent la réalisation des activités d’audit interne. Ils contiennent des processus et des pro-cédures, tels que les outils et techniques, les programmes et les approches pas-à-pas, et donnent des exemples delivrables. Les guides pratiques s’inscrivent dans le Cadre de référence international des pratiques professionnellesde l'audit interne de l’Institute of Internal Auditors. Ces guides pratiques relèvent de la catégorie des dispositionsfortement recommandées. La conformité à ces guides pratiques n’est donc pas obligatoire, mais fortement recom-mandée. Ces guides ont été officiellement révisés et approuvés par l’IIA.Le Global Technologies Audit Guide (GTAG) est un type de guide pratique qui aborde, dans un langage courant,une question d’actualité liée à la gestion, au contrôle ou à la sécurité des technologies de l’information.Pour de plus amples informations sur les documents de référence proposés par l’Institute, vous pouvez consulternotre site Web, www.theiia.org.guidance ou www.ifaci.com.

AVERTISSEMENT

L’Institute of Internal Auditors publie ce document à titre informatif et pédagogique. Cette ligne directrice n’a pasvocation à apporter de réponses définitives à des cas précis, et doit uniquement servir de guide. L’Institute ofInternal Auditors vous recommande de toujours solliciter un expert indépendant pour avoir un avis dans chaquesituation. L’Institute dégage sa responsabilité pour les cas où des lecteurs se fieraient exclusivement à ce guide.

COPYRIGHT

Le copyright de ce guide pratique est détenu par l’Institute of Internal Auditors et par l’IFACI pour sa version fran-çaise. Pour l’autorisation de reproduction, prière de contacter l’Institute of Internal Auditors à l’[email protected] ou l’IFACI à l’adresse [email protected].

The Institute of Internal Auditors IFACI247 Maitland Avenue, Altamonte Springs 98bis, Boulevard HaussmannFlorida 32701, États-Unis 75008 PARIS, FranceTéléphone : +1 407 937 1100 Téléphone : 01 40 08 48 00Télécopie : 1 407 937 1101 Fax : 01 40 08 48 20Site Web : www.theiia.org Site Web : www.ifaci.comCourrier électronique : [email protected] Courrier électronique : [email protected]

mailto:[email protected]

mailto:[email protected]

http://www.ifaci.com

http://www.theiia.org

Documents

Contrôles de la gestion du changement et des patchs : Un ...€¦ · ments fondamentaux concourant à la maîtrise du processus de gestion des changements informa-tiques, à savoir