# Journal officiel C 32/2010

| | ISSN 1725-2431
  doi:10.3000/17252431.C_2010.032.fra |
| --- | --- |
| Journal officiel
  de l'Union européenne | C 32 |
| | |
| Édition de langue française | Communications et informations | 53e année9 février 2010 |

ISSN 1725-2431

doi:10.3000/17252431.C_2010.032.fra

Journal officiel

de l'Union européenne

C 32

Édition de langue française

Communications et informations

53e année9 février 2010

---

| Numéro d'information | Sommaire | page |
| --- | --- | --- |
| | IV   Informations |
| | INFORMATIONS PROVENANT DES INSTITUTIONS, ORGANES ET ORGANISMES DE L'UNION EUROPÉENNE |
| | Cour des comptes |
| 2010/C 032/01 | 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 | 1 |

Numéro d'information

Sommaire

page

IV   Informations

INFORMATIONS PROVENANT DES INSTITUTIONS, ORGANES ET ORGANISMES DE L'UNION EUROPÉENNE

Cour des comptes

2010/C 032/01

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

1

| FR | |
| --- | --- |

FR

---

IV Informations

INFORMATIONS PROVENANT DES INSTITUTIONS, ORGANES ET ORGANISMES DE L'UNION EUROPÉENNE

Cour des comptes

| 9.2.2010 | FR | Journal officiel de l'Union européenne | C 32/1 |
| --- | --- | --- | --- |

9.2.2010

FR

Journal officiel de l'Union européenne

C 32/1

---

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

| BCE | Banque centrale européenne |
| --- | --- |
| COBIT | Control Objectives for Information and related Technology (objectifs de contrôle des technologies de l'information) |
| DG-H | Direction générale des ressources humaines, budget et organisation |
| DG-SI | Direction générale des systèmes d'information |
| EER | Rafraîchissement de l'ECB-LAN Eurotower (ECB-LAN Eurotower Refresh) |
| MAU | Mise à niveau de la zone des salles informatiques principales (Main computer rooms Area Upgrade) du bâtiment Eurotower |
| MDP | Compilation de données de marché (Market Data Provision) |
| MPIDS | Système d'aide à la décision pour la mise en œuvre de la politique monétaire (Monetary Policy Implementation Decision support System) |
| PMBOK | Project Management Body of Knowledge (somme de connaissances sur la gestion de projets) |
| PMI | Project Management Institute |
| POCP | Project Organisation and Control Procedures (procédures relatives à l'organisation et au contrôle des projets) |
| PPU Target 2 | Plate-forme partagée unique pour Target 2 |
| SEBC | Système européen de banques centrales |
| TCERTO | Extension de la téléconférence, du CoreNet et du SEBC-Net à la Bulgarie et à la Roumanie |

BCE

Banque centrale européenne

COBIT

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

DG-H

Direction générale des ressources humaines, budget et organisation

DG-SI

Direction générale des systèmes d'information

EER

Rafraîchissement de l'ECB-LAN Eurotower (ECB-LAN Eurotower Refresh)

MAU

Mise à niveau de la zone des salles informatiques principales (Main computer rooms Area Upgrade) du bâtiment Eurotower

MDP

Compilation de données de marché (Market Data Provision)

MPIDS

Système d'aide à la décision pour la mise en œuvre de la politique monétaire (Monetary Policy Implementation Decision support System)

PMBOK

Project Management Body of Knowledge (somme de connaissances sur la gestion de projets)

PMI

Project Management Institute

POCP

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

PPU Target 2

Plate-forme partagée unique pour Target 2

SEBC

Système européen de banques centrales

TCERTO

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

INTRODUCTION

| 1. | 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. |
| --- | --- |

1.

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.

| 2. | 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. |
| --- | --- |

2.

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.

| 3. | Le budget de la BCE est scindé en deux grandes parties: les activités relevant du «fonctionnement de la banque» [les dépenses opérationnelles des services – ou entités organisationnelles – de la BCE (4)] et celles concernant l'«évolution/consolidation de la banque». Ces dernières se répartissent en deux grands groupes:






  i) | 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; |
| --- | --- | --- |

3.

Le budget de la BCE est scindé en deux grandes parties: les activités relevant du «fonctionnement de la banque» [les dépenses opérationnelles des services – ou entités organisationnelles – de la BCE (4)] et celles concernant l'«évolution/consolidation de la banque». Ces dernières se répartissent en deux grands groupes:

i)

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;

