Mémoire M2 MIAGE SIC 2012 - Simon Joliet

UNIVERSIT PARIS 1 PANTHON SORBONNE
MMOIRE DE MASTER M2
MANAGEMENT SYSTMES DINFORMATION ET
DE CONNAISSANCE
&
INFORMATIQUE DES ORGANISATIONS
MIAGE

EN APPRENTISSAGE
PROMOTION 2012

DEFINITION DE MOYENS ET DE METHODES POUR LA CONDUITE DU CHANTIER DE LEXPLOITABILITE

-APPLICATION DU MODELE INTENTIONNEL AU SEIN DES METHODES AGILES.

REDIGE ET SOUTENU PAR : SIMON JOLIET
DIRECTEUR DE MEMOIRE : SAMIRA SI-SAID CHERFI
MAITRE DAPPRENTISSAGE : ALAIN GOY
RAPPORTEUR ENTERPRISE : UGO JUYOU
DATE DE SOUTENANCE : 18 SEPTEMBRE 2012
Dfinition de moyens et de mthodes pour la conduite du chantier de lexploitabilit

2
Simon Joliet
3

A ma famille.

4
Simon Joliet
5

1. PRAMBULE

1.1. Rsum
Dans lindustrie, il est rgulirement cas de systmes dune valeur fonctionnelle certaine, o la
valeur dusage est cependant faible due la difficult dapprhension des utilisateurs. La cause
est souvent imputable aux stratgies dexploitation inadaptes, voir obsoltes. Ce mmoire se
propose de dfinir moyens et mthodes permettant de piloter un chantier visant laugmentation
de la valeur dusage dun systme. La matrialisation de cette plus-value seffectue en impactant
le volet de lexploitabilit dun systme, grce aux exigences formules par ses utilisateurs. La
mthodologie propose une solution lgante et innovante inspire du modle intentionnel,
intgre dans une approche Agile. Ce processus a pu tre valid de manire empirique par une
mise en situation au sein de lentreprise France Tlcom. Le projet pilote a t le chantier de
renouvellement des interfaces hommes-machine dun produit de mdiation pour les
applications de facturation.

1.2. Mots cls
Backlog ; EKD-CMM ; Exploitabilit ; Gisement ; Macro Design ; Map ; Maquette ; MDE ;
Mta-Modle ; Mthodes Agile ; Partie Prenante ; Requirement Engineering ; Scenario Based
Approach ; SCRUM ; ScrumMaster ; Spcifique ; Sprint ; UML AJAX ; Client lger ;
Framework ; IHM ; Java, J2EE, JSP ; Off The Shelf ; PHP ; RIA ; SCADA ; SNMP ; Supervision

6
Simon Joliet
7

1.3. Remerciements
Je tiens remercier trs sincrement toutes les personnes qui, de prs ou de loin, mont appuy
et soutenu au cours de la ralisation de ce projet ainsi que tout au long de la rdaction de ce
mmoire. Mes remerciements sadressent tout dabord Madame Samira Si-Said Cherfi, en
qualit de Directrice de Mmoire, pour stre montre disponible et pour mavoir suivi, aiguill
et conseill tout au long de la rdaction de ce mmoire.

Je souhaite de plus adresser mes remerciements Ugo Juyou, en qualit de Chef de Projet et
matre dapprentissage de novembre 2011 juin 2012 au sein du Skill Center Mdiation
Platine. Je le remercie chaleureusement pour son implication, ses conseils et la confiance quil
ma accord tout au long de mon apprentissage la Direction des Systmes dInformation de
France Tlcom / Orange.

Jadresse galement mes remerciements Alain Goy, en qualit de Directeur de Projet du Skill
Center Mdiation Platine et matre dapprentissage de juin septembre 2012. Je le remercie
pour le support et le soutien sans faille quil ma accord lors de toutes les runions que jai eu
loccasion dorganiser. Je lui sais gr de ne jamais avoir tari de nouvelles ides cratrices,
contribuant ainsi majoritairement la richesse et la densit de ce projet.

Je noublie pas Dominique Dejammes, en qualit dexpert technique et surtout collgue, pour
mavoir accord beaucoup de son temps. Je tiens le remercier pour stre montr disponible
pour maiguiller et pour me conseiller sur les plans conceptuels et techniques. Je le remercie de
plus trs chaleureusement davoir eu la gentillesse de relire lintgralit de mon mmoire, me
permettant damliorer ce dernier tant sur le fond que sur la forme.

Je remercie au mme titre toute lquipe du Skill Center Mdiation Platine et plus
personnellement Martine Roman, Fabrice Blanchard, Serge Bergre et Geoffroy Veger.

Jexprime ma gratitude Rahima Benhamada en qualit de reprsentante des utilisateurs de
lquipe DECI au sein du projet. Je remercie en passant toute lquipe de DECI pour le temps et
limplication quils ont su consacrer ce projet, ainsi que pour mavoir accueilli si
chaleureusement une journe sur leur site de lIsle dAbeau en Isre.

Je tiens enfin remercier tout spcialement ma sur Marguerite, qui a eu la patience et la
bienveillance de relire et de corriger ce travail dans son intgralit. Je la remercie davoir su
mettre en lumire les rectifications simposant sur la forme et parfois sur le fond, me permettant
de satisfaire pleinement les exigences de qualits que je mtais fix sur lensemble de ce travail.

Merci toutes et tous.

8
Simon Joliet
9
TABLE DES MATIERES

1. PRAMBULE 5
1.1. RESUME ........................................................................................................................................................................ 5
1.2. MOTS CLES .................................................................................................................................................................. 5
1.3. REMERCIEMENTS ....................................................................................................................................................... 7
2. INTRODUCTION 11
2.1. AVANT-PROPOS ........................................................................................................................................................ 11
2.2. CONTEXTE DE PROJET ............................................................................................................................................ 13
2.2.1. Introduction au projet .......................................................................................................................... 13
2.2.2. Problmatique ...................................................................................................................................... 13
2.3. PLAN DU MEMOIRE .................................................................................................................................................. 14
2.4. LIGNE DIRECTRICE .................................................................................................................................................. 15
3. TAT DE LART 16
3.1. INTRODUCTION A LETAT DE LART ................................................................................................................... 16
3.1.1. Thories de la supervision ..................................................................................................................... 17
3.2. SOLUTIONS OFF THE SHELF ................................................................................................................................. 23
3.2.1. Supervision rseau ................................................................................................................................ 23
3.2.2. Supervision industrielle ........................................................................................................................ 33
3.2.3. Bilan dexploitabilit des solutions Off The Shelf ................................................................................. 38
3.3. DEVELOPPEMENT SPECIFIQUE .............................................................................................................................. 40
3.3.1. Avant-Propos ....................................................................................................................................... 40
3.3.2. Application binaire .............................................................................................................................. 46
3.3.3. Application web .................................................................................................................................... 48
3.3.4. Bilan dexploitabilit des solutions spcifiques ...................................................................................... 60
3.4. SYNTHESE GENERALE .............................................................................................................................................. 62
3.4.1. Comparatif des solutions Off The Shelf et Spcifique ........................................................................... 62
3.5. ARBRE DES SOLUTIONS DE LETAT DE LART ..................................................................................................... 64
3.6. CONCLUSION DE LETAT DE LART ...................................................................................................................... 65
4. MTHODOLOGIE 66
4.1. APPROCHE ................................................................................................................................................................. 66
4.1.1. Constitution dune mthodologie ......................................................................................................... 67
4.1.2. Modle de processus .............................................................................................................................. 69
4.1.3. Approche Top-Down ............................................................................................................................ 71
4.1.4. Approche Bottom-Up............................................................................................................................ 72
4.1.5. Dterminer la meilleure approche de collecte ........................................................................................ 73
4.1.6. Aspect itratif de loprationnalisation ................................................................................................. 74
4.1.7. Extension de SCRUM la mthodologie ............................................................................................. 74
4.1.8. Implication des parties prenantes ......................................................................................................... 76
4.2. EXIGENCES ................................................................................................................................................................ 77
4.2.1. Modle des exigences ............................................................................................................................. 77
4.2.2. Exigences Stratgiques (propres lindustrie) ...................................................................................... 79
4.2.3. Exigences Fonctionnelles (propres aux mtiers) .................................................................................... 80
4.2.4. Exigences Oprationnelles (propres au systme) ................................................................................... 81

10
4.2.5. Recueil des exigences ............................................................................................................................. 81
4.3. SCENARIO .................................................................................................................................................................. 84
4.3.1. Thorie sur les scnarios ........................................................................................................................ 84
4.3.2. Modles de scnarios ............................................................................................................................. 85
4.3.3. Processus de rdaction du scnario ........................................................................................................ 86
4.3.4. Macro-design ........................................................................................................................................ 87
4.3.5. Maquette .............................................................................................................................................. 87
4.3.6. Macro-validation du scnario par les parties prenantes ....................................................................... 87
4.4. MACRO DEVELOPPEMENT .................................................................................................................................... 88
4.4.1. Modle du Macro Dveloppement ........................................................................................................ 88
4.4.2. Processus de Macro-Dveloppement ..................................................................................................... 89
4.4.3. Macro-validation de la brique applicative ........................................................................................... 89
4.5. PROTOTYPAGE ......................................................................................................................................................... 90
4.6. INDUSTRIALISATION ............................................................................................................................................... 91
4.6.1. Modles de lindustrialisation .............................................................................................................. 91
4.7. NOUVELLES EXIGENCES OPERATIONNELLES .................................................................................................... 92
5. VALUATION ET CONCLUSION 93
5.1. VALUATION EMPIRIQUE ...................................................................................................................................... 93
5.2. VALUATION PAR LES PARTIES PRENANTES ...................................................................................................... 95
5.3. BILAN ET PERSPECTIVES ....................................................................................................................................... 100
5.4. CONCLUSION ......................................................................................................................................................... 102
6. ANNEXES 104
6.1. REFLEXIONS SUR LA COUCHE TRANSACTIONNELLE .................................................................................... 104
6.1.1. Redfinition de la couche transactionnelle ......................................................................................... 106
6.1.2. Conservation en ltat de la couche transactionnelle .......................................................................... 107
6.1.3. Conclusion des rflexions sur la couche transactionnelle .................................................................... 107
6.2. REFLEXIONS SUR LA MISE EN PLACE DE MAQUETTES .................................................................................... 108
6.2.1. Interface actuelle ................................................................................................................................. 108
6.2.2. Interface projete ................................................................................................................................. 109
6.3. REFLEXIONS SUR LE MODELE DE DONNEES ..................................................................................................... 113
6.4. META MODELE GLOBAL DES ENTITES ET DES METHODES DE PROJET ....................................................... 115
6.5. CARTE MENTALE GLOBALE DU PROJET ........................................................................................................... 116
6.6. EXTRAIT DU GISEMENT DEXIGENCES .............................................................................................................. 117
6.7. IHM HISTORIQUE DE LAPPLICATION PLATINE ............................................................................................ 119
6.8. EXEMPLE DE MAQUETTE FIL DE FER .................................................................................................................. 120
6.9. EXEMPLE DE MAQUETTE ERGONOMIQUE ....................................................................................................... 121
6.10. EXEMPLE DINTERFACE HOMME MACHINE PROTOTYPEE ......................................................................... 122
6.11. REGLES DES REUNIONS AGILES ........................................................................................................................... 123
6.12. REUNION AGILE TYPE ........................................................................................................................................... 123
6.13. QUESTIONNAIRE DEVALUATION PARTIES PRENANTES ............................................................................. 126
7. RFRENCES 129
7.1. INDEX DES FIGURES ............................................................................................................................................... 129
7.2. INDEX DES TABLEAUX ........................................................................................................................................... 130
7.3. BIBLIOGRAPHIE ...................................................................................................................................................... 131
7.4. WEBOGRAPHIE ....................................................................................................................................................... 133
7.5. GLOSSAIRE ............................................................................................................................................................... 134
Simon Joliet

11
2. INTRODUCTION
2.1. Avant-propos
Le monde des systmes dinformation est en constante volution. Cela est d au fait que
ceux-ci, utiliss comme supports aux activits mtiers, doivent sans cesse se radapter de
nouvelles donnes business, tout en tant vecteurs dinnovation. Ce principe est aujourdhui
largement prsent au sein des directions des systmes dinformation sous le terme
dalignement.

Plusieurs mthodes sont alors apparues pour apporter de nouveaux cycles de
dveloppements, voulus plus rapides, plus proches des utilisateurs et de leurs
proccupations, mettant en avant le principe de cration de valeur. Cest une des bases
fondamentales des mthodes Agiles ou encore lingnierie des exigences. Ces deux
approches phares ont en commun limplication des parties prenantes au sein des projets.

Il existe un grand nombre de mthodes intervenant diffrents niveaux de lingnierie de
projet et exploitant des concepts souvent transverses, parfois propres lapproche. Bien
videmment, la mise en place dun chantier, de son dmarrage jusqu' sa concrtisation,
utilisera plusieurs approches offrant des visions diffrentes dun problme similaire mais
voluant mesure de lavancement dun projet. Ces visions diffrentes utilisent presque
toujours des considrations et des facettes similaires. Dans un projet majeur, il est
extrmement important de prendre en compte un maximum dinformations utiles, propre
aux projets, lenvironnement et aux mtiers, sans pour autant surcharger inutilement le
processus du projet lui-mme.

Deux approches offrent des lments de rponses. La premire est la construction dune
mthode spcifique base de composants (Ralyt J., Rolland C., 2001). La seconde et
lingnierie dirige par les modles nomme MDE
1
(Model Driven Engineering). Cette
dmarche consiste utiliser des outils permettant la mta-modlisation dun aspect de la
ralit afin datteindre un objectif. Les outils de la MDE permettent darticuler des modles
au sein de procdures, afin de raliser un mta-programme. Il est propos de marier ces deux
concepts afin de crer une mta-mthodologie, rpondant aux besoins spcifiques dun
chantier particulier.

12

Les avantages de lapproche MDE sont multiples. La rutilisation est assure par la
dimension haut-niveau de lapproche. Il a t convenu de la mettre en place pour un projet
de conduite du changement, au sein dun chantier damlioration de lexploitabilit dun SI
de mdiation pour la facturation, au sein de lentreprise France Tlcom/Orange.

La justification dune telle approche, spcifiquement pour un aspect dun chantier, a
plusieurs motivations. Tout dabord, les exigences trs nombreuses des parties prenantes aux
profils varis. Ensuite, la ncessit imprative dintroduire les parties prenantes dans des
cycles de dveloppement itratifs. Enfin, la ncessit de livrer un prototype, soit une
oprationnalisation pralable lindustrialisation.
Simon Joliet

13
2.2. Contexte de projet
2.2.1. Introduction au projet
Le projet pour lequel cette mthodologie sera mise en place porte sur la redfinition de la
supervision dun produit de mdiation pour la facturation, dans le domaine des tlcoms. Le
produit ralise la traduction des informations du monde de lutilisateur, vers le reste du SI
de facturation mais aussi les bases de donnes darchivage lgales ou encore les
DataWarehouses marketing et analytiques.

Le chantier ne se limite pas la couche de prsentation. Il sagit aussi de trouver de nouvelles
stratgies de supervision en partant dun systme existant. La supervision de ce produit est
complexe, il serait ncessaire de simplifier cette dernire en trouvant de nouvelles faons de
superviser lexistant, tout en conservant la supervision actuelle.

La mthode ainsi ralise permettrait de conduire tout chantier portant sur la conduite dun
projet dexploitabilit dun systme, ncessitant dimpliquer au maximum les parties
prenantes et dbouchant sur des livraisons rgulires de prototypes, puis la mise en place du
systme cible.
2.2.2. Problmatique
La problmatique retenue est donc La dfinition de moyens et de mthodes pour la
conduite du chantier de lexploitabilit . Ce type de chantier consiste partir dun systme
possdant dj une valeur fonctionnelle, mais o la valeur globale est affaiblie par la valeur
dusage. Cela peut-tre d un dfaut dalignement de la couche dexploitation du systme,
rsultant par exemple de lutilisation dune technologie obsolte, ou simplement de la
pauvret des interactions proposes aux utilisateurs. Le cur mtier du systme sur lequel la
mthode sappliquerait est suppos tre conserv en ltat, ce qui ne serait pas le cas des
couches de transport et de prsentation.

Cela signifie donc quil est ncessaire de dterminer les technologies permettant de
supporter le chantier et larchitecture mettre en place par rapport la technologie retenue.
Les mthodes formelles permettent de diriger et dorienter efficacement un projet et sur ce
point, limplication des parties prenantes est absolument dterminante. Ce mmoire
propose donc didentifier et dexpliciter les moyens et les mthodes ncessaires la
rsolution de cette problmatique dentreprise.

14
2.3. Plan du mmoire
Ce mmoire sera divis donc en deux parties ; Moyens et Mthode . La premire
partie permet didentifier les meilleures solutions applicables la couche technique et
larchitecture associe. Ces solutions seront proposes la suite dune tude de ltat de lart.
La seconde partie, constituant le cur du travail prsent, proposera une mthode
permettant de diriger le projet indpendamment des solutions techniques et structurelles
retenues.
Simon Joliet

15
2.4. Ligne directrice
Il est propos ici danalyser le contenu du mmoire dans sa capacit rpondre la
problmatique initialement formule. Cette analyse est une introspection a posteriori, base
sur lensemble du travail effectu tant sur le volet thorique que dans sa mise en uvre
pratique. Ainsi et dans une optique de rutilisabilit, les diffrentes tapes du projet seront
ici traites et les renvois aux pages sy rfrant seront mentionnes.

Constitution du gisement des exigences
La premire tape du chantier consiste rcolter les exigences des parties prenantes (p77).
Deux approches existent pour la constitution du premier gisement dexigences, une
approche Top-Down (p71) ou une approche Bottom-Up (p72). Ces exigences sagencent
selon trois niveaux : Stratgique (p79), Fonctionnel (p80) et Oprationnel (p81).

Identification dune technologie
Lorsque suffisamment dexigences ont ts rcolts, il devient possible dargumenter en
faveur dune technologie, en se basant pour cela sur ltat de lart (pp16-65). Deux grandes
familles dingnierie de produit sont documentes dans cette partie : lutilisation dun
progiciel (pp23-38), ou la mise en place dun dveloppement spcifique (pp40-60).

Dmarche organisationnelle
Une fois la technologie identifie, la mise en uvre du projet peut tre dclenche (pp84-
92). Ce volet est oprationnalis en mode Agiles (p74). La mise en uvre est ainsi motive
par la concrtisation des exigences telle que spcifie par les parties prenantes, en priorisant
systmatiquement la cration de valeur.

Ralisation de maquettes
Afin de justifier les dveloppements crant cette valeur ajoute, les exigences doivent tre
conceptualises en vue dtre valides par les parties prenantes (p87). Cette validation se
concrtise par la prsentation de maquettes (exemple p120) ou de scnarios fonctionnels,
embarquant une plusieurs exigences.

Dveloppement dun prototype
Les maquettes valides par les parties prenantes sont autant de dveloppements potentiels.
La somme des dveloppements permet de construire un prototype de manire itrative
(p90), (exemple p122).

Industrialisation
La dernire tape du chantier consiste tirer les conclusions du ou des prototypes. En
prenant pour base les dveloppements raliss puis valids par les parties prenantes, il
devient possible de raliser le systme cible crant le plus de valeur moindre cot (p91).

16
3. TAT DE LART
3.1. Introduction ltat de lart
Le rle de cet tat de lart est de dterminer les moyens techniques sur lequel le processus de
projet pourra sappuyer. Sagissant dun projet dexploitabilit, il semble dj intressant
dans un premier temps dobserver sil existe des progiciels permettant deffectuer la
supervision et lexploitation dun systme. Dans un second temps, il sera propos de
comparer ces approches avec celle dun dveloppement spcifique.

Actuellement, ces deux approches techniques prdominent pour ce type de chantier :
Lutilisation de solutions sur tagre (off the shelf
2
), soit des progiciels de supervision
et dexploitation, bass sur des protocoles rseau, techniques ou industriels.
La mise en place dun dveloppement spcifique pour une application base sur des
technologies et des Framework
3
de dveloppement.

Cest un constat tir par Sadovykh (Sadovykh A., 2005), qui propose un cadre de
classification aux solutions de supervision et dexploitation. Selon lui, quelle que soit la
technologie utilise, ces solutions doivent respecter les six points suivants :

Linteroprabilit, le fait que plusieurs systmes, qu'ils soient identiques ou
radicalement diffrents, puissent communiquer sans ambigut,
La portabilit, ou la capacit d'tre utilises sous diffrents systmes et plateformes,
La flexibilit de lapplication dans son intgration et dans son fonctionnement,
Le support dagents intelligents pour des solutions labores,
La facilit de dveloppement et dintgration des composants de supervision,
La facilit dutilisation de loutil tous les niveaux pour les parties prenantes.

Nous utiliserons ces six lments comme mtriques de notre cadre de classification de la
pertinence des solutions de supervision tudies, quelles soient sur tagre ou dveloppes
spcifiquement pour le besoin.
Simon Joliet

17
3.1.1. Thories de la supervision
Pour le chantier, comme le cur fonctionnel du systme nest pas impact, la priorit est
clairement mise sur la remonte dinformations, donc de la supervision du systme, puis de
son exploitation. Avant de mettre en comparaison des solutions ddies la supervision, il
semble pertinent de prendre du recul sur ce quest la supervision.

La supervision nest pas vue par Hernndez (Hernndez H. R., 2006) comme un simple
outil de surveillance. Elle doit aussi permettre le diagnostic, et faciliter laide la dcision.
Son rle consiste permettre la gestion et la surveillance de lexcution dune opration ou
dun travail accompli par lhomme, par une machine ou par un processus technique, puis
proposer des actions correctives si besoin est.

Pour Sadovykh (ibid.), la supervision est une fonction de surveillance et de gestion de tous
les aspects oprationnels dun systme complexe. Elle inclut la disponibilit des applications,
les systmes dexploitation, les quipements rseaux, les flux de donnes, le stockage de
donnes, les activits des utilisateurs, les droits daccs, etc.

Figure 3-1 : Synoptique des trois sous ensemble inhrents la supervision

La surveillance :
Cest une opration de recueil en continu des signaux et commandes dun processus
afin de reconstituer ltat du fonctionnement rel. Ainsi, la surveillance utilise les
donnes provenant du systme pour reprsenter ltat de fonctionnement, puis en
dtecter les volutions. Les informations retransmises par la surveillance viennent
alimenter le module de diagnostic.
Le diagnostic :
Cette tape permet didentifier la cause des volutions. Elle alimente le module
daide la dcision.
Laide la dcision :
Elle doit permettre un dcideur danalyser un dfaut, ou une situation et lui
proposer des solutions associes. Elle peut sappuyer sur une base de connaissances

18
hirarchises, gnre par des critres logiques ou dcouvertes aprs une phase
dapprentissage. Ce dernier peut alors proposer des actions correctives.
3.1.1.1. Les alarmes
Pour Hernndez (ibid.), les alarmes sont les symptmes dun comportement anormal du
systme afin de faciliter sa supervision. Une alarme est dune manire gnrale observe
lorsquune variable prend au cours du fonctionnement du systme, une valeur considre
comme tant anormale .

Lauteur distingue trois dclencheurs distincts dalarmes par rapport lobservation dun
variable :

Une variable prend une valeur non prvue dans un fonctionnement normal ;
elle est suprieure ou infrieure un seuil prdfini,
Une variable reste dans les tolrances, mais varie brusquement. Ce nest pas la
variable mais la drive de celle-ci qui dpasse la tolrance,
Une variable reste dans les tolrances, mais ne respecte pas une corrlation avec une
autre, ou ne respecte pas un pattern prdfini.

Dans le cas de ltude de Hernndez (ibid.), le contexte fait que les dfaillances doivent tre
anticipes (prdiction de la non-potabilit de leau). Cela permet de dtecter les besoins de
maintenance et offre un support daide la dcision. Il est pour cela primordial de disposer
dun grand nombre dinformations sur le systme que lon tudie.

Concernant les mthodes de diagnostic, il existe deux grandes familles : les mthodes base
de modles et celles base de donnes histories.

Simon Joliet

19

Figure 3-2 : Arbre des mthodes de diagnostic
3.1.1.2. La maintenance
Hernndez (ibid.) estime quune supervision a toujours un but sous-jacent de maintenance.
Le simple fait de superviser un systme implique par extension que celui-ci peut tre en
situation de dfaillance. On peut en conclure que la supervision ne permet pas de sassurer
que le systme fonctionne, mais plutt que celui-ci nest pas en dfaut.

Figure 3-3 : Diagramme de flux, problmatique de la maintenance


20
La maintenance corrective
La maintenance corrective est laction de maintenance la plus visible. Cette tape
implique quun lment est dfectueux, donc quil faut le rparer. Ainsi rien nest prvu
lorsque llment fonctionne correctement. La supervision doit pouvoir tre capable de
transmettre un diagnostic pertinent afin de pouvoir dterminer laction entreprendre :

La maintenance palliative
Intervention caractre provisoire, ou risque accept.
La maintenance curative
Ralisation de toutes les tapes ncessaires afin de rendre dune part, le systme de
nouveau oprationnel et dautre part, dviter les prochaines occurrences de cette
panne ( moins encore une fois que le risque soit accept).

La maintenance prventive
La maintenance prventive est lensemble des oprations dont le but est daugmenter la
fiabilit dun systme et de ses processus. Pour cela, un contrle frquent des donnes
dexploitation est ncessaire afin de sassurer du bon fonctionnement du systme, et
danticiper les problmes potentiels. On distingue trois types de maintenance
prventive :

La maintenance systmique
Les interventions sont places des chances fixes en prenant en compte les
phnomnes dusure.
La maintenance conditionnelle
Identique la maintenance systmique, c'est--dire base sur un chancier, mais
ltape de maintenance nest lance que si une dgradation est constate.
La maintenance prdictive
Dans ce dernier cas, le suivi du systme est continu. Lanalyse des situations passes
permet de prvoir les dfaillances futures. Cette maintenance est la plus mme
doffrir un haut niveau de disponibilit. Plusieurs stratgies de maintenance
prdictive sont envisageables (modles prdfinis, apprentissage).

Toujours selon Hernndez (ibid.), la maintenance doit tre continue sur le systme. Ce
nest pas parce que le systme nest pas en situation de dfaillance quil ne ncessite pas de
maintenance, bien au contraire. La maintenance prventive doit tre une composante de la
supervision ; cest le but dune maintenance prdictive que lauteur a mis en place par un
systme dapprentissage base de rseaux neuronaux, couple une ACP
4
(Analyse en
Simon Joliet

21
Composante Principale). Cela permet selon lui de passer dune maintenance curative une
maintenance prdictive.

En ralit, la meilleure faon dassurer la haute disponibilit du systme passe par :

Point amliorer Moyen
Maintenance corrective Mise en place dun outil de diagnostic
pertinent et efficace
Maintenance prdictive Analyse continu de la production, analyse
des rsultats passs
Tableau 3-1 : Axe damlioration, maintenance corrective et prdictive

