Le modèle C4 est une méthode pour dessiner une architecture logicielle en quatre niveaux de zoom, du contexte jusqu'au code. Cette leçon s'adresse aux administrateurs, développeurs et ops qui documentent un système sans méthode et dont les schémas ne se lisent qu'avec leur auteur à côté. Elle pose le vocabulaire (personne, système, conteneur, composant), la notation d'une boîte et d'une flèche, puis dit quel diagramme sert quel lecteur. Elle présente aussi la boutique en ligne, l'exemple que tout le module modélise. Aucune connaissance d'UML n'est nécessaire.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Situer l'origine du modèle C4 et ce qu'il corrige dans les schémas d'architecture habituels.
- Distinguer les quatre niveaux de zoom et la question à laquelle chacun répond.
- Nommer les cinq abstractions : personne, système logiciel, conteneur, composant, code.
- Annoter une boîte et une flèche pour qu'elles se lisent sans leur auteur.
- Choisir le diagramme adapté à un lecteur donné.
- Reconnaître la boutique en ligne, fil rouge des leçons du module.
Qu'est-ce que le modèle C4 et d'où vient-il ?
Section intitulée « Qu'est-ce que le modèle C4 et d'où vient-il ? »Le modèle C4 est une approche pour dessiner l'architecture d'un logiciel, créée par Simon Brown. Son site officiel, c4model.com, la présente ainsi : « The C4 model is an easy to learn, developer friendly approach to software architecture diagramming ». Le modèle est indépendant de la notation et de l'outillage : il fixe ce qu'on dessine et comment on l'annote, pas avec quel logiciel. Il a fait l'objet d'un livre, « The C4 model » (O'Reilly).
Il corrige trois défauts fréquents des schémas d'architecture. Le premier est le dessin sans légende, où chacun interprète couleurs et formes à sa façon. Le deuxième est la boîte sans type : on ne sait pas si « Backend » désigne un serveur, un service ou une équipe. Le troisième est la notation formelle UML (Unified Modeling Language, un langage de modélisation normalisé), trop lourde pour des lecteurs qui ne la connaissent pas.
Le nom résume la méthode : C4 pour Context, Containers, Components, Code. C'est une carte routière qu'on zoome : la vue du pays d'abord, puis la région, la ville, la rue. Chaque niveau montre moins de choses, mais plus en détail, et s'adresse à un lecteur différent.
Quels sont les quatre niveaux de zoom ?
Section intitulée « Quels sont les quatre niveaux de zoom ? »Le modèle C4 compte quatre niveaux emboîtés : le contexte, les conteneurs,
les composants et le code. Chacun zoome sur un élément du niveau précédent.
Le schéma ci-dessous ouvre la boutique en ligne : le contexte (la boutique,
son client, le service de paiement) contient le conteneur API, c'est-à-dire
le programme que l'interface web appelle pour obtenir ou modifier des données.
Cette API, écrite avec Node.js (un environnement qui exécute du JavaScript sur
un serveur), contient le composant Service Commandes, dont la classe
Commande forme le dernier niveau.
Le tableau associe chaque niveau à sa question, à son lecteur et à la vitesse à laquelle il devient faux. Cette dernière colonne vient de la FAQ de c4model.com : plus on descend, plus le diagramme vieillit vite, donc plus il coûte cher à tenir à jour.
| Niveau | Question à laquelle il répond | Lecteur | Vitesse de changement |
|---|---|---|---|
| Contexte | Quel est le système, qui l'utilise, avec quoi échange-t-il ? | Tout le monde, technique ou non | Très lente |
| Conteneurs | Quels blocs s'exécutent et se déploient, et comment se parlent-ils ? | Architectes, développeurs, ops | Lente (sauf microservices ou fonctions serverless) |
| Composants | De quoi est fait un conteneur à l'intérieur ? | Architectes et développeurs | Fréquente |
| Code | Comment une partie critique est-elle codée ? | Développeurs | Très rapide |
Il ne faut pas tout dessiner. c4model.com l'écrit sans détour : « you don't need to use all 4 levels of diagram », et « the system context and container diagrams are sufficient for most software development teams ». Les niveaux composants et code se dessinent quand ils apportent quelque chose, et le niveau code se génère depuis l'IDE (l'éditeur de code) à la demande. Les leçons Contexte et Conteneurs forment donc le cœur de la méthode ; celle sur les composants et le code est facultative.
Quelles sont les abstractions : personne, système logiciel, conteneur, composant, code ?
Section intitulée « Quelles sont les abstractions : personne, système logiciel, conteneur, composant, code ? »Le modèle C4 repose sur cinq abstractions, c'est-à-dire cinq types d'éléments qu'on emboîte. Les maîtriser vaut mieux que mémoriser les diagrammes, car chaque diagramme n'est qu'une façon de les disposer. Les définitions suivent celles de c4model.com.
| Abstraction | Définition | Exemple dans la boutique |
|---|---|---|
| Personne | Un acteur humain : rôle, persona ou personne nommée | Client, Gestionnaire de boutique |
| Système logiciel | Le plus haut niveau d'abstraction : quelque chose qui apporte de la valeur à ses utilisateurs, humains ou non, composé d'un ou plusieurs conteneurs | Boutique en ligne ; Service de paiement (externe) |
| Conteneur | Une application ou un magasin de données | Interface web, API, Base de données |
| Composant | Un regroupement de fonctionnalités liées, encapsulé derrière une interface bien définie, à l'intérieur d'un conteneur | Service Commandes |
| Code | Classes, interfaces, objets, fonctions | Classe Commande |
Le mot conteneur prête à confusion. Dans le modèle C4, il n'a aucun lien avec Docker ni avec les conteneurs Linux : c'est « an application or a data store », une application ou un magasin de données. Une base PostgreSQL installée sur une machine virtuelle est un conteneur C4, au même titre qu'une application monopage (une application web dont le code JavaScript s'exécute dans le navigateur) ou une application mobile. Le critère : c'est quelque chose qui tourne, ou qui garde des données, et qu'il faut déployer. La leçon Conteneurs approfondit ce point.
Les éléments s'emboîtent : un système contient des conteneurs, un conteneur contient des composants, un composant se compose d'éléments de code. Pour relier deux éléments, on trace une relation, qui est unidirectionnelle : une flèche, un verbe qui dit pourquoi l'un parle à l'autre, et, entre conteneurs, la technologie ou le protocole employé. Un protocole est l'ensemble de règles par lesquelles deux programmes échangent : HTTPS pour le web, SQL sur TCP pour une base de données.
Que doit porter chaque boîte et chaque flèche ?
Section intitulée « Que doit porter chaque boîte et chaque flèche ? »Une boîte lisible porte un nom, un type, une description et, pour un conteneur ou un composant, sa technologie ; une flèche porte un verbe. La page de notation de c4model.com le formule en règles : « Every diagram should have a title describing the diagram type and scope », « Every diagram should have a key/legend explaining the notation being used », « The type of every element should be explicitly specified » et « Every container and component should have a technology explicitly specified ». Chaque élément reçoit aussi une courte description de ses responsabilités.
Regardez les quatre repères numérotés du schéma ci-dessous. Le nom et le type avec la technologie entre crochets identifient la boîte, la description dit à quoi elle sert, et la flèche indique le sens, un verbe et le protocole.
Côté flèches, c4model.com demande que chaque ligne soit une relation unidirectionnelle et étiquetée, et recommande d'éviter le verbe « Uses » seul : il ne dit rien. Écrivez « Lit et écrit » ou « Envoie les e-mails de commande », puis la technologie entre parenthèses. Le texte doit aussi correspondre au sens de la flèche. Aucune palette de couleurs n'est imposée, mais le codage doit rester cohérent, lisible en noir et blanc et pour les daltoniens, et la légende l'explique. Pour relire un diagramme avant de le publier, trois questions de la checklist du site officiel suffisent : a-t-il un titre, le type de chaque élément est-il connu, chaque flèche a-t-elle un verbe ?
Quel diagramme pour quel lecteur ?
Section intitulée « Quel diagramme pour quel lecteur ? »Le bon diagramme est celui que le lecteur sait lire et dont il a besoin. c4model.com l'exprime ainsi : « The different levels of zoom allow you to tell different stories to different audiences ». Un dirigeant n'a pas besoin des technologies ; un nouveau développeur a besoin des conteneurs avant tout. Le schéma ci-dessous est un arbre de décision : partez de la question du lecteur et suivez la branche jusqu'au diagramme.
La dernière branche, « sinon une vue complémentaire », désigne trois diagrammes qui répondent à des questions que les quatre niveaux ne couvrent pas. Le paysage montre plusieurs systèmes d'une entreprise côte à côte. Le diagramme dynamique numérote les échanges d'un scénario précis, comme passer une commande. Le diagramme de déploiement place les conteneurs sur l'infrastructure d'un environnement donné. La leçon Paysage, dynamique, déploiement les construit.
Outil de modélisation ou outil de dessin ?
Section intitulée « Outil de modélisation ou outil de dessin ? »Un outil de modélisation garde l'architecture comme des données, un outil de dessin ne garde que des boîtes et des lignes. c4model.com distingue ces deux familles dans sa page d'outillage. Avec un outil de modélisation, on construit « a non-visual model of your software architecture » : « A model is just data! ». Les vues en sont dérivées et un élément se renomme à un seul endroit. Écrit en texte, le modèle se relit en diff, la comparaison ligne à ligne de deux versions dans Git. Avec un outil de dessin, « The domain language of diagramming tools is "boxes and lines" » : rien ne valide la cohérence, et les mêmes boîtes sont recopiées d'un dessin à l'autre.
Les outils de dessin génériques restent utiles pour une esquisse rapide. Dès que le diagramme doit vivre avec le code, le texte versionné l'emporte. La leçon C4 en code montre comment Structurizr (un outil de modélisation, avec son DSL, langage dédié qui décrit le modèle) et Mermaid portent le modèle C4. Pour écrire un schéma en texte et le rendre, la leçon Diagrammes as code fait déjà le travail.
Quel système les leçons du module modélisent-elles ?
Section intitulée « Quel système les leçons du module modélisent-elles ? »La boutique en ligne est le système que chaque leçon du module modélise à un niveau différent. Un seul exemple d'un bout à l'autre évite de réapprendre un nouveau cas à chaque page et montre comment les niveaux s'enchaînent.
Le Client parcourt le catalogue et passe commande ; le Gestionnaire de boutique met à jour le catalogue et les stocks. Ces deux personnes utilisent le système logiciel Boutique en ligne, qui vend le catalogue et encaisse les commandes. Il s'appuie sur deux systèmes externes qu'il ne développe pas : le Service de paiement, qui encaisse les cartes bancaires, et le Service de mail, qui envoie les e-mails de commande. À l'intérieur, la boutique se compose de trois conteneurs : une Interface web (application monopage), une API Node.js qui porte la logique métier, et une Base de données PostgreSQL.
Chaque leçon prend ensuite ce système sous un angle :
| Leçon | Ce qu'elle modélise sur la boutique |
|---|---|
| Contexte | Le système, ses personnes et ses systèmes externes |
| Conteneurs | Interface web, API et base de données |
| Composants et code | L'intérieur de l'API, puis le Service Commandes |
| Vues complémentaires | Paysage, commande en cours, déploiement en production |
| C4 en code | Le modèle écrit en Structurizr DSL et Mermaid |
La formation Architecture des services lit la même boutique : la leçon Lire une architecture apprend à lire un schéma d'architecture, tandis que le module présent apprend à l'écrire. On écrit mieux un schéma quand on sait ce qu'un lecteur y cherche.
À retenir
Section intitulée « À retenir »- Le modèle C4 décrit une architecture en quatre niveaux de zoom : Contexte, Conteneurs, Composants, Code.
- Il fixe ce qu'on dessine et comment on l'annote, pas l'outil : il reste valable avec n'importe quelle notation.
- Cinq abstractions : personne, système logiciel, conteneur, composant, code, emboîtées de l'une à l'autre.
- Un conteneur C4 est une application ou un magasin de données, sans lien avec Docker : une base PostgreSQL sur une machine virtuelle en est un.
- Une boîte porte un nom, un type, une description et une technologie ; une flèche porte un verbe et, entre conteneurs, un protocole.
- Chaque diagramme porte un titre (type et périmètre) et une légende.
- Contexte et conteneurs suffisent à la plupart des équipes ; les niveaux composants et code se dessinent seulement s'ils apportent quelque chose.
- Un modèle (données) se maintient mieux qu'un dessin (boîtes et lignes) : il se renomme en un endroit, et écrit en texte il se relit en diff.
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 : Diagramme de contexte C4 : votre système et son environnement
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications