Urbanisation (informatique)

L'urbanisation du système d'information d'une entité ou d'une organisation, qui peut être une entreprise ou une administration, est une discipline d’ingénierie informatique consistant à faire évoluer le système d'information (SI) de celle-ci afin qu'il soutienne et accompagne efficacement les missions de ladite organisation et anticipe ses transformations. L'urbanisation du SI ne fait pas table rase du passé mais tient compte de l'existant et permet de mieux envisager les évolutions ou contraintes internes et externes affectant le SI, en s'appuyant le cas échéant sur des opportunités technologiques. Les concepts manipulés s'apparentent à ceux de l'urbanisation de l'habitat humain (organisation des villes, du territoire), concepts qui ont été réutilisés en informatique pour formaliser ou modéliser la réingénierie du système d'information (SI).

L'urbanisation implique des principes et règles dans un cadre cohérent, stable et modulaire, auquel les différentes instances décisionnaires de l'organisation peuvent se référer  lors d'un investissement relatif au management du système d'information. 

L'urbanisation informatique est une des méthodologies d'architecture d'entreprise.

Enjeux de l'urbanisation du système d'information 
L'urbanisation facilite la transformation continue du système d’information.

Les évolutions des stratégies d'entreprise (regroupements et fusions, acquisitions, diversification des offres commerciales, commerce électronique, gestion de la relation client, nouveaux modes ou canaux de distribution, partenariats, réorganisation, externalisation, redéploiement des fonctions de back et front office) impliquent des changements structurels importants et accroissent l’interdépendance (dépendance mutualisée) et l’imbrication des applications informatiques avec le risque de renforcer « l’effet « sac de nœuds » du système d'information ou SI.

Cette complexité croissante a des conséquences sur les coûts, les durées et les risques des projets d’évolution des SI.

L'urbanisation et son prolongement dans l’architecture des systèmes informatiques  maîtrise l’évolution des SI et réduit ainsi les coûts informatiques, soutient et accompagne la stratégie d'entreprise en optimisant coûts/qualité/délais, améliore la réactivité, n’investit que dans les produits et services générateurs de valeur ajoutée et maîtrise les charges informatiques et le retour sur investissement.

Les outils d' favorisent cette démarche qui peut se mettre en œuvre :
 de manière opportuniste : à l’occasion d’un projet de développement, de refonte ou de maintenance ;
 de manière plus volontariste : dans le cadre d’un chantier d’urbanisation.

Le terme  est préféré à celui d' car il  met l'accent sur la progressivité  de l’évolution vers une cible correctement urbanisée. 

Par ailleurs, l'urbanisation rencontre une des préoccupations des  maîtres d'ouvrage, à savoir l'alignement stratégique du système d'information sur le métier.

Principe de l'urbanisation du SI 
L'urbanisation s'appuie sur deux règles de base :

 une application doit appartenir à un et un seul bloc afin de limiter les impacts lorsqu'on remplace celle-ci (règle de couplage faible) ;
 les dépendances doivent respecter les notions de cohérence forte et de couplage faible :
 entre les applications,
 entre les modules d'une même application,
 entre les composants d'un même module.

Le terme « en cible » définit l'application que l'on cherche à avoir (to be). Elle s'oppose à l'existant (as is). La méthode pour passer du as-is actuel au to-be souhaité est appelée la roadmap (feuille de route).

La notion de Cohérence Forte / Couplage Faible indique que deux applications doivent communiquer entre elles de façon simple et efficace, mais que la dépendance entre ces deux applications est minimale (idéalement inexistante). Cela permet donc de retirer un bloc pour le remplacer sans perturber le reste du SI.

Le système d'information peut donc être comparé au quartier d'une ville : si ce dernier est bien bâti et bien urbanisé, il est possible de raser un bâtiment au cœur du quartier sans mettre en péril tout le secteur et de le remplacer par un autre bâtiment, en raccordant ce nouveau bâtiment aux différents réseaux d'échanges : voirie d'accès, électricité, évacuation des eaux usées L'urbanisation consiste donc à créer un SI agile, modulable et évolutif.

