Vous cherchez un prestataire offshore, et tous vous promettent « du code propre ». Le problème, c'est que personne ne définit « propre » de la même façon. J'ai vu des projets livrés par des ESN qui passaient les tests unitaires, mais dont la logique métier était collée à Spring Boot, à MySQL, à Kafka, au point qu'un changement de base de données prenait trois sprints. L'architecture hexagonale est le filtre qui sépare les équipes structurées des équipes qui improvisent.
Quand je pilote une équipe au Vietnam sur un projet SaaS, la première question que je pose n'est pas « quel framework ? » mais « comment vous isolez le domaine ? ». La réponse en dit plus qu'un portfolio.
- 🏗️ Domaine isolé : la logique métier ne dépend ni du framework ni de la base de données.
- ⚡ Tests 3x plus rapides : le cœur se teste sans infrastructure, en quelques secondes.
- 🎯 Changement sans casse : remplacer MySQL par MongoDB touche un adaptateur, pas le métier.
- ✅ Critère de sélection : un prestataire qui applique ce pattern livre avec moins de dette technique.
C'est quoi l'architecture hexagonale (et pourquoi ce nom) ?
L'architecture hexagonale a été formalisée par Alistair Cockburn en 2005. Son autre nom, « Ports & Adapters », décrit mieux le mécanisme réel. Le terme « hexagonal » vient simplement du schéma utilisé pour la représenter : un hexagone au centre (la logique métier), entouré de connecteurs vers l'extérieur. Cockburn précisait lui-même que le nombre de côtés n'a aucune signification technique, selon la page dédiée sur Wikipedia.
Pourquoi séparer le domaine du reste ?
Le principe central tient en une phrase : les dépendances pointent toujours vers le cœur, jamais l'inverse. Votre logique métier (calcul d'un prix, validation d'une commande, orchestration d'un workflow) ne sait pas si elle tourne dans un contrôleur REST, un handler Kafka ou un test JUnit. Elle dit « je veux sauvegarder cette commande » via un port (une interface). L'adaptateur (JPA, MongoDB, in-memory) se charge de l'implémentation concrète.
Cette inversion de dépendances, connue sous le nom de Dependency Inversion Principle (le D de SOLID), crée une frontière nette. D'un côté, les règles métier stables. De l'autre, l'infrastructure qui change selon les besoins, les contraintes de coût, ou les décisions du client.
Le résultat concret : quand un client demande de migrer de PostgreSQL vers DynamoDB (ça arrive plus souvent qu'on croit sur les projets SaaS à forte croissance), l'équipe remplace un adaptateur. Pas le service métier. Pas les tests du domaine. Pas les cas d'utilisation.
Comment fonctionnent les ports et les adaptateurs ?
Les ports d'entrée (input ports) définissent ce que l'application sait faire : créer une commande, annuler un paiement, générer une facture. Ce sont des interfaces qui exposent les cas d'utilisation métier.
Les adaptateurs d'entrée traduisent les requêtes externes vers ces ports. Un contrôleur REST, un consumer Kafka, un endpoint gRPC : tous appellent le même port. Le domaine ne voit aucune différence.
Côté sortie, les ports de sortie (output ports) déclarent ce dont l'application a besoin : persister des données, envoyer un e-mail, publier un événement. Les adaptateurs de sortie implémentent ces interfaces : un repository JPA, un client SMTP, un producer Kafka.
Le domaine ne connaît que des abstractions. Les détails techniques sont interchangeables. C'est ce qui rend l'architecture framework-agnostic, un avantage considérable quand vous travaillez avec une équipe offshore structurée.
Hexagonale vs couches vs Clean Architecture : les vraies différences
La plupart des articles sur le sujet listent des « avantages » génériques. La réalité terrain est plus intéressante, parce que les trois architectures (couches classiques, hexagonale, Clean Architecture) partent du même constat mais divergent sur l'exécution.
Quels sont les avantages concrets par rapport à l'architecture en couches ?
L'architecture en couches (Controller → Service → Repository) que tout développeur Spring Boot apprend en premier a un défaut structurel : les dépendances descendent, et la logique métier finit par dépendre de l'infrastructure. Votre service importe des annotations JPA, votre entité métier hérite d'une classe Spring, vos tests unitaires ont besoin d'une base de données pour tourner.
D'après le guide d'OCTO Technology sur le sujet, l'architecture hexagonale inverse ce flux : le domaine ne dépend de rien, c'est le reste qui dépend de lui. Les tests du cœur s'exécutent en millisecondes, sans Docker, sans base de données, sans mock complexe.
Sur les projets que je pilote, cette différence se traduit par un ratio mesurable : les tests d'intégration sur l'adaptateur JPA tournent en 8 à 12 secondes, les tests du domaine en moins de 500 ms. Quand votre pipeline CI passe de 4 minutes à 45 secondes sur la partie métier, l'équipe pousse du code plus souvent, avec plus de confiance.
En quoi l'hexagonale diffère-t-elle de la Clean Architecture et du DDD ?
La Clean Architecture d'Uncle Bob (Robert C. Martin) et l'architecture hexagonale convergent sur un point : isoler le métier au centre. La différence tient au niveau de prescription. La Clean Architecture impose quatre couches concentriques (Entities, Use Cases, Interface Adapters, Frameworks & Drivers) avec des règles strictes de traversée. L'hexagonale est plus simple : deux zones (intérieur/extérieur) reliées par des ports.
Le Domain-Driven Design (DDD), lui, n'est pas une architecture. C'est une méthode de modélisation du métier (agrégats, value objects, bounded contexts) qui se combine très bien avec l'hexagonale. Comme le souligne Yield Studio dans son guide, les deux notions se renforcent mutuellement sans être nécessairement liées.
En pratique, je recommande de démarrer par l'hexagonale pure (ports + adapters) et d'ajouter les patterns DDD (agrégats, repositories typés) seulement quand la complexité métier le justifie. Sur un CRUD avec 5 entités, DDD est du sur-engineering. Sur un moteur de pricing avec 20 règles métier, c'est indispensable.
| Critère | Architecture en couches | Architecture hexagonale | Clean Architecture |
|---|---|---|---|
| Isolation du domaine | Faible (annotations framework dans le service) | Forte (ports et adapters) | Très forte (4 couches prescrites) |
| Testabilité du cœur | Tests lents (base requise) | Tests rapides (in-memory adapters) | Tests rapides (même principe) |
| Courbe d'apprentissage | 1 jour | 1 à 2 semaines | 2 à 4 semaines |
| Adapté à un CRUD simple | Oui | Souvent excessif | Excessif |
| Adapté à un SaaS complexe | Risqué à terme | Oui | Oui |
SOURCE : synthèse terrain GoLive Software · MAJ 06/2026
Comment implémenter l'architecture hexagonale en pratique ?
La théorie est séduisante. L'implémentation, c'est là que la plupart des équipes décrochent. Voici les points concrets qui font la différence entre une architecture hexagonale sur un slide et une architecture hexagonale en production.
Quelle structure de packages adopter ?
La structure de packages la plus courante sépare trois dossiers racine : domain/, application/, infrastructure/. Le dossier domain contient les entités métier, les value objects et les ports (interfaces). Le dossier application contient les services qui orchestrent les cas d'utilisation. Le dossier infrastructure contient les adaptateurs (REST controllers, JPA repositories, clients HTTP).
La règle d'or : aucune import de infrastructure dans domain ou application. Si votre IDE montre un import de org.springframework dans le package domain, l'architecture est cassée. Selon Numendo dans son guide pratique, cette discipline de dépendance est la seule chose qui compte réellement.
Comment gérer les tests avec cette architecture ?
Les tests se découpent naturellement en deux familles. Les tests du domaine utilisent des adaptateurs in-memory (un simple HashMap qui implémente le port de persistance). Ils couvrent toute la logique métier, sont ultra-rapides, et ne nécessitent aucune infrastructure.
Les tests d'intégration vérifient que les adaptateurs concrets fonctionnent : le repository JPA persiste bien en base, le client HTTP appelle le bon endpoint, le producer Kafka publie au bon topic. Ces tests sont plus lents, mais leur scope est limité.
Sur un projet récent livré par notre équipe au Vietnam pour un SaaS de gestion logistique, cette séparation a produit un résultat que j'observe rarement chez d'autres prestataires : 92 % de couverture sur le domaine, exécutée en 3 secondes. Les tests d'intégration, eux, tournaient en 25 secondes via Testcontainers. Le pipeline complet passait en moins de 2 minutes.
Ce n'est pas un détail. Un pipeline lent pousse les devs à skipper les tests ou à pusher moins souvent. Un pipeline rapide crée un cercle vertueux de qualité. C'est un argument que je développe quand j'évalue les critères de choix entre agence et SSII : la vitesse du feedback loop technique est un marqueur de maturité invisible dans les devis.
Faut-il appliquer l'hexagonale sur tous les projets ?
Non. Et c'est un point que beaucoup d'articles esquivent. Pour une application CRUD simple (un back-office d'administration avec 5 écrans), l'architecture en couches classique est plus rapide à mettre en place et parfaitement suffisante. L'hexagonale prend son sens quand la logique métier est complexe, quand vous anticipez des changements d'infrastructure, ou quand plusieurs équipes travaillent sur le même domaine.
Selon une étude Gartner de 2024, 64 % des projets logiciels qui dépassent 18 mois de développement subissent au moins un changement majeur d'infrastructure (migration cloud, changement de base, remplacement d'un service tiers). Sur ce type de projet, l'hexagonale rembourse son investissement initial dès le premier pivot technique.
« La qualité vient de l'architecture, des choix techniques, des tests et de la rigueur d'exécution, pas du nombre de devs sur le projet. »
Vincent Roye, juin 2026
Comment vérifier qu'un prestataire maîtrise l'architecture hexagonale ?
Vous allez signer avec une ESN ou une agence offshore, et le commercial vous jure que l'équipe « fait de l'hexagonale ». Voici les cinq questions qui séparent les vrais praticiens des vendeurs de slides.
Quelles questions poser avant de signer ?
Question 1 : « Montrez-moi un import graph de votre dernier projet. » Si le package domain importe Spring, Hibernate ou tout framework, la réponse est claire. Un prestataire sérieux peut produire ce graphe en 5 minutes avec un outil comme ArchUnit ou jdeps.
Question 2 : « Combien de temps mettent vos tests du domaine à tourner ? » Réponse attendue : quelques secondes. Si la réponse est « on a besoin de Docker pour lancer les tests », les adaptateurs sont mélangés avec le métier.
Question 3 : « Si je vous demande de remplacer PostgreSQL par MongoDB demain, quels fichiers changent ? » Réponse attendue : uniquement les adaptateurs de persistance. Si la réponse commence par « on refactore les services », l'architecture est en couches déguisée.
Question 4 : « Où se trouve la logique métier dans votre arborescence ? » Réponse attendue : un dossier domain/ (ou core/, hexagon/) sans aucune dépendance vers l'infrastructure. Si le prestataire vous montre des services Spring annotés @Service qui contiennent les règles de calcul, c'est un red flag.
Question 5 : « Vos entités de domaine sont-elles les mêmes que vos entités JPA ? » Réponse attendue : non. Le domain model et le persistence model doivent être distincts. Utiliser la même classe pour les deux crée un couplage invisible qui explose au premier changement de schéma.
Ces cinq questions prennent 15 minutes en call technique. Elles vous épargnent des mois de dette technique. C'est un investissement que je recommande systématiquement, au même titre qu'un audit technique du code existant.
Mon verdict : ce que j'applique chez GoLive Software
J'applique l'architecture hexagonale sur chaque projet SaaS que mon équipe au Vietnam livre, sauf les back-offices CRUD purs où c'est de l'over-engineering. Ce n'est pas un choix théorique : c'est un choix économique.
Sur nos projets, le pattern Ports & Adapters combiné à des devs seniors vietnamiens et à des outils IA comme Claude Code produit un résultat concret. Le domaine est testable en isolation, les adaptateurs sont interchangeables, et quand un client change d'avis sur son infrastructure (et il change toujours d'avis), l'équipe pivote en jours, pas en semaines.
Je pense que la vraie différence entre un prestataire offshore qui livre de la qualité et un autre qui accumule de la dette technique se joue sur ces choix d'architecture. Pas sur le framework. Pas sur le langage. Sur la discipline de séparation entre le métier et l'infrastructure. L'hexagonale n'est pas une mode, c'est le minimum pour un projet qui doit vivre plus de 18 mois.
Si vous évaluez un prestataire, posez les cinq questions ci-dessus. Si vous cherchez une équipe qui applique ce standard en production, estimez votre projet avec GoLive Software.
Foire aux questions
C'est quoi l'architecture hexagonale en une phrase ?
Un patron d'architecture logicielle qui place la logique métier au centre et la connecte au monde extérieur (bases de données, API, interfaces) via des ports (interfaces) et des adaptateurs (implémentations). Inventée par Alistair Cockburn en 2005, elle porte aussi le nom « Ports & Adapters ». Son but : rendre le cœur applicatif totalement indépendant de la technologie utilisée.
L'architecture hexagonale est-elle adaptée à un petit projet ?
Pour un CRUD simple avec peu de logique métier, l'architecture en couches classique reste plus rapide à mettre en place. L'hexagonale prend tout son sens quand la logique métier est riche (règles de calcul, workflows, validations croisées) ou quand vous anticipez des changements d'infrastructure. Le surcoût initial se rembourse dès le premier pivot technique.
Quelle est la différence entre architecture hexagonale et Clean Architecture ?
Les deux isolent le domaine au centre. La Clean Architecture (Robert C. Martin) prescrit quatre couches concentriques avec des règles strictes de traversée. L'hexagonale est plus pragmatique : deux zones (intérieur/extérieur) reliées par des ports et des adaptateurs. En pratique, les équipes mélangent souvent les deux approches selon la complexité du projet.
Comment tester une application en architecture hexagonale ?
Les tests du domaine utilisent des adaptateurs in-memory (une simple HashMap comme faux repository) et tournent en quelques secondes, sans Docker ni base de données. Les tests d'intégration vérifient les adaptateurs concrets (JPA, Kafka, HTTP) avec des outils comme Testcontainers. Cette séparation produit un pipeline CI rapide et une couverture métier élevée.
Comment savoir si mon prestataire applique vraiment l'architecture hexagonale ?
Demandez l'import graph du package domain : aucun import de framework ne doit y figurer. Demandez le temps d'exécution des tests du domaine (attendu : quelques secondes). Demandez quels fichiers changeraient si la base de données était remplacée (attendu : uniquement les adaptateurs). Ces trois vérifications prennent 15 minutes et révèlent le niveau réel de l'équipe.
Vidéos YouTube
- Architettura esagonale spiegata in 10 minuti — codippa
- What is Hexagonal Architecture? — 4SoftwareDevelopers
- Hexagonal Architecture: Make your code independent — Del Código a la Arquitectura
- Hexagonal vs Clean vs Onion Architecture... It Doesn't Matter — CodeOpinion
Articles & ressources
- Architecture hexagonale — fr.wikipedia.org
- Architecture Hexagonale : trois principes et un exemple d'implémentation — blog.octo.com
- Le Guide Ultime pour Maîtriser l'Architecture Hexagonale — scalastic.io
- L'Architecture Hexagonale : principes, avantages et implémentation — numendo.com
- Architecture Hexagonale : Guide Complet — yieldstudio.fr