Pour notre besoin, il est difficile de mettre en place une maintenance prdictive. Un systme
informatique ne possde pas de notion dusure, il est rarement possible danticiper les
pannes qui ne sont pas clairement rcurrentes. Mais cela pourrait tre le cas de certaines
briques techniques et ce titre, une telle rflexion semblerait tre pertinente.
3.1.1.3. La reprsentation de linformation
La reprsentation de linformation est un point trs important pour notre chantier ;
Hernndez (ibid.) en parle assez succinctement. Dans son cas, les seuls modes de
reprsentation sont des histogrammes simples. Ltude de Hurter (Hurter C., 2011) va
quant elle beaucoup plus loin puisque la reprsentation de linformation reprsente
lessence mme de sa thse. Lauteur y dresse dailleurs un tat de lart trs complet.

Ses travaux consistent trouver les manires les plus pertinentes de reprsenter une
information dans un domaine (le contrle arien) o une mauvaise interprtation de
linformation peut avoir des consquences dramatiques.

Il existe historiquement trois grands domaines de reprsentation des donnes :
La cartographie, premier champ dapplication par le biais notable des SIG (SI
Gographiques),
Les visualisations scientifiques (SciVis),
La reprsentation de linformation (InfoVis).

Le domaine de lInfoVis a une dizaine dannes dexistence. Son but est la reprsentation de
donnes de faon abstraite sans rfrentiel dans notre environnement naturel, mais en
utilisant notre systme perceptif comme vecteur damplification de la cognition.

22
3.1.1.4. Thorie des formes, ergonomie et affordance
Le fondement de ltude de Hurter (ibid.) est la recherche dune reprsentation
correctement interprtable en un minimum defforts. Il se base pour cela sur les travaux de
Tufte, Bertin, Kofka, Tukey, Cleveland, Treisman et McGill en matire de reprsentation
de linformation.

Mais cest la thorie de Kofta qui est la plus cite par la suite, notamment par le biais de la
thorie des formes, plus connue sous le nom de loi de Gestalt . Cette loi regroupe entre-
autre les rgles de base de lergonomie des systmes tels que la loi de la bonne forme, de la
continuit, de la proximit, de la similitude, du destin commun, de la clture, etc.

Ajoute cela laffordance
5
, qui est une thorie constituant une trs bonne base pour le
dveloppement dinterfaces homme-machine. Laffordance est la capacit dun objet
suggrer sa propre utilisation. Ce concept est trs employ notamment, dans le design et
les interfaces homme-machine actuelles.
Simon Joliet

23
3.2. Solutions Off The Shelf
Dans un premier temps, il convient de recenser les solutions sur tagre permettant
deffectuer de la supervision. Il existe deux grandes familles de supervision :

La supervision rseau, base entre autre sur les protocoles SNMP
6
et ICMP
7
,
La supervision industrielle, base sur une multitude de protocoles techniques
(SCADA
8
).
3.2.1. Supervision rseau
Le paysage actuel est constitu dun trs grand nombre de solutions adaptes au monitoring
de systmes dinformations complexes, par le biais notamment de la technologie SNMP
(Simple Network Monitoring Protocol). Utiliser ce protocole pour transmettre des
informations de contrle dexploitation est un enjeu terme pour le chantier. Mais
lutilisation de cette technologie pourrait aussi bien tre un atout pour faire transiter tous
types dinformations, puis dobserver ces dernires via un logiciel de monitoring rseau cl
en main. Cest lune des hypothses de cet tat de lart.
3.2.1.1. Les progiciels de supervision rseau
Deux grands standards permettent actuellement deffectuer une supervision des rseaux :
ICMP et SNMP. ICMP est orient technique alors que SNMP est plutt orient
fonctionnel ; ce standard est donc plus adapt aux problmatiques du chantier de
lexploitabilit.

De nombreux produits exploitent cette technologie. Il est noter quune grande partie de
ces outils sont open-source (GNU
9
GPL
10
, ).

Exemple : RRDTool, Cacti (Oudot C., 2005), OPenNMS, MRTG, Vigilo, Nagios
(Imanache D. et al, 2004), Icinga, Shinken, Centreon, Zabbix (Temple C., 2004),
Eyesofnetwork, Unicenter, TNG, HP Openview NMMi (Vilemaitis M., 2011), Pandora
FMS, IBM Tivoli, NetCrunch, SUNNetManager

<www.monitoring-fr.org>


24
Voici la description de cinq outils de supervision correspondant le plus notre besoin, en
termes de communaut dutilisateurs, de modularit, dergonomie et de reprsentation de
linformation :
3.2.1.2. Nagios
Nagios permet de superviser les machines et les services dun rseau en utilisant des plugins
indpendants. Ces plugins sont majoritairement des scripts excutables. Le comportement
de Nagios est renseign dans des fichiers de configuration plats. Nagios est l'utilitaire gratuit
le plus utilis dans le monde de la supervision.

Les informations sont remontes grce au plugin Snmptrapd. Ce dernier est charg de
rcuprer les traps SNMP sur un rseau. Il se configure via le fichier snmptrapd.conf. Nagios
fonctionne en deux modes :
le mode polling (il interroge les quipements),
le mode passif (il attend les requtes clients).

Le mode polling surcharge plus le rseau, mais offre une meilleure vision QoS
11
que le mode
passif.

Nagios peut alerter les administrateurs par mail ou par SMS
12
. Toute la configuration passe
par des fichiers textes. Celle-ci est, selon Imanache (Imanache D. et al, 2004), lauteur dun
guide assez exhaustif sur la solution, relativement longue si lon souhaite grer plusieurs
centaines de machines. Il existe un trs grand nombre de fichiers, ce qui peut tre
rapidement problmatique. Cest un point que Centreon se propose par exemple de corriger
(voir le chapitre consacr Centreon en page 25). Il est somme toute ncessaire daffiner
cette configuration pour ne conserver que les informations indispensables superviser.

Daprs Imanache (ibid.), il est possible de superviser quasiment tous les systmes avec
Nagios, ce qui ncessite recherche, dveloppement et surtout temps. Nagios est la base de
nombreux autres logiciels de supervision rseau, qui bnficient trs souvent de plugins,
ceux-ci tant souvent compatibles avec Nagios.

Avantages Inconvnients
La solution la plus utilise (Amazon, BMW,
Google, T-Mobile, Siemens)
Richesse des plugins
Permet de dvelopper ses propres plugins
Trs oriente alarme
Interface complexe et pas trs intuitive
Configuration fastidieuse, nombre
important de fichiers de configuration
Configuration de bout en bout
Un seul dveloppeur sur toute la solution
Simon Joliet

25
Tableau 3-2 : Avantages et inconvnients de la solution Nagios

<http://www.nagios.org/>
3.2.1.3. Zabbix
Zabbix est un logiciel permettant de superviser les lments physiques (mmoire, CPU
13
,
disques, ...), les services rseaux (SMTP, HTTP
14
, ...) ou les applications sur serveurs et
postes clients. Globalement, son comportement gnral est trs proche de Nagios bien que
son fonctionnement technique soit assez diffrent. Tout comme Nagios, Zabbix ne se limite
pas au SNMP et peut rcuprer des informations via des scripts locaux ou distants.

Il peut donc superviser de trois manires :
soit par un processus lanc sur chaque machines qui collecte les donnes en local,
soit par une vrification externe (seuls les services rseaux peuvent dans ce cas tre
tests),
soit par SNMP (il peut aussi superviser un quipement tel qu'un commutateur ou
un routeur qui supportant SNMP).

Contrairement Nagios, Zabbix est un tout-en-un et ne dispose pas de plugins.

(Temple C., 2004)

Support par tout une entreprise et non un
seul dveloppeur
Facilit de prise en main des tableaux de
bord
Richesse des sondes et tests possibles
Supervision de ressources htrognes
Gnration de rapports
Modularit limit faute de plugins tiers
Documentation un peu infrieure Nagios
Produit auto-suffisant (tout-en-un) et donc
relativement peu flexible

Tableau 3-3 : Avantages et inconvnients de la solution Zabbix

<http://www.zabbix.com/>
3.2.1.4. Centreon
Centreon est un utilitaire qui vient se placer en front end
15
Nagios. C'est un logiciel libre
sous licence GPL. Centreon est un programme modulaire qui se compose de trois parties :

Le moteur de l'application qui vient ordonnancer les tches de supervision,

26
L'interface web, qui permet d'avoir une vue d'ensemble du systme d'information et
des diffrentes anomalies,
Les plugins, soit une centaine de mini programmes que l'on peut complter en
fonction des besoins de chacun pour superviser chaque service ou ressource disponible
sur l'ensemble des ordinateurs et autres lments rseaux du SI.

Centreon est un moteur de services. Un service est une association plugin-machine. Ces
plugins peuvent tre par exemple des scripts allant tester une fonction, ou devant rcuprer
une donne via SNMP. Il peut encore une fois sagir de scripts distants. Ces services peuvent
avoir des valeurs de seuils, dclenchant par exemple une alarme ds que la valeur retourne
par un module dpasse une valeur prdfinie. De l il est possible de planifier des oprations
spcifiques. La premire alerte envoie un email, la seconde alerte un SMS, etc ...

La solution propose par Centreon offre donc les mmes fonctionnalits que Nagios, le tout
via une interface plus conviviale, avec une installation simplifie et une meilleure ergonomie
gnrale. La prise en main et la configuration est grandement facilite par rapport Nagios.
Pour mmoire, la configuration de Nagios se fait par fichiers plats et nest pas
particulirement aise dun premier abord.

Centreon encapsule aussi le progiciel Cacti. Cacti est une solution de supervision rseau
base sur loutil RRDTool. Globalement, cest une application permettant de gnrer
facilement des graphiques partir de donnes SNMP.

Bas sur Nagios (hritage des plugins)
Trs modulaire
Trs intuitif
Bonne ergonomie gnrale
Modules parfois propritaires
Produit tout-en-un
Fonctionnement plus complexe
Tableau 3-4 : Avantages et inconvnients de la solution Centreon

<http://www.centreon.com/>
3.2.1.5. OpenNMS
OpenNMS est un outil de supervision rseau dvelopp en Java, sappuyant sur le serveur
applicatif Jetty et sur une base de donnes PostgreSQL. OpenNMS est une application
offrant des fonctionnalits trs standards en termes de supervision. Son principal avantage
est en fait son cur applicatif Java, lui confrant de fait une modularit bien suprieure aux
autres solutions.

Simon Joliet

27
Trs performant
Bas sur Java et supporte PostgreSQL
Simple et intuitif
Documentation peu structure
Cur dapplication complexe
Ncessite des comptences Java trs
pointues pour le paramtrage (modification
directe du code source)
Tableau 3-5 : Avantages et inconvnients de la solution OpenNMS

<http://www.opennms.org>
3.2.1.6. HP Openview NMMi
HP Openview NMMi est une solution de monitoring rseau propritaire permettant
deffectuer une supervision autonome, pouvant tre fortement intgre linfrastructure
technique telle que les serveurs, les applications, mais aussi les utilisateurs.

Hewlett Packard dmarque son produit des autres solutions en le prsentant avant tout
comme un outil de gestion au niveau entreprise et non comme un simple lment de
monitoring. De la vision dOpenview, le rseau nest quune partie de la chane supervise
entre linfrastructure technique et lutilisateur en bout de chane.

Lutilisation du produit dpend ainsi du contexte ; il peut tre utilis comme un outil de
monitoring rseau standard, ou comme un outil dcisionnel par le biais de tableaux de
bords. Cette spcificit et le cot de licence non ngligeable de cette solution la rserve des
systmes dune taille consquente.

Comme les autres produits, HP Openview NMMi permet deffectuer une dcouverte en
temps rel du rseau.

(Vilemaitis M., 2011)

Solution globale et prouve
Primtres techniques et fonctionnels trs
tendus.
Supports techniques, SLA
16

Cot dacquisition et de support
Dveloppement additionnel restreint et
coteux
Plutt adapt aux trs gros rseaux
Tableau 3-6 : Avantages et inconvnients de la solution Openview NMMi

<http://www8.hp.com/us/en/software/software-product.html?compURI=tcm:245-936950>

28
3.2.1.7. Synthse des solutions de supervision rseau
Voici une liste des points dapprciation des diffrentes solutions disponibles actuellement.

a) Licence
Il ressort deux types de solutions, les libres sous licence GNU/GPL et les solutions
propritaires. Historiquement dans le domaine de la supervision, les solutions propritaires
taient les plus suivies et les plus flexibles. Ce nest plus vraiment le cas aujourdhui o les
solutions libres sont majoritairement employes et supportes.

b) Taille de la communaut
La taille de la communaut est dfinie selon plusieurs facteurs. La communaut open-source
est par exprience plus active que la communaut dutilisateurs de solutions propritaires.
Le critre est ensuite valu en se basant sur les forums, la facilit de la recherche
dinformation, les sites utilisateurs ddis des solutions et la ractivit de la communaut.

c) Prise en main
La prise en main se base en partie sur les retours des utilisateurs sur les sites spcialiss, et de
nombreux comparatifs accessibles sur Internet, voir des tests de solutions en ligne lorsque
des dmonstrations sont proposes par les diteurs.

d) Frquence des mises jour
La mesure se base sur la date de sortie de la dernire version majeure, lcartement calendaire
des versions majeures et sur la frquence des mises jours correctives.

e) Notorit
Ce critre constitue une apprciation des retours positifs des solutions, des ressentis
utilisateurs sur les forums, ou des conseils donns par les utilisateurs pour des questions
relatives aux solutions.

f) Documentation
La notation de laspect documentaire se base sur la facilit trouver des informations sur
internet pour les solutions tudies et sur lexistence de livres papier ou debooks. Pour les
produits propritaires, la notation est diffrente puisquil est relativement difficile de
trouver des informations techniques. Ce point se base alors sur la disponibilit
dinformations techniques sur les sites officiels des solutions.
Simon Joliet

29
Voici une liste synthtisant les principales solutions gratuites et payantes actuellement
disponibles sur le march. Cette tude se base sur de nombreux tests, comparatifs, retours
utilisateurs, forums et tutoriels disponibles sur Internet.
S
o
l
u
t
i
o
n

D
v
e
l
o
p
p
e
u
r

/

d
i
t
e
u
r

V
e
r
s
i
o
n

a
c
t
u
e
l
l
e

L
i
c
e
n
c
e

T
a
i
l
l
e

d
e

l
a

c
o
m
m
u
n
a
u
t

P
r
i
s
e

e
n

m
a
i
n

F
r
q
u
e
n
c
e

d
e
s

m
i
s
e
s

j
o
u
r

N
o
t
o
r
i

D
o
c
u
m
e
n
t
a
t
i
o
n

Cacti
The Cacti
Group
0.8.7i
GNU
GPL
Moyenne Moyenne Moyenne Moyenne Moyenne
Centreon Centreon 2.3.1
GNU
GPL v2
Moyenne Facile leve
Plutt
importante
Plutt
importante
Eyes of
network
EON 3.0
GNU
GPL v2
Faible Facile Moyenne
Plutt
importante
Moyenne
Icinga Icinga 1.6.1
GNU
GPL v2
Moyenne Facile leve Bonne Moyenne
MRTG
Tobi
Oetiker
2.17.2
GNU
GPL
Faible Difficile Moyenne Faible Moyenne
Nagios Nagios 3.3.1
GNU
GPL
Important
e
Facile leve Importante Importante
NetCrunch
AdRem
Software
6.5
Propritair
e
Faible Difficile leve Assez faible Faible
OPenNMS
The
OPenNMS
Group
1.8.16
GNU
GPL
Moyenne Facile leve
Plutt
importante
Plutt
importante
Openview
NMMi
HP 9.10
Propritair
e
Moyenne Facile leve Importante Faible
Pandora
FMS
rtica ST 4.0
GNU
GPL +
EULA
Trs faible Facile leve Assez faible Faible
RRDTool
Tobi
Oetiker
1.4.5
GNU
GPL
Faible Difficile Faible Moyenne Faible
Shinken Shinken 1.6
GNU
AGPL
17

Moyenne Facile leve
Moyenne-
faible
Moyenne
SUNNet
Manager
Oracle 2.2
Propritair
e
Moyenne Difficile leve Importante Faible
Tivoli IBM 6.2
Propritair
e
Moyenne Difficile leve
Trs
importante
Moyenne
Unicenter
TNG
Computer
Associates
2.4
Propritair
e
Faible Difficile Termine Importante Moyenne
Vigilo CS 2.0.0
GNU
GPL v2
Faible Facile Faible Faible Faible
Zabbix Zabbix SIA 1.8.9
GNU
GPL
Important
e
Facile leve Importante Importante
Tableau 3-7 : Benchmark des solutions de monitoring rseau

30
3.2.1.8. Proposition darchitecture pour la supervision rseau
Ces solutions pourraient tre des atouts dterminants au chantier. En effet, un effort
minimum serait ds lors port la prsentation des donnes, qui serait gre nativement par
les outils. Le volet transactionnel serait alors ralis par un serveur SNMP associ une
MIB
18
. Un effort non ngligeable devra tre port au dveloppement de ce modle de
donnes car le serveur SNMP sera le point dentre/sortie unique de toutes les informations
et commandes du cur de mtier.

Figure 3-4 : Proposition darchitecture associe un monitoring rseau

Les solutions tierces se composent globalement dun serveur Web, dun client SNMP et
dune base de donnes. Le client SNMP va mettre des Traps SNMP
19
afin de rcuprer les
informations sur le systme supervis, puis va remplir une base de donnes locale. Les clients
(utilisateurs effectuant la supervision) se connectent la solution via un navigateur web. Les
donnes affiches sont celles prsentes en base locale. Les commandes dexploitation sont
quant elles envoyes directement au client SNMP et ne passent logiquement pas par la
base de donnes.

Dans le cas du chantier de lexploitabilit, lintrt davoir une base de donnes ct solution
est trs discutable car celle-ci serait potentiellement redondante, verbeuse et peu pertinente.
Or de par la conception des outils de monitoring rseau, cette base de donnes est
primordiale. En effet dans une supervision rseau classique, les informations supervises ne
sont pas prsentes en base, il est donc intressant den conserver une copie pour observer par
exemple lvolution dune QoS au cours du temps. Copier les informations ct solution na
aucun sens dans notre chantier.

Le modle de donnes ensuite doit tre compltement matris afin de pouvoir exploiter la
fonction de dcouverte automatique dont les outils de monitoring rseau disposent bien
souvent. Lexploitabilit dune telle fonction nest pas garantie dans le cas dun systme
Simon Joliet

31
ntant pas un rseau au sens physique du terme. Le modle de donnes devrait ds lors
muler une sorte de rseau virtuel afin dexploiter proprement les outils. Ces derniers
servent en effet superviser avant tout des rseaux informatiques (postes, serveurs, routeurs,
applications, etc.). Dans un cas dutilisation sortant de ce primtre, il est important de se
poser les bonnes questions quant la pertinence de ces solutions.

32
3.2.1.9. Bilan dexploitabilit des technologies de supervision
rseau
Voici dune manire gnrale, les avantages et les inconvnients de la supervision rseau
pour le besoin du chantier :

Souvent de grandes communauts
Outils paramtrables et intelligents
Certains produits disposent de plugins
Restitution des informations aise

Effort de paramtrage
Pertinence des outils de supervision rseau
pour le besoin
Ncessite presque toujours une base de
donnes supplmentaire

Tableau 3-8 : Avantages et inconvnients des technologies de supervision rseau

Les technologies de supervision rseau possdent des atouts importants pour notre chantier.
Il est par contre clair quaucune de ces solutions ne correspond exactement notre besoin ;
celles-ci sont avant tout dveloppes et utilises pour superviser des rseaux physiques et des
applications techniques (plus rarement mtier). Elles sont donc destination
dadministrateurs rseaux par exemple, qui nont pas du tout les mmes besoins que les
exploitants du SI.

Ces outils se concentrent majoritairement sur la disponibilit et la qualit de service offerte
par des quipements rseaux, ce au cours du temps. Cela ne reprsente quune facette des
mtiers de lexploitation du SI. Par ailleurs, leffort de portage sous une de ces solutions de
monitoring rseau serait important et pas forcment optimal. Tout paramtrage ralis sous
ces conditions serait spcifique une application et donc difficilement rutilisable et
capitalisable.
Simon Joliet

33

3.2.2. Supervision industrielle
En matire de supervision industrielle, il existe une famille doutils se retrouvant sous la
terminologie SCADA (acronyme pour Supervisory Control And Data Acquisition). Les outils
SCADA sont utiliss pour surveiller, contrler et exploiter une infrastructure industrielle et
plus prcisment des processus techniques.

Ces systmes sont apparus ds lors quil a t possible de commander et de contrler des
systmes industriels via loutil informatique. Ces solutions se sont dveloppes
paralllement laugmentation de la puissance de calculs des outils. La complexit et la
richesse grandissante des systmes superviss ont impos la ncessit de centraliser et de
synthtiser les informations techniques et les commandes dexploitation sur un minimum
de postes de contrle.

Ces outils se rejoignent par la reprsentation trs graphique des systmes quils supervisent.
Les interfaces de ces outils se doivent dtre extrmement claires, au point que les lments
superviss sont parfois reprsents graphiquement tels quils sont dans la ralit (cuves,
vannes, tapis roulants). Ceci est un point trs positif pour le dveloppement dIHM
moindre cot.

(Wiberg K., 2006) ; (Etinkaya E. K., 2001)
<www.linuxscada.com> ; <www.scadaworld.org>

Il existe un certain nombre de solutions type SCADA actuellement. Cette tude porte sur
trois dentre eux, considrs comme tant les plus graphiques et flexibles disponibles
actuellement.

3.2.2.1. Ignition
Ignition rpond aux problmatiques de collecte, de centralisation, dinteroprabilit et de
visualisation de linformation. La solution est installe sur un serveur ; le dploiement est
donc quasi-instantan pour les clients. Lapplication est base de Java Web Start, qui se
dploie donc par le biais dun page Web ( linstar du dploiement actuel de Platine). Le
client comme le serveur sont multi OS
20
.


34
Ignition sappuie sur une base de donnes. Toutes les informations acquises sont en effet
enregistres en base par le serveur applicatif. Les clients se connectent ensuite cette base
pour rcuprer les donnes collectes. Ce fonctionnement, qui se retrouve dans presque
toutes les solutions SCADA nest pas sans poser problme en termes darchitecture. Ignition
possde une solution pour construire facilement ses IHM
21
(type IDE
22
).

Le prix de la licence dIgnition est par serveur. Le nombre de clients est donc illimit, pour
un cot en version standard de 9925$.
3.2.2.2. Aggregate
Aggregate est un systme de visualisation et dexploitation de processus industriels, de flux
de production, de machines et dinstallations techniques. Il s'agit d'une solution multi-
utilisateurs distribue qui fournit un contrle de supervision centralis.

A linstar dIgnition, Aggregate est un produit permettant deffectuer lacquisition et le
traitement de donnes dquipements industriels. Le systme cre ensuite des interfaces
homme-machines associes afin dafficher en temps rel, dalerter ou de piloter un processus.
Aggregate supporte un grand nombre de protocoles industriels : OLE
23
for Process Control
(OPC), Modbus (TCP
24
, UDP
25
, srie RTU/ASCII
26
/BIN
27
), BACnet IP
28
, et plus
intressant encore, SNMP. Le spectre dun produit comme Aggregate est donc bien plus
large quune solution de monitoring rseau classique.

La solution possde aussi son constructeur dIHM simplifies, tout comme Ignition. Les
objets graphiques sont moins nombreux mais les interfaces gnres sont plus soignes.
Aggregate est plus orient pour les besoins M2M
29
que ne lest Ignition.

Le prix de la licence dAggregate est fonction des quipements superviss. Pour 100
lments, le cot est de 2400$.
3.2.2.3. Mango M2M
Mango M2M est actuellement loutil open-source de contrle industriel SCADA le plus
populaire. Il est comme son nom lindique, trs orient pour des projets M2M. Mango
utilise le navigateur Web et est dploy en mode client lger (application web J2EE
30
) et
non en mode semi lger via des technologies Java Web Start comme cest le cas pour
Ignition ou Aggregate. Mango M2M requiert un serveur applicatif Java Apache Tomcat
pour fonctionner.

Simon Joliet

35
Comme les autres solutions SCADA, Mango M2M va collecter les donnes et les afficher au
sein dIHM destination des oprateurs, qui peuvent leur tour envoyer des commandes
aux lments du processus supervis. Mango M2M fournit une interface simple pour
superviser des donnes htrognes, simplifier la cration et la configuration de flux
multiples tout en offrant la gestion en amont de l'accs des utilisateurs, des alertes, de
l'enregistrement des donnes et de l'automatisation des processus. Le produit est open
source.

(Juhsz B., 2009)

Mango est une solution relativement exotique dans la mesure o celle-ci, contrairement
une majorit de solutions SCADA, est libre et base sur un serveur applicatif Java. Du reste,
mme si la solution est moins riche que les deux prcdentes, cest aussi la plus flexible.

36
3.2.2.4. Synthse des solutions de monitoring industriel
S
o
l
u
t
i
o
n

D
v
e
l
o
p
p
e
u
r
/
d
i
t
e
u
r

L
i
c
e
n
c
e

C
o
u
t

d
e

l
i
c
e
n
c
e

T
e
c
h
n
o
l
o
g
i
e

e
m
p
l
o
y
s

O
p
e
r
a
t
i
o
n

S
y
s
t
e
m
s

L
a
n
g
u
e

I
H
M

W
e
b

A
r
c
h
i
v
a
g
e

A
l
a
r
m
e
s

T
e
n
d
a
n
c
e
s

C
o
n
t
r
l
e

B
a
s
e

d
e

d
o
n
n
e
s

Aggreg
ate
Tibbo
technol
ogy
Propri
taire
2400$
(100) Java
Linux/
Unix,
Win Multi Oui Oui Oui Oui Oui
Oracle,
Postgre
SQL
Argos
SCAD
A
CINT
AL GPL C++ Mono Oui Oui Oui Oui Oui -
Energo
SCAD
A
Oleg
Ivanov
Propri
taire ?
C++/P
HP Linux
Mono
(ru) Oui Oui Oui Oui Oui -
ICSCA
DA
O.Aut
omatio
n
Propri
taire ? PHP
Linux,
Win Multi Oui Oui Oui Oui Non -
Ignitio
n
I.Auto
mation
Propri
taire 9925$ Java
Linux,
Win,
Mac, Multi Oui Oui Oui Oui Oui -
IGSS IGSS
Propri
taire 730 C++ Multi Non Oui Oui Oui Oui -
Lintouc
h SWAC GNU
C++/J
ava
Linux,
Win
Mono
(en) Non Non Non Oui Oui -
Mango
Seroto
nin
Softwa
re
Open-
source Libre
J2EE,
JS,
AJAX Mono Oui Non Oui Oui Oui SQL
openSC
ADA
R.
Savoch
enko GPL C Linux Multi Oui Oui Oui Oui Oui
mySQ
L,SQL
Lite
Provie
w
Manda
tor /
SSAB
O.
Open-
source C Linux Multi Oui Oui Oui Oui Oui -
RTAP
Industr
ial
Defend
er
Propri
taire ?
C/Java
JS,VBA
,
Linux,
Unix,
Win
Mono
(en) Oui Oui Oui Oui Oui Oracle
Stantor Stantor GPL Libre
C/PH
P/JS Linux Multi Oui Oui Oui Oui Oui -
Storozh
Storoz
h GPL C
Linux
Win Multi Non Non Non Non Oui -
SZARP
D.
TERM GPL
C++,S
VG
Linux,
Win Multi Oui Oui Oui Oui Oui -
Tableau 3-9 : Benchmark des solutions de monitoring industriel

