Martin Ludovic

Rapport de stage
Ludovic MARTIN
Mastère spécialisé en
Architecture des Systèmes d’Information 2007
Pérennisation de l’infocentre Ressources

Humaines des bases aériennes
Stage réalisé du 05 mars 2007 au 31 août 2007
Responsables de stage :
 Lieutenant-colonel Philippe Poumaroux : chef du département ressources humaine
administration et finance du centre des systèmes d’information air (CSIA).
 M. Michel Mauny : responsable du Mastère - ENSTA
Rapport de stage Mastère ASI
REMERCIEMENTS
Je tiens à remercier l’ensemble des personnes qui m’ont aidé à réaliser cette étude.
Ces remerciements s’adressent tout particulièrement aux personnels de la division

ressources humaines du CSIA qui ont constamment répondu à mes sollicitations en dépit de leur
charge. Leurs compétences techniques et fonctionnelles ont permis de répondre à toutes les
questions et de faciliter ainsi l’aboutissement de ce travail.
Par ailleurs, je tiens à remercier le commandant du Centre des systèmes d’information air le
Lieutenant-colonel Lasvenes ainsi que mon responsable de stage le Lieutenant-colonel Poumaroux
pour leur disponibilité, leurs précieux conseils et pour la confiance qu’ils m’ont témoignée.
2/54
SOMMAIRE
1.Préambule............................................................................................................... 5
1.1Rappel du sujet................................................................................................... 5
1.2Analyse du sujet.................................................................................................. 5
1.3Limites du sujet................................................................................................... 5
1.4Enjeux de l’étude................................................................................................. 5
2.L’organisme d’accueil : Le Centre des Systèmes d’Information Air (CSIA)......6
2.1Carte d’identité.................................................................................................... 6
2.2Missions.............................................................................................................. 6
2.3Organisation........................................................................................................ 7
3.Contexte de l’étude................................................................................................. 8
3.1Un système en fin de vie : SIGAPAIR V5............................................................ 8
3.2Une solution de pérennisation immédiate : SIGAPAIR V6.................................. 9
3.3Un projet interministériel s’appuyant sur le PGI SAP : ORCHESTRA.................9
3.4Un projet décisionnel de niveau ministériel : PITAGORE.................................. 10
4.Pérennisation de l’infocentre des bases aériennes........................................... 12
4.1Analyse de l’existant.......................................................................................... 12
4.2Différenciation des infocentres opérationnels et décisionnels........................... 13
4.3Les contraintes.................................................................................................. 14
4.3.1Contraintes calendaires............................................................................................14
4.3.2Contraintes financières.............................................................................................14
4.3.3Contraintes techniques............................................................................................. 14
4.3.4Contraintes de sécurité.............................................................................................15
4.3.5Facteur humain........................................................................................................ 15
4.4Solutions architecturales proposées................................................................. 16
4.4.1Solution1 : maintien de l’application actuelle mais avec une unique base de données
nationale........................................................................................................................... 16
4.4.2Solution 2 : montée en version de BiQuery pour permettre l’interrogation via une
interface web.....................................................................................................................18
4.4.3Solution 3 : récupération en l’état des requêtes Biquery et utilisation de briques open
source pour la présentation des données via une interface web...................................... 19
4.4.4Solution 4 : variante de la solution 3 avec transposition des requêtes BiQuery pour la
base de données SIGAPAIR V6........................................................................................ 21
4.4.5Tableau récapitulatif des solutions proposées......................................................... 22
5.Processus de développement du démonstrateur décisionnel RH................... 23
5.1Rappel sur les principes de l’informatique décisionnelle................................... 23
5.1.1Généralités............................................................................................................... 23
5.1.2Modélisation dimensionnelle....................................................................................25
5.1.3Data warehouse et datamarts...................................................................................27
5.1.4L’ETL (Extract Tranform and Load) - composant essentiel de l’architecture
décisionnelle..................................................................................................................... 29
5.1.5Les différents niveaux d’utilisation...........................................................................30
5.2 Périmètre retenu............................................................................................... 33
5.2.1Balance des droits et existants..................................................................................33
5.2.2Capacité de projection des personnels en opération ...............................................33
5.3Architecture logique........................................................................................... 34
3/54
5.4Modélisation dimensionnelle............................................................................. 35
5.4.1Choisir les datamarts............................................................................................... 35
5.4.2Déclarer la granularité de la table de faits..............................................................35
5.4.3Choix des dimensions............................................................................................... 37
5.4.4Définition des faits à mesurer...................................................................................39
5.4.5Modèles physiques de données................................................................................. 39
5.4.6Estimation de la volumétrie......................................................................................40
5.5Processus d’alimentation ETL........................................................................... 41
5.5.1Choix de l’ETL......................................................................................................... 41
5.5.2L’alimentation initiale.............................................................................................. 43
5.5.3L’alimentation incrémentale.....................................................................................44
5.5.4La reprise de l’historique......................................................................................... 45
5.5.5Le traitement des rejets.............................................................................................45
5.6Présentation de l’information............................................................................. 46
5.6.1Tableaux statiques – Jasper Report..........................................................................46
5.6.2Tableaux dynamiques – Mondrian / JPivot..............................................................48
5.6.3QBE.......................................................................................................................... 49
6.Déroulement du stage.......................................................................................... 50
7.Préconisations organisationnelles pour la conduite d’un projet de data warehouse
d’entreprise.............................................................................................................. 51
8.Conclusion............................................................................................................ 52
4/54
1. Préambule
1.1 Rappel du sujet
L’Armée de l’air effectue actuellement une migration de son système d’information des
ressources humaines (SIRH) d’une architecture client serveur distribuée vers une architecture
intranet centralisée. Cette évolution majeure va rendre inopérant l’actuel infocentre RH des bases
aériennes. Le premier objectif du stage consiste donc à proposer une solution concrète de
pérennisation.
Parallèlement, le Centre des systèmes d’information air (CSIA) souhaite mener une réflexion
plus large sur les infocentres. En effet, la plupart des applications de gestion sont dotées d’un
infocentre spécifique développé de manière isolée. Cette situation ne permet pas de répondre
efficacement aux nouveaux besoins et génère des coûts en terme d’achat de licences et de
maintenance qui ne sont pas satisfaisants. Au-delà de la pérennisation d’un outil existant, cette
étude doit donc permettre de jeter les bases d’un entrepôt de données décisionnel.
1.2 Analyse du sujet
L’informatique décisionnelle distingue deux types d’infocentre : d’une part les infocentres
opérationnels qui sont le prolongement des systèmes de production et d’autre part, les infocentres
décisionnels conçus pour produire des informations à haute valeur ajoutée provenant souvent de
plusieurs systèmes sources. L’analyse de l’infocentre RH montre qu’il appartient à la première
catégorie. Ce constat impose de distinguer deux axes de travail pour couvrir complètement la
problématique:
 proposer des solutions pour pérenniser l’infocentre ressources humaines en prenant en
compte les contraintes engendrées par la modernisation déjà en cours du SIRH1;
 définir au travers un exemple issu du tableau de bord DRHAA2 des bases aériennes
comment mettre en œuvre un infocentre décisionnel.
1.3 Limites du sujet
Un entrepôt de données décisionnel est par essence transverse aux différents domaines de
l’entreprise. Cependant cette étude ce limitera au domaine SIAG (systèmes d’information
d’administration et de gestion) qui constitue le domaine de compétence du CSIA.
Par ailleurs, ce travail n’a pas pour but de comparer les différentes solutions décisionnelles du
marché. L’expérience acquise pour le développement du démonstrateur ne suffit pas pour arrêter
des préconisations.
1.4 Enjeux de l’étude
Votée en 2001, la loi organique relative aux lois de finance (LOLF) s’applique à toutes les
administrations depuis le 1er janvier 2006, l’armée de l’air est donc soumise à cette nouvelle
réglementation qui entend promouvoir la culture du résultat plutôt que la culture de moyens. Les
responsables de programme LOLF sont les dépositaires de cette culture de la performance, ils gèrent
comme ils l’entendent les moyens qui leur sont alloués pour atteindre les objectifs fixés par les
politiques. Ils ont donc besoin de suivre l’évolution des indicateurs de performance de l’entreprise pour
prendre les bonnes décisions. Ils doivent par ailleurs justifier leurs dépenses dés le premier euro à l’aide
d’éléments tangibles. Ceci est impossible sans un système d’information décisionnel performant.
L’enjeu d’un projet décisionnel à l’échelle de l’entreprise est donc bien la maîtrise de l’information.
1
SIRH : système d’information ressources humaines
2
Direction des ressources humaines de l’armée de l’air
5/54
2. L’organisme d’accueil : Le Centre des Systèmes

d’Information Air (CSIA)
2.1 Carte d’identité
 Date de création : Unité créée en 1944 par le Général VALIN

 Subordination : Le CSIA est une unité du Commandement du
soutien des forces aériennes (CSFA.) Il constitue l’un des deux
centres informatiques de l’armée de l’air
 Nombre de personnels : 172 (34 officiers, 123 sous-officiers, 6
militaires du rang, 9 civils)
 Implantation : Base aérienne 217 de Brétigny-sur-orge
Figure 1: Insigne du CSIA
2.2 Missions
Le CSIA assure des missions très variées et parfaitement complémentaires :
 Maîtrise d’œuvre
Il s’agit d’une mission majeure du centre puisqu’elle concerne environ 90 personnes. Le CSIA
conçoit, réalise et maintien des logiciels dans de nombreux domaines :
 ressources humaines,
 finances,
 restauration,
 matériels techniques,
 matériels commissariat.
 Hébergement d’applications et des sites web

Le CSIA assure l’hébergement sur différents réseaux (Internet, Intradef3, Intraced4) des
applications nationales (dont SIGAPAIR5 V6) ainsi que des sites Web de l’armée de l’air. Ces
systèmes d’information installés sur les serveurs de la salle de production du CSIA nécessitent de
garantir un haut niveau de disponibilité et de sécurité.
 Lutte informatique défensive

Le CSIA participe à l’organisation permanente de veille d’alerte réponse (OPVAR) en tant que
centre expert en matière de sécurité informatique. A cette fin, il dispose en son sein de la cellule de
vigilance informatique orientée application (CVIOA).
 Formation
Le CSIA assure la formation des spécialistes de la sécurité des systèmes d’information ainsi
que la gestion des stages informatiques au profit de l’ensemble des personnels de l’armée de l’air.
3
Intradef : réseau intranet du ministère de la défense utilisé pour les informations sensibles
4
Intraced : réseau intranet du ministère de la défense utilisé pour les informations classifiées de défense
5
SIGAPAIR : système informatique de gestion et d’administration des personnels air
6/54
Ces quatre missions principales concourent à donner au CSIA un haut niveau

d’expertise dans de nombreux domaines (sécurité informatique, conduite de projet,
architecture des systèmes d’information), ce qui lui permet de réaliser des études très
pointues et de participer à plusieurs groupes de standardisation ministériels.
Cette expertise se traduit également par des missions d’assistance à maîtrise d’ouvrage
(AMOA) au profit de l’Etat-major de l’armée de l’air sur des projets transverses.
2.3 Organisation
Commandant
le centre
Commandant en second Bureau Contrôle de gestion

Section & qualité
le centre
Commandement
Bureau Assistance
à Maîtrise Ouvrage
Division Formation
Bureau cohérence ASSI
Département RH Département Matériels Département Technique

Administration finance
Division RH Division Mat Technique Division Systèmes
Division AGF Division Mat Commissariat Division Exploitation
Division LID applicative

Figure 2: Organigramme du CSIA
Cette étude a été menée au sein de la division ressources humaine du département ressources
humaines administration finance. Cette division qui a une mission de maîtrise d’œuvre logicielle et
d’expertise est notamment en charge du MCO6 de SIGAPAIR V5, du développement de SIGAPAIR V6
et la maintenance évolutive et corrective de l’application BRH7. Ces trois applications sont les sources
de données références du domaine couvert par cette étude (cf. §3).
6
MCO : maintien en condition opérationnel
7
BRH : Bureau ressources humaines
7/54
3. Contexte de l’étude
Dans un premier temps, il a été nécessaire d’examiner le contexte applicatif et projet de l’étude. En ce
qui concerne les SIRH, quatre systèmes sont à prendre en compte :
 SIGAPAIR V5: l’actuel SIRH référence de l’armée de l’air,
 SIGAPAIR V6: la version web de SIGAPAIR qui remplace progressivement la V5,
 BRH : application de gestion du référentiel d’organisation de l’armée de l’air,
 ORCHESTRA : le projet ministériel s’appuyant sur le PGI SAP qui entrera en service courant 2009.
Enfin, il a été nécessaire de situer cette étude et l’éventuel projet décisionnel qui pourrait en résulter par
rapport au projet ministériel PITAGORE.
3.1 Un système en fin de vie : SIGAPAIR V5
SIGAPAIR est le principal système de gestion des ressources humaines (SIRH) de l’armée de l’air.
Technologie utilisée dans le cadre de SIGAPAIR V5:

 Langage : Open road, C
 Base de données : Ingres
 Architecture : client -serveur décentralisée
