Vous êtes sur la page 1sur 172

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/303339170

METHODOLOGIE DE PLANIFICATION STRATEGIQUE DES SYSTEMES


D’INFORMATION BASEE SUR L’ARCHITECTURE D’ENTREPRISE

Thesis · June 2015


DOI: 10.13140/RG.2.1.4214.6163

CITATIONS READS

0 14,200

1 author:

Mouhsine Lakhdissi
Université Hassan 1er
15 PUBLICATIONS   43 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Digital Transformation in Universities and Higher Education View project

All content following this page was uploaded by Mouhsine Lakhdissi on 19 May 2016.

The user has requested enhancement of the downloaded file.


Année : 2015 Thèse n° 28/ST2I

École Nationale Supérieure d'Informatique et d'Analyse des systèmes


Centre d’Études Doctorales en Sciences des Technologies de l'Information et de l'Ingénieur

THÈSE DE DOCTORAT

METHODOLOGIE DE PLANIFICATION STRATEGIQUE DES


SYSTEMES D’INFORMATION BASEE SUR L’ARCHITECTURE
D’ENTREPRISE

Présentée par
Mouhsine LAKHDISSI

Le 10 Juin 2015
Formation doctorale : Informatique
Structure de recherche : Equipe Qualité des Architectures logicielles,
développement et Intégration (AlQualsadi)

JURY
Pr. Laila KJIRI Président ENSIAS
Pr. Ounsa ROUDIES Rapporteur EMI
Pr. Azedine BOULMAKOUL Rapporteur FST Mohammedia
Pr. Mahmoud NASSAR Rapporteur ENSIAS
Pr. Abdellatif MEZRIOUI Examinateur INPT
Pr. Mounia FREDJ Examinateur ENSIAS
Pr. Bouchaïb BOUNABAT Directeur de thèse ENSIAS

i
1
‫بسم هللا الرحمن الرحيم‬
{ ‫قل إ َّن صَلتي وَنسكي وِمحياي وِمماتي َّّلِل ربّ العالمين اَل َشريك لُه وبَذلك ُأِمرت وُأَنا ُأ َّول‬
‫}المسلمين‬

163 -162 : ‫األنعام‬

« A la mémoire de mon défunt père que Dieu l’ait en sa Sainte


Miséricorde, Il aurait tant voulu voir le fruit de ses sacrifices »

i
Remerciements

« La méthode est une explication en vue d’une application »

Remerciements
Je tiens à exprimer mes remerciements à mon directeur de thèse, Pr. Bouchaïb BOUNABAT,
pour son soutien et sa confiance ainsi que pour ses conseils et recommandations durant les
années de thèse. En dehors de l’apport scientifique, je ne pourrais oublier de lui exprimer toute
ma gratitude pour ses qualités humaines, sa disponibilité et son encadrement de qualité.

Je tiens aussi à remercier vivement Pr. Laila KJIRI, Professeur à l’ENSIAS, pour m'avoir fait
l'honneur d'accepter d'examiner mes travaux et de présider le jury de ma soutenance de thèse.

Je remercie aussi les membres du Jury, Pr. Ounsa ROUDIES, Professeur à l’EMI, Pr Azedine
BOULMAKOUL, Professeur à la FST de Mohammedia et Pr. Mahmoud NASSAR, Professeur
à l’ENSIAS, qui m’ont fait l’honneur d’être rapporteurs de ce travail. Je leur suis pleinement
reconnaissant pour leur participation à ce jury.

Mes vifs remerciements sont destinés au Pr. Abdellatif MEZRIOUI, Professeur à l’INPT et Pr.
Mounia FREDJ, Professeur à l’ENSIAS pour l’honneur qu’ils m’ont fait d’examiner et de juger
ce travail.

Ma reconnaissance va aux professeurs et doctorants de l’Equipe Qualité des Architectures


logicielles, développement et Intégration (AlQualsadi) pour leur disponibilité et le partage des
connaissances ainsi qu’à mes amis et collègues de Neoxia Maroc et notamment Tawfik ES-
SQALLI et Rachid EL HABI pour leur support et leurs encouragements.

Ma gratitude va aux membres de ma famille, petits et grands et plus particulièrement ma mère


et ma femme. Leur présence et leur appui moral ont toujours été très bénéfiques pour m’aider
à atteindre mes objectifs.

Finalement, pour tous ceux que je n’ai pas cités, mais que je n’oublie pas pour autant, qu’ils
reçoivent ici toute ma reconnaissance et ma gratitude. A tous un grand merci !

ii
‫ِملخص‬

‫ملخص‬

‫ال بد للشركات واإلدارات الحكومية أن تضبط واقع نظم معلوماتها وأن تخطط لتطوريها بما يتناسب مع استراتيجياتها‪،‬‬
‫خاصة في سياق البيئة المتغيرة والتعقيد المتزايد ألنشطتها‪.‬‬
‫التخطيط االستراتيجي لنظم المعلومات يتيح لهاته النظم إمكانية المواءمة والتناغم مع استراتيجية األعمال وجعل التكنولوجيا‬
‫عنصر تأثير مهم الكتساب ميزة تنافسية‪.‬‬
‫الهدف الرئيس للتخطيط االستراتيجي لنظم المعلومات هو تحديد الوضعية المستقبلية لنظم المعلومات وخارطة الطريق‬
‫للوصول إليها‪ .‬ويعتبر هذا التخطيط أساس التخاذ القرارات والحكامة الجيدة في مجال المعلوميات‪ .‬ومع ذلك‪ ،‬فإن غالبية‬
‫التقنيات واألساليب والوسائل المستخدمة قديمة وأكثر مالءمة للتخطيط االستراتيجي العام ال المعلوماتي‪.‬‬
‫العمران المقاوالتي (أو البنية المقاوالتية) هو المجال الذي يهدف لوضع نموذج للبنية الحالية للشركة ونظامها المعلوماتي‪،‬‬
‫وتحديد الهيكل المستقبلي لهذا النظام ووضع خطة التطوير‪ .‬في هذا اإلطار‪ ،‬يمكن أن يوفر العمران المقاوالتي إطارا لمعالجة‬
‫أوجه القصور في المنهجيات الحالية للتخطيط االستراتيجي لنظم المعلومات كما يمكن أن يساهم في هيكلة وضبط هاته‬
‫المناهج‪ .‬هذا ويستفيد العمران المقاوالتي أيضا من جهد توحيد المنهجيات ودعم من قبل أدوات النمذجة‪ .‬كما تختص مناهج‬
‫العمران المقاوالتي بضبط جيد للمخرجات والنماذج‪.‬‬
‫يعرض هذا العمل منهجية جديدة للتخطيط االستراتيجي لنظم المعلومات مؤسسة على نسق العمران المقاوالتي‪ .‬هذا النهج‬
‫الجديد يثري ويحين نماذج العمران المقاوالتي القائمة ويضع هيكل اإلطار الجديد للمحتوى‪ .‬عالوة على ذلك فهو يطرح‬
‫بتفصيل منهجية التخطيط االستراتيجي مع شرح المراحل واألنشطة والمخرجات وتفصيل كيفية العمل باستخدام منصة‬
‫النمذجة‪.‬‬
‫باإلضافة إلى هذا‪ ،‬يعرض هذا البحث إمكانية تحيين المنهجية المقترحة وتكييفها مع الحاجة إلى التخطيط االستراتيجي في‬
‫م جال المحمول في سياق تأثير التكنولوجيا على استراتيجية األعمال‪ .‬باإلضافة إلى ذلك‪ ،‬يعرض دراسة تفصيلية لكيفية‬
‫استخدام هذا النهج في سياق المنظمين الحكوميين مما يساعد على إظهار سياق استخدام المنهجية لضمان المواءمة‬
‫االستراتيجية لنظم المعلومات‪.‬‬
‫تسمح المنهجية المقترحة باستيعاب الضعف والقصور في األساليب الحالية للتخطيط االستراتيجي لنظم المعلومات عبر تبني‬
‫نهج أكثر تنظيما وتدرجا وتصنيعا ً وبالتالي تمكين نظم المعلومات من لعب دورها المحوري كمحرك أساس لتحول الشركات‬
‫واإلدارات‪.‬‬

‫كلمات البحث‬
‫التخطيط االستراتيجي لنظم المعلومات‪ ،‬العمران المقاوالتي‪ ،‬المنهجية‪ ،‬النموذج‪ ،‬هيئة تنظيم‪ ،‬المواءمة االستراتيجية‪،‬‬
‫استراتيجية نظم المحمول‬

‫‪iii‬‬
Résumé

Résumé
Les entreprises et les administrations, du fait de l’évolution de leur environnement et de la
complexité grandissante de leurs activités, doivent maitriser leur existant et planifier leur
transformation de manière cohérente avec leur stratégie.

La Planification Stratégique des Systèmes d’Information permet aux Systèmes d’Information


de s’aligner par rapport au métier et à la stratégie des entreprises et de faire de la technologie
un élément d’impact pour acquérir un avantage compétitif.

Le focus principal de la Planification Stratégique des SI est la définition de l’état cible du SI et


de la feuille de route pour y arriver. Cette discipline est considérée à la base de la prise de
décision et de la gouvernance SI. Néanmoins, la majorité des techniques, approches et méthodes
utilisées, sont anciennes et sont plus adaptées à la planification stratégique métier que SI.
L’Architecture d’Entreprise est une discipline qui vise à modéliser l’architecture existante, à
définir l’architecture cible et à élaborer le plan de migration. Dans ce sens, elle peut fournir un
cadre de travail pour combler les insuffisances des méthodes existantes de Planification
Stratégique SI et contribuer à structurer et formaliser la discipline. L’Architecture d’Enterprise
bénéficie, en outre, d’effort de standardisation et de support par les outils de modélisation. Les
livrables et les artéfacts de l’Architecture d’Entreprise sont bien structurés et définis.

Le présent travail présente une nouvelle méthodologie de Planification Stratégique SI basée sur
l’Architecture d’Entreprise. Cette nouvelle approche enrichit et personnalise les métamodèles
d’Architecture d’Entreprise existants et définit un nouveau Framework de contenu de
l’architecture. De plus, elle structure la démarche de Planification Stratégique SI avec un cycle
de vie détaillant les phases, activités et livrables et industrialise le travail via une plateforme de
modélisation.

Par ailleurs, la méthodologie proposée est illustrée et adaptée pour le besoin de planification
stratégique mobile dans le contexte de l’impact des technologies sur la stratégie des entreprises.
De plus, une étude de cas permet de détailler l’usage de la démarche dans le contexte des
organismes de régulation gouvernementaux. Cette étude de cas permet de montrer l’usage de
la méthodologie pour assurer l’alignement stratégique du SI.

La méthodologie ESPAM, ainsi proposée permet de résorber les défaillances et déficiences des
méthodes actuelles de Planification Stratégique des Systèmes d’Information en définissant une
démarche structurée, progressive et industrialisée permettant ainsi aux Systèmes d’Information
de jouer pleinement leur rôle central de moteur de la transformation des entreprises et des
administrations.

MOTS-CLEFS
Planification Stratégique SI, Architecture d’Entreprise, Méthodologie, Métamodèle,
Organisme de régulation, Alignement stratégique, Stratégie mobile

iv
Abstract

Abstract
Businesses and governments, due to changes in their environment and the increasing
complexity of their activities, must control and govern their existing assets and plan their
transformation consistently with their strategy.

Information Systems Strategic Planning allows to align IT with respect to the business and
corporate strategy and make technology an impacting element to gain competitive advantage.

Defining IT target and the specific roadmap to attain it, are main focuses of IS Strategic
Planning which is considered increasingly as the basis for IT decision-making and governance.
Nevertheless, most of the techniques, approaches and methods related to IT Strategic Planning
date back to the 80s or 90s and are most often oriented business rather than IT strategic
planning. Enterprise Architecture is a promising discipline aimed at capturing the as-is
architecture of an enterprise, defining the target and the roadmap to get from existing to desired
state. In that way, it is tightly related to IT strategic planning and it can provide a framework to
fill the gap and contribute in structuring and formalizing IT Strategic Planning field. Enterprise
Architecture benefits from a standardization effort as well as from tool support. Deliverables
and artifacts are generally well defined and structured in the existing frameworks.

The current work presents a new IS Strategic Planning methodology based on Enterprise
Architecture. This new approach enhances and personalizes the existing Enterprise Architecture
metamodels and defines a new Architecture Content Framework. Furthermore it structures the
IS Strategic Planning process with a life cycle that details phases, activities and deliverables
and with a modeling platform enabling more industrialized activities.

Furthermore, the proposed methodology is illustrated and adapted to the need for mobile
strategic planning in the context of the impact of technology on business strategy. In addition,
an exhaustive case study details the use of the approach in the context of government regulatory
agencies. This case study helps demonstrating the use of the methodology to ensure strategic
alignment of the IS.

The proposed methodology ESPAM addresses the failures and shortcomings of current
Information Systems Strategic Planning methods by defining a structured, progressive and
industrialized process allowing Information Systems to be a key element in the transformation
of enterprises and governments.

KEYWORDS
IS Strategic Planning, Enterprise Architecture, Methodology, Metamodel, Regulation agency,
Strategic Alignment, Mobile strategy

v
vi
Table des matières

Table des matières


Remerciements ........................................................................................................................... ii
‫ ِملخص‬.......................................................................................................................................... iii
Résumé ...................................................................................................................................... iv
Abstract ...................................................................................................................................... v
Table des matières .................................................................................................................... vii
Liste des abréviations .............................................................................................................. xiii
Liste des figures ....................................................................................................................... xv
Liste des tableaux ................................................................................................................... xvii
Introduction Générale ................................................................................................................. 1
Contexte .................................................................................................................................. 1
Motivations et problématique ................................................................................................. 2
Principes et axes de recherche ................................................................................................ 2
Apport et contributions ........................................................................................................... 3
Plan du document ................................................................................................................... 3
Publications ............................................................................................................................ 4
Chapitre 1 : Planification Stratégique des Systèmes d’Information .......................................... 5
1.1 Introduction ................................................................................................................ 6
1.2 Contexte ..................................................................................................................... 6
1.3 Généralités sur la planification stratégique ................................................................ 6
1.3.1 Stratégie et planification stratégique ...................................................................... 6
1.3.2 Enjeux de la planification stratégique .................................................................... 7
1.3.3 Planification stratégique des Systèmes d’Information ........................................... 8
1.4 Description des méthodologies PSSI ......................................................................... 8
1.4.1 Méthodologie, méthode et Framework .................................................................. 8
1.4.2 Analyse de la Chaîne de Valeur ............................................................................. 9
1.4.3 Facteurs critiques de succès ................................................................................. 10
1.4.4 Planification des systèmes métier ........................................................................ 11
1.4.5 Planification stratégique des systèmes ................................................................. 12
1.4.6 Information Engineering ...................................................................................... 13
1.4.7 Méthode Method/I ................................................................................................ 13
1.4.8 Méthode RACINES.............................................................................................. 14

vii
Table des matières

1.5 Synthèse des méthodologies PSSI............................................................................ 15


1.6 Conclusion ................................................................................................................ 17
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI .................................... 19
2 ............................................................................................................................................ 19
2.1 Introduction .............................................................................................................. 20
2.2 Définition et objectifs de l’Architecture d’Entreprise .............................................. 20
2.2.1 Définition de l’Architecture d’Entreprise ........................................................... 20
2.2.2 Objectifs et enjeux de l’Architecture d’Entreprise ............................................... 21
2.3 Activités de l’Architecture d’Entreprise .................................................................. 23
2.4 Architecture d’Entreprise Descriptive ...................................................................... 24
2.5 Architecture d’Entreprise Prescriptive ..................................................................... 25
2.6 Frameworks d’Architecture d’Entreprise ................................................................. 25
2.6.1 Définition d’un framework d’AE ......................................................................... 25
2.6.2 Frameworks d’Architecture d’Entreprise de Référence ....................................... 26
2.6.2.1 Zachman ........................................................................................................... 27
2.6.2.2 Framework d’architecture d’entreprise DoDAF .............................................. 28
2.6.2.3 Framework d’Architecture MoDAF ................................................................. 28
2.6.2.4 Framework Fédéral d’Architecture d’Entreprise FEAF ................................... 29
2.6.2.5 Framework TAFIM .......................................................................................... 30
2.6.2.6 Framework d’architecture de l’Open Group .................................................... 31
2.7 Synthèse des Frameworks ........................................................................................ 34
2.7.1 Évolution des Framework d’AE ........................................................................... 34
2.7.2 Étude comparative ................................................................................................ 34
2.8 Domaines connexes de l’AE .................................................................................... 36
2.8.1 Modélisation SI .................................................................................................... 36
2.8.2 Modélisation Entreprise ....................................................................................... 36
2.8.3 Modélisation des processus métier (BPM) ........................................................... 37
2.8.4 Service Oriented Architecture .............................................................................. 37
2.8.5 Model Driven Architecture .................................................................................. 37
2.8.6 Gouvernance SI (CoBIT) ..................................................................................... 38
2.8.7 Management des services SI (ITIL) ..................................................................... 38
2.8.8 Management de projet avec PMBOK .................................................................. 39
2.8.9 Frameworks métier ............................................................................................... 40

viii
Table des matières

2.8.10 Synthèse des sujets connexes ........................................................................... 40


2.9 Utilisation de l’Architecture d’Entreprise dans le contexte de la Planfication
Stratégique SI ....................................................................................................................... 41
2.9.1 Architecture d’Entreprise et PSSI ........................................................................ 41
2.9.2 Utilisation de l’AE dans le cadre de la PSSI ........................................................ 42
2.9.2.1 Besoin de Transformation ................................................................................ 42
2.9.2.2 Besoin d’un métamodèle .................................................................................. 42
2.9.2.3 Métamodèles existants ..................................................................................... 43
2.9.2.4 Éléments pour définir la méthodologie ............................................................ 43
Méta-modèle ..................................................................................................................... 44
Framework de contenu/Cadre de modélisation ................................................................. 44
Processus et cycle de vie ................................................................................................... 44
Outil de modélisation ........................................................................................................ 45
2.10 Conclusion ................................................................................................................ 45
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM ........ 47
3 ............................................................................................................................................ 47
3.1 Introduction .............................................................................................................. 48
3.2 Framework de contenu GAM (Global Architecture Map) ....................................... 48
3.2.1 Description générale ............................................................................................. 48
3.2.2 Référentiel d'Architecture d'Entreprise de GAM ................................................. 50
3.3 Métamodèle GCM (Global Content Metamodel) .................................................... 51
3.3.1 Objectifs ............................................................................................................... 51
3.3.2 Métamodèle GCM ................................................................................................ 51
3.3.3 Détail du métamodèle GCM ................................................................................ 52
3.3.4 Métamodèle de la couche Stratégie ...................................................................... 53
3.3.5 Métamodèle de l’Architecture métier................................................................... 54
3.3.6 Métamodèle de l’Architecture Applicative .......................................................... 55
3.3.7 Métamodèle de l’Architecture de données ........................................................... 56
3.3.8 Métamodèle de l’Architecture technique ............................................................. 57
3.3.9 Métamodèle de la Planification stratégique ......................................................... 59
3.3.10 Caractéristiques du méta-modèle GCM ........................................................... 60
3.4 Conclusion ................................................................................................................ 61
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM.......................................... 63
4 ............................................................................................................................................ 63

ix
Table des matières

4.1 Introduction .............................................................................................................. 64


4.2 Processus et cycle de vie ESPAM ............................................................................ 64
4.2.1 TOGAF ADM ...................................................................................................... 64
4.2.2 Détail du cycle de vie méthodologique ................................................................ 65
4.2.3 Phase 0 : Initiation et Organisation du projet ....................................................... 66
4.2.4 Phase 1 : Analyse et évaluation de l’existant et des besoins ................................ 67
4.2.4.1 Description des activités................................................................................... 67
4.2.4.2 Livrables de la phase ........................................................................................ 71
4.2.5 Phase 2 : Définition de la vision stratégique d’architecture ................................. 71
4.2.5.1 Description des activités................................................................................... 71
4.2.5.2 Livrables de la phase ........................................................................................ 75
4.2.6 Phase 3 : Élaboration du plan d’action à court terme ........................................... 75
4.2.6.1 Description des activités................................................................................... 75
4.2.6.2 Livrables de la phase ........................................................................................ 76
4.2.7 Phase 4 : Élaboration de l’architecture cible et du plan d’urbanisation ............... 77
4.2.7.1 Description des activités................................................................................... 77
4.2.7.2 Livrables de la phase ........................................................................................ 78
4.2.8 Phase 5 : Evaluation des scénarii de mise en œuvre et élaboration du plan de
migration ........................................................................................................................... 79
4.2.8.1 Description des activités................................................................................... 79
4.2.8.2 Livrables de la phase ........................................................................................ 80
4.2.9 Phase 6 : Élaboration du plan de gouvernance et d’alignement stratégique du SI
80
4.2.9.1 Description des activités................................................................................... 80
4.2.9.2 Livrables de la phase ........................................................................................ 82
4.3 Plateforme de modélisation ESPAP ......................................................................... 82
4.3.1 UML, MOF et OCL ............................................................................................. 82
4.3.2 Architecture technique de l’outil .......................................................................... 83
4.3.3 Fonctionnalités de la plateforme ESPAP ............................................................. 84
4.3.3.1 Explorateur d’objets ......................................................................................... 84
4.3.3.2 Propriétés des objets de l’explorateur .............................................................. 85
4.3.3.3 Le dessin des diagrammes ................................................................................ 85
4.3.3.4 Propriétés des objets graphiques ...................................................................... 86
4.3.3.5 Génération des rapports .................................................................................... 87

x
Table des matières

4.4 Adaptation d’ESPAM à la définition de la stratégie mobile .................................... 89


4.4.1 Planification stratégique dans le contexte du mobile ........................................... 89
4.4.2 Méthodologie de planification stratégique mobile ............................................... 90
4.4.2.1 Présentation générale de la méthodologie ........................................................ 90
4.4.2.2 Description détaillée de la méthodologie ......................................................... 91
4.4.2.3 Outils et techniques méthodologiques .............................................................. 91
4.4.3 Conclusion ............................................................................................................ 95
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation 97
5 ............................................................................................................................................ 97
5.1 Introduction .............................................................................................................. 98
5.2 Alignement stratégique ............................................................................................ 98
5.2.1 Définition de l’Alignement Stratégique (AS) ...................................................... 98
5.2.2 Importance de l’alignement stratégique ............................................................... 99
5.2.3 Alignement stratégique et PSSI............................................................................ 99
5.3 Contexte des organismes de régulation .................................................................... 99
5.3.1 Métier des organismes de régulation .................................................................... 99
5.3.2 Besoins en alignement stratégique SI................................................................. 101
5.4 Application d’ESPAM dans l’étude de cas ............................................................ 101
5.4.1 Rappel de la méthodologie ESPAM................................................................... 101
5.4.2 Étude de l’existant et cadrage du besoin ............................................................ 102
5.4.2.1 Couverture SI sur la chaine de valeur ............................................................ 102
5.4.2.2 Couverture du SI par rapport à l’organisation ................................................ 103
5.4.2.3 Architecture technique ................................................................................... 104
5.4.3 Définition des orientations stratégiques ............................................................. 104
5.4.3.1 Stratégie métier .............................................................................................. 104
5.4.3.2 Synthèse des orientations stratégiques SI....................................................... 104
5.4.4 Plan d’action à court terme................................................................................. 106
5.4.4.1 Plan d’actions correctives ............................................................................... 106
5.4.4.2 Plan d’actions préalables ................................................................................ 106
5.5 Conclusion .............................................................................................................. 108
Conclusion Générale .............................................................................................................. 109
Récapitulatif du travail ....................................................................................................... 109
Contributions et bénéfices .................................................................................................. 109

xi
Table des matières

Perspectives et travaux futurs ............................................................................................. 110


Bibliographie .......................................................................................................................... 111
ANNEXES ............................................................................................................................. 117
Annexe 1 : Méthodes et référentiels ....................................................................................... 117
Annexe 2 : Technologies de la plateforme ESPAM .............................................................. 117
Annexe 3 : Livrables détaillés de l’étude de cas .................................................................... 117
Annexe 4 : Modèles de livrables ESPAM .............................................................................. 117

xii
Liste des abréviations

Liste des abréviations


Abbréviation Détail
ADM Architecture Development Method
AE/EA Architecture d’Entreprise
AS Alignement Stratégique
BIAN Banking Industry Architecture Network
BPM Business Process Modeling
BPR Business Process Reengineering
BSP Business System Planning
COBIT Control Objectives for Information Technology
CRM Customer Relationship Management
CSF/FCS Critical Success Factors / Facteurs Critiques de Succès
DODAF Department of Defense Architecture Framework
DSI Direction des Systèmes d’Information
DSL Domain Specific Language
EMF Eclipse Modeling Framework
ESPAM Enterprise Strategic Planning Architecture Methodology
ESPAP Enterprise Strategic Planning Architecture Platform
ETL Extract Transform Load
eTOM Enterprise Telecom Operation Map
FEAF/FEA Federal Enterprise Architecture Framework
GAM Global Architecture Map
GCM Global Content Metamodel
GEF Graphical Editing Framework
HTML Hyper Text Markup Language
IIIRM Integrated Information Infrastructure Reference Model
ISO International Standard Organization
IT Information Technology (Technologie de l’Information)
ITIL Information Technology Infrastructure Library
KPI Key Performance Indicator
MDA Model Driven Architecture
MODAF Military of Defense Architecture Framework
NFC Near Field Communication
OCL Object Constraints Language
PMBoK Project Management Body Of Knwoledge
PMI Project Management Institute
PSA Planification des Systèmes d’Affaire (voir BSP)
PSSI/ISSP Planification STratégique des Systèmes d’Information
RCP Rich Client Platform
ROI Return On Investment (Retour sur investissement)
SCOR Supply Chain Operational Reference model
SDSI Schéma Directeur des Systèmes d’Information
SI Système d’Information
SLA Service Level Agreement
SMQ Système de Management de la Qualité
SOA Service Oriented Architecture
SWOT Strength Weakenesses Opportunities Threats

xiii
TAFIM Technical Architecture Framework For Information Management
TEAF Treasury Enterprise Architecture Framework
TOGAF The Open Group Architecture Framework
TRM Technical Reference Model
UML Unified Modeling Language
XML Extensible Markup Language

xiv
Liste des figures

Liste des figures


Figure 1 : Exemple de chaine de valeur (Porter, 1985) .......................................................................... 9
Figure 2 : Etapes de la méthode SSP (Pant, 1995) .............................................................................. 12
Figure 3 : Vue globale de la méthode Information Engineering (Martin, 1982) .................................... 13
Figure 4 : Contenu de l'Architecture d'Entreprise .................................................................................. 21
Figure 5 : Activités de l’Architecture d’Entreprise .................................................................................. 24
Figure 6: Matrice du Framework Zachman (Zachman, 1987) ............................................................... 27
Figure 7: Les vues du Framework d’AE DoDAF (DoD, 1998) ............................................................... 28
Figure 8: Les vues du Framework d’AE MoDAF (MoD, 2008) .............................................................. 29
Figure 9: Le Framework FEA (FEAF, 1999) .......................................................................................... 29
Figure 10: Framework TAFIM (TAFIM, 1996) ....................................................................................... 31
Figure 11: Composants du Framework TOGAF (TOGAF, 2011) .......................................................... 32
Figure 12: Cycle de TOGAF ADM (TOGAF, 2011) ............................................................................... 33
Figure 13 : Evolution et relations entre Frameworks d’AE (Schekkerman, 2004) ................................ 35
Figure 14 : Cube de CoBIT (AFAI, 2002) .............................................................................................. 38
Figure 15 : Vue globale du modèle de référence du métier Télécom (Frameworx/eTOM) .................. 40
Figure 16 : Framework de contenu Global Architecture Map (GAM) ................................................... 49
Figure 17 : Vue générale du référentiel d’Architecture d’Entreprise personnalisé ................................ 51
Figure 18 : Diagramme de packages du Métamodèle Global de Contenu GCM .................................. 52
Figure 19 : Vue globale du métamodèle d’Architecture d’Entreprise GCM .......................................... 53
Figure 20 : Métamodèle de la couche stratégie .................................................................................... 54
Figure 21 : Métamodèle de l’Architecture métier ................................................................................... 55
Figure 22 : Métamodèle de l’Architecture applicative ........................................................................... 56
Figure 23 : Métamodèle de l’Architecture de données .......................................................................... 57
Figure 24 : Métamodèle de l’Architecture technique ............................................................................. 58
Figure 25 : Métamodèle de la planification stratégique ......................................................................... 60
Figure 26 : Méthodologie TOGAF ADM (TOGAF, 2011) ...................................................................... 64
Figure 27 : Déroulement du cycle de vie méthodologique ESPAM ...................................................... 66
Figure 28 : Phase 0 de la méthdologie ESPAM .................................................................................... 67
Figure 29 : Phase 1 de la méthodologie ESPAM .................................................................................. 67
Figure 30 : Phase 2 de la méthodologie ESPAM .................................................................................. 71
Figure 31 : Eléments de la vision Architecture ...................................................................................... 72
Figure 32 : Exemple de synthèse de la Vision d'Architecture ............................................................... 74
Figure 33 : Phase 3 de la méthodologie ESPAM .................................................................................. 76
Figure 34 : Positionnement du plan d'actions à court terme par rapport au PSSI ................................ 77
Figure 35 : Phase 4 de la méthodologie ESPAM .................................................................................. 77
Figure 36 : Méthodologie de définition de l'architecture cible ............................................................... 78
Figure 37 : Phase 5 de la méthodologie ESPAM .................................................................................. 79
Figure 38 : Calendrier de mise en œuvre d'un PSSI ............................................................................. 80
Figure 39 : Phase 6 de la méthodologie ESPAM .................................................................................. 81
Figure 40 : Architecture d'entreprise appliquée à la gouvernance d'entreprise .................................... 82
Figure 41: Architecture technique globale de l’outil............................................................................... 84
Figure 42: Explorateur d'objets du méta modèle ................................................................................... 84
Figure 43: Ajout d'un objet à l'aide du menu contextuel ........................................................................ 85
Figure 44 : Vue propriétés de l'objet "Mission" de la couche stratégie ................................................. 85
Figure 45: L'éditeur graphique de l'outil ................................................................................................ 85
Figure 46 : Contexte du MVC dans l'outil .............................................................................................. 86
Figure 47 : Dessin de diagramme "Actor _ Role" .................................................................................. 86
Figure 48 : Propriétés graphiques de l'élément "Facteur de succès" ................................................... 87
Figure 49 : Matrice de dépendance sous forme Excel .......................................................................... 87
Figure 50 : Un exemple de modèle métier ............................................................................................ 88
Figure 51 : Fenêtre de demande du chemin de sauvegarde du rapport ............................................... 88
Figure 52 : Exemple de rapport généré ................................................................................................. 89
Figure 53 : Exemple de rapport HTML généré ...................................................................................... 89
Figure 54 : Méthodologie de planification stratégique mobile VERGA ................................................. 91
Figure 55 : Mobile Vision Cube ............................................................................................................. 93
Figure 56 : Chaine de valeur mobile ..................................................................................................... 94
Figure 57 : Modèle de référence applicatif mobile ................................................................................ 94
Figure 58 : Modèle de référence technique mobile ............................................................................... 95

xv
Figure 59 : Chaîne de valeur de l’organisme de régulation ................................................................ 100
Figure 60 : Couverture du SI dans la chaine de valeur ....................................................................... 102
Figure 61 : Matrice de dépendance Applications / Directions ............................................................. 103
Figure 62 : Diagramme d’architecture des serveurs ........................................................................... 103
Figure 63 : Synthèse des orientations stratégiques ............................................................................ 105
Figure 64: Procédure de génération de code ...................................................................................... 124
Figure 65 : Vue "statique" en couche de l'architecture logicielle cible ................................................ 129
Figure 66 : Vue "dynamique" en couche de l'architecture logicielle cible ........................................... 129

xvi
Liste des tableaux

Liste des tableaux


Tableau 1 : Comparaison entre méthode, méthodologie et framework (Lakhdissi, 2011)...................... 9
Tableau 2 : Etapes de la méthode RACINES (Balantzian, 1992) ......................................................... 15
Tableau 3 : Comparatif des méthodes de planification stratégique ...................................................... 16
Tableau 4 : Etude comparative des frameworks d’AE .......................................................................... 35
Tableau 5 : Comparaison entre PSSI et AE .......................................................................................... 42
Tableau 6 : Description des objets de la stratégie ................................................................................ 54
Tableau 7 : Description des objets de l’Architecture métier .................................................................. 55
Tableau 8 : Description des objets de l’Architecture applicative ........................................................... 56
Tableau 9 : Description des objets de l’Architecture de données ......................................................... 57
Tableau 10 : Description des objets de l’Architecture technique .......................................................... 58
Tableau 11 : Description des objets de la planification stratégique ...................................................... 59
Tableau 12 : Comparaison entre GCM et les métamodèles existants .................................................. 61
Tableau 13 : Phases de la méthodologie TOGAF ADM ....................................................................... 65
Tableau 14 : Détail d'un élément de diagnostic .................................................................................... 70
Tableau 15 : Détail d'une ligne directrice .............................................................................................. 75
Tableau 16 : Détail des phases de la méthodologie VERGA ................................................................ 92
Tableau 17 : Axes et objectifs stratégiques ......................................................................................... 104
Tableau 18 : Détail d’une orientation stratégique SI (ligne directrice) ................................................ 105
Tableau 19 : Détail des actions correctives à mettre en place ............................................................ 107

xvii
Introduction Générale

Introduction Générale

Contexte
L’entreprise et l’administration confrontent aujourd’hui plusieurs défis et enjeux qui
conditionnent leur évolution, leur compétitivité et leur existence. Le contrat qui lie une
organisation à ses clients est simple : les uns ont des besoins, l'autre doit y répondre. Toutefois,
les raisons pouvant causer la non satisfaction du client sont multiples, donc une organisation
doit avant tout se concentrer sur sa raison d'être : son métier. Par ailleurs, tout serait facile si ce
métier, quel qu'il soit, banque, télécoms, industrie ou service public, ne changeait
continuellement. En effet, les besoins des clients ainsi que les réglementations évoluent
constamment et cela l’organisation n'y peut rien ; soit elle s'adapte soit elle meurt. A cela
s'ajoute le fait que ces changements s'enchaînent de plus en plus vite : le défi auquel les
organisations doivent répondre n'est plus d'être les plus volumineuses ou les plus profitables
mais bien d'être les plus réactives voire proactives. C’est dans ce cadre qu’intervient le principe
d’agilité métier (McCoy et al, 2006).

Le Système d'Information (SI) joue un rôle moteur dans une entreprise mais pourrait devenir
un frein important à son évolution quand il n’arrive pas à suivre les changements de l’entreprise.
On parle alors de manque d’alignement du SI par rapport au métier ou carrément de son
absence. D’où la nécessité de recourir à la démarche d’alignement SI / métier.

Lorsque l’écart entre les stratégies métier et SI devient important, même la démarche
d’alignement n’aboutit pas, et il devient alors inévitable d’opter pour des transformations
radicales au sein de l’entreprise. Le schéma directeur et/ou le plan stratégique est un des outils
facilitant la gestion des projets de transformation dans une entreprise. L’urbanisation du SI (et
l’architecture d’entreprise) se veut aussi une autre approche pour la résolution du problème
d’adaptabilité du SI avec le métier de l’entreprise.

Par ailleurs, le Système d’Information peut également impacter fortement et positivement la


productivité et la performance des entreprises, à travers le concept de transformation
numérique. En effet, le SI, et plus généralement, les technologies transforment et révolutionnent
les modes adoptés par l’entreprise pour distribuer ses produits, assurer le support client, gérer
l’opérationnel ou prendre des décisions. Le Cloud, le mobile, les réseaux sociaux et le Big Data
sont autant de technologies qui peuvent profiter pleinement à la performance des entreprises et
à leur compétitivité globale.

Transformer le SI en un moteur de la performance du métier nécessite de s’assurer que la


stratégie SI est alignée avec celle du métier et que la technologie est utilisée de manière
optimale. C’est pour cela qu’il est important de mettre en place et de conduire régulièrement un
processus de planification stratégique du SI avec une démarche structurée, formalisée et
industrialisée.

