La clean architecture est une façon d'organiser le code d'une application pour placer les règles de votre activité au centre et tout ce qui est technique autour. La base de données, le framework web, le prestataire de paiement et le service d'emails sont traités comme des détails branchés depuis l'extérieur. Le cœur de l'application ignore leur existence.

Le sujet concerne tous ceux qui financent un logiciel sur mesure censé durer plusieurs années : une marque qui commande une boutique personnalisée, un fondateur qui construit un SaaS, une agence qui maintient l'outil d'un client. Au quotidien, c'est l'affaire des développeurs. Mais les conséquences arrivent sur vos factures. C'est elle qui décide si changer de prestataire de paiement prend deux jours ou deux mois.

Qu'est-ce que la clean architecture ?

La clean architecture est une manière de structurer une application en couches concentriques, popularisée par l'ingénieur logiciel Robert C. Martin. Son principe central est la règle de dépendance : le code d'une couche intérieure ne fait jamais référence au code d'une couche extérieure. Les dépendances pointent toujours vers l'intérieur, vers les règles métier.

On décrit généralement les couches ainsi, du centre vers l'extérieur :

  • Les entités : les notions et règles fondamentales du métier. Une commande, un produit, une remise, et la règle selon laquelle une remise ne peut pas rendre un prix négatif.
  • Les cas d'usage : les actions que réalise l'application. « Passer une commande », « rembourser une commande », « appliquer un code promo ». Ils orchestrent les entités et décrivent ce qui se passe, étape par étape.
  • Les adaptateurs : des traducteurs entre les cas d'usage et le monde extérieur. Ils transforment une requête web en appel de cas d'usage, ou une commande en ligne de base de données.
  • Les frameworks et pilotes : les outils concrets. La base de données, le framework web, la bibliothèque du prestataire de paiement, le service d'emails.

Quand un cas d'usage doit enregistrer une commande ou débiter une carte, il n'appelle ni la base de données ni le prestataire directement. Il demande « quelque chose qui sait enregistrer une commande » ou « encaisser un paiement », décrit sous forme d'interface. Une couche extérieure fournit l'implémentation réelle. C'est cette inversion qui garde le cœur indépendant.

La clean architecture est proche de deux idées plus anciennes, l'architecture hexagonale (dite aussi ports et adaptateurs) et l'architecture en oignon. Même esprit, dessins différents. Ce n'est pas un mode de déploiement : une clean architecture peut vivre dans un seul monolithe comme dans chacun de nombreux services. C'est une réponse parmi d'autres dans le champ plus large de l'architecture logicielle, centrée sur l'intérieur d'une application.

Pourquoi c'est important

Le bénéfice de la clean architecture, c'est de pouvoir changer à moindre coût là où vous ne l'aviez pas prévu. Le prix, c'est davantage de structure au départ.

Imaginons une marque de sacs artisanaux, 600 commandes par mois à 110 € en moyenne. Sa boutique sur mesure, développée pour 14 000 €, appelle le prestataire de paiement depuis 40 endroits du code : le checkout, les remboursements, l'administration, le générateur de factures. Deux ans plus tard, un prestataire moins cher ferait gagner 0,4 point de frais. Sur 792 000 € de ventes annuelles, cela représente environ 3 170 € par an.

Le développeur estime la migration à 20 jours, soit près de 9 000 €, car il faut retrouver, réécrire et tester les 40 endroits. Le retour sur investissement prend presque trois ans, alors la marque garde le prestataire le plus cher.

La même boutique construite en clean architecture aurait un seul adaptateur « paiements » derrière une seule interface. Changer revient à écrire un nouvel adaptateur, peut-être 4 jours ou 1 800 €, sans toucher aux cas d'usage. Le retour tombe à environ sept mois. L'architecture n'a rendu la boutique ni plus rapide ni plus jolie. Elle a gardé une décision commerciale ouverte.

Comment ça marche

Concrètement, une équipe applique la clean architecture à travers quelques habitudes :

  • Modéliser le métier d'abord. Écrire les notions centrales, commande, produit, stock, client, avec leurs règles, sans importer aucun framework ni outil de base de données.
  • Un cas d'usage par action. « Passer commande » vérifie le stock, calcule les totaux, réserve les articles et demande le paiement. Il se lit comme la description du processus.
  • Définir des ports. Pour chaque besoin extérieur, enregistrer des données, encaisser, envoyer un email, déclarer une petite interface qui dit ce qu'il faut, pas comment.
  • Construire des adaptateurs. Implémenter chaque port avec un outil réel : un adaptateur base de données, un adaptateur Stripe, un adaptateur email. Tout le code propre à l'outil reste là.
  • Tout brancher en bordure. Un seul point de démarrage relie chaque port à son adaptateur. Changer d'outil revient à modifier ce branchement et un adaptateur.
  • Tester le cœur seul. Comme le cœur n'a besoin ni de base de données ni de réseau, ses règles se testent en quelques secondes avec de faux adaptateurs.

