Cette leçon présente les trois vues complémentaires du modèle C4 : le paysage, la dynamique et le déploiement. Elle s'adresse aux administrateurs, développeurs et ops qui ont déjà dessiné un contexte et des conteneurs et qui butent sur trois questions : que font nos autres systèmes, dans quel ordre les échanges se produisent-ils, sur quels serveurs tout cela tourne-t-il ? Chaque vue est montrée sur la boutique en ligne, avec le moment où elle vaut la peine d'être produite, et celui où il vaut mieux s'en passer.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Choisir la vue complémentaire qui répond à votre question, ou renoncer à en produire une.
- Interpréter un diagramme de paysage, un diagramme dynamique et un diagramme de déploiement de la boutique.
- Décrire un déploiement : des nœuds (les endroits où tourne un élément) imbriqués, leur technologie et leurs instances.
- Décider quelles vues garder, régénérer ou supprimer pour qu'elles ne deviennent pas fausses.
Pourquoi trois vues complémentaires, et quand les produire ?
Section intitulée « Pourquoi trois vues complémentaires, et quand les produire ? »Le modèle C4 propose, en plus de ses quatre niveaux, trois diagrammes complémentaires : le paysage (« system landscape »), la dynamique (« dynamic ») et le déploiement (« deployment »). Ils existent parce que les quatre niveaux, présentés dans la leçon sur le modèle C4, sont statiques et centrés sur un seul système. Trois questions restent sans réponse : que se passe-t-il à l'échelle de plusieurs systèmes, dans quel ordre s'échangent les messages, et où tourne chaque élément ?
Le schéma ci-dessous est un arbre de décision. Partez du haut avec votre question et suivez la branche : plusieurs systèmes mènent au paysage, un scénario ordonné à la dynamique, l'emplacement des conteneurs au déploiement. Si aucune de ces questions ne se pose, les quatre niveaux suffisent.
La documentation du modèle C4 donne la même consigne que pour les niveaux : « you don't need to use all 4 levels of diagram », et ses diagrammes de contexte et de conteneurs « are sufficient for most software development teams ». Les vues complémentaires suivent cette logique, avec une nuance : sa page sur le déploiement le note recommandé, celle du paysage aussi (surtout pour les grandes organisations, qui comptent plusieurs systèmes), alors que celle de la dynamique répond non et la réserve avec parcimonie aux motifs récurrents ou aux interactions complexes.
Le paysage : comment cartographier tous les systèmes d'une organisation ?
Section intitulée « Le paysage : comment cartographier tous les systèmes d'une organisation ? »Un diagramme de paysage est un diagramme de contexte « sans focus » sur un seul système : il montre tous les systèmes d'une entreprise, d'une organisation ou d'un département, avec les personnes qui les utilisent. Son périmètre n'est plus un système mais une organisation entière. Le modèle C4 le décrit comme « a bridge into the enterprise architecture world », un pont vers l'architecture d'entreprise. Il parle aux profils techniques comme aux autres, et sert surtout à représenter un portefeuille de systèmes : la liste de ce que l'organisation exploite, et qui parle à qui.
Regardez d'abord le cadre « La boutique » : il contient les trois systèmes internes (Boutique en ligne, Gestion des stocks, Comptabilité). Les systèmes externes (Service de paiement, Service de mail, Transporteur) sont dehors, atténués. Les quatre personnes sont aux bords, reliées au système qu'elles utilisent. Suivez ensuite les flèches entre systèmes : elles portent un verbe et, quand il existe, la technologie.
La lecture tient en trois relations. La Boutique en ligne réserve les articles vendus auprès de la Gestion des stocks (JSON/HTTPS). Elle transmet les ventes du jour à la Comptabilité par un fichier CSV (valeurs séparées par des virgules, un fichier texte tabulaire) déposé chaque nuit. La Gestion des stocks commande l'enlèvement des colis au Transporteur (JSON/HTTPS).
Ce que l'on en tire dépasse le dessin. Le paysage révèle les dépendances entre équipes : si la Comptabilité attend un fichier chaque nuit, une panne de la boutique la concerne. Il rend visible un échange qui passe par un fichier plutôt que par une API. Enfin il sert de table des matières : chaque système peut recevoir ensuite son propre diagramme de contexte, comme celui de la leçon sur le contexte. Un paysage ne zoome jamais dans un système : dès que vous y dessinez des bases ou des API, vous êtes passé aux conteneurs.
La vue dynamique : comment montrer un scénario pas à pas ?
Section intitulée « La vue dynamique : comment montrer un scénario pas à pas ? »Une vue dynamique montre comment des éléments collaborent pour réaliser une fonctionnalité ou un cas d'utilisation (un scénario d'usage), à l'aide d'interactions numérotées. Les quatre niveaux ne disent jamais dans quel ordre les messages circulent : une flèche entre l'API et le Service de paiement ne précise pas ce qui se passe avant ou après. Le modèle C4 s'inspire du diagramme de communication d'UML (Unified Modeling Language, la notation de modélisation logicielle classique) et le décrit comme « similar to a UML sequence diagram ». Ses éléments sont des systèmes, des conteneurs ou des composants.
Le schéma ci-dessous raconte « Passer une commande » au niveau des conteneurs. Lisez-le de haut en bas : chaque flèche porte un numéro, de 1 à 9, et un message. Le temps s'écoule vers le bas ; les colonnes sont le Client, l'Interface web, l'API, la Base de données, le Service de paiement et le Service de mail.
L'ordre a un sens. Après la validation du panier (1), l'Interface web envoie
POST /commandes à l'API en JSON/HTTPS (2). L'API enregistre la commande
« en attente » (3) avant de débiter la carte (4), puis, une fois le
paiement accepté (5), la passe en « payée » (6). Elle demande ensuite l'envoi
de la confirmation au Service de mail (7) et répond 201 à l'Interface web
(8), qui affiche la confirmation au Client (9). Si le débit échoue entre
(4) et (5), la commande « en attente » existe déjà : seule cette vue rend
ce détail visible.
Produisez une vue dynamique quand un motif récurrent revient dans le système, quand une interaction complexe demande un ordre précis, ou quand un incident doit être expliqué. Elle sert alors un runbook (la procédure d'urgence, qui s'appuie sur l'ordre des échanges pour diagnostiquer) ou un postmortem (le compte rendu qui retrace la chronologie d'un incident). Ne la produisez pas pour chaque fonctionnalité : chaque scénario dessiné est un scénario à maintenir.
Reste la disposition. Une vue en communication place les éléments sur la page et numérote les flèches ; une vue en séquence, comme ci-dessus, les aligne en colonnes et fait descendre le temps. L'information est la même : choisissez celle que votre lecteur lit le plus facilement. L'écrire en texte relève de la leçon Diagrammes as code.
La vue déploiement : comment dire où tourne chaque conteneur ?
Section intitulée « La vue déploiement : comment dire où tourne chaque conteneur ? »Un diagramme de déploiement montre les instances de systèmes ou de conteneurs posées sur l'infrastructure d'un seul environnement. Un environnement est un jeu complet de machines au service d'un usage : production, préproduction (« staging », la copie d'essai de la production) ou développement. C'est la réponse à une limite posée par la leçon sur les conteneurs : ce niveau dit très peu de choses sur le clustering, les répartiteurs de charge, la réplication ou la bascule. Le déploiement s'en charge, avec un diagramme par environnement : mélanger deux environnements dans un même dessin produit un schéma faux pour les deux.
Quatre notions composent cette vue, et chacune est définie avant le dessin :
- un deployment node (nœud de déploiement) est l'endroit où tourne un élément : machine physique, machine virtualisée, conteneur Docker ou environnement d'exécution comme un navigateur ; les nœuds s'imbriquent, par exemple un serveur qui contient un runtime (le programme qui exécute le code) ;
- un infrastructure node (nœud d'infrastructure) représente un élément d'infrastructure qui n'est pas un conteneur C4 : DNS, répartiteur de charge (qui distribue les requêtes entre plusieurs serveurs), pare-feu ;
- une container instance (instance de conteneur) est un exemplaire en fonctionnement d'un conteneur du niveau précédent, posé sur un nœud ;
- une software system instance (instance de système logiciel) fait la même chose pour un système entier.
Le schéma ci-dessous montre l'environnement « Production ». Lisez-le de l'extérieur vers l'intérieur : chaque cadre est un nœud, chaque nœud porte sa technologie entre crochets, et les éléments du niveau précédent (Interface web, API, Base de données) apparaissent en tant qu'instances. Les systèmes externes restent hors des nœuds.
Suivez les trois machines. Le Poste du client a pour environnement d'exécution le navigateur web, qui exécute l'Interface web. Le Serveur applicatif, en deux exemplaires, tourne sous Ubuntu 24.04 et contient Node.js 22, qui exécute l'API. Le Serveur de données tourne sous Ubuntu 24.04 et contient PostgreSQL 17, qui héberge la Base de données. Les ports sont sur les flèches : 443 pour HTTPS, 5432 pour PostgreSQL, 587 pour l'envoi de mails. Le Service de paiement et le Service de mail restent dehors, puisque la boutique ne les exploite pas.
C'est ici, et pas au niveau des conteneurs, qu'apparaissent Docker, Kubernetes ou une machine virtuelle : un conteneur Docker ou une machine virtuelle est un nœud de déploiement, pas un conteneur C4. Le modèle C4 admet aussi les icônes des fournisseurs cloud, à condition qu'elles figurent dans la légende. Ce que ce diagramme dit aussi à l'exploitation, la carte d'identité du service le reprend en texte, et la documentation opérationnelle dit où le ranger.
Comment tenir ces vues à jour ?
Section intitulée « Comment tenir ces vues à jour ? »Une vue complémentaire vieillit à la vitesse de ce qu'elle décrit, et seule une régénération depuis une source fiable la maintient juste. Le déploiement change à chaque évolution de l'infrastructure : un serveur ajouté, une version de PostgreSQL montée, un répartiteur inséré. La dynamique vieillit avec le code, puisque chaque nouvelle étape du scénario la rend fausse. Le paysage bouge lentement, au rythme où l'organisation ajoute ou retire des systèmes.
La FAQ du modèle C4 donne des pistes de génération. Le déploiement peut se produire depuis l'infrastructure as code (Terraform, CloudFormation : des fichiers qui décrivent les serveurs), puisque le code décrit déjà l'infrastructure. Un catalogue de services (Backstage, ServiceNow : un inventaire des services de l'organisation) peut servir de source aux vues de haut niveau, paysage et contexte, et des données OpenTelemetry (les traces émises par les applications) à repérer les services et leurs relations. Pour la dynamique, la FAQ ne dit rien ; tirer une vue des traces d'un scénario réel est une extension logique, pas une consigne du modèle. Une autre voie consiste à tenir un modèle unique et à en dériver les vues, ce qu'explique la leçon sur C4 en code avec Structurizr.
Une règle évite l'accumulation de schémas morts : une vue par question réelle. Datez chaque vue (le titre ou la légende porte la date ou la version de l'infrastructure), régénérez celles qui ont une source, et supprimez celles dont plus personne ne se sert. Un schéma périmé trompe plus qu'une absence de schéma, parce que le lecteur lui fait confiance.
Quelles erreurs fréquentes éviter ?
Section intitulée « Quelles erreurs fréquentes éviter ? »Les erreurs les plus courantes sont un paysage qui zoome, une dynamique sans numéros et un déploiement qui mélange des environnements. Le tableau ci-dessous les regroupe avec leur conséquence et la correction à apporter. Il se lit comme une liste de contrôle avant de publier une vue.
| Erreur | Conséquence | Correction |
|---|---|---|
| Un paysage qui zoome dans un système (bases, API) | Le lecteur ne sait plus s'il lit un paysage ou des conteneurs | Rester au niveau des systèmes, un contexte ou des conteneurs par système |
| Une dynamique sans numéros | L'ordre des échanges, seul intérêt de la vue, disparaît | Numéroter chaque interaction et nommer le message |
| Un déploiement qui mélange deux environnements | Personne ne sait si le serveur existe en production ou en test | Un diagramme par environnement |
| Des nœuds sans technologie | Impossible de savoir quel système d'exploitation ou quel runtime est visé | Porter la technologie sur chaque nœud, comme « Ubuntu 24.04 » ou « Node.js 22 » |
| Des systèmes externes posés dans un nœud | Le lecteur croit que vous exploitez le Service de paiement | Les laisser à l'extérieur des nœuds |
| Une vue dont plus personne n'est propriétaire | Elle dérive jusqu'à devenir fausse | La dater, la régénérer ou la supprimer |
À retenir
Section intitulée « À retenir »- Les trois vues complémentaires du modèle C4 sont le paysage, la dynamique et le déploiement ; chacune répond à une question que les quatre niveaux ne traitent pas, et sans question on ne la dessine pas.
- Le paysage est un contexte « sans focus » : tous les systèmes d'une organisation, sans zoom dans l'un d'eux.
- La vue dynamique numérote les interactions d'un scénario ; elle s'utilise avec parcimonie, pour un motif récurrent, une interaction complexe ou un incident à expliquer. Communication ou séquence : même information, autre disposition.
- Le déploiement pose des instances sur des nœuds imbriqués, avec leur technologie, un diagramme par environnement ; Docker, Kubernetes et les machines virtuelles apparaissent à ce niveau.
- Les systèmes externes restent hors des nœuds de déploiement.
- Une vue qui n'a pas de source de régénération (infrastructure as code, catalogue, modèle) se date et se supprime quand plus personne ne s'en sert.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : C4 en code : Structurizr DSL, Mermaid C4 et C4-PlantUML
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications