Par quel moyen deux logiciels peuvent-ils communiquer ? La boutade ci-après résume bien le deuxième problème technique :
Pour communiquer, les logiciels techniques doivent se doter d'une bouche et d'oreilles et parler un même langage dont les mots sont les objets du bâtiment.
A défaut, ils utilisent une sorte d'excroissance, les interfaces, qui provoquent des transferts d’information douloureux .
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 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 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 dynamique du traitement, écrit dans un langage de programmation).
Les résultats produits, supposés être communicables à une tierce personne (documents ou fichiers exportables).
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 à adopter une sorte de langage de programmation pour tous les logiciels spécifiques du domaine du bâtiment. Les objets informatiques manipulés correspondraient aux composants et ouvrages du bâtiment. Les langages orientés objets permettent cette performance. Il faudrait alors que les données et les résultats s’expriment également en composants et ouvrages du Bâtiment.
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.