Language Workflow — dans le cadre de la BU MUI, l’enjeu est de centraliser la gestion des processus de façon homogène, tout en isolant la logique métier des mécanismes d’accès aux données et aux systèmes externes.
Ces mises en place visent aussi à améliorer les parcours usagers et à renforcer la connaissance des usagers (profils, historique, contexte d’usage) au sein des systèmes de transport, pour des parcours plus lisibles et une vision usager plus exploitable par les opérateurs.
La solution repose sur un formalisme textuel versionnable (fichiers .wf) : la spécification est directement exécutable par la VM, avec un diagramme dérivé du code — et non l’inverse comme en BPMN pur. Un processus métier peut tenir sur une page, être revu en comité de conception, diffé dans Git, puis suivi instance par instance en exploitation.
Ce qui est en place (décembre 2025 — juillet 2026)
- Un langage fortement typé et impératif — cahier des charges fonctionnel et implémentation — permet de décrire des workflows dans des contextes transport, systèmes transactionnels et distribution de titres.
- La VM (crate Rust
language_workflow_vm) et le moteur (workflow_engine) font l’objet de validation et de tests dans un projet engagé sur une problématique de covoiturage (réservations, offres, paiement, contrôles anti-fraude). - Un serveur workflow (
workflow-server) déployable en Docker, exposant une API REST documentée (OpenAPI / Swagger). - Un back-office technique (
wfengine-backoffice) pour l’administration des définitions de processus, le suivi des instances et l’intervention sur les exécutions en cours. - wfUser : application web usager (TypeScript / React) pour les saisies dans le cadre d’un parcours workflow.
- Un Playground navigateur et des IHM de conception (éditeur Monaco, composants Vue, librairie de diagrammes
vmui-diagram) pour prototyper, tester et visualiser les workflows sans déploiement complet. - Une chaîne de tests intégrée (tests unitaires VM, campagnes de charge HTTP Gatling sur le moteur).
- Des intégrations SI via bus de messages (MQTT, Redis, Kafka) ou plugins embarqués, avec persistance au choix (fichiers, SQLite, PostgreSQL en production).
- Plusieurs SDK plugin (Java, Python, Rust, Go) pour implémenter des fonctions externes branchées sur le bus retenu, sans modifier le cœur de la VM.
Le langage en bref
Le langage organise l’exécution autour de blocs Seq (séquentiel) et Par (parallèle, attente de plusieurs sources externes). Il couvre :
- États (
state "NOM") pour marquer les phases du parcours et alimenter le suivi opérateur ; - Décisions (
match … when …) pour router selon les réponses métier ; - Signaux (
sig) dans les blocs parallèles, pour gérer annulations, timeouts ou événements asynchrones (ex. conducteur ou passager qui annule en cours de trajet) ; - Fonctions internes (
def) et fonctions externes (appels vers le SI, les API ou les plugins) ; - Structures de données (
struct) pour typer les échanges entre étapes.
L’exemple covoiturage de la documentation illustre un parcours complet : collecte parallèle des propositions et informations usager, contrôle bancaire, acceptation conducteur, phases OPENED → RIDING → FINALIZED, avec signaux d’annulation et de fin de trajet.
Écosystème technique
| Brique | Rôle |
|---|---|
| libvm | Analyse, typage, compilation et exécution des programmes .wf |
| libwfengine | Gestion des définitions, instances, persistance, liaison VM / plugins |
| workflow-server | Point d’entrée HTTP, création et pilotage des instances |
| wfengine_wasm | Exécution dans le navigateur sans serveur (Playground) |
| Back-office + wfUser | Supervision opérateur et parcours usager final |
| Cartouche MaaS | Plugins métier préassemblés (compte mobilité, covoiturage, messages usager…) |
Deux modes de déploiement coexistent : standalone (API REST + back-office, utilisable par d’autres services et IHM) ou intégré (librairie Rust ou binding C embarqué dans une application existante).
Objectifs du langage et de la VM
Le langage et la VM couvrent des processus variés, par exemple :
- Parcours usagers : enrôlement métier, traitement des demandes et des parcours associés ;
- Paiement et commande : paniers d’achat, paiements multi-systèmes ;
- Après-vente et conformité : suivi des procédures de service après-vente, audit des actions utilisateur et traçabilité du chemin parcouru ;
- Verticale transport / MaaS : billetterie, comptes de mobilité, fraude, information voyageurs, partenaires et opérateurs.
Des patterns d’usage documentés couvrent la corrélation entre instances, la sécurité des échanges et la conception d’API data-driven autour des workflows.
Positionnement technique
L’architecture s’inspire des VM à forte capacité d’instanciation (plusieurs exécutions en parallèle) et des moteurs capables de traiter un grand nombre de cas d’exécution, tout en restant volontairement plus simple et mieux intégrée aux produits paramétrables existants.
Le moteur est implémenté en Rust : empreinte mémoire contenue (environ 200 Mo RAM, image Docker inférieure à 100 Mo), dépendance production limitée à PostgreSQL pour la persistance. Les campagnes de charge montrent une capacité à gérer plus d’un million d’instances en parallèle, avec un débit de l’ordre de 1 700 requêtes/s et des temps de réponse autour de 10 ms (selon profil CPU et charge).
L’objectif est de proposer une alternative plus légère aux chaînes lourdes type BPMN / orchestrateurs généralistes (ex. Camunda, suites BOAT type Pega ou Appian), sans sacrifier les besoins métier transport, systèmes transactionnels et distribution de titres.
Par rapport à l’orchestration code-first (Temporal, Conductor…), Language Workflow privilégie la lisibilité métier (DSL dédié, documentation inline sur les états, diagramme natif) et un back-office inclus — plutôt que la chorégraphie microservices à très grand volume.
Travaux en cours
- Fonctions métier : extension du langage et de la VM en cours pour couvrir les problématiques transport (cas d’usage, règles, intégrations) ; enrichissement de la cartouche MaaS (paiement, SAV, billetterie).
- Back-office : mise en place et évolution des écrans et flux d’administration associés.
- Outillage : développement d’outils internes pour accélérer la conception, les tests et la mise au point des workflows (Playground, éditeur, client API JavaScript).
- Visualisation : représentation graphique (diagrammes) des workflows, accessibles selon le profil — métier, usager ou développeur — synchronisés avec le programme source.
- Industrialisation : finalisation du packaging wfUser, gouvernance multi-tenant et montée en compétence concepteur / testeur (plan de formation documenté).