Rapport de la Cour des comptes sur l'audit de l'efficience de la gestion de la Banque centrale européenne pour l'exercice 2007, accompagné des réponses de la Banque centrale européenne

2010/C 32/01

TABLE DES MATIÈRES

Liste des abréviations et glossaire

Introduction

Étendue et approche de l'audit

Observations

La BCE disposait-elle d'un cadre de gouvernance approprié pour la gestion de ses projets informatiques?

La BCE disposait-elle d’une stratégie informatique pluriannuelle conforme à ses buts et objectifs globaux en matière d’organisation?

La BCE planifiait-elle les activités relatives à ses projets informatiques selon un cycle annuel?

Le processus de sélection des projets informatiques à mettre en œuvre était-il fondé sur des critères satisfaisants?

Des procédures appropriées ont-elles été établies pour la gestion des projets informatiques?

Le cadre de gouvernance mis en place pour la gestion des projets informatiques a-t-il été appliqué comme prévu?

Les différents projets étaient-ils planifiés de manière appropriée?

Les projets ont-ils été correctement mis en œuvre?

Les projets ont-ils fait l’objet d’un suivi approprié?

Une évaluation formelle a-t-elle été effectuée à l’issue des projets?

Conclusions et recommandations

La BCE disposait-elle d'un cadre de gouvernance approprié pour la gestion de ses projets informatiques?

Le cadre de gouvernance mis en place pour la gestion des projets informatiques a-t-il été appliqué comme prévu?

Annexe – Vue d'ensemble des projets audités par la Cour des comptes européenne

LISTE DES ABRÉVIATIONS ET GLOSSAIRE

Extension de la téléconférence, du CoreNet et du SEBC-Net à la Bulgarie et à la Roumanie

