de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Une étude de cas complète et étape par étape : application du modèle C4 au système de banque en ligne (Big Bank plc)

Le modèle C4, créé par Simon Brown, est une méthode simple, hiérarchique et conviviale pour les développeurs afin de visualiser l’architecture logicielle. Elle utilise quatre niveaux d’abstraction (d’où le « C4 ») pour décrire un système, du niveau le plus élevé jusqu’aux détails au niveau du code :

  1. Contexte du système (Niveau 1) – La vue d’ensemble : le système et ses utilisateurs/dépendances externes.

  2. Conteneurs (Niveau 2) – Choix technologiques de haut niveau et responsabilités.

  3. Composants (Niveau 3) – Blocs logiques majeurs à l’intérieur d’un conteneur.

  4. Code (Niveau 4) – Détails optionnels au niveau des classes ou de la structure du code.

Il est soutenu par trois types supplémentaires de diagrammes :

  • Paysage du système

  • Dynamique

  • Déploiement

Le modèle est indépendant de la notation (vous pouvez utiliser n’importe quel outil de diagrammation) et se concentre sur la clarté, la cohérence et les détails adaptés au public cible. Il est largement adopté car il évite les diagrammes d’architecture « big ball of mud » et s’adapte des croquis au tableau blanc à la documentation automatisée.

Pour cette étude de cas ciblée, nous utilisons l’exemple canonique du site officiel C4 : Système de banque en ligne pour la banque fictive « Big Bank plc ». L’objectif métier est de permettre aux clients particuliers de consulter leurs comptes et de réaliser des paiements en ligne tout en s’intégrant aux systèmes centraux existants de la banque.

Nous allons passer en revue chaque niveau avec :

  • Objectif et public cible

  • Éléments clés + responsabilités

  • Relations

  • Un diagramme C4 PlantUML prêt à l’emploi diagramme PlantUML C4(PlantUML prend en charge la syntaxe C4 et s’affiche magnifiquement dans la plupart des visualisateurs Markdown)

  • Raisonnement et décisions clés

  • Comment le diagramme aide les parties prenantes

Étape 1 : Définir le périmètre et créer le diagramme de contexte du système (Niveau 1)

Objectif: Montrer comment le nouveau système de banque en ligne s’intègre dans le monde. Public cible : parties prenantes métier, personnes non techniques, nouveaux membres de l’équipe.

Éléments (exemple officiel) :

  • Client de banque personnelle (Personne) – Un client possédant un ou plusieurs comptes bancaires personnels.

  • Système de banque en ligne (Système logiciel) – Le nouveau système que nous développons.

  • Système bancaire central (Système logiciel, existant) – Système central qui gère les données des clients, les comptes et les transactions.

  • Système de messagerie (Système logiciel, externe) – Service Simple d’Email d’Amazon Web Services (AWS SES) pour envoyer des confirmations.

Relations:

  • Client → utilise → Système de banque en ligne (pour consulter les comptes et effectuer des paiements)

  • Système de banque en ligne → utilise → Système bancaire central (pour les données de compte et les paiements)

  • Système de banque en ligne → envoie un courriel via → Système de messagerie

Voici le Diagramme de contexte C4 PlantUML:

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

LAYOUT_TOP_DOWN()
LAYOUT_WITH_LEGEND()

title Diagramme de contexte du système (Niveau 1) pour le système de banque en ligne

Personne(client, "Client de banque personnelle", "Un client possédant un ou plusieurs comptes bancaires personnels.")
Système(systeme_banque_en_ligne, "Système de banque en ligne", "Le nouveau système pour consulter les comptes et effectuer des paiements.")
Système(systeme_banque_centrale, "Système bancaire central", "Système central existant gérant les données des clients, les comptes et les transactions.")
Système_Ext(systeme_messagerie, "Système de messagerie", "Service Simple d'Email d'Amazon Web Services (AWS SES) pour envoyer des confirmations.")

Rel(client, systeme_banque_en_ligne, "Utilise")
Rel(systeme_banque_en_ligne, systeme_banque_centrale, "Utilise")
Rel(systeme_banque_en_ligne, systeme_messagerie, "Envoie un courriel via")

Lay_D(client, systeme_banque_en_ligne)
Lay_D(systeme_banque_en_ligne, systeme_banque_centrale)
Lay_U(systeme_messagerie, systeme_banque_en_ligne)
@enduml

Raisonnement et valeur: Ce seul diagramme répond immédiatement à la question « Qu’est-ce que nous construisons et avec qui interagit-il ? ». Il empêche le débordement de périmètre en rendant explicites les dépendances externes. Les parties prenantes métier l’apprécient car aucun détail technique n’est encore présent.

Étape 2 : Diagramme de conteneurs (Niveau 2)

Objectif: Zoomer sur le système de banque en ligne et montrer les principaux unités déployables/exécutables (conteneurs) ainsi que leurs choix technologiques. Public cible : architectes, chefs développeurs, équipes opérationnelles.

Conteneurs à l’intérieur du système de banque en ligne:

  • Application à page unique (Navigateur web – JavaScript + Angular) – Interface utilisateur complète de la banque en ligne.

  • Application mobile (Appareil mobile – natif iOS/Android ou React Native) – Fonctionnalités limitées pour une utilisation en déplacement.

  • Application d’API (Côté serveur – Java + Spring Boot) – API JSON/HTTPS utilisée par les deux interfaces frontales.

  • Base de données (Base de données relationnelle – PostgreSQL) – Stocke les données de session, les préférences utilisateur, les résumés de comptes mis en cache (les données principales restent sur le système central).

Relations clés (mêmes systèmes externes que le niveau 1) :

  • SPA et application mobile → appel → Application d’API

  • Application d’API ↔ Base de données

  • Application d’API → Système bancaire central et système de messagerie

Diagramme de conteneurs C4 PlantUML:

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/angular.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/java.puml
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/postgresql.puml

LAYOUT_HAUT_BAS()
LAYOUT_AVEC_LÉGENDE()

titre Diagramme de conteneurs C4 pour le système de banque en ligne

Personne(client, « Client de banque personnelle », « Un client possédant un ou plusieurs comptes bancaires personnels. »)

Systeme_Bordure(systeme_banque_en_ligne, « Système de banque en ligne », « Le nouveau système pour consulter les comptes et effectuer des paiements. ») {
Conteneur(spa, « Application à page unique », « JavaScript + Angular », « Interface utilisateur complète de la banque en ligne », $sprite=”angular”)
Conteneur(application_mobile, « Application mobile », « iOS/Android (React Native) », « Fonctionnalités limitées pour une utilisation en déplacement », $sprite=”react”)
Conteneur(application_api, « Application d’API », « Java + Spring Boot », « API JSON/HTTPS utilisée par les deux interfaces frontales », $sprite=”java”)
ContainerDb(base_de_donnees, “Base de données”, “PostgreSQL”, “Stocke les données de session, les préférences des utilisateurs et les résumés de comptes mis en cache”, $sprite=”postgresql”)
}

Systeme(systeme_bancaire_central, “Système bancaire central”, “Mainframe existant gérant les données clients, les comptes et les transactions.”)
Systeme_Ext(systeme_email, “Système email”, “Service simple de messagerie d’Amazon Web Services (AWS SES) pour envoyer des confirmations.”)

‘ Relations
Rel(client, spa, “Utilise”, “HTTPS”)
Rel(client, application_mobile, “Utilise”, “HTTPS”)
Rel(spa, application_api, “Appelle”, “JSON/HTTPS”)
Rel(application_mobile, application_api, “Appelle”, “JSON/HTTPS”)
Rel(application_api, base_de_donnees, “Lit et écrit dans”, “JDBC/SQL”)
Rel(application_api, systeme_bancaire_central, “Interroge / Met à jour”, “JSON/HTTPS”)
Rel(application_api, systeme_email, “Envoie un email via”, “HTTPS”)

