Clean architecture

Rédigé par David Brulin, co-fondateur de Quai des Balises

Clean architecture est une approche de conception logicielle qui organise le code en couches concentriques pour isoler la logique métier des détails techniques (base de données, framework, interface). Le cœur applicatif ne dépend d'aucune technologie externe, ce qui rend le système testable, évolutif et durable.

Principes fondamentaux de la clean architecture

Formalisée par Robert C. Martin, la clean architecture repose sur une règle structurante : la règle de dépendance. Les dépendances ne pointent que vers l'intérieur, des couches techniques vers la logique métier, jamais l'inverse. Le domaine métier ignore totalement la façon dont les données sont stockées ou affichées.

Elle s'organise généralement en couches concentriques :

Entités : règles métier essentielles, indépendantes de toute application.
Cas d'usage (use cases) : logique applicative orchestrant les entités pour un besoin précis.
Adaptateurs d'interface : conversion des données entre les cas d'usage et le monde extérieur (controllers, présentateurs, gateways).
Frameworks et pilotes : couche la plus externe (base de données, framework web, services tiers), considérée comme un détail interchangeable.

L'inversion de dépendance (interfaces définies par le métier, implémentées par la couche technique) permet de remplacer une base de données ou un framework sans toucher au cœur applicatif.

Bénéfices et coûts pour un projet sur mesure

La clean architecture vise la durabilité d'un système qui doit évoluer pendant des années : ERP, plateforme métier, logiciel propriétaire. Son intérêt augmente avec la complexité métier et la durée de vie attendue du projet. Sur un développement simple ou jetable, sa rigueur peut représenter un surcoût injustifié.

Critère	Architecture en couches stricte (clean)	Architecture monolithique couplée
Logique métier	Isolée, indépendante du framework	Mêlée au framework et à la base de données
Testabilité	Élevée : le cœur se teste sans infrastructure	Faible : tests dépendants de la base et du framework
Changement de technologie	Localisé à la couche externe	Impacte l'ensemble du code
Coût initial	Plus élevé (abstractions, interfaces)	Plus faible au démarrage
Coût d'évolution à long terme	Maîtrisé	Croissant avec la dette technique

Le compromis se résume ainsi : la clean architecture déplace une partie de l'effort vers le démarrage du projet pour réduire le coût des évolutions futures.

Mise en œuvre concrète

Adopter la clean architecture ne dépend pas d'un langage ou d'un framework particulier : elle s'applique aussi bien en PHP, Java, TypeScript que dans une application mobile. Quelques repères pratiques :

Définir les interfaces côté métier : les contrats (repositories, services externes) appartiennent au domaine, leurs implémentations à la couche technique.
Garder les entités pures : aucune annotation de framework ni dépendance d'ORM dans le cœur métier.
Faire transiter des objets dédiés entre les couches plutôt que d'exposer directement les modèles de base de données.
Mesurer le bon dosage : appliquer la rigueur là où la complexité métier le justifie, sans sur-architecturer les parties triviales.

Cette discipline structure un code dont la valeur, la logique métier, reste protégée des changements technologiques qui surviennent inévitablement sur la durée de vie d'un logiciel.

Questions fréquentes

Les deux partagent le même objectif : isoler la logique métier des détails techniques via l'inversion de dépendance. L'architecture hexagonale (ports et adaptateurs) se concentre sur la séparation entre le cœur et l'extérieur. La clean architecture généralise cette idée en couches concentriques explicites (entités, cas d'usage, adaptateurs, frameworks). En pratique, elles sont très compatibles et souvent combinées.

Non. Son intérêt croît avec la complexité métier et la durée de vie du logiciel. Sur un projet simple, un prototype ou un développement à courte durée de vie, ses abstractions ajoutent un coût initial difficile à rentabiliser. Elle se justifie pleinement sur des ERP, plateformes métier ou logiciels destinés à évoluer pendant des années.

Non, c'est un principe de conception indépendant de la technologie. Elle s'applique en PHP, Java, C#, TypeScript ou sur une application mobile. Justement, l'un de ses objectifs est de traiter le framework et la base de données comme des détails interchangeables situés dans la couche la plus externe.

En isolant la logique métier, elle limite la propagation des changements : remplacer une base de données ou mettre à jour un framework n'affecte que la couche externe. Le cœur applicatif se teste sans infrastructure, ce qui accélère la détection des régressions. Le code reste lisible et modulaire, ce qui réduit le coût des évolutions sur le long terme.

Vous voulez un logiciel testable et évolutif sur le long terme ? L'architecture y est pour beaucoup.

Voir nos logiciels sur mesure

Définitions liées

← Retour au glossaire