La normalisation des données : un problème de sémantique
Comment concevoir ces interfaces d'échange, dans le cas du projet ?
Jusqu'au début de 1999, il fallait obligatoirement que les éditeurs de logiciels s'entendent deux à deux pour développer des interfaces spécifiques. Car il n'existait pas de dictionnaire, chaque langue parlée étant réputée être unique pour un logiciel existant !
Le constat suivant est encore d'actualité :
Le transfert des données est qualifié de "douloureux". Il l'est au moins à deux titres :
Pour le développeur de ces interfaces, c'est à dire chaque concepteur de logiciels métiers qui a bien voulu, quelque fois contraint, ouvrir son logiciel. La maintenance de ces interfaces, souvent complexes, constitue un frein économique et technique à la diffusion des logiciels. Il faut gérer la combinatoire des versions du logiciel avec chacune des interfaces (qui comporte séparément une lecture et une écriture) vis à vis de l'évolution non maîtrisable des logiciels interfacés. En pratique, cette solution ne dépasse pas deux ou trois possibilités de communication directe. Cela reste du « sur mesure ».
Pour l'utilisateur aussi. Celui-ci est confronté à une recherche continuelle de logiciels "compatibles" avec les siens. Et quand il en a trouvé un, il s'aperçoit que les données transmises subissent une "perte d'information", dont les causes sont diverses. Bien souvent, il n'y a pas d'autres solutions que la re-saisie des données.
Ce constat encore valable explique le frein à la diffusion des logiciels métiers. Il explique aussi que les grands éditeurs de logiciels de CAO et de calcul dans le bâtiment développent des interfaces « internes », des Building Information Modeling « propriétaires », pour le confort de leurs clients. Qui deviennent alors dépendants d'un seul éditeur. Car un BIM propriétaire est le contraire d'une norme. A moins que l'idée, purement stratégique et commerciale, soit d'imposer dans le monde « sa norme ». Guerre d'influence en perspective !
Afin que :
chaque utilisateur puisse garder cette précieuse indépendance,
chaque éditeur puisse développer des logiciels compatibles avec les logiciels mondiaux du secteur du bâtiment, connus ou à venir,
les échanges des données d'un projet soient toujours possibles quelque soit le métier et la spécialisation de ses logiciels,
des efforts de recherche considérables portant sur les modèles conceptuels, chargés de numériser les aspects du bâtiment ont été engagés dans de nombreux pays, dont la France, mais aussi aux États-Unis. En vue de créer une norme.
C'était urgent pour les logiciels graphiques, et en particulier pour ceux des architectes, qui constituent le point d'entrée de toute la chaîne informatisable.
Remarque :
En l'absence de standard d'échanges entre les différents outils informatisés des métiers du bâtiment, les éditeurs de logiciels sont obligés de développer des interfaces sur mesure, sortes de verrues associées à leurs logiciels, uniquement exploitables pour un logiciel cible connu par avance. Cet investissement peu productif, la gestion de la combinatoire des solutions, la difficulté de la maintenance de ces « verrues », conduisent à l'impossibilité d'échanger économiquement les données techniques d'un projet entre les partenaires d'une opération. |  L'impasse : la multiplication des interfaces |
Une description normalisée qui permettrait d'intégrer tous les aspects du projet, puis la possibilité pour les logiciels métiers d'accéder à cette information, sont les deux préalables à l'objectif recherché.
Il s'agit donc d'inventer un langage définissant la description des ouvrages et composants ainsi que l'environnement méthodologique du bâtiment.
Ce langage concerne les informaticiens qui développent des interfaces et des logiciels, mais surtout les professionnels des différents métiers qui utiliseront ces logiciels. Tous doivent donc être d'accord sur les définitions des éléments physiques et méthodologiques, et ce qui complique la tâche, en plus observés selon leur vue métier.
Réussir ce qui devient « une norme d'échange informatisé dans le secteur de l'AEC » implique donc que le monde entier s'entende enfin sur une unique définition professionnelle, un standard universel d'une portée indiscutable, reconnue par exemple par l'organisme international qui fait force de loi : l'ISO[1].
On imagine la complexité et la difficulté pour aboutir à un tel résultat, quand on connaît les défauts structurels du secteur du bâtiment : la fragmentation des métiers, et l'état artisanal des techniques et méthodes. Un constat négatif : la difficulté existante pour les professionnels de parler un même langage technique, en dehors de toute contrainte informatique !
Et pourtant cet accord sur une norme commune du secteur du bâtiment a pu se réaliser, sans douleur, et il faut bien le dire, presque à l'insu de la majorité des professionnels concernés. Ils ont accepté la démarche de normalisation par ce qu'elle est imposée par les besoins des techniques informatiques.
Le résultat dépasse pourtant les besoins d'échange de données informatisé. L'informatique est en train d'imposer au niveau mondial un dictionnaire des ouvrages et composants du bâtiment.
Pour espérer une mise en place rapide du premier objectif, les échanges, et rendre irréversible par voie de conséquence l'adoption d'une norme descriptive mondiale, deuxième objectif, il faut continuer d'agir à la fois sur :
l'évolution du standard à l'étude (les modèles conceptuels, les formats d'échange),
les systèmes techniques d'échange et d'archivage (les outils logiciels, interfaces, bases de données et langages d'accès),
la méthodologie (l'évolution des méthodes existantes) autour des opérations de construction (ne pas sous estimer la difficulté de changer les habitudes de conduite des études !),
et à toutes les étapes de la vie d'un bâtiment : CONCEPTION – INGÉNIERIE – CONSTRUCTION – MAINTENANCE – RÉHABILITATION - GESTION DE LOCAUX - GESTION TECHNIQUE DE PATRIMOINE IMMOBILIER (GTP) - GESTION ADMINISTRATIVE DE PATRIMOINE IMMOBILIER.
