Introduction à la notion d'urbanisation des systèmes d'information et des architectures d'entreprises

1. Chp 1 - Introduction à l’Urbanisation des SI
Urbanisation des Systèmes d’Information
GL5
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
INSAT - Institut National des Sciences Appliquées et de Technologie
‫واﻟﺗﻛﻧوﻟوﺟﯾﺎ‬ ‫اﻟﺗطﺑﯾﻘﯾﺔ‬ ‫ﻟﻠﻌﻠوم‬ ‫اﻟوطﻧﻲ‬ ‫اﻟﻣﻌﮭد‬

2. ❏ Architectures d’Entreprise
❏ Frameworks d’architectures d’entreprise
❏ TOGAF
❏ Urbanisation des Systèmes d’Information
2
PLAN

3. Chp 1 - Introduction à l’Urbanisation des SI
3
Architectures d’Entreprise

4. Définition (1)
● Architecture enables you to accommodate complexity and change.
If you don't have Enterprise Architecture, your enterprise is not
going to be viable in an increasingly complex and changing
external environment.
John Zachman
● EA provides the strategic context to enable organizations to move
from innovation to assembly line production information products,
and still meet the constantly changing needs of the business
environment.
IBM Certified Infrastructure Systems Architect
4
Architectures d’Entreprise

5. Définition (2)
● Plan conceptuel, définit la structure et le fonctionnement des
organisations.
● Permet de déterminer comment une organisation peut atteindre
efficacement ses objectifs actuels et futurs.
● Implique la pratique de l'analyse, de la planification, de la conception
et de la mise en œuvre éventuelle de l'analyse sur une entreprise.
● Aide à la transformation numérique:
○ Regroupement des applications et des processus existants dans le
but de créer un environnement homogène.
○ Permet de répondre à la croissance rapide des technologies
5
Architectures d’Entreprise

6. Définition (3)
● Les concepts d'architecture d'entreprise sont variables:
○ Différents d’une organisation à l’autre
○ Différents d’un profil à l’autre dans une même organisation
■ Professionnels IT: Infrastructures, d'applications et de composants de
gestion sous leur contrôle.
■ Architectes d'entreprise: Architectures logicielles, processus et
orchestration
■ Intégrateurs: Assemblage de matériels et logiciels
6
Architectures d’Entreprise

7. Importance
● Aider les différents départements d'une entreprise à mieux
comprendre le modèle d'entreprise et à articuler les défis et les
risques commerciaux.
○ Alignement stratégique
● Unification et la coordination des processus départementaux au
sein d'une organisation
● Identification des lacunes de l’entreprise par tous ses acteurs
○ Prise de décision plus éclairée.
7
Architectures d’Entreprise

8. Objectifs
● Fournir des systèmes d'information (SI) appropriés en fonction des
demandes de l'entreprise
● Optimiser l’utilisation des processus, souvent fragmentés, d’une entreprise,
dans un environnement intégré, ouvert aux changements et cohérent avec
la stratégie métier.
● Créer une carte ou un plan (blueprint) de la structure et des opérations
d'une organisation.
○ Doit comprendre des informations telles qu'une carte des actifs informatiques
et des processus opérationnels.
● Promouvoir l'alignement et la normalisation des équipes.
○ Unification des environnements au sein des équipes et des organisations,
et/ou établissement de communications automatisées entre eux
8
Architectures d’Entreprise

9. Architectures d’Entreprise vs. Architectures Logicielles
9
Architectures d’Entreprise
Architecture d’Entreprise Architecture Logicielle
Quoi? Système d’Information Application
Pourquoi?
Définir les principes directeurs
d’une organisation, respect de
normes et règles techniques
Définir des directives techniques pour
la phase de réalisation
Qui?
Dirigeant, DSI, Architecte, Cabinet
de conseil
Ingénieur d’études, Responsable
informatique, Analyste, Développeur,
Intégrateur
Comment? Vendor-neutral
Liée à des solutions technologiques,
fournisseurs et compétences
Quand?
Ponctuellement, sur décision des
dirigeants
Dans la phase de conception de
chaque projet

