Comme de nombreux éditeurs de PGI (1), vous vous lancez dans la location d’application. Avez-vous, pour cela, développé une version ad hoc d’Adonix X3 ? Non. Nous ne voulions pas que les versions internet – vendue aux ASP – et client/serveur soient trop différentes. L’ensemble est donc basé sur le même référentiel, géré par notre AGL (2) Adonix. Nous avons dû, pour cela, y intégrer la problématique web. Ceci a été d’autant plus facile que l’architecture de notre progiciel date, dans sa dernière mouture, de 1999, et est orientée objet. L’essentiel de notre travail a été réalisé au niveau le plus bas de l’architecture technologique. De cette manière, les fonctions de notre progiciel sont susceptibles d’être utilisées simultanément en mode client/serveur Windows et en mode web.Pourquoi ne pas avoir utilisé un atelier de génie logiciel du marché ? Le fait d’avoir notre propre AGL nous a permis de répondre de façon parfaite à toutes les contraintes que nous nous étions fixées : disposer d’un progiciel multilingue de façon native, capable d’intégrer des développements spécifiques, créés par des tiers, et pérennes en cas de changement de version, et sur tous les environnements ouverts du marché (serveurs Windows NT, 2000 ou Unix, et clients Windows ou navigateurs web). De même, le support de manière transparente des principales bases de données du marché (Oracle, SQL Derver, DB2) était un point fondamental.Quelle architecture avez-vous choisie pour vous adapter aussi bien à une configuration client/serveur qu’à une optique web ? Il s’agit d’une architecture à trois niveaux, communiquant via des protocoles basés sur TCP/IP. Le serveur de traitement sait répondre simultanément à des requêtes venant de clients Windows connectés directement et à des flux de données XML en provenance d’un serveur web intermédiaire. Ce serveur web gère les clients ASP connectés en HTTP à l’aide de servlets (3) et communique avec le serveur de gestion à l’aide de messages au format XML. Données et écrans sont transmis sous cette forme et sont transformés en pages HTML et, le cas échéant, en classes java par des parsers (4) XSL (eXtensible Stylesheet Language). L’interface utilisateur peut ainsi être personnalisée par des feuilles de style, être adaptée à de nouveaux types de langage (WML, par exemple, pour le WAP) sans que ni l’architecture, ni le référentiel de gestion n’ait besoin de modifications.Quelle est la principale caractéristique d’un développement axé sur le web ? L’utilisation native d’écrans du PGI via le web pose le problème essentiel des temps de réponse. Par définition, un PGI intègre une base de données riche, avec des écrans de dialogue contenant de nombreux champs, et des contrôles les plus interactifs possibles. En mode web, cette interactivité qui provoque de nombreux allers-retours entre le client et le serveur peut être pénalisante en temps de réponse si la bande passante du réseau est mauvaise. On peut alors vouloir travailler en mode page, l’ensemble des données d’une page étant contrôlé uniquement lorsqu’on a appuyé sur le bouton de validation. Inversement, dans un intranet, la bande passante peut être très bonne, et l’interactivité doit pouvoir être meilleure. Dans l’implémentation technique d’Adonix X3, l’utilisateur choisit son niveau d’interactivité, et l’interface s’adapte automatiquement. Ceci a été rendu possible par la modélisation des actions associées aux champs et aux boutons dans le référentiel même du progiciel : elles peuvent être déclarées comme obligatoires, recommandées, ou simplement utiles.Ne craignez-vous pas que l’hébergement de votre progiciel et sa mutualisation chez des partenaires nuisent à son optimisation ? Le dimensionnement d’un serveur de gestion mutualisé ne se différencie pas d’un serveur de gestion local. Ce dimensionnement dépend essentiellement du nombre d’utilisateurs simultanés et de la taille des données. Nos partenaires disposent ainsi de préconisations (tant en terme de mémoire que de puissance CPU) pour dimensionner des serveurs Adonix X3. A ce jour, nous avons des serveurs Adonix fonctionnant avec un nombre d’utilisateurs très varié (de 10 à plus de 400 dans certaines implémentations).Les clients de vos partenaires hébergeurs accepteront-ils de voir leurs données stockées sur des machines servant à d’autres entreprises ? Ils peuvent rechigner, c’est vrai. Mais c’est une question de coût. Le serveur dédié coûte évidemment plus cher que le serveur mutualisé. La mutualisation, quant à elle, permet aussi de disposer de façon économique de serveurs plus chers, plus sécurisés. De toute façon, la principale réticence n’est pas là : il faut d’abord que les sociétés acceptent de laisser leurs données (comptables, clients, produits. . . ) sortir de leurs murs.(1) Progiciel de gestion intégré. (2) Atelier de génie logiciel. (3) Application écrite en Java hébergée sur un serveur web. (4) Traducteur de XML en données compréhensibles par une application.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
