La réponse la plus courante est souvent :

« On est en Microservice, ou architecture en couche (Layered).. voir meme en Clean Architecture »

Mais en réalité cela ne décrit qu’une seule chose : la structure technique du système.

C’est comme dire d'un temple grec :

« il est construit en marbre » ou « il est ionique »

ce qui n’est pas faux, mais ça ne dit rien sur l’architecture du temple.

🏛️ L’analogie du temple grec

Pour comprendre ce qu'est réellement l'architecture d'un système, j'aime utiliser l'analogie d'un temple grec comme le Parthénon.

Un temple repose sur trois éléments fondamentaux : le toit, les piliers (colonnes) et la base

1. Le Toit : entablement, fronton et toiture

La partie visible, spectaculaire du temple est composée de l'entablement, du fronton et de la partie toiture. L'entablement repose directement sur les colonnes et comprend l'architrave, la frise et la corniche.

• Le fronton : sommet triangulaire du temple qui ferme la toiture et complète la structure supérieure. Il expose une surface visible destinée à accueillir des scènes mythologiques ou religieuse, rendant l'histoire et la fonction du temple immédiatement lisible depuis l'agoras

• La corniche : partie saillante supérieure de l’entablement qui termine la façade et protège les éléments inférieurs contre les intempéries et sert également d'element décoratifs pouvant accueillir des acrotères.

• La frise est une bande horizontale comprise entre l'architrave et la corniche. Elle est conçue pour recevoir des éléments narratifs et décoratifs représentant processions, batailles ou scène mythologiques, illustrant l'identité du temple ou de la cité.

• L'architrave est l'élément inférieur de l'entablement qui repose sur les chapiteaux des colonnes, element clé qui transmet et repartit les charges de la structure superieure vers les colonnes.

• Entablement : Ensemble horizontal composé de l’architrave, de la frise et de la corniche. Constitue la structure supérieure portée par les colonnes et forme la base du fronton et de la toiture.

• Chapiteau : élément de transition entre la colonne et l'architrave. Assure une meilleure distribution des charges tout en marquant visuellement l'ordre architectural (dorique, ionique ou corinthien).

Bien qu’il soit situé sous l’entablement, le chapiteau n’en fait pas réellement partie. Il joue le rôle de pièce de transition entre la colonne et la structure supérieure. On le mentionne ici pour matérialiser ce point de jonction entre les deux grands composants du temple : les colonnes et l’entablement qu’elles supportent.

2. Des piliers

Les colonnes sont les piliers du temple. Elles soutiennent l’entablement et la toiture décrits dans la section précédente. Leur rôle est simple : porter la charge imposée par la structure supérieure.

Autrement dit, la forme et les proportions des colonnes ne sont pas seulement esthétiques. Elles sont choisies en fonction des contraintes imposées par le toit : son poids, sa portée et la richesse de son décor.

Les Grecs ont ainsi développé trois grands ordres architecturaux, chacun offrant un compromis différent entre robustesse, capacité de charge et finesse structurelle.

Dorique

L’ordre dorique est le plus ancien et le plus robuste. La colonne est massive, avec un fût épais et un chapiteau simple, ce qui lui permet de supporter un entablement particulièrement lourd.

Cette solidité autorise également un espacement plus important entre les colonnes, ce qui permet de couvrir de grandes portées et de supporter des structures supérieures monumentales. C’est pour cette raison que les temples les plus imposants, comme le Parthénon, utilisent l’ordre dorique.

Ionique

L’ordre ionique introduit des colonnes plus élancées et plus fines, reconnaissables à leur chapiteau à volutes. Cette finesse apporte élégance et légèreté visuelle, mais réduit la capacité de charge.

Un temple ionique impose donc un entablement plus léger et nécessite généralement un espacement plus réduit entre les colonnes afin de maintenir la stabilité de la structure.

Corinthien

L’ordre corinthien est le plus tardif et le plus décoratif. Les colonnes sont encore plus élancées et leur chapiteau, richement orné de feuilles d’acanthe, accentue l’impression de verticalité et de légèreté.

Cette élégance impose cependant des contraintes structurelles plus fortes : l’entablement doit rester relativement léger et la stabilité repose souvent sur une multiplication des colonnes plutôt que sur la robustesse de chacune d’elles.

