Un projet collaboratif qui fait primer l'exigence de la communication
Deux approches peuvent exister pour ceux qui étudient une norme :
on étudie une norme, puis on la décrète.
on attend qu'un standard émerge, puis on l'adopte comme norme.
Cette deuxième approche est la plus facile. D'ailleurs, si un standard émerge, il n'y a pas lieu de pousser les travaux pour en faire une norme, la force du standard se suffisant à lui-même. Mais il y a deux inconvénients à se limiter à cette dernière approche.
Le premier est que la technologie du standard n'est pas forcément adaptée au besoin général. Par exemple, les éditeurs de logiciels graphiques concurrents d'Autodesk soulignent les défauts du DXF :
illisible à l'œil, donc difficile à maîtriser pour la mise au point des développements,
redondant et volumineux en code, donc manque d'économie des supports,
grave manque de souplesse pour décrire l'aspect relationnel des entités (mais il n'a pas été « fait pour »).
Le deuxième inconvénient est bien sûr le manque de contrôle des utilisateurs sur l'évolutivité de ce standard, car il dépend entièrement du bon vouloir de la société qui l'a imposé sur le marché.
Un standard peut donc être anti-économique pour certains éditeurs et utilisateurs.
Pour assurer des fonctionnalités plus ambitieuses, il faudra inventer un autre dispositif.
Par exemple le standard DXF (ou DWG) est bien adapté pour décrire une énumération d'objets graphiques, qui se suffit d'une forme numérique syntaxique. Mais il est urgent de franchir une étape supplémentaire de complexité : répondre aux besoins de la communication sémantique des objets du bâtiment, ce qui devient notre préoccupation essentielle pour assurer les échanges entre logiciels techniques.
Au-delà du graphique et de la forme géométrique, limite fonctionnelle du DXF, il s'agit de décrire l'idée abstraite d'un objet, c'est-à-dire son modèle conceptuel[1] réunissant les aspects de l'information utiles aux applications concernées.
L'intérêt général commande l'approche inverse, c'est à dire étudier et décréter une norme, ce qui comporte d'autres risques. Par exemple, ne pas disposer de moyens suffisants pour l‘étudier complètement, l'expérimenter, et la faire connaître (problèmes d'investissements marketing et médiatique). Qui doit investir ?
De plus, avant de "normaliser" dans le domaine des systèmes d'information, il faut disposer du fameux « modèle conceptuel ».
Cette étape préalable pose le problème le plus difficile à résoudre dans le secteur du bâtiment, nous l'avons évoqué : obtenir une adhésion de tous les professionnels d'un pays, puis de tous les pays, sur un même modèle, car la matière à normaliser est internationale.
Fondamental :
Il existe trois actions à mener pour élaborer et mettre en place une norme de communication informatique du bâtiment :
- une étude des besoins professionnels qui ne peut être menée que par les utilisateurs,
- une action purement technique pour que son contenu soit "validé".
- une action purement politique et économique pour aboutir au consensus mondial.
Quelques pays ont pris des initiatives, dont la France (à travers les recherches SUC et CCM) et bien évidemment les USA avec l'IAI, et à l'international l'ISO avec STEP et les IFC. Ces sigles vous deviendront familiers à travers ce cours.
