Le DDD à l'épreuve de l'expérience utilisateur
Le DDD à l'épreuve de l'expérience utilisateur
Quand le DDD rencontre l’expérience utilisateur
Le DDD a t-il une relation avec conflictuelle avec les équipes UX / Front-end
© Source: https://coopleo.care/manque-communication-couple/
Avant tout, de quoi parle-t-on ?
Dans les modernisations les plus ambitieuses, le découpage en sous-domaines peut légitimement être interrogé au regard de l’intégrité des informations présentées à l’utilisateur. La logique du Domain-Driven Design conduit en effet à structurer le système autour de frontières métier, tandis que l’expérience utilisateur traverse souvent plusieurs de ces frontières au sein d’un même écran ou d’un même parcours utilisateur, comme un tunnel d’achat pour un système de e-commerce.
Cette tension soulève une question d’organisation essentielle : les équipes en charge du développement front-end doivent-elles être regroupées au sein d’une équipe experte des technologies front, intervenant en support des différents sous-domaines métier selon les besoins, ou bien être intégrées directement dans les équipes responsables au sein de leur sous-domaine, avec une responsabilité de bout en bout ?
La cohérence de l’interface utilisateur peut souffrir d’un découpage réparti entre plusieurs équipes métier. Le découpage en sous-domaines se doit d’être agnostique au regard de l’expérience utilisateur.
La question est légitime, car chacune de ces approches engage un modèle organisationnel différent.
- La première option renforce l'autonomie des équipes métier et leur ancrage dans les besoins fonctionnels, mais expose davantage au risque de fragmentation technologique et complique le maintien d'une expérience utilisateur cohérente. Placer le métier au centre ne saurait en effet justifier que l'on néglige les usages et la qualité de l'expérience offerte à l'utilisateur au travers de l'interface graphique.
- La seconde option favorise la cohérence visuelle et fonctionnelle de l’interface utilisateur, mutualise les compétences et facilite la maîtrise d’un système unifié. En contrepartie, la centralisation des développements au sein d’une équipe UX / Front-End dédiée peut créer un goulot d’étranglement organisationnel et éloigner progressivement les développeurs front-end des enjeux et de la logique métier.
Ce dilemme entre un découpage des équipes favorisant l’autonomie et une meilleure répartition des problématiques métier, d’une part, et la recherche d’une expérience utilisateur fluide et cohérente, d’autre part, demeure difficile à arbitrer. Chaque approche présente en effet ses propres avantages, mais également ses limites et compromis.
La première option : un équilibre organisationnel délicat
Dans le schéma ci-dessous, nous illustrons un exemple où les différents sous-domaines, Facturation, Livraison et Paiement, sont décrits de manière détaillée, mais sans véritable cohérence d’ensemble du point de vue de l’expérience utilisateur.
Dans ce contexte, une approche orientée tunnel de vente aurait sans doute été plus pertinente qu’une simple juxtaposition de parcours fonctionnels indépendants. En faisant l’impasse sur l’expérience utilisateur, on expose ce dernier à des erreurs directement imputables à une interaction mal conçue, nuisant à la compréhension des usages ainsi qu’à la fluidité de navigation.
En revanche, cette organisation favorise une compréhension métier beaucoup plus fine. Les équipes, directement immergées dans leur domaine fonctionnel, développent une meilleure maîtrise des problématiques métier, des contraintes opérationnelles et des attentes associées à leurs livrables. Cette proximité avec le métier renforce leur autonomie décisionnelle et leur capacité à livrer plus fréquemment, avec un niveau d’alignement fonctionnel souvent supérieur.
La seconde option : organisation centralisée sur la cohérence visuelle
Sans doute l’organisation la plus répandue, car héritée de la traditionnelle architecture en couches. Elle répond en partie aux limites de la première option en apportant davantage de cohérence visuelle, d’homogénéité ergonomique et de fluidité dans l’expérience utilisateur.
Les expertises front-end (Web et Mobile) sont généralement organisées au sein de structures spécialisées : une équipe dédiée au site Web et une ou deux équipes dédiées au Mobile. Ces équipes ont la responsabilité de concevoir l'ensemble de l'expérience utilisateur, tout en assurant les interactions entre les interfaces graphiques et les différents modules back-end.
Si cette organisation renforce la cohérence globale de l’application, mutualise les compétences et facilite la gouvernance technique, elle introduit également un risque de dépendance forte envers l’équipe centrale. À terme, cette concentration des responsabilités peut ralentir les évolutions métier, créer des goulots d’étranglement et réduire l’autonomie des équipes alignées sur les domaines métier.
Quand l’expérience utilisateur rencontre les frontières métier
L’approche Domain-Driven Design
L’approche Domain-Driven Design invite à répartir les compétences front-end au sein des équipes alignées sur les sous-domaines métier, tout en les complétant par une équipe transverse dédiée au socle commun de l’expérience utilisateur.
En d’autres termes, chaque équipe métier intègre des compétences front-end chargées de concevoir et de développer le reflet de son domaine fonctionnel au sein de l’interface utilisateur. Les composants graphiques éligibles à la généricité métier sont ensuite mutualisés et intégrés au sein d’un socle d’interface commun, maintenu par une équipe transverse garante de la cohérence globale de l’expériencCe utilisateur.
Lorsqu’une équipe réunit l’ensemble des compétences nécessaires pour traiter les problématiques métier dont elle a la responsabilité, elle gagne en autonomie, ce qui constitue souvent un objectif recherché dans les organisations modernes. Elle peut alors prendre en charge l’essentiel de ses sujets sans dépendre systématiquement d’autres équipes.
Diviser pour régner
Cette autonomie lui permet de piloter ses objectifs de bout en bout, tout en restant alignée sur les enjeux métier et sur la cohérence globale de l’expérience utilisateur.
© Source: Introducing EventStorming – Alberto Brandolini
Sur ce schéma, les lignes jaunes matérialisent la séparation entre les sous-domaines métier. Les carrés orange illustrent des exemples d’événements métier pivots, c’est-à-dire des événements traversant plusieurs sous-domaines. Enfin, les formes patatoïdes représentent les différents Bounded Contexts.
Plusieurs arguments plaident en faveur de ce modèle. Tout d’abord, la proximité entre les développeurs front-end et les experts métier réduit considérablement les boucles de feedback et limite les pertes d’information entre le besoin exprimé et l’interface finalement livrée. Cet avantage devient particulièrement précieux dans des domaines à forte densité fonctionnelle, comme la valorisation financière ou la préparation de commandes, où la compréhension fine du métier influence directement la qualité des interactions utilisateur.
Par ailleurs, la responsabilité de bout en bout, depuis le modèle métier jusqu’à l’interface utilisateur, renforce l’autonomie des équipes, accélère les cycles de livraison et clarifie les frontières de responsabilité au sein d’un domaine métier.
Cette organisation s’inscrit naturellement dans un découpage en Bounded Context identifiés lors d’ateliers tels que l’EventStorming Big Picture suivi d’un Context Mapping (pour plus d’information : https://blog.octo.com/octo-article-de-blog-19) afin de juger de la qualité des relations entre les Bounded Contexts. Ces pratiques permettent non seulement de structurer les responsabilités métier, mais également d’améliorer la qualité des relations et des interactions entre les équipes.
Définir le concept de Bounded Context en quelque mots
Si la notion de Bounded Context ne vous est pas familière, il convient de la comprendre, en premier lieu, comme une sphère de connaissance dédiée à la résolution d'un problème métier spécifique. Son ambition est de produire un code, le plus souvent matérialisé sous la forme d'un microservice, capable d'incarner la solution métier avec cohérence, clarté et souplesse d'évolution.
Cette sphère de connaissance respective à une problématique métier, repose sur un vocabulaire partagé, appelé langage ubiquitaire. Ce langage commun permet aux experts métier et aux équipes de développement de raisonner ensemble, de confronter leurs compréhensions respectives et de réduire progressivement la complexité du domaine métier. Au fil des échanges et des itérations, cette intelligence collective permet de distiller le problème jusqu'à en produire une modélisation simple, explicite et profondément ancrée dans la réalité du métier.
Il est important de noter la forte communication entre les experts métier est le membre d’un Bounded Context. C’est bien cette communication qui est cœur d’une compréhension métier au profit d’une modélisation plus approfondie.
Lorsque la charge cognitive d'une équipe reste maîtrisable, celle-ci peut prendre en charge plusieurs Bounded Contexts au sein d'un même sous-domaine. La proximité fonctionnelle facilite alors la compréhension globale et fluidifie la coordination des travaux. En revanche, gérer des Bounded Contexts relevant de sous-domaines distincts se révèle généralement plus exigeant : la diversité des concepts, des règles fonctionnelles et des modèles mentaux accroît significativement la charge cognitive de l'équipe, au risque de fragiliser son autonomie et la qualité de sa modélisation.
Enfin, tout Bounded Context produit un livrable qui matérialise la solution au problème qu'il adresse. Dans une organisation structurée autour de cette approche, chaque contexte délivre ainsi un artefact concret, qu'il s'agisse d'une application, d'un service ou d'un micro-frontend, contribuant à l'édifice global du système d'information.
Etude de cas - le Front End est en souffrance
Dans notre métier de consultant chez OCTO Technology, nous rencontrons régulièrement des organisations dont le système d’information a progressivement évolué vers un monolithe complexe, devenu difficile à faire évoluer, à maintenir et à opérer.
Dans cet exemple, il est intéressant d’observer que les problématiques de migration technologique ne se manifestent pas au niveau des services back-end.
Chaque équipe y exploite un logiciel indépendant, ce qui lui confère une autonomie naturelle ainsi que la liberté d’évoluer à son propre rythme, selon ses propres contraintes et priorités.
Les tensions apparaissent principalement au niveau du front-end, là où les responsabilités se chevauchent et où toute évolution technique impacte l’ensemble du système, indépendamment de la volonté ou du calendrier de chaque équipe. Nous nous retrouvons alors face à une application web monolithique, dans laquelle les dépendances techniques finissent par freiner l’autonomie organisationnelle.
Schéma simplifié qui illustre la situation avant la modernisation de l’architecture Front
Pour répondre durablement à cette problématique structurelle, il devient nécessaire de redonner à chaque équipe la responsabilité claire d’un périmètre fonctionnel du front-end, tout en lui laissant la liberté de choisir les standards et les technologies les plus adaptés à ses enjeux métier, sans que ces décisions n’imposent de contraintes aux autres équipes. C’est précisément à ce besoin d’autonomie, de découplage et d’évolutivité que répond l’architecture micro-frontend.
Réorganiser les équipes en bonne intelligence
Dans cet exemple, la partie front-end repose sur une application web monolithique chargée de servir l’ensemble des équipes responsables des différents contextes métiers.
Avec l’apparition progressive de nouveaux Bounded Contexts, cette architecture web atteint ses limites. Chaque évolution fonctionnelle augmente les dépendances entre équipes, complexifie les cycles de livraison et accentue le couplage au sein de l’application. Peu à peu, le front-end monolithique devient un point de congestion organisationnel et technique.
La montée en charge des nouveaux contextes métier finit alors par fragiliser l’architecture existante au point de ralentir fortement, voire d’empêcher, la livraison de nouvelles fonctionnalités. Ce qui devait initialement favoriser la mutualisation devient progressivement un facteur de rigidité, réduisant la capacité des équipes à évoluer de manière autonome et soutenable.
L'architecture micro-frontend s’impose comme la réponse naturelle à cette problématique. Son principe fondateur consiste à décomposer l'interface utilisateur en fragments autonomes et isolés, chacun relevant d'une équipe et d'un contexte métier bien identifiés.
À noter que le BFF (Back For Front) conserve, dans cette organisation, le statut de brique unique : son rôle se limitant au mapping de données pour des pages spécifiques, il n'appelle pas de fragmentation supplémentaire.
De la segmentation métier à la convergence graphique
Ce que le schéma d’architecture ne révèle pas, c’est la manière dont les équipes sont réellement organisées, ou plus précisément, la façon dont les Bounded Contexts sont délimités. Car, comme nous l’avons vu, cette délimitation ne relève jamais d’une simple frontière technique : elle se construit avant tout autour d’une problématique métier cohérente et porteuse de sens pour l’équipe qui en a la responsabilité.
Lorsqu’une problématique métier devient trop vaste pour être comprise, discutée et maîtrisée collectivement par une seule équipe, il devient pertinent de la scinder en plusieurs périmètres distincts. Il est préférable de disposer de deux équipes pleinement engagées sur des problèmes clairement circonscrits, plutôt qu’une seule équipe confrontée à un domaine devenu trop large pour être appréhendé sereinement.
À l’inverse, lorsque la complexité d’un Bounded Context demeure limitée, une même équipe peut parfaitement prendre en charge plusieurs contextes métier sans compromettre ni la cohérence du modèle, ni sa capacité de décision et d’évolution.
Ainsi, le Bounded Context ne doit pas être perçu uniquement comme un mécanisme de découpage technique, mais comme un espace de cohérence métier, porté par une équipe autonome et incarné par un livrable clairement identifié.
Ici nous avons représenté seulement quatre contextes métier afin de comprendre l’organisation des équipes métier Front-End au regard de leur pendant Back-End :
- Produit
- Offre
- Panier
- Marketing
L'objectif est de tirer parti du concept de Bounded Context afin de composer des équipes pluridisciplinaires organisées par domaine métier, c'est notamment le cas des contextes Produit, Offre et Marketing. Il s'agit également de montrer comment, lorsque l'équipe Front-End ne prend pas en charge la partie Back-End, assurer malgré tout une communication fluide et robuste entre les deux. Ce cas de figure est illustré à travers le contexte Panier.
Context Mapping des équipes Front-End et Back-End, où lorsque deux Bounded Contexts sont cerclées, ils sont alors gérés par une même équipe.
Les Bounded Contexts représentés en vert correspondent à des contextes orientés UX/front-end, dont le livrable prend la forme d'un fragment d'interface graphique, généralement implémenté sous la forme d'un micro-frontend. Les Bounded Contexts représentés en rouge couvrent, quant à eux, les responsabilités métier et back-end.
Lorsqu'un Bounded Context vert et un Bounded Context rouge apparaissent cerclés ensemble, cela traduit une responsabilité unifiée : une seule et même équipe prend en charge l'ensemble du périmètre, des dimensions métier jusqu'à l'expérience utilisateur. Cette organisation pluridisciplinaire incarne pleinement l'idéal d'une équipe autonome, responsable de bout en bout de la valeur qu'elle délivre.
Le contexte Panier constitue une exception à ce schéma. Le panier présente par nature une complexité métier intrinsèque au domaine d'un système e-commerce, qui ne permet pas une gestion unifiée au sein d'une seule équipe. Deux équipes distinctes y interviennent, l'une sur le Front-End, l'autre sur le Back-End, sans pour autant opérer de manière indépendante. Leurs destins sont étroitement liés : leurs organisations internes sont volontairement alignées, et leur collaboration est structurée pour permettre une livraison conjointe et cohérente des deux dimensions. Elles forment en ce sens un véritable Partnership : pattern de communication issu du DDD, fondé sur une proximité fonctionnelle et une coordination étroite.
Ce choix organisationnel découle directement des principes évoqués précédemment : la complexité métier propre au domaine du Panier et la charge cognitive qui en résulte ont rendu nécessaire cette séparation des responsabilités, sans pour autant renoncer à l'exigence de cohérence et d'alignement entre les deux équipes.
L’équilibre entre autonomie métier et cohérence utilisateur
Cette approche introduit néanmoins un équilibre délicat entre autonomie métier et cohérence globale de l’interface utilisateur. Pour les utilisateurs, la continuité de l’expérience reste essentielle et ne doit pas être fragilisée par la décomposition interne du système d’information en Bounded Contexts. Une fragmentation organisationnelle mal maîtrisée pourrait en effet conduire à des interfaces hétérogènes, générant confusion et perte de repères.
C’est précisément pour répondre à cet enjeu que les équipes Front-End et UX intervenant au plus près des différents Bounded Contexts doivent collaborer étroitement avec l’équipe chargée de l’intégration des micro-frontends et du socle d’expérience utilisateur. Cette coopération permet de garantir simultanément la cohérence globale de l’interface, l’harmonisation des usages et la pertinence fonctionnelle propre à chaque sous-domaine métier.
Vers une organisation centrée sur le métier au service de l’utilisateur
En définitive, le Domain-Driven Design n’est pas incompatible avec les exigences d’une expérience utilisateur cohérente ; il conduit plutôt les organisations à repenser la manière dont collaborent les équipes métier, l’architecture et les expertises front-end.
Là où une approche purement technique pourrait opposer découpage métier et cohérence visuelle, le DDD invite au contraire à rechercher un équilibre durable entre autonomie des équipes et discipline collective. La répartition des équipes autour des Bounded Contexts offre ainsi une souplesse organisationnelle capable de s’adapter à des contraintes variées, qu’elles soient métiers, techniques ou liées à l’expérience utilisateur.
La réussite d’une telle organisation repose moins sur une centralisation systématique des compétences front-end que sur la capacité des équipes à partager des standards communs, des patterns d’intégration et une compréhension convergente des usages.
Les équipes alignées sur les Bounded Contexts doivent préserver leur proximité avec le métier et leur capacité de décision locale, tandis qu’une équipe transverse veille à la cohérence globale de l’expérience utilisateur ainsi qu’à l’intégrité d’ensemble du système.
Au fond, la véritable question n’est pas de choisir entre autonomie métier et cohérence de l’expérience utilisateur, mais de construire une organisation capable de concilier ces deux dimensions sans les opposer. C’est précisément dans cette articulation entre spécialisation métier, collaboration transverse et vision produit globale que réside sans doute l’une des formes les plus abouties de modernisation des systèmes d’information.
Pensée finale
L'architecture micro-frontend, pensée à travers le prisme du Domain-Driven Design, ne se réduit pas à une réponse technique à un problème de scalabilité. Elle constitue avant tout un modèle organisationnel, dans lequel les frontières logicielles épousent les frontières humaines, et où chaque équipe trouve dans son Bounded Context un espace de sens, de responsabilité et d'engagement.
La mutualisation des compétences UX/front-end entre plusieurs contextes connexes illustre la souplesse et la maturité de ce modèle. Elle démontre que l’autonomie et la collaboration ne sont pas antagonistes : une équipe peut intervenir sur plusieurs Bounded Contexts sans diluer sa valeur, dès lors que la proximité métier est préservée et que la charge cognitive reste soutenable.
À grande échelle, cette organisation fait émerger un écosystème d'équipes de proximité, chacune ancrée dans la réalité fonctionnelle de son domaine, et collaborant avec une équipe transverse garante de la cohérence globale de l'expérience utilisateur. Ce double niveau, spécialisation et intégration, reflète précisément l'équilibre que toute organisation produit cherche à atteindre : permettre à chaque équipe d'exceller dans son périmètre, tout en préservant l'unité de ce qui est livré à l'utilisateur final.
En définitive, ce que cette démarche révèle, c'est qu'un système bien conçu n'est pas seulement le fruit d'une bonne architecture technique. Il est le reflet d'une organisation dans laquelle les humains comprennent ce qu'ils construisent, partagent un langage commun, et se reconnaissent collectivement dans la valeur qu'ils délivrent. C'est cette convergence entre structure organisationnelle, intention métier et excellence technique qui constitue le véritable fondement d'un système d'information durable et évolutif.