EN RESUME
360SmartConnect a créé le béton connecté pour lier l’ouvrage à ses data, et dans le même temps aux services qui permettent notamment d’interagir avec ces données. Le lien entre Béton Connecté et BIM, level3 ou supérieur, est donc évident, car à terme la maquette numérique contiendra toutes les données de l’ouvrage.
Cependant il faut avouer que nous sommes encore très loin d’un usage régulier de la maquette numérique cloud qui permettrait des interactions rapides entre tous les acteurs de la chaîne. Nous avons identifié deux freins majeurs à cela : le concept même de centralisation et le défaut de confiance dans le système.
Aussi il est légitime de se demander si les techniques actuelles d’API et de Blockchain ne pourraient pas aider à accélérer l’adoption du BIM dans une logique CLOUD ? C’est la question que nous allons nous poser lors d’une table ronde du salon BATIMAT avec des acteurs du BIM et de la Blockchain.
La Table ronde « Béton Connecté et Blockchain au service d’un BIM decentralisé » se tiendra donc le 08 novembre 2017, 14:00 – 14:45, HALL 5A (entrée) | Forum Construire & Rénover Durable à BATIMAT Villepinte
Pour bénéficier d’une invitation gratuite, inscrivez vous sur ce site (lien https://badge.lemondialdubatiment.com/?codePromo=BEE3041645 ) avec le code BEE3041645
EN VUE DE LA TABLE RONDE DU 8 NOVEMBRE EN MARGE DE BATIMAT
Ce billet n’a pas la prétention d’être dans la plus grande des précisions en ce qui concerne le propos technique. Son but est plutôt de partager un point de vue et de le mettre en débat sur un sujet qui nous tient à coeur et qui nous semble très important pour l’avenir et l’évolution de notre écosystème : celui de la construction et de l’immobilier.
Nous tenons donc par avance à excuser les inexactitudes et les approximations.
BÉTON CONNECTE ET BIM
Pourquoi nous intéressons-nous au BIM? Alors que notre raison d’être est de promouvoir l’utilisation du Béton Connecté, que nous avons créé. Parce que le but du Béton Connecté est de relier les ouvrages à leurs données et à leurs services. Encore faut il savoir quelles données ? Elles peuvent être multiples et de sources très hétérogènes.
La promesse d’organisation des informations faite par le Building Information Management est donc coeur de notre réflexion pour nous. Car nous considérons comme une évolution normale des choses que ces données soient toutes logées dans la maquette numérique de l’ouvrage lui-même.
Ainsi par un jeu de références croisées, nous pouvons relier la pièce, la salle, l’étage, l’ouvrage à son élément fini, avatar digital, correspondant dans la maquette numérique. Le béton connecté est une référence externe rattachée à un élément fini de la maquette, et en retour la référence de l’élément fini de la maquette est une propriété de la pièce béton augmentée par notre procédé.
Le résultat est de permettre d’accéder, depuis le terrain, aux propriétés d’une pièce avec une facilité déconcertante. Il est d’ailleurs tout aussi simple de pouvoir en modifier certains attributs, si besoin.
A partir de là il est assez facile de percevoir les potentiels offerts par l’exploitation de ce lien: L’exemple le plus parlant est sans doute celui du suivi du cycle de vie d’une pièce de préfabrication dans un ouvrage.
« Juste » en posant son smartphone sur la pièce, il est possible de mettre à jour l’état de l’élément fini correspondant dans la maquette numérique, pour déclarer la pièce réceptionnée sur le chantier.
Cela permet d’en optimiser la gestion dans la chaîne de distribution.
Cet état pouvant être: « pièce à livrer », « pièce en cours de livraison », « pièce réceptionnée », « pièce posée » … ce qui en donne au gestionnaire une connaissance instantanée. Il nous est même possible en cas de « réception avec réserve » d’associer la photo du problème à la pièce dans la maquette.
L’intérêt pour le gestionnaire d’un chantier est ici évident. Il l’est tout autant pour le fournisseur dont le système de facturation peut être immédiatement informé de la réception de la pièce. Sans ressaisie manuelle du BL, les process de facturation s’en trouvent sécurisés et accélérés.
Des applications similaires peuvent être tout aussi bien trouvées pour des gestionnaires d’actifs, pendant les cycles d’exploitation de l’ouvrage (bâtiment ou ouvrage TP)
Encore faut-il pour réaliser ce qui est décrit plus haut, de pouvoir interagir en temps réel avec la maquette numérique dans la logique collaborative de niveau 3.
LES FREINS A LA GÉNÉRALISATION DU BIM LEVEL 3
Nous avons constaté, que, malgré tous les efforts et toutes les annonces, nous sommes encore assez loin de la généralisation de la maquette numérique centralisée de niveau 3 et supérieur, qui commence à pointer le bout de son nez dans certaines industries comme l’aéronautique.
Combien de projets sont réalisés actuellement dans le monde en BIM level 3 ?
Difficile à dire, mais il nous semble que cela est encore largement marginal.
Des raisons à cela ?
Il nous semble que le principe même d’une maquette numérique centralisée est à l’origine de ces blocages qui ralentissent son déploiement.
Les freins sont sans doutes nombreux, pour notre part nous en avons identifié deux qui nous semblent majeurs: Ressource d’infrastructure digitale et confiance des acteurs.
UNE MAQUETTE TROP GOURMANDE EN RESSOURCES
Le problème de la ressource d’infrastructure digitale est celui de la taille des données VS les ressources disponibles.
Dans l’absolu compte tenu de l’évolution rapide des systèmes informatiques (cf. loi de Moore : https://fr.wikipedia.org/wiki/Loi_de_Moore ) on peut considérer que d’ici peu la ressource disponible sera suffisante pour pouvoir héberger tous les modèles BIM, y compris celle de gros projets.
Sauf que dans le même temps on assiste à une inflation du volume de données que l’on souhaite enregistrer dans la maquette BIM.
Maquettes qui en conséquence sont de plus en plus volumineuses et donc gourmande en ressources pour leur stockage et leur traitement.
Si bien qu’il est légitime de se demander s’il sera possible un jour d’aligner, dans un cadre usuel, besoin de ressources de stockage et ressources disponibles.
Cette « gourmandise » freine le développement de la maquette numérique centralisée de niveau 3.
Peu de projets ayant les moyens de mobiliser les ressources permettent une unicité de la maquette durant la conception, la réalisation et l’exploitation des projets.
RÉTICENCE A PARTAGER DES INFORMATIONS QUI POURRAIENT ÊTRE SENSIBLES.
Qu’est ce qui est indispensable au quotidien? Qu’est ce qui est utile occasionnellement? Qu’est ce qui relève des informations propres au producteur? Car certaines informations n’ont non seulement pas d’intérêt à être partagées, mais peuvent être délicates à exposer à des confrères ou des concurrents.
Pire au moment du transfert des informations vers une maquette centralisée, il faut se poser la question de la sélection de la nature des informations à transmettre.
Cela entraîne de fait une rupture dans la continuité et l’automatisation de l’information, qui outre d’être contraire d’une logique de bon usage, génère un travail supplémentaire et potentiellement des erreurs.
Pourtant, dans certains cas, par exemple un sinistre, il peut être très intéressant pour toutes les parties de partager la totalité des informations. Ne serait-ce que pour déterminer les responsabilités de chacun ou la bonne foi des uns et des autres.
Vous l’aurez compris ces 2 sujets nous semblent être à l’origine de 2 freins majeurs à l’heure actuelle dans le déploiement du BIM de Niveau 3.
Empêchant par la même de tirer pleinement profit de toutes les opportunités que cette logique d’organisation devrait permettre.
Mais à bien y réfléchir ces deux problèmes ne sont-ils pas vieux … comme le monde informatique.
Et sauf erreur de notre part cela fait longtemps que le monde digital a apporté des réponses efficaces et robustes à celles-ci: la décentralisation et la cryptographie.
VERS UN RÉSEAU DE SERVEUR BIM CONVERSANT VIA DES API.
Ainsi il pourrait être envisagé de créer une maquette maître où chaque objet élémentaire ne serait « qu’une » référence externe vers l’objet correspondant dans le serveur de son producteur.
Tels des X-ref, connues dans le dessin 2D, les informations seraient non pas en local, mais seules les données nécessaires et pertinente seraient récoltées « à la volée » dans un serveur distant, celui de l’acteur responsable de la production aussi bien de l’objet physique, que de son avatar digital.
Ainsi chacun pourrait garder la maîtrise des données qu’il a produit (après tout n’est ce pas le principe du droit d’auteur qui est inaliénable ?)
La maquette centrale, elle n’aurait plus qu’à gérer la synthèse automatique, « en live », surveillant les interactions et conflits, entre les différents éléments finis.
Pour en savoir plus sur les API voir ces vidéos :https://youtu.be/s7wmiS2mSXY ou https://youtu.be/D_XFUE1GeWk
LA BLOCKCHAIN AU SERVICE DE LA CONFIANCE
Comment garantir que la partie des données que j’expose à mon partenaire, via l’API de mon BIM SERVEUR seront toujours les mêmes dans le temps ?
Comment puis je certifier que ces données ne seront pas changées en fonction des besoins ?
Mieux encore n’est il pas possible d’exposer une seule partie des informations, les données publiques, et pouvoir garder pour moi les données sensibles tout en apportant la preuve, non seulement de l’existence de ces dernières mais de leur stabilité dans le temps?
Il nous semble que la cryptographie et la Blockchain sont les réponses idéales à ces questions.
Cette « signature », créée par un algorithme serait unique, de sorte que le moindre changement dans les données entraînerait une différence dans la « signature ».
Il « suffit » donc d’inscrire cette « signature » dans un registre, si possible décentralisé et ultra robuste comme une blockchain, pour l’inscrire dans le marbre.
Lors d’un contrôle la comparaison de la « signature » actuelle et de la « signature » « historique » permettrait de détecter la moindre modification dans les informations exposées.
La confiance serait donc « juste » une question de processus.
Partant de là, un chiffrement des données privées permettrait en plus de pouvoir les exposées à tous, en garantissant ainsi leur existence, sans pour autant les dévoiler.
En cas de besoin, par exemple lors d’un règlement de litige, elles pourraient être dévoilées à un tiers par application d’un décodage.
Pour en savoir plus sur la Blockchain : l’excellente vidéo de science étonnante de David LOAPRE Le Bitcoin et la Blockchain (avec Heu?Reka) — Science étonnante #31 https://youtu.be/du34gPopY5Y
ILLUSTRONS LE PROPOS
Pour mieux comprendre le fonctionnement de ce à quoi nous pensons, avec l’équipe de 360SmartConnect (www.360sc.io), illustrons le propos par un exemple simple. (Nous concédons bien volontiers que l’instanciation complète d’un système fonctionnant sur ce procédé doit être plus complexe.
Regardons donc comment cela pourrait se passer dans la relation entre deux acteurs d’un projet : l’entreprise générale A et le fournisseur B. L’entreprise générale A ayant commandé au fournisseur B, qui se trouve être un préfabriqueur, une poutre en béton.
L’entreprise A possède une maquette dans laquelle est décrite une poutre.
L’élément fini concernant la poutre possède notamment comme propriété, outre les informations les plus usuelles de description géométrique :
– la référence du BIMserveur du fournisseur B
– la référence de la poutre dans le BIMserveur du fournisseur B
– la signature unique de la poutre dans le BIMserveur du fournisseur B
De son côté le Fournisseur B a, dans son BIM serveur, ce même élément fini, outre les mêmes éléments de référence ci-dessus, un ensemble d’informations complémentaires comme:
– la poutre est elle conforme aux exigences d’essais demandés par la norme
– le rapport d’essai de la poutre
– les résistances mécaniques de la poutre
– la formule du béton avec les conditions de coulage …
– des informations relatives au coût de fabrication …
– …
Au moment où le Bureau d’Étude de l’entreprise générale veut s’assurer de la résistance globale de l’ouvrage, un dialogue se ferait entre les deux BIMserveur, via leur API respective:
BIMserveurA: SVP BIMserveurB que peux-tu me dire sur la poutre ?
BIMserveurB: Voici la liste des informations existantes, publiques et privées, et voici la signature unique.
BIMserveurA: Est-ce que la poutre est conforme aux exigences d’essais demandées par la norme ?
BIMserveurB: Oui
BIMserveurA : Puis-je avoir le rapport de test ?
BIMserveurB: NON, je ne vois pas à quoi ça te sert à ce stade.
BIMserveurA : Ok quelle est la résistance de la poutre ?
BIMserveurB: 150Mpa.
BIMserveurA : Quelle est la formulation du béton utilisé?
BIMserveurB: NON, je ne vois pas à quoi ça te sert à ce stade?
…
En cas de sinistre, ce dialogue pourrait se faire, des années plus tard, de la même façon avec un Tiers agréé par les 2 parties:
Exemple l’assureur C, consultant les informations depuis son BIMserveurC.
BIMserveurC à BIMServeurA: D’où vient cette poutre ?
BIMserveurA à BIMServeurC: Du BIMserveurB avec telle ref et telle signature.
BIMserveurC à BIMServeurB : Quelle est la signature de la poutre ref ?
BIMserveurB à BIMServeurC: Voici la signature.
BIMserveurC : Vérifie la cohérence entre les signatures du BIMserveurA et BIMserveurB, puis les compare avec la signature qui remonte de la Blockchain. si ok (il n’y a pas de raison que ça ne soit pas le cas,
car tout le monde est de bonne foi)
BIMserveurC à BIMServeurB : Je suis « BIMserveurC » agréé par A et B pour comprendre ce qui s’est passé dans le sinistre : donne moi le rapport du test.
BIMserveurB à BIMServeurC: Dans ces conditions OK : voici le rapport du test.
…
Bien évidemment le système est plus complexe, mais le principe est là:
Chacun garde ses informations, c’est presque un prolongement du droit d’auteur.
Certaines peuvent être « communicables » sans condition, d’autres « sous conditions » et d’autre enfin privées.
Il nous semble que par ce système de BIM décentralisé on résout plusieurs problèmes:
– le besoin de ressource : la maquette centrale gérée des métadonnées et va chercher à la volée les informations utiles via les API.
– la confiance entre les acteurs: le système garantit la détection du moindre changement sans pour autant avoir besoin de tout exposer en permanence.
– la souplesse et l’interopérabilité: des systèmes hétérogènes peuvent converser ensemble via les API, sans pour autant devoir suivre un standard figé, il suffit de traiter les choses au cas par cas entre systèmes, comme cela se fait dans TOUS les systèmes digitaux actuels.
FAISONS LE POINT ENSEMBLE
Pour faire le point ensemble et aller plus loin, Rolland MELET (https://www.linkedin.com/in/rollandmelet/), CEO de 360SmartConnect
Invite
– Pierre Olivier BOYER,( https://www.linkedin.com/in/pierre-olivier-boyer-b336b81/) Directeur des partenariats stratégiques du Groupe VICAT, Vice-président de l’Aimcc (http://www.aimcc.org/) membre d’ADN construction
– Damien MAITROT, (https://www.linkedin.com/in/damien-maitrot-b91ab68/) Développeur chez KeeeX, pour son éclairage sur la Blockchain
– Pierre-François Jullien (https://www.linkedin.com/in/pierre-fran%C3%A7ois-jullien-1841801/) Président d’ATALANE, pour nous faire part de son éclairage sur les travaux de normalisation en cours et l’intégration du BIM dans le système d’information du fabricant.
Le 08 novembre 2017, de 14:00 à 14:45 HALL 5A (entrée) dans le cadre du Forum Construire & Rénover Durable (https://goo.gl/JtvABz) du salon BATIMAT (https://www.batimat.com/) qui se tient à Villepinte du 6/11 au 10/11 au PARC DES EXPOSITIONS, PARIS NORD VILLEPINTE.
Pour bénéficier d’une invitation gratuite, inscrivez-vous sur ce site (lien https://badge.lemondialdubatiment.com/?codePromo=BEE3041645 ) avec le code BEE3041645
RETROUVEZ NOUS !
Rolland MELET, ceo, 360SmartConnect
