Pesi PDF

Lettre de marché N° 2010/257973
Contrat Cadre EuropeAid: 127054/C/SER/multi - Lot 11

Macroéconomie, Statistiques et Gestion des Finances
publiques
Plan d’Evolution du Système

d’Information (PESI) du Ministère
de l’Economie et des Finances
(MEF) au Bénin
Rapport final – version définitive
23 Août 2011
Rue de Clairvaux 40, bte 101 – B 1348 Louvain-la-Neuve – Tel +32 10 45 45 10 – Fax +32 10 45 40 99
E-mail [email protected] – Website www.ade.eu
" Ce rapport a été préparé par MM Marc
Rolland, Loïc Elies et Thierry Salmon avec
l'aide de l'Union européenne. Le contenu de
ce document relève de la seule
responsabilité de ADE et ne peut en aucun
cas être considéré comme reflétant la
position de l'Union européenne."
ELABORATION DU PLAN D’ÉVOLUTION DU SYSTÈME D’INFORMATION
DU MINISTÈRE DE L’ÉCONOMIE ET DES FINANCES AU BÉNIN ADE - ATC Consultants
Table des matières
ABREVIATIONS ...................................................................................................................... 7
TABLE DES ILLUSTRATIONS ................................................................................................... 8
1. INTRODUCTION .................................................................................................1
1.1 CONTEXTE GENERAL .......................................................................................................... 1
1.2. OBJET DE LA MISSION.......................................................................................................... 1
1.3. LES ENJEUX DU PLAN D’EVOLUTION ................................................................................ 3
2. DEROULEMENT ET METHODOLOGIE ............................................................... 5
2.1 METHODOLOGIE ................................................................................................................. 5
2.2 STRUCTURE RENCONTREES ................................................................................................ 6
2.3 PLANNING DE LA MISSION .................................................................................................. 8
2.4 ORGANISATION DU DOCUMENT ........................................................................................ 8
2.5 PORTAIL DU RAPPORT ....................................................................................................... 10
PARTIE A : ANALYSE DES BESOINS ET RECOMMANDATIONS................................................. 11
3. ORGANISATION ET RESSOURCES HUMAINES .................................................... 12
3.1 SITUATION OBSERVEE ....................................................................................................... 12
3.1.1 Une organisation déconcentrée ....................................................................................... 12
3.1.2 Des informaticiens d’un bon niveau technique mais insuffisamment
impliqués ............................................................................................................................. 14
3.1.3 Coordination insuffisante des actions informatiques ................................................... 15
3.1.4 Absence de référentiel qualité pour la gestion des projets informatiques ................. 16
3.2 BESOINS EXPRIMES ET CONSTATES ................................................................................. 17
3.3 AVIS DE LA MISSION ........................................................................................................... 18
3.3.1. Réorganisation de la DOI et des services informatiques ................................................ 18
3.3.2 Un management par projet............................................................................................... 21
3.3.3 Référentiel qualité .............................................................................................................. 22
3.3.4 Formation des agents ........................................................................................................ 24
4. APPLICATIONS INFORMATIQUES ......................................................................27
4.1.1 Absence de vision globale du SI ...................................................................................... 27
4.1.2. Automatisation insuffisante du SI ...................................................................................... 31
4.1.3 Absence de contrôle des données et de fiabilité des chiffres fournis ........................ 36
4.1.4 Une bonne appropriation des applications .................................................................... 37
4.1.5 Des logiciels « qui ne marchent pas ».............................................................................. 37
4.1.6 Les applications spécifiques privilégiées par rapport aux progiciels .......................... 39
4.1.7 Hétérogénéité des technologies informatiques des applications................................. 41
Scénario 1 « a minima » : consolidation du SI actuel ................................................................. 43
Rapport final – version définitive - Août 2011 Table des matières

Scénario 2 « raisonnablement ambitieux »: Intégration et centralisation du SI ...................... 44

Scénario 3 « innovant » : Externalisation du SI........................................................................... 44
Marche à suivre pour le choix du scénario .................................................................................. 45
Choix technologiques ..................................................................................................................... 45
Mise en œuvre d’un EAI / ESB puis éventuellement d’un Data Warehouse ........................ 46
Mise en œuvre d’un support (help desk et hotline) .................................................................... 47
5. SITES INTERNET ET INTRANET .......................................................................49
5.1.1 Présence sur le Web........................................................................................................... 49
5.1.2. Intranet ................................................................................................................................ 50
5.3.1 Fonctionnement et mise à jour du site Internet ............................................................ 50
5.3.2 Déploiement d’un Intranet ............................................................................................... 52
5.3.3 Identité visuelle et capitalisation des outils .................................................................... 53
6. PARC INFORMATIQUE ......................................................................................55
7. RESEAU INFORMATIQUE LOCAL ET ETENDU ...................................................63
7.1.1. Architecture ........................................................................................................................ 63
7.1.2 Configuration ..................................................................................................................... 66
7.1.3 Fonctionnement ................................................................................................................. 67
8. ENVIRONNEMENT ELECTRIQUE ..................................................................... 71
9. SECURITE .........................................................................................................75
PARTIE B : PLAN D’EVOLUTION DU SYSTEME D’INFORMATION (PESI) .............................79
1. COMPRENDRE LE PLAN D’EVOLUTION ............................................................ 81
2. LOGIQUE D’INTERVENTION DU PESI..............................................................83
3. PROJETS DU PESI ............................................................................................87
3.1 INTRODUCTION .................................................................................................................. 87
3.2 SYNTHESE DES PROJETS ET PLANIFICATION .................................................................. 89

3.3 PROJETS LIES A L’ORGANISATION ET AUX RESSOURCES HUMAINES ........................... 91

O1 : Réforme de la fonction informatique du MEF .................................................................. 92
O2 : Formation des informaticiens du MEF .............................................................................. 94
O3 : Elaboration du prochain SDI de GFP ................................................................................ 96
3.4 PROJETS LIES AUX APPLICATIONS .................................................................................... 97
A1 : Elaboration du dossier de conception général du SI de GFP .......................................... 98
A2 : Déploiement de l’application de gestion de la paie SunKWE. ...................................... 100
A3 : Amélioration de l'interface SIGFiP-ASTER et développement interface
ASTER-SICOPE ............................................................................................................. 101
A4 : Déployer Aster à la DGTCP-DCCE, dans les Recette-Perception, à la DGDDI
et DGID............................................................................................................................ 102
A5 : Elaboration du cahier des charges pour l'automatisation de la production du
TOFE. ............................................................................................................................... 103
A6 : Réalisation d'un système informatique mécanisant les procédures de passation
des marchés publics ......................................................................................................... 104
A7 : Création d’une base de données unique des agents de l’Etat ......................................... 107
A8 : Mise en œuvre d’un EAI / ESB puis d’un entrepôt de données (DW) ...................... 108
A9 : Mise en place d’une base de données pour la gestion des contribuables ..................... 109
A10 : Opérationnalisation de l'IFU au MEF et dans les autres administrations
(déploiement et extension de l'IFU).............................................................................. 110
A11 : Adaptation des logiciels de gestion des finances publiques à la nouvelle
nomenclature (ASTER, Interface SIGFiP-ASTER, Sunkwe). .................................. 111
A12 : Intégration de la nomenclature des pièces justificatives dans SIGFiP........................ 112
A13 : Développement d’une base de données exhaustive des dons et prêts et de leur
exécution ........................................................................................................................... 113
A14 : Traçabilité dans SIGFiP des dépenses financées sur ressources extérieures ............. 114
A15 : Définir une nouvelle architecture de transmission des données à la DGDDI.......... 115
A16 : Déployer Sydonia dans les postes/recettes de Douanes. ............................................. 116
A17 : Réaliser un répertoire des prix et l’actualiser .................................................................. 117
A18 : Acquisition d’un progiciel de gestion de projets ............................................................ 118
A19 : Acquisition d’un progiciel de gestion de courrier et archivage (GED) ...................... 119
A20 : Appui à la DGID : mise en place opérationnelle du SIGTAS..................................... 120
3.5 PROJETS LIES AUX SITES WEB ....................................................................................... 121
W1 : Refonte globale du site WEB institutionnel du MEF .................................................... 122
W2 : Extension et mise à jour du site web du MEF (textes juridiques) ................................ 124
W3 : Publication en ligne des rapports sur l’exécution budgétaire ........................................ 125
W4 : Création du sous-site WEB de la DGID sous le site global du MEF
www.finances.bj. .............................................................................................................. 126
W5 : Conception, réalisation et mise en exploitation du site web des marchés publics ..... 127
3.6 PROJETS LIES AU PARC INFORMATIQUE ........................................................................ 128
P1 : Création d’une salle informatique centralisée aux normes internationales ................... 129
P2 : Acquisition des équipements informatiques au profit des personnels de
l'administration centrale du Contrôle Financier .......................................................... 130
P3 : Acquisition d'équipements informatiques pour la DGTCP (Services centraux et
postes comptables) .......................................................................................................... 131
3.7 PROJETS LIES AU RESEAU INFORMATIQUE.................................................................... 132
I1 : Réalisation de l'interconnexion DGID / DGDDI / DGB / DGTCP ......................... 133

I2 : Mise en œuvre d'un système informatique de suivi des activités des composantes
à l’UGR.............................................................................................................................. 134
I3 : Réalisation du Backup de la station VSAT du Ministère de l'Economie et des
Finances............................................................................................................................. 135
I4 : Audit du réseau informatique du MEF et recommandations et mise en oeuvre .......... 136
3.8 PROJETS LIES A L’ALIMENTATION ELECTRIQUE .......................................................... 137
E1 : Réhabilitation et mise en production du réseau ondulé du MEF .................................. 138
E2 : Mise en place d’un local pour les onduleurs à la DGDDI ............................................. 139
E3 : Réalisation d’un audit électrique dans toutes les structures du MEF et mise en
œuvre ................................................................................................................................. 140
3.9 PROJETS LIES A LA SECURITE .......................................................................................... 141
S1 : AMOA pour la rédaction d’un plan de sécurité des systèmes d’information
(PSSI) ................................................................................................................................. 142
S2 : Audit des risques environnementaux des installations du MEF,
recommandations et mise en œuvre.............................................................................. 143
S3 : Sensibilisation des utilisateurs à la sécurité ........................................................................ 144
4. MISE EN ŒUVRE DES PROJETS........................................................................ 145
4.1 Gouvernance et Unité de Gestion ...................................................................................... 145
4.2 Mise à jour du PESI .............................................................................................................. 145
4.3 Planification, priorités........................................................................................................... 146
4.4 Financement........................................................................................................................... 146
PARTIE C : ANNEXES ......................................................................................................... 149
1. CONFIGURATIONS TYPES DES MATERIELS...................................................... 151
1.1 POSTES DE TRAVAIL......................................................................................................... 151
1.1.1 Ordinateur de bureau ...................................................................................................... 151
1.1.2 Imprimantes...................................................................................................................... 151
1.1.3 Onduleurs ......................................................................................................................... 152
1.2 SERVEURS ET SYSTEMES DE SAUVEGARDE ................................................................... 152
1.2.1 Serveurs ............................................................................................................................. 152
1.2.2 Systèmes de sauvegarde (NAS) ...................................................................................... 152
1.2.3. Systèmes de sauvegarde (bandes) ..................................................................................... 153
2. LISTE DES APPLICATIONS INFORMATIQUES ................................................... 155
3. APPELS D’OFFRES POUR CF, DGTCP, DGID ET UGR .................................. 157
3.1 OBJET................................................................................................................................. 157
3.2 OBSERVATIONS GENERALES .......................................................................................... 157
3.3 APPEL D’OFFRE POUR L’UGR ........................................................................................ 158
3.3.1 Matériel bureautique ........................................................................................................ 158
3.3.2 Matériel de communication et réseau ........................................................................... 158
3.3.3 Matériel électrique ............................................................................................................ 158
3.4 APPEL D’OFFRES POUR LA DGID .................................................................................. 159
3.5 APPEL D’OFFRES POUR CF ET DGTCP ........................................................................ 159
3.6 CONCLUSION .................................................................................................................... 159

Abréviations
BCEAO Banque Centrale des Etats de l'Afrique de l'Ouest
C/FED Cellule d'Appui à l'ordonnateur national du Fonds Européen de
Développement
CAA Caisse Autonome d'Amortissement
CENAFOC Centre National de Formation Comptable
CF Contrôle Financier
CIPE Centre des Impôts pour les Petites Entreprises
CIME Centre des Impôts pour les Moyennes Entreprises
CSPEF Cellule de Suivi des Programmes Economiques et Financiers
CSSFD Cellule de Surveillance des Structures Financières Décentralisées
DA Direction des Assurances
DGAE Direction Générale des Affaires Economiques
DGB Direction Générale du Budget
DGCPE Direction de Gestion et de Contrôle du Portefeuille de l'Etat
DGDDl Direction Générale des Douanes et Droits Indirects
DGID Direction Générale des Impôts et des Domaines
DGML Direction Générale du Matériel et de la Logistique
DGTCP Direction Générale du Trésor et de la Comptabilité Publique
DIR Direction de l'Intégration Régionale
DNCMP Direction Nationale de Contrôle des Marchés Publics
DOI Direction de l’Organisation et de l’Informatique
DPC Direction de la Prévision et de la Conjoncture
DPE Direction de la Promotion Economique
DPP Direction de la Programmation et de la Prospective
DRFM Direction des Ressources Financières et du Matériel
DRH Direction des Ressources Humaines
EAI Enterprise Application Integration
FAGACE Fonds Africain de Garantie et de Coopération Economique
IGF Inspection Générale des Finances
LNB Loterie Nationale du Bénin
MR/BOAD Mission Résidente de la Banque Ouest-Africaine de Développement
SA Secrétariat Administratif
SGM Secrétariat Général du Ministère
SGBD Système de Gestion de Base de Données
SI Système d’Information
SRU Service des Relations avec les Usagers
TOFE Tableau des Opérations Financières de l’Etat
Rapport final – version définitive - Août 2011 Abréviations

Table des illustrations
Figure 1 : Organigramme actuel du Ministère ......................................................................................... 6
Figure 2 : Structures rencontrées et calendrier des RDV ....................................................................... 7
Figure 3 : Nb d'informaticiens par structure .......................................................................................... 13
Figure 4 : Proposition d'organisation de la future DOI ....................................................................... 19
Figure 5 : proposition d'organisation des services informatiques des directions techniques.......... 20
Figure 6 : Cartographie fonctionnelle possible d'un MEF .................................................................. 30
Figure 7 : « Cartographie applicative » partielle liée aux processus métier GFP............................... 32
Figure 8 : cartographie applicative actuelle pour le processus de traitement d'un titre ................... 33
Figure 9 : Exemple d'optimisation de la cartographie applicative pour le paiement d’un titre ...... 33
Figure 10 : Parc informatique constaté ................................................................................................... 55
Figure 11 : Copie d'écran d'un logiciel de gestion de parc informatique ........................................... 60
Figure 12 : Logique Globale d’Intervention (WBS) .............................................................................. 83
Figure 13 : Modèle de fiche de projet déjà programmé ....................................................................... 87
Figure 14 : Modèle de fiche des nouveaux projets ................................................................................ 88
1. Introduction
1.1 Contexte général
Le Ministère de l’Economie et des Finances (MEF) a pour mission de proposer et de

mettre en œuvre la politique économique et financière du gouvernement de la république
du Bénin. L’activité du MEF est régie par le Décret n° 2008-111 du 12 mars 2008 portant
attributions, organisation et fonctionnement du Ministère de l’Economie et des Finances.
Le MEF s'est doté depuis de nombreuses années de moyens informatiques importants.

Une Direction de l'Organisation et de l'Informatique a été mise en place dès 2002 avec
pour mission de déployer la politique informatique du MEF. Un Schéma Directeur
Informatique a été réalisé en 2004. Ce premier SDI a permis d'obtenir des résultats
significatifs (réseaux locaux, interconnexion des sites, applications de gestion majeures).
En 2007, conformément au déroulement de tout SDI, un Plan d'évolution a été réalisé
mais, par manque de moyens financiers en pleine crise internationale, sa mise en œuvre n'a
pas pu avoir lieu.
En 2009 le gouvernement a lancé un Plan d'Actions pour l'Amélioration de la gestion des

Finances Publiques soutenu par les bailleurs. Ce Plan d’Actions est appuyé en partie par
l’Union européenne à travers le Programme d’Appui Conjoint à la Bonne Gouvernance en
matière de Finances Publiques et de Statistiques (PAC). Le Plan d'Actions comporte
plusieurs composantes dont une concerne le Système d'Information du MEF. La DOI en
collaboration avec l'Unité de Gestion de la Réforme (UGR), appuyé par l'Union
Européenne a lancé une consultation en vue d'étudier un Plan d'Evolution du Système
d'Information 2011.
C'est dans ce contexte qu’ADE s’est vu confier la mission d’assistance technique de court
terme pour l’élaboration du Plan d’Evolution du Système d’Information (PESI) du MEF
du Bénin.
La mission a débuté en avril 2011, le rapport final devant être approuvé en août 2011.
1.2. Objet de la mission
La mission a pour but de concevoir un Plan d’Evolution du Système d’Information (PESI)

du Ministère de l’Economie et des Finances du Bénin. Ce plan doit s’appuyer sur les études
précédemment réalisées par les services du Ministère (notamment la Direction de
l’Organisation et de l’Informatique) : le plan stratégique informatique de 2004 et le plan
d’évolution du système d’information de 2007. D’autres documents ont été fournis à la
mission afin de prendre pleinement connaissance des différents projets en cours dont ceux
financés par certains partenaires.
Le Schéma Directeur Informatique établit pour une période généralement de 5-7 ans une
stratégie de développement qui soutient la vision stratégique du Ministère. Un plan initial
Rapport final – version définitive - Août 2011 Page 1

ELABORATION DU PLAN D’ÉVOLUTION
OLUTION DU SYSTÈME D’INFORMATION
DU MINISTÈRE DE L’ÉCONOMIE ET DES FINANCES
FINA AU BÉNIN ADE - ATC Consultants
est intégré au SDI et concerne la première période de 2-3

2 ans.
ns. Au bout de cette période, un
plan d'évolution s'avère nécessaire pour prendre en compte les changements, tant internes
qu'externes, intervenus durant la première période. Ce plan se veut donc une aide à la prise
de décision pour mettre en œuvre des mesures
mesures de progrès. Le Plan Initial et les Plans
d'Evolution ont une structure identique et se suivent dans le temps de mise en œuvre d’un
SDI.
Les niveaux de décisions sont différents. Le SDI est réfléchi, conçu et validé par les plus
hautes instances de la structure. Il se situe à un niveau clairement stratégique et concerne
tous les aspects, fonctionnels, organisationnels et techniques. Puis vient un découpage en
phases plus opérationnelles dont la mise en œuvre est confiée aux responsables
organisationnels.
s. C’est là que le plan initial et les plans d’évolution se situent.

Dans ce cadre, la mission va réaliser les actions suivantes dans le temps qui lui est imparti :
• Etat de l’existant et recueil des besoins
• Etude des données relevées
• Elaboration du plan d’évolution
Elles sont décrites dans le chapitre suivant.
1.3. Les enjeux du plan d’évolution
Des opérations d'informatisation, toujours plus nombreuses, sont lancées et le recours à

des solutions techniques ambitieuses tend à se généraliser touchant tous les domaines du
MEF : moyens de télécommunications (Cotonou et autres villes) équipements en micro-
ordinateurs portables, serveurs et bases de données de grande capacité.
L'attention des hauts responsables se porte sur des budgets informatiques en constante
augmentation, mais pas toujours en rapport avec la qualité des résultats obtenus. Accroître
l'efficacité des projets et obtenir un réel retour sur investissement sont aujourd'hui un
objectif cardinal.
La planification des projets d'informatisation est une activité délicate et la qualité du résultat
dépend de la capacité du MEF à maîtriser le savoir-faire nécessaire. Le premier SDI (2004)
a permis de poser les bonnes bases de la construction du SI. Le premier Plan d'évolution
du SI (PESI 2007) a montré les capacités du MEF à identifier les besoins mais sa mise en
œuvre n'a pas été possible par manque de moyens.
L'enjeu essentiel de la mission sera donc de permettre au MEF d'améliorer le traitement de

l'information et par là même les résultats obtenus, grâce au Plan d'Evolution du SI 2011.
Une information fiable disponible en temps et en heure permettra d'obtenir de
manière régulière les Tableaux de Bord essentiels au pilotage du MEF. Un Tableau de Bord
produit dans les temps et, surtout, obtenu comme sous-produit automatisé du SI
(provenant donc des principales applications) est le meilleur indicateur de l'état de santé du
SI de l'organisme.
Mais le PESI 2011 est également porteur d'un autre enjeu : préparer les conditions
nécessaires au lancement d'une opération d'Urbanisation du SI.
Le terme d’urbanisation est une analogie avec le domaine de l’organisation d’une ville. Dans
cette vision, le SI est découpé en unités, ou modules, de plus en plus petits et spécialisés.
On parlera donc de zones, quartiers ou blocs (fonctionnels). Des zones d’échange
d’informations se dessinent entre chaque module afin de les découpler et de leur permettre
d’évoluer séparément tout en conservant leur capacité à interagir avec le reste du système.
Nous voyons se dessiner dans cette description les mécanismes d’EAI dont nous parlerons
plus loin dans ce document.
Ainsi l'urbanisation vise à (i) favoriser l'évolutivité du SI, sa pérennité et (ii) renforcer sa
capacité à intégrer des solutions hétérogènes (progiciels, applications issues du passé,
applications génériques telles que SYDONIA, plateformes techniques).

De cette manière le SI se trouve organisé en BLOCS FONCTIONNELS déconnectés des

différents changements, à caractère « politique », intervenants dans l'organisation du MEF :
ajout ou suppression d'un service, d'une entité, rattachement de la fonction Solde au
Budget ou au Trésor par exemple.
Le PESI 2011 doit donc guider le MEF à mettre son SI en ordre pour pouvoir engager une
étude longue et approfondie débouchant sur la conception d’un SI totalement urbanisé et
facilement évolutif.

2. Déroulement et méthodologie
2.1 Méthodologie
La méthodologie adoptée par la mission est décomposée en quatre étapes principales

regroupées en trois périodes :
- période de terrain
o étude du fonds documentaire mis à disposition et identification des
structures à consulter
o entretiens au sein des structures identifiées
- période « home based »
o analyse des informations recueillies et préparation du rapport final
- Atelier final de restitution du PESI
o Présentation du PESI par la mission et prise en compte d’éventuelles
remarques
La période de terrain s’est déroulée du 04 au 29 avril 2011 à Cotonou et du 16 au 20 mai

2011. Un second déplacement a en effet été nécessaire en raison de l’actualité sociale qui
prévalait en avril et qui a rendu difficile la collecte exhaustive des informations.
Lors de la première semaine, la DOI a fourni au chef de mission un ensemble de

documents qui ont permis d’appréhender le contexte du Ministère1 :
- le schéma directeur informatique 2004
- le plan d’évolution du système d’information 2007
- le plan d’évolution des finances publiques 2009
- le devis programme n°1 de la DUE
- l’audit du système informatique de la Direction Générale des Impôts 2011
- le schéma directeur de la Direction Générale des Impôts 2011
Ces documents ont été analysés et ont servis à dresser la liste des structures du Ministère à
visiter ainsi que les sujets à aborder. Les membres de la mission ont utilisé la totalité de leur
séjour à Cotonou pour réaliser les entretiens programmés et dresser des notes de synthèse.
C’est durant cette phase que l’appui de la DOI a été déterminant pour l’organisation des
rendez-vous et la collecte d’un certain nombre d’informations techniques. Une première
restitution a été effectuée le 29 avril en présence de toutes les parties concernées (DUE,
UGR, DOI et quelques directions générales).
La seconde phase, engagée au retour de la mission en France, consiste à analyser les notes
de synthèse produites à la suite des entretiens et à en dégager les grandes lignes pour
rédiger le présent rapport et le PESI proprement dit.
La troisième et dernière phase consiste à présenter, dans une démarche participative, le

PESI au MEF lors d’un atelier de quelques jours à Cotonou. L’objectif est alors de finaliser
1 L’ensemble de ces documents peut être consulté sur le portail dont l’URL est fournie plus loin

en temps réel et de façon participative le PESI, par une recherche permanente du meilleurs
compromis possible entre les parties, et ce afin d’obtenir in fine un PESI qui soit totalement
approprié par les parties prenantes. Un PESI qui ne reflèterait que l’avis de la mission
n’aurait en effet que peu de chances d’être
d’être mis en œuvre une fois la mission terminée.
2.2 Structure rencontrées
L’organigramme du Ministère des Finances,

Finances donné ci-dessous,
dessous, présente les différentes
structures qui le composent.
Figure 1 : Organigramme actuel du Ministère
L’ensemble des rendez-vous

vous tenus est présenté dans le tableau ci-dessous
ci dessous (carrés bleus).
Les structures surlignées n’ont par contre pas pa pu être visitées, soit en raison de
l’indisponibilité des correspondants, soit par manque de temps, soit encore parce que
certaines de ces structures n’étaient pas d’importance forte pour l’étude ou étaient tout
simplement en dehors du champ considéré.
On remarquera aussi que seul la ville de Porto Novo a été visité comme exemple de
structures en régions, cela pour des raisons évidentes d’éloignement et de temps limité.

Figure 2 : Structures rencontrées et calendrier des RDV

2.3 Planning de la mission
Comme énoncée plus haut, la mission s’est déroulée en trois grandes périodes :
- 4-29 avril 2011, 16-17
17 mai 2011 sur le terrain
- mai et juin au siège pour la rédaction du rapport final
- 23 Août 2011 à Cotonou pour la restitution participative finale.
Les étapes de validation et de correction du rapport se déroulent successivement durant les

mois de juin à août 2011 pour aboutir à un atelier final de restitution
restitution qui s’est
s tenu à
Cotonou le 23 août 2011 en présence des experts, de la DUE de l’UGR et de toutes les
parties concernées du MEF.
2.4 Organisation du document
Le présent document est articulé en trois parties. Passés les chapitres d’introduction
d’introductio et de
présentation de la mission, la première partie présente le résultat de la collecte
d’information effectuée lors des phases de terrain. Chacun des 7 grands thèmes suivant est
abordé avec un exposé de la situation constatée et des besoins exprimés, suivi
suivi d’un avis que
la mission porte sur ces situations :
1. Organisation et Ressources Humaines,
2. Applications
tions informatiques,
3. Sites Internet et intranet
4. Parc informatique,
5. Réseaux informatiques,
informatiques
6. Environnement électrique,
7. Sécurité
Contrairement à ce qui avait it été fait pour le SDI 2004 et le PESI 2007, nous n’avons pas
voulu présenter le diagnostic de l’existant et les propositions du PESI 2011 par Direction
du Ministère.
inistère. En effet, nous défendons tout au long du document l’idée d’apporter
davantage de transversalité
rsalité à la fonction informatique qui est pour l’instant
l’instan beaucoup trop
cloisonnée par Direction. Rédiger le PESI par Direction
D ction aurait donc été un contresens
contre par
rapport à notre idée directrice. Les Directions ne doivent donc pas chercher dans le présent
document
ocument une analyse spécifique de leur situation, mais ont au contraire la possibilité
d’évaluer elle-même
même leur propre situation au regard de la situation globale décrite dans le

document. Ceci étant dit, nous avons trouvé une assez bonne homogénéité dans les
situations des structures, et la plupart des situations décrites s’appliquent à toutes les
Directions.
La seconde partie découle de l’analyse de la situation observée et des besoins exprimés ou

constatés. Elle présente la logique du plan d’évolution du système d’information et son
cadre d’intervention. Nous donnons notre avis sur un ensemble de projets déjà identifiés et
figurant dans le devis programme ou le « plan d’action pour l’amélioration de la gestion des
Finances Publiques » et nous proposons une liste de projets importants que nous pensons
devoir être engagés sans délai afin de préparer le SI du Ministère à son évolution à plus
long terme.
Enfin la troisième et dernière partie regroupe les annexes telles que les configurations
standard préconisées ou la liste des applications actuelles qui nous ont été communiquées.

2.5 Portail du rapport
Au vu du nombre de documents fournis, collectés ou produits au cours de cette mission,

nous avons pensé utile de créer un portail sur lequel ces informations sont mises à
disposition.
Il est accessible à l’adresse http://e-sud.fr/client/PESI_Benin/PESI_Benin.php et permet

de télécharger l’ensemble de la documentation électronique.
Nous ne pouvons que vivement recommander à la DOI de récupérer ce portail pour

l’héberger sur son propre site, dans une partie privée (non accessible au public). Les
consultants tiennent à disposition de la DOI tous les sources de ce portail qui pourra être
remis lors de la réunion de restitution.
Ce portail contient notamment le fond documentaire, les fiches d’enquêtes réalisées auprès
des structures, et les documents produits par la mission.

Partie A :
Analyse des besoins et
recommandations
3. Organisation et ressources
humaines
Résumé : L’organisation mise en œuvre par le Ministère pour gérer son système d’information est
déconcentrée, c'est-à-dire que chaque direction possède son propre service informatique. Les services
informatiques sont très autonomes et ne dépendent hiérarchiquement que de leur Direction. Les Directions
qui n’ont pas de service informatique sont appuyées par la DOI.
La DOI tente de coordonner l’ensemble des services informatiques mais aucun outil formel de coordination
n’a été mis en œuvre. La DOI et la plupart des services informatiques déplorent un manque de partage
d’informations. L’organisation globale mise en œuvre ne permet ainsi pas un développement cohérent du SI
global du MEF.
Le personnel informatique au sein du Ministère est nombreux, dont une grande part d’ingénieurs.
Globalement le niveau de formation initiale est bon. La formation continue a été le plus souvent faible
malgré l’évolution rapide des technologies en la matière.
Cette remarquable compétence informatique disponible au MEF pourra, une fois mieux organisée, produire
et piloter le système informatique du Ministère qui permettra de fournir aux hauts responsables des
informations fiables dans les meilleurs délais.
3.1 Situation observée
3.1.1 Une organisation déconcentrée
Le Ministère de l’Economie et des Finances compte une trentaine de structures (voir Figure
1 : Organigramme actuel du Ministère2 ) et une centaine de services. Les informaticiens du
Ministère se retrouvent répartis dans des services de la plupart des structures et ils
dépendent hiérarchiquement de leur propre structure.
Les structures qui n’ont pas leur propre informaticien (par exemple le Cabinet, la DRFM, la
DGML, …) sont appuyées par la DOI. En revanche, les structures qui en sont dotées
(DGB, DGDDI, DGTCP, DGID, etc.) développent leurs programmes informatiques en
toute autonomie, c'est-à-dire que chaque service informatique du MEF est organisé pour
réaliser tous types d’activités informatiques : développement de logiciel, maintenance
corrective et évolutive, administration de serveurs et de bases de données, déploiement de
réseau, support informatique, achats de matériel, etc.
2 Pour davantage de détails sur les structures, consulter les résultats des entretiens sur le portail, et en particulier la page
http://www.e-sud.fr/client/PESI_Benin/donneesPESI.htm

Figure 3 : Nb d'informaticiens par structure

Bien que la DOI, rattachée au Informaticiens
Secrétariat Général, soit théoriquement Structure cadres techniciens
Ministère 46 93
une direction transversale qui a pour Services rattachés au ministre 1 7
mandat de coordonner toutes les Cabinet 0 0
activités informatiques du MEF, nous Secrétariat général 45 86
Secrétaire général 0
avons constaté dans les faits que Protocole
beaucoup de services informatiques SRU
DOI 5 21
ont pris l’habitude de fonctionner de CPMP 0 1
façon autonome sans en référer à la SPD
SA
DOI (comme nous l’expliquons Directions centrales
chapitre 3.1.3, les causes sont DPP 0 0
DRFM 0 0
multipkes). La DOI ignore par DRH 0 1
conséquent de nombreuses activités Directions générales ou techniques
informatiques réalisées par les services DGB 6 23
DGID 4 11
du MEF. DGDDI 2 19
Par ailleurs, en regardant DGTCP 20 4
DGML 0 1
l’organigramme du MEF on se rend DGAE 0 0
compte que la DOI n’est DNMP 1 2
Organismes sous tutelle
hiérarchiquement pas en mesure de CENAFOC 1 1
coordonner les services informatiques LNB 5 0
BCEAO
des Directions qui dépendent d’autres CAA 1 2
Directions Générales. D/PC-CIC 0
Bien sûr, en théorie la DOI pourrait MR/BOAD
FAGACE
tout de même coordonner les activités Cadre = personne à responsabilité d’encadrement (généralement
informatiques mais sans positionnement ingénieur). Technicien = personne sous la responsabilité d’un cadre
hiérarchique officiel sur les services, cette coordination ne sera possible que selon le bon
vouloir des Directions Générales des structures, et de fait, dans la pratique, cette
coordination ne se fait pas.
L’organisation actuelle, déconcentrée, offre l’avantage d’une meilleure réactivité des
informaticiens en cas de besoin. En effet, en l’absence d’organisation bien définie et de
volonté politique affirmée, mais aussi en l’absence d’une bonne appréciation /
reconnaissance de la DOI par ses pairs, chaque structure va spontanément chercher à
recruter ses propres informaticiens de façon à obtenir un support informatique interne qui
sera immédiatement à son entière disposition. En disposant de ses propres informaticiens,
une structure peut également lancer à sa guise des projets de développement de logiciels sur
mesure en fonction de ses besoins.
Cependant, les structures sollicitent différents bailleurs de fonds pour financer leurs projets
« internes » sans concertation préalable, ce qui devient un inconvénient important. En effet
les bailleurs de fonds n’ont pas établi de charte commune pour coordonner leurs
interventions dans le domaine informatique au niveau du MEF3. On se retrouve ainsi par
exemple avec plusieurs projets relativement proches en terme d’objectif (exemple :
« construction d’un data center » et « construction d’un centre de calcul », ou « mise en
œuvre d’une VSAT » et « mise en réseau des postes de travail » ou « schéma directeur de la
DGID » et « étude de faisabilité de la DNCMP ») et pour lesquels différents bailleurs de
fonds ont été sollicités. Pris indépendamment les uns des autres, ces projets peuvent se
justifier, mais analysés de manière globale, des incohérences apparaissent. Le fait de ne pas
coordonner les activités informatiques est une source de gaspillage important de
3 Il existe par exemple une charte commune de tous les bailleurs de fonds du MALI dans le secteur du développement
rural, qui, de notre expérience, donne d’excellents résultats.

moyens financiers, d’inefficience (c.à.d que le rapport : résultat / coût est faible) voire
même d’inefficacité (c.à.d que le rapport : résultat / attentes est faible) quand les projets
sont contradictoires.
Cette organisation déconcentrée comporte de nombreux autres inconvénients :
• Il n’y a quasiment aucune mutualisation des logiciels métiers. On trouve ainsi
plusieurs logiciels de « gestion des ressources humaines4 » au sein du MEF, à
chaque fois développé en interne par les informaticiens de la structure. Ce qui est
vrai pour les logiciels est également vrai pour les méthodes et outils
• Les structures ne disposent pas d’une masse critique d’ingénieurs et techniciens
suffisante pour s’organiser en véritable direction informatique et spécialiser les
informaticiens. Par conséquent, les informaticiens doivent souvent occuper
plusieurs fonctions (par exemple un informaticien peut être à la fois « développeur
d’application », « administrateur des bases de données » et « dépanneur auprès des
utilisateurs »), sans qu’ils n’aient le temps de se perfectionner dans une fonction.
Globalement le niveau de service offert par des agents dispersés assurant plusieurs
fonctions est moins bon que celui offert par ces mêmes agents mais regroupés et
spécialisés
• Le MEF dans sa globalité n’est pas organisé pour capitaliser ses très nombreuses
expériences en matière de développement d’applications, de mise en œuvre de
réseau ou de méthodes de maintenance évolutive et corrective. Il ne peut
promouvoir correctement en son sein les bonnes pratiques (référentiels sur la
gestion des projets ou de la qualité, normes sur les outils de développement à
privilégier, spécifications techniques des ordinateurs et serveurs lors des appels
d’offres, etc.) faute d’avoir les moyens de les élaborer. .
• Le cloisonnement hiérarchique des informaticiens et leur appartenance à une
structure unique ne favorise pas leur mobilité au sein du MEF. Elle est pourtant
fortement souhaitée pour partager les expériences et le savoir et ainsi favoriser
l’innovation et les bonnes pratiques, mais son absence constitue un facteur de
démotivation du personnel. Il est en effet fréquent de rencontrer des informaticiens
ayant passé plusieurs années (et même pour quelques uns quelques décennies) dans
la même structure sans changement ni de fonction, ni de service, ni même de lieu.
De plus le fonctionnement en mode administratif (par opposition au mode projet)
engendre des habitudes fortes et une routine quotidienne source de désintérêt
croissant pour la fonction occupée.
3.1.2 Des informaticiens d’un bon niveau technique mais insuffisamment

impliqués
Le Ministère de l’Economie et des Finances compte environ 138 informaticiens, cadres et

non cadres (voir Figure 3 : Nb d'informaticiens par structure, voir le portail pour plus de détails).
S’il est difficile d’évaluer individuellement leur niveau de performance (ce qui n’était
d’ailleurs pas le rôle de la mission), nous pouvons constater que, globalement, les
informaticiens du MEF sont d’un bon niveau. Il semble en effet que ce Ministère soit
suffisamment attractif pour attirer les meilleurs informaticiens du Pays, comparé à d’autres
Ministères ou administrations publiques, en raison des programmes informatiques
ambitieux qui y sont développés.
4 MIR, GESPER, SIGRH, etc.

Un bon nombre d’entre eux continue de bénéficier de formations professionnelles, même

si, comme dans toute entreprise ou administration en général, les formations sont jugées
trop peu nombreuses. L’auto-formation sur les aspects techniques est souvent la norme
chez les informaticiens du monde entier, les sites web d’information et de formation étant
très nombreux sur le Net. Nous avons constaté que cette pratique de l’auto-formation n’est
cependant pas encore tout à fait entrée dans les habitudes de tous les informaticiens du
MEF, et beaucoup préfèrent systématiquement bénéficier d’une formation sanctionnée par
un diplôme ou une attestation de formation. Cela s’explique sans doute par le caractère
prépondérant du diplôme sur l’expérience en matières d’avancement de carrière et de
rémunération d’un fonctionnaire (cela était d’ailleurs la règle il y a quelques décennies en
Europe, mais aujourd’hui la tendance dans les pays occidentaux est de privilégier
l’évaluation annuelle des résultats de l’agent plutôt que ses diplômes pour l’avancement de
sa carrière. Nous avons eu l’occasion de mettre en œuvre cette pratique dans un Office
publique au Mali, ce qui a très bien fonctionné à petite échelle. Le MEF pourrait
s’intéresser à cet aspect de la GRH, qui dépasse cependant le cadre strict de la présente
étude).
Si l’implication des informaticiens tient à l’intérêt des projets sur lesquels ils sont amenés à
travailler, le niveau de leur rémunération n’en demeure pas moins un facteur important. En
ce sens, négliger ce dernier aspect fait courir le risque de voir les informaticiens les plus
talentueux développer une activité professionnelle annexe de consultant, sachant que cette
activité peut devenir prépondérante.
Potentiellement, la totalité des informaticiens du MEF représente une capacité
exceptionnelle dans le domaine informatique pour le Bénin, bien supérieure à la plupart des
autres administrations et de n’importe quelle société informatique du pays. La gestion
informatique du MEF devrait ainsi devenir un modèle au Bénin, tant sur le plan technique
qu’organisationnel. C’est le défi que nous proposons plus loin.
3.1.3 Coordination insuffisante des actions informatiques
Comme nous l’avons évoqué précédemment, les services informatiques du MEF sont
déconcentrés. Cette organisation pourrait se justifier si la DOI jouait pleinement son rôle
de coordination des actions informatiques. Ce n’est malheureusement pas le cas.
Le mandat de la DOI est, entre autres :
1. d’élaborer le plan stratégique,
2. de manager les projets S.I, dans une démarche projet, en collaboration avec les
maîtrises d’ouvrage métiers,
3. de définir la politique Qualité et les niveaux d’engagement de service.
La DOI remplit son premier mandat : elle a élaboré un Schéma Directeur Informatique
(SDI) en 2004 et un Plan d’Evolution du Système d’Information (PESI) en 2007, mais bien
que quelques actions du SDI 2004 aient été mises en œuvre (ex : réalisation de réseaux
locaux, interconnexion départementale) aucune des activités recommandées dans ces
documents n’a malheureusement pu être financée. Il faut en déduire que les documents
stratégiques de la DOI ne sont pas reconnus par le reste de l’administration : la DOI
manque de reconnaissance par ses pairs.
Pour le second mandat, la DOI n’assure pas son rôle de « management des projets SI », ou
plus simplement de coordination. Pour illustrer cela, citons à titre d’exemple que, la DOI
n’a pas été en mesure de fournir à la mission la liste des applications en cours d’utilisation

au MEF, ni de dresser la liste des projets en cours, ni de présenter sa politique de qualité, ni

de tenir à jour la liste des informaticiens du MEF, etc.
Concernant le troisième mandat, il n’y a pas, à notre connaissance, de politique de gestion
de la qualité.
La mission n’a pas cherché à connaître
conna tre les causes profondes de ces différentes lacunes,
parce qu’elles sont naturellement multiples, et surtout parce qu’il est difficile de discerner
les causes des conséquences. Par exemple, si la DOI ne dresse pas la liste des projets, alors
la DOI ne peut communiquer (via site intranet ou autre) sur les projets, alors les structures
n’ont pas connaissance des autres
autre projets, alors les
structures ne pensent pas à informer la DOI lors
du lancement d’un nouveau projet, alors la DOI
ne peut dresser la liste des projets. Et le cercle
vicieux se referme.
Quelle est la cause ? Quelle est la conséquence ?
Nous pourrions établir le même cercle vicieux en
ce qui concerne les référentiels, les formations, la
gestion de la qualité, la gestion des compétences,
etc.
Pour « casser » tous ces cercles vicieux, il faut
• changer les habitudes,
• informer les décideurs de la situation et ces décideurs doivent se saisir de ces questions
et demander à ce qu’un point soit fait régulièrement,
• insuffler de nouvelles idées et innover,
• trouver les mécanismes d’incitation et de sanction pour
pour que les nouvelles procédures
soient respectées.
Il n’existe pas, à notre connaissance, d’organe formel de coordination pour le pilotage du
S.I. du MEF, tel qu’un comité de pilotage regroupant les responsables informatiques des
différentes directions. Pourtant
ourtant la communication formelle est la base de la coordination. Il
n’existe pas d’outil de suivi ni d’espace de communication commun sur l’Intranet. Il
n’existe pas d’Intranet.
Tout ceci dénote une insuffisance de coordination.
Notons tout de même quelques
quelques contre exemples, trop peu nombreux, de collaboration
entre directions sur des activités informatiques. SUNKWE est le (futur) logiciel de gestion
de la solde qui doit remplacer à terme SDL7. Il est le fruit d’une collaboration entre la
DGB, la DGTCP et laa DOI en mode projet. Il semble que le développement proprement
dit du logiciel se soit bien déroulé ; le déploiement (c'est-à-diredire l’installation du logiciel chez
les utilisateurs, la formation, et in fine l’utilisation effective du nouveau logiciel) en revanche
n’est toujours pas un succès.
D’autres activités telles que le développement de certaines interfaces a pu se faire en
impliquant 2 Directions. Mais les « négociations » se sont révélées difficiles, les Directions
D
étant réticentes à donner accès à « leur » bases de données. Par conséquent les quelques
interfaces développées sont
nt des transferts de fichiers textes qui requiert des interventions
manuelles et volontaires pour être activées. Ce sont des interfaces « fragiles ».
3.1.4 Absence de référentiel qualité pour la gestion des projets

informatiques

Nous n’avons nulle part trouvé de service qui utilise des méthodes formalisées de gestion
de projets ou de gestion de la qualité. L’absence de référentiel commun ne favorise pas
l’émergence d’une « culture » commune dans la gestion des projets informatiques. Et puis
comment les services informatiques font-ils aujourd’hui pour s’assurer de la qualité des
outils produits ? En l’absence de méthode formalisée et d’outils standardisés, les services
informatiques peuvent-ils évaluer s’ils réalisent leur maintenance évolutive et corrective au
meilleur coût ?
Nous n’avons pas trouvé non plus de méthode formalisée de réalisation des projets, ce qui
ne veut pas dire que les services informatiques réalisent leurs projets sans aucune méthode,
bien au contraire, mais que les méthodes de réalisation sont pas ou peu formalisées, ce qui
ne favorise pas l’émergence de méthode commune et éprouvée.
Par exemple, la DRFM a demandé en août 2010 à la DOI de développer un module de
gestion des immobilisations et amortissements dans le logiciel SISFOM. Un cahier des
charges a bien été élaboré, un comité a même été mis en œuvre par une note de service, un
chronogramme a été élaboré. Les ingrédients de base pour fonctionner en « mode projet »
sont donc bien réunis, et puis les informaticiens connaissent bien la gestion en mode projet,
en théorie et en pratique. Cependant, l’étude de ces documents de projet montre que les
modèles de documents utilisés peuvent être améliorés, et doivent être uniformisés. Par
exemple, il est préférable de bien distinguer dans les documents l’expression des besoins, le
cahier des charges fonctionnels, le cahier des charges techniques, les besoins non
fonctionnels (matériel, ressources, etc.), le document de suivi et pilotage de projet, le
dossier de recette, le planning, le budget nécessaire, etc. La normalisation de ces documents
permettra à terme de mieux comparer et évaluer les projets, et de mieux maitriser la gestion
du projet par la suite.
Les cadres de la DOI se sont organisés pour développer des applications selon un
processus qui va dans le sens du mode projet visé : 4 groupes sont formés pour réaliser les
études, les développements, la recette et la documentation. Ce noyau d’organisation doit
être utilisé comme base de la mise en place d’une véritable organisation en mode projet.
Notons enfin l’absence d’un support organisé de la part de la DOI une fois les logiciels mis
en production. Cela ne signifie pas que la DOI n’assure pas de support, au contraire. Mais il
n’existe pas de processus de gestion de la fonction support, ni d’outil de help desk ou hot
line, ni même une cellule « support » au sein du MEF
Tout cela laisse une impression globale d’une gestion trop archaïque de la fonction
informatique au MEF.
3.2 Besoins exprimés et constatés
Les besoins exprimés en termes d’organisation sont faibles. Les personnes interviewées ont
surtout exprimé des demandes de formation. Nous ne recensons pas ici toutes les
formations demandées, qui, prises séparément sont pertinentes. Mais la formation de 138
informaticiens ne doit pas se programmer de façon individuelle, ni pour des besoins ou
intérêts personnels. Une formation doit permettre à un agent de mieux réaliser la mission
qui lui est confiée, ou de préparer l’agent à assumer de nouvelles fonctions. Il faut donc au
préalable définir les attributions actuelles ou futures de chacun selon la place occupée dans
l’organigramme. Un programme de formation ambitieux doit être prévu au MEF pour les
informaticiens, mais il faut au préalable réorganiser la fonction informatique du MEF.

Le DOI a expressément demandé que la mission fasse des recommandations sur la

nouvelle organisation de la DOI mais aussi sur la gouvernance du SI. Le DOI se préoccupe
notamment que tout soit fait pour que les décisions liées à l’informatique puissent ensuite
être appliquées. A quoi servirait en effet le SDI ou le PESI s’ils n’étaient pas suivis
d’effets ?
Enfin, notons qu’une majorité des personnes rencontrées souhaitent davantage de

communication, de coordination par la DOI, et qu’elles sont globalement favorables à la
modernisation de la gestion de l’informatique au MEF. Les premières réticences naturelles
à l’idée de mutualiser davantage les ressources pour davantage d’efficacité ont finalement
souvent été levées par le dialogue.
3.3 Avis de la mission
Une réforme ambitieuse de la fonction informatique du MEF doit être menée afin de
mieux exploiter le formidable potentiel humain et technique dont dispose le Ministère. Afin
de mener cette réforme en mode projet, le MEF devra nommer un responsable de ce projet
de réforme et déterminer si un encadrement est nécessaire.
3.3.1. Réorganisation de la DOI et des services informatiques
Les compétences informatiques du MEF doivent être regroupées afin de créer des masses
critiques suffisantes d’informaticiens pour spécialiser les agents et pour professionnaliser les
prestations informatiques globalement rendues par le MEF pour le MEF. Nous
recommandons pour cela que la DOI soit profondément réorganisée ainsi que les services
informatiques des différentes structures.
Nous préconisons que la DOI soit renommée pour marquer le changement et qu’elle soit
hiérarchiquement en mesure de coordonner toutes les activités informatiques de toutes les
structures du MEF. Ainsi la nouvelle DOI pourrait être rebaptisée Direction Générale de
l’Organisation et de l’Informatique ou Direction Centrale ou simplement Direction des
Systèmes d’Informations (DSI) et son nouveau mandat sera de :
• coordonner l’ensemble des activités informatiques du Ministère
• réaliser l’exploitation des matériels et logiciels
• faire évoluer le SI global du MEF en mode projet
• apporter le soutien nécessaire à l’ensemble des utilisateurs de l’informatique du
Ministère et offrir un support de haute qualité, suivi et géré de manière
professionnelle
• développer la communication extérieure du MEF via le WEB
• mettre en œuvre les outils de communication interne
• avoir une politique proactive de recherche & développement pour l’amélioration
permanente du SI global
• définir et mettre en œuvre la politique de sécurité des informations
Pour se faire nous proposons l’organigramme suivant pour la future DOI :

Figure 4 : Proposition
P d'organisation de la future DOI
OI
Nouvelle DOI
Secrétariat Adjoint
Gestion des Chargé de

achats Communication
RSSI
Direction de Direction de la Direction de la Direction des

Support
l'exploitation comm. & WEB R&D projets
réseau Gestion du Assistance à

Help desk Contrôle qualité
informatique contenu MOA
Administration Développement Méthodes et Réalisation

Hot line
Serveur sites normes (MOE)
Administration Formation Messagerie et Veille

poste de travail interne outils intranet technologique
Atelier
DBA Stratégie du SI
informatique
Maintenance des
applications
Infrastructure
La DOIOI compte à ce jour 26 informaticiens, soit un peu plus de 18% de l’effectif total des
informaticiens du Ministère.. Nous proposons que le nouvel effectif de la nouvelle DOI soit
le suivant :
• 5 personnes au niveau de la direction générale
• 25 personnes à la direction de l’exploitation
• 20 personnes au support
• 5 personnes à la direction de la communication et du WEB
• 15 personnes à la direction de la Recherche & Développement
• 10 personnes PERMANENTES à la direction des projets (s’y ajouteront
temporairement d’autres
utres personnes pendant la durée des projets)
Soit 80 personnes à la nouvelle DOI

D (sans compter le personnel d’appui),
i), ce qui représente
environ 57%% de l‘effectif des informaticiens du Ministère.
Les services informatiques des différentes structures doivent

doiv être réorganisés
rganisés en même
temps que la DOI.
OI. Leur mandat doit également être revu, nous proposons le suivant :

• Support technique de premier niveau aux utilisateurs (résolution des problèmes

matériels, déploiement de nouveaux postes, supervision du réseau informatique
local, etc.)
• Support fonctionnel de premier niveau : appui aux utilisateurs pour l’utilisation des
logiciels spécialisés et bureautiques
• Maintenance préventive du matériel : nettoyage des imprimantes, PC,
photocopieurs, vérification des onduleurs et du réseau informatique et électrique,
vérification des mises à jours antivirus, OS, office, etc. (travail en lien avec la
direction de l’exploitation
tation de la nouvelle DOI)
Figure 5 : proposition d'organisation des services informatiques des directions

techniques
Les différents services informatiques

info compteront au total 59 (139 – 80) agents
informaticiens de proximité.
Concernant la Direction des Projets

Proj de la future DOI, l’organisation
’organisation qui devra être mise en
œuvre pour la gestion de chaque projet consistera à faire intervenir sur le projet des
personnes de la DOI OI (issues de la Direction des Projets),
Projets), plus des personnes du service
informatique du ou des structures concernées par le projet, plus des personnes ressources
(notamment des « experts métiers » de la maîtrise d’ouvrage des directions techniques, des
prestataires, etc.).
Le changement d’organisation de la DOI en nouvelle DOI peut lui-même même être géré en
mode projet (voir au chapitre suivant la définition du mode projet). La préparation du
changement organisationnel doit être rigoureuse et la plus complète possible (étape de
conception, voyage d’étude), ), puis la mise en œuvre de la nouvelle organisation (étape de
réalisation) doit être rapide et surtout limitée dans le temps (inférieure à 6 mois).
mois) La clôture
de ce projet doit formellement être réalisée par un atelier au cours duquel un retour
d’expérience sera discuté par toutes les parties prenantes.
C’est au Ministère de concevoir ce projet de changement organisationnel, de valider les

objectifs et de définir dans la phase de réalisation le rythme du changement. Si le MEF juge
qu’un changement rapide est trop risqué, on peut envisager de le réaliser par étapes. Nous
proposons à titre d’exemple des étapes qui pourraient jalonner ce changement :
1. mise en place dès la validation du PESI d’une réunion mensuelle entre tous les
responsables des services informatiques pour échanger
échanger sur leurs projets en cours et
leurs besoins. L’objectif de ces réunions est de dégager les premiers projets
transversaux, éventuellement de favoriser des mises à dispositions d’informaticiens
d’un service à un autre. La réunion est présidée par la DOI
D (ou par une autorité
informatique présidée par le DOI et comprenant d’autres membres à définir,définir ou
alors par le Secrétariat Général)
Général et doit faire l’objet d’un compte rendu qui sera
diffusé à toutes les Directions

2. définir l’organisation cible de la nouvelle DOI (l’organigramme que nous

proposons ci-dessus pourra servir de base de réflexion), les méthodes, les mandats.
Outiller la nouvelle DOI pour qu’elle assure un support de second niveau aux
utilisateurs (help desk). Définir les mandats des services informatiques qui resteront
dans les Directions Générales techniques (a priori comme nous l’avons proposé
plus haut, les informaticiens qui resteront dans les services informatiques seront là
pour assurer le support de premier niveau)
3. prévoir l’espace et les bureaux pour loger la future DOI
4. formaliser les choix par des arrêtés ou décisions ministériels pour :
a. mutations d’informaticiens vers la nouvelle DOI
b. nouveau mandat de la DOI
c. nouveau mandat des services informatiques
5. transférer progressivement les informaticiens retenus des structures vers la nouvelle
DOI
6. formaliser la fin de la restructuration et réaliser un retour d’expérience5
3.3.2 Un management par projet
Le terme « projet » est souvent galvaudé. Il peut tantôt être synonyme d’un financement,
tantôt d’une idée un peu lointaine (« on a le projet d’organiser une formation sur tel sujet
un jour ») ou encore synonyme d’une activité. Pourtant dans le domaine du management, le
terme « projet » a une définition précise, il peut se définir et se caractériser de la façon
suivante :
• un projet est un ensemble d’actions à réaliser pour atteindre un objectif défini, dans
des délais déterminés et avec des moyens identifiés.
• un projet vise à apporter un changement : on passe de l’état 1 à l’état 2 en réalisant
un projet. En cela, gérer un projet, c’est aussi gérer le changement.
• Un projet nait, vit et meurt. Un projet ne peut pas durer indéfiniment (dans le
domaine informatique, en particulier au MEF, un projet de 2-3 ans est une limite
maximale que nous préconisons de ne pas dépasser)
• dans le cas d’une maintenance évolutive du SI (exemples : ajout d’une
fonctionnalité dans un logiciel, déploiement d’un réseau informatique dans de
nouveaux locaux, développement d’une interface entre 2 applications, etc.), si la
charge de travail totale estimée est inférieure à n mois/hommes alors il ne s’agit pas
d’un projet mais de l’exploitation normale d’un logiciel, l’évolution sera réalisée
dans le cadre de la maintenance ; dans le cas contraire, l’évolution fera l’objet d’un
« projet ». n est généralement fixé entre 2 et 6 selon les organisations, le MEF doit
décider ce qui lui convient le mieux.
• un projet :
o porte un nom
o est géré par un chef de projet nommément identifié, détaché à 50%
minimum de son temps sur le projet (mais la norme et la recommandation
est d’être chef de projet à temps plein sur un projet)
o est défini par un planning (qui contient au minimum une date de début, une
durée et une date de fin)
5 Le retour d’expérience est une étape trop souvent oubliée dans la gestion des projets. Elle consiste à faire un bilan de ce
qui a bien fonctionné, et ce qui sera à améliorer. Ainsi, chaque nouveau projet qui est lancé peut s’inspirer du retour
d’expérience des projets passés, et on constate « normalement » une amélioration progressive de la qualité des projets.

o est défini par un cadre logique (ou équivalent) c'est-à-dire une chaine de
résultats (de l’objectif global aux tâches en passant par l’objectif spécifique,
les résultats, les activités) et des indicateurs pour les mesurer à chaque
niveau ainsi que les risques (ou hypothèses) liés
o est identifié, suivi et validé par une maîtrise d’ouvrage dont les membres
sont nommément identifiés
o est mis en œuvre par une maîtrise d’œuvre dont les membres sont
nommément identifiés
o est supervisé par un comité de pilotage réunissant la maîtrise d’ouvrage et la
maîtrise d’œuvre
o est formalisé dans un plan d’assurance qualité
o est budgétisé si nécessaire, et les moyens sont listés et sécurisés
La littérature est prolifique sur le sujet. A titre d’exemple, on pourra
lire www.metaxcellence.com/IMG/pdf/Mode_Projet.pdf qui donne une bonne
définition, et dont nous en donnons ici un extrait :
« Né dans les années 80, le mode projet est une façon de travailler en entreprise de façon transversale. Le cœur du
fonctionnement n’est plus la dimension départementale et hiérarchisée, mais la notion d’équipe temporaire, transversale aux
différents services de l’entreprise, et constituée spécifiquement pour mener un projet à son terme.
L’objectif est de réunir les meilleurs experts et les meilleures conditions pour mener un projet donné. Le postulat est qu’en
travaillant de la sorte, on raccourcit les circuits de décisions habituels, et on se focalise entièrement sur l’atteinte des objectifs.
On se situe ici dans un contexte de recherche d’efficacité accrue, de retour sur investissement élevé et de respect de politique
Qualité codifiée.
Le principe n’est plus la fragmentation des tâches de l’entreprise, typique du fonctionnement en services hiérarchisés, mais la
construction d’équipes temporaires capables de gérer un projet dans sa totalité et de délivrer un produit fini.
Ainsi, un chef de projet est nommé. Sa première tâche sera de rassembler une équipe opérationnelle faite des spécialistes dont
il aura besoin. Ces personnes viendront d’horizons différents de l’entreprise et rempliront chacune un rôle précis par rapport
au projet. L’équipe sera constituée en fonction des objectifs et finalités du projet à mener.
Le chef de projet aura ainsi à négocier avec les responsables des services qu’il va « dépouiller » […]
La notion de hiérarchie traditionnelle est absente, ou en tout cas, fortement limitée, dans le travail en projet. Le chef de projet
a la responsabilité de faire en sorte que l’équipe qu’il anime atteigne ses objectifs dans le délai et le budget impartis. Chaque
participant au projet est responsable de l’achèvement de ses tâches, sachant que celles-ci sont intrinsèquement associées aux
tâches d’autres membres de l’équipe projet. […]
La façon de gérer une équipe projet, ainsi que celle de s’y insérer, impliquent des comportements différents du management «
classique », hiérarchisé et pyramidal. […]
Le chef de projet, lui, se trouve dans une situation où, comme un chef de service, il a des objectifs qualitatifs et quantitatifs à
atteindre, mais en se trouvant à la tête d’une équipe sur laquelle il n’a aucun pouvoir hiérarchique ! Le seul pouvoir qui lui
est accordé est celui de réclamer des résultats respectant délais et budget et de remonter à l’échelon supérieur les problèmes
rencontrés. Ce qui signifie que son autorité doit être basée sur la compétence, la confiance, la stricte définition
organisationnelle des objectifs à atteindre, et sa propre compétence d’animateur. […]»
Ainsi défini, beaucoup d’activités informatiques qui sont actuellement menées au MEF
pourraient être réalisées sous forme de projet. L’avantage principal de gérer ses activités par
projet est l’amélioration significative de l’efficience et de l’efficacité des services
informatiques. Le management par projet est devenu progressivement la norme dans les
grandes entreprises et institutions, et nous préconisons que le MEF du Bénin s’inscrive à
son tour dans cette logique.
3.3.3 Référentiel qualité
La gestion de projet informatique n’est pas une science exacte, et de nombreux échecs sont
encore constatés aujourd’hui à travers le monde. Là aussi la littérature est très abondante

sur le sujet des causes d’échec des projets SI. L’étude qui fait référence est connue sous le
nom de CHAOS et est réalisée tous les 4 ans par le standish group. Les chiffres ci-dessous
en sont extraits :
Succès Mitigé Échecs

projets achevés dans les délais et Budget, planning et/ou périmètre projets annulés
dans le respect du budget initial fonctionnel non respecté
% % %
53% 53%
49%
29% 31%
28% 23%
18%
16%
1994 2000 2004 1994 2000 2004 1994 2000 2004
En 2004, aux Etats-Unis, seulement 29% des projets informatiques étaient achevés dans les
délais et le respect du budget initial, 53% des projets n’avaient pas respectés les délais et/ou
le budget et/ou l’objectif initial, et enfin 18% des projets n’ont pas aboutis.
L’étude, réalisée sur 40 000 projets aux Etats-Unis, précise par ailleurs que si on observe le
secteur de la fonction publique en particulier, alors le taux de succès des projets SI tombe à
18% (au lieu de 29% en moyenne). Il est donc fort probable que dans un environnement
tel que le MEF au Bénin, le taux de succès des projets SI soit encore inférieur, c'est-à-dire
que statistiquement une très grande majorité des projets SI ne respectent pas les délais, le
budget initial et/ou l’objectif qui était fixé au départ.
Le but de ces études et de pouvoir identifier les facteurs clé du succès et les pièges à éviter.
Selon le Standish Group les 6 facteurs clé du succès suivants sont les plus importants :
1. l’implication des utilisateurs à toutes les étapes
2. le soutien des dirigeants
3. des objectifs métiers clairs
4. un périmètre fonctionnel bien adapté (pas trop large ni trop réduit).
5. des petits projets et une approche itérative à petits pas (« Agile Process »).
6. l’expérience du directeur ou chef de projet.
Des référentiels (méthodes, guide des bonnes pratiques, outils, etc.) ont été élaborés afin de
mieux anticiper les causes d’échec des projets SI. La mise en œuvre de ces référentiels n’est
bien entendu pas la garantie de réussir tous les projets, mais l’absence de référentiel est un
facteur aggravant d’échec des projets. Le MEF n’ayant pas à notre connaissance de
référentiel, nous conseillons très vivement d’en adopter un ou plusieurs parmi ceux, listés
ci-après, qui sont les plus répandus pour la gestion des projets et pour la gestion de la
qualité6 :
• ITIL V3 : ITIL (Information Technology Infrastructure Library pour «
Bibliothèque pour l'infrastructure des technologies de l'information ») est un
ensemble d'ouvrages recensant les bonnes pratiques pour le management du
système d'information, édictées par l'Office public britannique du Commerce
(OGC). C’est une référence majeure dans le domaine des systèmes d’informations.
• CMMi : sigle de Capability Maturity Model + Integration, est un modèle de
référence, un ensemble structuré de bonnes pratiques, destiné à appréhender,
évaluer et améliorer les activités des entreprises d'ingénierie. CMMi a été développé
par le Software Engineering Institute de l'université Carnegie Mellon, initialement
pour appréhender et mesurer la qualité des services rendus par les fournisseurs de
6 Toutes les définitions des méthodes et normes suivantes sont issues de http://fr.wikipedia.org

logiciels informatiques du Département de la Défense US (DoD). Il est maintenant

largement employé par les entreprises d'ingénierie informatique, les Directeurs des
systèmes informatiques et les industriels pour évaluer et améliorer leurs propres
développements de produits.
• ISO : L'Organisation Internationale de Normalisation (International Organization for
Standardization), ou ISO est un organisme de normalisation international composé
de représentants d'organisations nationales de normalisation de 158 pays. Cette
organisation créée en 1947 a pour but de produire des normes internationales dans
les domaines industriels et commerciaux appelées normes ISO. Elles sont utiles aux
organisations industrielles et économiques de tout type, aux gouvernements, aux
instances de réglementation, aux dirigeants de l’économie, aux professionnels de
l’évaluation de la conformité, aux fournisseurs et acheteurs de produits et de
services, dans les secteurs tant public que privé et, en fin de compte, elles servent
les intérêts du public en général lorsque celui-ci agit en qualité de consommateur et
utilisateur.
L'ISO est le plus grand organisme de normalisation au monde. C’est une
organisation non gouvernementale représentant un réseau d’instituts nationaux de
162 pays, selon le principe d’un membre par pays.
La norme ISO 9001 fait partie de la série des normes ISO 9000, relatives aux
systèmes de gestion de la qualité. Elle définit des exigences concernant
l'organisation d'un système de gestion de la qualité.
• PMI : Le Project Management Institute, fondé en 1969, est une association
professionnelle à but non lucratif qui propose des méthodes de Gestion de projet.
Son siège est à Philadelphie en Pennsylvanie (États-Unis), elle compte plus de
200 000 membres répartis dans 125 pays. Elle publie des standards relatifs à la
gestion de projet et est en charge de la certification des processus de gestion de
projet.
• PRINCE 2 : PRINCE2 (PRojects IN Controlled Environments) est une méthode
de gestion et de certification de projet structurée qui se focalise sur trois points :
l'organisation, la gestion et le contrôle du projet
3.3.4 Formation des agents
Lors de la mise en œuvre de la future DOI, la nouvelle affectation des agents doit être
programmée en fonction des affinités7 et compétences de chacun. Une fois les affectations
décidées, il faut prévoir des formations pour ceux qui occuperont des nouvelles fonctions
afin de les préparer.
Des formations doivent être prévues sur les thèmes liés à la nouvelle organisation. Citons à
titre d’exemple :
• Méthode qualité, gestion de projet et organisation de la fonction informatique
(former sur les méthodes retenues par le MEF, voir chapitre précédent). Plusieurs
formations à prévoir.
• Gestion d’un help desk, gestion d’une hot line
• Outil de messagerie
• JOOMLA ou DRUPAL, MS Sharepoint
7 En effet certains informaticiens sont naturellement attiré par des fonctions de développeur, ou d’administrateur réseau,
ou responsable qualité, ou gestion de projet, etc. Respecter l’attirance naturelle des informaticiens permettra de tirer le
meilleur d’eux-mêmes.

• Administration ORACLE
• Gestion de la sécurité
• Réseau informatique
• Méthode et langages de développement d’applications
• Langages pour le Web (HTML, JAVA, PHP, AJAX, XML, etc.)
• Etc.
Les formations aux outils doivent être programmées une fois que les outils de
développement de référence au MEF seront formellement définis.
On privilégiera les formations groupées au Bénin, en séminaire, ce qui a un coût de revient
très inférieur à des formations individuelles dispensées à l’étranger. Il faudra étudier la
possibilité d’organiser ces formations au CENAFOC, parfaitement équipé pour cela, ce qui
constituerait la contre partie nationale et permettrait, à budget équivalent, un bien plus
grand nombre de formations. Eventuellement le lieu de formation peut être en dehors de
Cotonou pour éviter que les participants à la formation soient perturbés pour des raisons
sociales ou professionnelles.
Pour cela un contrat cadre pourrait être passé avec un centre de formation pour une durée
de deux ans : le centre de formation, qui aurait remporté le contrat sur la base de la qualité
de son catalogue de formation, et de sa capacité à délocaliser ses séances de formation,
s’engagerait à organiser dans un délai de quelques semaines les formations demandées tout
au long de l’année au Bénin et à la demande du MEF. Nous pensons que ce contrat cadre
pourrait prévoir 30 semaines de formation au total entre 2012 et 2013 ce qui permet de
former au moins une fois par an tous les informaticiens du MEF pendant 1 semaine. Le
budget à prévoir pour un tel contrat cadre serait de l’ordre de 200 MFCFA (300 k€).
Pour information, les centres de formation informatiques en France sont très nombreux, il
y a par exemple :
• IBM Formation : http://www-304.ibm.com/jct03001c/services/learning/ites.wss/fr/fr?pageType=page&c=a0003630
• CAP GEMINI institut : http://www.institut.capgemini.fr/index.php?nos-seminaires-capgemini-institut
• ATOS ORIGIN centre de formation : http://www.formation.atosorigin.fr/
• ORSYS : http://www.orsys.fr/
• CEGOS : http://www.cegos.fr
• EGILIA : http://www.egilia.com
• PLB : http://www.plb.fr/
• Etc.

4. Applications informatiques
Résumé : Le MEF dispose de nombreuses applications métier pour automatiser les processus de gestion des
finances publiques. Les applications sont, à l’image de l’organisation vue au chapitre précédent, gérées de
façon décentralisée, leur nombre n’est d’ailleurs pas connu précisément. Il n’y a quasiment pas d’application
transversale au sein du MEF et il y a des applications redondantes. Malheureusement l’ensemble de ces
applications ne forme pas un « système » intégré et cohérent. Ces applications ont une fonction très
importante puisqu’elles doivent fournir régulièrement les données de référence pour la
gestion des finances publiques du Bénin. Pourtant cet objectif n’est actuellement pas atteint.
Nous préconisons que dorénavant cet objectif guide les futurs projets d’amélioration des applications
informatiques. Nous recommandons par ailleurs la mise en œuvre d’un « EAI » ou « EBS » pour
améliorer la circulation de l’information entre applications et ensuite, éventuellement, un entrepôt de données
(data warehouse) pour produire davantage d’information « intelligente » afin de produire les tableaux de
bords et d’aider à la prise de décision.
La stratégie du MEF a été de privilégier jusqu’à présent autant que possible les développements spécifiques
sur mesure plutôt que l’intégration de progiciels du marché. Ces applications « maison » ont été développées
selon différentes technologies et différentes architectures logicielles ce qui oblige le MEF à conserver et former
en son sein différentes compétences pour maintenir ces logiciels. Il manque un cadre stratégique du
développement des applications informatiques, que nous préconisons de définir afin d’harmoniser davantage
les outils. Nous préconisons enfin de lancer l’étude de conception de l’architecture cible du SI de GFP.
4.1.1 Absence de vision globale du SI
Le S.I. est un système qui est au « service » du Ministère pour l’aider à réaliser son
« métier ». Les services rendus par le SI, également appelés « fonctionnalités » du SI, sont
fournies par des « applications » communément appelées logiciels. Schématiquement, ces
applications sont techniquement constituées d’une base de données (SGBD) et de codes
sources développés dans un ou plusieurs langages, et qui fonctionnent grâce à des serveurs,
réseaux et postes informatiques. Nous distinguons ainsi les 4 « couches » qui se retrouvent
sur le schéma suivant8 :
8
Source : http://blog.xebia.fr/2008/04/10/urbanisation-pour-les-nuls/

• Vue métier : cartographie des processus métiers de l’organisation.

• Vue fonctionnelle : description des fonctionnalités (services) offertes par le système d’information
pour supporter les processus métiers.
• Vue applicative : description de l’ensemble des éléments du système informatique implémentant les
services urbanisés sous forme d’éléments logiciels.
• Vue technique : description de l’infrastructure de fonctionnement des éléments logiciels du système
informatique.
Pour évaluer la qualité du SI du MEF nous pourrions chercher à mesurer l’écart entre les
services rendus (couche fonctionnelle) par les applications (couche applicative) et les besoins liés
aux processus métier (couche métier). Nous pourrions également évaluer la qualité de
l’architecture technique des applications (couche technique). Autrement dit, par rapport au
schéma ci-dessus, pour évaluer la qualité du SI il faut évaluer une couche par rapport à une
autre.
Evaluation de la couche métier versus couche fonctionnelle
Pour évaluer la pertinence des services rendus par les logiciels (fonctionnalités), il faudrait
commencer par disposer d’une cartographie des processus métier afin de savoir si ces
processus sont bien informatisés.
La cartographie des processus métier est une modélisation de ce qui est précisément réalisé
par chaque direction, chaque service, sous quelle fréquence, comment et avec quel moyen ?
Un bon système informatique ne peut se développer que par une connaissance exhaustive
préalable de toutes les opérations menées par les agents y travaillant. Un audit
organisationnel complet du MEF suivi d’un projet de réformes organisationnelles si
nécessaire est la base afin d’obtenir une cartographie des processus métier.

Par exemple, il faudrait une description, puis une modélisation des processus métier
d’élaboration et de validation du budget, ou le processus métier d’exécution du budget, ou le
processus de comptabilisation, mais aussi, dans d’autres domaines métiers, le processus de
recrutement, d’élaboration des salaires ou de traitement du courrier, etc.
Malheureusement la cartographie des processus métier du MEF n’existe pas, ce qui
est regrettable. En effet, toute conception ou évaluation d’un système d’information en vue
de son évolution commence par une analyse métier de l’institution, et l’audit
organisationnel permet de savoir quel service est chargé de quelles attributions, pour savoir
quels sont les échanges entre les services, et quels sont les processus et procédures de
traitement des différentes activités menées par l’institution. Au-delà de l’intérêt
informatique, ces analyses « métier » et « organisationnelle » sont fondamentales pour
mener à bien les réformes de gestion des finances publiques.
Une étude a bien été menée en 2008 par le cabinet ProGenia, intitulée « Audit du SI de la
chaîne des dépenses publiques (lien pour télécharger le rapport : http://www.e-
sud.fr/client/PESI_Benin/doc/Audit_Sigfip.pdf), mais cette étude ne traite que des
logiciels SIGFiP et ASTER (il manque notamment MATKOSS, SYDONIA, DEBTPRO,
TAKWE pour prendre en compte toute la gestion des finances publiques). Par ailleurs, si
cette étude a bien esquissé les principaux processus de GFP de la chaîne de la dépense, et
posé les bonnes questions, elle n’est pas assez détaillée en ce qui concerne l’analyse de
l’adéquation entre les fonctionnalités offertes par les applications et les processus métiers.
Aucune modélisation n’a été proposée, et les recommandations ne permettent pas de
mettre en évidence de défauts fonctionnels majeurs dans les logiciels étudiés (alors que
nous verrons tout au long de ce document que plusieurs reproches sont clairement
formulés, notamment à l’encontre d’ASTER, on ne les retrouve pas dans cette étude de
2008, ce qui est surprenant). Il faut préciser à la décharge du cabinet, que l’étude a été
menée en moins de deux mois alors qu’il aurait fallu y consacrer davantage de temps. De
plus, l’étude a abordé trop de sujets (techniques, réseau, sécurité) plutôt que de se focaliser
sur les aspects métiers et fonctionnels.
Comme il ne nous était pas possible de réaliser nous-mêmes en quelques jours cette
cartographie fondamentale des processus métiers avec la rigueur exigée pour un tel
exercice, il nous est difficile d’évaluer objectivement et précisément la pertinence du SI
actuel, et de formuler des recommandations détaillées pour son évolution.
Toutefois, nous pouvons donner un avis général sur la « couverture fonctionnelle » actuelle
des applications du MEF en matière de GFP par rapport à une cartographie fonctionnelle
type que l’on peut trouver dans un Ministère de Finance de culture francophone:

9
Figure 6 : Cartographie fonctionnelle possible d'un MEF
Unene macroanalyse des applications

applicati en cours
au MEF du Bénin par rapport à ces deux
exemples de cartographie fonctionnelle nous
permet de conclure, qu’a priori, la couverture
fonctionnelle actuelle de la GFP au Bénin est
correcte, c'est-à-dire
dire qu’il n’y a pas de manque
majeur d’application au MEF. Elle n’est
cependant
nt pas totale (il manque par exemple
les services aux usagers, etc.), et
l’informatisation de certaines fonctionnalité
ne sont encore qu’à l’état de projet (ex : Achat
ou Passation des marchés).
Les applications qui pourraient manquer ne
concernent pas directement
ectement la GFP, mais des
activités de gestion interne, telle que par
exemple la gestion du courrier (logiciel très
fréquemment demandé par les services), la
gestion des stocks et des matériels, la gestion
et le suivi des ressources humaines : aucune
application
tion globale n’existe pour cela.
cela
9 Source du premier schéma : schéma directeur informatique du MEF d’Algérie pour le premier schéma (qui est aussi
celui qui est en cours d’adoption au Tchad, avec les revenus pétroliers en plus).
Source du second schéma : schéma directeur informatique du MINFI du Cameroun, étude en cours en 2011, le
schéma tel que présenté est à l’état de projet

Evaluation de la couche fonctionnelle versus couche applicative
Nous pourrions également chercher à évaluer la cohérence entre les fonctionnalités du SI

et les applications en production qui supportent ces fonctionnalités. Cela permettrait par
exemple de constater que plusieurs applications réalisent la même fonction, ou qu’une
fonctionnalité est assurée par plusieurs applications non interfacées, ou encore que 2
applications sont très proches en termes de fonctionnalités et qu’une fusion entre ces 2
applications est à préconiser. Malheureusement, la cartographie fonctionnelle du MEF
n’existe pas, et le parc applicatif n’est pas connu avec suffisamment de précision.
Nous consacrons cependant une étude partielle des applications au chapitre 4.1.2.
Evaluation de la couche technique
Enfin, concernant la couche la plus basse, c.à.d la couche technique, le MEF dispose bien
de quelques schémas partiels du réseau informatique. Par contre l’emplacement de tous les
serveurs et de toutes les applications n’est pas connu avec précision et, surtout, avec
exhaustivité. Il en est de même de la liste des technologies utilisées. Un travail de remise à
plat du réseau global a débuté au sein de la DOI, ce qui devrait pallier à ce manque constaté
et permettra bientôt de dessiner l’architecture technique.
Un pilotage du développement « à vue »
L’absence de cartographie des différentes couches du SI du MEF rend donc difficile son
évaluation par la mission, mais aussi et surtout par la DOI. Sans cet état des lieux
permanent il est difficile de prendre des décisions pour améliorer le SI. Ainsi, le MEF
n’est actuellement pas en capacité de piloter stratégiquement le développement de
son SI global. Comment en effet la DOI (ou la future DOI) pourrait-elle prendre une
décision sur l’avenir du SI global sans qu’elle n’ait la connaissance des processus métiers,
fonctionnalités, applications et technologies actuels ?
Sur la base des éléments relevés lors des interviews, nous avons néanmoins réalisé un
diagnostic partiel de l’existant et formulons plus loin quelques recommandations tant sur
les couches fonctionnelles et applicatives que sur la couche technique. Mais la
recommandation la plus importante reste de réaliser cette cartographie actuelle du SI (pour
ensuite définir une cartographie optimisée). Il s’agit du projet A1 décrit dans la partie B.
4.1.2. Automatisation insuffisante du SI
Nous avons constaté qu’au MEF l’insuffisance de l’automatisation du SI était liée à 3

facteurs :
• défaut de cohérence fonctionnelle et applicative du SI,
• absence de volonté politique,
• difficultés techniques.
Nous donnons ci-après des exemples pour chacun de ces 3 facteurs.

Défaut de cohérence fonctionnelle et applicative
Le dernier recensement connu des applications date du dernier PESI en 2007. 76

applications étaient alors recensées en production (dont la moitié développée en interne) et
24 applications en cours de développement. Nous avons listé en annexe 5 les applications
qui nous ont été mentionnées lors de la phase d’interviews.
Nous avons cependant tenté de relever certaines interfaces entre les principales applications
de la gestion des finances publiques (GFP) et le schéma ci-après en représente l’état non
exhaustif :
Figure 7 : « Cartographie applicative » partielle liée aux processus métier GFP
Ce schéma donne une première idée du SI global lié à la gestion des finances publiques.
Nous constatons immédiatement que de nombreuses interfaces sont en projet ou réalisées
de façon manuelle, c'est-à-dire qu’il y a intervention manuelle d’un agent pour transférer les
données d’une application à l’autre. Le SI de GFP n’est donc pas entièrement
automatisé.
Pour l’illustrer, prenons le cas détaillé du traitement d’un titre (mandat de paiement) par la
DGTCP. Le processus qui nous a été décrit est le suivant :
• Le titre (mandat de paiement) arrive à la RGF (recette générale des finances) et passe dans plusieurs divisions. Ce
workflow est géré par MATKOSS.
• Une fois le titre validé, étape 7 dans MATKOSS, par le service « VISA », ce dernier saisit également dans SIGFiP
la prise en charge. Pas d’interface entre MATKOSS et SIGFiP à ce niveau là. Puis SIGFiP informe (via interface)
ASTER que le titre est pris en charge.

• La division « règlement » du service de la dépense de la RGF procède à la comptabilisation du titre (prise en charge
comptable) dans ASTER et édite le titre de règlement dans SIGFiP puis transfert tous ces documents à la trésorerie.
• Le service de la trésorerie édite le titre de paiement avec SIGFiP, comptabilise dans ASTER, puis édite le bordereau
de virement ou le chèque avec MATKOSS.
Ce processus de traitement d’un titre par les applications peut se représenter
schématiquement de la façon suivante (nous ne faisons pas apparaître dans cette
représentation les acteurs qui interviennent dans les processus pour conserver un schéma
simple) :
Figure 8 : cartographie applicative actuelle pour le Nous constatons tout d’abord qu’il
processus de traitement d'un titre faut 3 logiciels pour traiter un titre, et
qu’ensuite, faute d’interface entre les
étapes 2 et 3, et entre les étapes 5 et 6
il faut saisir plusieurs fois la même
information. La redondance des
applications et les doubles saisies sont
sources d’erreurs (comment s’assurer
en effet que les mêmes montants ont
été saisis dans tous les logiciels ?) et
de ralentissements du traitement des
dossiers. Cet exemple illustre ainsi
parfaitement le manque d’intégration
du système d’information actuel et le
manque d’optimisation de la gestion
des processus métiers.
Dans nos recommandations et dans le projet A1 nous indiquons qu’il faut réaliser la
cartographie du SI actuel par reverse engineering10, puis l’optimiser pour produire une
cartographie cible. Dans notre exemple du traitement d’un titre de paiement, le reverse
engineering est représenté figure 8 (dans une version très simplifiée), et la cartographie cible
optimisée pourrait être l’une des deux suivantes :
Figure 9 : Exemple d'optimisation de la cartographie applicative pour le paiement d’un titre
10 Le reverse engineering est une technique qui consiste à représenter les schémas de conception d’un logiciel à partir de
l’étude des codes sources du logiciel. Autrement dit, en étudiant précisément le logiciel on modélise son
fonctionnement. Cela se nomme « reverse » engineering puisque le processus normale est de commencer par
modéliser /concevoir le logiciel puis ensuite de le développer. Malheureusement lorsque les modèles de conception
n’ont pas été bien conservé, ou pas transmis, ou jamais fait, il est nécessaire de les refaire par « reverse engineering »
afin de pouvoir réaliser une maintenance évolutive correcte de ce logiciel.

Dans cette optimisation, MATKOSS et ASTER seraient fusionnés (c'est-à-dire que soit les
fonctionnalités d’ASTER sont intégrées dans MATKOSS, soit c’est le contraire, ou alors
un nouveau logiciel est créé à partir de ces 2 logiciels) puisqu’ils ont des fonctionnalités
assez proches. Nous diminuons ainsi le nombre de logiciels à exploiter, maintenir et
déployer, le nombre de formations à dispenser, etc. et l’intégration est renforcée. Ce logiciel
de comptabilité MATKOSS/ASTER contiendrait des fonctionnalités bien distinctes de
celles de SIGFiP, c'est-à-dire que l’on cherchera à spécialiser les applications. Une troisième
option pourrait même être étudiée, il s’agirait de n’avoir qu’une seule application intégrée
de gestion de la chaîne de la dépense, comme cela est le cas dans certain pays (Burkina Faso
par exemple). Nous ne faisons cependant aucune recommandation ici sur ce sujet précis
qui n’est présenté que pour illustrer notre argumentaire. Il faudrait en effet une analyse
poussée et exhaustive de plusieurs semaines avant de pouvoir tirer quelle que conclusion
que ce soit sur l’architecture fonctionnelle et applicative cible (voir partie B le projet A1 de
conception générale que nous proposons).
Cet exemple montre que l’absence d’automatisation du SI peut être liée à un défaut de
conception fonctionnelle du SI.
Absence de volonté politique
Une autre explication de l’insuffisance de l’automatisation du SI tient dans le manque de

volonté des Directions du MEF de donner accès à d’autres Directions du MEF à « leurs »
données. C’est par exemple le cas de l’interface SYDONIA – ASTER qui existe
techniquement mais qui n’est pas mise en œuvre. L’absence de volonté de partage des
informations ne permet pas une circulation fluide des informations entre les logiciels des 4
grandes directions (Douanes, Impôts, Trésor, Budget). Nous pouvons également citer
l’exemple de l’interface « retour » entre ASTER et SIGFiP pour transmettre à SIGFiP
l’information liée au paiement d’un titre (interface entre étape 5 et 6 dans le schéma de la
« Figure 8 : cartographie applicative actuelle pour le processus de traitement d'un titre »). Cette interface, par
ailleurs programmée dans le DP et la partie B du présent rapport, est techniquement
relativement simple à réaliser, et toutes les compétences requises sont largement
disponibles à la DGTCP et à la DGB. Enfin, notons comme dernier exemple
caractéristique, l’absence d’interface automatisée entre la CAA et la DGTCP pour le
traitement de la dette.
Difficultés techniques
L’absence d’automatisation du SI peut simplement être liée à des difficultés techniques. Par
exemple, au Trésor, la communication entre le siège et les Recette-Finances (RF) et entre
les RF et les Recettes-Perception (RP) n’est pas bonne en raison de problèmes de liaison du
réseau informatique (voir chapitre 7. Réseau informatique local et étendu). Fiabiliser les
liaisons VSAT11 (par satellite) entre le siège et les RF, et la BLR (Boucle Local Radio, qui
est une connexion par antenne hertzienne) entre les RF et les RP permettrait de déployer
WMoney (une application légère) dans les RP et de faire remonter beaucoup plus
rapidement les informations de recettes et dépenses des régions vers le siège, ce qui aurait
l’avantage d’informer le comité de Trésorerie qui décide des dépenses et de leurs paiements.
11 Le MEF précise que depuis sa mise en service, le réseau VSAT fonctionne de manière tout à fait fiable, par contre à la
date de la mission des consultants il était complètement coupé par le fait du non-paiement des prestations. Il ne s'agit
donc pas d'une difficulté technique, mais plutôt d'une difficulté administrative ;

Une telle connexion permettrait en outre d’envisager une application WEB centralisée, ce
qui autoriserait une gestion en temps réel des recettes et dépenses.
Nous avons également constaté de graves problèmes de fonctionnement du réseau
informatique12 avec la DGTCP qui empêchent parfois de faire fonctionner l’interface entre
SIGFiP et ASTER. L’origine du problème étant en l’occurrence liée au réseau, nous
formulons nos recommandations dans la partie consacrée à ce sujet dans le rapport.
Conséquence : un constat d’échec global du « système » d’information
Comme nous venons de le voir, l’automatisation totale du SI se heurte à des défauts de

conception fonctionnelle des applications, à un manque de volonté politique et à des
problèmes techniques. L’absence d’automatisation totale entraîne une incertitude sur la
qualité des données produites par le système informatique du MEF, laquelle sème le doute
sur la capacité du MEF à produire les chiffres crédibles des finances publiques et par
conséquent sur la bonne gestion des finances de l’Etat. Le fait que le SI ne produise pas
automatiquement les chiffres fiables de GFP est un constat d’échec du S.I. Il est
dommage que les problèmes fonctionnels et techniques du SI aient une telle conséquence,
alors qu’il serait relativement simple de les résoudre. Si la volonté politique de rendre plus
efficace le SI existe, alors les solutions techniques et fonctionnelles pourront être trouvées
en l’espace de quelques mois.
Le fait que le TOFE ne soit pas produit de façon automatique (voir l’encadré ci-dessous)
met en évidence l’absence d’automatisation de toute la chaîne de traitement de
l’information. Produire automatiquement un TOFE cohérent serait la garantie d’une
informatisation correcte et fiable à tous les niveaux de traitement des informations de GFP
du MEF. L’informatisation du TOFE, ou la production fiable et automatique des
informations de GFP doit donc être l’objectif spécifique du PESI.
12 Rupture totale de communication

L’absence d’automatisation du SI : de graves conséquences pour le TOFE
Le TOFE est produit par la CSPEF. La procédure d'obtention du TOFE est conforme au cahier des charges du FMI. Il est à noter
que le Bénin fait partie des « bons élèves » du FMI pour la production de ce document. Malgré ce bon point le TOFE comporte une
lacune importante : il est obtenu par collecte manuelle d'informations au sein du MEF. La périodicité du TOFE est trimestrielle mais
la collecte a lieu mensuellement afin d'effectuer des contrôles et des recoupements avec les informations produites dans chaque direction.
Le principe de fonctionnement est le suivant :
- Il est demandé au service concerné l’extraction d’informations à partir de critères préalablement établis (requêtes en terme
informatique)
- le service concerné livre ces informations sur un support magnétique (clé USB, CD, pièce jointe dans un mail)
- les conseillers intègrent ces informations dans des tableaux Excel assez sophistiqués.
Première remarque : au plan de l’intégrité de l’information, l’utilisation du tableur Excel n’est aucunement une garantie d'intégrité.
Deuxième remarque : les membres de cette cellule technique ne maîtrisent pas le contenu de la requête (les critères de sélection
d’information) il se peut qu’il n’y ait pas concordance à un moment donné entre l’extraction demandée et l’état des informations dans la
base de données (cas d’un changement de secteur prioritaire qui a été fait dans la base de données centrale et pas dans la requête, ou
encore cas de la TVA portée par les Douanes et la DGID).
Pour palier à ces problèmes, il faudrait naturellement tendre vers une production totalement informatisée du TOFE. La Cellule de
Conseillers devrait être dédiée à des tâches de vérification des informations contenues dans ces différents documents plutôt qu’à des
manipulations de tableur alimenté manuellement par des informations hautement sensibles.
L'automatisation du TOFE est prévue sur le Devis Programme, les termes de référence ont été approuvés mais le projet n'a pas été
lancé à ce jour. Nous le prévoyons en priorité 1 dans le PESI 2011 (voir partie B).
4.1.3 Absence de contrôle des données et de fiabilité des chiffres fournis
Si nous représentions sur le schéma de cartographie applicative (Figure 7) les utilisateurs des
applications, il apparaîtrait que les organes de contrôle externes et internes (chambre des
comptes, Inspection Générale d’Etat (IGE), contrôle financier, CSPEF, CSSFD, IGF,
ARMP, DCCE) n’ont pas d’accès direct au S.I. de GFP. Ces organisations effectuent
principalement leurs contrôles sur la base de documents produits par les services et non sur
la base de requêtes qu’ils pourraient réaliser eux-mêmes dans le SI global. Ainsi les données
contenues dans les applications de gestion des Finances Publiques ne sont pas
« contrôlées », mais ce sont les données contenues dans les rapports qui ont été produits
grâce au S.I. après traitement manuel qui le sont, ce qui est bien différent. Cette absence de
contrôle ne permet pas de garantir la fiabilité des chiffres produits automatiquement par le
SI global. La chambre des comptes est pourtant demandeur depuis longtemps d’une
connexion à SIGFiP et à Aster pour effectuer son travail de contrôle, tout comme la
DCCE réclame un accès à Aster pour la réalisation du compte général de l’administration
des finances et du projet de loi de règlement des finances qui, jusqu’ici, sont entièrement
réalisés de façon manuelle. Donner l’accès au SI par les autorités de contrôle permettra de
renforcer considérablement le poids de l’informatique dans la GFP et le rôle des
informaticiens.
Notons ici un autre exemple d’absence de contrôle, sans pour autant rentrer dans trop de
détails. Actuellement la chaîne de dépense publique débute par la programmation du
budget et se termine par le paiement, en passant par les étapes d’engagement, liquidation,
ordonnancement. Ainsi lorsqu’un montant a été alloué à une ligne budgétaire, les logiciels
actuels SIGFiP et ASTER permettent de suivre les sommes engagées et payées. Mais
comment vérifie-t-on que tous les paiements réalisés ont bien été saisis dans les logiciels ?

Autrement dit, quel(s) moyen(s) de contrôle(s) informatique avons-nous pour nous assurer
que des paiements n’ont pas été oubliés ? Bien sûr il existe de nombreuses procédures
manuelles de contrôle, mais le moyen simple de s’assurer que toutes les données sont bien
saisies serait de faire le rapprochement bancaire dans ASTER. C'est-à-dire qu’il faudrait
pouvoir « pointer » dans le logiciel les dépenses effectivement constatées sur le relevé de
compte bancaire. Ainsi le solde calculé par ASTER et celui figurant sur le relevé bancaire
devraient-ils toujours être le même après rapprochement, ce qui garantirait la qualité des
données présentes dans ASTER. Malheureusement, cette procédure de rapprochement
bancaire est réalisée manuellement avec un risque toujours présent d’omission potentielle et
ce bien que cette fonctionnalité existe potentiellement dans ASTER. Du point de vue des
Finances Publiques et informatique, la chaîne de dépense publique doit comprendre le
rapprochement bancaire automatisé.
4.1.4 Une bonne appropriation des applications
Même si nos interlocuteurs étaient le plus souvent des informaticiens et rarement les
utilisateurs des applications, il ne nous a pas été rapporté de difficultés structurelles ou
organisationnelles dans l’appropriation des principales applications métiers par les
utilisateurs (il existe bien des utilisateurs qui éprouvent toujours des difficultés liées à
l’informatique, mais ces difficultés sont normales et s’atténueront progressivement avec le
temps).
Il semble donc que les services informatiques réussissent très correctement leur mission de
déploiement des applications et de gestion du changement pour permettre l’appropriation
des applications par les utilisateurs. Ceci est remarquable et cette capacité doit être
conservée dans la future organisation qui sera mise en place.
Notons toutefois l’inexistence ou l’absence de mise à jour de la documentation des
applications existantes. La documentation à produire concerne aussi bien les utilisateurs
(guide utilisateur, aide mémoire) que les administrateurs (guide d’installation, guide
d’administration) et les développeurs (MCD, modèles de traitement, cahier des charges).
Une documentation à jour permet le transfert de compétences d’une façon générale. Ne
pas disposer de documentation fait courir le risque de voir une partie de la mémoire
technique et fonctionnelle, c'est-à-dire la compétence informatique du Ministère,
disparaître.
La documentation d’un logiciel doit être accessible de plusieurs façons : par exemple
l’application doit disposer d’un menu « aide », ou les écrans doivent avoir une aide
contextuelle (un point d’interrogation ou un clic droit sur un champ doivent ouvrir une
infobulle ou une popup qui doivent aider l’utilisateur à renseigner l’écran ou comprendre
les informations affichées). La documentation doit également être disponible sous format
papier, et idéalement sous un logiciel de e-learning de façon à favoriser l’auto-
apprentissage. Toute la documentation des logiciels doit être regroupée dans un portail ou
dans la GED, et pour les documentations destinées aux développeurs, on pourrait
envisager la mise en place d'un « wiki » pour faciliter le travail collaboratif.
4.1.5 Des logiciels « qui ne marchent pas »
Il est fréquent d’entendre des utilisateurs de toutes organisations dire que « les logiciels ne
fonctionnent pas ». Il est fréquent également qu’il y ait des insatisfactions dans le
fonctionnement d’un service et que la raison invoquée soit le logiciel. Ce sentiment est

tellement partagé par les utilisateurs du monde entier, qu’il est donc vrai que « les logiciels
ne marchent pas ».
Afin de traiter correctement cette question, il faut détailler les causes possibles des
dysfonctionnements des logiciels, puis chercher à catégoriser les problèmes soulevés par les
utilisateurs pour savoir quelle(s) réponse(s) apporter. Les sources potentielles de
dysfonctionnement des logiciels que nous avons identifiés sont les suivantes :
1. Dysfonctionnement technique (Bug) : il s’agit d’une erreur manifeste du logiciel qui
« plante »
2. Dysfonctionnement fonctionnel : le logiciel produit une erreur de calcul ou de
traitement d’une procédure.
3. Dysfonctionnement conceptuel : le logiciel fonctionne conformément au cahier des
charges, mais c’est le cahier des charges qui n’est pas conforme au processus métier
(le logiciel n’est pas ou n’est plus adapté, ce qui est par exemple le cas suite à une
réforme qui modifie le fonctionnement d’une procédure)
4. Dysfonctionnement lié à une mauvaise utilisation du logiciel
5. Dysfonctionnement lié à une mauvaise compréhension du logiciel
6. Dysfonctionnement lié à des raisons exogènes (électricité, réseau, etc.)
Il faut savoir qu’en général dans toutes les organisations, une grande majorité des
dysfonctionnements rapportés par les utilisateurs sur les logiciels éprouvés (nous ne parlons
pas ici des logiciels nouveaux qui sont souvent encore très « bugués ») sont de type 4 et 5,
c'est-à-dire que ce n’est pas le logiciel en soi qui doit être remis en cause, mais la formation
au logiciel et l’organisation mise en place pour l’utiliser. A titre d’exemples :
• nous avons vu au chapitre « 4.1.3 Absence de contrôle des données et de fiabilité des
chiffres fournis » que le rapprochement bancaire n’était pas fait dans ASTER. Rien ne
permet donc de garantir qu’ASTER contient tous les paiements. Pourtant la
fonctionnalité de rapprochement existe dans ASTER, mais elle n’est pas utilisée. Ce
n’est pas un dysfonctionnement intrinsèque du logiciel ASTER mais une sous-
utilisation (dysfonctionnement de type 4).
• dans SIGFiP il est possible de produire un état d’exécution budgétaire d’un Ministère
par exemple. Lors de la production de cet état, il est possible de ne sélectionner qu’une
partie des lignes budgétaires. S’affiche alors un « Taux d’exécution total » qui est la
moyenne pondérée du taux des lignes budgétaires sélectionnées. Si on produit à
nouveau cet état, mais en sélectionnant d’autres lignes budgétaires, alors ce taux va bien
entendu varier. Cette variation de taux est interprétée par certain comme un manque de
fiabilité des données de SIGFiP puisque le taux d’exécution « varie tout le temps ». Le
problème vient simplement du libellé de l’état, il faudrait que soit affiché « Taux
d’exécution total pour les lignes sélectionnées : » puis une autre ligne avec « Taux
d’exécution total pour tout le budget indépendamment de l’extraction : ». Cette
évolution fonctionnelle, qui ne demande sans doute pas plus de 15 minutes à un
informaticien, résoudrait alors le « problème » ! C’est un exemple de
dysfonctionnement de type 5.
• Il n’y a pas de report à nouveau réalisé dans ASTER au MEF. Ainsi la balance générale
des comptes de l’Etat (BGCE) en début d’exercice n’est pas celle de la fin de l’exercice
précédent. Tout expert dira ainsi que « les balances issues d’ASTER sont fausses et
inutilisables » ce qui est vrai. Pourtant la fonctionnalité de report à nouveau existe bien
dans ASTER d’après la documentation accessible sur

http://www.tresor.gov.ci/reformes/logiciel_aster.htm. Là encore il s’agit donc d’une

sous-utilisation du logiciel, et non pas d’un problème intrinsèque au logiciel.
• Les comptes provisoires de classe 4 ne sont pas soldés ou encore le reflet des comptes
de la classe 9 (comptabilité analytique) dans la classe 2 (immobilisation), 6 (compte de
charges) et 7 (compte de produits) sont partiels. Certaines opérations sont enregistrées
dans des comptes d’attente « fourre-tout » ne permettant pas ensuite de solder les
comptes provisoires après paiement et d’obtenir une imputation définitive. Il s’agit
d’une mauvaise utilisation d’ASTER par les comptables, soit par négligence, par
manque de formation, ou pour toutes autres raisons. La solution n’est pas
informatique, et n’est donc pas traitée dans cette étude, mais elle doit venir des
procédures d’imputations (voir le manuel de GFP) et de la formation des comptables.
Pour aider les comptables, le « guide des imputations » pourrait leur être mis à la
disposition sous la forme d’une aide en ligne contextuelle, c'est-à-dire qu’au moment
d’imputer, un clic droit rappellerait aux comptables les règles d’imputation en vigueur.
Il existe des cas de dysfonctionnement technique (bug), fonctionnel ou conceptuel. Si les

premiers sont généralement rapidement corrigés, les deux autres nécessitent la mise en
œuvre d’un véritable support informatique organisé (voir nos recommandations) pour
prendre en compte les retours des utilisateurs. Le support doit aussi avoir pour mandat
d’accompagner les utilisateurs pour une bonne utilisation du logiciel. C'est-à-dire que le
support doit à la fois être technique pour les corrections informatiques, et fonctionnelles
(réalisé par des experts métiers) pour aider à l’utilisation fonctionnelle des logiciels.
4.1.6 Les applications spécifiques privilégiées par rapport aux progiciels
Les services informatiques du MEF ont fait le choix de privilégier depuis de nombreuses
années le développement interne de leurs logiciels plutôt que l’acquisition de progiciels du
marché.
Nous avons ainsi relevé 22 applications développées en interne sous différentes versions de
Windev, et dans le même temps nous n’avons relevé que peu de progiciels acquis sur le
marché (Aster, SDL7, Sydonia++, Eurotrace pour nommer les plus importants). En nous
basant sur les chiffres de l’inventaire 2007, 62% des applications métier sont réalisées en
développement spécifique contre 38% de progiciels / logiciels acquis.
Les informaticiens du MEF ont constamment assumé cette stratégie qui leur permet
d’avoir une maîtrise complète de leurs logiciels et qui leur offre une totale indépendance
par rapport à un éditeur de logiciel.
Nous proposons cependant une comparaison plus complète des 2 approches dans le
tableau ci-après :

Avantage Inconvénient
Maîtrise du code source. Risque important de dépassement des délais et
Personnalisation totale du logiciel possible coûts prévus initialement.
Réactivité de la maintenance. Forte incertitude sur la qualité finale.
Développement Spécifique
Valorisation des capacités du personnel informaticien. Coût élevé, tant financier qu’humain.
Incertitude sur la capacité de la maîtrise d’ouvrage à
produire un cahier des charges complet et tenant
compte de l’état de l’art.
Coût important de la maintenance réalisée en
interne
Pas de mutualisation de l’expertise avec d’autres
MEF
Dispersion des énergies (le même outil peut être
développé plusieurs fois).
Absence de réflexion globale (le programme répond
à un besoin immédiat).
Le progiciel reflète l’état de l’art puisqu’il est déjà Coût d’achat parfois élevé.
installé chez plusieurs clients qui font le même métier. Risque de difficulté dans l’intégration avec le SI
Le progiciel est rapidement mis en œuvre existant.
Le progiciel est éprouvé chez d’autres clients, par L’organisation doit s’adapter au mode de
conséquent faible risque de « mauvaise surprise ». fonctionnement du progiciel.
Progiciel
L’outil répond à des besoins fréquents rencontrés par Difficulté à obtenir les codes sources souvent
des structures variées et est parfaitement adapté. protégés.
Le prestataire est un spécialiste et peut mobiliser des Risque de faillite de l’éditeur du progiciel.
ressources spécifiques. Coûts récurrents du support (licence forfaitaire de
Les cadres du MEF se spécialisent sur leur cœur de maintenance).
métier et ne se concentrent que sur leur rôle de
maîtrise d’ouvrage dans les projets informatiques
Il ne faut pas être dogmatique sur le choix des types d’applications (progiciel versus
spécifique), il n’y a pas de vérités universelles sur la question. Les décisions doivent se
prendre au cas par cas. Mais nous pouvons préconiser que, d’une façon générale, les
applications très spécifiques telles que la GFP et les petites applications ponctuelles telles
que la gestion temporaire d’un fonds de modernisation, continuent à être des
développements spécifiques, c'est-à-dire des applications entièrement conçues et réalisées
par le MEF, ou alors des applications du marché ayant un code source « ouvert » (c'est-à-
dire modifiable) afin que le MEF puisse les adapter. En revanche, pour les applications qui
couvrent des fonctions connues et répandues, telles que la gestion du courrier, la gestion
des marchés, la gestion des ressources humaines (fonctions que des milliers d’institutions à
travers le monde ont déjà informatisées), ou le suivi-évaluation de projets il est préférable
de recourir à des progiciels standard du marché.
Il semble que la décision de généraliser le recours au développement d’applications
spécifiques soit surtout motivée par la crainte des informaticiens du MEF de voir réduire
l’importance de leurs interventions. Il s’agit d’une mauvaise appréciation car, au plan
international, la tendance observée est que les informaticiens ayant recours à l’utilisation de
progiciels voient leur rôle renforcé et leurs compétences recherchées. Par ailleurs, on ne
bâtit pas une telle stratégie pour justifier le travail des informaticiens : s’il n’y avait pas
suffisamment de travail pour tous les informaticiens du Ministère, la solution ne serait pas
de leur chercher à tout prix du travail, mais d’adapter les missions des informaticiens en
fonction des besoins. Si davantage de recours aux progiciels permet en effet de libérer du
temps aux informaticiens, ce temps libre doit être mis à profit pour réaliser les très

nombreuses autres activités telles que le support, l’automatisation du SI, la recherche &
développement, etc. (voir la partie B du présent rapport qui contient la liste des projets à
lancer).
4.1.7 Hétérogénéité des technologies informatiques des applications
Nous avons vu que le travail de cartographie de la couche technique du SI était en cours.

Nous savons déjà que les SGBD (système de gestion de bases de données) utilisés pour la
centaine d’applications connue sont ORACLE, WINDEV (plusieurs versions), DELPHI,
ACCESS, DBASE, FOXPRO. Les langages de développement utilisés sont WINDEV
(plusieurs versions), ORACLE forms (plusieurs versions, certaines désormais totalement
abandonnées par l’éditeur), JAVA, PHP, C++, VBA. Les serveurs sont très nombreux,
hétérogènes et répartis dans différents locaux du Ministère. Il n’existe pas à ce jour de
représentation du parc de serveurs, ni de schéma complet du réseau informatique ou des
bases de données.
Fort de ce constat et des discussions avec les informaticiens, il ressort qu’il n’existe pas de
norme technique et méthodologique pour le développement des applications. Selon les
époques, les services et les personnes, des choix différents ont été faits, même si l’AGL
(ensemble d’outils de développement d’application) WINDEV est dominant. Ce choix se
justifiait il y a encore quelques années, mais semble à contre courant aujourd’hui dès qu’il
s’agit d’importantes applications. En effet, de nos jours la tendance est très fortement
orientée vers les applications web.
Nous avons constaté des audits techniques extrêmement pointus sur les bases de données
ORACLE pour SIGFiP et ASTER et nous avons noté les préconisations très générales
formulées par certains consultants sur l’intérêt d’investir dans un centre de données ou de
doter les salles informatiques de serveurs à très haute disponibilité (ce qui inclut une
redondance des serveurs de façon à ce qu’en cas de panne, le second serveur prenne
immédiatement le relais). Il nous semble aujourd’hui que l’étude de l’évolution de
l’architecture technique globale soit devenue une priorité afin de définir les orientations
technologiques de l’informatique du MEF et pour harmoniser à terme l’architecture
technique des applications. Faute d’une telle vision, le MEF risque de continuer à maintenir
des dizaines de technologies plus ou moins obsolètes et de voir des applications qui ne
pourront bientôt plus fonctionner faute de compatibilité avec les technologies plus
récentes. A ce sujet le regroupement des différents serveurs sur des plateformes de
virtualisation constitue une solution intéressante qui est détaillée plus loin (6.3 Avis
de la mission).
Globalement les informaticiens manquent de recul et ont une analyse très partielle de leurs
forces et faiblesses concernant les applications. Il n’y a eu par exemple que peu de besoins
exprimés sur l’automatisation du SI, le besoin de cartographie du SI ou le besoin de
contrôle des données. Les informaticiens sont par contre demandeurs de conseils sur les
technologies à adopter, et sont conscients que WINDEV n’est aujourd’hui plus adapté.
Pourtant aucune étude ou réflexion n’a été lancée à l’échelle du MEF concernant les
technologies à adopter.

Les demandes ont surtout porté sur la mise en œuvre d’un data warehouse (DW). Il s’agit
d’un outil informatique, un logiciel, qui va puiser ses informations dans les bases de
données des applications métiers en exploitation, pour les stocker dans sa propre base de
données de façon à permettre à un utilisateur d’un logiciel de datamining de construire des
informations élaborées. Pour faire un parallèle que chacun pourra comprendre, le DW
correspondrait dans Excel à un tableau croisé dynamique, dont les données de base seraient
issues d’autres feuilles de calcul Excel, feuilles qui seraient l’équivalent des applications
métiers. Le DW ne produit pas d’information nouvelle en soi, il aide l’utilisateur à créer des
tableaux qui agrègent des informations de base. La mise en œuvre d’un DW requiert ainsi
que le SI dans lequel il va puiser ses informations soit préalablement bien intégré, c'est-à-
dire que les interfaces entre applications soient construites. Le DW n’est donc en aucune
façon un outil qui va permettre au MEF d’avoir un système plus intégré, ou qui va
permettre d’avoir des informations plus fiables. Un DW ne reste qu’un outil qui offre une
meilleure visibilité de ses données qui doivent au préalable être parfaitement maîtrisées. Le
DW offre également l’avantage de stocker « à part » une copie des données de production,
ce qui permet de créer dans la base de données du DW des index, des vues, des univers,
etc. c’est à dire des objets informatiques qui vont faciliter la production de ces informations
élaborées, sans pour autant perturber les applications en exploitation. Autrement dit, on
peut se permettre certaines manipulations techniques dans la base de données du DW pour
améliorer les performances, manipulations qu’on ne peut pas se permettre sur les bases de
données de production. Pour construire un DW, dont la finalité reste à déterminer dans le
cas du MEF, il y a des actions préalables à mener que nous recommandons au chapitre
suivant.
Au niveau individuel, les services expriment de nombreuses demandes en termes
d’applications. Nous pouvons citer par exemple des demandes pour des logiciels de :
• gestion des contentieux (AJT),
• suivi des formations (CENAFOC),
• gestion des marchés (DNCMP),
• module de gestion des immobilisations et amortissements dans SISFOM (DRFM),
• suivi de gestion des projets FED (cellule FED),
• gestion du courrier (plusieurs services),
• gestion des stocks et des archives (plusieurs services),
• etc.
Toutes ces demandes sont pertinentes et argumentées. Les plus importantes qui justifient le
lancement d’un projet sont intégrées dans le PESI. Pour les autres, la future DOI doit tenir
à jour un tableau de bord exhaustif de tous les projets en cours et à lancer.
Enfin, notons une demande de la DOI, qui a d’ailleurs été formalisée dans les TdR de la
présente mission, concernant la « dématérialisation ». « La dématérialisation a pour objet de gérer
de façon totalement électronique des données ou des documents métier (correspondances, contrats, factures,
brochures, contenus techniques, supports administratifs,…) qui transitent au sein des entreprises et/ou dans
le cadre d’échanges avec des partenaires (administrations, clients, fournisseurs…).
La dématérialisation, c’est le remplacement des documents papier par des fichiers informatiques, entraînant
la mise en œuvre du fameux "bureau sans papier ". »13.
13 Source : www.infogreffe.fr

Cette demande est motivée pour des raisons de recherche de « performance » de

l’informatique au MEF, et également pour faire « ce qui se fait de mieux ». Ces arguments
ne sont pas suffisants de notre point de vue pour se lancer dans un tel chantier très
ambitieux, et nous recommandons de traiter d’autres sujets bien plus prioritaires et
fondamentaux pour la GFP. En effet, quel pourrait être l’objectif d’une dématérialisation :
utiliser moins de papier pour des raisons écologiques ? Accélérer les procédures de
traitement des dossiers ? Sécuriser les archives ? Certes, tous ces objectifs sont parfaitement
pertinents, et nous recommandons en effet de les inscrire dans le plan général de la
réforme. Mais penser que la dématérialisation, grâce à des outils informatiques, permettra à
elle seule d’atteindre ces objectifs est un leurre. L’informatique ne peut être qu’un support
technique à ces objectifs, mais elle n’est pas suffisante en soi. Nous pensons en outre que la
dématérialisation pose des questions juridiques difficiles : le MEF est-il prêt par exemple à
accepter que les décisions ministérielles soient signées électroniquement et envoyées par e-
mail sans qu’aucun support papier original ne les accompagne ? Ce niveau de
dématérialisation n’est pas atteint dans une grande majorité des administrations du monde,
le MEF n’a certainement pas les moyens de faire partie des précurseurs mondiaux en la
matière. Nous recommandons en revanche, de déployer un logiciel de gestion du courrier
et de gestion des archives (sans pour autant parler de dématérialisation). Le prochain
schéma directeur informatique pourrait à nouveau aborder le sujet de la dématérialisation si
des avancées notables ont été réalisées dans le monde et par le MEF d’ici là.
Les recommandations que nous formulons pour l’évolution à court et moyen terme (2-3
ans) des applications du MEF doivent s’inscrire dans une vision à plus long terme du parc
applicatif. En effet, si l’on ne s’interroge pas sur ce que pourrait être le parc applicatif du
MEF d’ici 10 ans, ou si on ne prend pas en compte les grandes tendances mondiales
actuelles sur l’évolution technique et fonctionnelle des S.I., alors nous risquons de formuler
des recommandations qui améliorent le SI de façon temporaire et non durable, et surtout
de ne pas inscrire le MEF dans la dynamique d’évolution actuelle.
Ainsi, sur la base du SI actuel du MEF, de la tendance de l’évolution générale des SI, et en
tenant compte des capacités du MEF, nous imaginons 3 scénarios possibles d’évolution du
SI du MEF pour les prochaines années :
Scénario 1 « a minima » : consolidation du SI actuel
L’objectif est de conforter le SI actuel dans ses choix principaux :

• le réseau informatique et électrique est renforcé,
• les applications spécifiques actuelles sont progressivement migrées vers des
technologies WEB et continuellement maintenues tant du point de vue technique
que fonctionnel,
• l’automatisation totale du SI est recherchée en développant les interfaces
manquantes et en adaptant les fonctionnalités des logiciels pour assurer la
cohérence, un EAI ou ESB est mis en œuvre et éventuellement ensuite un Data
Warehouse,
• les salles informatiques actuelles sont améliorées et répondent à un cahier des
charges élaboré par le MEF

Ce scénario est le moins risqué et le moins ambitieux, c’est aussi celui qui demandera le
moins de réformes au MEF et qui sera donc le moins difficile à mettre en œuvre.
Selon ce scénario, il existe un risque que l’intégration globale du SI ne se fasse pas
totalement puisque d’un point de vue organisationnel, chaque structure conserve ses
prérogatives et aucune contrainte technique n’oblige à une meilleure intégration du SI.
On cherchera avant tout avec ce scénario à mettre aux normes l’existant sans bouleverser
l’ordre des choses.
Scénario 2 « raisonnablement ambitieux »: Intégration et centralisation du

SI
Ce scénario vise à obtenir un SI très intégré et centralisé. C'est-à-dire que les principales
fonctions de GFP seront gérées dans un logiciel WEB principal qui remplace les autres
applications de GFP actuelles (sauf SYDONIA qui est un standard international qu’il est
préférable de conserver s’il continue à être maintenu par l’éditeur), ce qui va de la
programmation budgétaire à la comptabilité générale, en passant par la gestion des
marchés, le suivi des programmes et la gestion des acquisitions, etc. Toutes les directions
utiliseraient ce même logiciel mais avec bien entendu les niveaux d’habilitations et de
sécurités nécessaires pour éviter tout conflit d’intérêt. Les informations sont alors gérées en
temps réel par les services, de façon sécurisée et transparente. Les régions accèdent
également via le réseau à l’application WEB de GFP.
Le site WEB du MEF diffuse des informations publiques liées à la GFP et permet un début
de e-government.
Les applications autres que celle liées à la GFP telles que la GRH, la gestion du courrier ou
le traitement des pensions, sont autant que possible des progiciels WEB du marché,
partagés par les services, et pour lesquels des contrats de maintenance évolutive et support
(help desk) sont passés avec les éditeurs. Ces progiciels seront bien entendu fortement
interfacés avec la ou les applications de GFP pour éviter la redondance des données.
Un annuaire LDPA est utilisé pour la gestion des utilisateurs.
Afin d’héberger toutes les applications, une seule salle informatique mutualisée répondant
aux standard qualités internationaux est construite en replacement des salles informatiques
actuelles.
Scénario 3 « innovant » : Externalisation du SI
Ce scénario innovant fait le pari que la tendance actuelle du « cloud computing » sera
généralisée dans les années à venir, et suppose que le MEF souhaite dès aujourd’hui se
projeter dans cet avenir.
Il s’agit de passer du SI actuel qui est de type client / serveur non intégré hébergé sur une
centaine de serveurs et déployé sur plus d’un millier de postes informatiques, à un SI cible
hébergé sur une plateforme virtuelle sur Internet (le « nuage »). Il n’est plus besoin de
prévoir d’importants moyens humains et matériels pour l’exploitation du SI (tout est
externalisé), le seul impératif est de disposer d’un accès Internet à haut débit fiable.
Une alternative à ce mouvement radical qu’est l’adoption du « cloud computing » est le
choix d’un hébergeur identifié et localisé dans un pays dont les infrastructures
(principalement électrique et Internet) garantissent une très haute disponibilité.

Ce scénario rencontrera certainement beaucoup de résistance d’une grande partie des

agents du MEF (les gens voudront notamment spontanément conserver leur serveur près
d’eux, et s’inquièteront à juste titre des aspects sécurités). Ce n’est pas pour autant qu’il doit
immédiatement être écarté. A contrario, ce n’est pas parce que ce scénario est novateur
qu’il est le plus intéressant pour le MEF. Nous avons tous connu des « modes »
informatiques qui n’ont pas duré …
Marche à suivre pour le choix du scénario
Le choix du scénario d’évolution du SI du MEF à l’horizon d’une dizaine d’année ne relève

pas de la présente étude qui a pour objectif d’identifier les principaux projets à lancer les 2-
3 prochaines années. Chacun de ces scénarios mériterait en effet d’être développé puis
discuté avec le MEF, le scénario retenu devrait alors être détaillé. C’est ce qui devra être fait
dans un des projets que nous proposons dans le PESI (voir partie B du présent rapport).
Toutefois, même si nous ne pouvons pas présager du scénario qui sera finalement adopté
par le MEF pour l’évolution du SI, du simple point de vue applicatif et quel que soit le
scénario, il implique d’avoir des applications d’architecture WEB. Le scénario 1 serait la
migration progressive des applications existantes vers une architecture n-tiers (c'est-à-dire
WEB), alors que les scénarios 2 et 3 viseraient à refonder le SI en un SI global et intégré
d’architecture WEB. Le choix du scénario engage l’avenir du SI du MEF pour au moins
une décennie et doit donc être fait méthodologiquement. Nous préconisons donc les
actions suivantes :
1. réaliser par reverse engineering les 4 couches de cartographie du SI : processus métier,
fonctionnalités, applications, technique. Ceci peut être fait avec des outils tels que
WIN DESIGN ou AMC DESIGNOR auquel il conviendrait de se former si tel
n’était pas déjà le cas.
2. concevoir l’architecture cible idéale de la couche fonctionnelle. Prévoir à ce
moment là les fonctionnalités utiles aux organes de contrôle pour leur permettre de
contrôler et valider les données de GFP.
3. concevoir une esquisse des couches cibles applicatives et techniques pour chacun
des scénarios
4. étudier en détail les avantages et inconvénients des 3 scénarios, puis en sélectionner
un
5. concevoir l’architecture cible fonctionnelle et technique avec le scénario retenu
Choix technologiques
Pour les technologies à retenir, nous préconisons :

• JAVA pour le langage de développement d’applications, et plus particulièrement
J2EE qui offre le niveau de professionnalisme requis pour le MEF
• le MEF étant déjà familiarisé avec les bases de données ORACLE nous
préconisons de généraliser l’utilisation de ce SGBD pour toutes les applications,
même si ORACLE a un coût relativement élevé par rapport à des SGBD open
source gratuits (tels que MySQL ou PostGreSql)
• l’utilisation d’un outil de conception, tel que WIN DESIGN ou AMC
DESIGNOR, pour concevoir les MCD et autres couches du SI

• l’utilisation de REDMINE, outil open source de gestion des tickets, pour le support
et GLPI pour la gestion du parc informatique
• JOOMLA ou DRUPAL pour le développement de sites WEB, de préférence à
SPIP en n raison du dynamisme de leurs communautés d’utilisateurs
Mise en œuvre d’un EAI / ESB puis éventuellement d’un Data Warehouse
Comme nous l’avons vu, la priorité du SI est donnée à son automatisation. Pour ce faire,
des interfaces « point à point » peuvent être développées. Il s’agit techniquement soit (i)
d’une extraction de données de l’application A vers un fichier « plat » (c'est-à-dire
(c'est un fichier
texte) puis l’import de ce fichier dans l’application B, soit (ii) d’une connexion directe de
l’application A dans la base de données de l’application B et réciproquement.
Cependant, nous avons vu Figure 7 : « Cartographie applicative » partielle liée aux
processus métier GFP qu’il existe près d’une trentaine d’applications pour la gestion des
finances publiques. Si nous considérons que chaque application doit au minimum
communiquer avec une seule autre, cela fait 29 interfaces. En revanche, si nous
considérons que chaque application doit communiquer avec ne serait-ce
serait ce qu’avec 5 autres
(ce qui est une estimation réaliste), cela nous amène à interfaces possibles !
Maintenir autant d’interfaces n’est pas
pas envisageable en l’état actuel de l’organisation et des
moyens du MEF.
Nous préconisons donc la mise en œuvre d’un « EAI » (Enterprise Application Integration) qui
est un outil qui se connecte aux bases de données des applications et gère les flux
d’informations entre toutes les applications. Schématiquement cela peut se représenter de la
façon suivante :
L’EAI offre l’inconvénient d’utiliser des technologies propriétaires (c'est-à-dire

(c'est qu’on est
dépendant d’un éditeur d’EAI) et d’être le moteur de tous les échanges ce qui implique que
si l’EAI tombe en panne plus aucune application ne peut communiquer avec une autre.
Depuis les années 2000, d’autres technologies dont le principe est proche de celui des
« webservices » ont vu le jour. Il s’agit desde ESB14 qui offrent les mêmes avantages
avantage et
fonctionnalités que les EAI, mais qui utilisent des technologies non propriétaires et offrent
l’avantage de ne pas arrêter tout le SI en cas de problème.
Cela étant dit, le choix entre EAI et ESB est très technique et pointu, et doit faire l’objet
d’une étude spécifique. Le principe développé dans le présent PESI est d’utiliser un EAI ou
un ESB pour intégrer le SI du MEF, et contribuer significativement son automatisation.
automatisation
Il peut être envisagé ensuite la mise en œuvre
œuvre d’un Data Warehouse (DW) comme cela est
demandé par les informaticiens du MEF. Mais avant d’implémenter un tel outil, il faudra
impérativement définir l’objectif du DW. Si par exemple l’objectif est de produire les états
financiers du budget, le PIB ou le niveau de recette, cela se fait simplement par des requêtes
adaptées dans les applications actuelles, et il n’est nul besoin d’un DW. Le DW peut se
14 Enterprise Service Bus

justifier si le volume de tableaux à produire est conséquent et varie très souvent,

souvent mais aussi
si la nature
ure et la fréquence des requêtes directes dans les bases applicatives dégradent les
performances en saisie/modification. C'est au vu de cela qu'il faudra décider de passer ou
non par un datawarehouse pour telle ou telle requête. Par ailleurs, un autre point
poin qui sera à
prendre en compte lors de l’étude d’implémentation d’un DW est que, dans le cas de
l'utilisation d'un datawarehouse, les données continuent à être disponibles pour les
décideurs même en cas d'indisponibilité temporaire (panne, etc.) des serveurs
serveu applicatifs
sous-jacents ;
Le DW pourra alors être mis en œuvre APRES l’EAI :
dessus montre que la mise en place directe d’un DW ne simplifiera pas le

Le schéma ci-dessus
nombre d’interfaces à mettre en place : en plus de fournir leurs données aux autres
applications,
pplications, chaque logiciel du SI devra les mettre à disposition du DW, ajoutant ainsi une
interface supplémentaire à chaque fois.
Mise en œuvre d’un support (help desk et hotline)

hot
La conception et le déploiement de logiciels au sein du MEF ne peut se faire de façon

durable en l’absence de support. La fonction support informatique n’est actuellement pas
formalisée, même si les informaticiens apportent forcément un support aux utilisateurs. utilisa
Cependant comme nous l’avons vu, le support ne doit pas être que technique, il doit aussi
être fonctionnel. Nous préconisons dans le nouvel organigramme de la DOI une direction
support spécialisée qui comprend :
• Une hotline : il s’agit d’un standard téléphonique qui permet de répondre en direct
aux demandes
mandes des utilisateurs. La hotline
hotline fait l’interface entre les utilisateurs et le
help desk.
• Un help desk : il s’agit d’un service qui traite les demandes, c’est à dire qu’il archive
les demandes d’intervention,
d’intervention, qualifie la demande, la dirige vers le service compétent
pour y répondre, informe le demandeur de la prise en charge et du délai
prévisionnel de traitement de la demande, et prévient les utilisateurs de la livraison
d’une nouvelle version et des demandes
demandes qu’elle traite. L’outil REDMINE permet
par exemple de réaliser toutes ces fonctions. S’agissant d’un logiciel open source, il
est gratuit et peut tout à fait être personnalisé au MEF

• Un service de formation interne : des experts fonctionnels vont réaliser des

formations spécialisées aux utilisateurs. Ces experts fonctionnels aideront
également le help desk et la hot line notamment pour qualifier les demandes (et y
répondre le cas échéant)
• Un atelier informatique qui prendra en charge les petites réparations matérielles qui
n’auraientt pas besoin d’être sous-traitées, et qui pilotera les prestataires en charge
de la maintenance hard. Le pilotage consiste à suivre les pannes traitées par les
prestataires, évaluer le temps d’intervention, la qualité, le coût (il pourrait d’ailleurs
être intéressant d'interfacer l’application de suivi des pannes avec les factures des
prestataires, afin notamment de pouvoir établir un TCO du parc informatique
(Total Cost of Ownership, ou Coût Total de Possession) ;
Nous préconisons également que les services informatiques restants dans les structures
assurent un support de premier niveau. Ces informaticiens et experts fonctionnels de
proximités seront multi-tâches et peu spécialisés. Dès qu’un problème ne peut être résolu
par eux, ils appelleront le support de la nouvelle DOI qui prendra le relais.
Grâce à la centralisation du support, le MEF aura une bien meilleure visibilité des
difficultés rencontrées en général par les utilisateurs des logiciels. Ainsi des études
statistiques pourront être envisagées, les actions préventives pourront être mieux ciblées,
etc.

5. Sites Internet et Intranet
5.1.1 Présence sur le Web
Le Ministère des Finances dispose d’un site Internet (www.finances.bj) hébergé en France
par la société Sivit et réalisé à l’aide du CMS15
SPIP. Il constitue un portail permettant
d’obtenir des informations institutionnelles sur
le Ministère et ses Directions. Il donne accès à
différents documents (loi de finances, code des
marchés publics, notes de conjoncture, etc.) et
quelques actualités. Un lien est également
présent pour consulter la messagerie, mais il
s’agit là de l’ancien système de messagerie que
quelques personnes utilisent toujours (un
serveur MS Exchange est installé mais son
usage n’est pas encore répandu).
Parmi les Directions et organismes rattachés au Ministère, peu possèdent leur propre site.
Nous pouvons citer :
• la direction des Douanes (www.douane-benin.bj) dont le site est hébergé chez un
prestataire à Cotonou et réalisé en code html (site statique),
• la caisse autonome d’amortissement (www.caabenin.org) réalisé à l’aide du CMS
Joomla et hébergé en Suisse,
• la loterie nationale (www.lnb.bj) hébergé au Bénin et réalisé sous Joomla,
Cependant le site des Douanes ne possède qu’un corpus limité d’information et certaines
rubriques ne sont pas renseignées (par exemple les procédures de dédouanement).
Les grandes Directions Générales comme le Trésor, les Impôts ou le Budget ne possède
pas de vitrine sur le Net et n’ont à leur disposition qu’une page au sein du site du Ministère
des Finances. Il n’y a par conséquent que très peu d’interaction avec le public et les
contribuables.
Les informations d’actualité sont peu mises à jour sur le site du Ministère et la dernière
fonctionnalité majeure qui a été intégrée est le répertoire des prix, fin 2010.
Bien que les sites Internet proposent de nombreux documents en téléchargement, aucun
service pour le grand public n’est proposé (par exemple téléchargement des documents
fiscaux, mise à disposition du code des impôts, lieux et horaires d’ouverture des agences du
Trésor, etc.).
15 Content Management System, ou Gestionnaire de Contenu en français.

5.1.2. Intranet
Le Ministère ne dispose pas de site Intranet. Des ressources réseaux partagées existent ainsi
que quelques répertoires, mais pas de portail dédié à l’information. Ce manque amène les
informaticiens développeurs de la DOI et d’autres directions à produire des outils
informatiques très spécifiques (par exemple une base de données pour l’annuaire des agents
du Ministère) alors que ces fonctionnalités seraient couvertes s’il y avait un véritable
Intranet. Il en résulte que la communication est faible au sein du Ministère et la diffusion de
l’information demeure lourde et assez inefficace.
Cependant une installation de MS Sharepoint server est en cours mais son utilisation se
heurte à des difficultés de prise en main (voir plus bas).
Point commun aux aspects Internet et Intranet, s’il existe une cellule de communication au
Ministère, elle ne semble pas être en relation régulière avec le service en charge du site web.
Les directions qui ne possèdent pas encore de site Internet en font la demande et ces
demandes font ou ont fait l’objet de projets financés par des bailleurs. C’est le cas de la
DGID qui demande un site Web dont le financement est prévu sur le DP1 signé avec la
DUE ou encore le besoin exprimé par les structures judiciaires du Ministère de voir les
textes et règlements publiés sur Internet pour en assurer la plus large diffusion (là encore
un budget est prévu sur le même DP).
Nous constatons aussi que les sites existants ne disposent pas de toute l’information que les
utilisateurs d’aujourd’hui sont en droit d’attendre et que leur potentiel n’est pas
convenablement exploité faute d’une mise à jour suffisamment fréquente et adéquate.
Le déploiement d’un Intranet à l’échelle du Ministère (y compris ses directions et services
annexes) est voulu par les équipes informatiques de la DOI, mais elles se trouvent dans une
impasse concernant la mise en œuvre du logiciel MS Sharepoint Server. Des connaissances
leur manquent et le temps disponible à l’autoformation est insuffisant. Elles sollicitent donc
une assistance.
La mise en œuvre de ce système requiert naturellement un réseau informatique performant
et homogène, lequel fait l’objet d’une étude plus loin dans ce document.
5.3.1 Fonctionnement et mise à jour du site Internet
Le site Internet du Ministère est un outil stratégique autant que de communication. Il

informe les Béninois sur l’actualité des finances de l’Etat mais permet également aux
partenaires du pays d’obtenir des données officielles sur le Bénin. Le Ministère doit
conserver le contrôle de ses données et régulièrement fournir du contenu au site afin de
satisfaire les besoins d’informations sans cesse grandissant du public. Un site Internet est
une vitrine pour l’institution qui en possède un, et à ce titre doit faire l’objet d’une attention
toute particulière. En tant que Ministère régalien, le Ministère de l’Economie et des

Finances doit penser son site comme un portail vers l’ensemble des données financières,
fiscales, douanières, etc. du pays.
La mise à jour et la dynamisation du site Internet du Ministère rend nécessaire une
collaboration encore plus étroite entre la DOI et la cellule de communication. Des réunions
régulières doivent être programmées sur un rythme hebdomadaire afin de faire le point sur
les informations à publier sur le site. Les informations discutées à ce niveau concernent des
communiqués de presse ou des brèves d’actualités sur le Ministère dans son ensemble (par
exemple l’agenda du ministre, l’avancement de certains projets, les nouveautés
réglementaires, etc.). Ces réunions n’auront pas vocation à être très longues mais doivent
déboucher sur une mise en ligne rapide (24 à 48h maximum) de ce qui y aura été décidé.
Une actualité plus urgente pourra faire l’objet d’une réunion ad hoc et d’une mise en ligne en
dehors des réunions programmées.
Ce fonctionnement implique que la DOI conserve les actions de mise à jour du site sur
demande de la cellule de communication. Cependant ceci doit laisser la place à une plus
grande autonomie de la cellule en matière de mise en ligne d’informations. Lorsque la
plateforme finale sera déployée (voir plus bas la capitalisation des outils), les agents de la
cellule de communication devront être formés à l’utilisation des mécanismes de publication
afin de devenir autonomes, la DOI conservant un rôle technique (nouvelles versions,
nouvelles fonctionnalités, résolution de problèmes, etc.).
Concernant les informations récurrentes et vivantes, telles
que le PIB, les recettes, les dépenses, la liste des
entreprises déclarées, les appels d’offres en cours, le
barème des perdiem du pays, etc. (il existe une grande
quantité d’informations de ce type), il doit être décidé
quelles sont celles qui sont intéressantes à publier pour le
public, en s’inspirant si nécessaire des informations
publiées par d’autre MEF (voir par exemple ci-contre un schéma
issu du site du Ministère Français du Budget 16). Pour publier ces
informations, un Data Warehouse peut être utile, mais ce n’est pas obligatoire. Il est
techniquement simple de développer une interface d’une application (SIGFiP ou ASTER
ou SYDONIA, etc.) pour alimenter automatiquement la base de données du CMS du site
WEB. Ainsi toutes les informations publiques contenues dans les applications métiers de la
GFP peuvent très facilement être mises en ligne, ce qui donnerait une excellente image au
MEF.
Par ailleurs un comité d’animation du site web doit être créé (ou réactivité puisqu’il semble
qu’il existe déjà) afin d’étudier les évolutions du site et de corriger les dérives qui seraient
éventuellement constatées (problème d’accès, erreurs de mise en page, mauvaises ou
nouvelles rubriques, etc.). Ce comité devra alors réunir une à deux fois par trimestre un
représentant du ministre, un responsable de la DOI, de la cellule de communication et des
directions (à déterminer) ne disposant pas de site en propre.
16 Graphique extrait du site http://www.performance-publique.gouv.fr/le-budget-et-les-comptes-de-

letat/approfondir/tableau-de-bord/toutes-administrations-publiques.html

Recommandations :
• mise en place de réunions hebdomadaires entre DOI et cellule de
communication
• formation des agents de la cellule de communication sur la publication de
contenu à l’aide des outils de la plateforme Internet retenue in fine
• formation des agents du Ministère (toutes directions) en charge de fournir
du contenu aux techniques de rédaction pour le web
• Etudier les interfaces possibles entre les applications métiers de GFP et le
portail Internet
5.3.2 Déploiement d’un Intranet
L’existence d’un véritable Intranet est essentielle pour une bonne communication au sein
d’un organisme. Cet outil permet de constituer un référentiel de textes et règlements
d’ordre pratique (règlement intérieur, notes de services, statut du personnel, formulaires
administratifs) à destination des agents du Ministère ainsi que de mettre à disposition un
annuaire centralisé des personnes. Il est tout autant envisageable d’y intégrer des
formulaires de réservation de salles de réunion, de location de matériel (projecteurs pour
réunions) ou de demande de mission. Cet Intranet doit également permettre la mise en
œuvre d’espaces dédiés à des équipes œuvrant sur des projets communs.
L’Intranet doit aussi être une plateforme privilégiée d’accès à l’information financière du
pays pour les décideurs. Ces informations proviendront des systèmes utilisés par les
différentes directions (Sydonia++, Aster, SIGFiP, Takwe, Sunkwe, etc.) afin de fournir les
données d’un tableau de bord de suivi des finances de l’Etat. Les accès seront protégés et
donnés à des profils spécifiques. Les données seront agrégées grâce à un mécanisme d’EAI
dans un entrepôt de données (data warehouse) dans lequel l’Intranet puisera les
informations dont il a besoin. Ainsi à tout instant le ministre, les directeurs et leurs
conseillers disposeront de données en temps réel sur l’exécution des recettes et des
dépenses.
En ce sens la mise en œuvre de MS Sharepoint par la DOI est pertinente et va dans le sens
de la construction d’un système informatique homogène basé sur des technologies
communes et communicantes (en l’occurrence l’écosystème applicatif de Microsoft).
Cependant le déploiement d’un tel système n’est pas anodin et requiert des compétences
que la DOI admet ne pas totalement posséder. Une assistance doit donc être envisagée
pour (i) définir clairement le contour fonctionnel de l’Intranet, au besoin sur plusieurs
phases, (ii) préparer la mise en œuvre en mode projet (installation initiale et configuration,
développement des fonctionnalités décidées préalablement, déploiement), (iii) renforcer les
capacité des équipes concernées de la DOI (formation du l’outil) et (iv) accompagner le
changement en sensibilisant les agents du Ministères ainsi que l’encadrement à l’importance
de cet outil pour assurer une meilleure communication.

Recommandations :
• mobilisation d’une assistance technique pour la mise en œuvre de l’Intranet
du Ministère sur la base de MS Sharepoint
5.3.3 Identité visuelle et capitalisation des outils
Les bases techniques sur lesquelles est construit le site Web devront être revues à l’aune des
possibilités offertes par le système MS Sharepoint car cet outil permet également de créer et
d’automatiser un site Internet. Une étude devra être menée pour décider si MS Sharepoint
deviendra la fondation d’un nouveau site web ou si une solution indépendante sous la
forme d’un CMS plus moderne doit être conservée.
Enfin une certaine identité visuelle (charte graphique) doit être maintenue entre les
différents sites Internet des Directions Générales du Ministère. Elle peut prendre la forme
d’une gamme de couleurs commune, d’un format de page commun ou simplement de
logos et/ou de quelques éléments visuels communs afin de renforcer aux yeux du public
internaute l’appartenance de ces Directions au Ministère de tutelle.
Des outils communs doivent être choisis pour la réalisation de ces sites afin de mutualiser
et capitaliser les compétences techniques des équipes de développement.
Recommandations :
• définir une charte graphique unique pour l’Intranet et l’Internet du
Ministère (y compris les sites des Directions Générales)
• sélectionner un outil commun pour réaliser les sites Web des structures
(MS Sharepoint ou Drupal ou Joomla)

6. Parc informatique
Le Ministère des Finances dispose d’un équipement informatique assez conséquent. Si l’on
compte les postes informatiques disponibles dans les administrations centrales (Ministère,
Directions Générales, organismes
sous tutelle) et dans certains Figure 10 : Parc informatique constaté
services régionaux (notamment les
postes dédiés à SIGFiP), nous
arrivons à plus de 1400
postes (voir ci-contre). Le nombre
réel de poste est encore supérieur
puisque les données de certains
services ne nous ont pas été
communiquées17.
Les postes déployés en région
pour le Trésor par exemple ne
sont pas non plus comptabilisés. Il
y a donc probablement plus de
1500 ordinateurs déployés au sein
du MEF, ce qui est considérable.
Le décompte est aussi conséquent
en termes de serveurs
informatiques. Le recensement
réalisé par la DOI et transmis à la
mission fait ainsi état de près de
100 unités, sachant qu’un serveur
est considéré comme tel lorsqu’il
héberge une application ou une
base de données utilisée par
plusieurs utilisateurs (cette
définition inclus donc les postes
de travail qui sont utilisé comme
serveur). La DGDDI a besoin
d’un grand nombre de serveurs
(28) en raison du nombre de
postes douaniers devant être équipés de leur propre serveur SYDONIA++ par manque de
moyen de communication avec la direction générale à Cotonou
17 Les données complète que nous avons recueillis peuvent être consultées sur le portail, et en particulier sur la page :
http://www.e-sud.fr/client/PESI_Benin/donneesPESI.htm . Lorsqu’une donnée n’a pas pu être fournies lors de
l’entretien ou si la fiche d’enquête ne nous a pas été retournée, la case est laissée vide

L’état de fonctionnement des postes informatiques est globalement satisfaisant et les

services parviennent à en assurer la maintenance et le renouvellement, soit sur budget
propre, soit grâce aux interventions des PTF. Par contre cette disparité des sources de
financement a un impact sur l’homogénéité du parc informatique. En raison des règles
régissant les passations de marchés il n’est pas possible au Ministère de définir précisément
une marque et/ou un modèle d’ordinateur privilégié. Il n’est pas envisagé non plus de
définir un contrat cadre sur 2 à 3 ans avec un fournisseur particulier pour être certain de
toujours avoir la même configuration de poste.
Les équipements périphériques (imprimantes, scanners, onduleurs) sont également répartis
de manière assez inhomogène. Par exemple l’IGF ne possède aucun onduleur ou le CF
dispose de plusieurs imprimantes de marques et types disparates (Canon, HP, laser, jet
d’encre) dont certaines sont hors service. Cette disparité a un impact sur les coûts
d’approvisionnement en consommables et sur les coûts de maintenance.
L’environnement dans lequel sont placés tous ces équipements n’est pas toujours idéal. Les
bureaux sont parfois surchargés et/ou ne bénéficient pas de mobilier adéquat pour
positionner correctement les ordinateurs. L’absence de climatisation dans certains locaux
est préjudiciable aux équipements dans un pays fortement humide, et la poussière ne
favorise pas un fonctionnement durable. Il est fréquent de constater une succession de
prises multiples sur lesquelles se trouvent plusieurs équipements (ordinateurs, écrans,
onduleurs, imprimantes). Il n’est également pas rare de voir des imprimantes laser
connectées aux onduleurs, ce qui raccourcit l’autonomie et la durée de vie des batteries (une
imprimante laser consomme beaucoup de courant lors de sa phase de préchauffage).
Le nombre de serveurs pose la question de leur bon usage. Nous avons dit plus haut que le
cas de la DGDDI est particulier, mais il va évoluer avec la mise en réseau de tous les postes
douaniers à l’horizon fin 2011. Par contre dans de nombreuses autres administrations une
rationalisation est possible. Le constat est en fait qu’à chaque création d’une application
nécessitant une base de données, un serveur est mis en place. Les machines ainsi déployées
ne sont utilisées qu’à quelques pourcents de leurs vraies capacités alors que chaque ajout
d’un serveur entraîne des contraintes fortes : charge sur le réseau électrique, besoin
d’onduleur, nécessité de programmer des backups, protection logicielle (antivirus), licences
serveur et utilisateurs (si Windows), etc. Cet « écosystème » entourant chaque serveur a un
coût financier et représente une charge de travail supplémentaire en termes
d’administration.
Ces serveurs sont regroupés dans des salles qui ne sont pas prévues pour cela. Par exemple
la DOI regroupe 14 serveurs (réels ou postes de travail reconvertis) dans un demi-bureau
par ailleurs occupé par au moins 4 agents, la DGB dispose de ses 13 serveurs dans 2 pièces
qui servent également de bureaux, la DGTCP réparti les siens sur 3 salles, etc. Il semble
que seule la DGDDI dispose d’une pièce suffisamment grande et dédiée pour ses serveurs
SYDONIA++. De plus les salles en question sont, dans leur grande majorité, dépourvues
de toute sécurité électrique (absence de mise à la Terre) et leur climatisation n’est pas
garantie, de même que leur alimentation électrique en cas de panne de courant. Le MEF n’a
pas défini de cahier des charges pour l’aménagement de ses salles serveurs, aucune norme
n’a été définie.
La gestion du parc informatique est en grande partie manuelle. La configuration des postes
de travail n’est pas centralisée et ils ne sont pas systématiquement attachés à un domaine

Windows. Pourtant cela rendrait beaucoup plus simple la gestion des adresses des machines
sur le réseau, le paramétrage de la sécurité des postes (mots de passe, privilèges, antivirus,
pare feu) ou encore la diffusion d’un environnement de travail homogène (espaces disques
partagés). La gestion des serveurs souffre des mêmes maux avec, en plus, différentes
versions des systèmes (Windows server ou, plus souvent, Linux) et des bases de données.
Enfin l’inventaire exact et à jour de ce parc est très difficile à maintenir, pour preuve la
collecte d’informations lancée par la DOI à l’occasion de la mission et qui n’a pas obtenue
toutes les réponses. Cela démontre le manque de pouvoir et/ou de moyens de la DOI à
remplir ce rôle qui est pourtant dans ses attributions.
La maintenance des machines informatiques est assez bien assurée par les différents
informaticiens du MEF. Néanmoins les moyens font souvent défaut, surtout lorsqu’il faut
faire appel à un prestataire. Par exemple l’IGF possède un onduleur de 15kVA qui est hors
service depuis plusieurs années et il n’est pas rare que les agents doivent attendre des
semaines voire des mois pour qu’un climatiseur soit réparé. De plus il s’agit très souvent
(pour ne pas dire exclusivement) de réagir à une demande d’assistance selon le temps
disponible au moment de la demande. En d’autres termes il n’y a pas de planification des
maintenances et des interventions ni de trace de ces interventions (lieu de la panne, motif,
solution apportée, résultat, temps passé). En conséquence il n’y a pas de partage des
connaissances gagnées lors de la résolution des problèmes et, donc, une inévitable perte de
temps lorsque la même panne se répète.
Concernant les espaces de stockage et de sauvegarde, il n’existe pas de ressources partagées
significatives sur les réseaux rencontrés. Au mieux trouve-t-on des répertoires partagés sur
telle ou telle machine, mais pas répertoire de groupe sur un serveur. De même n’existe-t-il
pas d’espace volumineux de stockage. Les espaces disponibles sur le réseau sont pris sur les
disques durs des serveurs. Ils sont donc limités et empiètent sur l’espace utilisable par le
serveur lui-même. Ce manque empêche de mettre en place des mécanismes de sauvegarde,
comme par exemple dupliquer les fichiers de travail des agents (ils sont sur leur machine,
mais également sur la zone de stockage) pour pouvoir, le cas échéant, centraliser leur
écriture sur des bandes. Ces espaces de stockage peuvent aussi servir de bibliothèque de
documents et/ou de logiciels à usage professionnel.
La majorité des demandes dans ce domaine consiste en équipements récents. Nous l’avons
dit certains services sont totalement dépourvus de matériels de base comme des onduleurs.
D’autres possèdent plusieurs machines et imprimantes hors service, qu’il faudrait réparer
mais pour lesquels les moyens manquent.
Parmi les besoins constatés figurent les systèmes permettant de répondre aux défauts
décrits plus haut :
• une configuration homogène des postes de travail pour une gestion centralisée plus
simple. Cela passe par la mise en domaine de tous les postes ;
• adoption d’un outil de gestion de parc informatique, comme GLPI par exemple
(solution libre). L’inventaire de toutes les machines informatiques pourra y être
suivi ;

• adoption d’un système de suivi des tickets d’incident pour déterminer les priorités
d’intervention, identifier rapidement les problèmes graves, constituer une base de
connaissances et rendre compte du temps passé à la résolution de tous ces
problèmes. Cette dernière mesure permettant de mieux justifier certains
investissements.
Il apparaît également nécessaire de standardiser au mieux les équipements et logiciels
utilisés par le plus grand nombre et la standardisation des serveurs est très importante pour
alléger leur administration et leur coût.
Le besoin de rationaliser le nombre de salles informatiques est patent, ne serait-ce que pour
garantir la bonne conception de celles qui existeront finalement. Le besoin exprimé par la
DOI de construire une salle informatique aux normes internationales pour le Ministère est
ainsi parfaitement justifié (voir chapitre 7.3).
Enfin l’environnement électrique est crucial, et nous le traitons au chapitre 8.
Plusieurs actions sont à mener pour améliorer le parc informatique et sa gestion. La taille
du parc justifie que la gestion de celui-ci se fasse de façon « industrielle » avec des solutions
professionnelles éprouvées. Un parc de plus de 1500 serveurs et ordinateurs ne se gère pas
comme un parc de quelques dizaines d’unités.
Il faut tout d’abord garantir le financement du remplacement d’une partie des postes de
travail chaque année en se basant sur la durée d’amortissement. Sur 4 ans, cela requiert
d’acquérir chaque année 25% du parc installé, soit l’achat d’au moins 375 postes chaque
année ! Cette durée peut être modulée en fonction des contraintes budgétaires, mais elle ne
doit pas excéder 5 ans en raison des conditions environnementales dans lesquelles sont
utilisés les postes (poussière, humidité, électricité). Si cela est impossible, alors le strict
minimum est de garantir un budget permettant de réparer/remplacer les postes en défaut.
L’acquisition de nouveaux équipements (ordinateurs, imprimantes, onduleurs, serveurs)
doit se faire en respectant des caractéristiques établies et approuvées par la DOI. Nous
donnons en annexe quelques caractéristiques pour des équipements tels que ordinateurs de
bureau, imprimantes, onduleurs ou encore serveurs. Elles représentent selon nous le
minimum à demander auprès des fournisseurs lors de nouvelles commandes. La DOI
pourra les enrichir et les préciser encore un peu plus tout en restant dans les limites
acceptées par les règles des marchés publics. Elle veillera aussi à les mettre à jour à
échéance régulière, par exemple chaque année ou chaque deux ans. Une fréquence trop
élevée en effet irait à l’encontre de la standardisation souhaitée car chaque commande
subirait de facto la loi de l’évolution technologique, ce qui n’est pas souhaitable si l’on veut
conserver la maîtrise de son parc informatique.
Chaque service qui souhaite s’équiper devra chercher l’aval de la DOI via son service
informatique pour le matériel visé. L’idéal est que le Ministère, via la DOI, passe des
accords par appels d’offres avec des constructeurs qui lui garantiront la disponibilité de
quelques configurations standard sur une période de 2 à 3 ans en contrepartie de
l’assurance d’un nombre minimal de commandes par an. En se basant sur un

amortissement de 5 ans, le Ministère (dans sa globalité) est en mesure d’assurer l’acquisition

de près de 1440/5=288 ordinateurs par an, sans compter les imprimantes et onduleurs. De
manière générale, tout achat informatique doit être coordonné avec la DOI.
Une réflexion doit être menée en interne du MEF sous l’impulsion de la DOI afin de
sélectionner le système d’exploitation standard pour tout le MEF et les applications
bureautique.
Une première possibilité est de choisir de régulariser toutes les licences microsoft
(un contrat global doit être négocié avec microsoft qui peut proposer des prix très
fortement réduits par rapport à des achats individuels), et d’adopter ainsi
« officiellement » microsoft windows 7 pro par exemple, et microsoft office
enterprise 2010. Les versions windows doivent, dans la mesure du possible, être
configurés avec les versions professionnelles de Windows (XP pro, Vista pro et
maintenant 7 pro) pour pouvoir être migrés au sein d’un domaine géré par un
serveur Windows (2003 R2 ou 2008). En effet les versions personnelles (home) en
sont incapables. Cette demande doit figurer sur les commandes de matériel : ne pas
accepter de versions non professionnelles. La configuration des postes actuels doit
être menée à terme, notamment au sein du Ministère où encore de nombreux
postes n’ont pas migrés sur le domaine. Cela doit être fait rapidement. Les
mécanismes de politiques de sécurité (ou GPO) existant dans Windows Server
doivent être utilisées pour diffuser largement et automatiquement les configurations
des postes de travail (privilèges, protections, accès aux ressources, etc.).
Une seconde possibilité est d’opter pour des solutions open source telles que Open
Office pour les logiciels bureautiques, et linux pour le système d’exploitation. Cette
solution offre de nombreux avantages tels que le coût nul, et une meilleure
résistance aux attaques virales, mais oblige le MEF à déployer des formations à
grande échelle pour l’utilisation de ces nouveaux outils (ce qui a un coût).
La protection par un antivirus centralisé doit être généralisée. Elle existe déjà au Ministère
par la DOI et à la DGB et doit être étendue. Là encore le Ministère, par la DOI, doit
sélectionner un antivirus adapté à ses besoins et acquérir les licences nécessaires pour
équiper la totalité des postes. Ce choix unique permet de bénéficier de réductions grâce au
volume, et facilite la maintenance et la mise à jour : un seul serveur télécharge les mises à
jour pour la totalité des postes.
L’homogénéité des versions de logiciels système pour les postes de travail vaut aussi pour
les serveurs : une version commune de Windows Server et une version commune de Linux.
Il faut également converger vers une version commune d’Oracle et des différents outils
afférents, ceci toujours dans le but de diminuer les coûts d’acquisition, de maintenance et
de cibler les formations.

La convergence des versions Figure 11 : Copie d'écran d'un logiciel de gestion de parc
des logiciels permet informatique
d’envisager la mise en place
d’un outil de gestion de parc
informatique. Ce type d’outil
se compose d’un petit
programme client qui est
déposé sur les postes du
réseau et d’une base de
données qui recueille
ecueille les
données des clients. La base
contient alors les détails du
matériel inventorié et des
logiciels présents dans le
réseau. De nombreuses
solutions existent : Landpark
Manager, VisionSoft, etc
pour les outils commerciaux
et le couple
OCSinventory/GLPI
/GLPI (copie
d’écran ci-contre)
contre) pour une
solution libre. Généralement
une interface web permet de
consulter et gérer l’ensemble.
La DOI doit mettre en place un help desk et un système de gestion des incidents. Là
encore plusieurs logiciels existent (Redmine
(Redmine par exemple). Une telle solution est
indispensable pour une gestion rationnelle du temps des informaticiens et pour la
constitution d’une base de connaissance partagée par tous.
Enfin les financements disponibles pour mettre en place des salles informatiques
informat existent
dans différents projets. Le Ministère et la DOI doivent les coordonner pour mutualiser les
capitaux disponibles et construire un nombre limité de salles informatiques avec toute la
sécurité requise. C’est le cas au Ministère avec le projet dee datacenter (voir plus loin) et il est
recommandé de ne conserver qu’une salle par localisation géographique. Dans cette
optique, la DGB comme tous les services hébergés dans le bloc technique et dans le
bâtiment du cabinet n’a plus besoin de disposer d’une d’une salle serveur. La DGTCP ou la
DGID, proches du Ministère,
Ministère, peuvent conserver une salle mais de taille réduite. Elles
pourront héberger des serveurs de secours (backup) et un nombre réduit de serveurs de
production qui auront leur backup dans le datacenterdatacente du Ministère.. La gestion de
l’exploitation de ses serveurs reviendra à la DOI, mais l’accès aux données sera réservé aux
agents des directions concernées.
La réduction du nombre de serveurs pourra se faire non seulement en hébergeant plusieurs
applications
ons par machine, mais aussi (et peut-être
peut être surtout) en étudiant les possibilités de
virtualisation. Un nombre limité de machines physiques,, correctement dimensionnées
(processeurs, mémoire, espace
space de stockage) et reliées par un réseau performant (câbles
gigabits
abits au minimum, voire en fibre optique) doit permettre de manipuler les serveurs de la
même manière qu’on le ferait avec une application. Un système d’exploitation spécifique

(hyperviseur de type 1 ou natif) est installé sur le serveur principal, puis l’administrateur
crée autant de machines virtuelles qu’il le souhaite et les stocke sur les espaces de stockage,
le système d’exploitation se chargeant de les faire « fonctionner ». Un avantage indéniable
de cette solution est la possibilité d’effectuer des sauvegardes totales des machines qui se
manipulent alors comme de simples fichiers : la totalité de la machine serveur ainsi créée
tient en un ensemble fini de fichiers informatiques qui contiennent l’état de la « mémoire »,
du « disque dur », du « processeur », etc. Il est en plus possible de déplacer une machine
virtuelle d’un espace de stockage vers un autre, voire d’un serveur physique vers un autre,
aussi simplement que de déplacer des fichiers d’un disque à un autre, le tout étant géré par
le système d’exploitation spécifique.
Le but est bien de diminuer les coûts de construction et d’exploitation des salles serveurs
en faisant le meilleur usage possible des financements disponibles.
Recommandations :
• mettre en place des configurations types pour les différents équipements et
s’y tenir pour tous les achats
• renforcer le rôle de la DOI dans la coordination des investissements
(matériels, logiciels, salles informatiques)
• consolider la configuration des postes de travail : migration dans le
domaine Windows, déploiement des politiques de sécurité, déploiement
d’un antivirus centralisé et commun à toutes les directions
• choisir et acquérir un outil de gestion et supervision de parc
• créer un service de help desk et l’équiper d’un outil de suivi des tickets
d’incidents, former les informaticiens et sensibiliser les utilisateurs
• réaliser une étude de marché sur les hyperviseurs de type 1 afin de
déterminer le meilleur système de virtualisation et programmer la migration
des serveurs physiques vers leur équivalent virtualisé

7. Réseau informatique local et étendu
7.1.1. Architecture
Le réseau informatique global est composé de plusieurs réseaux locaux (un par bâtiment)
reliés entre eux par des liaisons fibre optique, radio ou satellite selon l’éloignement constaté.
Une grande partie des structures appartenant au Ministère de l’économie et des finances est
ainsi mise en réseau.
Interconnexion entre régions
Le maillage du pays est réalisé par liaison radio (Porto Novo) et par satellite :
Communication du Ministère à travers le pays
Interconnexion dans une région
Dans les régions, l’arrivée du signal se situe au niveau des préfectures qui, ensuite, relaient
la liaison par boucle locale radio aux structures connectées, ce qui pour Porto Novo donne
le schéma suivant (la situation est similaire dans les autres régions, les structures connectées
pouvant être différentes) :

Implantation boucle radio à Porto Novo

Le système en place à Porto Novo montre que des structures étrangères au Ministère de
l’économie et des finances utilisent la liaison radio en place pour leurs propres besoins. Il
en est ainsi car, à Cotonou, le Ministère fait également office de point central dans le réseau
informatique gouvernemental et, à ce titre, d’autres Ministères et institutions utilisent son
infrastructure. C’est le cas de la Présidence de la République, du Ministère de la Justice, de
la Législation et des Droits Humains, du Ministère Délégué Chargé des Technologies de
l’Information et de la Communication auprès du Président de la République ou encore du
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique.
Interconnexion au siège à Cotonou
Physiquement, le Ministère à Cotonou est implanté sur deux bâtiments situés sur le même
terrain : un bâtiment technique (« bloc technique ») et le cabinet du Ministre. Dans le bloc
technique se trouvent les directions du Budget (DGB), de l’organisation et de
l’informatique (DOI), le contrôle financier (CF), l’inspection générale des finances (IGF).
L’ensemble des liens réseaux externes (radio, VSAT) arrivent et partent au niveau de la
direction du Budget. Le schéma synoptique global montre que la DOI n’est qu’une
direction comme les autres sur ce réseau, avec néanmoins la particularité de fournir l’accès
Internet au Ministère et aux structures qui en font la demande.
Le cœur du réseau est donc situé au sein de la direction du Budget.

Bo
ucle
loc
ale
r ad
io C
o to
nou
INTERNET
DSIA, RFA, METFP, MPMEPSP, MU, MJLDH,

CF MAPLN, AGEFIP, MCPTN, CC, CAA, MDN, MSP,
DOI MESRS, MTPT, HAAC, MJSL, MEMEH, CES,
Présidence République, MDGLAAT, MCRI, MRAI
DGB
IGF
MEF
Bloc
Technique
MEF
Cabinet
Ministre
FED
DGID IGF Réseau local

DGTCP
Liaison fibre optique
Liaison réseau Ethernet
DGDDI
Schéma de principe du réseau à Cotonou
Direction Générale des Douanes

La direction générale des Douanes (DGDDI) présente ici la particularité de mettre en place
son propre réseau national afin de relier tous les postes de douane. Un projet, financé par le
MCA (Millenium Challenge Account) et une participation nationale, vise à rénover certains
postes douaniers, à y installer un réseau local et à relier le tout à la direction générale par
liaison VSAT et lignes spécialisées. Les équipements sont en cours de livraison et les
installations vont se faire avant la fin de l’année. Néanmoins Bénin Télécom, prestataire
pour les lignes spécialisées, n’est toujours pas en mesure d’en assurer la fourniture, ni la
facturation alors que les équipements arrivent. Le MEF doit s’impliquer au plus haut niveau
auprès de Bénin Télécom pour faire avancer ce dossier.
Direction Générale des Impôts

La DGID tente également d’être en contact direct avec les bureaux régionaux et locaux tels
les CIPE/CIME. Les connexions se font sous forme de boucle locale radio, mais des
intempéries en 2010 ont rendu le matériel inopérant. Il est prévu de les remettre en état au
cours de cette année 2011.

Direction Générale du Trésor et de la Comptabilité Publique

La DGTCP rencontre de graves problèmes de fonctionnement sur son réseau local. Celui-
ci est relié au reste du Ministère via une liaison en fibre optique sur la DGB, mais un défaut
de configuration sur un ou plusieurs équipements rend le réseau local quasiment inopérant.
Les agents perdent alors très fréquemment la connexion avec les bases de données qu’ils
utilisent (notamment Aster et SIGFiP). La solution actuelle est de déconnecter le réseau de
la DGTCP d’avec le reste du Ministère. Ce faisant les agents accèdent alors normalement à
leurs bases de données. Un tel cas a été constaté par la mission lors de la mise en paiement
de la solde. L’enregistrement des opérations a été arrêté le temps d’isoler le réseau de la
DGTCP. La DOI est informée depuis longtemps, mais faute de temps et/ou de moyens le
problème perdure. Néanmoins les travaux démarrés récemment sur le réseau global
devraient permettre de résoudre ce souci.
Agence Judiciaire du Trésor

L’AJT est une structure très importante au sein du Ministère car elle suit les contentieux
judiciaires jusqu’à leur résolution. Elle manipule de nombreux dossiers qui peuvent être très
volumineux et nécessiter l’intervention de plusieurs agents sur une durée de plusieurs mois,
voire plus. Malgré cela l’AJT ne dispose d’aucun moyen informatique et n’est bien sûr pas
connecté à la DGTCP pour pouvoir vérifier les dossiers des parties impliquées dans les
contentieux.
Cellule de Surveillance des Structures Financières Décentralisées

La CSSFD dispose d’un réseau local mais ce dernier n’est pas interconnecté au MEF. La
DOI a fait installer une antenne radio mais elle est tombée. La CSSFD attend une solution
de financement pour pouvoir remettre en état cette liaison radio.
7.1.2 Configuration
Le Ministère dispose d’un domaine Windows2003 (« finances.local ») avec Active Directory

et d’un contrôleur de domaine secondaire. Historiquement les postes informatiques
obtenaient leur adresse sur le réseau à partir du serveur de domaine. Il y a un an la DOI a
choisi d’utiliser un autre plan d’adressage et d’attribuer les adresses de manière statique (le
serveur DHCP pouvant ne pas être joignable). Le processus de changement est toujours en
cours et rencontre des réticences (un tiers des postes n’a pas encore basculé) car cela
s’accompagne d’une modification des droits de l’utilisateur sur sa machine (restriction). Si la
plupart des postes informatiques sont inscrits sur le domaine, il en reste encore beaucoup
qui ne profitent pas pleinement des ressources du réseau. Parmi les autres directions et
Ministères certains possèdent leur propre serveur de domaine et leur propre nom de
domaine, bien que la DOI favorise l’utilisation de sous domaines de « finances.local ». A
noter que la DGID en avait un dans le passé mais il n’est plus opérationnel (cf. audit
informatique réalisé à la DGID en début d’année).
L’accès à Internet est géré par la DOI pour les bâtiments du Ministère et pour quelques
structures extérieures (CENAFOC, LNB et Présidence de la République). Les autres
directions et Ministères possèdent leur propre accès. La présence de deux plages d’adresses

sur le réseau local du Ministère amène la DOI à maintenir deux accès à Internet, l’un au
travers d’un serveur proxy sous Linux, l’autre au travers d’un serveur ISA.
Un serveur de messagerie sous MS Exchange 2007 est présent sur le réseau mais tous les
utilisateurs n’y possèdent pas encore un compte. La raison invoquée tient au nombre de
licences détenues qui est insuffisant. L’ancien serveur de messagerie, Roundcube, fourni
par l’hébergeur du site (société Sivit en France) est ainsi toujours utilisé et accessible depuis
le site Web. Le serveur MS Exchange est destiné aux postes pleinement inscrits sur le
domaine.
Enfin un serveur DNS spécifique est en place également dans le réseau afin de fournir ses
services aux machines du réseau local. Il est cascadé avec les serveurs DNS du fournisseur
d’accès à Internet.
La Direction Générale du Budget gère indépendamment un réseau parallèle réservé aux
postes SIGFiP. Au Ministère ce réseau utilise le câblage existant mais le routage se fait dans
des switchs et routeurs dédiés non connectés aux autres équipements. Dans les structures
utilisant SIGFiP (Directions Générales, Ministères, régions), un câblage spécifique est
déployé à chaque fois pour les postes SIGFiP (à Porto Novo par exemple, un réseau local
sous domaine Windows existe à la préfecture, mais un second réseau indépendant reliant 5
postes à une antenne radio est déployé uniquement pour SIGFiP). Enfin l’adressage de ces
postes est différent du reste, ce qui achève de réserver leur usage à SIGFiP et à rien d’autre
(ni bureautique, ni Internet).
La DGB possède aussi un serveur contrôleur de domaine sous Windows2003 pour gérer
ses autres postes.
7.1.3 Fonctionnement
Le réseau présente de nombreux problèmes de fiabilité :

• l’attribution des fréquences et des puissances utilisées au Bénin est en cours de
régulation au niveau de l'Autorité Transitoire de Régulation des Postes et
Télécommunications. De ce fait il est fréquent qu’une liaison radio opérationnelle
devienne inopérante suite à l’installation de l’antenne d’un opérateur privé dont la
puissance d’émission écrase littéralement celui du Ministère. Un changement de
fréquence est alors nécessaire ;
• conséquence de ce qui précède, les liaisons radio dans la boucle locale de Cotonou
ne sont pas fiables, la liaison entre DGID et DGDDI n’est par exemple plus
utilisée ;
• la configuration des réseaux locaux n’est pas optimisée et conduit à des
perturbations entraînant un mauvais fonctionnement des liens par fibre optique.
Les liaisons entre la DGB et la DGID ou la DGTCP par exemple en
souffrent (pour la DGTCP il est parfois nécessaire de physiquement débrancher le
lien avec la DGB pour que le réseau fonctionne correctement !) ;
• des structures importantes ne sont toujours pas reliées au réseau : AJT, UGR,
Chambre des comptes ;
• les liaisons VSAT sont inopérantes depuis 2 ans en raison du non paiement par le
Ministère des frais d’utilisation des canaux.

Pour palier une partie de ces défauts, un audit du réseau a été réalisé en 2006 suivi d’une
expertise effectuée par Cisco. Un programme de modernisation s’en est suivi pour :
• acquérir du matériel réseau moderne professionnel ;
• former les administrateurs du réseau ;
• optimiser le câblage et le paramétrage du réseau ;
• mettre en place une salle informatique.
Sur fonds propres du Ministère, les équipements réseaux (switchs, routeurs, etc.) ont été
acquis en 2009 mais ne sont toujours pas installés. Les administrateurs ont suivi en avril
2011 la formation prévue et la conception de l’architecture de base du réseau (plan
d’adressage, configuration des équipements) est en cours. Parallèlement aux travaux de
mise en conformité du réseau électrique (voir plus loin), un cœur de réseau en fibre optique
a été installé dans les bâtiments du bloc technique. Il n’est pas encore utilisé car il aboutit à
l’emplacement de la future salle informatique.
Les demandes récurrentes constatées concernent la fiabilité du réseau informatique et la

stabilité électrique. Les travaux en cours qui font suite à la formation récente des
administrateurs réseau vont dans le sens de l’amélioration du fonctionnement du réseau.
Néanmoins cela ne pourra aboutir qu’avec la mise en place d’une véritable salle
informatique regroupant les serveurs du Ministère. Un emplacement est déjà prévu et les
travaux sont estimés à 600 MFCFA.
La sécurité électrique doit être assurée par un ensemble d’onduleurs et des groupes
électrogènes. Ces équipements sont déjà en place (voir chapitre suivant) mais ne sont pas
opérationnels. Cela pose des problèmes critiques, notamment pour l’IGF ou la DGTCP qui
ne possède aucun onduleur et subit chaque jour de multiples microcoupures dommageables
à la fois pour son activité (perte de données) et pour le matériel.
La multiplication des salles informatiques requiert une rationalisation. Nous avons déjà vu
qu’au sein du même bâtiment (bloc technique), la DGB et la DOI possède chacune leur
salle serveur (la DGB en a 2). La DGTCP de son côté possède 3 salles et pourtant ses
bâtiments sont voisins du Ministère. Toutes ces salles ont en commun de ne pas respecter
les règles de base que sont par exemple une mise à la terre des équipements, un câblage
clair et protégé, une climatisation correctement dimensionnée ou encore l’absence de poste
de travail parmi les serveurs. Le besoin d’une salle dédiée, déjà exprimé pour le Ministère et
la DOI, vaut donc pour les autres structures. Les Douanes disposent déjà d’un tel
emplacement, mais la DGTCP par exemple doit faire un effort de concentration de ces
équipements en concertation avec la DOI.
Nous avons aussi constaté l’absence de dispositif de stockage suffisant pour les données
traitées dans le Ministère au sens large. Les fichiers sont en général tous stockés sur les
disques durs des serveurs, quels qu’ils soient, et les copies de sauvegarde sont soit faites sur
les serveurs, soit sur des disques externes, rarement sur des bandes. Les structures doivent
s’équiper autant que possible de dispositifs de stockage en réseau, de type NAS ou SAN, de
grande capacité (plusieurs téraoctets) et disposant de mécanismes de redondance adéquats.

Enfin plusieurs projets financés par des bailleurs différents prévoient des réalisations
similaires. Nous avons déjà vu le réseau étendu des Douanes dont certaines stations VSAT
se trouveront dans des localités déjà pourvues d’une station dans le cadre du réseau du
Ministère. Il en est de même avec la DGID ou la DNCMP qui font l’objet pour l’une d’un
schéma directeur et pour l’autre d’un projet de progiciel de gestion intégré et dans lesquels
des salles informatiques importantes sont prévues sans pour autant prendre en compte les
besoins du Ministère dans son ensemble. Une coordination de tous ces projets est
absolument nécessaire.
La LNB a exprimé un besoin spécifique d’utilisation de la technologie GPRS pour
connecter ses terminaux TPM (pour les jeux) seront en mode Online avec le système
central localisé au siège de la DG de la LNB contrairement au mode Offline actuel dont les
inconvénients sont la perte de données, la diminution de temps de validation des enjeux et
l’augmentation de certaines charges d’exploitation.
Les travaux de modernisation du réseau informatique engagés par la DOI au Ministère des
Finances doivent se poursuivre et aboutir rapidement afin de garantir les prérequis
indispensables à la modernisation des applications informatiques. Cela entraîne le
financement et la réalisation du centre de données du Ministère, l’installation et la
configuration des équipements réseau déjà acquis et le transfert des serveurs présents dans
les bâtiments du bloc technique et du cabinet dans ce data center.
Recommandations :
• financer à hauteur de 600 Mfcfa et réaliser le centre de données du
Ministère de l’économie et des finances selon le projet préparé par la DOI
• mettre en place les équipements réseau acquis en 2009 pour obtenir un
réseau informatique fiable et rapide au Ministère début 2012
Le projet d’amélioration du système informatique de la DGID (cf. schéma directeur), de la

DGDDI (cf. projet MCA) ou encore l’environnement prévu par le projet SIGMAP de mise
en œuvre d’un progiciel de gestion des marchés publics doivent impérativement être
coordonnés au niveau du Ministère afin de mutualiser au maximum les moyens mobilisés :
- le projet SIGMAP prévoit ainsi un centre de données pour les serveurs du progiciel
alors que la DNCMP est physiquement située dans les bâtiments du Ministère, tout
comme l’est la DOI. Nous recommandons qu’il y ait un seul centre de données
commun.
- certaines stations VSAT de la DGDDI vont être redondantes avec les antennes
VSAT du réseau du Ministère. Ce n’est matériellement pas défavorable, mais cela
entraînera des coûts d’abonnements supplémentaires alors qu’une solution existait
déjà (boucle locale radio conjuguée au VSAT).

Recommandations :
• coordonner les différents financements d’amélioration du réseau
informatique pour garantir la cohérence et l’efficience des solutions
adoptées
• prévoir un nouvel audit du réseau informatique dans sa globalité lorsque
toutes les opérations prévues (équipements, centre de données,
configuration, etc.) auront été achevées (fin 2012-début 2013)
• adopter des outils de supervision du réseau
Le fonctionnement du réseau étendu n’est possible que si les communications entre sites
sont maintenues opérationnelles, et cela passe par le paiement régulier des frais de
communication.
Recommandations :
• régler au plus vite les arriérés de paiement et assurer le règlement annuel
des abonnements VSAT
• assurer le financement des liaisons VSAT mises en place par la douane
lorsque le projet MCA sera clos

8. Environnement électrique
La situation des différentes structures sur le plan de la sécurité électrique est très variable.
De façon générale des générateurs existent mais ne sont pas en bon état et/ou utilisé :
• le Ministère possède un générateur de 630kVA depuis 2003 qui est hors fonction
depuis 2005. Un second générateur a été acheté en 2009 mais n’a encore jamais été
utilisé… ;
• la DGDDI ne possède aucun générateur. Le projet MCA doit lui en fournir 2
(220kVA et 80kVA) très prochainement ;
La situation dans les régions n’est pas meilleure : la préfecture de Porto Novo (utilisation
de SIGFiP) dispose d’un générateur sous dimensionné, la direction départementale des
Impôts n’en a pas, ni la recette des finances.
Des onduleurs sont présents, mais là aussi de manière très disparate :
• le Ministère dispose de 14 onduleurs de 20kVA installés depuis 2 ans, mais jamais
encore utilisés ;
• l’IGF (situé dans le bloc technique du Ministère) ne possède aucun onduleur pour
les postes de travail. Un vieil onduleur central de 15kVA est hors service depuis
2005 ;
• les autres structures utilisent des onduleurs individuels pour les postes
informatiques, mais beaucoup sont hors service.
Le Ministère a engagé des travaux de mise en conformité du réseau électrique des
bâtiments du bloc technique et du cabinet il y a près de 7 ans. Le budget nécessaire n’ayant
jamais été sécurisé, le chantier traîne en longueur et n’est toujours pas achevé. Mis en
sommeil pendant un temps en raison d’impayés trop importants, les travaux ont repris il y a
environ 2 ans mais le périmètre a été augmenté pour inclure un système de sécurité
incendie (détecteurs et alarmes). A ce jour il inclut :
• la mise en conformité du réseau électrique
• la mise en place de détecteurs et d’alarmes incendie
• la mise en place d’un réseau électrique ondulé
• l’acquisition et installation d’onduleurs centraux de 20kVA
• l’acquisition et installation d’un générateur de 650kVA
La remise en état de l’ancien générateur de 630kVA est envisagée mais les financements
font défaut.
La coordination de ce projet conséquent (le budget total atteint 2,2 Mds FCFA) s’est
révélée très mauvaise. Les équipements lourds ont été commandés et livrés avant que les
câblages correspondant n’aient été mis en place. Le générateur de 650kVA est ainsi installé
depuis 2 ans tout comme les onduleurs centraux de 20kVA. Seulement aucun n’a été mis
en fonctionnement. Le résultat est que la totalité des batteries des onduleurs est désormais

hors service et il est légitime de se poser des questions quant à l’état du moteur du
générateur.
Un budget de 1 Mds FCFA a été demandé à l’Etat pour terminer ce projet, mais cela
n’inclut pas le remplacement des batteries (756 unités pour un total de près de 106MFCFA
selon la source consultée) ni la réparation de l’ancien générateur.
La DGDDI fait face au même problème. Le projet de modernisation et d’interconnexion
des postes de Douanes, financé en grande partie par le MCA, comprend l’acquisition de 2
générateurs (220kVA et 80kVA) et de 3 onduleurs centraux (2x60kVA et 1x80kVA). Le
matériel est attendu pour juin 2011, mais aucun local n’est équipé pour l’accueillir. Si la salle
est désignée, il manque toujours un budget de 8 MFCFA (demandé à la DRFM) pour
réaliser les dessertes électriques nécessaires.
L’Unité de Gestion de la Réforme (UGR) ne dispose pas non plus d’une autonomie
électrique suffisante. Elle entend acquérir un générateur plus puissant.
La DGID a subi l’an dernier des pertes de matériel en raison des intempéries (foudre) et
doit se rééquiper pour connecter ses différents sites, notamment la DDIAL avec les CIPE.
La remise en service de l’ancien générateur et l’achèvement des travaux de mise en

conformité du réseau électrique du Ministère, l’équipement d’une salle à même d’accueillir
les onduleurs acquis par la DGDDI, la mise à la terre des différents bâtiments.
La sécurité électrique est impérative pour que les services puissent fonctionner
correctement. Les projets visant cet objectif doivent être privilégiés.
Au niveau du Ministère, les équipements déjà installés doivent être utilisés dès que possible
et assurer l’achèvement des projets en cours.
Recommandations :
• financer la remise en état de l’ensemble des 756 batteries des onduleurs de
20kVA ainsi que des armoires supplémentaires (le budget envisagé serait
de 106 MFCFA selon la source consultée aux services financiers) ; d’autres
travaux pourraient être nécessaires, aussi une inspection sera nécessaire
pour déterminer avec précision ce qu’il y a lieu de faire
• remettre en état l’ancien générateur de 630kVA
• finaliser le réseau ondulé et le mettre en fonctionnement (faire une
réception partielle du chantier de mise aux normes du réseau électrique)
• assurer le financement et la réalisation du local d’accueil des onduleurs de
la DGDDI

Tous les bâtiments du Ministère, des directions et des structures associées doivent être mis
à la Terre pour assurer la sécurité des biens et des personnes. La protection anti-foudre doit
également être assurée.
Recommandations :
• contrôler tous les bâtiments et, le cas échéant, réaliser les travaux de mise à
la terre
• vérifier l’existence des protections anti-foudre et, au besoin, les réparer ou
les mettre en place
Enfin il est essentiel que la DOI ait un droit de regard sur tous les projets ayant un impact
sur l’approvisionnement électrique des structures du Ministère. Il est en effet du ressort de
la DOI de s’assurer que le matériel informatique demeure opérationnel et efficient.

9. Sécurité
La sécurité des postes de travail n’est pas totalement assurée. Il n’existe pas de politique de
composition et de changement des mots de passe, et quand bien même il y en aurait une,
elle serait difficile à mettre en œuvre dans toutes les structures en raison de l’absence d’un
domaine sur la plupart des réseaux.
Pour la même raison les droits d’accès des différents utilisateurs, soit aux ressources
réseaux, soit aux ressources de leur propre machine, ne sont pas uniformisés et
réglementés. Il en résulte des failles de sécurité importantes facilitant l’intrusion de virus (la
plupart des utilisateurs possèdent les droits d’administrateur sur leur machine).
La protection contre les virus et autres attaques n’est pas homogène et est largement
perfectible. La DOI dispose de 2 serveurs antivirus équipés de Kaspersky Entreprise
utilisés chacun pour une plage d’adresses (la DOI gère en effet deux gammes d’adresses en
parallèle sur son réseau, voir plus haut). La DGB possède également un serveur Kaspersky
utilisé à la fois pour son réseau de postes SIGFiP et pour son réseau bureautique.
L’existence de ces serveurs antivirus a permis de réduire fortement les attaques de virus,
sans pour autant la supprimer. La plupart des autres structures ne sont pas équipées de
serveur antivirus mais disposent sur chaque poste de travail d’un antivirus,
malheureusement souvent en version gratuite et/ou périmée faute de mise à jour régulière
(abonnement terminé, liaison Internet défaillante, etc.).
Il n’existe pas de règle d’utilisation des supports de stockage externes (clés et disques USB).
Leur usage (transferts de données, sauvegardes) est rendu quasi obligatoire par l’absence
d’espace de stockage protégé sur les réseaux. Mais ces supports sont utilisés sur de
multiples postes, professionnels tout autant que personnels, et favorisent la dissémination
des virus.
La protection des bases de données stratégiques (SIGFiP, Aster, Sydonia, etc.) n’est pas
suffisamment forte et les données ne sont pas cryptées. Les interventions directes dans les
bases de données ne sont pas systématiquement documentées et aucune procédure en ce
sens n’existe pour en assurer la traçabilité18.
Le code source des applications stratégiques (SIGFiP, Aster) liées à ces bases de données
est disponible, ce qui est un avantage pour assurer l’autonomie des services dans la
maintenance des logiciels, mais devient un inconvénient majeur lorsque aucune procédure
n’existe pour encadrer les modifications faites dans le code. Ainsi il arrive qu’un contrôle de
validité, présent dans le code informatique, soit mis en commentaire pour ne plus bloquer
un fonctionnement voulu mais pour autant non réglementaire. A titre d’exemple (non
avéré), l’accès au code source de SIGFiP permet de supprimer définitivement ou
provisoirement le contrôle prévu dans le logiciel qui permet d’éviter qu’un engagement sur
une ligne budgétaire soit supérieur au disponible sur cette ligne. A l’heure actuelle rien ne
18 Cela a clairement été exposé lors de la restitution de fin de mission sans qu’une information contradictoire ne soit
apportée. Cependant la DGB précise qu’il existe une « stratégie formelle d’audit de la base SIGFiP ».

permet de garantir la fiabilité des procédures et données puisque aucune traçabilité n’est
assurée dans la modification des codes sources.
Certaines applications révèlent des failles dans leur fonctionnement et autorisent des saisies
en double ou des impressions de bulletins et bordereaux en double (cas du buffer
d’impression de Sicope non vidé après interruption accidentelle) ce qui entraîne un double
paiement de ces bordereaux (cas avéré mais qui semble être résolu à ce jour).
Sur un plan physique l’accès aux salles informatiques est souvent peu régulé avec la plupart
du temps une simple clé. La majorité d’entre elles ne possède aucun système de détection et
d’alarme incendie (une installation est en cours au Ministère, bloc technique) et leur
système électrique n’est pas aux normes (voir supra). La sécurité physique des équipements
n’est donc pas assurée, mettant en danger l’existence des données.
La plupart des besoins exprimés sur ce sujet concernent la sécurité électrique (onduleurs,
générateurs), la protection contre les virus et les sauvegardes. La sécurité physique des
serveurs est évoquée par la volonté de mettre en œuvre de véritables salles informatiques.
Des besoins procéduraux sont pourtant bien réels, avec un manque manifeste de règles
encadrant les interventions sur les données et les codes sources, la gestion des mots de
passe et des droits d’accès sur les réseaux, le comportement des utilisateurs vis-à-vis
d’Internet, etc.
La sécurité d’un SI revêt de nombreux aspects. Elle concerne tout aussi bien l’informatique
que l’Humain, premier maillon de la chaîne informatique et souvent élément le plus difficile
à sécuriser !
Le rôle de la DOI doit plus que jamais être renforcé sur ce chapitre. Nous l’avons déjà
indiqué, mais cette direction doit être le centre de gouvernance du SI et donc être garante
de la sécurité des données. Un responsable de la sécurité des systèmes d’information (RSSI)
doit être nommé et avoir des compétences claires en matière de surveillance du SI et de
proposition de règles et procédures pour améliorer la sécurité. Il doit être consulté lors de
chaque projet informatique pour étudier les impacts en termes de sécurité. Il doit également
être informé de tous travaux d’infrastructure, qu’ils visent le réseau informatique ou le
réseau électrique, et avoir la capacité de les faire modifier si des risques sont identifiés.
Pour faciliter la mise en place de règles de sécurité efficaces, tous les postes de travail de
toutes les structures du Ministère doivent être intégrés dans un domaine disposant d’un
mécanisme de gestion à distance des droits d’utilisateurs. Active Directory sous Windows
2003 et Windows 2008 est à privilégier en raison des outils déjà disponibles au sein du
Ministère. Le RSSI et les administrateurs réseaux doivent alors réfléchir aux différents
groupes d’utilisateurs à créer et des droits qu’il convient de leur attribuer, que ce soit pour
l’accès aux ressources du réseau (stockage, Internet, etc.) ou pour l’accès aux applicatifs
métier.

Sur cette base le RSSI, en concertation avec les autorités du Ministère, devra proposer et
mettre en œuvre une politique globale de sécurité qui concernera la gestion des mots de
passe, l’utilisation des supports amovibles, les solutions antivirales à adopter globalement
au Ministère (il devra faire garantir le financement des abonnements), le mécanisme des
sauvegardes de données, l’utilisation d’Internet (afin d’assurer une bonne utilisation de la
bande passante disponible), etc. Cette politique doit être validée au niveau du Ministre et
être acceptée par toute la hiérarchie qui devra se l’approprier pour la rendre applicable. Des
audits réguliers seront fait par le RSSI pour vérifier l’application de cette politique et, selon
les besoins, l’améliorer.
Le trop grand nombre d’interventions manuelles dans la chaîne de traitement de
l’information est une cause non négligeable de failles de sécurité. Par conséquent une
intégration plus forte des différents applicatifs métier est à rechercher. Cela doit se faire
avec les responsables des infrastructures réseau et applicative (interconnexion fiable des
réseaux, dialogue automatisé entre applications via un EAI et/ou un data warehouse, etc.)
sous la coordination de la DOI et avec l’implication du RSSI.
Enfin la sécurité physique des équipements doit être assurée. Cela passe par le réseau
électrique, mais également des systèmes de détection incendie, de contrôle d’accès aux
salles informatiques (badges, caméras).
Recommandations :
• renforcer le rôle institutionnel de la DOI pour l’ensemble du Ministère et
des organismes associés
• créer le poste de Responsable Sécurité des Systèmes d’Information (RSSI)
au sein de la DOI
• définir une politique globale de sécurité des SI et la faire valider par le
Ministre des Finances
• organiser des ateliers de sensibilisation à destination des conseillers,
directeurs et chefs de service pour qu’ils se l’approprient
• organiser les mécanismes de vérification de la bonne application de cette
politique et de sa mise à jour
• favoriser l’achèvement des travaux de modernisation du réseau
informatique (financement, assistance technique, matériel, etc.)
• favoriser la réalisation des interconnexions entre les applications (EAI, data
warehouse)
• garantir la sécurité physique des équipements (électricité, accès aux salles,
détection incendie, etc.)

Partie B :
Plan d’Evolution du
Système d’Information
(PESI)
1. Comprendre le plan d’évolution
Nous avons indiqué au chapitre 1 qu’un plan d’évolution s’intègre dans le contexte plus
vaste d’un schéma directeur informatique. Ce dernier est construit pour une durée
généralement de 5 à 7 ans et sa mise en œuvre débute par un plan initial.
Le présent plan d’évolution se positionne près de 7 ans après le premier schéma directeur
de 2004 et 4 ans après le précédent plan d’évolution (2007). Certaines activités prévues
dans ces documents ont été réalisées ou sont en cours, même si malheureusement la grande
majorité n’a pour autant pas trouvé de financement. Ce document présente donc bien l’état
des lieux et propose les pistes pour remettre « sur les rails » le développement du système
d’information du Ministère.
Dans cette partie nous proposons tout d’abord une logique d’intervention qui permet de
clarifier les objectifs de notre plan. Grâce à elle nous définissons les différents projets
nécessaires pour atteindre les objectifs découlant de cette logique. D’autres activités ont été
décrites dans le devis programme et le plan d’évolution des finances publiques. Nous
donnons notre avis sur celles-ci et indiquons leur positionnement par rapport à la logique
d’intervention proposée. Nous précisons également le degré d’urgence que nous percevons
pour leur mise en œuvre.
Les principaux projets propres au PESI 2011 sont détaillés au chapitre 3 avec, pour chacun
d’entre eux, un descriptif des objectifs poursuivis, le positionnement dans la logique
d’intervention et une proposition de budget. Nous proposons aussi un planning
d’exécution à un horizon de 3 années.

2. Logique d’intervention du PESI
Le PESI doit s’inscrire dans une logique globale d’intervention de façon à permettre aux
projets lancés d’être cohérents entre eux, et pour qu’ils participent à un objectif spécifique
commun déterminé. Ainsi tous les principaux efforts des 3 prochaines années sont
concentrés vers un objectif, et ne sont pas dispersés, ce qui augmente considérablement les
chances d’atteindre l’objectif défini. La logique d’intervention (ou « chaîne de résultat »),
que nous proposons est représentée par le WBS (Work Breakdown Structure / Structure
Fractionné des Tâches en français) suivant :
Figure 12 : Logique Globale d’Intervention (WBS)
Objectif global :
Meilleure gestion des
finances publiques de l’Etat
Objectif spécifique : produire

des informations fiables dans
des délais raisonnables
1
3
Automatisation totale de la 2 4
Impliquer les utilisateurs et
chaines de traitement des Bonne gouvernance du SI Exploitation et Maintenance
communiquer sur le SI
informations
1.1 3.1 4.1

2.1
Formaliser des accords de Organiser des Créer l'instance de support
Piloter le développement
partages d'informations ateliers/séminaires de (Help Desk) pour appuyer et
stratégique du SI
entre structures sensibilisation dépanner les utilisateurs
2.2 3.2 4.2

1.2
Utiliser de manière optimum Mobiliser les organes de Garantir l'adaptation
Cartographie applicative
les RH, formations, appuis contrôles à utiliser le SI pour permanente du SI aux
actuelle et cible
extérieurs, veille, etc. auditer les chiffres obtenus évolutions organisationelles
1.3 3.3 4.3

2.3
Développer les modules Consacrer le SI comme Garantir l'adaptation
Gérer les normes (qualité,
informatiques manquants ou source officielle et unqique permanente du SI aux
gestion projet, technologie)
refonte de l'existant des chiffres du MEF évolutions technologiques
2.4 3.4
1.4 4.4
Impliquer la hiérarchie dans Mettre en place un Intranet
Supprimer toutes les Assurer un réseau électrique
l'application des décisions dont la mise à jour régulière
opérations manuelles fiable
informatiques est assurée
3.5
1.5 4.5
Moderniser/créer les sites
Développer toutes les Garantir un réseau
Web du ministère et de ses
interfaces entre applications informatique performant
directions générales
4.6
Héberger les équipements
informatiques majeurs
(serveurs) dans des salles
informatiques aux normes

Comme nous l’avons vu tout au long de l’analyse de l’existant (partie A du présent rapport),
le but de l’informatique du MEF est d’aider le MEF à « produire dans des délais
raisonnables des informations fiables sur la gestion des finances publiques ». Cet objectif
fait consensus et c’est tout naturellement que nous proposons de le formaliser comme étant
l’objectif spécifique (OS) du PESI 2011, et qui doit donc « guider » les projets qui seront
lancés entre 2011 et 2013.
Nous proposons qu’un des indicateurs objectivement vérifiables (IOV) de cet OS soit la
« production totalement automatisée du TOFE en quelques heures et qui soit validé par les
instances internes et externes de contrôle des GFP ». En effet, le TOFE étant élaboré
notamment à partir des recettes et des dépenses, c'est-à-dire à partir de la plupart des
informations de GFP, s’il est automatisé cela implique qu’une grande partie de la GFP est
automatisée.
Les hypothèses et risques de l’OS sont les suivants :

• Toutes les parties prenantes (ministre, directions du MEF, et bailleurs de fonds)
font du PESI 2011 le cadre de leurs interventions. En effet, si les bailleurs de fonds
ne coordonnent pas leurs activités et financent des projets différents que ceux
proposés dans le PESI alors c’est la cohérence de l’informatique du MEF qui est
remise en cause. De la même façon, les directions du MEF et le ministre doivent
s’accorder sur ce plan commun afin de coordonner leurs actions.
• La DOI bénéficie d’un appui qualifié pour réaliser les réformes organisationnelles
et mettre en œuvre les recommandations du PESI. En effet, les réformes proposées
dans le PESI sont ambitieuses, et la DOI doit être appuyée tant sur le plan
technique, qu’organisationnel ou financier. La DOI ne pourra pas mettre en œuvre
les réformes proposées seule.
Pour que l’OS soit atteint, il est a priori nécessaire et suffisant d’atteindre les 4 résultats
suivants :
1. Le SI de GFP doit entièrement être automatisé et intègre19,
2. Le SI doit être piloté selon les règles de bonne gouvernance
3. Les utilisateurs et les responsables s’impliquent dans le développement du SI, grâce
notamment à une bonne communication interne
4. L’exploitation et la maintenance du SI sont réalisées selon les règles de l’art
Pour atteindre chacun de ces 4 résultats les actions à mener sont représentées dans le WBS.
Les projets que nous proposons de faire figurer dans le PESI contribuent tous à la
réalisation de l’une de ces activités, et par conséquent à l’atteinte de l’OS.
19 Nous entendons pas « intègre » le fait qu’une fonction soit assurée par une et une seule application et qu’une donnée
n’est saisie qu’une seule fois et qu’elle est partagée si besoin.

Notons en particulier le résultat 2.5 du WBS : « Impliquer la hiérarchie dans l’application

des décisions informatiques ». Ce résultat ne fait pas l’objet de projet particulier par la suite,
puisqu’il s’agit surtout de sensibilisation de la hiérarchie, de communication et de
pédagogie. En effet, comme cela est malheureusement très souvent le cas, la hiérarchie
considère le Système d'Information comme un « mal nécessaire », dévoreur de budget, et
même parfois source d’ennuis, sans percevoir le SI comme une source de productivité et de
bonne gouvernance. Espérons que la présente étude aura contribué à montrer que pour
produire des informations fiables de GFP dans des délais raisonnables, le SI informatisé est
un outil indispensable et hautement stratégique, et que si la hiérarchie s’en désintéresse, cela
contribue à maintenir un faible niveau de fiabilité des données de Finances Publiques.

3. Projets du PESI
La traduction concrète des recommandations formulées (partie A du présent rapport) pour

le PESI 2011 est une liste de projets à réaliser sur la période définie.
Ce chapitre est consacré à la description des projets du PESI.
3.1 Introduction
Le MEF n’ayant pas attendu l’étude du PESI pour continuer à lancer de nouveaux projets
informatiques, de nombreux projets ont été identifiés dans le plan d’amélioration des
finances publiques (PAAGFP, 2009) et programmés dans le devis programme (DP) de
l’UGR financé par l’Union Européenne.
Le PESI intègre d’une part ces projets déjà prévus et propose d’autre part de lancer de
nouveaux projets.
Pour les projets prévus, nous donnons un avis sur l’orientation à leur donner de façon à
conserver une cohérence avec le reste du PESI, et nous proposons pour certains projets
une réorganisation. La fiche synthétique suivante sera utilisée pour ces projets déjà
programmés :
Figure 13 : Modèle de fiche de projet déjà programmé

Nom du projet :
Budget indicatif : Budget prévu DP ou PAAGFP Budget revu : Proposé par la mission
Activité DP : N° de l’activité Activité C7O1.120
PAAGFP :
Description du projet
Description succincte de ce qui est prévu dans le DP ou le PAAGFP
Etat d’avancement
Avancement du projet d’après nos informations
Avis de la mission
Avis sur la pertinence, le budget, et éventuellement une réallocation du budget.
Nous donnons dans cette fiche un bref résumé des projets programmés, mais on pourra se
reporter aux documents originaux pour plus de détails. Rappel : le DP et le PAAGFP 2009
peuvent être consultés sur le portail du PESI :
http://www.e-sud.fr/client/PESI_Benin/doc_recus.php.
Les budgets des projets programmés sont réévalués et nous proposons des réallocations
budgétaires de façon à financer (au moins partiellement) certains nouveaux projets. L’UGR
en concertation avec la DUE devra décider de la nécessité de faire un avenant au DP pour
prendre en compte la réallocation budgétaire proposée.
20 L’identification des activités du PAAGFP se fait de la façon suivante : C7O1.1 : C=composante ; 7=n° de
composante ; O=objectif ; 1.1 = n° de l’objectif/Action.

Pour les nouveaux projets que nous proposons, ils seront décrits à l’aide de la fiche
synthétique suivante :
Figure 14 : Modèle de fiche des nouveaux projets

Nom du projet :
Budget indicatif : Priorité (1, 2 ou 3)
Description synthétique du projet (OS, résultats, principales activités)
Justification
Indique notamment l’élément de la logique d’intervention auquel ce projet participe.
Avertissement ! Le SI actuel comprend une centaine d’applications, près de 150

informaticiens, une trentaine de service traitant de l’informatique, plus de 1500
postes informatiques, une centaine de serveur … La maintenance et l’évolution de cet
ensemble nécessite le lancement permanent de nombreux projets. Le PESI ne contient
pas la liste exhaustive de tous ces projets informatiques. Nous n’avons listé que les
projets déjà prévus plus les nouveaux qui nous semblent très structurant pour l’évolution
du SI.
La rédaction du PESI est indispensable au développement cohérent du SI du MEF, mais

pas suffisant (cf. PESI 2007 jamais mis en œuvre). Le PESI doit impérativement être
approprié par le MEF, et en particulier l’UGR, la DOI et tous les services informatiques,
mais aussi par les grandes directions du MEF et les bailleurs de fonds.
Pour ce faire, nous proposons d’adopter une démarche participative. Le PESI proposé
sera ainsi soumis à débat lors de sa restitution finale. En effet, l’avis de la mission est
un avis d’expert objectif, cependant il n’est pas exclu que, faute d’une connaissance pointue
et exhaustive du contexte, certains détails aient échappés à la mission, et qu’ils faillent les
considérer pour adopter le PESI définitif. Ainsi les 3 jours de débats lors de la restitution
permettront-ils d’ajuster les priorités, la pertinence et éventuellement le budget des projets.
A l’issue de ces 3 jours de restitution – débat, le PESI doit être parfaitement connu de tous,
et reconnu comme étant le fruit d’une réflexion collective qui reflète au mieux l’avis
général.

ELABORATION DU PLAN D’ÉVOLUTION DU SYSTÈME D’INFORMATION DU MINISTÈRE DE L’ÉCONOMIE ET DES FINANCES AU BÉNIN ADE - ATC Consultants
3.2 Synthèse des projets et planification
Prévus Revu
Nom du projet 11 2012 2013 2014
(MFCFA)
------- projets liés à l’ORGANISATION et aux RH -------
O1 : Réforme de la fonction informatique du MEF - 400
O2 : Formation des informaticiens du MEF 23 200
O3 : Elaboration du prochain SDI 0 150
------- projets liés aux APPLICATIONS -------
A1 - (1) Elaboration du dossier de conception générale du SI de GFP 30 250
A1 - (2) prestation d’assistance à maitrise d’ouvrage pour rédiger le DAO et aider à l’évaluation technique des offres - 50
A1 - (3) Réalisation du SI de GFP - 300
A2 - Déploiement de l’application de gestion de la paie SunKWE. 100 0
A3 - Amélioration de l'interface SIGFiP-ASTER et développement interface ASTER-SICOPE 45 0
A4 - Déployer Aster à la DGTCP-DCCE, dans les Recette-Perception, à la DGDDI et DGID 20 0
A5 - Elaboration du cahier des charges pour l'automatisation de la production du TOFE. 37 0
A6 - Réalisation d'un système informatique mécanisant les procédures de passation des marchés publics 4 397 50
A7 - Création d’une base de données unique des agents de l’Etat 120 50
A8 - Mise en œuvre d’un EAI puis d’un entrepôt de données (DW) 221 80
A9 - Mise en place d’une base de données pour la gestion des contribuables 20 0
A10 - Opérationnalisation de l'IFU au MEF et dans les autres administrations (déploiement et extension de l'IFU) 30 0
A11 - Adaptation des logiciels de gestion des finances publiques à la nouvelle nomenclature. 127 50
A12 : Intégration de la nomenclature des pièces justificatives dans SIGFiP 25 0
A13 : Développement d’une base de données exhaustive des dons et prêts et de leur exécution 85 50
A14 : Traçabilité dans SIGFiP des dépenses financées sur ressources extérieures 18 50
A15 : Définir une nouvelle architecture de transmission des données à la DGDDI - - Terminé
A16 : Déployer Sydonia dans les postes/recettes de Douanes. - - En cours de finalisation
A17 : Réaliser un répertoire des prix et l’actualiser - - Terminé
A18 : Acquisition d’un progiciel de gestion de projets - 150
A19 : Acquisition d’un progiciel de gestion de courrier et archivage (GED) - 150
A20 : Appui à la DGID : mise en place opérationnelle du SIGTAS 1 800 1 800
------- projets liés aux SITES WEB -------
W1 : Refonte globale du site WEB institutionnel du MEF - 150
W2 : Extension et mise à jour du site web du MEF (textes juridiques) 30 0

ELABORATION DU PLAN D’ÉVOLUTION DU SYSTÈME D’INFORMATION DU MINISTÈRE DE L’ÉCONOMIE ET DES FINANCES AU BÉNIN ADE - ATC Consultants
W3 : Publication en ligne des rapports sur l’exécution budgétaire 16 0

W4 : Création du sous-site WEB de la DGID sous le site global du MEF www.finances.bj 16 0
W5 : Conception, réalisation et mise en exploitation du site web des marchés publics 40 40
------- projets liés au PARC INFORMATIQUE-------
P1 : Création d’une salle informatique centralisée aux normes internationales - 400
P2 : Acquisition des équipements informatiques au profit des personnels de l'administration centrale du Contrôle Financier 25 25
P3 : Acquisition d'équipements informatiques pour la DGTCP (Services centraux et postes comptables) 280 280
------- projets liés au RESEAU INFORMATIQUE-------
I1 : Réalisation de l'interconnexion DGID / DGDDI / DGB / DGTCP 15 0
I2 : Mise en œuvre d'un système informatique de suivi des activités des composantes à l’UGR. 38 38
I3 : Réalisation du Backup de la station VSAT du Ministère de l'Economie et des Finances 236 0
I4 : Audit du réseau informatique du MEF et recommandations et mise en œuvre - 330
------- projets liés au RESEAU ELECTRIQUE -------
E1 - Réhabilitation et mise en production du réseau ondulé du MEF - 150
E2 - Mise en place d’un local pour les onduleurs à la DGDDI - 8
E3 - Réalisation d’un audit électrique dans toutes les structures du MEF et mise en œuvre - 530
------- projets liés à la SECURITE -------
S1 - AMOA pour la rédaction d’un plan de sécurité des systèmes d’information (PSSI) - 30
S2 - Audit des risques environnementaux des installations du MEF, recommandations et mise en œuvre - 200
S3 - Sensibilisation des utilisateurs à la sécurité - 20
Les projets à lancer de façon prioritaires en 2011 sont les projets A2 ; A3 ; A4 ; A6 ; A7 ; A8 ; A13 ; A1821 ; A19 ; W2 ; W3 ; P2 ; P3 ; I2 ;
E1 ; E2 ; E3 ; S2 ; S3.
Les projets à lancer en 2012 sont : O1 ; O2 ; A1 ; A9 ; A10 ; A11 ; A12 ; A14 ; A18 ; A19 ; W1 ; W5 ; P1 ; S1
21 A13 et A18 doivent être étudiés concomitamment

3.3 Projets liés à l’organisation et aux ressources humaines
Les projets détaillés ci-après sont les suivants :
• O1 : Réforme de la fonction informatique du MEF

• O2 : Formation de tous les informaticiens du MEF
• O3 : Elaboration du prochain SDI

Nom du projet : O1 : Réforme de la fonction informatique du MEF
Budget indicatif 400 MFCFA Priorité (1, 2 ou 3) 1

Objectif Spécifique (OS) de ce projet :
Optimiser l’organisation de la gestion informatique du MEF
La finalité (ou objectifs globaux) du projet :

• Rendre plus performant les prestations informatiques réalisées par le MEF pour le MEF
• Améliorer la qualité du SI par une meilleure utilisation des fonds disponibles
• Atteindre l’OS du PESI
Pour atteindre l’OS de ce projet, nous proposons que les résultats / activités suivants soient atteints /
réalisés :
1. Améliorer la coordination des projets informatiques en attendant la mise en œuvre de la

réforme informatique
a. mise en place dès que possible d’une réunion mensuelle entre tous les responsables
des services informatiques pour échanger sur leurs projets en cours et leurs besoins.
L’objectif de ces réunions est de dégager les premiers projets transversaux,
éventuellement de favoriser des mises à dispositions d’informaticiens d’un service à
un autre. La réunion est présidée par la DOI et doit faire l’objet d’un compte rendu
qui sera diffusé
b. Lister l’ensemble des projets, des applications, inventorier précisément les serveurs
et leurs localisations, les postes, etc. de façon à mieux connaître le SI existant
c. Identifier quelques responsables qui vont commencer à étudier la mise en place des
futures fonctions de la DOI : hot line, help desk, méthodes et normes, qualité, etc.
2. Concevoir la nouvelle organisation cible
a. Le projet pourra s’inspirer de la nouvelle organisation préconisée par le PESI (voir
organigramme présenté au chapitre 3.3.1 page 18) pour élaborer son organigramme
définitif.
b. Réaliser des voyages d’études dans 2-3 autres MEF pour voir comment est organisée
la fonction informatique
c. Rédiger les mandats de chaque service
d. Définir les affectations
e. Identifier et budgétiser l’aménagement des nouveaux bureaux
f. Identifier les futures affectations de tous les agents
g. Identifier les formations nécessaires des agents si occupation de nouvelles fonctions
h. Communiquer largement sur la réforme et recueillir les avis de façon participative
3. Mettre en œuvre la nouvelle organisation
a. Décider de l’organigramme et des mandats
b. Décider des affectations
c. Déménager les postes
4. Formaliser la fin du projet de réforme informatique et réaliser un atelier de retour
d’expérience
Cette nouvelle organisation permettra notamment de produire toutes les recommandations formulées
dans la partie A du PESI, à savoir (liste non exhaustive) :
• Spécialisation des agents

• Développement d’une méthode propre de gestion de projet, inspirée d’une méthode

reconnue (ITIL / PRINCE 2 / etc.)
• Mise en œuvre d’une gestion de la qualité, production de PAQ pour les projets
• Mise en œuvre d’un mode de gouvernance de type « management par projet »
• Production des normes :
o Spécifications ordinateurs
o Spécifications serveurs
o Protocole réseau
o Normalisation des outils de développement des applications
Le budget de ce projet doit permettre de financer de l’expertise d’appui à la mise en œuvre de la

réforme informatique, le déménagement des agents, l’acquisition du matériel nécessaire
(documentation, logiciels spécifiques, mobilier, etc.), des formations spécifiques qui ne seraient pas
prises en compte dans le plan de formation général, etc.
Ce budget ne peut être construit à partir d’une liste des besoins. Nous proposons cependant que le
budget soit à la hauteur de l’ambition de ce projet, et donc conséquent. Nous proposons de le fixer
de façon arbitraire à 400 MFCFA.
Justification
Ce projet contribue significativement aux activités 1.1 ; 2.1 ; 2.2 ; 4.1 du WBS du PESI

Nom du projet : O2 : Formation des informaticiens du MEF
Budget indicatif 22 725 528 FCFA Budget revu : 200 MFCFA

Activité DP : 2.8.3.2 Activité PAAGFP : C8aO4
Le projet est intitulé « Former les informaticiens de la DNCMP aux logiciels orientés WEB et les
correspondants dans les Ministères sectoriels » dans le DP. Afin de garantir une bonne mise à jour du
site Internet, les informaticiens de la DNCMP doivent être formés aux technologies utilisées. Nous
proposons de reformuler largement ce projet programmé pour qu’il bénéficie à l’ensemble des
informaticiens du MEF.
Etat d’avancement
3 personnes ont déjà été formées à TUNIS via ce financement.
Avis de la mission
La formation des informaticiens doit se placer dans un plan global de formation des informaticiens
du Ministère. La DOI doit coordonner ces actions et la maintenance des sites web du Ministère doit
être confiée à un département spécifique de la DOI qui en assurera la coordination. Il n’est pas
raisonnable d’envisager des actions envers les informaticiens sans que la DOI ne soit partie prenante.
Nous proposons par conséquent d’annuler ce projet tel qu’il est formulé, et de le formuler de la façon
suivante (extrait de la partie « A » chapitre 3.3.4 :
Formation de l’ensemble des informaticiens du MEF :

Des formations doivent être prévues sur les thèmes liés à la nouvelle organisation. Citons à titre
d’exemple :
• méthode qualité et gestion de projet
• gestion d’un help desk, gestion d’une hot line
• outil de messagerie
• JOOMLA ou DRUPAL, MS Sharepoint
• administration ORACLE
• gestion de la sécurité
• réseau informatique
• Méthode et langages de développement d’applications
• langages pour le Web
• etc.
Les formations aux outils doivent être programmées une fois que les outils de développement de
référence du MEF seront formellement définis.
On privilégiera les formations groupées au Bénin, en séminaire, ce qui a un coût de revient très
inférieur à des formations individuelles dispensées à l’étranger. Il faudra étudier la possibilité
d’organiser ces formations au CENAFOC, parfaitement équipé pour cela, ce qui constituerait la
contre partie nationale et permettrait, à budget équivalent, un bien plus grand nombre de formations.
Pour cela un contrat cadre pourrait être passé avec un centre de formation pour une durée de deux
ans : le centre de formation, qui aurait remporté le contrat sur la base de la qualité de son catalogue de
formation, s’engagerait à organiser dans un délai de quelques semaines les formations demandées tout
au long de l’année au Bénin et à la demande du MEF. Nous pensons que ce contrat cadre pourrait
prévoir 30 semaines de formation au total entre 2012 et 2013 ce qui permet de former au moins une
fois par an tous les informaticiens pendant 1 semaine. Le budget à prévoir pour un tel contrat cadre

serait de l’ordre de 200 MFCFA (300 k€).

Pour information, les centres de formation informatiques en France sont très nombreux, il y a par
exemple :
• IBM Formation : http://www-304.ibm.com/jct03001c/services/learning/ites.wss/fr/fr?pageType=page&c=a0003630
• CAP GEMINI institut : http://www.institut.capgemini.fr/index.php?nos-seminaires-capgemini-institut
• ATOS ORIGIN centre de formation : http://www.formation.atosorigin.fr/
• ORSYS : http://www.orsys.fr/
• CEGOS : http://www.cegos.fr
• EGILIA : http://www.egilia.com
• PLB : http://www.plb.fr/
• Etc.

Nom du projet : O3 : Elaboration du prochain SDI de GFP

Elaborer le Schéma Directeur Informatique 2014-2019 validé par toutes les parties prenantes
et reconnu comme LA référence pour tous les projets et investissements informatiques sur la
période
La finalité (ou objectifs globaux) du projet :

• Avoir un cadre cohérent reconnu par toutes les structures du MEF et par tous les bailleurs de
fonds qui appuient le MEF
• Poursuivre l’effort d’amélioration de la Gestion des Finances Publiques du Bénin
• Accompagner le MEF pendant quelques mois la mise en œuvre du SDI
Ce projet doit permettre au MEF de disposer d’un nouveau SDI qui succèdera au PESI 2011. Pour ce
faire, il est préférable d’externaliser ce projet à un cabinet spécialisé qui pourra proposer un regard
neuf et objectif sur les résultats obtenus par le PESI 2007, puis proposer à partir de ce diagnostic de
l’existant et des résultats, des scénarios pour le SDI 2014-2019.
L’un des scénarios sera adopté par le MEF puis détaillé. Le SDI sera alors finalisé, et présenté en
atelier, en prenant toutes les mesures nécessaires pour que toutes les structures du MEF sans
exception s’approprient ce nouveau SDI, et pour que tous les bailleurs de fonds reconnaissent ce SDI
comme seul et unique cadre de référence des projets informatiques de GFP.
Suite à la validation du SDI, le cabinet de consultants accompagnera sur une période significative (1
an environ) à temps partiel le MEF pour le lancement des projets du SDI.
L’élaboration du SDI doit se faire sur une période de 6 mois minimum, et l’accompagnement sur une
période de 1 an à raison de 1 mois sur 3 (soit environ 4 mois prestés). La charge totale estimée pour
une équipe de 3 à 4 consultants est de 10 à 15 mois.homme, soit un budget de 150 MFCFA.
Justification
Ce projet contribue significativement à l’activité 2.1 du WBS du PESI

3.4 Projets liés aux applications
• A1 : Elaboration du dossier de conception général du SI de GFP

• A2 : Déploiement de l’application de gestion de la paie SunKWE
• A3 : Amélioration de l'interface SIGFiP-ASTER et développement interface
ASTER-SICOPE
• A4 : Déployer Aster à la DGTCP-DCCE, dans les Recette-Perception, à la
DGDDI et DGID
• A5 : Elaboration du cahier des charges pour l'automatisation de la production du
TOFE
• A6 : Réalisation d'un système informatique mécanisant les procédures de passation
des marchés publics
• A7 : Création d’une base de données unique des agents de l’Etat
• A8 : Mise en œuvre d’un EAI puis d’un entrepôt de données (DW)
• A9 : Mise en place d’une base de données pour la gestion des contribuables
• A10 : Opérationnalisation de l'IFU au MEF et dans les autres administrations
(déploiement et extension de l'IFU)
• A11 : Adaptation des logiciels de gestion des finances publiques à la nouvelle
nomenclature (ASTER, Interface SIGFiP-ASTER, Sunkwe).
• A12 : Intégration de la nomenclature des pièces justificatives dans SIGFiP
• A13 : Développement d’une base de données exhaustive des dons et prêts et de
leur exécution
• A14 : Traçabilité dans SIGFiP des dépenses financées sur ressources extérieures
• A15 : Définir une nouvelle architecture de transmission des données à la DGDDI
• A16 : Déployer Sydonia dans les postes/recettes de Douanes
• A17 : Réaliser un répertoire des prix et l’actualiser
• A18 : Acquisition d’un progiciel de gestion de projets
• A19 : Acquisition d’un progiciel de gestion de courrier et archivage (GED)
• A20 : Appui à la DGID : mise en place opérationnelle du SIGTAS

Nom du projet : A1 : Elaboration du dossier de conception général du SI de

GFP
Budget indicatif 30 000 000 FCFA (UE) Budget revu : 600 000 000 FCFA
Activité DP 2.4.3.3 Activité C4O3.3
PAAGFP :
Ce projet est libellé « Etude de faisabilité pour la réalisation d'un SI intégré de GFP fondé sur
une BD unique » dans le DP, mais étant donné la nouvelle orientation que nous proposons pour ce
projet, nous l’avons reformulé.
Etat d’avancement
Les TdR, faits par la DOI ont été transmis à l’ON qui doit les étudier.
La formulation du projet dans le DP est imprécise et mélange l’objectif à atteindre et les moyens d’y
parvenir. En effet, pour qu’un SI soit intégré il n’est pas nécessaire qu’il y ait une BD unique, par
ailleurs il est imprudent de « conclure » que la solution au problème des interfaces (est-ce d’ailleurs un
problème d’avoir des interfaces ?) est d’avoir une BD unique et de commander une étude dont la
conclusion est déjà rédigée. Nous proposons donc une reformulation de ce projet ci-dessous, qui
permette d’atteindre un OS selon une démarche méthodologique que nous avons expliquée dans la
partie A du rapport.
Avis de la mission
Ce projet est au cœur de l’objectif spécifique du PESI. Nous proposons de le reformuler de la façon
suivante :
Objectifs spécifiques : Elaboration du dossier de conception général du SI de GFP
Résultats et activités à prévoir :
1. Etudier et présenter au MEF les SI de GFP de 3 pays représentatifs (par exemple le Burkina
Faso, le Cameroun, la Côte d’Ivoire) [1 h.m]
2. Elaborer l’architecture applicative et fonctionnelle actuelle de GFP par reverse engineering [3
h.m]
3. Elaborer la cartographie des processus métiers actuel, et proposition d’améliorations [2 h.m]
4. Concevoir l’architecture fonctionnelle cible du SI de GFP [3 h.m]
5. Proposer 3 scénarios22 d’architecture applicative pour réaliser les fonctionnalités, et évaluer
chacune de ces variantes [3 h.m]
6. Définir l’architecture technique [2 h.m]
7. Rédiger le dossier de conception générale du SI de GFP [4 h.m]
La charge de travail totale estimée est de 18 hommes/mois pour les experts à laquelle il faut rajouter
au moins de 30 hommes/mois de charge de travail à fournir par le MEF. Ce projet doit se dérouler
dans un délai de 8-10 mois maximum.
L’équipe qui doit mener à bien cette étude doit être composée de la façon suivante :
- Chef de projet, expert informaticien dans la gestion de projet SI finances publiques
- Architecte fonctionnel (profil informaticien ayant une expertise fonctionnelle)
- Expert GFP
- Architecte technique (informaticien)
22 Consulter le paragraphe 4.3 (Marche à suivre pour le choix du scénario) pour plus de précisions

Le budget à prévoir pour l’appel d’offres pour espérer bénéficier d’une expertise internationale de
haut niveau est d’au moins 250 MFCFA.
Cette prestation étant très importante dans le cadre du PESI et très structurante pour de nombreuses
années, tous les moyens devront être déployés pour élaborer d’excellents TdR et sélectionner la
meilleure SSII ou cabinet de conseil pour réaliser l’étude. Pour ce faire, il peut être utile que la DOI
bénéficie d’une prestation d’assistance à maîtrise d’ouvrage pour rédiger le DAO et aider à
l’évaluation technique des offres. Une telle assistance nécessiterait un budget de 50 MFCFA et
pourrait être mobilisée par contrat cadre ou PNC.
Ce projet d’élaboration du dossier de conception général du SI de GFP que nous proposons regroupe
en fait différents projets programmés dans le DP. Ces projets, qui sont décrits plus loin, sont les
suivants :
• Elaboration du cahier des charges pour l'automatisation de la production du TOFE

• Réalisation d'un système informatique mécanisant les procédures de passation des marchés
publics
• Mise en place d’une base de données pour la gestion des contribuables
• Adaptation des logiciels de gestion des finances publiques à la nouvelle nomenclature
(ASTER, Interface SIGFiP-ASTER, Sunkwe).
• Intégration de la nomenclature des pièces justificatives dans SIGFiP
• Développement d’une base de données exhaustive des dons et prêts et de leur exécution
• Traçabilité dans SIGFiP des dépenses financées sur ressources extérieures
Une fois ce projet terminé, le MEF aura en sa possession tous les éléments nécessaires pour lancer le
projet de développement ou refonte du SI cible de GFP, qui consistera à rédiger les spécifications
détaillées, puis à développer le SI, puis à le tester (recette). Selon la variante retenue pour
l’architecture applicative cible :
• soit un appel d’offre est lancé pour faire développer le SI cible par une SSII,
• soit les informaticiens du MEF améliorent eux-mêmes les applications existantes
• soit le SI cible est composé de certaines applications existantes améliorées complétées par de
nouvelles applications
A ce stade il n’est pas possible de prévoir de budget pour cette phase de réalisation des applications
tant il peut être variable, et nous ne pouvons pas présager des conclusions de l’étude. Toutefois, nous
proposons de « réserver » un nouveau budget de 300 MFCFA pour la réalisation de ce SI cible en
2013.

Nom du projet : A2 : Déploiement de l’application de gestion de la paie

SunKWE.
Budget indicatif : 100 000 000 FCFA (national) Budget revu : 0 FCFA
Activité DP : - Activité C7O1.1
PAAGFP :
Il s’agit de mettre en usage le logiciel sunKWE destiné à remplacer SDL7. Le projet couvre les
déploiements et les formations.
Etat d’avancement
Le logiciel SunKWE est utilisé en parallèle de SDL7 et mobilise 2 agents à temps plein depuis 2 ans.
Pour autant SDL7 est toujours le logiciel officiel de gestion de la solde et SunKWE n’est toujours pas
le logiciel en production
Avis de la mission
SDL7 est désormais dépassé technologiquement. Il faut réaliser sans tarder une évaluation claire de
l’utilisation parallèle de SunKWE sur les 2 années passées et fixer une date pour le basculement vers
celui-ci et l’abandon de SDL7. La date annoncée par la DGTCP pour la bascule de SDL7 à
SUNKWE est juin 2011. Pourtant rien ne permet de garantir que cette nouvelle échéance sera cette
fois respectée. Les raisons pour lesquelles la bascule n’a toujours pas été réalisée ne nous ont pas été
clairement expliquées (l’autorisation du conseil des ministres serait requise et le projet de communication serait en
cours de validation au niveau du CODIR MEF).
Nous mettons ce projet en priorité 1 afin qu’une décision soit enfin prise sur le déploiement de
SunKWE, ou son abandon.
Nous préconisons que ce premier projet soit géré en mode projet.
Le blocage du déploiement étant avant tout lié à une décision, le budget doit être supprimé, ou alors il
doit être justifié. Dans l’attente d’une éventuelle justification, nous proposons de réallouer ce budget
pour financer d’autres projets.

Nom du projet : A3 : Amélioration de l'interface SIGFiP-ASTER et

développement interface ASTER-SICOPE
Budget indicatif : 45 000 000 FCFA (UE) Budget revu : 0 FCFA

Activité DP : 2.15.1.1 Activité C4O3.4
PAAGFP :
Une communication existe entre SIGFiP et ASTER, mais pas dans le sens inverse. Il s’agit donc de
faire circuler l'information dans le second sens du bus (d'ASTER vers SIGFiP) et rendre plus fluide
les échanges d'information entre les deux applications.
Etat d’avancement
Le service informatique de la DGTCP a indiqué ne pas avoir été informé de ce projet bien qu’il soit
concerné en premier lieu de la réalisation de ce projet, et la première recommandation est donc de
communiquer largement autour de l’avancement de ce projet.
Ce projet, qui a été identifié dès 2008, est très attendu et demandé par l’ensemble des parties
prenantes. Pourtant, bien qu’il n’existe pas de blocages techniques, et bien que le MEF ait toutes les
compétences pour réaliser ce projet, il n’a toujours pas démarré. Les actions à mener sont
parfaitement connues, et très bien résumée dans le DP.
Des TdR ont même été rédigés et se trouvent au niveau de l’ON.
Avis de la mission
Cette interface est très importante pour l’amélioration des GFP, et doit être réalisée rapidement. Elle
participe de l’automatisation globale du SI, qui est l’activité 1.5 du PESI. Etant donné l’urgence de
mise en œuvre de cette interface, nous recommandons de lancer le projet dès que possible sans
attendre l’autre projet plus global de mise en œuvre d’un EAI qui sera mis en œuvre plus tard.
Lorsque l’EAI sera opérationnel, il pourra aisément intégrer cette interface ASTER -> SIGFiP.
Des discussions approfondies avec les informaticiens du MEF nous ont convaincu qu’ils possèdent
toutes les compétences nécessaires et suffisantes pour réaliser cette interface. La conception requiert
d’avoir une bonne connaissance des modèles de données (MCD) des 2 logiciels SIGFiP et ASTER,
ce qui est le cas des informaticiens du MEF. Il n’est donc pas nécessaire de faire appel à un prestataire
extérieur pour la concevoir ou la réaliser. Etant donné l’importance de cette interface et du caractère
sensible des informations traitées, nous préconisons d’ailleurs que ce projet soit internalisé, c'est-à-
dire réalisé par les informaticiens du MEF eux-mêmes, toutefois, si pour des raisons de disponibilités,
le MEF souhaite confier l’analyse et/ou la réalisation de l’interface à un prestataire informatique
extérieur, cela est tout à fait possible. Nous estimons que l’étude et la réalisation par un prestataire
nécessite environ 5 mois/homme de prestation (1 mois de prise de connaissance approfondie, 2 mois
de conception, 1 mois de réalisation, 1 mois de recette).
Nous n’avons pas saisi l’intérêt de l’achat d’un serveur pour l’hébergement de cette interface puisque
la base de données d’ASTER et SIGFiP peuvent mutuellement se mettre à jour via des trigger et
procédures stockées.
Le budget prévu pour ce projet ne nous parait justifié que si le MEF choisit de faire appel à la sous-
traitance. Si ce n’est pas le cas, et nous proposons de l’utiliser à d’autres fins (notamment pour le
projet de mise en œuvre d’un EAI).
Dans le cadre de ce projet d’interface, on s’intéressera également à l’interface entre ASTER et

SICOPE. Pour les mêmes raisons que SIGFiP-ASTER, nous ne prévoyons a priori pas de budget
pour ce projet interne. Les éventuels frais de fonctionnement de ce projet seront à prendre sur le
budget de l’UG PESI.

Nom du projet : A4 : Déployer Aster à la DGTCP-DCCE, dans les Recette-

Perception, à la DGDDI et DGID
Budget indicatif : 20 000 000 FCFA (national) Budget revu : 0 FCFA

PAAGFP :
La DCCE est la direction du contrôle de la comptabilité de l’Etat. Elle prépare le compte général de
l’administration des finances et le projet de loi de règlement des finances. Elle doit avoir accès aux
logiciels de suivi des finances publiques que sont Aster et SIGFiP.
Etat d’avancement
Les modules nécessaires à la DCCE ont été réalisés et testés par le service informatique de la
DGTCP. Pour autant aucun déploiement n’a été effectué.
Avis de la mission
Ce déploiement est réputé être bloqué en raison d’un manque de matériel au sein de la DCCE. 11
personnes composent cette direction, mais seuls 4 postes informatiques sont disponibles.
L’acquisition de quelques postes est de toute façon nécessaire, mais cela n’empêche pas la mise en
place d’Aster sur les postes déjà disponibles.
Jusqu’à preuve du contraire, le déploiement d’ASTER à la DCCE ne souffre d’aucune contrainte

technique, il s’agit uniquement d’une décision à prendre. Nous recommandons vivement au MEF de
prendre cette décision ce qui renforcera la qualité des informations contenues dans ASTER.
Ce « projet » (qui n’en est pas un à proprement parler, puisqu’il s’agit d’une « décision ») participe de
l’activité 1.1 du PESI.
L'acquisition des postes informatiques de la DCCE est indépendante de ce « projet » et fait partie du
projet de renouvellement du parc informatique. Aucun budget n’est par conséquent nécessaire pour
mener à bien ce « projet » prioritaire.
Concernant le déploiement d’ASTER dans les autres structures (RP, DGDDI, DGID), il s’agit a
priori de la même logique, il n’y a pas de contraintes techniques mais des décisions à prendre.

Nom du projet : A5 : Elaboration du cahier des charges pour

l'automatisation de la production du TOFE.
Budget indicatif : 37 500 000 FCFA (UE)

Activité DP : 2.4.6.2 Activité PAAGFP : C4O6.5
Le but est d’éviter les nombreuses opérations manuelles nécessaires à ce jour pour composer le
TOFE.
Etat d’avancement
Des TdR ont été obtenus de la part de la DGB et de la CSPEF et transmis à l’UGR. Cependant la
CSPEF aurait indiqué que ce projet n’est plus d’actualité. Le dossier est en attente.
Avis de la mission
Ce projet doit être intégré dans le cadre du projet A1 de conception du SI global. En effet comme
nous l’avons vu dans la partie A du PESI, l’automatisation de la production du TOFE est
l’aboutissement de l’automatisation du SI. Nous proposons par conséquent d’annuler ce projet mais
de récupérer son budget pour participer au financement du projet A1.
L’objectif de ce projet reste toutefois tout à fait pertinent et nous indiquons par conséquent dans le
planning global qu’il devra être réalisé en même temps que la fin de la mise en œuvre du projet A1.

Nom du projet : A6 : Réalisation d'un système informatique mécanisant

les procédures de passation des marchés publics
Budget indicatif : 50 000 000 FCFA (UE) et 4.3 Mds FCFA (total demandé, tous bailleurs)
Activité DP : 2.8.8.1 Activité PAAGFP : C8aO1
La direction des marchés publics possède une application SIGMAP peu évoluée, dépassée et plus
adaptée à ses besoins. Une étude de faisabilité a préconisé la mise en place une solution globale de
gestion de marchés. Le budget initialement prévu fin 2009 était de 2 906.7 MFCFA, et a été revu à la
hausse en 2011 pour atteindre 4 397.2 MFCFA.
Etat d’avancement
Le budget alloué par l’UE ne concerne qu’une assistance à la mise en route du projet principal. Les
TdR sont à finaliser/valider par l’ON. Néanmoins, s’agissant d’un projet impliquant plusieurs
bailleurs pour un montant important, des clarifications ont été demandées, notamment à la BAD.
Avis de la mission
L’étude de faisabilité est de qualité, et les recommandations sont globalement pertinentes, même si
parfois un peu trop académiques. Les commanditaires de l’étude ont eu une excellente initiative, qui
était notamment justifiée en raison de l’importance de disposer d’une bonne gestion des marchés
publics. Cependant, après avoir commenté l’étude, nous proposons de recentrer ce projet sur
l’intégration d’un SI de gestion des marchés (et d’inclure cela dans le cadre du projet plus vaste
d’élaboration du dossier de conception générale du SI de GFP), et de reporter le budget de 4.3
milliards sur les projets transversaux liés au réseau, à la construction d’une salle informatique ou à la
formation.
Un périmètre d’étude trop large :

L’étude de faisabilité formule des recommandations qui dépassent très largement le cadre strict de la
gestion informatisée des marchés, puisque des préconisations sont formulées sur le réseau, le
backbone, les spécifications matériels, le site web, la formation, le réseau électrique, etc. A vouloir
mettre tous ces sujets dans l’étude de faisabilité du SIGMAP, les préconisations perdent un peu de
leur force. Cela donne aussi l’impression que toutes les actions proposées concernent SIGMAP, alors
que ce n’est pas le cas, et le budget demandé est très important ce qui rend difficile son financement.
Un périmètre fonctionnel mal défini :

L’étude préconise, outre l’acquisition d’un logiciel de gestion des marchés, l’acquisition d’un progiciel
de gestion des ressources humaines, de comptabilité et d’amortissement, ce qui est très largement en
dehors du périmètre initial. C’est vrai que le SI des marchés publics est fortement lié aux autres blocs
fonctionnels du SI global, puisqu’un marché doit être imputé sur le budget de l’Etat, éventuellement
lié à un financement extérieur, il doit être comptabilisé, et amorti, suivi techniquement, etc.
Mais l’étude ne portait pas sur l’acquisition d’un SI complet de GFP incluant les marchés publics, elle
ne se limitait théoriquement qu’à la gestion des marchés publics ce qui nécessitait d’étudier
précisément l’intégration du futur SIGMAP avec le SI existant (SIGFiP, ASTER, MATKOSS,
SIPIBE, etc.). Or, les frontières du futur SIGMAP n’ont pas été dessinées précisément.
Par exemple, page 45 est présenté un schéma complet (bien que difficile à interpréter) de la procédure
de traitement des titres de paiement. Malheureusement il n’y a aucune conclusion à la suite de ce
schéma, ce qui est dommage, puisque justement il convient de dire ici que la procédure de paiement
n’est pas suffisamment optimisée (voir l’analyse que nous en avons faite chapitre « 4.1.1 Absence
de vision globale du SI »). Que préconise le consultant pour intégrer SIGMAP au SI existant
insuffisamment intégré en l’occurrence ?
L’étude ne dit pas, à tord, que le logiciel de gestion des marchés devra fortement s’intégrer à SIGFiP,
ASTER et MATKOSS (qui sont déjà eux-mêmes insuffisamment intégrés), et il ne faudra pas que

l’utilisateur ait à saisir des informations déjà saisies dans SIGFiP ou ASTER. C’est pour cette raison
que nous préconisons plus loin que l’étude d’optimisation ou de refonte du SI existant prenne en
compte la gestion des marchés, de façon à concevoir un SI global cohérent et intégré.
Absence de mutualisation :
Tout SI pour fonctionner doit s’appuyer sur un réseau informatique et électrique performant, sur des
agents formés, etc. Ceci n’est pas spécifique à SIGMAP !
Il faut par exemple replacer la demande de financement de plus de 1 milliard de FCFA pour
améliorer le réseau informatique, dans le cadre d’une action qui ne concerne pas uniquement la
DCNMP mais tout le MEF.
Nous retrouvons dans cette étude la même absence de vision commune de l’informatique du MEF
que tout ce que nous avons rencontré au MEF.
Des scénarios manquants :

Concernant les scénarios, nous pouvons regretter qu’un scénario d’ajout des fonctionnalités
identifiées dans SIGFiP n’ait pas été envisagé. Il pourrait en effet être intéressant d’étudier cette
solution, peu coûteuse, rapide à mettre en œuvre, et qui améliorera très significativement la gestion
des marchés publics dans un premier temps. Dans un second temps, lorsque le réseau informatique
sera sécurisé, lors que le réseau électrique sera stable, lorsqu’une salle informatique centralisée sera
opérationnelle, lorsque le SI cible de GFP aura été défini, alors il pourra être prévu l’acquisition du
progiciel SIGMAP.
Un budget excessif :
Le budget proposé par le consultant est très élevé (2.9 Milliards) puisqu’il doit permettre de financer
un très grand nombre d’actions et pas uniquement l’informatisation de la gestion des marchés publics.
Ce budget a de plus été augmenté très significativement de 1.5 milliards par le MEF, l’argumentaire
de 2 pages est cependant trop léger, d’autant plus que le MEF propose de réduire le périmètre
fonctionnel. Autrement dit, le budget initial nous paraissait déjà élevé, mais lorsqu’il est augmenté de
plus de 50% en même temps que le périmètre fonctionnel est réduit, il nous paraît excessif.
Préconisations du PESI :
Nous préconisons de segmenter cet important projet de 4.3 milliards en plusieurs projets :
Concernant la mise en œuvre du logiciel SIGMAP, nous proposons de procéder graduellement avec
les 2 projets suivants :
1. Intégration d’un module simplifié « marché public » dans SIGFiP :

• A partir de l’étude de faisabilité du SIGMAP, rédiger un cahier des charges fonctionnel des
principales fonctionnalités de gestion des marchés. Seules les grandes fonctionnalités seront
retenues à cette étape (c'est-à-dire par exemple, élaboration du plan de passation de marché,
suivi des étapes de passation de marché par type de marché, gestion de l’attribution, suivi des
principaux jalons de l’exécution du marché et des paiements, gestion de la clôture et des
avenants).
• Développer ces fonctionnalités dans SIGFiP
• Recetter et déployer la nouvelle version de SIGFiP
Ce projet requiert avant tout du temps de travail des informaticiens du MEF. Toutefois, si le MEF le
juge nécessaire, une prestation d’assistance pourra être mobilisée, à hauteur de 4 homme/mois, soit
un budget de 50 MFCFA.
2. Concevoir l’architecture fonctionnelle cible complète du bloc fonctionnel de gestion des marchés
dans le cadre de l’étude globale d’élaboration du dossier de conception générale du SI de GFP.
L’intégration de l’étude du SIGMAP dans la conception générale du SI de GFP permet de

garantir sa parfaite intégration dans le SI global, tant technique que fonctionnelle. De plus, suite
au premier projet rapide d’ajout d’un SIGMAP simplifié dans SIGFiP, un premier retour
d’expérience permettra de mieux définir les attentes du SIGMAP cible dans le SI global.
Il n’y a pas de budget spécifique à prévoir pour cette étude puisqu’elle est intégrée dans un projet déjà
budgétisé.
Concernant les autres actions prévues dans l’étude de faisabilité, nous proposons tout simplement de
les mutualiser au niveau du MEF :
3. Utiliser le reste du financement prévu pour SIGMAP pour les projets transversaux suivant :
• Audit réseau informatique et réalisation
• Amélioration du réseau électrique
• Construction d’une salle serveur
• Formation des informaticiens du MEF

Nom du projet : A7 : Création d’une base de données unique des agents

de l’Etat
Budget indicatif : 120 000 000 FCFA (PTF) Budget revu : 50 000 000 FCFA
PAAGFP :
La liste des agents de l’Etat n’est pas à jour et les informations pour la renseigner proviennent d’outils
disparates et non synchronisés (MIR, listes sous tableur, etc.). Une base unique et centralisée est
l’objet de cette activité.
Etat d’avancement
Aucune action n’a été encore engagée à ce jour.
Avis de la mission
Ce projet doit être lancé après que SunKWE ait été déployé (voir projet « Déploiement de
l’application de gestion de la paie SunKWE »).
Ce projet est pertinent pour connaître et suivre exactement les agents de l’Etat et la charge salariale.
Elle permettra aussi de programmer précisément les besoins en ressources humaines.
La démarche qui devra être adoptée pour atteindre l’OS est la suivante :
• Lister de façon exhaustive toutes les applications de GRH
• Lister les fonctionnalités offertes par ce parc applicatif
• Etudier la possibilité d’intégrer l’ensemble de ces fonctionnalités dans SunKWE
(prévoir éventuellement l’acquisition d’un progiciel de GRH du marché)
• Développer toutes les fonctionnalités manquantes dans SunKWE et le recetter
• Déployer SunKWE dans tous les services et abandonner tous les autres anciens
systèmes de GRH. Ainsi tous les agents seront enregistrés dans SunKWE et l’OS
sera atteint.
Le budget de 120 MFCFA ne nous parait pas justifié. La plupart de ces opérations peuvent être
réalisées en interne avec les ressources du MEF. Nous proposons de conserver un budget de 50
MFCFA pour faire ponctuellement appel à des consultants externes et pour faire face à d’éventuels
achats de licence ou matériel.

Nom du projet : A8 : Mise en œuvre d’un EAI / ESB puis d’un entrepôt
de données (DW)
Budget indicatif : 221 033 250 FCFA (UE) Budget revu : 80 MFCFA
Tel que prévu dans le DP, il s’agit de la mise en place d’un entrepôt de données, ou data warehouse
(matériel, logiciel) afin de centraliser les données des finances publiques et faciliter les travaux de
synthèse et de recherche.
Comme nous l’avons vu dans la partie A du PESI, il est nécessaire de mettre en œuvre un EAI (ou
ESB) avant le data warehouse (DW). Nous reformulons ainsi le projet.
Etat d’avancement
Les TdR pour la recherche d’un prestataire chargé de rédiger le cahier des charges (maîtrise
d’ouvrage) sont en cours de validation à l’ON.
Avis de la mission
Le projet tel que formulé dans le DP est pertinent. Cependant, cette activité doit être le point final de
la mise en œuvre du SI intégré de GFP au Ministère. Toute l’infrastructure réseau ainsi que le
déploiement d’interfaces entre applications et d’un EAI ont pour but d’amener les données vers le
data warehouse.
Le projet d’EAI / ESB doit se faire rapidement, avant la refonte du SI. L’EAI / ESB permettra en
effet de résoudre des difficultés de circulation de l’information qui facilitera le projet de refonte du SI,
et offrira dans des délais raisonnables (bien avant la mise en œuvre du SI global intégré) une meilleure
intégration du SI actuel.
Le projet de DW est nécessaire, mais doit se faire une fois que tous les éléments de base sont en
place, notamment le SI global intégré.
Le budget de 221 MFCFA nous parait très élevé (nous n’avons pas le détail qui a permis de
l’élaborer), et nous proposons qu’il soit largement réutilisé pour financer les autres projets.
La mise en œuvre de l’EAI / ESB sur le SI actuel peut se faire en l’espace de 6 mois et nécessite
l’achat d’un EAI et la formation, plus éventuellement la mobilisation très ponctuel d’un expert. Nous
proposons de réserver un budget de 50 MFCFA pour cela.
L’achat d’un DW peut considérablement varier, puisqu’il en existe des gratuits qui sont open source
(satisfont-ils aux besoins du MEF ?) ou des très élaborés tel que Business Object qui peut se chiffrer
toutes prestations confondues à plusieurs millions d’euros. Nous proposons de réserver un budget
prévisionnel de 30 MFCFA pour mener les premières études. Un nouveau budget devra être élaboré
le moment venu.

Nom du projet : A9 : Mise en place d’une base de données pour la

gestion des contribuables

Activité DP : 1.5b.7.2 Activité PAAGFP : C5bO7.2
Afin de lutter contre la fraude fiscale, ce projet vise à mettre en place une base de données permettant
de reconstituer le chiffre d’affaires des entreprises à partir de différentes informations. Le budget
provisionné doit permettre l’achat d’ordinateurs et photocopieur.
Etat d’avancement
Aucune information d’avancement n’est disponible. La DOI n’a pu fournir aucun renseignement sur
ce projet.
Avis de la mission
Cette activité entre dans le cadre d’un SI intégré et les recoupements recherchés pourront être faits au
sein d’un entrepôt de données. La DGID indique pouvoir réaliser ce projet en interne sans faire appel
à de la prestation extérieure.
Le budget de 20 MFCFA demandé est justifié par l’acquisition de matériel informatique, sans lien
immédiat apparent avec l’objectif du projet lui-même. Il semble que la réalisation de cette
fonctionnalité « recherche » soit la justification pour faire acheter du matériel, or il nous semble plus
pertinent de découpler les investissements en matériel informatiques évidemment nécessaires (voir les
chapitres qui y sont consacrés) des activités de maintenance évolutive des applications.
Nous proposons par conséquent de réallouer ce budget demandé à d’autres projets. La demande
d’achat de 8 ordinateurs par la DGID doit par ailleurs être prise en compte dans le plan global d’achat
d’ordinateurs au MEF en 2011 ou 2012.
Concernant le projet de maintenance applicative proprement dit, c'est-à-dire le développement d’un

module de « recherche » des données reconstituées des contribuables, même si ce projet est a priori
purement DGID, il nous semble pertinent qu’il soit mené en mode projet et implique d’autres
informaticiens que ceux de la DGID.
Il faut prévoir que ce module de recherche sera intégré à terme dans le futur SI de GFP, il convient
par conséquent de réaliser un premier module rapidement.
Attention ! Ce projet doit être étudié dans le cadre d’un projet plus vaste sur financement Canadien
qui semble se dessiner et qui vise à remplacer les 9 applications actuelles par une seule application
intégrée. Un SDI spécifique à la DGID est en cours de finalisation, ses conclusions n’ont pas pu être
prises en compte dans le présent PESI. Cependant lors de la mise en œuvre du PESI, ce projet devra
éventuellement être amendé pour prendre en compte les avancées du SDI de la DGID et du
programme Canadien.

A10 : Opérationnalisation de l'IFU au MEF et dans les

Nom du projet : autres administrations (déploiement et extension de
l'IFU)
Budget indicatif : 30 000 000 FCFA au total (UE)

Activité DP : 1.5b.4.1/1.5b.4.2 Activité PAAGFP : -
L’IFU est géré dans une base de données de la DGID, mais est utilisé par plusieurs applications dans
différentes structures. Il n’existe pour autant aucun lien automatique de diffusion des nouveaux IFU.
Ce projet vise à y remédier.
Plusieurs volets ont été programmés dans le DP : applicatifs, réseau, reprise de données, formation,
sensibilisation et maintenance.
Etat d’avancement
Des TdR ont été transmis à la DOI. Ils concernent les aspects réseau uniquement. La DOI réfléchit
sur l’opportunité d’élargir le champ de ces TdR.
Avis de la mission
Le budget demandé doit permettre de
1. Réaliser une étude de faisabilité pour la mise en œuvre d’un réseau informatique (15
MFCFA)
2. Renforcement des capacités (l’objectif ici n’est pas clair) : 15 MFCFA
Nous proposons de mutualiser ces moyens financiers avec les études spécifiques prévues dans le
cadre des projets réseaux (voir plus loin). La DGID indique avoir tous les moyens pour réaliser avec
ses ressources internes le volet applicatif. Aucun budget n’est donc nécessaire.
De la même façon que pour le projet A9, ce projet doit être mené en mode projet n’incluant pas
forcément que du personnel de la DGID, et il faut prévoir que ce module sera intégré à terme dans le
futur SI de GFP, il convient par conséquent de réaliser un premier module rapidement.
Attention ! Ce projet doit être étudié dans le cadre d’un projet plus vaste sur financement Canadien
qui vise à remplacer les 9 applications actuelles par une seule application intégrée. Voir projet A20.

A11 : Adaptation des logiciels de gestion des finances

Nom du projet : publiques à la nouvelle nomenclature (ASTER, Interface
SIGFiP-ASTER, Sunkwe).
Une révision de la nomenclature budgétaire est prévue pour la mise en place d’une gestion axée sur
les résultats. Des modifications sont à prévoir dans les applications qui utilisent la nomenclature
budgétaire. Ce projet, tel que décrit dans le devis programme, vise à recruter un expert informaticien
qui sera chargé de rédiger les tdr et le dossier d’appel d’offres, de suivre son traitement et de suivre le
développement des adaptations des logiciels par un consultant recruté selon l’appel d’offres.
Etat d’avancement
La nouvelle nomenclature est toujours en cours d’élaboration. Une ébauche de TdR a été réalisée par
la DOI.
Avis de la mission
Ce projet entre dans les activités de maintenance évolutives des applications. Les TdR doivent être
finalisés et l’activité programmée afin de minimiser le temps de transcription de la nouvelle
nomenclature lorsqu’elle aura été votée.
Le descriptif présent dans le DP1 est cependant ambigu. Si les actions à mener comprennent bien les
études et les réalisations des adaptations, les tâches à exécuter par le consultant recruté consiste en
une assistance à maîtrise d’ouvrage.
Nous considérons que les équipes informatiques du MEF (DOI, DGID, DGTCP, etc.) sont les
mieux à même de réaliser les études d’impact et les adaptations requises. Les informaticiens
connaissent les applications concernées et sont à même de se coordonner pour réaliser les
modifications de sorte à ne pas créer d’incompatibilité entre les applications.
Par contre une assistance à maîtrise d’ouvrage chargée de traiter les dossiers et de suivre les
réalisations a son intérêt, mais pour cela le budget alloué nous semble très élevé. Nous proposons de
conserver un total de 50 MFCFA pour cette assistance qui sera répartie en plusieurs missions dont la
périodicité sera à définir le moment venu.
Le reste du budget est réalloué pour financer le projet A1 qui intègrera le résultat de ce projet.

Nom du projet : A12 : Intégration de la nomenclature des pièces

justificatives dans SIGFiP
Budget indicatif : 25 000 000 FCFA (national ?)

Activité DP : - Activité PAAGFP : C4O1.3
Ce projet vise à fournir à SIGFiP la liste des documents justificatifs des dépenses publiques afin
d’améliorer la vérification et la validation des dépenses engagées.
Etat d’avancement
Des TdR ont été transmis à l’UGR mais la nomenclature en question n’est pas encore finalisée.
Avis de la mission
Cela entre dans le cadre de la maintenance évolutive des applications du Ministère et doit être
coordonné avec la DOI et les responsables de la préparation de la nomenclature.
Afin de rendre l’adaptation des logiciels rapide après la validation de la nouvelle nomenclature, une
première phase d’étude peut être lancée pour identifier les éléments qui devront être modifiés. Cette
étude peut parfaitement être faite par les informaticiens du MEF et coordonnée par la DOI. Il s’agira
notamment de permettre un archivage électronique des pièces justificatives de recettes et de dépenses
et leur transmission suivant la nomenclature en vigueur (par exemple l’arrêté n°1264, …) pour
justifier des montants du compte envoyé à la juridiction financière.
La chambre des comptes devra être impliquée dans la mise en œuvre de ce projet.
Comme tous les projets réalisés en interne, nul budget spécifique ne semble a priori nécessaire pour
mener à bien ce projet (concernant les primes de « motivation » pour les agents travaillant sur le
projet ainsi que toutes dépenses annexes classiques de fonctionnement, elles seraient financées par le
budget transversal de l’UG PESI. C’est la raison pour laquelle un budget spécifique à ce projet interne
n’est pas programmé).

Nom du projet : A13 : Développement d’une base de données exhaustive

des dons et prêts et de leur exécution
Budget indicatif : 85 000 000 FCFA (CAA)

La Caisse Autonome d’Amortissement utilise les logiciels SIGMAE et CSDRMS2000 respectivement
pour la mobilisation des financements extérieurs et pour la gestion comptable de la dette. L’outil
CSDRM gère les dons gérés par la CAA, mais la CAA ne gère pas tous les dons. SIGMAE n’est plus
utilisé, un autre programme est en cours de développement.
Etat d’avancement
L’état d’avancement n’est pas connu, mais l’informaticien de la CAA qui était en charge du
développement de SIGMAE a été muté dans un autre service où il n’exerce plus d’activité
informatique. Par ailleurs le service informatique ne dispose pas des codes sources du logiciel.
Avis de la mission
L’intégration des différents outils utilisés par la CAA en un système unique connecté au SI du
Ministère est une bonne chose. Ce projet doit être l’occasion de moderniser les logiciels utilisés et
d’utiliser des outils de développements communs avec les autres structures du MEF. Une
coordination avec la DOI est nécessaire, mais ce n’est pas le cas actuellement.
Si cette activité se heurte à la non disponibilité des codes sources de SIGMAE, cela peut être
rapidement résolu par la nécessité de réécrire ce logiciel avec des outils modernes (SIGMAE est
réalisé sous Oracle 4).
Cette activité est donc à réaliser en mode projet et doit impliquer la DOI, non seulement pour étudier
les liens avec les autres logiciels, et notamment SIGFiP, mais aussi, et surtout, pour qu’elle apporte les
ressources que la CAA ne possède pas (très peu d’informaticiens). Une étude est à mener avec les
cadres de la CAA pour produire le cahier des charges du nouveau SIGMAE, puis les développements
sont à organiser avec les informaticiens du MEF, plus particulièrement ceux de la CAA et ceux de la
DOI.
L’ancienneté du logiciel SIGMAE est un facteur suffisant pour décider d’engager cette activité dès
que possible.
Si le projet est réalisé en interne par les informaticiens du MEF, aucun budget spécifique n’est a priori
nécessaire. La CAA a pourtant provisionné 85 MFCFA sur ses fonds propres. Nous pensons qu’un
budget de 50 MFCFA pour requérir une assistance à maîtrise d’ouvrage doit cependant être très
largement suffisant.
Nous recommandons que ce projet soit mené en même temps que le projet A18 (cf remarques sur le
projet A18)

Nom du projet : A14 : Traçabilité dans SIGFiP des dépenses financées

sur ressources extérieures

Activité DP : 2.4.3.1 Activité PAAGFP : -
Il s’agit de transmettre les informations détenues par la CAA sur les projets financés sur ressources
extérieures vers SIGFiP.
Un atelier est tout d’abord prévu afin de regrouper les PTF et les administrations Béninoises pour
dresser la liste des informations qui doivent remonter dans SIGFiP. Suite à cet atelier, un consultant
doit être recruté pour agir en tant qu’assistant à maîtrise d’ouvrage, la réalisation étant confiée à la
DGB.
Etat d’avancement
La DOI est en attente d’un cahier des charges de la part de la DGB avant de produire des TdR.
L’atelier n’a pas été réalisé.
Avis de la mission
L’obtention d’informations exhaustives sur l’exécution des dépenses, qu’elles soient sur financement
interne ou externe, est un résultat clé de l’intégration du SI des finances publiques. En ce sens cette
activité doit s’insérer dans le projet plus global A1 vu plus haut, de la même manière que l’est
l’automatisation du TOFE. Elle doit également être synchronisée avec les mises à jour et/ou
réécriture des applications concernées au sein de la CAA (voir projet A13) et les adaptations des
nomenclatures budgétaires dans les logiciels de GFP, dont bien sûr SIGFiP (voir projet sur ce sujet
plus haut).
Nous préconisons par ailleurs que le consultant international qu’il est prévu de recruter, participe à
l’atelier et à la préparation de l’atelier, de façon à ce qu’il ait une parfaite maîtrise fonctionnelle du
sujet, ce qui garantira sa capacité à mieux jouer son rôle d’assistant à maîtrise d’ouvrage. Le
recrutement de ce consultant doit se faire dès que possible.
Comme pour toutes prestations d’assistance à maîtrise d’ouvrage, nous préconisons un budget
forfaitaire de 50 MFCFA, ce qui permettra de couvrir environ 3 mois de prestation et le financement
de l’atelier.
Pour information, ce type d’étude vient d’être mené au Mali, au SHA (Service d’Harmonisation de l’Aide). Il pourrait être
intéressant de s’inspirer des TdR de cette étude et d’en récupérer les résultats. Les TdR de cette étude sont disponibles sur le portail,
menu « Fond documentaire », partie « Documents connexes à la mission » référence #3

Nom du projet : A15 : Définir une nouvelle architecture de transmission

des données à la DGDDI
Budget indicatif : 129 000 000 FCFA (PTF/MCA)

Activité DP : - Activité PAAGFP : C5aO2.1
Afin d’améliorer la circulation des informations au sein de la douane, un schéma directeur
informatique est réalisé.
Etat d’avancement
Le MCA a pris en charge cette activité. Le document est réalisé et les préconisations sont en cours de
mise en œuvre.
Avis de la mission
Activité réalisée.
La DOI doit être impliquée dans la mise en œuvre.

Nom du projet :
A16 : Déployer Sydonia dans les postes/recettes de
Douanes.
Budget indicatif : 7 500 000 000 FCFA (MCA et national)

Activité DP : - Activité PAAGFP : C5aO2.2
Les postes douaniers du pays sont tous équipés d’un système informatique leur permettant d’utiliser
Sydonia et de transmettre leurs données à la DG.
Etat d’avancement
Le MCA prend en charge cette activité. Les équipements sont en cours de livraison.
Avis de la mission
L’interconnexion des postes de Douanes avec la DG est essentielle pour une bonne utilisation de
Sydonia++ et une bonne appréciation des recettes douanières. Cependant cette interconnexion
s’appuie fortement sur des liaisons VSAT sans prendre en compte les équipements déjà déployés
dans le cadre du réseau national du Ministère. Il y a donc redondance dans certaines localités et cela
produira une charge supplémentaire sur le budget de l’Etat à échéance de la prise en charge par le
MCA.
Nous recommandons une attention particulière lors de la préparation des budgets annuels afin que les
frais d’utilisation des bandes passantes satellites soient toujours prévus.

Nom du projet :
A17 : Réaliser un répertoire des prix et l’actualiser
Budget indicatif : 205 000 000 FCFA au total (national)

Activité DP : - Activité PAAGFP : C10O4
Il s’agit de réaliser un répertoire des prix constatés chez les fournisseurs du Bénin afin de proposer un
référentiel utilisé dans les différents marchés publics. Il y a 3 volets : réalisation, déploiement, mise à
jour annuelle.
Etat d’avancement
Le répertoire est disponible sur CDROM et sur le site web du Ministère. Il y a une version en réseau
permettant aux délégués de faire des propositions de nouveaux produits.
Avis de la mission
Activité réalisée.

Nom du projet : A18 : Acquisition d’un progiciel de gestion de projets

Objectif spécifique : Acquisition d’un progiciel de comptabilité et suivi-évaluation des
projets financés par l’aide extérieure
Plusieurs structures gèrent déjà des projets : l’UGR pour le suivi des projets de la réforme, la cellule
FED également pour le suivi et la comptabilisation des projets FED, et d’autres services ont besoin
d’un logiciel de gestion de projet (comptable et suivi-évaluation) pour piloter tous les projets financés
par l’aide extérieure.
Par exemple, la DOI a également un besoin d’application pour suivre les projets du PESI. Il faut
donc chercher à mutualiser tous ces besoins pour acquérir un seul système complet et partagé par ces
services.
Il existe sur le marché des logiciels de ce type : TOMATE, AID IMPACT, PGA, SARA, E-OLE,
PROME, SIGMAH, etc. Tous ne font pas à la fois la comptabilité et le suivi-évaluation, et tous ne
sont pas full web. Il convient donc de se renseigner précisément sur chacune de ces applications, de
les tester puis d’acquérir le logiciel qui convient le mieux (la mission a consacré quelques instants
auprès de la cellule FED pour faire une démonstration du logiciel E-OLE, ce qui leur a permis de
constater qu’ils sont en effet bien plus performants que celui qui a été développé spécifiquement en
local).
Nous ne préconisons pas d’intégrer cette fonctionnalité de gestion de projet dans le SI de GFP, mais
d’acquérir un logiciel distinct qui devra fortement être intégré au SI de GFP. En effet, le logiciel de
gestion des projets doit s’adapter en permanence aux procédures des bailleurs de fonds qui évolue
continuellement, de plus il existe suffisamment de logiciel standard sur le marché qui sont très
performant pour qu’il ne faille pas chercher à re-développer la même chose (ce qui prendrait plusieurs
années pour un coût bien plus élevé).
Nous préconisons que la DOI bénéficie d’une prestation spécifique d’assistance à maîtrise d’ouvrage
pour l’acquisition d’un tel système qui permettra de recenser les applications existantes, analyser tous
les besoins du MEF, rédiger le DAO, évaluer les offres, etc. L’application qui sera déployée doit être
reconnue et adoptée par les bailleurs de fonds.
Ce projet doit être étudié en même temps que le projet A13 sur la gestion des dons. En effet, il est
possible et souhaitable que le logiciel de gestion des projets financés par l’aide extérieurs, et le logiciel
de gestion des dons soient le même, ou en tout cas qu’ils communiquent fortement.
Tout comme pour le projet de conception générale du SI de GFP, la prestation d’assistance à

maîtrise d’ouvrage appuiera la rédaction du DAO et l’évaluation technique des offres et au
pilotage du prestataire. Une telle assistance nécessiterait un budget de 50 MFCFA et pourrait être
mobilisée par contrat cadre ou PNC. L’acquisition du logiciel, son paramétrage et son déploiement
nécessite un budget de 100 MFCFA.
Justification
Ce projet contribue aux activités 1.3 ; 1.4 et 4.2 du WBS du PESI

Nom du projet : A19 : Acquisition d’un progiciel de gestion de courrier et

archivage (GED)

L’objectif est d’améliorer la gestion du courrier et des archives par l’acquisition d’un progiciel
spécifique, et plus généralement toute la gestion documentaire du Ministère.
Jusqu’à présent certains services se sont équipés de solutions hétérogènes de gestion du courrier, soit
avec des solutions spécifiques, soit avec des solutions progiciel du marché. Il n’y a pas, à notre
connaissance, d’outil de gestion documentaire qui soit déployé.
Ce projet doit permettre à tous les services du MEF de disposer d’une même et unique application
centralisée de gestion du courrier et des archives, et plus globalement, de gestion de la
documentation. Ce projet va en outre dans le sens de la « dématérialisation » recherchée.
A titre d’exemple, le Ministère français de la justice s’est doté en 2008 de la solution open source
alfresco pour la gestion de ses dossiers d’instruction pénale et l’a déployé dans tous les tribunaux de
grande instance en France.
Bien que la solution soit gratuite et open source, l’intégration d’un tel outil requiert la mobilisation de
plusieurs mois/hommes d’experts intégrateurs pour paramétrer et intégrer la solution, puis la
déployer.
Pour que cet ambitieux projet réussisse, le MEF doit disposer d’un consultant expert en la matière qui
appuiera la maîtrise d’ouvrage dans l’analyse des besoins, la recherche de la meilleure solution sur le
marché, puis pour la rédaction du DAO. Ensuite ce consultant aidera à sélectionner la meilleure offre
technique, et procèdera si nécessaire à un benchmark pour comparer les solutions. Il aidera enfin le
MEF à piloter le prestataire informatique (intégrateur et/ou éditeur) qui viendra déployer sa solution.
Tout comme pour le projet de conception générale du SI de GFP, la prestation d’assistance à

maîtrise d’ouvrage appuiera la rédaction du DAO et l’évaluation technique des offres et au
pilotage du prestataire. Une telle assistance nécessiterait un budget de 50 MFCFA et pourrait être
mobilisée par contrat cadre ou PNC. L’acquisition du logiciel, son paramétrage et son déploiement
nécessite un budget de 100 MFCFA.
Justification
Ce projet contribue significativement aux activités 1.3 ; 1.4 et 4.2 du WBS du PESI

Nom du projet : A20 : Appui à la DGID : mise en place opérationnelle du

SIGTAS
Budget indicatif 1 800 MFCFA Priorité (1, 2 ou 3) 1

Déployer le système de gestion informatisé SIGTAS qui rendra la collecte et l’analyse des
données fiscales plus performantes, transparentes et fiable
Ce projet est entièrement pris en charge par l’ACDI et est déjà à un stade avancé. Un schéma
directeur informatique a été élaboré, le projet informatique a été identifié et le Canada s’est engagé
dans son financement. Au moment de la finalisation de l’élaboration du PESI (août 2011), ce projet
en était à la phase de sélection de l’agence d’accompagnement du projet.
Le projet informatique fait partie d’un projet plus vaste d’appui à la DGID, d’un montant total de
18 M $ CAN.
Ce projet mené de façon autonome et indépendante par la DGID devra dès que possible est présenté
aux autres services informatiques de façon à connaitre les technologies utilisées, à identifier les
interfaces à développer (notamment avec le trésor afin de déverser automatiquement les données de
recette des impôts dans la comptabilité générale de l’Etat, ou l’interface pour diffuser l’identifiant
fiscal unique).
Lors de la mise en œuvre du PESI il faudra que toutes les parties s’astreignent à parfaitement intégrer
ce projet stratégique des impôts dans le cadre du plan d’évolution du système d’information global du
Ministère dans l’intérêt de toutes les parties.
Justification
Ce projet contribue significativement à l’activité 1.3 du WBS du PESI

3.5 Projets liés aux sites WEB
• W1 : Refonte globale du site WEB institutionnel du MEF

• W2 : Extension et mise à jour du site web du MEF (textes juridiques)
• W3 : Publication en ligne des rapports sur l’exécution budgétaire
• W4 : Création du sous-site WEB de la DGID sous le site global du MEF
www.finances.bj
• W5 : Conception, réalisation et mise en exploitation du site web des marchés
publics

Nom du projet : W1 : Refonte globale du site WEB institutionnel du MEF
Budget indicatif 150 000 000 FCFA Priorité (1, 2 ou 3) 1

L’objectif spécifique de ce projet :
Moderniser les sites WEB du MEF
Le terme « moderniser » a trait aussi bien à la technologie qu’à l’aspect visuel ou aux fonctionnalités.
Ainsi la finalité du projet est :
- fournir au MEF un ensemble de sites modernes, simples et rapides à mettre à jour
délivrer des informations utiles et d’actualité au public
Pour atteindre l’objectif spécifique énoncé plus haut, quelques résultats sont à atteindre :
1. mettre en place les organes pérennes de suivi
a. constituer un comité de suivi des sites web (réunion mensuelle ou bimestrielle)
b. constituer les comités ad hoc de récolte, de mise en forme et de publication des
nouveautés
2. définir avec précision les services que devront rendre les sites du MEF
a. identifier les catégories d’utilisateurs à qui s’adresseront les sites du MEF
b. relever les informations statiques à publier selon les directions
c. lister les catégories d’actualités à mettre en ligne et leur fréquence
d. obtenir les données chiffrées que les sites devront/pourront mettre en ligne de
manière automatique
3. définir les chartes graphiques qui seront utilisées dans tous les sites (plusieurs variantes
officielles)
a. définir les jeux de couleurs selon les directions
b. concevoir les logos et autres éléments graphiques dans des ensembles homogènes
c. délimiter les contours de ce qui relève de l’identité partagée du MEF et de ce qui
relève des éléments spécifiques de chaque direction
d. lister les contraintes à respecter par les sites (absence ou limitation du nombre
d’éléments décoratifs dynamiques, organisation des pages, disposition des menus,
comportement global des sites, …)
4. développer et valider des maquettes
a. choisir un outil de gestion de contenus moderne (ex : Joomla, Drupal, Sharepoint)
b. réaliser des modèles de pages d’accueil selon les différentes chartes
c. réaliser des modèles de pages dynamiques selon différentes possibilités mais en
respectant les chartes graphiques
5. développer les sites selon les maquettes validées puis les tester
a. mettre régulièrement en place des versions des sites pour validation/correction
b. réaliser en premier les éléments statiques d’information pour permettre une mise en
ligne rapide
c. maintenir un retour d’expérience constant entre les testeurs (MEF, directions) et les
développeurs
6. organiser un séminaire de lancement du site officiel du MEF
a. le site du MEF sera le portail officiel : la mise en ligne doit être un événement
b. convier les PTF, les autres Ministères, les médias à ce séminaire
c. lors de l’inauguration, le site devra comporter toutes les informations statiques et au
moins quelques données dynamiques dont les sources et la disponibilité aura été
largement testées et vérifiées.
Les résultats du projet permettront de mettre en ligne rapidement le site officiel du MEF ainsi que

celui de la DGID, de l’AJT et de la chambre des comptes. Les autres structures désirant concevoir un
site devront se conformer aux chartes disponibles et aux guides qui auront été constitués. Par
exemple la LNB (Loterie Nationale) a manifesté un vif intérêt pour disposer d’un site internet
sécurisé, ce besoin devra donc être pris en compte.
La réalisation soignée et la mise à jour régulière et fréquente des sites imprimeront un réflexe de la
part des utilisateurs à aller consulter les sites du MEF et de ses structures pour toute information
récente. Les sites deviendront la vitrine publique d’un SI intégré et maîtrisé.
Le budget de ce projet doit permettre d’obtenir l’expertise nécessaire dans plusieurs domaines :
- organisation/maîtrise d’ouvrage
- cahier des charges
- conception graphique
- ergonomie et convivialité
- développement web
Grâce aux outils actuels (notamment les CMS), il peut être assez rapide de mettre en place les sites en
question. En conséquence nous pouvons prévoir :
- Cahier des charges MEF, DGID, AJT : 3 hommes/mois
- Conception visuelle : 2 hommes/mois
- Réalisation des 3 sites : 6 hommes/mois
- Tests et mise en ligne : 2 hommes/mois
Le budget total est arrondi à 150 MFCFA.
La contrainte de planification est liée à la mise en œuvre des interfaces entre applications majeures
afin de garantir une alimentation automatique des sites du MEF et de la DGID en données
significatives.
Dans le cadre de ce projet, un appui spécifique sera prévu pour appuyer la DOI dans la mise en
œuvre de sharepoint (ou alfresco ou tout autre logiciel de gestion de contenu) pour réaliser l’intranet.
Enfin, notons que la coordination des projets devra être vigilante à prendre en compte l’avancement
du projet A19. En effet certains outils de gestion documentaires intègrent des fonctionnalités
intéressantes de CMS (gestionnaire de contenu) de sites WEB.
Justification
Le site WEB actuel du Ministère est conçu autour d’un CMS un peu désuet, SPIP. Des rubriques y
sont ajoutées en fonction des besoins, mais il n’y a pas de conception d’ensemble de ce que doit
contenir le site. Plusieurs projets de création ou de modifications de sites ont été proposés sans avoir
pour autant une vue homogène (mise en ligne des textes juridiques (AJT), site DGID, refonte site
MEF, publication des rapports sur l’exécution budgétaire).
Les besoins peuvent être adressés rapidement dans l’immédiat (voir plus bas), mais une refonte
globale et ambitieuse du support web au niveau du MEF est nécessaire.
Ce projet contribue à l’objectif 3.5 du WBS.

Nom du projet : W2 : Extension et mise à jour du site web du MEF (textes

juridiques)

Activité DP : 2.14.3.1 Activité PAAGFP : C12O2.1/C12O2.3
Il s’agit de diffuser les textes réglementaires auprès du public.
Etat d’avancement
Les TdR ont été validés et transmis à l’ON.
Avis de la mission
Il s’agit d’un ensemble de pages à placer dans une branche du site web du MEF.
Cette activité étant urgente nous préconisons qu’elle soit réalisée avant le projet plus global de refonte
du site web global. En revanche nous proposons d’adopter une démarche très pragmatique, c'est-à-
dire qu’aucun développement n’est à prévoir, il s’agit simplement d’ajouter une page web (ce qui est
réalisé immédiatement avec SPIP) sur laquelle les internautes pourront télécharger les textes au
format PDF. Il n’y a pas d’autre difficulté que celle de décider et récupérer les documents à diffuser.
Une fois ce projet terminé, d’autres fonctionnalités plus élaborées de recherche, ou de facilité de mise
à jour pourront être développées dans le futur site web, à plus longue échéance (voir projet
précédent).
Par conséquent, aucun budget n’est nécessaire pour réaliser ce projet.
Dans un second temps, les attentes de ce projet seront prises en compte à travers les projets A19 et
W1, qui possèdent des budgets conséquents.

Nom du projet : W3 : Publication en ligne des rapports sur l’exécution

budgétaire
Budget indicatif : 16 000 000 FCFA (PTF) Budget revu : 0 FCFA

Il s’agit de mettre à disposition du public les rapports produits par la chambre des comptes.
Etat d’avancement
Aucune action n’a encore été engagée. L’UGR ou la chambre des comptes doit initier le projet.
Avis de la mission
Ces rapports peuvent être mis en ligne sur le site web du MEF dans un premier temps, puis des pages
spécifiques à la chambre des comptes peuvent y être ajoutées en attendant de réaliser un site à l’image
de la Chambre.
La chambre des comptes peut fournir les rapports à la DOI pour une mise en ligne rapide possible.
Nous préconisons d’adopter la démarche proposée pour le projet W2, à savoir mettre simplement en
ligne ces documents dans un premier temps, et de n’envisager le développement de fonctionnalités
plus élaborées que dans le futur site.
Il n’est ainsi besoin d’aucun budget pour réaliser ce projet.
Dans un second temps, les attentes de ce projet seront prises en compte à travers les projets A19 et
W1, qui ont possèdent des budgets conséquents.

Nom du projet : W4 : Création du sous-site WEB de la DGID sous le site

global du MEF www.finances.bj.
Budget indicatif : 16 000 000 FCFA (PTF) Budget revu : 0 FCFA

Activité DP : 1.5b.2.1 Activité PAAGFP : C5bO2.1
La DGID ne possède pas de site Internet. Ce projet vise à développer un site accessible par une
adresse dérivée de www.finances.bj
Etat d’avancement
La réalisation sera confiée à un prestataire. Les TdR ont été rédigés et transmis à l’ON.
Avis de la mission
Les contribuables ont besoin d’avoir un accès libre à l’information fiscale et ce site est naturellement
un élément important de la réponse à leur apporter.
Plusieurs projets de création de sites et/ou de pages ont été proposés. Celui-ci est potentiellement le
plus important en dehors de la refonte du site du MEF. A ce jour cependant il n’existe pas de cahier
des charges pour la réalisation du site de la DGID, seuls des TdR ont été produits.
Nous préconisons que cette activité soit englobée dans le projet plus vaste de refonte des sites web
du MEF (projet W1). Nous proposons que ce projet soit annulé pour être regroupée avec les autres
activités liées au web dans le projet de refonte cité plus haut. Le budget prévu est donc réalloué pour
les autres projets.

Nom du projet : W5 : Conception, réalisation et mise en exploitation du

site web des marchés publics
Budget indicatif : 40 000 000 FCFA (national)

Activité DP : - Activité PAAGFP : C8aO3
Ce site doit permettre au public et aux entrepreneurs d’être informés des appels d’offres émis par
l’Etat en toute transparence. Les informations sur les attributaires et les processus de sélection y
seront disponibles.
Etat d’avancement
Cette activité doit entrer dans le cadre de la mise en œuvre d’un système intégré de gestion des
marchés publics (projet A6). Le SIGMAP doit préalablement être développé.
Avis de la mission
Ce projet est tout à fait pertinent. Nous préconisons de le réaliser une fois le projet de
développement du SIGMAP allégé (nouveau module de SIGFiP) réalisé (voir projet A6).
Il s’agit de créer quelques pages dynamiques (en JAVA ou PHP) sur un espace dédié du site web
actuel du Ministère, qui viendra « puiser » les données relatives à la liste des marchés dans SIGFiP.
Cette première version du portail web des marchés doit être simple, à l’image de la première version
du SIGMAP par extension de SIGFiP. Cette première version du portail permettra de définir les
besoins, d’initier de nouvelles habitudes tant pour le MEF que pour les soumissionnaires, puis de
mieux cerner les besoins du portail cible qui sera développé lorsque le SIGMAP cible aura été
développé.
Ce projet peut être réalisé en interne, ce qui est souhaitable pour que les informaticiens du MEF se
forment au développement de pages WEB dynamiques. Nous maintenons le budget prévu pour
l’acquisition de licences ou autres dépenses, et éventuellement l’appui d’un prestataire (même si nous
recommandons d’en limiter l’usage pour ce projet).

3.6 Projets liés au parc informatique
• P1 : Création d’une salle informatique centralisée aux normes internationales

• P2 : Acquisition des équipements informatiques au profit des personnels de
l'administration centrale du Contrôle Financier
• P3 : Acquisition d'équipements informatiques pour la DGTCP (Services centraux et
postes comptables)

Nom du projet : P1 : Création d’une salle informatique centralisée aux

normes internationales

La salle informatique sera réalisée au niveau du bloc technique du MEF. Elle regroupera tous les
serveurs situés physiquement sur le campus du MEF ainsi que certains serveurs de secours des
directions voisines (DGTCP, DGID par exemple). Lorsque le réseau informatique sera de qualité, il
est recommandé que cette salle informatique centralise l’ensemble des serveurs du MEF.
Une étude et un dossier d’appel d’offres existent déjà qui ont été réalisés par la DOI. L’étude identifie
un emplacement au niveau du bloc technique et des travaux de câblage réseau ont déjà amené un
ensemble de fibres optiques à cet emplacement. La salle sera construite selon les normes, avec faux
plancher, climatisation, sécurité électrique (redondance, mise à la Terre), contrôle d’accès, redondance
des accès réseau, etc.
Le DAO prévoit 3 lots :
Lot 1 : Travaux de génie civil pour la construction du Datacenter du MEF
Lot 2 : Travaux d’équipements pour la construction du Datacenter du MEF
Lot 3 : Acquisition de serveurs
Nous préconisons que le lot 3 ne fasse pas partie du DAO. Si de nouveaux serveurs doivent être
achetés (il y en a déjà une centaine !) alors ceci doivent l’être dans le cadre d’un plan d’achat global du
matériel informatique du MEF.
La réalisation de ce projet doit être synchronisée avec la fin de la modernisation du réseau

informatique (mise en place des équipements réseau notamment).
Nous préconisons que la DOI présente ce projet à toutes les directions du MEF, de façon à ce que
chacune puisse exprimer son point de vue et suggérer des améliorations à ce projet de construction
d’une salle informatique. Ainsi les directions accepteront plus facilement ensuite de déménager leurs
serveurs dans cette salle commune aux normes.
Un document doit également être préalablement élaboré pour déterminer le mode de fonctionnement
de cette salle informatique partagée par toutes les directions du MEF.
Concernant la source de financement, la construction d’un tel bâtiment était programmée dans le
cadre du projet SIGMAP qui avait été approuvé par le Ministère. Le Ministère n’a donc qu’à réallouer
certains financements du SIGMAP vers ce projet.
Justification
Dans la partie A nous avons décrit les conditions d’installations des serveurs informatiques dans les
locaux du MEF. Nous avons indiqué que la sécurité électrique n’existait pas, que l’encombrement des
locaux était préjudiciable au bon état des machines et que les pannes de climatisation abrégeaient la
vie des équipements.
Ce projet répond à l’activité 4.6 et contribue aux activités 4.4 et 4.5 du WBS du PESI.

P2 : Acquisition des équipements informatiques au

Nom du projet : profit des personnels de l'administration centrale du
Contrôle Financier

Activité DP : 2.10.3.3 Activité C10O2.3/C10O2.5
PAAGFP :
Le contrôle financier est peu équipé en matière informatique et cette activité doit palier ce problème.
Etat d’avancement
Un dossier d’AO est prêt et déposé auprès de l’ON, mais les spécifications techniques du matériel
doivent être vérifiées. La présente mission a donné son avis (voir annexe).
Avis de la mission
Le CF est une administration importante mais peu équipée. Cet investissement est certes nécessaire
rapidement, mais d’autres services doivent également renouveler des ordinateurs. Nous préconisons
que l’achat de l’ensemble des ordinateurs se fasse de façon groupée
L’appel d’offres en préparation (qui ne représente pas un projet au sens où nous l’entendons) spécifie
l’achat non seulement d’ordinateurs, mais aussi d’un serveur, d’une imprimante réseau ainsi que
l’extension du câblage réseau informatique et divers autres petits équipements. Le CF est une
administration localisée dans le bâtiment du bloc technique du Ministère et, à ce titre, bénéficie du
réseau en place. Avec les travaux de modernisation en cours, nous ne pensons pas utile d’ajouter un
projet périphérique relatif au réseau principal.
Une remarque similaire est appelée par la demande d’un serveur. Il n’existe à ce jour aucune
application dédiée au CF qui nécessiterait un serveur. Certes, il nous est indiqué que l’aquisition d’un
serveur est un prélude à l’informatisation, mais nous estimons que les serveurs de la DOI peuvent
très bien héberger provisoirement la future application dont aurait besoin le CF. Une fois cette
application en production, alors il faudra éventuellement investir dans un serveur dédié, soit héberger
l’application dans le datacenter prévu à cet effet.
Enfin les imprimantes demandées (noir et blanc et couleurs) peuvent normalement toutes être
utilisées en réseau. L’acquisition d’une imprimante départementale pour gros volume est tout à fait
pertinente en sus de ces petites imprimantes.
En conséquence le budget demandé peut être revu à la baisse et les équipements demandés peuvent
utiliser les caractéristiques types indiquées en annexe.
Il faut souligner ici l’avantage et la nécessité qu’il y a à synchroniser l’acquisition de ces nouveaux
équipements avec l’achèvement du réseau électrique ondulé. En effet il est préférable de placer du
matériel neuf sur un réseau électrique opérationnel.
Notons également que cet achat doit être intégré dans le plan global d’achat du matériel informatique
du MEF. Si cela est possible nous préconisons même de réallouer ce budget pour financer le plan
d’achat du matériel informatique du MEF en 2011 ou 2012. En attendant cette décision, nous
laissons le budget dans ce projet.

Nom du projet : P3 : Acquisition d'équipements informatiques pour la

DGTCP (Services centraux et postes comptables)
Budget indicatif : 280 520 000 FCFA (UE) Budget revu : 280,52 MFCFA
Activité DP : 3.9.2.2 / 3.9.3.1 Activité C9O2.2
PAAGFP :
Les services de la DGTCP manquent d’équipements et cette activité vise à y remédier, à Cotonou
comme dans les régions.
Etat d’avancement
Un dossier d’AO est prêt, mais les spécifications techniques des équipements nécessitent l’avis de la
mission PESI (voir annexe).
Avis de la mission
Cette demande (qui n’est pas un projet au sens où nous l’entendons) vise à compléter l’équipement de
la DGTCP et à équiper/compléter les 69 perceptions du pays. Plus de 200 postes de travail et
mobilier sont prévus.
Cette acquisition est conséquente, et elle doit selon nous se faire en même temps que la précédente
(projet P2 pour le CF) afin de concevoir un marché global pour s’assurer que les configurations
seront homogènes et en accord avec les standards dressés par la DOI (voir nos préconisations en ce
sens dans la partie A).
D’une manière générale les achats de postes de travail doivent s’insérer dans un processus de
renouvellement régulier chaque année (20 à 25% du parc). L’achat massif de plus de 200 postes doit
donc aller de paire avec la mise en place de ce mécanisme.

3.7 Projets liés au réseau informatique
• I1 : Réalisation de l'interconnexion DGID / DGDDI / DGB / DGTCP

• I2 : Mise en œuvre d'un système informatique de suivi des activités des
composantes à l’UGR
• I3 : Réalisation du Backup de la station VSAT du Ministère de l'Economie et des
Finances
• I4 : Audit du réseau informatique du MEF et recommandations

Nom du projet : I1 : Réalisation de l'interconnexion DGID / DGDDI / DGB /

DGTCP

Activité DP : 1.5b.3.2 Activité C5bO2.3
PAAGFP :
Ce projet a été redéfini pour « Proposer une solution technique d’interfaçage» entre les applications
afin de faciliter l’échange d’information entre les différentes structures.
Etat d’avancement
Une ébauche de TdR a été faite par la DGID, la DOI doit encore donner son avis.
Avis de la mission
La DGID est demandeuse de ces interfaces de communication entre les applications, mais cela doit
se faire dans une vision globale du SI sous peine de voir se mettre en place un « plat de nouilles »
représentant l’enchevêtrement des différentes interfaces.
Les projets A1 et A8 décrit plus haut constitue le cadre dans lequel doit s’exécuter ce projet
d’interfaçage. Il sera donc un produit du projet global, son budget est réalloué pour ces 2 projets A&
et A8.

Nom du projet : I2 : Mise en œuvre d'un système informatique de suivi

des activités des composantes à l’UGR.
Budget indicatif : 38 500 000 FCFA (UE) Budget revu : 38,5 MFCFA
Activité DP : 4.16.1.2 Activité -
PAAGFP :
L’UGR s’est installé dans un local depuis sa création et a mis en place quelques équipements pour ses
premiers besoins. Il s’agit là de les renforcer (générateur, réseau, etc.) et de relier l’UGR au réseau du
Ministère par radio. Ce projet prévoit également l’acquisition d’un logiciel de comptabilité et suivi de
projet ainsi qu’un complément de matériel pour la DGID.
Etat d’avancement
Un dossier d’AO est prêt mais l’UGR et la DUE souhaite l’avis de la mission PESI sur les
caractéristiques techniques des équipements (voir annexe) Le marché a par ailleurs été attribué pour la
fourniture du logiciel de comptabilité (source : cellule FED).
Avis de la mission
La mise en réseau de l’UGR est nécessaire pour un travail efficace de la structure. Lors de son
installation, l’UGR a mis en place un réseau local sur fonds propres. Il s’agit sur ce nouveau « projet »
de consolider cette installation et de garantir sa sécurité par un onduleur de bonne capacité.
En outre l’UGR doit se raccorder au réseau du MEF pour pouvoir interagir avec les organes du
Ministère. Cela requiert la mise en place d’une antenne radio.
Tous ces équipements sont légitimes mais doivent s’inscrire dans une politique globale dirigée par la
DOI afin de standardiser les équipements informatiques et de télécommunication.
Par ailleurs ce marché doit aussi équiper la DGID avec quelques ordinateurs. La remarque relative à
la standardisation du matériel vaut également ici.

Nom du projet : I3 : Réalisation du Backup de la station VSAT du

Ministère de l'Economie et des Finances
Activité DP : 2.15.2.1 Activité PAAGFP : C15O2
Cette activité vise au recrutement d’un prestataire qui sera chargé de réaliser le cahier des charges
pour la mise en place d’une liaison VSAT sur le site qui hébergera les équipements de la salle
informatique de secours. Cette activité entre dans le cadre du projet de reprise sur accident (disaster
recovery).
Etat d’avancement
La DOI a réalisé des TdR mais se donne encore le temps de la réflexion, notamment du fait de la
mission PESI.
Avis de la mission
Depuis 2 ans toute communication est coupée entre le MEF et les régions, non pas du fait d’un
accident sur la station centrale, mais à cause du non paiement des abonnements aux fréquences
VSAT…
De plus un tel mécanisme de fail over n’a de sens que si le budget de fonctionnement garantit à 100%
et chaque année le paiement des factures de l’opérateur. L’expérience de ces 2 dernières années
montre que ce n’est pas le cas. Des mesures sont en train d’être prises pour que ceci ne se reproduise
plus, et il y a tout lieu de penser que ces mesures seront efficaces. Néanmoins, on peut se laisser le
temps de s’assurer que les abonnements seront bien systématiquement payés pendant 1 ou 2 ans
avant d’envisager la réalisation du backup.
Il est préférable d’investir plus fortement dans la sécurité des bâtiments du MEF (électricité aux
normes, salles informatiques aux normes, détection incendie, locaux ignifugés, etc.) et de mettre en
place des systèmes efficaces de sauvegardes des données.
Nous préconisons par conséquent de geler ce projet, et de réallouer ses fonds pour d’autres projets, et
aussi et surtout pour s’assurer du paiement des abonnements VSAT sur le budget de fonctionnement.

Nom du projet : I4 : Audit du réseau informatique du MEF et

recommandations et mise en oeuvre

Des travaux de modernisation sont en cours depuis quelques années et l’étude de rationalisation de la
configuration du réseau a repris depuis le retour de France de quelques cadres qui y ont suivi une
formation poussée en technologies réseaux.
Cependant les équipements acquis et le câblage installé l’ont été en 2008/2009 suite à 2 audits réalisés
en 2006 et 2007 par des experts réseau. Si les travaux avancent correctement ils seront installés en fin
2011/début 2012.
Entre les premiers audits et la fin de la modernisation du réseau il se sera écoulé près de 6 années. Le
présent projet vise à réitérer un audit poussé du réseau global du MEF afin de déterminer les
orientations à prendre, puis élaborer un plan d’action.
Nous recommandons donc vivement qu’un audit de haut niveau soit réalisé à la fin des travaux
actuels, soit vers 2013. Nous proposons de baptiser ce projet « Audit du réseau informatique du
MEF et recommandations » et qu’il soit réalisé par des consultants très qualifiés et certifiés (CISCO
ou MCITP). Le temps à prévoir pour un tel audit de qualité est d’environ 2 mois/hommes. Les
experts réseau certifiés étant très recherchés les honoraires à prévoir sont élevés. Nous proposons par
conséquent un budget de 30 000 000 FCFA.
Suite à cette mission, il faudra mettre en œuvre le plan d’action de façon à disposer enfin d’un réseau
informatique parfaitement sécurisé et correspondant aux normes internationales. Ce réseau devra être
très performant puisque toutes les applications de GFP (et autres) seront d’architecture n-tiers (WEB)
qui ne pourront fonctionner sans réseau.
Il n’est pas possible d’anticiper aujourd’hui le coût de financement du plan d’action qui sera élaboré
par les experts réseaux. Cependant, étant donné l’importance de ce projet, nous proposons de
réserver 300 MFCFA. Ce budget peut être « récupéré » du projet SIGMAP qui prévoit 1.3 Milliards
de FCFA pour le réseau (et que la BAD aurait accepté de financer).
La phase de réalisation du réseau devra se terminer au plus tard avec la réalisation du SI cible (projet
A1)
Justification
Ce projet participe de l’activité 4.5 du WBS du PESI.

3.8 Projets liés à l’alimentation électrique
• E1 : Réhabilitation et mise en production du réseau ondulé du MEF

• E2 : Mise en place d’un local pour les onduleurs à la DGDDI
• E3 : Réalisation d’un audit électrique dans toutes les structures du MEF et mise en
œuvre

Nom du projet : E1 : Réhabilitation et mise en production du réseau ondulé

du MEF

Des travaux de mise aux normes du réseau électrique du Ministère sont en cours depuis plusieurs
années (voir partie A). Dans ce cadre un réseau ondulé a été installé ainsi que des onduleurs de grande
capacité et un générateur de 650kVA. Un second générateur, plus ancien (2003) est en place mais
hors service.
Les onduleurs ont été mis en place avant que le câblage ne soit réalisé et les règles contractuelles entre
le MEF et le prestataire empêchent l’utilisation du réseau ondulé pour le moment. Le résultat est une
détérioration des batteries des onduleurs qui, de ce fait, sont inutilisables à présent.
Ce projet vise donc à mobiliser le financement nécessaire pour remettre en état les équipements déjà
en place et à les mettre en usage. Les activités à mener sont donc :
- Remplacer les 756 batteries des 14 onduleurs en place au MEF
- Remettre en état le générateur de 630kVA acquis en 2003
- Terminer les branchements du système ondulé (câblage, onduleurs, générateurs)
- Réceptionner cette partie du marché pour pouvoir l’utiliser
Les actions préconisées dans ce projet E1 nécessitent un budget prévisionnel d’environ 150 MFCFA
dont les deux tiers pour les seules batteries.
Justification
Ce projet participe pleinement à l’activité 4.4 du WBS du PESI. Il est crucial pour les services comme
l’IGF qui ne disposent d’aucune protection électrique (aucun onduleur) et sont soumises aux
aléas des coupures de courant.

Nom du projet : E2 : Mise en place d’un local pour les onduleurs à la DGDDI

Dans le cadre du projet d’appui du MCA à la douane, 3 onduleurs et 3 générateurs doivent être
réceptionnés par la DGDDI mi-2011 et installés à la Direction Générale. Cependant le bâtiment de la
DG n’a pas été conçu pour héberger des onduleurs centraux et le réseau électrique n’est pas organisé
de manière adéquate. Il est donc nécessaire d’adapter une pièce du bâtiment pour accueillir ces
équipements.
La DGDDI a identifié un local proche de la salle informatique et préparé un budget de 8 MFCFA

pour l’aménager. Ce budget doit constituer la partie nationale mais la DGDDI peine à l’obtenir.
Le projet E2 a pour but de mobiliser ce financement et de faire exécuter les travaux d’aménagement
du local pour que les onduleurs soient installés dès leur arrivée.
Justification
Ce projet participe pleinement à l’activité 4.4 du WBS du PESI. La DGDDI subit pleinement les
coupures de courant car elle ne dispose d’aucune source d’énergie de secours.

Nom du projet : E3 : Réalisation d’un audit électrique dans toutes les

structures du MEF et mise en œuvre
30 000 000 FCFA 1

Budget indicatif Priorité (1, 2 ou 3)
500 000 000 FCFA 2
Lors de nos visites dans les différentes directions nous avons noté le manque fréquent de réseau
électrique fiable. Les prises ne sont pas toujours en bon état et souvent surchargées, la mise à la Terre
est rare, les onduleurs ne sont pas toujours en service, etc. Le MEF a fait le bon diagnostic et mis en
œuvre un projet de remise aux normes de son réseau électrique. Malheureusement le financement n’a
pas suivi et les réalisations durent depuis près de 7 ans et souffrent d’une mauvaise coordination.
Ce projet vise à utiliser les services d’un spécialiste en électricité pour réaliser un audit exhaustif de
toutes les installations des structures du MEF et de dresser les recommandations qui permettront :
- De sécuriser l’utilisation de l’électricité pour les biens comme pour les personnes
- De sécuriser la continuité de l’alimentation électrique
Pour ce faire il sera nécessaire :

- De recruter un spécialiste pour réaliser les audits (2 hommes/mois)
- D’élaborer les dossiers d’appel d’offres pour la réalisation des recommandations
- De réaliser les travaux d’amélioration et acquisitions d’équipements
Il est difficile d’évaluer les besoins en termes d’investissements à venir dans ce domaine car ils
dépendront des résultats de l’audit. Néanmoins, en nous basant sur les coûts d’acquisition des
générateurs et des onduleurs nous proposons de provisionner 500 MFCFA pour l’ensemble des
directions. A cela s’ajoutent les coûts de prestation de l’expert en électricité.
La priorité est forte pour la réalisation de l’audit, un peu moins pour les acquisitions (l’audit doit être
fait tout de suite, les acquisitions plus tard).
Justification
Ce projet participe à la réalisation de l’activité 4.4 et indirectement à 4.5.

3.9 Projets liés à la sécurité
• S1 : AMOA pour la rédaction d’un plan de sécurité des systèmes d’information

(PSSI)
• S2 : Audit des risques environnementaux des installations du MEF,
recommandations et mise en œuvre
• S3 : Sensibilisation des utilisateurs à la sécurité

Nom du projet : S1 : AMOA pour la rédaction d’un plan de sécurité des

systèmes d’information (PSSI)

Nous recommandons dans la partie A la création du poste de responsable de la sécurité des systèmes
d’information (RSSI) et ce projet vise à aider à la rédaction du document qui sera la base du travail du
RSSI.
Le PSSI doit répondre à l’objectif principal qui est de « protéger les actifs informatiques contre les
risques et ce d’une manière qui est adaptée au Ministère, à son environnement et à l’état de son outil
informatique ». Plus précisément le PSSI adressera les activités suivantes :
Objectif Activités
Protéger… Conception, mise en œuvre, et maintenance des
contre-mesures de sécurité
…les actifs informatiques… Identification des actifs informatiques (information,
applications, systèmes, ressources humaines).
Détermination de la valeur des actifs:
* pour le Ministère, et
* pour les intrus potentiels
…contre les risques… Identification des risques, ce qui implique

l'identification des actifs vulnérables sur lesquels
pèsent des menaces significatives
…et ce, d'une manière qui est adaptée au Détermination du niveau de criticité des différents
Ministère,… actifs informatiques. Détermination du meilleur
équilibre entre risques et coût de protection
…à son environnement… Identification des menaces:
* internes et externes,
* d'origine accidentelle ou intentionnelle
…et à l'état de son outil informatique Identification des vulnérabilités des actifs
informatiques
L’AMOA mobilisée devra avoir une solide expérience de tous les aspects de la sécurité des systèmes
d’information et pour cela un budget de 30 MFCFA est proposé.
Ce projet devra éventuellement être ré-évalué par le comité du PESI afin de permettre la mise en
œuvre de vidéo surveillance pour les bureaux identifiés qui ne sont pas encore équipés.
Justification
Ce projet entre dans l’activité 4.5 et participe à la réalisation des activités 2.3 et 3.3 en garantissant un
outil fiable et sûr.

Nom du projet : S2 : Audit des risques environnementaux des installations du

MEF, recommandations et mise en œuvre
20 000 000 FCFA (audit) 1

Budget indicatif Priorité (1, 2 ou 3)
180 000 000 FCFA (mise en œuvre) 2
En conjonction avec la sécurité des installations électrique, les installations du MEF sont exposées aux
menaces environnementales que représentent les inondations et les incendies. Or il est peu fréquent de
voir les bâtiments disposer de mécanismes de détection des incendies ou de protection adéquates contre
les conséquences d’une inondation.
Ce projet veut donc organiser un audit de tous les bâtiments pour :

- Identifier leur exposition aux risques d’incendie
- Identifier leur exposition aux risques d’inondation
- Lister les conséquences d’un tel sinistre
- Recommander les mesures permettant de réduire au maximum ces risques et leurs
conséquences sur les dossiers et les données
Nul doute que les recommandations impliqueront la mise en place d’équipements de détection/alarme
incendie ainsi que des moyens de combattre le feu (extincteurs). Prévenir les inondations passera par le
déplacement de certains services critiques et/ou de certaines archives.
Pour réaliser tout ceci, un premier budget prévisionnel de 200 MFCFA est proposé. L’audit est une activité
à lancer dès à présent.
Notons également qu’une partie de ce budget sera réservé à l’équipement d’un système de vidéo
surveillance des bureaux du ministère. Une étude préalable a déjà été menée, et précise qu’il faut 181
caméras fixes, 6 caméras bull, 21 mini dômes, 15 coffrets et 40 écrans plats. Une budget de 50 MFCFA, à
prendre sur les 180 MFCFA, sera réservé pour ces investissements.
Justification
Ce projet participe aux activités 4.4 et 4.5 et consolide les objectifs poursuivis par l’activité 3.3.

Nom du projet : S3 : Sensibilisation des utilisateurs à la sécurité

Ce projet vise à organiser des séminaires et conférences à destination des décideurs et cadres du MEF
pour les sensibiliser aux nécessités quotidiennes garantissant la sécurité des données, des équipements
et des personnes dans les structures du MEF.
Il donne également des moyens au futur RSSI pour véhiculer son message dans l’ensemble du
Ministère, par exemple en éditant et diffusant des plaquettes auprès des utilisateurs : « les 10
commandements de la sécurité » (Tu ne révèleras ton mot de passe à personne, et surtout pas au
téléphone ; Tu n'ouvriras pas de pièces jointes suspectes dans ta messagerie ; Tu protègeras ton
économiseur d'écran par un mot de passe, etc.), des affiches et calendriers («avez-vous sauvegardé vos
fichiers cette semaine?»), etc.
Justification
Ce projet entre dans l’activité 3.1 et participe à la réalisation des activités 2.3 et 3.3 en garantissant un
outil fiable et sûr.

4. Mise en œuvre des projets
4.1 Gouvernance et Unité de Gestion
La mission a été informée de l’existence de l’arrêté n°11/MFE/DC/SGM/DOI pris le 26

janvier 2005 portant attributions, organisation et fonctionnement des structures de pilotage
et de mise en œuvre du système intégré de gestion financière au Bénin23. Cet arrêté a été
pris dans la continuité du schéma directeur informatique de 2004 et visait à mettre en place
les instances de gouvernance requises pour une mise en œuvre efficace.
Nous n’avons pas été informés sur d’autres dispositions qui modifieraient cet arrêté, aussi
nous considérons que le MEF devrait réactiver ces instances, qui sont tout à fait pertinentes
et les utiliser pour assurer le suivi de la mise en œuvre des recommandations et des projets
du PESI 2011.
Les représentants des structures créées après ce décret et impliquées dans les projets de
réforme du Ministère (par exemple l’UGR) devront cependant être intégrés dans ces
instances.
Outre la structure de pilotage PESI, nous proposons que soit défini une Unité de Gestion
(UG) du PESI qui, au quotidien, sera responsable de la mise en œuvre des projets du PESI,
et qui rendra compte à la structure de pilotage. L’UG pourra être l’UGR ou la DOI ou
toute autre structure (nous pensons que la DOI semble cependant tout à fait indiquée), cela
est à définir par le MEF. Si le PESI bénéficie de l’appui d’une assistance technique de long
terme, alors nous recommandons que l’AT soit logée au sein de cette UG PESI.
L’Unité de Gestion du PESI doit être dotée de moyens financiers pour son
fonctionnement, et sera également responsable d’attribuer des primes aux agents qui
travaillent sur les projets et des perdiem pour les réunions. Nous proposons un budget de
fonctionnement de 2 MFCFA par mois pendant les 3 années du PESI, soit 72 MFCFA en
tout.
4.2 Mise à jour du PESI
Le PESI 2011 est un document vivant. Il est illusoire de penser que les projets qui ont été
définis en 2011 resterons tous intégralement pertinents jusqu’en 2014.
Les contextes évoluent, les lois changent, les technologies avancent, des faits nouveaux non
prévus surgiront, etc. Il faut tenir de toutes ces évolutions en permanence pour adapter le
PESI de façon à le maintenir à tout moment pertinent.
Bien sûr, il ne s’agit pas de modifier les grands principes des orientations prises, mais
d’adapter les projets, d’en fusionner éventuellement, et de les décrire plus précisément au
fur et à mesure de l’avancement des réalisations du PESI.
23
L’arrêté peut être téléchargé sur le portail : http://e-sud.fr/client/PESI_Benin/doc/doc_recu/arrete_2005_11_MEF.pdf

Pour cela, nous proposons que le comité de pilotage du PESI organise une fois par an une
revue du PESI pour étudier l’opportunité de l’adapter au nouveau contexte.
De la même façon que le PESI a été validé par toutes les parties prenantes, les
amendements au PESI doivent être validés par ces mêmes parties prenantes.
4.3 Planification, priorités
Le calendrier envisagé a été présenté plus haut dans le chapitre 3.2 de cette même partie.
4.4 Financement
Le PESI est ambitieux de par les projets proposés. Ces projets sont ceux attendus par le
MEF et les PTF. La mise en œuvre de ces projets requiert d’importants moyens. Le fait de
présenter tous ces moyens dans un même tableau (cf. chapitre 3.2) peut donner
l’impression qu’ils sont élevés. Pourtant, lorsque les projets informatiques sont présentés
séparément, sans chercher à mutualiser certaines actions, les moyens sont encore plus
considérables.
Tous les projets présentés sont nécessaires si l’on veut atteindre l’objectif de fiabiliser les
chiffres de GFP qui sont produits.
Nous avons préconisé des modifications dans les budgets de projets pourtant déjà inscrits
au DP1 car il nous a semblé pertinent de réorienter ces activités. D’autres projets nous ont
semblés non essentiels ou réalisables en interne au MEF. De ce fait leurs budgets ont été
réduits à 0.
Le budget ci-dessous tient également compte du projet à la DGID de 1 800 MFCFA
financé par les Canadiens.
La répartition des budgets consolidés (en millions de FCFA) selon les domaines
d’intervention se résume ainsi :
Domaine Budgets
(MFCFA)
Fonctionnement UG PESI 72
Organisation et RH 750
Applications 3 030
Sites WEB 190
Parc informatique 705
Réseau informatique 368
Réseau électrique 688
Sécurité 250
TOTAL 6 053
Les applications informatiques représentent la plus grande part de l’investissement requis

car il s’agit tout simplement là de la « matière grise » du SI que l’on souhaite mettre en
place.

Le réseau informatique semble moins doté dans notre estimation que ce que l’on
imaginerait sachant qu’il s’agit du cœur du SI. Mais c’est aussi parce que ce domaine a déjà
reçu des investissements importants ces dernières années et qu’une nouvelle phase de
modernisation doit s’engager pour laquelle il est encore trop tôt pour définir précisément
une enveloppe.
Si on considère l’ensemble des budgets qui étaient prévus pour les projets programmés
(colonne « prévus » du tableau du chapitre 3.2), le total est de 7 794 MFCFA. Même si tous
les projets prévus n’étaient pas encore totalement financés, les financements déjà prévus
doivent suffire au financement du PESI.
La mise en œuvre du PESI ne devrait donc pas souffrir d’un problème de financement. Le
principal challenge sera la capacité du MEF à se coordonner pour sa mise en œuvre …

Partie C :
Annexes
1. Configurations types des matériels
1.1 Postes de travail
1.1.1 Ordinateur de bureau
Elément Caractéristiques
Processeur Intel Core i5 Quad-Core (min 2.5 Ghz)
AMD Athlon II X4 ou Phenom II X4 (min 2.5 GHz)
Mémoire RAM 4 Go DDR3
Disque dur 320 Go S-ATA (7200 rpm)
Lecteurs de disque DVD+/-RW avec technologie LightScribe
Cartes multimédia (5in1 ou +)
Carte graphique Intel GMA 4500 intégrée
Carte réseau Ethernet gigabit intégrée
Wifi 802b/g
Périphérique de Clavier 102 touches AZERTY
contrôle Souris optique avec molette + tapis
Ecran LCD 20 pouces
Divers Haut parleurs intégrés
6 Ports USB 2.0 dont 2 en façade
Système Windows 7 – 64 bits (français)
Logiciels MS Office 2010 (français) avec licence
Antivirus avec abonnement 12 mois*
* l’antivirus devra être en accord avec les choix effectués par la DOI pour la sécurité du réseau entier (même
antivirus sur tous les postes pour faciliter leur maintenance et mise à jour).
1.1.2 Imprimantes
Technologie Laser
Vitesse Minimum 26 pages par minute
Qualité 1200 x 1200 ppp
Pages par mois Minimum 2000
Langages supportés PCL6, PCL5, PS
Bacs 2 (dont un de 250 feuilles minimum)
Connectivité USB, RJ45 (Ethernet)
Compatibilité Windows XP, Vista, 7, server 2003, server 2008
Format papier Minimum A4, A5, envelopes

1.1.3 Onduleurs
Capacité 1500 VA
Technologie Online double conversion
Connectivité USB
Nombre de prises 4
Tension d’entrée 220/230V
Fréquence d’entrée 50 Hz
Tension de sortie 230V +/- 5%
Fréquence de sortie 50 Hz +/- 6%
1.2 Serveurs et systèmes de sauvegarde
1.2.1 Serveurs
Format Montage en rack
Processeurs 2x Intel Xeon E56xx (4 cœurs, minimum 2,5 GHz)
Mémoire 12 Go DDR3, extensible
Mémoire cache 12 Mo (L3)
Disques durs 6x146 Go SAS (15k rpm) + 1 en secours, hotswap
Contrôleurs 1 Gb Ethernet redondant
Gestion des disques RAID (0, 1, 5 avec disque de secours)
Alimentation Redondante, 750W
Lecteurs DVD-ROM 16x SATA
Système Windows 2008 R2 64 bits
Linux (Red Hat Enterprise) 64 bits
Un système clavier-écran-souris devra être prévu pour chaque rack afin de pouvoir gérer les
serveurs.
1.2.2 Systèmes de sauvegarde (NAS)
Processeurs Intel Xeon E55xx (double cœur, minimum 2 GHz)
Mémoire 4 Go DDR3, extensible
Disques durs 4x2 To SAS (10k rpm) + 1 en secours, hotswap
Contrôleurs 1 Gb Ethernet redondant
Gestion des disques RAID (0, 1, 5 avec disque de secours)
redondante (2 cartes)
Alimentation Redondante, 750W
Lecteurs DVD-ROM 16x SATA
Système Windows Storage Server 2008
Linux (Red Hat Enterprise)

1.2.3. Systèmes de sauvegarde (bandes)
Nombre de lecteurs 2
Type de lecteur LTO5
Capacité des lecteurs 1,5 To
Débit Jusqu’à 1 To / heure
Si la sauvegarde des données sur disque dur permet de nos jours une bonne sécurité des
informations, seule la sauvegarde sur bande autorise la prévention contre les flammes,
inondations et autres périls. Il est en effet possible de stocker les bandes dans une armoire
ou un coffre à l’épreuve de ces éléments tout comme on peut mettre les bandes à l’abri
dans un endroit physiquement différent du lieu principal d’utilisation des données.
C’est pourquoi les caractéristiques des serveurs de bandes sont proposées.

2. Liste des applications informatiques
Liste également disponible sur le portail www.e-sud.fr/client/PESI_Benin
Nom de Direction Description Commentaire Technologie

l’appli
ASTER DGTCP Comptabilité générale de l’Etat. Quelques interfaces doivent encore être ORACLE 8
développées pour éviter la double saisie et
garantir l’intégrité des données.
MATKOSS DGTCP Suivi des bordereaux et mandats Interface MATKOSS -> ASTER permettra WINDEV 7
d’éviter la double saisie.
MATKOSS pré-existait avant ASTER et il
semble que certaines fonctionnalités soient en
commun.
Projet interface SICA-UEMOA -> MATKOSS
en préparation (cabinet local COMTEL établit
un devis).
FLEURETTE DGTCP Gestion des comptes des Projet interface SICA-UEMOA -> WINDEV 10
correspondants du Trésor FLEURETTE en préparation (cabinet local
COMTEL établit un devis).
WMoney DGTCP Tenue de la comptabilité générale WINDEV 7
de l’Etat
TITRAGENT DGTCP Gestion des créances dues aux
APE
Fond DGTCP
modernisation
SICA-UEMOA DGTCP
SDL7 DGTCP, DGB Gestion de la solde Utilisé depuis 2000 ORACLE 7
SUNKWE DGB Gestion de la solde Doit remplacer SDL7, mais en stand-by depuis ORACLE
2 ans, nécessitant l’équivalant de 2 pers à plein
temps
MIR DGRH, Gestion des ressources humaines Logiciel utilisé dans plusieurs directions, mais WINDEV
DGTCP, DGB, (gestion des carrières) de manière indépendante et non synchronisée
DGDDI, DGID avec la gestion de la solde et la fonction
publique
SIGMAP DNCMP Gestion des marchés publics Projet à lancer JAVA
SISFOM DRFM Gestion des fournitures et du Projet en cours pour intégrer la gestion des WINDEV
matériel immobilisations et amortissements depuis sept
2010
SHISEPIP Planification et suivi des projets
TAKOE DGID Calcul d’assiettes et suivi des TAKWE manque de cohérence d’info. 3 WINDEV 10
recouvrements installations indépendantes (DGID/DIE,
CIME littoral et CIME atlantique)
IFU DGID Gestion des identifiants fiscaux Le transfert des données vers les applications ORACLE
uniques utilisant l’IFU se fait manuellement.
RFU DGID Registre du foncier urbain RFU mal sécurisé et peu fiable. Suivi par un WINDEV 5
prestataire depuis sa création en 1991. Aucun
lien avec IFU, doublons présents, chaque
installation de RFU est indépendante des
autres.
COFRET DGID Pour le suivi des domaines, N’a jamais été utilisé. Le MCA finance l’écriture WINDEV
enregistrements et timbres fiscaux d’un remplaçant.
WINIMPOT DGID Suivi des montants versés au Utilisé par 4 personnes uniquement à la DGID WINDEV 5.5
Trésor et des dépenses pour frais
internes réalisés par
l’administration fiscale dans le

pays.
SYDONIA- DGID Sous ensemble de données issues Les extractions sont faites manuellement. Une WINDEV 7.5
DGID de Sydonia++ et utilisé pour créer liaison fiable entre DGDDI et DGID rendra
des états spécifiques à la DGID cette application inutile
DNVEF DGID Copie des mandats émis dans Ces données servent à des recoupements sur les WINDEV
SIGFiP et utilisée par la direction entreprises bénéficiant de commandes.
nationale des vérifications et des Transfert annuel et manuel des données.
enquêtes fiscales.
GESEXO DGID / Gestion des exonérations (MP1 et Transfert des MP2 manuellement de DGID WINDEV 5.5
DGDDI MP2 à la DGID, MP3 à la vers DGDDI, pas de retour d’information
DGDDI) depuis la DGDDI. Projet de réécriture.
SIGFIP DGB Suivi de l’exécution du budget de Application majeur de l’Etat ORACLE
l’Etat
SICOPE DGB, DGTCP Gestion des pensions ORACLE
SIPIBE DGB Préparation du budget Absence des codes sources, dépendant d’un WINDEV 5.5
prestataire
SYDONIA++ DGDDI Application principale de gestion Produit et suivi par la CNUCED. C++ et
des déclarations en Douanes. ORACLE
SADEMAR DGDDI Permet aux consignataires de convertir leurs données de manifestes et déclarations en WINDEV
un format de fichier compréhensible par Sydonia, évitant ainsi une saisie fastidieuse
des données élémentaires.
SYSCODA DGDDI Préparation des états comptables à partir des journaux disponibles dans Sydonia. WINDEV
EUROTRACE DGDDI Production de statistiques sur le Produit et suivi par la CNUCED
commerce extérieur à partir des
liquidations stockées dans Sydonia.
ESPACE DGDDI Production de statistiques sur le Développé par la DGDDI ACCESS
commerce extérieur à partir de
toutes les données de Sydonia.
GESPER DGDDI Gestion du personnel (primes, salaires). Produit toujours en évolution. WINDEV
TRANSIT DGDDI Création puis apurement par des bons de retour des déclarations en transit vers WINDEV
d’autres Etats. Les déclarations sont lues dans Sydonia.
DECONSIT DGDDI Déconsignation des véhicules déclarés en transit suite à la réception des bons de WINDEV
retour. Les déclarations sont lues dans Sydonia.
AGBAN DGDDI Gestion des stocks. WINDEV
SICA DGDDI Gestion des contentieux automatisés. WINDEV
DEBA DGDDI Saisie des déclarations dans les services régionaux pour les postes non informatisés. WINDEV
Ces données sont ensuite collectées par les agents de la DGDDI.
SIGRH DOI Système de gestion des ressources Doit remplacer MIR depuis quelques années ORACLE
humaines mais n’est toujours pas en utilisation.
GESMAR DGML Gestion des matériels roulants Utilisé sur un poste unique, créé et géré par un ACCESS 2003
prestataire (codes sources non disponibles)
GESTIMMO DGML Gestion du parc immobilier bâti Utilisé sur un poste unique, créé et géré par un ACCESS 2003
prestataire (codes sources non disponibles)
DEBTPRO CAA Simulations et prévisions d’endettement
CSDRMS2000 CAA Gestion comptable de la dette ORACLE 8
SIGMAE CAA Gestion des mobilisations Logiciel toujours en développement interne ORACLE 4
CIRPRET CAA Suivi des recouvrements des prêts rétrocédés. ORACLE 4
CIPAIE CAA Gestion de la paie (sous Delphi et monoposte). Un autre logiciel est en cours de ORACLE 4
développement.
GESTPRIMES DOI, CF, etc. Calcul rapide des primes allouées Utilisée dans plusieurs directions de manière WINDEV
aux agents de l’Etat indépendante

3. Appels d’offres pour CF, DGTCP,

DGID et UGR
Avis de la mission PESI sur les dossiers d’appel d’offres au bénéfice du CF, de la DGTCP,
DGID et de l’UGR
3.1 Objet
La DUE souhaite publier des appels d’offres pour les activités suivantes :
- Mise en œuvre d'un système informatique de suivi des activités des composantes
(activité 4.16.1.2 du DP1)
- Acquisition d'équipements complémentaires au profit de l'UGR (activité 4.16.2.3)
- Acquisition des équipements informatiques au profit des personnels de

l'administration centrale du Contrôle Financier (activité 2.10.3.3)
- Equipement des locaux de la DGCTP et acquisition d'équipements informatiques

(activités 3.9.2.2 et 3.9.3.1)
Les dossiers comportent déjà des spécifications pour les matériels prévus et la DUE ainsi
que l’UGR souhaitent l’avis technique de la mission PESI sur ces données.
3.2 Observations générales
Au regard des documents fournis, il semble qu’une réflexion plus poussée aurait pu être
menée pour la préparation des spécifications techniques. La plupart du temps il s’agit
simplement d’une copie directe des données figurant sur les plaquettes commerciales des
équipements désirés, slogans marketing inclus.
Il n’est de ce fait pas étonnant que les caractéristiques ainsi insérées dans les dossiers d’AO
puissent être rejetées au motif qu’elles sont bien trop précises et de ce fait entraînent un
marché bien trop fermé. Il ne faut pas non plus oublier que toute caractéristique présente
dans un appel d’offre peu devenir de facto éliminatoire pour les offres. Cela vaut aussi pour
l’indication des marques des matériels.
Par contre certaines marques sont incontournables dans certains cas :
- Conserver l’homogénéité du parc matériel afin de garantir une maintenance plus
aisée (même marque et modèle d’imprimantes, même marque d’ordinateurs, etc.)
- Utilisation de standards incontournables dans le domaine bureautique professionnel

(le système MSWindows et la suite MSOffice en sont les exemples évidents)

3.3 Appel d’offre pour l’UGR
3.3.1 Matériel bureautique
Les caractéristiques techniques présentées sont bonnes, nonobstant la présence

d’informations marketing et commerciales (liste exhaustive des formats supportés ou des
formats d’impression, liste de tous les logiciels inclus, etc.).
3.3.2 Matériel de communication et réseau
Il s’agit du réseau local de l’UGR et de sa connexion avec le MEF. L’UGR a très tôt mis en
place un réseau local pour relier la dizaine de postes fixes qui équipe ses bureaux. Un
câblage est en place doublé d’une couverture wifi. L’ensemble permet aux utilisateurs
d’accéder à Internet via une connexion fournie par le prestataire Connecteo. Un pylône a
été installé à cette occasion.
Il manque par contre les éléments permettant de profiter à plein d’un réseau informatique :
serveur, espace de stockage et liaison avec le Ministère des Finances. L’acquisition de 2
serveurs (dont un en secours) équipé du système MS Windows Server est judicieuse. Par
contre un switch équipe déjà l’UGR pour son réseau.
La connexion au MEF doit être assurée par une antenne fixée sur un pylône et dirigée vers
le MEF. Trois options sont possibles :
1. conserver le pylône actuel (Connecteo) et y ajouter l’antenne du MEF
2. installer un pylône spécifique pour cette antenne
3. Racheter à Connecteo son pylône actuel
La première option rend l’UGR dépendante du contrat avec Connecteo qui conserve la
propriété de son pylône. La seconde option sépare les deux équipements mais place 2
pylônes sur le bâtiment de l’UGR. L’idéal est soitune solution intermédiaire qui consiste à
placer un nouveau pylône acquis par l’UGR sur lequel sera fixé la nouvelle antenne du
MEF ainsi que l’antenne de Connecteo qui, ainsi, pourra récupérer son pylône, soit la
troisième solution.
3.3.3 Matériel électrique
Il s’agit d’assurer la sécurité et l’autonomie des équipements de l’UGR en cas de coupure de

courant. L’acquisition d’un onduleur est fondée ainsi que la mise en place d’un circuit
électrique spécifique branché sur cet onduleur. Il conviendra de se souvenir que les
imprimantes laser ne doivent pas être branchées sur ce réseau ondulé en raison de la
puissance requise pour le préchauffage de l’imprimante. L’utilisation de ces équipements
doit être réservée aux périodes de fourniture normale d’électricité, soit par l’opérateur, soit
par le générateur.

3.4 Appel d’offres pour la DGID
Les caractéristiques du matériel demandé sont bonnes, sous réserve des remarques
générales énoncées plus haut et de celles-ci :
- Il n’est pas nécessaire de demander une possibilité de mise à niveau vers Windows
XP depuis Windows 7 si le bénéficiaire n’a pas l’intention de l’utiliser. Cela avait un
sens avec Windows Vista ;
- Les capacités des cartes graphiques pour une machine dédiée à la bureautique sont
bonnes pour l’ensemble des ordinateurs du marché. Il n’est pas utile de les spécifier
si l’on ne souhaite pas quelque chose de particulier ;
- La carte réseau doit simplement avoir une capacité gigabit afin de ne pas indiquer
de marque ;
- La connectique de la machine devrait être indiquée uniquement pour les ports

essentiels ;
3.5 Appel d’offres pour CF et DGTCP
Les remarques énoncées plus haut s’appliquent aussi, y compris celles de l’appel d’offres
pour la DGID. En sus :
- Le terme « scansnap » semble être une dénomination commerciale d’une option
chez un fabricant (Fujitsu en l’occurrence) ;
- La technologie des imprimantes n’est pas spécifiée, ce qui est important, alors que
d’autres détails sans importances sont précisés ;
- L’imprimante réseau (item 9) est en fait une imprimante gros volume (le format A3
est-il nécessaire ?) ;
- Les caractéristiques des serveurs sont bonnes, mais trop précises. Il vaut mieux
indiquer des valeurs minimales (mais cohérentes et réalistes) ;
- Enfin l’usage de ces serveurs est-il justifié ? (à ce jour aucune application connue au
CF ne justifie un serveur et la DGTCP en possède déjà une vingtaine…).
3.6 Conclusion
Sous réserve de corriger les spécifications en prenant en compte les remarques énoncées
ici, les appels d’offres concernant l’UGR peuvent être lancés. Il est par contre souhaitable
que les autres dossiers puissent attendre les conclusions de la mission PESI afin de placer
les acquisitions dans le contexte global d’évolution du SI du Ministère.

Pesi PDF

Transféré par

Droits d'auteur :

Formats disponibles

Pesi PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pesi PDF

Transféré par

Droits d'auteur :

Formats disponibles

Lettre de marché N° 2010/257973

Contrat Cadre EuropeAid: 127054/C/SER/multi - Lot 11

Plan d’Evolution du Système

Rapport final – version définitive

Table des matières

Rapport final – version définitive - Août 2011 Table des matières

Scénario 2 « raisonnablement ambitieux »: Intégration et centralisation du SI ...................... 44

Rapport final – version définitive - Août 2011 Table des matières

3.3 PROJETS LIES A L’ORGANISATION ET AUX RESSOURCES HUMAINES ........................... 91

Rapport final – version définitive - Août 2011 Table des matières

Rapport final – version définitive - Août 2011 Table des matières

Rapport final – version définitive - Août 2011 Abréviations

1.1 Contexte général

Le Ministère de l’Economie et des Finances (MEF) a pour mission de proposer et de

Le MEF s'est doté depuis de nombreuses années de moyens informatiques importants.

En 2009 le gouvernement a lancé un Plan d'Actions pour l'Amélioration de la gestion des

1.2. Objet de la mission

La mission a pour but de concevoir un Plan d’Evolution du Système d’Information (PESI)

Rapport final – version définitive - Août 2011 Page 1

est intégré au SDI et concerne la première période de 2-3

Rapport final – version définitive - Août 2011 Page 2

1.3. Les enjeux du plan d’évolution

Des opérations d'informatisation, toujours plus nombreuses, sont lancées et le recours à

L'enjeu essentiel de la mission sera donc de permettre au MEF d'améliorer le traitement de

Rapport final – version définitive - Août 2011 Page 3

De cette manière le SI se trouve organisé en BLOCS FONCTIONNELS déconnectés des

Rapport final – version définitive - Août 2011 Page 4

La méthodologie adoptée par la mission est décomposée en quatre étapes principales

La période de terrain s’est déroulée du 04 au 29 avril 2011 à Cotonou et du 16 au 20 mai

Lors de la première semaine, la DOI a fourni au chef de mission un ensemble de

La troisième et dernière phase consiste à présenter, dans une démarche participative, le

Rapport final – version définitive - Août 2011 Page 5

2.2 Structure rencontrées

L’organigramme du Ministère des Finances,

Figure 1 : Organigramme actuel du Ministère

L’ensemble des rendez-vous

Rapport final – version définitive - Août 2011 Page 6

Figure 2 : Structures rencontrées et calendrier des RDV

Rapport final – version définitive - Août 2011 Page 7

2.3 Planning de la mission

Les étapes de validation et de correction du rapport se déroulent successivement durant les

2.4 Organisation du document

Rapport final – version définitive - Août 2011 Page 8

La seconde partie découle de l’analyse de la situation observée et des besoins exprimés ou

Rapport final – version définitive - Août 2011 Page 9

2.5 Portail du rapport

Au vu du nombre de documents fournis, collectés ou produits au cours de cette mission,

Il est accessible à l’adresse http://e-sud.fr/client/PESI_Benin/PESI_Benin.php et permet

Nous ne pouvons que vivement recommander à la DOI de récupérer ce portail pour

Rapport final – version définitive - Août 2011 Page 10

3.1 Situation observée

3.1.1 Une organisation déconcentrée

Rapport final – version définitive - Août 2011 Page 12

Figure 3 : Nb d'informaticiens par structure

Rapport final – version définitive - Août 2011 Page 13

3.1.2 Des informaticiens d’un bon niveau technique mais insuffisamment

Le Ministère de l’Economie et des Finances compte environ 138 informaticiens, cadres et

4 MIR, GESPER, SIGRH, etc.

Rapport final – version définitive - Août 2011 Page 14