Project Organisation and Control Procedures (procédures relatives à l'organisation et au contrôle des projets)

Control Objectives for Information and related Technology (objectifs de contrôle des technologies de l'information)

INTRODUCTION

La Banque centrale européenne (BCE – «la banque») et les banques centrales nationales de l'ensemble des États membres constituent le Système européen de banques centrales (SEBC). L'objectif premier du SEBC est le maintien de la stabilité des prix. Le SEBC apporte également son soutien aux politiques économiques générales dans l’Union, en vue de contribuer à la réalisation des objectifs de l’Union (1) . À cette fin, la BCE s'acquitte des tâches définies dans ses statuts (2) et est responsable de la gestion de ses activités et de ses finances.

L'audit de l'efficience de la gestion de la BCE par la Cour est fondé sur l'article 27, paragraphe 2, du protocole fixant le statut du SEBC et de la BCE (3) . Le thème d'audit sélectionné était la gestion, par la BCE, des projets informatiques pour les exercices 2007 et 2008. L'évolution des pratiques de la BCE au cours du premier trimestre 2009 a également été prise en considération.

les activités concernant les projets, à savoir les grands projets de la BCE et du SEBC, les autres projets, les initiatives de moindre envergure et les investissements centralisés en informatique;

ÉTENDUE ET APPROCHE DE L'AUDIT

Pour apprécier si la BCE avait mis en place un cadre de gouvernance approprié, la Cour a pris notamment en considération l'ensemble des principaux documents et procédures relatifs à la gestion des projets informatiques. Le principal document utilisé pour la gestion des projets est le POCP (Project Organisation and Control Procedures), qui concerne les procédures relatives à l'organisation et au contrôle des projets (6) . Pour apprécier le caractère approprié du cadre de gouvernance pour l'informatique, il a également été tenu compte des normes et des meilleures pratiques internationalement reconnues, comme le Project Management Body of Knowledge [PMBOK (7) ] du PMI (Project Management Institute) et le référentiel COBIT (Control Objectives for Information and related Technology) de l'IT Governance Institute (institut de gouvernance en matière d'informatique).

Afin d'évaluer si les règles et les procédures étaient appliquées comme prévu au niveau du projet, six projets informatiques ont fait l'objet d'un audit approfondi, fondé sur des entretiens avec des gestionnaires de projets, des équipes de projet et des utilisateurs finals, ainsi que sur un examen des documents pertinents concernant le projet.

La ligne budgétaire de la BCE relative aux «grands projets de la BCE» a constitué la base de l'échantillon. Pour l'exercice 2007, elle comprenait seize grands projets, dont quatorze concernant l'informatique. La sélection a été opérée selon les critères suivants: i) le type de projet; ii) son budget; et iii) son état d'achèvement. Une description synthétique de chaque projet figure en annexe , ainsi que des informations sur la durée et le coût des projets.

OBSERVATIONS

La BCE disposait-elle d'un cadre de gouvernance approprié pour la gestion de ses projets informatiques?

La BCE disposait-elle d’une stratégie informatique pluriannuelle conforme à ses buts et objectifs globaux en matière d’organisation?

L'établissement d’une stratégie informatique pluriannuelle conforme aux buts et objectifs globaux en matière d’organisation constitue une condition préalable à l’utilisation efficace des ressources. Cette stratégie doit être formulée de manière à fournir des lignes directrices concernant la planification et la réalisation des activités informatiques sur plusieurs années, permettant ainsi de fixer les dépenses informatiques à un niveau adéquat et de les concentrer sur les domaines où les besoins en la matière sont les plus importants. Elle doit être fondée sur une évaluation globale des besoins informatiques qui permette de prendre des décisions fondées concernant la hiérarchisation des domaines d’intervention.

La Cour a constaté que la BCE ne disposait pas d’une stratégie informatique pluriannuelle présentant et définissant ses buts stratégiques et ses objectifs à moyen terme en matière d'informatique. La Cour a également relevé l'absence d’évaluation globale et formelle des besoins visant à hiérarchiser les domaines d’intervention dans une perspective à moyen terme. Néanmoins, la lettre du président et les grands axes stratégiques/opérationnels des différents services servent de base pour dresser la liste des nouveaux projets informatiques, qui sont ensuite classés par ordre de priorité lors de la mise à jour annuelle du portefeuille de projets (voir points 19 à 21).

En 2008, la direction générale des systèmes d'information (DG-SI) et la direction générale des ressources humaines (DG-H) ont engagé, en étroite collaboration avec les autres services de la BCE, un examen stratégique des activités informatiques de la BCE. Celui-ci n'était pas encore achevé au moment de l’audit de la Cour (premier trimestre 2009). La première phase de l’examen visait à étudier en détail les buts et objectifs des différents services et à connaître leurs besoins opérationnels stratégiques de nouveaux systèmes, projets et services informatiques pour les cinq années à venir (2009-2013). Elle s’est achevée en décembre 2008. Cet exercice devrait déboucher sur la formulation d’une stratégie informatique couvrant l’ensemble des fonctions de la DG-SI (notamment les projets informatiques).

La BCE planifiait-elle les activités relatives à ses projets informatiques selon un cycle annuel?

En 2007, la DG-SI a élaboré un document relatif aux grands axes stratégiques/opérationnels pour 2007, qui répertoriait un certain nombre de grands objectifs, dont certains concernaient la gestion de projets informatiques (8) . Ils n'étaient cependant pas traduits en objectifs et actions spécifiques, et les résultats escomptés n’étaient pas définis.

En 2008, la DG-SI a élaboré deux documents de planification: l’un, de caractère plus générique, qui s'intitule «grands axes stratégiques/opérationnels pour 2008», et l'autre «programme de travail 2008». Le document relatif aux grands axes stratégiques et opérationnels comprenait une section récapitulant les principaux défis de la DG-SI pour 2008 et un aperçu général des objectifs et des indicateurs de performance clés pour cette même année. Certains de ces objectifs avaient trait à la gestion des projets informatiques (9) , et leur réalisation devait être mesurée au moyen d’indicateurs de performance clés spécifiques et quantifiables pour lesquels des valeurs cibles étaient fixées pour les deuxième et quatrième trimestres 2008.

Le programme de travail 2008 était plus circonstancié et définissait les actions à mettre en œuvre pour atteindre chacun de ces objectifs. Cette évolution positive renforce le processus de planification et représente une amélioration de la situation par rapport à 2007. Il a toutefois été constaté que le programme 2008 comportait un nombre d'objectifs beaucoup plus important que n'en contenaient les «grands axes stratégiques/opérationnels pour 2008». Or, le programme de travail n'a pas été établi pour développer les objectifs fixés dans ces derniers, ni pour préciser les moyens à mettre en œuvre pour les atteindre, ni pour ajouter de nouveaux objectifs.

Le processus de sélection des projets informatiques à mettre en œuvre était-il fondé sur des critères satisfaisants?

Le processus suivi en 2007 pour hiérarchiser et sélectionner les projets s’appuyait sur un portefeuille de projets à moyen terme (trois ans). Chaque année, la BCE réévalue tous les projets (ceux en cours, ceux déjà saisis dans le système de projets mais non encore démarrés et les projets nouvellement saisis) en fonction des objectifs globaux de la BCE. Ce programme à moyen terme est mis à jour tous les deux ans de façon à tenir compte des nouveaux projets saisis et d’éventuelles autres évolutions. L’évaluation des projets est fondée sur les dossiers de rentabilité économique présentés et sur l'estimation des ressources nécessaires à leur réalisation. En l'absence de critères de hiérarchisation clairs, la sélection des projets est moins objective, ce qui accroît le risque d'une utilisation non optimale des ressources disponibles.

En 2008, une méthode de hiérarchisation des projets plus efficace a été instaurée. Elle reposait sur un «concept en trois piliers» (10) et consistait en des évaluations spécifiques par domaine (11) , qui étaient ensuite consolidées au niveau de la BCE. Le système de gestion des projets informatiques établi en 2008 fournissait suffisamment d’informations pour que les décisions puissent être prises.

Des procédures appropriées ont-elles été établies pour la gestion des projets informatiques?

Procédures de gestion des projets informatiques

La BCE a instauré des procédures relatives à l'organisation et au contrôle des projets (POCP) auxquelles doit se conformer la gestion de tous les projets (12) , y compris ceux qui ont trait à l’informatique. Le document POCP comprend une définition précise de ce qui constitue un projet et délimite clairement son champ d’application. Il détermine également la structure organisationnelle à mettre en place pour les projets, notamment les rôles et responsabilités des différentes entités participantes.

Le concept de cycle de vie défini dans le document POCP permet de disposer d'une structure de contrôle efficace des projets, en divisant ceux-ci en phases logiques et en fixant avec précision les étapes de la prise de décision (voir diagramme 1 ). Une comparaison avec le PMBOK montre que le document POCP est dans une large mesure conforme à ce corpus de bonnes pratiques. Les domaines dans lesquels le POCP peut être amélioré sont l’analyse des parties prenantes et l’évaluation a posteriori de l’incidence des projets. Les déficiences existantes et leurs conséquences sont présentées en détail dans les points ci-après.

Diagramme 1 – Phases du cycle de vie d’un projet

Source: Banque centrale européenne.

Le document POCP n’impose pas d’analyse formelle et documentée des parties prenantes. Cela signifie que l’équipe de projet n’est pas tenue de recenser formellement les parties prenantes et de diagnostiquer leurs besoins spécifiques dans le cadre de celui-ci (13) . Or, l’absence de recensement formel de toutes les parties prenantes et de leurs besoins peut avoir une incidence négative sur la réussite d’un projet. Il convient toutefois d'observer que, dans le cas des projets examinés, il a été tenu compte des besoins des utilisateurs (voir points 33 et 36).

Aucune évaluation a posteriori d’un projet n’est prévue dès lors que celui-ci est opérationnel depuis un certain temps. Ce type d’évaluation pourrait, notamment, fournir une appréciation formelle des avantages quantitatifs et qualitatifs escomptés dont il est fait état dans le dossier d’agrément du projet et faciliter ainsi la programmation de projets à venir (voir point 53). Récemment, le nouveau modèle, qui exige que les utilisateurs fassent part de leurs réactions aux projets informatiques afin de connaître leur degré de satisfaction quant à la qualité des services fournis, a constitué une évolution positive en la matière.

Répartition des responsabilités et structure décisionnelle

Pour faire en sorte que les projets soient mis en œuvre de manière efficace et efficiente, il est nécessaire d’établir un cadre de gestion définissant clairement les obligations en matière de rapports et les responsabilités des organes et fonctions intervenant dans le processus.

Diagramme 2 – Schéma du cadre de gestion de projet de la BCE

Source: Banque centrale européenne.

Le document POCP fixe clairement les obligations en matière de rapports entre les organes et fonctions engagés dans le processus de gestion de projets. Le comité de pilotage de projet est le principal organe de décision interne de la BCE s’agissant de la hiérarchisation, de la planification, de l’approbation et du suivi des projets. La structure établie par le document POCP couvre toutes les fonctions nécessaires et prévoit des procédures décisionnelles claires, avec des rôles et des responsabilités prédéfinis.

Le cadre de gouvernance mis en place pour la gestion des projets informatiques a-t-il été appliqué comme prévu?

assurait un suivi de la mise en œuvre à l'aide de systèmes assurant la production de comptes rendus fréquents, qui fassent la synthèse de toutes les données pertinentes relatives aux projets et permettent de prendre des décisions en connaissance de cause,

planifiait les différents projets de façon adéquate en évaluant, d’une part, leurs objectifs et les solutions proposées pour les atteindre, et, d'autre part, les ressources nécessaires,

Les différents projets étaient-ils planifiés de manière appropriée?

Le document de présentation de projet

La planification d’un projet est appropriée lorsqu’elle couvre les éléments suivants: i) l'étendue et les objectifs globaux du projet; ii) la solution proposée; iii) les étapes essentielles et éléments à livrer; iv) les ressources humaines et financières; et v) l’équipe de projet.

Le document de présentation de projet est le principal instrument de planification (voir diagramme 1). Ce document sert de base pour décider si la solution retenue doit être mise en œuvre. Pour les six projets examinés, ces documents étaient complets et couvraient toutes les questions essentielles qui doivent être abordées au moment d’approuver un projet.

Autorisation et sélection d’un projet

Besoins des utilisateurs et spécifications des projets

Pour trois des projets examinés (17) , les besoins des utilisateurs ont été évalués et documentés au stade de la planification. Les trois autres projets ne concernant que la prolongation d’un réseau déjà en place (TCERTO) ou la mise à niveau d’une infrastructure existante (EER et MAU), les utilisateurs n’ont pas été impliqués au stade de la planification. Dans le cas du projet MPIDS, les spécifications ont été élaborées selon une approche par tests itératifs. Celle-ci n’ayant pas été appliquée de la meilleure façon possible, des retards ont été enregistrés et les versions expérimentales n’étaient pas aussi élaborées que prévu.

Évaluation des risques

Les risques que les objectifs d’un projet ne soient pas atteints devraient être déterminés avec un niveau de précision suffisant et devraient être structurés et évalués en profondeur au cours de la phase de planification, tant pour ce qui concerne leur probabilité que leur incidence potentielle sur la réalisation des objectifs.

Les projets ont-ils été correctement mis en œuvre?

Gestion des ressources et participation des utilisateurs

Pour trois des projets examinés (19) , les ressources et les compétences affectées à leur mise en œuvre étaient suffisantes. Les trois autres ont connu un problème de ressources spécialisées, qui n’ont pas été mises à disposition en quantité suffisante en temps utile. S'agissant du projet MDP, les utilisateurs n’étaient pas toujours disponibles, car un projet similaire devait être achevé dans les mêmes délais. Cela a engendré des retards au niveau de la mise en œuvre. Pour ce qui concerne le projet MPIDS, l’équipe n’était pas secondée par un analyste commercial et le personnel de la DG-SI n’était pas toujours disponible en cas de besoin. L’engagement d’un développeur externe a engendré un retard de trois mois. Après avoir été engagé, le développeur a été remplacé à plusieurs reprises, ce qui a entraîné des problèmes de mise en œuvre du projet. En raison de la complexité du projet, sa mise en œuvre a été découpée en plusieurs phases (20) . Le transfert de connaissances entre la deuxième et la troisième phase ne s'est pas déroulé comme prévu, la plupart des principaux membres de l’équipe de projet, y compris le gestionnaire, n'ayant pas participé à la troisième phase.

Prestataires externes

Pour le projet MDP, une dérogation aux règles de passation de marchés de la BCE a été accordée en raison du fait que ce marché ne pouvait être dissocié de la sélection antérieure du fournisseur de données. Or, le développement et le soutien de logiciels n’étaient pas l’activité principale de ce dernier. Ce problème a fait que le volet «développement» de l’élaboration du module de mise à jour a été plus onéreux que prévu.

Test et acceptation des éléments du projet à livrer au cours de la mise en œuvre

Le test d'un élément informatique à livrer nouveau ou modifié fait partie intégrante des procédures de la BCE et doit être effectué avant toute mise en œuvre d’un élément. Les six projets ont tous été testés avant d’être lancés. Les tests ont été mis au point par l’équipe de projet. Cependant, les utilisateurs finals n’ont pas toujours été impliqués dans la conception des tests et, par conséquent, les améliorations nécessaires n’ont pas toujours été relevées à temps.

Les projets ont-ils fait l’objet d’un suivi approprié?

Systèmes d’informations de gestion et rapports de suivi

Les gestionnaires de projets doivent disposer d’informations suffisantes et fiables pour assurer un suivi efficace des projets au cours de leur mise en œuvre et pour que les problèmes puissent être décelés et résolus en temps utile.

La BCE utilise plusieurs instruments pour le suivi de ses projets informatiques. Le temps consacré à un projet ainsi que les données financières et les informations relatives aux principales réalisations et à l’état d’avancement des travaux sont consignés dans les rapports mensuels sur l'état d'avancement des projets. Des rapports de ce type, contenant des informations suffisantes, ont été produits régulièrement au cours de la mise en œuvre des six projets examinés. Il a toutefois été constaté, dans le cas du projet PPU Target 2, que certains rapports n’avaient pu être rédigés par manque de ressources humaines.

Néanmoins, seul le temps consacré aux projets par le personnel de la DG-SI est comptabilisé. Le temps consacré par les agents des autres services et par le personnel des banques centrales nationales ne fait l’objet que d’une simple estimation. De plus, les heures supplémentaires ne sont pas systématiquement comptabilisées, voire pas du tout. Le suivi n'est donc pas fondé sur des informations complètes et exactes s’agissant du temps consacré aux projets.

Une évaluation formelle a-t-elle été effectuée à l’issue des projets?

À l’issue d’un projet, il convient d’effectuer une évaluation formelle de la réalisation des objectifs visés et des ressources utilisées. Le document POCP prévoit la production d’un rapport de clôture dès que tous les éléments à livrer de la phase de mise en œuvre l'ont été avec succès et que le produit final du projet est accepté par le(s) service(s) concerné(s), par le responsable du système et par le service des opérations de la DG-SI. Le rapport de clôture est donc le document par lequel la clôture formelle d’un projet est approuvée.

Au 15 avril 2009, un rapport de clôture avait été produit et approuvé pour cinq des six projets examinés (voir annexe ). Le document POCP prévoit d'une manière générale qu’un projet doit être clôturé dans les trois mois qui suivent l’acceptation de ses éléments à livrer finals. Dans le cas du projet PPU Target 2, les travaux ont débuté en mai 2008 et le projet a été clôturé le 15 avril 2009. Cela est dû au fait que la DG-SI et le responsable technique ne parvenaient pas à s’entendre sur le contenu de l’accord de niveau de service. Lors de sa réunion d’octobre 2007, le groupe de pilotage avait indiqué que cet accord devait être conclu avant la mise en service du projet PPU Target 2 et qu’il était nécessaire de s’y atteler rapidement, car la présentation claire des attentes et des services et la communication entre le service des opérations et les différents utilisateurs sont des éléments essentiels. De même, dans le cas du projet MPIDS, la clôture du projet n’a pas eu lieu car la signature de l’accord de niveau de service a pris un retard important.

Évaluation du respect du champ d'application et de la réalisation des objectifs tels qu’ils ont été approuvés

Au moment de la clôture d’un projet, il convient d’effectuer une évaluation des résultats effectifs par rapport au champ d’application et aux objectifs approuvés. Cette évaluation doit porter sur les principales phases et sur les principaux éléments à livrer du projet, et fournir une justification pour tout écart important.

La Cour a examiné les évaluations effectuées pour chacun des quatre projets ayant fait l’objet d’un rapport de clôture adopté au plus tard fin mars 2009. Ces évaluations comparaient les réalisations avec le plan initial figurant dans le document de présentation du projet. Elles reprenaient toutes les étapes essentielles et tous les éléments à livrer prévus et fournissaient des explications pour les principaux écarts. Il a cependant été constaté que deux projets (21) avaient pris du retard par rapport au plan initial (voir annexe ). Les deux principales explications fournies étaient les suivantes:

Dans le cas du projet MAU, même si l’infrastructure technique était apparemment disponible et fonctionnait bien avant la date indiquée dans le document de clôture, l’acceptation et le transfert formels ont accusé un retard de six mois.

Évaluation de l’utilisation des ressources humaines et financières

La question de la sous-utilisation des crédits affectés aux projets a également été soulevée par le comité budgétaire de la BCE dans son rapport d’évaluation concernant le rapport de fin d'année établi par cette dernière sur le suivi budgétaire relatif à 2008. Il y est indiqué que le comité a constaté une sous-utilisation de crédits de 18 millions d’euros (28,8 %). Le comité a considéré que cela était principalement dû au retard pris par certains projets et qu’il était possible d’améliorer la planification et la mise en œuvre des projets. La Cour constate que la mise en œuvre des projets souffre de retards (voir annexe ) qui ont effectivement une incidence sur l’exécution budgétaire. Cependant, le fait que les ressources prévues dans le plan initial dépassaient les besoins indique que les budgets initiaux ne sont pas établis aussi précisément qu’ils le devraient. Il s'ensuit que des ressources budgétaires sont engagées qui ne sont donc pas disponibles pour des projets plus avancés.

Évaluation des avantages qualitatifs et quantitatifs

Au moment de la clôture du projet, il est procédé à une évaluation des avantages qualitatifs et quantitatifs à tirer au stade de l'exploitation du produit final. Il faut expliciter les écarts par rapport aux informations fournies dans le document de présentation du projet et, par conséquent, utilisées lors de la procédure de hiérarchisation et de sélection des projets.

Dans le cas du projet MDP, l'évaluation initiale figurant dans le document de présentation a été plus que confirmée. Il a été procédé à une autre évaluation avec une méthodologie différente. Les avantages du produit final ont été appréciés par rapport aux quatre dimensions fixées dans un tableau de bord (balanced scorecard) comprenant des indicateurs positifs et négatifs. Le but était donc de parvenir à une évaIuation équitable des résultats du projet. Il s'agissait là d'une initiative positive pouvant être considérée comme une bonne pratique pour d'autres projets à venir. Des extraits de cette évaluation sont présentés dans l'encadré 1:

Encadré 1 – Évaluation des avantages qualitatifs et quantitatifs de MDP à la clôture du projet (extraits)

Rapport sur les enseignements tirés

Un rapport sur les enseignements tirés a certes été joint aux rapports de clôture des quatre projets, mais le niveau du contenu différait. Dans le cas du projet EER, les points concernant les enseignements semblaient avoir été insérés pour témoigner d'une gestion efficace, et non pour indiquer comment améliorer la gestion à l'avenir. Dans le cas du projet MAU, les précisions fournies étaient trop nombreuses, ce qui brouillait le message des enseignements exploitables pour de futurs projets.

Encadré 2 – Enseignements figurant dans le rapport de clôture du projet MDP (extraits)

Souligner l'importance de l'engagement et de l'obligation de rendre compte de l'utilisateur: il se peut qu'en l'absence d'une responsabilité clairement définie, celui-ci ne soit pas pleinement conscient de l'importance de son engagement pour concevoir et tester la solution.

Enfin, bien que les autres gestionnaires de projet puissent prendre connaissance des enseignements tirés en consultant les rapports de clôture, des éléments jugés dignes d'intérêt pour l'ensemble de l'organisation et susceptibles de renforcer le partage de l'expérience entre gestionnaires de projets n'ont pas été mis en évidence et n'ont pas fait l'objet d'une diffusion active.

CONCLUSIONS ET RECOMMANDATIONS

La BCE disposait-elle d'un cadre de gouvernance approprié pour la gestion de ses projets informatiques?

Recommandations (première question)

Le cadre de gouvernance mis en place pour la gestion des projets informatiques a-t-il été appliqué comme prévu?

Globalement, la BCE a appliqué comme prévu le cadre de gouvernance mis en place pour la gestion des projets informatiques. Tous les projets audités ont été dûment autorisés, au stade de la planification, avec l'approbation du document de présentation de projet. Cependant, il a été constaté que l'évaluation des risques relatifs aux projets souffrait d'un manque de précision et de l'absence d'une approche commune. De plus, les budgets établis dans les plans initiaux n'étaient pas aussi précis qu'ils auraient pu l'être.

La coordination entre la DG-SI et les services devrait être encore renforcée, afin que l'accord de niveau de service puisse être conclu plus rapidement.

Il conviendrait d'améliorer la planification des ressources de manière à garantir que l'ensemble des ressources spécialisées nécessaires au stade de la mise en œuvre des activités/projets sélectionné(e)s soit disponible à temps et que les budgets soient établis avec une plus grande rigueur.

(1) Article 105, paragraphe 1, du traité instituant la Communauté européenne, devenu article 127, paragraphe 1, du traité sur le fonctionnement de l'Union européenne.

(2) Les statuts du SEBC et de la BCE font l'objet d'un protocole joint au traité.

(3) L'article 27, paragraphe 2, stipule que «les dispositions de l'article 248 du traité s'appliquent uniquement à un examen de l'efficience de la gestion de la BCE». Les dispositions institutionnelles relatives à la Banque centrale européenne figurent aux articles 112 à 115 du traité CE, devenus articles 283, 294, 134 et 135 du traité sur le fonctionnement de l'Union européenne.

(4) La BCE est divisée en dix-sept services qui reflètent l'éventail de ses fonctions. Chaque service, à l'exception des conseillers auprès du directoire et de la représentation de la BCE à Washington, est dirigé par un cadre supérieur (directeur général ou directeur) qui rend compte à un membre du directoire.

(5) Il s'agit de projets de la BCE faisant appel à des ressources informatiques et dont la gestion est assurée à la fois par le service concerné et par la direction générale systèmes d'information.

(6) Sa dernière mise à jour date de 2006.

(7) Le PMBOK établit des normes et des orientations qui sont largement reconnues en tant que meilleures pratiques et qui servent également de norme à la BCE pour ses procédures de gestion de projets.

(8) Par exemple, meilleure harmonisation entre les activités principales et l’informatique et passage d’une approche par projets à une approche par programme.

(9) Par exemple, adopter les meilleures pratiques en matière de gestion et de réalisation des projets, réaliser les projets en respectant les budgets, le calendrier et la qualité convenus, notamment en ce qui concerne la convivialité.

(10) Pilier no 1: questions normalisées (vingt-deux paramètres); pilier no 2: analyse globale des agrégats; et pilier no 3: critères de hiérarchisation agrégés au niveau de la BCE en vue d'une décision finale.

(11) La direction chargée des projets informatiques est organisée en cinq domaines. Chaque domaine a en charge les projets lancés par différents services.

(12) Le document POCP ne couvre pas les petites tâches, les projets soit menés au sein d’un seul service, soit ne requérant aucune solution informatique, les tâches concernant l’infrastructure informatique qui engendrent peu de tests, un niveau d'innovation peu élevé ou ayant une incidence organisationnelle mineure, et qui n’offrent aucun nouveau service. Les projets sélectionnés par la Cour en vue d’un audit approfondi sont tous dans le champ d'application du document POCP.

(13) À la section 2.2 du document relatif au PMBOK, il est stipulé que cela est nécessaire pour garantir la réussite d’un projet. Le PMBOK stipule également que l’absence d’identification d’une partie prenante essentielle peut avoir une incidence négative sur le projet. À la section 10.1, consacrée à la planification de la communication relative au projet, il est indiqué que la détermination des besoins des parties prenantes et l’élaboration d’un moyen approprié pour y répondre est un facteur important pour la réussite du projet.

(14) Lancement, élaboration et mise en œuvre.

(15) TCERTO, PPU Target 2 et EER.

(16) MDP, MPIDS et MAU.

(17) MDP, MPIDS et PPU Target 2.

(18) Document de lancement du projet, document d'élaboration et document de présentation.

(19) TCERTO, MAU et EER.

(20) La troisième phase a été sélectionnée par la Cour pour l'audit.

(21) MDP et TCERTO.

Extension de la téléconférence, du CoreNet et du SEBC-Net à la Bulgarie et à la Roumanie (TCERTO)

RÉPONSE DE LA BANQUE CENTRALE EUROPÉENNE

La Banque centrale européenne (BCE) accueille favorablement le rapport de la Cour des comptes européenne pour l’exercice 2007 ainsi que les observations et recommandations de la Cour en vue d’améliorations. La BCE note en outre que la Cour reconnaît: i) que la BCE a mis en place un cadre de gouvernance pour la gestion des projets informatiques; ii) que les procédures de la BCE relatives à la gestion des projets informatiques sont globalement conformes aux meilleures pratiques; et iii) que la BCE a, dans l’ensemble, appliqué comme elle l’avait envisagé le cadre de gouvernance mis en place pour la gestion des projets informatiques.