Le périmètre de cette application recouvre :

 les données privées de l'administré ;
 les données militaires;
 l'avancement ;
 la notation;
 la mobilité;
 les formations;
 les aptitudes ;
 les connaissances.
SIGAPAIR a été conçu à la fin des années 1990 ; à cette époque la qualité des réseaux imposait de
limiter le trafic sur les réseaux WAN 8 ce qui a conduit les concepteurs à faire le choix d’une architecture
client serveur décentralisée.
Ce système s’appuie sur un client lourd Open road déployé sur un poste Windows NT connecté à une
base de données Ingres locale à chaque base aérienne. Les bases de données sont déployées sur des
serveurs BULL ESCALA dotés d’un système d’exploitation UNIX AIX. Cette architecture est reproduite à
l'identique sur les 41 bases aériennes mais elle impose une réplication journalière sur deux serveurs
nationaux.
Arrivée à échéance du contrat de MCO des serveurs ESCALA:

L’architecture SIGAPAIR ne pourra être maintenue après 2009 avec l’arrivée à échéance du marché de
MCO des serveurs BULL. En effet, il existe un fort couplage d’une part, entre ce matériel et la version de
Ingres qui y est installée et d’autre part entre cette version de Ingres et le logiciel de réplication. Ainsi toute
modification de l’architecture en place visant à améliorer la pérennité du système engendrerait des
modifications lourdes de l’application.
L’infocentre SIGAPAIR V5 s’appuie sur cette architecture en fin de vie :

Un infocentre développé en interne sur la base de l'outil BiQuery de la société Humming Bird s’appuie
sur les bases de données locales de SIGAPAIR. L’infocentre est utilisé pour la gestion RH courante et il sert
8
WAN = Wide Area Network
8/54
aussi à réaliser des requêtes pour vérifier la cohérence des données du système. Enfin, en administration
centrale, il sert de base à l’établissement de rapports statistiques.
L'arrêt à court terme de SIGAPAIR V5 rendra inopérant l'actuel infocentre des bases aériennes.
Le CSIA doit donc prendre en compte l'infocentre dans sa démarche de pérennisation du SIRH, ce
qui constitue le premier axe de cette étude.
3.2 Une solution de pérennisation immédiate : SIGAPAIR V6
L’armée de l’air a lancé en 2005 un projet de modernisation du système SIGAPAIR. La maîtrise

d’oeuvre a alors décidé de passer à une architecture 3 tiers web centralisée.
Technologie utilisée dans le cadre de SIGAPAIR V6 :

 Langage : java
 Frameworks: struts (partie présentation), hibernate (mapping objet relationnel), PAMPAA (plate-
forme applicative multi-projets de l’armée de l’air)
 Base de données : Postgresql
Cette modernisation a commencé par la réalisation de nouveaux services jusque là absents de

SIGAPAIR V5 et ce plus particulièrement au profit des bases aériennes. Puis la question de la
pérennisation de SIGAPAIR V5 se posant, il a été décidé de transférer progressivement les
fonctionnalités de SIGAPAIR V5 vers ce qui allait devenir SIGAPAIR V6. Le transfert total, prévu pour la
mi 2008, permettra d’abandonner l’ancienne version sans attendre 2009, date d’arrivée prévue
ORCHESTRA (voir §3.3), projet qui s’intègre quant à lui dans une démarche interministérielle.
Par ailleurs, le passage à SIGAPAIR V6 doit être l’occasion d’assainir les données pour préparer
l’arrivée d’ORCHESTRA. Cette étude fera la démonstration que l’utilisation d’un ETL9 contribue à
l’amélioration de la qualité des données.
L’infocentre et l’entrepôt de données RH devront nécessairement s’intégrer à

l’environnement de SIGAPAIR V6.
3.3 Un projet interministériel s’appuyant sur le PGI SAP :

ORCHESTRA
La Direction générale de l'administration et de la fonction publique (DGAFP) mène un projet

interministériel visant à rationaliser les SIRH des différents organismes publics. L'objectif est de
permettre la consolidation nationale des données à partir de systèmes harmonisés et interopérables.
Ceci implique de définir un noyau commun sur lequel s'appuieront les SI des différents organismes.
Pour constituer un socle technique commun et atteindre rapidement cet objectif, la DGAFP a opté pour
un progiciel de gestion intégré (PGI). Après une procédure de marché public le progiciel SAP a été
retenu.
Le ministère de la défense s'inscrivant dans cette démarche, l'armée de l'air doit concevoir un
nouveau SIRH s'appuyant sur SAP. Ce projet baptisé ORCHESTRA pour "Outil de Réalisation du
Capital Humain et STRucturel Air" a été lancé en 2006 en parallèle du projet SIGAPAIR V6 pour une
mise en service prévue au plus tôt en 2009.
9
ETL : Extract Transform and Load
9/54
L'infocentre ressources humaines devra s'appuyer sur SIGAPAIR V6 qui sera le système RH
référence de l'armée de l'air au moins jusqu'en 2009. Cependant, il convient dans le cadre de cette
étude, de proposer les solutions techniques compatibles avec ORCHESTRA pour permettre la
continuité du service décisionnel après 2009.
3.4 Un projet décisionnel de niveau ministériel : PITAGORE
La mission d’aide au pilotage du ministère de la défense (MAP) conduit actuellement le

projet PITAGORE (Système d’information pour le PIlotage Transversal, strAtégique,
orGanique et Opérationnel du ministèRe de la défensE). L’objectif de ce projet est
d’instrumenter le tableau de bord du ministre, ceux de ses grands subordonnés, responsables
de programmes LOLF10, chefs d'état-major, et directeurs. L’armée de l’air souhaite décliner
cette démarche en son sein au travers du projet PITAGORE AIR. Le CSIA est directement
impliqué dans ce projet en tant qu’assistance à maîtrise d’ouvrage (AMOA). Il intervient de
selon deux axes :
 en expérimentant l’outil de business intelligence choisi dans le cadre de
PITAGORE (BOARD Management Intelligence Toolkit) pour instrumenter sa carte
stratégique.
 en intervenant auprès du Bureau Pilotage de l’Etat Major de l’armée de l’air (EMAA)
dans le cadre d’une mission d’aide à la décision.
Positionnement de la présente étude vis à vis de PITAGORE AIR :

En fait, l’armée de l’air ne dispose pas à ce jour d’entrepôt de données permettant de fusionner
les données provenant de ses systèmes informatiques. Cette absence de vision « infocentrée » entrave
le recueil de l’information et met donc en péril le déploiement d’un outil comme PITAGORE. Ensuite,
l’outil BOARD est principalement destiné aux décideurs de haut niveau, il ne couvre pas la totalité du
spectre fonctionnel de l’informatique décisionnelle, il convient donc de compléter la panoplie d’outils.
Ces carences sont mises en exergue dans le plan de maîtrise des risques projet qui a été établi par
la cellule AMOA du CSIA. Exemple de facteurs de risque recensés:
 analyse des données difficile à effectuer,
 données de mauvaise qualité,
 évolution du SI difficile,
 temps de réponse important,
 alimentation automatique difficile,
 pas de dictionnaire de données.
Ces facteurs de risque, non maîtrisés à ce jour vont d’une criticité mineure à catastrophique.
La mise en place d’un entrepôt de données (cf. §5) et d’outils de restitution adéquats permet de
placer un facteur de succès en face de chacun de ces facteurs de risque :
10
LOLF : Loi organique relative aux lois de finance
10/54
Facteurs de risque Facteur de succès
Mettre en place des outils d’analyse

multidimensionnelle venant compléter les
Analyse des données difficile à effectuer
fonctionnalités de BOARD.
Utiliser un ETL pour alimenter une unique source de

Données de mauvaise qualité données décisionnelles.
Mettre en place un data warehouse permet de créer

SI non interopérable le point d’intégration manquant (cf. §5.1.3)
Evolution du SI difficile
Modéliser l’entrepôt de données sous forme
dimensionnelle.
Temps de réponse important
Mettre en place une architecture décisionnelle avec

un unique entrepôt facilitera l’alimentation de
Alimentation automatique difficile
BOARD.
L’étude démontrera au chapitre 5.1.3 que la mise en

place d’une architecture en bus décisionnel passe
Pas de dictionnaire de données par l’établissement d’un référentiel de données
commun
L’élaboration d’un entrepôt de données, qui constitue le deuxième axe de cette étude, ne
vient pas concurrencer le projet PITAGORE AIR. Au contraire, l’analyse des risques projet
démontre que ce travail constitue un pré-requis indispensable à tout déploiement. De plus, un
entrepôt de données correctement structuré, complété par les outils de restitution ad hoc
permettra d’étendre les capacités d’analyse de PITAGORE pour couvrir la totalité du spectre
fonctionnel requis dans un système d’information de pilotage.
Conclusion : L’analyse du contexte permet d’une part, de réaffirmer l’opportunité de l’étude

et d’autre part d’identifier des contraintes, détaillées au chapitre 4.3, à prendre en compte
dans les solutions proposées.
11/54
4. Pérennisation de l’infocentre des bases aériennes

Après avoir analysé l’environnement applicatif de l’infocentre RH, l’étape suivante a consisté à
analyser l’outil en lui même et à proposer des solutions de pérennisations.
4.1 Analyse de l’existant
Figure 3: architecture logique actuelle des application SIGAPAIR V5, Infocentre et SIGAPAIR V6
Une analyse du besoin a dans un premier temps été effectuée sur deux sites:
 L’Ensemble équipe technique et instruction spécialisé des systèmes d’information ressources
humaines (EETIS SIRH) sur la base aérienne 102 de Dijon,
 Le bureau personnel militaire (BPM) de la base aérienne 217de Brétigny-sur-orge.
L’EETIS SIRH assure la maintenance de l’actuel infocentre et réalise les formations des secrétaires
à l’utilisation de cet outil.
L’infocentre fournit aux utilisateurs un ensemble de requêtes préétablies et paramétrables (490).
Après une analyse plus détaillée, il apparaît que ces requêtes permettent d’afficher des listes
d’administrés avec des informations textuelles extraites à l’état brut du système de production.
En outre, l’infocentre permet aux utilisateurs non informaticiens de créer leurs propres requêtes en
utilisant un requêteur graphique qui masque la complexité du langage SQL. Il s’avère que cette
fonctionnalité n’est utilisée que par quelques utilisateurs avertis, la plupart des requêtes étant établies
sur demande par l’EETIS SIRH.
12/54
Figure 4: Infocentre des bases aériennes - vue graphique du modèle de données pour le domaine mobilité.
L’interview d’utilisateurs sur la BA217 a permis de confirmer que BiQuery couvrait bien le besoin et
qu’il était indispensable de conserver un outil aussi souple, les demandes évoluant très fréquemment.
4.2 Différenciation des infocentres opérationnels et décisionnels
Le travail de documentation réalisé en parallèle de l’étude du besoin a permis de distinguer deux

types d’infocentre : l’infocentre opérationnel et l’infocentre décisionnel.
L’infocentre opérationnel s’appuie généralement sur la base de données de production ou sur une
copie de celle-ci, il permet de visualiser des données brutes. Ces données sont le plus souvent
textuelles et détaillées.
L’infocentre décisionnel permet de consulter des informations fiables à forte valeur ajoutée :
 les données sont contrôlées, normalisées et homogènes,
 les structures de données sont réorganisées pour s’adapter aux restitutions et
analyses,
 les données sont historisées et parfois agrégées.
Enfin, l’infocentre décisionnel offre, des fonctionnalités d’analyse évoluées.
La première catégorie d’infocentre peut conserver une conception isolée souvent très proche du
système transactionnel d’origine. En revanche, la deuxième catégorie devra respecter des normes de
conception spécifiques et communes à toute l’entreprise. Le processus de réalisation d’un
infocentre décisionnel est décrit dans le détail au chapitre 5 de cette étude.
13/54
Remarque : pour plus de clarté, dans la suite de l’étude les infocentres opérationnels seront
désignés sous le terme infocentre tandis que les infocentres décisionnels seront désignés sous le terme
data warehouse (entrepôt de données).
Infocentre Data warehouse

Sources multiples Non Oui
Analyse des besoins Faible Forte
Modèle de données Proche du système de opérationnel Intégré et orienté sujet
Objectifs Besoins d’analyses simples Besoins d’analyses avancées
Historisation Limitée à celle du système opérationnel Fort besoin d’historique
Données Données opérationnelles Données métier à usages multiples
Tableau 1: comparaison entre un infocentre et un data warehouse
A ce stade il apparaît que :

 l’infocentre actuel donne satisfaction,
 le caractère opérationnel de l’infocentre n’impose pas de réécrire l’outil pour l’intégrer à un
