de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Maîtriser le diagramme de conteneurs C4 : zoomer sur les choix technologiques, les responsabilités et la communication (avec des exemples PlantUML)

Qu’est-ce qu’un diagramme de conteneurs C4 ?

Le diagramme de conteneurs estNiveau 2dans le modèle C4 de Simon Brown. Il se concentre sur un seul système logiciel (défini au Niveau 1 – Contexte du système) pour montrer :

The Ultimate Guide to C4 Model Visualization with Visual Paradigm's AI Tools - ArchiMetric

  • Leformes de haut niveaude l’architecture à l’intérieur de la frontière de votre système.

  • Principauxunités déployables/exécutablesappeléesconteneurs.

  • Choix technologiquespour chaque conteneur.

  • Comment les conteneursinteragissententre eux et avec les acteurs/systèmes externes.

Précision importante : un « conteneur » dans C4n’est pasnécessairement un conteneur Docker. Il s’agit de toute unité déployable ou exécutable indépendamment qui exécute du code ou stocke des données. Exemples :

  • Application web / Application à page unique (SPA)

  • Application mobile

  • API côté serveur / microservice

  • Base de données (schéma)

  • Stockage de fichiers (bucket S3, dossier système de fichiers)

  • Broker de messages / file d’attente (lorsqu’il est modélisé explicitement)

  • Application bureau / application en ligne de commande (CLI)

  • Processus par lots / tâche planifiée

Le diagramme restede haut niveau — aucun détail sur les classes ou le code interne (c’est le niveau 3 des composants ou le niveau 4 du code).

Quand créer un diagramme de conteneurs

Créez (et maintenez) un diagramme de conteneurs lorsque :

  • Vous avez terminé (ou au moins esquissé) le Diagramme du contexte du système diagramme et devez répondre à la question : « Quels sont les principaux blocs de construction à l’intérieur de notre système ? »

  • Intégration de nouveaux développeurs, architectes ou personnel opérationnel — ils doivent comprendre rapidement la pile technologique et les responsabilités de haut niveau.

  • Prendre des décisions importantes en matière de technologie ou d’architecture (monolithe → microservices, ajout d’une application mobile, choix de la base de données, introduction de files de messages, migration vers le cloud).

  • Documentation destinée aux audits, à la conformité, aux revues de sécurité ou à la réponse aux incidents (aide à visualiser la surface d’attaque, les flux de données).

  • Vous souhaitez une « architecture en tant que code » qui réside dans le dépôt et évolue avec le système.

  • La plupart des équipes s’arrêtent là — Simon Brown lui-même remarque que Contexte du système + conteneurs les diagrammes sont suffisants pour la majorité des équipes logicielles. Passez à un niveau plus profond (composants/code) uniquement lorsque la complexité à l’intérieur d’un conteneur le justifie.

Sauter ou reporter si :

  • Le système est extrêmement simple (un processus + une base de données).

  • Vous êtes dans une phase très précoce d’idéation et n’avez besoin que du contexte global.

Pourquoi utiliser des diagrammes de conteneurs ? (Principaux avantages)

  • Clarté pour différents publics
    Les développeurs voient les technologies et les points d’intégration.
    Les équipes Ops/infra voient les unités déployables et les chemins de communication.
    Les architectes voient les limites de responsabilité et les risques liés à la dette technique.
    Les gestionnaires voient une vue suffisamment neutre sur la technologie, tout en restant concrète.

  • Évite le problème du « grand diagramme unique »
    Empêche de tout jeter (utilisateurs + infrastructure + classes + icônes cloud) dans une seule image surchargée.

  • Met en évidence les décisions clés
    Mettre clairement en évidence des choix comme une SPA + API + base de données relationnelle contre un rendu côté serveur + NoSQL, ou synchrone contre événementiel.

  • Communication et collaboration
    Agit comme une carte partagée lors des sessions de conception, des analyses d’incidents, de la modélisation des menaces et de la planification stratégique.

  • Documentation vivante
    Lorsqu’elle est écrite en PlantUML / Structurizr DSL / similaire → versionnée dans Git, régénérée automatiquement en continu, toujours à jour.