Le choix de l’ordre architectural n’est pas uniquement esthétique.
Chaque ordre impose des contraintes structurelles précises qui déterminent la charge que les colonnes peuvent supporter et influencent directement la dimension de l’entablement et de la base.

Après avoir déterminé le type de colonnes capables de supporter les exigences imposées par l’entablement et la toiture, il reste une dernière question fondamentale : sur quoi repose l’ensemble de la structure ?

Car les colonnes, aussi robustes soient-elles, doivent elles-mêmes s’appuyer sur une base capable de répartir correctement les charges vers le sol.

3. Une base solide

Le crépis est une plateforme composée de trois marches. La marche supérieure, appelée Stylobate, supporte directement les colonnes. Sa taille et sa structure doivent être adaptées à l’ordre architectural choisi, car elle doit supporter le poids des colonnes, de l’entablement et de la toiture.

Autrement dit, le dimensionnement de la base dépend du type de colonnes et de la charge qu’elles doivent porter.

💬 Oui..! Mais l'architecture logicielle dans tout ça ?

Vous n'avez pas cliqué pour suivre un cours d’architecture grecque.
Pourtant, cette analogie permet de comprendre beaucoup plus clairement ce qu’est réellement l’architecture d’un système.

🏛️ Traduire le temple en architecture logicielle

Maintenant que nous avons compris comment est construit un temple grec,
revenons à notre sujet initial : l’architecture d’un système logiciel.

Dans cette analogie :

- le toit représente les exigences métiers visibles
- les piliers représentent les capacités structurelles du système
- la base représente la structure technique sur laquelle tout repose

1. Le toit : les besoins métiers

(Exigences fonctionnelles - EF)

Dans un temple grec, le toit est la partie la plus visible. C'est ce que les citoyens voient de loin lorsqu'ils arrivent sur l'agora. C'est là que l'on représente des scènes, des symboles ou des récits qui racontent ce que présente le temple.

Autrement dit : le toit ne sert pas seulement à couvrir le bâtiment. Il porte une histoire.

Dans un système logiciel, c'est exactement le rôle des besoins métiers. Ils expriment la vision du produit que l'on veut construire, racontent ce que le système doit permettre aux utilisateurs.

C'est le porteur de projet, le Product Owner, ou le métier qui pose cette vision simple. Pas de jargon technique, juste des phrases que tout le monde comprend :

• Commander en 3 clics maximum

• Payer sans jamais stresser sur la sécurité

• Suivre ma commande heure par heure  

• Service dispo 24/7, même à Noël

• Ajouter 100 produits sans couper le site

Cest éléments sont visibles par tous : utilisateurs, les équipes métiers, sponsors et dirigeants. Comme le fronton d'un temple, ils exposent la promesse du système au monde.

Mais pour que cette promesse tienne dans le temps, il faut que quelque chose la soutienne. Et c'est là qu'interviennent les piliers de l'architecture.

2. Les piliers

(Ce qui permet au système de tenir)

Dans le temple grec, le toit ne repose pas directement sur le sol. Il repose sur des colonnes massives qui porte toute la structure. Sans ces piliers, le temple s'effondre.

Dans un système logiciel, ces piliers correspondent aux fondations de l'architecture. On peut les regrouper en trois grandes catégories :

• les caractéristiques d'architectures (ENF)

• les décisions architecturales

• les principes de conception

Ces éléments sont étroitement liés, les caractéristiques d'architecture agissent comme des drivers, ce sont elles qui orientent les choix techniques. Ces drivers vont ensuite conduire à :

• des décisions architecturales ( ce que l'on choisit d'imposer dans le système)

• des principes de conception ( les lignes directrices qui guident les équipes)

Les qualités attendues du système influencent la manière dont il sera construit.

Voyons maintenant ces piliers plus en détail.

Premier pilier : les caractéristiques d’architecture (ENF)

aussi appelées exigences non fonctionnelles, décrivent les qualités que le système doit garantir. Elles répondent à la question : « Comment le système doit se comporter ?» Pas « quoi faire », mais « comment bien le faire » .

Par exemple

• Disponibilité : Service accessible 24/7, même à Noël minuit