3.2.2.5. Bilan dexploitabilit des technologies SCADA
Simon Joliet

37
Voici dune manire gnrale, les avantages et les inconvnients de la supervision SCADA
pour notre besoin :

Reprsentation graphique aise
Conception des IMH efficace
Cot des solutions
Lourdeur des technologies employes
Manque de pertinence pour le besoin
Produits trs riches, mais trop de
fonctionnalits par rapport au besoin
Architecture permissive
Scurit des donnes
Tableau 3-10 : Avantages et inconvnients des technologies de monitoring industriel

Les solutions de supervision industrielles sont moins nombreuses que les solutions de
monitoring rseau. Elles paraissent cependant plus adaptes au besoin dexploitation et de
supervision que les solutions de supervision rseau. Cependant, peu dentre elles sont
gratuites et celles qui le sont disposent gnralement dun faible suivi. La problmatique de
ces solutions est encore une fois les faibles perspectives de rutilisation du code. En effet, si le
choix ralis venait ne plus convenir, les dveloppements ne pourraient pas ou trs peu
servir au paramtrage dune autre solution ; en ralit il sagit dun problme rcurrent aux
solutions sur tagre.
3.2.2.6. Proposition darchitecture pour une supervision industrielle
Les diffrentes solutions de monitoring industriel tudies possdent globalement la mme
philosophie. Celles-ci diffrent quelque peu des solutions rseau. Largument cl de SCADA
est en effet doffrir une rponse aux problmatiques dinteroprabilit. De fait et
contrairement aux solutions de monitoring rseau qui cherchent apporter une couche
dabstraction entre larchitecture technique et fonctionnelle, SCADA se place au plus prs
des infrastructures techniques. Et ce tous les sens de terme : les solutions grent
nativement un grand nombre de protocoles industriels afin de pouvoir collecter
linformation, de lenregistrer en base, puis de lafficher par le biais dinterfaces graphiques.
Elles se contentent uniquement dinformations techniques (plus rarement fonctionnelles),
le tout reprsent de manire trs graphique.


38

Figure 3-5 : Proposition darchitecture associe une supervision industrielle

Dans notre cas, le volet dinteroprabilit naurait aucun intrt puisque cette contrainte a
dj t rsolue en amont ; dautre part, toutes les informations sont dj prsentes en base.
Comme ces outils permettent dextraire les informations via de multiples protocoles et au
plus prs des quipements rseaux, il parat vident que la solution la plus logique
consisterait aller interroger directement la base de donnes.

Dans le cadre du chantier de lexploitation, cette solution serait souvent impossible
implanter au vu des contraintes darchitecture quelle implique. Lintrt dun tel choix
devient ds lors trs limit, de surcrot la plupart de ces solutions sont assez coteuses. Le
volet dinteroprabilit constitue largument phare de ces solutions, mais il ne serait dans
notre cas jamais exploit. Les cas dutilisations standards de ces outils sont trs loigns de
notre besoin.
3.2.3. Bilan dexploitabilit des solutions Off The Shelf
Les solutions sur tagre disposent de nombreux atouts. Leffort de paramtrage est du reste
une donne trs importante prendre en compte. Les contraintes sur les besoins sont
ensuite trs nombreuses et loutil parfait nexiste pas. Le choix dune solution off the shelf
demanderait priori des modifications importantes du produit pour satisfaire le besoin,
modifications sur lesquelles la capitalisation serait trs dlicate.

Cependant le principal problme des solutions sur tagre tudies est que celles-ci sont trs
souvent dployes dans un environnement ne possdant pas dhistorique dexploitation et
de supervision mutualise. Le fait de vouloir reproduire par lutilisation dun progiciel, les
comportements dune solution historique possdant un trs grand nombre de spcificits est
trs complexe et trs difficile mesurer. Il existe des mthodes permettant danalyser les
carts des solutions sur tagre (COTS), qui pourraient avoir du sens dans le cadre dune
analyse plus pousse de la variabilit des solutions tudies ici (Rolland C., 1999). Quoi quil
en soit dans le cas dun prototypage ralis avec une technologie se rvlant tre mauvaise, le
Simon Joliet

39
dveloppement et le paramtrage spcifique une solution ne pourra pas ou peu tre
rutilis dans un autre contexte.

Dveloppement minimalis (idalement)
Librairies graphiques existantes
Intgration facilite
Support fournisseur
Effort de paramtrage
Rutilisation la plupart du temps limit
Solutions parfois payantes
Manque de pertinence des solutions pour le
besoin
Tableau 3-11 : Avantages et inconvnients des solutions sur tagre

40

3.3. Dveloppement spcifique
3.3.1. Avant-Propos
Ce deuxime choix de solution soppose aux produits sur tagre. Il sagirait dexploiter la
couche mtier par une application dveloppe spcifiquement pour le besoin. Il semble
cohrent de mesurer si un dveloppement spcifique ne pourrait pas potentiellement
apporter une meilleure solution par rapport aux progiciels sur tagre. Il est clair quun tel
dveloppement serait plus long. Mais le spcifique permet de sapprocher de la solution la
plus pertinente, tout en permettant une plus grande capitalisation sur le dveloppement
ralis.

Nous noterons deux grandes technologies candidates pour un dveloppement spcifique :
lapplication binaire classique (compile ou prcompile), avec un schma type client
lourd
31
et lautre, lapplication web pour un schma type client lger
32
.

Contrairement aux solutions off the shelf, le fait de dvelopper une application en interne
impose une rflexion pousse sur larchitecture applicative cible. Les choix darchitectures
doivent en ralit se poser de la mme manire pour les solutions sur tagre, mais cette
tape est bien plus importante pour un dveloppement spcifique. Dans le paysage actuel,
un dcoupage de type MVC
33
semble tre la solution la plus approprie.
3.3.1.1. Introduction au modle MVC
MVC est l'acronyme pour le Modle Vue Contrleur. Cest un modle darchitecture utilis
en gnie logiciel, permettant de simplifier la mise en uvre dapplications ayant besoin
dafficher des donnes tout en prenant en compte les interactions des utilisateurs.

Le Modle est la structuration des donnes au sein du logiciel, afin de faciliter leurs
traitements et leurs manipulations. La Vue prend en charge la reprsentation des donnes
pour lutilisateur final. Enfin, le Contrleur est la couche transactionnelle responsable du
traitement de linformation, en fonction des demandes de lutilisateur. Le contrleur extrait
les donnes du modle pour les mettre la forme spcifie par la vue.
(Machacek et al., 2008)

Cette philosophie apparat comme trs pertinente pour notre choix darchitecture.
Simon Joliet

41
3.3.1.2. Dveloppement dune couche middleware
Dans le dveloppement de notre application et daprs larchitecture dfinie prcdemment,
nous allons avoir besoin de dfinir une couche dinterface entre le cur mtier et les IHM.
En fonction de larchitecture prexistante, il peut tre primordial de redfinir la couche
Middleware
34
. Si cette dernire nest pas satisfaisante dans le produit. Il semble intressant
de voir comment ce point pourrait tre consolid terme via le chantier.

Selon Sadovykh (Sadovykh A., 2005), un Middleware de supervision est un progiciel
permettant de faire le lien entre des sources ou des moyens de supervision et des applications
utilisatrices des fonctions dadministration. Le rle du Middleware est de cacher la
complexit de la distribution de la communication. Il fournit la base de la conception
dagents dexploitation et de supervision et simplifie de fait lintgration avec des outils de
visualisation.

Sadovykh nonce 6 familles de normes permettant selon lui, de raliser un Middleware :

Normes Technologies
Appel de procdure distance RPC
35
JRES
Middleware Orient Objet RMI, DCOM
36
, Corba
37

Middleware de Composants CCM, EJB
38

Plateforme Multi-Agents (SMA) FIPA, ICM
Middleware de Messages JMS
39
, Message Query
Webservices
40
SOAP, REST
41
, .NET
42

Tableau 3-12 : Technologies Middleware

Daprs les travaux de Sadovykh, les deux technologies se prtant le mieux cet exercice sont
CORBA et les Webservices. Sadovyky met par la suite en opposition ces deux mthodes.
Globalement suite sa rflexion, il avance que les Webservices sont plus intressants dans le
cadre de composants autonomes tel que des agents de supervision. La suite de son travail a
donc consist dvelopper un Middleware de supervision base de ces Webservices (en
technologie SOAP
43
).

Dune manire gnrale et dans le cadre de notre projet, voici ce que nous pouvons conclure
sur lutilisation dun Middleware de supervision :

Architecture SOA
44

Flexibilit optimale
Cot de dveloppement de la couche
interface et prsentation
Charge serveur plus importante (selon les

42
Division de la supervision en couches
Nombreuses technologies envisageables
Trs adapt pour lexploitation dynamique
(JSON,
45
AJAX
46
)
Possibilit de connexion lexistant (en
SOAP)
solutions)

Tableau 3-13 : Avantages et inconvnients des technologies Middleware
3.3.1.3. Choix dune technologie de Webservices
Pour les besoins du chantier, la solution la plus pertinente en matire de Middleware est
effectivement une approche base de Webservices. Il existe actuellement 23 familles de
Webservices : les technologies SOAP, REST et .NET. Dans le cadre dune optimisation de
lapplication, il serait cohrent doffrir un certain nombre de services mtiers, interrogeables
par le biais des IHM.

Si le choix se portait sur une application Web, une technologie semblerait particulirement
adapte ; il sagirait des Webservices REST. Par rapport la technologie SOAP, ceux-ci
offrent un grand nombre davantages quil conviendrait de prendre en considration.

Larchitecture .NET est exclue doffice du comparatif de par son caractre propritaire et
surtout, non interoprable.

a) Introduction aux Webservices

Les Webservices consistent faire communiquer entre-eux de manire standardise des
environnements htrognes et des systmes potentiellement distants. Ils permettent un
accs des ressources de manire identique pour nimporte quelle application ou utilisateur.
Les informations changes sont structures et normalises, elles transitent au sein dun
intranet ou sur internet par le biais du standard HTTP.

Il existe actuellement deux interprtations majeures de la notion de Webservice que sont :
SOAP et REST. Dune manire gnrale, ces deux mthodes utilisent le protocole HTTP,
ceci prs que SOAP encapsule des trames propritaires au sein de linterface POST. Le
protocole REST pour sa part exploite directement des interfaces (verbs) spcifies par
HTTP. Nous nous concentrerons ici sur limplantation et le fonctionnement des
Webservices REST, ses avantages et ses inconvnients.
Simon Joliet

43

b) Les Webservices REST

Larchitecture REST (REpresentational State Service) est un modle dimplantation des
Webservices interrogeable par le biais des interfaces propres au protocole HTTP. Laccs et la
modification dune ressource se fait au moyen de lURI
47
(Uniform Ressource Identifier),
coupl quatre mthodes classiques de lHTTP: GET, POST, PUT et DELETE. La
structure des ressources repose souvent sur une structuration descriptive de type XML mais
dautres formats sont possibles (texte, HTML, JSON).

Larchitecture REST est une interprtation des Webservices oriente ressource. Cela signifie
quau lieu davoir un point unique de collecte des requtes clients redistribuant les rsultats,
limplantation REST fournie pour chaque donne une interface interrogeable par son URI
respectif. Llment URI est facilement comprhensible de par sa formulation simple et
retourne la ressource explicitement demande par sa syntaxe. Lagencement des ressources
fournie ainsi une stratgie daccs permettant plusieurs acteurs daccder plusieurs
ressources en mme temps, sans goulot dtranglement.

44

Les ressources fournies en retour dune requte client peuvent prendre plusieurs formes :
Une entit HTML : cela dans le but de prsenter facilement des ressources et de
les hirarchiser de manire transparente. Le rfrencement web est alors largement
facilit,
Un document XML : la rcupration dun tel objet permet par exemple un
traitement ultrieur par lapplication consommatrice de donnes (aprs parsing),
Un lment JSON : cela permet dobtenir les donnes dune entit tout en
respectant la structure de lobjet relatif, directement interprtable. Trs utilis en
usage web,
Un lment texte : directement intgrable ou transformable dans lapplication
consommatrice de donnes.

Il apparat que le protocole HTTP se prte parfaitement la notion mme de Webservices
telle que dfinie par limplmentation REST. La structure mme du World Wide Web peut
tre en effet vue comme une architecture REST. HTTP comme REST embarquent tous
deux les notions suivantes :
Ressource : entit accessible par son adresse.
tat : un tat est le statut particulier dune ressource.
Reprsentation : la manire de prsenter ltat dune ressource (texte, HTML, XML,
JSON).
Transfert : la transition entre les tats.

En fait, une requte REST na pas dtat : elle est dite auto-suffisante . Toutes les
informations ncessaires au bon droulement de la requte sont dj contenues dans cette
dernire. Cela a pour effet de rduire les changes client-serveur, de limiter la bande passante
ncessaire ce niveau et enfin de ne pas surcharger le serveur par louverture et la fermeture
de sessions clientes.

Dans le cas dun quilibrage de charge sur plusieurs machines, la requte pourra tre
excute sur nimporte quel serveur.
Simon Joliet

45
c) Avantages et inconvnients des Webservices RESTFull

Limplantation permet un meilleur
nommage des ressources accessible via
lURI,
Lutilisation des URI permet de gnrer des
requtes la syntaxe humainement
comprhensible,
Le protocole exploite un standard robuste,
prouv et gnrique : HTTP. Cela facilite
clairement linteroprabilit,
Seulement 4 interfaces sont ncessaires
pour accder toutes les ressources : GET,
PUT, POST et DELETE,
Limplantation des Webservices REST est
lgre et facilement reproductible (peu de
code ncessaire ; moins que SOAP),
La structure gnre par limplantation est
facilement accessible et rfrenable,
Les ressources tant accessibles
indpendamment et paralllement, il est
possible de prioriser certains traitements
par rapport dautres, ou dquilibrer une
charge,
Le fait quune ressource pointe vers une
URI unique permet de mettre en cache
linformation ct serveur, et daugmenter
la ractivit gnrale,

La scurit nest pas la principale
proccupation de cette architecture,
Limplantation oriente donne demande un
effort supplmentaire pour une utilisation
dun point de vue mtier,
Le passage dlments scuriss par le biais
dune URI nest pas idal.
Avoir une URI par entit nest pas toujours la
meilleure approche selon lapplication,
La formalisation des applications REST nest
pas encore totalement stabilise,
Limplantation de REST nest pas une
solution linteroprabilit en soit, mais elle
la facilite grandement,
Les quatre interfaces HTTP sont bien
adaptes pour manipuler des ressources,
moins lorsquil sagit de concepts mtiers
haut-niveau,
La gestion succs/erreur est celle du
protocole HTTP. Cela nest pas toujours
explicite pour une application ou un
utilisateur (erreurs 4xx et 5xx par exemple),
La mthode DELETE est trs peu utilise sur
le protocole HTTP en temps normal et nest
pas toujours bien implant ou interprt par
les navigateurs et autres applications,
Les donnes ncessaires lenvoi dune
requte doivent tre conserves pendant le
droulement de cette dernire ct client.
Tableau 3-14 : Avantages et inconvnients des Webservices Restfull

46

d) Conclusion des Webservices REST

En faisant le choix de simplanter sur le protocole HTTP, une norme dj solide et
cohrente, larchitecture des Webservices REST bnficie datouts considrables. Laccs
des Webservices peut en effet tre ralis trs efficacement au moyen de seulement quatre
oprateurs dj dfinis. Cela permet REST dtre un protocole lger, performant et
surtout trs facilement intgrable.

Cette implantation nest cependant pas sans inconvnients. Mme si lexploitation de la
norme HTTP permet de rpondre trs justement la problmatique de mise disposition
dinformations dans le but de faciliter linteroprabilit, il nen demeure pas moins que
limplantation reste trs oriente ressource.
3.3.2. Application binaire
Technologies candidates : Java, C/C++,

Pour le chantier, si la mise en place dun IHM Web est acte, REST apparat comme tant la
solution la plus pertinente. Les applications dexploitation historiques sont bien souvent
bases sur des technologies compiles au dploiement problmatique. Ces technologies sont
actuellement dprcies, dans la mesure o elles sont perues comme un frein au
dploiement et lvolutivit du business.

Dans le projet de lexploitabilit ces solutions offrent de nombreux dsavantages. Proposer
une application compile ne permet pas tout dabord dassurer une maintenabilit aise des
solutions. Sur la problmatique du dploiement, ce type dapplication est bien plus
complexe apprhender quune solution Web. Un cas particulier concerne les Applets Java,
dont le dploiement nest pas rellement un problme mais o lobsolescence est effective.

Ces solutions prsentent par contre certains avantages majeurs, comme lintgration
souvent trs pousse des outils de dveloppement via les IDE. Mais cet avantage est
temprer par rapport aux solutions Web qui possdent elles-aussi des solutions de design
rapide dIHM.
Simon Joliet

47

3.3.2.1. Proposition darchitecture associe une application
binaire
En appliquant la philosophie MVC un systme existant et associe une solution
spcifique binaire ventuelle, larchitecture propose serait la suivante :

Figure 3-6 : Proposition darchitecture associe une solution spcifique binaire

Par rapport aux solutions sur tagre, le dveloppement spcifique offre une plus grande
libert en termes darchitecture. Le modle propos nest plus soumis aux contraintes de
solutions tierces potentiellement en conflit avec les contraintes mtiers, internes ou
stratgiques. Ce gain en souplesse se perd mcaniquement en cots dtudes et de
dveloppement.

Dans cette solution, les problmes de redondance de linformation sont limins et par
rapport lexistant, la couche contrleur propose n Webservices, associs toutes les entits
du cur de mtier supervises. Lintelligence serait dporte dans les couches modle et
contrleur qui raliseraient les traitements mtiers entre le cur mtier et les interfaces
homme-machines (vue).

Linconvnient de ce modle est propre la technologie employe ici, savoir lapplication
binaire, qui prsente un certain nombre de limitations en termes de scurit, darchitecture
et de dploiement.
3.3.2.2. Bilan dexploitabilit des applications binaires
En rsum, une solution de supervision base sur une application binaire spcifique nest pas
un choix trs judicieux par rapport au besoin.

48

Performance des solutions
Richesse des outils de conception (IDE)
Dploiement difficile
Maintenance du code complexe
Dveloppement souvent fastidieux
Tableau 3-15 : Avantage et inconvnients des applications binaires

3.3.3. Application web
Technologies candidates : PHP
48
, JSP
49
, .NET,

La problmatique de ces solutions est de dvelopper un modle de donnes permettant une
intgration performante des lments actuels. Il est cependant ncessaire de se tourner vers
des technologies matures, proposant des Framework amliorant significativement la rapidit
de production de code ainsi que sa rutilisation. Les technologies open sources libres seront
privilgies ce qui exclura de fait .Net de ce benchmark.

Deux technologies sont actuellement les plus en vue du Web dynamique dentreprise, PHP
et JSP. Ces deux technologies sont dune part extrmement matures, mais dautre part
disposent de Framework rputs et trs performants qui feront gagner un temps certain lors
du processus de dveloppement ?
3.3.3.1. Utilisation dun Framework
Un Framework est un ensemble doutils de haut niveau, permettant dlaborer rapidement
une application en utilisant une mthode de programmation dite orient composant .
Ces techniques pallient aux limitations des technologies sur lesquelles elles sarticulent, en
facilitant notamment les interactions entre lapplication, les utilisateurs et les autres
systmes (base de donnes, applications tierces, etc.)
3.3.3.2. Les Framework PHP
La liste des Framework PHP est longue. Gnralement ces derniers proposent les mmes
approches, savoir une interprtation de la philosophie MVC plus ou moins pousse. Nous
ne retiendrons que deux de ces Framework, Zend et Symfony. Ces deux Framework sont les
plus riches et les plus utiliss dans lindustrie (respectivement 22% et 34% de part de march
des Framework applicatifs Web utiliss en entreprise).

a) Zend

Simon Joliet

49
Zend Framework est dvelopp par la socit Zend, qui est linitiateur du langage PHP. Un
grand nombre dentreprises utilise ce Framework : Google, IBM, Microsoft, Adobe
Lutilisation de Zend impose de comprendre la philosophie MVC. Le dveloppement dune
application doit suivre des tapes prcises (proposition, modlisation et implmentation), ce
qui est un avantage comme un inconvnient. Lavantage est une bonne modlisation
garantissant un haut niveau de rutilisation du code et un dcoupage applicatif cohrent.

Zend nest pas exempt de dfauts. Le Framework est moins riche que dautres. Certains
lments gnriques doivent parfois tre rcrits. Ensuite, ce Framework ne dispose pas
doutil de gnration automatique de code.

Trs document
Orientation professionnelle
Support de lapplication facilite
Open-Source
Difficile apprhender
Non adapt pour les petits projets et les
prototypes
Performances limites
Tableau 3-16 : Avantages et inconvnients du Framework Zend

<http://www.zend.com/fr/>

b) Symfony

Le Framework Symfony est support par lagence Web franaise Sensio depuis 2003, et est
propos en open source depuis 2005. Lavantage principal de la solution est la gnration de
code qui lui permet de prototyper rapidement une application. Cette gnration est
prsente tous les niveaux dune application Web : vue, contrleur, modle, formulaire, test,
configuration

Lide de base de Symfony est de ne pas avoir rcrire des briques ayant dj t
dveloppes par dautres. En effet le Framework consiste assembler divers projets, avec
leurs spcificits propres, en les liant dans une mme structure de dveloppement tout-en-
un.

Cest un Framework de choix pour industrialiser les dveloppements et simplifier la
maintenance des projets.

50

Trs document
Orient dveloppement rapide
Simple installer et configurer
Apprentissage rapide
Orientation Corporate
volutif sans modifications structurelles
Trs nombreuses briques de base
Open-Source
Installation et utilisation complexe
Forte dpendance au Framework
Lourdeur du Framework
Performances limites
Tableau 3-17 : Avantages et inconvnients du Framework Symfony

<http://www.symfony-project.org/>

c) Comparatif Zend/Symfony

Zend Symfony
Prise en main Trs bonne Bonne
Installation Trs facile Plutt difficile
Routing Trs bon Trs bon
Mapping relationnel-objet Trs bon Plutt bon
Mise en place de modules Trs facile Facile
Formulaires Trs bon Trs bon
Frontend et backend Trs bon Bon
Sessions Moyen Moyen
Organisation du code Trs bon Trs bon
Interactions avec la BDD Trs bon Trs bon
Documentation sur les APIs Bon Bon
Outils de dveloppement Trs bon Moyen
Feuilles de style CSS Trs bon Trs bon
Composants labors Trs bon Trs bon
Tableau 3-18 : Benchmark des Framework Zend et Symfony

(Moro A., 2010)

d) Conclusion Framework PHP

Globalement, on notera une maturit plus importante du cadre propos par Symfony. Dans
une optique de gnration automatique de code et de simplicit du modle, Symfony semble
tre la meilleure approche.

3.3.3.3. Les Framework Java
Simon Joliet

51
Il existe une grande varit de Framework Java. Nous nen retiendrons que deux, qui sont
actuellement les plus suivis, documents et riches. Il sagit des Framework MVC Struts et
Spring MVC. Ces deux produits sont les Framework Java les plus utiliss en entreprise.

a) Struts

Struts est un Framework J2EE libre cr par Craig McClanahan, soutenu par la fondation
Apache depuis 2000. Il utilise lAPI
50
Servlet Java afin dimposer la philosophie MVC. Ce
Framework permet le dveloppement dapplications Web en quipe, optimisant ainsi le
dcoupage applicatif dune solution.

En approche Struts, une application est un ensemble dvnements et dactions dclenchs
par les utilisateurs du systme. Ces lments sont dcrits dans des fichiers XML, dans
lesquels sont renseigns les diffrents cheminements possibles des actions.

Struts est privilgier pour obtenir un gain de temps sur les grosses applications de type
MVC.

Quasiment un standard de fait
Intgration pousse dans les IDE
Nombreuses sources d'informations
Utilisation abusive du XML
Peu d'volutions
Avenir incertain
Beaucoup de classes et de code produire
Architecture vieillissante (Servlets)
Tableau 3-19 : Avantages et inconvnients du Framework Struts

<http://struts.apache.org/>

b) Spring MVC

Spring MVC est un Framework open source, cre par Rod Johnson. Il a t cr pour faire
face la complexit du dveloppement d'applications d'entreprise. Cest un Framework
injection de dpendances, orient aspect. Le Framework est constitu dun certain nombre
de modules dintgration tels quORM
51
, JMX
52
, JDBC
53
ou encore DAO
54
.
(Ladd D., 2006)

Spring MVC est un conteneur dit lger , car son infrastructure est similaire celle dun
serveur applicatif JSP. A linstar de Struts, il prend en charge la cration dobjets ainsi que la
mise en relation de ces derniers par lintermdiaire dun fichier de configuration.

52

Le Framework Spring MVC offre une couche dabstraction permettant dintgrer dautres
Framework, notamment Struts. De fait il ne concurrence pas rellement Struts puisquil est
tout fait possible dutiliser Spring pour le dcoupage MVC, et Struts pour la couche de
prsentation (et donc pas forcment Spring MVC).

Pour ltude, seule limplantation Spring MVC peut-tre mise en comparaison avec Struts.
Lavantage majeur de lutilisation de Spring MVC est surtout son intgration sans coutures
dans Spring, ainsi que son excellent support des Webservices REST.

Intgration complte dans Spring
Grande maturit
Niveau dabstraction pousse
Modularit trs importante
Complexe utiliser dun premier abord
Tableau 3-20 : Avantages et inconvnients du Framework Spring MVC

<http://www.springsource.org/>

c) Comparatif Struts/Spring MVC

Struts Spring MVC
Prise en main Bonne Bonne
Installation Facile Moyenne
Routing Trs bon Trs bon
Mapping relationnel-objet Trs bon Trs bon
Mise en place de modules Bon Bon
Formulaires Bon Bon
Frontend et backend Bon Bon
Sessions Bon Trs bon
Organisation du code Bon Trs bon
Interactions avec la BDD Trs bon Trs bon
Documentation sur les APIs Bon Bon
Outils de dveloppement Trs bon Trs bon
Feuilles de style CSS Trs bon Trs bon
Composants labors Moyen Moyen
Tableau 3-21 : Benchmark des Framework Struts et Spring MVC

