Open-source · Self-hostable · Licence MIT

Concevez,
Exploitez,
vos workflows IA, en JSON

Waiflo exécute des workflows en parallèle, applique des limites de concurrence par utilisateur et met tout en file d'attente — sur un seul serveur, zéro dépendance externe. Livrez des fonctionnalités IA sans la dette ops.

⬡ Ouvrir l'éditeur — sans inscription ★ GitHub ⚡ Démarrage rapide
Exécution parallèle des workflows Serveur unique, zéro dépendance Queue management par fichiers Limites de concurrence par utilisateur
Ça vous parle ?
Prompts dans le code applicatif
Impossible à versionner, tester ou réutiliser
Votre logique LLM vit dans un script Python, une constante de string ou un fichier de config que personne n'ose toucher. Aucune structure. Aucun contrat entre les étapes. Aucune visibilité sur ce qui a changé.
LangChain / LlamaIndex
Puissant, mais vous êtes enfermé dans leurs abstractions
Vous écrivez leur code, pas le vôtre. Les mises à jour cassent tout. La logique du pipeline est cachée dans des objets Python, pas dans un fichier que vous pouvez lire, differ ou déployer indépendamment.
Dify / Flowise / n8n
Visuel mais opaque — pas de Git, pas d'API, pas de contrôle
Parfait pour prototyper. Catastrophique en production. Vos workflows vivent dans une base de données que vous ne pouvez pas versionner. Le vendeur s'interpose entre vous et votre propre logique.
L'approche Waiflo

Un seul fichier JSON.
Le pipeline complet.

Définissez les étapes, reliez-les, exécutez tout avec un seul appel API. Chaque workflow est un fichier .waiflo.json que vous commitez, relisez et déployez comme n'importe quel autre artefact.

support_triage.waiflo.json git diff-able · CI/CD ready 
{
  "lang_name": "support_triage",
  "steps": [
    {
      "ws_name":             "classify_ticket",
      "ws_type":             "prompt",
      "ws_llm":              { "provider": "anthropic", "model": "claude-sonnet-4-20250514", "temperature": 0 },
      "ws_system_prompt":    "You are a support triage expert. Classify tickets with high precision.",
      "ws_inputs_schema":    { "required": ["ticket_body"], "properties": { "ticket_body": { "type": "string" } } },
      "ws_output_schema":    { "properties": { "priority": { "type": "string" }, "category": { "type": "string" } } }
    },
    {
      "ws_name": "enrich_customer",  "ws_type": "api",
      "ws_api":  { "method": "GET", "url": "https://crm.internal/customers/" }
    },
    {
      "ws_name": "draft_response",  "ws_type": "prompt",
      "ws_llm":  { "provider": "anthropic", "model": "claude-sonnet-4-20250514", "temperature": 0.3 }
    }
  ],
  "workflows": [ { "wf_name": "triage_and_respond", "wf_nodes": [...] } ]
}
Comment ça marche

Définissez une fois.
Exécutez partout.

Trois primitives. Pas de magie, pas d'état caché, pas de framework à apprendre.

01
Les étapes — l'unité atomique
Chaque étape a un type (prompt, api, transform, tool, script), des schémas d'entrée/sortie typés et sa configuration complète. Réutilisable entre les pipelines.
ws_name · ws_type · ws_inputs_schema
02
Les workflows — le DAG
Reliez les étapes dans un graphe acyclique dirigé via wf_nodes et depends_on. Le runtime résout l'ordre d'exécution. Vous définissez l'intention.
wf_nodes · depends_on · step_id
03
Exécution via API REST
Un seul appel POST /api/exec/step avec les entrées. Streaming SSE pour les étapes prompt. Réponse JSON pour les étapes API. Votre backend reste maître — Waiflo est le moteur, pas le propriétaire.
SSE streaming · réponse JSON · sorties typées
Pourquoi Waiflo

Arrêtez de choisir entre
vitesse et contrôle.

Toutes les autres approches imposent un compromis. Waiflo non.

