Le commerce électronique et la programmation à base de règles étaient faits pour se rencontrer. En effet, la possibilité d’introduire et de modifier en ligne les règles qui gèrent le métier de l’entreprise dans un langage quasi naturel, proche de l’anglais, apporte une souplesse importante aux applications d’e-business. Avec la généralisation de ces dernières, le cycle des affaires se raccourcit et les besoins métiers sont en constante évolution.
Gagner du temps et assouplir les procédures
Dans cet environnement mouvant, il est essentiel pour l’entreprise de pouvoir réagir rapidement. Avec des logiciels toujours plus lourds et complexes, introduire facilement des modifications se révèle de plus en plus difficile. Peu de solutions apportent la réactivité nécessaire.L’essor du commerce électronique B to C (Business to consumer) transforme la manière dont sont pris en compte les clients. Ces derniers peuvent dorénavant interagir directement avec les applications centrales de l’entreprise, le dialogue avec les commerciaux est alors réduit à sa plus simple expression.
Le prêt-à-l’emploi n’a pas sa place
Or, une grande partie des règles de fonctionnement d’une entreprise et, en particulier, du traitement différencié de ses clients est davantage dans la tête de ses collaborateurs que dans son système informatique. Pour vendre sur Internet, il faut pourtant introduire ces règles implicites dans les applications d’e-business et… être en mesure de les modifier facilement et aussi souvent que nécessaire.De plus, tout changement de politique commerciale doit pouvoir être répercuté très rapidement dans les applications de commerce électronique, de préférence par les membres des directions commerciale ou marketing. En outre, chaque client est unique et singulier, et les règles qui lui sont appliquées doivent l’être tout autant. Cette personnalisation est cruciale dans une perspective de fidélisation.Le commerce B to B (Business to business) a, quant à lui, des besoins croissants de flexibilité. Les partenariats commerciaux doivent, en effet, pouvoir être établis (ou rompus) très facilement. Pour profiter des nouvelles places de marché sur le Web, les mécanismes d’échanges B to B doivent être aussi souples que dynamiques. Les processus du commerce B to B sont des plus complexes, car ils font interagir les systèmes d’information de multiples entreprises dans des transactions de longue durée. En conséquence, l’automatisation des processus métiers liés aux échanges interentreprises implique la prise en compte de milliers de règles changeant constamment. Sur ce créneau, spécifique du B to B , chaque relation commerciale relève d’outils sur mesure.Pour introduire les règles qui régissent le métier et les pratiques d’une entreprise dans une application d’e-business, plusieurs solutions sont envisageables. Longtemps en vigueur, le codage du fonctionnement de l’entreprise dans l’application n’est plus assez souple et fait intervenir des informaticiens de plus en plus nombreux. L’utilisation de tables de configuration ou de scripts d’adaptation des applications rend encore plus complexe la maintenance et se révèle d’une grande rigidité. La programmation à base de règles représente actuellement la solution la plus flexible.
Le second souffle des systèmes experts
Les moteurs de règles permettent l’emploi de règles métiers pour définir le comportement de tout ou partie du fonctionnement d’une application de commerce électronique.Tout comme les systèmes experts dont ils sont les héritiers directs, ils exécutent des règles pour déterminer des actions à réaliser. Toutefois, les règles métiers définissant ou contraignant certains aspects du métier de l’entreprise diffèrent des systèmes experts ” fermés “. Les moteurs de règles, au contraire, doivent être le plus ouverts possible et offrir de multiples options de déploiement dans les environnements Windows-COM, Java ou Corba. De plus, ils doivent impérativement autoriser une intégration avec les applications existant dans l’entreprise.
Le moteur de règles fonctionne par itération
Les règles métiers contiennent, d’une part, un ensemble de conditions et, d’autre part, des traitements déclenchant des méthodes sur les objets de l’application en fonction de conditions. Cela peut être, par exemple : ” Les clients qui nous ont commandé cinq mille pièces sur les six derniers mois et n’ont jamais été à l’origine de retard de paiement entrent dans la catégorie Gold “, ou ” Tout achat d’équipement au-dessus de 3 000 dollars doit être approuvé par un responsable de la division Finances “, ou encore, ” Pour chaque ligne de produits hors saison, accordez une remise de 20 % sur le prix affiché “. Si les conditions sont remplies, alors les traitements correspondants seront exécutés. Les moteurs de règles disponibles sur le marché comprennent deux types d’outils. Les premiers sont des environnements de création et de test des règles qui contiennent les éditeurs nécessaires à la saisie des règles (textuels ou graphiques), les utilitaires de test du comportement obtenu, et, enfin, ceux qui sont nécessaires à la compilation des règles dans un format compréhensible par le moteur. Les éditeurs peuvent, en général, être personnalisés en fonction des besoins de chaque entreprise. De plus, avec certains environnements de création de règles, l’écriture de ces dernières est effectuée en modélisant les processus métiers, depuis un niveau général jusqu’aux détails inclus dans les règles. Les seconds outils sont des environnements d’exécution des règles comprenant le moteur proprement dit, ainsi qu’un environnement serveur éventuel assurant la montée en charge. Les règles métiers sont stockées dans une base dans laquelle le moteur puise celles qui sont à exécuter.Le moteur est déclenché sur occurrence d’un événement (requête utilisateur, par exemple) par les applications qui utilisent des interfaces de programmation prédéfinies.Après son activation, il va d’abord évaluer les conditions incluses dans les règles afin de déterminer celles qui sont à lancer. Ensuite, il va déclencher les traitements correspondants qui peuvent parfois valider les conditions d’autres règles. Le traitement se poursuit de façon itérative jusqu’à ce que plus aucune règle ne puisse être exécutée.
Exécution en cascades de règles interdépendantes
Ce mode de fonctionnement permet aux utilisateurs de définir des règles sans tenir compte de leur dépendance, c’est-à-dire sans devoir les classer en fonction du fait que les conditions de certaines d’entre elles utilisent les résultats d’autres. L’évaluation itérative des conditions des règles effectuée par le moteur conduit le plus souvent à l’exécution en cascade de nombreuses règles interdépendantes.Supposons, par exemple, que les règles suivantes aient été introduites dans la base : ” Si le client est douteux, exigez un règlement en espèces ” ; ” Si le règlement est effectué en espèces, accordez une remise de 10 % ” ; ” Si le client a connu des incidents significatifs de paiement durant l’année qui précède, classez-le dans les clients à risque “.Ces trois règles sont interdépendantes, car la condition de la deuxième dépend des résultats du traitement associé à la première. De même, pour la première vis-à-vis de la troisième. Dès que le moteur sera invoqué, la troisième sera exécutée à la première itération. La première sera exécutée à la deuxième itération. Et, enfin, la deuxième sera exécutée en dernier.
Langage naturel et personnalisation
À la fin du traitement de toutes les règles exécutables, le moteur rend la main à l’application qui l’avait appelé.Depuis les dernières versions commercialisées cette année, les moteurs sont capables de prendre en compte des règles métiers écrites en langage quasi naturel. Cette introduction plus intuitive des règles est possible grâce à la définition, par les informaticiens, d’une correspondance entre le monde des utilisateurs et l’univers des applications informatiques. Et cela, afin que le moteur puisse évaluer les règles et déclencher les actions. La possibilité d’écrire les règles dans un langage quasi naturel, doublée du fait que leurs auteurs n’ont pas besoin de gérer les interdépendances, en autorise une écriture intuitive, beaucoup plus accessible aux membres des divisions opérationnelles de l’entreprise.En cas de changement stratégique, les directions commerciale ou marketing pourront fournir les nouvelles règles à appliquer dans un format compréhensible par un moteur. La communication entre les informaticiens et les divisions opérationnelles s’en trouve ainsi facilitée.Par ailleurs, la flexibilité apportée par les moteurs est due à la possibilité de modifier les règles prises en compte, sans arrêter l’application d’e-business. Cela donne la possibilité de changer les règles métiers aussi souvent que nécessaire et donc de faire preuve de réactivité dans un environnement des plus concurrentiels.Actuellement, la principale utilisation des moteurs de règles par les entreprises réside dans la personnalisation des applications d’e-business. Celle-ci constitue l’un des points clés de nombreux sites de commerce électronique, en complément de l’intégration de l’application d’e-business avec le back-end. Selon leurs promoteurs, l’utilisation des moteurs de règles autorise une personnalisation plus poussée des applications d’e-business qu’avec des technologies de filtrage collaboratif. Il s’agit alors de déterminer dynamiquement le profil des utilisateurs en fonction de leur comportement, afin de leur présenter ensuite des recommandations d’achat. L’exemple le plus connu de mise en ?”uvre du filtrage collaboratif est amazon.com, qui détermine uniquement les profils des internautes d’une façon dynamique, sans que la politique et les pratiques de l’entreprise pour fidéliser les clients ne soient prises en compte.
Les éditeurs de moteur se font rares
Pour fonctionner correctement, le filtrage collaboratif a besoin d’un historique important. La technologie des moteurs de règles permet de regrouper dans une seule base l’ensemble des politiques et des pratiques de l’entreprise et de les prendre en compte dans toute action commerciale vis-à-vis des clients. En revanche, elle ne détermine pas les profils et nécessite donc une segmentation, au préalable, des utilisateurs, ainsi que la saisie par les utilisateurs de leurs préférences, ce qui est difficile à obtenir en commerce B to C, mais est beaucoup plus accessible en B to B.Blaze Software (ex-Neuron Data) est pionnier dans ce domaine avec son moteur de règles écrit en Java. Blaze Advisor tire profit de la maîtrise de l’intelligence artificielle, figure de proue de l’ancienne Neuron Data. Son principal concurrent est Ilog, avec Jrules, également écrit en Java. Ces produits ont été inclus dans les serveurs de commerce électronique Web Logic Commerce Server 2.0, de BEA Systems, et WebSphere Commerce Suite 4.1, d’IBM. Ce dernier croit suffisamment dans la technologie des moteurs de règles pour l’inclure dans son nouveau serveur de personnalisation WebSphere Personalization.
Une application directement issue des règles
Celui-ci associe des fonctions de personnalisation reposant sur l’utilisation d’un moteur de règles métiers, avec des utilitaires de recommandation. L’ensemble fonctionne sur le serveur d’applications WebSphere, d’IBM.Versata, éditeur du moteur de règles éponyme, propose à ses clients d’aller encore plus loin. À partir de la déclaration des règles définissant les processus métiers, les outils de Versata génèrent et déploient automatiquement une application de commerce B to B.Ils sont capables de transformer les règles métiers en logique métiers compilée et contenue dans des composants Enterprise JavaBeans (EJB) ou dans des objets Corba. Le produit central de la suite de l’éditeur américain est un outil de modélisation de processus métiers et de leurs relations qui génère des règles comme résultat.Les politiques, les procédures et les pratiques d’entreprise sont stockées sous la forme de règles métiers dans un référentiel XML. L’approche à base de règles de Versata autorise un développement itératif des applications en ajoutant de nouvelles règles ou en modifiant celles déjà définies, aussi souvent que nécessaire.IBM a reconnu l’intérêt de cette approche en acquérant une licence de l’offre OEM, de Versata, incluse dans le produit Visual Age for Application Rules. Versata Logic Server fonctionne alors comme un conteneur spécifique d’EJB au-dessus de WebSphere. Les analystes du cabinet d’études IDC estiment que le couplage de ces produits crée un environnement de haut niveau pour le développement d’applications d’e-business.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
