Analyse
Cette phase s’inscrit dans la continuité directe du travail sémantique.
Elle ne consiste pas à produire une liste exhaustive de fonctionnalités ou à décrire des comportements applicatifs au travers d’écrans, de workflows ou de cas d’usage. Elle vise avant tout à structurer le système autour du métier, en s’appuyant sur un langage désormais stabilisé et partagé.
C’est ici qu’intervient une rupture méthodologique importante.
Dans de nombreux projets, la spécification fonctionnelle devient progressivement un empilement de descriptions littérales, souvent très détaillées mais difficilement exploitables. Le système y est décrit au travers de ce qu’il doit faire, sans que soit réellement clarifiée la nature profonde des objets qu’il manipule.
Cette approche produit fréquemment des architectures instables, car les fonctionnalités évoluent plus vite que la compréhension du domaine qu’elles tentent de représenter.
L’approche inverse consiste à considérer qu’avant même de définir les comportements d’un système, il faut d’abord définir sa structure métier fondamentale.
Autrement dit : avant la fonction, il existe l’objet.
Une fois les termes clarifiés lors du travail sémantique, il devient possible d’identifier les entités métier possédant une identité propre, de structurer des agrégats cohérents garantissant la stabilité fonctionnelle, et de formaliser des règles de gestion explicites indépendantes des implémentations techniques futures.
Le système n’est alors plus décrit en phrases. Il commence à être décrit en structures. Cette transition est essentielle.
Elle marque le passage d’une logique documentaire vers une logique de modélisation. Le projet cesse progressivement d’être une accumulation de spécifications pour devenir une représentation cohérente du réel métier.
Cette démarche s’inscrit naturellement dans les principes du Domain-Driven Design (DDD) introduits par Eric Evans.
Le DDD repose sur une idée particulièrement puissante : le modèle logiciel doit être une traduction fidèle du domaine métier.
Dans cette perspective, les concepts d’Ubiquitous Language, de Bounded Context ou encore d’agrégats métier ne sont pas de simples abstractions théoriques. Ils deviennent les mécanismes permettant de préserver la cohérence du système dans le temps.
Sans travail sémantique préalable, ces concepts restent souvent artificiels. Avec une sémantique maîtrisée, ils deviennent opérationnels.
C’est précisément ce qui permet de réduire la complexité structurelle des systèmes modernes.
Lorsque les frontières métier sont clairement établies, les architectures techniques deviennent naturellement plus lisibles. Les APIs s’alignent sur les responsabilités réelles du domaine. Les microservices cessent d’être des découpages arbitraires. Les événements métier deviennent compréhensibles. Les règles de cohérence trouvent enfin un périmètre clair.
La spécification fonctionnelle cesse alors d’être un simple livrable documentaire. Elle devient un véritable acte de conception.
Là où une approche classique décrit ce que doit faire le système, cette approche cherche d’abord à structurer ce qu’est réellement le métier, afin de laisser émerger naturellement ce que le système devra devenir.
Pour aller plus loin:
Le livre de référence incontournable reste “Domain-Driven Design: Tackling Complexity in the Heart of Software” de Eric Evans, qui pose les fondations du Domain-Driven Design moderne et introduit les notions d’Ubiquitous Language, d’agrégats et de Bounded Contexts.
Les travaux de Martin Fowler autour de la modélisation métier et de l’architecture d’entreprise constituent également une lecture essentielle, notamment ses articles sur les Bounded Contexts et la cohérence des modèles distribués.
Enfin, “Implementing Domain-Driven Design” de Vaughn Vernon propose une approche beaucoup plus opérationnelle du DDD appliqué aux architectures modernes distribuées, microservices et systèmes événementiels.
