Architecture hexagonale et agents IA : une affinité naturelle

Quand les agents IA rencontrent l'architecture hexagonale

L'IA agentique bouscule nos certitudes. Là où les copilotes d'hier se contentaient de suggérer une ligne de code ou de compléter une fonction, les agents d'aujourd'hui agissent : ils orchestrent des workflows complexes, appellent des APIs tierces, manipulent des fichiers, déclenchent des pipelines. Claude Code, lancé en février 2025, a matérialisé cette rupture mieux que n'importe quel discours théorique — en passant du rôle d'assistant à celui d'acteur autonome dans la chaîne de développement.

Cette évolution pose une question architecturale fondamentale que l'on entend régulièrement dans les missions de nos consultants SFEIR : comment concevoir des systèmes qui accueillent ces agents sans se transformer en boîtes noires incontrôlables ? La réponse, nous en sommes convaincus, passe en grande partie par un principe vieux de deux décennies : l'architecture hexagonale, aussi connue sous le nom de Ports & Adapters.

Ce n'est pas un hasard. L'architecture hexagonale a toujours été pensée pour isoler la logique métier du monde extérieur — qu'il s'agisse d'une base de données, d'une interface utilisateur ou, demain, d'un réseau d'agents autonomes. En 2026, cette affinité structurelle devient une nécessité opérationnelle.

Rappel des fondamentaux : l'hexagone comme bouclier

Proposée par Alistair Cockburn au milieu des années 2000, l'architecture hexagonale repose sur une idée simple mais puissante : le domaine métier ne doit jamais dépendre de son environnement technique. La logique applicative — les règles, les invariants, les processus — est encapsulée au centre de l'hexagone. Tout ce qui est externe (bases de données, messageries, APIs, interfaces graphiques) communique avec ce noyau via des ports bien définis, implémentés par des adapters interchangeables.

Concrètement, cela signifie que votre logique de validation d'une commande, de calcul d'un score de risque ou de traitement d'un dossier client est totalement indépendante du fait qu'elle soit appelée par une API REST, un message Kafka, un batch nocturne… ou un agent IA.

• Ports entrants (driving ports) : interfaces exposées par le domaine pour recevoir des instructions — use cases, commandes, requêtes.
• Ports sortants (driven ports) : interfaces définies par le domaine pour interagir avec l'extérieur — persistence, notification, appel de services tiers.
• Adapters : implémentations concrètes des ports, facilement substituables, testables en isolation.

Ce modèle a prouvé sa valeur dans des contextes de microservices, de migrations cloud et de refactoring progressif. Mais c'est face à l'IA agentique qu'il révèle peut-être sa pertinence la plus profonde.

Le défi architectural de l'IA agentique

Les agents IA ne se comportent pas comme des appelants ordinaires. Là où un microservice envoie une requête HTTP déterministe, un agent prend des décisions dynamiques, enchaîne des actions en fonction de résultats intermédiaires, peut réessayer, bifurquer ou déléguer à un sous-agent. Dans le contexte des Tech Trends 2026 de SFEIR et WEnvision, cette réalité est décrite comme une rupture opérationnelle : les équipes techniques ne rédigent plus du code syntaxique, elles supervisent des intentions et valident des comportements.

Cette autonomie nouvelle soulève des risques architecturaux bien réels :

• Couplage sauvage : un agent qui accède directement à une base de données, appelle des APIs internes sans contrat formalisé, ou manipule l'état système de manière non tracée crée une dette technique considérable.
• Observabilité dégradée : si l'agent interagit avec des couches techniques directement, tracer ses actions et comprendre leurs effets devient un cauchemar opérationnel.
• Testabilité compromise : comment valider le comportement d'un système si un agent peut appeler n'importe quelle couche à n'importe quel moment ?
• Sécurité affaiblie : l'accès non médiatisé aux ressources sensibles par des systèmes autonomes constitue une surface d'attaque que les RSSI regardent avec une inquiétude légitime.

L'architecture hexagonale adresse directement ces risques — non pas en limitant les capacités des agents, mais en les canalisant de façon maîtrisée.

L'agent comme adapter : une vision naturelle

L'insight central de cette affinité est le suivant : un agent IA est, du point de vue de l'hexagone, un adapter comme un autre. Il peut être un adapter entrant — celui qui déclenche des use cases métier en interprétant des intentions en langage naturel — ou un adapter sortant — celui qui utilise des capacités externes (recherche vectorielle, appel à un LLM, interaction avec un système tiers) pour accomplir une tâche définie par le domaine.

Prenons un exemple concret. Imaginons un système de gestion des contrats d'assurance. Le domaine métier expose un port entrant SouscriptionUseCase avec une méthode initierSouscription(DemandeClient). Dans une architecture classique, cet use case est appelé par un controller REST. Dans une architecture agentique, un agent reçoit un email de demande de souscription, en extrait les informations pertinentes, construit l'objet DemandeClient et appelle exactement le même port — sans que la logique métier ne sache ni ne se soucie de la nature de son appelant.

Cette équivalence est précieuse à plusieurs titres :