entrepôt de donnée décisionnel.
Une modernisation de l’existant doit donc être préférée à une réécriture.
4.3 Les contraintes
4.3.1 Contraintes calendaires
L’infocentre des bases aériennes doit être opérationnel au plus tard fin 2008, date à laquelle
SIGAPAIR V5 devrait être abandonné. Le développement devra donc être achevé à la fin du premier
semestre 2008.
4.3.2 Contraintes financières
Le projet SIGAPAIR V6, dans lequel s’inscrit l’infocentre, est une solution temporaire dans l’attente
de l’arrivée d’ORCHESTRA. Il convient donc de limiter au maximum les coûts engendrés notamment en
limitant l’achat de licences et la consommation d’ETP (Effectifs temps plein).
4.3.3 Contraintes techniques
L’intégration au réseau Intranet air :

L’armée de l’air est dotée d’un réseau privé s’appuyant sur les technologies internet. Pérenniser
l’infocentre implique de centraliser la base de données sur laquelle il va s’appuyer. En conséquence,
l’infocentre sera bien plus dépendant du réseau qu’il ne l’est actuellement et ce sur plusieurs aspects:
- les performances : les volumes de données échangés devront être minimisés,
- les règles de sécurité : la nature des flux échangés devra être conforme aux règles
définies sur l’intranet air,
14/54
- la disponibilité : toute indisponibilité du réseau entraînera de facto l’indisponibilité de

l’application.
L’architecture retenue devra prendre en compte ces contraintes.
La montée en charge :
L’architecture retenue devra permettre la connexion de 1500 utilisateurs. La charge prévue sera
nettement supérieure à la charge subie par les actuelles bases de données. En conséquence, pour
éviter de pénaliser la base de données de production de SIGAPAIR V6, une base de données
spécifique sera créée pour l’infocentre. Cette précaution est par ailleurs conforme aux préconisations
couramment rencontrées. En effet, même avec un faible nombre d’utilisateurs, si l’infocentre s’appuie
sur la BDD11 de production, une simple requête suffisamment complexe peut mettre à mal le serveur de
données et interrompre le service.
Enfin, si les performances ne sont pas conformes aux attentes, il sera possible de dupliquer le
serveur de données pour répartir la charge entre deux machines. Ceci est facilité par le fait que la base
de données infocentre n’est accessible qu’en lecture et qu’il n’y a pas, de ce fait, de problème de
synchronisation entre les serveurs.
4.3.4 Contraintes de sécurité
Confidentialité :
L’infocentre manipule des données de niveau confidentiel personnel ce qui implique de limiter
l’accès aux seules personnes autorisées. Les droits en consultation seront déterminés d’une part, par la
fonction occupée, par ex : analyste en administration central, secrétaire d’un bureau personnel militaire
ou secrétaire en secrétariat unité élémentaire (SUE) et d’autre part, par la localisation de l’utilisateur qui
donnera accès uniquement à la partie de la population qui est dans la gestion de l’utilisateur. Ainsi le
secrétaire travaillant en SUE ne doit pouvoir consulter que les informations des personnels de son unité.
Intégrité :
Toute modification inopinée des données contenues dans la base de données de l’infocentre est
jugée inacceptable compte tenu de la sensibilité de ces données. Même si l’infocentre en lui même ne
donne qu’un accès en lecture, le connecteur à la BDD pourrait être utilisée de manière détournée dans
le but de modifier les données. La solution retenue devra donc prévoir un dispositif de sécurité adéquat.
Disponibilité :
Il ne s’agit pas du critère de sécurité essentiel, l’application n’ayant pas d’impact sur l’activité
opérationnelle. Une interruption de fonctionnement de 24 heures peut donc être tolérée.
4.3.5 Facteur humain
Les acteurs de la chaîne RH doivent actuellement faire face à de nombreuses évolutions de leurs
outils informatiques avec notamment la montée en puissance de SIGAPAIR V6 et l’arrivée prochaine
d’ORCHESTRA. Il convient donc de prendre en compte cet état de fait et de ne pas perturber les
utilisateurs en produisant une solution la plus proche possible de l’existant.
11
BDD : base de données
15/54
4.4 Solutions architecturales proposées
4.4.1 Solution1 : maintien de l’application actuelle mais avec une unique base de
données nationale
Figure 5: architecture logique de la première solution
Description :
Cette solution consiste à conserver BiQuery dans sa version actuelle et à remplacer les bases de
données locales par une unique base de données nationale dédiée à l’infocentre. Cette base de
données sera de type SIGAPAIR V5 pour permettre de conserver en l’état les modèles BiQuery.
Charge de déploiement :
a) Paramétrage des postes clients

Le paramétrage des connecteurs NetUtil devra être effectué pour chaque poste client afin que
l’infocentre interroge la base de données nationale.
b) Gestion des profils utilisateur

Il est nécessaire de limiter les données visibles en fonction des droits utilisateurs.
Actuellement, il existe 4 profils :
- le profil administration centrale a accès à toutes les données du serveur national,
- le profil BPM-chancellerie a accès à toutes les données du serveur local,
- le profil BPM a accès à toutes les données du serveur local hormis les données de
chancellerie,
16/54
- le profil SUE (secrétariat unité élémentaire) n’a accès qu’aux données des personnels de
l’unité mais n’a pas accès aux données de chancellerie.
Le principe retenu pour gérer les droits est de créer des vues spécifiques en base de données
pour chaque compte de connexion. Chaque vue ayant le même nom que la table cible, il est alors
inutile de modifier le modèle BiQuery.
Un principe similaire sera retenu dans la solution 1. Les vues de chaque unité existant déjà, il
ne restera qu’à créer celles des BPM de chaque base.
c) Autorisation des flux sur le réseau

En outre, le déploiement d’une solution client serveur sur un réseau intranet implique l’ouverture
de ports spécifiques pour certaines adresses IP ce qui représente une charge en terme de
déploiement.
Charge liée à la sécurité :
Cette solution implique de faire transiter sur le réseau Intranet air un flux Ingres non sécurisé. Pour
palier ce problème, il est préconisé de mettre en place tunnel chiffré. Cette technique n’a pu être
expérimentée faute de temps dans le cadre de cette étude.
Charge d’exploitation :
Une base de données Ingres SIGAPAIR V5 sera conservée et une réplication unidirectionnelle
perdurera entre le système de production SIGAPAIR V6.
Avantages:
 Coût financier nul : l’armée de l’air possède une licence illimitée pour BiQuery,
 Coût humain faible,
 Transparence du changement pour l’utilisateur : L’environnement est conservé à l’identique. L’effort
nécessaire pour accompagner le changement est donc nul.
Inconvénients :
 Dépendance vis-à-vis de BiQuery et de Ingres maintenue,

 Solution non portable.
17/54
4.4.2 Solution 2 : montée en version de BiQuery pour permettre l’interrogation via

une interface web
Figure 6: architecture logique de la solution 2

Description :
L’infocentre utilise une version 5 de BiQuery qui ne permet pas l’interrogation via le web, cette
fonctionnalité est offerte par le module BiWeb disponible dans BiQuery 8. Cette solution permet à la fois
de conserver les modèles BiQuery et les requêtes existantes et de passer à une architecture web.
Charge liée à la migration : Test de non régression sous BiQuery 8 et éventuellement modification
de certaines requêtes qui ne seraient pas compatibles.
Charge de déploiement:
a) Paramétrage des postes client
Contrairement au client lourd aucune action n’est en principe nécessaire avec une solution web.
Ici, BiWeb utilisant des applet java, le poste client n’est pas complètement banalisé et il sera
nécessaire de veiller à l’installation d’une JVM12 microsoft.
b) Gestion des profils utilisateurs
Il est nécessaire de créer les différents comptes sur Bi Server.
Avantages :
 Déploiement facilité par le client léger
 Maintenance facilitée
 Utilisation d’un protocole réseau nativement sécurisé (HTTPS)
Inconvénient :
12
JVM : java virtual machine
18/54
 Coût des licences : Une licence pour 9 connexions simultanées coûte plus de 2000€ HT or ici il
faudrait plusieurs centaines de jetons pour assurer un niveau de service correct, le coût serait alors
inacceptable.
4.4.3 Solution 3 : récupération en l’état des requêtes Biquery et utilisation de briques

open source pour la présentation des données via une interface web
Description :
Cette solution consiste à s’affranchir complètement du logiciel BiQuery en utilisant des briques open
sources.
Pour le besoin type « requête presse bouton » :Le principe est de développer en java un programme
capable de prendre en entrée les requêtes provenant de BiQuery pour générer dynamiquement les
tableaux résultats en fonction de la requête. Il est possible de formater les rapports en utilisant l’API 13
open source Jasper Report ou en utilisant l’API FOP déjà intégrée au framework de l’armée de l’air. Il
sera aussi possible d’utiliser le framework open source POI pour l’export des résultats au format xls,
pdf, etc…
Pour les requêtes ad hoc : QBE (Query By Exemple) est un module open source intégré à SpagoBi, il
permet à l’utilisateur de créer ses propres requêtes en mode graphique. Les requêtes créées peuvent
13
API : Application programing interface
19/54
être enregistrées et mises à la disposition de la communauté. Le portail SpagoBi est accessible via le
web.
Avantages:
Le mode web offre les mêmes avantages que la solution 2, en outre il offre les avantages suivants :
Portabilité : L’utilisation de briques java open source permet de s’affranchir du système d’exploitation.
Gratuité : Le choix d’un développement en régie s’appuyant sur des briques gratuites permet d’éviter
l’achat de licences.
Inconvénients :
Coût humain: Contrairement aux deux premières solutions qui permettaient de récupérer en l’état les
modèles BiQuery, cette solution implique une charge en terme de développement.
Perte d’ergonomie : QBE n’est pas complètement équivalent à BiQuery en terme d’ergonomie. En effet,
il ne crée pas de jointures implicites entre les tables, et les champs affichés sont ceux de la base de
données ce qui ne correspond pas toujours au vocabulaire des utilisateurs. En d’autres termes, il n’offre
pas de gestion avancée des métadonnées, ce qui en fait plutôt un outil conçu pour les informaticiens.
Une solution pourrait consister à limiter l’accès à quelques experts qui seraient chargés de créer les
nouvelles requêtes à la demande.
20/54
4.4.4 Solution 4 : variante de la solution 3 avec transposition des requêtes BiQuery

pour la base de données SIGAPAIR V6
L’intérêt de cette dernière solution est de supprimer la base de données SIGAPAIR V5. La base de
données infocentre pourra être dénormalisée ou bien des vues spécifiques pourront être utilisées afin
de diminuer la complexité du modèle et d’améliorer les performances en lecture (cf §5.1.1). Un ETL
pourrait être utilisé pour le chargement.
Avantages :
Homogénéisation de la plateforme : En plus des avantages de la solution 3, cette version permettrait de
s’affranchir de SIGAPAIR V5 et de supprimer la réplication V5-V6.
Diminution de la complexité du modèle : Permis par la création de vues en base de données ou par la
dénormalisation des tables (cf. 5.1.1).
Inconvénients :
Coût humain: Cette solution impliquerait de réécrire complètement les requêtes puisque les structures
de données de SIGAPAIR V5 et V6 sont radicalement différentes.
21/54
4.4.5 Tableau récapitulatif des solutions proposées
Solution 1 Solution 2 Solution 3 Solution 4

Coût financier ++ -- + +
Coût humain + + - --
Performances - + + +
Conduite du changement ++ + - -
Pérennité /ouverture - - + ++
BILAN +2 0 +1 +1
En conclusion, compte tenu des contraintes listées supra, c’est la solution 1 qui est
retenue. Elle permet à moindre coût et en mobilisant un minimum de ressources de
maintenir le même niveau de service et ce de manière totalement transparente pour les
utilisateurs. La solution 2 est rejetée en raison de son coût. Enfin, les solutions 3 ou 4 sont
trop coûteuses en terme de ressources et risquent d’engendrer un rejet de la part des
utilisateurs, les outils libres n’offrant pas à ce jour exactement les mêmes fonctionnalités
que BiQuery.
22/54
5. Processus de développement du démonstrateur

