Traduire, c’est trahir : L’importance des standards partagés dans l’établissement des paramètres

Publié le 17 Janvier 2019 par Vincent Cadoret

Traduire, c’est trahir : L’importance des standards partagés dans l’établissement des paramètres

Le problème

La langue des humains regorge d'ambiguïtés. Prenons, par exemple, la phrase suivante :

Il m’a rapporté des fruits d’Afrique (Merci à Danièle Fleury pour l’exemple)

On pourrait vouloir dire “À son retour d’Afrique, il m’a offert des fruits en cadeau” ou tout simplement “il m’a apporté des fruits qui proviennent d’Afrique”.

Si on peut s'accommoder d’un peu de confusion, la langue des machines, elle, doit être rigoureusement définie et catégorisée, le binaire n’autorisant pas vraiment les zones grises. En l’absence de définitions partagées de la signification d’un paramètre et des valeurs qu’il peut prendre, il est très difficile de programmer des solutions automatisées pour utiliser ou pour exploiter cette donnée.

Le même concept s’applique aux données relatives à la construction. D’expérience, nous savons que sans définition préalable de ce qu’est un paramètre et de ce qu’il devrait contenir, les données BIM ne peuvent pas être transférées entre différents partenaires, encore moins s’ils utilisent différents logiciels. En conséquence, en plus du célèbre et toujours valide principe GIGO, nous faisons face à un autre problème : “traduire, c’est trahir”.

Ce qui existe déjà

Il existe quelques initiatives notables qui visent à régler le problème dont :

Même si ces efforts sont louables, les deux premiers sont liés à un fournisseur et à un logiciel spécifique, ce qui entraîne certains problèmes:

  • Vous êtes menottés à un fournisseur.

  • Vous perdez de l’interopérabilité avec d’autres fournisseurs.

Pour éviter ce menottage, la base de données de définitions partagées devrait être contrôlée par une tierce partie neutre (comme BuildingSMART ou NBS) et être neutre du point de vue du fournisseur.

Cependant, le fait d’avoir une organisation centrale pour gérer la base de données ne vient pas non plus sans problème :

  • Délais dans l’approbation et l’ajout de nouveaux paramètres (ce qui est inacceptable dans le contexte d’un problème où l’on fait face à des dates de tombées).

  • Même si l’organisation est supposée être neutre, elle souffre quand même de quelques biais.

  • Si l’organisation fait faillite, qui se charge de la maintenance des définitions?

La solution?

En ce moment, notre meilleur espoir pour standardiser la définition des paramètre est IFC par BuildingSmart International. La solution est agnostique face aux fournisseurs et elle est aussi neutre qu’il est possible de l’être.

IFC4 possède une longue liste de définitions de paramètres relevant de plusieurs secteurs industriels dont l’architecture, la structure, CVAC, l’électricité et même en gestion immobilière. Le niveau de détail est impressionnant. Par exemple, il existe des définitions pour l’évaluation du niveau de risque, les conséquences des risques et même les instructions d’emballage! Ça nous conduit peut-être vers une discussion à propos de la frugalité de données, mais il s’agit d’un sujet pour un autre article...

Conclusion

Une solution existe déjà pour standardiser nos définitions de paramètres. Elle s’appelle IFC. Bien sûr, elle n’est pas parfaite et elle ne couvre pas 100% des cas d’usage, mais elle couvre certainement les plus communs.

Alors pourquoi est-ce qu’il existe encore tellement “d'ambiguïté paramétrique” dans l’industrie? Est-ce qu’on doit blâmer les fournisseurs qui agissent uniquement dans leurs intérêts? Peut-être que c’est le manque de connaissances à propos du mouvement OpenBIM? Le niveau de maturité BIM de l’industrie est-il assez développé? Est-ce que le besoin de se distinguer et d’emporter la mise nous empêche de collaborer? Ou est-ce que c’est simplement parce que les solutions OpenBIM en place sont trop difficiles à implanter? Notre expérience au sein de l’industrie nous amène à croire que tous ces facteurs jouent un rôle et que cette liste n’est pas exhaustive.

Si l’on revient à la phrase du début du texte, on comprend qu’elle peut être clarifiée lorsque l’on utilise les bons mots pour que “Il m’a rapporté des fruits d’Afrique” sont clairement interprété comme “Il m’a rapporté des fruits qui proviennent d’Afrique”. Toutefois, nous avons besoin, pour ce faire, d’une liste communément admise de mots, un dictionnaire et un peu d’effort de la part de l’utilisateur pour lire le dit dictionnaire.

Tant qu’il y aura des humains impliqués dans le processus de design, nous ne serons pas en mesure d’éliminer complètement l'ambiguïté. Nous devrons peut-être attendre que les avancées de l’Intelligence artificielle (qui est plus à même de gérer l'ambiguïté que les programmes traditionnels) se popularisent dans notre industrie pour qu’émerge une vraie automatisation du BIM.


Vincent Cadoret
Spécialiste BIM