• Le domaine reste pur et testable indépendamment de tout agent.
• L'agent peut être remplacé, mis à jour ou désactivé sans toucher au cœur applicatif.
• Les règles métier s'appliquent de façon identique, qu'elles soient déclenchées par un humain via une interface ou par un agent autonome.

Stack AI-Ready : construire pour accueillir les agents

La notion de Stack AI-Ready émerge naturellement de cette réflexion. Ce n'est pas une stack technologique figée — c'est une posture architecturale qui garantit qu'un système peut intégrer des capacités IA agentiques sans refonte majeure. L'architecture hexagonale en est la colonne vertébrale.

Une stack AI-Ready construite sur ce principe présente plusieurs caractéristiques structurantes :

Des ports comme contrats d'intention

Les ports ne sont plus seulement des interfaces techniques — ils deviennent des contrats d'intention métier que les agents peuvent découvrir et utiliser. En exposant ces ports via des mécanismes adaptés (OpenAPI, schémas JSON, descriptions sémantiques), on donne aux agents la capacité de sélectionner et d'orchestrer les bonnes actions sans intervention humaine sur chaque cas particulier. C'est l'équivalent architectural du function calling des LLMs, mais à l'échelle du système d'information tout entier.

Des adapters IA comme citoyens de premier rang

Un adapter LLM, un adapter de recherche vectorielle, un adapter d'orchestration d'agents (LangGraph, AutoGen, CrewAI) s'intègrent dans la même logique que les adapters de persistence ou de messaging. Ils implémentent des ports sortants définis par le domaine — par exemple, un port AnalyseDocumentaire dont l'implémentation concrète peut s'appuyer sur GPT-4o aujourd'hui et un modèle open-source souverain demain, sans que le domaine ne le remarque.

Une observabilité structurelle

Parce que toutes les interactions passent par des ports contractualisés, il devient possible d'instrumenter chaque franchissement de frontière : quel agent a déclenché quel use case, avec quels paramètres, avec quel résultat, en combien de temps. Cette traçabilité n'est pas un ajout tardif — elle est architecturalement garantie. Dans un contexte où la confiance et la souveraineté deviennent des avantages compétitifs (comme le soulignent les Tech Trends 2026), cette observabilité intégrée est un argument de poids auprès des directions risk & compliance.

IA Mesh : quand les hexagones se connectent

L'IA agentique en entreprise ne se déploie pas en silo. Les Tech Trends 2026 décrivent une réalité dans laquelle les organisations orchestrent des réseaux d'agents autonomes — des architectures distribuées où plusieurs agents collaborent, se délèguent des tâches, partagent des contextes. C'est ce que le concept d'IA Mesh capture : un tissu interconnecté d'intelligences distribuées, analogue dans sa structure à ce que le Data Mesh a représenté pour la donnée.

L'architecture hexagonale se révèle ici particulièrement bien adaptée à une raison structurelle profonde : chaque domaine de l'IA Mesh peut être lui-même un hexagone.

Dans un IA Mesh, chaque nœud — qu'il s'agisse d'un agent spécialisé, d'un micro-domaine avec sa propre logique, ou d'un orchestrateur — expose des ports bien définis vers l'extérieur et maintient une logique interne encapsulée. Les agents communiquent entre eux via ces ports, sans connaître les détails d'implémentation des voisins. Cette séparation des responsabilités à grande échelle présente plusieurs avantages déterminants :

• Évolutivité indépendante : un nœud du mesh peut évoluer, changer de modèle IA sous-jacent ou être remplacé sans affecter les autres, tant que son contrat de port est respecté.
• Gouvernance distribuée : chaque équipe produit peut posséder son nœud hexagonal, l'instrumenter et le faire évoluer à son rythme — rejoignant la philosophie du Data Mesh appliquée aux agents.
• Résilience accrue : l'encapsulation limite la propagation des défaillances. Un agent qui échoue n'emporte pas avec lui l'ensemble du tissu.
• Testabilité à tous les niveaux : on peut tester un nœud isolément, simuler ses voisins via des adapters de test, valider les comportements d'ensemble avec des doubles.

Concrètement, imaginez un système de traitement de sinistres construit sur ce modèle. Un agent d'ingestion analyse et structure les documents entrants. Un agent d'évaluation applique les règles de couverture. Un agent de communication rédige et envoie les réponses. Chacun est un hexagone avec ses propres ports et ses propres adapters. L'orchestrateur du mesh les connecte via leurs interfaces contractualisées. L'équipe sinistres peut remplacer le moteur d'évaluation par un nouveau modèle sans toucher à l'agent de communication. L'audit peut tracer chaque décision au franchissement de chaque port.

Patterns concrets pour une implémentation réussie

Mettre en œuvre cette combinaison architecture hexagonale + IA agentique demande quelques patterns éprouvés que nos équipes SFEIR ont eu l'occasion de raffiner sur le terrain.

Le port de Tool Use

Plutôt que de laisser un agent appeler directement des fonctions ou des APIs, définissez un port sortant AgentToolRegistry qui expose les capacités disponibles de façon structurée. Chaque outil est une implémentation concrète de ce port. Cette approche facilite le contrôle des permissions, la journalisation et l'évolution du catalogue d'outils disponibles pour les agents.