d) Conclusion Framework Java

Les Framework Java offrent de trs nombreux avantages, notamment en termes de richesse
dAPI. Les solutions Struts et de Spring MVC se rvlent toutes deux excellentes pour
Simon Joliet

53
raliser des applications mtiers. Cest dailleurs ce titre que ces dernires sont les plus
utiliss en entreprise pour ce type de besoins. Pour conclure, lindustrie tend de plus en plus
vers Spring et Spring MVC, qui se rvlent tre des choix plus durables.

54

3.3.3.4. Synthse sur les Framework
Pour conclure, voici globalement les avantages et les inconvnients de lutilisation des
Framework :

a) Avantages des Framework

Un Framework possde de nombreux intrts. Sil permet effectivement de simplifier les
interactions de base comme les appels la base de donnes ou des Webservices, le cur de
lapplication doit quant lui tre cod autour des outils proposs par le Framework. Le
dveloppement dun projet est globalement plus rapide grce lutilisation dun Framework,
cest un fait.

Il est par contre ncessaire de respecter un certain formalisme, une architecture et des
contraintes de dveloppement propres aux Framework. Cela peut tre problmatique mais
cest pourtant la principale force de ces solutions. Il est en fait plus facile ds lors de se
concentrer sur le cur fonctionnel dun projet, plutt que de rsoudre des problmes
techniques dj rsolus pour dautres besoins. Enfin ces outils possdent pour la plupart de
grandes communauts de dveloppeurs et mcaniquement, les correctifs et volutions sur
ces outils sont relativement frquentes et efficaces

b) Inconvnients des Framework

Ces solutions ne sont cependant pas exemptes de dfauts. Si un Framework oriente
larchitecture technique, il est noter que les dveloppements ne sont pas interoprables
entre les diffrents Framework. Ainsi plus un Framework dispose de fonctions avances et de
haut niveau, plus il sera dlicat de modifier le comportement technique dune application.

Ensuite, le poids dun Framework peut ne pas tre ngligeable. Ntant certes compos que
de fichiers, un Framework chargera significativement le serveur applicatif. Enfin, les mises
jour peuvent parfois tre dlicates mettre en uvre sur un systme en production, mais ce
problme est assez rcurrent dans lindustrie.
Simon Joliet

55

c) Synthse Framework

Gain de temps
Maintenance facilite
Communauts ractives
Solutions gratuites
Structure impose
Poids du Framework important
Normes de travail respecter
Apprentissage parfois dlicat
Mises jour non videntes
Scurit des Framework
Tableau 3-22 : Avantages et inconvnients des Framework de dveloppement Web
3.3.3.5. Comparatif des Framework PHP/J2EE
Globalement, les quatre Framework sont de trs bons outils permettant tous sans exception
de raliser une application web de manire efficace et performante. Le seul point dcart
significatif entre ces quatre solutions est bien sr la diffrence entre le langage utilis, PHP
ou Java (JSP).

Ces deux langages sont relativement diffrents. Le PHP sera toujours prfr pour les
dveloppements rapides et les sites Web dynamiques de moyenne envergure. La technologie
JSP est quant elle privilgie par lindustrie pour les applications mtiers, les sites
marchands, les prototypes et les gros intranets sur architecture n-tiers. Voici donc un
comparatif entre ces deux technologies sur laspect fonctionnel :

JSP PHP
Excution Lourde (pr-compilation) Lgre (interprt)
Paradigme Totalement objet Procdural et notions objet
Dbugger Lourd et complexe Aucun
Connexion une BDD
55
Tous types (JDBC) Tous types (ODBC
56
)
Processus Un processus multithread Un processus par script
Performance Assez performant Trs performant
Complexit Plutt complexe Plutt simple
Verbosit Trs verbeux Peu verbeux
Portabilit Compltement portable Problmes potentiels
Scalabilit Trs scalable Peu scalable
Robustesse Trs robuste Peu robuste
Orientation Corporate Web
Cout de dveloppement Plutt important Bon march
Communaut En de de PHP Nombreuse et active
Intgration technique Difficile Facile
Intgration fonctionnelle Facile Difficile
Tableau 3-23 : Benchmark des technologies JSP et PHP

56

Et dune manire plus synthtique, ce quil faut retenir de ces deux solutions :

P
H
P

Performance
Simplicit
Communaut
Aspect technique
Orient web simple
Peu robuste
Procdural
Peu maintenable
J
S
P

Modle robuste
Scalabilit (extensibilit)
Orient application dentreprise
Aspect fonctionnel
Dbugger lourd
Rigidit
Verbosit
Complexit
Tableau 3-24 : Synthse comparative des technologies JSP et PHP
3.3.3.6. Les Framework Javascript
Cette solution nest pas comparer avec les deux prcdentes ; il sagirait dune brique
complmentaire permettant de gagner du temps lors du dveloppement de lapplication,
ct client. De fait, les Framework PHP ou JSP constitueraient lapplication sur le serveur.
Ceux-ci raliseraient les oprations mtiers au sein des couches contrleur et modle. Le
Framework ct client neffectuerait que des oprations de prsentation de linformation
(graphiques, tri, optimisation daffichage).

De plus et dans le cadre du dveloppement de toute application Web (PHP, JSP ou autre
technologie), il sera ncessaire de dvelopper en Javascript ne serait-ce que pour effectuer des
contrles de base ct client. Utiliser un Framework Javascript est, au vu de la technologie
Javascript actuelle, un argument fondamental en termes de rationalisation et doptimisation
des cots de dveloppement dune application Web.

Les Framework permettant deffectuer des oprations complexes cts client web sont
appels Rich Internet Application
57
Framework . Il en existe actuellement environ 40. Les
solutions payantes et celles utilisant des produits tiers et non interoprables sont limins
(Flash
58
, Silverligh
59
t, WPF
60
). Le Javascript reste la seule technologie lgre et complte
permettant deffectuer des oprations avances cot client.

Le Javascript nest pas exempt de dfaut et dvelopper toute une application dans cette
technologie peut se rvler long, fastidieux, inefficace et non interoprable. Voici une liste
des solutions existantes, adaptes notre besoin :
Simon Joliet

57

Nom License Format
Ample SDK MIT
61
, GPL Javascript
AppFlower MIT License ou commercial Javascript
Cappuccino LGPL Javascript, .sj
Dojo Toolkit BSD
62
Javascript
ExtJS GPLv3 ou commercial Javascript
Google Web Toolkit Apache 2 Javascript
Lively Kernel MIT Javascript
Qooxdoo LGPL, EPL Javascript
Quick PHP Open source Javascript > PHP > Javascript
Sproutcore MIT Javascript
Vaadin Apache 2 Javascript
Tableau 3-25 : Liste des Framework Javascript

De ces solutions, deux sortent du lot : il sagit de Dojo Toolkit et de Google Web Toolkit.
Dune part, ces solutions sont les plus matures, les plus utilises et les plus suivies de tous ces
Framework. Elles disposent de nombreux outils facilitant le dveloppement dapplication et
la construction dinterfaces homme-machine.

a) Google Web Toolkit

Dernirement, les technologies Web sefforcent de simplifier les interactions homme
machine, notamment par le biais des applications internet riches (RIA). L'utilisation accrue
des technologies Ajax pour dvelopper ces applications est une chose, mais il est ncessaire
de garantir la rutilisation et la maintenance de ces applications.

La ralisation de ces objectifs avec les technologies Ajax et Javascript est plutt difficile. La
compatibilit du code sur toutes les plateformes nest jamais vraiment garantie. Ensuite, le
dveloppement et le dbogage dans cette technologie est loin dtre une sincure, ce qui peut
apparatre comme une perte de temps et un des derniers gros problmes en dveloppement
web avanc.

Le Framework GWT, lanc en mai 2006 par Google, a t dvelopp pour rpondre ces
points. Il s'agit d'un ensemble d'outils de dveloppement, de services ouverts et libres de
programmation et de widgets pour le dveloppement bass sur les technologies Ajax. GWT
propose de dvelopper les applications riches dans un environnement Java, infiniment plus
efficace que le Javascript en termes de dveloppement, de rutilisabilit et de matrise du
code.

58

La compilation ne gnre pas de bytecode
63
Java, mais un programme Javascript optimis,
interoprable entre les diffrents navigateurs Web, le tout sans couture. Le dbogage nest
pas celui du navigateur, mais celui intgr lenvironnement de dveloppement utilis.

Leffort a t port par Google pour intgrer pleinement ce Framework dans lIDE Eclipse (
partir de la version 3.2). Le dveloppement des interfaces homme-machine se fait via la bote
outil fournie par lIDE, ce qui constitue un gain non ngligeable.

(Faiz B. M., 2009)

Aucune connaissance Javascript requise
Possibilit de rcuprer le code Java
Communaut trs active
Code Javascript extrmement optimis
Perte de comptence sur le code par
compilation Java vers Javascript
Compilation trs lente
Code difficile tester
Tableau 3-26 : Avantages et inconvnients du Framework Google Web Toolkit

<https://developers.google.com/web-toolkit/>
Simon Joliet

59

b) Dojo Toolkit

Dojo Toolkit est un Framework open source modulaire bas sur une bibliothque Javascript,
conu pour dvelopper rapidement des Applications Internet Riches (RIA), indpendantes
de la plateforme, sur base HTML
64
/CSS
65
, Javascript et Ajax. Il a t lanc en 2004 par Alex
Russell, Dylan Schiemann et David Schontzler entre autres. Le produit est sous licence
BSD.

En utilisant la classe graphique Dijit, Dojo propose un trs grand nombre dlments pour
construire rapidement une interface (compteurs, histogrammes, cartes). La cration des
IHM peut se faire en code, soit avec loutil libre Maqetta. Enfin, ce Framework sintgre
nativement dans les Framework PHP Zend et Symfony, ainsi que le JSP Spring MVC.

Richesse, flexibilit, maturit et lgret du
Framework
Pas dintgration native dans un IDE
Obligation de coder un minimum en
Javascript
Tableau 3-27 : Avantages et inconvnients du Framework Dojo Toolkit

<http://dojotoolkit.org/>

3.3.3.7. Proposition darchitecture associe une application web
En appliquant la philosophie MVC lexistant, voici une proposition darchitecture
applicative web :

Figure 3-7 : Proposition darchitecture associe une solution spcifique binaire


60
Le dveloppement spcifique web est la meilleure interprtation du modle n-tiers, et
srement la meilleure approche en termes darchitecture MVC que lon peut actuellement
trouver. Cest notamment le cas grce aux nombreux Framework qui intgrent et imposent
cette philosophie, permettant ds le dveloppement de partir sur de bonnes bases.

Dans cette solution, le client utilise son navigateur pour accder aux IHM Web.
Lapplication est prsente sur un serveur applicatif Web dynamique (PHP, JSP, ), il ny a
donc pas de contraintes de dploiement de la solution. La maintenance de lapplication se
fait en modifiant les sources du serveur Web, structures de manire efficace par le
Framework applicatif et le modle de donnes prsent dans les traitements mtiers.
Lintgrateur rcupre les objets spcifis dans le modle dobjet, et les place dans des
conteneurs. Lagencement est ensuite ralis ct client.

Une fois lapplication internet riche charge sur le poste du client, celle-ci va utiliser un
Framework Javascript pour rcuprer les informations mtier sur la couche contrleur.
Concrtement, lutilisateur tlcharge un canevas vide, et chaque lment (arborescence,
compteur, ) va se connecter au bon Webservice de manire asynchrone (AJAX), afin de
rcuprer les informations spcifiques la vue utilisateur souhaite.
3.3.3.8. Bilan dexploitabilit des applications web
Pas de problmatique de dploiement
Clients lgers
Gratuit des Framework
Effort de dveloppement
Problmatique de scurit mesurer
Tableau 3-28 : Avantages et inconvnients des applications Web
3.3.4. Bilan dexploitabilit des solutions spcifiques
En rgle gnrale, voici ce que lon peut retenir des solutions spcifiques. Dans un premier
temps, toutes se baseraient sur des technologies libres. En couplant ces technologies des
Framework de dveloppement libres (notamment sur la partie Web), il serait possible de
construire une application de manire rapide et efficace, pour peu que le modle de donnes
soit matris.

La flexibilit et lintgration des exigences du chantier seraient optimales de par la spcificit
du dveloppement. Bien entendu, cela signifie un effort supplmentaire en modlisation,
mais cet effort serait plus structurant long terme. Bien sr, une solution spcifique nest
pas cl en main ; il faudra donc trs certainement dvelopper des briques gnriques existant
Simon Joliet

61
dj dans des produits sur tagre. Le support nest enfin pas garanti sur la solution (mais il
lest sur la technologie et sur le Framework).

Solutions libres
Rutilisation possible
Flexibilit optimale
Intgrations optimale des exigences
Effort de dveloppement
Pas de solutions cl en main
Modle de donnes matriser parfaitement
Pas de support
Tableau 3-29 : Avantages et inconvnients du dveloppement spcifique


62
3.4. Synthse gnrale
3.4.1. Comparatif des solutions Off The Shelf et Spcifique
Daprs ce que nous avons pu voir des analyses prcdentes, nous dressons le tableau
comparatif suivant, en nous basant sur les six points proposs par Sadovykh :

Interoprabilit : Cest le point fort dune solution spcifique. Les solutions sur
tagre intgrent quant elles plutt bien cette donne au niveau rseau mme si ce
nest pas le but premier et cest encore plus le cas avec les solutions de type SCADA
dont une des motivations premires est de faire communiquer des appareils
industriels de technologie diffrente.
Portabilit : Elle est plus facile ct dveloppement spcifique. Ct solutions sur
tagre, elle est souvent dpendante des systmes htes sur les parties serveur et
client, mais ce point est rarement problmatique. La mise en place dun systme sur
tagre au sein dun systme complexe et lhistorique charg peut-tre
problmatique, notamment en terme dintgration avec lexistant et sur des
questions darchitecture.
Flexibilit : Le dveloppement spcifique offre une grande flexibilit, surtout avec
les Webservices, les diffrents Framework et le modle MVC. Les solutions sur
tagre sont en rgle gnrale plus rigides. La scalabilit nest pas toujours assure.
Support dagent : Les solutions sur tagre disposent trs souvent de moyens de
prdiction dvnement, de dcouverte des systmes, etc. Ce point qui est un
avantage significatif, peut ne pas tre trs utile lorsquun systme sur lequel
sapplique une solution est trs particulier. Ct dveloppement spcifique, le
support dagent intelligent nexiste pas. Cest une notion mettre en place si le
besoin est effectif.
Facilit de dveloppement : Ce point est assez particulier puisque idalement, une
solution sur tagre ne devrait pas imposer de dveloppement. En ralit, un
paramtrage ( mesurer) peut-tre une opration trs lourde et dans le cas de
systmes trs particuliers, lutilisation de produits off the shelf ne se justifie pas
toujours. Ct dveloppement spcifique, par essence tout devra tre dvelopp
donc la facilit de mise en uvre nest pas garantie.
Facilit dutilisation : En dveloppement spcifique, les outils tels que les Framework
simplifient la gnration et la rutilisation du code, mais ces solutions ne sont tout
de mme pas videntes prendre en main. En spcifique, lergonomie doit tre mise
Simon Joliet

63
en place. Les solutions sur tagre intgrent nativement les notions dergonomie et
poussent au maximum la facilit dutilisation.

En voici la synthse :

Off the shelf Spcifique
Interoprabilit Moyenne Trs bonne
Portabilit Moyenne Bonne
Flexibilit Moyenne Bonne
Support d'agents Bon Faible
Facilit de dveloppement Moyen Assez faible
Facilit dutilisation Bon Assez faible
Tableau 3-30 : Comparatif qualitatif des solutions sur tagre et du dveloppement spcifique

Ce que nous synthtisons de la manire suivante :

Figure 3-8 : Synoptique de synthse, solutions off the shelf contre dveloppement spcifique
Interoprabilit
Portabilit
Flexibilit
Support d'agents
Facilit de dveloppement
Facilit dutilisation
Off the shelf
Spcifique

64
3.5. Arbre des solutions de ltat de lart
La constitution de cet tat de lart nous permet donc dexposer objectivement loutillage
technique ncessaire la mise en uvre du produit. Ce dernier est prsent ci-dessous sous
la forme dun outil dcisionnel facilitant le choix dune solution par rapport aux besoins sur
une problmatique identique du chantier de lexploitabilit.

Figure 3-9 : Arbre de solutions de ltat de lart

: Choix darchitecture : Branche principale

: Choix de solution : Branche complmentaire

: Choix darchitecture et de solution

Simon Joliet

65
3.6. Conclusion de ltat de lart
Il existe de nombreuses possibilits pour superviser et exploiter un systme. Les besoins
industriels ont contribus au dveloppement de deux grandes familles de supervision : la
supervision rseau et la supervision industrielle. La liste nest pas exhaustive et pourra au
besoin tre tendue dautres familles de progiciels. Pourtant si ces deux solutions semblent
brasser un ventail trs large de besoins, il nest pourtant pas vident de choisir une solution
par rapport une autre, tant celles-ci peuvent diffrer dans lusage.

La rutilisation doutils existants nest cependant pas la seule approche bien quelle prsente
un avantage incontestable. En effet, un dveloppement spcifique pourrait, face des
besoins non couverts par une solution du march, tre une dmarche ncessaire. Cependant,
un dveloppement spcifique ne signifie pas ncessairement une mise en uvre from scratch.
Il existe de nombreux Framework gnriques permettant de dvelopper rapidement et
efficacement une solution sur mesure. Encore une fois, dautres paradigmes que ceux
prsents existent en gnie logiciel et pourrait aussi bien supporter ce chantier.

Le choix dune solution est en somme un exercice difficile. Pour tre certain de faire le bon
choix, la meilleure solution reste de cerner prcisment le besoin et dargumenter sur ce
denier en fonction des spcificits des approches. Chacune des technologies prsentes serait
mme de pouvoir conduire le chantier. Reste savoir laquelle pourrait le faire dune
manire indiscutablement plus efficace.

66
4. MTHODOLOGIE
4.1. Approche
La mthodologie constitue la dfinition du processus dingnierie du projet. Cette
formalisation permet de guider le cycle de dveloppement, afin de transformer un systme
existant en une nouvelle solution. Cette dernire doit la fois tenir compte de la stratgie de
lentreprise et des exigences des parties prenantes. Ces exigences sont gnres sur la base de
lexploitation du systme actuel et plus globalement, de lenvironnement des parties
prenantes.

Dans le cas prsent, le rle de la formalisation est daider la constitution du dispositif
organisationnel permettant de redfinir lexploitabilit dun systme existant. Lexcution
de cette dmarche permettrait ainsi dobtenir un projet fonctionnel, conduisant
efficacement lingnierie de produit.

Figure 4-1 : Workflow de plus haut niveau, dfinissant la position de la mthodologie

Dans le projet de lexploitabilit, nous observons la prsence dun certain nombre dacteurs
que nous englobons ici dans lentit Parties prenantes . Le systme actuel est utilis et
maintenu par des parties prenantes. Lutilisation faite du systme actuel gnre des besoins qui
viennent alimenter un processus de dveloppement. Afin dviter que le projet ne soit pas
tabli sur un mauvais primtre, il est ncessaire avant cette tape que lorganisation
structure les pr-tudes avant mme le recueil des besoins des parties prenantes. Il sagit en
effet de dfinir qui sont ces parties prenantes, comment formaliser leurs besoins, quelle
mthode de projet va tre mise en place, quelle cible est fixe, quel budget est allou, etc. Le
tout pour diriger un projet sur une cible, le systme projet, qui nest ni clairement dfinie, ni
mme connue. Lexercice est donc loin dtre trivial.
Simon Joliet

67

Globalement pour rpondre au besoin qui vient dtre soulev, deux grandes familles
dingnierie de projet sont potentiellement mme de piloter ce chantier :
Lingnierie classique (Modle en cascade
66
, cycle en V
67
, )
Lingnierie incrmentale (Mthodes Agiles
68
, RUP
69
, )

Par rapport au chantier, un modle classique ne parat pas tre la meilleure approche. En
effet, cette mthode impose que tous les besoins, parties prenantes et systme cible soient
connus au dmarrage du projet. Or ce nest presque jamais le cas sur un chantier aussi
structurant que celui de lexploitabilit des systmes. De plus en impliquant directement les
parties prenantes, il ne semblerait pas pertinent de raliser lexpression de besoins au seul
moment du dmarrage du projet.

La meilleure rponse en termes de mthodologie, afin de prendre en compte des besoins
susceptibles dvoluer au cours du temps, sont clairement les mthodes Agiles (Aubry,
2011). La notion de communication sur les livrables est en effet fondamentale pour un tel
chantier. Plutt que de se concentrer sur des tapes de projet, il apparat plus logique
dobserver une dmarche oriente par les livrables. Ces livrables permettraient la fois de
communiquer sur le projet et de faire participer les parties prenantes la mise en place du
systme projet. Il convient ensuite de valider rgulirement les dveloppements afin de
pouvoir ragir rapidement en cas de mauvaise interprtation des besoins. Chaque cycle est
enfin la possibilit pour les parties prenantes de dcouvrir de nouvelles exigences.

Lide directrice de la mthodologie mise en uvre dans le cadre de ce projet, est que le
chantier serait dirig exclusivement par les exigences de ses parties prenantes. Ces exigences
constitueront la matire premire du projet ; elles seront rcoltes, classifies et tries, puis
conceptualises, compiles itrativement au sein dun prototype et enfin mutualises au sein
du systme cible. Il convient prsent de dfinir comment passer de labstrait au concret, en
mettant en place cette mthodologie innovante.
4.1.1. Constitution dune mthodologie
4.1.1.1. Transformation des artefacts de projet
Comme nonc prcdemment, il est ncessaire de dvelopper une mthode performante
afin de piloter un tel chantier. Une premire tape consiste dfinir clairement comment
transformer des exigences en une srie de livrables intermdiaires permettant par la suite de
construire un prototype, puis le systme cible. Cette reprsentation est inspire des
transformations de modles UML (Menet L., 2008).

Figure 4-2 : Modle de transition du systme existant au systme cible en utilisant les exigences

Voici larticulation de ces transformations successives :

68

Lorganisation met des exigences stratgiques au systme cible (exemple : obtenir
de nouveaux marchs ou augmenter le nombre dutilisateurs satisfaits). Les parties
prenantes mettent leur tour leurs exigences oprationnelles et fonctionnelles
sur lexistant.
Ces exigences sont alors organises, groupes et relies les unes aux autres afin de
constituer des clusters dexigences corrls et hirarchises.
Ces clusters dexigences sont extraits du gisement, et sont contextualises par le
biais de macro-design, regroups ensuite au sein de maquettes. Ces macro-designs
qui reprsentent une plusieurs exigences sont alors soumis la validation des
parties prenantes.
Les macro-designs sont transforms en briques applicatives grce la technologie
retenue par lapplication de ltat de lart par rapport au contexte.
Les briques applicatives embarquant les clusters dexigences sont alors soumis la
validation des parties prenantes, gnrant potentiellement de nouvelles exigences
oprationnelles ou fonctionnelles ajouter au gisement.
Les briques applicatives valides sont compiles au sein du prototype. Une fois un
trigger atteint (nombre dexigences satisfaites atteint, ressources puises, deadline
atteinte), le prototype est soumis la validation des parties prenantes.
La validation du prototype par les parties prenantes gnre de nouvelles exigences
ajouter au gisement. Le prototype fournit alors la base de lindustrialisation du
produit final.
4.1.1.2. Mthodes utilises
Plutt que de dvelopper une mthode sur mesure, il est souvent prfrable dutiliser des
mthodes prouves pour les connecter (Ralyt et al, 2001). En utilisant lingnierie des
mthodes base de composants, il est possible de dvelopper une mthode pour les besoins
spcifiques dun projet, en modlisant les concepts utiliss au sein des diffrentes mthodes.

Voir Annexe Mta modle global des entits et des mthodes de projet en page 115.

Pour formaliser lensemble projet, lapproche retenue est lingnierie dirige par les modles
(MDE). En effet, la complexit mais aussi la richesse et la dure du projet implique une
rflexion importante sur sa formalisation. Cela permet ainsi darticuler un certain nombre
de mthodes utilisant des artefacts pour crer dautres dartefacts. Les diffrentes mthodes
peuvent en thorie tre connectes par ces artefacts, pour peu que ceux-ci soient dfinis
dune manire les rendant compatibles avec les mthodes les exploitant.

Simon Joliet

69
Lingnierie dirige par les modles simplifierait le dcoupage du projet en un ensemble de
processus clairs et squencs. De plus, comme cette mthodologie utilise plusieurs approches
distinctes, la formalisation des processus et des artefacts du projet permet de la reprsenter
de faon homogne. Globalement toute la mthodologie est base sur trois concepts : des
concepts de parties prenantes, dartefacts et de transformation dartefacts, comme expliqu
dans la partie prcdente.

Les artefacts sont les objets du projet, comme les exigences ou les macro-designs, exprims
par les parties prenantes, quand les transformations sont des processus de projet, pilots par
certaines parties prenantes. Ces processus explicits par la suite utiliseront la reprsentation
MAP
70
(Ben Achour et al., 1999), et les entits seront modlises par des diagrammes de
classe de type UML (Morley C., 2008). Exemple : on passe dun artefact exigence un
artefact prototype par un processus de rdaction dun scnario (voir partie 4.3.3
Processus de rdaction du scnario en page 86). Schmatiquement, ce processus consommer
une exigence, pour la transformer en scnario.

Les mthodologies et concepts utiliss pour piloter le chantier de lexploitabilit sont :
lingnierie des exigences pour la collecte des besoins (Rolland et al, 1999),
les verbes dEKD-CMM
71
pour formaliser les exigences dimpact (Nurcan S., 2003),
lapproche dirige par les scnarios pour raliser macro-designs, (Rolland et al, 1996),
les mthodes agiles pour loprationnalisation des solutions (Aubry C., 2011).

Lide sous-jacente lemploi dune composition de ces diffrentes mthodes est
limplication forte des parties prenantes lors de la mise en uvre du systme cible.
Lapproche est donc de chaner de manire homogne les trois premires mthodes au sein
de cycles de dveloppement Agiles (en utilisant une approche SCRUM
72
).

Figure 4-3 : Modle de transition et chanage des mthodologies utilises
4.1.2. Modle de processus
Tel que dfinie prcdemment, la base et la matire premire du projet sont donc un
gisement dexigences structures, hirarchises et mises jour de manire incrmentale. La
dfinition itrative des exigences est donc le point central de toute la mthodologie, ce qui
impose presque mathmatiquement lutilisation dune approche de type Agile, afin de
pouvoir ragir la mise jour permanente du rfrentiel dexigences.