1
Introduction Générale

Motivations et problématique
Ce travail de recherche vient suite à de nombreux constats sur le terrain concernant les
démarches actuelles de Planification Stratégique SI (PSSI) (Wilton, 2007). En effet, ces
démarches accusent une faiblesse en terme de structuration, de formalisation et
d’industrialisation ; ce qui les rend lourdes et inadaptées, surtout avec la vitesse actuelle des
transformations au sein des organisations. De plus, les projets, souvent proposés à la suite des
schémas directeurs SI, ne sont souvent pas justifiés par les objectifs stratégiques. Ce lien
descendant des objectifs stratégiques aux initiatives SI n’est pas toujours présent. Souvent les
consultants SI ont recours à des recommandations et à des projets « prêts à porter » qui ne
conviennent pas toujours au contexte et qui ne sont pas en phase avec la stratégie. Il a été
également remarqué que le diagnostic de l’existant habituellement source des
recommandations, est basé sur des entretiens et des ateliers et peut refléter une vision très
subjective des acteurs SI ou métier. L’exercice du diagnostic n’est pas formalisé et peut
conduire à des recommandations inadéquates.

Les méthodes actuelles ne sont pas outillées et produisent le plus souvent des documents qui
deviennent rapidement obsolètes et inexploitables vu qu’aucune structure conceptuelle n’est à
la base des livrables et artéfacts produits lors du processus de PSSI (Pant, 1995). Ce manque de
structure implique également une description disproportionnée des différents volets du SI avec,
dans certains cas, une modélisation très pauvre des aspects techniques à l’existant et dans la
cible (Lakhdissi, et al., 2011). Il est également difficile d’établir des dépendances entre le métier
et les différents éléments du SI en vue de mener de manière systématique des analyses d’écart
et des analyses d’impact (Lakhdissi, et al., 2011).

Tenant compte de l’ensemble de ces déficiences, il serait opportun de réévaluer les méthodes
existantes, au regard des domaines annexes et de proposer une approche structurée, formalisée
et outillée à même de mener une étude de planification stratégique du SI. Ceci constitue
l’objectif du présent travail de recherche dont les résultats sont exposés dans ce mémoire.

Principes et axes de recherche


Prenant en considération ce constat, le travail s’est porté sur le rapprochement des démarches
de planification stratégique des SI (PSSI) avec les frameworks d’architecture d’entreprise en
vue d’élaborer une méthodologie structurée, formalisée et outillée pour la planification
stratégique. Pour ce faire, il a été nécessaire d’étudier les méthodes existantes de PSSI ainsi que
les frameworks existant d’architecture d’entreprise pour identifier les points communs et définir
une structuration qui profite des avantages de l’architecture d’entreprise et prend en compte les
exigences de la planification stratégique.

Par la suite, un framework d’architecture d’entreprise (AE) en particulier TOGAF (TOGAF,


2011), a été utilisé comme base pour définir la nouvelle méthodologie de planification
stratégique baptisée ESPAM et décrite dans le troisième et quatrième chapitre. Cette
méthodologie est décrite selon quatre aspects : le métamodèle qui structure les éléments de la

2
Introduction Générale

méthodologie, le framework de contenu qui décrit les livrables, le cycle de vie qui décrit le
processus méthodologique et, enfin, les outils qui permettent d’industrialiser la méthodologie.

Pour illustrer la méthodologie, deux études de cas ont été menées avec deux objectifs différents
et ont permis de valider la viabilité de la méthodologie dans des contextes réels et pour des
exigences particulières. La première étude de cas est une illustration de l’adaptation de la
méthodologie au cas particulier de la planification stratégique mobile. La seconde est une
application de la méthodologie ESPAM dans le contexte des organismes de régulation
gouvernementaux pour assurer l’alignement stratégique du SI.

Apport et contributions
Le présent travail a permis d’introduire plusieurs contributions aux domaines de la PSSI et de
l’AE dont :

- La structuration d’une méthodologie de planification stratégique SI qui peut s’étendre


vers la planification stratégique métier via un framework de contenu, un métamodèle,
un cycle de vie méthodologique et une plateforme de modélisation,
- L’enrichissement des frameworks d’architecture d’entreprise qui restent incomplets,
notamment au niveau de la description du SI et de l’alignement stratégique des projets
et des transformations,
- L’élaboration d’un modèle associant la description de l’entreprise et de son Système
d’Information tant au niveau des opérations courantes que des transformations,
- L’élaboration d’une étude de cas complète de la méthodologie pour un organisme
gouvernemental de régulation avec comme objectif d’assurer l’alignement stratégique,
- L’application de la méthodologie sur des domaines transverses de planification
stratégique comme la définition de la stratégie mobile.

Plan du document
Le présent document est organisé comme suit :

Le premier chapitre a pour objectif de définir la planification stratégique en général et la


planification stratégique SI en particulier, d’en exposer les enjeux et de présenter les méthodes
existantes de planification stratégique en faisant une synthèse de ces méthodes.

Dans le second chapitre, l’objectif est d’introduire la discipline d’Architecture d’Entreprise en


termes de définition, d’enjeux et d’objectifs. Par la suite, une description est faite des
frameworks d’architecture et une synthèse de ces frameworks est faite avec un comparatif.
Enfin, des domaines complémentaires sont présentés avec leurs liens avec l’AE.

Le troisième chapitre permet de définir la méthodologie de planification stratégique proposée.


Celle-ci est baptisée ESPAM (Enterprise Strategic Planning Architecture Methodology) et est
inspirée du framework d’architecture d’entreprise TOGAF (TOGAF, 2011) (et plus
particulièrement de sa méthodologie TOGAF ADM). Cette description permet de définir et
détailler, entre autres, le framework de contenu et le métamodèle proposés.

3
Introduction Générale

Le chapitre 4 détaille le processus et cycle de vie de la méthodologie avec les différentes phases,
activités et livrables ainsi que la plateforme de modélisation qui a été développée pour
industrialiser la démarche. Il présente également un cas d’adaptation de la méthodologie pour
la définition de la stratégie mobile.

Dans le chapitre 5, une étude de cas est présentée pour illustrer l’usage de la méthodologie.
Cette étude de cas concerne un plan stratégique d’un organisme de régulation gouvernemental
et revêt une importance particulière vu qu’il adopte une logique d’alignement pour construire
et consolider un système d’information à l’image du métier et aligné avec la stratégie.

Publications
Plusieurs papiers, articles de recherche sont publiés dans le cadre du présent travail à travers la
contribution d’un chapitre à un livre et la publication dans des journaux indexés et des
conférences nationales et internationales spécialisées :

- Contribution dans un livre

L.G Cretu, Designing Enterprise Architecture Frameworks: Integrating Business Processes


with IT Infrastructure, February 10, 2014 by Apple Academic Press, ISBN 9781771880077

- Articles de revues internationales

M. Lakhdissi, R. Elhabi, B. Bounabat, Adapting IS Strategic Planning methodology to define


Mobile Strategy, International Journal of Computer Science Issues (IJCSI) Volume 10 Issue 5,
September 2013

M. Lakhdissi , B. Bounabat, A new content metamodel for IS Strategic Planning with a tool
implementation, International Journal of Computer Science Issues (IJCSI) Volume 9 Issue 8,
Mars 2012

M. Lakhdissi, B. Bounabat, A new content metamodel for IS Strategic Planning : Regulation


Agency Case Study, Journal of Communication and Computer, David publishing Company,
Number 12, 2011

- Conférences internationales / nationales

M. Lakhdissi, R.El Habi, B. Bounabat, Planification stratégique mobile basée sur


l’Architecture d’Entreprise, Proceedings of ISKO Maghreb, Marrakech 2013

M. Lakhdissi, B. Bounabat, Toward a novel methodology for IT Strategic Planning,


Proceedings of ICIME 2011, p 277-287, Toronto Canada, ISBN: 97-1-906638-98-6, April 2011

- Workshops internationaux / nationaux

M. Lakhdissi, B. Bounabat, A new content framework and metamodel for ISSP and EA.
Proceedings of WOTIC 2011, p 211-221, Casablanca, Octobre 2011

4
Chapitre 1 : Planification Stratégique des Systèmes d’Information

Chapitre 1 : Planification Stratégique


des Systèmes d’Information

5
Chapitre 1 : Planification Stratégique des Systèmes d’Information

1.1 Introduction
La planification stratégique est un processus important pour construire, améliorer et transformer
les systèmes d’information. Elle s’intègre à la gouvernance globale du SI et vise à définir et une
stratégie cohérente pour le SI et à planifier sa mise en œuvre.

L’objectif de ce chapitre est de définir la planification stratégique en général et la planification


stratégique SI en particulier d’en exposer les enjeux et de présenter les méthodes existantes de
planification stratégique en faisant une synthèse de ces méthodes.

1.2 Contexte
Ce travail de recherche vient suite à de nombreux constats sur le terrain concernant les
démarches actuelles de Planification Stratégique SI (PSSI). En effet, ces démarches accusent
une faiblesse en terme de structuration, de formalisation et d’industrialisation ce qui les rend
lourdes et inadaptées, surtout avec la vitesse actuelle des transformations au sein des
organisations. De plus, les projets souvent proposés à la suite des schémas directeurs SI ne sont
souvent pas justifiés par les objectifs stratégiques. Ce lien descendant des objectifs stratégiques
aux initiatives SI n’est pas toujours présent. Souvent les consultants SI ont recours à des
recommandations et des projets « prêts à porter » qui ne conviennent pas toujours au contexte
et qui ne sont pas en phase avec la stratégie. Il a été également remarqué que le diagnostic de
l’existant, habituellement source des recommandations, est basé sur des entretiens et des ateliers
et peut refléter une vision très subjective des acteurs SI ou métier. L’exercice du diagnostic
n’est pas formalisé et peut conduire à des recommandations inadéquates.

En outre, les méthodes actuelles ne sont pas outillées et produisent le plus souvent des
documents qui deviennent rapidement obsolètes et inexploitables vu qu’aucune structure
conceptuelle n’est à la base des livrables et artéfacts produits lors du processus de PSSI. Ce
manque de structure implique également une description disproportionnée des différents volets
du SI avec dans certains cas, une modélisation très pauvre des aspects techniques à l’existant et
dans la cible. Il est également difficile d’établir des dépendances entre le métier et les différents
éléments du SI en vue de mener, de manière systématique, des analyses d’écart et des analyses
d’impact.

Tenant compte de l’ensemble de ces déficiences, il est opportun de réévaluer les méthodes
existantes, au regard des domaines annexes et de proposer une manière structurée, formalisée
et outillée à même de mener une étude de planification stratégique du SI. Ceci constitue
l’objectif du présent travail de recherche dont les résultats sont exposés dans ce mémoire.

1.3 Généralités sur la planification stratégique

1.3.1 Stratégie et planification stratégique


La Stratégie est définie comme étant “La définition des objectifs stratégiques à long terme,
l’adoption de plan d’action et l’allocation des ressources nécessaires pour atteindre ces

6
Chapitre 1 : Planification Stratégique des Systèmes d’Information

objectifs” (Chandler, 1988) et comme étant « L’art de construire l’avantage concurrentiel


durable et défendable » (Porter, 1985).

L’une des définitions les plus exhaustives est celle donnée par (Hax, 1996), « Un framework à
la base duquel une organisation confirme sa continuité tout en facilitant son adaptation aux
changements de l’environnement ».

Dans l’ensemble des définitions, la planification stratégique est focalisée sur les trois questions
suivantes : Où sommes-nous ? Où veut-on aller ? Quel est le chemin pour y arriver ? (Lakhdissi,
2011).

1.3.2 Enjeux de la planification stratégique


La planification stratégique est un processus complexe et continu de changement
organisationnel. Les composantes décrites ci-dessous doivent être réunies pour constituer un
processus complet et efficace de planification stratégique.

La planification stratégique selon (Hax, 1996) :

- est axée sur l’avenir et se concentre sur l’anticipation de l’avenir. Elle examine les moyens
à mettre en œuvre pour faire en sorte que la réalité des entreprises soit différente dans un
délai de 5 à 10 ans. Elle vise à façonner l’avenir de l’organisation en se fondant sur les
caractéristiques que cet avenir est susceptible de présenter.
- repose sur une analyse soigneuse des tendances prévues ou prédites et des divers scénarios
d’avenir possibles, ainsi que sur l’analyse des données internes et externes.
- est souple et vise l’orientation selon une perspective globale. Elle aligne l’organisation sur
son environnement, en établissant un contexte pour l’accomplissement des objectifs et en
définissant un cadre et une direction pour la réalisation de l’état futur souhaité de
l’organisation.
- crée un cadre pour obtenir un avantage concurrentiel au moyen d’une analyse minutieuse
de l’organisation, de son environnement interne et externe, et de son potentiel. Ceci permet
aux organisations de faire face aux tendances, événements, défis et opportunités qui se
présentent, dans le cadre de la vision et de la mission qu’elles ont élaborées au moyen du
processus de planification stratégique.
- est un processus qualitatif, impulsé par l’idée. Elle engage l’organisation dans un dialogue
continu et vise à dégager une vision et une focalisation organisationnelles claires.
- permet aux organisations de se focaliser, car c’est un processus d’auto-analyse constant et
dynamique.
- est un processus permanent et continu d’apprentissage, un dialogue organisationnel, qui va
au-delà de la réalisation d’un ensemble d’objectifs prédéfinis. Elle vise à modifier la façon
de penser et d’opérer de l’organisation et crée une organisation autodidacte.
- a, lorsqu’elle est efficace, des incidences dans tous les domaines d’activité de l’organisation
et s’intègre dans les principes et la culture de l’organisation.

7
Chapitre 1 : Planification Stratégique des Systèmes d’Information

1.3.3 Planification stratégique des Systèmes d’Information


La planification stratégique SI (PSSI) est définie dans (Lederer, 1988) comme étant « le
processus d’identification d’un portefeuille d’applications/projets SI qui peuvent aider une
organisation à atteindre sa stratégie métier ». Elle se focalise sur la feuille de route (roadmap)
d’initiatives, projets et transformations SI qui doivent s’appliquer à l’existant en vue :

- d’aligner le SI avec les besoins et contraintes du métier ainsi qu’avec sa stratégie


- d’utiliser le système d’information pour impacter la stratégie métier
A cause de la complexité des SI et la diversité des approches technologiques des entreprises,
plusieurs méthodes existent pour structurer le processus de planification stratégique SI et
plusieurs techniques permettent de traiter des aspects particuliers de cette discipline. (Vitale,
1986) classifie les méthodologies selon deux catégories :

- Méthodes d’impact : essayant d’aider le métier à créer un impact positif et à assurer la


transformation
- Méthodes d’alignement : qui se focalisent sur l’alignement du SI pour répondre au mieux
aux exigences métier et supporter les objectifs stratégiques
Parmi les méthodes les plus utilisées dans le domaine de la planification stratégique SI, il y a la
Chaîne de Valeur de Porter (Porter, 1985), les scénarios métiers (Schwartz, 1991), Business
Systems Planning (BSP) (Wiseman, 1988) et Critical Success Factors (CSF) (Rockart 1981).
Ces techniques peuvent être groupées de manière complémentaire pour définir une
méthodologie comme CCTA (CCTA, 1988) (CCTA, 1999) et Boar (Boar, 2001). Dans le
monde francophone, la méthode la plus utilisée s’appelle RACINES (Balantzian, 1992) qui a
été initiée par le gouvernement français.

De nombreux cabinets de conseil et sociétés de services SI utilisent aussi leurs propres


méthodes et méthodologies. C’est le cas de Method/1 d’Arthur Andersen et Summit de Coopers
and Lybrand (Lederer, 1988).

1.4 Description des méthodologies PSSI


Cette section donne une définition de « méthodologie » en la comparant avec « Framework »
et « méthode ». Ensuite, elle décrit les méthodes les plus utilisées dans le domaine de la
planification stratégique SI et en donne une synthèse.

1.4.1 Méthodologie, méthode et Framework


Une méthodologie est « Une approche documentée pour mener des activités et le corpus de
méthodes, règles et postulats employés dans une discipline donnée » (Merriam, 2010). Elle est
également décrite comme « Une approche documentée pour mener des activités de manière
cohérente, consistante, responsable et répétable » (TEAF, 2000). Une méthode est définie,
quant à elle, comme « Une façon, technique ou procédé pour réaliser quelque chose » (Merriam,
2010).

8
Chapitre 1 : Planification Stratégique des Systèmes d’Information

Ces définitions permettent de conclure qu’une méthodologie peut être une composition
structurée de méthodes, règles et principes. Elle a un périmètre plus large et plus abstrait qu’une
méthode.

Le tableau 1 résume les différences entre ces trois concepts.

Méthode Méthodologie Framework


Périmètre Spécifique Général Général
Niveau Concrete Abstraite Abstrait
d’abstraction
Nature Prescriptive Prescriptive Descriptive
Composition Simple Composite Composite
Processus Optionnel Obligatoire Optionnel
Description de Faible Moyenne Détaillée
produits/livrables
Tableau 1 : Comparaison entre méthode, méthodologie et framework (Lakhdissi, 2011)
La distinction entre une méthodologie et un framework doit également être précisée. (FEAF,
1999) définit un framework comme « une structure logique pour classifier et organiser des
informations complexes ». Un framework est perçu généralement en tant que cadre ou structure
qui donne des lignes directrices concernant une discipline sans être prescriptive et sans
précision de processus structuré pour réaliser les tâches et activités.

1.4.2 Analyse de la Chaîne de Valeur


Il s’agit d’une méthode élaborée par Michael Porter en 1985 (Porter, 1985). D’après Porter,
chaque entreprise est un ensemble d'activités qui sont effectuées en vue de concevoir, produire,
commercialiser, livrer et assurer le soutien de son produit ou service. Toutes ces activités
peuvent être représentées en utilisant une chaîne de valeur (Figure 1).

Figure 1 :Figure 16 :de


Exemple Chaîne
chainededevaleur
valeuren(Porter,
Informatique
1985)

9
Chapitre 1 : Planification Stratégique des Systèmes d’Information

L'analyse de la chaîne de valeur :

- est une forme d'analyse d'activité des entreprises qui décompose une entreprise par
rapport à ses activités et non à son organisation. Les systèmes d'information à mettre en
place pour répondre aux besoins métier sont déduits de cette analyse
- aide à l'élaboration de systèmes d'information qui augmentent le bénéfice global à la
disposition d'une entreprise.
- aide à identifier le potentiel d'avantages commerciaux mutuels des entreprises, dans les
mêmes secteurs ou dans des secteurs connexes. Ce potentiel est disponible à partir de
l'échange d'information.
- concentrée sur la valeur ajoutée des activités commerciales qui est indépendante de la
structure organisationnelle.

La principale force de l'analyse de la chaîne de valeur, c'est qu'elle se concentre sur la valeur
directe ajoutée d’activités d'une entreprise et donc l’emplacement des systèmes d'information
dans le domaine de la valeur ajoutée plutôt que de réduction des coûts.

Parmi les faiblesses de cette méthodologie c’est qu’elle fournit seulement un modèle abstrait
de l'information d'une entreprise et ne répond pas aux questions de la mise en œuvre et elle se
focalise sur les opérations plutôt que sur les données, donc elle ne sert pas à définir une structure
de données pour l’entreprise. Le concept de base d'une chaîne de valeur est difficile à appliquer
à des organisations non-manufacturières, où le produit n'est pas tangible. Elle ne fournit pas,
donc, un support automatisé pour l'analyse comparative.

1.4.3 Facteurs critiques de succès


L’analyse des facteurs critiques de succès peut être considérée comme une méthode
d’alignement et d’impact. Les Facteurs Critiques de Succès (FCS) sont « l’ensemble des
éléments dont les résultats, lorsqu’ils sont satisfaisants, garantissent la performance
concurrentielle de l’organisation ». L’analyse des facteurs critiques de succès, proposée par
(Daniel, 1961) et popularisée par (Rockart, 1979), vise à permettre un alignement stratégique
des processus de l’entreprise. Elle aide, aussi, à une meilleure compréhension et, donc, à un
plus large consensus sur les enjeux importants et les priorités d’une entreprise.

Les FCS sont maintenant utilisés aussi bien dans la planification stratégique métier et SI, que
dans l’évaluation de la performance et pour déterminer les besoins en matière d’informations.

L’analyse des FCS fournit une méthode très puissante permettant la concentration sur
l'information clé qui définit les exigences d’une organisation, d’une unité d'affaires ou d'un
gestionnaire. Cela permet, à la direction, de concentrer les ressources sur le développement de
systèmes d'information autour de ses exigences.

L’analyse des FCS par elle-même ne suffit pas pour effectuer une planification stratégique
globale des systèmes d’information, elle ne définit pas une architecture des SI et ne fournit pas
des soutiens à l'analyse. Les FCS portent principalement sur le contrôle de gestion et ont donc
tendance à être concentrés sur l’analyse interne plutôt que sur la création de valeur.

10
Chapitre 1 : Planification Stratégique des Systèmes d’Information

L’analyse des FCS reflète en partie le style de gestion dans un cadre particulier. Bien que
l’analyse des FCS facilite l'identification des systèmes d'information qui répondent aux
principaux besoins d'information d'une unité d'affaires / organisation, la valeur, provenant de
ces systèmes, n’est pas évaluée.

1.4.4 Planification des systèmes métier


La Planification des Systèmes d’Affaire ou le Business Systems Planning (BSP) est une
méthode d'analyse, de la définition et de la conception d'une architecture d'information des
organisations. Elle a d'abord été publiée par IBM en 1981, bien que le travail initial sur les BSP
a commencé dans le début des années 1970. Au début, c'était pour IBM à un usage interne. Plus
tard, elle a été mise à la disposition des clients et cette méthode est devenue un outil important
pour de nombreuses organisations (Wiseman, 1988).

C'est une méthode complexe du traitement de données, processus, stratégies, objectifs et de


l’organisation qui sont interconnectés. Les processus métiers sont analysés pour déterminer les
besoins de données et, ensuite, les classes de données. Les classes de données semblables sont
combinées pour développer des bases de données. Le plan final BSP décrit une architecture
globale des systèmes d'information ainsi que le calendrier d'installation de systèmes individuels.

Dans le cadre de la planification du haut vers le bas (descendante), les cadres dirigeants
exposent la mission et les objectifs stratégiques de l’organisation devant un groupe d’étude
composé de gestionnaires, de professionnels et de spécialistes des systèmes d’information. Par
la suite, le groupe d’étude s’entretient systématiquement avec les gestionnaires de l’ensemble
de l’organisation en vue de déterminer comment on met en œuvre ces objectifs dans les
fonctions de base (marketing, production, etc.) et dans les processus de l’entreprise (saisie des
commandes, expédition, réception, etc.). Puis, le groupe examine les types ou catégories de
données qu’exigent ces processus élémentaires, et finalement, il conçoit l’architecture des
systèmes d’information qui définit les relations entre les classes de données et les processus de
l’entreprise.

La mise en œuvre du bas vers le haut (ascendante) exige que les activités de développement
d’applications soient effectuées par les utilisateurs finaux et les professionnels des systèmes
d’information. Il s’agit des applications particulières des systèmes d’information (comme le
traitement transactionnel des ventes) qui utilisent la conception des bases de données
déterminée par l’architecture des systèmes d’information. Ainsi, chaque application devrait
servir une fonction de l’entreprise et appuyer la mission et les objectifs de l’organisation.

La Planification des Systèmes d’Affaires (PSA) est une méthode exhaustive, bien documentée
et couramment utilisée. Elle fait participer les cadres dirigeants et les utilisateurs finaux au
processus de planification des systèmes d’information.

D’après la PSA, les objectifs et les processus de l’entreprise constituent les fondements de
l’architecture des systèmes d’information. Cette architecture privilégie une approche de base
de données partagées et la gestion des données comme une ressource de l’entreprise.

11
Chapitre 1 : Planification Stratégique des Systèmes d’Information

La méthode BSP ou PSA a l’inconvénient d’être une méthode laborieuse dont les
recommandations ne sont pas faciles à mettre en œuvre.

1.4.5 Planification stratégique des systèmes


La planification stratégique des systèmes (SSP) est connue aussi sous PROPlanner et
développée par Robert Holland (Pant 1995), cette méthode est similaire à BSP. Un modèle de
fonction métier est défini par l'analyse des principaux domaines fonctionnels d'une entreprise.
Une architecture de données est dérivée du modèle de la fonction métier en combinant les
exigences d'informations dans les entités de données génériques et des objets de base de
données. De nouveaux systèmes et leurs calendriers d'exécution sont dérivés de cette
architecture. Cette architecture est alors utilisée pour identifier de nouveaux systèmes et leur
calendrier de mise en œuvre.

Bien que des étapes dans la procédure de SSP soient similaires à ceux de la BSP, une différence
majeure entre les SSP et BSP est une manipulation automatique des données recueillies au cours
du processus PSSI. Le logiciel produit des rapports dans un large éventail de formats et avec
différents niveaux de détail. Les rapports d'affinité montrent les fréquences d'accès aux données
et aux rapports de clustering qui donne des orientations pour la conception de base de données.
Les utilisateurs sont guidés à travers les menus on-line de collecte de données et la maintenance.
Le logiciel fournit également une interface de données dictionnaire de données SSP partagée
avec un dictionnaire de données existantes ou d'autres outils de conception automatisée.

Les étapes de la méthode SSP sont illustrées sur la figure 2.

Figure 2 : Etapes de la méthode SSP (Pant, 1995)


Pour les avantages et les inconvénients, elle est similaire à la Planification des Systèmes
d’Affaires (BSP).

12
Chapitre 1 : Planification Stratégique des Systèmes d’Information

1.4.6 Information Engineering


Cette méthode a été développée par (Martin, 1982) et fournit des techniques pour les entreprises
pour construire des modèles de données et de processus. Ces modèles se combinent pour former
une vaste base de connaissances qui est utilisée pour créer et maintenir des systèmes
d'information. La philosophie de base qui sous-tend cette technique est l'utilisation de
techniques structurées dans l'ensemble des tâches relatives à la planification, l'analyse, la
conception et la construction de systèmes d’information d’entreprise. Ces techniques
structurées donnent lieu à des systèmes d'information intégrés. L’IE repose sur une pyramide
des systèmes d'information d'une entreprise. Une telle pyramide est indiquée ci-dessous. La
pyramide a trois côtés qui représentent les données de l'organisation, les activités de
l'organisation effectuées en utilisant les données et la technologie qui est employée dans la mise
en œuvre des systèmes d'information.

Figure 21 :La pyramide du système d’informations (James Martin, 1989)


Figure 3 : Vue globale de la méthode Information Engineering (Martin, 1982)
Cette méthode ne définit pas par contre comment chaque étage ou couche est décrit et comment
le lien est fait entre les différentes couches.

1.4.7 Méthode Method/I


Méthode / 1 (Andersen, 1992) est une approche multidimensionnelle pour la PSSI. La couche
supérieure est la méthode elle-même, la couche intermédiaire de techniques supporte la
méthodologie, et une couche inférieure formée d'outils qui prennent en charge les techniques.

Les techniques prise en charge par cette méthode sont les diagrammes de flux, l’analyse
matricielle, la décomposition fonctionnelle, les groupes de discussion et des études Delphi.

13
Chapitre 1 : Planification Stratégique des Systèmes d’Information

Cette méthodologie a cinq objectifs distincts (Lederer, 1992):

- Identifier les informations dont l'organisation a besoin


- Trouver de nouveaux débouchés pour l'utilisation de l'information afin d’obtenir un
avantage concurrentiel.
- Définir une stratégie informatique globale pour satisfaire les objectifs IT de
l'organisation.
- Définir les données, les applications, la technologie et les exigences
organisationnelles pour soutenir l’ensemble de la stratégie IT.
- Définir les activités nécessaires pour satisfaire les exigences ci-dessus et mettre ainsi
en œuvre la stratégie globale de l'information.

Cette méthode ne définit pas la forme et la structure des livrables à produire par les différentes
phases et ne structure pas les liens entre les différents domaines du SI.

1.4.8 Méthode RACINES


La méthode RACINES (Balantzian, 1992) est la méthode la plus utilisée en France et au Maroc
pour la réalisation des schémas directeurs ou des plans stratégiques. Développée par le ministère
de l'Industrie français depuis 1976, elle a pour objectif de faciliter la planification et la
rationalisation des développements informatiques dans les grandes entreprises. La démarche
RACINES représente un cadre global d'analyse tenant compte des perspectives d'évolution de
l'organisation, de la cohérence globale du système d'information, de la place de l'informatique
et de l'état actuel des différentes technologies.

Les étapes du plan stratégique

Les étapes de la planification stratégique selon la méthode Racines sont synthétisées sur le
tableau 2 et détaillées en annexe 1.

Les scénarios types

La méthode des scénarios vise à définir plusieurs stratégies pour atteindre les objectifs fixés par
le plan stratégique. Elle met également en évidence les enjeux économiques de chaque stratégie
possible. Trois types de scénarios peuvent être distingués :

(1) Le scénario tendanciel propose le renforcement des moyens existants pour atteindre les
objectifs visés. Il s'inscrit dans le cadre de la continuité du système d'information de l'entreprise.
(2) Le scénario contrasté se veut novateur. Il prend appui sur les innovations technologiques et
propose une redéfinition du système d'information. (3) Le scénario de compromis propose une
solution intermédiaire entre les deux scénarios précédents.

Les plans d'actions

Les plans d'actions permettent de préciser les modalités de mise en œuvre des développements.
Ils sont en principe limités aux trois premières années. Ils prévoient les études et réalisations à
entreprendre ainsi que les exploitations à effectuer. Ils fixent les échéances et valorisent les
investissements à réaliser.

14
Chapitre 1 : Planification Stratégique des Systèmes d’Information

Tableau 2 : Etapes de la méthode RACINES (Balantzian, 1992)


Les procédures de suivi

Les procédures de suivi consistent à exploiter les valeurs fournies par différents indicateurs et
à tenir à jour un répertoire actualisé des applications, des projets et études et à rapprocher
l'activité observée des prévisions propres au scénario retenu. Il est alors possible de vérifier les
conditions d'exécution du plan, d'actualiser les objectifs du plan en cours et des suivants, de
redéfinir, si nécessaire, les priorités et, éventuellement, de déclencher un nouveau plan
stratégique.

Les points de contrôle

Ils ont lieu après chaque étape et permettent de vérifier que toutes les actions à mener ont été
réalisées et que toutes les décisions nécessaires ont été prises avant l'étape suivante.

1.5 Synthèse des méthodologies PSSI


La plupart des techniques, approches et méthodes relatives à la planification stratégique SI
datent des années 1980 et 1990 et sont orientées métier plus que SI. Les nouvelles méthodes
comme Praxeme reposent fortement sur les anciennes. Le tableau suivant présente un
benchmark de comparaison entre ces méthodes (Wilton, 2007) (Lakhdissi, 2011).

15
Chapitre 1 : Planification Stratégique des Systèmes d’Information

Méthodes Classification Domaines Techniques / Outillage Cycle Lien autres


couverts Méthodes de vie méthodes
Chaine de Méthode
Métier, SI Non Non Non Non
valeur d’impact
Critical
Méthode
Success
d’alignement et Métier, SI Non Non Non Non
Factors
d’impact
(CSF)
Méthode Métier, SI,
BSP/SSP Oui Oui Oui Non
d’alignement Technologie
Oui.
Information Méthode Métier, SI,
Oui Oui 1 Oui Utilisation de
Engineering d’alignement Technologie
CSF
Oui.
Méthode / 1
Méthode Métier, SI, Utilisation de
Oui Oui 2 Oui
d’alignement Technologie la Chaine de
Valeur
Méthode
Racines Métier, SI Non Non Oui Non
d’alignement
Tableau 3 : Comparatif des méthodes de planification stratégique
Les méthodologies utilisées pour mener à bien une étude de plan stratégique ou de schéma
directeur sont relativement classiques. Les sociétés spécialisées dans ce genre de prestations ou
les Directions des Systèmes d'Information (DSI) qui se lancent débutent, le plus souvent, par
une phase de diagnostic, qui revient sur l’historique de ce qui a été fait et qui analyse l’existant.

En découle une photographie très précise des nouveaux besoins exprimés. Par la suite, on arrive
à la définition d'une cible pour le nouveau système d'information. L'élaboration d'un plan
d'action pluriannuel - ou stratégie de mobilisation des ressources - garantit ensuite les moyens
de la mise en œuvre, du suivi et de l'actualisation du plan stratégique.

Ces démarches classiques souffrent de l’absence d’un référentiel méthodologique qui permet
non seulement de bien cadrer les études de plan stratégique mais aussi d’assurer un lien entre
plusieurs plans stratégiques du même système d’information. De ce fait, la plupart des plans
stratégiques réalisés restent obsolètes et leur cadre d’application très limité.

D’autres inconvénients de ces démarches peuvent être relevés au niveau :

- Linéarité : ceci implique un manque de visibilité sur les livrables du plan stratégique
pendant le déroulement du projet.
- Coût en charge et délais : coûteuse surtout par le fait qu’on peut arriver à la fin avec des
livrables non conformes puisqu’il y a peu de livrables intermédiaires.

1
Information Engineering Workbench
2
Outil Foundation

16
Chapitre 1 : Planification Stratégique des Systèmes d’Information

- Manque de visibilité sur la cible : même si suite à un plan stratégique, le portefeuille de


projets pour arriver à la cible est bien clair, le détail du SI cible ainsi que les phases
intermédiaires ne sont pas abordés de manière concrète. Il y a plus de recommandations
pour la cible qu’une définition claire et détaillée de la cible et des étapes intermédiaires
- Insuffisance au niveau de l’étude d’impact et de dépendances : l’étude de l’impact des
transformations recommandées dans le cadre du plan stratégique sur le système existant
n’est souvent pas à un niveau de profondeur satisfaisant par manque de référentiels de
l’existant contenant les dépendances des différents éléments du SI.
- Manque de profondeur par rapport à la partie technique : généralement les aspects
techniques sont abordés de manière superficielle dans l’étude, les choix techniques et
technologiques sont pris à la légère même s’ils sont impactants.
- Manque de référentiel méthodologique et manque de méta-modèle pour décrire, de
manière standard, les différents éléments du SI.
- Absence de feuille de route ou Roadmap : ce qui ne permet pas de visualiser la situation
du SI dans les phases intermédiaires et à la fin de la mise en œuvre du plan stratégique
- Démarche non outillée : il n’y a pas généralement d’outils qui supportent ces démarches
(à part SSP) et industrialise les différentes activités et livrables.

1.6 Conclusion
Les intervenants pour les méthodologies de planification stratégique sont, la plupart des cas,
des consultants experts en stratégie et gouvernance des systèmes d’information. Ils disposent
souvent de peu de retours d’expériences relatifs aux problèmes techniques et technologiques
associés au Système d’Information ou aux projets opérationnels de refonte ou d’évolution. Or,
l’évolution, la diversité et la complexité des technologies liées aux SI exigent une maîtrise de
la dimension organisationnelle, stratégique et technologique. C’est un véritable impératif pour
la réussite de toute étude de plan stratégique pragmatique et cohérente.

Il est donc nécessaire, pour mener à bien la planification stratégique SI, de disposer d’une vue
globale et cohérente traitant tous les éléments du SI en lien avec le métier. L’AE peut aider dans
ce sens et permet de traiter, de manière exhaustive, le SI et le métier.

17
Chapitre 1 : Planification Stratégique des Systèmes d’Information

18
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Chapitre 2 : Architecture d’Entreprise


et Planification Stratégique SI

19
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.1 Introduction
L’Architecture d’Entreprise est une discipline plus récente que la planification stratégique qui
fournit un cadre structuré pour définir, structurer et faire évoluer les architectures des SI en
cohérence avec le métier.

Dans ce chapitre, l’objectif est d’introduire la discipline d’Architecture d’Entreprise en termes


de définition, d’enjeux et d’objectifs. Par la suite, une description sera faite des frameworks
d’architecture en établissant le lien avec les autres domaines du SI.

2.2 Définition et objectifs de l’Architecture d’Entreprise

2.2.1 Définition de l’Architecture d’Entreprise


Le standard ISO42010 et l’Open Group définissent l’architecture comme étant « L’organisation
fondamentale d’un système en termes (TOGAF, 2011) :

