La maquette numérique du Bâtiment : une convergence internationale

Par quel moyen deux logiciels peuvent-ils communiquer ?

La boutade ci-après résume bien le deuxième problème technique :

Un logiciel, pour fonctionner, organise quatre types d'information, à l'image de ce qui se passe dans la tête d'un professionnel pour résoudre un problème sans l'aide d'informatique :

Les données externes, que l'utilisateur apporte (les données du problème). Il s'agit non seulement des données propres au projet, qu'il faut décrire au logiciel, mais aussi les données propres au métier et qui seront prises en compte par le logiciel, s'il est assez « intelligent » pour les traiter. La base de données projet[1] du logiciel, c'est à dire la représentation et les transformations des données que le logiciel effectue (dont l'organisation est formalisée par ce que l'on appelle le modèle conceptuel[2] statique). Les procédures de traitement, c'est à dire le raisonnement interne, les calculs que le logiciel effectue selon des instructions et des connaissances que son auteur a imaginé, stockés et automatisés pour lui (le modèle conceptuel[2] dynamique du traitement, écrit dans un langage de programmation). Les résultats produits, supposés être communicables à une tierce personne (documents ou fichiers exportables).

La connaissance et la mémoire

Le problème de la communication entre deux logiciels revient à rendre compatibles les résultats de l'un, pour qu'ils deviennent les données externes du suivant, et éventuellement dans le sens inverse.

Bien évidemment, c'est la plupart du temps impossible, et l'auteur du logiciel n‘a souvent même pas envisagé cette possibilité !

Une solution consisterait à résoudre le problème à la source : adopter une sorte de langage de programmation pour tous les logiciels spécifiques du domaine du bâtiment. Les objets informatiques manipulés et stockés en mémoire correspondraient aux composants et ouvrages du bâtiment. Les langages orienté objet^[3] permettent cette performance.

Mais il est impossible d'imposer aux développeurs un langage de programmation et des bases de données internes structurées identiquement pour tous. Il faut donc accepter de laisser à chaque auteur de logiciels la liberté complète d'imaginer et de structurer sa propre base de données représentative du bâtiment.

A chacun son modèle conceptuel interne, résultat de sa façon de voir et de traiter.

Il faut donc se résoudre à la boutade, qui précise que la seule solution réside dans le développement d'excroissances associées à chaque logiciel : une (ou plusieurs) interface^[4] de communication, qui exploitent un langage commun extérieur aux logiciels, susceptible de véhiculer du sens (de la sémantique).

Et c'est ce langage qui pose problème dans le bâtiment, comme pour deux personnes étrangères qui ne parlent pas la même langue. Il leur faut une interface pour se comprendre. Dans le meilleur des cas, c'est un interprète qui en fait joue deux rôles pour chacun : il écoute, puis il parle. Ce qui fait quatre fonctions d'échange dans le système d'information qu'ils forment entre eux.

Une solution plus économique consiste pour chaque candidat à la communication à s'équiper d'un dictionnaire, muni des deux sens possibles. Mais c'est plus long et difficile.

Ces principes sont à la base des interfaces de chaque logiciel, pour lesquels on distingue une interface^[4] d'entrée, et de sortie.

Les quatre fonctions des interfaces.