Opérateurs

Un opérateur est un nœud qui exécute une action déterministe : pas de LLM, pas d'aléatoire. Pour chaque entrée donnée, la sortie est prévisible.

Pourquoi les utiliser

Toute logique qui peut être écrite explicitement doit l'être. Un LLM qui « calcule un total » ou « formate une date » est un anti-pattern : il est plus lent, plus cher, et peut se tromper.

Règle pratique : si vous savez écrire la fonction en 5 lignes de Python, c'est un opérateur — pas un agent.

Types disponibles

operator HTTP

Effectue un appel HTTP (REST, GraphQL). Configuration :

• URL (avec placeholders depuis le contexte)
• Méthode, headers, body
• Authentification : bearer, basic, api_key_header (header custom) ou oauth2 (voir ci-dessous)
• Mapping de la réponse vers des slots

operator DB

Exécute une requête sur une base de données enregistrée dans Administration → Bases de données. Supporte Postgres, MySQL, MongoDB, et la base interne betool pour les tables user-defined.

file_transform

Transforme un fichier. Transformers livrés :

• Lecture (PDF avec OCR, DOCX, XLSX, CSV)
• Découpe (par page, par chunk de tokens)
• Conversion (HTML → texte, Markdown ↔ HTML)
• Extraction de structure (JSON depuis un schéma)

compute

Calculs et agrégations sur les slots du contexte :

• Filtre / map / reduce sur des listes
• Stats colonne par colonne (count, total, pct)
• Projections de schéma
• Conditions logiques composées

payload_mapper

Composition d'un payload de sortie depuis des slots du contexte. Utile pour préparer le body d'un opérateur HTTP downstream.

code_step

Quand une logique déterministe dépasse ce que compute sait faire, une étape de code exécute du code custom en sandbox — verrouillé par revue humaine. Voir Étapes de code gouvernées.

Authentification & secrets

Les opérateurs qui parlent à un système externe (HTTP, DB) référencent un compte enregistré dans l'organisation. Les credentials ne sont jamais visibles dans le pipeline lui-même — juste un nom de compte.

Conséquence : changer un mot de passe ne nécessite pas de rééditer chaque pipeline.

OAuth2 sortant (client_credentials)

Pour les APIs qui exigent un jeton OAuth2 (cloud d'entreprise, ERP, providers tiers), l'opérateur HTTP supporte le mode oauth2. Vous enregistrez un credential OAuth2 dans l'organisation — token_url, client_id, client_secret, scope — et le nœud n'y référence qu'un identifiant non secret.

Au moment de l'appel, betool obtient un jeton et le réutilise tant qu'il est valide ; il le rafraîchit paresseusement à expiration, sans tâche de fond. Le client_secret n'est jamais renvoyé en lecture par l'API d'administration (seul un indicateur a un secret est exposé), et le jeton obtenu est posé en Authorization: Bearer … sur la requête sortante.

Changer le secret après une rotation côté provider ne demande aucune réédition de pipeline : le prochain appel rafraîchit automatiquement.

Idempotence

Tout opérateur qui produit un effet de bord (POST HTTP, INSERT DB, envoi d'email) doit être pensé idempotent côté cible. Pratique recommandée :

• Inclure un idempotency_key dans le payload (typiquement exchange_id).
• Vérifier côté cible si la clé a déjà été traitée.

betool ne réessaie pas automatiquement un opérateur qui a échoué : c'est à votre pipeline d'orchestrer la stratégie de retry (boucle + condition).