70
Start
i1 Dfinir les
exigences
i2 Prototyper
S2 Par approche
Bottom-Up
S1 Par approche
Top-Down
S3 Par cluster
S11 Par
validation
dtude
S4 Par
similitude
S8 Par
invalidation
de concept
S7 Par validation
de concept
S10 Par
itration
S5 Par composition
i3 Industrialiser
Stop
S15 Par validation
dindustrialisation
S13 Par invalidation
dindustrialisation
S6 Par rdaction
De scnario
S12 Par
composition
S14 Par itration
S9 Par macro
dveloppement

Figure 4-4 Modlisation du processus de projet macro avec MAP

Nom Processus de projet de haut niveau
But Augmenter la valeur dusage dun systme
Entre Le Business Model de lorganisation
Les besoins des parties prenantes du systme AS IS
Sortie Le systme TO BE conforme aux exigences valides des parties prenantes
Intentions

i1 : Dfinir les exigences
i2 : Prototyper
i3 : Industrialiser
Stratgies S1 : Par approche Top Down
S2 : Par approche Bottom Up
S3 : Par cluster
S4 : Par similitude
S5 : Par composition
S6 : Par rdaction de scnario
S7 : Par validation de concept
S8 : Par invalidation de concept
S9 : Par macro dveloppement
S10 : Par itration
S11 : Par validation dtude
S12 : Par composition
S13 : Par invalidation dindustrialisation
S14 : Par itration
Simon Joliet

71
S15 : Par validation dindustrialisation
Tableau 4-1 : Description de la stratgie : Processus du projet de lexploitabilit de haut niveau

La mthodologie se compose donc de trois tapes majeures : La premire i1 Dfinir les
exigences , est lintention centrale, elle est en fait la constitution du gisement dexigence,
qui sera exploit tout au long du cycle de vie du projet. La seconde intention i2
Prototyper consiste conceptualiser une plusieurs exigences au sein dun prototype. Un
prototype peut tre de plusieurs niveaux ; il peut sagir dun scnario fonctionnel, dune
maquette, dune brique applicative, etc. Ce point sera dfinit dans le chapitre associ. Enfin
la troisime intention, i3 Industrialiser consiste en la compilation des multiples
prototypes valids dans un produit complet et fonctionnel rpondant aux exigences
slectionnes et valides dans leurs interprtations par les parties prenantes.

La MAP utilise ici sera raffine section par section dans les parties associes la suite de ce
document.
4.1.3. Approche Top-Down
Lapproche Top-Down part du principe que lapplicatif, les exigences des parties prenantes
et lexpertise sur le systme sont suffisant pour dfinir les exigences du niveau stratgique au
niveau oprationnel. Il sagit du raffinement de la section S1 de la MAP globale.

Figure 4-4 : S1, Modlisation de dcouverte des exigences par processus Top-Down

Nom Dcouverte des exigences par processus Top-Down
But Constituer un gisement dexigences
Entre Le Business Model de lorganisation
Sortie Un gisement dexigences de niveau stratgique, fonctionnel et oprationnel
Intentions i1.1 : Collecter des exigences stratgiques

72
i1.2 : Collecter des exigences fonctionnelles
i1.3 : Collecter des exigences oprationnelles
Stratgies S1.1 : Par analyse du business model
S1.2 : Par composition
S1.3 : Par raffinement
S1.6 : Par cluster
S1.7 : Par similitude
S1.8 : Par validation
Tableau 4-2 : Description de la stratgie S1 : Dcouverte des exigences par processus Top-Down
4.1.4. Approche Bottom-Up
Comme il a t dit, il nest pas toujours possible de mettre en place une approche Top-
Down. Dans les autres cas, cest lapproche Bottom-Up qui sera prfre. Contrairement
lapproche Top-Down, lapproche Bottom-Up doit tre mise en place en deux temps.
Dabord on capture les exigences oprationnelles, puis on les organise afin de dcouvrir nos
exigences fonctionnelles, que lon rapproche aux exigences stratgiques de lorganisation.
Une fois cette premire passe effectue, on applique lapproche Top-Down sur le gisement
organis afin dliminer les exigences fonctionnelles et oprationnelles hors scope. Il sagit
du raffinement de la section S2 de la MAP globale.

Figure 4-5 : S2, Modlisation de dcouverte des exigences par processus Bottom-Up

Nom Dcouverte des exigences par processus Bottom-Up
But Constituer un gisement dexigences
Entre Les besoins des parties prenantes du systme AS IS
Sortie Un gisement dexigences de niveau stratgique, fonctionnel et oprationnel
Simon Joliet

73
Intentions

i2.1 : Collecter des exigences oprationnelles
i2.2 : Collecter des exigences fonctionnelles
i2.3 : Collecter des exigences stratgiques
Stratgies S2.1 : Par analyse du systme
S2.2 : Par cluster
S2.5 : Par cluster
S2.7 : Par gnralisation
S2.8 : Par cluster
S2.10 : Par gnralisation
S2.11 : Par rapprochement avec le business model
S2.12 : Par limination
S2.13 : Par limination
Tableau 4-3 : Description de la stratgie S2 : Dcouverte des exigences par processus Bottom-Up

Lapproche Bottom-Up est privilgier lorsque le niveau dexpertise nest pas juge suffisant
sur le systme.

: Dans le cas du projet Platine, cest cette approche qui aura t retenue face la
complexit de lapplication et au vu des diversits potentielles des parties prenantes et des
besoins.
4.1.5. Dterminer la meilleure approche de collecte
Comme cela a t prsent, il existe deux approches distinctes de collecte initiale des
exigences : lapproche Top-Down et lapproche Bottom-Up (aussi connues sous le nom
dapproche montantes et descendantes). Comme il nest pas toujours vident de trouver la
meilleure stratgie, il peut paratre intressant de dresser une synthse pouvant servir doutil
dcisionnel lorsque la meilleure approche doit tre dtermine. En effet la premire
constitution des exigences est primordiale pour lancer efficacement le chantier.

Top-Down Bottom-Up
Paradigme Heuristique Empirique
Approche Analytique Synthtique
Fonctionnement Par dduction Par initiative
Dmarche mise en place Dirigiste Participative
Taille de lorganisation Petite moyenne Moyenne grande
Tableau 4-4 : Comparatif des approches Top-Down et Bottom Up

Comme ce comparatif le montre, ces deux approches ne partent pas des mmes postulats.
Lapproche Top-Down est donc privilgier lorsque lorganisation, les objectifs et la cible
sont connus au dmarrage du chantier, ce qui sera dans les faits rarement le cas. Ainsi et de

74
par son aspect collaboratif, lapproche Bottom-Up sera trs souvent prfre pour les
chantiers dexploitabilit.
4.1.6. Aspect itratif de loprationnalisation
Concernant loprationnalisation, celle-ci est linstar de lensemble de la mthodologie,
base sur des modles itratifs. Lobjectif premier est doffrir un prototype cohrent par
rapport un certain nombre dexigences (un maximum en loccurrence). Si toutes ne
peuvent pas bien sr, tre oprationnalises au sein dun prototype, il est ncessaire de
dceler les exigences fondamentales oprationnaliser en priorit.

Pour cela il est primordial que les parties prenantes soient inclues au plus proche du
chantier. La meilleure solution semble passer par des dveloppements unitaires, des
validations nombreuses de la part des parties prenantes afin de pourvoir efficacement piloter
une oprationnalisation.

Lutilisation des mthodes Agiles semble tomber sous le sens par rapport ces contraintes.
La mthodologie prsente est compatible SCRUM (Aubry C., 2011).

: Pour Platine, les entits SCRUM au projet ont t identifies au sein des parties
prenantes :
Le Directeur de Projet et responsable du service Skill Center Mdiation ,
Alain Goy, en tant que Product Owner en qualit dditeur de solution,
Le charg de projet, Simon Joliet, en tant que ScrumMaster,
Lquipe de projet, Geoffroy Veger et Dominique Dejammes, en tant que team,
Et enfin les utilisateurs du systme, en loccurrence linstance dexploitation
DECI, en tant que Systems Users.
4.1.7. Extension de SCRUM la mthodologie
Lobjectif nest pas ici de prsenter une mthodologie dj prouve, mais plutt dobserver
comment celle-ci pourrait tre mise en situation dans le cadre de ce chantier de
lexploitabilit. La formalisation des exigences propose et lapproche dirige par les scnarii
structurent certains livrables, dont la dfinition diffre mme si lensemble de la philosophie
reste inchange.

A titre dillustration, le cycle de vie dun processus SCRUM :

Figure 4-6 : La vision des sprints SCRUM selon Mike Cohn
Simon Joliet

75

Dans ce schma, il apparat que la base du dveloppement, lquivalent des spcifications en
ingnierie classique, est ici un rfrentiel appel backlog. Cet lment est simplement une
liste dlments rangs par priorit. SCRUM ne dfinit pas ce que doivent tre ces lments,
qui sont nomms de manire courante des stories. Le backlog de produit est lensemble de ces
stories, quand le backlog de sprint est lensemble des stories extraites dans le cadre dun sprint.
A la fin du sprint, les stories sont compiles dans le livrable.

Lapproche utilise diffre quelque peu, mais comme les objets consomms par les processus
SCRUM ne sont pas clairement dfinis par la mthode elle-mme, il est possible de
structurer le processus dingnierie incrmentale en se basant sur dautres entits. Pour la
mthodologie mise en place dans le cadre de cette tude, cest lapproche ci-dessous qui a t
observe.

Gisement
Dexigences
Maquette
Livrable
Sprint
2 semaines
24 heures

Figure 4-7 : Extension du schma de Mike Cohn par une approche dirige par les exigences

Dans le cas prsent, le gisement dexigence est organis par priorit, mais aussi par niveau
fonctionnel et par oprateur, ce qui est un enrichissement considrable par rapport aux
backlog classiques (voir chapitre suivant, 4.2 Exigences en page 77).

Lextraction des exigences se fait par priorisation motive par les parties prenantes ; les
extractions ralises sont ensuite conceptualises au sein de maquettes, embarquant des
clusters dexigences corrls, quivalents aux stories SCRUM.

Une des grandes diffrences de lapproche est de pouvoir lutiliser pendant une dmarche
conceptuelle, c'est--dire que le livrable pourra tre une autre maquette. Ainsi la dmarche
ne sert pas seulement de support lingnierie logicielle dans le cadre des dveloppements,
mais aussi de guide lingnierie des exigences de par sa capacit formaliser des exigences
fonctionnelles au travers de maquettes.

76
4.1.8. Implication des parties prenantes
Lutilisation des mthodes Agiles au sein de ce projet va donc nous permettre de rapprocher
les parties prenantes de notre rflexion de projet. Pour les impliquer de faon efficace et
productive, il est indispensable de fixer des runions davancement et de validation
frquence fixes. Ces runions permettraient de :
Prsenter lavancement des travaux,
Valider les dveloppements effectus,
Exprimer la liste des lots suivants oprationnaliser en priorit,
Valider une liste dexigences oprationnaliser,
Fixer les objectifs de prochaine itration (sprint
73
).

Voir annexe : 6.12 Runion Agile type en page 123.

Dans le cadre de ce projet et conformment la philosophie SCRUM, il est ncessaire
dorganiser un ensemble de runions. Les runions sont intervalles rguliers et chacune
possde un ordre du jour bien spcifique. Le rle du ScrumMaster
74
est de veiller ce que
chaque runion atteigne son objectif prvu.

: Dans le cas du premier sprint du projet Platine, 21 exigences oprationnelles ont ts
extraites du gisement. Ces exigences ont t conceptualises dans plusieurs macro-designs
(principalement des maquettes) qui ont t prsents, arguments puis valids de manire
itrative au cours de diverses runions Agiles. Ces runions sont aussi loccasion de
dcouvrir de nouvelles exigences oprationnelles et fonctionnelles qui sont alors ajoutes au
gisement.
Simon Joliet

77
4.2. Exigences
Les exigences sont la base de ce projet. Chaque maquette, scnario ou dveloppement doit
imprativement tre support par une n exigences du gisement. Un macro design ne
concrtisant pas dexigence doit tre abandonn et ne peut pas servir de base un
dveloppement. En philosophie SCRUM, lapproche est quasiment identique avec le
backlog de produit (Aubry C., 2011).

Lintrt des exigences au sein de ce type de chantier est de pouvoir consigner un trs grand
nombre et une trs grande varit de besoins exprims par les parties prenantes. Mais pour
que lexploitation de ce gisement soit efficace, il doit imprativement tre organis de
manire pertinente. Avant daller plus loin concernant les stratgies applicables aux
exigences, tchons de dfinir ce quest cet lment atomique au chantier : lexigence.
4.2.1. Modle des exigences
Comme indiqu prcdemment, il existe trois niveaux dexigences : Stratgiques,
Fonctionnelles et Oprationnelles. Afin dorganiser le plus efficacement possible ces
exigences, il est primordial de les classer selon ces trois niveaux. Nous dcrierons plus loin les
caractristiques associes cette taxonomie.

Niveau dexigence Impacts
Exigences stratgiques Propres lindustrie
Exigences fonctionnelles Propres aux mtiers ; qualitatives
Exigences oprationnelles Propres lapplication ; quantitatives
Tableau 4-5 : Description des niveaux dexigences

En voici une le mta modle conforme la reprsentation UML
75
:


78
Exigence Partie prenante
1 0..*
Propose
1..* 1
Concerne Priorit
*
1
Possde
0..*
1..*
Compose
par
Corps
*
1
Dcrite par
Stratgique Applicative Oprationnelle
OR
Identifiant
Niveau
0..*
1..*
Raffin
par
1
*
Caractris par
1
*
Repre par

Figure 4-8 : Mta-modlisation des exigences

Attribut Rle Contenu
Exigence Nomme Le nom (titre <verbe> <cible> <manire>) de
lexigence
Identifiant Identifie Lidentifiant unique de lexigence
Niveau Caractrise Le niveau de lexigence (Stratgique, Applicatif ou
Oprationnel)
Auteur Propos par La partie prenante mettrice de lexigence
Partie(s) prenante(s) Concerne Les/les parties prenantes concernes par lexigence
Exigence(s)
parente(s)
Compose
une
La ou les exigences dun niveau suprieur (sauf si
niveau dexigence stratgique)
Exigence(s)
descendante(s)
Raffine par La ou les exigences descendantes dun mme niveau
Corps Dcrit par Le contenu descriptif (prose) de lexigence
Tableau 4-6 : Descriptif du mta modle des exigences

Les exigences sont toujours spcifies et rdiges par une partie prenante. Elle doit possder
un identifiant unique, ou un texte format explicitant son action et un texte en prose
commentant cette dernire. De plus, chaque exigence peut possder 0 n exigences
parentes, et 0 n exigences enfantes.

: 4 parties prenantes ont t identifies dans le cadre du projet Platine et ont donc t
invites abonder le gisement dexigences associ au chantier :
La matrise duvre du produit (Skill Center Mdiation Platine)
Les ergonomes
Les intgrateurs
Et bien sr les utilisateurs du produit, qui sont diviss en deux mtiers :
Simon Joliet

79
Les experts mtiers
Les exploitants

Concernant les utilisateurs, deux instances dexploitation du produit ont ts sonds.
Lexploitant DECI supervise la production de toutes les instances France du produit (quatre
instances techniques, fixe et mobile et temps rel), ainsi que lexploitant Sonatel qui
supervise les instances du groupe au Sngal, pour le compte des clients du groupe en
Afrique de louest (Sngal, Guine Bissau, Guine Conakry et Cte dIvoire).

Voir en annexe 6.6 Extrait du gisement dexigences en page 117.

Le mta-modle UML des exigences propose de lier chaque exigence une autre de niveau
infrieur ou suprieur, de la manire suivante :

Figure 4-9 : Exemple de taxonomie des exigences

Dans cet exemple, on voit que les exigences stratgiques E1 et E2 sont supportes par au
moins une exigence fonctionnelle, elles-mmes supporte par une plusieurs exigences
oprationnelles.

A titre dillustration : lexigence stratgique E2 est Introduire un nouvel argument
commercial au systme X , qui se traduit par lexigence fonctionnelle E5 Amliorer la
connectivit avec le systme Y , encore une fois traduit par une exigence oprationnelle
Introduire un connecteur applicatif type Z . Si lobjectif du chantier change et lexigence
E2 nest plus lordre du jour, les exigences E5 et E8 seront de fait limines du chantier.
4.2.2. Exigences Stratgiques (propres lindustrie)
Ces exigences sont conditionnes par le modle de lorganisation. Elles fixent un spectre trs
large au projet. Dans le cas de lexploitabilit dun systme, il peut sagir par exemple
dobtenir de nouveaux marchs, de satisfaire les utilisateurs, doptimiser lactivit dun
mtier. Dans ces exemples, de telles exigences ne peuvent tre satisfaites que si certaines
exigences qualitatives (fonctionnelles) sont elles-mmes satisfaites. Encore une fois ces
exigences fonctionnelles se basent sur la mise en uvre dexigences oprationnelles.


80
Le Business Model dune organisation consiste en une mission stratgique, une vision et les
valeurs de cette dernire (Hearn D., 2009). Cette dfinition permet de dfinir et de
structurer des sous-stratgies, assemblables en processus mtiers, donc de niveau
fonctionnel. Dans les SI, et par effet de bord dans les projets SI, les produits et les processus
sont et doivent tre perus comme tant le support du business model et des exigences
stratgiques. Cela ncessite une modlisation de la stratgie dentreprise, oriente et
applique au projet dexploitabilit pour un systme donn.

Les exigences stratgiques doivent tre en phase avec la stratgie dentreprise. Le rle du
projet dexploitabilit consiste donc traduire ces exigences stratgiques en fonctions, puis
les rendre oprationnelles. Ce mcanisme est appliqu aux exigences afin daligner le produit
sur la stratgie de lorganisation.

: Dans le projet Platine, le service daccueil est aussi diteur de solution et propose ainsi
ses exigences stratgiques.
4.2.2.1. Dtermination des exigences stratgiques partir dun
business model
Cette stratgie consiste connecter directement le projet au Business Model de
lorganisation. Elle implique une connaissance forte du systme sur lequel le projet porte,
mais aussi sur lorganisation elle-mme.

: Exemple dans le cadre du projet Platine, au sein de lentreprise France
Tlcom/Orange :

La stratgie actuelle du groupe consiste en quatre grands axes, visant mettre en valeur :
Les femmes et les hommes dOrange,
Les rseaux,
Les clients,
Le dveloppement international.

Pour le projet Platine, la rflexion dirigeant le renouveau de lexploitabilit est avant tout
motive par lacquisition de nouveaux marchs internationaux, la dcouverte de nouvelles
applications au systme type M2M et la satisfaction des utilisateurs actuels du systme. Le
projet est donc directement connect aux stratgies dentreprise mettant en valeur le
dveloppement international, ainsi que les utilisateurs de la solution au sein du groupe
France Tlcom /Orange.

Dans ce projet, le choix de partir des exigences stratgiques pour dterminer les exigences
fonctionnelles et oprationnelles (approche Top-Down), na cependant pas t retenu. La
richesse de lorganisation en effet, mais aussi des mtiers exploitant le produit est trop
complexe pour rendre cette approche rapidement efficace.
4.2.3. Exigences Fonctionnelles (propres aux mtiers)
Simon Joliet

81
Les exigences fonctionnelles portent globalement sur les aspects qualitatifs des systmes, ou
en tout cas tous les points ne pouvant tre directement oprationnaliss mais ntant pas de
niveau stratgique. Ces aspects qualitatifs peuvent servir llaboration dindicateurs de
performance cl (KPI
76
).

Il est possible de dterminer les exigences stratgiques partir des exigences fonctionnelles.
Au lieu danalyser les perspectives damlioration en alignant les ingnieries de projet et de
produit au business model (approche Top-Down), une autre approche consiste dterminer
les exigences stratgiques au travers des exigences fonctionnelles (approche Bottom-Up).

Dans cette optique, la stratgie dentreprise nimpacte le produit que par le biais des
exigences fonctionnelles exprimes par le mtier et les autres parties prenantes. Ce sont les
qualits et les comportements voulus par ces parties prenantes pour ce systme qui fixent les
directives du projet et ces mmes qualits doivent ensuite trouver justification auprs de la
stratgie dentreprise. Cette stratgie Bottom-Up consiste dterminer les corrlations des
exigences oprationnelles par un processus de clustrisations. Une telle stratgie est
privilgier sur les projets trs impactants et les organisations complexes.

: Dans le cadre du projet Platine, cest cette stratgie qui aura t mise en place.
4.2.4. Exigences Oprationnelles (propres au systme)
Les exigences oprationnelles sont le niveau le plus bas atomique des exigences. Une
exigence oprationnelle pourrait tre directement implantable sur le systme courant, mais
dans la mthodologie propose, ces exigences de bas niveau doivent imprativement tre
connectes des exigences fonctionnelles elles-mmes connectes des exigences
stratgiques, afin que chaque oprationnalisation permette de participer la concrtisation
des objectifs stratgiques du chantier.

Comme expliqu prcdemment, une exigence orpheline na pas lieu dtre prise en
considration dans les cycles incrmentaux si elle ne participe pas des exigences de plus
haut niveau. Elle doit donc tre limine moins que de nouvelles exigences fonctionnelles
soient dcouvertes. Les exigences oprationnelles peuvent facilement tre conceptualises
dans des macro-designs, elles sont donc de fait la base du chantier.
4.2.5. Recueil des exigences
Le mta-modle ci-aprs nous permet dobtenir un canevas formalisant les exigences que
nous dfinirons au cours de notre tude. Mais si ce-mta-modle convient la structuration
de linformation, ce nest pas forcment le cas pour la captation de cette dernire. Or dans
lapproche Bottom-Up, il est ncessaire de recueillir les exigences des parties prenantes,
structures par un canevas (ou dun backlog SCRUM). Il est ncessaire dexcuter le mta-
modle afin dobtenir un formulaire de recueil dexigences.


82
La mthode EKD-CMM (Nurcan et al, 2003) permet de lancer le chantier du changement.
Elle se base pour cela sur des modles de buts de transitions, oprationnaliss par les 5 verbes
dactions suivants : maintenir, cesser, amliorer, introduire, et tendre.

Dvelopper des scnarios de transition est un enjeu important pour la mthode qui est
toujours base sur un systme en ltat (AS-IS). Ces 5 verbes daction pourraient tre utiles
dans le recueil des exigences oprationnelles auprs des parties prenantes. Il convient
dtendre le modle des exigences oprationnelles afin dintgrer ces 5 oprateurs :

Exigence
AND/OR
Oprationnelle Oprateur
1 1..*
Maintenir Cesser Introduire Amliorer Etendre
0..*
1..*
0..* 0..* 0..*
0..*

Figure 4-10 : Mta-modlisation des exigences oprationnelles et des 5 oprateurs du changement

Exigence Nomme Le nom (titre <verbe> <cible> <manire>) de lexigence
Oprationnelle Dtermine Niveau dexigence pouvant tre mise en uvre sans
exigence enfant
Oprateur Caractrise Verbe du changement formalisant laction effectuer par
rapport une entit
Maintenir Conditionne Entit du systme en ltat conserver
Cesser Conditionne Entit du systme en ltat retirer
Amliorer Conditionne Entit du systme en ltat amliorer
Introduire Conditionne Entit du systme en ltat ajouter
tendre Conditionne Entit du systme en ltat dont le champ daction doit
tre augment
Tableau 4-7 : Descriptif du mta-modle des exigences oprationnelles

Ds lors, nous concluons que dans le cadre de la rcolte des exigences oprationnelles, il sera
fondamental dans un premier temps de comprendre ce que les parties prenantes veulent
maintenir, cesser, amliorer, introduire, et enfin tendre.

Simon Joliet

83
Encore une fois, le mta-modle est un cadre la structuration de nos donnes, mais il ne
permet en aucun cas la collecte. En effet dans le processus Bottom-Up, il est ncessaire de
dfinir un canevas permettant le recueil et le stockage du gisement dexigences. La
constitution et lutilisation dun canevas de recueil dexigences na de raison dtre
logiquement que dans loptique dune approche Bottom-Up (Stratgie S2). Dans lapproche
Top-Down, la premire itration du modle nimplique pas la collecte des exigences auprs
des parties prenantes ; lutilisation dun outil nest donc ncessaire que pour stocker et
organiser les exigences dans ce cas.

Un des objectifs de la mthode est de faire labstraction de toute technique
dimplmentation. Il en va de mme pour loutil formalisant la collecte et le stockage du
gisement dexigences. Loutil ici nomm canevas peut prendre de nombreuses formes.
Une base de donnes de type Microsoft Access peut tre un outil performant et rapidement
oprationnalisable pour le dveloppement du canevas. Une fois le canevas dvelopp, celui-
ci peut tre diffus afin de servir efficacement de support la capture des exigences
oprationnelles et fonctionnelles auprs des parties prenantes.

: Dans le cas du projet Platine, le canevas a pris la forme dune feuille Excel formate
champs fixes. Il a t soumis la validation du service daccueil, qui a ensuite t la premire
partie prenante contributrice. Ce canevas a ensuite t prsent aux utilisateurs finaux, puis
des ergonomes de profession.

Nous avons pu constituer grce la premire itration de cette mthode, un gisement de
124 exigences constitues de :
7 exigences stratgiques
30 exigences fonctionnelles
88 exigences oprationnelles

Par rapport aux verbes de transition, ces exigences se composent de :
10 Maintenir
68 Introduire
34 Amliorer
4 tendre
8 Cesser

Le canevas, doit tre considr comme un contenant. Le contenu est lensemble des
exigences recueillies par loutil jusquau dclenchement du trigger (nombre dexigences
suffisantes pour le dclenchement du premier incrment, deadline atteinte, ressources de
projet puises).

Dans SCRUM, le recueil est ralis au sein du backlog, qui nest quune liste dexigences,
faiblement organise et sans vritable structure moins dutiliser des outils avancs tels que

84
iceScrum (Aubry C., 2011). Preuve tant que les stories, lments de base de ce recueil, sont
consignes bien souvent laide de fiches bristol ou encore de Post-It. Daprs Aubry, le fait
de ne pas utiliser loutil informatique devient trs vite un problme. Dans la mthodologie
propose, le stockage et la gestion du gisement dexigences sera systmatiquement
informatis.
4.3. Scnario
4.3.1. Thorie sur les scnarios
La conceptualisation des exigences oprationnelles est effectue laide de maquettes
embarquant un n macro-designs. Une maquette est une forme particulire de scnario
amliorant significativement la description, la porte et lexploration des interactions
homme-machine pour un systme donn. Les projets denvergure intgrent aujourdhui
presque systmatiquement cette dmarche dans leurs dveloppements. Elle permet en effet
une exhaustivit difficilement atteignable par dautres moyens. La mthode est de plus trs
efficace dans la dcouverte de certaines attentes ou de comportements tacites dun systme
par ses parties prenantes.

