Urbanisation (informatique)

Un article de Wikipédia, l'encyclopédie libre.

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.

L'urbanisation informatique est une des méthodologies d'architecture d'entreprise[5],[4],[1].

Enjeux de l'urbanisation du système d'information[modifier | modifier le code]

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

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[modifier | modifier le code]

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, etc. L'urbanisation consiste donc à créer un SI agile, modulable et évolutif.

Application des concepts d'urbanisation[modifier | modifier le code]

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 :

  1. "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.
  2. "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.
  3. "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.
  4. "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)[modifier | modifier le code]

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[modifier | modifier le code]

  • 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[modifier | modifier le code]

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

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[modifier | modifier le code]

À 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[modifier | modifier le code]

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[modifier | modifier le code]

Ce niveau de préoccupation du SI est constitué par la description :

Ces objectifs peuvent être modélisés

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[modifier | modifier le code]

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

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 à :

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[modifier | modifier le code]

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

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[modifier | modifier le code]

Le système d'information d'un point de vue informatique est constitué d'un ensemble structuré :

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[modifier | modifier le code]

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[modifier | modifier le code]

  1. a et b Christophe Longépé, Le projet d'urbanisation du SI : cas concret d'architecture d'entreprise, Paris, Dunod, , 4e édition éd., 297 p. (ISBN 978-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.
  2. notamment par Jacques Sassoon dans les années 1990 dans le secteur bancaire
  3. 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é.
  4. a et b Club Urba-EA, Urbanisme des SI et Gouvernance : bonnes pratiques de l'architecture d'entreprise, Paris, DUNOD, , 331 p. (ISBN 978-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.
  5. Elles sont toutefois parfois confondues dans la littérature française[réf. nécessaire].

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • 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. Théorie de la modélisation, Paris, PUF, 1977.
  • Jacques Mélèse, Approches systématiques des organisations, Paris, Hommes et Techniques, 1979.
  • 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[modifier | modifier le code]