‘ Indications de disposition (facultatif – aide PlantUML à organiser les éléments mieux)
Lay_D(client, systeme_banque_en_ligne)
Lay_D(systeme_banque_en_ligne, systeme_bancaire_central)
Lay_U(systeme_email, systeme_banque_en_ligne)

@enduml

Raisonnement: Nous avons choisi un modèle moderne SPA + backend API pour le web, une application mobile native pour des performances optimales, et avons gardé la base de données légère (la majorité des données se trouvent dans le mainframe hérité). Ce diagramme est la source unique de vérité pour les décisions technologiques de haut niveau et aide les équipes DevOps à planifier l’infrastructure.

Étape 3 : Diagramme de composants (Niveau 3)

Objectif: Zoomer sur un conteneur (généralement le plus complexe – l’application API) et montrer ses principaux composants logiques. Public cible : les équipes de développement.

Exemple : Composants à l’intérieur de l’application API:

  • Contrôleur des comptes (Spring MVC)

  • Contrôleur d’authentification

  • Contrôleur de réinitialisation du mot de passe

  • Composant de sécurité (gère l’authentification, JWT, etc.)

  • Composant de gestion des comptes (orche斯特re les appels au système bancaire central)

  • Composant de notification par email

Diagramme de composants PlantUML C4 (focalisé sur l’application API) :

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml

LAYOUT_WITH_LEGEND()

title Diagramme de composants pour le système de banque en ligne - application API

Container(spa, "Application à page unique", "javascript et angular", "Fournit toutes les fonctionnalités de banque en ligne aux clients via leur navigateur web.")
Container(ma, "Application mobile", "Xamarin", "Fournit un sous-ensemble limité des fonctionnalités de banque en ligne aux clients via leur appareil mobile.")
ContainerDb(db, "Base de données", "Schéma de base de données relationnelle", "Stocke les informations d'inscription des utilisateurs, les identifiants d'authentification hachés, les journaux d'accès, etc.")
System_Ext(mbs, "Système bancaire principal", "Stocke toutes les informations essentielles sur les clients, les comptes, les transactions, etc.")

Container_Boundary(api, "Application API") {
    Component(accounts, "Contrôleur des comptes", "Spring MVC", "Fournit les résumés et soldes des comptes aux clients.")
    Component(auth, "Contrôleur d'authentification", "Spring MVC", "Gère la connexion des utilisateurs, la gestion des sessions et la génération des jetons.")
    Component(reset, "Contrôleur de réinitialisation du mot de passe", "Spring MVC", "Permet aux utilisateurs de réinitialiser leur mot de passe par courrier électronique.")
    Component(security, "Composant de sécurité", "Spring Bean", "Gère l'authentification, la génération des jetons JWT et le hachage des mots de passe.")
    Component(accountmgmt, "Composant de gestion des comptes", "Spring Bean", "Orchestre les appels au système bancaire principal pour les opérations sur les comptes.")
    Component(email, "Composant de notification par courrier électronique", "Spring Bean", "Envoie des courriels de réinitialisation de mot de passe et de vérification de compte via SMTP.")

    Rel(accounts, security, "Utilise")
    Rel(auth, security, "Utilise")
    Rel(reset, security, "Utilise")
    Rel(accountmgmt, mbs, "Utilise", "XML/HTTPS")
    Rel(email, db, "Lit", "JDBC")
}

Rel(spa, accounts, "Utilise", "JSON/HTTPS")
Rel(spa, auth, "Utilise", "JSON/HTTPS")
Rel(spa, reset, "Utilise", "JSON/HTTPS")
Rel(ma, accounts, "Utilise", "JSON/HTTPS")
Rel(ma, auth, "Utilise", "JSON/HTTPS")
Rel(ma, reset, "Utilise", "JSON/HTTPS")
@enduml


Raisonnement: Ce niveau montre comment les responsabilités sont réparties (séparation des préoccupations) et rend l’intégration des nouveaux développeurs beaucoup plus rapide. Vous ne dessinez des diagrammes de composants que pour les conteneurs suffisamment complexes pour le justifier.

Étape 4 : Diagramme de code (niveau 4) – facultatif