10. Architecte SI : Profil
● Chef d’orchestre
● Coordonne les différents spécialistes intervenant dans les SI
● Au delà de l’expertise technique, il doit faire du SI un outil de développement
et de stratégie
○ Doit être calé dans les métiers de l’entreprise
● Travaille au sein des grandes entreprises utilisatrices (banques,
télécommunications, grande distribution, etc.) mais aussi dans les cabinet
de conseil
10
Architectures d’Entreprise
(*)
(*) https://www.lesjeudis.com/metiers/systeme/architecte-systeme-d'information/fiche

11. Architecte SI : Missions
● Analyser le système existant
● Construire la cartographie du SI
● Choisir les technologies selon les contraintes (coût, délai, intégration et
sécurité)
● Élaborer un plan de développement ou d’intégration
● Piloter le déploiement
● Informer et conseiller la direction sur les conséquences technologiques et
organisationnelles du nouveau SI
11
Architectures d’Entreprise

12. Couches d’une Architecture d’Entreprise
● Les différentes couches d’une AE (Layers) sont des domaines de pratique
pour décrire correctement une entreprise selon une spécification bien
déterminée.
● Le nombre de couches change d’un framework à un autre (voir les
frameworks dans la section suivante), mais les plus populaires sont les
suivantes:
○ Couche métier
○ Couche de données
○ Couche applicative
○ Couche de technologie
Slide 12
Architectures d’Entreprise

13. Couches d’une Architecture d’Entreprise
Slide 13
Architectures d’Entreprise
Couche métier - Business Layer
Couche de données - Data Layer
Couche applicative - Application Layer
Couche technologique - Technology Layer

14. Couches d’une Architecture d’Entreprise
Slide 14
Architectures d’Entreprise
Business
Couche métier - Business Layer
Décrit:
● Les objectifs stratégiques, politiques d’entreprise, et
modèles opérationnels
● Décompositions fonctionnelles et modèles
organisationnels
● Processus métier, workflows et règles qui articulent les
autorités, responsabilités et politiques affectées
● Organisation des cycles, périodes et calendriers
● Fournisseurs d’équipements, logiciels et services

15. Couches d’une Architecture d’Entreprise
Slide 15
Architectures d’Entreprise
Business
Couche de données - Data Layer
Concerne les informations et données collectées, organisées,
sauvegardées et distribuées. A les caractéristiques suivants:
● Architecture d’Information: Une vue globale du flux d’information de
l’entreprise
● Architecture de données: Décrit le flux des données et comment elles
sont sauvegardées et traitées.
● MDM: Master Data Management & BI: Business Intelligence
● Data quality: identifier, analyser, améliorer et mesurer la qualité des
données, les problèmes d’intégrité et les efforts d’amélioration
● Abstraction des modèles de bases de données
● Gestion du cycle de vie des données
Data

16. Couches d’une Architecture d’Entreprise
Slide 16
Architectures d’Entreprise
Business
Couche applicative - Application Layer
Offre une description rigoureuse des applications logicielles, par exemple:
● Un inventaire des applications et des diagrammes logiciels
● Les interfaces entre les applications qui sont: les événements,
messages, etc.
● Modélisation des entités structurelles: composants logiciels
réutilisables, applications et systèmes d’informations
● Définition des collaborations entre les applications ou services
● Définition du comportement des applications et services
Data
Application

17. Couches d’une Architecture d’Entreprise
Slide 17
Architectures d’Entreprise
Business
Couche technologique - Technology Layer
La couche ou architecture technologique comprend:
● Les middlewares
● Les environnement d’exécution des applications et frameworks
● Les serveurs et systèmes d’exploitation, d’authentification et
d’autorisation.
● Les systèmes de sécurité et de monitoring.
● Les plateformes matérielles et serveurs hôtes
● Les datacenters, réseaux LAN et WAN disponibles, diagrammes de
connectivité internet.
● Les bases de données et langages de programmation utilisés
Data
Application
Technology

18. Chp 1 - Introduction à l’Urbanisation des SI
18
Frameworks d’Architectures d’Entreprise

19. Objectif d’un EAF (Enterprise Architecture Framework)
● EAF : décrit des méthodes structurées afin de mettre en œuvre les projets
d’architecture d’entreprise, accompagnés d’outils et bonnes pratiques.
● Plusieurs EAF de référence:
○ ZF : Zachman’s Framework
○ EAP : Enterprise Architecture Planning
○ FEAF: Federal Enterprise Architecture Framework
○ TOGAF : The Open Group Architecture Framework
19
Frameworks d’Architectures d’Entreprise

