Événement d'erreur
Un événement marqué d'un éclair qui lève ou rattrape une erreur à l'intérieur d'un processus.
Ce que fait un événement d'erreur
Un événement d'erreur est un cercle avec un marqueur éclair. Il représente une exception — quelque chose qui a mal tourné dans le processus. Il existe en deux variantes : un événement d'erreur *qui lève* (marqueur plein) déclenche l'erreur, un événement d'erreur *qui rattrape* (marqueur vide) la gère ailleurs dans le diagramme.
Le placement le plus fréquent est un événement d'erreur qui rattrape, collé à la frontière d'un sous-processus. Le sous-processus tourne normalement ; si quelque chose à l'intérieur lève une erreur, le jeton est interrompu, sort par l'événement frontière, et continue sur un chemin dédié à la gestion d'erreur. C'est l'équivalent BPMN du try/catch en code — le chemin heureux reste propre, le chemin d'erreur est explicite et visible.
Les patterns que vous dessinerez vraiment
- Rattraper à la frontière : sous-processus « Traiter le paiement » avec un événement frontière d'erreur « Paiement refusé » → route vers « Notifier le client ».
- Lever à la fin : dans un sous-processus, une activité atteint un état impossible → événement de fin d'erreur. L'événement frontière du parent le rattrape.
- Rattraper dans un sous-processus événementiel : un sous-processus invisible qui s'active seulement quand une erreur correspondante se lève quelque part dans le parent. À utiliser quand plusieurs activités peuvent lever la même erreur.
- Re-lever : rattraper une erreur, exécuter une compensation, puis relever une erreur de plus haut niveau depuis le handler. C'est ainsi qu'on fait remonter.
Les événements d'erreur dans LucidFlow
Quand le document source décrit des chemins d'échec (« si le contrôle de crédit échoue », « si le fournisseur refuse le bon de commande », « si le système expire »), LucidFlow émet des événements d'erreur plutôt que d'aplatir l'échec en une simple branche conditionnelle. Cette différence compte pour le tableau de bord : les chemins d'erreur sont typiquement beaucoup plus rares que les chemins heureux, et leur coût par exécution explose quand on divise par la faible fréquence. Modéliser les erreurs explicitement permet à la heatmap de révéler « ce chemin rare nous coûte de façon disproportionnée » — souvent là où se trouvent les gains d'automatisation les plus rapides.
Questions fréquentes
Quelle différence entre une erreur et une simple branche conditionnelle ?
Une erreur est exceptionnelle — c'est un chemin que le processus n'est pas censé emprunter. Une branche conditionnelle est normale — c'est l'une des issues attendues. Modéliser une erreur comme une branche conditionnelle rend le chemin heureux moins lisible, parce que la gestion d'exception se mêle à la logique ordinaire.
Puis-je attraper n'importe quelle erreur ou seulement les erreurs nommées ?
Les deux. Un événement frontière sans code d'erreur précis rattrape toutes les erreurs levées par l'activité hôte. Avec un code nommé, il rattrape seulement celle-là. Les moteurs matchent par code, ce qui rend la sémantique d'escalade précise à l'exécution.
Que se passe-t-il si une erreur est levée sans qu'aucun événement frontière ne la rattrape ?
L'erreur remonte : au processus parent, puis son parent, jusqu'à ce que quelque chose la rattrape. Si rien ne l'attrape, l'instance de top-level se termine dans un état d'erreur.