Le modèle C4 à l'ère de l'IA : qui tient la carte du code généré ?

Jamais une équipe n'a produit autant de code aussi vite ; jamais la part de ce code lue par un humain n'a été aussi faible. La vitesse de génération a explosé, la vitesse de lecture humaine n'a pas bougé. Simon Brown, le créateur du modèle C4, le formule sans détour : l'IA génère des montagnes de code que plus personne ne comprend entièrement.¹⁰

Face à ce déséquilibre, le réflexe habituel, relire, ne passe pas à l'échelle. Nous l'avons documenté à propos de la code review à l'ère de l'IA : quand la production explose, le goulot se déplace vers la vérification, et le développeur bascule de créateur à vérificateur. Vérifier ligne à ligne est une bataille perdue d'avance ; le contrôle redevient possible à un autre niveau d'abstraction, celui de l'architecture.

Un modèle vieux de quinze ans y retrouve une seconde jeunesse. Le modèle C4, conçu par Simon Brown pour aider des humains à se parler d'architecture, est en train de changer de statut : de support de documentation, il devient un instrument de contrôle du cycle de développement, la carte qu'on superpose au territoire que l'IA vient de construire.

Un modèle né d'un déficit de communication

Le modèle C4 est né d'un constat pédagogique. Entre 2006 et 2011, Simon Brown anime des ateliers de conception logicielle et observe le même phénomène, session après session : la plupart des participants savent concevoir un système, mais pas le représenter clairement. Les diagrammes produits au tableau blanc accumulent boîtes ambiguës, flèches sans sémantique et légendes absentes.¹ Les équipes agiles, elles, avaient abandonné l'UML, jugé trop lourd, sans rien mettre à la place.

Brown formalise alors sa méthode personnelle de visualisation, sur des bases explicites : la notation UML et le modèle de vues « 4+1 » de Philippe Kruchten, dont il reprend la philosophie de décomposition en la simplifiant. Les quatre types de diagrammes sont nommés début 2010 (« context », « containers », « components », « classes ») et l'acronyme « C4 » apparaît en 2011. Vers 2015-2016, le quatrième niveau est renommé de « classes » à « code », pour couvrir aussi les paradigmes non orientés objet.¹ Détail savoureux confirmé par l'auteur : il utilisait le terme « container » deux à trois ans avant que Docker n'adopte le même mot.¹⁰

Quinze ans plus tard, le modèle est devenu le standard de fait de la visualisation d'architecture pour les équipes agiles : des retours d'expérience publiés chez Spotify, Decathlon ou Co-op sont documentés sur le site officiel, et l'approche est reconnue par le standard Open Agile Architecture de The Open Group.¹ Sa force tient à ce qu'il ne prétend pas être : ni un framework d'architecture d'entreprise à la TOGAF, ni une notation exhaustive. C'est un cadre de visualisation centré sur le développeur, dont l'ambition est de minimiser l'écart entre la description de l'architecture et le code réel. L'IA remet cette ambition au centre du jeu.

Quatre niveaux de zoom, une seule carte

Le principe du C4 tient en une analogie : une carte routière que l'on zoome. Chaque niveau répond à une question différente, pour un public différent : ce contrat de lecture fait la valeur du modèle.

Le diagramme de contexte (niveau 1) place le système au centre de son écosystème : les personnes qui l'utilisent, les systèmes avec lesquels il échange. Aucun choix technologique n'y figure : c'est le diagramme qu'on montre à un comité de direction. Le diagramme de conteneurs (niveau 2) zoome à l'intérieur : applications, API, bases de données, avec leurs technologies et leurs protocoles. Attention au faux ami : « conteneur » désigne ici toute frontière d'exécution (une application web, un schéma de base), et non un conteneur Docker. Le diagramme de composants (niveau 3) ouvre un conteneur pour en montrer les blocs logiques. Le diagramme de code (niveau 4), enfin, est explicitement optionnel : il évolue trop vite pour être maintenu à la main, et la recommandation officielle est de le générer depuis l'outillage.¹

À ces niveaux s'ajoutent des règles de présentation strictes : tout élément porte un nom, sa nature, sa technologie et une description de ses responsabilités ; tout diagramme porte un titre et une légende. Ces règles paraissent scolaires ; elles sont la condition pour qu'un diagramme soit vérifiable, par un humain hier, par une machine aujourd'hui.