Objectif: Montrer la structure interne d’un composant unique (diagramme de classes, diagramme de séquence, etc.). Public cible : les développeurs travaillant sur ce code.

Exemple pour le Contrôleur d’authentificationcomposant – un diagramme de classes UML simple en PlantUML :

@startuml
diagrammeDeClasses

skinparam {
arrondirCoin 8
CouleurFlèche #444444
CouleurPoliceFlèche #444444
CouleurBordure #444444

Classe {
CouleurBordure #1A237E
CouleurFond #E8EAF6
CouleurPolice #1A237E
}
}

classe “ContrôleurD’authentification” {
+connexion(identifiants)
+récupérerJeton()
}

classe “FournisseurDeJetonJwt” {
+générerJeton(utilisateur)
+validateToken(token)
}

class “UserRepository” {
+findByUsername()
}

AuthenticationController ..> JwtTokenProvider : “utilise”
AuthenticationController ..> UserRepository : “utilise”
@enduml


Dans les projets réels, vous passez souvent le niveau 4 et pointez vers le code source réel au lieu de cela.

Étape 5 : Diagrammes d’accompagnement

Diagramme dynamique (exemple : flux « Visualiser le résumé du compte »)

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml

title Diagramme dynamique pour Visualiser le résumé du compte

Person(customer, “Client de banque personnelle”) {
Container(spa, “Application à page unique”) {
Container(api, “Application API”) {
ContainerDb(db, “Base de données”) {
System_Ext(coreBanking, “Système bancaire central”)
}
}
}
}

Rel(customer, spa, “1. Clique sur ‘Comptes’”, “”)
Rel(spa, api, “2. GET /accounts”, “JSON/HTTPS”)
Rel(api, db, “3. Lire le résumé mis en cache”, “”)
Rel(api, coreBanking, “4. Récupérer les données les plus récentes”, “”)
Rel(api, spa, “5. Retourner JSON”, “”)

MONTRER_LEGEND()
@enduml

Diagramme de déploiement (mappage physique de haut niveau) :

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Deployment.puml

titre Diagramme de déploiement pour le système bancaire en ligne

Noeud_Deploiement(aws, « Amazon Web Services », « Cloud ») {
Noeud_Deploiement(ec2, « Groupe d’auto-échelonnement EC2 », « Linux ») {
Conteneur(api, « Application API », « Java Spring Boot »)
}
Noeud_Deploiement(rds, « RDS », « PostgreSQL ») {
ConteneurBaseDeDonnées(db, « Base de données »)
}
}

Noeud_Deploiement(clientDevice, « Appareil du client », « Web/Mobile ») {
Conteneur(spa, « Application à page unique »)
Conteneur(mobile, « Application mobile »)
}

Système_Ext(coreBanking, « Système bancaire central (mainframe local) »)

Rel(spa, api, « Effectue des appels API vers », « HTTPS »)
Rel(mobile, api, « Effectue des appels API vers », « HTTPS »)
Rel_U(api, spa, « Fournit au navigateur web du client »)
Rel_U(api, mobile, « Fournit à l’application mobile »)

MONTRER_LÉGENDE()
@enduml

Comment utiliser cette étude de cas en pratique

  1. Commencez par un atelier : dessinez le contexte sur un tableau blanc.

  2. Itérez vers les conteneurs et les composants en utilisant PlantUML C4.

  3. Gardez les diagrammes dans le dépôt de code (en tant que code !) afin qu’ils restent à jour.

  4. Générez automatiquement une documentation vivante.

Cet exemple exact du système de banque en ligne est la référence officielle créée par Simon Brown et utilisé par des milliers d’organisations dans le monde entier. En suivant ces étapes, vous disposez désormais d’une description complète et prête à être mise en production de l’architecture, compréhensible par n’importe qui – du PDG au nouveau développeur junior – au bon niveau de détail.

Articles sur les diagrammes C4

Cette publication est également disponible en Deutsch, English, Español, فارسی, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 : liste des langues séparées par une virgule, 繁體中文 : dernière langue.