Séparer les règles métiers du code, ou encore les en extraire. Recourir à un moteur qui gère et orchestre ces règles et le processus, et s’appuyer sur un référentiel. Telle serait l’architecture d’une application moderne. Mais comment et pourquoi en est-on arrivé là ? Et quelles sont les solutions types de ce marché ?

Un algorithme d’à peine 25 ans

L’algorithme de Rete fut créé en 1983 par Charles Forgy. Dès lors, les solutions de moteur de règle basées sur cet algorithme notamment autour du langage C++ apparaissent. Leur coût lié à un besoin de compétences très pointues devenait prohibitif, car elles fonctionnaient des machines puissantes de l’époque (Station Unix). Autant de caractéristiques qui réservaient ce type de solution à des industries à même d’en retirer une plus value importante et donc de justifier les montants nécessaires à leur implémentation.

Il existait déjà des solutions « gratuites » dans des langages comme Lisp, prolog… Mais la faible distribution de ces langages dans le monde de l’entreprise ne favorisait pas leur adoption : le client/serveur autour de la base de données était roi ! Plusieurs phénomènes conjugués ont permis la modification de cette situation:

• la diminution du prix de la puissance des machines,

• l’avènement d’internet et la montée en puissance des communautés open source,

• la création d’un langage (java) associé au point précédent qui va imposer un standard de fait dans le monde de l’informatique et faciliter le portage des applications dans plusieurs environnements.

Grâce à internet et à la création de communautés dédiées (SourceForge, codehaus, etc.), une coopération mondiale est devenue devient possible, relayée par une diffusion des connaissances et les savoir-faire sur ces technologies. Alors, les moteurs de règles ont émergé et pris de l’ampleur en dehors de marchés de niches (banque/assurance, grandes administrations, grandes industries) sur lesquels elles étaient cantonnées.

La diffusion de ces savoir-faire a permis l’avènement de projets devenus des commodités et fournis en standard :

• Les systèmes d’exploitation, le navigateur Internet, le logiciel de messagerie, les outils bureautiques, les applications multimédias: toutes ces briques sont aujourd’hui accessibles au grand public à un prix inclus dans celui de la machine ou même à un prix nul pour celui qui fait le pas vers l’open source.

• Pour internet et le monde de l’entreprise : système d’exploitation (Linux), serveur d’application (Apache, Jboss, etc.), base de données, outils de développements, langages, outils d’intégration (ES B), etc. Tous ces composants existent en open source. La technologique n’est plus un frein pour la réalisation de logiciels complexes.

Il était donc naturel que le monde de la connaissance métier dispose également d’outils matures. Ces composants font maintenant parties des commodités au même titre que les autres composants.

L’algorithme de Rete et les solutions maison

Une des principales caractéristiques des langages de programmation est leur mode d’exécution procédurale liée aux matériels sous-jacents. En effet, le code est exécuté suivant le codage écrit par le développeur sans aucune interprétation. Derrière l’algorithme de Rete (prononcer « Rété ») se cache une approche radicalement différente : la programmation déclarative.

Le programmeur code les règles unitairement, et l’algorithme ordonnance les traitements en utilisant des composants et des concepts codés d’une manière classique.

L’algorithme de Rete traduit les règles déclarées en un graphe (rete = réseau en latin) qui sera parcouru par le moteur d’exécution des règles.

Chaque règle se décompose en :

• conditions qui se basent sur des faits insérés dans un espace de travail (« working memory » en anglais),
• actions si les conditions sont remplies.

Les conditions vont mettre à jour des données du modèle et il est possible d’indiquer au moteur de règles de réévaluer un fait qui peut déclencher éventuellement d’autres règles.

Par exemple, il est possible d’ajouter un nouveau fait qui doit être pris en compte. Ainsi, l’application des règles de calcul sur un ticket de caisse va créer des bons de réductions. Ces mêmes bons de réduction peuvent être limités en fonction du type de carte de fidélité utilisé par le client. La règle qui génère le bon de réduction va, dans sa partie action, notifier au moteur de prendre en compte ce nouveau fait parmi les règles à évaluer.

L’insertion d’un fait permet au moteur de savoir quelle règle peut-être déclenchée et celle qui ne peut pas l’être. D’ailleurs, une des bonnes pratiques consiste à utiliser un modèle objet « fin » (en opposition à un modèle type base de données avec 100 champs par table). Ce type de modèle crée des branches dans le réseau de Rete, et donc la non-insertion d’un type d’objet va permettre d’éliminer toutes les règles qui n’utilisent pas ce type d’objet et ceci très rapidement par simple parcours de graphe.

Un moteur de règle est constitué de plusieurs composants :

• une mémoire de travail qui contient les faits dont le moteur doit tenir compte. Ces faits peuvent être insérés depuis l’extérieur par le programme appelant le moteur de règle ou par les règles elles-mêmes,
• une mémoire de production qui contient l’ensemble des règles,
• un moteur d’inférence infère entre les faits et les règles. Il dispose d’un agenda qui lui permet de stocker les règles à exécuter (cf. illustration pour une vue simplifiée de l’algorithme).

Les moteurs de règles effectuent un « chainage avant » (« forward Chaining »). C’est-à-dire qu’ils partent des faits pour arriver aux conclusions. Cependant, certains moteurs de règles agissent à l’inverse : ils partent des résultats (appelés fréquemment « les contraintes ») pour proposer les solutions possibles.