Développement maison
✓Contrôle total
—Réécrit de zéro à chaque projet
—Aucune réutilisabilité entre équipes
—Logique de prompts enfouie dans le code
—Concurrence à gérer manuellement
LangChain / Dify / Flowise
✓Rapide à démarrer
—Enfermé dans les abstractions du vendeur
—Workflows non versionnables avec Git
—Self-hosting difficile ou impossible
—Redis / broker obligatoire pour scaler
Waiflo
✓JSON pur — faites git diff sur vos pipelines
✓Self-hostable, zéro vendor lock-in
✓API-first — s'intègre dans n'importe quelle stack
✓Parallélisme natif, file FIFO filesystem
✓Limites de concurrence par utilisateur / plan
Design API

Modifications chirurgicales.
Sans écrasement.

Les endpoints PATCH utilisent une fusion profonde récursive — seuls les champs envoyés sont mis à jour. Conçu pour l'autosave, les éditeurs inline et les constructeurs de pipelines assistés par IA.

Étape actuelle
{
  "ws_name": "classify",
  "ws_llm": {
    "provider": "anthropic",
    "model": "claude-sonnet",
    "temperature": 0
  },
  "ws_system_prompt":
    "You are an expert…"
}
+
Corps PATCH
{
  "workflow_name": "triage",
  "ws_name": "classify",
  "patch": {
    "ws_llm": {
      "temperature": 0.4
    }
  }
}
→
Résultat
{
  "ws_name": "classify",
  "ws_llm": {
    "provider": "anthropic", ✓
    "model": "claude-sonnet", ✓
    "temperature": 0.4  ← patched
  },
  "ws_system_prompt":
    "You are…"  ✓
}
Types d'étapes

5 primitives.
Tous les cas d'usage couverts.

Chaque étape a un ws_type qui détermine le comportement à l'exécution, les champs requis et la sémantique d'exécution.

prompt
Appel LLM. System prompt, template {{var}}, schéma de sortie typé. Streaming via SSE.
ws_llm
ws_system_prompt
ws_prompt_template
api
Appel HTTP. L'URL supporte la substitution {{input}}. Retourne du JSON parsé ou du texte brut.
ws_api.method
ws_api.url
ws_api.headers
transform
Remise en forme de données entre étapes. Filtrer, calculer ou dériver des champs depuis les sorties amont.
ws_transform_fn
— bientôt disponible
tool
Appel d'outil MCP. Google Maps, Asana, Gmail, Slack… via le tableau ws_tools.
ws_tools: [
"maps_search"
]
script
Exécution de code personnalisé dans un runtime sandboxé avec entrées liées et sorties typées.
ws_script
— bientôt disponible
Démarrer

Opérationnel
en 3 minutes.

Self-host avec Docker. Zéro service externe — juste un secret JWT et votre clé Anthropic.

1
Cloner et configurer
Deux secrets à générer : un pour la signature JWT, un pour le chiffrement des clés API au repos.
git clone https://github.com/jpdesmontils/waiflo
cd waiflo && cp .env.example .env
# Définir JWT_SECRET et MASTER_SECRET dans .env
2
Démarrer le serveur
Lance l'API + l'éditeur visuel. Persiste les fichiers de workflow dans un volume monté — aucune base de données requise.
docker compose up -d
# Éditeur disponible sur http://localhost:3001/editor
3
Ouvrir l'éditeur — ou appeler l'API directement
Explorez l'éditeur visuel sans compte. Ou inscrivez-vous et commencez à pousser des workflows par programme depuis votre pipeline CI, votre agent ou votre backend.
# Essayez d'abord l'éditeur — sans compte requis
open http://localhost:3001/editor

# Ou commencez par l'API
curl -X POST http://localhost:3001/api/auth/register \
  -d '{"email":"vous@exemple.com","password":"secret"}'

La plupart des équipes sont opérationnelles
en moins de 10 minutes.

Éditeur visuel inclus. Pas d'inscription pour explorer. Vos clés API ne quittent jamais votre infrastructure.

Sur la pérennité : Sous licence MIT. Vos workflows sont de simples fichiers JSON — ils survivront à n'importe quel SaaS, framework ou vendeur. Si Waiflo disparaissait demain, vos pipelines continueraient à fonctionner.
⬡ Ouvrir l'éditeur ★ GitHub