Analyse

Bien avant l’architecture, les spécifications ou les choix technologiques, un projet repose sur une matière beaucoup plus fondamentale : les mots.

C’est souvent ici que naissent les premières fragilités.

Dans de nombreux programmes Data, IA ou SaaS, les difficultés ne proviennent pas d’un manque de compétences techniques. Elles apparaissent lorsque les acteurs du projet utilisent les mêmes termes sans leur attribuer exactement le même sens.

Un “client”, une “commande”, un “produit”, un “incident” ou un “document” peuvent désigner des réalités très différentes selon les équipes métier, les applications existantes ou les habitudes opérationnelles.

  • Le problème est rarement visible au départ.

  • Les réunions semblent fluides.

  • Les spécifications avancent.

  • Les ateliers produisent des documents cohérents en apparence.

Puis progressivement, les interprétations divergent. Les modèles deviennent incohérents. Les règles métier se contredisent. Les interfaces s’alourdissent. Les équipes commencent à compenser des ambiguïtés conceptuelles par de la complexité technique.

Le système devient alors difficile à maintenir non pas parce qu’il est techniquement mauvais, mais parce qu’il repose sur une représentation floue du métier.

Cette étape repose sur une conviction forte : éviter les biais initiaux et poser un cadre méthodologique partagé.

Comme l’écrivait Nicolas Boileau :

« Ce qui se conçoit bien s’énonce clairement, et les mots pour le dire arrivent aisément. »

Cette idée reste profondément moderne dans le monde du logiciel.

Formaliser un langage commun n’est pas un exercice documentaire secondaire.
C’est une étape structurante. Dans cette logique, la mise en place d’un dictionnaire sémantique devient un véritable levier d’accélération.

Avant même d’aborder les spécifications fonctionnelles, il devient essentiel de définir précisément les concepts métier, d’aligner les parties prenantes sur un vocabulaire commun et d’éliminer les ambiguïtés structurelles qui contaminent ensuite toute la chaîne de conception.

Sans ce travail préalable, les spécifications dérivent rapidement vers un empilement de formulations littérales interprétées différemment selon les acteurs. Le document grossit. La précision apparente augmente. Mais la compréhension réelle diminue.

La sémantique permet précisément d’éviter cette dérive. Elle transforme un ensemble de formulations parfois implicites en un langage opérant, compréhensible à la fois par les équipes métier, les architectes, les développeurs et les décideurs.

Cette approche rejoint directement les principes du Domain-Driven Design introduits par Eric Evans autour du concept d’Ubiquitous Language.

L’idée est simple : un même terme doit porter le même sens dans les discussions, les spécifications, les modèles métier, les APIs, les bases de données et le code lui-même.

Sans cela, l’ambiguïté finit toujours par se transformer en dette technique silencieuse.

Cette problématique peut être rapprochée du paradoxe du bateau de Thésée.

Si chaque composant d’un système est progressivement remplacé, renommé ou interprété différemment, le système conserve-t-il encore son identité initiale ?

Dans beaucoup d’organisations, les projets évoluent pendant des années au travers de nouvelles équipes, de nouveaux besoins, de multiples couches applicatives, de migrations et d’intégrations successives.

Sans socle sémantique stable, le système conserve parfois le même nom… mais plus le même sens.

C’est souvent ainsi que naissent les plateformes devenues difficiles à faire évoluer, coûteuses à maintenir ou conceptuellement instables.

La complexité n’est alors plus uniquement technique.
Elle devient cognitive.

Avant de penser architecture, microservices, IA ou gouvernance data, il faut donc commencer par une question beaucoup plus simple :

Avons-nous réellement défini les mots que nous utilisons ?

Car un projet robuste commence rarement par du code.

Il commence par une compréhension commune du réel.

Pour aller plus loin:

Le concept d’Ubiquitous Language est au cœur du Domain-Driven Design. Il introduit l’idée qu’un système robuste repose d’abord sur un langage partagé entre experts métier et équipes techniques.

Livre de Eric Evans : “Domain-Driven Design: Tackling Complexity in the Heart of Software”.

Les réflexions de Donella Meadows dans “Thinking in Systems”Écrivez votre post ici...