Diagrams-as-code : la condition pour que la carte suive le territoire

Le modèle C4 ne prescrit aucun outil, mais son évolution moderne a une direction claire : le texte. Avec le Structurizr DSL, créé par Simon Brown lui-même, l'architecte ne dessine plus des boîtes : il déclare un modèle unique (éléments et relations) dont l'outil dérive toutes les vues. La séparation modèle/vues garantit la cohérence : une relation modifiée au niveau conteneur se répercute sur tous les diagrammes qui en dépendent.²

Autour de cette référence gravitent des alternatives aux compromis bien identifiés : C4-PlantUML offre une large couverture des vues C4 sans dépendre de Structurizr, au prix de la verbosité PlantUML ; Mermaid se rend nativement dans GitHub, GitLab ou Notion, mais son support du C4 reste qualifié d'expérimental et son moteur de mise en page faiblit sur les grands schémas.³ Le choix se résume assez bien : Structurizr DSL ou C4-PlantUML pour la documentation d'architecture pérenne, Mermaid pour les diagrammes légers intégrés à un README.

Ce détour par l'outillage est le point de bascule. Un diagramme dessiné dans un outil graphique est une image : opaque pour un LLM. Un modèle C4 exprimé en DSL est du texte structuré : diffable dans Git, validable en CI, et surtout lisible et productible par un modèle de langage. Les LLM excellent sur les syntaxes textuelles structurées. Le jour où l'architecture est devenue du code, elle est devenue un langage commun entre l'humain et la machine, dans les deux sens.

Ce que montre la recherche : la carte se dessine désormais dans les deux sens

Du brief au modèle : des agents qui conçoivent l'architecture

Premier sens : générer le modèle C4 à partir d'exigences. Une étude présentée à HICSS-59 propose un système multi-agents qui automatise la production d'un modèle C4 depuis un simple brief fonctionnel, en simulant un dialogue d'experts : un agent concepteur analyse les exigences et produit les vues Contexte, Conteneurs et Composants ; un agent auditeur confronte la proposition aux règles de cohérence du C4 et aux exigences non fonctionnelles, et renvoie ses objections jusqu'à consensus.⁴ Pour un praticien, l'évaluation compte plus que la génération : la qualité est notée par un cadre hybride combinant des vérifications déterministes (le DSL compile, la hiérarchie C4 est respectée) et une notation sémantique par un LLM juge (couverture des exigences, cohérence logique, conformité à la notation, lisibilité).⁴ La structure se vérifie mécaniquement, le sens se juge : la grille maker/checker que nous appliquons dans le SDLC piloté par l'IA.

Du code au modèle : la rétro-ingénierie assistée par LLM

Deuxième sens, plus utile encore au quotidien : reconstruire la carte depuis le territoire. C'est le champ de la Software Architecture Recovery, que les LLM sont en train de démocratiser. L'approche CIAO (Code In, Architecture Out) génère une documentation d'architecture directement depuis le code source, en combinant techniques classiques de récupération d'architecture et modèles de langage.⁵ D'autres travaux étendent l'exercice aux diagrammes de composants et aux vues comportementales.⁶ Côté praticiens, la recette est déjà opérationnelle : donner une base de code à un agent et lui faire produire un modèle Structurizr DSL complet, qui fournit toutes les vues pertinentes en une seule fois, plutôt que de reconstituer mentalement l'architecture en lisant les fichiers.⁸

Concrètement, ces outils croisent plusieurs sources d'évidence : l'arborescence et les manifestes de build (package.json, pom.xml) pour regrouper le code en composants ; les fichiers de déploiement (Dockerfile, charts Helm, manifestes Terraform) pour cartographier les conteneurs réels et leurs technologies. Le résultat n'est pas la carte voulue : c'est la carte vraie, celle de l'état effectif du système. Pour un audit d'architecture, une reprise de legacy ou un onboarding, repartir de cette carte-là plutôt que d'une documentation obsolète change la nature de l'exercice.

L'œil critique du SDLC : superposer l'intention et le code généré

L'IA sait générer du code depuis une architecture ; elle sait aussi régénérer une architecture depuis du code. Entre les deux se glisse la pratique qui nous semble la plus prometteuse pour la gouvernance du développement agentique : la boucle de contrôle architectural.

