Sous-pipelines
Au-delà d'un certain point, copier la même séquence de nœuds dans dix pipelines devient une dette. Les sous-pipelines permettent à un pipeline d'en appeler un autre comme une fonction : on définit une logique une fois, on la réutilise partout — y compris entre organisations.
Deux briques symétriques :
pipeline_callable(un receiver, déclaré sur le nœud Start) expose un pipeline derrière une URL, avec un contrat d'entrées et de sorties typé.pipeline_call(un nœud) appelle ce pipeline : il mappe ses entrées depuis le contexte courant, et range le résultat dans une clé de sortie.
Exposer un pipeline (pipeline_callable)
Sur le pipeline « service », vous ajoutez un receiver pipeline_callable qui déclare :
- Entrées — la liste des paramètres attendus (nom, type, requis ou non).
- Sorties — les clés du résultat renvoyé.
- Clé de réponse — quelle valeur du contexte constitue la réponse.
- Budget de temps — délai max d'exécution (30 s par défaut, 300 s max).
Le pipeline obtient alors une URL publique (avec un jeton), à communiquer au pipeline appelant. Le jeton est rotatable à tout moment pour révoquer un accès.
Appeler un pipeline (pipeline_call)
Sur le pipeline « consommateur », le nœud pipeline_call est configuré avec :
- L'URL du pipeline cible.
- Un mapping d'entrées — pour chaque paramètre attendu, le sélecteur du contexte qui le remplit.
- La clé de sortie où ranger le résultat.
En cas d'échec (timeout, erreur, réponse malformée), le pipeline continue : la clé de sortie reçoit null et une clé ._error décrit ce qui s'est passé. À vous d'orchestrer la suite (branche de repli, alerte).
Appels entre organisations : opt-in et audité
Un sous-pipeline peut être appelé par une autre organisation — c'est la base d'un partage de capacités entre entités. Le modèle reste strict :
- Refusé par défaut. L'appel cross-organisation n'est possible que si l'administrateur du pipeline exposé l'autorise explicitement (
allow_cross_org). - Signature HMAC recommandée. Dès qu'on ouvre un appel cross-org, on active un secret partagé : chaque requête est signée, le receiver rejette une signature absente ou invalide.
- Tout est tracé. Chaque invocation écrit une ligne d'audit (organisation appelante, nœud, profondeur, latence, statut) — avant l'exécution, pour qu'une trace subsiste même en cas d'incident. Les deux parties consultent leurs journaux (côté appelant comme côté appelé), conformément au droit d'accès RGPD.
Facturation : l'organisation appelée paie les ressources (LLM, voix…) consommées pendant l'exécution. Logique de l'invité : vous utilisez les ressources de votre hôte.
Anti-boucle
Un pipeline qui s'appellerait lui-même, directement ou via une chaîne, consommerait des crédits à l'infini. Deux protections :
- Détection statique à l'enregistrement (au sein d'une organisation) : l'éditeur refuse de publier un cycle direct (
A → A) ou indirect (A → B → C → A), en citant la chaîne fautive. - Garde-fou au runtime (entre organisations, où la visibilité statique est impossible) : chaque appel propage sa profondeur ; au-delà d'un plafond, l'appel est coupé.
Modes d'exécution
- Synchrone — le nœud attend la réponse complète. Adapté aux traitements courts.
- Streaming — pour un sous-pipeline long (raisonnement LLM, traitement par lots), la progression est streamée en temps réel, sans timeout fixe. Le pipeline appelant peut exposer cette progression dans une UI.
Quand l'utiliser
- Factoriser une séquence réutilisée par plusieurs pipelines (résumer un fil, qualifier un lead, vérifier une pièce).
- Partager une capacité entre organisations — une entité expose « vérifier une facture contre l'ERP », une autre la consomme, avec audit des deux côtés.
- Paralléliser un éventail de sous-traitements indépendants depuis une boucle.