décisionnel RH
Le deuxième axe de cette étude consiste à établir un socle méthodologique architectural et
technique pour le développement d’applications décisionnelles. Cette partie a tout d’abord nécessité un
travail de documentation important dont le résultat est synthétisé dans le chapitre 5.1. Le but de ce
chapitre est non seulement de clarifier les concepts manipulés dans la suite de l’étude mais aussi
d’expliciter certains choix architecturaux.
Le reste du chapitre 5 décrit concrètement le développement du démonstrateur décisionnel RH. Il
est à noter que ce travail a occupé la majeure partie du stage.
5.1 Rappel sur les principes de l’informatique décisionnelle
5.1.1 Généralités
L’informatique est aujourd’hui omniprésente dans l’entreprise et l’armée de l’air ne fait pas
exception en la matière. Une telle masse d’information traitée par des dizaines de systèmes
informatiques dits opérationnels laisse entrevoir des possibilités extrêmement intéressantes pour des
décideurs désirant avoir une vision précise, synthétique et actuelle de leur entreprise. Cependant, ces
applications opérationnelles ne permettent pas directement de répondre à cette attente.
Le premier problème est technique. Comment regrouper des informations provenant de systèmes
techniquement hétérogènes ?
Deuxième problème : lorsque l’on souhaite interroger en transverse plusieurs sources de données il
est difficile de s’assurer qu’une donnée a bien la même sémantique dans les différents systèmes
où elle est présente.
Ces deux premiers problèmes peuvent être qualifiés de problèmes d’interopérabilité. Le chapitre
5.1.4 démontre que le rôle d’une infrastructure de type ETL est de prendre à sa charge cette complexité
en réconciliant des données provenant de sources multiples.
Enfin, le dernier problème concerne l’organisation des données. Les modèles de données des
systèmes opérationnels ne sont pas conçus pour l’interrogation.
En effet, ces bases de données sont modélisées selon le principe entité relation, principe largement
éprouvé et formalisé dans la méthode Merise ou dans le diagramme des classes d’UML 14. Il consiste
à créer autant de tables qu’il y a de notions métiers importantes manipulées dans le SI. Les relations
sémantiques existant dans le monde réel entre ces entités sont transposées en relations dans les
modèles de données et donneront au final des tables de jointure et des clés étrangères en base de
données.
Ce type de modèle tend à supprimer toute redondance pour optimiser les performances en
modification, insertion et suppression. En effet, si une donnée n’est présente qu’à un seul endroit, le
système ne la manipule qu’une fois. Cela permet de plus, de conserver plus facilement l’intégrité de la
base de données.
Pour minimiser ces répétitions, les concepteurs doivent respecter autant que faire se peut les
principes de normalisation des bases de données relationnelles. Généralement, les bases de données
sont modélisées en troisième forme normale.
C'est-à-dire :
 tout attribut contient une valeur atomique
14
UML :Unified Modeling Language
23/54
 tout attribut n'appartenant pas à une clé ne dépend pas que d'une partie de cette clé,
 tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.
Ces modèles sont donc optimisés pour les applications transactionnelles, c‘est pourquoi ils sont
évoqués sous le terme OLTP pour Online Transaction Processing.
En revanche, ce principe n’est pas adapté aux applications décisionnelles. Tout d’abord, parce qu’il
induit une multiplication du nombre de tables, ce qui engendre une complexité difficile à appréhender
pour un utilisateur non informaticien, comme l’illustre le modèle de la figure 5. Or, dans les applications
décisionnelles les utilisateurs souhaitent interroger eux mêmes le modèle pour faire face aux nouveaux
besoins.
Figure 9: modèle de données SIGAPAIR pour le domaine chancellerie
Ensuite, s’ils sont optimisés pour la mise à jour, les modèles OLTP ne sont pas adaptés pour
l’interrogation. En effet, pour réaliser les requêtes complexes, il va falloir passer par plusieurs jointures
sur des tables contenant parfois plusieurs centaines de milliers d’enregistrements. De telles requêtes
engendrent des temps de réponse inacceptables pour les utilisateurs.
Il est donc impératif de développer des structures conçues spécifiquement pour le

besoin décisionnel, puisant les données de sources multiples et hétérogènes et présentant
ces données sous une forme propice à l’interrogation. Ces structures sont appelées
entrepôt de données ou data warehouse. L’entrepôt de données doit être modélisé sous
forme dimensionnelle.
24/54
5.1.2 Modélisation dimensionnelle
La modélisation dimensionnelle consiste à présenter les données sous la forme d’un cube
constitué :
 De N dimensions matérialisant les axes d’analyse possibles (exemple : le temps, les
produits en catalogue, les différents sites de vente)
 De données numériques appelées faits enregistrées à chaque croisement d’axe (exemple :
chiffre d’affaire par mois, par produit et par site)
temps
Chiffre d’affaire de juillet 2007

pour le produit x sur le site y
produits
zone
Figure 10: exemple de cube
Ainsi, il suffit pour l’utilisateur de naviguer dans le cube selon les différents axes pour effectuer son
analyse. Cette présentation de l’information est particulièrement intuitive puisque l’utilisateur manipule
au travers des dimensions et des faits des notions bien connues de son domaine métier. Le
tableau ci-dessous représente un exemple d’état que l’on pourrait réaliser à l’aide du cube de la figure
10.
localisation produit Chiffre d’affaire

Brétigny-sur-orge Pare-brise 2843.65 €
Brétigny-sur-orge Plaquettes de freins 5645.56 €
Evry Disques de freins 6432.21 €
Evry Pare-brise 3250.23 €
Evry Plaquettes de freins 8547.35 €
Un hypercube est implémenté à l’aide d’un modèle en étoile. Cette structure de données est
constituée de tables de dimensions qui forment les branches de l’étoile et au centre d’une table de
faits qui enregistre les évènements qui se produisent à l’intersection de chaque dimension. La table de
faits contient les clés des différentes dimensions ainsi que les valeurs qui correspondent aux indicateurs
que l’on souhaite suivre. La plupart des données de la table de faits sont donc numériques. Dans les
dimensions se retrouvent tous les attributs, le plus souvent textuels, utilisés pour qualifier les requêtes.
Ces attributs seront utilisés en tant qu’en-têtes de ligne dans les tableaux.
Ainsi, pour le cube de la figure 1, le modèle doit être constitué d’une table de faits qui enregistre
toutes les ventes effectuées avec comme valeur contenue le montant de la vente, il comprend aussi les
tables de dimension produit, zone et temps (cf. figure 11).
25/54
tem ps produi t
id_tem ps INT 4 <pk> i d_produi t INT 2 <pk>
jour INT 2 l ibel le VA RCHAR(255)
m oi s INT 2 fam i ll e_produi t VA RCHAR(255)
trim estre INT 2 type_condi ti onnem ent VA RCHAR(255)
annee INT 2
ventes
id_tem ps INT 4 <fk1>
id_zone INT 2 <fk2>
id_produit INT 2 <fk3>
m ontant INT 2
coût INT 2
zone
i d_zone INT 2 <pk>
vil le VA RCHAR(255)
departem ent VA RCHAR(255)
region VA RCHAR(255)
pays VA RCHAR(255)
Figure 11: Modèle en étoile correspondant au cube de la figure 1
Par opposition aux structures OLTP des applications à vocation transactionnelle, ces structures
analytiques sont appelées OLAP pour OnLine Analytical Processing.
Ce type de structure peut-être implémentée de deux manières :

 dans une base de données relationnelle classique, il faudra alors utiliser un moteur ROLAP
(Relationnel) pour créer les cubes,
 directement dans une base de données multidimensionnelle OLAP, c’est le concept
MOLAP (Multidimensionnel).
La première solution permet de conserver une structure relationnelle ce qui facilite le chargement de
gros volume de données. En revanche, les performances lors de l’interrogation sont moins bonnes
puisque le moteur ROLAP doit créer les agrégats en mémoire.
A l’inverse, les moteurs MOLAP stockent directement les données sous forme dimensionnelle et
calculent les agrégats au cours de l’alimentation ce qui alourdit le processus. En revanche les
performances à la consultation sont optimales puisque tout est calculé à l’avance.
Par ailleurs les solutions MOLAP sont aujourd’hui essentiellement commerciales.
Dans le cadre de cette étude c’est la solution ROLAP qui a été retenue. Ce choix est motivé
par les arguments suivants :
- le volume des données de SIGAPAIR fait craindre des temps de chargement important
- le démonstrateur doit être réalisé à l’aide de logiciels libres.
26/54
5.1.3 Data warehouse et datamarts
Les grands concepts de l’informatique décisionnelle ont été formalisés par deux théoriciens
américains, Bill Immon et Ralph Kimball. Ils présentent deux visions sensiblement différentes du data
warehouse.
Pour Bill Immon, le data warehouse a une existence physique (cf. figure 12). Il est matérialisé par
une base de données le plus souvent relationnelle et a pour but de réconcilier différentes sources de
données. Il rassemble des informations intéressantes d’un point de vue décisionnel provenant de divers
domaines métier de l’entreprise. En aval de ce data warehouse, se trouvent des datamarts (magasins
de données) qui contrairement au data warehouse sont orientés sujet et répondent à la problématique
particulière d’une entité de l’entreprise. Ces datamarts sont le plus souvent modélisés sous forme
dimensionnelle.
Portail de restitution
ETL ETL
Figure 12: Architecture décisionnelle préconisée par Bill Immon
Pour Ralph Kimball, le data warehouse est constitué de l’agrégation des différents datamarts (cf.
figure 13). Les datamarts sont les subdivisions logiques du datawarehouse. Kimball met en avant le
développement itératif et incrémental du data warehouse, chaque itération devant correspondre au
traitement d’un sujet particulier et donc à la création d’un nouveau datamart.
27/54
ETL Portail de
restitution
Figure 13: Architecture décisionnelle vue par Ralph Kimball
Ce datamart nécessairement modélisé sous forme dimensionnelle devra utiliser des dimensions et
des faits que l’on qualifiera de conformes, c'est-à-dire que les dimensions et faits utilisés seront
conformes à une définition communément admise au sein de l’entreprise. Cette définition comprend :
 la sémantique,
 la structure (libellé et type des attributs),
 la granularité (ex : pour la table de faits vente chaque transaction unitaire réalisée).
L’utilisation de dimensions et de faits conformes garantit la bonne intégration des différents
datamarts à l’architecture décisionnelle et assure par là même, de pouvoir requêter en transverse sur
différents domaines métier. On parle alors d’architecture en bus décisionnel (cf. figure 14). Le non
respect de cette préconisation engendre l’apparition de datamarts dits en « tuyau de poêle » isolés les
uns des autres.
Bus du data
warehouse Commandes
Faits conformes
Production
Dimensions Centre de Produit Client Temps

conformes distributions
Usine Promotion Commercial
Figure 14: architecture en bus décisionnelle telle qu'elle est préconisée par Ralph Kimball
28/54
Le point de vue de Ralph Kimball est ici retenu car a l’avantage de privilégier une démarche
incrémentale et modulaire plutôt qu’une démarche monolithique. En effet, le risque en
voulant concevoir directement un data warehouse comprenant toutes les données de
l’entreprise, est de ne jamais voir aboutir un résultat intéressant pour l’utilisateur dans des
délais raisonnables et de compromettre ainsi le projet.
5.1.4 L’ETL (Extract Tranform and Load) - composant essentiel de l’architecture

décisionnelle
La mise au point du processus d’alimentation est la tâche la plus critique du cycle de vie d’un data
warehouse, c’est aussi la plus laborieuse puisque 60% de la durée du développement seront consacrés
à cette tâche. L’alimentation se déroule en trois étapes :
- l’extraction des données depuis les systèmes sources,
- la transformation des données,
- le chargement dans l’entrepôt de données.
Extraction :
Dans un premier temps, les données sont extraites de différents systèmes sources. Il est en effet
rare d’alimenter un data warehouse à partir d’un unique système opérationnel. L’ETL doit permettre
d’interconnecter un environnement technique hétérogène constitué de bases de données mais aussi de
fichiers voire de PGI.
Transformation :
Une fois que les données sont extraites, elles subissent une série de traitements de manière à les
rendre présentables pour les utilisateurs et dignes d’intérêt pour l’entreprise. Parmi ces transformations
on trouve :
- le mapping (pour adapter les données à la structure cible)
- le calcul (pour mettre en œuvre les règles de gestion identifiées)
- la création d’agrégats (parfois nécessaire pour améliorer les performances)
- la vérification du contenu des données (pour améliorer leur qualité),
- la dénormalisation et la renormalisation,
- la conversion des types de données,
- la gestion des clés de substitutions utilisées dans les tables de l’entrepôt.
Chargement :
Tout comme pour l’extraction, les services de chargement doivent être compatibles avec divers
environnements cibles. Le chargement doit optimiser les performances pour permettre le respect de la
fenêtre de mise à jour nocturne du data warehouse. Enfin, il doit être possible de jouer un chargement
complet depuis la création des tables, le peuplement jusqu’à l’indexation.
Contrôle des tâches de préparation de données :

Durant tout le processus d’alimentation, le programme utilisé devra assurer les services suivants :
- la définition des tâches et l’ordonnancement,
- la planification des tâches,
- la surveillance /journalisation,
- la gestion des exceptions (permet de traiter les rejets),
- la gestion des erreurs / notifications.
29/54
Rien n’oblige d’utiliser un ETL pour réaliser l’alimentation, il est tout à fait possible de développer
des scripts dans un langage de programmation adapté. Cependant, l’ETL offre une infrastructure prête
à l’emploi avec des bibliothèques de composants riches, fiables et performants. En outre, les interfaces
graphiques mises à disposition améliorent grandement la prise en main, la productivité et la
maintenabilité. Le seul argument favorable au développement de scripts spécifiques est en fait la
souplesse de cette solution. Cependant, certains ETL comme Talend qui a été utilisé dans cette étude,
laissent la possibilité de développer des jobs qui s’appuient sur du code spécifique externe à l’outil, ce
qui lève cette limitation.
En conséquence, l’alimentation d’un entrepôt de données décisionnel doit être effectuée à