Le schéma est simple et déjà praticable avec l'outillage courant : fournir à l'agent une spécification d'architecture accompagnée de diagrammes as-code ; le laisser générer l'implémentation ; puis demander à un autre modèle de rediagrammer le code produit, et comparer visuellement les deux versions. La justification tient en une asymétrie cognitive : les humains sont meilleurs pour repérer une divergence entre deux schémas que pour détecter la même divergence en relisant des milliers de lignes.⁹ Une flèche qui n'existait pas dans l'intention (un composant qui parle à la base en court-circuitant la couche prévue, une dépendance qui traverse une frontière hexagonale) saute aux yeux sur un diagramme de niveau 2 ou 3, et resterait invisible dans une pull request de quarante fichiers.

Cette boucle a trois propriétés qui en font un instrument de gouvernance. D'abord, elle est indépendante du déclarant : on ne demande pas à l'agent s'il a respecté l'architecture, on régénère la carte depuis le code et on regarde. La sortie réelle plutôt que le claim : le principe même de la discipline de preuve du SDLC. Ensuite, elle est répétable à chaque itération : la dérive architecturale est une érosion continue, et un contrôle qui ne coûte qu'une régénération de diagramme peut tourner à chaque pull request. Enfin, elle reconcentre l'humain là où il a un avantage comparatif : juger une structure, pas parcourir du texte. C'est le complément naturel du plan de contrôle des agents : celui-ci gouverne le comportement de la flotte, la boucle C4 gouverne la forme de ce qu'elle produit.

Cartographier les systèmes agentiques eux-mêmes

Il reste un troisième front, plus jeune : utiliser le C4 non plus pour surveiller ce que l'IA produit, mais pour décrire les systèmes d'IA eux-mêmes. Un système agentique ne ressemble pas à une application classique : agents autonomes, décisions non déterministes, mémoires partagées, invocations d'outils. Des retours d'expérience industriels récents proposent d'adapter le formalisme C4 à ces architectures.⁷

L'adaptation est instructive à chaque niveau. Au niveau contexte, on représente explicitement les LLM qui motorisent les agents — versions comprises : le modèle fait partie de l'architecture, au même titre qu'une base de données. Au niveau conteneurs, on explicite le mode de coordination : orchestration (un superviseur central) ou chorégraphie (des agents réagissant à des événements). Au niveau composants, une extension de notation introduit des stéréotypes dédiés : <<agent>>, <<task>>, <<artifact>>, <<memory>>, et, le plus parlant, <<quality_gate>>, le nœud de décision qui modélise un agent critique validant la production d'un autre avant de la laisser passer.⁷ Que la première extension formelle du C4 pour les agents ait jugé nécessaire de réserver un stéréotype aux gates de qualité en dit long : même les notations convergent vers la vérification comme structure de base.

Le domaine reste peu standardisé, et il faut le lire comme tel : ces travaux, concentrés sur 2025-2026, sont des pistes de recherche actives, pas des pratiques industrielles consolidées. Mais pour qui conçoit aujourd'hui une architecture multi-agents (mémoire partagée, sous-agents vérificateurs, harnais), disposer d'une notation commune pour en discuter est déjà un progrès.

Le point de vue SFEIR : la carte est un actif, au même titre que le harnais

Chez SFEIR, nous défendons l'idée que dans un SDLC piloté par l'IA, le code est le sous-produit ; l'actif réel est la connaissance qui l'encadre : specs, contexte, harnais, règles apprises. Le modèle C4 as-code appartient à cette famille d'actifs : c'est la couche de connaissance structurelle, celle qui dit à l'agent dans quelle forme son travail doit s'inscrire, et qui permet à l'humain de vérifier qu'il s'y est inscrit. Un modèle Structurizr versionné dans le dépôt joue pour l'architecture le rôle que le context engineering joue pour le savoir métier : un contrat durable, machinable, amélioré à chaque itération.

Pour une équipe qui veut s'y mettre, la marche est basse :

