Compte-rendu du Café du Produit #37 :  “Aligner les équipes métier et tech grâce au DDD”

Le mardi 03 juin dernier, pour ce 37ème épisode nous avons abordé un sujet souvent évoqué mais encore trop rarement mis en œuvre : le Domain-Driven Design (DDD), ou comment mieux aligner les équipes tech et métier au service du produit.

Durant cet épisode animé par Ève de la Grange (Product et Service Designer), nos deux invités Antoine Mazure (Tech Lead) et Rémi Flipo (Coach craft et formateur) sont revenus sur leur expérience de terrain et ont partagé les apports concrets d’une approche DDD dans les organisations tech–produit.

Entre pratiques d’organisation, exploration métier et modélisation du code, ils ont mis en lumière comment cette démarche permet non seulement de mieux comprendre le métier, mais surtout de l’ancrer concrètement dans la conception du produit.

Avant de reprendre les éléments partagés par nos invités, découvrez l’épisode #37 à travers la sketchnote réalisée par Laurent Igout.

Une réponse à la complexité croissante des produits

Le DDD est né d’un besoin fondamental : mieux gérer la complexité métier dans les systèmes logiciels. Face à la multiplication des produits, des parties prenantes et des dépendances, il devient vital que le code reflète avec précision le langage et les logiques métier.

C’est tout le sens du “design centré sur le domaine” : faire en sorte que ce soit bien la compréhension du métier par les développeurs qui parte en production, et non des spécifications déconnectées.

À travers leur retour d’expérience, Antoine et Rémi ont montré que cette approche ne se limite pas à un pattern technique ou à une méthode de découpage — c’est un changement de posture, qui favorise l’autonomie, la communication directe et la prise de décision au plus près du métier.

Structurer autour des contextes métier : le rôle du DDD stratégique

Lorsqu’on parle de DDD, il faut distinguer deux volets complémentaires : le stratégique et le tactique.

La première étape clé stratégique est la clarification des Bounded Contexts (ou contextes bornés), ces zones d’autonomie métier qui permettent de limiter les effets de bord et les malentendus entre équipes. En d’autres termes, c’est une frontière logique autour d’un vocabulaire, de règles métiers et de comportements, partagés et compris de la même manière par toutes les personnes qui y travaillent (développeurs, métiers, etc.). Antoine raconte comment ce découpage a permis, dans une marketplace, de distinguer les logiques de gestion des produits physiques et dématérialisés autour de la billetterie, libérant ainsi la roadmap et l’autonomie de chaque équipe.

Pour arriver à ces découpages, l’Event Storming s’impose comme un outil central. Il s’agit d’un atelier collaboratif entre experts métier, designers et développeurs, qui vise à cartographier les événements métier et les enchaînements logiques. C’est une manière très efficace de partager la connaissance et de faire émerger une vision commune du produit, tout en révélant les zones de friction.

Grâce à cet exercice, les équipes peuvent ensuite prioriser les contextes à traiter à l’aide d’un Core Domain Chart : une matrice qui croise la valeur métier et la complexité technique, permettant d’identifier où concentrer les efforts.

Modéliser le métier dans le code : le DDD tactique au service de la lisibilité

Une fois les contextes bien définis, le travail peut se poursuivre dans le code. C’est ici que le DDD prend toute sa force tactique : dans la capacité à créer un modèle logiciel qui colle au langage du métier, avec des objets, des règles et des relations qui font sens pour les utilisateurs.

Chez Rémi comme chez Antoine, cela passe par la mise en place de rituels de discovery réguliers avec les métiers (souvent 2h par semaine), et par des pratiques de développement comme le Test-Driven Development (TDD : développement dirigé par les tests), le Behavior-Driven Development (BDD : développement dirigé par le comportement) ou l’example mapping (atelier rapide pour clarifier une user story). Ces formats permettent de confronter directement le code aux cas d’usage réels, de le rendre plus explicite, et même, dans certains cas, compréhensible par les experts métier eux-mêmes.

La promesse n’est pas seulement d’écrire un meilleur code : c’est de réduire les frictions entre intention et exécution, en alignant au plus près les attentes du métier avec ce qui est effectivement livré.

Quand et comment démarrer une démarche DDD ?

Le DDD peut être initié à différents moments du cycle de vie produit. Antoine et Rémi insistent toutefois sur un point : mieux vaut structurer les contextes métier avant de se lancer dans un discovery ou une refonte technique, sous peine de créer plus de confusion qu’autre chose.

Cela dit, en l’absence de vision claire sur le périmètre métier, débuter par un Event Storming exploratoire reste une bonne façon de poser les bases.

Ce type de démarche est particulièrement utile en phase de scaling (changement d’échelle), de refonte applicative ou lors de la création d’un nouveau produit. C’est aussi un bon moyen de réinterroger l’allocation des ressources, notamment lorsqu’un contexte générique absorbe une part disproportionnée des efforts au détriment du cœur de métier.

Une approche culturelle, pas juste technique

Ce que soulignent les deux intervenants, c’est que le DDD est avant tout une posture collaborative. Elle nécessite :

• de réduire la distance entre développeurs et experts métier,
• d’accepter de se tromper, d’itérer et de s’aligner continuellement,
• de favoriser la clarté plutôt que l’exhaustivité technique.

Le code devient alors un support de communication métier, un langage partagé qui reflète les règles du jeu et les intentions produit.

Les takeaways de l’épisode

• Osez l’Event Storming pour construire une vision partagée et identifier les véritables frontières métier.
• Faites parler le code : nommez les concepts avec les mots du métier, pas ceux du framework.
• Invitez les experts métier à lire le code ou les tests : cela change la donne.
• Privilégiez l’autonomie des équipes par contexte pour limiter les dépendances et améliorer le delivery.
• Utilisez des formats légers mais réguliers pour entretenir la connaissance du domaine.

Envie d’approfondir ?

• "Domain-Driven Design: Tackling Complexity in the Heart of Software" Eric Evans - 2003
• Introducing… by Alberto Brandolini [Leanpub PDF/iPad/Kindle]
• Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy 1st Edition
• “a deeper model enables breakthroughs in product dev*.” - Kenny Baas-Schwegler & Bruno Boucard - Présentation en anglais du Model-Driven Design How -* youtube.com
• https://github.com/ddd-crew/ddd-starter-modelling-process
• “Continuous discovery habits” - Teresa Torres
• Refcard “DDD Stratégique” — OCTO Technology
• Formations et coaching craft — OCTO Academy

Le Café du Produit, kezako ?

Le rendez-vous en ligne mensuel, pour tous les profils Produit, le premier mardi tous les 2 mois, de 9h à 9h45, pour échanger autour des sujets Produit avec des invité·e·s engagé·e·s issus de divers secteurs d'activité, qui partagent leurs réussites, échecs et apprentissages sur une thématique dédiée.

Retrouvez toute l’intégralité des épisodes ICI.

Découvrez le podcast du Café du Produit

Le podcast du Café du Produit by OCTO Technology reprend quelques épisodes phares et destiné aux professionnels du développement produit.

Disponible sur Spotify, Deezer et d'autres plateformes, chaque épisode propose des interviews d’experts d’OCTO Technology qui partagent leurs expériences concrètes et expertises. N’hésitez pas à vous abonner sur votre plateforme de prédilection.

Podcast de l’épisode

L’écouter sur : Apple Podcasts, Spotify