l’aide d’un ETL.
5.1.5 Les différents niveaux d’utilisation
Les applications décisionnelles sont destinées à plusieurs types d’utilisateurs ayant chacun un
besoin de restitutions spécifiques. Le diagramme de cas d’utilisation de la figure 15 décrit ces différents
types de besoin.
Figure 15: Diagramme de cas d'utilisation illustrant les différents profils d'utilisation des outils décisionnels
Décideur :
Les décideurs souhaitent visualiser rapidement l’évolution des indicateurs permettant de mesurer la
performance de l’entreprise.
Exigences particulières :
 accès rapide à l’information,
 transversalité de l’information,
 fiabilité de l’information.
30/54
Analyste :
Les analystes sont les principaux clients de l’informatique décisionnelle. Ils cherchent à expliquer
l’évolution des indicateurs. Ils ont donc besoin de naviguer dans les données selon différentes
dimensions avec des niveaux de détails variés. Ils peuvent aussi être amenés à simuler l’évolution des
données en fonction de divers scénarios.
 historique des données important,
 ergonomie et puissance des outils de navigation multidimensionnelle,
 fiabilité de l’information,
 performances,
 puissance des outils mathématiques de simulation.
Opérationnel :
Les opérationnels ont des besoins d’interrogation variés utilisés pour le pilotage tactique au
quotidien. Le niveau de détail des données dont ils ont besoin est maximal.
 actualité des données,
 performance,
 historique limité,
 interface simple.
Ces besoins bien distincts sont satisfaits par différents modes de restitutions :
Reporting :
Consiste à générer des tableaux statiques dont le format est prédéfini. Tout au plus, l’utilisateur
pourra à la génération du document renseigner certains paramètres comme une date ou une
localisation géographique. Les rapports sont conçus pour être mis à disposition de tout type
d’utilisateurs, aucune compétence nécessaire n’étant requise pour leur utilisation. Il y a deux manières
de mettre à disposition ces rapports. Soit ils sont générés et diffusés automatiquement, par exemple par
messagerie électronique (mode push), soit c’est l’utilisateur qui fait la démarche de télécharger les
rapports en passant par le portail décisionnel quand il le souhaite (mode pull).
Requêteur ad hoc :
Permet aux utilisateurs de réaliser leurs propres requêtes en s’appuyant sur une abstraction le plus
souvent graphique de la base de données. Ce type d’outil est destiné plutôt aux analystes et aux
opérationnels car il nécessite une prise en main plus poussée et une connaissance du modèle de
données. Les modules de requêtage permettent d’extraire le résultat dans divers formats bureautiques
pour une exploitation ultérieure.
Analyse multidimensionnelle :
Les navigateurs multidimensionnels permettent de manipuler des tableaux dynamiques. Ces
tableaux ont une forme et un niveau de détail défini initialement mais contrairement au reporting,
l’utilisateur peut analyser plus finement les données en naviguant dans le cube (cf. figure 6):
 en modifiant par exemple le niveau de granularité (drill down / drill up),
 en modifiant les axes d’analyse (drill across),
 en consultant la transaction ou les transactions à l’origine de la valeur de l’indicateur (drill
through).
Ce mode de restitution est principalement destiné aux analystes.
Datamining :
Permet de faire une analyse encore plus poussée des données en s’appuyant sur des outils
mathématiques (statistiques, probabilités, règles de classification, auto-apprentissage). Deux modes
d’utilisation différents peuvent être distingués :
31/54
 l’analyse descriptive : permet de mettre en évidence des corrélations entre les données qui au
départ n’ont aucun lien entre elles. Exemple : lorsque un produit X est présent sur un ticket de
caisse le client est 9 fois sur 10 un homme.
 L’analyse prédictive : permet en fonction des éléments recueillis dans le passé au moyen de
l’analyse descriptive de simuler l’évolution des indicateurs en fonction de scénarios donnés.
Ce type d’outil est réservé à un public très ciblé.
Reporting Requêteur Analyse Datamining

multidimentionnelle
Décideur
oui non non non
Analyste
oui oui oui oui
Opérationnel
oui oui (*) oui (*) non
(*) Remarque : attention, ces modes de restitutions peuvent s’avérer complexes. Il est donc préférable
soit de limiter leur utilisation à quelques personnes bien formés soit de brider suffisamment ces
modules pour faciliter leur utilisation.
Ce chapitre a permis d’une part, de définir les différents concepts manipulés dans la suite
de l’étude et d’autre part d’exposer certains choix architecturaux:
 le data warehouse sera modélisé sous forme dimensionnelle,
 il sera constitué d’une constellation de datamart utilisant des dimensions et des faits
conformes,
 l’alimentation se fera à l’aide d’un ETL.
32/54
5.2 Périmètre retenu
Le chapitre 4 a permis notamment de souligner le caractère opérationnel de l’infocentre des bases

aériennes. Pour illustrer de manière concrète le processus de développement d’un data warehouse,
deux sujets présentant un intérêt crucial pour l’armée de l’air ont donc été retenus:
 la balance des droits et existants,
 la capacité de projection des personnels en opération.
Ces deux sujets sont issus du tableau de bord DRHAA des base aériennes. Ce besoin a été exprimé
récemment par la maîtrise d’ouvrage à l’aide d’une maquette statique.
5.2.1 Balance des droits et existants
L’armée de l’air possède un référentiel d’organisation (RO) définissant la répartition quantitative et

qualitative des personnels dans les unités. Le RO contient tous les postes des unités de l’armée de l’air
et définit combien de personnes doivent occuper ces postes pour que la mission soit accomplie
correctement. Le référentiel précise quels sont les grades, spécialités et qualifications nécessaires pour
tenir les postes. Par exemple, le chef du CSIA doit être d’après le RO un Colonel de la spécialité
informatique. On parlera de droits en personnels.
Par ailleurs, l’armée de l’air recense ses existants en personnels. De la même manière que pour
les droits, il est essentiel de connaître à chaque instant les effectifs en activité et de connaître leur
répartition, notamment, en terme de grade et de spécialité.
Une problématique récurrente pour les gestionnaires de ressources humaines est de faire la
balance entre les droits et les existants. Un exemple de cas d’utilisation de cette balance droits/existant
est celui d’un bureau mouvement d’un bureau personnel militaire (BPM) sur une base aérienne :
Lorsque un sous-officier est affecté sur une base, il n’est pas toujours posté dans une unité, c’est alors
au BPM que revient le choix de l’unité qui accueillera ce personnel. Les gestionnaires RH doivent savoir
quelle est l’unité qui a le plus besoin d’un personnel correspondant au grade et à la spécialité de
l’intéressé.
Ce cas d’utilisation de niveau opérationnel constitue un exemple de niveau tactique. A plus haut
niveau, l’administration centrale a elle aussi besoin en permanence d’un outil similaire mais à la
granularité différente pour gérer les mutations mais aussi pour piloter la masse salariale. Il s’agit donc
d’un sujet critique à divers niveaux de responsabilité et dans différents domaines métiers dans l’armée
de l’air.
Le choix d’un sujet critique est important pour réaliser un démonstrateur convaincant mais ce n’est
pas le seul critère à rechercher. En effet, le sujet choisi doit permettre d’aborder l’ensemble des
problématiques techniques liées au data warehouse.
Parmi ces problématiques :

 La volumétrie des données. Avec 65000 administrés d’active à suivre ce sujet permettra
d’appréhender cette problématique.
 L’alimentation multi sources. Les données devront être collectées depuis deux systèmes ressources
humaines.
 Les modes de restitution : reporting statique ou tableaux d’analyse multidimensionnelle
 La hiérarchisation des dimensions d’analyse : besoin de hiérarchisation des grades en catégories et
sous-catégories puis de la localisation sous la forme base aérienne/unité/poste.
 L’historisation : Un historique des données de deux ans devra être récupéré.
5.2.2 Capacité de projection des personnels en opération
L’une des missions prioritaires de l’armée de l’air est de réaliser des opérations sur théâtres
extérieur (OPEX) ou intérieur (MISSINT). Pour ce faire, elle doit veiller en permanence au maintien en
33/54
condition opérationnelle de son personnel. Tout personnel servant en opération extérieure doit répondre
à certains critères d’aptitude. Par exemple : aptitude médicale, aptitude sportive, aptitude au tir, etc…
Le but de ce datamart sera donc le suivi des aptitudes des militaires. Tout comme la balance droits
existants, cette base de données pourra être utilisée avec différents modes de présentation selon le
niveau de responsabilité des utilisateurs.
L’intérêt de réaliser un second datamart est d’une part, de valider le savoir faire acquis lors du
premier sujet et d’autre part, d’introduire une itération dans le processus de développement
incrémentale de la constellation de datamarts. En effet, l’autre intérêt de ce sujet est qu’il nécessite les
mêmes dimensions d’analyse que le datamart balance droit / existant c’est à dire les grades et
spécialités des administrés. La construction du bus décisionnel préconisé par Ralph Kimball est ainsi
entamée (cf. figure 14 - §5.1.3).
5.3 Architecture logique
Figure 16: architecture logique de la plateforme décisionnelle
L’architecture proposée est un architecture décisionnelle classique avec les deux systèmes de
production sources SIGAPAIR et BRH qui alimentent via un ETL15 d’une part, la base de données
analytique du DATAMART RH et d’autre part, la base de données infocentre qui est une copie
éventuellement dénormalisée de la base de données SIGAPAIR de production. Un conteneur de servlet
Tomcat sera chargé d’héberger le module décisionnel.
Pour le module décisionnel, deux solutions sont possibles : soit une intégration totale à SIGAPAIR
V6 au niveau applicatif, soit l’utilisation d’un portail décisionnel externe. Dans tous les cas l’application
sera accessible via un navigateur.
15
ETL : Extract Transform and Load
34/54
5.4 Modélisation dimensionnelle

Le cas concret du datamart droits / existants sera utilisé pour illustrer la processus de modélisation
dimensionnelle. Il n’y a pas pour la conception d’un data warehouse de méthodes très formalisées
comme cela peut être le cas pour les applications transactionnelles avec Merise ou RUP mais plutôt des
bonnes pratiques communément admises par les experts du domaine. Le choix a ici été fait de
s’inspirer des préconisations de Ralph Kimball définies dans son ouvrage de référence : « Le Data
warehouse – guide de conduite de projet ».
Kimball préconise une conception des modèles dimensionnels en 4 étapes :

 choisir les datamarts,
 déclarer la granularité de la table de faits,
 définir les dimensions,
 définir les faits à mesurer.
5.4.1 Choisir les datamarts
Deux datamarts ont été identifiés :

 la balance droits /existants
 la projetabilité
Sources de données :
Pour la balance droits/existants, la source de données est essentiellement SIGAPAIR dans sa
version 6. En effet, SIGAPAIR V5 n’est pas pérenne et l’entrepôt de données devra perdurer après la
disparition de V5.
En ce qui concerne les existants, aucune ambiguïté dans le choix n’est possible vu que SIGAPAIR
est officiellement le système référent.
Par contre, pour les droits, le choix était moins évident. En effet, le référentiel d’organisation de
l’armée de l’air est géré par l’application BRH (Bureau des ressources humaines) et une interface entre
les deux applications permet à SIGAPAIR de récupérer les tables des postes, unités et tableau
d’effectifs. BRH pourrait être considéré comme la référence des droits mais sa base de données
s’avère être une base de travail en perpétuel chantier qui de plus, ne gère pas d’historique. SIGAPAIR
quant à lui, reçoit périodiquement les versions validées du référentiel d’organisation et tient un
historique à son niveau de ces différentes versions. SIGAPAIR V6 sera donc la source retenue pour la
partie droit hormis pour la donnée BOP16 qui sera récupérée de BRH.
Pour la projetabilité la source de données sera SIGAPAIR V6.
5.4.2 Déclarer la granularité de la table de faits
Cette étape est essentielle dans la conception de l’entrepôt de données. Sans avoir clairement
défini le niveau de détail de la table de faits il est inutile d’aller plus loin dans la conception au risque
d’avoir à tout refaire lorsque les utilisateurs découvriront le produit final. Le but est de spécifier ce que
représentera un enregistrement de la table de faits.
Lors du travail de modélisation de la balance droits/existants deux solutions sont apparues :
Solution 1:
Table de faits « balance/droits existants » : permet de connaître à l’instant t pour chaque unité les
effectifs réels (existants) et les effectifs théoriques (droits) calculés par grade et spécialité.
Solution 2:
Ici deux tables de faits seront nécessaires.
Table de faits « existants » : Recense l’ensemble des événements de carrière d’un administré tels que :
 les affectations,
 les promotions,
16
BOP : Budget Opérationnel de Programme ( une unité est liée à un BOP)
35/54
 les spécialisations.
Table de faits « organisation » : Contient les versions successives du référentiel d’organisation en
définissant pour chaque poste les droits pour un grade et une spécialité donnés.
Avantages et inconvénients des deux solutions exposées :
La première solution présente l’avantage d’offrir une vue des données déjà agrégée, les
performances attendues sont donc excellentes mais c’est là le seul avantage de cette solution.
En effet, il est préconisé lorsque cela est possible de conserver le niveau de détail le plus atomique
possible. C’est le principe qui a été retenu dans la deuxième solution en choisissant comme niveau de
granularité la transaction à l’origine de l’événement.
Avantages de cette solution :
 l’utilisateur bénéficie d’emblée d’un meilleur niveau de détail :