- de ses composants,
- des relations entre ces composants et leurs liens avec leur environnement
- des principes qui gouvernent leur conception et évolution ».

Comme le montre la figure 4, trois aspects ressortent de cette définition qui caractérisent
l’architecture d’entreprise (Lakhdissi, 2011) :

- L’aspect descriptif de l’architecture : « l’organisation fondamentale du système, ses


composants et leurs relations ». Cet aspect se traduit souvent par des cartographies en
forme d’inventaires et diagrammes.
- L’aspect prescriptif de l’architecture : « les principes qui les gouvernent ». Ce qui est
traduit par les règles qui régissent la conception et l’évolution des éléments
d’architecture
- L’aspect actif de l’architecture : « les évolutions ». Cet aspect est décrit sous forme de
transformations, actions et projets d’évolution de l’architecture.

L’architecture d’un système est constituée typiquement de :

- Une description avec revue de la situation existante


- Une vision en termes de prescription ou description détaillée de la situation cible
- Une feuille de route qui décrit comment partir de l’existant pour atteindre la cible

L’Architecture d’Entreprise cherche à définir ces aspects pour l’ensemble des éléments
d’architecture de l’entreprise intégrant les aspects stratégie, organisation, métier, SI et
technologique ainsi que les liens et dépendances entre ces éléments.

20
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.2.2 Objectifs et enjeux de l’Architecture d’Entreprise


L’AE cherche à réaliser deux objectifs principaux :

- Avoir une meilleure visibilité sur l’existant pour mieux le cerner, le diagnostiquer et le
revoir et pour maîtriser les impacts de son évolution.
- Définir une vision formalisée pour le futur intégrant une description de la situation cible
et les actions à mener pour y arriver

Cible

Exigences, Stratégie, Enjeux, Contraintes,


Facteurs d’impacts internes et externes

Gouvernance et Gestion
du Changement
Planification de la
migration
Architecture descriptive Inventaires
• Métier

Opportunités /
• SI (Applications – Données) Matrices

Solutions
• Technologie
Diagrammes

Architecture prescriptive
• Principes
• Standards
• Règles
• Bonnes Pratiques

Existant

Figure 4 : Contenu de l'Architecture d'Entreprise


La discipline d’Architecture d’Entreprise est née à la fin des années 80 (Zachman, 1987). Elle
répond à un ensemble d’enjeux et de motivations qui sont liés à la complexification des
systèmes d’information avec une diminution de leur valeur ajoutée pour le métier :

- Faible visibilité du métier

Le métier des entreprises est souvent compris et maitrisé par les opérationnels chacun dans son
domaine et sans vision globale et partagée. Il est, dans certains cas, décrit de manière textuelle
ou graphique dans le cadre de procédures qui ont très souvent une logique très opérationnelle,
très dépendantesde l’organisation, dans une logique silo et très procédurale.

21
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Le besoin de modéliser le métier de manière globale et en lien avec le SI et de partager cette


modélisation et la faire évoluer est important pour maitriser l’existant et les transformations et
impacts.

- Des SIs de plus en plus complexes et non maitrisés globalement

Le SI est devenu de plus en plus complexe avec la multiplication, des infrastructures, des
technologies et des applications, chacune apportant son lot de contraintes et d’exigences. En
plus, avec les évolutions apportées pour répondre aux besoins métiers, l’historique devient lourd
et de plus en plus opaque. A cela s’ajoutent les parties invisibles du SI à savoir les batchs et les
interfaces d’intégration, le SI technique. Pour pouvoir maitriser le SI dans toute sa complexité
et en tenant compte de son lien avec le métier il est nécessaire de le modéliser. Cette maitrise
permet, au-delà du diagnostic des défaillances, d’identifier les opportunités de simplification
ou de réutilisation dans le SI (Caseau, 2007).

- Fort impact des transformations

Les transformations qui touchent le métier et par la suite le SI sont de plus en plus nombreuses
et de plus en plus rapides. Pour maitriser l’impact de ces transformations, il est nécessaire de
maitriser l’organisation, les activités métier et leurs liens avec les différents éléments du SI. Ces
liens et dépendances permettent de mener des analyses d’impact à chaque fois qu’une
transformation s’opère pour mieux maitriser ses conséquences (Perks, 2003).

- Faible alignement du SI avec le métier et la stratégie

Au fur et à mesure de l’évolution du SI, on s’écarte de la ligne stratégique qui lui a été tracée
pour se retrouver avec un SI à fort potentiel technique mais avec une faible valeur ajoutée
métier. Cet état des lieux est dû au fait que souvent on ne fait pas le lien entre le patrimoine et
les initiatives SI et ce qu’elles permettent de couvrir comme périmètre métier ou ce qu’elles
réalisent comme objectif stratégique. L’Architecture d’Entreprise peut être utilisée comme
moyen d’évaluation de l’alignement stratégique du SI (Luftman, 2000) (Bounabat, 2006)
(Novica et al, 2006).

- Faible agilité métier et SI

Les entreprises doivent de plus en plus se concentrer sur leur cœur métier afin d’optimiser leurs
opérations et assurer une meilleure satisfaction client. Or, le métier quel qu'il soit, banque,
télécoms ou encore industrie, est amené à changer plus souvent. En effet, les besoins des clients,
les réglementations évoluent constamment et l'entreprise doit s’y adapter. A cela s'ajoute le fait
que ces changements s'enchaînent de plus en plus vite : le défi auquel les entreprises doivent
répondre n'est plus d'être les plus grosses mais bien d'être les plus rapides (McCoy et al, 2006).

Le système d'information est souvent un frein important à l'évolution d'une entreprise. De plus
en plus, cette dernière dépend des technologies ; cela n'est pas sans conséquence sur le métier.

- Faible gouvernance du SI et du métier

22
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Pour assurer une bonne gouvernance du SI et du métier, il est important de maitriser les
différents éléments qui constituent le SI ainsi que leur lien avec les processus métier. Ceci est
de plus en plus une obligation de gestion et de réglementation.

2.3 Activités de l’Architecture d’Entreprise


Dans le cadre de la définition de l’Architecture d’Entreprise, il est question de mener les
activités suivantes (Figure 5) :

- Description de la situation actuelle : Cette description se fait via des diagrammes ou


des inventaires (catalogues) et permet d’avoir une bonne visibilité sur l’existant sur les
différentes couches d’architecture
- Analyse d’écart et diagnostic de l’existant : La description exhaustive de l’existant
permet de relever les écarts possibles avec la stratégie, en termes de couverture ou avec
les bonnes pratiques. Ceci se fait notamment via les matrices de dépendances.
- Description de la situation cible : Cette description est importante pour construire une
vision détaillée de la cible qui est décrite de la même manière que l’existant, en utilisant
des catalogues et des diagrammes.
- Elaboration du plan de transformation : Sur la base de l’écart entre l’existant et la
cible, des transformations sont identifiées et permettent d’alimenter le plan d’action.
Une analyse d’impact se fait à ce niveau pour maitriser les impacts des transformations
et utilise les matrices de dépendance.

• Description de l’architecture • Matrices de


(Livrables) dépendance,
• Analyse d’écart

Architecture Diagnostic de
actuelle l’existant

Roadmap de Architecture
transformation cible
• Opportunités et • Description de
solutions l’architecture
• Plan de migration • Prescriptions de
• Gouvernance et l'architecture
conduite
du changement

23
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Figure 5 : Activités de l’Architecture d’Entreprise

2.4 Architecture d’Entreprise Descriptive


L’architecture d’entreprise représente la manière dont l’entreprise opère et doit se transforme.
Elle sert à piloter la transformation. Elle réunit l’ensemble des acteurs de l’entreprise et facilit
e leur synergie (TOGAF, 2011).

Elle fournit une cible, une analyse des écarts et un planning de migration (la roadmap). C’est
un processus dynamique et itératif (Lankhorst, 2005).

Une Architecture d’Entreprise se compose de plusieurs couches, chaque couche ayant une
influence sur l’autre : l’Architecture métier, l’architecture système d’information et
l’architecture technique ou technologique (TOGAF, 2011) (Zachman, 1987).

- Architecture Métier : l’Architecture Métier décrit la façon d’organiser et de gérer


l’entreprise selon plusieurs volets :
- Volet stratégique
- Volet organisationnel
- Volet informationnel
- Volet processus
- Architecture du Système d’Information : l’Architecture du système d’information
comprend l’Architecture Applicative et l’Architecture de données. Elle décrit la façon
d’organiser le système d’information. L’Architecture Applicative (ou d’Application)
fournit le plan de déploiement des applications et leurs interactions avec les processus
principaux de l’entreprise. L’Architecture des données décrit l’organisation logique et
physique ainsi que la gestion de ressources consommées par les données. Elle est appelée
aussi Architecture d’Information.
- Architecture Technique : l’Architecture Technique est la manière d’organiser a partie
physique du système d’information. Elle décrit les infrastructures destinées à soutenir le
développement des principales applications métier de l’entreprise.

La description de l’AE peut se faire selon (TOGAF, 2011) de trois manières différentes
(appelées également artéfacts d’architecture):

- Diagramme : représentation riche et composite avec la possibilité d’avoir de la


perspective par acteur. Par exemple : le diagramme de base de données pour
l’architecture de données.
- Inventaires : représentation linéaire mais riche en information sur un élément
d’architecture en particulier. Par exemple : une liste de serveurs dans l’entreprise.
- Matrices : croisement de deux éléments d’architecture faisant ressortir les liens. La
matrice est utile pour les analyses d’écart et d’impact. Par exemple : un fichier excel ou
il y a les différents liens entre acteurs et rôles dans l’entreprise.

24
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.5 Architecture d’Entreprise Prescriptive


Les prescriptions sont des directives qui permettent de faire évoluer l’existant et de cadrer la
cible et les transformations et qui intègrent selon (TOGAF, 2011).

- Les principes : obligatoires et directeurs (Ex : Privilégier l’acquisition au


développement spécifique)
- Les standards : ouverts et définis par le marché (Ex : le standard PMBOK)
- Les règles : les règles qui régissent la définition et l’évolution de l’architecture sur un
volet donné (Ex : règles de sécurité, règles de développement)
- Les bonnes pratiques : ce qui est capitalisé en termes de retour d’expérience positive
(Ex : bonnes pratiques de gouvernance SOA).

Ces prescriptions peuvent concerner les différentes couches d’architecture qu’elles soient :

- Métier : méthodologie SIX SIGMA avec ses différents niveaux de maturité (Yellow,
Green, Black Belt).
- SI : Bonnes pratiques de développement et de tests
- Technologies : Bonnes pratiques de sauvegarde/restauration sur les data centers.

Enfin, ces prescriptions peuvent toucher des aspects transverses tels que la sécurité,
l’intégration ou la performance.

2.6 Frameworks d’Architecture d’Entreprise

2.6.1 Définition d’un framework d’AE


Un Framework (cadre) d'architecture est une spécification sur la façon d'organiser et de
présenter l'Architecture d’Entreprise d'un organisme. C’est une structure de référence qui
définit les modèles ou artéfacts d’architecture suggérés. Elle décrit comment ces artefacts sont
liés les uns aux autres, et fournit des définitions génériques de la forme qu’auront ces artefacts
(Schekkerman, 2004). Il contribue à structurer et à formaliser la modélisation de l’entreprise
(TOGAF, 2011).

On distingue trois volets sur lesquels le Framework d’AE apporte sa valeur ajoutée :

- Produit d’architecture : Décrit les livrables qui permettent de modéliser l’entreprise


en termes de forme, de structure et de lien et dépendance. Ceci se fait à travers un
Framework de contenu et un métamodèle des éléments d’architecture. Cela correspond
à la partie descriptive de l’AE.
- Processus d’architecture : Décrit comment ces livrables sont produits à travers un
cycle méthodologique. La méthodologie décrit les phases de production des livrables en
termes d’entrants, d’activités et de sortants. Le processus d’architecture permet
également de définir l’organisation et le cadre de gouvernance nécessaire pour assurer
la pérennité et le bon déroulement de la méthodologie.

25
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

- Exigences d’architecture : Regroupent les contraintes et exigences qui régissent les


processus et les produits d’architecture. Ces exigences peuvent être des principes, des
standards, des règles et des bonnes pratiques

Dans le détail, un Framework d’architecture peut offrir :

- Framework de contenu : Il définit les couches, les vues, les questions et les aspects
gérés dans la description d’architecture. L’importance de ce Framework est d’organiser,
de classifier et lier les éléments d’architecture et les artefacts. Les éléments à décrire et
leurs relations sont structurés dans un métamodèle (décrit dans la section suivante). Le
Framework de contenu peut être vu comme une grille bidimensionnelle où les lignes
représentent les couches et les colonnes représentent les classifications.
- Metamodèle : C’est l’élément névralgique de la méthodologie et de la description
d’architecture. Il garantit l’exhaustivité de tout le travail de l’architecture et de la
cohérence et l’alignement avec les couches d’architecture. Il contient des définitions des
éléments d’architecture, des définitions de leurs attributs et de leurs relations.
- Méthodologie : La méthodologie d’architecture est un terme générique qui décrit toute
approche structurée pour résoudre certains ou tous les problèmes en relation avec
l’architecture.
- Modèles de référence : C’est un cadre abstrait constitué d'un ensemble interdépendant
de concepts. Ce cadre sert de référence sur un sujet donné ou par rapport à un secteur
donné. C’est une base d’inspiration pour définir les architectures cibles.
- Base de connaissances (standards, principes, règles, bonnes pratiques) : Pour gérer
les connaissances de l’entreprise, il faut établir une base de standards, principes, règles
et bonnes pratiques.
- Framework de gouvernance : C’est un cadre qui permet d’intégrer les principes de la
gouvernance. Il définit les rôles et missions liés à l’AE ainsi que les instances et les
processus de prise de décision.
- Notation : C’est une manière graphique de représenter et modéliser les éléments
d’architecture conformément aux préconisations du Framework.

2.6.2 Frameworks d’Architecture d’Entreprise de Référence


Les Frameworks d’Architecture sont des cadres de référence qui permettent de structurer le
travail d’architecture et de fournir les éléments de base et les techniques nécessaires pour
construire un référentiel d’Architecture d’Entreprise (Lillihagen, 2005). Ils ont été définis pour
des besoins spécifiques ou génériques (Schekkerman, 2004). Cette section présente les
principaux frameworks d’AE sans être exhaustive. L’objectif est surtout d’identifier le
framework le plus adapté pour supporter le besoin de planification stratégique. A noter que le
concept d’Urbanisation SI (Longépé, 2004) est considéré comme étant un framework particulier
d’AE sans pour autant qu’on le détaille à ce niveau vu que les concepts qui le sous-tendent sont
assimilables aux concepts des Frameworks AE.

26
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.6.2.1 Zachman
Conçu à l'origine par John Zachman chez IBM en 1987 (Zachman, 1987), le framework de
Zachman est un framework d'architecture d'entreprise qui définit une manière formelle et
hautement structurée de définir le système d'information d'une entreprise.

Le framework de Zachman pour l’Architecture d’Entreprise est un schéma de classification des


représentations descriptives de l’entreprise. Il se présente sous la forme d’une matrice composée
de six lignes et six colonnes, contenant toute la gamme de modèles décrivant les activités et les
fonctions des organisations. La partie horizontale de la matrice est structurée en 6 colonnes
selon lesquelles le développeur de framework pose les questions qui définissent l’entreprise.

La partie verticale présente 6 rangs/lignes qui déterminent les rôles joués par les différents
acteurs de l’entreprise. L’intersection de chaque ligne et colonne forme une cellule qui contient
un artefact d’entreprise spécifique. Zachman affirme qu’une entreprise complètement
‘architecturée’ aurait une représentation explicite qui décrit les activités actuelles et futures de
l’entreprise dans cette cellule.

Figure 6: Matrice du Framework Zachman (Zachman, 1987)


Une entreprise aussi bien décrite aurait un alignement complet de ses missions d’affaires avec
ses systèmes d’implémentation et serait pleinement efficace dans son application des
ressources, des priorités et des procédés.

Le framework Zachman a aussi généré un grand nombre d’autres frameworks similaires, pour
appliquer l’architecture d’entreprise à des domaines spécifiques. Ceux-ci incluent le FEAF
(FEAF, 1999), le TOGAF (TOGAF, 2011) et le DoDAF (DOD, 1998).

27
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.6.2.2 Framework d’architecture d’entreprise DoDAF


Le Department of Defense Architecture Framework (DoDAF) est un framework destiné au
développement d'une architecture de systèmes ou d'une architecture d'entreprise (DoD, 1998)

Le contexte militaire, à l’origine de DoDAF, est complexe et en perpétuelle évolution, d’où la


nécessité d'une analyse poussée et cohérente des besoins opérationnels et des fonctions à mettre
en œuvre.

Figure 7: Les vues du Framework d’AE DoDAF (DoD, 1998)


DoD Architecture Framework est un standard de fait défini par le DoD US et obligatoire pour
les nouveaux systèmes (à partir d'un certain montant). Il est la base des standards MODAF et
NATO-AF respectivement pour le Royaume Uni et l'OTAN.

Selon la figure 7, DoDAF couvre les trois aspects requis

- La Vue Opérationnelle qui permet de formaliser les besoins opérationnels

- La Vue Système qui permet de définir les solutions correspondantes

- La Vue des Standards Techniques qui permet de définir les standards techniques à
utiliser

2.6.2.3 Framework d’Architecture MoDAF


Le framework du ministère de la défense du Royaume-Uni MoDAF (MoD, 2008) définit, pour
la défense britannique, une manière standardisée de piloter l'architecture d'entreprise et fournit
un moyen de modéliser, de comprendre, d'analyser et de spécifier les capacités et les processus
métier.

L'objectif de MoDAF est de fournir une définition rigoureuse des systèmes lorsqu'on achète et
on intègre des systèmes de défense.

MoDAF est basé sur le framework DoDAF, en présentant des extensions sur deux points de
vue supplémentaires - stratégique et acquisition.

28
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Le framework, comme le montre la figure 8, définit des vues d'architecture qui couvrent les
objectifs stratégiques de l'entreprise, les personnes, les processus et les systèmes qui cherchent
à atteindre ces objectifs.

Figure 8: Les vues du Framework d’AE MoDAF (MoD, 2008)

2.6.2.4 Framework Fédéral d’Architecture d’Entreprise FEAF


L’Architecture Fédérale d'Entreprise (FEA) est l'architecture d'entreprise d'une agence du
gouvernement fédéral américain (FEAF, 1999) qui fournit une méthodologie commune pour
les technologies de l'information (IT) : leur acquisition, utilisation et élimination au sein du
gouvernement fédéral.

Figure 9: Le Framework FEA (FEAF, 1999)

29
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

L’objectif de cette architecture est de faire évoluer le gouvernement fédéral américain en


privilégiant le résultat. L’architecture FEA est constituée de cinq modèles de référence inter-
reliés pour identifier des opportunités de collaboration inter et intra organisations fédérales.
Cette architecture décrit les services et les activités du gouvernement fédéral fournis au citoyen,
indépendamment des agences, des bureaux et des organismes qui les fournissent.

Ce framework est conçu pour faciliter le partage d'informations et de ressources entre les
organismes fédéraux, de réduire les coûts, et d’améliorer les services aux citoyens.
FEA (V1 : 2002 – V complète 2006) fournit une méthodologie commune pour traduire la
stratégie métier en architecture IT.
La figure 9 montre comment on passe de l’architecture existante vers l’architecture cible sur les
différentes couches en s’appuyant sur les standards et en gardant en vue les principes et la vision
stratégique.

2.6.2.5 Framework TAFIM


TAFIM (Technical Architecture Framework for Information Management) est un Framework
d’AE qui a été développé entre 1986 et 1999 par le Département de Défense Américain
(TAFIM, 1996). Il définit un modèle de référence pour définir la cible de l’infrastructure d’un
Système d’Information. Il a été inspiré de POSIX du IEEE (TAFIM, 1996) et est à l’origine de
TOGAF (TOGAF, 2011).

Les buts recherchés par TAFIM sont :

- l'utilisation de principes communs, d’assertions et de terminologies dans les


définitions des composants de l'architecture technique (au niveau des Services,
Agences, et Etats-Majors).

- la définition d'une structure unique pour les composants de l'infrastructure technique


du DoD (composants du système) et la manière avec laquelle ils sont gérés.

- le développement de systèmes d'information en accord avec les principes communs


afin de permettre l'intégration et l'interopérabilité au sein du DoD.

TAFIM ne définit pas une architecture spécifique à un système. Il fournit les services, standards,
guides de conception, composants et configurations qui peuvent être utilisés pour guider le
développement d'architectures techniques qui répondent aux besoins d'une mission.

TAFIM est indépendant des applications spécifiques aux missions et de leurs données
associées. Il cherche avant tout à promouvoir l'interopérabilité, la portabilité et la juste-mesure
des systèmes d'information du DoD. TAFIM est un guide permettant, au niveau de l'entreprise,
de développer des architectures techniques qui répondent à des besoins précis. L'utilisation de
TAFIM peut :

- promouvoir l'intégration, l'interopérabilité, la modularité et la flexibilité,

- guider lors de l'achat et la réutilisation de produits du marché,

- accélérer la mise en place des technologies de l'information et abaisser ses coûts.


30
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

La figure 10 reprend la démarche et les objectifs visés par les différents documents constituant
TAFIM.

Figure 10: Framework TAFIM (TAFIM, 1996)

2.6.2.6 Framework d’architecture de l’Open Group


TOGAF «The Open Group Architecture Framework » a été élaboré au milieu des années 1990.
Ce Framework porté par le consortium Open Group fait l'objet de mises à jour régulières dont
la dernière est la version 9.1 qui date de 2011 (TOGAF, 2011).

Indépendant du secteur d'activité, TOGAF n'impose pas de modèle de formalisation


d'architecture, mais en recommande, en revanche, l'utilisation. Sa mise en œuvre n'est donc pas
antinomique avec l'utilisation de méthodes de conception d'architecture, comme Zachman ou
toute autre infrastructure métier formalisée.

TOGAF est plusieurs choses à la fois (Figure 11) :

- Une Méthode de Développement d’Architecture (ADM)

- La description du Continuum de l’Enterprise

- Une Information sur les Normes de Base

- Un Modèle de Référence Technique

Le schéma suivant récapitule les éléments qui composent TOGAF :

31
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Figure 11: Composants du Framework TOGAF (TOGAF, 2011)


L’ISO/IEC 42010/2007 définit l’architecture comme étant : « l’organisation fondamentale d’un
système, mis en œuvre par ses composants, par les relations que ces derniers ont entre eux, et
avec l’environnement, et par les principes qui régissent la conception et l’évolution. »

TOGAF reprend et élargit cette définition. Selon TOGAF, « l’architecture » a deux


significations suivant le contexte :

- La description formalisée d’un système, ou bien au niveau d’un composant, sa


description détaillée permettant sa mise en œuvre.

- La structure des composants, accompagnée des relations entre les composants, et les
principes et recommandations déterminant leur conception et leur évolution au cours
du temps.

TOGAF permet de développer quatre types d’architecture apparentés. Ces quatre types
d’architecture sont habituellement considérés comme étant des sous-ensembles d’une
architecture globale, tous pris en charge par TOGAF :

- Architecture métier (ou du Business) : Stratégie du business, gouvernance,


organisation, et processus métiers clés

32
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

- Architecture Applicative : Plan général destiné au déploiement des applications,


décrivant leurs interactions et leurs relations, avec les principaux processus métiers de
l’entreprise.

- Architecture des Données : Structure des actifs de données logiques et physiques


d’une organisation, et ressources de gestion des données

- Architecture Technique : Capacité des logiciels et des matériels nécessaires au


déploiement de services métiers, données et applications. Cela comprend
l’infrastructure informatique, le middleware, les réseaux, les communications, les
moyens de traitement et les standards.

TOGAF est constitué de plusieurs parties, la première et la principale concerne la méthodologie


de développement de l’architecture ADM (Architecture Development Method). L’ADM est le
résultat de contributions de nombreux utilisateurs des architectures. Elle décrit une méthode de
développement d’une architecture d’entreprise et forme le cœur de TOGAF.

Figure 12: Cycle de TOGAF ADM (TOGAF, 2011)


L’ADM peut être adaptée pour mieux correspondre avec un nombre important de scénarios
incluant différents styles de processus ainsi que des architectures spécialisées (comme la
sécurité). Cela correspond à la deuxième partie de TOGAF.

Les architectes qui exécutent l’ADM produisent un nombre de livrables en fonction de leurs
efforts, comme par exemple les flux de processus, les besoins architecturaux, les plans des
projets, les évaluations de conformité des projets, etc. Le Framework de contenu fournit un
modèle structurel pour le contenu de l’architecture qui permet à la majorité du travail produit
par un architecte d’être défini, structuré et présenté de façons consistantes. C’est la troisième
partie de TOGAF.

33
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

La quatrième partie est le Continuum d’Entreprise qui est une vue temporelle et progressive du
contenu du référentiel d’AE qui permet de passer des architectures et solutions génériques aux
architectures et solutions spécifiques. L’intérêt du Continuum d’Entreprise vient
principalement du fait qu’il est généralement impossible de créer une seule architecture unifiée
qui satisfait l’ensemble des besoins de tous les intervenants et ce à tout moment.

La cinquième partie correspond aux modèles de références qui sont des bases de benchmark
pour la bonne définition des architectures cibles. Deux modèles de références sont définis au
niveau de TOGAF : le modèle de référence technique (Technical Reference Model ou TRM)
qui structure les couches techniques d’une application et le modèle de référence de
l’infrastructure d’intégration de l’information (Integrated Information Infrastructure Reference
Model ou IIIRM) qui fournit une architecture de référence pour l’intégration entre applications
du Système d’Information.

La dernière partie de TOGAF concerne le Framework de gouvernance de l’architecture (ou


Framework de capacité de l’architecture). En effet, pour faire fonctionner avec succès des
fonctions architecturales au sein d’une entreprise, il est nécessaire de mettre en place des
structures organisationnelles, des processus, des rôles, des responsabilités et des compétences
pour mettre en œuvre les capacités architecturales.

2.7 Synthèse des Frameworks

2.7.1 Évolution des Framework d’AE


La plupart des frameworks se sont inspirés du Framework Zachman. Par la suite, des
frameworks sectoriels se sont développés pour répondre à des besoins spécifiques. TOGAF est
issu à la base de TAFIM, il s’est ensuite développé de manière indépendante en s’inspirant
notamment de FEAF. Ce dernier reste assez générique même s’il a été conçu initialement pour
les agences fédérales du gouvernement américain. Il est à noter que TOGAF a repris des
concepts de TAFIM, FEAF et DoDAF (voir figure 13). Un autre élément à prendre en
considération est la complémentarité des Frameworks. En effet, Zachman peut être utilisé
comme framework de contenu avec TOGAF et Archimate (Archimate, 2004) peut servir de
notation comme précisé par (Session, 2007).

2.7.2 Étude comparative


En prenant en considération les éléments qui composent un framework d’AE, le tableau suivant
présente un comparatif des différents frameworks selon ce critère et permet de ressortir la
complémentarité de ces frameworks ainsi que la couverture exhaustive par TOGAF de la
majorité des aspects. Nous ajoutons aux frameworks déjà étudiés la notation Archimate
(Archimate, 2004) et la méthode Praxeme (Bonnet et al, 2013) qui a été initialement conçu sur
les traces de Merise avec un périmètre plus important et le support de nouvelles démarches
comme SOA et MDA.

34
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Figure 13 : Evolution et relations entre Frameworks d’AE (Schekkerman, 2004)


Le tableau suivant fait ressortir le fait que la plupart des frameworks définissent un framework
de contenu à l’image de Zachman et également les livrables et le métamodèle. Par contre la
richesse de ce métamodèle est à revoir. De plus, ces frameworks pour la plupart d’entre eux ne
spécifient pas le processus ou le cycle de vie de production des livrables ainsi que la cadre de
gouvernance de l’architecture.
Framework Livrable Processus Modèle Meta Notation Framework Framework
de modèle de contenu de
référence gouvernance
Zackman √ - - √ - √ -
TOGAF √ √ √ √ - √ √
Archimate - - - √ √ √ -
DoDAF √ - - √ - √ -
MoDAF √ - - √ - √ -
FEAF √ √ √ √ - √ -
PRAXEME √ - - √ - √ -
TAFIM √ - - √ √ √ -
Tableau 4 : Etude comparative des frameworks d’AE
Le framework le plus complet de la liste reste TOGAF qui couvre la majorité des aspects et qui
peut être complété par Archimate par rapport à l’aspect notation. Archimate est d’ailleurs
également maintenu par l’Open Group (Archimate, 2004).

35
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.8 Domaines connexes de l’AE


Un domaine connexe est une thématique du SI qui a une complémentarité avec l’AE. Tous les
processus IT concernent les éléments d’architecture (par exemple : gestion des incidents, de la
configuration et de la disponibilité). Les éléments d’architecture et les processus sont régis par
des exigences. Tous les éléments d’Architecture sont gérés dans les processus.
Parmi ces domaines, on peut citer :
- La modélisation SI et d’entreprise
- La modélisation des processus métier (Business Process Modeling BPM)
- L’architecture orientée service (Service Oriented Architecture SOA)
- L’architecture orientée modèle (Model Driven Architecture MDA)
- La gouvernance SI et le référentiel CoBIT
- Le management des services et le référentiel ITIL
- Le management de projet et le référentiel PMBoK

2.8.1 Modélisation SI

Le but de la modélisation d'un SI (Système d'information) est d'aboutir à une spécification qui
est une représentation simplifiée de la réalité, de façon telle à faire ressortir les points auxquels
on s'intéresse. C'est un processus d'abstraction complexe qui fait appel à différentes approches
et méthodes d'analyse.
En relation avec l’architecture, la modélisation SI concerne les processus SI de l’entreprise. Des
méthodes/langages de modélisation comme Merise et UML (Sousa et al, 2006) permettent de
modéliser les processus SI de l’entreprise.
2.8.2 Modélisation Entreprise
La modélisation d’entreprise se situe au cœur du domaine de la planification stratégique, traitant
de problèmes allant de la représentation du système d’entreprise en vue de son analyse et de sa
conception, jusqu’à des problèmes d’intégration et d’interopérabilité des systèmes
d’entreprises.
Des exemples de la modélisation d’entreprise :
 La méthodologie UEML (Unified Enterprise Modeling Language) (Vernadat, 2002) est
un ensemble de théories, technologies et d’outils pour une utilisation intégrée de
l’entreprise et des modèles SI exprimés en utilisant différents langages.
 L’exemple du Framework Archimate (Archimate, 2004) permet de présenter une
notation unifiée pour la modélisation de l’Architecture d’Entreprise, il s’apparente à
UML mais il est conçu pour modéliser l’AE. Le modèle d’Archimate est composé de
trois couches : métier, applicative et technologie et définit trois vues à ces couches :
structures passives, comportement et structure active. Principalement, c’est un
métamodèle bien structuré qui couvre les besoins de l’Architecture d’Entreprise, mais
n’intègre pas la partie de la planification stratégique.

36
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.8.3 Modélisation des processus métier (BPM)


La BPM permet de modéliser informatiquement les processus métiers de l'entreprise. Il s’agit
de structurer l’information sous forme de modèles employés dans toutes les étapes du cycle de
vie des processus métiers. Elle adopte une approche ascendante bottom-up.

L’objectif est d’aboutir à une meilleure vue globale de l'ensemble des processus métiers de
l'entreprise en plus de leurs interactions et à être en mesure de les optimiser/automatiser au
maximum à l'aide d'applications métier.

C’est un domaine qui a une relation avec l’AE. La BPM avec la SOA dotent l’entreprise d’une
meilleure adéquation entre les objectifs du SI et ceux du métier, mais aussi lui permettent une
optimisation des performances individuelles des SI et des processus (Unilog, 2005).

2.8.4 Service Oriented Architecture


Service Oriented Architecture est une Architecture orientée service qui se fond sur
l’organisation en services métiers et processus métiers (Unilog, 2005).

La SOA vise les objectifs suivants (Bonnet et al, 2013) :

 Accroître l’agilité métier de l’entreprise


 Améliorer l’agilité du SI par rapport aux évolutions du métier par de nouveaux produits
et de nouveau canaux de distribution
 Faciliter l’adaptation de l’entreprise aux contraintes du marché par une nouvelle
réglementation, de nouveaux partenaires,
 Accroitre le ROI du SI par la Valorisation des investissements du SI et la Capitalisation
et réutilisation des services.

Comme domaine de l’AE, la SOA comprend des services types à chaque couche de
l’architecture d’entreprise. Ainsi, on peut catégoriser les services en services métier, services
applicatifs, services de données et services technique. De plus dans TOGAF, un guide
méthodologique est dédié à l’utilisation de TOGAF pour cadrer les architectures SOA.

2.8.5 Model Driven Architecture


La MDA (Kleppe et al, 2003) de l’OMG (OMG, 2003) offre une approche pour modéliser la
couche application de l’architecture permettant de préserver la logique métier des changements
qui surviennent dans l’implémentation technologique des couches inférieures. C’est un
domaine de l’AE puisqu’il concerne une couche parmi les couches d’AE.

MDA utilise des méta modèles et profils UML pour représenter les informations sur les
systèmes. Ces éléments sont utilisés pour créer des modèles classés par fonction. (CIM, PIM,
PSM).

37
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.8.6 Gouvernance SI (CoBIT)


COBIT (Control Objectives for Information Technology) est un modèle de référence utilisé
pour l'audit et la maîtrise des systèmes d'information (AFAI, 2002). COBIT peut servir à:

- représenter une source d'idées sur les meilleurs pratiques, processus, rôles et livrables,
- accélérer l'amélioration en suggérant les priorités, la cible et les solutions possibles,
- comparer le niveau de maturité d'une organisation informatique,
- gouverner le SI,
- pouvoir atteindre et démontrer la conformité à une norme.

Le modèle COBIT est centré sur la gouvernance des processus de gestion d'une direction
informatique. Les processus de COBIT sont regroupés en quatre domaines (AFAI, 2002) :

- Planning et organisation
- Acquisition et mise en œuvre
- Fourniture et soutien
- Surveillance

Le cube de COBIT est le suivant (AFAI, 2002) :

Figure 14 : Cube de CoBIT (AFAI, 2002)


COBIT offre une vue sur les processus SI et TOGAF et plus généralement l’AE se focalise sur
le produit SI. Il y a un mapping entre Cobit et TOGAF par rapport aux différents processus de
COBIT et la méthodologie TOGAF ADM (TOGAF, 2011).

Par exemple, TOGAF (TOGAF, 2011) lie le domaine PO de COBIT à un objectif de contrôle
« AI1 Identify automated solutions » du domaine A1.

2.8.7 Management des services SI (ITIL)


Créé à la fin des années 80, à l’initiative du secteur public britannique, ITIL (Information
Technology Infrastructure Library) est un référentiel de bonnes pratiques pour la gestion des
38
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

services informatiques (internes et externes) (Chamfrault et al, 2006). ITIL s’intéresse à la


production, qu’il s’agisse de fourniture de services informatiques ou d’exploitation interne.

ITIL vise à améliorer les services informatiques (prestation de service, service aux utilisateurs)
suivant plusieurs principes :

- constituer un catalogue de bonnes pratiques à partir de démarches reconnues ;


- mettre le client au centre de la démarche de la DSI ;
- organiser les activités suivant des processus bien établis ;
- jeter les bases d’une évolutivité dans le temps des processus et services.

ITIL est également orientée processus SI alors que TOGAF est focalisé sur le produit SI mais
il est à noter que la CMDB telle que définie dans ITIL peut s’apparenter au référentiel
d’architecture et que ITIL peut être utilisé comme cadre de référence pour définir les
architectures cibles.

2.8.8 Management de projet avec PMBOK


L’acceptation croissante du management de projet montre que l’application de connaissances,
de processus, de compétences, d’outils et de techniques appropriés peut avoir un impact
significatif sur le succès d’un projet. Le Guide PMBOK (PMI, 2008) identifie ce sous-ensemble
du Corpus des connaissances en management de projet qui est généralement reconnu comme
étant de bonne pratique.

« Généralement reconnu » signifie que la connaissance et les pratiques décrites sont applicables
la plupart du temps à la majorité des projets, et qu’un consensus existe sur leur valeur et leur
utilité.