La BCE prend note des observations et recommandations de la Cour en vue d’améliorations. Les commentaires de la BCE concernant certains paragraphes du rapport et les six recommandations qu’il contient sont formulés ci-après.

Points 12, 13 et 60

La BCE estime que son portefeuille pluriannuel de projets informatiques est conforme à ses objectifs stratégiques ainsi qu’à ceux de ses différents services. Les priorités de haut niveau de la BCE – définies dans la lettre du président et dans les grands axes stratégiques des différents services – servent de base pour dresser la liste des nouveaux projets. L’opportunité stratégique de chaque projet doit être décrite, notamment en ce qui concerne sa conformité aux objectifs stratégiques à moyen terme de la BCE et du service concerné. Les projets informatiques sont ensuite systématiquement notés et classés par ordre de priorité lors de la mise à jour annuelle du portefeuille de projets.

S’agissant de la stratégie informatique pluriannuelle, dont la portée est bien plus large que celle du portefeuille de projets informatiques, la BCE tient à signaler qu’un examen stratégique de ses activités informatiques a été lancé en juillet 2008. Les besoins opérationnels stratégiques identifiés au cours de la première phase de l’examen ont été approuvés en décembre 2008. En outre, une note sur l’orientation stratégique des services informatiques a été adoptée en janvier 2009. Cette orientation stratégique et les besoins opérationnels ont ensuite contribué à la formulation du plan stratégique 2009-2013 pour les services informatiques. Les buts stratégiques informatiques contenus dans le plan et les initiatives qui y sont associées ont été approuvés en mai 2009 (deuxième phase de l’examen). Le plan stratégique 2009-2013 a été adopté en août 2009 (au titre de la troisième phase de l’examen).

Points 18 et 61

Les grands axes stratégiques fournissent un cap stratégique pluriannuel. Le programme de travail annuel est plus détaillé; il est utilisé pour définir les activités à travers lesquelles les objectifs stratégiques sont mis en œuvre, mais répertorie aussi les activités opérationnelles. Les informations financières concernant l’ensemble des projets sont fournies dans différents documents relatifs à l’adoption des projets, à commencer par le formulaire d’enregistrement du projet. Des informations quant à la planification sont également fournies pour chaque activité de projet en vue d’une planification et d’un contrôle efficaces.

En ce qui concerne les activités n’ayant pas trait aux projets (comme les activités informatiques opérationnelles), les ressources financières et humaines sont planifiées et allouées dans le cadre de l’exercice budgétaire annuel. De plus, certaines ressources humaines affectées à la direction générale des services informatiques (DG-SI) sont planifiées et allouées à des activités tant de projet qu’opérationnelles dans le système d’allocation des ressources.

Point 24

La BCE reconnaît que les procédures relatives à l’organisation et au contrôle des projets (POCP) ne prévoient pas l’élaboration d’un document formel d’analyse des parties prenantes. Cette analyse est toutefois effectuée. Les parties prenantes sont recensées au cours de la phase de lancement du projet, donnant lieu au document de lancement du projet. La phase de lancement du projet a principalement pour objectif de mettre l’accent sur le problème et/ou le besoin opérationnel ainsi que sur les solutions éventuelles, ce qui doit permettre de recenser les parties prenantes (les services concernés, par exemple) et les prestataires de services potentiels. Un groupe de pilotage du projet, dans lequel toutes les parties prenantes sont présentes ou représentées, est mis sur pied dans le cadre de l’exercice de préparation du document de lancement du projet.

Point 38

La BCE s’est clairement efforcée de minimiser globalement les coûts et les risques aux niveaux opérationnel et du développement, plutôt que partiellement (à savoir les coûts de développement seulement), lorsqu’elle a envisagé de recourir au fournisseur à la fois pour la phase de développement du projet de compilation de données de marché et la fourniture de services concernant les données. Les résultats obtenus ont conduit à la fois au coût total de propriété le plus avantageux et à une diminution du risque lié au projet (c’est-à-dire une réduction du risque fournisseur, dans la mesure où les risques associés à la gestion de différents fournisseurs de logiciels et de séries de données ont pu être évités).

La BCE reconnaît que le développement de logiciels ne constituait pas l’activité principale du fournisseur. Le développement, qui a été sous-traité, a donc été limité aux fonctionnalités minimales nécessaires pour l’intégration de la solution principale, les tests ayant été renforcés au cours du cycle de vie du projet pour assurer la livraison d’éléments de projet de haute qualité.

Recommandation 1

La BCE estime qu’elle disposait d’un cadre de gouvernance approprié pour la gestion de ses projets informatiques, prévoyant notamment la définition d’objectifs stratégiques pluriannuels et leur alignement sur le portefeuille de projets informatiques. Elle reconnaît l’importance d’une stratégie informatique pluriannuelle, couvrant les projets informatiques mais aussi l’ensemble de la fonction informatique. C’est pour cette raison que la BCE a mis en place, à partir de 2009, un plan stratégique pour les services informatiques. L’examen stratégique des activités informatiques, lancé en juillet 2008, a donné lieu à la formulation d’un plan stratégique 2009-2013 pour les services informatiques. Les buts stratégiques informatiques qu’il contient ainsi que les initiatives dans ce domaine ont été approuvés en mai 2009 (deuxième phase de l’examen). Le plan stratégique 2009-2013 a quant à lui été adopté en août 2009 (au titre de la troisième phase de l’examen).