Il apparait vident pour les besoins du chantier de comprendre comment ces maquettes
doivent tre construites, tout en mettant en vidence leur pertinence. La suite du chantier
sarticule en effet autour de lapproche dirige par les scnarios (Rolland et al., 1999). Le
projet CREWS
77
a mis en place un cadre de classification de diffrentes approches diriges
par les scnarios. En effet le volet dexploitabilit concentre lintgralit des interactions
homme-machine. Ceci fait de lapproche par scnario une tape cl de lingnierie des
exigences pour un tel chantier. Il est donc important de pouvoir dterminer de quelle
manire et sur quels aspects ces approches pourront interagir avec le dveloppement.

Le CREWS propose une mthode permettant de classifier des scnarios selon 4 dimensions,
dtermines comme tant les plus pertinentes. Elle propose ainsi doffrir une structure
commune aux formalismes dune majorit des types dapproches diriges par les scnarios
existants. Les auteurs notent ainsi les concepts de forme, de contenu, de but et de dure de vie.

La forme est la manire dont est exprim un scnario. Elle peut tre dcrite de
manire formelle ou informelle et prendre diffrentes aspects : texte, image, dessin,
vido, animation
Le contenu est lexpression du scnario en soi. Il contient lexpression de la
connaissance dudit scnario. Cette expression peut tre concrte ou abstraite.
Simon Joliet

85
Le but reprsente la fin du scnario face un problme rencontr ou une fonction
dun systme. Il peut exprimer des alternatives ou montrer des dfauts.
La dure de vie stipule lvolution du scnario au cours du temps. Un scnario est vu
comme un artefact pouvant tre cr, affin ou supprim. Cette vue oppose
notamment les caractres persistants et transitoires.

Toutes ces caractristiques ne seront pas forcment pertinentes pour lensemble des
chantiers dexploitabilit, la prise en considration de certains lments au profit dautres
devra tre nanmoins argumente.
4.3.2. Modles de scnarios
En se basant sur notre contexte o les scnarios sont une reprsentation dune exigence
oprationnelle et sur lanalyse des diffrentes approches diriges par les scnarios du
CREWS, nous pouvons reprsenter le mta modle des scnarios tels quutilis au sein de
notre mthode.

Le modle dfini par le CREWS a cependant t tendu afin dintgrer la notion dexigence.
Un scnario possde en effet un but, mais aussi une n exigences oprationnelles. Ces
exigences dfinissent un scnario. Sont ajoutes ensuite les macro-designs qui sont lentit
atomique dune maquette, conceptualisant une ou plusieurs exigences oprationnelles.

Figure 4-11 : Mta-modlisation du scnario


86
Scnario Modlise Aspect fonctionnel du
scnario
Contenu Dcrit par Le corps du scnario
Dure de vie Valide pendant La dure de validit du
scnario
Forme Dfini par La forme, support physique
du scnario
Macro Design Conceptualise Scnario unitaire
embarquant une n exigence
Maquette Compile Compilation de macro-
designs sur un mme
support
But Possde Le rle dun scnario, la
fonctionnalit reprsente
Partie prenante Propose/Valide Entit validant le scnario
(via la prsentation dune
maquette)
Dveloppeur Rdige Entit mettant en place les
scnarii
Tableau 4-8 : Descriptif du mta modle des scnarios
4.3.3. Processus de rdaction du scnario
Lentit scnario aillant t dfinie, il faut prsent expliciter le processus permettant de
passer dun cluster dexigences oprationnelles un macro-design (un scnario),
conceptualisant des principes fonctionnels exprims par les parties prenantes.

Figure 4-12 : Processus de rdaction du scnario
Simon Joliet

87

Nom Processus dcriture du scnario
But crire un scnario permettant de conceptualiser une plusieurs exigences
fonctionnelles du gisement
Entre Exigences oprationnelles valides
Sortie Scnario oprationnel
Intentions

i6.1 : Agrger les exigences
i6.2 : crire un scnario
Stratgies S6.1 : Par extraction dexigences
S6.4 : Par rcriture
S6.6 : Par cluster
Tableau 4-9 : Description de la stratgie S6 : Par rdaction du scnario
4.3.4. Macro-design
4.3.5. Maquette
Une maquette est un regroupement de macro design au sein dune IHM complte, pouvant
servir de support la communication lors des runions SCRUM o sont ralise la
prsentation et la validation de ces maquettes. Les maquettes sont lquivalent des stories
SCRUM ; elles sont les axes de travaux dun sprint embarquant un certain nombre de points
du backlog (Aubry C., 2011).

: Pour le projet Platine, les maquettes sont ralises en deux temps. Une premire
itration permet de valider les principes fonctionnels en utilisant une maquette type
Wireframe (voir 6.8 Exemple de maquette fil de fer en page 120). Si validation de ces
principes, les maquettes taient rinterprts par les ergonomes du chantier, ou les
interactions et les scnarios taient mis en lumire (voir 6.9 Exemple de maquette
ergonomique en page 121).
4.3.6. Macro-validation du scnario par les parties prenantes
Les macro-validations des scnarios se font lors des runions Agiles. Dans ce cadre, des
maquettes embarquant une plusieurs exigences oprationnelles sont prsentes aux parties
prenantes. Le rle du ScrumMaster doit tre de prsenter les concepts lis aux diffrents
macro-designs composant ces maquettes, qui seront valids ou non par les parties prenantes.
Un scnario non valid peut conduire une rcriture de ce dernier, puis un nouveau
passage en validation au sein dun nouveau sprint SCRUM.

Un scnario valid signifie que linterprtation fonctionnelle dune ou plusieurs exigences
est cohrente pour une majorit des parties prenantes. Elle peut ds lors tre
oprationnalise. Pour ce faire, le scnario doit tre transform en macro-cahier des charges.

88
4.4. Macro Dveloppement
Un macro-dveloppement (ou brique applicative) correspond la mise en uvre technique
dun macro-design, embarquant donc une n exigences. Une brique applicative est
dveloppe laide dun socle technologique dtermin par ltat de lart.
4.4.1. Modle du Macro Dveloppement
Tout ou partie dune maquette valide par les parties prenantes sert ds lors de base au
processus de macro dveloppement (ou doprationnalisation). En loccurrence, chaque
Macro design packag au sein dune maquette dfini un macro dveloppement. Ces macro-
dveloppements utilisent une technologie spcifie par ltat de lart.

Figure 4-13 : Mta-modlisation du macro-dveloppement

Macro-design Dfini Entit qui, valide, motive
un macro-dveloppement
Macro-dveloppement Fonctionnalise Laspect fonctionnel du
macro-dveloppement
Corps Oprationnalise Laspect technique du
macro-dveloppement
Technologie Utilise La technologie servant de
base au macro-
dveloppement
Partie Prenante Valide Entit validant le scnario
(via la prsentation dune
maquette)
Dveloppeur Dveloppe Entit mettant en place les
scnarii
Simon Joliet

89
Tableau 4-10 : Descriptif du mta modle des macro-dveloppements
4.4.2. Processus de Macro-Dveloppement
Le processus de macro dveloppement doit se reposer sur la validation dun scnario (ou
dune maquette). Lorsque la validation est effective, le prochain sprint sera loccasion de
dvelopper une brique logicielle rpondant lexigence embarque dans le scnario valid.
Cette brique sera ensuite teste et en cas de validation fonctionnelle, prsente lors de la
prochaine runion.

Figure 4-14 Processus de macro dveloppement

Nom Processus de Macro Dveloppement
Rle Dvelopper une brique fonctionnelle permettant de prototyper un scnario
pralablement valid par les parties prenantes
Entre Macro Design valid
Sortie Brique fonctionnelle valide
Intentions

i9.1 : Dvelopper
i9.2 : Tester
Stratgies S9.1 : Par validation du scnario
S9.2 : Par rutilisation
S9.3 : Par fin de dveloppement
S9.4 : Par nouveau testeur
S9.5 : Par validation fonctionnelle
S9.6 : Par invalidation du dveloppement
Tableau 4-11 : Description de la stratgie S9 : Par macro dveloppement
4.4.3. Macro-validation de la brique applicative
Le dernier jour dun sprint, les travaux raliss sont prsents un maximum de parties
prenantes et potentiellement des invits. Les tches accomplies sont unitairement
approuves ou dsapprouves par les parties prenantes, de sorte que le tir puisse
systmatiquement tre corrig ds le sprint suivant. La macro-validation se fait donc de
manire collgiale (Aubry C., 2011).

90
4.5. Prototypage
Le prototypage est incrmental. Il se construit donc brique par brique mesure que les
cycles incrmentaux se suivent. Il nexiste donc pas de phase de prototypage en soit, puisque
ce dernier nest finalement que la compilation de tous les macros-dveloppements effectus,
puis valids par les parties prenantes.

: Dans le cas du projet Platine cest la dernire intention de la mthode propose qui a pu
tre mise en uvre.

Simon Joliet

91
4.6. Industrialisation
Lorsque le prototype est jug assez mature, par exemple si ce dernier satisfait suffisamment
dexigences, ou si le dlai voir si les ressources imposent le passage en industrialisation, le
prototype doit tre valid. Un prototype valid, cest une base capitalise de fonctionnalits
valides, oprationnelles sur un primtre restreint.

: Dans le cas du projet Platine, ltape dindustrialisation est prvue pour dbut 2013, soit
suite la livraison finale du prototype. La suite de cette approche est aborde de manire
thorique dans la mesure o aucune validation empirique na pu tre mise en place.
4.6.1. Modles de lindustrialisation
Comme nous lavions dfini, le prototype est compos de 1 n macro dveloppements
valids par les parties prenantes. Lorsque le prototype est jug suffisamment mature, celui-ci
est valid ou invalid dans son ensemble (voir MAP globale), afin de servir de base
supportant le systme cible (TO-BE). Nous modliserons donc cela de la manire suivante :

Figure 4-15 : Mta modlisation de lindustrialisation

Macro Dveloppement Est compos de Motive le prototype
Prototype Conceptualise Base du systme cible
Systme TOBE Finalise Le systme cible du chantier
Partie Prenante Valide Valide le ou les prototypes
ainsi que le systme cible
Dveloppeur Dveloppe Dveloppe le ou les
prototypes ainsi que le
systme cible
Tableau 4-12 : Descriptif du mta modle de lindustrialisation

92
4.7. Nouvelles exigences oprationnelles
La validation du prototype, comme la validation dune maquette ou dune manire gnrale,
lors de tout point formel et informel, est loccasion dajouter de nouvelles exigences au
gisement. Le rle du prototype est en effet de concrtiser les exigences fonctionnelles en
conceptualisant un certain nombre dexigences oprationnelles. Le systme cible pourra
ainsi bnficier de la base capitalise que constituent les incrments du prototype, tout en
apportant de nouvelles exigences sur un primtre plus large cette fois.
Simon Joliet

93
5. VALUATION ET CONCLUSION
5.1. valuation empirique
Tous les processus de la mthode ayant t explicits en dtail, lheure est au bilan pour cette
dernire partie. La mise en uvre in situ de la mthode aura permis de revoir certains points
qui se seraient montrs perfectibles. Par exemple le canevas de recueil des exigences qui a t
deux fois rvalu lorsque des champs manquaient, ce qui a conduit lvolution du mta-
modle. Un autre heurt vient du fait que certaines parties prenantes ont t intgres aprs
le dmarrage des cycles de projet, ce qui peut potentiellement remettre en cause les travaux
prliminaires. Dans le cadre du projet Platine, la mthodologie aura prouv sa robustesse
puisquelle a pu efficacement intgrer deux parties prenantes majeures alors mme que le
projet tait enclench depuis plusieurs mois (il sagit en loccurrence des ergonomes et de
linstance dexploitation du Sngal).

Il est en effet assez difficile de formaliser lensemble dune ingnierie de projet avant le
dmarrage du projet lui-mme. Cest dautant plus vrai lorsque la cible et les parties
prenantes ne sont pas encore totalement identifies linitialisation du projet. Il est de plus
trs dlicat de diriger tout un projet sans visibilit globale ni objectifs initiaux dfinis.
Pourtant le fait de travailler avec ces lments atomiques que sont les exigences, permet
chaque instant de juger de la maturit du projet et si la piste actuelle est bonne ou mauvaise,
tout en pouvant rapidement ragir lajout ou la suppression dentits au projet. Enfin, il
ne faut pas perdre de vue que proposer une mthode gnrique nest pas toujours la
meilleure solution puisque chaque projet est unique et quune mthode doit sadapter aux
spcificits dun projet et non linverse.

Dun point de vue purement pragmatique, le bienfond de la mthodologie propose ici
pour ce projet particulier apparat comme vident. Gageons que cette dernire reste
rutilisable et adaptable dautres domaines de la supervision et de lexploitabilit des
systmes, ce qui na pas pu tre mis en place. Le formalisme impos par une telle approche
peut tre peru comme problmatique. Dans les faits, quand il sagit de projets aussi
impactant que ceux de lexploitabilit des systmes, ce formalisme est loin dtre un luxe. De
plus linertie de la mthode impose par ces processus permet de soigner les pr-tudes et
dtre rapidement performant et pertinent auprs des parties prenantes au projet.

Pour visualiser clairement ce qui aura pu tre mis en place au sein du chantier, il est propos
de projeter les activits ralises sur la Map globale du projet.

94

Figure 5-1 : valuation empirique ; Map relle

Comme le montre la Map ci-dessus, seules 9 stratgies sur les 15 proposes par cette
mthode ont pu tre mises en place au sein du projet. Concernant les intentions, 3 ont t
ralises sur les 5 de la mthode. Cela limite bien entendu la validation de cette dernire un
certain primtre. Pourtant, la dure totale du projet tant estime 36 mois pour
lindustrialisation de linstance France, de tels rsultats en 6 mois le recueil des exigences
effectu par le dclenchement de la stratgie S2 a en effet dbut fin fvrier 2012
apparaissent comme clairement encourageants pour la poursuite du chantier. Passons
maintenant une valuation objective base sur les retours des parties prenantes au projet
sur la mthodologie mise en uvre.
Simon Joliet

95
5.2. valuation par les parties prenantes
Afin de qualifier la pertinence de la mthode pour guider le chantier de lexploitabilit, mais
dun point de vue objectif cette fois, il est propos dvaluer les retours des parties prenantes
au projet fin de parcours. Cette valuation a t ralise laide dun questionnaire envoy
22 des parties prenantes au projet, parmi lesquelles 9 ont rpondu. Le questionnaire
comporte 12 questions et est joint en annexe (voir 6.13 Questionnaire dvaluation Parties
Prenantes en page 126). La structure utilise prsente une caractristique intressante, elle
est en fait base sur le mme formalisme que celui utilis pour le recueil des exigences (et
donc est supporte par les 5 oprateurs cls, Amliorer, Introduire, Cesser, tendre et
Maintenir) Voici une synthse sur les retours.

Q1 : Pensez-vous que cette mthode est plus mme de guider un chantier IHM quune
expression de besoin initiale, suivi du cycle de dveloppement classique (ingnierie de
projet) ?

Rponse Dcompte Pourcentage

Pas du tout 1 11,11%

Un peu 0 0,00%

Moyennement 4 44,44%

Beaucoup 4 44,44%

Selon les parties prenantes, la mthode sest montre trs pertinente dans le chantier des
IHM pour 44% (4) des sonds, assez pertinente pour 44% (4) et pas du tout pour 11% (1).
Cest un rsultat globalement satisfaisant bien quil semble que la mthode puisse tre
amliore.

Q2 : Selon vous, a-t-il t pertinent de communiquer rgulirement sur lavancement du
projet ?


Oui 9 100,00%

Parfois 0 0,00%

Non 0 0,00%

Sans rponse 0 0,00%

11%
0%
45%
44%
Pas du tout Un peu Moyennement Beaucoup
100%
0% 0% 0%
Oui Parfois Non Sans rponse

96

Il a t dcid pour ce projet de communiquer le plus possible et avec un maximum
dacteurs, ce de manire rgulire. Pour 100% (9) des parties prenantes, ceci est une bonne
approche.

: Le concept dimpliquer rgulirement et un maximum de parties prenantes doit donc
tre retenu dans la mthode.

Q3 : Pensez-vous que dans lensemble, le fait de se baser sur les exigences pour piloter le
projet a apport une plus-value ?


Oui 5 55,55%

Parfois 4 44,44%

Non 0 0,00%

Sans rponse 0 0,00%

A la question de la pertinence dutiliser les exigences comme pilote du projet, les rsultats
sont partags puisque 55% (5) des parties prenantes estiment que cela a toujours t
pertinent, quand 44% (4) estiment que cela a parfois t pertinent. Note : aucune partie
prenante nestime que cela na jamais t pertinent.

Q4 : Est-ce que la structure utilise pour la tenue des runions (prsentation des travaux
effectus, prsentation des travaux venir, ordre du jour, suivi des exigences) a t
pertinente ?


Trs pertinent 4 44,44%

Plutt pertinent 5 55,55%

Pas pertinent 0 0,00%

Sans rponse 0 0,00%

Les runions effectues dans le cadre du projet suivaient un canevas prcis. Les avis sont
partags entre les sonds puisque 55% (5) indiquent que ce canevas est trs pertinent quand
quasiment la mme proportion (4) indique que celui-ci est plutt pertinent. Un
commentaire indique de plus quil est parfois difficile de voir en cela la ralisation concrte
56%
44%
0%
0%
44%
56%
0% 0%
Trs pertinent Plutt pertinent
Pas pertinent Sans rponse
Simon Joliet

97
du projet. Il est de plus remarqu que les changements taient plus facilement accepts par
les utilisateurs dans la mesure o ces derniers taient impliqus aux dcisions.

: Pour la suite de la mthodologie, il semble primordial de conserver et damliorer ce
formalisme. Ensuite, laccent doit tre mis sur les dmonstrations afin de montrer des
ralisations concrtes autant que faire se peut.

Q5 : Selon vous, la dure des runions fixe 1 heure 30 est-elle suffisante, trop
importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?


Pas assez longue 0 0,00%
Bonne dure 9 100%
Trop longue 0 0,00%
Sans rponse 0 0,00%

La dure des runions a t fixe 1h30. Pour 100% (9) des parties prenantes, cette dure a
t juge comme suffisante. Un commentaire indique que cette dure est bien adapte au
nombre des participants (soit entre 10 et 20). Cette dure serait certainement revue la
hausse ou la baisse en fonction dune volution du nombre de participants.

: Pour la suite de la mthodologie, il faut privilgier une conservation de cette dure.

Q6 : Selon vous, la frquence des runions fixe 2 semaines est-elle suffisante, trop
importante ou pas assez importante ? Si trop ou pas assez, pourquoi ?


Trop
importante 0 0,00%
Satisfaisante 9 100%
Pas assez
importante 0 0,00%
Sans rponse 0 0,00%

La frquence des runions tait fixe deux semaines. Pour 100% (8) des parties prenantes,
cette frquence a t juge satisfaisante.

: Pour la suite de la mthodologie, il est donc dcid de conserver cette frquence.

0%
100%
0%0%
Pas assez longue Bonne dure
Troplongue Sans rponse
0%
100%
0%0%
Tropimportante Satisfaisante
Pas assez importante Sans rponse

98
Q7 : A votre avis, cette mthode pourrait tre pertinente dans dautres chantiers que celui
des IHM ?


Oui 6 66,67%
Parfois 2 22,22%
Non 1 11,11%
Sans rponse 0 0,00%

Un point cl de la mthode propose est de pouvoir piloter les chantiers de lexploitabilit,
c'est--dire pas seulement la conduite dun chantier de renouveau dIHM, mais aussi pour
tout projet attenant aux stratgies de supervision et dexploitation dun systme. Il a ainsi t
demand aux parties prenantes dvaluer la gnricit de cette mthode. Pour 66% (6) des
sonds, cette mthode aurait dune part un intrt tre utilise dans un autre contexte.
Pour 22% (2) des sonds, la mthode pourrait parfois avoir un intrt dans dautres
contextes. Enfin, pour 11% (1) des sonds, cette mthode napporterait pas de plus-value
dans dautres cas que ce chantier.

Q8 : Selon vous, que faut-il absolument maintenir dans la mthode ?

Selon les sonds, un certain nombre de points doivent tre conservs dans la mthode mise
en uvre. Majoritairement, cest le dialogue rgulier entre concepteur et utilisateur qui est
plbiscit. Le fait de se baser sur les exigences et de produire un prototype de manire
itrative sont tous deux vus comme des concepts phares la mthode, conserver.

Q9 : Selon vous, que faut-il absolument amliorer dans la mthode ?

Pour les sonds, un certain nombre de points doivent tre amliores. Tout dabord, la
priorisation des exigences na pas t perue par tous. Ensuite, une demande davoir
systmatiquement une maquette par choix conceptuel a t formule. Enfin, certains sonds
souhaiteraient arriver plus rapidement un prototype quand dautres dsireraient que les
utilisateurs soient associes au projet encore plus tt.

Q10 : Selon vous, que faut-il absolument introduire dans la mthode ?

Selon certaines parties prenantes, il semblerait utile de mettre en corrlation les propositions
fonctionnelles formules lors de la mise en uvre conceptuelle, avec de vritables donnes
de production.
67%
22%
11%
0%
Simon Joliet

99
Q11 : Selon vous, que faut-il absolument cesser (supprimer) dans la mthode ?

Pour certaines parties prenantes, il faudrait cesser de prsenter des concepts (maquettes ou
dveloppements) tant quils ne sont pas mrs. Un autre point consisterait ne pas expliquer
la mthode utilise aux parties prenantes si celle-ci est complexe, comme cela aura parfois t
peru.

Q12 : Selon vous, avec quelles autres mthodes celle-ci devrait tre tendue ?

Il est propos par les parties prenantes de coupler la mthode par une analyse des impacts et
des carts sur lexistant. Dautres parties prenantes souhaiteraient que lanalyse des exigences
soit couple une analyse des besoins.

Lvaluation de la mthode par les utilisateurs sonds retourne globalement un bon niveau
dadhrence de leurs parts. Il existe bien sr quelques heurts rendant la mthode perfectible
aux yeux des intervenants, mais les avantages quelle aura procur pour ce projet lui sont en
grande partie reconnus. Du reste de tels retours sont trs positifs ; gageons de surcrot quil
est difficile dvaluer une mthode utilise partie.

100

5.3. Bilan et perspectives
Si la mthodologie propose a pu guider efficacement le projet, il serait trs intressant dun
point de vue pragmatique de suivre cette dernire de bout en bout pour lensemble du projet
et pas seulement pour une partie. La dmarche dirige par les exigences et le fait de produire
un grand nombre de livrables intermdiaires est un atout considrable apport par la
mthode. Dans le cadre des chantiers importants o le processus de capitalisation de
connaissances nest pas ngligeable, le fait de possder un gisement dexigences unique et de
consigner lensemble des maquettes et des scnarios facilite le commissionnement et le
dcommissionnement de ressources, le tout moindre cot. De plus, la runion de fin de
sprint permet rapidement des parties prenantes non inities au projet de comprendre trs
rapidement les enjeux de lensemble du chantier, le tout en peu de temps.

Toujours par rapport cette mthodologie, le fait de la rendre compatible avec SCRUM
offre de nombreux avantages, dont le plus important est en toute franchise, lutilisation
dune mthode populaire et reconnue dans lindustrie. Il est pourtant primordial de ne pas
cder aux sirnes de la SCRUMmania ; SCRUM est dabord tout sauf une panace. Ensuite,
les mthodes Agiles ne sont pas synonymes de dveloppements bcls, de documentation
inexistante et de rentabilit maximum. Cest un outil proche du lean management certes, o
la notion de qualit est fondamentale. Il est quoi quil en soit dlicat dappliquer SCRUM
dans une organisation ayant recours uniquement aux mthodes classiques, dans ce cas la
mise en place dun chantier pilote savre souvent tre une bonne approche.

Un problme inhrent aux mthodes Agiles, est quil nest pas toujours vident de
communiquer sur un produit en cours de ralisation. Les mthodes classiques nimposent
des points de synchronisation sur lavancement qu certains moments cls comme les
passages de jalons, ou encore la livraison finale du produit. Sil est communment admis
que le fait de prsenter un produit uniquement avant sa livraison est une mauvaise pratique,
il nest pas non plus vident dutiliser un produit en cours de ralisation comme support de
prsentation. Il peut exister une incomprhension de la part des parties prenantes, cest
pourquoi il est primordial de toujours rappeler lors des runions de sprint que les travaux
prsents sont partiels et que les autres aspects fonctionnels seront oprationnaliss
ultrieurement.

Un des avantages majeurs de SCRUM qui contribue dailleurs trs certainement sa
grande popularit, est justement le fait de nimposer finalement que trs peu de formalisme.
Il sagit en fait dun simple framework qui impose un pattern de processus respecter, mais
qui en soi nimpose aucune contrainte sur le processus en lui-mme, ni sur les objets
manipuls par ce processus (comme les backlog ou les stories). De fait, il est tout fait
possible que deux projets appliquant SCRUM la lettre en aient une approche finalement
trs diffrente, ce qui est plutt positif quant la flexibilit potentielle par rapport aux
projets. Il serait tout de mme intressant douvrir le processus de conduite du chantier
Simon Joliet

101
dautres mthodes Agiles telles que XP ou encore RUP, et de faire finalement labstraction
de la mthode retenue, linstar de la technologie.

Ensuite, la mthode ayant t mise en pratique pour conduire un chantier de renouveau
dIHM, il serait intressant dobserver dans quelle mesure cette dernire serait pertinente
dans dautres contextes dexploitation, encore une fois dans le cadre dune dmarche
empirique.

102
5.4. Conclusion
Les solutions proposes, tant sur le volet moyens via ltat de lart que sur la partie
mthode, se sont donc rvls performantes pour piloter le chantier de renouveau dIHM
sur un primtre circonscrit. Concernant la partie moyens, celle-ci bien quexhaustive,
pourrait tre tendue dautres types de progiciels dune part, et dautres paradigmes du
gnie logiciel. Bien entendu cette mthode comme toute mthode reste perfectible. Une
seule mise en pratique de cette dernire ne semble cependant pas suffisante pour tirer de
conclusion gnrale, dautant que lensemble des stratgies de cette dernire nont pas pu
tre mises en place. Dune manire gnrale, il est important de noter que lutilisation des
mthodes Agiles napporte pas toujours les meilleures rponses organisationnelles aux
structures.

En effet linstar de certaines mthodes Agiles, ce qui est propos ici nest quun cadre qui
devra tre adapt dans une optique de rutilisation aux spcificits dun autre projet. En
suivant cette considration, la mthode ne doit pas tre vue comme un processus formalis,
mais plutt comme un framework mthodologique permettant de piloter le chantier
spcifique de lexploitation. Les concepts mthodologiques ntant connects entre eux que
par le biais dartefacts de projets formalises, les diffrentes approches sont compltement
indpendantes les unes des autres. Elles peuvent ainsi tre remplaces souhait par dautres,
potentiellement plus pertinentes dans un autre contexte.

