⚙️ Message-oriented vs Data-oriented orchestration - de la donnée à la connaissance

le 17 avril 2026

Pour des raisons de propriété intellectuel, le sujet choisi pour la mise en application de cet article ne sera pas celui traité, bien qu'il s'en approche. Pour tout renseignement, il faut s'adresser à Omer qui se fera un plaisir de répondre, et priera de m'escuser pour les éventuels effets de bord provoqués.

Dans cet article, nous explorons deux approches fondamentales d’orchestration logicielle :

Message-Oriented Orchestration : via Symfony Messenger synchrone respectivement asynchrone
Data-Oriented Orchestration : via Navi pour le synchrone respectivement Flow pour l'asynchrone

Le cas d’étude repose sur un problème classique mais structurant : le text mining appliqué à un ensemble de repositories Git.
Pour la démonstration pratique, je vais reprendre le TD d'EIT de 2007/2008 réalisé à l'époque sur la classification avec Matthieu Beyou en cours de travaux dirigés de classe en informatique.
Pour les données, on utilise celles de Omer (ancien collègue de travail) disponibles son site https://git.arkalo.ovh (via l'api).

L’objectif n’est pas de produire le meilleur modèle de machine learning, mais de comprendre comment la forme de l’orchestration influence la complexité, la lisibilité et l’évolutivité du système.

Le problème : transformer des repositories en connaissance exploitable

Le dataset est constitué d’une liste de dépôts Git définis dans un fichier repos.json la donnée des répertoires listés sur https://git.arkalo.ovh/explore/repos.

Pour information, on pourrait extraire les informations avec le connecteur Composio pour https://composio.dev/toolkits/gitea. Se référer à mon article précédent pour l'implémentation https://blog.darkwood.com/fr/article/relacher-les-connecteurs-des-outils-au-langage.

Chaque dépôt devient un document canonique construit à partir de :

nom du repository
description
README
métadonnées (owner, topics…)

Ce document est ensuite transformé via une pipeline classique de text mining :

Prétraitement (nettoyage, tokenisation)
Extraction de features
Pondération TF-IDF
Similarité entre documents
Classification / clustering

Ce pipeline est directement inspiré des approches historiques :

TF-IDF : poids = tf * log(N / df)
Similarité cosinus entre documents
Classification Naive Bayes supervisée
Clustering k-means non supervisé

Ce qui nous intéresse ici n’est pas l’algorithme, mais la manière de l’orchestrer.

A noter, si vous êtes friant de documentation, vous pouvez vous référer à la partie Ressources en bas de l'article qui liste un certains nombre de sujet concernant le data-mining appliqué en informatique.

Pipeline métier (indépendant de l’orchestration)

Avant toute chose, il faut isoler le cœur métier.

Repository → Document → Tokens → Features → TF-IDF → Similarity → Results

Ce pipeline représente une transformation de données.

Chaque étape :

prend une donnée
produit une nouvelle donnée
sans dépendance forte à un contexte externe

C’est précisément là que les deux approches divergent.

Approche 1 Message-Oriented - Orchestration via Symfony Messenger

Dans l’implémentation Message-Oriented, le pipeline n’est pas exprimé comme une transformation continue de données.

Il est encapsulé dans un message, puis exécuté via le bus Symfony.

Modèle d’exécution

Command → Message Bus → Handler → PipelineService → Stages

Concrètement :

une commande CLI déclenche l’exécution
un message est dispatché
un handler prend en charge l’exécution
le cœur métier reste centralisé dans un service partagé

RunMessengerPipelineMessage
→ RunMessengerPipelineHandler
→ PipelineService

Séparation des responsabilités

Cette implémentation respecte une contrainte forte du projet :

le cœur métier est strictement partagé entre les deux approches

Ainsi :

Messenger ne contient aucune logique métier
il orchestre uniquement l’exécution

Pipeline réel exécuté

Le handler déclenche un pipeline déterministe :

1. ingest
2. preprocess
3. feature build
4. classification
5. clustering

Chaque étape est exécutée dans un service applicatif commun (PipelineService).

Concepts introduits par Messenger

L’orchestration introduit explicitement :

une classe de message
un handler dédié
une dépendance au bus
une couche de dispatch

Command → Message → Handler → Service

Ces éléments sont spécifiques à Messenger et n’existent pas dans le modèle data-oriented

Observabilité et debug

Messenger offre un modèle de debug naturel :

inspection des messages
middleware
logging du bus
extensibilité vers async / queue

Debug = niveau message + middleware

Nature de l’overhead

Dans ce MVP, l’overhead est mesurable conceptuellement :

introduction d’un message artificiel
indirection via handler
nécessité de structurer l’exécution autour du bus

Mais cet overhead est localisé dans l’adapter d’orchestration, pas dans le métier

Résumé

Cette approche transforme le pipeline en :