20. ZF : Zachman’s Framework
● Défini par John Zachman, le pionnier des architectures d’entreprises, initialement
publié en 1987.
● Un schéma de classification bidimensionnel pour les représentations descriptives
d'une entreprise.
● Représente les artefacts de conception de divers produits selon le public cible
(perspective) ainsi que le contenu ou sujet de l’artefact (abstraction)
20
Frameworks d’Architectures d’Entreprise
A1 A2 A3
P1 AC11 AC12 AC13
P2 AC21 AC22 AC23
P3 AC31 AC32 AC33
Artefact de
conception
Abstractions
Perspectives

21. ZF : Zachman’s Framework
21
(*)
(*) https://www.dragon1.com/downloads/ZachmanBookRFIextract.pdf

22. EAP : Enterprise Architecture Planning
● Framework qui détermine le processus de planification pour définir les
architectures d’entreprise et les implémenter.
● EAP permet de définir la façon d’approcher la création des deux premières lignes
dans le framework de Zachman, le planner et le owner.
○ La conception du système en tant que tel est en dehors du scope de EAP.
● EAP définit ce que les données, applications et technologies permettent de
faire pour le bénéfice de l’entreprise.
● Définit 4 niveaux (Levels) et 7 composants
22
Frameworks d’Architectures d’Entreprise

23. EAP : Enterprise Architecture Planning
● Level1 : Par où commencer?
Production d’un plan, couvrant les
décisions à prendre pour la méthodologie
à utiliser, les parties impliquées et les
outils nécessaires.
● Level2 : Où en sommes-nous aujourd’hui?
Définition des processus métiers et des
systèmes et technologies actuellement utilisés.
● Level3 : Où voulons-nous aller?
(1) définition des données nécessaires pour le métier, (2) définition des applications majeures
nécessaires pour la gestion des données et des fonctions métier, et (3) définition des
plateformes nécessaires pour supporter ces applications.
● Level4 : Comment y arriver?
Définition des plans d’implémentation des applications, une analyse coût/bénéfice, et un chemin
clair pour la migration.
Slide 23
Frameworks d’Architectures d’Entreprise

24. FEAF : Federal Enterprise Architecture Framework
● Architecture d’entreprise de référence réalisée par le gouvernement fédéral aux États Unis.
● Permet de guider l'intégration des processus d'architecture de gestion stratégique, commerciale et
technologique.
● C’est un framework spécifiquement réservé aux agences fédérales, contrairement aux autres
frameworks plus génériques tels que Zachman ou TOGAF.
● Ce framework est basé sur l’approche Zachman, comme c’est le cas pour EAP, par contre il inclut les trois
premières colonnes.
● Définit quatre niveaux d’architecture:
○ Architecture métier: Ce qui est fait, par qui, comment et pourquoi
○ Architecture de données: Informations utilisées par l’agence pour réaliser le métier
○ Architecture d’application: Applications et logiciels qui traitent les données selon les règles métiers définies.
○ Architecture de technologie: Technologies de communication et matériel utilisé pour supporter les trois couches
ci-dessus.
24
Frameworks d’Architectures d’Entreprise

25. FEAF : Federal Enterprise Architecture Framework
● FEAF Définit un assortiment de modèles de référence appelé CRM (Consolidated Reference
Model) qui développe une taxonomie commune pour décrire les ressources IT
Slide 25
Frameworks d’Architectures d’Entreprise

26. TOGAF : The Open Group Architecture Framework
● Le standard EAF le plus utilisé et le plus célèbre dans le monde
● Développé et maintenu par les membres de The Open Group, travaillant sous le Architecture
Forum (voir www.opengroup.org/architecture )
● Le développement initial de la version 1 de TOGAF en 1995 était basé sur le EAF TAFIM
(Technical Architecture Framework for Information Management), développé par le
département de la défense américain (DoD).
● Se base sur les 4 domaines d’architecture précédemment cités (métier, données, application
et technologie), mais définit également d’autres domaines en combinant ces quatre couches:
○ L’architecture d’information
○ Les architecture de risque et de sécurité
○ L’architecture digitale
Nous présentons le framework TOGAF plus en détails dans la section suivante.
26
Frameworks d’Architectures d’Entreprise

27. Chp 1 - Introduction à l’Urbanisation des SI
27
TOGAF

