Urbanisation du SI¶

Organiser le système d'information comme on planifie une ville — zones, quartiers, ilots et règles de circulation.

La metaphore urbaine¶

L'urbanisation du SI est une approche française — nee dans les grandes entreprises hexagonales et theorisee par Longepe (Le projet d'urbanisation du SI) et Caseau (Urbanisation et BPM). Elle emprunte ses concepts à l'urbanisme : une ville bien organisée a des zones (residentielle, industrielle, commerciale), des règles de circulation, des espaces publics partages. Un SI bien urbanise suit les mêmes principes.

Pourquoi cette approche ? Parce que les grandes organisations ont des centaines d'applications qui se sont accumulees au fil des decennies — acquisitions, fusions, projets departementaux, systèmes historiques. Sans vision d'ensemble, le SI ressemble a une ville sans plan d'urbanisme : des constructions anarchiques, des routes qui ne menent nulle part, des quartiers entiers inaccessibles.

L'urbanisation ne propose pas de refaire le SI à zero — c'est irrealiste et dangereux. Elle propose de définir un plan cible et des règles de transformation progressive. Chaque nouveau projet, chaque remplacement d'application, chaque intégration doit rapprocher le SI du plan cible.

Les niveaux d'urbanisation¶

L'urbanisation structure le SI en quatre niveaux hierarchiques, du plus macro au plus micro :

graph TB
    subgraph "Zone"
        subgraph "Quartier 1"
            subgraph "Ilot A"
                B1["Bloc fonctionnel"]
                B2["Bloc fonctionnel"]
            end
            subgraph "Ilot B"
                B3["Bloc fonctionnel"]
                B4["Bloc fonctionnel"]
            end
        end
        subgraph "Quartier 2"
            subgraph "Ilot C"
                B5["Bloc fonctionnel"]
                B6["Bloc fonctionnel"]
            end
        end
    end

Règles d'urbanisme¶

L'urbanisation définit des règles strictes sur les communications entre niveaux :

• Pas de couplage direct entre blocs d'ilots différents. Toute communication passe par des interfaces définies au niveau de l'ilot.
• Pas de dépendance circulaire entre quartiers. Si le quartier A dépend du quartier B, alors B ne peut pas dépendre de A.
• Les zones communiquent uniquement via des services d'échange. Pas d'appel direct d'une zone a une application dans une autre zone.
• Un bloc fonctionnel n'appartient qu'a un seul ilot. Pas de duplication de responsabilité.

Ces règles rappellent directement les principes de modularité logicielle (couplage faible, cohesion forte) mais appliques à l'échelle du SI.

Les zones d'urbanisation¶

Longepe définit quatre grandes zones que l'on retrouve dans la plupart des plans d'urbanisme :

graph TB
    subgraph "Zone Echange"
        ECH["Services d'echange<br/>avec l'exterieur"]
    end

    subgraph "Zone Pilotage"
        PIL["Tableaux de bord<br/>Reporting<br/>Indicateurs"]
    end

    subgraph "Zone Metier"
        MET1["Quartier<br/>Gestion clients"]
        MET2["Quartier<br/>Production"]
        MET3["Quartier<br/>Comptabilite"]
    end

    subgraph "Zone Ressources"
        RES["Referentiels<br/>Donnees partagees<br/>Infrastructure"]
    end

    ECH --flux entrants--> MET1
    ECH --flux entrants--> MET2
    MET1 --donnees--> PIL
    MET2 --donnees--> PIL
    MET3 --donnees--> PIL
    MET1 --referentiels--> RES
    MET2 --referentiels--> RES
    MET3 --referentiels--> RES

Cartographie applicative¶

La cartographie applicative est l'outil central de l'urbanisation. Elle représenté visuellement l'ensemble des applications du SI, leurs fonctions et leurs interactions. Sans cartographie, on ne peut pas urbaniser — on ne transforme pas ce qu'on ne connait pas.

Types de cartographies¶

On distingue plusieurs vues complementaires :

• Vue fonctionnelle : quelles fonctions sont couvertes par quelles applications, positionnees sur le plan d'urbanisme (zones, quartiers, ilots)
• Vue applicative : les applications et leurs flux d'échanges — qui appelle qui, par quel protocole, avec quelle fréquence
• Vue infrastructure : les serveurs, les réseaux, les bases de données — ou tourne chaque application physiquement
• Vue métier : les processus métier et les applications qui les supportent

La cartographie révélé les problèmes invisibles : les applications qui couvrent la même fonction (redondance), les applications critiques qui ne sont connues que d'une seule personne, les flux de données non documentes, les dépendances circulaires.