une unité de travail dispatchée

Elle privilégie :

standardisation Symfony
extensibilité vers async
intégration avec l’écosystème

Au prix d’une couche d’indirection supplémentaire.

Exemple conceptuel

final class ComputeTfIdfMessage
{
    public function __construct(public DocumentId $id) {}
}

final class ComputeTfIdfHandler
{
    public function __invoke(ComputeTfIdfMessage $message)
    {
        $document = $this->repository->get($message->id);
        $vector = $this->tfidf->compute($document);

        $this->bus->dispatch(new ComputeSimilarityMessage($vector));
    }
}

Avantages

découplage fort
résilience (retry, queue)
parallélisation native
standard Symfony

Limites structurelles

Le problème apparaît rapidement :

➡️ le message devient une enveloppe artificielle

On manipule :

des IDs
des états persistés
des transitions indirectes

Alors que le problème est simplement :

data → transformation → data

Cela introduit :

du boilerplate
des dépendances implicites
une perte de lisibilité globale

Approche 2 Data-Oriented - Orchestration via Navi (synchrone) et Flow (asynchrone)

Dans l’implémentation Data-Oriented, le pipeline est exprimé comme une suite ordonnée d’actions appliquées à un contexte.

Il n’y a pas de message.

Il n’y a pas de dispatch.

Il y a uniquement :

une donnée
un contexte
une transformation séquentielle

Modèle d’exécution

Command → WorkflowRunner → Actions → PipelineService → Data

Concrètement :

une commande déclenche un workflow
le WorkflowRunner exécute une liste d’actions
chaque action transforme un Context
les services métier sont identiques à Messenger

WorkflowRunner
→ PipelineStageAction[]
→ Context
→ PipelineService

Structure du pipeline

Le pipeline est explicitement défini comme une séquence :

[IngestAction,
 PreprocessAction,
 FeatureBuildAction,
 ClassificationAction,
 ClusteringAction]

Chaque action :

prend un Context
applique une transformation
retourne un nouveau Context

Nature du Context

Le Context devient l’objet central :

il contient l’état du pipeline
il évolue à chaque étape
il est inspectable

Context₀ → Context₁ → Context₂ → ... → Contextₙ

Concepts introduits par Flow

Cette approche introduit :

des actions explicites
un runner
un contexte évolutif

Data → Action → Data

Contrairement à Messenger :

pas de message
pas de handler
pas de bus

Observabilité et debug

Le debug change complètement de nature :

Debug = suite d’actions + snapshots de contexte

Avantages :

ordre d’exécution visible
état intermédiaire inspectable
pipeline déterministe

Nature de la lisibilité

Le pipeline est directement lisible comme un flux :

ingest → preprocess → features → classification → clustering

Sans transformation structurelle.

Overhead structurel

Le coût introduit est différent :

nécessité d’un Context
abstraction via actions

Mais :

aucune enveloppe
aucune indirection via bus
aucune rupture dans le flux de données

Résumé

Cette approche transforme le pipeline en :

une suite de transformations de données

Elle privilégie :

lisibilité immédiate
transformation directe des données
absence d’enveloppe
pipeline déterministe
facilité de test

Limites

moins adapté aux systèmes distribués complexes
nécessite une discipline forte sur la pureté des transformations
tooling moins standard que Messenger

Comparaison directe

| Critère | Message-Oriented | Data-Oriented | | --- | --- | --- | | Modèle mental | événements / messages | flux de données | | Lisibilité | fragmentée | linéaire | | Overhead | élevé (messages, handlers) | faible | | Scalabilité | excellente | dépend du design | | Debug | indirect | direct | | Couplage métier | faible mais diffus | fort mais explicite |

| Aspect | Messenger | Navi Flow | | --- | --- | --- | | Unité centrale | Message | Context | | Orchestration | Bus + Handler | Runner + Actions | | Flux | indirect | direct | | Debug | message-centric | data-centric | | Overhead | message + handler | action + context | | Pipeline | encapsulé | explicite |

Point clé : l’illusion de la complexité

Dans le cas du text mining, chaque étape est :

pure
déterministe
fonctionnelle

Exemples :

TF-IDF → simple formule mathématique
Similarité cosinus → produit scalaire normalisé

Il n’y a aucun besoin naturel de messages.

L’introduction de Messenger est donc une décision d’architecture, pas une nécessité métier.

Insight principal

Message-Oriented transforme des données en événements.
Data-Oriented transforme des données en données.

Dans un système comme celui-ci :

Message-Oriented ajoute une couche
Data-Oriented révèle le modèle

Implications pour Symfony

Symfony évolue vers :

async
workers
sidekicks (FrankenPHP)
orchestration distribuée

Mais cela pose une question fondamentale :

👉 tout doit-il être orchestré via des messages ?

La réponse dépend du problème.

Quand utiliser chaque approche