INSAT - Institut National des Sciences Appliquées et de Technologie

‫اﻟﻣﻌﮭد اﻟوطﻧﻲ ﻟﻠﻌﻠوم اﻟﺗطﺑﯾﻘﯾﺔ واﻟﺗﻛﻧوﻟوﺟﯾﺎ‬

GL5

Chp 1 - Introduction à l’Urbanisation des SI

Urbanisation des Systèmes d’Information

Dr. Lilia SFAXI

Slide 1
www.liliasfaxi.wix.com/liliasfaxi
PLAN

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

2
Chp 1 - Introduction à l’Urbanisation des SI

Architectures d’Entreprise

3
Définition (1)
Architectures d’Entreprise
● 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
Définition (2)
Architectures d’Entreprise
● 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
Définition (3)
Architectures d’Entreprise

● 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
Importance
Architectures d’Entreprise
● 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
Objectifs
Architectures d’Entreprise
● 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 vs. Architectures Logicielles
Architectures d’Entreprise

Architecture d’Entreprise Architecture Logicielle

Quoi? Système d’Information Application

Définir les principes directeurs

Définir des directives techniques pour
Pourquoi? d’une organisation, respect de
la phase de réalisation
normes et règles techniques

Ingénieur d’études, Responsable

Dirigeant, DSI, Architecte, Cabinet
Qui? informatique, Analyste, Développeur,
de conseil
Intégrateur

Liée à des solutions technologiques,

Comment? Vendor-neutral
fournisseurs et compétences

Ponctuellement, sur décision des Dans la phase de conception de

Quand?
dirigeants chaque projet

9
 (*)
Architecte SI : Profil
Architectures d’Entreprise
● 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

(*) https://www.lesjeudis.com/metiers/systeme/architecte-systeme-d'information/fiche

10
Architecte SI : Missions
Architectures d’Entreprise

● 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
Couches d’une Architecture d’Entreprise
Architectures 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
Couches d’une Architecture d’Entreprise
Architectures d’Entreprise

Couche métier - Business Layer

Couche de données - Data Layer

Couche applicative - Application Layer

Couche technologique - Technology Layer

Slide 13
Couches d’une Architecture d’Entreprise
Architectures d’Entreprise

Couche métier - Business Layer

Décrit:
● Les objectifs stratégiques, politiques d’entreprise, et
Business 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

Slide 14
Couches d’une Architecture d’Entreprise
Architectures d’Entreprise

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
Business
l’entreprise
● Architecture de données: Décrit le flux des données et comment elles
Data 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

Slide 15
Couches d’une Architecture d’Entreprise
Architectures d’Entreprise

Couche applicative - Application Layer

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

Slide 16
Couches d’une Architecture d’Entreprise
Architectures d’Entreprise

Couche technologique - Technology Layer

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

Slide 17
Chp 1 - Introduction à l’Urbanisation des SI

Frameworks d’Architectures d’Entreprise

18
Objectif d’un EAF (Enterprise Architecture Framework)
Frameworks d’Architectures d’Entreprise

● 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
ZF : Zachman’s Framework
Frameworks d’Architectures d’Entreprise
● 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)
Abstractions Artefact de
A1 A2 A3 conception

P1 AC11 AC12 AC13

Perspectives

P2 AC21 AC22 AC23

P3 AC31 AC32 AC33

20
 (*)
ZF : Zachman’s Framework

(*) https://www.dragon1.com/downloads/ZachmanBookRFIextract.pdf

21
EAP : Enterprise Architecture Planning
Frameworks d’Architectures d’Entreprise

● 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
EAP : Enterprise Architecture Planning
Frameworks d’Architectures d’Entreprise
● Level 1 : 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.
● Level 2 : Où en sommes-nous aujourd’hui?
Définition des processus métiers et des
systèmes et technologies actuellement utilisés.
● Level 3 : 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.
● Level 4 : 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
FEAF : Federal Enterprise Architecture Framework
Frameworks d’Architectures d’Entreprise

● 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
FEAF : Federal Enterprise Architecture Framework
Frameworks d’Architectures d’Entreprise
● 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
TOGAF : The Open Group Architecture Framework
Frameworks d’Architectures d’Entreprise
● 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
Chp 1 - Introduction à l’Urbanisation des SI

TOGAF

27
Principes TOGAF : Principes métier
TOGAF
Principe Définition

Ces principes de gestion de l'information s'appliquent à toutes les organisations au sein de

Primauté des principes
l'entreprise.

Maximiser le bénéfice pour Les décisions relatives à la gestion de l'information sont prises de manière à procurer un avantage
l'entreprise maximal à l'entreprise dans son ensemble.

La gestion de l'information Toutes les organisations de l'entreprise participent aux décisions de gestion de l'information
est l'affaire de tous 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.

Le développement d'applications utilisées dans l'ensemble de l'entreprise est préféré au

Applications d'usage
développement d'applications similaires ou dupliquées qui ne sont fournies qu'à une organisation
courant
particulière.

L'architecture est basée sur une conception de services qui reflètent les activités commerciales
Orientation vers les services
réelles comprenant les processus commerciaux de l'entreprise (ou inter-entreprises).