| ii) | les activités relatives aux billets de banque, consacrées principalement à la recherche et au développement en matière de billets. |
| --- | --- |

ii)

les activités relatives aux billets de banque, consacrées principalement à la recherche et au développement en matière de billets.

| 4. | En 2007, les dépenses de la BCE concernant les projets informatiques (5) se sont élevées à quelque 20 millions d'euros sur le montant total de 31 millions d'euros qu'elle a consacrés à l'ensemble des activités relatives aux projets. |
| --- | --- |

4.

En 2007, les dépenses de la BCE concernant les projets informatiques (5) se sont élevées à quelque 20 millions d'euros sur le montant total de 31 millions d'euros qu'elle a consacrés à l'ensemble des activités relatives aux projets.

ÉTENDUE ET APPROCHE DE L'AUDIT

| 5. | L'audit de la Cour visait principalement à évaluer la gestion, par la BCE, des projets informatiques, en posant les deux questions suivantes:






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

5.

L'audit de la Cour visait principalement à évaluer la gestion, par la BCE, des projets informatiques, en posant les deux questions suivantes:

—

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? |
| --- | --- |

—

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

| 6. | L'audit a comporté une évaluation des règles et des procédures de la BCE applicables aux différentes étapes de la gestion des projets informatiques, ainsi qu'un examen de leur mise en œuvre. |
| --- | --- |

6.

L'audit a comporté une évaluation des règles et des procédures de la BCE applicables aux différentes étapes de la gestion des projets informatiques, ainsi qu'un examen de leur mise en œuvre.

| 7. | 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). |
| --- | --- |

7.

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).

| 8. | 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. |
| --- | --- |

8.

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.

| 9. | 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. |
| --- | --- |

9.

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?

| 10. | En procédant à l’audit du cadre de gestion des projets informatiques, la Cour a examiné si la BCE:






  — | disposait d’une stratégie informatique pluriannuelle conforme à ses buts et objectifs globaux en matière d’organisation, |
| --- | --- | --- |

10.

En procédant à l’audit du cadre de gestion des projets informatiques, la Cour a examiné si la BCE:

—

disposait d’une stratégie informatique pluriannuelle conforme à ses buts et objectifs globaux en matière d’organisation,

| — | planifiait les activités relatives à ses projets informatiques selon un cycle annuel, |
| --- | --- |

—

planifiait les activités relatives à ses projets informatiques selon un cycle annuel,

| — | se fondait sur des critères rigoureux pour sélectionner les projets informatiques à mettre en œuvre, |
| --- | --- |

—

se fondait sur des critères rigoureux pour sélectionner les projets informatiques à mettre en œuvre,

| — | avait établi des procédures appropriées pour la gestion de ses projets informatiques. |
| --- | --- |

—

avait établi des procédures appropriées 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?

| 11. | 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. |
| --- | --- |

11.

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.

| 12. | 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). |
| --- | --- |

12.

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).

| 13. | 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). |
| --- | --- |

13.

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?

| 14. | Tout cycle de programmation annuel requiert la formulation d'objectifs annuels et la définition d'actions à entreprendre pour les atteindre, ainsi que l'établissement d’indicateurs de performance clés pour mesurer les performances. |
| --- | --- |

14.

Tout cycle de programmation annuel requiert la formulation d'objectifs annuels et la définition d'actions à entreprendre pour les atteindre, ainsi que l'établissement d’indicateurs de performance clés pour mesurer les performances.

| 15. | 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. |
| --- | --- |

15.

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.

| 16. | 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. |
| --- | --- |

16.

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.

| 17. | 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. |
| --- | --- |

17.

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.

| 18. | Aucun des deux documents de planification n’est, en fin de compte, suffisamment détaillé pour être efficace. En outre, ils ne fournissent aucune indication sur les ressources financières nécessaires pour réaliser chaque objectif et mettre en œuvre les actions sélectionnées. |
| --- | --- |