L'adapter de supervision humaine

Pour les décisions critiques, un adapter de Human-in-the-Loop peut s'intercaler sur un port sortant, suspendant l'exécution de l'agent en attendant une validation humaine. Du point de vue du domaine, rien ne change — le port est appelé de la même façon. Mais l'adapter concret introduit une étape de supervision. Ce pattern est particulièrement précieux pour les cas d'usage à fort enjeu réglementaire ou financier.

Les adapters de contexte partagé

Dans un IA Mesh, les agents ont besoin de partager du contexte — l'historique d'une conversation, l'état d'un workflow, les résultats d'étapes précédentes. Plutôt que de laisser chaque agent gérer cette mémoire de façon ad hoc, définissez des ports de ContextRepository dont les adapters s'appuient sur des technologies adaptées (Redis, stockage vectoriel, graphe de connaissance). La logique de l'agent ne sait pas comment le contexte est stocké — elle sait seulement qu'elle peut le récupérer et le mettre à jour via son port.

Le pattern Circuit Breaker agentique

Les agents autonomes peuvent, s'ils ne sont pas contraints, générer des boucles d'appels coûteuses ou des comportements inattendus. Instrumenter les ports de sortie avec des mécanismes de circuit breaker — limitation du nombre d'appels, timeout, détection d'anomalies comportementales — permet de garder le contrôle sans modifier la logique agent elle-même.

La perspective SFEIR : accompagner la transition vers des architectures agentiques maîtrisées

Chez SFEIR, nous observons depuis plusieurs mois une accélération des demandes liées à l'IA agentique dans les organisations. Ce qui était une exploration exploratoire il y a dix-huit mois devient aujourd'hui une priorité de roadmap pour de nombreux DSI. Et invariablement, les premières difficultés rencontrées ne sont pas de l'ordre du modèle IA — elles sont architecturales.

Les équipes qui progressent le plus rapidement vers une Stack AI-Ready opérationnelle sont celles qui, souvent sans l'avoir formulé ainsi, ont déjà investi dans une séparation claire entre logique métier et couches techniques. L'architecture hexagonale, le DDD tactique, les microservices bien découplés — ces fondations facilitent considérablement l'intégration d'adapters IA sans refonte globale.

À l'inverse, les organisations qui ont accumulé une dette architecturale importante — couplages forts, logique métier dispersée dans les couches techniques, absence de contrats explicites entre composants — se retrouvent à devoir résoudre simultanément deux problèmes : refactorer l'existant et intégrer les agents. C'est faisable, mais la trajectoire est plus longue et plus risquée.

Notre approche s'articule autour de trois axes :

• Audit architectural ciblé : identifier les domaines où l'introduction d'agents crée le plus de valeur et évaluer leur maturité architecturale pour l'accueillir sereinement.
• Définition de la cible AI-Ready : co-construire avec les équipes techniques et métier une vision cible qui intègre les principes hexagonaux pour les domaines candidats à l'agentique.
• Accompagnement à l'implémentation : nos Staff Engineers et Architects IA travaillent aux côtés des équipes pour implémenter les premiers nœuds du mesh, poser les patterns de référence et former les équipes à leur application.

Les Tech Trends 2026 le soulignent avec clarté : nous passons à l'ère où les développeurs supervisent plutôt que rédigent. Cette transition demande non seulement de nouveaux outils, mais de nouvelles postures, de nouveaux réflexes architecturaux et une capacité à penser les systèmes comme des tissu d'intentions contractualisées plutôt que comme des pipelines d'instructions séquentielles. C'est précisément ce que l'architecture hexagonale, appliquée au contexte agentique, permet de cultiver.

Conclusion : l'hexagone comme fondation du futur agentique

L'architecture hexagonale n'est pas une mode passagère revisitée à la sauce IA. C'est un principe d'ingénierie logicielle dont la pertinence se révèle avec une acuité renouvelée face aux défis des agents autonomes. En traitant chaque agent comme un adapter — ni plus ni moins important que n'importe quel autre composant technique — elle permet de construire des systèmes où l'autonomie des agents est une force canalisée, pas un risque subi.

La promesse de l'IA Mesh, ce réseau distribué d'intelligences collaborantes qui redessine les architectures d'entreprise, ne peut se concrétiser de façon durable que si chaque nœud du tissu est lui-même solide, encapsulé et testable. L'hexagone est la forme naturelle de ce nœud.

À mesure que des outils comme Claude Code, OpenAI Codex CLI ou Gemini CLI généralisent le développement agentique, la question n'est plus de savoir si les agents vont intégrer nos systèmes, mais comment nous allons les accueillir. La réponse architecturale est entre nos mains — et elle ressemble beaucoup à un hexagone.

Vous souhaitez évaluer la maturité AI-Ready de votre architecture ou explorer l'intégration d'agents dans votre système d'information ? Les équipes SFEIR sont disponibles pour en discuter et vous accompagner dans cette transformation.