Cela permettra de ne pas limiter l’utilisation de l’entrepôt au seul besoin des BPM. Il sera
notamment possible de savoir qui sont les individus affectés sur les postes.
 meilleure évolutivité du modèle :

Avec une vue prématurément agrégée, si l’utilisateur souhaite ajouter une dimension qui n’a pas un
niveau de granularité concordant avec celui de la table de faits il est nécessaire de développer un
nouveau datamart. Par exemple, l’ajout à la solution 1 de la dimension poste, qui est un niveau plus
précis que l’unité, impliquerait de développer un nouveau datamart. La solution 2 permet de se
prémunir de telles modifications puisqu’elle prévoit déjà le niveau de détail le plus bas.
 L’alimentation est facilitée:

Pour la solution 1 l’alimentation consiste à prendre une photo de la situation tous les jours, ce qui
correspond à l’insertion de dizaines de milliers d’enregistrements.
Pour la solution 2 il suffit de récupérer chaque jour les événements qui se sont produits depuis la
veille, ce qui correspond au maximum à quelques centaines d’enregistrements.
En outre, conformément à la solution 2, la balance droits/existants implique de créer deux tables de

faits distinctes. En effet, même si le niveau de granularité est le même, la partie droit n’est pas liée à la
dimension administré. De plus, le référentiel d’organisation n’évolue que 2 ou 3 fois par an alors que la
situation des existants évolue quotidiennement.
Le diagramme de la table des faits présenté ci-dessous nomme la table des faits, définit clairement
sa granularité ainsi que les dimensions auxquelles elle est liée.
Date de
l’événemen
t Table des faits
Existants Grade
Granularité :
Administré
Recense l’ensemble des
évènements de carrière
d’un administré tels que :
les affectations
Spécialité
les promotions
Poste
les spécialisations.
Figure 17: Diagramme de la table des faits Existants
36/54
5.4.3 Choix des dimensions
Les dimensions d’analyse sont déterminées à l’aide des maquettes de rapports fournies par la
maîtrise d’ouvrage. Les attributs des différentes dimensions sont en général en en-tête de ligne des
tableaux. La granularité découle de celle qui a été définie pour la table de faits.
Certaines dimensions sont communes aux deux modèles en étoile :
 la dimension temps,
 la dimension spécialité,
 la dimension grade,
 la dimension poste.
Il est essentiel que les deux tables de faits s’appuient sur des dimensions conformes pour permettre
le rapprochement des droits et des existants. Il s’agit donc ici d’un premier pas dans la conception du
bus décisionnel (cf. figure 14 § 5.1.3).
Attention : Les notions métiers présentes dans les dimensions doivent avoir la même sémantique.
Remarque : A ce sujet, il a longtemps été difficile d’effectuer une balance droits / existants étant donnée
les différences de sémantique entre les deux applications sources. En effet, le référentiel d’organisation
s’appuyait sur un champ appelé grade mais qui combinait en fait, les notions de grade et de
qualification, ce qui rendait difficile tout rapprochement avec SIGAPAIR, qui distinguait bien les deux
notions. C’est la convergence entre les grades militaires et les « grades-qualifications » de BRH, voulue
par la maîtrise d’ouvrage qui permet aujourd’hui de rapprocher précisément les droits des existants.
Ceci illustre bien que la construction du bus décisionnel, qui s’appuie sur la définition de faits et
de dimensions conformes, n’est possible qu’avec une volonté de conciliation de la part de la
maîtrise d’ouvrage. La problématique n’est donc pas seulement technique.
Granularité et hiérarchie des dimensions :
 Dimension temps :
o Granularité : la journée
o Hiérarchie : année civile, mois, jour
 Dimension grade :
o Granularité : sans objet
o Hiérarchie : catégorie1 (militaire, civil), catégorie2 (OFF,SOFF, MDR), catégorie
3(OFF SUP, OFF SUB ,SOFF SUP…)
 Dimension localisation ou poste :
o Granularité : le poste
o Hiérarchies :
- d’une part base aérienne, unité, poste
- d’autre part bop, unité, poste
 Dimension spécialité :
o Hiérarchie : l’introduction d’une hiérarchie par corps est envisagée
 Dimension administré :
o Hiérarchie : aucune
Le diagramme de la figure 18 formalise la définition des dimensions en regroupant la granularité, les

attributs, les éventuelles hiérarchies et entre parenthèses la cardinalité prévue.
37/54
Base
(46) aérienne
BOP (17)
(1045) Unité
Cellule (11300)
(40 000) Poste
Figure 18: Diagramme des dimensions
Gestion des dimensions changeantes :
On appelle dimensions changeantes les dimensions dont les descriptions évoluent. Par exemple, un
administré peut changer d’adresse ou de nom plusieurs fois durant sa carrière.
Kimball propose 3 stratégies pour gérer les dimensions changeantes :
La réponse de type 1 consiste à écraser l’ancienne valeur. Cette technique est utilisée lorsque
l’ancienne valeur n’a plus d’importance, c’est le cas par exemple d’une correction d’erreur.
La réponse de type 2 consiste à créer autant d’enregistrements dans la table qu’il y a de versions.
Ainsi chaque enregistrement correspondra à une description de l’entité dimensionnelle valable pour une
période donnée. La clé sous-jacente de cette table est constituée de l’identifiant métier du système
source suivi de la date de début.
Cette solution implique :
 d’utiliser une clé de substitution propre au datamart,
 de créer des champs date de début et date de fin définissant la période de validité de
l’enregistrement.
Dans l’exemple de l’administré, à chaque fois que l’un de ses attributs changerait de valeur un
nouvel enregistrement serait créé avec le même identifiant métier mais avec une nouvelle clé de
substitution.
La réponse de type 3 consiste à créer un champ « ancien » pour conserver l’ancienne valeur du
champ. Cette solution peut être utilisée pour les changements légers et occasionnels. En effet, si deux
changements sont effectués consécutivement l’historique de la première valeur est perdu.
Stratégies choisies pour le datamart droits / existants :
Pour l’administré, si les informations grade et spécialité avaient été incluses dans la dimension
administré, il aurait fallu obligatoirement utiliser la solution de type 2, il est en effet impératif de connaître
l’évolution dans le temps des caractéristiques de l’administré. Cependant, garder des tables de
dimension indépendantes permet d’améliorer les capacités d’analyse tout en conservant les mêmes
performances (Il ne faut pas oublier qu’administré contient 65000 enregistrements). Grade et spécialité
seront donc des dimensions à part entière. Les promotions, les changements de spécialités et les
changements d’affectation seront enregistrés dans la table de faits existant. Pour les autres attributs de
l’administré, le choix qui a été fait est la stratégie de type 1. Si un besoin d’analyse demandant de suivre
l’évolution de ces attributs apparaît, un nouveau type d’événement sera enregistré dans la table des
38/54
existants. Même raisonnement pour la dimension poste avec la table de faits organisation. Pour les
dimensions grade et spécialité c’est aussi la stratégie de type 1 qui a été retenue.
5.4.4 Définition des faits à mesurer
Pour la table des droits, le fait mesuré est le nombre d’effectifs temps plein (etp) affecté à un poste
pour un grade, une spécialité et une date donnés par le référentiel d’organisation. La règle d’agrégation
pour ce fait est la somme.
Pour la table des existants, il s’agit d’un cas particulier puisqu’il n’y a pas de faits numériques.
L’effectif existant qui est la valeur recherchée, sera calculé en comptant le nombre d’occurrences au
croisement des dimensions.
5.4.5 Modèles physiques de données
Le déroulement des quatre étapes de la conception logique permet de passer à une conception
physique. Comme tout travail de conception, il est itératif et incrémental. De ce fait, le modèle présenté
figure 13 est déjà considérablement enrichi par rapport à ce qui a été défini plus haut. Ce sont les
travaux d’alimentation, d’optimisation puis les recettes utilisateurs qui viendront modifier la structure de
données. En revanche, la granularité est censée ne pas bouger, elle constitue le socle du modèle en
étoile.
d im _adm ini stre

i d_adm ini stre INT 4 <pk>
ni a VARCHAR(10)
ni d VARCHAR(10)
nom _usage VARCHAR(255)
nom _fam i l le VARCHAR(255)
prenom VARCHAR(255)
date_nai ssance ti m estam p
code _insee VARCHAR(12) di m _grade
sexe VARCHAR(20)
i d_grade INT 2 <pk>
cl e_ni a CHAR
di m _ speci al ite l i b_court VARCHAR(10)
i d_source INT 8
id_speci ali te INT 2 <pk> l i b_long VARCHAR(255)
li b_court VA RCHAR(10) ca tegorie VARCHAR(50)
li b_l ong VA RCHAR(100) o rdre_hi erarchiq ue INT 2
id_source INT 8 ca tegorie 1 VARCHAR(20)
ca tegorie 2 VARCHAR(20)
ca tegorie 3 VARCHAR(20)
i d_source INT 8
ft_existant
id_tem ps INT 4 <pk,fk4>
id_po ste INT 2 <pk,fk3>
id_grade INT 2 <pk,fk1>
id_speci ali te INT 2 <pk,fk5>
id_ad m i nistre INT 4 <pk,fk2>
id_source_evenem ent INT 8
type_e ve nem en t CHAR
si tu_ courante BOO L
ft_m aj_o rgani sati on

i d_tem p s INT 4 <pk,fk1>
i d_poste INT 2 <pk,fk2>
i d_grade INT 2 <pk,fk3>
i d_speci ali te INT 2 <pk,fk4>
d roi t_etp INT 2
n um _te INT 2
o rga_cou rante BO O L
d im _poste
id_poste INT 2 <pk>
date_d ebut T IM EST AM P
date_fi n T IM EST AM P
li b_court_cel lul e VA RCHAR(255)
li b_lon g_cell ul e VA RCHAR(255)
dim _tem p s li b_court_uni te VA RCHAR(50)
i d_tem ps INT 4 <pk> li b_lon g_unite VA RCHAR(255)
j our INT 2 code_uni te VA RCHAR(10)
m ois INT 2 li b_court_base VA RCHAR(50)
annee INT 2 li b_lon g_base VA RCHAR(100)
bop VA RCHAR(10)
id_source_poste INT 8
id_source_uni te INT 8
Figure 19: Modèle physique de données du datamart droits/existants
39/54
5.4.6 Estimation de la volumétrie
Les modèles en étoiles ont le défaut d’introduire de la redondance dans les données c’est pourquoi
le volume des bases de données est extrêmement important par rapport aux systèmes de production.
Il est donc primordial de se soucier le plus tôt possible des problèmes de volumétrie.
Une première évaluation a consisté à évaluer la cardinalité de chaque dimension, il en ressort

l’ordre de grandeur suivant :
Poste : 40 000 enregistrements
Administré : 65 000 enregistrements
Grade : 200 enregistrements
Spécialité : 500
Temps : 1825
Le volume de données brut estimé de chaque dimension est:
Vposte= 40000 x 170= 13 600 000 o soit 13 Mo

Vadministre= 65000 x120= 7 800 000 o soit 5 Mo
Vgrade= 200 x 70= 14 000 o soit 14 Ko
Vspecialite= 500 x 65= 32500 soit 32 Ko
Vtemps= 1825 x 10= 18250 soit 18 Ko
Soit un total pour les dimension Vdim= 20.5 Mo
Puis il est nécessaire d’estimer le volume initial de la table de faits. Pour ce qui est de la table des
existants, initialement elle doit contenir toutes les affectations en cours. Elle comprendra donc un
enregistrement par administré d’active soit 65000 enregistrements.
La croissance annuelle est estimée à 35 000 mutations, 15 000 promotions et 20 000

spécialisations soit 70 000 enregistrements supplémentaires par an.
Si un historique de 5 ans est conservé pour les données atomiques, en régime de croisière, la table
de fait existant comprendra 65 000+ 4 x 70 000 = 345 000 enregistrements.
D’où Vexistant= 345 000 x 24= 8 280 000 o = 8Mo
Le même raisonnement pour la tables de faits organisation amène au résultat suivant :