18.

Aucun des deux documents de planification n’est, en fin de compte, suffisamment détaillé pour être efficace. En outre, ils ne fournissent aucune indication sur les ressources financières nécessaires pour réaliser chaque objectif et mettre en œuvre les actions sélectionnées.

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

| 19. | Les ressources disponibles n’étant pas suffisantes pour financer tous les projets possibles chaque année, il est nécessaire d’établir un processus de sélection des projets présentant le degré de priorité le plus élevé afin de faire le meilleur usage de ces ressources. |
| --- | --- |

19.

Les ressources disponibles n’étant pas suffisantes pour financer tous les projets possibles chaque année, il est nécessaire d’établir un processus de sélection des projets présentant le degré de priorité le plus élevé afin de faire le meilleur usage de ces ressources.

| 20. | 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. |
| --- | --- |

20.

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.

| 21. | 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. |
| --- | --- |

21.

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

| 22. | 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. |
| --- | --- |

22.

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.

| 23. | 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. |
| --- | --- |

23.

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

Image

Source: Banque centrale européenne.

| 24. | 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). |
| --- | --- |

24.

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).

| 25. | 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. |
| --- | --- |

25.

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

| 26. | 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. |
| --- | --- |

26.

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.

| 27. | Le document POCP établit la structure organisationnelle qui doit être mise en place pour la gestion des projets de la BCE, notamment les rôles et responsabilités, ainsi que la composition des entités participantes concernées (voir
  diagramme 2). |
| --- | --- |

27.

Le document POCP établit la structure organisationnelle qui doit être mise en place pour la gestion des projets de la BCE, notamment les rôles et responsabilités, ainsi que la composition des entités participantes concernées (voir
  diagramme 2).

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

Image

Source: Banque centrale européenne.

| 28. | 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. |
| --- | --- |

28.

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?

| 29. | Dans le cadre de l'audit de l’application du cadre de gestion des projets informatiques, la Cour a examiné si la BCE:






  — | 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, |
| --- | --- | --- |

29.

Dans le cadre de l'audit de l’application du cadre de gestion des projets informatiques, la Cour a examiné si la BCE:

—

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,

| — | mettait correctement en œuvre les différents projets en faisant en sorte que les ressources soient mises à disposition en temps utile et en testant suffisamment chaque élément de projet à livrer, |
| --- | --- |

—

mettait correctement en œuvre les différents projets en faisant en sorte que les ressources soient mises à disposition en temps utile et en testant suffisamment chaque élément de projet à livrer,

| — | 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, |
| --- | --- |

—

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,

| — | évaluait formellement les éléments de projet à livrer et les ressources utilisées une fois les projets achevés. |
| --- | --- |

—

évaluait formellement les éléments de projet à livrer et les ressources utilisées une fois les projets achevés.

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

Le document de présentation de projet

| 30. | 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. |
| --- | --- |

30.

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.

| 31. | 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. |
| --- | --- |

31.

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

| 32. | Tous les projets ont été autorisés conformément aux procédures prévues par le document POCP. Avant chacune des trois étapes, une décision formelle visant à poursuivre le projet était prise par le comité (14). Trois projets (15) étaient considérés comme indispensables afin d'assurer la conformité aux normes SEBC et autres normes en vigueur. Les autres (16) avaient été sélectionnés au moyen de la méthode de hiérarchisation des projets. Tous les projets étaient cohérents par rapport aux grands axes stratégiques/opérationnels de la DG-SI ou aux stratégies générales des services concernés. |
| --- | --- |

32.

Tous les projets ont été autorisés conformément aux procédures prévues par le document POCP. Avant chacune des trois étapes, une décision formelle visant à poursuivre le projet était prise par le comité (14). Trois projets (15) étaient considérés comme indispensables afin d'assurer la conformité aux normes SEBC et autres normes en vigueur. Les autres (16) avaient été sélectionnés au moyen de la méthode de hiérarchisation des projets. Tous les projets étaient cohérents par rapport aux grands axes stratégiques/opérationnels de la DG-SI ou aux stratégies générales des services concernés.

Besoins des utilisateurs et spécifications des projets