« Bonne pratique » signifie qu’il existe un large consensus sur le fait que la mise en œuvre de
ces compétences, outils et techniques peut améliorer les chances de succès de projets très divers.
La notion de bonne pratique ne signifie pas que la connaissance décrite doit toujours être
uniformément appliquée à tous les projets ; la responsabilité de déterminer ce qui convient à un
projet particulier revient à l’organisation et/ou à l’équipe de management de projet.

PMBOK, dans sa version 4, propose 9 domaines de connaissances regroupés par 5 groupes de


processus (PMI, 2013).

En lien avec l’AE et TOGAF, le plan de migration F préconisé par TOGAF ADM se traduit par
des projets qui peuvent utiliser, dans leur définition et mise en œuvre, les bonnes pratiques
PMBoK.

Dans la phase de Gouvernance d’implémentation G dans TOGAF ADM utilise les informations
sur les projets (chartes de projets, livrables, plannings…).

Dans la phase de Conduite de changement de l’architecture H, PMBOK propose dans le


processus « gestion intégrée des modifications » d’avoir un plan de gestion du changement du
ou des projets qui permettra de surveiller et de contrôler les changements.

39
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.8.9 Frameworks métier


Les Frameworks métier (ou modèles de référence métier) représentent le retour d’expérience
dans un secteur donné. Ils offrent un moyen de cadrer la réflexion sur l’existant et la cible par
rapport à un métier. Généralement, ils offrent un modèle de processus qui reprend les bonnes
pratiques relatives à un secteur d’activité ce qui est le cas de SCOR (Supply Chain Operational
Reference model) (APICS, 2014) ou BIAN (Banking Industry Architecture Network) (BIAN,
2009). Dans certains cas comme pour Frameworx (ou eTOM voir figure 15) (TM Forum, 2011)
dans les Télécom ou Acord (Acord, 2014) pour l’assurance, ils offrent également des modèles
de référence pour la partie applicative et données.

Figure 15 : Vue globale du modèle de référence du métier Télécom (Frameworx/eTOM)


La figure 15 présente une représentation en couches de l’AE pour un opérateur télécom avec
les mêmes couches que TOGAF et des modèles de références pour chaque couche. Pour la
couche métier, par exemple, une cartographie détaillée des processus standards des opérateurs
télécom est présentée dans eTOM.

2.8.10 Synthèse des sujets connexes


De manière globale, l’AE s’intéresse au produit SI en terme de structuration et d’urbanisation
alors que la planification stratégique, le management de projet, ITIL ou CoBIT s’intéressent à
la vision processus du SI en terme de cycle et de bonnes pratiques. Des disciplines comme le
BPM, la SOA et la MDA représentent des modèles de références pour la cible de l’architecture
métier, SI et technique. De la même manière, les frameworks métier sont des modèles de
référence à prendre en considération pour l’architecture métier ou SI cibles. La modélisation
d’entreprise, quant à elle, est la base conceptuelle de l’AE, notamment sur la couche métier.

40
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.9 Utilisation de l’Architecture d’Entreprise dans le


contexte de la Planfication Stratégique SI
2.9.1 Architecture d’Entreprise et PSSI
(Wilton 2007) a établi que la planification stratégique manque d’une méthodologie formelle et
structurée et d’outils qui supportent, structurent et industrialisent la PSSI.

L’AE, comme domaine d’application de la PSSI, fournit une feuille de route de migration de
l’architecture existante vers l’architecture cible en opérant des transformations sur les éléments
d’architecture.

Les frameworks d’AE permettent de définir et structurer les livrables et les artéfacts. Par
exemple, Zachman définit une taxonomie pour les artéfacts, d’autres comme TOGAF décrivent
un processus qui produit les livrables d’architecture.

Le concept majeur qui rassemble le processus et la taxonomie est nommé Méta modèle. Il
permet de décrire les éléments d’architecture et de produire les livrables. Ce méta modèle est
parfois pauvre pour décrire l’architecture entière ou n’est pas structuré pour définir les
dépendances et les relations entre les éléments.

Des comparaisons théoriques entre PSSI et AE ont été menées par (Perks, 2003) et (Wilton,
2007). Ces comparaisons ont pu conclure que l’AE et la PSSI ont le même objectif et les mêmes
périmètres. (Wilton, 2008) a mené également une comparaison empirique sur la base d’une
enquête qui a permis d’établir une corrélation forte des deux activités au regard des sujets
qu’elles couvrent.

La principale différence qui a été mise en avant par (Wilton, 2008) est que la PSSI est plutôt
orientée processus avec une faible spécification des livrables et contenu alors que l’AE est
orientée produit en terme de définition et description de l’état actuel et cible du SI.

Cette différence tend à se réduire vu l’évolution des frameworks d’architecture d’entreprise. En


effet, dans des frameworks comme TOGAF, le décalage se réduit avec une définition détaillée
de la méthodologie qui permet de décrire l’architecture et de produire les modèles et livrables.

Dans le cadre de ce travail de recherche, d’autres différences ont été soulevées et sont
synthétisées dans le tableau ci-dessous.

Une des principales différences est liée au fait qu’au niveau de l’Architecture d’Entreprise,
aucun lien n’est établi entre la description des éléments d’architecture et les projets/programmes
contenus dans le roadmap des transformations. Ce manque de correspondance rend difficile
l’utilisation des frameworks d’architecture pour planifier les transformations SI.

41
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Planification Stratégique SI Architecture d’Entreprise


Période de développement 1970-1995 1987-2010
Processus Linéaire Iteratif and incrémental
Nature Orientée métier Orientée metier et SI
Livrables principaux Portefeuille de projets Description de l’architecture
Charges et budgets existante et cible
Roadmap de transformations
Support de la stratégie Elevé Moyen à faible
Techniques Oui Oui
méthodologiques
Modélisation Faible Forte
Référentiel de livrables Non Oui
Existence d’outil Rare Commun
Tableau 5 : Comparaison entre PSSI et AE

2.9.2 Utilisation de l’AE dans le cadre de la PSSI


2.9.2.1 Besoin de Transformation
Un projet est défini par (PMI, 2008) comme étant « Un effort temporaire mené pour créer un
produit unique, un service ou un résultat ». Cette définition insiste sur le fait qu’un projet a pour
objectif de produire un livrable sans mentionner les éléments qui sont impactés par un projet
qu’ils soient de nouveaux éléments crées dans le cadre du projet ou des éléments existant qui
ont été transformés. Dans la définition de PMBoK, le focus est également mis sur l’aspect
budget en terme de délais, de charge et de coût arrêtés au démarrage.

Dans le contexte de la PSSI et l’AE, un projet peut être défini comme un ensemble de
transformations appliquées sur des éléments d’architecture existants pour les faire évoluer d’un
état existant à un état cible. Ces éléments peuvent être des processus ou des produits métier, des
applications ou des modules applicatifs, des bases de données et des flux ou des éléments
d’infrastructure technique. Très souvent, un projet c’est une combinaison de transformations
impliquant plusieurs de ces éléments (Lakhdissi 2011).

2.9.2.2 Besoin d’un métamodèle


Une méthodologie structurée de planification stratégique SI, doit définir les projets de
transformations. Ces transformations s’appliquent comme décrit ci-dessus, sur des éléments
d’architecture. Il est donc nécessaire de déterminer les éléments d’architectures, leurs attributs
et leurs relations. D’où la nécessité de définir un métamodèle riche et structuré qui couvre les
éléments descriptifs de l’architecture (Processus, applications, data …) et les éléments actifs de
transformations (programmes, projets, budgets).

Le métamodèle cible pourrait aussi être utilisé comme une plateforme de description de
l’architecture, son évaluation et la définition des transformations et leur planification en termes
de projets et programmes.

42
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

2.9.2.3 Métamodèles existants


Plusieurs métamodèles existent, mais ils ont fait preuve de plusieurs insuffisances, certains sont
pauvres au niveau du contenu et ne permettent pas de dégager des bénéfices par rapport à leur
exploitation, d’autres ne traitent pas la partie de la planification stratégique.

 TOGAF

Le métamodèle de TOGAF est un métamodèle qui n’est pas souvent mis en pratique, faiblement
riche au niveau de la définition des objets. En fait, TOGAF fournit un métamodèle avec un
minimum de contenu d’architecture muni d’un certain nombre d’extensions que chaque
organisme, désirant faire une démarche d’Architecture d’Entreprise, doit utiliser selon leurs
besoins. Cela n’est pas apprécié du fait qu’il est coûteux pour l’entreprise car elle doit définir
son propre métamodèle au lieu de se baser sur un retour d’expérience d’une précédente
définition.

De plus, le métamodèle de TOGAF n’inclut pas une couche qui permet la couverture de la
planification stratégique.

 ARCHIMATE

Archimate présente une notation unifiée pour la modélisation de l’Architecture d’Entreprise, il


s’apparente à UML mais il est conçu pour modéliser l’AE.

Il est composé de trois couches, métier, applicative et technologie et définit trois vues à ces
couches : structures passives, comportement et la structure active.

Principalement, c’est un métamodèle bien structuré qui couvre les besoins de l’Architecture
d’Entreprise, mais n’intègre pas la partie de la planification stratégique.

 OUTILS DE MODELISATION

Les outils de modélisation de l’Architecture d’Entreprise, comme PowerAMC, MEGA, …etc


proposent de leur côté des métamodèles, mais le problème majeur est qu’ils ne sont pas riches
en contenu.

Heureusement que certains, comme PowerAMC, permettent une extension de leur méta-modèle
malgré les bugs qui apparaissent lors de son utilisation.

2.9.2.4 Éléments pour définir la méthodologie


On décrit ici les éléments qui vont permettre de définir la méthodologie proposée pour la PSSI
et basée sur l’AE. L’élément focal d’une méthodologie est le processus ou le cycle de vie de la
démarche. Le métamodèle et le framework de contenu ont été introduits en s’inspirant des
frameworks d’architecture comme TOGAF pour mieux structurer les livrables de la démarche.
L’outil support est un complément optionnel de la méthodologie.

43
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Méta-modèle
Le méta modèle est le principal élément de la description de l’architecture et de la
méthodologie. Le méta modèle garantit l’exhaustivité de tout le travail d’architecture, la
cohérence et l’alignement des couches d’architecture.

Il est similaire dans la forme à un Modèle Conceptuel de Données ou un diagramme UML. Il


structure les livrables de l’AE à travers la définition d’objets, d’attributs et de relations. En
effet :

- la définition d’objets assure l’exhaustivité et la couverture des aspects comme la


standardisation, les exigences et l’intégration.
- les attributs fournissent une manière pour effectuer le diagnostic et l’analyse des actifs
existants et futurs. Les attributs peuvent couvrir des aspects tels que la sécurité et la
performance nécessaire pour le processus d’évaluation.
- les relations sont importantes pour effectuer l’Analyse des écarts à l’intérieur de la même
couche et pour les besoins d’alignement entre couches.

Framework de contenu/Cadre de modélisation


Le Framework de contenu définit les couches, vues, questions et aspects décrits dans
l’architecture. Ce Framework organise, classifie et lie les éléments d’architecture et les
artefacts. Il est aussi important parce qu’il assure la cohérence et l’exhaustivité du métamodèle.

Le Framework de contenu d’architecture peut avoir la forme d’une grille bidimensionnelle ou


les lignes représentent les couches ou les vues et les colonnes représentent les classifications. Il
définit les éléments du métamodèle à un niveau élevé en mettant en relief la structure globale
plus que le modèle détaillé.

Cette notion est inspirée de (TOGAF, 2011) et désigne la manière dont les livrables sont
décomposés et structurés. La matrice de Zachman peut être également considérée comme un
framework de contenu.

Processus et cycle de vie


Le processus est le cœur de la méthodologie. Il définit les phases/étapes qui permettent de
dérouler les activités de la méthodologie. Il structure la manière dans laquelle les livrables sont
produits avec un enchaînement logique de phases qui sont liées les unes aux autres avec pour
chaque phase, les activités, les livrables et les méthodes et techniques appliquées. Les livrables
peuvent être cadrés via des modèles ou templates de livrables.

Dans chaque phase, la correspondance a été faite avec les phases du cycle TOGAF ADM pour
assurer le lien entre la méthodologie de planification stratégique et le framework d’architecture
d’entreprise.

44
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

Outil de modélisation
Cet élément de la méthodologie n’est pas obligatoire mais reste important pour valider la
pertinence et la viabilité de la méthodologie. L’un des objectifs derrière la structuration d’une
nouvelle méthodologie de planification stratégique est le manque d’outillage et
d’industrialisation des méthodes actuelles. Il est question d’outiller la méthodologie soit en
personnalisant des outils existants du marché ou en construisant un outil spécifique.

2.10 Conclusion
Ce chapitre permet d’identifier les faiblesses des méthodologies de PSSI existantes en
comparaison avec les frameworks AE. Il a été constaté plusieurs ressemblances entre l’AE et
la PSSI en termes de démarches et d’objectifs sachant que les frameworks AE présentent des
avantages en termes de structuration et de cadrage des livrables par rapport aux méthodes PSSI.
Ceci permet aussi de dégager le besoin d’une nouvelle méthodologie de PSSI s’inspirant des
frameworks d’AE pour assurer une meilleure structuration et industrialisation de la discipline
de PSSI.

45
Chapitre 2 : Architecture d’Entreprise et Planification Stratégique SI

46
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Chapitre 3 : Fondements de la
Méthodologie de Planification
Stratégique SI - ESPAM

47
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

3.1 Introduction
Suite aux constats faits par rapport aux méthodes existantes de PSSI, il a été noté le besoin
d’une nouvelle méthodologie basée sur les frameworks d’AE et qui doit proposer une
structuration des livrables, un cycle de vie formalisé et une meilleure industrialisation. Dans ce
qui suit, les fondements de la méthodologie de planification stratégique proposée sont décrits,
à savoir le framework de contenu et le métamodèle. La méthodologie est baptisée ESPAM
(Enterprise Strategic Planning Architecture Methodology) et est inspirée du framework
d’architecture d’entreprise TOGAF (et plus particulièrement de sa méthodologie TOGAF
ADM).

3.2 Framework de contenu GAM (Global Architecture Map)

3.2.1 Description générale


Le framework de contenu proposé (Lakhdissi, 2012) (Global Architecture Map) se base sur
l’exploration des frameworks de contenu existants en prenant en compte les défaillances et
faiblesses de ceux-ci. Dans ce framework de contenu, quatre couches principales sont définies
(voir Figure 16) :

- Couche Stratégie
- Couche Architecture Métier
- Couche Architecture SI (intégrant architecture application et architecture de donnée)
- Couche Architecture Technique ou Technologique

Une couche additionnelle est ajoutée pour représenter la partie planification stratégique et est
détaillée dans le métamodèle de la figure 18.

La différence est également faite entre :

- Éléments statiques : qui permettent de décrire un élément d’architecture de manière


statique très souvent hiérarchique.
- Éléments dynamiques : qui se focalisent sur la vue dynamique (en fonctionnement) de
ce même élément.

La distinction est également faite entre trois natures d’éléments :

- Éléments de structure : comme l’organisation et le réseau


- Éléments de fonction (ou de comportement) : comme les services et les fonctionnalités
- Éléments de contenu ou d’information : comme les données et le stockage

Cette distinction se base en partie sur ce qu’on peut retrouver dans Archimate qui distingue
entre structure passive (appelée ici contenu ou information), comportement et structure active.

Entre chaque couche d’architecture et celle qui es en dessous, il y a également des couches
intermédiaires qui peuvent être importantes dans certains cas :

48
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

- Couche d’architecture fonctionnelle : Entre la couche métier et la couche SI


- Couche d’architecture de solution ou de développement : entre la couche d’architecture
SI et d’architecture technique logicielle
- Couche d’architecture de déploiement ou de production : entre la couche d’architecture
technique logicielle et matérielle.

Figure 16 : Framework de contenu Global Architecture Map (GAM)


Deux préoccupations importantes émergent comme éléments transversaux à ces différentes
couches à savoir la sécurité, la performance et l’intégration.

49
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

- Sécurité

La sécurité représente un axe transversale du framework de contenu dans le sens ou les


exigences de sécurité doivent être prises en compte depuis la stratégie et le métier jusqu’à
l’infrastructure technique.

- Intégration

L’intégration est souvent perçu comme un problème applicatif par rapport à l’urbanisation du
SI et à sa cohérence. Toutefois, dans beaucoup d’entreprises, on constate que les problèmes
d’intégration proviennent d’incohérences au niveau des processus métier ou de l’organisation.
Cet aspect est également adressé au niveau de l’infrastructure technique en termes
d’interopérabilité des plateformes technologiques.

- Performance

La performance, quant à elle, est un aspect de plus en plus crucial dans les SI d’aujourd’hui
surtout avec l’ouverture de ces SI et la charge qu’ils doivent supporter en conséquence. La
performance doit être spécifiée d’abord comme exigence au niveau métier pour être traduite au
niveau des applications et des données et, enfin, se refléter sur les infrastructures.

3.2.2 Référentiel d'Architecture d'Entreprise de GAM


Le référentiel d’AE représente de manière globale le détail du framework de contenu GAM par
rapport aux objets décrits dans chaque couche et, par la suite, les livrables correspondants.

La figure 17 illustre une vue générale du référentiel d’AE préconisé. Les colonnes présentent
les différentes couches de l’Architecture d’ Entreprise (stratégie, métier, application, données
et technique).

Les lignes présentent les éléments du référentiel (diagrammes, inventaires, matrices de


dépendance, etc.). Elles permettent de naviguer dans le référentiel.

- Diagrammes : un diagramme est une représentation graphique d'un ensemble d'objets


du référentiel. Il permet de donner une vision schématisée des liens et parfois des
dépendances entre les objets.
- Matrice de dépendance : les matrices de dépendances permettent de passer en revue et
de créer des liens entre les objets du référentiel. Il s'agit d’un concept important qui
donne une vision en termes d'impacts et de dépendances entre les différents éléments de
l'architecture. Cette vision est primordiale dans le cadre des projets de transformation
de l'architecture d'entreprise. A noter que le nombre et la pertinence des matrices de
dépendances d'un référentiel dépendent du métamodèle et principalement de la richesse
des liens entre ses objets.
- Inventaire : un inventaire permet de lister sous forme de tableau le contenu des objets
du référentiel d’Architecture d’Entreprise.

50
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

- Rapport généré : un rapport peut être généré des éléments précédents et permet de
dégager le contenu d'un niveau d'architecture, répertoriant tout le contenu du niveau
dans un seul document.

Figure 17 : Vue générale du référentiel d’Architecture d’Entreprise personnalisé

3.3 Métamodèle GCM (Global Content Metamodel)

3.3.1 Objectifs
Dans l’interêt d’unifier la démarche d’Architecture d’Entreprise avec la planification
stratégique, un métamodèle est proposé pour pallier les faiblesses des autres métamodèles et
garantir un lien entre les différentes couches du Framework de contenu GAM.

3.3.2 Métamodèle GCM


Le métamodèle proposé par TOGAF est un métamodèle qui peut difficilement être mis en
pratique et faiblement riche au niveau de la définition des objets comme expliqué dans le
précédent chapitre. TOGAF fournit un métamodèle avec un minimum de contenu d’architecture
(Lakhdissi, 2012). Ce métamodèle est extensible pour chaque organisme désirant mettre en
place une démarche d’Architecture d’Entreprise adaptée à son besoin (Lakhdissi, 2013).

Dans le métamodèle GCM, qui est inspiré des métamodèles de TOGAF et d’Archimate, les
couches de base de l'architecture d'entreprise (métier, applicative, données et technique) sont
suffisamment détaillées. En outre, le métamodèle proposé permet d'intégrer deux nouvelles
couches nécessaires au contexte de la planification stratégique et adapté au framework de
contenu GAM à savoir la couche Stratégie et la couche Planification stratégique du futur
système d'information.

51
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Ainsi, le métamodèle proposé ici est un métamodèle qui se compose de six couches classées
par dépendance. La couche stratégique guide l’Architecture métier, cette dernière se base sur la
couche système d’information qui répond à ses besoins. La couche technique implémente les
objets de la couche SI, tandis que la couche planification stratégique sert à analyser l’existant
pour permettre à l’entreprise les transformations nécessaires pour sa mise en œuvre (Lakhdissi,
2011).

Le métamodèle proposé est cohérent avec les besoins de la majorité des organismes et donne
un premier niveau de structuration du référentiel d'Architecture d'Entreprise cible. Ce
métamodèle est détaillé, dans la suite de ce chapitre, au niveau des différents composants (ou
objets) des six couches proposées.

La figure 18 présente une vue globale sur le cadre d’Architecture d’Entreprise basé sur le
métamodèle GCM.

Cette vue globale met en évidence les différentes couches de ce métamodèle, guidées par la
stratégie et définissant une gestion des exigences qui intervient dans toutes les autres couches
afin de définir les besoins et les contraintes liés aux différents objets des différentes couches.

3.3.3 Détail du métamodèle GCM


Chaque objet du métamodèle personnalisé dispose de sa propre structure qui doit contenir les
informations pertinentes en lien avec l'objet.

Figure 18 : Diagramme de packages du Métamodèle Global de Contenu GCM


Le diagramme de packages de la figure 19 donne une vue globale des relations entre les couches
d’Architecture d’Entreprise.

52
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

La vue globale du métamodèle est décomposée sur les couches suivantes :

- Stratégie
- Architecture métier
- Architecture des SI
- Architecture technique
- Planification stratégique

Figure 19 : Vue globale du métamodèle d’Architecture d’Entreprise GCM

3.3.4 Métamodèle de la couche Stratégie


Une stratégie contient plusieurs axes stratégiques, chacun des axes possède des objectifs
stratégiques qui ont une capacité mesurée par un KPI (Key Performance Indicator). Le tableau
suivant décrit les objets de la couche stratégie:

53
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Objet Description
Mission de l’Entreprise Raison d’être de l’organisation. Cadre général de la stratégie.
Vision Aspiration, état futur souhaité. Projection de l’avenir
Stratégie Il s’agit de la formulation d’objectifs de long terme
Axe stratégique Précise une direction d'ensemble pour réaliser la mission de
l'entreprise
Objectif stratégique Déclinaison opérationnelle des axes stratégiques
Objectif opérationnel C’est un objectif immédiat dérivé d’un objectif stratégique
Facteur critique de succès C’est un facteur dont la présence ou l’absence peut influencer
l’atteinte d’un objectif stratégique
Mesure Présente une mesure associée au KPI
KPI L'indicateur clé de performance mesure la réalisation de
l'objectif précédemment défini et permet d'apprécier son
atteinte

Tableau 6 : Description des objets de la stratégie


Ces différents éléments de la stratégie sont décrits dans le diagramme de classe suivant :

Figure 20 : Métamodèle de la couche stratégie

3.3.5 Métamodèle de l’Architecture métier


La figure 21 représente un diagramme de classes qui présente les éléments qui décrivent
l’architecture métier en termes d’organisation, de processus et de fonctions.

Les objets du diagramme sont détaillés ci-dessous.

54
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Objet Description
Domaine Présente un domaine ou bien un sous domaine d’activité
de l’entreprise

Fonction métier Présente une fonction métier de l’entreprise


Processus métier Présente un processus métier de l’entreprise
Rôle Présente un rôle dans l'organisation de l'entreprise
Acteur Présente une unité d’organisation ou une personne
éxecutant un rôle
Unité d’organisation Groupement de personnes ou d’unités d’organisation
Personne Modélise une personne
Site Emplacement physique de l'entreprise

Tableau 7 : Description des objets de l’Architecture métier

Figure 21 : Métamodèle de l’Architecture métier

3.3.6 Métamodèle de l’Architecture Applicative


Ce diagramme (Figure 22) présente le métamodèle de l’architecture applicative avec les
différentes applications du SI, les modules, les bases de données et les différents flux d’échange.
Le tableau suivant présente quelques objets de cette couche.

55
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Objet Description
Application Présente une application (progiciel, application développée,
etc.)
Flux Présente un flux de données entre deux entités
(Application/Application ou Application/Base de données)
Module Présente un module d'une application
Fonction applicatif Présente une fonction applicative

Tableau 8 : Description des objets de l’Architecture applicative

Figure 22 : Métamodèle de l’Architecture applicative

3.3.7 Métamodèle de l’Architecture de données


Dans ce diagramme, sont présentés les éléments de la couche données qui servent comme
supports de stockage pour les éléments de la couche applicative.

56
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Figure 23 : Métamodèle de l’Architecture de données


Le tableau suivant présente quelques objets de l’Architecture de données :

Objet Description
Flux externe C’est un flux entre une unité d’organisation et une base de données
Fichier Un résultat d’échange de données d’un flux
Base de données Présente une base de données
Table Présente une table d’une base de données
Schéma conceptuel Présente un schéma conceptuel de données
Entité Présente un élément d’un schéma conceptuel

Tableau 9 : Description des objets de l’Architecture de données

3.3.8 Métamodèle de l’Architecture technique


Le diagramme de classes de la couche technique (Figure 24) englobe toutes les classes qui
présentent les éléments de la couche d’infrastructure technique.

Le tableau suivant présente quelques objets de l’Architecture technique :

57
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Objet Description

Réseau Présente un réseau d’entreprise (Local ou inter-site)

Typologie Présente une typologie de réseau (LAN, WAN, Radio ….)

Nœud réseau Présente un nœud réseau (Switch, Routeur, …)

Equipement de stockage Présente une entité de stockage en réseau

Equipement de sécurité Présente un élement de sécurité réseau (Parefeu ..)

Machine Présente une machine (Poste de travail, Serveur, …)

Logiciel Présente un Logiciel

Environnement Présente une énumération (Développement, Recette ..etc)

Tableau 10 : Description des objets de l’Architecture technique

Figure 24 : Métamodèle de l’Architecture technique

58
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

3.3.9 Métamodèle de la Planification stratégique


Le diagramme ci-dessous (Figure 25) présente la partie Planification Stratégique qui regroupe
les éléments qui permettent d’assurer la relation entre l’Architecture d’Entreprise et la
Planification Stratégique SI.

Dans le tableau 11, on trouve tous les éléments qui rentrent dans le cadre de la planification
stratégique.

Objet Description

Diagnostic Présente un diagnostic

Analyse SWOT Cet objet décrit la matrice SWOT permettant d’évaluer


les éléments de force, faiblesse, d’opportunité et de
menace

Analyse d’écart Cet objet permet de mesurer l’écart entre deux éléments
ou entre un élément et une référence

Element architecture Présente un élément architecture

Plan stratégique C’est le résultat d’un diagnostic

Projet Un ensemble de transformations qui agissent sur un


élément d’architecture d’entreprise.

Programme Permet de définir un ensemble de projets

Analyse d’impact L’analyse d’impact concerne un objet impacté et un


objet impactant.

Transformation Une transformation est un changement de l’état d’un


élément architecture.

Tableau 11 : Description des objets de la planification stratégique


Le principe global adopté à ce niveau est l’introduction de la notion de transformation qui
permet de lier l’AE à la planification stratégique. En effet, un plan stratégique est composé d’un
ensemble de projets et un projet est un ensemble de transformation sur des éléments
d’architecture métier, SI et technique. Ces transformations sont justifiées entre autres par le
diagnostic qui est fait de ces éléments.

59
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Figure 25 : Métamodèle de la planification stratégique

3.3.10 Caractéristiques du méta-modèle GCM


Le métamodèle GCM a pour objectif de combler les lacunes des métamodèles existants (voir
la section 9 du chapitre 2). Ainsi ce métamodèle permet d’unifier la planification stratégique
et l’Architecture d’Entreprise dans une seule structure.

De plus, le métamodèle GCM est indépendant des outils de modélisation, des méthodologies et
des frameworks d’Architecture d’Entreprise ; ce qui peut assurer une certaine flexibilité au
niveau de son utilisation.

GCM est aussi une structure éprouvée qui peut être utilisée dans différents domaines métiers
d’entreprises, étant basé sur les meilleures pratiques des métamodèles existants et sur le retour
d’expérience de plusieurs études de cas (détaillées dans les chapitres 4 et 5)

En outre, ce métamodèle peut structurer la méthodologie de travail pour des projets tels que la
cartographie SI, l’urbanisation, la planification stratégique et l’assistance à maitrise d’ouvrage.

Le tableau suivant présente une comparaison théorique entre le métamodèle GCM et les
métamodèles existants :

60
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

Global Content Métamodèle des


TOGAF Archimate Zachman
Metamodel-GCM outils d’AE
Exigences Oui Non Oui Partiellement Oui
Stratégie Oui Oui Non Oui Non
Planification
Oui Non Non Non Oui
stratégique
Liens projets et
Oui Non Non Non Non
architecture
Standards Oui Non Non Non Oui
Description Faible à
Détaillée Détaillée Détaillée Moyenne
metier moyenne
Description SI Détaillée Faible Moyenne Détaillée Détaillée
Description de Détaillée (cela
Détaillée Faible Moyenne Détaillée
infrastructure dépend de l’outil)
Support d’un
Oui Partielle Oui Partiel Oui
outil
Support Oui (pour
Oui Oui Oui Oui
methodologies certains outils)
Indépendance Oui Oui Oui Oui Non
Aspects
transverses
Non (en
(performance, Non Non Partiel Partiel
perspective)
integration,
sécurité)

Tableau 12 : Comparaison entre GCM et les métamodèles existants


De manière globale, le métamodèle GCM couvre aussi bien l’AE que la PSSI à travers
l’introduction de la couche planification stratégique où le lien entre les projets et l’architecture
est établi. De plus, le métamodèle GCM décrit de manière plus détaillée l’architecture SI et
technique et est supporté par un processus méthodologique et un outil de modélisation (cycle
de vie et plateforme détaillés dans le chapitre suivant)

3.4 Conclusion
Le métamodèle et le Framework de contenu présentés, dans ce chapitre, représentent le fruit de
notre étude comparative des Frameworks d’Architecture en prenant en considération les besoins
de la planification stratégique SI. Ils permettent, à travers la notion de transformation d’un
élément d’architecture SI, d’introduire des éléments de planification stratégique tels que les
projets en les liant aux éléments du SI. Le métamodèle GCM permet, en outre, de lier les
différentes couches du SI avec le métier et la stratégie pour assurer de manière pertinente
l’alignement stratégique.

61
Chapitre 3 : Fondements de la Méthodologie de Planification Stratégique SI - ESPAM

62
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Chapitre 4 : Cycle de Vie et Plateforme


de Modélisation ESPAM

63
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

4.1 Introduction
Dans ce chapitre, le cycle de vie de la méthodologie ESPAM est détaillé. Ce cycle de vie est
basé sur une adaptation de TOGAF ADM et chaque phase est décrite avec ses activités et ses
livrables. La plateforme de modélisation ESPAP qui a été mise en œuvre pour illustrer
l’industrialisation de la méthodologie est également décrite dans une deuxième partie.

4.2 Processus et cycle de vie ESPAM


4.2.1 TOGAF ADM
La méthode de développement de l’architecture (ADM) proposée par TOGAF (voir figure 26)
décrit la façon d’élaborer une architecture d’entreprise devant répondre aux exigences métiers
spécifiques d’une organisation. L’ADM est le principal composant de TOGAF et assiste les
architectes à plusieurs niveaux :

- Elle propose un certain nombre de phases d’un cycle de développement d’architecture


(Architecture du Business, Architectures des Systèmes d’Information, Architecture
Technique), sous la forme d’un modèle de processus global destiné à l’activité de
développement d’architectures.
- Elle fournit un descriptif de chaque phase de l’architecture, présentant ses objectifs, sa
démarche, ses entrants, ses étapes et ses sortants. Les parties concernant les entrants et les
sortants définissent la structure du contenu d’une architecture et les livrables (une
description détaillée des entrants de phase et des sortants de phase est fournie dans le Cadre
de Contenu d’Architecture).
- Elle fournit des récapitulatifs de l’ensemble des phases couvrant la gestion des exigences.

Figure 26 : Méthodologie TOGAF ADM (TOGAF, 2011)


64
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Le tableau suivant détaille les différentes phases du cycle ADM

Phase ADM Activité


Phase préliminaire Préparer l’organisation pour la réussite des projets d’architecture TOGAF.
Entreprendre les activités de préparation et de démarrage nécessaires pour aligner
les recommandations métiers pour une nouvelle architecture d’entreprise, incluant
la définition d’un cadre d’architecture et d’outils propres à l’organisation, avec la
définition des principes
Gestion des exigences Chaque stade d’un projet TOGAF fait appel à des exigences du métier et valide
ces dernières. Les exigences sont identifiées, stockées et délivrées comme entrants
et sortants des phases ADM concernées, qui manipulent, traitent et hiérarchisent
ces exigences.
A. Vision de Définir le périmètre, les contraintes et les attentes d’un projet TOGAF. Créer une
l’Architecture Vision de l’Architecture. Définir les acteurs concernés. Valider le contexte du
métier et créer la Définition du Chantier d’Architecture. Obtenir les approbations.
BCD. Architecture Développer les architectures à trois niveaux : Métier, Systèmes d’Information
Métier, des Systèmes (Applications et Données) et Technique.

d’information, Dans chaque cas, développer les Architectures Initiale et Cible et analyser les
écarts.
Technique
E. Opportunités et Effectuer une première planification de mise en œuvre et une première
Solutions identification des modalités de livraison pour les Building Blocks identifiés lors
des phases précédentes. Identifier les principaux projets de mise en œuvre et les
regrouper en Architectures de Transition.
F. Planification de la Analyser les avantages et les risques financiers. Développer un plan détaillé de
Migration Mise en œuvre et de Migration.

G. Gouvernance de Assurer la supervision de la mise en œuvre par l’architecture. Préparer et diffuser


la Mise en œuvre les Contrats d’Architecture (Comité de Gouvernance de la Mise en œuvre).
Vérifier que le projet de mise en œuvre respecte l’architecture.

H. Gestion du Assurer un suivi continu et prévoir un processus de gestion des changements


Changement garantissant que l’architecture réponde aux besoins de l’entreprise et rende
maximale la valeur ajoutée de l’architecture pour le métier.
d’Architecture

Tableau 13 : Phases de la méthodologie TOGAF ADM

4.2.2 Détail du cycle de vie méthodologique


Le cycle ADM est focalisé sur la production des livrables d’architecture notamment sur les
phases B, C et D. Il ne distingue pas entre description de l’existant et de la cible et ne prévoit
pas de manière systématique des itérations pour planifier la migration. En plus, l’aspect
diagnostic de l’existant n’est pas abordé.

Le cycle méthodologique proposé maintient une correspondance avec les phases du cycle ADM
mais qui se distingue par :

- Des phases claires de description et de diagnostic de l’existant


- Une phase de plan d’action à court terme permettant de répondre aux besoins urgents

65
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

- Une description plus détaillée de l’architecture cible comparée aux méthodologies


classiques de PSSI.
- Une description détaillée dans chaque phase des démarches, méthodes ou techniques
méthodologiques associées.

La démarche proposée s’articule autour de six phases hors la phase initiale d’initiation et
d’organisation du projet. Ces phases sont présentées sur la figure 27.

Figure 27 : Déroulement du cycle de vie méthodologique ESPAM

4.2.3 Phase 0 : Initiation et Organisation du projet


Dans un premier temps il est crucial de prendre connaissance de l’ensemble du contexte afin de
préparer la finalisation et l’optimisation des méthodes et des outils utilisés tout au long du
projet, et d’adapter la démarche proposée, dans le cadre de ce document, au contexte de
l’organisation. Ainsi, la phase 0 doit permettre :

 La mise en place de l’organisation technique, fonctionnelle et humaine qui sera utilisée


dans la suite du projet.
 La prise de connaissance de l’existant, organisationnel, fonctionnel et technique
nécessaire au bon déroulement du projet, selon les axes qui suivent (Figure 28) :

66
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 28 : Phase 0 de la méthdologie ESPAM


La visibilité atteinte à l’issue de cette première phase doit permettre de détailler et finaliser le
plan de charge de la prestation et de présenter rigoureusement son plan d’assurance qualité,
ainsi que les modalités du transfert de compétences tout au long de la prestation.

4.2.4 Phase 1 : Analyse et évaluation de l’existant et des besoins


4.2.4.1 Description des activités
Cette phase est décrite dans la figure ci-après.

Figure 29 : Phase 1 de la méthodologie ESPAM

