Tables de décision
La table de décision est une représentation tabulaire et compacte d'un ensemble de règles qui gouvernent une décision unique et répétable. Chaque règle occupe une ligne, chaque condition une colonne et la colonne finale porte l'action ou l'issue retenue lorsque toutes les conditions de la règle sont satisfaites. Sa valeur tient à une propriété que la prose ne donne pas: l'exhaustivité et la cohérence des règles y deviennent vérifiables par construction. Pour n conditions binaires il existe 2ⁿ combinaisons, et la grille les rend toutes visibles d'un coup, de sorte qu'un testeur en tire ses cas, un auditeur confirme qu'aucune situation n'est laissée sans réponse et un moteur de règles l'exécute telle quelle. Le BABOK la décrit parmi les techniques de modélisation des décisions, aux côtés de l'arbre de décision et du diagramme des exigences de décision; l'OMG en normalise la notation, dont les politiques d'appariement qui lèvent l'ambiguïté quand plusieurs règles peuvent s'appliquer.
Objectif
La table de décision capture une décision unique, atomique et répétable sous la forme d'un ensemble exhaustif de règles condition-action. Atomique signifie qu'une seule issue est retenue à chaque passage, choisie dans un jeu fixé d'avance; répétable, que la même décision se pose de nombreuses fois sur des données différentes. Là où une politique écrite en prose disperse ses règles dans des paragraphes et laisse au lecteur le soin de vérifier qu'elles couvrent tous les cas, la table les aligne dans une grille où l'exhaustivité et la cohérence se lisent.
Son intérêt propre tient à deux propriétés qui deviennent vérifiables par construction. L'exhaustivité: pour n conditions binaires la grille compte 2ⁿ combinaisons, et l'on voit immédiatement si l'une manque. La cohérence: deux règles ne peuvent pas prescrire des issues contradictoires pour les mêmes entrées sans que le conflit saute aux yeux. C'est ce qui fait de la table le livrable que l'on remet à qui automatise ou audite la décision: un moteur de règles l'exécute telle quelle, un testeur en dérive ses cas de test, un auditeur confirme qu'aucune situation n'est laissée sans réponse. Sur des règles en prose, ces trois vérifications se font à la main et se ratent; sur la table, elles se font par lecture.
Le livrable est la table remplie elle-même: les conditions et leurs valeurs possibles, l'action attachée à chaque combinaison, une règle par ligne, la politique d'appariement déclarée et la garantie que toute combinaison d'entrées valides tombe sous le nombre de règles que la politique autorise. Une table sans politique d'appariement déclarée est ambiguë dès l'instant où deux règles peuvent s'appliquer à la même entrée. Une table dont on n'a pas contrôlé l'exhaustivité laisse passer en silence les cas qu'elle ne prévoit pas.
Usage
Quand l'utiliser
- Décision atomique à issue unique: une seule issue d'un jeu fixé, pilotée par un ensemble maîtrisable de conditions qui se combinent.
- Exhaustivité ou cohérence à prouver: la grille 2ⁿ montre qu'aucun cas n'est oublié ni traité deux fois, ce qu'une prose de règles ne montre pas.
- Règles à confier à l'automatisation: un moteur de règles ou une plateforme DMN exécute la table sans réécriture.
- Conditions plates qui se combinent librement: la plupart des conditions comptent dans la plupart des cas, et la table reste compacte là où un arbre répéterait ses sous-branches.
- Décision réglementée, tarifaire ou de routage à auditer ou à tester: la grille exhaustive est à la fois la base de test et la trace d'audit.
Quand ne pas l'utiliser
- Conditions nombreuses et fortement hiérarchisées: quand une condition ne compte que sur certains chemins, la grille 2ⁿ explose et se lit mal, préférer un arbre de décision.
- Décision non atomique se décomposant en sous-décisions: alimentée par d'autres décisions et des sources de connaissances, la cartographier d'abord avec un diagramme des exigences de décision et laisser chaque feuille être sa propre table.
- Règles comportementales ou jugement contextuel: un jeu fixe de conditions force une fausse précision, documenter la règle en langage naturel, au besoin par l'analyse des règles métier.
Description
Anatomie: conditions, entrées, actions, règles
Quatre éléments composent une table de décision. Les conditions sont les entrées de la décision, chacune rattachée à un élément de données précis: le domicile du demandeur, l'existence d'un contrat, le niveau d'un revenu. Les entrées de condition sont les valeurs que chaque condition peut prendre: deux valeurs booléennes, oui et non, dans une table à entrées limitées; des valeurs, des plages ou des expressions dans une table à entrées étendues. Les actions, ou issues, sont ce que la décision produit, une par règle sous une politique Unique. Les règles, enfin, sont le cœur de la table: chacune est une combinaison complète d'entrées de condition à laquelle est attachée une action, et chacune occupe une ligne. L'orientation où chaque règle est une ligne et chaque condition une colonne est celle que l'OMG retient par défaut; l'orientation classique, chaque règle en colonne, porte la même information, et le choix entre les deux relève de la lisibilité.
Entrées limitées et entrées étendues
La distinction entre les deux formes décide de la difficulté du contrôle. Une table à entrées limitées ne porte que des booléens et des indifférents, et son exhaustivité est une arithmétique exacte, 2ⁿ. Une table à entrées étendues porte des valeurs et des plages, plus compacte, mais dont l'exhaustivité dépend de la façon dont les plages se raccordent, et c'est là que les trous se logent. Ramener une décision à des conditions binaires, quitte à en multiplier le nombre, est souvent ce qui rend l'exhaustivité contrôlable d'un coup d'œil plutôt que par un examen de bornes.
Construire la table
- Fixer la décision et son jeu d'issues
Écrire la décision en un énoncé sans ambiguïté et lister les actions possibles. - Lister les conditions et, pour chacune, ses valeurs possibles
Celles-là seules qui font basculer l'issue. - Choisir la politique d'appariement et l'écrire sur la table
Unique par défaut, tant qu'aucun recouvrement voulu n'impose autre chose. - Énumérer les combinaisons
2ⁿ pour n conditions binaires, davantage dès qu'une condition prend plus de deux valeurs. - Attribuer une issue à chaque combinaison
C'est ici que se lit l'intention de la règle, et c'est le seul pas qui demande du jugement. - Contrôler l'exhaustivité et la cohérence
Les 2ⁿ combinaisons sont couvertes, aucune contradiction, aucun recouvrement sous Unique. - Replier les redondances par les indifférents
Sans masquer aucune distinction réelle.
L'exhaustivité: les 2ⁿ combinaisons
L'exhaustivité est la propriété la plus enseignable de la technique et la plus mécanique à contrôler. Chaque condition binaire double le nombre de combinaisons: une condition en donne deux, deux en donnent quatre et n conditions binaires en donnent 2ⁿ. Une table à entrées limitées est exhaustive lorsque ses règles, dépliées, couvrent ces 2ⁿ combinaisons sans en oublier ni en compter deux fois. Le contrôle est une addition, qui ne se délègue pas au jugement.
Le piège se déplace sur les tables à entrées étendues, où les cellules portent des plages plutôt que des booléens. Des bornes qui glissent ou se recouvrent d'une plage à l'autre laissent des trous silencieux. Une règle qui traite « montant supérieur à un seuil » et une autre « montant inférieur ou égal à ce même seuil » se raccordent proprement; mais un seuil écrit « supérieur à 18 » sur une bande de montant et « supérieur à 21 » sur la bande voisine laisse une plage entière sans règle, et la décision échoue sans que personne l'ait voulu. C'est une erreur de bornes, « supérieur à » posé pour « supérieur ou égal à », ou un seuil qui se déplace par bande, et c'est la manière la plus courante dont une table qui paraît complète ne l'est pas.
La cohérence et le repli sur les indifférents
La cohérence exige que deux règles ne prescrivent jamais des issues contradictoires pour les mêmes entrées. Sous une politique Unique, tout recouvrement est une erreur de construction, puisque la politique promet qu'au plus une règle s'applique.
Une table exhaustive de 2ⁿ règles est le plus souvent redondante, parce que l'issue ne dépend pas toujours de toutes les conditions. Là où l'issue est identique quelle que soit la valeur d'une condition, on remplace cette cellule par un indifférent, noté d'un tiret, et l'on fusionne les lignes que cette valeur distinguait. Une table exhaustive de huit lignes se replie couramment sur trois ou quatre. Le repli ne perd aucune couverture tant que le tiret est honnête. Le piège est là: un tiret posé trop vite masque une distinction réelle et fait dire à la table une chose fausse pour la moitié des cas qu'il recouvre. On ne pose un tiret que là où l'issue reste la même pour chaque valeur de la condition, et le contrôle consiste à déplier mentalement le tiret et à vérifier que l'issue tient pour chacune de ces valeurs.
Les politiques d'appariement
Quand plusieurs règles peuvent s'appliquer à une même entrée, il faut dire laquelle l'emporte, et c'est le rôle de la politique d'appariement (hit policy dans la norme de l'OMG), que l'OMG place dans le coin supérieur gauche de la table sous la forme d'une lettre. La politique Unique (U) est la première à enseigner: au plus une règle s'applique à toute entrée, et tout recouvrement est une erreur. C'est elle qui rend la table vérifiable, parce qu'elle interdit l'ambiguïté.
Les autres politiques servent des tables où le recouvrement est voulu. Any (A): plusieurs règles s'appliquent, mais elles donnent toutes la même issue. Priority (P): plusieurs s'appliquent avec des issues différentes, et l'issue la plus haute dans un ordre de priorité déclaré l'emporte. First (F): la première règle qui s'applique dans l'ordre des lignes l'emporte, l'ordre de lecture portant alors du sens. Collect (C): la table renvoie toutes les issues qui s'appliquent, éventuellement agrégées par une somme, un minimum, un maximum ou un compte. Une table qui ne déclare aucune politique est ambiguë dès que deux règles peuvent s'appliquer, et le lecteur ne sait pas si l'omission est une erreur ou un choix.
Table, arbre et diagramme des exigences
Trois techniques de la modélisation des décisions se ressemblent au point qu'on les confond, et la frontière décide du bon choix. On prend une table quand la décision est atomique et qu'on veut l'exhaustivité et la cohérence vérifiables d'un coup d'œil: la grille 2ⁿ est exhaustive et se contrôle par une addition. On prend un arbre de décision quand les conditions sont hiérarchiques et élaguent, quand une condition ne compte pas sur tous les chemins, comme dans une segmentation: une table plate y répéterait des sous-branches entières. On prend un diagramme des exigences de décision quand la décision n'est pas atomique: elle se décompose en un réseau de sous-décisions, de données d'entrée et de sources de connaissances, et chaque sous-décision feuille est elle-même une table ou un arbre. Table et arbre sont deux notations d'une même décision atomique; le diagramme des exigences est le niveau au-dessus, qui en organise plusieurs.
Ce qui fait échouer la table
Une erreur de bornes
« Supérieur à » écrit pour « supérieur ou égal à », ou un seuil qui glisse d'une bande à l'autre, laisse une entrée dans aucune règle ou dans deux.
Un indifférent posé trop vite
Un tiret qui masque une distinction réelle fait dire à la table une chose fausse pour la moitié des cas qu'il recouvre.
Une politique d'appariement non déclarée
La table reste muette sur ce qui se passe quand deux règles s'appliquent, et chaque lecteur suppose la sienne.
Des conditions qui ne sont pas indépendantes
Deux conditions qu'une contrainte lie, l'une impliquant l'autre, créent des combinaisons impossibles qu'on croit devoir remplir alors qu'elles n'existent pas.
Une règle comportementale glissée dans une table définitionnelle
Forcer une règle de jugement dans une grille lui donne une fausse précision qu'elle n'a pas.
Une table désynchronisée de la politique qu'elle encode
Une règle change dans le règlement et pas dans la table, et la table ment en silence jusqu'au prochain audit.
Considérations IA
Le premier usage utile est la rédaction d'un premier jet de règles à partir d'un texte de politique ou de règlement. Un modèle de langage à qui l'on fournit une directive en prose en tire une liste de conditions candidates et des lignes de règles, ce qui est la moitié fastidieuse de la préparation. Le deuxième usage est un contrôle avant même que la table n'existe: donner au modèle un jeu de règles écrit en langage naturel et lui demander de signaler les combinaisons non couvertes et les contradictions apparentes. Le troisième prolonge le repli: repérer les règles où une condition ne change pas l'issue, donc les indifférents candidats et les lignes redondantes.
Ce que l'IA ne peut pas faire tient à la nature de l'exercice. L'exhaustivité de la grille est mécanique, 2ⁿ est une arithmétique; l'exactitude des règles au regard de la réalité est humaine. Un modèle ne sait pas si une règle est fidèle à l'intention de la politique ou du texte de loi qu'elle encode. Il ne sait pas non plus choisir une borne: écrire « supérieur à » ou « supérieur ou égal à » pour un seuil de revenu est une décision de domaine, souvent inscrite dans un règlement. Et il ne sait pas quelle conséquence attacher à chaque issue, qui est le fond de la décision. L'IA dessine la table; l'analyste répond de sa justesse.
La protection des données ferme le sujet dès que la table porte sur des personnes. Une table d'éligibilité remplie de cas réels contient des données personnelles au sens de la nLPD, revenus, situations, statuts. Elle ne se colle pas dans un modèle public, et l'assistance se conduit sur un outil dont le traitement des données est maîtrisé ou sur une table dont les valeurs sensibles ont été remplacées par des symboles de condition.
Exemples
Une décision d'éligibilité à une aide cantonale à la formation professionnelle se prend sur trois conditions binaires: le demandeur est domicilié dans le canton, un contrat d'apprentissage est signé, le revenu du ménage est sous le plafond, fixé à CHF 60'000. L'aide n'est accordée que si les trois sont remplies. Deux propriétés font la technique. L'exhaustivité: trois conditions binaires donnent 2³ = 8 combinaisons, toutes couvertes. Le repli sur les indifférents: la table exhaustive de huit lignes se lit en quatre, parce que dès qu'une condition suffit à refuser l'aide, les suivantes n'importent plus. La règle 1 refuse tout demandeur non domicilié, quels que soient le contrat et le revenu, ce que ses deux tirets disent, et cette seule ligne couvre 1 × 2 × 2 = 4 des huit combinaisons. La règle 2 en couvre 2, les règles 3 et 4 une chacune, soit 4 + 2 + 1 + 1 = 8: le repli n'a rien perdu. La politique d'appariement est Unique, marquée U dans le coin supérieur gauche, et l'on vérifie qu'elle tient, les quatre règles s'excluant deux à deux, si bien que toute entrée tombe sous exactement une règle. L'ordre des lignes n'a aucune importance pour l'issue, parce que les règles ne se recouvrent pas; ce serait faux sous une politique First, où la table renverrait la première ligne satisfaite et où l'ordre porterait du sens.
Table de décision
Aide cantonale à la formation professionnelle
| U | Domicilié dans le canton | Contrat d'apprentissage signé | Revenu du ménage sous CHF 60'000 | Décision |
|---|---|---|---|---|
| 1 | non | - | - | Refusée |
| 2 | oui | non | - | Refusée |
| 3 | oui | oui | non | Refusée |
| 4 | oui | oui | oui | Accordée |
Visualisations
La sortie de la technique est une table. Les colonnes de conditions séparées de la colonne d'issue montrent d'un coup la structure condition-action. Les tirets alignés en colonne rendent le repli visible: on voit quelles conditions cessent de compter et où. Le marqueur de politique dans le coin supérieur gauche dit comment lire un éventuel recouvrement, information sans laquelle la table serait ambiguë.
La forme repliée est celle qu'on montre parce qu'elle est celle qu'on lit. La forme exhaustive à 2ⁿ lignes n'existe que le temps du contrôle: elle prouve que rien n'est oublié, puis la forme repliée sert à décider vite.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | S'accorder sur les conditions, sur les valeurs que chacune prend et sur l'intention du propriétaire de la règle est le travail de fond. L'ambiguïté se loge ici, dans un terme de règlement qui admet deux lectures ou une borne que personne n'a arrêtée. |
| Exécution | Faible | Une fois les conditions et les actions fixées, énumérer les combinaisons et contrôler l'exhaustivité est mécanique: 2ⁿ est une arithmétique, et le repli sur les indifférents se fait à la main ou au tableur. Aucun atelier long, aucune donnée à réunir. |
| Documentation | Moyen | La table est un artefact vivant. Elle se versionne et se recontrôle à chaque changement de la règle qu'elle encode, faute de quoi elle se désynchronise de la politique et ment en silence jusqu'à ce qu'un audit ou un cas limite la rattrape. |
Outils
Le tableur (Excel, Google Sheets) est l'outil du quotidien. Une ligne par combinaison donne l'exhaustivité par construction, une colonne par condition tient la structure, et une formule contrôle les bornes ou compte les lignes. Il sert à penser la table; le sens des règles reste à la charge de l'analyste.
Les outils de modélisation DMN (Camunda Modeler, Trisotech, SAP Signavio, Sparx EA, Drools et sa suite KIE) sont le palier au-dessus. Ils connaissent les politiques d'appariement, signalent les combinaisons non couvertes ainsi que les recouvrements et produisent une table exécutable plutôt qu'un simple document. C'est là qu'on valide et qu'on exécute une table destinée à l'automatisation.
Les moteurs de règles et systèmes de gestion des règles métier (BRMS) exécutent la table en temps réel, sur les données de production, une fois qu'elle a été validée. La table cesse alors d'être un livrable d'analyse pour devenir un composant du système.
Le tableau blanc reste l'outil de l'élicitation initiale, tant que les conditions et leurs valeurs se discutent encore. La règle pratique tient en une phrase: le tableur pour penser, l'outil DMN pour valider et exécuter.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17 Decision Modelling: la définition de la table de décision, son anatomie en conditions et actions, l'usage des cellules vides ou indifférentes et les forces et limites de la modélisation des décisions.
- Object Management Group, Decision Model and Notation (DMN), Clause 8 (Decision Table): la notation normalisée, l'orientation par défaut où chaque règle est une ligne, le marqueur de politique dans le coin supérieur gauche et les politiques d'appariement Unique, Any, Priority, First et Collect.
- ISTQB, Certified Tester Foundation Level Syllabus, Decision Table Testing: l'exhaustivité, la cohérence et l'élimination des redondances comme discipline de conception de tests, dont la dérivation des cas de test à partir des combinaisons de conditions.