Vorganisation= 45500 x 13= 580Ko
Donc le volume de données brut attendu pour le datamart est de 30 Mo environ. En prenant en
compte le volume pris par les indexes, l’espace de travail et de tri, et d’éventuelles tables d’agrégat, le
volume final nécessaire sur le disque est estimé à 100Mo. Ce volume est largement en deçà des
capacités actuelles. Aucun problème lié à la volumétrie n’est donc à prévoir avec ce datamart.
40/54
5.5 Processus d’alimentation ETL
5.5.1 Choix de l’ETL
Comme il l’a été démontré dans le chapitre 5.1.4, l’utilisation d’un ETL devient rapidement
incontournable dans un projet de data warehouse. Pour cette étude le choix a été de privilégier la
recherche d’outils open source. Deux de ces outils ont été testés : Kettle et Talend.
Kettle est déjà utilisé au CSIA pour mettre à jour les tables de référence de SIGAPAIR V6 à partir de
SIGAPAIR V5. Un premier test d’alimentation du datamart droits / existants a été fait. Kettle s’est avéré
assez simple d’utilisation et particulièrement riche en terme de composants. Cependant, la possibilité de
recourir à du code spécifique par le biais de code javascript s’est avérée assez limitée.
Figure 20: job Kettle permettant l'alimentation d'une table de fait
Sur le conseil de CARRA consulting Talend Open Studio a été utilisé pour le reste du stage. C’est
l’ouverture de l’outil, sa souplesse et ses performances comparables aux ETL commerciaux qui ont
conduit à faire ce choix. Talend Open studio est une plateforme ETL s’appuyant sur Eclipse. Il génère
au choix du code java ou perl. Il est doté d’une panoplie de composants très riches. En revanche, il est
dépourvu à ce jours de composant dédiés au data warehouse. Enfin, Talend est particulièrement ouvert
puisqu’il expose des web-services et permet d’introduire des portions de code spécifique. (Par
exemple : pour effectuer des traitements sur les dates, une classe java DateUtil possédant des méthode
de transformation dateToInt(), year(), month() et day() a été créé. Cette classe peut être appelée dans
tous les jobs du projet)
41/54
Figure 21: job Talend permettant l'alimentation d'une table de fait
Pour ces deux solutions l’absence de connecteur SAP s’avère être un handicap, même si ce service
est promis dans les prochaines versions. La connexion à SAP sera en effet une exigence forte de
l’armée de l’air lorsque la question du choix définitif de l’ETL se posera. Le fait de posséder un
connecteur SAP permettra de migrer à moindre coût les jobs d’alimentation le jour où la source de
données ne sera plus SIGAPAIR mais ORCHESTRA. La pérennité de l’entrepôt au-delà de l’arrivée
d’ORCHESTRA serait ainsi assurée.
42/54
5.5.2 L’alimentation initiale
L’objectif de cette première alimentation est de prendre un instantané de la situation actuelle de

manière à initialiser l’entrepôt. Il est essentiel qu’à ce stade les sources soient parfaitement identifiées.
Lorsque les sources sont multiples, il y a un travail préalable de comparaison des données pour
permettre leur conciliation. Le concepteur doit alors se poser les questions suivantes : Quel est
l’identifiant métier de chaque occurrence permettant d’effectuer la conciliation ? De tous les systèmes
sources lequel est la référence?
Cette initialisation de l’entrepôt permet de réaliser un premier démonstrateur qui pourra être
présenté à l’utilisateur. A noter que ces traitements ne seront lancés qu’une fois, il n’y a donc pas
expressément besoin d’optimiser les performances.
L’alimentation initiale comporte deux étapes :
Alimentation initiale des dimensions :

Le but est de renseigner les dimensions avec des données fiables. Il faut charger non seulement les
données qui sont susceptibles d’être liées à un enregistrement de la table de faits mais aussi celles que
l’utilisateur souhaite voir apparaître dans les listes de valeurs même si aucun fait ne s’est produit pour
ces données.
Par exemple, pour les grades le choix a été fait de charger la totalité des grades en cours de validité
même si certains de ces grades ne sont à ce jour pas utilisés. Cette question de la complétude des
dimensions peut être traitée ultérieurement.
Figure 22: Alimentation de la dimension poste depuis deux sources de données BRH et SIGAPAIR V6
Alimentation initiale des tables de faits :

Le travail consiste à extraire les événements des tables transactionnelles. Ces enregistrements
comprennent des clés propres aux systèmes sources, la première tâche va donc consister à trouver la
clé de substitution correspondante dans les dimensions. Si l’enregistrement n’est pas présent, il est
nécessaire d’enrichir la dimension. Tous les enregistrements de la table de faits doivent être liés à
chaque dimension, la clé de la table de faits étant composée de l’ensemble des clés de chaque
dimension mises bout à bout.
L’enrichissement consiste donc à ajouter un enregistrement dimensionnel en élargissant les
critères de filtrage de la source. Il peut aussi être décidé d’ajouter un enregistrement « sans objet »,
« non communiqué » ou « inconnu » en cas de besoin. C’est aussi à cette étape que l’on gère le
changement dans les dimensions en fonction du type de gestion retenu 1, 2 ou 3 (cf. §5.4.3).
43/54
Enfin, il est parfois nécessaire d’effectuer les calculs nécessaires pour les différents indicateurs de
la table des faits.
Remarque : Tant que les données ne sont pas fiables et que les utilisateurs n’ont pas validé les
premiers écrans, il est inutile d’aller plus loin dans le développement des jobs d’alimentation.
Figure 23: alimentation initiale de la table de faits des existants
5.5.3 L’alimentation incrémentale
Une fois le besoin stabilisé et les données fiabilisées, il est temps de développer les jobs qui seront
lancés selon la fréquence de rafraîchissement des données souhaitée. Dans le cas du datamart
droits/existants, la mise à jour de la partie existant sera quotidienne, il est donc nécessaire d’optimiser
au mieux les traitements. Dans le cas d’un datamart qui aurait une granularité atomique, le principe sera
de ne récupérer que les dernières transactions effectuées. Pour ce faire, il est possible de s’appuyer sur
les journaux de la base de données ou sur d’éventuelles dates de mise à jour des tables du système de
production. Dans notre cas, il a été décidé de s’appuyer sur les tables temporaires générées lors de
chaque réplication entre SIGAPAIR V5 et SIGAPAIR V6. Dans le cas d’une table de faits qui agrégerait
fortement les données, cette partie serait identique au chargement initial, elle consisterait à prendre une
photo de la situation à chaque mise à jour.
44/54
5.5.4 La reprise de l’historique
Il est souvent nécessaire de récupérer un historique pour pouvoir établir des tendances ou mettre
en place un outil de datamining. Cette opération est très coûteuse en temps de traitement, elle doit donc
être lancée de manière exceptionnelle. Pour ce faire, l’historique ne sera repris que lorsque la validation
finale de l’entrepôt aura été effectuée par la maîtrise d’ouvrage. Dans l’exemple présenté ici, la maîtrise
d’ouvrage a souhaité reprendre un historique de 2 ans.
5.5.5 Le traitement des rejets
L’un des objectifs du data warehouse est d’offrir une source de données fiable, il est donc
nécessaire de procéder à un travail de nettoyage lors de l’alimentation. Cependant, il n’est pas judicieux
de se contenter de supprimer les enregistrements incohérents, il faut les traiter. Là encore, l’ETL s’avère
être un allié de poids puisqu’il permet aussi bien de corriger automatiquement le système source que de
solliciter une intervention humaine lorsque cela est nécessaire en envoyant par exemple par mail le
fichier des rejets. Il est aussi possible de tenir des statistiques des rejets ce qui contribue à
l’amélioration de la qualité des données.
Figure 24: Exemple de job Talend qui met dans un fichier .xls les administrés ayant des données manquantes
45/54
5.6 Présentation de l’information
Partie émergée de l’iceberg, la présentation de l’information n’est pas celle qui occupe la plus
grande part du temps de travail puisqu’elle ne prend qu’environ 20% du temps total. C’est pourtant bien
par là que l’on aborde le plus souvent l’informatique décisionnelle négligeant de prendre en compte les
autres niveaux de l’architecture. Le parti pris dans cette étude a été, comme l’ont démontré les
précédents chapitres, de ne pas commettre cette erreur et de ne pas brûler les étapes dans la
conception du datamart. Ce n’est pas pour cela que la présentation doit être négligée. Bien au contraire,
Il s’agit du point d’entrée du data warehouse qui va permettre de valoriser le travail effectué en amont.
Si belle est la mécanique sous-jacente, si l’application qui permet de visualiser les données ne répond
pas au besoin ou n’est pas ergonomique, elle sera rejetée par les utilisateurs et le projet sera enterré.
La fin du stage a donc été consacrée à l’élaboration de la partie présentation du démonstrateur. Le
portail open source SpagoBi a été utilisé pour arriver rapidement à un résultat visible. Ce portail intègre
différentes briques open source permettant de générer des rapports de différents types.
5.6.1 Tableaux statiques – Jasper Report
Le générateur d’état choisi dans le cadre de l’étude est JasperReport. Développé par la société
JasperSoft sous licence open source, JasperReport permet de générer des rapports au format PDF,
HTML, XML, CSV, RTF, XLS et TXT. Il se présente sous la forme d’une librairie java et s’appuie sur des
fichiers de description XML générés par un outil de conception graphique comme iReport (cf. figure 25).
Figure 25: l'outil de conception d'état iReport
46/54
Il y a plusieurs moyens de mettre à disposition les états générés :

 intégrer la librairie dans le framework java de l’armée de l’air et accéder aux rapports via
SIGAPAIR V6 ;
 utiliser un portail décisionnel comme SpagoBi qui intègre déjà les états JasperReport en
standard.
La première solution est plus coûteuse puisqu’elle nécessite un effort de développement, en

revanche, elle permet à l’utilisateur de ne s’authentifier qu’une seule fois (Single Sign On) dans le portail
RH. Par la suite, l’administration des droits n’en sera que plus aisée. Enfin, la charte graphique du
portail restera inchangée.
Pour le démonstrateur c’est l’intégration à SpagoBi qui a été retenue pour des raisons de rapidité de
mise en œuvre. Mais pour les développements futurs c’est l’intégration aux applicatifs métier qui sera
privilégiée.
Figure 26: Exemple de rapport statique s'appuyant sur la balance droit existant
47/54
5.6.2 Tableaux dynamiques – Mondrian / JPivot
JPivot et Mondrian forment un couple performant, capable de traiter des cubes volumineux.
Mondrian est un serveur OLAP disponible sous licence open source. Il s’agit plus exactement d’un
serveur de type ROLAP, c'est-à-dire qu’il s’appuie sur des bases de données relationnelles. C’est
Mondrian qui se charge de la constitution des cubes en mémoire et du calcul des agrégats, il se charge
aussi de la conversion optimale des requêtes multidimensionnelles MDX17 en requêtes SQL
compréhensibles par le SGBDR18. Les structures dimensionnelles sont définies dans un schéma XML19.
JPivot est le plus souvent l’interface graphique choisie pour exploiter Mondrian. Il s’agit d’une
bibliothèque de composants graphiques et d’actions permettant d’afficher dans des pages JSP, donc en
mode web, les tableaux croisés dynamiques correspondant aux vues multidimensionnelles. La barre
d’outil fournie par JPivot permet de réaliser toutes les opérations d’analyse OLAP courantes (drill down,
drill across, drill through…).
Figure 27: exemple de rapport dynamique s'appuyant sur la balance droits existants
En ce qui concerne les solutions d’intégration, les possibilités sont les mêmes que pour
JasperReport : une fusion dans SIGAPAIR V6 ou une utilisation dans un portail décisionnel comme
SpagoBI ou Penthao.
17
MDX : Multi Dimensional eXpression
18
SGBDR : Système de Gestion de Base de Données Relationnel
19
XML : eXtended Markup Language
48/54
5.6.3 QBE
Les utilisateurs souhaitent souvent créer leurs propres requêtes sur le datamart. Pour couvrir ce
besoin dans le cadre de cette étude, c’est le module QBE de SpagoBi qui a été mis en œuvre.
Contrairement aux outils précédemment présentés, QBE est fortement lié à SpagoBi et l’intégration fine
avec SIGAPAIR V6 semble difficile.
L’impression qui ressort de cette expérimentation est l’absence de gestion des métadonnées. Ainsi,
les champs affichés sont des champs techniques et les jointures entre les tables doivent être effectuées
à la main ce qui risque de rebuter les non informaticiens (cf. figure 28).
Figure 28: exemple de requête pouvant être effectuée à l'aide de QBE
49/54
6. Déroulement du stage
Mars :
 Découverte du domaine
 Analyse de l’existant et étude du besoin
 Documentation sur l’informatique décisionnelle
 Visite de l’équipe projet CHEOPS au bureau organisation système d’information de l’état major de
l’armée de terre afin de recueillir leur retour d’expérience sur la mise en place d’un data warehouse.
Avril :
 Documentation sur l’informatique décisionnelle
 Choix d’architecture infocentre SIGAPAIR V6
 Première modélisation datamart droits existants
 Analyse des sources (BRH, SIGAPAIR V6)
Mai :
 Expérimentation Kettle
 Rédaction rapport intermédiaire
 Deuxième modélisation du datamart droit-existant. Mise en place d’une granularité plus fine sur le
conseil de la société CARRA Consulting
 Expérimentation Talend sur le conseil de la société CARRA Consulting
Juin
 Alimentation initiale du datamart droits-existants
 Réalisation de rapports statiques à l’aide de Jasper Report
 Réalisation de rapports dynamiques à l’aide des briques Mondrian/JPivot
Juillet
 Rédaction du rapport de stage
 Expérimentation de QBE
 Intégration à SpagoBI des états réalisés
Août
 Rédaction du rapport de stage
 Amélioration du démonstrateur
 Ajout du datamart projetabilité (optionnel)
 Préparation de la soutenance
