Le Model-Driven Design - Chimère ou réalité

le 11/04/2025 par Bruno Boucard
Tags: Software Engineering, Product & Design, Bonne Pratique, Architecture, Craft

Model-Driven-Design

Le Model-Driven Design - Chimère ou réalité ?

Peu de gens le réalisent mais, au sein de l’approche Domain-Driven Design, la collaboration entre les experts métier et les développeurs ne s'arrête pas aux discussions… Elle se prolonge jusqu’au code !

Zoom rapide sur le Model-Driven Design

Le Domain-Driven Design (DDD) repose sur deux volets complémentaires :

1. Le design stratégique vise à comprendre l’organisation d’un domaine métier afin de le découper en sous-domaines cohérents. Chacun de ces sous-domaines peut ensuite être pris en charge par une ou plusieurs équipes. Dans le vocabulaire DDD, on parle alors de Bounded Contexts.

2. Le design tactique, aussi appelé Model-Driven Design, repose sur trois piliers :

  • Une boîte à outils pour structurer proprement le code ;
  • Une collection de patterns techniques — le Supple Design — visant à rendre le code souple et adaptable ;
  • Une approche résolument collaborative et itérative — le Deep Modeling — menée main dans la main avec les experts métier, pour attaquer les problèmes complexes à la racine… et en ressortir avec un code simple, clair et maintenable. Une belle promesse, certes, mais qui soulève une vraie question : est-ce réellement possible ?

Ensemble, on va creuser plusieurs thématiques pour découvrir si le Model-Driven Design tient vraiment toutes ses promesses… ou si ce n’est qu’un mythe bien raconté.

Succès mitigé des projets IT

Il y a vingt ans, l’ouvrage éponyme d’Eric Evans, Domain-Driven Design, était révélé à la sphère IT. Cependant, depuis des décennies, le Chaos Report tire la sonnette d’alarme : les résultats dans le secteur de l’IT sont globalement mitigés et les projets échouent souvent à livrer la valeur attendue. Dans ce contexte, on aurait pu croire que l’adoption des méthodes agiles allait inverser la tendance… mais la réalité montre que les résultats ne sont pas à la hauteur des promesses initiales.

Des user stories… aux tickets déconnectés

Sur une granularité plus fine, intéressons-nous au transfert des besoins métier entre les donneurs d’ordre et les équipes de développement. En théorie, les équipes de développement reçoivent les besoins métier sous forme de user stories, structurées, contextualisées, discutées. En pratique ? Ces besoins sont le plus souvent réduits à de simples tickets Jira, déconnectés de leur intention initiale, vidés de leur contexte métier, et porteurs d’une compréhension fragmentaire.

Quand une user story embarque plusieurs règles métier imbriquées, elle révèle souvent une fonctionnalité complexe, essentielle pour produire de la valeur. Pourtant, dans la majorité des cas, l’équipe de développement finit par construire un modèle métier… qu’elle ne comprend pas elle-même.

Un manque de temps pour penser la complexité

La cause principale de cet échec est le manque de temps alloué à la réflexion et à la distillation du problème. Très peu d’équipes ont le luxe de ralentir pour modéliser un problème complexe — les itérations s’enchaînent, les sprints s’accumulent… et l’espace pour penser disparaît. Mais il n’y a pas de raccourci : toute activité humaine impliquant de la complexité nécessite du temps.

Un point souvent négligé par les organisations : pour modéliser un problème complexe, notre cerveau a besoin de temps de maturation. Le sommeil joue un rôle clé dans cette digestion mentale. En d’autres termes, il faut dormir dessus pour y voir plus clair — littéralement.

Le DDD entre en scène !

Le pouvoir du langage partagé

En DDD (Domain-Driven Design), la notion de langage ubiquitaire (ubiquitous language) souligne à quel point les mots façonnent notre manière de penser le métier. Notre cerveau agit comme une éponge : il absorbe les mots que nous entendons au quotidien. À force d’exposition, nous intégrons inconsciemment les concepts sous-jacents.

Le problème ? Dans les équipes de développement, les conversations portent rarement sur les concepts métiers. Les experts sont souvent absents, et la qualité de l'information métier transmise est pauvre — surtout dans les grandes organisations où cette dynamique reste figée.

Pourtant, le lien entre les équipes métier et les développeurs est essentiel. Il permet une assimilation progressive du vocabulaire métier, et donc une meilleure compréhension des enjeux réels. Quand les échanges sont fréquents, les développeurs absorbent naturellement ce langage commun, qui devient une grille de lecture du métier lui-même.

L’immersion rend les sessions de modélisation plus riches et plus pertinentes. L’équipe clarifie la complexité du métier sans détour, la découpe en éléments simples et peut prendre des décisions partagées. L’absorption du vocabulaire métier, associé à des petits refactoring de code, permet de ciseler le modèle attendu en toute sérénité.

Mais c’est quoi un modèle métier ?

