Les formats d'échanges : "la raison du plus fort"
La multiplicité et la diversité des couches d'informations nécessaires pour décrire le « réel » ont induit, au fil du temps, l'hétérogénéité et l'incompatibilité (au moins partielle) des modes de représentation numérique de cette information (i.e. des formats de fichier). Pour s'en convaincre, il suffit de consulter une des nombreuses listes des formats existants que l'on trouve sur internet. Sans représentation standard (i.e. universelle) de l'information, les éditeurs et donc les utilisateurs sont condamnés à jongler entre des schémas de représentation de l'information qui sont différents. Dans ces conditions l'interopérabilité devient alors un véritable casse-tête, entre ressaisies manuelles et utilisation de logiciels spécialisés dans la conversion de fichiers d'un format à l'autre.
Exemple :
llustrons nos propos par un exemple concret :
Grâce au logiciel AutoCERCLE (n°1), nous allons dessiner un cercle de centre (X,Y,Z) et de diamètre D. Nous voulons ensuite transmettre ce cercle à un collaborateur qui n'utilise que le logiciel de dessin ArchiCERCLE (n°2). Malheureusement, ces logiciels sont incapables de dialoguer nativement dans une même langue commune, c'est à dire dans un même format de fichier. Plusieurs solutions s'offrent à nous pour contourner ce problème :
L'éditeur AutoCERCLE a mis au point une interface d'export qui nous permet d'enregistrer notre cercle dans un fichier au format natif de ArchiCERCLE, lisible par notre collaborateur.
L'éditeur ArchiCERCLE a mis au point une interface d'import qui permet à notre collaborateur d'importer directement un fichier au format natif de notre logiciel AutoCERCLE.
Les éditeurs des logiciels AutoCERCLE et ArchiCERCLE n'ont pas prévu d'interfaces d'import/export mais un logiciel spécialisé, que nous-même ou notre collaborateur possédons permet de réaliser cette conversion.
Aucune des solutions semi-automatisées décrites précédemment ne sont envisageables. Par conséquent, nous imprimons un plan du cercle, afin que notre collaborateur puisse le ressaisir correctement dans son propre logiciel de dessin, une opération fastidieuse et source d'erreurs.
Comme nous pouvons le constater, l'interopérabilité est sujette à caution et dépend actuellement du bon vouloir des éditeurs qui sont, pour des raisons commerciales, peu enclin à proposer des interfaces d'import/export fiables. L'arrivée des IFC comme format de fichier partagé, ouvert, et évolutif offre enfin une solution satisfaisante à ce problème majeur en proposant un langage commun et complet pour l'échange des informations relatives au secteur de la construction.
Nous venons d'évoquer le problème technique majeur (il y en a d'autres) des logiciels traditionnels en AEC : leur difficulté à s'échanger des données.
Quelles en sont les causes ?
La communication est difficile non seulement entre logiciels de métiers différents (par exemple entre ceux des concepteurs et ceux des économistes), mais aussi à l'intérieur du même métier (entre les logiciels différents de CAO[1], DAO[2] de plusieurs architectes, entre ceux des entreprises de gros œuvre et de second œuvre ...)
Les professionnels du bâtiment exploitent des logiciels de DAO, CAO, d'imagerie, de calcul thermique, de calcul de structure, de calcul et dessin de béton armé, de calcul quantitatif, d'estimation de prix, de calepinage[3], de devis couplés à des plans graphiques, de gestion technique de patrimoine, de maintenance ....
Il existe souvent dans un seul pays, comme la France, entre une dizaine et une cinquantaine de logiciels commercialisés dans chaque métier, sans compter les logiciels "maisons" que les propriétaires ne veulent pas abandonner, car ils répondent "sur mesure" à leurs besoins.
Que dire du nombre de logiciels existants en Europe, et dans le monde !
Le premier problème technique est donc le grand nombre de logiciels différents existant sur le marché, ce qui interdit tout espoir d'une concertation directe entre les auteurs de ces logiciels pour une entente sur un moyen de communication.
De plus, chaque éditeur a conçu le cœur de son outil, c'est-à-dire l'organisation de l'information interne du logiciel, comme il l'entendait. Cette structure d'information obéit à une logique, une vue réduite à son propre métier, et de plus limitée aux seules fonctionnalités envisagées.
Autant dire que dans ces conditions faire en sorte que deux logiciels puissent parler un même langage interne relève de l'impossible.