Application des concepts d'urbanisation 
L’urbanisation du SI est une démarche d'aide à la transformation, rationalisation, simplification et amélioration du SI. Certains auteurs comparent le système d'information à l’image d’une ville, c'est-à-dire réfléchie, structurée, durable. Dans le prolongement de cette analogie — qui a toutefois des limites —, l'urbanisation du SI consiste à planifier des refontes structurantes pour optimiser, les échanges, les services, la flexibilité, la modularité… et d'une façon plus générale à répondre à la stratégie SI de l'entreprise en parallèle de l'évolution du métier.

De façon concrète, urbaniser un SI consiste essentiellement à découper le SI en sous-systèmes de façon optimale selon quatre grands principes d'urbanisme des systèmes :
 "Diviser pour régner" ou principe de modularité. Le but est de découper le système en sous-systèmes de taille optimale et ayant chacun son autonomie d’exploitation et d’utilisation. L'indisponibilité temporaire d'un sous-système n'empêche pas les autres sous-systèmes de fonctionner.
 "Regrouper pour simplifier" ou principe de subsidiarité. Le but est de mutualiser ce qui peut l'être et de traiter chaque spécificité en différentiel par rapport au cas général. La complexité est isolée dans des sous-systèmes de cas particuliers facilement maîtrisables et ne faisant pas courir de risque aux sous-systèmes génériques.
 "Répartir pour mieux communiquer" ou principe de réduction des adhérences. Le but est de minimiser les adhérences entre sous-systèmes et de compenser par une coopération dynamique entre eux. Les données échangées entre sous-systèmes ne sont créées et modifiées que dans un seul sous-système (notion de sous-système propriétaire). Les échanges d'information entre sous-systèmes se font via des interfaces standardisés.
 "Commencer petit mais voir grand" ou principe de progressivité. Le but est de prévoir une évolution du système par étapes et à partir de l'existant.

Le plan d'urbanisme SI ou plan d'occupation des sols (POS) 
Pour faciliter les planifications au regard des évolutions du SI, l'urbanisation s'appuie sur un plan d'urbanisme souvent appelé POS, en analogie avec l'urbanisme. 

Le POS consiste à représenter le SI en s'appuyant sur une cartographie fonctionnelle du SI et un découpage en capacités autonomes, de description de plus en plus fine :
 les zones ;
 les quartiers ;
 les îlots ;
 et enfin les blocs fonctionnels ou encore les briques.

Le POS doit faciliter la construction d'une architecture optimisée du point de vue fonctionnel du SI qui est le point de vue pivot entre le point de vue du métier et le point de vue informatique.

Plus particulièrement, l’urbanisation vise :
 à renforcer la capacité à construire et à intégrer des sous-systèmes d'origines diverses ;
 à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres SI (interopérabilité) ;
 à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité).
et de manière générale pour le SI à :
 favoriser son évolutivité, sa pérennité et son indépendance ;
 renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes plates-formes).

Exemple de règles de découpage du SI 
 Règle 1 : Séparation du Back-office du Front-office.
 Règle 2 : Découpage par processus et par métier. On crée ainsi les zones Décisionnel, Support et Métier. 
 : La zone Métier peut être découpée en plusieurs blocs. 
 Règle 3 : Séparation des canaux technologiques d'accès et de communication (site Web, notification SMS…) des canaux du métier « Relation Client » (CRM, Marketing). On inscrit deux nouvelles zones dans le Front-Office : Acquisition/Restitution et Relation avec les tiers.
 Règle 4 : Il faut isoler ce qui est partagé par le Back-office et le Front-office ainsi que ce qui les intègre. On définit donc les zones Intégration et Données Partagées.
 Règle 5 : Intégrer un système d'information en Transport "T.M.S" et en entreposage "W.M.S" afin de simplifier et faciliter les fonctions de A à Z du départ à l'arrivée dans l'entrepôt des marchandises. La simplification et la facilitation peut engendrer une diminution des coûts de productions et de revient de ceux et celles qui les gèrent au quotidien.
 Règle 6 : Optimiser les coûts demande une organisation fonctionnelle de tous les systèmes d'information afin de fluidifier les informations tant en haut qu'en bas du "Bilan". Cela passe par une transparence financière inévitable afin de rassurer toutes les parties prenantes des entreprises qu'elles soient internes et ou, externes. Il en va de soit par la mise en place de procédures simplifiées et ayant pour objectif d'y intégrer un support et une plateforme contenant toutes les informations requises afin de réussir les travaux les concernant.