Recommandation 2

Conformément aux commentaires de la BCE relatifs aux paragraphes 18 et 61 du rapport de la Cour des comptes, la BCE estime que le cadre de gouvernance informatique en place désormais pour la planification et le contrôle des projets informatiques ainsi que l’affectation des ressources afférentes est approprié. Un document exhaustif couvrant les buts, les objectifs, les indicateurs de performance et les actions est disponible pour la fonction informatique dans son ensemble, y compris les activités non liées aux projets. Le renforcement, le cas échéant, des liens entre les différents points d’action et les dépenses financières associées est une source d’améliorations possibles.

Recommandations 3, 4 et 5

La BCE accepte les recommandations nos 3, 4 et 5.

Recommandation 6

La BCE a d’ores et déjà commencé à constituer une base de données/un rapport sur les enseignements tirés, qui sera à la disposition des gestionnaires de projet et des groupes de pilotage de projet. La direction générale des ressources humaines, du budget et de l'organisation (DG-H) utilisera également cette base de données pour l’évaluation des projets à l’attention du comité de pilotage des projets.

Mise en œuvre des recommandations

La recommandation no 1 a déjà été mise en œuvre. La recommandation no 2 a été largement mise en application en 2008, et le dernier élément (voir notre réponse ci-dessus) sera totalement mis en place d’ici à la fin 2010. Les recommandations nos 3 à 6 seront mises en œuvre d’ici à la fin 2010.