Un modèle métier, c’est une version simplifiée de la réalité, construite pour mettre en lumière certains aspects… et en laisser d’autres de côté. Autrement dit, c’est une abstraction pensée pour un objectif bien précis, il naît le plus souvent d’une collaboration étroite entre les experts métier et l’équipe de développement. Avec le Model-Driven Design, l’enjeu est d’aller plus loin : faire vivre ce modèle directement dans le code. Et c’est là que la magie opère — ou que les premières frictions apparaissent. Car l’implémentation technique agit comme un révélateur. Elle provoque des échanges, génère des feedbacks et pousse parfois à remettre en question le modèle initial… ou au contraire à le renforcer. Ce dialogue constant entre code et métier nourrit une compréhension partagée. Au bout de quelques semaines, les développeurs ne sont plus de simples exécutants : ils deviennent eux aussi des experts du domaine.

Des équipes orientées modélisation métier

Dans l’univers Domain-Driven Design, on parle de Bounded Context — comme une sphère de connaissances tangibles liées à un problème métier spécifique, accompagné d’un vocabulaire partagé entre l'équipe et les experts, appelé langage ubiquitaire. Tous les éléments de ce contexte – documents, emails, dossiers, fichiers, structure et design du code – reflètent la sémantique du métier.

Pour appuyer un autre angle pour regarder les bounded contexts ce terme — des équipes orientées modélisation métier. Ces équipes possèdent des caractéristiques bien distinctes :

  • Une compréhension approfondie du domaine : grâce à leur proximité avec les experts métier, elles gagnent en justesse dans leurs choix.
  • Une modélisation plus stable et évolutive : les modèles produits reflètent fidèlement le métier, ce qui les rend plus robustes dans le temps.
  • Une autonomie accrue : leur cohérence fonctionnelle leur permet de prendre des décisions sans dépendance excessive.
  • Une collaboration enrichie : le langage partagé fluidifie les échanges et diminue les malentendus.

Il s’agit donc d’un écrin intellectuel où le vocabulaire métier imprègne chaque échange, dans le but de concevoir un logiciel finement ajusté aux attentes métier des utilisateurs.

La modélisation : mal comprise, car mal enseignée

Un constat décevant

La modélisation est souvent mal comprise, car elle est mal expliquée. Lors d’une de mes formations, j’ai posé cette question à l’audience : « Que signifie modéliser en informatique ? » Les réponses étaient fascinantes — et révélatrices. La majorité des réponses se divisaient entre modélisation fonctionnelle d’un côté, et modélisation technique de l’autre.

Mais aucun système robuste ne repose durablement sur cette séparation artificielle. Cette distinction vient probablement d’une vision dépassée, où la technologie et le fonctionnel sont perçus comme deux mondes séparés. Or, un modèle, c’est avant tout la représentation d’un problème métier.

En d’autres termes : on ne peut pas modéliser correctement sans une collaboration étroite entre développeurs et experts métier. Les meilleurs modèles émergent toujours d’activités de découverte partagée, où les idées circulent librement entre les deux mondes.

Les racines du problème

Cependant, la perception du métier de développeur est souvent différente de la réalité. Depuis les débuts de l’informatique — et plus particulièrement en Europe — les développeurs sont souvent considérés comme de simples exécutants. Autrement dit, leur rôle est rarement perçu comme fortement créateur de valeur. Dans cette logique, il paraît donc "rationnel" d’externaliser le développement vers des pays à moindre coût. Pourtant, les experts métier, eux, sont rarement délocalisés.

Ce décalage introduit inévitablement des complications dans les échanges : barrière de la langue, décalage horaire, différences culturelles, voire écarts de compétences. Autant de facteurs qui nuisent à la collaboration étroite entre métier et technique, pourtant essentielle à la réussite d’un Model-Driven Design.

Et si tout avait commencé avant ?

La balle est (aussi) dans le camp des écoles

Les difficultés de modélisation prennent racine dès la formation. Les écoles d’ingénieurs, les facs d’informatique forment des étudiants brillants techniquement — mais souvent déconnectés de la réalité métier.

Bien sûr, il faut maîtriser les bases : algorithmes, programmation, systèmes d'exploitation, etc. Mais cela ne suffit pas. En tant que développeurs, notre rôle ne se limite pas à écrire du code : il s'agit aussi de comprendre les besoins métier, là où ils prennent vie — dans leur contexte réel. Car sans besoin, pas de produit. Et sans produit… pas de développeur.

