Les moteurs de règles ont traditionnellement un positionnement haut de gamme. De fait, ils sont doublement intimidants : d’abord ils sont plutôt chers, ensuite, pour justifier leur prix, ils sont présentés comme une solution à des besoins complexes, finalement pas si répandus que cela. Drools de JBoss pourrait bien changer quelque peu la donne.

D’un point de vue académique, celui de l’intelligence artificielle, le principe des moteurs de règles est simple. On décrit d’une part un ensemble de règles, et d’autre part, un ensemble de faits. En appliquant ces règles sur ces faits, on déduit (‘on infère’ dans le jargon de l’IA) de nouveau faits, et ainsi de suite. L’inférence des faits est assurée par un algorithme classique baptisé Rete ou par l’une de ses nombreuses variantes, plus ou moins brevetées.

Bon, tout cela ne nous dit pas trop ce que nous pouvons en faire pour les applications d’entreprise et le système d’informations. Pour cela, essayons de ne pas mettre la charrue avant les bœufs et revenons aux … besoins.

Classiquement, dans une architecture fonctionnelle, on identifie un certains nombres de règles fonctionnelles durables et relativement faciles à formaliser. Il existe aussi souvent un certains nombre de micro règles, que l’on peine à décrire exhaustivement, et qui ne cessent de changer dans le temps. Ces micro règles correspondent en fait fréquemment à des besoins en flexibilité qui découle de la nature même du métier : adaptation fine des politiques tarifaires, traitement particuliers de certaines catégories de clients, individualisation du service à la clientèle …

Deux dangers nous guettent alors. Le premier danger consiste à exclure les cas particuliers et donc à refuser la flexibilité au métier. Le second consiste à construire une architecture fonctionnelle centrée sur les cas particuliers, rapidement minée par la complexité, et finalement peu flexible.

Il existe diverses approches pour maîtriser le foisonnement des variantes de comportement, dont les moteurs de règles. Malheureusement, leur coût les confine aux cas complexes, alors qu’ils sont déjà intéressant pour les cas plus simples.

Le moteur de règles open source Drools (ou JBoss Rules) se présente dans ces conditions comme une possibilité intéressante. Tout d’abord, il a tous les atours des moteurs de règles établis. Ensuite, il offre deux possibilités dignes d’intérêt. Drools propose ainsi une interface web relativement simple pour décrire des règles. D’autre part, il est possible de définir des règles sous une forme beaucoup plus proche du langage naturel. Dans les deux cas, bien sûr, les règles finissent exprimées dans le langage de définition de règle de Drools. En évitant les discours lénifiants, on peut dire que Drools rapproche ainsi le technique du fonctionnel.

Les moteurs de règles offrent un choix supplémentaire dans la palette de l’architecte. Alors, pourquoi ne pas en profiter ?

Références