Urbanisation (informatique)

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

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

NB : 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.

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, etc. ;
• Les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations commerciales, gestion des opérations logistiques internes, etc. ;
• 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, etc.) ;
• Les zones de gestion des gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (données de production, etc.) ;
• Les zones des activités de support : comptabilité, ressources humaines, etc. ;
• 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 ».

À 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 ».

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

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 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érent 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 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.

La démarche d’urbanisation s’articule sur 3 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.

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

• 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, (ISBN 2-10-007376-1)
• Bernard Le Roux, Luc Desbertrand, Pascal Guérif, Xavier Tang, Julien Tixier, Pierre Verger, Urbanisation et modernisation du SI, Lavoisier, Paris, 2004, (ISBN 2-7462-0885-7)
• 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 (ISBN 978-2-9525895-0-5)
• Club URBA-SI, Pratiques de l'urbanisme des systèmes d'information en entreprises, Publibook, 2003, (ISBN 2-7483-2942-2)
• Jean-Christophe Bonne, Aldo Maddaloni, Convaincre pour urbaniser le SI, Lavoisier, Paris, 2004, (ISBN 2-7462-0977-2)
• Bernard Le Roux, Joseph Paumier, La gouvernance de l'évolution du SI, Lavoisier, Paris, 2006, (ISBN 2-7462-1293-5)
• René Mandel, De la stratégie business aux systèmes d'information: l'entreprise et son écosystème, Lavoisier, Paris, 2006, (ISBN 2-7462-1297-8)
• Club URBA-EA (ex Club URBA-SI), Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques, Dunod, Paris, 2006, (ISBN 2-10-049678-6)
• Michel Volle, De l'informatique : savoir vivre avec l'automate, Economica, Paris, 2006, (ISBN 2-7178-5219-0)
• 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, (ISBN 9782746229808)
• 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

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

• Portail de l’informatique
• Portail du management