Moteur de règles métier : fonctionnement et table de décision

Une demande d’achat de 4 800 € part chez le responsable de service ; la même à 5 200 € doit aussi passer par un acheteur. Un logiciel doit être visé par la DSI, quel que soit son montant. Ces décisions changent plus souvent que le circuit lui-même : un seuil est relevé, une catégorie est ajoutée, une exception est supprimée. Un moteur de règles métier évalue ces conditions à part, à partir de données d’entrée, et renvoie une décision au workflow qui l’applique.

Ce guide explique comment séparer les règles de la séquence du processus, écrire une table de décision lisible, éviter les conflits entre règles, puis versionner et tester ces règles. L’exemple suivi est une demande d’achat. Vous pouvez télécharger la table de décision et ses cas de test pour l’adapter à vos propres seuils.

Qu’est-ce qu’un moteur de règles métier ?

Une règle métier relie une condition à une conclusion : « si le budget est insuffisant, la direction financière arbitre ». Un moteur de règles est le composant qui reçoit des données (montant, catégorie, budget, fournisseur), évalue les règles applicables et renvoie un résultat (le circuit de validation, un niveau de risque, une éligibilité). Le processus qui l’appelle n’a pas à connaître le détail des seuils : il demande une décision et suit la branche correspondante.

On parle aussi de système de gestion des règles métier (BRMS, pour Business Rules Management System) lorsque l’outil ajoute au moteur d’exécution un référentiel des règles, un éditeur destiné aux équipes métier, la gestion des versions et la trace des changements. Les règles métier sont souvent appelées règles de gestion dans les spécifications : « une commande de 25 000 € HT ou plus exige trois devis » en est une.

Cette approche a une limite, bien décrite par Martin Fowler dans son article « Rules Engine » (2009). Lorsque l’action d’une règle modifie les données qui déclenchent d’autres règles (le chaînage), le comportement devient vite difficile à comprendre et à déboguer. Il observe aussi que la promesse de règles entièrement écrites par le métier, sans développeur, se vérifie rarement. Pour des décisions de gestion courantes, une table par décision, sans chaînage implicite, reste la forme la plus sûre.

Séparer les règles de la séquence du workflow

Le moteur de workflow fait avancer une demande : il crée les tâches, les attribue, relance et conserve l’historique. Le moteur de règles répond à une question posée à un moment précis du parcours. La frontière se trace avec un critère simple : ce qui change plus souvent que le circuit relève des règles.

Ce découpage a trois effets concrets. Le diagramme reste lisible : une seule passerelle « selon la décision » remplace une cascade de losanges imbriqués. Une règle se modifie sans redessiner le processus. Enfin, chaque décision peut être tracée avec la règle qui l’a produite, ce que les conditions dispersées sur plusieurs branches rendent difficile.

La notation standard des décisions, ses diagrammes de dépendances et son langage d’expressions sont présentés dans notre article sur DMN (Decision Model and Notation). Ce guide se concentre sur l’écriture, la gouvernance et les tests des règles, quel que soit l’outil d’exécution.

Écrire une table de décision

Une table de décision présente des règles sous forme de lignes. Les premières colonnes sont les entrées (les conditions à évaluer), les dernières sont les sorties (le résultat). Chaque ligne se lit « si … et … alors … ». Voici la table d’une demande d’achat ; les seuils, les catégories et les circuits sont illustratifs.

Le tiret signifie « indifférent » : la règle s’applique quelle que soit la valeur. Après l’arbitrage budgétaire (R01) ou le référencement du fournisseur (R02), la demande repasse par la table : un logiciel passe donc toujours par la DSI. Quelques conventions rendent la table fiable :

• Une table par décision. Le circuit de validation et le niveau de risque fournisseur sont deux questions différentes, donc deux tables. Si une décision dépend d’une autre, la première produit une sortie qui devient une entrée de la seconde, de façon explicite.
• Des entrées observables. Chaque entrée vient d’un champ du formulaire ou d’une donnée de référence (budget restant, liste des fournisseurs référencés). Une entrée qui suppose une appréciation, comme « achat stratégique », se transforme en question fermée ou reste une décision humaine.
• Des intervalles sans trou ni chevauchement. Écrivez les bornes de la même façon partout : borne basse incluse, borne haute exclue (« de 500 € à moins de 5 000 € »).
• Un identifiant, un propriétaire et une source pour chaque règle. R06 renvoie, par exemple, à l’article 4.3 d’une politique achats fictive ; son propriétaire est la direction des achats, que l’on peut désigner dans une matrice RACI. Sans propriétaire, personne ne peut arbitrer une demande de modification.
• Un résultat prévu quand aucune règle ne s’applique : une revue humaine, plutôt qu’un blocage silencieux ou une validation par défaut.

