Regard critique sur les logiciels de modélisation – Partie 2

Regard critique sur les logiciels de modélisation – Partie 2

Comme signalé dans le précédent article, la question de l’évolution des logiciels de modélisation n’est pas forcement liée aux attentes du BIM mais une est une question de sommes d’adaptations de ces derniers. Chacun suivant sa logique de départ.

Pour mieux le comprendre et il faut essayer d’avoir une vue globale sur les développements informatiques depuis leur naissance. Si nous devions expliquer cela de façon simple, la programmation informatique a été une invention extraordinaire qui permet à partir d’un langage particulier programmer un certain nombre de commande et créer des chaines complexes de commandes suivant ses besoins. Deux facteurs apparaissent déjà dans cette premier aperçu ; les besoins et la personne qui va créer le programme.

Les besoins. Dans le monde de l’architecture le besoin qui a eu le plus succès était celui de pouvoir produire des plans précis reproductible à l’infini et imprimable en autant d’exemplaire souhaités. Si on voit l’évolution des outils de CAO c’est effectivement vers cela que les outils sont devenus de plus en plus performants. Dans cette évolution il a été pris en compte des « besoins » des architectes progressivement et seulement lors qu’ils étaient compatible avec une vision technique informatique des outils. Plus les outils répondaient aux besoins des architectes, plus les architectes commençaient à les utiliser sans trop s’inquiéter de la logique de départ de la programmation. Comme dans beaucoup de domaine, la logique commerciale prime sur le reste. L’architecte étant un client potentiel il fallait trouver le moyen d’intégrer ses besoins mais dans une logique de cycle de vie d’un produit de consommation, pas trop de changements à la fois donnant ainsi une valeur supplémentaire à la nouvelle version sans mettre en péril la rentabilité commercial de la version précédente.

Certain développeurs on fait le pari de créer des outils spécifiques aux architectes sur base d’une réelle analyse des processus de production des documents d’architecture et des besoins du moment des architectes. Ce qui a eu le mérite d’introduire la notion de 3D dans la modélisation assistée par ordinateur. Mais cette analyse se limitait aux besoins du moment, les architectes n’étant pas demandeurs de plus et faisant appliquer la logique, là aussi, du cycle de vie d’un produit de consommation pour donner une viabilité au programme.

Tout cela nous mène directement à la personne qui crée le programme. Ils sont rare les architectes qui ont une double compétence d’architecte et de programmeur, même une troisième celle d’analyste des besoins. Il est donc rare que les programmeur, avec toute la bonne volonté qu’il peut avoir, d’analyser au mieux les besoins des futurs utilisateurs tout en anticipant les besoins futurs liées à l’évolution d’une société 2.0 les le nouveau rôle de l’architecte dans la construction virtuelle de son projet. Nous pouvons ajouter à cela aussi l’anticipation des besoins en termes d’échanges de données avec les autres acteurs.

Tout cela se complexifie encore en sachant qu’en général les programmeurs partent des logiciels existants qui ont leur propre logique de conception informatique. Si l’on fait le lien entre ces deux facteurs ; les besoins et les programmeurs, le résultat est ce que nous avons à notre disposition sur le marché des logiciels de modélisation aujourd’hui. Des logiciels qui n’ont pas été fait pour communiquer ensemble, qui ont leur propre logique de programmation et qui cherche désespérément à s’adapter aux nouveaux besoins, dans une logique de cycle de vie d’un produit de consommation.

L’idée de cet article n’est pas de rejeter les logiciels de modélisations, bien au contraire, mais de mettre en place les bases d’une réflexion permettant une réelle évolution de ces outils vers un BIM ouvert.

atelierakb