De quoi s'agit-il?

Pratique de conception issue du livre de Eric Evans "Domain Driven Design" (2003), elle consiste notamment à s'attacher à utiliser le vocabulaire et les notions des clients et experts métiers, non seulement dans les discussions autour des exigences, mais également dans le code source.

(D'autres techniques complémentaires sont détaillées dans le livre d'Evans, mais le nom de "langage omniprésent" reflète l'intention principale.)

Quels bénéfices en attendre?

L'un des obstacles couramment rencontré par les projets de développement concerne la difficulté de la traduction entre deux langages techniques, celui des développeurs d'une part, celui des experts métier d'autre part.

Pour une part cette traduction est inévitable: les développeurs doivent s'exprimer en termes d'algorithmes, par exemple, qui n'ont pas nécessairement un équivalent dans le vocabulaire de l'entreprise pour laquelle ils travaillent.

Cependant on constate souvent que ce vocabulaire du logiciel "déborde" du cadre dans lequel il est justifié, au point que les interlocuteurs des développeurs se sentent démunis, voire aliénés, lors des conversations avec ces derniers.

L'adoption explicite et délibérée d'un "langage omniprésent" permet de mitiger ces difficultés et représente donc un facteur de succès d'une approche Agile.

Origines

• dans les premières années, Kent Beck tente de populariser une pratique d'Extreme Programming appelée "Métaphore"; celle-ci est rarement utilisée car mal comprise (2000 environ)

• le terme "langage omniprésent" apparaît avec le livre de Eric Evans (2003)

• un consensus s'établit ensuite pour ne plus parler de "Métaphore", et remplacer cette pratique par les recommandations, jugées plus précises, de Eric Evans concernant ce "langage omniprésent" (2004)