Avis
Voici les notes que j’ai retranscrites de la conférence donnée par Bernard Cache sur “l’éthique du logiciel libre” lors de la conférence Open Source pour les architectes, qui s’est tenue le 16 mars 2023. Il est professeur au Laboratoire de culture numérique pour les projets d’architecture à la École Polytechnique Fédérale de Lausanne en Suisse.
– – –
Les architectes rêvent encore de l’idéal d’un seul ingénieux réalisant son propre projet sur une seule plateforme auteur, alors que l’on sait que les projets d’architecture deviennent de plus en plus complexes, avec des interactions et des négociations continues entre de nombreux acteurs, qui utilisent chacun des logiciels différents avec des atouts et des capacités spécifiques. faiblesses.
En fait, il n’existe pas de logiciel unique et universel. L’interopérabilité n’est pas une option, mais c’est notre situation quotidienne désordonnée actuelle. Qui peut penser à un aspect moins créatif du processus de conception [than interoperability], qui ne fait que répéter exactement la même chose dans un format de fichier différent. Puisqu’elle apporte une valeur ajoutée, l’interopérabilité ne devrait pas du tout être un problème.
Il y a une solution à portée de main : IFC, les classes de base de l’industrie, qui capitalise sur 25 ans d’échanges, de discussions et de négociations, mais c’est très lent. C’est très lent, à cause des nombreux acteurs différents, qui envisagent chacun une utilisation possible. IFC apporte des réponses à des questions telles que « Est-il possible de retrouver les propriétés de classement au feu dans la maquette numérique d’un bâtiment vingt ans après sa construction ? Il offre le meilleur cadre pour décrire les composants BIM architecturaux.
Par conséquent, IFC est principalement utilisé pour la conversion de fichiers entiers avec des pertes de données et d’intelligence paramétrique. Réfléchissez une seconde : pensez-vous qu’une conversion IFC efficace serait une bonne idée pour les intérêts commerciaux des éditeurs de logiciels ? Ainsi, ils mettent tout en œuvre pour entraver son évolution, et ralentir les progrès réalisés dans le renseignement IFC.
Par conséquent, voici deux alternatives que nous aimerions explorer :
- Outils d’interopérabilité dynamique
Outils de conception IFC natifs
Outils d’interopérabilité dynamique
Deux outils d’interopérabilité dynamique possibles sont Tache (une plateforme de données 3D à https://speckle.systems)et Rhino.Inside (Rhino open source pour s’exécuter dans d’autres programmes à https://www.rhino3d.com/features/rhino-inside), et ne dépendent pas directement du format IFC.
– – –
Tache pourrait éventuellement assurer une interopérabilité globale entre plusieurs acteurs, chacun utilisant le logiciel de son choix sur son propre ordinateur relié à un serveur. Il ne gère pas la conversion de fichiers, mais traite les flux de données en utilisant le versionnage GitDif pour communiquer uniquement ce qui a changé dans le fichier. Si vous avez un bâtiment avec mille colonnes et que vous modifiez l’une de ces colonnes, pourquoi renverriez-vous tout le fichier ? Envoyez simplement la colonne qui a changé.
Grâce à GitDif, Speckle offre une communication ciblée et en temps quasi réel entre des personnes utilisant différents logiciels. Mais le modèle d’objet par défaut de Speckel est différent de l’IFC, ce qui signifie qu’il est indépendant du processus de normalisation lent et qu’il n’est pas gêné par les fournisseurs dominants.
Étant open source, il permet à tout contributeur de le développer dans le sens qu’il souhaite et le plus rapidement possible. Speckle est ouvert, donc tout contributeur peut proposer et utiliser des modèles objets alternatifs. Pourquoi ne pas envisager un modèle IFC open source fragmentable ?
– – –
Rhino.Inside est pour l’interopérabilité des bulles, car il est fait pour un seul utilisateur, qui est prêt à lancer Rhino et/ou Grasshopper dans son logiciel préféré. Il partage le même espace mémoire de son ordinateur.
En tant que bulle, ce sont des outils très puissants, mais qui ne résolvent pas le problème d’interopérabilité. La version la plus populaire est Rhine pour Revit, qui ne fait qu’augmenter la domination d’Autodesk, ce qui pour vous, architectes, signifie des prix élevés et des pièges propriétaires.
Élargir le BIM au général
Nous devrions élargir l’interopérabilité de l’industrie BIM vers l’industrie générale, car l’industrie du bâtiment sera toujours dépendante de l’industrie générale, que ce soit pour la fabrication ou pour la réutilisation de composants existants. Ainsi, l’interopérabilité devra étendre les ponts entre la conception et la construction et la fabrication.
Notre laboratoire développe deux outils open source qui relient les logiciels d’architecture aux logiciels de CAO/FAO, en particulier TopSolide (de France à https://www.topsolid.com/en/products):
- Speckle – Connecteur TopSolid
- Rhine.Inside pour TopSolid
Outils de travail natifs IFC
Cela implique de changer IFC d’un format de traduction de données à un format de données exploitable. Il existe déjà deux librairies de code qui permettent de travailler directement sur les données ITC :
- IFC.js est une boîte à outils BIM destinée aux communications Web à
- ifcOpenShell fonctionne directement sur les données IFC et peut donc se débarrasser de tous les formats propriétaires à http://ifcopenshell.org. Il est déjà intégré dans des logiciels ouverts comme BlenderBIMet est prévu pour FreeCAD et Xeokit (API 3D à http://xeokit.io).
Développement Open Source
Le développement open source (où aucune entreprise ne garde le code de programmation secret) n’est pas magique, et ce n’est pas un développement spontané, surtout si l’on attend des outils professionnels. On ne peut pas compter sur la bonne volonté des jeunes geeks qui travaillent tard gratuitement. Même l’industrie du logiciel propriétaire manque de main-d’œuvre avec ses salaires élevés.
Il ne faut pas répéter l’échec de Linux, qui reste un système d’exploitation marginal au-delà du rôle de serveur.
Ensuite, il y a la question culturelle : dans quelle mesure la communauté architecturale serait-elle prête à collaborer à la fabrication de ses propres outils ? Les architectes sont traditionnellement réticents à s’engager dans des questions techniques.
Le développement de logiciels libres doit être protégé par des acteurs publics, comme l’Etat de Genève, par des initiatives privées, et par des institutions publiques de recherche et d’enseignement.