• Performance : Commande validée en < 2 secondes

• Sécurité : Paiement impossible à pirater

• Scalabilité : Supporte 10x trafic Black Friday sans broncher

• Résilience : Une panne = zéro interruption client

• Maintenabilité / Évolutivité : ajouter un PSP (Payment Service Provider) sans devoir tout casser.

Ces qualités ne sont pas toujours visibles directement par les utilisateurs. Mais elles déterminent la solidité du système.

Un site peut promettre

« commander en 3 clics »

Mais si le système devient inutilisable dès qu'il y a trop de trafic, la promesse ne tient plus.

Toutes les qualités ne sont pas prioritaires dans tous les systèmes. L'architecture consiste justement à identifier celles qui comptent vraiment.

Prenons l'exemple d'un site marchand, l'equipe se concentre uniquement sur les fonctionnalités : Parcourir le catalogue, ajouter au panier et payer en ligne.

Tout fonctionne parfaitement...jusqu'au Black Friday, le trafic explose, les pages deviennent lentes, certaines commandes échouent et le site finit par tomber.

Le problème ne vient pas des fonctionnalités, il vient du fait que certaine ENF n'avaient pas été identifiées comme critiques :

• la scalabilité / élasticité pour absorber les pics de trafic

• la disponibilité pour maintenir le service accessible

• la performance pour garantir la fluidité des parcours clients.

C'est pour cela que les caractéristiques d'architecture sont appelées drivers. Elles pilotent les choix d'architecture.

Par exemple :

• une exigence force de scalabilité pourra pousser vers une architecture microservice

• une exigence forte de résilience pourra orienter vers une architecture event-driven

• une exigence forte de sécurité pourra imposer certaines contraintes techniques

Et une fois ces drivers identifiés, il faut encore les traduire en règles concrètes pour construire le système.

C’est là qu’interviennent les décisions architecturales.

Deuxième pilier : décisions architecturales

SI les caractéristiques d'architecture définissent les qualités que le système doit garantir, les décisions architecturales définissent comment ces qualités vont être concrètement mise en oeuvre. Autrement dit elle traduisent les drivers du système en règles de construction.

Le raisonnement est souvent le suivant :

Qualité recherchée

        ↓

Décision architecturale

        ↓

Règle appliquée dans le système

Exemple 1 : séparation des responsabilités

Dans un style d’architecture en couches (layered), par exemple, on vous a déjà dit :

« Seules les couches métier et services peuvent accéder à la base de données. »

Cette règle empêche ainsi la couche de présentation d’effectuer des appels directs à la base de données. Ce qui permet de préserver la séparation des responsabilités et de faciliter l'évolution du système. Elle protège donc plusieurs qualités du système, notamment la maintenabilité, la cohérence métier et la sécurité, en centralisant l’accès aux données dans la couche métier.

Exemple 2 : interopérabilité et simplicité d’exploitation

On peut trouver aussi des règles concernant les choix des technologies.

L’architecte peut décider de la règle suivant :

Toutes les API doivent être développées en utilisant le style REST plutôt que GraphQL

Cette règle peut répondre à plusieurs qualités d’architecture, comme l’interopérabilité, la simplicité d’exploitation ou la prévisibilité des performances.

Exemple 3 : sécurité et conformité

L'architecte peut par exemple imposer la règle suivante :

Aucune donnée de carte bancaire ne doit être stockée dans le système. Les paiements doivent être délégués à un PSP (Payment Service Provider).

Cette règle évite au système de manipuler directement des données hautement sensibles.

Les informations de paiement sont traitées par un prestataire spécialisé (Stripe, Paypal, etc.) qui fournit un token de paiement utilisé par l’application.

Elle protège ainsi plusieurs qualités du système, notamment la sécurité, la conformité réglementaire et la réduction du risque opérationnel, en externalisant la gestion des données de paiement vers une infrastructure certifiée PCI DSS.

Exemple 4 : scalabilité

L’architecte peut également imposer la règle suivante :

Tout service critique doit être stateless afin de pouvoir être répliqué horizontalement.

Cette règle permet d’ajouter facilement de nouvelles instances du service lorsque le trafic augmente.

