Moteurs de règles : résurrection, partielle…

Fin des années 1980, les systèmes experts battent leur plein. Ils sont le fleuron de l’Intelligence Artificielle, discipline de l’Informatique avec laquelle on espère construire des programmes pas forcément plus intelligents que l’Homme mais surement plus rigoureux. Au cœur de ces systèmes se trouve un moteur de règles, cerveau autonome alimenté par une réflexion concentrée du savoir d’experts humains. A partir d’une base de règles exprimant des conditions et des conclusions sur les valeurs des attributs d’un graphe d’objets, il déduit les valeurs des attributs manquants ou les demande à l’utilisateur s’il ne peut pas les calculer lui-même. Partant d’un problème dont il a une connaissance partielle, il optimise les déductions et / ou les questions et aboutit à la conclusion finale : le montant de remboursement d’un déplacement en ambulance, l’équipement défectueux sur un banc de test satellite. A cette époque, le système d’information n’existe pas et le moteur de règles est égocentrique : il est lancé en tant que « main loop », il attend de nouveaux faits, il se déclenche et propage un fait tant que des règles s’appliquent. Il est la mémoire, la base de données, l’IHM du programme. Des chercheurs passionnés l’intègrent dans du Lisp, du Kool, du Loir et inventent les Systèmes à Base de Connaissances.

Fin des années 2000, le moteur de règles revient à la mode, sous l’acronyme BRMS (Business Rules Management System). Il est commercialisé seul ou packagé à des solutions ESB (Enterprise Service Bus) et / ou BPM (Business Process Management). On l’invoque si besoin pour retourner le résultat d’un calcul « complexe » (tarification, commissionnement… financier la plupart du temps). Il sert en mode « calculette » : des paramètres d’entrée et un paramètre de sortie. On l’enrobe avec de la verbalisation pour que les utilisateurs formalisent et exécutent les règles avec plus de confort : « au moins 1 contrat du client » remplace le cryptique « client.contrats.size >= 1 ». La verbalisation est internationalisée. Si nécessaire, on appelle le moteur plusieurs fois dans un flux potentiellement conditionnel : « si client.fidélité >= ‘gold’ alors invoquer_règle(tapis rouge) ». On appelle une base de données ou un Web Service pour compléter les faits à analyser. Le moteur est embarqué dans une application ou un ESB, ou appelé en Web Service depuis une application ou une étape de processus. Mais de central, le moteur de règles est devenu annexe. Une toute dernière tendance pourrait lui redonner le rôle central d’autrefois : le CEP (Complex Event Processing), qui vise à corréler des événements dans un laps de temps.

En 20 ans, le positionnement d’un moteur de règles dans le SI n’est pas passé de central à annexe voire central à nouveau uniquement pour des raisons de mode ou de commerce. Fin des années 80, bien que les règles aient le vent en poupe, la complexité d’écrire un ensemble cohérent reste aux mains de profils technico fonctionnels très isolés. Ces profils disparaissent et la discipline n’évolue plus depuis. Début des années 2010, cette complexité se retrouve. Elle est même accrue par la complexité de « synchroniser » le contexte du moteur de règles avec l’état des applications dont il dépend et qu’il alimente. Nouveau challenge dans lequel malheureusement peu de travaux théoriques et métodologiques viennent proposer des bonnes pratiques et où seuls les éditeurs avancent leurs pions sans savoir plus que nous les intégrateurs à quel jeu ils jouent !