Ainsi et en guise de conclusion, ce mmoire aura permis de dmontrer quil est possible de
composer une mthode de conduite de projet sur mesure, base dingnierie des exigences et
dapproches diriges par les scnarios, le tout au sein de cycles Agiles. Les mthodes
communiquent entre elles par le biais des livrables quelles produisent et quelles
consomment, en abstraction complte des autres approches satellites. Le fait de coupler
diffrentes mthodes permet en cas de russite, de tirer parti efficacement des avantages de
chacune. En dcorellant moyens et mthodes, la solution propose enfin dapporter une
couche dabstraction garantissant la gnricit des solutions mises en uvre dans le cadre de
cette tude, autorisant de fait sa rutilisation.
Simon Joliet

103

104

6. ANNEXES
Il est propos au sein des annexes de suivre certains raisonnements dvelopps au sein du
projet IHM Platine titre dillustration de points particuliers, soulevs par la mise en
pratique de ltat de lart et de la mthodologie formalise prcdemment.
6.1. Rflexions sur la couche transactionnelle
Mesurer les contraintes lies au dialogue (entre le cur de produit, la passerelle SOAP et les
IHM actuelles) ; voir si cet lment serait impact ou non par le chantier.

Couche
dinterface
Couche
prsentation
Couche
mtier

Figure 6-1 : Architecture actuelle simplifie

Larchitecture actuelle autorise une communication efficace entre le cur de mtier et les
IHM. Cependant, le primtre du chantier impactant la prsentation des donnes, il peut
tre intressant dobserver si et dans quelle mesure, la couche dinterface actuelle pourrait
tre amliore. Limplantation actuelle possde certains dsavantages notamment sur ces
derniers points :

Les donnes sont rcupres la vole, directement au sein de la classe daffichage
des IHM. Il ny a pas dans les IHM de sparation entre la gestion du protocole et
celle de laffichage des donnes.
La smantique ncessaire pour envoyer des requtes au sein des IHM et pour
comprendre les rponses de la couche mtier est duplique entre les deux parties.
Les requtes envoyes et reues sont srialises par cette smantique sous un format
binaire via un mcanisme de srialisation propritaire, ce qui est vraisemblablement
un hritage de larchitecture historique Corba.
Les services transactionnels sont limits entre le mtier et la prsentation (une
dizaine seulement). Ces derniers sont de niveau technique et non mtier ou
fonctionnel. Les stratgies dextraction de linformation ne sont valables que pour
les IHM actuelles, les donnes tant remontes panneau par panneau.
Les changes sont soit synchrones (exploitation), soit asynchrones (supervision) et
les informations sont remontes la couche transactionnelle soit en mode pull
Simon Joliet

105
(pour les compteurs), soit en push (pour les notifications dtat de la couche mtier,
comme le dmarrage ou larrt du serveur de supervision).

La redfinition de cette couche dinterface impliquerait soit une urbanisation, soit une
sparation de la partie transactionnelle et de la partie prsentation des donnes.
Globalement, voici ce quil faut en retenir : lutilisateur, par le biais des IHM, affiche un
panneau. Le code de ce panneau implique la rception dinformations de la couche mtier.
La requte est srialise ct IHM et celle-ci est envoye la passerelle SOAP. Un identifiant
de requte est alors gnr, la requte srialise est ensuite envoye au mtier et lidentifiant
de requte est retourne aux IHM. Ceci est valable en mode asynchrone seulement.

Ct mtier, la requte est dsrialise, excute, puis le rsultat est de nouveau srialis et
envoy la passerelle. Celle-ci rceptionne la rponse et lassocie la session de lIHM ainsi
qu lidentifiant de la requte initiale. La rponse est stocke dans une pile en attendant
lappel de la couche de prsentation.

La couche de prsentation envoie des requtes la passerelle jusqu' ce quune rponse
associe lidentifiant de requte retourne un rsultat. La passerelle renvoie alors la rponse
mtier srialise, qui est ds lors dsrialise par les IHM, puis intgre aux lments
graphiques ct applet Java. Lchange est modlis par le diagramme de squence suivant.

Session
Couche de prsentation
:Applet Java
Couche transactionnelle
:Passerelle SOAP
Couche Mtier
:Base de donnes
mettre requte passerelle
Recevoir identifiant rponse
Emettre requte mtier
Recevoir rponse mtier
mettre requte passerelle
avec identifiant rponse
Excution requte mtier
Afficher panneau
Srialiser requte panneau
Dsrialiser requte mtier
Recevoir rponse
Dsrialiser rponse
Afficher rponse
Panneau affich
Srialiser rponse

Figure 6-2 : Diagramme de squence du dialogue IHM/Mtier actuel (dialogue asynchrone)

La communication est plutt lourde, mais ce nest pas vraiment un problme au niveau de la
performance de lensemble. Par contre, lasynchronisme et la ncessit de conserver les

106
identifiants de requte est potentiellement un mcanisme revoir en cas de modification de
la couche transactionnelle. Cette stratgie de dialogue nest pas sans possder quelques
avantages en cas de transaction longue (ce qui est souvent le cas), elle est de plus trs bien
adapte au multi-thread et surtout, elle ne bloque pas les appels client.

Cependant le point le plus problmatique sur cette partie protocolaire est les srialisations
et les dsrialisations successives, ncessaires lenvoi et la rception des requtes. Ce
formalisme est logiquement dupliqu ct prsentation (en Java) et ct Mtier (C++). Le
problme est que lajout par exemple, dun nouveau panneau de supervision ou dune
nouvelle fonction mtier implique systmatiquement ces deux modifications.

Les stratgies de dialogue entre les couches est extrmement pauvre. Si la robustesse de
lchange est certaine, la plus-value apporte par la solution et lvolutivit quelle autorise
est trop faible pour servir de base tout projet trs impactant. Ce point sera clairement un
problme pour toutes les volutions ciblant le mtier et les IHM.
6.1.1. Redfinition de la couche transactionnelle
Proposition darchitecture selon les bonnes pratiques de lurbanisation des systmes
(Longp C., 2009)

Figure 6-3 : Architecture cible urbanise

La meilleure solution en termes darchitecture consisterait ainsi redfinir non seulement la
couche de prsentation, mais aussi la couche dinterface (transactionnelle) associe. La
redfinition de la couche dinterface permettrait de faciliter le dveloppement de la couche
de prsentation. En effet actuellement, les transactions passent par un nombre limit de
services et la smantique est code en dur dans la couche mtier comme dans la couche
prsentation (par le biais du fichier synoptique.dat).

Il en rsulte une architecture certes efficace, mais peu maintenable. Une bonne solution
consisterait dfinir une couche dinterface exposant un certain nombre de services, tantt
spcialiss, tantt gnriques.

Cette nouvelle architecture impacterait fortement lexistant, notamment sur la partie
mtier. Si la refonte de la couche dinterface est une solution long terme, il nen demeure
pas moins que le cot de dveloppement de celle-ci ne sera pas ngligeable.

Meilleure solution en termes darchitecture
Dveloppement ultrieur facilit
Cot de dveloppement non ngligeable
Impacte potentiellement la couche mtier
Simon Joliet

107
Tableau 6-1 : Avantages et inconvnients dune nouvelle architecture fonctionnelle

6.1.2. Conservation en ltat de la couche transactionnelle
Voici une solution hybride, finalement retenue dans le cadre de la premire
oprationnalisation.

Figure 6-4 : Solution intermdiaire

Une solution intermdiaire consisterait laisser la couche dinterface en ltat et de
dvelopper une couche transactionnelle intermdiaire entre la couche dinterface et la
couche de prsentation. Lobjectif serait de pouvoir intgrer le modle de donnes
moindre effort au sein de la couche de prsentation.

Le remplacement ultrieur de la couche dinterface constituerait une tape cruciale pour la
prennit et la maintenance du produit. Le remplacement de cette couche transactionnelle
temporaire se ferait de fait moindre effort.

Rapidement oprationnalisable
Remplacement couche transactionnelle
Capitalisation faible sur dveloppement
Pauvret des informations disponibles
Tableau 6-2 : Avantages et inconvnients dune architecture fonctionnelle hybride
6.1.3. Conclusion des rflexions sur la couche transactionnelle
La manire et la smantique de remonte de linformation est certes efficace, mais
relativement pauvre et assez contraignante. La conservation de cette couche en ltat ne
serait pas sans poser problme dans la mesure o celle-ci ne prsente que peu de services et
en tout cas, aucun dintrt fonctionnel. Cela conviendrait dans un premier temps ; terme
il nest pas certain que toutes les informations ncessaires au chantier soient prsentes en
base. Dans ce cas une modification de la partie mtier serait potentiellement ncessaire pour
afficher toute information non prsente actuellement dans les IHM.

Le problme est que les modifications ct mtier sont dune part viter pour le prototype
et dune autre que dventuelles modifications perdraient en porte lors de la mise en uvre,
de par la pauvret de lchange mtier/interface. Garder en ltat cette couche de
communication nest pas une solution valable long terme. Mais sur les IHM, il est par
contre primordial de sparer les requtes mtier de leurs affichages dans les applets Java.

108
6.2. Rflexions sur la mise en place de maquettes
Dfinir des maquettes permettant de reprsenter linformation (Look) en se basant sur les
exigences de DECI, les solutions de supervision et dexploitation existantes et les bonnes
pratiques de lergonomie.

En intgrant les retours dtermins par les grands principes fonctionnels, lenjeu consiste
maintenant intgrer ces derniers principes afin de dterminer de nouvelles stratgies de
supervision sur lexistant.
6.2.1. Interface actuelle
Avant toute chose, voici un aperu de lorganisation des lments sur linterface de
supervision :

Figure 6-5 : Wireframe de linterface actuelle

C : Nom de la plateforme volet Heure courante (Fig) : affiche les informations
courantes de la plateforme actuelle.
C : Alarmes (Fig) : Contient trois options concernant les alarmes :
Alarmes : affiche toutes les alarmes du systme dans un nouvelle
fentre.
Voir fentres dalarmes : affiche la fentre dalarme.
Simon Joliet

109
Fermer fentre alarmes : ferme la fentre dalarme.
C : Commande et options (Fig) : Contient 5 commandes :
Couleur qui permet de changer la couleur de fond des IHM (afin de
reprer par exemple des supervisions dinstances diffrentes sur une mme
machine).
ECC Arbo qui permet de modifier la stratgie dorganisation des
arborescences.
Versions qui permet dafficher les versions des modules de lapplicatif.
Exploitation qui permet de passer de lIHM de supervision lIHM
dexploitation (fonctionne uniquement si lIHM dexploitation est dj
lance).
Quitter qui termine la session de supervision en cours.
C : Navigation (Fig) : reprsente actuellement le dcoupage de plus haut niveau du systme
(Platine, Mdiation active, Collecte). Les alarmes sont affiches en rouge sur
llment en dfaut et en orange sil sagit dune information.
C : Arborescence (Facultative) : reprsente la sous-arborescence si celle-ci existe, de
llment parent slectionn dans C.
: Vue : affiche les compteurs ou la vue courante spcifie par les lments C et C.
C : lments en anomalie (Dynamique) : recense les lments en anomalie hritant de
llment courant (C et C).

