🎨 Pipe Programming : linéariser la complexité des graphes

Mathieu Ledru — Sun, 14 Sep 2025 17:11:06 +0000

Dans de nombreux outils d’automatisation et de dataflow, la logique est représentée sous forme de graphes de nœuds. Cette approche est intuitive au premier abord : chaque nœud représente une opération, et les flèches matérialisent les flux de données. Mais dès que la complexité augmente, la lisibilité diminue fortement. La programmation fonctionnelle offre une alternative élégante : le pipe, une construction linéaire où les transformations s’enchaînent naturellement, de haut en bas, comme la lecture d’un texte.

Le graph de nœuds : intuitif mais vite complexe
Représentation en deux dimensions.
Facile pour de petits prototypes.
Mais : ambiguïtés (quand les données “pop” ?), contraintes visuelles (arêtes qui s’entrecroisent), coût cognitif croissant à mesure que le graph grandit.
Exemple minimal :

[Source A] →

↘
[ Merge ] → [ Transform ] → [ Output ]
↗
[Source B] →
Le pipe : une lecture linéaire et concise
En programmation fonctionnelle, le même processus peut être représenté sous forme de pipeline :

use Flow\Flow;

$result = Flow::pipe(
yield emit(['foo', 'bar']), // Source A
yield emit(['baz']), // Source B
yield merge(), // Merge
yield transform(), // Transform
yield output()
);

echo $result; // "FOO, BAR, BAZ"
Les avantages du pipe
Clarté : une seule direction, de haut en bas, comme une phrase que l’on lit.
Concision : moins de bruit visuel, seules les transformations apparaissent.
Maintenabilité : ajouter ou retirer une étape = ajouter ou retirer une ligne. Pas besoin de redessiner un graphe.
Prévisibilité : chaque étape est le résultat des précédentes, aucun flottement sur “où en est le flux”.
Quand préférer le pipe au graph ?
Pour des transformations de données séquentielles.
Pour des pipelines évolutifs où l’on ajoute souvent des étapes.
Pour un code versionné : un pipe est diffable dans Git, là où un graphe binaire/visuel ne l’est pas.
Conclusion
Le graph de nœuds reste pertinent pour le prototypage visuel ou les utilisateurs non-développeurs. Mais dès que la logique grandit, la représentation 2D devient vite un fardeau. Le pipe programming, tel qu’implémenté dans Flow (flow.darkwood.com), offre une alternative puissante : linéaire, concise, facile à maintenir, et surtout lisible comme un texte.

Message clé :

Avec un pipe, la logique est dans le code, pas dans les câbles.

🎁 Je propose des séances de coaching gratuites de 30 minutes pour aider les créateurs comme vous à automatiser leurs processus et à gagner du temps ⏱️

👉 Réservez votre séance gratuite ici : https://www.bonzai.pro/matyo91/lp/4471/je-taide-a-automatiser-tes-process

Merci de votre lecture ! Créons ensemble des workflows intelligents, rapides et automatisés 💻⚡

Railway FBP v1.0.8 is released 🎉

Mathieu Ledru — Sat, 02 Oct 2021 08:04:57 +0000

Railway FBP v1.0.8 introduce Monads.

A rework was done on this release when deepen into monads theory and their implementation in PHP. This could give the project deeper approach when considering the implementation to get much cleaner way to use it.

https://github.com/darkwood-fr/railway-fbp/releases/tag/v1.0.8

Railway FBP v1.0.3 is released 🎉

Mathieu Ledru — Thu, 29 Apr 2021 15:54:35 +0000

Railway FBP v1.0.3 is now released and introduce Ip Strategy that allow sequencing the order of processing Ip.
This is useful to get a granular control of your asynchronous Job. You can then decide to prioritize witch Ip should be processed by define a strategy.

https://github.com/darkwood-fr/railway-fbp/releases/tag/v1.0.3