• Passer l'architecture en texte. Un modèle C4 dans un outil graphique est une image morte ; en Structurizr DSL ou C4-PlantUML, c'est un artefact diffable, versionné à côté du code, que les agents lisent et écrivent. Réserver Mermaid aux schémas légers de README.³
• Donner la carte à l'agent avant qu'il code. Le modèle C4 fait partie du contexte d'entrée, au même titre que la spec : l'architecture cesse d'être une contrainte implicite que l'agent devine, elle devient une consigne explicite qu'il doit satisfaire.
• Régénérer la carte après qu'il a codé. Un second agent (jamais celui qui a produit le code) rétro-ingénierie l'implémentation et produit la carte vraie. Le diff visuel entre les deux cartes devient un critère de gate, à côté des tests et du lint.
• Ne maintenir à la main que les niveaux 1 à 3. Le niveau 4 se génère ; s'obstiner à le documenter manuellement, c'est recréer la documentation obsolète que le C4 cherchait à éliminer.

Une réserve d'honnêteté, enfin : la convergence explicite entre modèle C4 et IA est un champ jeune, dont l'essentiel des publications date de 2025-2026. Les systèmes multi-agents qui conçoivent des architectures complètes fonctionnent mieux comme point de départ à valider que comme source de vérité autonome. Mais la boucle de contrôle, elle, ne demande aucun pari sur la recherche. Elle assemble des briques disponibles aujourd'hui : un DSL mûr, des agents qui lisent le code, un humain qui compare deux images. Peu d'investissements offrent un tel ratio entre simplicité de mise en œuvre et regard critique retrouvé.

Points clés

• Le modèle C4 (Simon Brown, 2006-2011) décrit un système en quatre niveaux de zoom (contexte, conteneurs, composants, code) avec des règles de présentation strictes qui rendent les diagrammes vérifiables.¹
• Sa forme as-code (Structurizr DSL, C4-PlantUML) en fait un langage commun humain-machine : les LLM savent générer un modèle C4 depuis un brief, et le régénérer depuis une base de code existante.⁴⁵
• L'usage le plus rentable dans le SDLC est la boucle de contrôle architectural : contraindre l'agent avec la carte voulue, faire rediagrammer le code produit par un autre agent, et confier à l'humain le diff visuel, là où son œil est supérieur.⁹
• Des extensions du C4 émergent pour décrire les systèmes agentiques eux-mêmes (LLM explicites, orchestration vs chorégraphie, stéréotypes agent, memory, quality_gate) : champ prometteur mais encore peu standardisé.⁷
• Plus l'IA écrit de code, plus la représentation d'architecture lisible par l'humain redevient centrale : la discipline de modélisation n'est pas rendue obsolète par l'IA, elle est remise au centre par elle.¹⁰

Sources

1. Simon Brown, C4 model — FAQ et documentation officielle — c4model.com.
2. Simon Brown, Software architecture diagrams: which tool should we use? — dev.to/simonbrown ; documentation du Structurizr DSL — docs.structurizr.com.
3. Hidekazu Konishi, Diagramming with C4-PlantUML and Mermaid: a selection guide — hidekazu-konishi.com.
4. Collaborative LLM Agents for C4 Software Architecture Design Automation, accepté à HICSS-59 — arXiv:2510.22787, octobre 2025.
5. CIAO — Code In, Architecture Out: automated software architecture documentation with LLMs — arXiv:2604.08293, 2026.
6. Generating software architecture descriptions from source code using reverse engineering and LLMs — arXiv:2511.05165, novembre 2025.
7. Describing Agentic AI Systems with C4: Lessons from Industry Projects — arXiv:2603.15021, 2026.
8. Working Software, AI-assisted software architecture: generating the C4 model and views directly from code — workingsoftware.dev.
9. Taskade, The history of Mermaid (dont la pratique du re-diagramme comparatif spec vs code généré) — taskade.com, 2026.
10. Podcast Hard Boiled Software avec Simon Brown (résumé publié par l'auteur) et épisode GOTO Book Club (antériorité du terme « container ») — linkedin.com/in/simonbrownjersey.

Pour aller plus loin — conférences de Simon Brown

• The C4 Model — Beyond The Basics — YOW! 2025.
• The C4 Model — Misconceptions, Misuses & Mistakes — GOTO 2024.
• The C4 model: misconceptions, misuses and mistakes — Domain-Driven Design Europe 2025.
• C4 models as code — Craft Conference 2023.
• Visualising software architecture with the C4 model — Porto Tech Hub 2024.