Les difficultés d'échange des données selon les représentations graphiques
La présente unité de cours a pour objectif d'essayer de théoriser pourquoi certains échanges de données se révèlent difficiles dans la pratique. A partir d'un modèle conceptuel unique, les logiciels métiers doivent en effet reconstruire une représentation conforme à leur modèle interne. Le plus souvent ce modèle « propriétaire » est à l'image de la représentation graphique utilisée dans le métier : filaire pour le calcul de structure, locaux (espaces) pour le calcul thermique, composants pour l'architecte, et composants et ouvrages pour l'économiste.
Il s'agit donc bien pour le besoin des échanges, de transformer une représentation graphique en une autre, à partir d'une extraction du modèle conceptuel général hébergé dans une maquette numérique unique.
Les difficultés d'extraction d'une structure graphique peuvent avoir trois sources :
il manque des informations conceptuelles (concepts) dans la maquette numérique,
ou bien cette information prévue dans le modèle n'a pas été remplie, n'a pas été saisie par l'émetteur (la case est « vide », ce qui sera souvent le cas pour des relations),
ou encore c'est le développement algorithmique de l'interface IFC qui est en cause.
La difficulté est prise dans le sens d'automaticité de la procédure. Il est évident qu'il est impossible d'envisager les échanges des données techniques du projet si cette opération n'est pas complètement automatisée par les logiciels concernés.
Dans une période de transition, on peut admettre que l'opérateur puisse intervenir ponctuellement pour « réparer » des incohérences ou des oublis dans les échanges.
Mais les éditeurs de logiciels doivent impérativement faire disparaître ces freins à court terme, pour permettre une interopérabilité réellement performante.
Malgré toute la compétence de développement des éditeurs, l'automaticité ne sera pas toujours réalisable à 100 %, car il semble bien exister des incompatibilités « structurelles ».
C'est-à-dire que même en les complexifiant, tout en restant dans le domaine du raisonnable, il est impossible à un éditeur d'écrire dans une interface[1] de communication un algorithme de transcription du projet d'un logiciel vers un autre, sans intervention manuelle de l'opérateur.
Ce qui diminue le bénéfice économique de l'utilisation de procédures informatisées.
Dans le contexte d'une norme, le danger serait de proposer une structure d'échange "qui ne marche pas", c'est-à-dire d'avoir oublié de mettre en évidence les limites d'application de cette structure (de données) au sein d'un modèle conceptuel[2].
