UML ou C4 : pourquoi je ne dessine plus mes architectures en spaghetti
Pendant longtemps, UML a régné sans partage dans les modélisations d’architecture logicielle. Normé, exhaustif, rigoureux… et souvent illisible.
Avec le temps (et l’expérience), j’ai ressenti le besoin d’un outil plus clair, plus adapté à la communication entre profils variés (techniques, produit, métier, DSI, etc.). C’est là que j’ai découvert le C4 Model.
Depuis, je ne fais plus mes architectures autrement.
C4 : un modèle pour raconter l’architecture
Le modèle C4 repose sur une idée simple : on ne communique pas de la même façon avec un CTO, un développeur back ou un Product Owner. Il faut donc plusieurs niveaux de vue, adaptés à chaque besoin.
Voici les 4 vues de base du modèle C4 :
- System Context : vue d’ensemble des interactions entre le système et ses utilisateurs ou autres systèmes externes.
- Container : les grandes briques techniques internes (API, DB, frontend, worker, etc.) et leurs liens.
- Component : zoom sur un container pour montrer ses modules internes (contrôleurs, services, repositories).
- Code : vue fine sur les classes ou fonctions (rarement nécessaire).
Chaque vue répond à une question différente, pour un public différent. Ensemble, elles racontent une histoire cohérente du système.
Des vues avancées pour aller plus loin
C4 propose aussi deux vues très puissantes souvent oubliées :
- Deployment View : représente la façon dont les composants sont déployés sur des machines, pods, VM, suivant les environnements (dev, staging, prod). Indispensable en contexte cloud / DevOps.
- Dynamic View : permet de représenter un scénario dynamique : une séquence d’appels entre composants pour répondre à une action métier ou technique.
Structurizr DSL : la puissance du “code as model”
Pour passer à l’échelle, j’utilise la DSL Structurizr pour décrire mes vues C4.
Les avantages sont clairs :
- Pas de duplication entre vues (DRY)
- Historique via Git
- Génération automatique des liens entre niveaux
- Intégration CI/CD possible
Et pour aller plus loin, je recommande fortement ce dépôt :
Il permet de générer un site statique de documentation d’architecture, incluant :
- Les diagrammes C4 (interactifs)
- Les ADRs (Architecture Decision Records)
- Du contenu Markdown (notes, liens, explications)
- Et même des diagrammes Mermaid intégrés pour représenter des flux, séquences, etc.
Idéal pour faire vivre la doc dans le temps, et la diffuser simplement.
Et UML dans tout ça ?
UML n’est pas inutile. Il reste plus complet pour certains usages : diagrammes d’état, modélisation de domaine fine, transitions, etc.
Mais dans 90% des cas projets, C4 permet de concevoir, comprendre, expliquer et faire évoluer une architecture avec bien plus d’impact.
Conclusion
Le modèle C4 ne remplace pas UML, mais il le dépasse largement sur le terrain de la communication, de la compréhension et de la collaboration.
Ajoutez Structurizr DSL + un site généré, et vous avez une documentation vivante, claire et industrialisable.
Un grand merci encore à Xavier Bouvard pour cette découverte.
Et vous ? Vous modélisez comment vos archis aujourd’hui ?