| 33. | 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. |
| --- | --- |

33.

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

| 34. | 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. |
| --- | --- |

34.

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.

| 35. | Une section spécifique est réservée à l’analyse du risque dans les trois documents de planification (18). Cette section a été complétée dans chacun de ces documents. Néanmoins, il n’y avait pas d'approche commune de la détermination des risques encourus par les projets, ni de l’évaluation de leur probabilité et de leur incidence. L’évaluation était fondée sur l’expérience propre à chacun des gestionnaires de projets. L’évaluation initiale des risques dans le cadre du projet MDP ne tenait compte que des risques liés aux prestataires externes. Au cours de la mise en œuvre du projet, des risques internes se sont également matérialisés, par exemple des contraintes financières. Étant donné que ces facteurs n’avaient pas été considérés comme des risques, aucune action correctrice n’avait été prévue au stade de la planification. Dans le cas du projet MPIDS, d’autres risques, tels ceux liés à la complexité des processus opérationnels concernés, auraient également pu être prévus, mais il n’en était pas fait état dans le document de présentation. |
| --- | --- |

35.

Une section spécifique est réservée à l’analyse du risque dans les trois documents de planification (18). Cette section a été complétée dans chacun de ces documents. Néanmoins, il n’y avait pas d'approche commune de la détermination des risques encourus par les projets, ni de l’évaluation de leur probabilité et de leur incidence. L’évaluation était fondée sur l’expérience propre à chacun des gestionnaires de projets. L’évaluation initiale des risques dans le cadre du projet MDP ne tenait compte que des risques liés aux prestataires externes. Au cours de la mise en œuvre du projet, des risques internes se sont également matérialisés, par exemple des contraintes financières. Étant donné que ces facteurs n’avaient pas été considérés comme des risques, aucune action correctrice n’avait été prévue au stade de la planification. Dans le cas du projet MPIDS, d’autres risques, tels ceux liés à la complexité des processus opérationnels concernés, auraient également pu être prévus, mais il n’en était pas fait état dans le document de présentation.

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

Gestion des ressources et participation des utilisateurs

| 36. | 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. |
| --- | --- |

36.

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.

| 37. | Dans le cadre de tous les projets sélectionnés, les utilisateurs étaient régulièrement informés au cours de la mise en œuvre. Dans la plupart des cas, les utilisateurs étaient représentés au sein du groupe de pilotage et/ou d’autres réunions de l’équipe de projet, et ils étaient également informés par le biais des rapports mensuels sur l'état d'avancement des projets. |
| --- | --- |

37.

Dans le cadre de tous les projets sélectionnés, les utilisateurs étaient régulièrement informés au cours de la mise en œuvre. Dans la plupart des cas, les utilisateurs étaient représentés au sein du groupe de pilotage et/ou d’autres réunions de l’équipe de projet, et ils étaient également informés par le biais des rapports mensuels sur l'état d'avancement des projets.

Prestataires externes

| 38. | 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. |
| --- | --- |

38.

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

| 39. | 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. |
| --- | --- |

39.

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

| 40. | 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. |
| --- | --- |

40.

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.

| 41. | 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. |
| --- | --- |

41.

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.

| 42. | 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. |
| --- | --- |

42.

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?

| 43. | À 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. |
| --- | --- |

43.

À 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.

| 44. | Ce document doit être complet puisqu'il doit aborder tous les aspects essentiels qui doivent être pris en compte au moment de la clôture d’un projet. Ses principales sections sont:






  i) | l'évaluation du respect du champ d'application et de la réalisation des objectifs tels qu’ils ont été approuvés; |
| --- | --- | --- |

44.

Ce document doit être complet puisqu'il doit aborder tous les aspects essentiels qui doivent être pris en compte au moment de la clôture d’un projet. Ses principales sections sont:

i)

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

| ii) | l'évaluation de l’utilisation des ressources humaines et financières; |
| --- | --- |

ii)

l'évaluation de l’utilisation des ressources humaines et financières;

| iii) | l'évaluation des avantages quantitatifs et qualitatifs; |
| --- | --- |

iii)

l'évaluation des avantages quantitatifs et qualitatifs;

| iv) | le rapport sur les enseignements tirés. |
| --- | --- |

iv)

le rapport sur les enseignements tirés.

| 45. | 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. |
| --- | --- |

45.

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

| 46. | 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. |
| --- | --- |

46.

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.

| 47. | 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:






  i) | ampleur accrue des travaux à effectuer; |
| --- | --- | --- |

47.

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:

i)

ampleur accrue des travaux à effectuer;

| ii) | manque de ressources humaines. |
| --- | --- |

ii)

manque de ressources humaines.

| 48. | 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. |
| --- | --- |

48.

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

| 49. | Le document de clôture de projet doit comporter une comparaison des ressources humaines et financières prévues avec celles effectivement utilisées. Les documents de clôture des quatre projets précités comprenaient cette comparaison ainsi qu’une explication des principaux écarts. |
| --- | --- |

49.

Le document de clôture de projet doit comporter une comparaison des ressources humaines et financières prévues avec celles effectivement utilisées. Les documents de clôture des quatre projets précités comprenaient cette comparaison ainsi qu’une explication des principaux écarts.

| 50. | Les ressources humaines et financières effectivement utilisées pour chacun des projets étaient inférieures à celles qui avaient été budgétisées. Les dépenses effectives étaient de 3 à 23 % inférieures à celles inscrites au budget (voir
  annexe
  ). De nombreuses raisons, liées aux projets eux-mêmes, ont été avancées pour expliquer cette sous-utilisation des crédits. |
| --- | --- |

50.

Les ressources humaines et financières effectivement utilisées pour chacun des projets étaient inférieures à celles qui avaient été budgétisées. Les dépenses effectives étaient de 3 à 23 % inférieures à celles inscrites au budget (voir
  annexe
  ). De nombreuses raisons, liées aux projets eux-mêmes, ont été avancées pour expliquer cette sous-utilisation des crédits.

| 51. | 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. |
| --- | --- |

51.

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

| 52. | 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. |
| --- | --- |

52.

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.

| 53. | Pour les quatre projets, le rapport de clôture indiquait que les avantages mentionnés dans le document de présentation, soit étaient encore valables, soit avaient été obtenus. Or, certains de ces avantages ne peuvent être évalués correctement qu'après une période de fonctionnement (voir point 25). |
| --- | --- |

53.

Pour les quatre projets, le rapport de clôture indiquait que les avantages mentionnés dans le document de présentation, soit étaient encore valables, soit avaient été obtenus. Or, certains de ces avantages ne peuvent être évalués correctement qu'après une période de fonctionnement (voir point 25).

| 54. | 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: |
| --- | --- |

54.

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)

| — | Finances: (positif) le projet a été mis en œuvre dans les limites du budget; (négatif) les honoraires des consultants correspondant à l'élaboration de la solution sont jugés supérieurs aux prix du marché. |
| --- | --- |

—

Finances: (positif) le projet a été mis en œuvre dans les limites du budget; (négatif) les honoraires des consultants correspondant à l'élaboration de la solution sont jugés supérieurs aux prix du marché.

| — | Innovation: (positif) le projet a contribué à l'élaboration d'un système de suivi à l'appui de l'accord de niveau de service; (négatif) le projet a donné lieu à la mise en place d'une nouvelle base de données propre à l'organisation, d'une utilisation assez complexe et moins souple que celle qui était déjà en service. |
| --- | --- |

—

Innovation: (positif) le projet a contribué à l'élaboration d'un système de suivi à l'appui de l'accord de niveau de service; (négatif) le projet a donné lieu à la mise en place d'une nouvelle base de données propre à l'organisation, d'une utilisation assez complexe et moins souple que celle qui était déjà en service.

| — | Organisation: (positif) le projet a contribué à l'élaboration de politiques concernant l'utilisation des données de marché. |
| --- | --- |

—

Organisation: (positif) le projet a contribué à l'élaboration de politiques concernant l'utilisation des données de marché.

| — | Utilisateurs: (positif) le projet a permis l'intégration des données de Bloomberg; (négatif) les possibilités d'utilisation de la solution ont été jugées inférieures aux attentes. |
| --- | --- |

—

Utilisateurs: (positif) le projet a permis l'intégration des données de Bloomberg; (négatif) les possibilités d'utilisation de la solution ont été jugées inférieures aux attentes.

Rapport sur les enseignements tirés

| 55. | Selon le document POCP, un rapport sur les enseignements tirés doit être annexé au rapport de clôture de projet. Le but est de garantir que l'expérience acquise avec la mise en œuvre d'un projet particulier soit mise à la disposition de l'ensemble de l'organisation, de manière à améliorer la gestion de futurs projets. |
| --- | --- |

55.

Selon le document POCP, un rapport sur les enseignements tirés doit être annexé au rapport de clôture de projet. Le but est de garantir que l'expérience acquise avec la mise en œuvre d'un projet particulier soit mise à la disposition de l'ensemble de l'organisation, de manière à améliorer la gestion de futurs projets.

| 56. | 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. |
| --- | --- |

56.

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.

| 57. | Dans le cas des projets MDP et TCERTO, des points qui intéresseront effectivement les procédures de gestion de projets de la BCE ont été mis en évidence. Des extraits des points soulevés dans le rapport du MDP sont présentés dans l'encadré 2: |
| --- | --- |

57.

Dans le cas des projets MDP et TCERTO, des points qui intéresseront effectivement les procédures de gestion de projets de la BCE ont été mis en évidence. Des extraits des points soulevés dans le rapport du MDP sont présentés dans l'encadré 2:

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

| — | Souligner l'importance de la phase d'élaboration, notamment la détermination des exigences des utilisateurs. Il est suggéré de donner plus de poids, à l'avenir, à l'utilisateur final pour décider du choix de la solution. |
| --- | --- |

—

Souligner l'importance de la phase d'élaboration, notamment la détermination des exigences des utilisateurs. Il est suggéré de donner plus de poids, à l'avenir, à l'utilisateur final pour décider du choix de la solution.

| — | 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. |
| --- | --- |

—

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.

| — | Souligner l'importance des tests réalisés sur les éléments à livrer à chaque phase. |
| --- | --- |

—

Souligner l'importance des tests réalisés sur les éléments à livrer à chaque phase.

| — | Planifier les ressources en fonction de la hiérarchisation des projets: le projet a souffert d'un manque de ressources pendant chaque phase de tests en raison d'un télescopage avec un autre élément à livrer dans le même service. |
| --- | --- |

—

Planifier les ressources en fonction de la hiérarchisation des projets: le projet a souffert d'un manque de ressources pendant chaque phase de tests en raison d'un télescopage avec un autre élément à livrer dans le même service.

| — | Considérer le portail d'un projet comme un outil efficace de partage des connaissances: un point d'accès central et convivial à l'ensemble des informations relatives au projet s'est avéré très utile. |
| --- | --- |

—

Considérer le portail d'un projet comme un outil efficace de partage des connaissances: un point d'accès central et convivial à l'ensemble des informations relatives au projet s'est avéré très utile.

| 58. | 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. |
| --- | --- |

58.

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?

| 59. | La BCE a mis en place un cadre de gouvernance pour la gestion de ses projets informatiques; certaines améliorations sont toutefois possibles. |
| --- | --- |

59.

La BCE a mis en place un cadre de gouvernance pour la gestion de ses projets informatiques; certaines améliorations sont toutefois possibles.

| 60. | La BCE n'a pas établi de stratégie informatique pluriannuelle qui définisse de manière formelle ses orientations stratégiques et ses objectifs à moyen terme. En 2008, elle a entrepris un examen stratégique de ses activités informatiques, qui devrait déboucher sur l'élaboration d'une stratégie en la matière. |
| --- | --- |

60.

La BCE n'a pas établi de stratégie informatique pluriannuelle qui définisse de manière formelle ses orientations stratégiques et ses objectifs à moyen terme. En 2008, elle a entrepris un examen stratégique de ses activités informatiques, qui devrait déboucher sur l'élaboration d'une stratégie en la matière.

| 61. | Contrairement aux projets informatiques de la BCE pour lesquels les ressources financières ont été estimées, les documents de planification annuelle de la direction générale des systèmes d'information ne donnaient aucune précision concernant les ressources financières nécessaires pour atteindre les objectifs de celle-ci et mettre en œuvre les actions sélectionnées. |
| --- | --- |