Au niveau de la démarche d’Architecture d’Entreprise, cette phase permet d’étudier et de


définir l’architecture d’Entreprise existante de l’entreprise et d’élaborer le référentiel
d’Architecture d’Entreprise, cela concerne :

67
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

A. Elaboration de l’architecture métier existante

L'architecture métier est une description du métier de l’entreprise, elle a pour principal intérêt
de fournir les informations permettant de développer un système d’information et une
architecture technique alignées sur les besoins métier.

L'objectif de l'architecture métier n'est pas de fournir une description exacte du métier dans sa
totalité, mais de se concentrer sur les domaines qui permettent de fournir les exigences métier :
ce que fait le métier, ce qu’il vend, comment il fonctionne, etc.

L’objectif de cette étape est de regrouper, de structurer et de donner la vision en se basant sur
les documents existants. Il est également question ici de ressortir les services métier qui seront
la base de la définition des services applicatifs et de données.

Dans le cadre de cette phase et sur toute les couches d’architectures, la démarche sera itérative
et parallélisée.

- Itération documentaire : dans un premier temps, une définition de l’existant et de la cible


est faite sur la base des documents fournis par l’entreprise.
- Itération questionnaire et entretien : dans cette itération, la version précédente sera affinée,
enrichie et améliorée sur la base des entretiens menés avec l’équipe.
- Itération de validation : dans cette itération, l’architecture définie sera restituée à l’équipe
pour discussion, rectification et validation

Il s’agit de mener les activités suivantes en faisant référence au framework de contenu et au


métamodèle déjà définis :

- Définition et validation des principes métier


- Définition de l’architecture métier existante
- Mise en place des modèles d’architecture couvrant l’organisation, les acteurs et rôles, les
fonctions métier, les processus métier de la chaine de valeurs et les informations métier.

B. Elaboration de l’architecture applicative existante

L’architecture applicative permet de recenser les applications, leurs relations, leurs composants
internes de haut niveau et leur évolution.

Il s’agit de mener les activités suivantes en faisant référence au framework de contenu et au


métamodèle déjà définis :

- Définition et validation des principes applicatifs


- Définition de l’architecture applicative existante
- Mise en place des modèles d’architecture couvrants les applications, les composants
applicatifs, les services applicatifs, les progiciels existants, les bases de données et les
dépendances entre applications
- Identification des services applicatifs existants

68
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

C. Elaboration de l’architecture de données existante

Il s’agit de mener les activités suivantes en faisant référence au framework de contenu et au


métamodèle déjà définis :

- Définition et validation des principes de données


- Définition de l’architecture des données existantes
- Audit et revue de l’intégration et des échanges
- Définition des référentiels de données partagés
- Mise en place des modèles d’architecture couvrant les bases de données et liens avec les
applications, les entités haut niveau et relations, les services de données, les flux de données,
la sécurité des données, les transformations de données et les dépendances entre Bases de
données (réplication, répartition)
- Identification des services de données

D. Elaboration de l’architecture technique existante

Il s’agit de mener les activités suivantes en faisant référence au framework de contenu et au


métamodèle déjà définis :

- Définition et validation des principes technologiques


- Définition de l’architecture technique existante
- Audit de sécurité de l’architecture technique
o Mise en place des modèles d’architecture couvrant les logiciels et matériels, les
systèmes et réseaux, les couches technologiques, la sécurité des infrastructures, la
haute disponibilité, le dimensionnement et les dépendances entre les applications,
les données et les infrastructures
- Identification des services techniques d’infrastructure

E. Analyse d’écart par rapport à la stratégie

Le diagnostic de l’existant est une étape cruciale de l’étude du plan stratégique de toute
organisation. En effet, cette étape permet de relever les insuffisances, les déficiences et les
défaillances de l’architecture existante aussi bien au niveau métier, applicatif, données et
technique. Elle permet en outre de dégager les éléments d’action et les points d’amélioration.

Le diagnostic est généralement fait sur la base d’une analyse d’écart entre ce qui est et ce qui
doit être, ce qui se fait et ce qui doit se faire.

Cette analyse porte sur :

- Des éléments de benchmark par rapport à des organismes similaires ou par rapport
à l’industrie dans son ensemble. Dans ce cas, l’objectif du diagnostic est de se
comparer aux organismes similaires pour profiter de leurs expériences

69
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

- Des standards, des recommandations ou des bonnes pratiques SI ou technologiques.


Dans ce cas, l’objectif du diagnostic est de se mesurer par rapport à ce qui se fait de
mieux en termes de SI ou de technologie.
- Des écarts entre les différentes couches de l’architecture, généralement appelés
écarts de couverture. Ainsi, un écart peut être constaté entre la stratégie et
l’organisation ou entre le métier et les applications. Combler ces écarts permet
d’aligner les différentes couches à la stratégie ce qu’on appelle également
« Alignement stratégique »
- Des caractéristiques ou des éléments de la même couche. Ainsi, on peut avoir une
analyse des processus ou du portefeuille applicatif selon plusieurs critères ou
caractéristiques des applications. On peut faire de même pour le parc matériel.
- Des analyses SWOT (Strenghts, Weaknesses, Opportunities, Threats) d’un élément
d’architecture comme d’une application ou d’une base de données.

Ainsi, le diagnostic est présenté sous forme de tableau récapitulant les éléments de détail avec
une illustration si elle s’applique.

Le tableau suivant présente un exemple d’un diagnostic formalisé selon ESPAM:

Catégorie Architecture applicative – Utilité/utilisation


Code DIAG-APP-01
Intitulé Valeur métier faible d’une partie des applications métier (2 applications)
La valeur métier est un indicateur subjectif permettant de mesurer le bénéfice métier
Description
apporté par l’application
Type Analyse du portefeuille applicatif
Pas de valeur ajoutée perçue par les utilisateurs du SI
Impacts
Pas ou peu d’impact sur la productivité et la qualité d’exécution des processus
Le diagramme suivant est généré automatiquement de la plateforme ESPAM.

Proportion des applications


par valeur métier

Exemple ou
Illutration

Elevée
Moyenne
Faible

Proportion des applications par valeur métier

Tableau 14 : Détail d'un élément de diagnostic


70
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

4.2.4.2 Livrables de la phase


Les livrables principaux de cette phase sont :

- Etude de l’architecture existante : qui décrit l’architecture existante au niveau des


différentes couches en la modélisant sur l’outil.
- Diagnostic et analyse d’écart de l’existant : permet de dresser les insuffisances,
incohérences et déficiences de l’architecture existante de manière structurée.

4.2.5 Phase 2 : Définition de la vision stratégique d’architecture


4.2.5.1 Description des activités
En partant sur une vision claire de l’existant, la phase 2 permet de mieux cerner les objectifs de
la planification stratégique et de disposer d’une vision complète de besoins du futur système
d’information de l’entreprise. Cela nécessite l’implication forte des cadres dirigeants de
l’entreprise et la mise en place d’une organisation pour engendrer une réelle synergie.

Figure 30 : Phase 2 de la méthodologie ESPAM


Au niveau de la démarche d’Architecture d’Entreprise, cette phase consiste à élaborer la Vision
Architecture qui fournit une description de haut niveau des objectifs stratégiques Métier de
l'entreprise et la façon d’atteindre ces objectifs. Une stratégie système d’information doit définir
un système d’information cible, les priorités, les étapes et les moyens nécessaires pour
l’atteindre. C’est un outil clé pour s'assurer qu'il y’a une compréhension de la part de la
Direction Métier de ses priorités et les principales contraintes influençant sur la prise de
décision.

La vision architecture représente la redéfinition des exigences et les priorités du métier, elle est
essentielle pour aligner les efforts IT sur les besoins métier. Cette vision influence sur la
hiérarchisation des priorités et la prise de décision. Les éléments clés de la Vision d'architecture
sont les suivants (Figure 30):

71
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

- La Stratégie : élément clés dans la mise en place de la vision d’architecture, elle intègre les
objectifs métiers stratégiques constituant la base pour les plans d'entreprise afin de réaliser
sa mission et sa vision, et fournit les grandes lignes directrices qui dictent la conduite de
l’organisation, à moyen et à long terme. Le nombre d’objectifs métier stratégiques est
généralement réduit.

Figure 31 : Eléments de la vision Architecture


- Les Exigences : Les exigences métier représentent le premier niveau de détail qui décrit la
manière d’atteindre les objectifs métier stratégiques en décrivant les actions de haut niveau
nécessaires. Ces exigences sont composées principalement de :
o Contraintes : dues principalement à des facteurs internes et externes ;
o Principes : indiquent les principes internes de l'Entreprise ;
o Standards, règles et bonnes pratiques ;
o Attentes et besoins : Une transformation des "macros" objectifs métiers stratégiques en
besoins métier ;
- Capacités et ressources : Les Capacités se réfèrent à l’aptitude à fournir un service défini.
Les capacités sont établies via une collaboration entre personnes, processus et technologie,
et sont souvent une source d'avantage concurrentiel. Les entreprises ont beaucoup de
capacités, mais l'accent, pour le développement d'une Vision Architecture, est mis sur la
compréhension des capacités qui doivent être améliorées pour atteindre les objectifs métier.
Ces capacités sont de natures différentes : humaine, technique, métier et financière.

Il est reconnu que, à ce niveau de détail, il est, de plus en plus difficile, de parvenir à une
couverture complète dans l'ensemble de l'organisation. Il est important de se rappeler que le but
de documenter les capacités (comme les objectifs métier stratégiques et les exigences métier)
est d’extraire les informations pertinentes qui aideront à orienter le développement global de

72
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

l'architecture d’entreprise. Un jugement doit être appliqué pour évaluer si un niveau de


granularité plus fin est requis.

- Mission et métier : décrit principalement ce que fait l'entreprise et quelles sont ses
principales activités.
o Mission : La mission d'une institution se compose de ses principes directeurs et de son
orientation générale. C'est une expression de la vision qui est à l'origine de sa création.
Son énoncé vise à communiquer à l’intérieur comme à l’extérieur le but et la
contribution de ses activités. Il donne un aperçu de ce qui constituera un succès, et doit
être formulé de manière à inspirer la fierté des différents acteurs. Il doit identifier aussi
bien le bénéficiaire (Client) que l’activité de l’Institution et sa valeur pour ses clients.
o Chaine de valeur : La chaîne de valeur peut se définir comme l’étude précise des
activités de l’entreprise afin de mettre en évidence ses activités clés, c’est-à-dire celles
qui ont un impact réel en termes de coût ou de qualité et qui lui donneront un avantage
concurrentiel.
- Les principes IT et Lignes directrices de la vision Architecture (ou réponses
Architecture conceptuelle) : il s'agit des orientations clés à employer pour atteindre les
objectifs stratégiques de l’entreprise. Ces lignes directrices seront utilisées pour orienter le
développement de l'architecture d'entreprise, les feuilles de route et les plans afin d'évoluer
vers l'architecture cible.

Les principes IT sont généralement issus des meilleures pratiques dans l’examen de la mission
de l'organisation, la vision et les convictions clés. Par exemple, si une entreprise désire être «le
fournisseur le plus souple », alors leurs principes IT et leur lignes directrices directives devront
tenir compte de leurs besoins en matière de systèmes configurables.

La liste suivante donne des exemples de principes IT :

o ITP-01 : Privilégier le recours à des solutions du marché plutôt qu’au développement


spécifique
o ITP-02 : Maintenir l'indépendance entre les couches de l'architecture (Couplage faible)
o ITP-03 : Isoler les applications de la technologie, anticiper les changements technologiques
o ITP-04 : Concevoir l’interopérabilité, créer une couche d’Intégration inter-applications
d’entreprise

Le schéma suivant représente un exemple de synthèse de la vision d’architecture :

73
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 32 : Exemple de synthèse de la Vision d'Architecture


74
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

4.2.5.2 Livrables de la phase


Un document abordant les différents volets listés ci-dessous :

 La vision architecture de l’organisme : établir la vision architecture de l’entreprise en


approchant le sujet des différents onglets à savoir : mission et métier, stratégie, exigences,
capacités et ressources
 Un benchmark des organismes similaires : permet de profiter des expériences des
organismes similaires à l’échelle internationale pour alimenter la vision d’architecture. La
comparaison se fait à différents niveaux :
- Stratégie et Marché
- Métier
- Organisation
- Système d’Information
 Les lignes directrices de la vision d’architecture sous forme d’assertions : ci-dessous
une assertion type (Tableau 15).

Assertion 1 Référentiel de données communes

Enoncé Mettre en place le référentiel de données opérationnelles, fiables et cohérentes,


pouvant être partagées par plusieurs applications opérationnelles.

Description La donnée est l’un des éléments clés du SI. Pour pouvoir disposer de vue complète,
cohérente et intégrée sur les données de référence, il est important de disposer de
référentiels uniques des données importantes.

Justification - Simplification et optimisation des activités des processus métiers


- Contribution à la mise en place de la démarche d’analyse et de gestion des
risques systémiques du fait de la cohérence sémantique des données
- Transparence de l’information liée au secteur (simple et pertinente)
- Meilleure gouvernance du SI

Origine Objectif 1.1, 2.1 et 2.3, FI 5, Principe 5, 6 et 7

Implications - Elaboration du modèle conceptuel des données métier: représentation des


principaux concepts des données du métier et de l'interaction entre eux.

Tableau 15 : Détail d'une ligne directrice

4.2.6 Phase 3 : Élaboration du plan d’action à court terme


4.2.6.1 Description des activités
Lors des phases précédentes, un diagnostic de l’existant a été réalisé sur la base d’une étude de
l’architecture existante. Ce diagnostic a permis de relever les incohérences, les
dysfonctionnements et les observations qui devront permettre de poser un œil critique sur
l’existant SI et, par conséquence, construire un système cible à l’image de la vision
d’architecture validée.
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 33 : Phase 3 de la méthodologie ESPAM


Le plan d'actions à court terme est un premier pas vers la construction de ce système cible. Il
permet de définir un plan d'action préliminaire et préparatif pour la mise en place du système
d'information cible. Cela concerne principalement les études préalables "fonctionnelles et
techniques", nécessaires avant le lancement des projets de la mise en place du futur système
d'information.

Par ailleurs, cette phase a pour objectif également de recenser les actions urgentes et nécessaires
pour combler les insuffisances du système existant avant la mise en place du système cible. Ces
actions doivent apporter à moindre coût les premières améliorations sur le système existant et
le rendre opérationnel pendant la période de transition.

Cette phase est alimentée principalement par le diagnostic établi lors de la phase de l'étude de
l'existant mais aussi par les orientations pré-identifiées du futur système d'information et qui
seront formalisées lors de la définition de l'architecture cible (prochaine phase).

De ce fait, le plan d'action à court terme est une phase permettant à la fois d'améliorer la qualité
du système d'information existant mais aussi un accélérateur pour la mise en place du futur
système d'information. La figure 34 présente le positionnement de ce plan d'action par rapport
à certaines phases du plan stratégique du système d'information.

La figure 34 présente la démarche d’élaboration du plan d’action à court terme sur la base des
actions les plus urgentes à traiter qu’elles soient correctives ou préparatoires. La figure illustre
également le positionnement de ce plan d’action dans la démarche globale.

4.2.6.2 Livrables de la phase


Plan d’actions à court terme : Les différents actions correctives ou bien préalables sont
illustrées sous forme de fiches projets, comme pour la phase 5.

76
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 34 : Positionnement du plan d'actions à court terme par rapport au PSSI

4.2.7 Phase 4 : Élaboration de l’architecture cible et du plan


d’urbanisation
4.2.7.1 Description des activités
Cette phase est décrite dans la figure ci-après.

Figure 35 : Phase 4 de la méthodologie ESPAM


En partant de l’Architecture d’Entreprise définie dans le cadre de la phase 1 et la définition des
orientations stratégiques assignées au futur système d’information pendant la phase 2, cette
quatrième phase a pour objectif principal de définir la nouvelle Architecture d’Entreprise de
l’organisme. Les différents niveaux d’architecture (métier, applicatif, données et technique)
seront à nouveau définis.
77
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

La cible est définie en se basant sur plusieurs éléments en input qui proviennent des phases
précédentes et qui permettent d’assurer l’alignement avec la stratégie (figure 36) :

- Les lignes directrices issues de la phase 2 et qui proviennent elles-mêmes de la stratégie de


l’organisme.
- Le diagnostic et les analyses d’écart par rapport à l’existant qui ont été identifiés lors de la
phase 1. L’un des objectifs ici est de pallier les déficiences et réduire les écarts.
- Les attentes et besoins exprimés lors des phases précédentes par les entités métier ou
Système d’Information.

Cette définition va au-delà de simples recommandations de l’architecture prescriptive


(principes, standards, règles et bonnes pratiques) pour décrire en détails les différents éléments
du métier et du SI.

Figure 36 : Méthodologie de définition de l'architecture cible


Dans le cadre de l’élaboration du référentiel d’architecture existante et cible de l’entreprise, la
méthodologie ESPAM propose de se baser sur le méta-modèle décrit dans la section 3.3.

4.2.7.2 Livrables de la phase


Définition de l’architecture cible : C’est un document qui détaille l’architecture cible sur les
différentes couche de l’AE (métier, SI et technologique) et identifie les transformations
nécessaires pour atteindre cette cible.

78
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

4.2.8 Phase 5 : Evaluation des scénarii de mise en œuvre et


élaboration du plan de migration
4.2.8.1 Description des activités
L’objectif de la phase précédente (phase 4) était de définir le référentiel d’Architecture
d'Entreprise Cible en ligne avec la stratégie, celui de la phase 5 est plutôt de définir le chemin
de migration vers cette cible. L'architecture d'entreprise est souvent utilisée pour faciliter la
planification de transformation IT. En général, ceci implique le développement :

- Description des lignes directrices de l’architecture, illustrant l'état actuel


- Analyse des écarts afin d’identifier les problèmes et lacunes ainsi que les solutions

Figure 37 : Phase 5 de la méthodologie ESPAM


Ainsi, les principales tâches de cette phase sont les suivantes :

- Identifier les lacunes et les solutions pour corriger les écarts


- Prioriser les projets et les possibilités de transformation
- Élaborer une feuille de route pour répondre aux objectifs stratégiques de
l'organisation
- Gérer les changements et les urgences
- Aligner la conception de la solution sur une vision à long terme.
- Accélérer la conception de la solution.

Le plan de migration, proposé par une étude de schéma directeur classique, est de haut niveau.
Dans le cadre d’une étude de schéma directeur, basée sur une démarche d’architecture
d’entreprise, ce plan est repris en ajoutant le détail nécessaire fourni par les projets et en le
raffinant sur la base des analyses d’impacts entre les différents éléments de l’Architecture
d’Entreprise déjà définis. En effet, chaque projet qui affecte une brique des quatre couches peut
avoir un impact sur le reste. Il est important de mesurer l’impact pour pouvoir prendre les
bonnes décisions en termes d’évolution du Système d’Information.

79
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

La figure suivante décrit un calendrier global prévisionnel de mise en œuvre d’un PSSI.

Figure 38 : Calendrier de mise en œuvre d'un PSSI


Chaque projet de migration de l'architecture existante vers l'architecture cible est présenté via
une fiche dont le modèle est décrit en annexe 4.

4.2.8.2 Livrables de la phase


Le résultat de cette phase est :

- Un document d’analyse d’impact


- Des études comparatives des choix d’architecture et des scenarii
- Un portefeuille des projets de mise en œuvre du plan stratégique
- Un plan de migration

4.2.9 Phase 6 : Élaboration du plan de gouvernance et d’alignement


stratégique du SI
4.2.9.1 Description des activités
L’enjeu fondamental de l’alignement stratégique est de faire du système d’information un atout
au service de la stratégie de l’entreprise. Il s’agit de mettre en cohérence la stratégie du système
d’information avec la stratégie de l’entreprise et de planifier dans une perspective pluriannuelle.
L’alignement stratégique du système d’information suppose deux conditions :

80
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

- Compréhension et intégration de la stratégie de l'entreprise par la fonction système


d’information dans son ensemble. La fonction système d’information met en œuvre les
structures, les organisations et les outils qui veillent à ce qu'elle poursuive cette
intégration ;
- Prise en compte des contraintes et des opportunités de l'informatique dans la stratégie
de l'entreprise.

Figure 39 : Phase 6 de la méthodologie ESPAM


La notion d’alignement stratégique n’est pas propre au système d’information : tous les métiers
et fonctions de l’entreprise devraient être alignés sur la stratégie de l’entreprise.

Un des objectifs de l'architecture d'entreprise est de fournir un alignement entre le Métier et le


SI (Figure 40). Une fois mis en place, les décisions et les plans, élaborés au sein de l'architecture
d'entreprise, peuvent être utilisés comme une base solide pour la gouvernance de l'entreprise,
la fourniture des éléments d’entrée clés pour la planification stratégique, la hiérarchisation des
projets, et l'alignement des projets et des solutions.

81
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Architecture Produit
• Plannification Stratégique
Architecture Organisation

Architecture
Gouvernance Métier

Alignement du Métier & les


Architecture Processus Métier • Gestion des Projets

Métier Autres

Investissements IT
Architecture Enterprise

Architecture Métier pour SI


• Pacification Stratégique IT
Architecture Systemes
Gouvernance • Priorisation Projets IT &
Architecture

information
(Applications & Information) SI Gestion de Portfolio
• Gouvernance Project IT
Architecture Technique
SI

Figure 40 : Architecture d'entreprise appliquée à la gouvernance d'entreprise


Si les projets ne cherchent pas à améliorer l’architecture d'Enterprise tout en se conformant à
des concepts généraux et à des normes de l’entreprise et ne fournissent pas l’effort d'alignement.
Des solutions isolées seront développées, donnant lieu à un IT disparate et une faible cohésion
entre ses composantes.

4.2.9.2 Livrables de la phase


Les livrables de cette phase sont :

- Un plan de conduite de changement


- Un plan de communication
- Une organisation cible pour supporter les projets de mise en œuvre
- Un plan d’alignement et de mise en oeuvre

4.3 Plateforme de modélisation ESPAP


Afin d’industrialiser la méthodologie ESPAM et vu qu’une partie des livrables décrits ci-haut
peuvent être générés automatiquement, le choix s’est porté sur la mise en place d’une
plateforme qui permet de modéliser selon le métamodèle GCM et de supporter la méthodologie
ESPAM. Cette plateforme a été baptisée ESPAP (Enterprise Strategic Planning Architecture
Platform).
Deux choix d’implémentation se présentaient pour ce besoin :
- Se baser sur un outil du marché comme Power AMC et personnaliser son métamodèle et
ses rapports pour s’adapter à GCM et ESPAM.
- Développer une plateforme adaptée au besoin et qui pourrait évoluer et s’adapter selon les
évolutions de la méthodologie
Après avoir exploré la première piste, la deuxième option a été choisie ce qui assure une maitrise
parfaite de la plateforme développée tout en se basant sur des outils open source du marché.
4.3.1 UML, MOF et OCL
Le langage UML (Unified Modeling Language) a été adopté par l’OMG (Object Management
Group) (OMG, 2013) comme standard de modélisation de système informatique en novembre
1997. Le langage UML est décrit par un métamodèle conforme au MOF (Meta-Object Facility)

82
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

qui est également un standard de l’OMG pour la représentation des métamodèles et leur
manipulation.
L’UML a apporté au domaine de la méta-modélisation sa notation graphique et ses concepts
objet. Le langage UML permet la modélisation de systèmes indépendamment de toute
implémentation.
A partir de la version 2 (OMG, 2013), UML intègre le langage OCL (Object Constraint
Language) comme standard. OCL est un langage d’expression permettant de décrire des
contraintes sur des modèles objet. Une contrainte est une restriction sur une ou plusieurs valeurs
d’un modèle non représentable en UML. OCL est un langage sans effet de bord, il est incapable
de modifier quoi que ce soit au sein des objets ou même des variables.
Il donne des descriptions précises et non ambiguës du comportement du logiciel en complétant
les diagrammes. Il définit des pré-conditions, des post-conditions ou des invariants pour une
opération. Il permet aussi la définition des expressions de navigation ou des expressions
booléennes. OCL est un langage de haut niveau d’abstraction parfaitement intégré à UML qui
permet de trouver des erreurs beaucoup plus tôt dans le cycle de vie de l’application. Cette
vérification d’erreurs est rendue possible grâce à la simulation du comportement du modèle.
OCL est interprété par des outils et, par conséquent, le passage vers différentes plates-formes
technologiques est réalisable de façon semi-automatique ou automatique.
4.3.2 Architecture technique de l’outil
Cette section présente le volet technique de l’implémentation d’un outil de planification
stratégique basé sur Eclipse GEF et EMF des plugins de modélisation disponible sur Eclipse.

Comme cité précédemment, l’outil se base sur une architecture de plugins (Eclipse RCP).

Ce package contient les implémentations


des différentes interfaces.

Ce package contient toutes les


interfaces générées en utilisant
EMF.

83
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 41: Architecture technique globale de l’outil


La plateforme ESPAP se base sur deux plugins principaux présentés dans le diagramme de
packages ci-dessous :
- Le premier plugin est le plugin qui contient notre modèle.
- Le deuxième plugin contient les packages de l’explorateur d’objets, l’éditeur de
diagrammes et la génération de rapport…
L’architecture de l’outil est présentée plus en détails dans l’annexe 2.
4.3.3 Fonctionnalités de la plateforme ESPAP
4.3.3.1 Explorateur d’objets
Un développement spécifique est fait sur la base des frameworks d’Eclipse qui permettent de
générer un squelette de code. Les différentes vues de l’application sont développées à l’aide de
SWT et jFace. Ces deux outils sont décrits dans les parties précédentes.

La première vue développée (1ère itération de la méthode XP) consiste en un explorateur


d’objets (Tree View). Cet explorateur doit montrer le modèle et ses sous-dossiers et dans chaque
dossier, les objets correspondant à chaque couche. La figure 42 représente l’explorateur
d’objets :

Figure 42: Explorateur d'objets du méta modèle


Le menu contextuel donne la possibilité d’ajout d’un nouvel objet dans un dossier donné, et ce
selon la couche représentée par le dossier. La figure 43 montre un tel scénario :

84
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 43: Ajout d'un objet à l'aide du menu contextuel


4.3.3.2 Propriétés des objets de l’explorateur
Chaque élément de cet arbre possède ses propriétés. Eclipse RCP donne la possibilité de créer
une vue propriétés pour chaque élément.

La figure 44 montre les propriétés de l’élément « Mission » de la couche stratégie :

Figure 44 : Vue propriétés de l'objet "Mission" de la couche stratégie


4.3.3.3 Le dessin des diagrammes
Les objets ainsi créés peuvent être présentés graphiquement à l’aide de l’éditeur graphique.
Comme vu précédemment, GEF est le Framework qui s’occupe de la partie graphique. GEF se
base sur le design pattern MVC.

Cette étape s’installe dans la fin de la première itération du développement de l’outil. La partie
modèle de l’éditeur graphique est le modèle généré par le Framework EMF, les vues sont
dessinées à l’aide de la bibliothèque Draw 2D. La partie contrôleur est assurée par les EditParts.
Les figures 45 et 46 montrent l’éditeur graphique de l’outil ainsi que les différents packages
correspondants.

L’éditeur
graphique

La palette

Figure 45: L'éditeur graphique de l'outil

85
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Les Edit Part


(Contrôleur)

Les vues

Figure 46 : Contexte du MVC dans l'outil


Le dessin des diagrammes se fait à l’aide de l’utilitaire « Drag and Drop » que cela soit depuis
la palette ou depuis l’explorateur d’objets, la figure 47 représente un exemple de dessin de
diagramme :

Figure 47 : Dessin de diagramme "Actor _ Role"


4.3.3.4 Propriétés des objets graphiques
Chaque élément dessiné dans la partie graphique de l’éditeur a des propriétés, tout comme un
objet de l’explorateur, sauf que dans ce cas, il est possible de définir la forme et la couleur de
l’élément (Figure 48).

86
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Propriétés graphiques de
l’objet « Facteur de
succès »

Figure 48 : Propriétés graphiques de l'élément "Facteur de succès"


4.3.3.5 Génération des rapports
Comme tout outil d’architecture d’entreprise, l’outil développé doit disposer d’un mécanisme
de génération des rapports. Il existe plusieurs types de rapports : Matrice de dépendance,
Rapports Word, Rapports HTML…

- Matrice de dépendances

La création des matrices de dépendances permet de passer en revue et de créer des liens entre
objets de n’importe quel type.

La matrice de dépendances affiche les connexions entre les objets des types spécifiés dans sa
définition. Il est possible d’ajouter et de supprimer des connexions dans la matrice, mais aussi
de filtrer les lignes et colonnes affichées et d’imprimer ou exporter la matrice.

Actuellement, la première version de la matrice de dépendances de l’outil se génère comme un


fichier Excel.

Cette première version est faite en parcourant le fichier XML du modèle enregistré. Les
relations sont définies à l’aide des liens qui existent entre ces objets dans le modèle. Chaque
relation a un élément « Source » et un élément « Target ». Les éléments « Source » sont écrits
verticalement et les éléments « Target » horizontalement.

La figure 49 montre la matrice de dépendance sous forme Excel :

Figure 49 : Matrice de dépendance sous forme Excel


- Rapport Word

87
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Les rapports permettent de publier des informations relatives au modèle et peuvent être utilisés
pour documenter le système. Il est possible de créer plusieurs types de rapports à savoir des
rapports portant sur un modèle donné et qui documentent son contenu ainsi que les rapports
tabulaires. L’outil, ainsi développé, permet de capturer tous les modèles d’une instance et de
générer les rapports du premier type.

Pour générer un tel rapport, l’outil demande à l’utilisateur l’emplacement du nouveau rapport à
générer, et cela après définition du modèle. La figure 50 montre un exemple de modèle source
du rapport à générer :

Figure 50 : Un exemple de modèle métier


Le menu de l’outil donne la possibilité de choisir quel type de rapport à générer. La figure n°51
présente la fenêtre de demande du dossier de sauvegarde du rapport :

Figure 51 : Fenêtre de demande du chemin de sauvegarde du rapport


Après avoir choisi le dossier ou créé un nouveau dossier de sauvegarde (Make New Folder),
l’utilisateur peut ainsi générer le rapport, et l’ouvrir depuis le dossier de sauvegarde.

La figure 52 représente un exemple de rapport généré depuis le modèle de la figure 50 :

88
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 52 : Exemple de rapport généré


- Rapport HTML

Il est possible de générer des rapports de type HTML depuis l’outil. Pratiquement, c’est le
même principe qu’un rapport Word. La figure 53 montre un résultat de génération d’un tel
rapport :

Figure 53 : Exemple de rapport HTML généré

4.4 Adaptation d’ESPAM à la définition de la stratégie mobile


La méthodologie ESPAM peut être utilisée aussi bien dans une logique d’alignement que dans
une logique d’impact. Dans ce chapitre, il sera question de présenter comment la méthodologie
a été adaptée pour faire la planification stratégique SI axée sur la mobilité. Dans ce sens, la
méthodologie ESPAM a été utilisée avec une spécification du métamodèle pour définir
comment la mobilité peut impacter la stratégie de l’entreprise.
4.4.1 Planification stratégique dans le contexte du mobile
Dans les trois dernières années, le mobile est devenu un sujet important en entreprise. Au-delà
de son utilisation par le grand public, on parle de plus en plus du mobile comme le terminal du
futur (ère Post-PC), comme canal important de communication avec les acteurs externes (les
clients, fournisseurs, partenaires) et avec les acteurs internes (collaborateurs, managers,
actionnaires) ou comme outil de support des processus métier de l’entreprise.
Ces transformations impliquent un besoin de définition de la stratégie mobile d’une entreprise
en cohérence avec sa stratégie globale et en prenant en considération les particularités et les
contraintes des environnements mobiles.
L’approche classique consiste à considérer les applications mobiles comme faisant partie du SI
et à les intégrer dans le processus de planification stratégique SI. Cette approche peut être
89
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

adoptée quand le mobile n’est autre qu’un canal d’accès du SI et va s’appliquer plutôt dans une
logique d’alignement que dans la logique d’impact (Clevenger, 2011). L’autre inconvénient de
cette approche est le fait qu’elle ne prend pas en considération les spécificités du développement
mobile, des projets mobiles et du contexte mobile.
Le concept du ‘contexte’ de l’utilisateur du mobile est très important pour comprendre l’intérêt
du mobile dans la transformation de l’entreprise vers l’ère numérique. Plusieurs définitions ont
été avancées par (Cheng, 2000) qui conclut par sa propre définition « Le contexte est un
ensemble d’état environnementaux et de préférences utilisateur qui déterminent soit le
comportement de l’application ou qui implique un évènement applicatif intéressant pour
l’utilisateur ». Plusieurs définitions permettent de faire ressortir des classifications comme celle
donnée par Forrester (Ask, 2011) à travers les trois éléments suivants :
 La Situation : qui peut être caractérisée par le temps actuel, l’emplacement, l’altitude, les
conditions environnementales, la vitesse, etc.
 Les Préférences : construites par l’historique des décisions prises par l’usager et qui sont
partagées (dans l’application ou dans les réseaux sociaux)
 L’Attitude : à travers les sentiments et émotions déduites des actions de l’usager
ou celle de (Schillit, 1994) qui distingue le contexte informatique, le contexte utilisateur et le
contexte physique.
La récupération du contexte de l’usager est devenue plus facile grâce à l’intégration dans les
terminaux de nouvelles fonctionnalités logicielles et composantes électroniques comme la
caméra, GPS, accéléromètre, capteurs, NFC (Near Field Communications), etc.
Le contexte n’est autre que « la combinaison d’un usage particulier
(situation/relations/comportement) de l’utilisateur avec une capacité offerte par le terminal ».
Cette définition introduit le lien entre le contexte et le besoin utilisateur avec les capacités du
terminal. Il est possible de classifier le contexte comme combinaison de trois aspects :
 Contexte informationnel : situation et conditions environnantes
 Contexte structurel/organisationnel : relations, contacts, réseaux
 Contexte comportemental : attitude, préférences et réactions
4.4.2 Méthodologie de planification stratégique mobile
4.4.2.1 Présentation générale de la méthodologie
Faisant suite à un travail de définition de la méthodologie de planification stratégique SI
ESPAM, l’approche proposée, basée sur l’Architecture d’Entreprise, est adaptée pour définir
une méthodologie spécifique au mobile en prenant en compte les éléments suivants :
 Une démarche légère adaptée à la contrainte de temps généralement liée à la définition d’une
stratégie mobile
 Une démarche itérative et incrémentale pour prendre en considération le caractère progressif
et la maturité de l’entreprise pour passer au mobile.
 Une démarche qui s’intègre dans un Framework global qui est le cadre TOGAF (TOGAF,
2011) d’Architecture d’Entreprise, ce qui permet d’enrichir le Framework et d’étendre la
démarche en cas de besoin.

90
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

 Une démarche pragmatique et supportée par des techniques méthodologiques comme ce sera
présenté dans ce chapitre
La méthodologie baptisée VERGA (Lakhdissi et al, 2013) proposée est composée de 5 phases :

Figure 54 : Méthodologie de planification stratégique mobile VERGA


Vision Entreprise Mobile : L’objectif dans cette phase est de définir les objectifs stratégiques
de la mobilité et la Vision Entreprise Mobile alignée avec les objectifs stratégiques du métier
de l’entreprise et ceux du système d’information
Cible Entreprise Mobile : Il s’agit dans cette phase de définir l’état cible de l’entreprise en
adoptant la mobilité
Roadmap mobile : Dans cette phase, l’objectif est de définir les plans d’action qui permettront
de passer de l’état actuel de l’entreprise à la cible Entreprise Mobile
Gouvernance mobile : Il s’agit, dans cette phase, de mettre l’organisation, les processus et les
autres outils et activités nécessaires pour déployer, gérer et maintenir la mobilité
Amélioration continue : Pour assurer l’amélioration continue de l’Entreprise Mobile, les
initiatives déployées doivent être maintenues, et doivent évoluer tout en supervisant les KPIs.
4.4.2.2 Description détaillée de la méthodologie
Le tableau 16 détaille les principales activités et livrables de la méthodologie VERGA adaptée
de la méthdologie ESPAM.
4.4.2.3 Outils et techniques méthodologiques
Les activités des phases, précédemment décrites, ont besoin d’être supportées par des outils et
techniques. Cette section présente les outils méthodologiques suivants :
- « Mobile Vision Cube » qui est un outil qui permet de dégager des lignes directrices pour
l’Entreprise Mobile dans la phase « Vision Entreprise Mobile »
- La chaine de valeur mobile
- Des modèles de références destinés à supporter la phase « Cible Entreprise Mobile » dont
le modèle de référence applicatif et le modèle de référence technique