28. Principes TOGAF : Principes métier
Slide 28
TOGAF
Principe Définition
Primauté des principes
Ces principes de gestion de l'information s'appliquent à toutes les organisations au sein de
l'entreprise.
Maximiser le bénéfice pour
l'entreprise
Les décisions relatives à la gestion de l'information sont prises de manière à procurer un avantage
maximal à l'entreprise dans son ensemble.
La gestion de l'information
est l'affaire de tous
Toutes les organisations de l'entreprise participent aux décisions de gestion de l'information
nécessaires pour atteindre les objectifs de l'entreprise.
Continuité des activités Les opérations de l'entreprise sont maintenues malgré les interruptions du système.
Applications d'usage
courant
Le développement d'applications utilisées dans l'ensemble de l'entreprise est préféré au
développement d'applications similaires ou dupliquées qui ne sont fournies qu'à une organisation
particulière.
Orientation vers les services
L'architecture est basée sur une conception de services qui reflètent les activités commerciales
réelles comprenant les processus commerciaux de l'entreprise (ou inter-entreprises).
Respect de la loi
Les processus de gestion des informations de l'entreprise sont conformes à toutes les lois,
politiques et réglementations pertinentes.
Responsabilité
informatique
L'organisation informatique est responsable de la propriété et de la mise en œuvre des processus
et de l'infrastructure informatiques qui permettent aux solutions de répondre aux exigences
définies par l'utilisateur en matière de fonctionnalité, de niveaux de service, de coûts et de délais de
livraison.
Protection de la propriété
intellectuelle
La propriété intellectuelle (PI) de l'entreprise doit être protégée. Cette protection doit être reflétée
dans l'architecture informatique, la mise en œuvre et les processus de gouvernance.

29. Principes TOGAF : Principes de données
Slide 29
TOGAF
Principe Définition
Les données sont un
atout
Les données sont un actif qui a une valeur pour l'entreprise et qui est géré en
conséquence.
Les données sont
partagées
Les utilisateurs ont accès aux données nécessaires à l'exercice de leurs fonctions ;
les données sont donc partagées entre les fonctions et les organisations de
l'entreprise.
Les données sont
accessibles
Les données sont accessibles aux utilisateurs pour qu'ils puissent remplir leurs
fonctions.
Administrateur des
données
Chaque élément de données a un administrateur responsable de la qualité des
données.
Vocabulaire et
définitions des
données communs
Les données sont définies de manière cohérente dans toute l'entreprise, et les
définitions sont compréhensibles et disponibles pour tous les utilisateurs.
Sécurité des données
Les données sont protégées contre toute utilisation ou divulgation non autorisée.
En plus des aspects traditionnels de la classification de la sécurité nationale, cela
inclut, mais sans s'y limiter, la protection des informations pré-décisionnelles,
sensibles, sensibles à la sélection des sources et propriétaires.

30. Principes TOGAF : Principes d’application & de technologie
Slide 30
TOGAF
Principe Définition
Indépendance
technologique
Les applications sont indépendantes des choix technologiques spécifiques et
peuvent donc fonctionner sur une variété de plateformes technologiques.
Facilité d'utilisation
Les applications sont faciles à utiliser. La technologie sous-jacente est
transparente pour les utilisateurs, qui peuvent ainsi se concentrer sur les tâches à
accomplir.
Changement basé sur
les exigences
Ce n'est qu'en réponse aux besoins de l'entreprise que des changements sont
apportés aux applications et à la technologie.
Gestion réactive du
changement
Les modifications apportées à l'environnement d'information de l'entreprise sont
mises en œuvre en temps utile.
Contrôle de la diversité
technique
La diversité technologique est contrôlée pour minimiser le coût non trivial du
maintien de l'expertise et de la connectivité entre plusieurs environnements de
traitement.
Interopérabilité
Les logiciels et le matériel doivent être conformes à des normes définies qui
favorisent l'interopérabilité des données, des applications et des technologies.

31. ADM : The Architecture Development Method
● TOGAF ADM fournit un processus testé pour le développement des architectures.
● ADM permet d’établir un EAF, de développer le contenu d’une architecture, et faire la
transition et de gouverner la réalisation d’architectures.
● Cycle itératif de définition et réalisation continues d’architectures
○ Permet une transformation contrôlée des entreprises, en réponse de leurs
besoins et opportunités métiers
31
TOGAF