Malheureusement, trop d’étudiants choisissent l’informatique pour éviter les interactions humaines. L’écran devient alors un refuge, une barrière protectrice. Ils sont parfois réservés, ou au contraire affichent une grande confiance dans leur capacité à développer seuls un algorithme "juste". Pourtant, la singularité de leurs solutions — souvent brillantes mais inutilement complexes — rend le code difficilement maintenable et peu lisible pour les non-initiés. On se souvient des dérives de certains modèles éducatifs, comme celui de l’école 42, où la valorisation des élèves repose essentiellement sur la performance individuelle. Arrêtons-nous un instant sur le concept de la piscine, où des personnes en reconversion devaient, seules, résoudre des problèmes qu’elles n’avaient jamais appris à aborder. Cette forme de sélection darwiniste, fondée sur la performance individuelle et la complexité technique, ne favorise ni le respect mutuel ni la collaboration nécessaire à une véritable co-construction avec les experts métier. La Piscine est une approche conçue par d’anciens élèves de l’EPITA, une école où l’enseignement de l’informatique reste encore très traditionnel — comme dans la majorité des écoles d’ingénieurs. Cela dit, quelques exceptions existent : certains établissements introduisent dès la formation des pratiques modernes comme le Test-Driven Development. Mais elles restent rares.

Un dysfonctionnement systémique

Dans beaucoup d’entreprises, les rôles, les structures et les modes d’organisation se répètent à l’identique. Même schémas, mêmes dynamiques, mêmes réflexes. Côté développement, les biais de confirmation font discrètement leur œuvre. Résultat : une culture qui freine le changement, notamment dans la manière d’aborder les problèmes. On redoute l’erreur, on stigmatise l’échec dès la première tentative… là où les Anglo-Saxons, eux, voient une étape normale – voire nécessaire – de l’apprentissage. C’est bien là que le bât blesse : explorer, itérer, recommencer… tout cela est indispensable pour affronter la complexité. Or, les équipes informatiques se retrouvent souvent face à des problèmes épineux, qui exigent du temps, de la patience et le droit à l’erreur. Les forces à l’œuvre dans l’entreprise s’appuient souvent sur des règles socio-culturelles qui dépassent la conscience individuelle. C’est une forme d’héritage silencieux, qui dispense trop souvent de remettre en question des principes ou des valeurs d’un autre temps.

Changer de perspective pour changer la culture

Mais imaginez un instant un enseignement différent : des pédagogies inspirées de Training From The Back Of The Room: c’est passer de “Je parle, tu écoutes” à “Tu parles, tu partages, tu apprends.” Dans un cadre pédagogique dynamique, l’audience est répartie en petits îlots de 4 à 5 personnes, chacun équipé d’un tableau pour réfléchir et visualiser ses idées. Les groupes partagent ensuite leurs solutions entre eux, pendant que l’instructeur, en retrait, se contente de faciliter les échanges.

Dans la même veine, les étudiants pourraient s'enquérir de quelques ateliers de découvertes:

  • L’Event Storming de type __Big Picture__ est sans doute l’atelier le plus structurant pour découper un domaine métier en sous-domaines. Pour des étudiants en informatique, cette prise de recul est essentielle : elle éclaire la manière dont ils peuvent se projeter dans leur futur métier.
  • L’atelier de Story Mapping est un excellent moyen de visualiser les besoins sous forme de récits comportementaux. Sa force : aller à l’essentiel en ne retenant que les stories à fort impact pour les utilisateurs. Il montre qu’un produit se construit avant tout par la valeur qu’il génère dans la vie des usagers. Pour des étudiants en informatique, cette prise de conscience est clé pour intégrer pleinement la notion de valeur dans la conception d’un produit.
  • L’Example Mapping est un atelier collaboratif qui permet de distiller visuellement les besoins métier d’une user story à partir d’exemples concrets. En 25 minutes, il illustre parfaitement la transition des exigences métier vers l’équipe de développement. Encore une fois, un format visuel et collaboratif qui aide les étudiants à affiner leurs compréhensions des comportements métier attendus.

En découvrant une facette plus collaborative du métier — fondée sur le dialogue, la co-modélisation et l’échange avec les parties prenantes — et en s’initiant au Model-Driven Design, les étudiants changent de regard sur leur futur rôle. Ce changement de paradigme peut profondément transformer la culture des entreprises, en réconciliant enfin métier et technique.

Pensée finale

Peut-on vraiment dire que le Model-Driven Design est une chimère ? Ou bien reste-t-il un espoir, celui de voir les organisations informatiques agir autrement — cesser d’avoir peur, apprendre à ralentir pour mieux avancer ?

Apprendre à apprendre s’inscrit dans le temps long. Ce n’est pas une course effrénée à la livraison de fonctionnalités, mais une démarche patiente, lucide. Tout commence par une bonne compréhension du besoin métier : sans cela, on prend le risque de construire un produit inutile. Les pratiques permettant de qualifier les besoins de manière visuelle et collaborative sont précieuses — et présentes dans de nombreux domaines.

Ce qui fait encore cruellement défaut, en revanche, ce sont des équipes véritablement orientées modélisation, capables de faire vivre cette collaboration dans la durée, de rendre les concepts métier tangibles, tout en développant les comportements attendus. C’est là le dernier obstacle à franchir : l’inconscient collectif peine encore à envisager une collaboration active des métiers dans les phases conceptuelles. C’est donc ce verrou qu’il faut faire sauter. Tant que ce sujet ne sera pas compris et porté, le Model-Driven Design restera une chimère.

Références