Quand développeurs et experts métier parlent la même langue

Le mot qui a failli couler un projet

Un promoteur demande une application de suivi de "lots". Pour lui, un "lot" c'est un appartement. Pour le développeur, c'est un lot technique (corps d'état). Pendant 6 semaines, les deux équipes ont travaillé en pensant parler de la même chose. Coût : 3 mois de retard et un budget doublé.

Ce n'est pas un cas isolé. Dans chaque projet applicatif métier, il y a des mots piégés. Un "dossier" en promotion immobilière n'est pas un "dossier" en copropriété. Une "opération" chez un promoteur n'est pas une "opération" chez un constructeur. Et dès qu'un mot est interprété différemment par deux personnes, le projet dérive silencieusement, jusqu'à la catastrophe en recette.

Le principe est simple

L'Ubiquitous Language (langage ubiquitaire), c'est l'idée que tout le monde utilise les mêmes mots pour les mêmes choses. Et ce vocabulaire, c'est celui du métier. Pas un vocabulaire technique qu'on impose aux utilisateurs. Pas un vocabulaire commercial qu'on impose aux développeurs. Le vocabulaire métier, partagé du client au code.

Concrètement : si votre métier appelle ça un "lot technique", le nom de la classe dans le code sera LotTechnique, pas ItemGroup ou Category. Si votre métier parle de "situation de travaux", l'entité sera SituationTravaux, pas Invoice. La discipline est stricte mais le bénéfice est énorme : tout le monde peut relire le code, pointer une incohérence, demander une évolution dans son propre langage.

Comment on le construit

1. On liste les termes métier

Devis, métré, lot, ouvrage, DPGF, consultation, situation, décompte général définitif, avenant, avance forfaitaire, retenue de garantie. Chaque terme qui revient 3 fois ou plus dans les échanges métier entre dans le glossaire.

2. On les définit ensemble

Chaque terme reçoit une définition validée par tous : experts métier, développeurs, product owner, direction. Les points de désaccord sont identifiés et résolus au plus tôt, pas en cours de dev. Ce travail collaboratif prend typiquement 1 à 2 jours d'ateliers.

3. On les utilise partout

Dans les mails, les specs, l'interface utilisateur, les noms de classes dans le code, les noms de tables en base, les labels de tickets JIRA. Un terme = un sens = partout. Aucune traduction cachée.

4. On fait évoluer le glossaire

Le langage ubiquitaire n'est pas figé : quand on découvre une ambiguïté, on ajuste. Quand un nouveau concept métier émerge, on l'ajoute. Le glossaire vit avec le produit.

Les 4 bénéfices concrets

Moins de malentendus projet

Les erreurs de traduction entre métier et tech disparaissent. Les équipes gagnent un temps considérable en réunions : plus besoin de réexpliquer les mêmes concepts à chaque sprint.

Onboarding accéléré

Un nouveau développeur découvre le métier à travers le code. Un nouvel expert métier comprend l'application en lisant les noms des écrans et fonctionnalités. Le temps de ramp-up est divisé par 2.

Documentation vivante

Le code devient une documentation du métier. Pas besoin de maintenir un document séparé qui deviendra obsolète. Le code EST la documentation.

Évolutions plus sûres

Quand le métier évolue (nouvelle réglementation, nouveau processus), on sait exactement où intervenir dans le code. Les refactorings deviennent sûrs et rapides.

Pourquoi c'est crucial

Un Ubiquitous Language bien défini réduit les malentendus de 80% en moyenne. C'est le ratio le plus rentable de toute la méthodologie DDD. Pour un coût négligeable (quelques ateliers en amont), vous évitez les dérives projet qui coûtent des mois de retard et des budgets doublés.

Dans un projet applicatif BTP ou immobilier, où le vocabulaire est ultra-spécifique et où la moindre ambiguïté coûte cher, c'est la discipline qui fait la différence entre un projet qui réussit et un projet qui s'enlise.