Quelles sont les règles de gestion exécutées dans mon système d’information ? Comment puis-je m’assurer que ce sont les bonnes qui sont exécutées et qu’elles le sont à bon escient ? Est-ce que mes règles de gestion sont bien cohérentes pour l’ensemble de mon système d’information ? Ces questions fleurissent de plus en plus chez les grands comptes.
La première étape consiste à examiner attentivement des systèmes puisque, le plus souvent, la documentation reste incohérente avec ce qui est réellement exécuté, hors mise à jour en maintenance ou changements de dernière minute en phase de développement. Passé ce stade, une réponse à ces contraintes de traçabilité passe par une brique logicielle souvent ignorée pour diverses raisons : le moteur de règles.

En quoi consiste le moteur de règles ?

Un moteur de règles est avant tout un moteur d’exécution qui prend des règles d’un côté, des faits de l’autre et qui les rapproche pour obtenir un résultat correspondant aux attentes exprimées dans les règles.
Concrètement, cela se traduit sous différentes formes :

• Les règles peuvent également être représentées sous la forme de tables de décisions rapprochant des faits, souvent numériques ou codifiés, pour obtenir un résultat. Une obligation toutefois : la table est déterministe. Et l’ensemble des règles doit couvrir tous les cas. L’inconvénient réside dans le caractère simpliste des tables de décisions, car aucune opération complexe ne peut être envisagée.
• Les règles peuvent être implémentées sous forme de triggers ou de programmes en PL/SQL sur des bases de données permettant de réaliser des rapprochements de faits. On reste toutefois dans le domaine de la programmation et de l’interprétation, domaine pour lequel le rétro-engineering est nécessaire pour comprendre ce qui est réellement exécuté.
• Les règles peuvent être représentées par des fichiers de descriptions répondant à un langage évolué. Cette approche nécessite, comme tout langage, un apprentissage de sa grammaire, ou une traduction implicite. Ce type de moteur est généralement lié à un langage objet pour faciliter les manipulations du modèle métier. L’inconvénient demeure bien entendu le respect de ce langage ainsi que la construction en mémoire des objets pour être manipulés. Ceci peut s’avérer handicapant sur des volumétries importantes.

Cet article étudiera plus particulièrement ce dernier type de moteur, plus flexible, plus agile et plus à même de répondre aux questionnements évoqués précédemment.

Quelques excellentes raisons pour l’utiliser

Les raisons pour lesquelles l’utilisation des moteurs de règles s’avère utile sont variées.
Du point de vue du métier (directions opérationnelles), la définition des règles se rapproche d’une expression naturelle. Ce sont d’ailleurs parfois ces mêmes métiers qui peuvent mettre à jour le moteur en production. L’utilisation du moteur de règles apporte donc de la rapidité dans la mise à jour des règles. Cela s’avère très important dans les mises à jour à circuit très court, comme dans la grande distribution. Lorsque le supermarché voisin annonce une promotion très intéressante, le responsable d’un autre supermarché doit rapidement proposer quelque chose d’équivalent, au risque de perdre une clientèle importante.
Du point de vue du chef de projet informatique, le moteur de règles revêt également un aspect sécuritaire. En effet, lorsque les clients (internes ou externes) expriment leurs besoins, ils le font parfois en écrivant simplement sur un post-it, rendant ainsi le chiffrage des développements informatiques beaucoup plus coûteux puisqu’il est nécessaire de se lancer sur un ensemble de règles de gestion hasardeuses. Le moteur de règles peut alors permettre d’implémenter des règles sous une forme simple, mais qui prendra corps au fil du temps lors des différentes évolutions de l’expression de ces règles.
Dans le cadre de règles de gestion à cycle de vie plus long, le moteur de règles peut également prendre une importance conséquente, non pas dans leur complexité de mise en oeuvre, mais dans le délai de déploiement. Ce phénomène est courant dans le monde de l’assurance. Les conditions d’applications d’un nouveau type de produit peuvent être annoncées très tôt dans le temps sans pour autant en connaitre les détails. Ainsi les développements pourront se préparer sur la base des éléments généraux et être affinés juste après la mise en application. Ce phénomène a pu être observé lors de la mise en place des dispositifs PERP (Plan d’épargne retraite populaire) et PERE (Plan épargne retraite entreprise) par exemple. La mise en place et les différentes versions des contraintes réglementaires (Bale, Solvency, etc.) peuvent également être une source d’utilisation des moteurs de règles.
Enfin, l’utilisation même basique d’un moteur de règles peut simplifier les algorithmes de traitement. Récemment, pour une problématique autour de la délégation de rôle pour une application m’a amené, en changeant de point de vue, à simplifier énormément l’algorithme d’implémentation (4 classes et 3 règles à la place de parcours d’arbres de responsabilités). Bien entendu, une problématique simple comme celle-ci ne justifie pas la mise en place d’une brique logicielle telle qu’un moteur de règles. C’est parce que le moteur de règles est présent que l’on change le point de vue.