91
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Phase Activités / livrables


Vision Entreprise - Etude de l’existant
Mobile - Élaboration de la Vision Mobile incluant les objectifs stratégiques, les exigences métiers, les cibles
utilisateurs/clients, les besoins utilisateurs et la chaîne de valeur.
- Définition des capacités et ressources en terme de capacités technologiques (Terminal, SI, Cloud) ou
de capacité métier (Client, entreprise)
- Les principes et lignes directrices
- Benchmark des organismes similaires
- Indicateurs de performance (KPIs)
Entreprise - Expérience utilisateur : définir les principes d’expérience utilisateur et les Principes de charte
Mobile Cible graphique découlant des principes et des usages définis dans la phase « Vision Mobile »
- Vue métier : identifier les activités des processus qui peuvent être dotés de la mobilité. La vue métier
cible peut donner lieu à la création de nouvelles activités métiers à travers l’intégration de la mobilité.
L’outil qui peut être utilisé est la chaîne de valeur mobile.
- Vue SI : il s’agit de de transformer le besoin d’automatisation au niveau d’un ou plusieurs processus
où la mobilité sera introduite en une ou plusieurs applications faisant appel à des bases de données et
des flux. Les outils qui peuvent être utilisés sont :
o Le mapping avec le SI
o Le modèle de référence applicatif
- Vue technologique : identifier les types de terminaux et les technologies mobiles à utiliser. L’outil qui
peut être utilisé est le « Modèle de référence technique mobile»
Roadmap mobile - Plan d’action à court terme
o Opportunités de solution
o Capitalisation sur l’existant SI et notamment au niveau du web
o Préparation des capacités SI existantes (exposition de services)
- Plan projets
o Priorisation
o Liens entre les projets mobiles
o Dépendances avec les projets SI
Gouvernance - Définition des acteurs, rôle et processus nécessaires
mobile - Instauration de l’intégration du canal mobile dans les projets entreprise (SI et métier)
- Définition de la gouvernance de la sécurité mobile
- Industrialisation mobile
- Organisation et conduite de changement
- Plan de communication
Amélioration - Traçabilité et monitoring des usages mobile
continue - Suivi des KPIs
- Maintenance et évolution des solutions mobiles

Tableau 16 : Détail des phases de la méthodologie VERGA


Mobile Vision Cube

Le cube proposé est une représentation de trois paramètres clés dont la combinaison permet
d’identifier des initiatives de mobilité, des applications mobiles ou des familles d’applications
mobiles. Le premier paramètre est le « Besoin Utilisateur », le deuxième est la « Chaîne de
Valeur » et le troisième est « les Capacités du Terminal et du SI ».

92
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

Figure 55 : Mobile Vision Cube


L’intégration de la mobilité vient pour répondre à un ou plusieurs besoins des utilisateurs qui
peuvent être des clients, des collaborateurs internes ou des partenaires. Cette réponse à ce besoin
de l’utilisateur est forcément prise en charge dans le cadre d’une activité au sein de la chaîne
de valeur de l’entreprise. Les capacités des terminaux mobiles qui seront utilisés ou les
capacités existantes au niveau du SI de l’entreprise ou du Cloud permettront d’apporter richesse
de solutions technologiques possibles.
Pour illustrer l’utilisation du cube dans le cadre d’une société d’assurance, une application
mobile de télé-déclaration de sinistre est la combinaison de :
 Un besoin du client qui est la rapidité de la déclaration du sinistre
 Des capacités du terminal mobile comme la possibilité de faire des prises de photos avec le
terminal. L’application fera appel aussi à des capacités du SI de l’entreprise comme
l’exposition de services d’une application de gestion des déclarations des sinistres
 L’activité de la chaîne de valeur de l’entreprise concernée est la « Gestion des Sinistres »
Un autre exemple d’une application mobile pour géo-localiser les stations de distribution de
carburant :
 Le besoin du client est de s’informer sur l’adresse des stations les plus proches
 La capacité géolocalisation offerte par le terminal mobile
 L’activité de la chaîne de valeur de l’entreprise concernée est la « Gestion de la Relation
Client »
Un troisième exemple d’illustration est la famille d’applications de décisionnel sur mobile :
 Le besoin de l’utilisateur (qui est dans ce cas les managers des entreprises) est de s’informer
sur des indicateurs et des statistiques qui concernent le métier
 La capacité offerte par le terminal mobile est la possibilité de consulter une base de données
locale sur le mobile qui est mise à jour à partir du SI de l’entreprise
 L’activité de la chaîne de valeur de l’entreprise concernée est le « Pilotage de l’entreprise »
Chaîne de valeur mobile

La chaîne de valeur mobile est un outil qui permet d’identifier les macros processus métiers ou
processus d’un niveau plus fin (niveau 2 ou 3) qui sont susceptibles d’être dotés d’initiatives de
mobilité ou applications mobiles typiques. Les activités de la Gestion de la Relation Client, par

93
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

exemple, peuvent être munies d’applications de « Mobile CRM ». Les activités de pilotage
peuvent être munies d’applications de « Pilotage mobile ».
Cette chaîne de valeur peut être élaborée pour un métier donné (exemple entreprises
commerciales) ou un secteur d’activité donné (secteur Assurance).

Figure 56 : Chaine de valeur mobile


Modèle de référence applicatif mobile

Le modèle de référence applicatif permet de fournir des catégories prédéfinies d’applications


mobiles qui peuvent être mises en œuvre soit au niveau FrontOffice de l’entreprise, soit au
niveau BackOffice, soit de façon transversale.

Figure 57 : Modèle de référence applicatif mobile


Modèle de référence technique mobile

Le modèle de référence technique mobile permet de lister un catalogue de capacités


technologiques offertes par les terminaux mobiles tels que :

94
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

 Les capteurs (GPS, Caméra, Accéléromètre, etc.)


 Les applications standards (Calendrier, Contacts, Notification, etc.)
 Les entrées (Ecran tactile, Saisie clavier, Reconnaissance vocale, etc.)
 Des moyens de communication (Appel voix, Envoi SMS/MMS, Envoi email, etc.)
 Des sorties (Affichage textuel, Affichage image et vidéo, Son, etc.)
 Des moyens de stockage (stockage disque, stockage mémoire vive, etc.)
 Des ports (USB/Mini USB, sortie TV, Bluetooth, etc.)

Figure 58 : Modèle de référence technique mobile

4.4.3 Conclusion
La méthodologie proposée dans ce chapitre est inspirée de la méthodologie TOGAF ADM tout
en ajoutant les spécificités du mobile et en spécialisant le métamodèle ESPAM, l’aspect léger,
pragmatique et progressif adapté aux exigences de compétitivité de l’entreprise. Elle est
supportée par trois outils et techniques méthodologiques qui assurent un déploiement rapide et
efficace sur des entreprises de différentes tailles et activités.
Les techniques méthodologiques (dont les modèles de références applicatifs et techniques) qui
ont été introduites constituent, de manière indépendante, une extension et un enrichissement
des frameworks d’architecture existants comme TOGAF pour supporter l’aspect mobilité.
La méthodologie et ses supports constituent une contribution importante dans le monde du
mobile qui est souvent caractérisé par l’opportunisme des initiatives et des contraintes de temps
qui impliquent un manque d’organisation et de structuration.
La méthodologie peut être enrichie par d’autres outils et techniques méthodologiques pour les
phases Roadmap et Gouvernance notamment. Il est également possible de définir un modèle de
maturité pour la mobilité en entreprise qui permettra de définir le contenu du cycle VERGA
selon la maturité de l’entreprise.

95
Chapitre 4 : Cycle de Vie et Plateforme de Modélisation ESPAM

96
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

Chapitre 5 : Etude de Cas ESPAM :


Alignement Stratégique des
Organismes de Régulation

97
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.1 Introduction
Dans ce chapitre, une étude de cas est présentée pour illustrer l’usage de la méthodologie. Cette
étude de cas concerne un plan stratégique d’un organisme de régulation des marchés financiers
et revêt une importance particulière vu qu’il adopte une logique d’alignement pour construire
et consolider un système d’information à l’image du métier et aligné avec la stratégie.

5.2 Alignement stratégique


5.2.1 Définition de l’Alignement Stratégique (AS)
La revue de la littérature concernant le terme « Alignement Stratégique » (Elhari, 2010), montre
qu’il n’existe pas de définition formelle pour ce terme. En effet, (Henderson et al, 1989)
considère que les caractéristiques du concept d’alignement ne sont pas clairement définies, alors
que (Avison et al, 2004) estime que la notion d’alignement reste floue, tant au niveau
stratégique (entre stratégies d’entreprise et stratégies des technologies de l’information) qu’au
niveau opérationnel (entre système et processus). De même, (Etien, 2006) relève qu’il n’existe
pas de définition communément acceptée de l’alignement.

La diversité des termes utilisés implique la diversité des sens donnés au concept d’AS. Selon
(Henderson et al, 1993), l’alignement des SI est considéré comme une mise en cohérence
interne à l’organisation, des composants du domaine des TI, notamment l’architecture du
système informatique, et les composants du domaine du Business, notamment la stratégie
concurrentielle et les processus de l’organisation. Dans cette optique, les TI sont considérées
comme un support opérationnel qui permet aux parties prenantes d’accomplir les activités de
l’organisation (souvent regroupées en processus) afin d’atteindre les objectifs stratégiques
fixés. Cet alignement « interne » est aussi appelé dans la littérature « alignement stratégique ».

(Papp, 1998) le voit comme le fait d’appliquer les TI en harmonie avec les stratégies, les besoins
et les objectifs du métier. (Regev et al, 2004) le définit comme étant la correspondance entre un
ensemble de composants (par exemple entre les processus d’entreprise et le système
informatique qui les supporte). D’autres travaux traitent l’AS comme étant l’harmonie entre
l’architecture logicielle et l’architecture des processus d’entreprise (Wieringa, 2003). D’autres,
s’intéressent à l’alignement des processus métier et le système qui les supporte (Bodhuin et
al,2004), (Soffer, 2004).

(Etien, 2006) définit l’alignement comme l’ensemble des liens existant entre des éléments du
modèle de processus d’entreprise et des éléments du modèle du système informatique support.
L’AS doit être appréhendé d’un triple point de vue : (1) d’alignement avec la stratégie ; (2)
d’alignement avec l’environnement externe et (3) d’alignement avec les évolutions incertaines.
Pour (Thevenet, 2009), le terme est utilisé pour désigner l’alignement entre les niveaux
stratégique (la stratégie) et opérationnel (les processus métier).

(Fimbel, 2006) le définit comme la pratique managériale visant à « mieux comprendre, mettre
en œuvre et renforcer les convergences et synchronisations du SI avec les finalités, les
trajectoires, les rythmes et les manœuvre de l’entreprise »

98
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.2.2 Importance de l’alignement stratégique


Dans le contexte actuel, les organisations publiques et privées doivent disposer de SI flexibles
et performants permettant de supporter leurs stratégies, leurs processus métier, ainsi que tout
effort d’adaptation en réponse aux exigences de leur environnement. De telles adaptations
issues des changements de la stratégie ou de l'environnement font partie des problématiques
traitées par l'alignement des SI. En effet, selon les sondages (Kearns et al, 2003), réalisés auprès
des cadres dirigeants des TI au sein de plusieurs multinationales, l’alignement des SI est parmi
les dix sujets de TI les plus importants dans l’industrie.

De plus, (Porter, 1987) démontrent l’importance de la réalisation de l’alignement en tant que


facteur de compétitivité et de rentabilité de l’organisation. (Ciborra, 1997) soutient aussi que la
performance économique de l’organisation peut s’améliorer par l'alignement, à condition
d’aboutir à ajuster le positionnement externe de l’organisation et ses dispositions internes, alors
que (Tallon et al, 2003) a pu établir dans ce cadre, la relation entre le degré d’alignement atteint
par une organisation et le retour potentiel sur investissement en TI réalisé.

Enfin, (Luftman, 1996) et (Papp, 1998) démontrent que l'alignement entre la stratégie et
l'infrastructure organisationnelle peut permettre aux sociétés, non seulement d’améliorer la
synergie entre les différents sous-systèmes organisationnels, mais aussi de faciliter le
développement du plan d’entreprise, tout en augmentant la rentabilité et l'efficacité. Ils
affirment que ces bénéfices tangibles permettent aux décideurs de se concentrer sur la mise en
œuvre des TI comme moyens d’amélioration de leurs compétences de base et technologiques.
Cela a pour conséquence une amélioration globale de la performance.

5.2.3 Alignement stratégique et PSSI


Au fur et à mesure de l’évolution du SI et du métier, les écarts se creusent d’autant plus que le
métier évolue de plus en plus rapidement. L’alignement stratégique est l’un des objectifs de la
PSSI et vise à réduire ces écarts et à améliorer l’agilité et la performance de
l’entreprise/organisation.

L’alignement stratégique permet de mettre à niveau le SI (ou le refondre complètement) de


manière à refléter les exigences et les orientations du métier. La planification stratégique est un
processus plus global qui peut se faire dans une logique d’alignement ou dans une logique
d’impact comme décrit dans la section 1.3.3.

5.3 Contexte des organismes de régulation


5.3.1 Métier des organismes de régulation
Le métier des organismes de régulation gouvernementaux est un métier complexe faisant
intervenir plusieurs acteurs. Le schéma suivant représente une chaine de valeur type pour ces
organismes.

99
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

De l’Etat vers les Marchés : Régulation


Gestion Relation
Gestion Relation Marchés
Administrations
Relation Gestion des Gestion Communication Ecoute
Administrations demandes des plaintes marché du marché

Réglementation Contrôle Développement


Activités
Métier

Veille Autorisation Suivi Accompagnement


réglementaire Intervenants
Stratégie

Agrément Intervenants Suivi Intervenants


Production Sensibilisation et
réglementaire Suivi Produits
Validation Produits éducation
Suivi Information
Visa Opérations Suivi Transaction

Approche risque
Activités
Support
Métier

Affaires Affaires Gestion Système Relations


Etudes Statistiques
juridiques comptables Documentaire d’information externes
Activités
Support

Capital Compta Contrôle Moyens


Qualité Communication
Humain Finance Interne généraux

Figure 59 : Chaîne de valeur de l’organisme de régulation


Cette chaîne de valeur se décompose de trois types d'activités :

1. Les activités métier, elles sont décomposées en :


- Activités externes-front : Gestion de la relation avec le marché régulé et l’administration
qui sont respectivement le Client et le Commanditaire.
- Activités internes-back : Réglementation, Développement et Contrôle. Ce dernier est
divisé en deux parties :
o Le contrôle statique (autorisations)
o Le contrôle dynamique (suivi)
- La gestion des risques : elle est définie comme une approche transverse pour les activités
métier back.
2. Les activités de support métier sont transverses par rapport aux activités métier, elles
interviennent tout au long de la chaîne pour fournir des services opérationnels aux activités
métier. Ces activités concernent en particulier :
- Les affaires juridiques et comptables ;
- La gestion des relations externes principalement avec les organismes similaires à
l’international ;
- La gestion documentaire ;
- Le système d'information.
3. Les activités de support : interviennent également tout au long de la chaîne pour fournir
des services de support de base aux activités métier mais aussi aux activités de support
métier. Ces activités sont quasiment standard au niveau de la plupart des institutions et
concernent notamment les ressources humaines, la communication, les moyens généraux,
etc.

100
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

L’ensemble de ces activités est guidé par la Stratégie. La mission principale d’un organisme
de régulation qui est bien entendu la Régulation peut représenter un axe horizontal de la chaine
de valeur dans le sens de l’Etat vers les acteurs régulés (marché).

5.3.2 Besoins en alignement stratégique SI


Les organismes de régulation, de par le métier, évoluent dans un contexte complexe et évolutif.
Leur métier de base implique une forte intégration avec les acteurs du marché régulé et une
adaptation continue avec l’évolution de ce marché.

En effet, les organismes de régulation gouvernementaux doivent prendre en considération :

- de nouveaux intervenants du marché à réguler


- de nouveaux produits à réglementer et à autoriser
- de nouvelles informations à traiter et contrôler
- de nouvelles transactions à surveiller et suivre
- de nouvelles réglementations à produire et développer

L’ensemble de ces éléments introduisent des évolutions sur les processus, activités et
organisation de ces organismes et impactent de ce fait leur SI.

Le besoin d’alignement stratégique du SI est par conséquent un besoin fondamental, voire vital,
pour ces organismes.

5.4 Application d’ESPAM dans l’étude de cas


La section suivante présente une partie des livrables produits lors de l’application d’ESPAM
dans le contexte de la planification stratégique SI des organismes de régulation
gouvernementaux.

Les artéfacts (diagrammes, inventaires et matrices) ont été construits en se basant sur le
métamodèle GCM et en utilisant la plateforme de modélisation ESPAP.

Une revue complète de ces livrables est présentée en annexe 4.

5.4.1 Rappel de la méthodologie ESPAM


La méthodologie ESPAM propose un métamodèle riche appelé GCM et décrit dans la section
3.3. Le cycle de vie ESPAM qui structure de manière détaillée les activités et livrables
d’ESPAM est composé des phases suivantes :

- Phase 1 : Analyse et évaluation de l’existant et des besoins


- Phase 2 : Définition des orientations stratégiques assignées au futur SI
- Phase 3 : Élaboration du plan d’action à court terme
- Phase 4 : Élaboration de l’architecture cible et du plan d’urbanisme
- Phase 5 : Évaluation des scenarii de mise en œuvre et élaboration du plan de migration
- Phase 6 : Élaboration du plan de gouvernance et d’alignement stratégique du SI

101
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.4.2 Étude de l’existant et cadrage du besoin


Dans le cadre de l’étude de l’existant et du diagnostic, un ensemble d’artéfacts sont produits
dont l’objectif est de maitriser et cadrer l’existant et identifier les points d’amélioration. Dans
le cadre de l’étude de cas, plusieurs inventaires, diagramme et matrices de dépendance ont été
élaborés afin d’obtenir une image fine de l’existant et pouvoir faire un diagnostic exhaustif.
Parmi les artéfacts produits pour maitriser l’alignement du SI :

- Un diagramme de couverture du SI sur la chaine de valeur


- Une matrice de dépendance entre le SI et l’organisation
- Un schéma d’architecture technique de l’infrastructure SI

5.4.2.1 Couverture SI sur la chaine de valeur


Dans le cadre de la définition de l’architecture existante, plusieurs modèles ont été produits
sous forme de catalogues, de diagrammes et de matrices. Parmi ces modèles, un diagramme de
couverture applicative sur la chaine de valeur qui permet de ressortir l’écart de couverture des
activités métier par le SI (Figure 60).

Figure 60 : Couverture du SI dans la chaine de valeur

102
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.4.2.2 Couverture du SI par rapport à l’organisation


Un autre livrable intéressant sous forme de matrice est la couverture du SI par rapport à
l’organisation qui permet de ressortir les entités qui ne disposent pas d’applications et
continuent à travailler manuellement (Figure 61).

Organisme de régulation

Figure 61 : Matrice de dépendance Applications / Directions

Figure 62 : Diagramme d’architecture des serveurs


103
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.4.2.3 Architecture technique


Sur la couche d’architecture technique, la figure 62 représente l’architecture des serveurs qui
supportent le SI.

5.4.3 Définition des orientations stratégiques


Dans cette phase, il est question de construire une vision globale du plan stratégique. Cette
vision s’accompagne de la formalisation de la stratégie métier et de la traduction de cette
stratégie en des orientations pour le système d’information.

5.4.3.1 Stratégie métier


La stratégie a été formalisée en utilisant le métamodèle ainsi que le standard OMG (Object
Management Group) Business Motivation Model (BMM) (OMG, 2008). Elle a permis de
ressortir un ensemble d’axes et objectifs stratégiques qui sont synthétisés par la suite.

5.4.3.2 Synthèse des orientations stratégiques SI


La stratégie d’entreprise couplée aux principes SI et associée aux facteurs d’impact et aux
exigences permet, selon la démarche décrite dans le chapitre « Cycle de vie ESPAM », de
déduire les orientations stratégiques du SI. Ceux-ci sont les premiers éléments en entrée pour
définir les architectures cibles.

Le tableau 17 permet de définir une liste de lignes directrices SI (ou orientation stratégiques)
qui peuvent être exprimés selon le métamodèle GCM sous cette forme.

Code Intitulé de l’axe Code Intitulé de l’objectif


Axe 1 Améliorer le contrôle du Objectif 1.1 le développement d’une démarche d’analyse et
marché de gestion des risques
Objectif 1.2 la simplification et la consolidation des
procédures de contrôle tant en amont qu’en aval
Objectif 1.3 la mise en place d’outils performants
indispensables à un contrôle efficace et efficient
du marché et des intervenants
Axe 2 Accompagner le Objectif 2.1 la professionnalisation des opérateurs
développement du Objectif 2.2 la proximité avec les intervenants
marché
Objectif 2.3 la qualité de l’information liée au secteur
Axe 3 Favoriser l’ouverture et Objectif 3.1 l’éducation et l’accompagnement du public
renforcer la présence Objectif 3.2 la visibilité de l’organisme au niveau
nationale et internationale international
Axe 4 Assurer l’environnement Objectif 4.1 l’encadrement réglementaire
adéquat à l’évolution du Objectif 4.2 la mise en place d’un environnement IT aligné
marché et performant
Objectif 4.3 le renforcement des capacités internes
Objectif 4.4 la mise en place d’un système de pilotage des
performances

Tableau 17 : Axes et objectifs stratégiques

104
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

La figure 63 présente la synthèse des orientations stratégiques SI modélisée sur la plateforme


ESPAP.

Figure 63 : Synthèse des orientations stratégiques


Le tableau 18, quant à lui, présente le détail d’une orientation stratégique avec son énoncé, sa
description, sa justification, son origine et ses implications éventuelles.

Assertion 8 Référentiel de données communes


Enoncé Mettre en place le référentiel de données opérationnelles fiables et cohérentes pouvant être
partagées par plusieurs applications opérationnelles.
Description La donnée est l’un des éléments clés du SI. Ceci est d’autant plus vrai dans le cas d’un
organisme de régulation. Pour pouvoir disposer de vue complète, cohérente et intégrée sur
les données de référence, il est important de disposer de référentiels uniques des données
importantes.
Justification - Simplification et optimisation des activités des processus métier
- Contribution à la mise en place de la démarche d’analyse et de gestion des risques
systémiques du fait de la cohérence sémantique des données
- Transparence de l’information liée au secteur (simple et pertinente)
- Meilleure gouvernance du SI
Origine Objectif 1.1, 2.1 et 2.3, FI 5, Principe 5, 6 et 7
Implications - Elaboration du modèle conceptuel des données métier: représentation des principaux
concepts des données du métier et de l'interaction entre eux.

Tableau 18 : Détail d’une orientation stratégique SI (ligne directrice)

105
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

5.4.4 Plan d’action à court terme


Cette phase a pour objectif de traiter rapidement les actions correctives et préparatoires pour le
plan d’action final. Ce plan d’action est divisé en deux parties :

- Le plan d’actions correctives : permettant de résoudre les anomalies critiques constatées


lors de la phase de diagnostic sans attendre la phase 5 de la démarche
- Le plan d’actions préalables : permettant de définir les études et actions préalables
nécessaires pour mener à bien le plan de migration

5.4.4.1 Plan d’actions correctives


Ce plan est alimenté principalement par les éléments de diagnostic du système existant. Les
actions proposées sont des actions de courtes durées permettent de combler les défaillances du
système existant et d’améliorer la qualité générale de son fonctionnement avant la mise en place
du nouveau système d'information.

Le tableau 19 illustre des actions contenues dans le plan d’actions correctives :

5.4.4.2 Plan d’actions préalables


Le plan d'actions préalables à court terme préalables proposé est divisé en deux grands axes :

1. Etudes préalable pour les projets du PSSI : ces études présentent un intérêt pour
détailler et formaliser davantage l'existant notamment au niveau métier et fonctionnel.
Elles présentent un support pour tous les projets du PSSI quelques soient leur
dimensions et leurs orientations
- Etude détaillée des flux de données pour la gestion de l’information : la gestion
des flux de données internes et externes présente le cœur métier d’un organisme
de régulation, cette étude est donc primordiale à tous les projets du PSSI
- Etude détaillée des processus métier (BPM) : l'étude de l'existant a permis
d'identifier plus de 300 processus métier. Si les procédures définies dans le cadre
du SMQ sont utiles pour définir le mode opératoire de ces processus, la
modélisation de ces processus demeure une exigence pour l'ensemble des projets
PSSI
2. Prototype et Proof of Concept technologique : l'étude de l'architecture existante et la
formalisation des besoins métiers exprimés, ainsi que la prise en compte des lignes
directrices de la vision d'architecture permettent de disposer de quelques orientations
technologiques indispensables et qui présenteront sans doute le cœur de l'architecture
du futur système d'information. Ces éléments concernant les aspects suivants :
- Workflow
- ETL
- Business Intelligence et décisionnel
- Gestion électronique des documents

106
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

Nom de l'action Criticité Description


Respect et mise à Critique L'audit de sécurité a ressorti le non-respect de la politique de sauvegarde, il est recommandé de :
- Respecter la politique de sauvegarde
jour de la politique - Tester périodiquement la restauration de la sauvegarde
de sauvegarde - Maintenir un journal de test de sauvegarde
- Mettre à jour la procédure de sauvegarde suite à toute acquisition

Suivi de la solution Critique L'audit de sécurité a révélé des attaques virales sur des postes et des serveurs. Même si la solution
antivirus installée sur la machine est à jour, cela n'empêche pas que la machine soit infectée. Ceci dit,
Antivirale il est recommandé de :
• Surveiller la mise à jour de la solution antivirale (dans le serveur) avec les sites de l’éditeur, et si
nécessaire mener des actions manuelles : si la solution n'arrive pas à télécharger les mises à jour, il
est possible de lancer l'opération manuellement ou télécharger les mises à jour à partir des sites puis
les placer sur le serveur.
• Surveiller la mise à jour entre le parc informatique (PC et Serveurs) et le serveur de la solution
antivirale. Actuellement, plusieurs postes ne sont pas à jour, le fait qu’une machine n’a pas le dernier
pattern peut provoquer la diffusion et la contamination des autres postes. C'est pour cela qu'il est
conseillé de résoudre tout problème de "mise à jour du poste client" et dans le cas échéant passer
par la procédure manuelle.
• Mettre en place les exceptions antivirales proposées ou exigées par les éditeurs
• Analyser le log des infections, la consultation doit être faite avec un œil critique afin de :
o Identifier les sources d’infection : USB, partage réseau (via une autre machine infectée),
internet, etc.
o Vérifier si le fichier a été nettoyé
o Se renseigner sur les infections les plus courantes, afin d’identifier le mécanisme de
contamination et les différentes failles exploitées par le virus.
o Vérifier si une action manuelle est exigée (exemple : démarrage de la machine, suppression
d'un fichier ou clés de registre)
o Parfois l’antivirus peut identifier une infection mais il est incapable de la nettoyer.
Généralement dans ces cas, l’éditeur publie sur son site une procédure manuelle de nettoyage mise
à la disponibilité des administrateurs.
o Identifier et résoudre les problèmes des postes de travail qui ne sont plus connectés au serveur.

Documentation Important Malgré les efforts personnels de l’équipe informatique et à l'exception du projet TSM, il n’y a pas de
documentation pour les autres projets.
Chaque projet informatique doit être accompagné d’une documentation exhaustive exigée. Cette
documentation doit être personnalisée selon le contexte et très facile à suivre par tout informaticien
novice.
Pour chaque nouveau projet, on doit exiger (dans la consultation) au minimum la documentation
suivante :
• Dossier d’architecture
• Dossier d’installation et de configuration
• Dossier d’exploitation
• Dossier de sauvegarde et de restauration
• Dossier de transfert entre environnement
• Documentation technique de l’éditeur

Sécurisation et Important Les ports USB, Wifi et Bluetooth représentent un risque de sécurité pour l’entreprise. En effet, même
si on protège au mieux le SI, tout employé peut utiliser une clé USB de stockage ou une clé 3G
protection de fuite Internet infectées. Ce qui risque de provoquer des infections et des attaques réseaux.
des informations Des solutions centralisées peuvent être mises en place afin de gérer les autorisations Wifi, Bluetooth
et USB ainsi que la journalisation des fichiers transférés sur les supports amovibles. Ce qui permet de
faire un suivi de tout risque de vol d’information.

Chiffrement des Important Les PC Portables, clés USB et disques amovibles utilisés par le personnel peuvent être une source de
diffusion des informations confidentielles suite à une perte ou un vol. Afin de remédier à cette
informations situation, il est conseillé d’utiliser des solutions de chiffrement des informations afin de rendre les
amovibles informations illisibles suite au vol (ou en cas de perte).

Tableau 19 : Détail des actions correctives à mettre en place


Même si l'orientation vers ces systèmes semble évidente au niveau de l'architecture cible, se
lancer directement vers des projets d'intégration de ces technologies est symbole de risque

107
Chapitre 5 : Etude de Cas ESPAM : Alignement Stratégique des Organismes de Régulation

imminent. En effet, même si le périmètre de chaque solution semble clair et facile à prendre en
main, faire confronter chaque solution à un contexte réel est assez difficile. Cette difficulté n'est
pas due simplement à l'utilisation de ces solutions, mais principalement à la maîtrise du contexte
global de son utilisation dans le cadre d'un besoin réel (expression du besoin, formalisation des
règles métier, configuration et paramétrage, organisation, etc.).

Par ailleurs, une autre difficulté s'ajoute, c'est comment faire intégrer ces solutions entre elles
pour disposer d'un système d'information intégré. Par exemple, l'exécution d'un processus
métier par un moteur de Workflow nécessite souvent une interaction avec le moteur ETL
(exemple déclanchement d'un processus lors de la réception et le contrôle d'un flux de données).

Afin de remédier à ce risque, une phase de prototypage du système d'information cible est
nécessaire. Cette phase aura pour objectif d'une part, de mettre en pratique les différentes
solutions techniques proposées sur un périmètre fonctionnel réduit, allégé (i.e. certaines règles
de gestion peuvent être allégées) mais représentatif, et d'autre part, de disposer d'un premier
socle d'intégration du futur système d'information. Ce socle d'intégration technique sera le cœur
de l'architecture technique du futur système d'information.

5.5 Conclusion
L’application réussie de la méthodologie ESPAM dans un cas aussi complexe que les
organismes de régulation gouvernementaux permet de montrer la richesse du métamodèle
proposé (GCM) et son niveau d’adaptation à plusieurs contextes. La qualité des livrables et leur
pertinence provient principalement de cette richesse et structuration. De plus, l’utilisation de
l’outil permet un niveau de productivité et de pérennité des artéfacts produits.

108
Conclusion Générale

Conclusion Générale
Récapitulatif du travail
Le présent travail de recherche consiste en l’exploration du domaine de la Planification
Stratégique des Systèmes d’Information en vue d’identifier les points d’amélioration,
notamment sur le volet méthodologique. L’approche proposée est basée sur un rapprochement
de la PSSI avec l’Architecture d’Entreprise. L’objectif est de poser les fondements d’une
méthodologie de Planification Stratégique SI, basée sur l’Architecture d’Entreprise.

L’état de l’art réalisé porte sur de nombreuses méthodologies de planification stratégique


existantes qui ont été comparées pour ressortir les avantages et inconvénients de chacune
d’entre elles et les points d’amélioration à proposer.

Par la suite, le focus s’est porté sur l’Architecture d’Entreprise en tant que discipline structurée
et industrialisée, pouvant être utilisée dans le contexte de la planification stratégique. A ce
niveau, une étude détaillée des frameworks d’AE est faite dans le but d’identifier leurs
positionnements respectifs et préciser leur contribution dans le processus de planification
stratégique SI.

Ces études permettent ainsi d’élaborer les fondements d’une méthodologie originale
comprenant un nouveau métamodèle, un cycle de vie, un Framework de contenu ainsi que les
outils de mise en œuvre de la méthodologie.

Le métamodèle est l’élément fondamental de la méthodologie et permet d’intégrer dans une


logique complémentaire des éléments de description de l’architecture avec des éléments de
planification stratégique et ce à travers le concept de transformation. Le Framework de contenu
permet, quant à lui, de structurer les éléments du métamodèle et les livrables de la méthodologie
dans un cadre global en précisant les liens entre les différentes couches d’architecture. Le cycle
de vie méthodologique représente une adaptation de TOGAF ADM pour le besoin de la
planification stratégique et permet de décrire les phases, activités et livrables de la méthodologie
ESPAM. L’outil assure la mise en œuvre du métamodèle et de la méthodologie de manière
pratique pour valider la cohérence du métamodèle et des livrables proposés et pour assurer
l’industrialisation des activités de planification stratégique SI.

Une adaptation de la méthodologie est faite pour le cas de la planification stratégique mobile
avec spécialisation du métamodèle GCM pour s’adapter à ce contexte. L’ensemble des éléments
de la méthodologie sont ensuite illustrés via un cas pratique de projet de planification
stratégique d’un organisme de régulation gouvernementale.

Contributions et bénéfices
Les contributions du présent travail de recherche sont nombreuses. Peuvent être mentionnées
entre autres :

109
Conclusion Générale

a) La structuration d’une méthodologie de planification stratégique SI pouvant s’étendre à la


planification stratégique métier et comprenant un Framework de contenu, un métamodèle, un
cycle de vie méthodologique et une plateforme de modélisation.

Cette méthodologie possède l’avantage d’être basée sur un métamodèle structuré qui repose sur
les bonnes pratiques de la discipline d’Architecture d’Entreprise. En outre, elle peut être utilisée
aussi bien dans une logique d’impact que dans une logique d’alignement, tout en étant outillé à
travers la plateforme de modélisation ESPAM.

b) L’enrichissement des frameworks d’architecture d’entreprise incomplets au niveau de


l’alignement stratégique des projets et transformations. Le métamodèle proposé (GCM) peut en
effet, être utilisé dans le cadre de la mise en place d’un référentiel d’AE en complément des
Frameworks existants. Il enrichit les métamodèles existants notamment au niveau de
l’architecture SI et l’architecture technique et dans la description des transformations.

c) L’élaboration d’un modèle associant la description de l’entreprise aussi bien au niveau des
opérations (existant) que des transformations (cible). Le métamodèle proposé associe les
aspects descriptif, prescriptif et actif de l’architecture d’entreprise.

d) L’élaboration d’une étude de cas complète de la méthodologie dans un domaine important


et complexe à savoir les Systèmes d’Informations des organismes de régulation
gouvernementaux. Cette étude de cas illustre la démarche ESPAM, ses activités et ses livrables
pour ce domaine métier, dans une logique d’alignement stratégique du SI.

e) L’application de la méthodologie sur des domaines transverses de planification stratégique


telle que la définition de la stratégie mobile.

Perspectives et travaux futurs


Le travail réalisé et les résultats obtenus permettent d’identifier de nombreuses voies de
recherche et de développement, parmi lesquelles :

a) L’introduction dans le métamodèle GCM à tous les niveaux d’attributs d’architecture


transverses tels que la sécurité, l’intégration et la performance. Ceci permettrait de
décliner la méthodologie pour le besoin de mener des activités de planification
stratégique orientée sécurité, performance ou interopérabilité.
b) Définition d’un profil UML spécifique pour la PSSI supportant le métamodèle proposé
et développement éventuellement d’un langage spécifique au domaine de la PSSI en se
basant sur les concepts de MDA (Model Driven Architecture) et de DSL (Domain
Spécifique Language) [Mernik 2005]
c) Généralisation de la méthodologie à la planification stratégique globale. Le métamodèle
proposé est à même de s’adapter à ce changement vu qu’il couvre plusieurs aspects
métier au niveau de la stratégie, de l’organisation, des processus, des produits et des
informations.
d) Introduction de métriques dans le diagnostic permettant de caractériser l’écart
d’alignement, de couverture ou l’écart par rapport aux bonnes pratiques.