32. ADM : The
Architecture
Development
Method
TOGAF
32
Une description détaillée des phases de l’ADM est fournie ici:
https://pubs.opengroup.org/togaf-standard/adm/index.html

33. ADM : Phases (1)
33
TOGAF
● Phase0 : Phase préliminaire
Activités de préparation et d’initiation pour
créer l’architecture, inclut la personnalisation du
framework TOGAF et la définition des principes
d’architecture.
● PhaseA : Architecture Vision
Phase initiale du cycle de définition de
l’architecture. Informations sur la définition de
sa portée (scope), identification des parties
prenantes, et l’obtention de l’accord nécessaire
pour sa mise en place.
● PhaseB : Business Architecture
Développement de l’architecture métier.
● PhaseC : Information Systems Architecture
Développement de l’architecture du SI.
● PhaseD : Technology Architecture
Développement de l’architecture technologique.

34. ADM : Phases (2)
34
TOGAF
● PhaseE : Opportunities & Solutions
Planning initial d’implémentation et
identification des livrables de l’architecture
prédéfinie.
● PhaseF : Migration Planning
Comment passer de l’architecture initiale vers
l’architecture cible en finalisant un plan détaillé
d’implémentation et de migration.
● PhaseG : Implementation Governance
Définition d’un contrat d’architecture pour gérer
le processus d’implémentation et déploiement,
et attribution des rôle pour les intervenants.
● PhaseH : Architecture Change Management
Établissement de procédures pour gérer les
modifications de la nouvelle architecture.
● PhaseCentrale : Requirements Management
Définition du processus de gestion des besoins
tout au long de l’ADM

35. Contenu de l’architecture dans TOGAF
● Le TOGAF Content Framework définit un cadre de catégorisation à utiliser pour structurer :
○ La description de l'architecture
○ Les produits de travail utilisés pour exprimer une architecture
○ La collection de modèles qui décrivent l'architecture.
● Il permet de:
○ Fournir un modèle détaillé des produits du travail architectural
○ Favoriser la cohérence des résultats créés en suivant l’ADM.
○ Fournir une liste de contrôle complète des produits d'architecture qui pourraient
être créés.
○ Réduire le risque de lacunes dans l'ensemble des livrables d'architecture finaux.
○ Aider l'entreprise à définir des concepts, des termes et des livrables d'architecture
standard.
35
TOGAF

36. 36
Contenu de
l’architecture
dans TOGAF
TOGAF

37. Artefacts d’Architecture selon les phases de l’ADM (1)
● TOGAF définit plusieurs concepts pour satisfaire les besoins des différentes parties
prenantes, tels que les blocs de construction, les catalogues, les matrices et les
diagrammes.
● Blocs de construction (Building blocks)
○ Entités d'un type particulier dans le métamodèle
■ par exemple, un service commercial appelé "Bon de commande"
○ Peuvent également inclure des entités dépendantes ou contenues selon le
contexte de l'architecture
■ par exemple, un service commercial appelé "Bon de commande" peut inclure
implicitement un certain nombre de processus, d'entités de données, de
composants d'application, etc.
37
TOGAF

38. Artefacts d’Architecture selon les phases de l’ADM (2)
● Catalogues
○ Listes de blocs de construction d'un type spécifique, ou de types apparentés, qui sont utilisés à des
fins de gouvernance ou de référence
■ par exemple, un organigramme, indiquant les lieux et les acteurs
● Matrices
○ Grilles qui montrent les relations entre deux ou plusieurs entités du modèle
○ Utilisées pour représenter les relations qui sont basées sur des listes plutôt que sur des graphiques
■ par exemple, une matrice CRUD montrant quelles applications créent, lisent, mettent à jour et
suppriment un type particulier de données.
● Diagrammes
○ Rendus du contenu architectural dans un format graphique pour permettre aux parties prenantes de
récupérer les informations requises
■ par exemple, un diagramme de flux ou BPM
38
TOGAF

39. Artefacts TOGAF
39
TOGAF

40. Exemples d’Artefacts : APPLICATION PORTFOLIO CATALOG
40

41. Exemples d’Artefacts : Application / Data Matrix
41

42. Exemples d’Artefacts : BUSINESS SERVICES AND INFORMATION DIAGRAM
42