Actuellement, la navigation seffectue laide des lments C et C. Le contenu de
larborescence C dpend en effet de lentit Navigation C slectionn. Par contre,
larborescence nest pas toujours prsente. Pour certains lments en effet, llment C nest
pas prsent et est remplac par une plus grande vue . Du reste, linterface nest pas
homogne en fonction de llment slectionn dans la navigation C, ce qui doit cesser. [#3
#4]

En rgle gnrale, le zonage fonctionnel nest pas satisfaisant sur lexistant, par exemple via
certains lments regroupant des actions de niveau fonctionnels ingaux. Cest notamment
le cas de llment C avec la commande Couleur , ou encore llment C avec le
panneau Connexions . Ces deux lments ne sont pas par exemple dans une zone
cohrente au vu de leurs niveaux fonctionnels.
6.2.2. Interface projete
Lexercice propos est donc de prendre en compte les problmatiques des interfaces
actuelles, tout en rorganisant les lments en fonctions de leurs rles, niveaux fonctionnels
et stratgies dinteraction. Les lois de Gestalt et le principe de laffordance permettraient une
rorganisation efficace de linterface actuelle dun point de vue fonctionnel. Les
reprsentations ne tiennent pas compte de la mise en uvre ; celle-ci peut se faire bien
videmment indpendamment de la technologie retenue.

Voici titre illustratif, un zonage fonctionnel rpondant potentiellement ces derniers
critres :

110

Navigation
et
Arborescence
Vue
Alarmes
Informations et commandes gnrales
Onglets
Chemin

Figure 6-6 : Interface projete

C : Informations et commandes gnrales
Cet lment reprendrait les informations gnrales prsentes dans les interfaces
actuelles [#9]. Il devrait idalement prsenter les informations de connexion de lutilisateur,
les paramtres gnraux des interfaces ainsi que les stratgies daccs dautres ressources
(autres IHM, aide contextuelle [#34]), etc.

C : Navigation et arborescence
Il est ncessaire de conserver larborescence en ltat, ce qui est impos par les
exigences [#6 #103]. Cependant, il peut paratre intressant de fusionner les notions de
navigation et darborescence, qui sont actuellement fortement imbriques. La notion
dalarme doit tre apporte ce nouvel lment [#72] comme sur lexistant.

C : Onglets
Les onglets permettraient, en fonction du module slectionn dans llment C,
doffrir un point de vue diffrent (facette) en fonction de la supervision souhaite [#27
#119]. Le type donglet disponible est dpendant du rle de lutilisateur et de limplantation
faite par lintgrateur pour linstance [#44]. Les diffrentes facettes potentielles seront
dcrites dans le modle de donnes (chapitre 5).

C : Chemin
Cet lment fournirait une nouvelle stratgie daccs aux entits. En effet et
contrairement lexistant, il serait souhaitable que la navigation se fasse de diffrentes
manires, donc pas seulement laide de llment C [#3 #24].
Simon Joliet

111

C : Vue
Dans cette proposition, le vue serait fonction de la slection de llment C et de
llment C (les onglets). Celle-ci est de plus lie au chemin spcifi par C. Par rapport
lexistant, cet lment offrirait de plus grands niveaux dinteraction, comme par exemple
[#36]. Autre ajout, la possibilit davoir des vues paramtrables par utilisateurs et par
lment [#38].

: Alarmes
Au lieu de prsenter les lments en anomalies, cette interface projete prsenterait
des alarmes, contextuelles ou non, ce qui resterait dfinir. Les libells dalarmes et les
oprations entreprendre doivent tre plus clairs que sur lexistant, ce qui pourrait
ncessiter une redfinition de ces dernires [#61].
6.2.2.1. Instanciation du zonage fonctionnel
A titre dillustration, voici comment le zonage fonctionnel pourrait tre instanci en
intgrant un ensemble dexigences corrles.

Figure 6-7 : Exemple dintgrations des exigences fonctionnelles dans linterface

[1 Les feuilles constituent les fonctionnalits atomiques qui peuvent tre des
applications ou des flux. La remonte est effective dans les arborescences
par le biais dune coloration de llment.
[2 Les regroupements de feuilles (dossiers) constituent les lots et les blocs
fonctionnels. Ces regroupements sont bien entendu autant dlments
supervisables.

112
[3 Le niveau suprieur de larborescence est constitu des quartiers
fonctionnels.
[4 Le second niveau correspond aux cinq zones fonctionnelles de Platine.
[5 Le niveau racine constitue linstance mtier et mne de fait au synoptique
global de linstance.
[6 Premire partie de lentte, (voir C : informations gnrales) [#9].
[7 Permet daccder llment parent ; dans ce cas par exemple, il sagirait
de passer de Q_Traitement Z_Core [#23].
[8 Affichage de la date et de lheure comme sur lexistant [#9].
[9 Indique le login de lutilisateur authentifi sur lIHM (informations
rcuprs sur le cur de mtier) [#9].
[10 Dconnection ou passage sur un autre volet.
[11 Accs aux options de second plan (couleurs, connexions).
[12 Barre donglets, supervision en fonction dune facette [#27].
[13 La barre dadresse permettant daccder rapidement un lment [#24].
[14 La fentre centrale offre des stratgies daccs aux lments prsents. Ici,
la supervision prsente est dite par flux, elle est donc fonctionnelle et non
technique.
[15 Info bulle ; cet lment permettrait dafficher les informations de base
dun lment : articles en entre, articles en sortie, articles en cours, divers
et alarmes [#39 #62].
Zoom, notion dfinir [#3].
Alarmes intervention immdiate.
Alarmes intervention diffre.
Simon Joliet

113

6.3. Rflexions sur le modle de donnes
Dfinir un modle de donnes sur le primtre du prototype, mais en prvenant lvolution de ce
modle tout le produit moyen/long terme.

La cl du projet est de dvelopper un modle de gnricit entre les diffrents lments
superviss. Leffort apport cette gnricit apporterait une plus-value consquente aux
dveloppements futurs.

Historiquement, le dveloppement de chaque panneau de la supervision de Platine aura t
le fruit des besoins directs du mtier. Le problme de ce dveloppement est que sa mise en
place naura pas t loccasion de dfinir une homognit de la supervision. En revanche,
cet effort a t port sur la mdiation active.

De fait, les retours sur ce volet semblent trs pertinents pour notre chantier. Dans notre cas,
il sagirait doffrir une vision fonctionnelle et non plus technique du systme supervis.

Pour la mdiation active, les panneaux gnriques proposent les informations suivantes :
articles en entre, articles en sortie, articles en cours, divers. Ce mode de supervision
prsente un avantage significatif pour reprsenter lensemble du systme sous forme de flux.

Voir la proposition du modle de donnes page suivante.

114

Figure 6-8 : Premire proposition dun modle de donnes pour le chantier Platine
Annexes Simon Joliet
115
6.4. Mta modle global des entits et des mthodes de projet
Systme
TOBE
1..*
1..*
Dveloppe
1
1
Supporte
Prototype
1
1..*
Est
compos de
Macro
Dveloppement
1..*
1..*
Dveloppe
0..*
1
Compose
par
Corps
1..* 1
Dfini par
Technologie
1..*
1
Valide
0..*
1
Ncessite
0..*
1
Rutilise
1..*
1..*
Utilise
1..*
1
Dfini
Scnario
1 0..*
Propose
1..* 1
Rdige
0..*
1
Compose
par
Contenu
1..* 1
Dcrite par
Scnario
fonctionnel
Macro-design
OR
Partie prenante
Dveloppeur
Forme
1..*
1
Possde
1..*
1
Valide
1
1..*
Dfinit
Dure de vie
1..*
1
Possde
But
1..*
1
Possde
AND/OR
Oprateur
1 1..*
Formalise par
Maintenir Cesser Introduire Amliorer Etendre
0..*
1..*
0..* 0..* 0..* 0..*
Exigence
1
0..*
Propose
1..*
1
Concerne
Priorit
* 1
Possde
0..*
1..*
Compose
par
Corps
*
1
Dcrite par
Stratgique Applicative
Oprationnelle
OR
Identifiant
Niveau
0..*
1..*
Raffin
par
1 *
Caractris par
1
* Repre par
Systme
ASIS
1
1..*
Gnre
Approches
diriges par les
scnarios
Entits
communes
EKD-CMM
Ingnierie des
exigences
SCRUM
Lgende

Figure 6-9 : Mta modlisation globale des entits du projet

116
6.5. Carte Mentale globale du projet

Figure 6-10 : Carte mentales globale des concepts utiliss dans le projet
117
6.6. Extrait du gisement dexigences
Id Auteur Niveau Val. *Oprateur *Cible Paramtres *Commentaire
4 Exploitant Oprationnel OK Introduire des commandes sur les lments du
synoptique
Avoir sur le synoptique des boutons (lment, groupe, serveur, instance...) ou "lien"
entre ces lments (file, liaison..) ; un clic droit avec un certain nombre de possibilits
propres a l'objet (info alarme, info compteur, commandes spcifiques A/R ou autre -->
crans dfinir ultrieurement).
11 Exploitant Fonctionnel OK Introduire dans l'interface
principale
un cadre
regroupant
l'ensemble des
commandes et des
scripts
A droite par ex : se laisser un cadre Outil avec accs l'ensemble des commandes ou
scripts.
18 Exploitant Oprationnel OK Maintenir le bouton
d'alarme
sur toutes les
fentres, en
fonction du niveau
Sur toutes les fentres, alarmes se rapportant au niveau o lutilisateur se trouve.
19 Exploitant Fonctionnel OK Amliorer la
reprsentation
du synoptique ce
qui est supervis
En adquation avec ce qui est supervis (BIE, PRIMS, GOUROU, Platine,...) ; gestion
dynamique; ne faire apparatre que l'existant
voir feuille DtailExploit pour les propositions et/ou les propositions synoptiques
(fichiers joints).
45 Exploitant Fonctionnel OK Amliorer les temps de
rponses
de la visualisation Optimiser les temps de rponse (ex supervision pop-up dconnection).
49 Exploitant Oprationnel OK Cesser l'affichage du module de
retraitement
En effet le module de retraitement nest actuellement plus utilis.
51 Exploitant Fonctionnel OK Amliorer les dlais
d'acquittement
des alarmes L'acquittement des alarmes est trop long (de 10 20 secondes).

118
52 Exploitant Fonctionnel OK Amliorer la fiabilit des IHM Les timeout sur les IHM sont trop frquents et obligent arrter et relancer les IHM.
58 Exploitant Oprationnel OK Introduire une notion de
tri
insensible la casse Quel que soit la liste, pouvoir trier par ordre alphabtique sans respecter la casse.
59 Exploitant Oprationnel OK Introduire la
personnalisation
du synoptique Pouvoir dvelopper un synoptique la demande pour un besoin ponctuel. Exemple : suivre
le changement de palier sur 1 GSN.
65 Exploitant Fonctionnel OK Introduire la
personnalisation
des arborescences Pouvoir modifier les arborescences de manire dynamique.
66 Exploitant Oprationnel OK Introduire l'affichage du
dcalage horaire
pour les EEC hors
mtropole
Pouvoir afficher le dcalage horaire pour les EEC hors mtropole.
81 Exploitant Oprationnel OK Introduire une vue regroupant
linformation des
lots en anomalie de
retard
Besoin dune vue qui regroupant linformation des lots en anomalie de retard/Niveau
IECC. En effet, si les lots ne sont pas envoys, alors il y a un problme.
90 Exploitant Oprationnel OK Amliorer l'aide des commandes Apporter une aide contextuelle sur les commandes.
108 Skill
Center
Stratgique OK Introduire une IHM light pour les besoins
AMEA
Offrir la possibilit de superviser le produit de manire synthtique, de la mme manire
qu'un tableau de bord, pour satisfaire les besoin AMEA. Voir en quoi cela peut tre une
plus-value pour les instances historiques.
Tableau 6-3 : Extrait de 14 exigences du gisement mis en place pour le projet Platine
119
6.7. IHM historique de lapplication Platine

Figure 6-11 : IHM du module de collecte des IHM historique de Platine (v4)

120
6.8. Exemple de maquette fil de fer

Figure 6-12 : Maquette prsentant le nouveau principe fonctionnel Supervision par synoptique
121
6.9. Exemple de maquette ergonomique

Figure 6-13 : Maquette ergonomique prsentant le principe fonctionnel Supervision par synoptique

122
6.10. Exemple dInterface Homme Machine prototype

Figure 6-14 : Une itration du prototype des nouvelles IHM Web de Platine
123
6.11. Rgles des runions Agiles
Afin datteindre ses objectifs, la tenue des runions Agiles doivent tre garantie. Pour cela, le
formalisme suivant tendra tre respect dans la mesure du possible.

L'ordre du jour de la runion doit tre clair.
Si les membres de l'quipe dmarrent une discussion sans rapport avec l'objectif de la
runion, les membres devront reprendre cette discussion plus tard dans un autre
contexte. Le ScrumMaster doit identifier et indiquer le moment o les membres de
l'quipe doivent poursuivre une discussion dans un autre contexte.
Toutes les runions doivent suivre la structure de base dcrite pour cette runion.
Les runions doivent dmarrer l'heure, mme si certains membres de l'quipe sont
en retard.
Les membres de l'quipe doivent tre l'heure sauf dans les rares cas invitables. Si
votre planification vous empche d'tre l'heure rgulirement, le conflit doit tre
rsolu ds que possible. Si ncessaire, le ScrumMaster doit adapter l'heure de la
runion pour rsoudre le conflit si le changement ne drange pas indment un autre
membre de l'quipe.
Chaque membre de l'quipe doit venir la runion prpar.
Les runions doivent finir l'heure. Dans la plupart des cas, la longueur de la runion
est dtermine par la dure du sprint. Par exemple pour le projet Platine, une heure et
demie apparat comme suffisante pour un sprint de deux semaines.
La mthode SCRUM applique cette structure de runion un niveau qui peut ne pas
convenir certaines personnes. Cette raction est cause par l'exigence de ponctualit,
la responsabilit vis vis de ses pairs lie au fait de prendre et de tenir des
engagements, et la transparence requise pour une participation active.

(Aubry C., 2011)
6.12. Runion Agile type
Pour conceptualiser la tenue dune runion agile type pour ce type de chantier, voici un exemple
de structure dune runion type. Il sagit dans les faits de la troisime runion Agile du cycle de
dveloppement, en date du 29 juin 2012. Au cours de cette runion, huit nouvelles exigences
ont t apports au chantier.

1. Travaux effectus et venir
2. Les retours du Workshop Sngal
3. Nouvelles exigences AMEA
78

4. Nouvel lment : Diagnostic
5. Nouvel lment : Journal de Bord

124
6. Prsentation des maquettes
7. Suivi des exigences

En voici une version plus dtaill pour information :

1. Travaux effectus et venir
Invariant : chaque runion est prsent la liste des tches effectues depuis le
dernier point, et les tches lancer pour la suite. Exemple dans le cas de la
runion n2 :

Tches effectues Tches dmarrer
Prsentation et intgration de
Sonatel au sein du chantier
Synchronisation interne suite au
workshop Sngal
Dveloppement de nouvelles
maquettes
Dveloppement de deux
nouveaux lments :
Diagnostic et Journal de
Bord
Poursuite et validation du
dveloppement des maquettes
[SKC & Ergonomes]
Poursuite des dveloppements
de lapplication web
Tableau 6-4 : Diapositive type Tche effectues / Tches dmarrer

2. Retours du Workshop Sngal
Le chantier a t prsent de nouvelles parties prenantes, il sagit de linstance
Sonatel au Sngal. Le ScrumMaster prsente ainsi les retours.
3. Nouvelles exigences AMEA
8 nouvelles exigences sont ajoutes au gisement suite au retour du workshop, et
sont donc prsentes aux participants de la runion. Ces exigences sont repres
par leur identifiant unique (#xxx), et suivent le formalisme impos par le
canevas mis en uvre.
#141 Introduire des IHM lgres
#142 Introduire des IHM exploitables avec peu de ressources
#143 Amliorer la vrification de l'tanchit
#144 Introduire un outil de traabilit
#145 Introduire une supervision multi-instance
#146 Introduire une visualisation des lments en anomalies quelle que soit
l'instance
#147 Introduire un traage des lments via un journal de bord
#148 Introduire des tableaux de statistiques
#149 Introduire un lment de diagnostic

4. Nouvel lment Diagnostique
125
Llment Diagnostic est un macro-design conceptualisant lexigence #149
5. Nouvel lment : Journal de Bord
Llment Journal de Bord est un macro-design conceptualisant lexigence
#147
6. Prsentation des maquettes
Prsentation en temps rel dune maquette ralise par les ergonomes du
chantier, montant les IHM sur la base des exigences prcdemment valides.
7. Suivi des exigences
Ici, le ScrumMaster expose toutes les exigences sur lesquelles les efforts ont t
ports au cours du dernier sprint Agile. En loccurrence pour le point n2 :
#9 : Introduire des informations gnrales dans l'entte
#26 : Amliorer l'affichage du synoptique de manire dynamique
#34 : Introduire la notion d'aide
#31 : Amliorer la gestion de l'espace dans les crans
#33 : Amliorer la pertinence et nommage des compteurs
#36 : Amliorer les tableaux de compteurs
Il est ensuite demand aux intervenants de valider les travaux prsents portant
sur ces exigences. Si celles-ci sont valides, elles seront dveloppes. Sinon, elles
seront conceptualises dans de nouvelles maquettes, puis repasseront une tape
de validation lors dun sprint suivant.

126
6.13. Questionnaire dvaluation Parties Prenantes
Il est propos ici de rdiger un canevas permettant de capturer les retours des parties prenantes
quant limplantation de la mthode utilis dans le cadre du chantier Chantier IHM Platine.
Ce questionnaire a t mis disposition des parties prenantes pendant environ un mois, via le
service www.mon-enquete-en-ligne.fr.

Questionnaire dvaluation Parties Prenantes

Dans le cadre de mon mmoire, jai document une partie de la mthodologie que jai mise en
place afin de guider le processus de projet. Je souhaiterais valuer la comprhension et lefficacit
de la mthode pour le chantier des IHM. Aussi jaimerais quun maximum de personnes ayant
particip de prs ou de loin au chantier et qui ont assist au moins une runion, puissent
rpondre ces 12 questions.

Le projet a t men jusque-l via un processus de projet hybride, utilisant les mthodes Agiles
(SCRUM) coupl une mthode de l'ingnierie des besoins (Requirement Engineering), ainsi
quune approche dirige par les scnarios (Maquettes et Macro-Designs).

--Simon

Il y a 12 questions dans ce questionnaire.

Ce questionnaire est anonyme.

Principal

Q1: *Pensez-vous que cette mthode est plus mme de guider un chantier IHM quune
expression de besoin initiale, suivi du cycle de dveloppement classique (ingnierie de projet) ?
Veuillez slectionner seulement une rponse ci-dessous :

Pas du tout
Un peu
Moyennement
Beaucoup

Q2: *Selon vous, a-t-il t pertinent de communiquer rgulirement sur lavancement du projet
?

Oui
Parfois
127
Non
Autre (Prcisez)

Q3: *Pensez-vous que dans lensemble, le fait de se baser sur les exigences pour piloter le projet a
apport une plus-value ?

Oui
Parfois
Non
Autre (Prcisez)

Q4: *Est-ce que la structure utilise pour la tenue des runions (prsentation des travaux
effectus, prsentation des travaux venir, ordre du jour, suivi des exigences) a t pertinente ?
Veuillez slectionner une rponse ci-dessous:

Trs pertinent
Plutt pertinent
Pas pertinent

Veuillez saisir votre commentaire ici :

Q5: *Selon vous, la dure des runions fixe 1 heure 30 est-elle suffisante, trop importante ou
pas assez importante ? Si trop ou pas assez, pourquoi ?
Veuillez slectionner une rponse ci-dessous:

Pas assez longue
Bonne dure
Trop longue

Veuillez saisir votre commentaire ici :

Q6: *Selon vous, la frquence des runions fixe 2 semaines est-elle suffisante, trop importante
ou pas assez importante ? Si trop ou pas assez, pourquoi ?
Veuillez slectionner seulement une rponse ci-dessous

Trop importante
Satisfaisante
Pas assez importante
Autre (Prcisez)

Q7: *A votre avis, cette mthode pourrait tre pertinente dans dautres chantiers que celui des
IHM ?
Veuillez slectionner seulement une rponse ci-dessous

128

Oui
Parfois
Non

Q8: Selon vous, que faut-il absolument maintenir dans la mthode ?

Q9: Selon vous, que faut-il absolument amliorer dans la mthode ?

Q10: Selon vous, que faut-il absolument introduire dans la mthode ?

Q11: Selon vous, que faut-il absolument cesser (supprimer) dans la mthode ?

Q12: Selon vous, avec quelles autres mthodes celle-ci devrait tre tendue ?

Envoyer votre questionnaire.

Merci d'avoir complt ce questionnaire.
Rfrences Simon Joliet
129
7. RFRENCES
7.1. Index des figures
Figure 3-1 : Synoptique des trois sous ensemble inhrents la supervision ....................................................................... 17
Figure 3-2 : Arbre des mthodes de diagnostic ......................................................................................................................... 19
Figure 3-3 : Diagramme de flux, problmatique de la maintenance ..................................................................................... 19
Figure 3-4 : Proposition darchitecture associe un monitoring rseau ............................................................................ 30
Figure 3-5 : Proposition darchitecture associe une supervision industrielle ................................................................ 38
Figure 3-6 : Proposition darchitecture associe une solution spcifique binaire ........................................................... 47
Figure 3-7 : Proposition darchitecture associe une solution spcifique binaire ........................................................... 59
Figure 3-8 : Synoptique de synthse, solutions off the shelf contre dveloppement spcifique ..................................... 63
Figure 3-9 : Arbre de solutions de ltat de lart ........................................................................................................................ 64
Figure 4-1 : Workflow de plus haut niveau, dfinissant la position de la mthodologie ................................................. 66
Figure 4-2 : Modle de transition du systme existant au systme cible en utilisant les exigences ................................ 67
Figure 4-3 : Modle de transition et chanage des mthodologies utilises ........................................................................ 69
Figure 4-4 : S1, Modlisation de dcouverte des exigences par processus Top-Down ..................................................... 71
Figure 4-5 : S2, Modlisation de dcouverte des exigences par processus Bottom-Up .................................................... 72
Figure 4-6 : La vision des sprints SCRUM selon Mike Cohn................................................................................................ 74
Figure 4-7 : Extension du schma de Mike Cohn par une approche dirige par les exigences ....................................... 75
Figure 4-8 : Mta-modlisation des exigences ........................................................................................................................... 78
Figure 4-9 : Exemple de taxonomie des exigences .................................................................................................................... 79
Figure 4-10 : Mta-modlisation des exigences oprationnelles et des 5 oprateurs du changement........................... 82
Figure 4-11 : Mta-modlisation du scnario ............................................................................................................................ 85
Figure 4-12 : Processus de rdaction du scnario ..................................................................................................................... 86
Figure 4-13 : Mta-modlisation du macro-dveloppement ................................................................................................. 88
Figure 4-14 Processus de macro dveloppement ...................................................................................................................... 89
Figure 4-15 : Mta modlisation de lindustrialisation ........................................................................................................... 91
Figure 5-1 : valuation empirique ; Map relle ......................................................................................................................... 94
Figure 6-1 : Architecture actuelle simplifie ............................................................................................................................ 104
Figure 6-2 : Diagramme de squence du dialogue IHM/Mtier actuel (dialogue asynchrone) .......................... 105
Figure 6-3 : Architecture cible urbanise .................................................................................................................................. 106
Figure 6-4 : Solution intermdiaire ........................................................................................................................................... 107
Figure 6-5 : Wireframe de linterface actuelle ......................................................................................................................... 108
Figure 6-6 : Interface projete ..................................................................................................................................................... 110
Figure 6-7 : Exemple dintgrations des exigences fonctionnelles dans linterface ......................................................... 111
Figure 6-8 : Premire proposition dun modle de donnes pour le chantier Platine .................................................... 114
Figure 6-9 : Mta modlisation globale des entits du projet .............................................................................................. 115
Figure 6-10 : Carte mentales globale des concepts utiliss dans le projet.......................................................................... 116
Figure 6-11 : IHM du module de collecte des IHM historique de Platine (v4) ............................................................. 119
Figure 6-12 : Maquette prsentant le nouveau principe fonctionnel Supervision par synoptique .................... 120
Figure 6-13 : Maquette ergonomique prsentant le principe fonctionnel Supervision par synoptique ............ 121
Figure 6-14 : Une itration du prototype des nouvelles IHM Web de Platine .............................................................. 122


130

7.2. Index des tableaux
Tableau 3-1 : Axe damlioration, maintenance corrective et prdictive ............................................................................ 21
Tableau 3-2 : Avantages et inconvnients de la solution Nagios .......................................................................................... 25
Tableau 3-3 : Avantages et inconvnients de la solution Zabbix .......................................................................................... 25
Tableau 3-4 : Avantages et inconvnients de la solution Centreon ..................................................................................... 26
Tableau 3-5 : Avantages et inconvnients de la solution OpenNMS .................................................................................. 27
Tableau 3-6 : Avantages et inconvnients de la solution Openview NMMi ..................................................................... 27
Tableau 3-7 : Benchmark des solutions de monitoring rseau .............................................................................................. 29
Tableau 3-8 : Avantages et inconvnients des technologies de supervision rseau ........................................................... 32
Tableau 3-9 : Benchmark des solutions de monitoring industriel ........................................................................................ 36
Tableau 3-10 : Avantages et inconvnients des technologies de monitoring industriel .................................................. 37
Tableau 3-11 : Avantages et inconvnients des solutions sur tagre .................................................................................. 39
Tableau 3-12 : Technologies Middleware .................................................................................................................................. 41
Tableau 3-13 : Avantages et inconvnients des technologies Middleware ......................................................................... 42
Tableau 3-14 : Avantages et inconvnients des Webservices Restfull ................................................................................. 45
Tableau 3-15 : Avantage et inconvnients des applications binaires ................................................................................... 48
Tableau 3-16 : Avantages et inconvnients du Framework Zend ........................................................................................ 49
Tableau 3-17 : Avantages et inconvnients du Framework Symfony .................................................................................. 50
Tableau 3-18 : Benchmark des Framework Zend et Symfony .............................................................................................. 50
Tableau 3-19 : Avantages et inconvnients du Framework Struts ....................................................................................... 51
Tableau 3-20 : Avantages et inconvnients du Framework Spring MVC .......................................................................... 52
Tableau 3-21 : Benchmark des Framework Struts et Spring MVC ..................................................................................... 52
Tableau 3-22 : Avantages et inconvnients des Framework de dveloppement Web ..................................................... 55
Tableau 3-23 : Benchmark des technologies JSP et PHP ....................................................................................................... 55
Tableau 3-24 : Synthse comparative des technologies JSP et PHP .................................................................................... 56
Tableau 3-25 : Liste des Framework Javascript ......................................................................................................................... 57
Tableau 3-26 : Avantages et inconvnients du Framework Google Web Toolkit ........................................................... 58
Tableau 3-27 : Avantages et inconvnients du Framework Dojo Toolkit ......................................................................... 59
Tableau 3-28 : Avantages et inconvnients des applications Web ........................................................................................ 60
Tableau 3-29 : Avantages et inconvnients du dveloppement spcifique ......................................................................... 61
Tableau 3-30 : Comparatif qualitatif des solutions sur tagre et du dveloppement spcifique ................................. 63
Tableau 4-1 : Description de la stratgie : Processus du projet de lexploitabilit de haut niveau................................. 71
Tableau 4-2 : Description de la stratgie S1 : Dcouverte des exigences par processus Top-Down ............................. 72
Tableau 4-3 : Description de la stratgie S2 : Dcouverte des exigences par processus Bottom-Up ............................ 73
Tableau 4-4 : Comparatif des approches Top-Down et Bottom Up .................................................................................. 73
Tableau 4-5 : Description des niveaux dexigences .................................................................................................................. 77
Tableau 4-6 : Descriptif du mta modle des exigences .......................................................................................................... 78
Tableau 4-7 : Descriptif du mta-modle des exigences oprationnelles ............................................................................ 82
Tableau 4-8 : Descriptif du mta modle des scnarios .......................................................................................................... 86
Tableau 4-9 : Description de la stratgie S6 : Par rdaction du scnario ............................................................................ 87
Tableau 4-10 : Descriptif du mta modle des macro-dveloppements .............................................................................. 89
Tableau 4-11 : Description de la stratgie S9 : Par macro dveloppement ......................................................................... 89
Tableau 4-12 : Descriptif du mta modle de lindustrialisation .......................................................................................... 91
Tableau 6-1 : Avantages et inconvnients dune nouvelle architecture fonctionnelle ................................................... 107
Tableau 6-2 : Avantages et inconvnients dune architecture fonctionnelle hybride .................................................... 107
Tableau 6-3 : Extrait de 14 exigences du gisement mis en place pour le projet Platine ................................................. 118
Tableau 6-4 : Diapositive type Tche effectues / Tches dmarrer ...................................................................... 124

131

7.3. Bibliographie
Aubry C., 2011 : Scrum : Le guide pratique
de la mthode agile la plus populaire -
2me edition, Dunod, 304p
Ben Achour C. et al., 1999 : Guiding
Requirement Engineering with a
Process Map, Fourth IEEE
International Symposium on
Requirements Engineering, University
of Limerick, 15p
Etinkaya E. K., 2001 : Reliability Analysis
Of SCADA Systems Used In The
Offshore Oil And Gas Industry,
Faculty of the Graduate School of the
University Of Missouri-Rolla, 75p
Faiz Bashir M., 2009 : Google Web Toolkit
(GWT) and Java EE, Center for
Advanced Software Engineering
(CASE) Faculty of Computer Science
and Information System Universiti
Teknologi Malaysia, 88p
Hearn D., 2009 : Enterprise architecture
Evolving to succeed, Deloitte, Deloitte
& Touch House, Earlsfort Terrace,
Dublin 2, 12p
Hennion N., 2011 : Introduction Nagios
Nicolargo, 65p
Hernndez De Len, H. R., 2006 : On-Line
Monitoring And Diagnosis Of
Potable Water Production Processes,
Laboratoire d'Analyse et
d'Architecture des Systmes du CNRS,
Universit de Toulouse, 163p
Hurter C., 2010 : Characterization of
Visualizations and Interactive
Exploration of Large Quantity of
Multidimensional Data, Institut
Suprieur de lAronautique et de
lEspac, Universit de Toulouse, 190p
Imanache D. et al, 2004 : Nouvelles
Technologies Rseau Nagios,
Ingnieurs 2000, Universit de Marne
la Valle, 26p
Juhsz B., 2009 : Developing M2M
Applications With Mango JAMK
University of Applied Sciences, 42p
Longp C., 2009 : Le projet d'urbanisation
du systme d'information
Dmarche pratique avec cas
concret, Dunod, 290p
Machacek, J. et al, 2008. Pro Spring 2.5,
Apress, 920p
Menet, L. 2008 : Enrichissement smantique
de mta modles XML et UML pour
une transformation bidirectionnelle
de modles Laboratoire
dInformatique et Communication),
Universit Paris 8, 16p
Morley C., 2008 : UML 2 pour l'analyse d'un
systme d'information - Le cahier des
charges du matre d'ouvrage, Dunod,
232p
Moro A., 2010, Les Framework au cur des
applications Web - Haute Ecole de
Gestion de Genve (HEG), 128p
Nurcan S. et al, 2003 : A Multi-Method for
Defining the Organizational Change,
Centre de Recherches en Informatique
Universit Paris I Panthon-
Sorbonne, 35p
Oudot C., 2005 : Introduction Cacti
Linagora Paris, 40p
Ralyt J., Rolland C., 2001 : An assembly
process model for method
engineering, Centre de Recherches en

132
Informatique Universit Paris I
Panthon-Sorbonne, 24p
Rolland C, et al, 1999 : A Multi-Model
View of Process Modelling, Centre de
Recherches en Informatique
Universit Paris I Panthon-Sorbonne,
p. 169-187
Rolland C., 1999 : A goal driven approach
to modelling COTS acquisition
impacts Centre de Recherches en
Panthon-Sorbonne, p. 8
Rolland C et al., 1996 : A Proposal For A
Scenario Classification Framework,
Centre de Recherches en
Panthon-Sorbonne, 44p
Sadovykh A., 2005 : Innovative Middleware
Concept for Supervision of Complex
Systems, EADS SPACE
Transportation, Universit Paris VI,
107p
Temple C., 2004 : Monitoring de serveurs
avec Zabbix - Universit des Sciences et
Technologies de Lille, 29p
Vilemaitis M., 2011 : HP Network Node
Manager 9: Getting Started - Chapter
No.1 "Before we Manage with
NNMi", 39p
Wiberg K., 2006 : Identifying Supervisory
Control And Data Acquisition
(SCADA) Systems On A Network
Via Remote Reconnaissance, Naval
Postgraduate School, Monterey,
California, 147p
133
7.4. Webographie
Bartol N., 2012 : Serveur Web d'applications
PHP - Outils de dveloppement PHP -
Formations PHP - Zend.com
<http://www.zend.com/fr/>
Bhaskar J., 2012 : Google Web Toolkit
Google Developers
<https://developers.google.com/web
-toolkit/>
Chong, L., 2012 : Meetings (Agiles)
<http://msdn.microsoft.com/fr-
fr/library/dd997582.aspx>
Galstad E., 2011 : Nagios - The Industry
Standard In IT Infrastructure
Monitoring And Alerting
<http://www.nagios.org/>
Germusk J., 2012 : Welcome
<http://struts.apache.org/>
Gutmans A., 2011 : Home Centreon
<http://www.centreon.com/>
Ivanova E., 2011 : Linux SCADA ::
SCADA/HMI for Linux platform
reviews, <http://linuxscada.info>
Ivanova E., 2011 : SCADA World - all world
SCADA systems / HMI Interface,
[compare price, choose, links, download
information],
<http://scadaworld.org>
Jan O., 2012 : Supervision, monitoring,
mtrologie, capacity planning la
sauce Open Source | Communaut
Francophone de la Supervision Libre
<http://www.monitoring-fr.org>
Johnson R., 2012 : SpringSource.org |
<http://www.springsource.org/>
Potencier F., 2012 : Symfony | Web PHP
Framework <http://www.symfony-
project.org/>
Russell A., 2012 : Unbeatable JavaScript
Tools - The Dojo Toolkit
<http://dojotoolkit.org/>
Ryals A., 2011 : HP Network Node Manager
i software | HP Software
<http://www8.hp.com/us/en/softwa
re/software-
product.html?compURI=tcm:245-
936950>

134
7.5. Glossaire

1
MDE : Model Driven Engineering ;
Ingnierie dirige par les modles
2
Off The Shelf : Solutions sur tagre
3
Framework : Kit de composants logiciels
structurels servant crer tout ou partie
d'un logiciel
4
ACP : Analyse en Composante Principale ;
mthode danalyse statistique de donnes
5
Affordance : capacit dun objet suggrer
sa propre utilisation
6
SNMP : Simple Network Management
Protocol ; protocole de communication
permettant de grer et de superviser des
quipements rseau
7
ICMP : Internet Control Message Protocol.
Utilis pour vhiculer des messages de
contrle et d'erreur
8
SCADA : Supervisory Control And Data
Acquisition ; tlsurveillance et
acquisition de donnes
9
GNU : systme dexploitation libre lanc en
1984
10
GPL : Licence publique gnrale de
distribution des logiciels libres
11
QoS : Quality of Service ; Qualit de
service
12
SMS : Short Message Service ; Service de
messagerie
13
CPU : Central Process Unit ; Le processeur
physique
14
HTTP : HyperText Transfer Protocol ;
protocole de communication client-
serveur dvelopp pour le World Wide
Web
15
Front end : Point d'entre uniformis pour
des services diffrents

16
SLA : Service Level Agreement ; document
qui dfinit la qualit de service requise
entre un prestataire et un client
17
AGPL : Affero General Public License ;
licence libre drive de la Licence
publique gnrale GNU avec une partie
supplmentaire couvrant les logiciels
utiliss sur le rseau
18
MIB : Management Information Base, base
d'information pour la gestion du rseau
utilis dans SNMP
19
Traps SNMP : type de PDU utilis pour
signaler un vnement asynchrone
comme une alerte ou autre autour d'un
sous-systme de gestion
20
OS : Operating System ; Systme
dexploitation
21
IHM : Interface Homme-Machine ; outils
de contrle et de communication entre
un systme et son utilisateur
22
IDE : Integrated Development
Environment ; Environnement de
dveloppement logiciel intgr
23
OLE : Object Linking and Embedding ;
protocole et systme d'objets distribus,
distribu par Microsoft
24
TCP : Transmission Control Protocol ;
protocole de transport fiable en mode
connect
25
UDP : User Datagram Protocol ; protocole
de transport en mode non connect
26
ASCII : American Standard Code for
Information Interchange ; norme de
codage de caractres en informatique la
plus ancienne
27
BIN : fichier excutable binaire compil
28
IP : Internet Protocol ; protocole de
communication fondamental de la suite
des protocoles internet,
29
M2M : Machine to Machine, systmes de
communications entre machines sans
intervention humaine.
135

30
J2EE : Java Enterprise Edition,
spcification Java particulirement
destine aux applications dentreprise
31
Client lourd : Logiciel qui propose des
fonctionnalits complexes avec un
traitement autonome
32
Client lger : Machine ddie
larchitecture client-serveur, naillant
presque aucune logique applicative
33
MVC : Modle-Vue-Contrleur ;
paradigme dorganisation dune
application en couches
34
Middleware : Logiciel tiers crant un
rseau d'change d'informations entre
diffrentes applications informatiques
35
RPC : Remote procedure call ; protocole
d'appel de procdures distance
36
DCOM : Distributed Component Object
Model ; technique de Microsoft
permettant la communication entre des
composants logiciels distribus
37
CORBA : Common Object Request
Broker Architecture ; architecture
logicielle pour le dveloppement de
composants et dORB
38
EJB : Enterprise JavaBeans ; Architecture
de composants logiciels ct serveur pour
la plateforme de dveloppement JEE.
39
JMS : Java Message Service ; interface de
programmation Java
40
Webservices : Programme informatique
permettant la communication et
l'change de donnes entre applications et
systmes htrognes
41
REST : REpresentational State Transfer ;
manire de construire une application
pour les systmes distribus ( linstar de
SOAP)
42
.NET : Ensemble de produits
informatiques de Microsoft pour rendre
des applications facilement portables sur
Internet

43
SOAP : Simple Object Access Protocol ;
protocole RPC orient objet bti sur
XML permettant la transmission de
messages entre objets distants
44
SOA : Service Oriented Architecture ;
forme d'architecture de mdiation qui
met en uvre des services
45
JSON : JavaScript Object Notation ;
Format de donnes textuel hritant de la
notation JavaScript
46
AJAX : Asynchronous Javascript and
XML ; Manire de faire communiquer
des applications Web de manire
dynamique
47
URI : Uniform Resource Identifier ;
Courte chane de caractres identifiant
une ressource sur un rseau
48
PHP : Hypertext Preprocessor ; Langage de
scripts libre utilis pour produire des
pages dynamiques via serveur HTTP
49
JSP : JavaServer Pages ; technique base sur
Java qui permettant aux dveloppeurs de
crer des pages web dynamiques
50
API : Application Programming Interface ;
interface fournie par un programme
informatique
51
ORM : Object-Role Modeling ; dmarche
et formalisme de modlisation
conceptuelle de bases de donnes
52
JMX : Java Management Extensions ; API
Java permettant de grer le
fonctionnement d'une application en
cours d'excution
53
JDBC : Java DataBase Connectivity ; API
de connexion une base de donnes pour
les programmes Java
54
DAO : Data Access Object ; objet
permettant l'accs aux donnes dune base
55
BDD : Base de Donnes
56
ODBC : Open Database Connectivity ;
logiciel middleware qui permet une
application informatique de se connecter
une base de donnes

136

57
Rich Internet Application : Application
Internet riche ; Application Web qui
offre des caractristiques similaires aux
logiciels traditionnels
58
Flash : Logiciel multimdia utilis pour
crer des graphiques vectoriels et des
bitmap anims
59
Silverlight : Framework dapplication
internet riche de Microsoft (quivalent
de Adobe Flash)
60
WPF : Windows Presentation Foundation
est la spcification graphique de
Microsoft .NET 3.0
61
MIT (licence) : Licence de logiciel utilise
notamment pour la diffusion du
gestionnaire de fentre X11
62
BSD (licence) : Licence libre utilise pour
la distribution de logiciels
63
Bytecode : Code intermdiaire plus proche
des instructions machines que le code
source, excutable par machine virtuelle
64
HTML : Hypertext Markup Language,
Langage de balisage utilis pour
reprsenter les pages web
65
CSS : Cascading Style Sheets ; langage
informatique pour la prsentation des
documents HTML
66
Modle en cascade : Cycle de
dveloppement traditionnel o tout le
processus du chantier est formalis au
pralable et les tches sont excuts dans
un ordre bien tabli
67
Cycle en V : Amlioration du modle en
cascade permettant en cas d'anomalie, de
limiter un retour aux tapes prcdentes
68
Mthodes Agiles : Groupe de mthodes
itratives ou incrmentales, permettant
de ragir au changement des besoins et
impliquant plus efficacement les
utilisateurs dans les dveloppements
69
RUP : Rational Unified Process ; Mthode
de dveloppement pour les logiciels
orients objets (itrative)

70
Map : Modlisation permettant la
reprsentation de plusieurs faons de
conduire un processus d'ingnierie
71
EKD-CMM : Enterprise Knowledge
Development - Change Management
Method ; Dmarche mthodologique
permettant de guider une activit de
modlisation du changement
organisationnel
72
SCRUM : Mthode Agile incrmentale
permettant de prendre en charge une
production planifie. Scrum autorise
l'affinement itratif des exigences lors des
cycles de dveloppement
73
Sprint : Incrment de projet durant
gnralement deux semaines, termin par
une dmonstration des travaux raliss
74
ScrumMaster : animateur d'une quipe qui
applique Scrum
75
UML : Unified Modeling Language, ;
langage graphique de modlisation des
donnes et des traitements dun systme
76
KPI : Key Performance Indicator ;
indicateurs de performance cls,
indicateurs mesurables permettant lide
dcisionnelle.
77
CREWS : Projet du centre de recherche de
Paris I dont lobjectif est de mettre en
place et dvaluer des outils de lingnierie
des besoins

Mémoire M2 MIAGE SIC 2012 - Simon Joliet

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mémoire M2 MIAGE SIC 2012 - Simon Joliet

Uploaded by

Copyright:

Available Formats

UNIVERSIT PARIS 1 PANTHON SORBONNE

You might also like