Ou quand, dans vos projets, on parle plus de tables, de flux et de programmes que du métier lui-même.

La scène est familière.

Une réunion réunit des experts métier et des équipes techniques pour discuter de l’évolution d’un système. Très vite, la conversation dérive : on parle de tables, de colonnes, de flux batch, de champs obligatoires. Les développeurs expliquent comment le système fonctionne, et les experts métier tentent de suivre. Peu à peu, la discussion ne porte plus vraiment sur le métier lui-même, mais sur la manière dont il peut s’adapter aux structures du système existant. Le système existant devient alors la grille de lecture à travers laquelle le métier est reformulé. Les questions ne sont plus « comment fonctionne le métier ? », mais « comment faire entrer ce besoin dans la structure actuelle du système ? ». Le domaine disparaît derrière les artefacts techniques.

On pourrait penser que ce phénomène n’est pas grave lorsque des équipes techniques discutent entre elles. Après tout, entre développeurs, parler technique semble naturel. Mais même dans ce cas, un glissement peut apparaître. Les discussions devraient porter sur les capacités exposées par les systèmes et sur les contrats qui permettent aux équipes d’interagir. Pourtant, il arrive que les équipes parlent surtout de leurs tables, de leurs fichiers ou de leurs structures internes — des détails que chaque système devrait normalement encapsuler. Dans une architecture bien conçue, les échanges entre équipes devraient porter sur les capacités exposées par les systèmes et sur leurs contrats d’interaction. Les structures internes — tables, fichiers ou modèles de données — devraient rester encapsulées à l’intérieur de chaque système et ne pas apparaître dans ces interactions. Cette idée se retrouve notamment dans les approches décrites par Team Topologies, où les équipes interagissent à travers des interfaces claires plutôt qu’à travers les détails d’implémentation de leurs systèmes.

Le symptôme le plus frappant apparaît lorsque les experts métier eux-mêmes commencent à adopter ce langage. Dans certaines réunions, on peut entendre des experts métier dire :

« Il suffirait d’ajouter une colonne. »

« On peut mettre un flag dans la table. »

« On fera un batch pour corriger ça. »

À ce moment-là, quelque chose a basculé. Le logiciel n’est plus seulement un outil pour représenter le domaine : il est devenu le cadre à travers lequel le domaine lui-même est pensé.

Ce phénomène a été décrit dès 1973 par le sociologue norvégien Stein Bråten sous le nom de Model Monopoly. Il désigne une situation où un modèle devient le cadre dominant à travers lequel un système se comprend lui-même. Les autres manières de représenter la réalité deviennent alors difficiles à exprimer — non pas parce qu’elles seraient fausses, mais parce que le modèle dominant structure déjà la manière dont les problèmes sont formulés.

Dans les systèmes d’information, ce monopole peut facilement apparaître lorsque le modèle technique devient le langage principal des discussions. Ce n’est plus seulement un monopole de modèle, c’est une colonisation du raisonnement métier par le modèle technique. Les tables, les flux et les programmes finissent par remplacer les concepts du domaine dans les conversations. Le système ne représente plus le métier : il devient la manière de le penser.

Une des causes de ce phénomène est la confusion entre deux espaces pourtant distincts : l’espace du problème et l’espace de la solution. L’espace du problème correspond au domaine : les concepts métier, les règles, les événements, les contraintes réelles. L’espace de la solution correspond à la manière dont le logiciel implémente ces concepts : bases de données, services, fichiers, flux ou programmes. Lorsque ces deux espaces se mélangent trop tôt dans les discussions, la solution finit par structurer la manière dont le problème lui-même est formulé. C’est à ce moment que les équipes commencent à parler de tables plutôt que de contrats, de fichiers plutôt que d’opérations, de batchs plutôt que d’événements métier.

Cela ne signifie pas que les équipes ne doivent pas partager un langage commun. Au contraire : un langage de travail partagé, ancré dans les concepts du domaine, est essentiel pour permettre la collaboration entre métier et technique. C’est précisément l’idée du Ubiquitous Language en Domain-Driven Design. Mais ce langage devrait décrire le domaine et ses capacités, pas les détails techniques de leur implémentation. Les tables, les flux et les programmes ne sont que des solutions.

Le métier, lui, devrait toujours rester le point d’ancrage des conversations. Car un système qui parle uniquement en termes de tables et de flux finit souvent par oublier ce qu’il était censé représenter : le domaine lui-même.