Outils de cartographie¶

Les outils de cartographie vont du simple tableur aux plateformes specialisees (Mega, LeanIX, Ardoq). L'important n'est pas l'outil mais le processus : la cartographie doit être vivante, mise à jour à chaque changement, consultee à chaque décision d'architecture.

Le plan d'urbanisme¶

Le plan d'urbanisme est le document de référence qui décrit l'état cible du SI. Il contient :

• Le découpage en zones, quartiers et ilots avec les responsabilités de chaque bloc
• Les règles de communication entre blocs : quels protocoles, quels formats, quels services d'échange
• Les référentiels partages : quels sont les objets métier communs (client, produit, contrat) et qui en est le maître
• La trajectoire de transformation : comment passer de l'état actuel à l'état cible, projet par projet

Le plan d'urbanisme est un compromis entre l'idéal architectural et la réalité opérationnelle. Il doit être suffisamment précis pour guider les décisions, mais suffisamment souple pour s'adapter aux contraintes des projets. Un plan trop rigide sera ignore. Un plan trop vague sera inutile.

BPM et processus métier¶

Caseau (Urbanisation et BPM) fait le lien entre l'urbanisation du SI et la gestion des processus métier. Le BPM (Business Process Management) modélisé, exécuté et optimise les processus métier de l'entreprise.

Le lien SI-processus¶

Un processus métier traverse plusieurs zones du SI. Prenons l'exemple d'un processus de souscription d'assurance :

graph LR
    A["Demande client<br/>(Zone Echange)"] --formulaire--> B["Analyse risque<br/>(Zone Metier)"]
    B --scoring--> C["Decision<br/>(Zone Metier)"]
    C --accepte--> D["Emission contrat<br/>(Zone Metier)"]
    C --refuse--> E["Notification refus<br/>(Zone Echange)"]
    D --archivage--> F["GED<br/>(Zone Ressources)"]
    D --reporting--> G["Tableau de bord<br/>(Zone Pilotage)"]

Le BPM aide à identifier les services que le SI doit exposer pour supporter les processus métier. Chaque activité du processus correspond à un ou plusieurs services applicatifs. L'urbanisation garantit que ces services sont dans la bonne zone et respectent les règles de communication.

BPMN¶

BPMN (Business Process Model and Notation) est le standard de modélisation des processus métier. Contrairement a BPEL qui est un langage d'exécution, BPMN est un langage de modélisation lisible par les métiers et les IT. Les outils modernes (Camunda, Bonita) permettent d'exécuter directement des diagrammes BPMN.

Référence croisee avec TOGAF¶

L'urbanisation du SI est une approche complementaire de TOGAF (The Open Group Architecture Framework), traite au chapitre 03. Les deux se rejoignent sur plusieurs points :

La différence principale : TOGAF est un cadre méthodologique qui décrit comment faire de l'architecture d'entreprise. L'urbanisation est une metaphore et un ensemble de pratiques qui décrivent quoi organiser. Les deux se completent naturellement — on peut utiliser l'ADM de TOGAF pour piloter un projet d'urbanisation.

Les limites de l'urbanisation¶

L'urbanisation a apporte une vision d'ensemble indispensable pour les grands SI, mais elle a aussi ses limites :

Le temps long vs l'agilité. Un plan d'urbanisme se projette sur 3 a 5 ans. Les méthodes agiles demandent des résultats en semaines. La reconciliation entre vision long terme et exécution rapide reste un défi.

Le coût de la cartographie. Maintenir une cartographie applicative précisé dans un SI de plusieurs centaines d'applications est un travail a plein temps. Si la cartographie n'est pas à jour, elle est pire qu'inutile — elle donne une fausse confiance.

La gouvernance lourde. Comme pour SOA, la gouvernance des règles d'urbanisme peut devenir un frein à l'innovation. Si chaque nouveau projet doit passer par un comite d'urbanisme, les équipes contournent le processus.

Le décalage avec le code. L'urbanisation raisonne au niveau des applications et des flux, pas au niveau du code. Elle ne dit rien sur la qualité interne des applications. Un SI parfaitement urbanise peut être compose d'applications individuellement desastreuses.

Malgre ces limites, les concepts d'urbanisation — zones de responsabilité, référentiels partages, règles de communication — restent pertinents. On les retrouve dans la notion de bounded context du DDD, dans les team topologies, et dans la segmentation en domaines des architectures microservices.

Chapitre suivant : Cloud et microservices — quand l'infrastructure devient programmable et les services veritablement autonomes.