Structure technique¶

Documenter les composants, leurs interfaces, et l'infrastructure sur laquelle ils tournent.

Pourquoi modéliser la structure technique¶

Les chapitres précédents modelisent les acteurs, les processus, les données et les comportements — tout ce qui releve du "quoi" et du "comment logiquement". La structure technique répond a une question différente : comment le système est-il organisé physiquement ? Quels composants existent, quelles interfaces exposent-ils, sur quels nœuds sont-ils déployés ?

Cette vue est indispensable pour trois raisons :

1. Communication avec les ops : les équipes d'exploitation ont besoin de savoir ce qui tourne ou, avec quelles dépendances.
2. Analyse d'impact : quand un composant change, quels autres composants sont affectes ?
3. Décisions d'infrastructure : scaling, haute disponibilité, sécurité réseau — tout dépend de la topologie.

On dispose de trois notations principales pour cette vue : UML (composants et déploiement), C4 (niveaux 3 et 4), et ArchiMate. Chacune a son public et son niveau de formalisme.

Diagrammes de composants UML¶

Le diagramme de composants montre les unites logicielles modulaires du système, leurs interfaces et leurs dépendances.

Éléments¶

Exemple : architecture d'une plateforme e-commerce¶

graph TD
    subgraph "Frontend"
        WEB[Application Web]
        MOB[Application Mobile]
    end

    subgraph "API Layer"
        GW[API Gateway]
    end

    subgraph "Services metier"
        CAT[Service Catalogue]
        CMD[Service Commande]
        PAY[Service Paiement]
        USR[Service Utilisateur]
        NOT[Service Notification]
    end

    subgraph "Infrastructure"
        DB_CAT[(Base Catalogue)]
        DB_CMD[(Base Commande)]
        DB_USR[(Base Utilisateur)]
        MQ[Message Broker]
        CACHE[Cache distribue]
    end

    WEB --> GW
    MOB --> GW

    GW --> CAT
    GW --> CMD
    GW --> USR

    CAT --> DB_CAT
    CAT --> CACHE
    CMD --> DB_CMD
    CMD --> PAY
    CMD --"event"--> MQ
    USR --> DB_USR
    MQ --> NOT
    PAY --"callback"--> CMD

Interfaces : le contrat entre composants¶

L'interface est le concept le plus important du diagramme de composants. Elle définit le contrat : ce que le composant promet de faire (interface fournie) et ce dont il a besoin (interface requise). Le couplage entre composants se fait exclusivement via les interfaces, jamais via l'implémentation interne.

Diagrammes de déploiement UML¶

Le diagramme de déploiement montre l'infrastructure physique (ou virtuelle) et la répartition des composants sur cette infrastructure.

Éléments¶

Exemple : déploiement Kubernetes¶

graph TD
    subgraph "Cloud Provider"
        subgraph "Cluster Kubernetes"
            subgraph "Namespace: production"
                subgraph "Pod: api-gateway"
                    GW[Container: nginx + envoy]
                end
                subgraph "Pod: services"
                    S1[Container: service-commande]
                    S2[Container: service-catalogue]
                    S3[Container: service-paiement]
                end
            end
            subgraph "Namespace: data"
                DB1[(PostgreSQL - commandes)]
                DB2[(PostgreSQL - catalogue)]
                RD[Redis - cache]
                KF[Kafka - events]
            end
        end
        LB[Load Balancer] --> GW
        GW --> S1
        GW --> S2
        S1 --> DB1
        S1 --> KF
        S2 --> DB2
        S2 --> RD
        S1 --> S3
    end

    CDN[CDN] --> LB
    CLIENT[Client] --> CDN

Le diagramme de déploiement révélé des informations invisibles dans les autres vues : la latence réseau entre composants, les points de défaillance unique, les frontieres de sécurité (quel composant est expose a internet, lequel est dans un réseau prive).

C4 niveaux 3 et 4¶

Le modèle C4 de Simon Brown (présente au chapitre 03) définit quatre niveaux de zoom. Les niveaux 1 (contexte) et 2 (conteneurs) sont couverts dans le chapitre précédent. Ici on traite les niveaux 3 et 4.

Niveau 3 : Component diagram¶

Le niveau 3 zoome à l'intérieur d'un conteneur pour montrer ses composants internes. Chaque composant a une responsabilité, une technologie et des relations avec les autres composants et les systèmes externes.

Niveau 4 : Code diagram¶

Le niveau 4 zoome dans un composant pour montrer les classes, interfaces et patterns de code. En pratique, ce niveau est rarement maintenu manuellement — il est généré depuis le code ou abandonne au profit de la lecture directe du code.

C4 vs UML composants¶

ArchiMate¶

ArchiMate est un standard ouvert (The Open Group) pour la modélisation d'architecture d'entreprise. La ou UML et C4 se concentrent sur un système, ArchiMate couvre l'ensemble du SI et ses liens avec l'organisation.

Les trois couches¶

ArchiMate organisé l'architecture en trois couches, chacune avec ses éléments et ses relations.

Relations ArchiMate¶

Quand utiliser ArchiMate¶

ArchiMate prend tout son sens dans les contextes suivants :

• Cartographie du SI existant : comprendre les liens entre processus métier, applications et infrastructure
• Transformation d'entreprise : planifier la migration d'un SI legacy vers une architecture cible
• Impact analysis : identifier les conséquences d'un changement (retirer une application, migrer une base)
• Gouvernance IT : communiquer avec la direction sur l'état du SI

Quand utiliser quoi¶

Le choix de la notation dépend du public, du contexte et de l'objectif.

Combinaison des notations¶

En pratique, on combine les notations selon les besoins :

graph TD
    C4_1[C4 niveau 1 - Contexte] --"zoom"--> C4_2[C4 niveau 2 - Conteneurs]
    C4_2 --"zoom"--> C4_3[C4 niveau 3 - Composants]
    C4_3 --"si necessaire"--> UML_COMP[UML Composants - interfaces]
    C4_2 --"infrastructure"--> UML_DEP[UML Deploiement]
    C4_1 --"enterprise"--> ARCHI[ArchiMate - SI global]

L'erreur est de choisir une seule notation pour tout. C4 ne remplacé pas UML déploiement quand on doit planifier l'infrastructure. ArchiMate ne remplacé pas un diagramme de sequence quand on doit comprendre un protocole. Chaque notation a une force — on utilisé la bonne pour la bonne question.

Bonnes pratiques¶

Chapitre suivant : Flux de données — DFD, niveaux de détail, data mapping et zones de confiance pour comprendre comment les données traversent le système.