À quoi servirait une application de commerce électronique qui ne serait pas capable d’informer le client de l’état de traitement de sa commande, de reconnaître que l’utilisateur qui vient d’acheter un produit est en fait un client historique à forte valeur ajoutée, d’identifier que le message électronique émane d’un client ayant appelé la veille ? Apporter un service autour du produit n’est plus accessoire.C’est l’incontournable prix à payer pour fidéliser le client et rentabiliser ses investissements. Et ce prix s’appelle EAI (Enterprise Application Integration), marché en plein essor, qui a déjà fait un bond de 50 % en 1999 et 2000 pour atteindre 2,5 Md$ (380 M?) selon le cabinet d’analyse Aberdeen Group.Fournir, autour d’une simple commande, un service de qualité signifie déclencher une réaction en chaîne. Pour que le catalogue en ligne reconnaisse le client, il doit être capable d’effectuer une requête dans l’application de CRM (Customer Relationship Management ou gestion de la relation client).Laquelle transmet l’information au système de comptabilité qui ira vérifier dans celui de gestion des stocks, qui validera la commande, qui enverra l’information au serveur de messages pour générer automatiquement un courrier… Combinant à la fois des fonctions de workflow, de transformation des données et des outils de middleware, l’EAI est indispensable pour assembler tous les éléments du puzzle et s’imposer sur le commerce en ligne.
Du middleware à l’EAI
Adaptés à des systèmes fermés, évoluant rarement, les outils de middleware géraient à la fois la transformation des données, dans un format approprié à chaque application, et leur transport, pris généralement en charge par des mécanismes de transfert de fichiers.Aujourd’hui, ils ne suffisent plus à la complexité croissante induite par l’explosion du nombre d’applications à interconnecter. Sans compter que le transport et la gestion des données ne sont plus les seuls enjeux de la communication entre les applications.Chaque commande en ligne comporte des conditions : déclencher la préparation, si le système de paiement a validé la transaction, envoyer alors un e-mail de confirmation, etc. Ces conditions doivent être formalisées sous forme de processus. C’est précisément le rôle de l’EAI.
UN POINT CENTRAL DE CONTROLE DES REGLES
Concrètement, les outils d’EAI ne se contentent pas de transporter des données d’un point A vers un point B : ils interfacent les applications en offrant un point central de contrôle des règles de communication, d’exploitation et d’administration.Associé à la notion d’urbanisation des systèmes informatiques, l’EAI met en ?”uvre un bus logiciel qui relie les applications entre elles selon des règles préétablies. Celles-ci correspondent aux traitements, conditionnels ou non, nécessaires à l’exécution d’un processus.Sous cet acronyme, se cachent en fait différentes catégories de logiciels : les adaptateurs ou connecteurs spécifiques à chaque application ; une messagerie interapplicative synchrone ou asynchrone (MOM) qui assure le transport des données ; un courtier ou broker de messages qui analyse et transforme les données dans le format adéquat ; et enfin un moteur de workflow qui gère les flux selon des règles préétablies par l’architecte du système.Jeune, le marché de l’EAI est encore en pleine évolution. Les offres sont donc loin de couvrir la totalité des fonctions. Mercator, par exemple, s’est spécialisé dans la transformation de données, tandis que les grands acteurs du middleware (IBM, BEA, ou encore Tibco) brillent sur la messagerie interapplicative. D’autres, à l’instar de Crossworlds, s’orientent vers des solutions très compactes tandis que Microsoft, avec Biztalk, préfère l’option boîte à outils.
SOAP, XML, DE GRANDES ORIENTATIONS TECHNIQUES SE DESSINENT
Du côté du transport, les éditeurs s’orientent vers un standard qui pourrait prendre la relève des protocoles DCom (Distributed Component Objet Model) de Microsoft, ou IIOP (Internet Inter-ORB Protocol), des partisans des architectures Java/Corba. Baptisé SOAP (Simple Object Access Protocol), ce protocole aide des environnements hétérogènes à communiquer entre eux. S’appuyant sur le protocole du Web, HTTP (Hypertext Transfer Protocol), il résout, en outre, l’un des gros problèmes soulevés par DCom ou IIOP, à savoir l’ouverture de brèches importantes au niveau du coupe-feu. Ainsi, contrairement à DCom ou IIOP qui supposent l’ouverture de nombreux ports ou des développements très complexes pour échanger des données, SOAP n’utilise que le port HTTP.Côté format des données, l’orientation est encore plus claire. “XML ressemble réellement aujourd’hui à une potion magique, solution à tous les problèmes rencontrés par les entreprises dans le cadre de leur développement.” Ces quelques mots de Guy Fermon, organisateur du salon Forum XML de novembre dernier à Paris, résument bien la situation. Quelle que soit l’application, tôt ou tard elle intégrera un connecteur pour transformer des données dans un format propriétaire en XML. Reste à savoir quel format. Le métalangage XML se contente, en effet, de donner des mécanismes, pas les balises qu’il faut utiliser, ni comment les données doivent être organisées, ou imbriquées (arborescence des informations). Or, deux applications qui échangent des données en XML doivent partager la même organisation des informations et le même balisage. Plusieurs organismes, dont notamment Oasis et RosettaNet, travaillent à la définition de ces normes regroupées dans des documents dits schémas. La plupart sont encore en cours de définition, mais certains éditeurs les utilisent déjà, ne serait-ce que pour imposer au marché leur vision de la normalisation.
LE SERVEUR D’APPLICATION PLACE EN INTERMEDIAIRE
Entreprendre un projet d’EAI ne signifie pas forcément remettre en cause tout le fonctionnement de son système existant. D’autant plus que les produits restent coûteux : il faut compter un minimum de 500 000 F (76 241 ?), sans la mise en ?”uvre. Celle-ci est aussi très onéreuse, ne serait-ce que par le manque d’expertise sur le marché. La refonte totale d’un système informatique signifie débuter un très long projet. : “Il faut procéder par étapes, souligne François Knab, directeur associé de CosmosBay. Les projets pharaoniques sont un contresens, à l’ère de l’e-business . Il faut utiliser des technologies modulaires. L’entreprise préserve ainsi toute sa capacité d’évolution, tout en allant vite vers les nouvelles technologies.” Concrètement, quelle que soit l’installation à réaliser, elle devra respecter les consignes de base des nouvelles architectures distribuées : ne pas lier un processus serveur à une application cliente. En optant pour un niveau de traitement intermédiaire, le serveur d’application, l’entreprise peut ensuite faire évoluer son système et ses services en ligne. À condition de rester sur des technologies ouvertes.Enfin, malgré les coûts impliqués par l’EAI et sa complexité de mise en ?”uvre, penser que “l’EAI ne passera pas par mon entreprise” serait commettre une erreur monumentale. L’entreprise ne manquera pas, tôt ou tard, d’être confrontée à un partenaire avec lequel elle devra échanger des données. C’est d’ailleurs déjà le cas sur les places de marché transactionnelles, qui imposent aux acheteurs et fournisseurs, petits ou grands, des outils émanant de l’EAI. D’après le Gartner Group, par rapport à un projet développé sans courtier de message, le retour sur investissement d’un projet déployé avec des outils d’EAI serait supérieur de 100 % dès la première année.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
