Présentation de Nomaflow
Nomaflow est le planificateur et le moteur d'orchestration livré avec le Liberty Framework. Il s'exécute dans le processus du framework — pas de worker séparé, pas de broker (Redis / RabbitMQ), pas de démon compagnon. Le framework déjà installé pour les écrans et les tableaux de bord planifie maintenant aussi les tâches cron, exécute des pipelines ETL, synchronise les annuaires LDAP, distribue des appels HTTP et permet aux opérateurs de suivre chaque exécution en direct depuis une interface.
Si une équipe dispose déjà du framework, elle dispose de Nomaflow. Sinon, le framework est le chemin d'installation.
Ce que Nomaflow résout
La plupart des équipes qui exploitent des applications internes finissent par avoir besoin du même type d'infrastructure de « travail en arrière-plan » :
- Un rafraîchissement nocturne de base de données qui rapatrie les données d'un magasin opérationnel vers un magasin de reporting.
- Une récupération périodique d'API depuis un service tiers, avec nouvelle tentative en cas d'échec.
- Une synchronisation LDAP / Active Directory qui réplique les utilisateurs et les groupes dans l'application.
- Une tâche de nettoyage qui purge les anciens enregistrements, archive les PDF, supprime les sessions expirées.
- Un flux conditionnel qui ne s'exécute que si un événement précis s'est produit (un fichier est arrivé, un compteur a dépassé un seuil).
- Une exécution manuelle ponctuelle qu'un opérateur déclenche depuis un bouton après une livraison.
Faire cela sans Nomaflow revient généralement à éparpiller des entrées cron sur plusieurs hôtes, à maintenir des scripts Python dans différents dépôts, sans logique de reprise commune ni point unique pour visualiser « ce qui vient de tourner ». Avec Nomaflow, on dispose d'un seul catalogue de tâches, d'un seul historique d'exécutions, d'un seul flux de logs en direct, le tout dans la même interface que le reste de l'application.
En un coup d'œil
Ce que vous pouvez construire
| Schéma | À quoi cela ressemble avec Nomaflow |
|---|---|
| Synchronisation planifiée de base de données | Cron à 02 h 00 → étape SQL Copy d'un pool source vers un pool cible → notification de succès. Recette. |
| Récupération d'API externe | Cron toutes les heures → étape HTTP avec authentification bearer → étape Python transformant le payload → écriture SQL dans la table cible. Recette. |
| Miroir LDAP / AD | Cron toutes les 4 heures → étape LDAP Sync → upsert dans la table des utilisateurs. |
| Nettoyage conditionnel | Cron quotidien → étape SQL Query pour compter les anciennes lignes → étape Python conditionnelle qui les supprime au-delà d'un seuil. Recette. |
| Exécution manuelle ponctuelle | Sans planification → l'opérateur ouvre la page Tâches → ▶ Lancer maintenant avec paramètres → suit les logs en direct. |
| Surveillance de fichiers → lot | Cron toutes les 5 minutes → étape Python listant un dossier → pour chaque nouveau fichier, SQL Copy + déplacement vers l'archive. |
| Test de bon fonctionnement | Cron toutes les 5 minutes → étape HTTP sur votre propre healthz → alerte e-mail après 3 échecs consécutifs. |
Les briques sont volontairement petites (une étape fait une seule chose). Les pipelines les composent ; l'historique des exécutions rend visible ce qui s'est passé.
Quand utiliser Nomaflow
| Choisir Nomaflow quand… | Choisir autre chose quand… |
|---|---|
| Les charges restent à l'échelle d'une installation et ne traversent pas plusieurs systèmes. | Les charges couvrent une douzaine de services et nécessitent une vue DAG globale. |
| Le pipeline complet se termine en quelques secondes à quelques minutes. | Une seule étape dure plusieurs heures et requiert de l'autoscaling. |
| Cron + étapes linéaires + nouvelle tentative suffisent. | Vous avez besoin d'expansion dynamique de tâches, de DAG fan-out / fan-in, de calcul distribué. |
| Vous voulez un seul outil, une seule interface, un seul flux de logs. | Vous exploitez déjà Airflow / Dagster / Prefect pour le reste, et un second outil constitue un surcoût. |
| L'alternative serait d'écrire à la main un script Python + un timer systemd. | L'alternative serait d'écrire à la main un CronJob Kubernetes avec sidecars. |
Le point de conception du framework, c'est « la colle opérationnelle dont la plupart des applications internes ont besoin » — pas « tous les cas d'orchestration ». Pour le cas des 80 %, il évite une bonne partie de la plomberie.
Comment Nomaflow s'intègre au framework
Nomaflow s'appuie sur les connecteurs du framework pour atteindre les bases de données et les API (les mêmes connecteurs qu'utilisent vos écrans et tableaux de bord), sur le modèle de permissions du framework pour décider qui peut déclencher quoi, sur la couche de chiffrement du framework pour conserver les identifiants en sécurité, et sur l'interface Paramètres du framework pour tout définir. Pas de « base Nomaflow » à installer, pas de « comptes utilisateurs Nomaflow » à gérer.
| Brique du framework | Ce que Nomaflow en tire |
|---|---|
| Connecteurs (SQL / HTTP / LDAP) | Accès aux sources de données et aux API via des requêtes / endpoints déclarés. |
| Pools | Connexions aux bases de données. |
| Authentification + rôles | Permissions job:<name> par rôle. :session_user pour l'audit des déclenchements. |
| Chiffrement | Identifiants des connecteurs, URL de webhooks, secrets OAuth — tous 🔒 chiffrés. |
| Interface Paramètres | Le constructeur de tâches et l'éditeur d'étapes y résident. |
| Socket.IO | Mises à jour en direct de l'état des exécutions, des transitions d'étapes, du flux de logs. |
| Canaux de notification | Slack / e-mail / webhook — définis une seule fois au niveau du framework, utilisés par toutes les tâches. |
La documentation du Liberty Framework couvre ces briques sous-jacentes ; la documentation Nomaflow se concentre sur ce que vous construisez avec elles.
Visite guidée de la documentation
| Page | À lire pour… |
|---|---|
| Démarrage rapide | Construire une première tâche planifiée en 10 minutes. |
| Concepts | Comprendre le modèle mental tâche / exécution / étape / planification. |
| Tâches → Catalogue | Parcourir, rechercher et déclencher des tâches depuis la page Tâches. |
| Tâches → Créer une tâche | Suivre pas à pas le constructeur de tâches. |
| Tâches → Planifications | Syntaxe cron, intervalles, aperçu calendrier. |
| Étapes | Le rôle de chaque type d'étape (SQL Query, SQL Copy, Python, HTTP, LDAP Sync). |
| Exécutions → Historique | La page Exécutions — filtres, statut, accès au détail d'une exécution. |
| Exécutions → Dépannage | Quand une exécution échoue — comment en trouver la cause. |
| Recettes de workflows | Trois schémas de bout en bout prêts à adapter. |
| Étapes Python personnalisées | Brancher votre propre logique quand les étapes déclaratives ne suffisent pas. |
| Notifications | Slack / e-mail / webhook selon les résultats. |
| Administration | Planificateur multi-réplique, rétention, comportement au redémarrage. |
Là où Nomaflow ne va pas
Une courte liste honnête, pour que les attentes correspondent à la réalité :
- Pas de DAG de tâches avec branches parallèles. Les étapes d'une tâche sont linéaires ; vous pouvez chaîner des tâches via Dépendances, mais le modèle reste « étape par étape » et non « graphe ». La plupart des charges opérationnelles s'y prêtent sans difficulté.
- Pas de pool de workers autoscalable. Le planificateur s'exécute dans le processus du framework. Les gros lots parallèles (milliers d'étapes simultanées) ne sont pas son point fort.
- Pas de lignage / catalogue de données. Nomaflow sait quelles étapes se sont exécutées ; il ne trace pas quelles colonnes ont circulé de quelle source vers quelle cible. Utilisez un outil de catalogue dédié si ce point est important.
- Pas d'interface de backfill de niveau SaaS. Vous pouvez rejouer une exécution terminée ; vous n'obtenez pas nativement « rejouer pour chaque jour des 90 derniers jours » (écrivez une étape Python pour cela).
Ce sont des arbitrages, pas des manques à combler — le point de conception, c'est le cas petit, à l'échelle d'une installation.
Prêt à démarrer
→ Démarrage rapide — votre première tâche planifiée en 10 minutes.
Ou, si vous préférez lire d'abord : Concepts pour le modèle mental, puis Tâches → Créer une tâche pour le pas à pas.