Gérer les priorités et les conflits entre règles

Deux défauts sont fréquents dans une première version de table. Le chevauchement : si R05 couvre « de 500 € à 5 000 € inclus » et R06 « de 5 000 € à 25 000 € », une demande de 5 000 € exactement satisfait deux règles qui donnent des circuits différents. Le trou : si R04 couvre « moins de 500 € » et R05 « plus de 500 € », une demande de 500 € n’en satisfait aucune.

Lorsque plusieurs règles peuvent s’appliquer, la table doit dire laquelle l’emporte. La spécification DMN de l’OMG (version 1.6, septembre 2026) nomme ce choix hit policy, que l’on traduit par politique de correspondance. Elle prévoit notamment :

• Unique (Unique) : une seule règle peut correspondre ; un chevauchement est une erreur de conception ;
• Première (First) : la première règle qui correspond, dans l’ordre de la table, l’emporte ;
• Priorité (Priority) : parmi les règles qui correspondent, l’emporte celle dont la sortie est la plus prioritaire, selon l’ordre des valeurs de sortie déclaré dans la table ;
• Collecte (Collect) : toutes les règles applicables renvoient leur résultat, sans ordre garanti, avec une agrégation possible (somme, minimum, maximum, nombre), par exemple pour cumuler plusieurs avis requis.

Pour un circuit de validation, la politique Unique est la plus facile à relire et à auditer : chaque demande correspond à une règle et à une seule, ce qu’un test automatique peut vérifier. La politique « Première » est pratique pour exprimer des exceptions placées en tête de table. Elle rend en revanche l’ordre des lignes significatif : déplacer une ligne peut changer une décision sans qu’aucune condition n’ait été modifiée.

Le même risque existe lorsque les règles sont écrites directement comme conditions sur les branches d’une passerelle exclusive : Softyflow, par exemple, retient la première condition évaluée comme vraie. Gardez des conditions mutuellement exclusives et prévoyez une branche par défaut vers une revue humaine.

Certaines situations ne se mettent pas en table et doivent être traitées comme des exceptions explicites, confiées à une personne :

• une urgence de sécurité ou de continuité d’activité ;
• un fractionnement suspect, par exemple plusieurs demandes au même fournisseur, sur le même objet, juste sous un seuil ;
• un demandeur qui serait aussi le valideur de sa propre demande, ce que la gestion des habilitations doit empêcher ;
• une régularisation d’achat déjà engagé.

Versionner et tester les règles

Une règle modifiée en production sans trace pose deux problèmes : on ne sait plus pourquoi une demande ancienne a suivi tel circuit, et une erreur de seuil peut toucher des centaines de dossiers avant d’être repérée. Traitez donc une table de décision comme du code.

Versionner

• Une version regroupe un ensemble de règles validées ensemble, avec une date d’effet, un auteur, un valideur (le propriétaire de la règle) et le motif du changement.
• Chaque décision enregistre ses entrées, la règle appliquée et la version de la table. Six mois plus tard, vous pouvez répondre à la question « pourquoi cette demande n’est-elle pas passée par les achats ? ».
• Décidez du sort des dossiers en cours. Une demande soumise sous la version 1 peut finir son parcours avec la version 1, ou être réévaluée. Les deux choix se défendent ; l’important est de consigner ce choix et de l’appliquer de la même façon partout.
• Faites passer le changement par les mêmes étapes que le reste de l’application : test, recette par le métier, puis production.

Tester

Un jeu de cas de test associe des entrées à la sortie attendue. Construisez-le avant de modifier la table, puis rejouez-le à chaque version.

• Un cas nominal par règle, pour vérifier qu’elle est atteignable.
• Les valeurs limites de chaque seuil, de part et d’autre : 499,99 € et 500 €, 4 999,99 € et 5 000 €, 24 999,99 € et 25 000 €. C’est là que se logent le plus souvent les erreurs de bornes.
• Chaque valeur « indifférente » : un logiciel de 300 € et un logiciel de 30 000 € doivent tous deux aller à la DSI.
• Le contrôle de couverture : chaque cas doit correspondre à une règle et à une seule. Zéro signale un trou, deux ou plus un chevauchement.
• L’analyse d’impact : avant de relever un seuil, rejouez les demandes du dernier trimestre avec l’ancienne et la nouvelle version, et comptez celles qui changeraient de circuit.

Ces cas trouvent naturellement leur place dans un cahier de recette informatique, à côté des tests d’écran et de droits.