Elle protège ainsi plusieurs qualités du système, notamment la scalabilité et la capacité à absorber les pics de charge, en permettant au système de répartir le trafic sur plusieurs instances.

Exemple 5 : disponibilité

Enfin, certaines décisions visent à garantir la continuité du service.

L’architecte peut par exemple imposer la règle suivante :

Tout composant critique doit être déployé avec au moins deux instances dans des zones différentes.

Cette règle évite qu’une panne isolée rende le service indisponible.

Elle protège ainsi plusieurs qualités du système, notamment la disponibilité et la résilience, en réduisant l’impact des défaillances d’infrastructure.

Contraintes organisationnelles

Mais dans la réalité, l’architecte ne construit pas sur un terrain totalement libre.

À ce stade, il peut être tentant de vouloir optimiser, moderniser ou introduire de nouvelles technologies pour répondre au mieux aux qualités recherchées.

Cependant, certaines décisions ne peuvent tout simplement pas être mises en œuvre.

Pourquoi ?

Parce que l’architecture doit aussi composer avec les contraintes de l’organisation :

• standards techniques

• politiques de sécurité

• exigences de gouvernance

• contraintes d’exploitation

Autrement dit, même si une solution semble techniquement pertinente, elle peut être incompatible avec l’environnement de l’entreprise.

Le plus souvent, ces contraintes prennent la forme de standards techniques imposés par l’organisation.