Repères et exemples

La clean architecture a un coût, et il vaut mieux savoir quand il se justifie.

  • Une landing page ou un petit site vitrine : inutile. Il n'y a presque aucune règle métier à protéger.
  • Une boutique sur mesure ou un outil interne prévu pour 3 ans ou plus : une version légère vaut généralement le coup. Séparer les règles métier de la base de données et isoler chaque service externe dans un adaptateur.
  • Un produit SaaS aux règles complexes (tarification, droits d'accès, facturation) : fortement recommandé. Les règles changent souvent et doivent être testées à fond.

À titre indicatif, les équipes estiment que cette structure ajoute 10 à 25 % au temps de développement initial. Sur un projet à 12 000 €, cela fait 1 200 à 3 000 €. En échange, les tests du cœur métier tournent en secondes plutôt qu'en minutes, et remplacer un service externe touche en général un dossier au lieu de tout le code. Un bon indicateur : si un développeur sait dire en une phrase où vivent les règles de remise, la structure fait son travail.

Erreurs fréquentes

  • Le formalisme sans raison. Créer quatre couches et des dizaines de fichiers pour une fonctionnalité qui enregistre un formulaire ralentit tout. Adaptez la profondeur à la logique métier réelle.
  • Laisser les outils entrer dans le cœur. Quand des annotations de base de données ou des types du framework s'invitent dans les entités, l'indépendance disparaît, même si les dossiers ont l'air bien rangés.
  • Un cœur vide. Si les entités ne sont que des conteneurs de données et que toute la logique se cache dans les adaptateurs, vous avez les couches sans le bénéfice.
  • Tout abstraire. Envelopper des outils qui ne changeront jamais ajoute des détours et une dette technique supplémentaire. Isolez ce qui risque de changer ou ce qui est difficile à tester.
  • Prendre le schéma pour une loi. Les cercles sont un guide. Une équipe qui débat des jours pour savoir dans quel anneau ranger un fichier a perdu de vue l'objectif.

Bonnes pratiques

  • Demandez où vivent les règles. Lors d'un recrutement, demandez au développeur où se trouveront les règles de prix, de stock et de remise. Une réponse claire et unique est bon signe.
  • Isolez d'abord les tiers. Paiement, emails, transport et toute API externe sont les éléments les plus susceptibles de changer. Placez chacun derrière son propre adaptateur.
  • Gardez le cœur sans framework. Les règles métier doivent survivre intactes à une mise à jour du framework.
  • Testez les cas d'usage. Exigez des tests automatisés sur les parcours principaux, passer, payer et rembourser une commande. Ils coûtent peu quand le cœur est isolé.
  • Dosez la rigueur selon le risque. Couches complètes là où les règles sont complexes, code simple ailleurs.
  • Documentez les frontières. Une carte d'une page des couches et des adaptateurs permet à un futur développeur de reprendre le projet sans tout réécrire.

Dans Roctify

La clean architecture concerne les équipes qui écrivent et maintiennent leur propre code. Sur Roctify, vous ne maintenez aucun code. Roctify est un SaaS et une plateforme no-code : il héberge votre boutique, la tient à jour et gère la partie technique, dont le checkout, les paiements par Stripe, PayPal ou paiement à la livraison, et le HTTPS avec un certificat SSL gratuit.

Le principe reste utile pour organiser votre activité. Gardez vos règles au même endroit : prix, stock, variantes, taxes et codes promo vivent dans le catalogue partagé et les réglages de Roctify, et tous les canaux les lisent. Si vous faites développer un logiciel autour de votre boutique, les intégrations au-delà des fonctionnalités incluses se discutent dans le plan Enterprise, et demander au développeur d'isoler cette connexion derrière un seul adaptateur est précisément l'habitude de clean architecture qui vaut son prix.

FAQ

La clean architecture, est-ce la même chose que le clean code ?

Non. Le clean code porte sur des fonctions lisibles, des noms clairs et de petites unités. La clean architecture porte sur l'organisation en couches de toute l'application et sur qui dépend de qui. L'un peut exister sans l'autre, même s'ils vont souvent ensemble.

La clean architecture ralentit-elle le logiciel ?

Pas de façon perceptible pour vos clients. Les couches supplémentaires ont un coût d'exécution négligeable. Le vrai coût, c'est le temps de développement au départ, et parfois une complexité inutile quand l'équipe l'applique plus strictement que le projet ne l'exige.

Dois-je exiger la clean architecture de mon agence ?

Exigez les résultats, pas l'étiquette. Demandez que les règles métier soient testables sans base de données et que chaque service externe soit derrière sa propre interface. Une bonne agence saura ce que cela signifie, quel que soit le nom qu'elle lui donne.