L'architecture hexagonale n'a rien de nouveau : Alistair Cockburn l'a documentée en 2005. Ce qui a changé, c'est ce qui écrit le code aujourd'hui. Sur mes projets offshore au Vietnam, un développeur senior assisté par Claude Code produit trois à quatre fois plus de lignes qu'il y a deux ans, et sans frontière technique claire, cette vitesse construit du couplage à la même cadence qu'elle construit des fonctionnalités.
- 🏗️ Domaine protégé, la logique métier ne dépend d'aucun framework ni base de données.
- ⚠️ IA sans garde-fou, le code généré vite par une IA aggrave le couplage sans frontière claire.
- 🔑 Ports et adaptateurs, chaque entrée-sortie passe par une interface définie par le domaine.
- 🚀 Verdict terrain, imposée à mes équipes offshore, elle rend Claude Code plus fiable.
Je ne défends pas l'architecture hexagonale par goût du purisme académique. Je la défends parce qu'elle est devenue le seul filet qui empêche un code généré rapidement de transformer votre produit en dette technique intraitable en six mois. C'est cette thèse que je développe ici, avec ce que j'observe concrètement chez mes clients et dans mes propres équipes.
L'IA a rendu le code rapide à produire, pas moins dangereux
Un non-ingénieur peut aujourd'hui générer un endpoint API, une requête SQL et un composant React en quelques minutes avec Claude Code ou Cursor. Ce que ces outils ne génèrent pas automatiquement, c'est la frontière entre ce qui appartient à votre métier et ce qui appartient à votre infrastructure.
Sans cette frontière, chaque appel direct à Prisma dans un contrôleur, chaque fetch() planté au milieu d'une fonction métier, s'accumule. Le code fonctionne en démo. Il devient injouable dès que vous voulez changer de base de données, brancher un second frontend, ou simplement écrire un test qui ne dépend pas d'un réseau.
Le vibe coding est utile pour prototyper, dangereux pour construire un produit sans supervision technique. Une étude McKinsey régulièrement citée dans le secteur estime que la dette technique peut absorber jusqu'à 20 à 40 % du budget IT d'une entreprise sur la durée de vie d'un système, selon les travaux de McKinsey Digital. Un code écrit dix fois plus vite sans architecture ne réduit pas ce chiffre : il l'accélère.
Pourquoi le vibe coding aggrave-t-il le couplage que personne ne voit ?
Le couplage ne casse rien le jour où il est écrit. Il casse trois mois plus tard, quand un changement de fournisseur de paiement oblige à toucher quarante fichiers au lieu de deux. Une IA qui génère du code sans contrainte architecturale reproduit le chemin le plus court, pas le chemin le plus sain, parce que c'est ce que le prompt moyen lui demande.
Qu'est-ce que l'architecture hexagonale, concrètement ?
Imaginez votre application comme un hexagone. Au centre, le domaine : les règles métier, les entités, les cas d'usage. Rien dans ce centre ne connaît l'existence de PostgreSQL, de Stripe ou de votre framework front. Autour, des ports, c'est-à-dire des interfaces définies par le domaine lui-même, qui décrivent comment il accepte d'être piloté et comment il attend ses données.
Les adaptateurs viennent ensuite brancher ces ports sur le monde réel : un adaptateur REST pour l'entrée utilisateur, un adaptateur PostgreSQL pour la persistance, un adaptateur Stripe pour le paiement. La chaîne YouTube CodelyTV résume bien la règle de dépendance : l'infrastructure peut connaître le domaine, jamais l'inverse, et le domaine ne connaît que lui-même.
Alex Hyett, sur sa chaîne, rappelle l'origine du terme : Cockburn a remarqué qu'interagir avec une base de données et interagir avec une API externe suit toujours le même schéma. Plutôt que de coder ce lien en dur, on définit un contrat côté domaine, et n'importe quel adaptateur peut le remplir. C'est cette inversion qui rend le cœur de l'application testable sans base de données, sans réseau, sans mock compliqué.
Comment fonctionnent concrètement les ports et les adaptateurs ?
Un port d'entrée expose un cas d'usage : « créer un utilisateur ». Un port de sortie décrit un besoin : « persister un utilisateur ». Le domaine appelle ces interfaces sans savoir ce qui les implémente. Augusto Galego, développeur senior brésilien, illustre ça simplement dans sa vidéo : du point de vue du service métier, écrire dans une base de données ou publier un message dans une file d'attente ne fait aucune différence, seul le contrat compte.
Pourquoi je l'impose maintenant à mes équipes offshore
Transparence : je dirige une ESN offshore au Vietnam, donc j'ai un biais évident sur ce sujet. C'est aussi pour cette raison que j'en connais les limites concrètes, pas seulement les arguments commerciaux qu'on répète en avant-vente.
En mai 2026, une squad de trois développeurs vietnamiens que je supervise a migré un backend Node vers une architecture hexagonale en douze jours, avant de brancher Claude Code sur le domaine isolé pour accélérer l'écriture des cas d'usage suivants. Résultat observé : les suggestions de l'IA restaient à l'intérieur du port qu'on lui donnait à remplir, parce que le contrat l'obligeait à ça. Sans cette frontière, le même outil aurait proposé d'importer directement le client Stripe dans une fonction de calcul de commission, ce qu'un junior aurait accepté sans sourciller.
Je pense qu'un développeur qui utilise Claude Code reste un ingénieur, pas un simple opérateur de prompt, à condition que l'architecture l'empêche de prendre le raccourci le plus rapide. Une équipe senior bien organisée, assistée par l'IA à l'intérieur d'un domaine protégé, produit un code qu'une équipe non structurée ne rattrape pas, même avec deux fois plus d'effectif.
Que se passe-t-il quand l'IA écrit contre un domaine mal isolé ?
L'IA ne refuse jamais une mauvaise idée si le code autour ne l'interdit pas structurellement. Sans port ni adaptateur, elle mélange logique métier et appel réseau dans le même fichier, parce que c'est le pattern le plus fréquent dans son corpus d'entraînement. L'architecture hexagonale ne rend pas l'IA plus intelligente : elle réduit l'espace des erreurs qu'elle peut commettre sans que personne ne le remarque avant la mise en production.
Hexagonale, clean, onion : le débat qui ne se referme jamais
Un thread ouvert sur r/softwarearchitecture, intitulé « Hexagonal vs Clean vs Onion, laquelle est vraiment la plus solide ? », résume bien la confusion ambiante. Un autre développeur, sur ce même forum, pousse la nuance plus loin dans le thread « Layered Architecture != Hexagonale, Onion and Clean Architecture » : pour lui, l'architecture en couches classique est une macro-architecture qui façonne l'organisation des équipes, quand hexagonale, onion et clean décrivent surtout comment structurer l'intérieur de la couche métier.
Je suis d'accord avec ce cadrage. Ce ne sont pas des concurrents interchangeables, ce sont des variations autour d'une même idée : isoler le métier, inverser les dépendances vers ce centre. La chaîne Código Fonte TV rappelle même que le nom « hexagonale » vient uniquement de l'illustration choisie par Cockburn, pas d'un nombre magique de six ports obligatoires.
« L'architecture ne protège pas contre l'IA. Elle protège contre les développeurs, humains ou augmentés, qui utilisent l'IA sans comprendre ce qu'ils construisent. »
Vincent Roye, Août 2026
| Critère | Hexagonale | Clean Architecture | Onion | Architecture en couches |
|---|---|---|---|---|
| Couplage au framework | Très faible | Très faible | Faible | Fort |
| Testabilité du domaine | Élevée sans mock lourd | Élevée | Élevée | Dépend de la couche |
| Courbe d'apprentissage équipe junior | Moyenne | Élevée | Moyenne | Faible |
| Résistance au code IA mal supervisé | Forte, contrat explicite | Forte | Moyenne | Faible |
| Coût de migration depuis un legacy | Progressif, port par port | Élevé, réécriture large | Progressif | Nul, c'est déjà l'existant |
SOURCE : threads r/softwarearchitecture, blog.octo.com · MAJ 08/2026
Faut-il vraiment choisir entre hexagonale, clean et onion ?
Non, et c'est un piège de croire qu'il faut trancher une fois pour toutes. Le blog OCTO, référence française sur le sujet, décrit trois principes suffisants pour démarrer : séparer explicitement l'entrée utilisateur, la logique métier et la sortie technique, faire pointer les dépendances vers cette logique métier, isoler les frontières par des ports et des adaptateurs. Ces trois principes s'appliquent que vous appeliez le résultat hexagonale, clean ou onion.
Les pièges qui transforment l'architecture hexagonale en usine à gaz
Sur un thread r/androiddev, un développeur cherchant un catalogue de patterns résume une frustration réelle : trop d'articles vendent l'architecture hexagonale comme une solution universelle sans jamais dire quand elle coûte plus qu'elle ne rapporte. Il a raison de se méfier.
Sur un CRUD simple, sans logique métier significative, empiler des ports et des adaptateurs pour trois entités ajoute de l'indirection sans bénéfice mesurable. J'ai vu des équipes juniors passer deux semaines à créer des interfaces pour un seul adaptateur concret, ce qui est exactement l'inverse de l'objectif recherché.
La règle que j'applique avec mes équipes est simple : l'architecture hexagonale se justifie dès que la logique métier dépasse la plomberie, ou dès que vous savez déjà que l'infrastructure va changer. Une startup qui doit migrer de Firebase vers un backend maison dans dix-huit mois gagne à isoler son domaine dès le départ. Un script interne jetable n'en a pas besoin.
Le verdict
L'architecture hexagonale n'est pas un standard à cocher pour rassurer un client ou un investisseur. C'est un choix qui détermine si votre code généré par IA reste sous contrôle humain ou s'accumule en dette invisible jusqu'au jour où plus personne ne veut y toucher. Je recommande de l'adopter dès qu'un projet dépasse le prototype et que la logique métier a une vraie valeur à protéger.
Sur les projets que je supervise, ce n'est plus une option esthétique. C'est la condition pour que des développeurs seniors, augmentés par Claude Code, restent plus productifs et plus fiables qu'une équipe deux fois plus nombreuse sans cette discipline. Pour la mise en œuvre pratique côté offshore, j'ai détaillé le sujet dans notre guide complet sur l'architecture hexagonale, et si vous cherchez à comprendre où l'IA remplace vraiment un développeur (et où elle ne le remplace pas), cet article complète directement le propos. Côté mise en œuvre avec les outils IA eux-mêmes, le blog AI First couvre les cas d'usage concrets en entreprise.
Foire aux questions
Qu'est-ce que l'architecture hexagonale en une phrase ?
C'est une manière d'organiser le code qui place la logique métier au centre et qui force toutes les dépendances techniques (base de données, API, frameworks) à passer par des interfaces définies par ce centre, jamais l'inverse. Le domaine ne connaît que lui-même et peut être testé sans aucune infrastructure réelle.
Quelle différence entre architecture hexagonale et Clean Architecture ?
Les deux partagent le même principe d'inversion de dépendances vers le métier. La Clean Architecture, popularisée par Robert C. Martin, ajoute des couches concentriques plus explicites et une terminologie propre (entités, cas d'usage, adaptateurs d'interface). Dans la pratique, les deux se substituent facilement l'une à l'autre sur un projet réel.
L'architecture hexagonale ralentit-elle le développement quand on utilise l'IA ?
Elle ajoute un peu de code au démarrage, notamment les interfaces des ports. Mais une fois le domaine isolé, un assistant comme Claude Code produit des suggestions plus pertinentes parce qu'il travaille dans un contrat clair, avec moins d'ambiguïté sur ce qui appartient au métier et ce qui appartient à l'infrastructure.
Faut-il toujours utiliser une architecture hexagonale ?
Non. Sur un script jetable ou un CRUD sans vraie logique métier, l'indirection ajoutée coûte plus qu'elle ne rapporte. Elle se justifie quand le domaine a une valeur à protéger dans la durée, ou quand vous savez qu'un composant technique (base de données, fournisseur de paiement) changera un jour.
Comment migrer un projet existant vers une architecture hexagonale ?
Progressivement, port par port, jamais en réécriture complète. On commence par isoler un cas d'usage à fort enjeu métier, on définit son port d'entrée et de sortie, on branche l'adaptateur existant derrière cette interface, puis on répète sur le composant suivant sans toucher au reste du système.
Vidéos YouTube
- Hexagonal Architecture: What You Need To Know - Simple Explanation — Alex Hyett
- Learn Hexagonal Architecture in 10 minutes — CodelyTV - Redescubre la programación
- Arquitetura Hexagonal | Explicação de um Dev Sr. — Augusto Galego
- Hexagonal Architecture (Simplified Explanation of Ports & Adapters) // Programmer's Dictionary — Código Fonte TV
Discussions Reddit
- Hexagonal vs Clean vs Onion Architecture — Which Is Truly the Most Solid? — r/softwarearchitecture
- Layered Architecture != Hexagonale, Onion and Clean Architecture — r/softwarearchitecture
- Looking for a pattern catalogue for app architecture — r/androiddev
