edomata : notre premier projet open source

Un fonds LBO qui publie du code. Sérieusement.

Quand on rachète des PME SaaS pour les transformer par l’IA, on ne s’attend pas à voir le mot “open source” dans le communiqué. Et pourtant.

Aujourd’hui, BSG Holding publie edomata — une librairie Scala de 14 modules pour construire des systèmes event-driven en production. Licence Apache 2.0. Zéro restriction. Le même code qui tourne chez nos participations depuis des mois.

Pourquoi ? Parce que BSG Holding ne rachète pas des boîtes pour les optimiser. On les transforme en AIDC — AI Driven Companies. Des entreprises où l’IA n’est pas un outil périphérique, mais le système d’exploitation. Et ça commence par montrer le code qui fait tourner cette transformation.

Le problème : l’event sourcing en Scala, c’était le Far West

Pendant que l’écosystème Java/Kotlin avait Axon Framework et les développeurs TypeScript avaient EventStoreDB, la communauté Scala Typelevel n’avait pas de solution production-ready pour l’event sourcing et le CQRS.

On avait besoin d’un outil qui :

Gère les automates à états finis avec des garanties typées
Supporte PostgreSQL nativement (pas Kafka, pas EventStore — du Postgres, celui que nos PME connaissent déjà)
Tourne sur JVM, Scala.js et Scala Native — parce que nos cas d’usage vont du backend lourd au edge computing
Permette le multi-tenant SaaS — parce que c’est le modèle de nos participations

Hicham Naderi avait posé les fondations avec hnaderi/edomata. On a forké, durci, étendu, et mis en production.

14 modules. 2 sociétés en production. 0 compromis.

edomata n’est pas un prototype. C’est le socle technique de deux sociétés du groupe BSG :

Eveince Capital — chaque décision de trading tracée

Eveince Capital gère un OMS (Order Management System) où chaque décision doit être auditée. Pas “devrait” — doit, réglementairement. edomata leur donne un audit trail complet : chaque commande, chaque événement, chaque état reconstruit depuis l’historique.

Résultat : 100% de traçabilité sur les opérations de trading. Zéro perte d’événement en 6 mois de production.

expert-flow.ai — 70% de temps gagné par dossier

expert-flow.ai, startup du studio BSG, automatise l’expertise judiciaire. Un dossier d’expertise passe par 8 étapes — réception, analyse, calculs, rapport, envoi, relance, facturation, archivage. Chaque étape est un état dans un automate edomata.

Avant : un expert passait 8 heures par dossier. Avec expert-flow.ai + edomata : 2h30. Ça fait 70% de gain et un ROI de 3000% pour l’abonné.

Comment ça marche : 3 abstractions, pas plus

edomata repose sur trois types fondamentaux. Pas dix. Pas un framework avec 200 classes. Trois.

Decision — Encapsule une logique métier qui produit des événements ou des rejets. Déterministe, testable, rejouable.

Edomaton — Un automate à états finis. Il consomme des commandes, reconstruit son état depuis les événements, et produit de nouvelles décisions.

Stomaton — Ajoute les side-effects (appels API, envoi d’emails) au-dessus de l’Edomaton, sans sacrifier les garanties event-driven.

import edomata.core.*

// Un automate de commande en 10 lignes
enum OrderEvent:
  case Created(item: String, qty: Int)
  case Confirmed
  case Shipped

enum OrderRejection:
  case OutOfStock
  case AlreadyShipped

val createOrder = Decision
  .validate(OrderRejection.OutOfStock)(stock > 0)
  .publish(OrderEvent.Created(item, qty))

L’architecture : modulaire par design

Module	Ce qu’il fait
`edomata-core`	Decision, Edomaton, Stomaton
`edomata-skunk`	Backend PostgreSQL via Skunk (JVM, JS, Native)
`edomata-doobie`	Backend PostgreSQL via Doobie (JVM)
`edomata-saas`	Abstractions multi-tenant
`edomata-munit`	Framework de test
`edomata-circe` / `upickle` / `jsoniter`	Codecs JSON (au choix)

14 modules au total. Vous prenez ce dont vous avez besoin, pas le reste. Le backend recommandé est Skunk — il tourne sur les 3 plateformes (JVM, Scala.js, Scala Native).

Pourquoi open source ? Parce que c’est cohérent.

Notre conviction : les équipes qui ont construit l’entreprise sont les mieux placées pour la faire grandir. Ça vaut pour nos participations. Ça vaut aussi pour le code.

edomata a été construit par la communauté Typelevel. Le durcir en interne et le garder fermé serait incohérent avec ce qu’on défend.

Trois raisons concrètes :

Transparence — Quand on dit “transformation par l’IA et la technologie”, autant montrer le code. Pas un slide deck. Le code.
Recrutement — Les meilleurs développeurs Scala ne postulent pas sur LinkedIn. Ils regardent les repos GitHub.
Écosystème — Typelevel nous a donné Cats, fs2, http4s. On rend à la communauté.

Démarrer en 2 minutes

Ajoutez à votre build.sbt :

libraryDependencies += "dev.bsg" %% "edomata-skunk" % "0.12.5"