61.

Contrairement aux projets informatiques de la BCE pour lesquels les ressources financières ont été estimées, les documents de planification annuelle de la direction générale des systèmes d'information ne donnaient aucune précision concernant les ressources financières nécessaires pour atteindre les objectifs de celle-ci et mettre en œuvre les actions sélectionnées.

| 62. | La BCE a renforcé sa procédure de sélection des projets, en 2008, en fournissant des informations suffisantes pour alimenter la prise de décisions. |
| --- | --- |

62.

La BCE a renforcé sa procédure de sélection des projets, en 2008, en fournissant des informations suffisantes pour alimenter la prise de décisions.

| 63. | Les procédures de gestion des projets informatiques de la BCE sont en grande partie conformes aux meilleures pratiques. Des déficiences ont été constatées au niveau de l'analyse des parties prenantes et de l'évaluation a posteriori de l'incidence des projets. |
| --- | --- |

63.

Les procédures de gestion des projets informatiques de la BCE sont en grande partie conformes aux meilleures pratiques. Des déficiences ont été constatées au niveau de l'analyse des parties prenantes et de l'évaluation a posteriori de l'incidence des projets.

Recommandations (première question)

| 1. | La BCE devrait établir de manière formelle une stratégie informatique pluriannuelle susceptible de constituer un outil efficace pour la gestion de ses activités informatiques. |
| --- | --- |

1.

La BCE devrait établir de manière formelle une stratégie informatique pluriannuelle susceptible de constituer un outil efficace pour la gestion de ses activités informatiques.

| 2. | La BCE devrait renforcer encore sa planification annuelle en matière d'informatique en élaborant un document exhaustif qui définisse des objectifs ainsi que des indicateurs de performance permettant d'en mesurer le degré de réalisation. Il conviendrait de ventiler les objectifs en actions spécifiques, en indiquant les ressources financières nécessaires à la réalisation de ces dernières. |
| --- | --- |

2.

La BCE devrait renforcer encore sa planification annuelle en matière d'informatique en élaborant un document exhaustif qui définisse des objectifs ainsi que des indicateurs de performance permettant d'en mesurer le degré de réalisation. Il conviendrait de ventiler les objectifs en actions spécifiques, en indiquant les ressources financières nécessaires à la réalisation de ces dernières.

| 3. | La BCE devrait inclure l'analyse des parties prenantes et l'évaluation a posteriori de l'incidence des projets dans ses procédures de gestion de projets. |
| --- | --- |

3.

La BCE devrait inclure l'analyse des parties prenantes et l'évaluation a posteriori de l'incidence des projets dans ses procédures de gestion de projets.

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

| 64. | 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. |
| --- | --- |

64.

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.

| 65. | La Cour a constaté qu'au stade de leur mise en œuvre, trois projets avaient souffert d'un manque de ressources spécialisées ayant occasionné des retards. |
| --- | --- |

65.

La Cour a constaté qu'au stade de leur mise en œuvre, trois projets avaient souffert d'un manque de ressources spécialisées ayant occasionné des retards.

| 66. | De manière générale, la BCE a mis en place des outils et des systèmes d'informations de gestion appropriés pour le suivi de ses projets informatiques. Toutefois, l'utilisation des ressources humaines affectées aux projets informatiques ne fait l'objet que d'un suivi partiel. |
| --- | --- |

66.

De manière générale, la BCE a mis en place des outils et des systèmes d'informations de gestion appropriés pour le suivi de ses projets informatiques. Toutefois, l'utilisation des ressources humaines affectées aux projets informatiques ne fait l'objet que d'un suivi partiel.

| 67. | Une évaluation formelle, effectuée lors de la phase d'achèvement, figure dans le rapport de clôture du projet, qui contient les principaux aspects à prendre en considération à ce stade. Cependant, sur les six projets, un seul a été clôturé dans les délais prévus dans le document de présentation du projet. |
| --- | --- |

67.