Dans certains cas particuliers, ces règles peuvent être contournées grâce à un mécanisme de dérogation d’architecture (Architecture Waiver). La demande est alors étudiée par un Architecture Review Board (ARB) (une comité de révision d'architecture) ou un architecte en chef.

Ce comité peut :

• approuver la demande

• la refuser

• demander des modifications

• ou accorder une dérogation contrôlée

Dans les grandes organisations, ce processus permet de maintenir la cohérence globale du système d’information, tout en laissant une certaine marge de manœuvre aux projets.

Les décisions architecturales définissent donc les règles de construction du système. Mais une architecture ne se limite pas à des règles strictes.

Pour guider les équipes dans les choix quotidiens qui ne peuvent pas tous être formalisés par des règles, on s’appuie sur un troisième pilier : les principes de conception.

Troisième pilier : principes de conception

Lorsque l’on parle d’architecture logicielle sur LinkedIn, ce sont souvent ces sujets qui reviennent le plus : SOLID, Clean Architecture, Domain Driven Design, découplage, event-driven…

Ces concepts sont largement discutés et parfois présentés comme des règles absolues de l’architecture. Mais en réalité, ils appartiennent à une catégorie différente : les principes de conception

Si les décisions architecturales définissent les règles de construction du système,
les principes de conception servent plutôt de lignes directrices pour guider les équipes de développement. La différence est simple :

• Une décision architecturale impose une règle claire dans le système.

• Un principe de conception oriente les choix lorsque toutes les situations ne peuvent pas être couvertes par une règle.

Prenons un exemple issu des décisions vues précédemment. Nous avons établi la règle suivante :

Toutes les API doivent être développées en utilisant le style REST.

Cette règle garantit l’interopérabilité et la simplicité d’exploitation. Mais elle ne dit rien sur la manière dont les services doivent communiquer entre eux. C’est là qu’intervient un principe de conception.

Par exemple :

Privilégier la communication asynchrone entre services lorsque cela est possible.

Ce principe vise à améliorer la résilience et la scalabilité du système. Cependant, contrairement à une décision architecturale, ce principe n’est pas une obligation.

Dans certains cas, une communication REST ou gRPC pourra être plus adaptée.

On peut prendre un autre exemple lié à la règle suivante :

Les paiements doivent être délégués à un PSP.

Cette décision protège la sécurité et la conformité du système. Mais elle ne dit pas comment organiser le code du système pour garder cette sécurité dans le temps.

C’est ici que les principes de conception prennent le relais.

Par exemple :

Les dépendances doivent toujours pointer vers le domaine métier.

Ce principe, que l’on retrouve dans Clean Architecture, permet d’éviter que des détails techniques (comme un PSP, une base de données ou un framework) contaminent la logique métier.

Les principes de conception servent donc à guider les développeurs dans leurs choix quotidiens, là où les décisions architecturales ne peuvent pas couvrir tous les cas possibles.

Ils encouragent certaines pratiques, sans imposer de règles rigides. Et dans la métaphore du temple :

• les besoins métiers sont le toit

• les caractéristiques d’architecture définissent les qualités des piliers

• les décisions architecturales fixent les règles de construction

et les principes de conception sont le savoir-faire des bâtisseurs, ce qui permet au système de rester solide même lorsque les situations évoluent.

3. La base : la structure technique

Dans un temple grec, les colonnes reposent sur le stylobate, la marche supérieure du crépis. Cette base ne porte pas seulement les colonnes : elle répartit les charges vers le sol et garantit la stabilité de l’ensemble.

Dans un système logiciel, cette base correspond à la structure technique du système. C’est elle qui définit comment les composants sont organisés et interagissent entre eux.

Mais contrairement à ce que l’on pense souvent, cette structure n’est pas choisie en premier. Elle est généralement la conséquence logique de tout ce qui précède.

Prenons un exemple simple. Supposons que les caractéristiques d’architecture du système soient les suivantes :

Forte scalabilité | haute disponibilité | résilience face aux pannes

Ces qualités deviennent alors des drivers du système. Pour y répondre, l’architecte peut prendre certaines décisions architecturales, par exemple :

• les services doivent être stateless

• les composants critiques doivent être répliqués

• les communications doivent être découplées

Ces décisions se traduisent ensuite en règles concrètes dans le système :

• les sessions ne sont jamais stockées en mémoire locale

• les services peuvent être répliqués horizontalement

• les traitements critiques passent par des mécanismes asynchrones

Les principes de conception viennent ensuite guider les développeurs dans la mise en œuvre :

• Privilégier le découplage
  (SOLID – Dependency Inversion / Clean Architecture / Ports & Adapters)
  Le domaine métier ne doit pas dépendre directement des détails techniques (framework, base de données, UI), mais d’interfaces. Le cœur métier définit les contrats, et les implémentations techniques viennent s’y brancher autour.

• Favoriser l’autonomie des services
  (DDD / Microservices / Bounded Context / Event-Driven)
  Chaque service possède son propre modèle métier et peut évoluer indépendamment. Idéalement, il dispose de sa propre base de données et communique avec les autres services via des événements plutôt que des appels en cascade.

• Limiter les dépendances entre composants
  (SOLID – Single Responsibility & Interface Segregation / Clean Architecture / Hexagonal)
  Les composants doivent rester petits, cohérents et bien isolés. Des interfaces simples et un faible couplage facilitent l’évolution du système, les tests et le remplacement de certaines parties sans effet domino.

Et progressivement, une structure technique cohérente émerge.

Dans ce cas précis, cette structure pourra naturellement conduire vers une architecture :

• microservices

• architecture événementielle

• ou modular monolith fortement découplé

Conclusion : l’architecture est un équilibre

Quand on demande :

« Quelle est l’architecture de votre système ? »

la réponse est souvent :

« Microservices »,
« Architecture en couches »,
« Clean Architecture ».

Mais ces réponses ne décrivent en réalité que la structure technique du système : la base.

C’est un peu comme dire d’un temple grec :

« Il est construit en marbre ».

C’est vrai… mais cela ne dit rien de son architecture.

L’architecture d’un système ressemble beaucoup plus à un temple grec :

• un toit, qui représente les besoins métiers que le système doit satisfaire

• des piliers, qui garantissent les capacités structurelles nécessaires pour supporter ces besoins

• une base, qui correspond à la structure technique sur laquelle tout repose

Sans exigences métiers claires, il n’y a rien à construire.
Sans piliers solides, le système ne tient pas.
Et sans base adaptée, l’ensemble devient instable.

L’architecture logicielle consiste donc à concevoir cet équilibre :

• identifier les qualités essentielles du système

• prendre les bonnes décisions architecturales

• définir des principes de conception cohérents

• et construire une structure technique capable de supporter l’ensemble

En d’autres termes :

l’architecture n’est pas seulement une question de technologies.

C’est l’art de faire tenir un système.

✍️ Tarik Moussaoui
Architecte logiciel

J’écris sur l’architecture logicielle, les décisions techniques et la conception de systèmes robustes.

→ https://astroip.fr