Comment concevoir ces interfaces d’échange, dans le cas du Projet ?
Jusqu’au début de 1999, il fallait obligatoirement que les éditeurs de logiciels s’entendent deux à deux pour développer des interfaces spécifiques. Car il n’existait pas de dictionnaire, chaque langue parlée étant réputée être unique pour un logiciel existant !
Le constat suivant est encore d’actualité :
Le transfert des données est qualifié de "douloureux". Il l'est au moins à deux titres :
Pour le développeur de ces interfaces, c'est à dire chaque concepteur de logiciels métiers qui a bien voulu, quelque fois contraint, ouvrir son logiciel.
La maintenance de ces interfaces, souvent complexes, constitue un frein économique et technique à la diffusion des logiciels. Il faut gérer la combinatoire des versions du logiciel avec chacune des interfaces (qui comporte séparément une lecture et une écriture) vis à vis de l'évolution non maîtrisable des logiciels interfacés.
En pratique, cette solution ne dépasse pas deux ou trois possibilités de communication directe. Cela reste du « sur mesure ».
Pour l'utilisateur aussi. Celui-ci est confronté à une recherche continuelle de logiciels "compatibles" avec les siens. Et quand il en a trouvé un, il s'aperçoit que les données transmises subissent une "perte d'information", dont les causes sont diverses.
Bien souvent, il n'y a pas d'autres solutions que la re-saisie des données.
Ce constat encore valable explique le frein à la diffusion des logiciels métiers.
C'est pourquoi des efforts de recherche considérables ont été engagés dans les domaines susceptibles de repousser les blocages rencontrés dans les échanges.
C'est urgent pour les logiciels graphiques, et en particulier pour ceux des architectes, qui constituent le point d'entrée de toute la chaîne informatisable.