Les processus de gestion des informations de l'entreprise sont conformes à toutes les lois,
Respect de la loi
politiques et réglementations pertinentes.

L'organisation informatique est responsable de la propriété et de la mise en œuvre des processus

Responsabilité et de l'infrastructure informatiques qui permettent aux solutions de répondre aux exigences
informatique 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é La propriété intellectuelle (PI) de l'entreprise doit être protégée. Cette protection doit être reflétée
intellectuelle dans l'architecture informatique, la mise en œuvre et les processus de gouvernance.

Slide 28
Principes TOGAF : Principes de données
TOGAF
Principe Définition

Les données sont un Les données sont un actif qui a une valeur pour l'entreprise et qui est géré en
atout conséquence.

Les utilisateurs ont accès aux données nécessaires à l'exercice de leurs fonctions ;
Les données sont
les données sont donc partagées entre les fonctions et les organisations de
partagées
l'entreprise.

Les données sont Les données sont accessibles aux utilisateurs pour qu'ils puissent remplir leurs
accessibles fonctions.

Administrateur des Chaque élément de données a un administrateur responsable de la qualité des

données données.

Vocabulaire et
Les données sont définies de manière cohérente dans toute l'entreprise, et les
définitions des
définitions sont compréhensibles et disponibles pour tous les utilisateurs.
données communs

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
Sécurité des données
inclut, mais sans s'y limiter, la protection des informations pré-décisionnelles,
sensibles, sensibles à la sélection des sources et propriétaires.

Slide 29
Principes TOGAF : Principes d’application & de technologie
TOGAF

Principe Définition

Indépendance Les applications sont indépendantes des choix technologiques spécifiques et

technologique peuvent donc fonctionner sur une variété de plateformes technologiques.

Les applications sont faciles à utiliser. La technologie sous-jacente est

Facilité d'utilisation transparente pour les utilisateurs, qui peuvent ainsi se concentrer sur les tâches à
accomplir.

Changement basé sur Ce n'est qu'en réponse aux besoins de l'entreprise que des changements sont
les exigences apportés aux applications et à la technologie.

Gestion réactive du Les modifications apportées à l'environnement d'information de l'entreprise sont

changement mises en œuvre en temps utile.

La diversité technologique est contrôlée pour minimiser le coût non trivial du

Contrôle de la diversité
maintien de l'expertise et de la connectivité entre plusieurs environnements de
technique
traitement.

Les logiciels et le matériel doivent être conformes à des normes définies qui
Interopérabilité
favorisent l'interopérabilité des données, des applications et des technologies.

Slide 30
ADM : The Architecture Development Method
TOGAF

● 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
 Une description détaillée des phases de l’ADM est fournie ici:
https://pubs.opengroup.org/togaf-standard/adm/index.html

ADM : The
Architecture
Development
Method
TOGAF

32
ADM : Phases (1)
TOGAF
● Phase 0 : 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.
● Phase A : 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.
● Phase B : Business Architecture
Développement de l’architecture métier.
● Phase C : Information Systems Architecture
Développement de l’architecture du SI.
● Phase D : Technology Architecture
Développement de l’architecture technologique.

33
ADM : Phases (2)
TOGAF
● Phase E : Opportunities & Solutions
Planning initial d’implémentation et
identification des livrables de l’architecture
prédéfinie.
● Phase F : Migration Planning
Comment passer de l’architecture initiale vers
l’architecture cible en finalisant un plan détaillé
d’implémentation et de migration.
● Phase G : 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.
● Phase H : Architecture Change Management
Établissement de procédures pour gérer les
modifications de la nouvelle architecture.
● Phase Centrale : Requirements Management
Définition du processus de gestion des besoins
tout au long de l’ADM
34
Contenu de l’architecture dans TOGAF
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
Contenu de
l’architecture
dans TOGAF
TOGAF

36
Artefacts d’Architecture selon les phases de l’ADM (1)
TOGAF
● 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
Artefacts d’Architecture selon les phases de l’ADM (2)
TOGAF
● 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
Artefacts TOGAF
TOGAF

39
Exemples d’Artefacts : APPLICATION PORTFOLIO CATALOG

40
Exemples d’Artefacts : Application / Data Matrix

41
Exemples d’Artefacts : BUSINESS SERVICES AND INFORMATION DIAGRAM

42
Artefacts d’Architecture selon les phases de l’ADM
TOGAF

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
Chp 1 - Introduction à l’Urbanisation des SI

Urbanisation des Systèmes d’Information

44
Définition
Urbanisation des SI

● 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
Origine
Urbanisation des SI
● 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 territoires vs. Urbanisation des SI.
Urbanisation des SI

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

Slide 48
Concepts fondamentaux: Conglomérats
Urbanisation des SI
● 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
Exemples de conglomérats
Urbanisation des SI

Slide 50
Concepts fondamentaux: Périmètres
Urbanisation des SI
● 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.

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.).

Slide 51
Plan stratégique et plan d’urbanisme
Urbanisation des SI
● 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
Cartographie d’un Système d’Information
Urbanisation des SI
● 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
Cartographie d’un SI : Composition
Urbanisation des SI
● 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
Notion de terrain
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

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

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

57
Références
- 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