Les différents types de zones 
Dans le découpage d'un SI on distingue habituellement différents types de zones :

 les zones des échanges avec l’extérieur du SI : acquisition/émission de/vers les partenaires : clients, fournisseurs ;
 les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations commerciales, gestion des opérations logistiques internes ;
 les zones de gestion des données de référence communes à l'ensemble du SI : les référentiels de données structurées (données clients, catalogue de produits et services) ;
 les zones de gestion des gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (exemple : données de production) ;
 les zones des activités de support : comptabilité, ressources humaines ;
 les zones des traitements pour l’aide à la décision et le pilotage : informatique décisionnelle.

Dans le cas de très grandes entreprises, il est matériellement impossible d'urbaniser la totalité du SI dans un même mouvement. Cela explique que l'on découpe le SI de l'entreprise en périmètres autonomes ; par exemple : par grandes directions. Chaque périmètre est alors considéré comme un SI autonome qui est urbanisé individuellement. Sa zone d'échange gère ainsi aussi bien les flux extra-entreprises « SI ⇔ SI extérieurs » que les flux intra-entreprises « SI ⇔ autres SI de l'entreprise ».

Exemple de découpage et d’énoncé de capacité fonctionnelle 
À titre d'illustration, une partie du découpage du système d'information d'une banque :

 zone (capacité métier de) production bancaire
 quartier (capacité de) vente de crédits
 îlot (capacité de) proposition de crédits
 bloc fonctionnel (capacité de) suivi (CRUD) d'une demande/proposition de crédit

Une mauvaise pratique courante consiste à utiliser « gestion de » qui porte à confusion avec la gestion d'un point de vue activité d'un processus. Une bonne pratique consiste à énoncer la capacité précise à faire dans le SI.

Dans cet exemple, la capacité à outiller est le suivi du cycle de vie d'un objet métier « proposition de crédit ».

Principaux niveaux de préoccupation 
Les niveaux de préoccupation constituent ce qu'on appelle le méta-modèle d’urbanisme : c'est-à-dire le modèle conceptuel de description du Système d'Information.

Les objectifs stratégiques du SI 
Ce niveau de préoccupation du SI est constitué par la description : 
 des objectifs de l'entreprise ;
 des objectifs du système d'information à urbaniser ;
 de la mise en correspondance entre ces deux sortes d'objectifs : l'alignement stratégique.

Ces objectifs peuvent être modélisés
 soit comme une liste hiérarchique de thèmes et de sous thèmes ;
 soit comme un diagramme de causes et effets, ou diagramme d'Ishikawa (en arête de poisson), qui indique les causes (matière, matériel, méthode, ressources humaines, milieu / contexte) qui produisent des effets.

Ces objectifs se déclinent en exigences métier ou SI, fonctionnelle ou non. La liste de thématiques métier et/ou fonctionnelle peut être obtenue par l'analyse des exigences du système.