Exemple : la décision dans une demande d’achat

Dans le circuit d’une demande d’achat, la décision intervient juste après la saisie. Le schéma ci-dessous montre où se place la table : le workflow collecte les données, la table renvoie un circuit, puis une passerelle oriente la demande. Les cas suivants sont illustratifs.

• Cartouches d’encre, 480 € HT, fournisseur référencé, budget disponible : R04 s’applique. La demande est validée automatiquement, et la décision reste consultable dans l’historique.
• Prestation de nettoyage, 5 000 € HT exactement, mêmes conditions : la borne basse étant incluse, R06 s’applique, et pas R05. Le responsable de service, puis un acheteur, valident.
• Abonnement logiciel, 1 200 € HT, fournisseur référencé, budget disponible : R03 s’applique quel que soit le montant. La DSI vérifie la compatibilité et la sécurité.
• Mobilier, 900 € HT, sur un centre de coût épuisé : R01 s’applique. La direction financière décide d’un virement de budget ou d’un report.

Si la politique achats relève demain de 500 € à 1 000 € le seuil entre R04 et R05, seule la table change. Les tests rejoués montrent les cas qui changent de circuit (ici T03, à 500 €), et de nouveaux cas à 999,99 € et 1 000 € remplacent ceux de l’ancien seuil ; le propriétaire valide la nouvelle version, qui entre en vigueur à la date prévue. Le processus, lui, ne bouge pas. Le circuit complet, de l’expression du besoin au bon de commande, est détaillé dans notre guide de la demande d’achat.

Une table de décision à télécharger

Télécharger la table de décision et ses cas de test (.xlsx) : modèle gratuit, sans formulaire.

Le classeur contient sept onglets :

• un mode d’emploi ;
• le dictionnaire des données d’entrée ;
• la table de décision de la demande d’achat ;
• les exceptions confiées à une personne ;
• les cas de test : pour chaque cas, des formules retrouvent la règle applicable, comptent les correspondances et comparent le résultat obtenu au résultat attendu ;
• le journal des versions ;
• une synthèse qui signale les trous, les chevauchements et les tests en échec.

Modifiez un seuil : les cas placés de part et d’autre de l’ancien seuil passent en échec tant que le circuit attendu n’est pas mis à jour. Les seuils et circuits sont fictifs, et des lignes vierges sont prévues pour vos propres règles et cas. Le fichier sert à concevoir et à vérifier une table : il n’exécute aucune décision dans vos applications.

Conditions, table de référence ou moteur dédié : comment exécuter les règles ?

Trois façons de faire, du plus simple au plus outillé :

• Des conditions sur les branches du workflow conviennent à quelques règles stables. Elles se modifient avec le processus et suivent ses versions.
• Une table de référence lue par le processus convient lorsque les seuils changent souvent. Les règles sont stockées comme des données, et une étape automatique les évalue. Les modifications échappent alors au cycle de version de l’application : protégez la table par des droits d’écriture restreints, et faites valider chaque changement par son propriétaire, avec un historique.
• Un moteur de règles ou de décision dédié se justifie pour des centaines de règles, des décisions réglementées ou un besoin de simulation à grande échelle. Le workflow l’appelle par API, puis applique le résultat.

Dans les applications créées avec l’outil workflow Softyflow, les éléments documentés couvrent les deux premières approches :

• la passerelle exclusive oriente le flux selon des conditions JavaScript posées sur les branches, avec un flux par défaut lorsqu’aucune condition n’est remplie ;
• des scripts JavaScript exécutés côté serveur peuvent lire une collection de données (par exemple la table des seuils) et écrire le résultat dans une variable du processus ;
• les droits de création, de lecture, de modification et de suppression d’une collection se définissent par rôle ;
• les versions de l’application enregistrent leur auteur, leur date et leur environnement, et se promeuvent de TEST à UAT puis à PROD, avec confirmation ;
• un journal d’audit centralisé conserve les actions des utilisateurs.

Le gestionnaire de règles du Web Modeler, lui, gère les règles d’interface (champ visible, requis ou désactivé) ; il ne remplace pas une table de décision évaluée par le processus.

Flowy AI peut générer une première version des règles métier à partir d’une description en langage courant ; les règles très complexes peuvent devoir être configurées manuellement ensuite. Softyflow ne documente pas d’exécution native de tables au format DMN : si vous devez exécuter des tables DMN, appelez un moteur DMN dédié par API depuis le processus. Pour cartographier l’ensemble du circuit, notre dossier sur la gestion de workflow et la page logiciel BPM présentent les autres briques.

Demander une démonstration à partir de votre propre table de décision.