Chargement…
Chargement…
Case study orienté impact: objectif métier clair, exécution maîtrisée, preuve ROI et plan de delivery traçable.
Statut
Bientôt disponible
Projet personnel en conditions réelles
Preuve technique
5/5 piliers
Concevoir, Visualiser, Exécuter, Tester, Documenter — tous réels
Accès
Démo live
Lien direct plus bas sur cette page
Scope livré
0 livrables
Briques prêtes à exploiter par les équipes
Aperçu produit
Workflows (exemple)
Lead pipeline quotidien
Rapport hebdo Slack
Alerte rupture stock
Email relance J+3
Cron 08:00
triggerFetch Leads
actionScore IA > 70?
conditionSlack notif
actionArchive lead
actionPush CRM
actionLogs d'exécution (exemple)
Architecture système
Triggers
Cron · Webhook · Email
Moteur d'exécution
apps/worker Fastify · propre
Schéma versionné
Postgres · workflow versionné
Logs temps réel
WebSocket · historique
Alertes erreurs
Slack · Email
Code — extrait anonymisé
1// Parallel workflow execution with resource locking2async function executeWorkflow(wf: Workflow): Promise<RunResult> {3 const dag = buildDAG(wf.nodes, wf.edges)4 const visited = new Set<string>()5 const results = new Map<string, NodeOutput>()67 async function runNode(nodeId: string): Promise<void> {8 if (visited.has(nodeId)) return9 visited.add(nodeId)1011 // Run all upstream dependencies first (parallel)12 const upstream = dag.getParents(nodeId)13 await Promise.all(upstream.map(runNode))1415 const node = wf.nodes.find((n) => n.id === nodeId)!16 const inputs = collectInputs(nodeId, results)1718 try {19 const output = await executeNodeType(node, inputs)20 results.set(nodeId, output)21 await db.logs.create({ workflowId: wf.id, nodeId, output })22 } catch (err) {23 await notifyError(wf, nodeId, err)24 throw err25 }26 }2728 const sinks = dag.getSinks()29 await Promise.all(sinks.map(runNode))30 return { success: true, results: Object.fromEntries(results) }31}
1// Cron scheduler — distributed lock prevents double-execution2class WorkflowScheduler {3 private readonly lock: RedisLock45 constructor(redis: Redis) {6 this.lock = new RedisLock(redis, { ttl: 30_000 })7 }89 async tick(): Promise<void> {10 const due = await db.workflows.findDue(new Date())1112 await Promise.allSettled(13 due.map(async (wf) => {14 const acquired = await this.lock.acquire(`wf:${wf.id}`)15 if (!acquired) return // another instance is running it1617 try {18 const run = await executeWorkflow(wf)19 await db.runs.create({ workflowId: wf.id, ...run })20 await db.workflows.updateNextRun(wf.id, wf.schedule)21 } catch (err) {22 await db.workflows.recordFailure(wf.id, String(err))23 if (wf.alertOnFailure) await notifyError(wf, err)24 } finally {25 await this.lock.release(`wf:${wf.id}`)26 }27 })28 )29 }30}
Le problème
Un workflow d'automatisation exporté en JSON et importé sur un serveur, en espérant que rien ne casse silencieusement après coup, n'est pas un livrable fiable — surtout quand plusieurs automatisations critiques dépendent les unes des autres sans documentation ni versioning.
La solution
Plateforme qui traite chaque workflow comme un livrable documenté, testé, versionné et prouvé en fonctionnement, avec son propre moteur d'exécution — distincte de FlowGuard (qui observe des instances n8n/Make existantes de l'extérieur). Les 5 piliers V1 sont désormais tous réels : Concevoir (canvas visuel), Visualiser (dashboard d'exécution), Exécuter (moteur propre), Tester (fixtures qui substituent réellement la sortie des nodes) et Documenter (Certificat de Workflow — lien lecture-seule révocable prouvant qu'un workflow fonctionne, partageable sans donner accès au dashboard).
Impact clé
Stack technique