Le point de vue du métier ou affaires 
Le système d'information d'un point de vue métier ou affaires (c'est-à-dire de l’ensemble des métiers) est constitué : 
 des processus de l'entreprise et des organisations qui y concourent ;
 des informations qui transitent dans les différents processus ;
 et des règles de gestion, utilisées par les métiers et les processus mis en œuvre par une même entité organisationnelle de l'entreprise.

La définition de la stratégie de l'entreprise conduit à répertorier :

 les métiers stratégiques qu’elle exerce vis-à-vis de son marché et autour desquels elle structure ses activités et son organisation - un métier stratégique (exemples : octroi de crédit, courtage d'assurance, ligne de fabrication) correspond à une combinaison de :
 segments de marché, 
 offres commerciales ou marketing,
 techniques de distribution ; 
 les métiers opérationnels qu’elle exerce dans le cadre de chacun des métiers stratégiques (exemples : production, marketing, gestion des risques).
Les activités exercées par l'entreprise, sont de plusieurs types :
 les activités opérationnelles qui contribuent à la fabrication des produits vendus ou à l’élaboration des services rendus aux clients ;
 les activités de gestion ;
 les activités de pilotage.
L'analyse du système métier peut s'appuyer sur les techniques de BPM (Business Process Management ou Gestion des processus métier) qui visent à :
 modéliser les processus de façon transversale à l'entreprise, dans le cadre d'une gestion de programme ;
 outiller ces processus pour faciliter une exécution fluide (workflow, moteur de règles ou d'exécution) ;
 piloter l'activité de ces processus au moyen d'indicateurs (gestion de la qualité, performance).
L'un des objectifs du BPM est de porter un diagnostic sur les processus de l'entreprise et de déterminer ainsi dans quels secteurs les évolutions du SI offriront le meilleur retour sur investissement.

Le point de vue fonctionnel 
 

Le système d'information (SI) d'un point de vue fonctionnel est constitué de l’ensemble :
 des fonctions, c'est-à-dire des capacités du SI,
 des objets métiers, c'est-à-dire de l'information (issue des processus) structurée en entités ou objets.

L'analyse fonctionnelle constitue la « pierre angulaire » de la démarche d'urbanisme car ce point de vue est le « levier » principal d'urbanisation du SI. C'est aussi le point de vue du SI le plus difficile à appréhender correctement ; la littérature peine à expliciter ce qu'est une fonction et les sources de confusion sont nombreuses :
 confusion avec l'activité ;
 confusion avec le use case ;
 confusion avec le rôle ou le poste d'un acteur ;
 confusion avec un module d'application ;
 

Le recensement des fonctions du SI nécessite une capacité d'abstraction qui peut dérouter les néophytes : une fonction est la capacité sous-jacente nécessaire à la réalisation d'une ou plusieurs activités, mais ce n'est pas l'activité. Par exemple, pour l'activité « planter un clou », la fonction sous-jacente est « frappe ». Ainsi la fonction « frappe » sert à d'autres activités d'un point de vue métier, et peut être outillée par différents outils d'un point de vue applicatif. Étant donné la problématique de granularité des fonctions, dans le point de vue fonctionnel, on parle aussi de blocs fonctionnels (qui regroupent les fonctions de bases concourantes à la même capacité du SI). Par exemple, le bloc « Enregistrement du client » comprend les fonctions de type CRUD (Création, Recherche/lecture, Mise à jour, Effacement).

Un SI urbanisé doit pouvoir découpler facilement les sous-systèmes d’information supportant différents métiers et pouvant évoluer à terme vers des systèmes d’information autonomes. Par exemple, une entreprise peut vouloir se donner à terme la possibilité de séparer ses métiers de distribution (vente) de ses métiers de production (gestion des produits) dans des unités organisationnelles distinctes.

L'urbanisation d’un SI combine :
 la volonté de pouvoir isoler certaines de ses parties pour pouvoir les faire évoluer facilement ;
 et l'objectif de mutualiser (mettre en commun avec des SI d'autres partenaires) ou d'externaliser d’autres parties plus stables, moins stratégiques, pour réaliser des économies.

Pour ce faire, l’architecture fonctionnelle recense à l’intérieur de chaque zone, quartier et îlot, les blocs fonctionnels qui entrent dans la composition du SI pour qu’il supporte les processus métiers de l'entreprise.

Le bloc fonctionnel assure : 
 une cohésion forte, cohésion entre les objets qu’il gère et les fonctions qu’il assure ;
 un couplage faible, soit un nombre limité d’échanges avec les autres blocs du SI.
La granularité du bloc fonctionnel (le niveau de maille du découpage) doit :
 faciliter sa réutilisation dans différents processus et renforcer la modularité du SI ;
 favoriser son remplacement par un bloc offrant des fonctionnalités équivalentes.

Le bloc fonctionnel constitue l’unité fonctionnelle à outiller de façon interchangeable. Un bloc fonctionnel est défini par :
 les objets métier qu’il gère pour le compte du SI ;
 les services fonctionnels, interfaces permettant d’échanger avec les autres blocs du SI, cela inclut les flux qu'il prend en charge et ceux qu'il produit ;
 les fonctions qu'il regroupe (fonctions liées aux objets métier), et les règles de production des données qu’il communique.

Le point de vue informatique 
 

Le système d'information d'un point de vue informatique est constitué d'un ensemble structuré :
 de composants matériels ;
 de composants logiciels ;
 et de centre de données, 
permettant d’automatiser tout ou partie d’un système d'information, et dont l’administration et l’exploitation sont assurées par une même entité organisationnelle (unité d’administration et d’exploitation).

Cette vue globalisante utile pour les non-informaticiens se découpe traditionnellement en différents points de vue bien distincts en informatique : 
 le point de vue applicatif qui se focalise sur les applications du SI indépendamment des plates-formes qui les hébergent ;
 le point de vue technique qui se découpe lui-même en :
 point de vue logiciel (qui décrit l'architecture logicielle d'une application ou d'une plate-forme qui l'héberge),
 point de vue infrastructure technique (qui décrit l'architecture réseau),
 point de vue physique ou matériel (qui décrit l'architecture matérielle).

Dans l'étude de l'existant, il faut prendre en compte ces différents types d'architecture, afin d'évaluer les vulnérabilités des sous-ensembles, ce qui ne peut être fait qu'en prenant en compte les niveaux technique et physique. Pour la définition de l’architecture cible, on peut se limiter à l'architecture applicative.

L'architecture applicative définit l’ensemble des applications constituant la partie automatisée d’un système d’information ainsi que leurs modalités d’assemblage et de communication.

Elle est une instanciation de l’architecture fonctionnelle d’un SI dans un environnement technique et d’exploitation donné : on parlera alors non plus de fonction dans la vue applicative mais de fonctionnalité d'une application (c'est-à-dire d'une fonction instanciée).

Le bloc applicatif est un ensemble de composants logiciels qui présentent une cohérence : 
 fonctionnelle : données et traitement sur les mêmes objets métiers ;
 technique : implémentation globale mono-plateforme.
Le bloc applicatif est autonome dans la mesure où son fonctionnement doit être indépendant du chemin que l'information aura suivi en amont et poursuivra en aval.

Le bloc applicatif est décrit en termes de :
 structures de données qu’il gère ;
 procédures fonctionnelles qu’il exécute ;
 services applicatifs qu’il met à disposition d'autres blocs ou des utilisateurs ;
 messages qu’il reçoit (les événements qu’il traite) et qu’il publie (les comptes-rendus d’événements ou d'opérations qu’il produit).

Les constituants du bloc applicatif (données et services) peuvent être publics (le bloc en donne la visibilité pour permettre à d’autres blocs de les utiliser) ou privés (pour les besoins internes du bloc).

Un bloc applicatif est un objet logiciel concret qui, dans un contexte technique donné, offre à l’ensemble du SI, l'implémentation des fonctionnalités des prises définies par le bloc fonctionnel correspondant.
Un bloc applicatif communique avec les autres blocs par échange de messages et par appel de services.

Méthodologie d’urbanisation 
La démarche d’urbanisation s’articule sur trois axes clés qui s’alimentent mutuellement :
 la modélisation de la stratégie ;
 la cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques) ;
 la détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques).
La distinction forte entre existant et cible est un facteur de clarification essentiel.

La démarche d’urbanisation du SI consiste notamment à :
 définir un SI cible, aligné sur la stratégie de l’entreprise ;
 déterminer la trajectoire à suivre pour atteindre ce SI cible.

Indépendamment des différentes approches qui, selon le contexte de l'entreprise et les options méthodologiques, peuvent être préconisées les activités d'urbanisations se classent en cinq grands domaines :

 le « cœur » des processus d'urbanisme ;
 définir et maintenir le cadre d'urbanisme : plans d’urbanisme (cibles et scénarios de migration), règles… ;
 réaliser et maintenir l'infrastructure fonctionnelle du SI : référentiels d’entreprise, dispositifs mutualisés d’échanges inter-applicatifs… ;
 développer les relations avec les projets : cadrage, études amont, accompagnement des projets… ;

 les processus de support : notamment « maintenir et diffuser les cartographies » ;

 et les processus de pilotage de l'urbanisation et de participation à l'arbitrage des projets.

Notes et références

Voir aussi

Articles connexes 
 Architecture d'entreprise
 Organisation
 Méta-modèle d’urbanisme
 SOA : Service Oriented Architecture
 Système d'information
 Sécurité informatique
 Sécurité des données
 Fuite d'information
 EAI : Enterprise Application Integration
 ESB : Enterprise Service Bus
 Middleware ou intergiciel
 Architecture logicielle
 Architecture flexible
 Progiciel de gestion intégré
 Data architecture dans la Wikipedia anglophone
 Analyse décisionnelle des systèmes complexes (méthode d'urbanisation des Systèmes d'Information)

Bibliographie 
 Jacques Sassoon, Urbanisation des systèmes d'information, Hermès Coll. Management et Informatique, 1998
 Christophe Longépé, Le projet d'urbanisation du S.I. 2e édition, Dunod, Paris, 2004, 
 Bernard Le Roux, Luc Desbertrand, Pascal Guérif, Xavier Tang, Julien Tixier, Pierre Verger, Urbanisation et modernisation du SI, Lavoisier, Paris, 2004, 
 Yves Caseau, Urbanisation et BPM, Le point de vue d’un DSI 2e édition, Dunod, Paris, 2006
 Pierre Pezziardi, Une Politique pour le Système d'Information - Descartes, Wittgenstein, "XML", OCTO, 2006 
 Club URBA-SI, Pratiques de l'urbanisme des systèmes d'information en entreprises, Publibook, 2003, 
 Jean-Christophe Bonne, Aldo Maddaloni, Convaincre pour urbaniser le SI, Lavoisier, Paris, 2004, 
 Bernard Le Roux, Joseph Paumier, La gouvernance de l'évolution du SI, Lavoisier, Paris, 2006, 
 René Mandel, De la stratégie business aux systèmes d'information: l'entreprise et son écosystème, Lavoisier, Paris, 2006, 
 Club URBA-EA (ex Club URBA-SI), Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques, Dunod, Paris, 2006, 
 Michel Volle, De l'informatique : savoir vivre avec l'automate, Economica, Paris, 2006, 
 Bernard Le Roux La transformation stratégique du système d'information, Lavoisier, Paris, 2009
 Jérome Capirossi, Architecture d'entreprise, Hermes Science Lavoisier, 2011,    
 Jean-Claude Jacquiot, L'architecture d'entreprise intégrée, cahier technique CASE France 2011
 Ludwig von Bertalanfy  Théorie générale des systèmes
 Jean-Louis Le Moigne  La théorie du système général
 Jacques Mélèse, Approches théoriques des organisations
 C.E. Shannon & W. Weaver  The mathematical theory of communication
 CARNOT, Deuxième principe de thermodynamique
 Ferdinand de Saussure, Cours de linguistique générale
 Luc Boyer et Noël Equilbey, Organisation, théories et applications

Liens externes 
 Club officiel d'Architecture d'Entreprise Club Urba EA 
 Architecture d'Entreprise et Chaîne de Valeur Value Architecture

Urbanisation du SI
Développement logiciel
Architecture logicielle