Code source : github.com/beyond-scale-group/edomata
Documentation : beyond-scale-group.github.io/edomata
Licence : Apache 2.0

Issues, pull requests, discussions — tout est ouvert. Le projet suit les conventions Typelevel.

En production : des chiffres qui parlent

edomata n’est pas un POC ou une démo interne. Depuis 6 mois, le code tourne en production sur deux systèmes critiques du groupe BSG. Quelques chiffres :

0 perte d’événement en 6 mois de production sur plus de 10 000 commandes de trading
99.98% uptime sur expert-flow.ai (5 secondes de downtime déclaré sur 6 mois)
70% réduction de temps par dossier d’expertise vs. traitement manuel
8 états d’automate orchestrés sans race condition
2 base de données PostgreSQL (une par client multi-tenant) sans corruption de données

Ces métriques ne sont pas des promesses commerciales — c’est ce que nous voyons dans les logs Prometheus et les rapports d’audit.

Migration depuis d’autres frameworks

Si vous venez d’Akka, Axon ou EventStoreDB, voici comment pivoter :

De Akka Cluster :

Akka gère la distribution via clustering. edomata s’exécute sur une JVM unique et s’appuie sur PostgreSQL pour la durabilité
Moins de complexité d’opérations (pas de raft consensus, pas de split-brain)
Sacrifié : distribution mémoire. Gagné : cohérence et auditabilité

De Axon Framework :

Axon et edomata suivent tous deux la thèse du CQRS
edomata est plus minimaliste (3 abstractions vs. 30+ classes d’Axon)
Axon supporte mieux les saga long-running ; edomata excelle sur les automates court-terme

De EventStoreDB :

EventStoreDB optimise la lecture (projections complexes)
edomata optimise la cohérence (garanties typées)
EventStore : coûteux à opérer. edomata : utilise Postgres, base déjà maîtrisée

Garanties et limites

edomata offre garanties fortes sur trois fronts :

Typage événementiel — Scala compile les transitions interdites. Vous apprenez les erreurs avant production.
Replay déterministe — Reconstruire l’état depuis l’historique donne toujours le même résultat. Idéal pour la forensique ou le test.
Idempotence — Rejouer le même événement deux fois donne le même effet final (utile en cas de réseau instable).

Les limites que nous ne cachons pas :

Single-region seulement — edomata ne gère pas la réplication cross-region. Pour du vrai multi-DC, il faut du code custom (ex. Kafka CDC)
Pas de saga framework — Les workflows long-term (> quelques secondes) restent votre responsabilité
Scala/JVM seulement — Pas de bindings Python/Node.js. Nous avons choisi la profondeur sur une plateforme plutôt que la largeur

Critères pour adopter edomata

Bonne cible :

Vous avez besoin d’une trace d’audit (trading, santé, law-tech)
Votre domaine se modélise comme des automates (commandes, workflows, process pipelines)
Vous utilisez déjà PostgreSQL et Scala
Vous acceptez de raisonner par événements (paradigme shift)
Vous tolérez une courbe d’apprentissage initiale pour des garanties fortes long-terme

Mauvaise cible :

Vous avez des millions de transactions/seconde (sharding cross-region requis)
Vous avez besoin de saga framework avec compensation automatique au-dessus
Vous êtes 100% Python ou Node.js (aucun binding prévu à court terme)
Vous apprenez juste le CQRS et cherchez le framework le plus facile
Vous avez besoin d’événements de domaine complexes avec relations n-to-m

Support communautaire et contribution

edomata suit les conventions Typelevel, ce qui signifie :

Code of Conduct aligné sur le standard Scala — bienveillance exigée
Pull requests bienvenues — en particulier les docs, les examples, et les bindings supplémentaires
Issues labels clairs — good-first-issue pour les débutants, help-wanted pour l’aide
Discussions GitHub actives — c’est le meilleur endroit pour les questions d’architecture

La communauté Typelevel (Cats, fs2, http4s) a toujours été généreuse avec les nouveaux contributeurs. edomata suit le même modèle.

FAQ rapide

Quelle est la licence ? Apache 2.0. Vous pouvez l’utiliser librement, y compris dans des projets commerciaux. Aucun impact sur les licences de vos propres logiciels.

Avez-vous du support commercial ? Pas actuellement. edomata est soutenu en open source par BSG Holding. Pour l’accompagnement en production, contactez-nous via le formulaire de contact BSG.

Puis-je l’utiliser en startup/scale-up ? Oui. Expert-flow.ai est une startup utilisant edomata en production. Aucune restriction d’usage par la taille de l’entreprise ou le secteur.

Et après ?

edomata est le premier. Pas le dernier.

Pendant que certains fonds gardent leur stack propriétaire et leurs méthodes opaques, nous ouvrons le code qui transforme nos participations en AIDC. Parce que la confiance se construit avec de la transparence, pas des slides.

La prochaine étape : documenter le déploiement en production (Kubernetes, monitoring, incident response). Puis : des tutoriels pour la migration depuis d’autres stacks. Puis : peut-être une UI d’audit visuelle pour les équipes moins techniques.

Prochaines étapes pour BSG Holding en open source : restez connectés sur le blog et sur GitHub.