110
Bibliographie

Bibliographie
(Acord, 2014) ACORD, The Acord Framework, An insurance Enterprise Architecture,
https://www.acord.org/standards/framework/Documents/ACORD_Framework_Overview.pdf,
2014

(AFAI, 2002), AFAI, COBIT : Gouvernance, Contrôle et Audit de l’information et des


technologies associées, Association Francaise de l’Audit et du conseil Informatique, 2002.

(Andersen, 1992) Andersen Consulting. Foundation Method/1. Version 9, Arthur Andersen and
Co, 1992.

(APICS, 2014) APICS Supply Chain Council, Supply Chain Operational Reference model
(SCOR) Framework, http://www.apics.org/sites/apics-supply-chain-council/frameworks/scor,
2014

(ArchiMate, 2004) Archimate, «Concepts for architectural description. Technical Report


TI/RS/2003/007», Telematica Institute, ArchiMate Deliverable 2.2.1 v4.0, December 2004..

(Ask, 2011) Ask J. The Future Of Mobile Experiences Is Context, Forrester Report, October
2011

(Avison et al, 2004) Avison D., Jones J., Powell P., Wilson D., «Using and validating the
strategic alignment model» Journal of Strategic Information Systems, 13, 2004, pp.223-246.

(Balantzian, 1992) Balantzian G. (1992). Les schémas directeurs stratégiques. Masson (Paris) :
210 p. ISBN 2-225-82501-7.

(BIAN, 2009) Banking Industry Architecture Network, Introduction to BIAN Service


Landscape, Juillet 2009

(Boar, 2001) Boar, B. (2001). The Art of Strategic Planning for Information Technology, John
Wiley and Sons, New York, NY.

(Bonnet et al, 2013) Pierre Bonnet, Jean-Michel Detavernier, Dominique Vauquier, Sustainable
IT Architecture: The Progressive Way of Overhauling Information Systems with SOA, John
Wiley & Sons, 1 mars 2013

(Bodhuin et al, 2004) Bodhuin T., Esposito T., Pacelli C., Tortorella M., «Impact Analysis for
Supporting the Co- Evolution of Business Processes and Supporting Software Systems»,
Proceedings of BPMDS’04 Workshop on Creating and Maintaining the Fit between Business
Processes and Support Systems, Riga, Latvia, 2004.

(Bounabat, 2006) Bounabat, B, “Enterprise Architecture Based Metrics for Assessing IT


Strategic Alignment”, European Conference On Information Technology Evaluation (ECITE),
2006.

111
Bibliographie

(Caseau, 2007) Performance du système d’information : Analayse de la valeur, organisation et


management, neuf scène de la vie quotidienne d’un DSI, Y. Caseau, Dunod, 2007, ISBN 978-
2-10-050596-8

(CCTA, 1988) Central Computer Telecom Agency, Guidelines for Directing Information
Systems Strategy, London: HM Treasury.

(CCTA, 1999) Central Computer Telecom Agency IS Strategy: process and products, Format
Publishing Limited, Norwich.

(Chamfrault et al, 2006) Chamfrault T., Durand C., ITIL et la gestion des services : Méthodes,
mise en œuvre et bonnes pratiques, Dunod, 2006.

(Chandler, 1988) Chandler, Alfred A., Jr., Strategy and Structure: Chapters in the History of
American Industrial Enterprise, The MIT Press, Cambridge, MA

(Cheng, 2000) Chen G. and Kotz D. A Survey of Context-Aware Mobile Computing Research.
Technical Report TR2000-381, Dartmouth Computer Science, November, 2000

(Clevenger, 2011) Clevenger N., iPad in the Enterprise: Developing and Deploying Business
Applications, John Wiley & Sons, 2011

(Ciborra, 1997) Ciborra C., «Deconstructing the concept of strategic alignment» Scandinavian
Journal of Information Systems, Vol 9 n°1,1997, pp. 67–82.

(Daniel, 1961) Ronald Daniel, Management information crisis.


Harvard Business Review (September–October 1961), pp. 110–119.

(DoD, 1998) Department of Defense , «C4ISR Architecture Working Group Final Report -
Levels of Information System Interoperability (LISI) »,Washington DC: OSD(ASD(C3I))
C4ISR AWG, 1998.

(Elhari, 2010] Elhari K., Bounabat B., «Strategic Alignment Assessment Based on Enterprise
Architecture » Proceedings of the International Conference on Information Management and
Evaluation (ICIME), 2010, pp.179-187.

(Etien, 2006) Etien A., «L’ingénierie de l’alignement: Concepts, Modèles et Processus La


méthode ACEM pour la correction et l’évolution d’un système d’information aux processus
d’entreprise», thèse de doctorat, 13 mars 2006, Université Paris 1.

(FEAF, 1999), “Federal Enterprise Architecture Framework Specification”,


http://www.whitehouse.gov/omb/e-gov/fea/

(Fimbel, 2006) Alignement stratégique : Synchroniser les systèmes d’information avec les
trajectoires et manœuvres d’entreprises, Eric Fimbel, Pearson Education France, 2006, ISBN
978-2-7440-7226-0

(Hax, 1996) Arnoldo C. Hax (1996), “Strategy Concept and Process: A Pragmatic Approach”,
Barnes and Noble, bn.com

112
Bibliographie

(Henderson et al, 1989) Henderson J., Venkatramen N., «Strategic Alignment: A Model
forOrganisational Transformation», Transforming Organisations , New York.

(Henderson et al, 1993) Henderson J., Venkatraman N., «Strategic alignment: Leveraging
information technology for transforming organizations», IBM Systems Journal, Vol. 32, No.1,
1993, pp.4-16, reprint in IBM Systems Journal, Vol. 38, No.2, 1999, pp.472-484.

(Kearns et al, 2000) Kearns G S, A. Lederer A L, «The effect of Strategic Alignment on the
Use of IS based Ressources for Competitive Advantage», Journal of Strategic Information
Systyems, vol. 9, pp 265-293, 2000.

[Kearns et al, 03] Kearns G S., Lederer A L., «A Resource-Based View of Strategic IT
Alignment: How Knowledge Sharing Creates Competitive Advantage» Decision Science,
Vol.34, No.1 pp. 1-29.

(Kleppe et al, 2003) Kleppe A., Warmer J., Bast W., «MDA Explained – The Model driven
Architecture : Practise and Promise», Object Technology Series, Addison-Wesley, 2003.

(Lakhdissi, 2011) Lakhdissi M, Bounabat B (2011). “Toward a novel methodology for IT


Strategic Planning”. Proceedings of ICIME 2011, p 277-287, Toronto Canada, ISBN: 97-1-
906638-98-6, April 2011.

(Lakhdissi, 2012) Lakhdissi M, Bounabat B (2012). “A new content metamodel for IS Strategic
Planning with a tool implementation”, International Jounal of Computer Science Issues (IJCSI)
Volume 8 Issue 8, Mars 2012.

(Lakhdissi et al 2013) Lakhdissi M, Elhabi R and Bounabat B. “Adapting IS Strategic Planning


methodology to define Mobile Strategy”, International Jounal of Computer Science
Issues(IJCSI), Vols. Volume 10 Issue 5, September 2013.

(Lankhorst, 2005), Lankhorst M., «Enterprise architecture at work: Modelling, communication


and analysis», Springer Berlin Heidelberg New York, 2005.

(Lederer, 1988) Lederer, A. L. and Sethi, V. (1988). The Implementation of Information


Systems Planning Methodologies, MIS Quarterly, September 1988, 445-461.

(Lederer, 1992) Lederer, Albert L., and Gardiner, Veronica, “Strategic Information Systems
Planning – The Method/1 Approach,” Information Systems Management, Summer, 1992.

(Lillehagen, 2005) Lillehagen F., Karlsen D., Enterprise Architectures – Survey of Practices
and Initiatives, Rapport Computas 2005.

(Longépé, 2004), Longépé C., Le projet d'urbanisation du SI - Démarche pratique avec cas
concret, Dunod, 2004, 284p.

(Luftman, 1996) Luftman J N., Competing in the information age: strategic alignment
inpractice, Oxford University Press, 1996, 414p.

(Luftman, 2000) Luftman J N., Assessing business-IT alignment maturity Communications of


the Association for Information Systems, Communications of the Association for

113
Bibliographie

Information Systems, Vol. 4, No.14, 2000, pp.1-50.

(Martin, 1982) Martin James, Strategic Data-Planning Methodologies, Prentice Hall, 1982.

(Merriam, 2010) Merriam Webster Dictionnary (2010), Dictionnary definition of Methodology


and Method http://www.merriam-webster.com/dictionary/method,http://www.merriam-
webster.com/dictionary/methodology?show=0&t=1290517042

(McCoy et al., 2006) McCoy D. W. et Plummer D. C., «Defining, Cultivating and Measuring
Enterprise Agility» , Gartner Research, 2006.

(MoD, 2008) Ministry of Defence « MOD Architecture Framework version 1.2.003». Technical
report, Ministry of Defence, UK, September 2008.

(Morel et al, 2008) SOA : Le guide de l’architecte du SI, X, Morel, P, Grojean, G. Plouin, C.
Rognon, 2ème édition, Dunod, ISBN 978-2-10-051708-4

(Mernik, 2005) Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to
develop domain-specific languages. ACM Comput. Surv., 37(4):316-344, 2005.

(Novica et al, 2006) Zarvic N., Wieringa R J., «An Integrated Enterprise Architecture
Framework for Business-IT Alignment. » 18th International Conference on Advanced
Information Systems Engineering (CAiSE'06), Luxembourg, 5-9 Jun 2006.

(OMG, 2003) Object Management Group, MDA Guide Version 1.0.1, Document Number:
omg/2003-06-01, June 2003.

(OMG, 2008) Object Management Group, Business Motivation Model Specification,


http://www.omg.org/spec/BMM/1.0/PDF, Août 2008

(OMG, 2013) Object Management Group, Unified Modeling Language Specification Version
2.5, http://www.omg.org/spec/UML/2.5/Beta2/PDF, Septembre 2013

(Pant, 1995) Pant S., Hsu C.: Strategic Information Systems Planning: A Review, 1995
Information Resources Management Association International Conference.

(Papp, 1998) Papp R., «Alignment of Business and Information Technology Strategy: How and
Why? » Information Management, Vol.11, No. 4, pp. 6-11.

(Perks, 2003) Perks, C. and Beveridge, T. Guide to Enterprise IT Architecture, Springer-Verlag,


New York, 2003.

(PMI, 2013) A Guide to the Project Management Body of Knowledge, Fifth Edition, Janvier
2013

(Porter, 1985) Porter, M. E. (1985). Competitive Advantage: Creating and Sustaining Superior
Performance, Collier Macmillan, New York, N.Y.

(Porter, 1987) Porter M., «From competitive advantage to corporate strategy» Harvard Business
Review, Vol.65, No.3, 1987, pp.43-59.

114
Bibliographie

(Regev et al, 2004) Regev G., Wegmann A., «Remaining Fit: On the Creation and Maintenance
of Fit», Proceedings of BPMDS Workshop on Creating and Maintaining the Fit between
Business Processes and Support Systems, Riga, Latvia, 2004, pp.131-137.

(Rockart, 1981) Rockart John F. "A Primer on Critical Success Factors" published in The Rise
of Managerial Computing: The Best of the Center for Information Systems Research, edited
with Christine V. Bullen. (Homewood, IL: Dow Jones-Irwin), 1981.

(Schekkerman, 2004) Schekkerman J., How to Survive in the Jungle of Enterprise Architecture
Frameworks: Creating or Choosing an Enterprise Architecture Framework, Trafford
Publishing, Vic-toria, British Columbia, 2004.

(Schilit, 1994) Schilit B. Adams N. Want R., Context-aware computing applications. In


Proceedings of IEEE Workshop on Mobile Computing Systems and Applications, pages 85-90,
Santa Cruz, California, IEEE Computer Society Press, December 1994.

(Schwartz, 1991) Schwartz P., The art of the long view: paths to strategic insight for yourself
and your company. Doubleday, New York.

(Sessions, 2007) Sessions R. : “A Comparison of the Top Four Enterprise-Architecture


Methodologies”, http://msdn.microsoft.com/en-us/library/bb466232.aspx (2007).

(Soffer, 2004) Soffer P., «Fit Measurement: How to Distinguish Between Fit and Misfit», note
for BPMDS'04, Workshop on Creating and Maintaining the Fit between Business Processes
and Support Systems, Riga, Latvia, 2004.

(Sousa et al, 06) Sousa P., Caetano A., Vasconcelos A., Pereira C., Tribolet J., Enterprise
Modeling and Computing with UML, Idea Group Publishing, 2006.

(TAFIM, 1996) TAFIM, Department of Defense. Technical Architecture Framework for


Information Management. Vol. 1. April 1996

(TEAF, 2000), U.S. Department of the Treasury. Treasury Enterprise Architecture Framework
Version 1, http://www.software.org/pub/architecture/teaf.asp, 2000.

(Thevenet, 2009) Thevenet L H., « Proposition d’une modélisation conceptuelle d'alignement


stratégique : La méthode INSTAL », Université Paris 1, Thèse de doctorat, 11 décembre 2009.

(TM Forum, 2011) TM Forum, Guide to applying Business Process Framework eTOM, April
2011

(TOGAF, 2011) TOGAF, The Open Group. 2011. TOGAF : The Open Group Architecture
Framework 9.1 "Enterprise Edition". http://www.opengroup.org/architecture/togaf/.

(Unilog, 2005) SOA et urbanisme Le rôle des Architectures Orientées Services dans
l’alignement métier des Systèmes d’Information, Unilog Managment, 2005. Disponible en
ligne:http://www.cio-online.com/fichiers/librairie/urbanisme-et-architectures-
orienteesservices. pdf. 19 Juillet 2011.

115
Bibliographie

(Vernadat, 2002) F. Vernadat "UEML: towards a unified enterprise modelling language".


In: Int. J. Production Research, 40 (17), 4309-4321.

(Vitale, 1986) Vitale, M., Ives, B. and Beath, C. (1986), “Identifying Strategic Information
Systems,” Proc. 7th Int’l Conf. Inf. Sys., San Diego, December 1986, pp. 265-276.

(Wieringa, 2003) R J Wieringa R J., Blanken H M., Fokkinga M M., Grefen P W., «Aligning
application architecture to the business context» Proceedings of 15th Conference on Advanced
Information System Engineering (CAiSE 03), Springer, 2003, p.209–225.

(Wilton, 2008) Wilton, D. (2008). The Relationship Between IT Strategic Planning and
Enterprise Architectural Practice, Journal of Battlefield Technology, 1, 18-22.

(Wilton, 2007) Wilton, D. (2007). The Relationship between IS Strategic Planning and
Enterprise Architectural Practice: a Study in NZ Enterprises, Information Resources
Management Association (IRMA), Vancouver.

(Wiseman, 1988) Wiseman C., Strategic Information Systems. Homewood, Illinois.

(Zachman, 1987) Zachman, J. A., «A framework for information systems architecture». IBM Syst.
J.26(3), 1987, pp. 276–292.

116
ANNEXES

ANNEXES
Annexe 1 : Méthodes et référentiels
Annexe 2 : Technologies de la plateforme ESPAM
Annexe 3 : Livrables détaillés de l’étude de cas
Annexe 4 : Modèles de livrables ESPAM

117
Annexe 1 : Méthodes et référentiels

Annexe 1 : Méthodes et référentiels

Méthode RACINES
Etape 1 - Etude d'opportunité et préparation du plan stratégique

Cette étape a pour objet de motiver les instances dirigeantes de l'institution, de vérifier
l'opportunité de l'élaboration d'un plan stratégique, d'affirmer ou de faire connaître la volonté
politique de l'institution et de créer les conditions de bon déroulement de l'opération.

Les premières phases de cette étape sont menées par la direction générale qui rappelle la
politique générale de l'entreprise, approuve le lancement de l'étude d'opportunité, mandate un
responsable provisoire, examine les conclusions de l'étude d'opportunité, et décide d'ajourner
ou de poursuivre l'étude. Dans ce cas, la direction générale définit les objectifs du plan
stratégique, nomme le chef de projet de l'opération plan stratégique, désigne les membres du
comité directeur, approuve les enveloppes de charge de l'opération plan stratégique, et examine
l'opportunité de faire appel à un conseil extérieur.

Le comité directeur reçoit délégation de la direction générale pour prendre les décisions qui
surviennent au cours de l'opération plan stratégique et arrête la constitution du groupe de projet,
le dossier d'évaluation des charges, la constitution et la désignation des responsables des
groupes d'utilisateurs, le cahier des charges de l'opération plan stratégique et le choix éventuel
du conseil extérieur.

Les documents établis sont au nombre de quatre. L'étude d'opportunité expose les arguments et
les réserves émises à l'égard de l'opération plan stratégique SI. La note d'information présente
les conclusions de l'étude d'opportunité et les décisions prises. Le dossier d'évaluation des
charges identifie les contributions des différents groupes de travail. Le cahier des charges de
l'opération plan stratégique SI précise sa dominante stratégique ou opérationnelle et définit le
champ et la taille de l'étude, fixe les modalités structurelles et organisationnelles du déroulement
de l'opération, l'évaluation des charges (financières, logistiques et en personnel) et le calendrier
général de l'opération.

Etape 2 - Bilan et orientation

Cette étape a pour objet d'établir un bilan de la situation actuelle de l'entreprise en ce qui
concerne les systèmes d'information et de gestion et les moyens de traitement et de
communication de l'information, de dégager des orientations générales, et de mesurer les
possibilités d'amélioration de l'efficacité de l'organisation et du fonctionnement de l'entreprise
par rapport à l'état de l'art.

Le comité directeur doit se prononcer sur les taux de progression des charges et les délais
attendus, les évolutions prévisibles des enveloppes budgétaires, la politique de redéploiement
du financement de l'informatique entre les directions utilisatrices, les valeurs à viser comme
objectifs d'efficacité et la politique du personnel.

118
Annexe 1 : Méthodes et référentiels

Les principaux documents sont au nombre de trois. Le bilan du système de gestion et


d'information décrit les grandes lignes de l'existant et fournit une appréciation du degré de
satisfaction des utilisateurs. L'inventaire de l'existant décrit les informations traitées, les
applications et les projets existants ou en cours de développement. La note de synthèse résume
les objectifs et les perspectives de développement du système.

Etape 3 - Les scénarios possibles

Il s'agit de proposer au comité directeur un nombre restreint de scénarios, à partir de la solution


conceptuelle retenue lors de l'étape précédente. Un scénario comprend une solution
conceptuelle, une solution organisationnelle, une solution technique, une évaluation financière,
un enchaînement de phases traduisant les priorités et l'évaluation des principaux impacts du
scénario sur l'organisme.

Pour un plan stratégique à tendance opérationnelle, on définit en général un scénario tendanciel,


un scénario contrasté et un scénario mixte. Pour un schéma à tendance stratégique, les scénarios
représentent plus volontiers les stratégies politiques possibles de l'entreprise (choix de filières
d'équipements, de normes, politique de personnel, etc.).

Les documents intermédiaires comprennent la synthèse comparative, des solutions


organisationnelles et techniques étudiées. Les documents de fin d'étape comprennent la note de
synthèse comparative des différents scénarios présentés, la note de présentation détaillée de
chaque scénario, et le compte rendu de la réunion du comité directeur, faisant état des
motivations ayant conduit au choix de l'un des scénarios et au rejet des autres.

Etape 4 - Plans d'actions

L'objectif de cet étape est d'aboutir progressivement à une description détaillée et quantifiée du
scénario retenu lors de l'étape précédente sous forme de plans d'actions en cernant les
conséquences de ces actions sur la structure et le fonctionnement des services, par rapport à la
situation de départ, évaluant les moyens techniques et humains nécessaires et déterminant les
enjeux, les coûts et les conditions de mise en œuvre.

Le comité directeur peut être amené à ajuster le scénario retenu en fonction des contraintes
révélées au cours de cette étape.

Les principaux documents sont la description détaillée du scénario (objectifs, politique en


matière de personnel et de matériel, actions clés), la synthèse des plans d'actions, sous forme
de plans annuels glissants et le recueil des plans d'actions spécialisés, (personnel, équipement
et financement).

Etape 5 - Mise en œuvre et suivi

Cette dernière étape a pour objectifs de définir les structures, les moyens et les procédures
nécessaires au suivi du plan stratégique, de mettre en forme et de rédiger les conclusions de
l'étude du plan stratégique SI, et d'arrêter les modalités de diffusion et de mise en application
des actions prioritaires pour le premier plan.

119
Annexe 1 : Méthodes et référentiels

Les principaux documents sont le document plan stratégique proprement dit, la note de synthèse
du plan stratégique, destinée aux instances dirigeantes, la note de définition des structures et
procédures de suivi, et la note de mise en application précisant les documents à diffuser et leurs
destinataires.

Référentiels qualité
Les DSI doivent aujourd'hui faire face à une problématique complexe de réalisation de projets
de plus en plus coûteux dans un contexte de réduction des budgets. Il s'agit donc pour eux de
maîtriser les coûts de réalisation des projets mais aussi et surtout les coûts récurrents
d'exploitation des applications dès lors qu'elles sont mises en production.

Face à cette problématique, il convient de travailler sur trois axes :

 Maîtriser l'organisation projet pendant la phase de réalisation en mettant en œuvre des


méthodologies adaptées
 Optimiser l'organisation et les processus dans le cadre de la production en vue de réduire
les coûts tout en améliorant le service rendu aux utilisateurs en mettant en œuvre des
pratiques éprouvées dans ce domaine, regroupées dans un référentiel public
 Agir sur le niveau de qualité des applications produites afin de réduire les incidents en
production. Cela doit se faire en amont, lors de la réalisation du projet en appliquant des
règles strictes au niveau de l'assurance qualité.
Par ailleurs, la gouvernance du système d'information est devenue également un enjeu de taille.
Cette gouvernance passe, en partie, par la constitution d’un corpus de références par grands
domaines ou grands processus du système d’information.

Le recours aux bonnes pratiques est à la fois un support méthodologique efficace et également
une sorte de label que le décideur informatique pourra mettre en avant pour démontrer qu'il a
pris les meilleures dispositions possibles.

Ci-après une synthèse de référentiels de bonnes pratiques SI existants. Dans la définition de


l'organisation cible, une sélection de celles-ci doit être faite.

Les principaux référentiels de bonnes pratiques, actuellement en vogue, sont :

 COBIT (Control Objectives for Business & Related Technology),


 ITIL (Information Technology Infrastructure Library),
 CMMi (Capability Maturity Model Integration).
Très complémentaires, ils sont destinés chacun à un domaine particulier.

Outre ces trois référentiels, il en existe d'autres, plus ou moins spécifiques ou plus moins "à la
mode":

 PMI (Project Management Institute),


 ISO 9000,
120
Annexe 1 : Méthodes et référentiels

 ISO 20000.
Même si chaque système a plus ou moins été étendu aux différentes facettes de l'activité
informatique, chaque référentiel trouve son efficacité dans un domaine particulier. Il n'est pas
donc pas trop difficile de se tourner vers celui qui sera pertinent dans le cadre spécifique qui
préoccupe l'entreprise.

CobiT
COBIT (Control Objectives for Business & Related Technology), est utilisé pour la
gouvernance et l'audit des systèmes d'information.

Il analyse le système informatique suivant 4 axes :

 planning et organisation,
 acquisition et mise en place,
 fourniture du service et support,
 surveillance.
Il est important de noter que la loi américaine Sarbanes Oxley impose d'utiliser l'infrastructure
de contrôle interne COSO (Committee of Sponsoring Organizations). En l'absence de
méthodologie précisée, beaucoup de grandes entreprises ont considéré que le CobiT était la
meilleure voie pour rendre le système d'information conforme aux exigences du COSO.

ITIL
ITIL (Information Technology Infrastructure Library), s'intéresse à la production, qu'il s'agisse
de fourniture de services informatiques ou d'exploitation interne.
C'est donc une voie pour s'assurer de la satisfaction des utilisateurs et/ou des clients (internes
ou externes) des services informatiques.

CMMi
CMMi (Capability Maturity Model intégration) est le référentiel dédié au développement de
systèmes et logiciels. CMMi permet d'évaluer la maturité de l'entreprise sur 5 niveaux :

 initial,
 reproductible,
 défini,
 maîtrisé.
 optimisé.
PMI/PMBoK
Le PMI (Project Management Institute) a développé le standard PMBOK (Project Management
Body of Knowledge, élaboré sur la base des meilleures pratiques du management de projet.

Il est organisé suivant 6 domaines :

 intégration du projet,

121
Annexe 1 : Méthodes et référentiels

 contenu du projet,
 délais du projet,
 communication du projet,
 risques du projet,
 approvisionnements du projet.
Le PMI propose une certification en management de projet correspondante, le PMP (Project
Management Professionals).

ISO 9000
Les certifications de la famille ISO 9000 constituent désormais un ensemble de références de
qualité, incontestées sur le plan mondial. Très généralistes, ces spécifications ne sont pas
forcément les plus productives pour l'informatique.

ISO 20000
Conçue dès le début comme un complément d'ITIL, la norme CEI/ISO 20000 a été élaborée
par British Standards Institute. C'est la première norme de gestion des services informatiques.
La norme ISO 20000 se compose de deux parties :

 La première partie consacrée à la spécification de la gestion des services précise les


conditions qu'une organisation doit remplir pour être conforme à la norme et obtenir une
certification,
 La deuxième partie, Code de pratique de gestion de services, dépasse la simple description
de la condition de conformité et offre des conseils pratiques aux fournisseurs de services
qui souhaitent devenir conformes à la norme

122
Annexe 2 : Technologies de la plateforme ESPAP

Annexe 2 : Technologies de la plateforme


ESPAP

Présentation de GEF
GEF (Graphical Editing Framework) est un framework aidant à implémenter un éditeur
graphique correspondant à un modèle. Il utilise la bibliothèque Draw2D basé sur la bibliothèque
graphique SWT pour créer un environnement graphique utilisable dans Eclipse. Ce plug-in
permet la manipulation de formes simples. GEF rajoute une couche supérieure à la bibliothèque
Draw2D pour l'encapsuler dans un canvas d'édition suivant le modèle MVC afin d'assurer que
les applications développées avec GEF suivent ce même modèle d'architecture d'interface.
Le modèle MVC dans GEF
Le modèle MVC est utilisé pour structurer une interface développé avec GEF car GEF lui-
même l'utilise. Il présente quelques différences avec le modèle MVC classique considéré
comme connu. Le modèle MVC de GEF est un MVC modifié et voici ce qui diffère entre les
deux.
- Le modèle :

GEF voit le modèle comme de simples classes JAVA. Ce modèle est séparément développé, à
l'aide du Framework EMF par exemple. Comme il ne connait pas la vue, un mécanisme de
notification doit être mis en place afin de maintenir la cohérence avec la vue, c'est le rôle joué
par GEF. Ainsi, à l'aide de "listener", le contrôleur écoute le modèle. Dès qu'un changement est
effectué sur le modèle, celui-ci prévient le contrôleur, contrairement au MVC standard, dans
lequel les changements sont "ordonnés" par le contrôleur qui n'a donc pas besoin d'écouter le
modèle pour les connaître.
- La vue

GEF utilise la librairie graphique Draw2D pour dessiner l'interface graphique de


l'application, ainsi que les données du modèle représentées par des formes simples ou plus
complexes. Et comme cela est dit ci-dessus, le MVC de GEF est différent du standard, ici la
vue est prévenue de la modification du modèle uniquement par le contrôleur et non par le
modèle.
- Le contrôleur

Dans GEF, le contrôleur est appelé Edit Part. Il se met à l'écoute du modèle et dès que celui-ci
le prévient d'un changement, il prévient à son tour la vue de ce changement. Ces changements
sont, le plus souvent, dus à une action de l'utilisateur sur la vue. De plus, et c'est le cas du MVC
classique, chaque objet correspond à un contrôleur qui correspond lui-même à un élément
graphique. Chaque contrôleur fils agit ainsi seulement sur l'objet du modèle et sa forme
associée.

123
Annexe 2 : Technologies de la plateforme ESPAP

Lien entre EMF et GEF


Tout Objet EMF (EObject) est également une notification qui permet l’écoute des objets dans
GEF. Les EditParts de GEF agissent comme contrôleurs : ils reçoivent les notifications de saisie
et orientent proprement alors les changements au niveau du model EMF correspondant ainsi
que des objets de la vue. Ils gardent également une suite de connections entre les objets du
model EMF et toute autre communication.
Génération du modèle
EMF comme cité dans les sections précédentes permet la génération de code. Ce qui suit montre
comment procéder à la génération du code.
Après introduction du modèle dans Eclipse, la génération de code se fait comme le montre la
figure n°64 :

Générer le modèle (les interfaces


et leurs implémentations)

Possibilité de générer même un


éditeur basique, ainsi que des
exemples pour tests.

Figure 64: Procédure de génération de code

124
Annexe 3 : Livrables détaillés de l’étude de cas

Annexe 3 : Livrables détaillés de l’étude de cas

Définition de l’architecture applicative cible (Phase 4 d’ESPAM)

La figure ci-après présente la couverture applicative cible de la chaine de valeur. Cette figure
indique également le type de chaque application : progiciel, développement spécifique,
développement basée sur l'utilisation des briques logicielles standards.

Figure : Couverture applicative cible de la chaine de valeur

Les tableaux suivants présentent une fiche pour chaque application cible avec un ensemble
d’informations utiles concernant chaque application comme les unités d’organisation
concernées, la priorité, la valeur métier, le type d’architecture et les briques logicielles à utiliser
pour la mise en œuvre de l’application.

125
Annexe 3 : Livrables détaillés de l’étude de cas

Application Extranet
Fonctionnalités Il s’agit d’une application qui va constituer le point de contact
principal avec le marché et va permettre d’offrir les fonctionnalités
suivantes :
- réceptions de données de la part des intervenants
- Gestion des demandes en termes de réception et de suivi:
avec la possibilité de consultation par l’intervenant
- Gestion des plaintes : avec une interface de suivi
- Gestion des contacts : permet d’enregistrer et suivre tout
les contacts entrants et sortants avec les intervenants
(courrier et requêtes en provenances et vers l’intervenant)
- Dépôt de dossier électronique pour les demandes
d’autorisation (e-filing)
Unité d'organisation Transverse
Sous unité d'organisation Transverse
Type d'application Développement spécifique
Valeur métier Elevée
Priorité de mise en place Elevée
Niveau de demande Elevé
Architecture Web
Catégorie Front office
Briques logicielles à utiliser Portail (éventuellement)

Application Gestion des données intervenants et produits


Fonctionnalités Il s'agit de l'application maître qui doit gérer les données de
référence métier à savoir les données des intervenants (ou tiers) et
celles des produits.
Cette application doit offrir deux grandes fonctionnalités :

1. Mise à jour des données concernant les intervenants et


les produits :
o Création
o Modification
o Suppression logique
2. Synthèse des données relatives aux intervenants et aux
produits. Cette fonctionnalité permet d'offrir à
l'utilisateur une vue unique sur toutes les informations
concernant les intervenants et les produits. Exemple
pour une société de bourse, cette application doit
afficher les informations concernant cette société ainsi
que l'historique des autorisations, des suivis, des
échanges, des inspections et des enquêtes la
concernant.

De part sa nature, La base de données de cette application est


« maître » des données de référence métier. Cette base de données
doit être synchronisée avec les bases de données des autres

126
Annexe 3 : Livrables détaillés de l’étude de cas

applications métiers (esclaves), notamment celle de la gestion des


autorisations et de contrôle sur pièces.

Unité d'organisation Transverse


Sous unité d'organisation Transverse
Type d'application Développement spécifique
Valeur métier Elevée
Priorité de mise en place Elevée pour la fonction de mise à jour. La fonction de
synthèse/consultation peut être développée ou intégrée une fois les
applications de gestion des autorisations et de contrôle sur place
sont déployées.
Niveau de demande Elevé
Architecture Web / Desktop
Catégorie Back office
Briques logicielles à utiliser Aucune

Application Gestion des inspections


Fonctionnalités Gestion des
Inspections :
Validation du planning annuel d’inspection
Programmation d’une mission d’inspection
Préparation des missions d’inspection
Réalisation de mission l'inspection
Rédaction, validation et envoi du rapport
d’inspection
Validation des rapports d’inspection
Travaux post-inspection

Unité d'organisation Transverse


Sous unité d'organisation Transverse
Type d'application Progiciel
Valeur métier Assez élevée
Priorité de mise en place Moyenne
Niveau de demande Elevé
Architecture Selon type de la solution
Catégorie Back office
Briques logicielles à utiliser Aucune

127
Annexe 3 : Livrables détaillés de l’étude de cas

Application Suivi des transactions et gestion des enquêtes


Fonctionnalités Suivi des
transactions Surveillance en ligne
Surveillance en différé
Surveillance rapprochée
Gestion de l'historique des transactions
Gestion des Instruction du dossier "enquête et
enquêtes sanction"
Rédaction et validation du rapport de
l'enquête
Unité d'organisation Direction Générale
Sous unité d'organisation Surveillance, Service enquête
Type d'application Progiciel
Valeur métier Elevée
Priorité de mise en place Moyenne
Niveau de demande Elevé
Architecture Selon type de solution
Catégorie Back office
Briques logicielles à utiliser Aucune

Application Gestion des risques


Fonctionnalités - Identification des risques
- Analyse & traitement des risques
- Surveillance et revue de la gestion des risques

Unité d'organisation Transverse


Sous unité d'organisation Transverse
Type d'application Progiciel
Valeur métier Elevée
Priorité de mise en place Moyenne
Niveau de demande Elevé
Architecture Selon type de solution
Catégorie Back office
Briques logicielles à utiliser Aucune

Définition de l’architecture logicielle cible (Phase 4 d’ESPAM)

Afin de mieux positionner le rôle de chaque brique logicielle par rapport au fonctionnement du
futur SI de l’organisme de régulation, les deux figures suivante présentent une vue en couche,
respectivement statique et dynamique, de l'architecture logicielle du système d'information
cible.

128
Annexe 3 : Livrables détaillés de l’étude de cas

Figure 65 : Vue "statique" en couche de l'architecture logicielle cible

La vue suivante est une vue dynamique qui présente le fonctionnement des différentes briques
logicielles du SI cible.

Figure 66 : Vue "dynamique" en couche de l'architecture logicielle cible

129
Annexe 3 : Livrables détaillés de l’étude de cas

Fiche projet du Plan Stratégique SI de l’organisme de régulation


(Phase 5 d’ESPAM)

Fiche de projet

Identification
Fiche de projet
Code PRJ_PSSI_14

Nom Mise en place d'un espace Web (site internent +


Extranet)
Direction/service Direction métier

Synthèse

130
Annexe 3 : Livrables détaillés de l’étude de cas

Description et objectifs

Ce projet à pour objectif la mise en place d’une application qui repose sur un
développement utilisant des briques logicielles (solution portail). Cette application doit
constituer le point de contact principal avec le marché et va permettre d’offrir les
fonctionnalités suivantes :

- Gestion des demandes en termes de réception et de suivi avec la possibilité de


consultation par l’intervenant
- Gestion des plaintes : avec une interface de suivi
- Gestion des contacts : permet d’enregistrer et suivre tous les contacts entrants et sortants
avec les intervenants (courrier et requêtes en provenances et vers l’intervenant)
- Dépôt de dossier électronique pour les demandes d’autorisation (e-filing)
- Eventuellement, dépôt de dossiers de suivi (spécifiques aux intervenants et aux produits).
- Mise en place d’un espace avec la possibilité de saisir dans des formulaires et d’envoyer
des fichiers pré-formatés
Ce système extranet doit présenter une exposition du système d'information cible vis-à-vis
des sociétés régulées (ensemble d'IHM Web). De ce fait, sa mise en place nécessite un
système d'information métier orienté services et homogène. Dans ce cadre, les futures
applications métiers (notamment celles relatives aux autorisations, aux suivis et d'accès aux
référentiels de données) doivent exposer leurs fonctionnalités afin de pouvoir les invoquer
au niveau du système extranet.

Cette dépendance avec les applications métier contraint une mise en œuvre de l'extranet
d'une manière progressive (évolution avec l'avancement des projets métier) ou à la fin de
la mise en œuvre des projets métiers.