Une évaluation formelle, effectuée lors de la phase d'achèvement, figure dans le rapport de clôture du projet, qui contient les principaux aspects à prendre en considération à ce stade. Cependant, sur les six projets, un seul a été clôturé dans les délais prévus dans le document de présentation du projet.

| 68. | La Cour recommande ce qui suit:

  Recommandations (seconde question)







  4. | 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. |
| --- | --- | --- |

68.

La Cour recommande ce qui suit:

Recommandations (seconde question)

4.

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.

| 5. | 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. |
| --- | --- |

5.

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.

| 6. | Le rapport sur les enseignements tirés devrait s'attacher à indiquer les possibilités d'améliorations pour les projets à venir, lesquelles devraient être activement diffusées auprès de l'ensemble des gestionnaires de projets. |
| --- | --- |

6.

Le rapport sur les enseignements tirés devrait s'attacher à indiquer les possibilités d'améliorations pour les projets à venir, lesquelles devraient être activement diffusées auprès de l'ensemble des gestionnaires de projets.

Le présent rapport a été adopté par la Cour des comptes à Luxembourg en sa réunion du 10 décembre 2009.

Par la Cour des comptes

Vítor Manuel da SILVA CALDEIRA

Président

---

(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.

1

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

2

(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.

3

(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.

4

(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.

5

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

6

(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.

7

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

8

(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é.

9

(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.

10

o

o

o

(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.

11

(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.

12

(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.

13

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

14

(15)  TCERTO, PPU Target 2 et EER.

15

(16)  MDP, MPIDS et MAU.

16

(17)  MDP, MPIDS et PPU Target 2.

17

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

18

(19)  TCERTO, MAU et EER.

19

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

20

(21)  MDP et TCERTO.

21

---

ANNEXE

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

| Projet | Durée du projet | Coût du projet (en euros) | |
| --- | --- | --- | --- |
| Date de début de mise en œuvre | Date de remise prévue | Date de fin de projet prévue | Date de remise effective | Date de fin de projet effective | Total des ressources budgétisées | Total des ressources effectives | Différence |
| 1) | Mise à niveau de la zone des salles informatiques principales du bâtiment Eurotower (MAU) |

Projet

Durée du projet

Coût du projet (en euros)

Date de début de mise en œuvre

Date de remise prévue

Date de fin de projet prévue

Date de remise effective

Date de fin de projet effective

Total des ressources budgétisées

Total des ressources effectives

Différence

1)

Mise à niveau de la zone des salles informatiques principales du bâtiment Eurotower (MAU)

28.6.2007

3.3.2008

18.4.2008

4.9.2008

2.12.2008

1 406 644

1 363 336

–43 308

–3,1 %

| 2) | Rafraîchissement de l'ECB-LAN Eurotower (EER) |
| --- | --- |

2)

Rafraîchissement de l'ECB-LAN Eurotower (EER)

1.7.2006

13.4.2007

25.5.2007

15.2.2007

30.3.2007

1 158 692

1 014 359

– 144 333

–12,5 %

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

3)

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

1.3.2006

16.10.2006

19.1.2007

28.3.2007

27.6.2007

2 060 927

1 594 595

– 466 332

–22,6 %

| 4) | Système d'aide à la décision pour la mise en œuvre de la politique monétaire – phase 3 (MPIDS) |
| --- | --- |

4)

Système d'aide à la décision pour la mise en œuvre de la politique monétaire – phase 3 (MPIDS)

1.3.2007

20.11.2007

29.2.2008

à obtenir de la BCE

à obtenir de la BCE

790 192

à obtenir de la BCE

—

—

| 5) | Compilation de données de marché (MDP) |
| --- | --- |

5)

Compilation de données de marché (MDP)

2.1.2007

30.9.2007

30.11.2007

31.12.2007

14.2.2008

1 859 379

1 458 105

– 401 274

–21,6 %

| 6) | Intégration de la BCE à la plate-forme partagée unique pour Target 2 (PPU Target 2) |
| --- | --- |

6)

Intégration de la BCE à la plate-forme partagée unique pour Target 2 (PPU Target 2)

15.5.2006

20.5.2008

8.8.2008

18.5.2008

15.4.2009

508 387

540 339

+31 952

+6,3 %

---

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.

---