50/54
7. Préconisations organisationnelles pour la conduite d’un

projet de data warehouse d’entreprise
Le démonstrateur décisionnel a été réalisé dans le cadre d’une étude, il n’était donc pas inscrit dans
une démarche projet classique. Aucune structure projet n’a été définie et les liens avec la maîtrise
d’ouvrage sont restés ponctuels et informels. Les travaux ont été réalisés en quasi autonomie et la
maîtrise d’œuvre (MOE) a souvent dû se substituer à la maîtrise d’ouvrage (MOA) lorsqu’il a fallu faire
certains choix. Bien entendu, il ne pourra pas en être ainsi si le projet débouche sur un véritable projet
de data warehouse d’entreprise. Il devra s’inscrire dans le processus projet conformément à la charte
définie par le CSIA. Cette charte projet définit :
 ce que doit être une structure projet avec les attributions de chaque acteur ;
 quelles sont les grandes étapes d’un projet ;
 quels sont les livrables devant être fournis par la MOE et par la MOA.
Il sera aussi nécessaire de prendre en compte les spécificités d’un tel projet :
Tout d’abord, le projet doit être soutenu au plus haut niveau de l’armée de l’air car l’enjeu est crucial
et concerne toute l’institution. Le démonstrateur doit d’ailleurs permettre d’obtenir cet engagement.
La MOA sera fortement impliquée pour :
- La définition du besoin :
 les requêtes,
 les modes de présentation,
 la définition des faits et dimensions conformes.
- L’alimentation :
 définition des règles de gestion,
 l’amélioration de la qualité des données.
- Les recettes (Vérifications d’aptitude et de service régulier)
La maîtrise d’œuvre devra s’adapter elle aussi aux spécificités d’un projet décisionnel. Tout d’abord,
contrairement au développement d’une application classique, la charge n’est pas répartie de la même
manière. Les experts estiment à 80% le temps dévolu à la conception des modèles et à la préparation
des données, la réalisation de l’application utilisateur proprement dite ne prenant que les 20% restant.
La nature du travail technique est aussi radicalement différente puisqu’il s’agit plutôt ici de mettre en
œuvre des outils du type ETL, base de données ou portails de restitution plutôt que d’un travail de
programmation classique.
Ensuite, la modélisation dimensionnelle est une discipline spécifique faisant appel à un savoir faire
différent de la modélisation transactionnelle.
Enfin, comme l’étude l’a démontré précédemment, le développement du bus décisionnel
nécessite d’avoir une vision transverse sur les différents domaines à intégrer. Le projet a besoin
d’un « gardien du temple » chargé de faire respecter les normes, sans quoi, les datamarts se
développeront de manière isolée et une divergence se produira naturellement.
Cette réflexion conduit à proposer une adaptation de l’organisation de la maîtrise d’œuvre pour le
cas où un tel projet serait conduit en interne. Il est proposé de diviser en deux la maîtrise d’œuvre des
datamarts.
D’une part les équipes en charge des applications opérationnelles pourraient conserver à leur
charge la partie alimentation de l’entrepôt du fait de leur expertise sur les données sources.
D’autre part, une équipe spécialisée en informatique décisionnelle sera responsable :
 du respect des normes du bus décisionnel,
 de la modélisation,
 de la réalisation des restitutions (optionnel)
A noter que l’armée de terre dans le cadre de son projet de data warehouse CHEOPS (cadre
homogène et évolutif pour l’optimisation d’un pilotage structuré) a mis en place une structure dédiée de
ce type.
51/54
8. Conclusion
Cette étude avait pour objectif de proposer des solutions de pérennisation de l’infocentre SIGAPAIR
et de profiter de ce chantier pour engager une réflexion visant à rationaliser le parc d’infocentres pour
aboutir à un véritable entrepôt de données d’entreprise.
Le travail accompli a permis tout d’abord de distinguer deux types d’infocentre : les infocentres
opérationnels comme celui de SIGAPAIR V5 et les infocentres décisionnels.
Pour la première catégorie, l’étude démontre que ce type de besoin ne nécessite pas de refonte en
profondeur des architectures en place. Ces applications constituent un prolongement des systèmes
opérationnels et en sont par conséquent très proches, notamment sur le plan de la structure de
données. Il en résulte pour le cas de l’infocentre RH une préconisation technique qui cherche plutôt à
privilégier un coût minimum et un maintien du niveau de service plutôt qu’une refonte en profondeur. Si
un nouveau besoin de ce type apparaît, la maîtrise d’œuvre devra veiller à la dissociation des bases de
données de production et d’infocentre et à la dénormalisation du modèle d’origine afin d’améliorer les
performances et la lisibilité du modèle.
Pour la deuxième catégorie, l’étude après avoir dressé un bref état de l’art de l’informatique
décisionnel a permis de définir un socle méthodologique, architectural et technique adapté aux futurs
projets de ce type. Le principe retenu est de créer un entrepôt de données suivant le mode itératif et
incrémental, chaque incrément correspondant à la prise en compte d’un nouveau sujet ou tout au plus,
d’un nouveau domaine. Chaque datamart sera modélisé sous forme dimensionnelle et utilisera des
tables de dimension et de faits conformes pour garantir la cohérence du bus décisionnel. Il est par
ailleurs fortement conseillé de mettre en place une équipe dédiée à l’entrepôt qui garantira le respect
des normes définies.
En outre, l’étude a permis de développer de bout en bout un démonstrateur décisionnel basé sur
une plateforme logicielle libre. Ce projet pilote va permettre d’une part, de montrer aux utilisateurs
potentiels l’intérêt du concept et d’autre part, de servir de modèle pour les futurs développements
décisionnels du CSIA. En revanche, le but n’était pas d’effectuer une étude comparative des outils du
marché. Il conviendra donc d’effectuer ce travail ultérieurement si un projet d’envergure est lancé.
Enfin l’expérience acquise sur le sujet a permis d’établir certaines préconisations d’ordre
organisationnel devant être mises en œuvre pour conduire efficacement un projet d’entrepôt de
données d’entreprise. Parmi ces propositions, la création d’une équipe dédiée au data warehouse et
dotée d’une vision transverse est une condition indispensable pour assurer le bon déroulement du projet
et garantir sa cohérence sur le long terme.
Sur un plan personnel, cette étude m’a permis de découvrir une nouvelle discipline de
l’informatique. Même si les systèmes d’aide à la décision ont été assez peu abordés durant le Mastère,
j’ai pu mettre en pratique de nombreux cours suivis durant la période théorique, notamment les cours
« Base de données », « Gestion de projet », « Architecture multi niveaux » et « Ingénierie des facteurs
humains ». En outre, ce stage m’a amené à mettre en pratique l’enseignement fondamental de cette
formation : « Ne plus considérer les applications isolément mais les considérer au sein du système
d’information ». Enfin, cette étude m’a aussi permis de travailler à différents niveaux d’abstraction du
plus conceptuel au plus technique, ce qui est particulièrement intéressant dans l’optique du poste que
j’occuperai prochainement au CSIA.
52/54
GLOSSAIRE
Terme Définition
Datamart (Magasin de données) Il s’agit d’une structure de données orientée sujet. Un

datamart est modélisé sous forme dimensionnelle.
Data warehouse (Entrepôt de données) Selon Kimball le data warehouse est constitué de
l’ensemble des datamarts. Pour Immon, il a une
existence physique, il sert à alimenter les datamarts et
est modélisé en troisième forme normale.
Dimension Axe d’analyse du cube
ETL (Extract Transform and Load) Logiciel permettant d’extraire des données de sources
multiples et hétérogène pour les réconcilier, les
nettoyer et finalement alimenter la structure de
destination qui peut être par exemple un data
warehouse.
Fait Les faits numériques sont des indicateurs ayant une

forte valeur ajoutée pour l’entreprise. Ex : montant
d’une vente.
JVM (Java Virtual Machine) Machine virtuelle java nécessaire pour exécuter du
code java compilé
MDX (MultiDimensional Expression) Langage d’interrogation des bases de données

multidimensionnelles.
MOLAP (Multidimensional OLAP) Base de données permettant de stocker directement

l’information sous forme dimensionnelle.
OLAP (On-Line Analytical Processing) Mode de stockage optimisé pour l’analyse. Les
données sont stockées dans un cube à n dimensions.
OLTP (On-Line Transactional Processing) Mode de stockage optimisé pour les applications
transactionnelles
PGI (Progiciel de gestion intégrée) Ensemble de logiciels intégrant les principales

fonctions nécessaires à la gestion des flux et
processus de l’entreprise. Ex : SAP
ROLAP (Relational OLAP) Moteur OLAP permettant ce visualiser sous forme de

cube les informations issues d’un système relationnel
SGBDR (Système de gestion de base de données Base de données relationnelle

relationnelles)
XML (eXtended markup language) Langage balisé utilisé pour décrire toute forme de
données ou de texte.
53/54
BIBLIOGRAPHIE
Livres et études :
 Ralph Kimball, Laura Reeves, Margy Ross et Warren Thornthwaite : Le data warehouse - guide
de conduite de projet
 Jean-Michel Franco et EDS-Institut Prométhéus : Le data warehouse – le datamining
 Smile : Décisionnel - Les solutions Open Source
 CERSIAT/BAE, TMIS : Etat de l’art sur les systèmes d’aide à la décision et le data warehouse.
Sites Internet :
Site francophones :
http://www.piloter.org/
http://www.decideo.fr/
http://www.systemeetl.com/
Sites anglophones :
http://www.kimballgroup.com/
http://www.inmoncif.com
http://www.1keydata.com/datawarehousing/datawarehouse.html
http://www.dwreview.com/
54/54

Martin Ludovic

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Martin Ludovic

Încărcat de

Drepturi de autor:

Formate disponibile

Rapport de stage

Pérennisation de l’infocentre Ressources

Stage réalisé du 05 mars 2007 au 31 août 2007

Ces remerciements s’adressent tout particulièrement aux personnels de la division

1.2 Analyse du sujet

1.3 Limites du sujet

1.4 Enjeux de l’étude

2. L’organisme d’accueil : Le Centre des Systèmes

2.1 Carte d’identité

 Date de création : Unité créée en 1944 par le Général VALIN

Le CSIA assure des missions très variées et parfaitement complémentaires :

 Hébergement d’applications et des sites web

 Lutte informatique défensive

Ces quatre missions principales concourent à donner au CSIA un haut niveau

Commandant en second Bureau Contrôle de gestion

Département RH Département Matériels Département Technique

Division RH Division Mat Technique Division Systèmes

Division AGF Division Mat Commissariat Division Exploitation

Division LID applicative

3.1 Un système en fin de vie : SIGAPAIR V5

Technologie utilisée dans le cadre de SIGAPAIR V5:

Le périmètre de cette application recouvre :

Arrivée à échéance du contrat de MCO des serveurs ESCALA:

L’infocentre SIGAPAIR V5 s’appuie sur cette architecture en fin de vie :

3.2 Une solution de pérennisation immédiate : SIGAPAIR V6

L’armée de l’air a lancé en 2005 un projet de modernisation du système SIGAPAIR. La maîtrise

Technologie utilisée dans le cadre de SIGAPAIR V6 :

Cette modernisation a commencé par la réalisation de nouveaux services jusque là absents de

L’infocentre et l’entrepôt de données RH devront nécessairement s’intégrer à

3.3 Un projet interministériel s’appuyant sur le PGI SAP :

La Direction générale de l'administration et de la fonction publique (DGAFP) mène un projet

3.4 Un projet décisionnel de niveau ministériel : PITAGORE

La mission d’aide au pilotage du ministère de la défense (MAP) conduit actuellement le

Positionnement de la présente étude vis à vis de PITAGORE AIR :

Facteurs de risque Facteur de succès

Mettre en place des outils d’analyse

Utiliser un ETL pour alimenter une unique source de

Mettre en place un data warehouse permet de créer

Mettre en place une architecture décisionnelle avec

L’étude démontrera au chapitre 5.1.3 que la mise en

Conclusion : L’analyse du contexte permet d’une part, de réaffirmer l’opportunité de l’étude

4. Pérennisation de l’infocentre des bases aériennes

4.1 Analyse de l’existant

4.2 Différenciation des infocentres opérationnels et décisionnels

Le travail de documentation réalisé en parallèle de l’étude du besoin a permis de distinguer deux

Infocentre Data warehouse

A ce stade il apparaît que :

Une modernisation de l’existant doit donc être préférée à une réécriture.

4.3 Les contraintes

4.3.1 Contraintes calendaires

4.3.2 Contraintes financières

4.3.3 Contraintes techniques

L’intégration au réseau Intranet air :

- la disponibilité : toute indisponibilité du réseau entraînera de facto l’indisponibilité de

4.3.4 Contraintes de sécurité

4.3.5 Facteur humain

4.4 Solutions architecturales proposées

Figure 5: architecture logique de la première solution

a) Paramétrage des postes clients

b) Gestion des profils utilisateur

c) Autorisation des flux sur le réseau

Charge liée à la sécurité :

 Dépendance vis-à-vis de BiQuery et de Ingres maintenue,