Une fois que l'extranet est mis en place, son évolution doit être intégrée aux projets
d'évolutions des projets métier pour éviter tout décalage entre ces systèmes.

Livrables

 Application extranet
 Modèle de données de cette application
 Dossiers de spécifications fonctionnelles et techniques
 Dossiers de conception
 Dossier de tests
 Dossier d'exploitation et d'administration
 Manuel de déploiement
 Modes opératoire de passage entre environnements
 Manuels d'utilisation

131
Annexe 3 : Livrables détaillés de l’étude de cas

Risques

 La réalisation de cette application dépend de l'avancement des projets de mise


en œuvre des applications de gestion des autorisations et de contrôle sur pièces.
De ce fait, sa mise en œuvre risque d'être discontinue si elle s'effectue en parallèle
avec les projets métier de gestion d'autorisation et de contrôle sur pièces.
 Le plan de charge prévu ne comporte pas une charge spécifique aux
o tests de charge (ou de performance). Ces tests doivent être effectués à l'issue
de la phase d'intégration et doivent simuler des scénarios d'utilisation réalistes
en termes de nombre d'utilisateurs simultanés et du volume de données à
traiter (exemple : fichiers déposés).
o Tests de sécurité : cette application doit être hautement sécurisée (documents
confidentiels, espace privé, etc.). Un ensemble de tests de sécurité doivent
être effectués avant son déploiement

Périmètre

Stratégie Architecture applicative Architecture technique

Architecture métier Architecture de données

Nature de mise en œuvre

Etude Intégration de Développement à base Développement


progiciel de briques logicielles spécifique

80 % 20 %

Transformations associées

132
Annexe 3 : Livrables détaillés de l’étude de cas

Transformation Type Objet Lien avec le projet


Espace Web : Site Internet
Ecart_APP_06 Ajout Fait partie du projet
+ Extranet
Transforma
Transformation des
tion
applications GVM et SCSB
/ Pré-requis pour le projet
Ecart_ APP_ 02 vers une nouvelle
Migration
application de Contrôle sur
/
pièces
évolution
Application Gestion des Pré-requis pour le projet
Ecart_ APP_ 01 Ajout
autorisations
Application Contrôle sur Pré-requis pour le projet
Ecart_ APP_ 02 Ajout
pièces
Ecart_ Don_ 01 Ajout Base de données
Pré-requis pour le projet
"Autorisations"
Ecart_ Don_ 02 Ajout Base de données "Suivi" Pré-requis pour le projet
Ecart_ LOG_ 01 Ajout Intégration des briques
Fait partie du projet
logicielles
Ecart_ Don_ 06 Ajout Base de données
"Demandes, plaintes et
contacts"
Ecart_ MAT_ 01 Refonte Plateforme serveur de
l'environnement de Pré-requis pour le projet
production et de recette
Ecart_Don_10 Ajout Référentiel "Intervenants" Pré-requis pour le projet
Ecart_Don_11 Ajout Référentiel "Produits"" Pré-requis pour le projet

Origine du besoin

Origine Description Type Source


Attentes métier
ATT-M18 Extranet dédié aux intervenants

Automatisation de la réception et du
Attentes métier
ATT-M15 contrôle sur pièces

Faible utilisation de certaines Diagnostic


DIAG-APP-07
applications
Pas d’utilisation de briques Diagnostic
DIAG-DON-07
technologiques/logicielles standards
Faible contrôle automatique sur les
Principe 10 Ligne directrice
données
Modernisation et simplification de
Assertion 2 Ligne directrice
l'environnement IT

Assertion 3 Architecture Basée sur les Composants Ligne directrice


Assertion 5 Architecture orientée services Ligne directrice
Assertion 7 Intégration d’Application Ligne directrice
Assertion 8 Référentiel de données communes Ligne directrice

133
Annexe 3 : Livrables détaillés de l’étude de cas

Pré-Requis et dépendances

Type Description

Projet : PRJ_PSSI_07 Mise en place d’une application de gestion des autorisations

Projet : PRJ_PSSI_08 Mise en place d’une application de gestion


de contrôle sur pièces

Projet : PRJ_PSSI_09 Gestion et synthèses des données intervenants et produits

Projet : PRJ_PSSI_05 Acquisition et mise en place de la plateforme logicielle et


matérielle

Niveau de criticité

Critique Important Moyen Faible

Charge de travail (en J.H)

Charges en JH

Avant projet Projet Total

Tâche/profil Interne externe interne externe Interne externe Total

Gestion de 35 30 0 30

projet

MOA (métier) 0 0 0

AMOA 20 35 20 50 20 70

AMOE 10 20 30 30 30 60

MOE 140 0 240 240

Total 30 0 90 190 110 290 310

Ce plan de charge n'intègre pas la mise en place et la conduite de changement auprès des intervenants.

Récapitulatif délais

Date de démarrage projet : Dead line ? Oui Non

Date de fin de projet :

134
Annexe 3 : Livrables détaillés de l’étude de cas

Budget prévisionnel

Type de
Description Budget (en DH HT)
ressource
Logiciel Dépend de la solution portail retenue
Intégré dans le cadre de projet d'acquisition de la
Matériel
plateforme matérielle et logicielle
AMOA, Architecture, intégration et développement à 890 000
base de briques logicielles type portail Web

AMOA 20 JH à base de 5 000 DH/J


Assistance
AMOE 30 JH à base de 5 000 DH/J

MOE 240 JH à base de 3 500 DH/J

Formation
Autre
Total 890 000

Planning prévisionnel

Phases M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15

Etude préalable et cadrage


fonctionnel et technique

Etude détaillée fonctionnelle et


conception technique

Mise en œuvre

Recette

Mise en production

135
Annexe 3 : Livrables détaillés de l’étude de cas

Plan d’alignement stratégique (Livrable de la phase 6 d’ESPAM)


Dans le cadre de l’alignement stratégique de l’organisation, d'une manière générale, les
domaines les plus fréquemment couverts par un référentiel SI, qu’il soit interne ou inspiré d’une
norme se situent autour du :
- Production et qualité de service.
- Sécurité
- Gouvernance
- Projets & Développement
- Achats " Gestion des acquisitions et de la sous-traitance"
- Contrôle et pilotage
- Qualité
- Architecture

Cette partie présente les bonnes pratiques des domaines les plus pertinents liés au système
d'information cible d’un organisme de régulation et à sa mise en œuvre. La prise en compte de
ces bonnes pratiques peut se faire d'une manière progressive.

Production et qualité de service

Sous domaines Processus et bonnes pratiques


Fourniture de − Gestion des niveaux de service : Maintenir et améliorer la qualité
services de service aux utilisateurs en détectant les dysfonctionnements,
en améliorant les procédures à travers des cycles permanents de
suivi, de contrôle et de réévaluation des processus
− Gestion des capacités : Gérer, planifier et prévoir les besoins de
ressources, en temps normal comme en temps de crise
− Gestion financière : Prévoir les besoins financiers nécessaires
pour tenir les objectifs en terme de budget, de financement et
d’imputation aux utilisateurs
− Gestion de la disponibilité : Optimiser l’infrastructure, les
services et l’organisation afin de permettre à celle-ci de tenir ses
engagements et objectifs, les niveaux de services sur lesquels elle
s’est engagée, pour un coût optimal
− Gestion de la continuité de service : Assurer un niveau de service
prédéterminé en temps de crise, d’une panne système à un
désastre majeur

Support des − Centre de services : Créer un point de contact unique pour


services l’ensemble des services et des utilisateurs

136
Annexe 3 : Livrables détaillés de l’étude de cas

− Gestion des problèmes : Détecter un disfonctionnement


susceptible de causer une répétition d’incidents et le corriger de
façon proactive
− Gestion des incidents : Résoudre un disfonctionnement dans les
meilleurs délais en minimisant l’impact sur le travail de
l’utilisateur
− Gestion des configurations : Maintenir un inventaire permanent
et à jour de l’ensemble des informations des composants de
l’infrastructure
− Gestion des mises à jour : Maîtriser tous les aspects des mises à
jour globales tant au plan technique de la préparation et de la
planification que de la minimisation de l’impact
− Gestion des changements : Utiliser des méthodes et procédures
standardisées afin d’apporter des modifications / corrections
avec une perturbation minimale des utilisateurs et sans altérer la
qualité de services perçus

Mise en place - La mise en place d’un contrat de service entre le service "Système
d’un contrat de d'information" et les directions métier et support afin de :
service − Formaliser les attentes en matière de service et les traduire en
objectifs réalisables
− Cadrer les relations entre le service système d'information et les
autres directions métier/support.

- Dans le cadre de cette démarche, les « cocontractants » doivent:


− Définir et détailler la nature et le niveau de service proposé pour
chaque activité concernée par les processus (i.e. périmètres et
niveaux de responsabilité)
− Définir les méthodologies et les règles de gestion (plan
d’assurance qualité) associées à chacune des activités et chacun
des processus concernés
− Définir et détailler le périmètre de responsabilités et de
prérogatives mutuelles
− Définir les instances de pilotage et de reporting, les modalités
de suivi de l’activité, les indicateurs pertinents, le mode de
collecte de données ainsi que les objectifs à atteindre par le
service système d'information
− Définir les modalités de modification et d’évolution du SLA

137
Annexe 3 : Livrables détaillés de l’étude de cas

Gouvernance
Sous
Bonnes pratiques
domaines
Généralités La figure ci-après présente une synthèse des bonnes pratiques à mettre en
œuvre dans le cadre de la gouvernance SI

Gestion et Méthodologie de conception conseillée


mesure de la
performanc 1ère étape : s’assurer que les objectifs assignés à la fonction SI sont clairs,
e SI connus et mesurables
• sans ambiguïté par rapport à la DG
• réaliste et pouvant être atteint dans des délais mesurables
• connus des personnes concernées par leur réalisation
• acceptés par ces mêmes personnes
2ème étape : Valider le découpage des activités SI
• Identifier les tâches à accomplir pour mener à bien les
missions et avoir la meilleure compréhension possible du
processus de réalisation des prestations (qui fait quoi,
chaînage des étapes…)

3ème étape : Définir les indicateurs de performance les plus pertinents


• établir la liste des indicateurs
• valider la représentation des objectifs et des activités du
service avec l’équipe concernée
• vérifier la pertinence des indicateurs dans la gestion
quotidienne du service ou de l’activité

138
Annexe 3 : Livrables détaillés de l’étude de cas

4ème étape : Analyser dans quelles conditions l’information sera


disponible ou produite
• mettre en place les indicateurs et mesurer régulièrement
leurs valeurs à des coûts optimisés
• analyser les modalités de production et de collecte des
informations nécessaires
• favoriser la génération automatique des valeurs des
indicateurs pour minimiser les risques d’erreurs, en
s’appuyant sur des outils adéquats. (Outil de help desk, outil
de supervision, … par exemple)
• prévoir un calendrier de réalisation et de mise en service du
tableau de bord
5ème étape : Structurer les indicateurs dans des tableaux de bord
• formaliser le ou les tableaux de bord
• s’assurer que la représentation est claire, synthétique, et que
l’information est facile à lire
• regrouper les indicateurs en fonction de leurs facteurs de
corrélation
• fournir des commentaires aux différents éléments des
tableaux de bord

La gestion La gestion de portefeuille (GP, ou PM pour Portfolio Management) vise à


de optimiser la création de valeur à travers la construction du portefeuille
portefeuille d'investissement. Il faut, notamment, identifier les ressources nécessaires à
projets chaque projet, définir les seuils d'investissement, évaluer, classer puis
orientée sélectionner (ou rejeter) les projets à lancer, gérer globalement le
création de portefeuille d'investissements en termes de risques et rentabilité, surveiller
valeur
les performances et en rendre-compte. Les processus composant GP sont :
• établir une stratégie claire et définir la structure de la cible en termes
d'investissements,
• déterminer les sources et la disponibilité des budgets,
• gérer la disponibilité des ressources humaines,
• évaluer et sélectionner les programmes à financer,
• monitorer et rendre compte de la performance des portefeuilles
d'investissement,
• optimiser la performance des portefeuilles par une revue régulière
des opportunités et risques.
La gouvernance de la valeur (GV ou VG pour Value Governance) a pour
objectif de s'assurer que le concept de valeur est présent dans les pratiques
de management de façon à assurer la cohérence avec les pratiques globales

139
Annexe 3 : Livrables détaillés de l’étude de cas

de gouvernance, à organiser le processus de décision, à fournir des directions


et des indicateurs de choix des projets en portefeuille et à assurer
l'apprentissage organisationnel par la vérification de l'atteinte des objectifs
sur les projets terminés. Les processus liés à la gouvernance de la valeur sont:
• établir un leadership informé et impliqué,
• définir et mettre en place les processus (et les structures associées,
les rôles, les responsabilités),
• définir les caractéristiques des différents portefeuilles de projets
(composition, poids relatifs...),
• aligner et intégrer la gestion de la valeur dans la gestion financière de
l'entreprise,
• établir une surveillance efficace de la gouvernance (et identifier les
dérives),
• mettre en place un processus d'amélioration continue des pratiques

Qualité et suivi des activités SI

Sous domaines Bonnes pratiques


Indicateurs de Dans le cadre de la mise en place d’un mode de fonctionnement basé
qualité sur les contrats de service (SLAs) entre la fonction SI et les directions
métier/support, il est primordial de mettre en place un ensemble de
mécanisme de surveillance et d’amélioration de la qualité des services
rendus par la Fonction SI.
Ceci passe impérativement par la mise en place d’un ensemble
d’indicateurs de suivi des activités informatiques.
Les indicateurs choisis doivent :
• Être pertinents
• être représentatifs de l’activité mesurée
• se prêter à une analyse (interprétable en terme de gestion :
comparaison par rapport à un objectif, une norme, un
standard…)
• être datés et quantifiés
Nous distinguons 4 familles d’indicateurs :
• les indicateurs d’activité: ex nombre d’intervention du help
desk par Direction, nombre de projets réussis.
• les indicateurs sociaux : ex taux de présence des ressources,
retards, heures supplémentaires, etc.
• les indicateurs d’efficacité/qualité/productivité: exemple taux
d’occupations des ressources, taux de dérapage projet.

140
Annexe 3 : Livrables détaillés de l’étude de cas

• les indicateurs financiers : suivi des budgets et coûts internes


des Prestations, suivi des engagements

Par ailleurs, ces familles d’indicateurs peuvent être classées en deux


types : quantitatifs et qualitatifs.
Dans ce qui suit, des exemples d’indicateurs pouvant être mis en place
pour le pilotage des activités informatiques.

1- Exemples d’Indicateurs quantitatifs basés sur des mécanismes de


collecte d’information manuels (fiches, tableaux) ou automatiques
(solution de helpdesk, outils de supervision des plates-formes SI, …):

Délai de prise en charge d’une demande utilisateur : Temps


maximum qui s’écoule entre la formulation, l’enregistrement
d’une demande et la transmission d’un accusé de réception au
Client demandeur.
Délai de traitement (problème, incident ou requête) / Délai de
résolution : Temps maximum qui s’écoule entre la prise en
charge d’une demande ou d’un incident et l’identification des
besoins pour répondre à cette demande ou résoudre l’incident.
Délai de clôture : Temps maximum qui s’écoule entre le
fonctionnement en mode dégradé et un fonctionnement
identique, voire amélioré à celui précédent l’incident ou la
demande. On parle de clôture définitive de l’incident.
Taux d’indisponibilité d’une ressource informatique : Temps
total pendant lequel une ressource* est indisponible sur une
période déterminée.

2- Exemple d’indicateurs qualitatifs basés sur des résultats d’enquêtes


• Niveau de satisfaction des utilisateurs propriétaires des
applications métiers par rapport à la qualité des interventions
techniques sur les applications dont ils sont propriétaires.
• Niveau de satisfaction des utilisateurs : peut être utilisé pour
suivre la performance du service Helpdesk (support technique
poste de travail et assistance), et du service «achat
informatique».
• Note générale : Appréciation de la Direction sur la qualité de
gestion des activités informatiques.
Indicateurs − Gestion de projet
suggérés pour les − Qualitatifs
activités SI − Taux de satisfaction de la maîtrise d’ouvrage

141
Annexe 3 : Livrables détaillés de l’étude de cas

− Quantitatifs (SLA)
− Suivi des charges, taux de dérapage projet
− Correspondance charges initialement prévues /
charges effectives
− Maintenance applicative de niveau 2
− Qualitatifs
− Diminution des réclamations
− Satisfaction des utilisateurs propriétaires de
l’application métier
− Quantitatifs (SLA)
− Délai de prise en charge des incidents
− Délai de résolution des incidents
− Efficacité escalade
− Gestion infrastructure
− Qualitatifs (qualité de service)
− Diminution des incidents
− Quantitatifs (SLA)
− Délai de prise en charge des incidents/Problèmes
− Délai de résolution des incidents/Problèmes
− Assistance utilisateur
− Qualitatifs
− Satisfaction utilisateur
− Adéquation des temps de réponse et d’exécution
− Diminution des demandes récurrentes, i.e.
remontée des problèmes
− Quantitatifs (SLA)
− Délai d’interventions

Sécurité

Sous domaines Bonnes pratiques


Gouvernance de  Aligner la stratégie de la sécurité sur celle de l’entreprise afin
la sécurité de supporter les objectifs poursuivis
 Créer de la valeur par une optimisation des
investissements en matière de sécurité
 Mettre en place des mesures appropriées permettant de
ramener les risques pesant sur les ressources
informationnelles à un niveau acceptable pour l’entreprise

142
Annexe 3 : Livrables détaillés de l’étude de cas

 Mesurer la performance des services de sécurité délivrés au


regard de l’atteinte des objectifs opérationnels de
l’entreprise
 Utiliser efficacement les ressources (humaines,
technologiques) dédiées à la sécurité
Mise en place Les SMSI fonctionnent selon un modèle cyclique en 4 étapes appelé « PDCA » c’est-
d'un Système de à-dire Plan, Do, Check, Act.
1. Phase Plan : consiste à planifier les actions que l’entreprise va
Management de
entreprendre en termes de sécurité
la Sécurité de
2. Phase Do : l’entreprise réalise ce qu’elle a planifié dans ce
l'Information
domaine
(SMSI), issu de la 3. Phase Check : l’entreprise vérifie qu’il n’existe pas d’écart
norme ISO entre ce qu’elle a dit et ce qu’elle a fait
27001 4. Phase Act : consiste à entreprendre des actions correctives pour
les écarts qui ont été constatés précédemment
Phase Plan : fixe les objectifs du SMSI
La phase Plan du SMSI comprend :
 Etape 1 : Définir la politique et le périmètre du SMSI
 Etape 2 : Identifier et évaluer les risques liés à la sécurité et
élaborer la politique de sécurité
- Identifier les actifs
- Identifier les personnes responsables
- Identifier les vulnérabilités
- Identifier les menaces
- Identifier les impacts
- Evaluer la vraisemblance
- Estimer les niveaux de risque
 Etape 3 : Traiter le risque et identifier le risque résiduel par un
plan de gestion
Phase Do : met en place les objectifs fixés Elle se découpe en plusieurs étapes :
1. Etablir un plan de traitement des risques
2. Déployer les mesures de sécurité
3. Générer des indicateurs
 De performance pour savoir si les mesures de sécurité sont
efficaces
 De conformité qui permettent de savoir si le SMSI est
conforme à ses spécifications
4. Former et sensibiliser le personnel
Phase Check : consiste à gérer le SMSI au quotidien et à détecter les incidents en
permanence pour y réagir rapidement 3 outils peuvent être mis en place pour détecter
ces incidents :
1. Les audits internes qui vérifient la conformité et l’efficacité du
système de management. Ces audits sont ponctuels et planifiés
à l’avance.

143
Annexe 3 : Livrables détaillés de l’étude de cas

2. Le contrôle interne qui consiste à s’assurer en permanence que


les processus fonctionnent normalement.
3. Les revues (ou réexamens) qui garantissent l’adéquation du
SMSI avec son environnement.
Phase Act : mettre en place des actions correctives, préventives ou d’amélioration pour
les incidents et écarts constatés lors de la phase Check
- Actions correctives : agir sur les effets pour corriger les écarts
puis sur les causes pour éviter que les incidents ne se
reproduisent
- Actions préventives : agir sur les causes avant que l’incident ne
se produise
- Actions d’amélioration : améliorer la performance d’un
processus du SMSI.

144
Annexe 4 : Modèles de livrables ESPAM

Annexe 4 : Modèles de livrables ESPAM


Ces modèles de livrables concernent les différentes phases de la méthodologie ESPAM.

Modèle de dossier de l’architecture existante (Livrable de la phase 1


d’ESPAM)
Ci-dessous une structure type de l’étude de l’existant

1 Document...............................................................................................................................
2 SOMMAIRE ..........................................................................................................................
3 LISTE DE FIGURES ............................................................................................................
4 LISTE DE TABLEAUX .......................................................................................................
5 RESUME EXECUTIF (EXECUTIVE SUMMURY) ...........................................................
6 ARCHITECTURE D’ENTREPRISE ....................................................................................
6.1 Définition ...........................................................................................................................
6.1.1 Contexte de l’Architecture d’Entreprise ......................................................................
6.1.2 Couches d’Architecture ...............................................................................................
6.2 Utilisation de l’Architecture d’Entreprise ..........................................................................
6.2.1 Planification des Transformations ...............................................................................
6.2.2 Gouvernance d’Entreprise ...........................................................................................
6.2.3 Architecture projet et conception de la solution ..........................................................
6.3 Les bénéfices d'une architecture d'entreprise .....................................................................
6.4 Facteurs de succès d’une Architecture d'Entreprise ...........................................................
7 VISION ARCHITECTURE ..................................................................................................
7.1 Définition ...........................................................................................................................
7.2 Synthèse et rappel de la vision d’architecture du ${organisme} .......................................
7.2.1 Axes et objectifs stratégiques du ${organisme} ..........................................................
7.2.2 Synthèse de la Vision d’architecture ...........................................................................
8 ARCHITECTURE METIER .................................................................................................
8.1 Contexte et définition .........................................................................................................
8.1.1 Les enjeux des entreprises modernes ...........................................................................
8.2 La Chaine de valeur Métier ................................................................................................
8.2.1 Définition .....................................................................................................................
8.2.2 Usage ...........................................................................................................................
8.2.3 La chaîne de valeur du ${organisme} .........................................................................
8.3 le modèle de capacité metier (domaines/fonctions) ...........................................................
8.3.1 Définition .....................................................................................................................
8.3.2 Usage ...........................................................................................................................
8.4 Processus Métier ................................................................................................................
8.4.1 Définition .....................................................................................................................
8.4.2 Usage ...........................................................................................................................
8.4.3 Gestion des processus métier .......................................................................................
8.4.4 Les macro-processus métier du ${organisme} ............................................................

145
Annexe 4 : Modèles de livrables ESPAM

8.4.5 Analyse des Processus Métier .....................................................................................


8.4.6 Relation entre la chaîne de valeur et les processus métier...........................................
8.4.7 Exigences d’exploitation .............................................................................................
8.4.8 Fiche type d’un processus............................................................................................
8.5 Objets métier ......................................................................................................................
8.5.1 Définition .....................................................................................................................
8.5.2 Usage ...........................................................................................................................
8.5.3 Objets métiers du ${organisme}..................................................................................
9 PROJETS EN COURS ..........................................................................................................
10 ARCHITECTURE APPLICATIVE ...................................................................................
10.1 Description de l’architecture applicative ............................................................................
10.1.1 Définition .....................................................................................................................
10.1.2 Ressources ...................................................................................................................
10.1.3 Intervenants .................................................................................................................
10.1.4 Enjeux ..........................................................................................................................
10.1.5 Vues, Schémas et Exemples ........................................................................................
10.2 Liste des applications du SI du ${organisme} ...................................................................
10.3 Vue couverture fonctionnelle .............................................................................................
10.3.1 Modèle .........................................................................................................................
10.3.2 Diagnostic ....................................................................................................................
10.4 Vue en couches ...................................................................................................................
10.4.1 Modèle .........................................................................................................................
10.4.2 Diagnostic ....................................................................................................................
11 ARCHITECTURE APPLICATIVE CIBLE ......................................................................
11.1 Vue globale ........................................................................................................................
11.2 Eléments de transformation ................................................................................................
11.3 Vue Couverture fonctionnelle ............................................................................................
12 ARCHITECTURE DE DONNEES EXISTANTE ............................................................
12.1 Description de l’architecture des données ..........................................................................
12.1.1 Définition .....................................................................................................................
12.1.2 Ressources ...................................................................................................................
12.2 Vue globale des flux ...........................................................................................................
12.3 flux internes et bases de données .......................................................................................
12.4 Volumétrie des bases de données .......................................................................................
13 ARCHITECTURE DE DONNEES CIBLE .......................................................................
13.1 Gestion des référentiels de données ...................................................................................
13.1.1 Clients ..........................................................................................................................
13.1.2 Produits ........................................................................................................................
13.1.3 Partenaires et canaux de distribution ...........................................................................
13.1.4 Outils (EII/MDM)........................................................................................................
13.2 Gestion des échanges de données .......................................................................................
13.2.1 Type de données d’échange .........................................................................................
13.2.2 Outil d’échange (ETL) .................................................................................................
14 ELEMENTS DE VIGILENCE POUR L’ARCHITECTURE CIBLE ...............................

146
Annexe 4 : Modèles de livrables ESPAM

14.1 Industrialisation des développements .................................................................................


14.2 Gestion de la Performance pendant le cycle de vie de projet .............................................
14.2.1 Expression de besoins ..................................................................................................
14.2.2 Analyse et conception ..................................................................................................
14.2.3 Développement ............................................................................................................
14.2.4 Intégration ....................................................................................................................
14.2.5 Production ....................................................................................................................
14.3 Gestion du cycle de vie de la donnée .................................................................................
14.4 Migration des données .......................................................................................................
14.5 Synchronisation de données dans la phase parallèle ..........................................................
14.6 Sécurité et accès .................................................................................................................
14.7 Gestion des environnements...............................................................................................
15 ARCHITECTURE TECHNIQUE ......................................................................................
15.1 Liste des serveurs ...............................................................................................................
15.2 Architecture des serveurs ...................................................................................................
16 ANALYSE ET DIAGNOSTIC DE L’EXISTANT ...........................................................
16.1 Architecture métier .............................................................................................................
16.1.1 Diagnostic par rapport au benchmark ..........................................................................
Métier ........................................................................................................................................
Organisation ..............................................................................................................................
16.1.2 Diagnostic par rapport aux standards et bonnes pratiques ..........................................
16.1.3 Diagnostic par rapport aux éléments de l’architecture métier .....................................
16.1.4 Diagnostic par rapport à la couche supérieure (stratégie) ...........................................
16.2 Architecture applicative .....................................................................................................
16.2.1 Diagnostic par rapport au benchmark ..........................................................................
16.2.2 Diagnostic par rapport aux standards et bonnes pratiques ..........................................
16.2.3 Diagnostic par rapport aux éléments de l’architecture métier .....................................
16.2.4 Diagnostic par rapport à la couche supérieure (métier) ...............................................
16.3 Architecture de données .....................................................................................................
16.3.1 Diagnostic par rapport au benchmark ..........................................................................
16.3.2 Diagnostic par rapport aux standards et bonnes pratiques ..........................................
16.3.3 Diagnostic par rapport aux éléments de l’architecture de données .............................
16.3.4 Diagnostic par rapport à la couche supérieure (métier) ...............................................
16.4 Architecture technique .......................................................................................................
16.4.1 Diagnostic par rapport au benchmark ..........................................................................
16.4.2 Diagnostic par rapport aux standards et bonnes pratiques ..........................................
16.4.3 Diagnostic par rapport aux éléments de l’architecture technique ................................
16.4.4 Diagnostic par rapport à la couche supérieure (applicative/données) .........................

147
Annexe 4 : Modèles de livrables ESPAM

Modèle de diagnostic de sécurité de l’existant (Livrable de la phase


1 d’ESPAM)
Ci-dessous la structure d’un diagnostic de sécurité réalisée dans le cadre d’une étude de plan
stratégique du système d’information.

1. Document ..............................................................................................................................
3.1. Version .........................................................................................................................
3.2. Responsables ................................................................................................................
3.3. Historique des versions ................................................................................................
4. Contexte et objet du document .............................................................................................
4.1. Contexte .......................................................................................................................
4.2. Objectifs du document .................................................................................................
4.3. Périmètre ......................................................................................................................
4.4. Démarche du projet ......................................................................................................
5. Audit de securité ...................................................................................................................
5.1. Architecture réseau .......................................................................................................
5.2. Antivirus et passerelles .................................................................................................
5.2.1. Antivirus des postes de travail et serveurs
5.2.2. Antivirus de la messagerie
5.2.3. Passerelle Antivirus Web
5.3. Parc informatique .........................................................................................................
5.3.1. Serveurs
5.3.2. Postes de travail
5.4. Procédures ....................................................................................................................
6. Recommandations .................................................................................................................
6.1. Présentation générale ....................................................................................................
6.2. Synthèse des recommandations ....................................................................................
6.3. Plan d'action .................................................................................................................
6.3.1. Réseau logique
6.3.1.1. Sécurisation réseau
6.3.2. Systèmes et plateformes
6.3.2.1. IDS/IPS
6.3.2.2. Sécurité web
6.3.2.3. Antivirus
6.3.2.4. Solution de déploiement des mises à jour
6.3.2.5. Solution de sauvegarde
6.3.2.6. Supervision et monitoring
6.3.3. Physique et environnement
6.3.3.1. Liaison Internet
6.3.3.2. Salle Informatique
6.3.4. Administratif
6.3.4.1. Améliorations OS/AD
6.3.4.2. Charte informatique

148
Annexe 4 : Modèles de livrables ESPAM

6.3.4.3. PCA
6.3.4.4. Documentation
6.3.4.5. Gestion des profils
6.3.4.6. Environnement SI
6.3.4.7. Ressource informatique
6.3.5. Applications et services
6.3.5.1. Chiffrement des informations amovibles
6.3.5.2. Sécurisation et protection de fuite des informations
7. Bilan ......................................................................................................................................

Modèle de définition des orientations stratégiques (Livrable de la


phase 2 d’ESPAM)
Ci-dessous la structure du dossier de définition des orientations stratégiques (Vision
d’Architecture).

1. Document ..............................................................................................................................
3.1. Version
3.2. Responsables
3.3. Historique des versions
2. Sommaire ..............................................................................................................................
4. Contexte et objet du document .............................................................................................
4.1. Contexte
4.2. Objectifs du document
5. Vision architecture : Définition et terminologie ...................................................................
5.1. Définition
5.2. Terminologie
5.2.1. Mission
5.2.2. Chaîne de valeur
5.2.3. Axes stratégiques
5.2.4. Objectifs stratégiques
5.2.5. Exemple
6. Vision Architecture de l’organisme ......................................................................................
6.1. Mission et métier
6.1.1. Mission
6.1.2. Métier
6.2. Chaîne de valeur
6.2.1. Vue global
6.2.1. Détail des domaines métier
6.3. Stratégie
6.3.1. Axes stratégiques
6.3.1.1. Améliorer le contrôle du marché
6.3.1.2. Accompagner le développement du marché
6.3.1.3. Favoriser l’ouverture et renforcer la présence nationale et internationale

149
Annexe 4 : Modèles de livrables ESPAM

6.3.1.4. Assurer l’environnement adéquat à l’évolution du marché


6.4. Exigences
6.4.1. Facteurs d’impacts (contraintes)
6.4.2. Principes d’Architecture, règles et bonnes pratiques
6.4.2.1. Principes d’Architecture relatifs aux métiers
6.4.2.2. Principes d’Architecture relatifs à la gestion des Données
6.4.2.3. Principes d’Architecture relatifs aux applications
6.4.2.4. Principes d’Architecture relatifs à la technologie
6.4.3. Attentes
6.5. Capacités et ressources
6.5.1. Evaluation des capacités RH
6.5.2. Evaluation des capacités IT
7. Benchmark des organismes similaires ..................................................................................
7.1. Organismes de référence
7.2. Eléments de comparaison
7.2.1. Marché et stratégie
7.2.2. Métier
7.2.3. Organisation
7.2.4. Système d’Information
8. Lignes directrice de la vision Architecture

Modèle de description de l’architecture cible (Livrable de la phase 4


d’ESPAM)
Ci-dessous la structure du dossier d’architecture cible.
1. Document ..............................................................................................................................
3.1. Version .........................................................................................................................
3.2. Responsables ................................................................................................................
3.3. Historique des versions ................................................................................................
2. Sommaire ..............................................................................................................................
4. Contexte et objectif ...............................................................................................................
5. Définitions et terminologie ...................................................................................................
5.1. Principes, standards, règles et bonnes pratiques...........................................................
5.2. Architecture cible .........................................................................................................
5.3. Ecarts et transformations ..............................................................................................
6. Démarche de définition de la cible .......................................................................................
6.1. Méthodologie ...............................................................................................................
6.2. Eléments d’entrée .........................................................................................................
7. Architecture métier cible .......................................................................................................
7.1. Principes, standards, règles et bonnes pratiques...........................................................
7.2. Chaine de valeur cible ..................................................................................................
7.3. Organisation cible (physique et logique) .....................................................................
7.4. Flux métier cibles .........................................................................................................
8. Architecture applicative cible ...............................................................................................
8.1. Principes, standards, règles et bonnes pratiques...........................................................
8.2. Couverture applicative cible de la chaîne de valeur .....................................................

150
Annexe 4 : Modèles de livrables ESPAM

8.3. Inventaire et fiches d’applications ................................................................................


8.4. Plan d’occupation de sol ..............................................................................................
9. Architecture de données cible ...............................................................................................
9.1. Principes, standards, règles et bonnes pratiques...........................................................
9.2. Flux applicatifs .............................................................................................................
9.3. Couverture Données de la chaîne de valeur cible : ......................................................
9.4. Référentiels cibles ........................................................................................................
9.5. BDs cibles ....................................................................................................................
9.6. Matrice Applications/Bases et référentiels de données ................................................
10. Architecture technique cible .................................................................................................
10.1. Principes, standards, règles et bonnes pratiques...........................................................
10.2. Briques logicielles du SI ..............................................................................................
10.3. Couverture logicielle de la chaîne de valeur ................................................................
10.4. Vue en couche de l'Architecture logicelle cible ...........................................................
10.5. Architecture matérielle .................................................................................................
1.1. Spécifications technique ...............................................................................................
1.1.1. Serveur SGBD / Application / logiciel :.......................................................................
1.1.2. Serveur Backup : ..........................................................................................................
1.1.3. Configuration Serveur (Développement & Recette) : .................................................

Modèle de fiche projet (Livrable de la phase 5 d’ESPAM)


Chaque projet est décrit via une fiche intégrant une description détaillée intégrant les éléments
suivants :

- Identification : comporte des informations signalétiques concernant le projet


- Description et objectifs : présente le contexte et objectifs du projet.
- Périmètre : précise les niveaux d'architecture d'entreprise concernés par le projet.
- Origine du besoin : permet de préciser les éléments déclencheurs de ce projet. Ces
éléments peuvent être de natures différentes : lignes directrices de la vision d'architecture,
éléments de diagnostic de l'architecture existante, recommandations suite à l'audit de
sécurité effectué, etc.
- Pré-Requis et dépendances : décrit les pré-requis (techniques, humains, organisationnels,
etc.) de ce projet et également en termes de dépendance avec d'autres projets
- Niveau de criticité : fournit une idée sur le niveau de criticité du projet (3 niveaux). Il
permet par la suite d'avoir une idée sur comment prioriser la réalisation de ces projets par
la suite
- Charge de travail (en J.H) : permet de disposer d'une première estimation de la charge de
projet en interne (équipe informatique, directions/services métiers) et externes par type de
profil nécessaire à la réalisation du projet.
- Récapitulatif délais : fournit, le cas échéant, la date de début et la date de fin du projet et
précise si le projet dispose d'un deadline.
- Planning prévisionnel : il s'agit d'un macro planning intégrant les phases du projet et la
durée d'exécution de chaque phase
- Budget prévisionnel : fournit un budget prévisionnel pour la réalisation du projet par type
de besoin (logiciel, matériel, assistance et formation)

151
152

View publication stats

Vous aimerez peut-être aussi