Comment créer un excellent diagramme de conteneurs (étape par étape + meilleures pratiques)

  1. Commencez au niveau 1
    Copiez les personnes et les systèmes logiciels externes du diagramme de contexte — ils deviennent des acteurs interagissant avec vos conteneurs.

  2. Tracez la frontière du système
    Utilisez Frontière_Système dans PlantUML pour définir clairement « à l’intérieur de notre système ».

  3. Identifiez les conteneurs
    Demandez : Quels sont les éléments exécutables/déployables séparément qui fournissent la fonctionnalité du système ?
    Schémas courants :

    • SPA web ↔ API backend ↔ Base de données

    • Application mobile ↔ Backend pour frontend (BFF) ↔ Services partagés

    • Microservices avec broker de messages

    • Monolithe hérité + nouvelle couche API

  4. Ajoutez la technologie et une brève description
    Chaque conteneur doit afficher : nom, technologie, objectif court.
    Gardez les descriptions inférieures à 15 mots.

  5. Définissez les interactions (relations)
    Montrez la direction + le protocole + l’intention (par exemple, « JSON/HTTPS », « Lit et écrit dans », « Publie vers », « Consomme depuis »).
    Utilisez des verbes sur les relations.

  6. Meilleures pratiques

    • Gardez-le lisible — visez moins de 10 à 12 conteneurs. Si plus → créez des vues ciblées (par exemple, « conteneurs du sous-système API »).

    • Soyez cohérent — même direction de disposition (haut-bas/gauche-droite), même niveau de détail.

    • Utilisez des icônes/sprites — ajoutez de la visibilité visuelle (PlantUML prend en charge devicons, font-awesome, etc.).

    • Légende et clé — activez la légende automatique dans PlantUML.

    • Évitez le bazar — omettez les files d’attente ou les sujets s’ils n’apportent pas de valeur ; étiquetez les protocoles sur les flèches à la place.

    • Version et stockage sous forme de code — validez les fichiers .puml dans le dépôt.

    • Adaptation au public cible — une version pour les développeurs (technologie détaillée), une version plus légère pour les parties prenantes.

Exemple PlantUML – Système bancaire en ligne classique (style Big Bank plc)

Voici un exemple propre et de qualité production utilisant la bibliothèque officielle C4-PlantUML.

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

' Optionnel : ajouter de jolis icônes (à partir des sprites tupadr3)
!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
!include https://raw.githubusercontent.com/tupadr3/plantuml-icon-font-sprites/master/devicons/android.puml

title Diagramme de conteneurs : Système bancaire en ligne

Personne(client, "Client de banque personnelle", "Un client de Big Bank plc")

BordureSysteme(c1, "Système bancaire en ligne") {
    Conteneur(spa, "Application monopage", "JavaScript & Angular", "Fournit toutes les fonctionnalités bancaires en ligne aux clients via leur navigateur web", $sprite="angular")
    Conteneur(mobile, "Application mobile", "Android/iOS (React Native)", "Fonctionnalités bancaires en ligne limitées", $sprite="android")
    Conteneur(api, "Application API", "Java & Spring Boot", "Fournit les fonctionnalités bancaires en ligne via une API", $sprite="java")
    ConteneurBaseDonnees_Ext(db, "Base de données bancaire", "PostgreSQL", "Stocke les préférences des utilisateurs, les données en cache, les sessions (les comptes principaux/transactions restent sur le système central)", $sprite="postgresql")
}

Systeme_Ext(core, "Système bancaire central", "Système principal – existant")
Systeme_Ext(email, "Système de messagerie", "Envoie des e-mails (ex. AWS SES)")

Rel(client, spa, "Utilise", "HTTPS")
Rel(client, mobile, "Utilise", "HTTPS")

Rel(spa, api, "Appelle", "JSON/HTTPS")
Rel(mobile, api, "Appelle", "JSON/HTTPS")

Rel(api, db, "Lit et écrit dans", "JDBC/SQL")
Rel(api, core, "Utilise", "JSON/HTTPS")
Rel(api, email, "Envoie un e-mail en utilisant", "HTTPS")

DISPOSITION_AVEC_LEGENDRE()
DISPOSITION_HAUT_BAS()

@enduml

Cela affiche un diagramme propre avec :

  • Bordure du système

  • Étiquettes de technologie

  • Sprites/icônes

  • Relations claires

  • Légende

Vous pouvez le coller directement sur le serveur en ligne PlantUML ou dans n’importe quel IDE ou éditeur compatible.

Utilisez cette structure comme modèle — remplacez les éléments par les noms, technologies et flux de votre propre système. Pour un styleage avancé (thèmes, couleurs personnalisées), consultez les exemples GitHub de C4-PlantUML.

Bon dessin de diagrammes — et souvenez-vous : l’objectif estune communication efficace, pas la perfection UML !

Ressource Diagramme de conteneurs 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.