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[1]. 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[2] pour formaliser ou modéliser la réingénierie du système d'information (SI)[3].
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[4] relatif au management du système d'information.
Les outils d'EAM(en) 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 « urbanisation » est préféré à celui d'« urbanisme » car il met l'accent sur la progressivité de l’évolution vers une cible correctement urbanisée.
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, etc. 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, etc.).
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.
N.B. : 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, 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 gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (exemple : données de production) ;
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 :
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é :
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 :
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 ;
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 :
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 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.
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 ;
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
↑ a et bChristophe Longépé, Le projet d'urbanisation du SI : cas concret d'architecture d'entreprise, Paris, Dunod, , 4e édition éd., 297 p. (ISBN978-2-10-052883-7), [...] la démarche d'urbanisation, c'est-à-dire la démarche permettant d'améliorer l'efficacité du système d'information tout en en sauvegardant la cohérence. [...] l'alignement du système d'information sur la stratégie d'entreprise [...] La modélisation des processus existants et la définition des processus cibles alignés sur la stratégie sont donc une étape indispensable du projet d'urbanisation du SI. [...] Finalement : Enterprise IT Architecture = urbanisme des SI, et, Enterprise Architecture = urbanisme de l'entreprise.
↑Définition proposée par le Club Urba-EA : Urbaniser, c'est organiser la transformation progressive et continue du système d’information visant à le simplifier, à optimiser sa valeur ajoutée (quelle est la définition de la valeur ajoutée d'un SI ?) et à le rendre plus réactif et flexible vis-à-vis des évolutions stratégiques de l'entreprise, tout en s'appuyant sur les opportunités technologiques du marché.
↑ a et bClub Urba-EA, Urbanisme des SI et Gouvernance : bonnes pratiques de l'architecture d'entreprise, Paris, DUNOD, , 331 p. (ISBN978-2-10-054680-0), Au niveau international, pour faire face aux mêmes problématiques que celles visées par l'urbanisme des SI en France, ont été développées des approches, des méthodes, relevant de l'Enterprise Architecture (EA), traduit en français par l'expression "architecture d'entreprise". [...] L'EA correspond à un cadre plus large que celui couvert par l'urbanisme des SI. [...] L'urbanisme contribue à la gouvernance du système d'information : il fournit une vision globale qui a du sens, adaptée au cas de l'entreprise, améliore la gouvernance des projets, participe au tableau de bord de la DSI, éclaire les maîtres d'ouvrage, incite à gouverner la transversalité et les grands référentiels.
↑Elles sont toutefois parfois confondues dans la littérature française[réf. nécessaire].
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, (ISBN2-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, (ISBN2-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 (ISBN978-2-9525895-0-5)
Club URBA-SI, Pratiques de l'urbanisme des systèmes d'information en entreprises, Publibook, 2003, (ISBN2-7483-2942-2)
Jean-Christophe Bonne, Aldo Maddaloni, Convaincre pour urbaniser le SI, Lavoisier, Paris, 2004, (ISBN2-7462-0977-2)
Bernard Le Roux, Joseph Paumier, La gouvernance de l'évolution du SI, Lavoisier, Paris, 2006, (ISBN2-7462-1293-5)
René Mandel, De la stratégie business aux systèmes d'information: l'entreprise et son écosystème, Lavoisier, Paris, 2006, (ISBN2-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, (ISBN2-10-049678-6)
