Erreur booléenne DMN – Cause racine en production (Analyse réelle)

January 13, 2026

Introduction

L’un des problèmes les plus fréquents et les plus critiques en production dans les systèmes basés sur DMN est l’erreur d’évaluation booléenne.
Ces erreurs passent souvent inaperçues en environnement local ou de test, mais provoquent des pannes une fois en production.

Symptômes typiques :

Échec d’exécution d’une décision DMN
Processus BPMN bloqué ou interrompu
Résultat de décision incorrect (false inattendu)
Exceptions telles que :
- FEEL evaluation error
- Boolean expected but got null
- Cannot coerce value to Boolean

Ce blog explique :

Ce qu’est une erreur booléenne DMN
Pourquoi elle survient en production
Les causes racines réelles
Comment la corriger et la prévenir

Qu’est-ce qu’une erreur booléenne DMN ?

Dans DMN, les booléens sont utilisés dans :

Les Input Expressions
Les conditions de tables de décision
Les expressions FEEL
Les Literal Expressions

Une erreur survient lorsque DMN attend true ou false, mais reçoit :

null
une valeur vide
un type incorrect
une expression FEEL invalide

👉 Résultat : échec de décision ou routage incorrect du processus.

Messages d’erreur fréquents en production

Vous pouvez rencontrer :


FEEL evaluation error: cannot convert null to Boolean


Expected Boolean but found String


Invalid FEEL expression in decision table


Condition expression evaluated to null

Ces erreurs apparaissent uniquement à l’exécution, avec des données réelles.

Cause racine n°1 : Valeurs nulles en entrée (la plus courante)

Scénario

Condition DMN :


approved = true

Entrée en production :


{
  "approved": null
}

Problème

null = true n’est pas une expression booléenne valide
→ Erreur d’évaluation FEEL

Pourquoi cela arrive en production

✔ Champs optionnels manquants
✔ Réponses API incomplètes
✔ Colonnes DB nulles
✔ Mapping incorrect des variables

✅ Correction (bonne pratique)

Toujours écrire des expressions null-safe :


approved != null and approved = true

Ou avec valeur par défaut :


if approved = null then false else approved

Cause racine n°2 : Chaîne de caractères au lieu d’un booléen

Scénario

Entrée REST / UI :


{
  "approved": "true"
}

DMN attend :


approved = true

Problème

"true" (String) ≠ true (Boolean)
→ Échec ou mauvaise évaluation

Origine du problème

✔ Problème de parsing JSON
✔ Frontend mal typé
✔ Mauvais mapping Java
✔ Utilisation incorrecte de Map<String, Object>

✅ Correction

Normaliser les données avant l’exécution DMN :


Boolean approved = Boolean.valueOf(input);

Cause racine n°3 : Cellules vides dans les tables de décision

Scénario

Table DMN :


Condition : approved
Cellule : (vide)

Problème

Cellule vide → null
DMN attend un booléen → erreur ou comportement imprévisible

Pourquoi c’est dangereux

✔ On suppose que vide = “peu importe”
✔ Ce n’est pas toujours vrai selon le moteur DMN

✅ Correction

Toujours définir explicitement la condition :


approved = true


approved != false

Cause racine n°4 : Syntaxe FEEL incorrecte

Scénario


approved == true

Problème

FEEL utilise = et non ==
L’erreur apparaît à l’exécution

✅ Correction

Syntaxe FEEL correcte :


approved = true

Cause racine n°5 : Expressions composées non sécurisées

Scénario


order.amount > 1000 and approved

Données :


{
  "order": { "amount": 1200 },
  "approved": null
}

Problème

true and null → évaluation invalide

✅ Correction

Toujours sécuriser les conditions :


order.amount > 1000 and approved = true

Cause racine n°6 : Différences entre moteurs DMN

Les comportements peuvent varier entre :

jBPM
Camunda

Comportement	jBPM	Camunda
Gestion des booléens null	Stricte	Variable
Cellules vides	Risqué	Dépend du moteur
Conversion de type	Limitée	Limitée

👉 Ne jamais supposer un comportement identique entre moteurs.

Comment debugger une erreur booléenne DMN en production

Checklist recommandée

Logger toutes les entrées DMN
Activer les logs FEEL
Tester avec les payloads réels
Vérifier explicitement les null
Tester les cas limites (null, vide, type incorrect)

Bonnes pratiques pour éviter ces erreurs

✔ Ne jamais supposer qu’un booléen n’est pas null
✔ Toujours écrire des expressions FEEL défensives
✔ Valider les données avant DMN
✔ Éviter les cellules vides
✔ Logger les décisions en production
✔ Tester les cas null en QA

Exemple DMN robuste (production-ready)


approved != null and approved = true


if approved = null then false else approved

Question d’entretien fréquente

Q : Pourquoi ces erreurs n’apparaissent qu’en production ?
R : Parce que les données réelles contiennent des valeurs nulles, optionnelles ou mal typées rarement couvertes par les tests.

Conclusion

Une erreur booléenne DMN n’est pas un bug du moteur, mais un problème de données et de modélisation défensive.

Dans 90 % des cas, les causes sont :

Valeurs nulles
Types incorrects
Expressions FEEL non sécurisées

👉 En écrivant des décisions explicites et robustes, vous évitez la majorité des incidents en production.

💼 Support professionnel disponible

Si vous rencontrez des problèmes sur des projets réels liés au développement backend d’entreprise ou à l’automatisation des workflows, je propose des services de conseil payants, de débogage en production, de support projet et de formations ciblées.
Les technologies couvertes incluent Java, Spring Boot, PL/SQL, Azure, ainsi que l’automatisation des workflows (jBPM, Camunda BPM, RHPAM), DMN/Drools.
📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 Website: IT Trainings | Digital lectern | Digital rostrum | Digital metal podium