43. Artefacts d’Architecture selon les phases de l’ADM
Vous trouverez une liste complète des templates des
différents artefacts TOGAF sur ce lien:
○ https://github.com/leonux/architecture-work/tree/master/Tog
af-material/TOGAF_9_Templates
Slide 43
TOGAF

44. Chp 1 - Introduction à l’Urbanisation des SI
44
Urbanisation des Systèmes d’Information

45. Définition
● Architectures d’entreprises
○ Met en évidence le rôle d’architecte
○ Propose une structure des applicatifs basée sur les processus métiers et objectifs de
l’entreprise, sans proposer de contraintes a priori
● Urbanisation / Urbanisme
○ Ensemble de règles s’imposant à tout ou partie du SI
○ Définition de règles à respecter par les applications, pour obtenir un SI évolutif
○ Les concepts manipulés s'apparentent à ceux de l'urbanisation de l'habitat humain
(organisation des villes, du territoire)
=> Le processus d'urbanisation répond aux couches "Scope (contexte)" , "Business
Model (conceptuel)" et "System Model (logique)" des Architectures d’Entreprise.
Slide 45
Urbanisation des SI

46. Origine
● Les chefs de projet concevaient des travaux par lot (batch) utilisant des
informations provenant d’applications connexes.
○ Programmes spécifiques d’extraction de fichiers des applications
● Plusieures difficultés:
○ Obligation de respecter les contraintes des concepteurs: horaire d’exploitation par
exemple
○ Incapacité d’optimiser l’utilisation des machines: difficulté de faire tourner les travaux en
parallèle
○ Les concepteurs des applications sources prennent en compte les contraintes
fonctionnelles, mais pas (ou peu) celles de l’exploitant
● Solution proposée:
○ Imposer des règles globales aux concepteurs de façon à tenir compte des contraintes
techniques et d’exploitation
○ Respecter l’asynchronisme et indépendance des traitements
○ Unifier les interfaces
=> de même que, dans une cité, l’urbaniste impose des règles aux architectes
(alimentation électrique, égouts, alimentation des eaux, etc.)
Slide 46
Urbanisation des SI

47. Urbanisation des territoires vs. Urbanisation des SI.
Slide 47
Urbanisation des SI

48. Méta-modèle des Concepts
Slide 48
Urbanisation des SI

49. Concepts fondamentaux: Conglomérats
● Découpage du SI en conglomérats hiérarchisés de façon à obéir à un plan
d’organisation du SI (POSI), garant des enjeux liés à l’urbanisation
● Les conglomérats peuvent être:
○ zone: zone d’affectation du sol selon l’usage qui y sera autorisé et la nature des
activités dominantes
■ Permet de classifier les quartiers selon la nature de la mission
○ quartier: entité assurant une production contribuant à la mission de l’entreprise
■ rassemble les différents types d’opérations ou processus homogènes d’un métier ou
activité
■ Le quartier s’appuie sur les blocs ou îlots qui le composent
■ Un quartier invoque principalement les services de ses îlots
○ îlot: blocs finaux indécomposables
■ Ensemble de données et de traitements homogènes dans une activité, portant sur un seul
niveau d’agrégation de l’information
■ Composant métier possédant une mission de service autours d’un thème dont il est
responsable pour tout le SI
Slide 49
Urbanisation des SI

50. Exemples de conglomérats
Slide 50
Urbanisation des SI

51. Concepts fondamentaux: Périmètres
● L’exercice le plus difficile est de déterminer la limite d’un bloc
● Il faut pour chaque bloc:
○ Attribuer son périmètre d’autonomie
○ Choisir les données et services qui seront dupliquées pour ce bloc, et celles qui seront
mutualisées.
Slide 51
Urbanisation des SI
Dans le milieu urbain cette organisation se fait au gré à gré par une régulation assez
naturelle de la redondance. Un magasin s'établit dans un quartier bien achalandé et
disparaît ou persiste en fonction de son essor. En revanche, l'implantation de
certaines composantes à des échelons plus ou moins locaux est décidée au niveau
de structures centrales (crèches, centres commerciaux, parkings, centrales
électriques, etc.).

52. Plan stratégique et plan d’urbanisme
● POSI: Plan d’organisation du SI
○ Équivalent du POS (Plan d’occupation du sol) dans le milieu urbain
○ Définit les grandes orientations du SI et les directions majeures de son
évolution
○ Doit porter :
■ Sur les aspects structurels (urbanisme): principes de découpage et identification
des blocs, sans descendre en dessous du niveau de la zone
■ Sur les aspects dynamiques (urbanisation): règles d’organisation statuant sur les
degrés de liberté associés aux futures constructions
● Plan d’urbanisme et d’urbanisation
○ Déclinaison opérationnelle du POSI
○ Traduisent l’aspect pratique des possibilités d’aménagement du SI
○ Déclinent les orientations du POSI de manière pratique restituée dans une
cartographie
Slide 52
Urbanisation des SI

53. Cartographie d’un Système d’Information
● Représentation du système d’information (SI) d’une organisation
ainsi que ses connexions avec l’extérieur
● Peut être plus ou moins détaillée et inclure, par exemple, les biens
matériels, logiciels, les réseaux de connexion, mais aussi les
informations, activités et processus qui reposent sur ces biens
● Doit permettre de:
○ réaliser l’inventaire patrimonial du système d’information, à savoir la
liste des composants du SI et leur description détaillée;
○ présenter le système d’information sous forme de vues
(représentations partielles du SI), de ses liens et de son fonctionnement.
Elles visent à rendre lisibles et compréhensibles différents aspects du
système d’information.
Slide 53
Urbanisation des SI

54. Cartographie d’un SI : Composition
● Vision métier
○ Vue de l’écosystème: entités ou systèmes avec lesquels le SI
interagit
○ Vue métier: processus et informations principales, valeurs métiers
● Vision applicative
○ Vue des applications: composants logiciels du SI, services offerts et
flux de données entre eux
○ Vue de l’administration: périmètres et niveaux de privilèges des
utilisateurs et administrateurs.
● Vision infrastructure
○ Vue des infrastructures logiques: cloisonnement logique des
réseaux, notamment par la définition des plages d’adresses IP, des
VLAN et des fonctions de filtrage et routage
○ Vue des infrastructures physiques: équipements physiques qui
composent le système d’information ou utilisés par celui-ci.
Slide 54
Urbanisation des SI

55. Notion de terrain
Slide 55
Urbanisation des SI
● Prise en compte de la nature du sol avant la construction
● Considérer les préoccupations fonctionnelles, techniques, organisationnelles..
● Terrain d’urbanisation: décomposition possible répondant à des niveaux de
préoccupations différents

56. Exemple de
Cartographie
Cartographie
Fonctionnelle de
l’INSAT
Réalisée par Amira Ben Achour, GL5,
promotion 2018
56

57. Exemple de
Cartographie
Cartographie
Applicative de
l’INSAT
Réalisée par Amira Ben Achour, GL5,
promotion 2018
57

58. - IBM Systems Group, IBM Certified Infrastructure Systems Architect, Mai 2004
- Alexander S. Gillis, Enterprise architecture (EA), Techtarget, 2020
- Badreddine Ladjemi, Cours d’urbanisation des SI, INSAT, 2017
- John A. Zachman, The Zachman Framework For Enterprise Architecture, 2003
- Steven Spewak and S. C. Hill (1992) Enterprise Architecture Planning: Developing a Blueprint for Data,
Applications, and Technology. Boston, QED Pub. Group. p. 1
- Lean IX, FEAF: le guide Ultime, consulté en Août 2022,
https://www.leanix.net/fr/wiki/ea/feaf-federal-enterprise-architecture-framework
- Wikipedia, Federal Enterprise Architecture, consultée en Août 2022,
https://en.wikipedia.org/wiki/Federal_enterprise_architecture
- Maache Salah, An experiment applying the enterprise architecture, case study: Algerian government agency.
International Journal of Research in Management, Science and Technology, April 2016.
- The Open Group, The TOGAF Standard, https://pubs.opengroup.org/togaf-standard/ , consulté Aout 2022
- DSCG: UE5 - Management des Systèmes d’Information, Architecture d’entreprise et Urbanisation des SI (Cours),
inspiré de IN Management et gouvernance des SI - Carvalho-Lavoisier 2009, et de Le projet d’urbanisation du SI -
C.Longépé 2009.
- ANSSI, Cartographie du SI,
https://www.mauricenavarro.com/ressources/cartographie-du-systeme-d-information/ Nov. 2018
-
58
Références