Étapes de code (code_step)
Certaines logiques sont trop spécifiques pour un opérateur compute, mais trop déterministes pour mériter un agent LLM : recoupements multi-sources, calculs métier sur-mesure, normalisations exotiques. Pour ces cas, le nœud code_step exécute du code dans une sandbox, sans appel LLM, avec une sortie prévisible.
Le code s'édite directement, comme n'importe quel champ de configuration : aucune clé de code_step n'est verrouillée, et aucune approbation spécifique au code n'est exigée. Une modification s'applique dès la publication du pipeline, à la prochaine exécution.
Le modèle d'exécution
code_step exécute du Starlark — un dialecte de Python conçu pour l'isolation : pas d'accès au système de fichiers, pas de réseau, pas d'import, ni boucle while ni récursion, déterministe, borné par un budget de temps. Le code ne voit que :
- Les entrées que vous lui mappez explicitement (
input_paths). - Les tools que vous l'autorisez à appeler (
allowed_tools).
Tout le reste est hors de portée. Une étape de code ne peut pas atteindre une ressource que vous ne lui avez pas tendue.
Configuration
| Champ | Rôle |
|---|---|
| Code | La source Starlark exécutée, éditable directement. |
Entrées (input_paths) | Mapping variable → sélecteur. Seules ces clés du contexte sont exposées au code. Les clés internes (_*) sont refusées. |
Allowlist tools (allowed_tools) | Les tools appelables via tool(nom, args), 50 appels maximum par exécution. Chaque appel hérite des garde-fous du tool (SSRF, facturation, audit, killswitch). |
Clé de sortie (output_key) | Où poser le résultat (sérialisable JSON) dans le contexte. Les nœuds aval lisent cette clé. Vide = résultat non stocké. |
Budget d'exécution (timeout_ms) | Plafond de temps : 5 000 ms par défaut, 30 000 ms maximum. Une étape qui dépasse échoue. |
Où est la frontière de sécurité
Le langage n'est pas la menace : Starlark est sandboxé par conception — il ne peut, à lui seul, ni lire un fichier, ni atteindre le réseau, ni boucler indéfiniment. Du code purement calculatoire est sans danger.
La seule capacité réelle est le pont tool(), et il est borné par l'allowlist appliquée au runtime : le code ne peut appeler que les tools que vous avez listés (un autre appel est refusé), et chacun porte ses propres garde-fous (SSRF, facturation, audit, killswitch). L'allowlist s'édite aussi librement que le code : c'est sur le choix des tools que vous cadrez ce qu'une étape peut faire.
Une allowlist vide = aucune capacité d'effet de bord : l'étape ne fait que calculer sur ses entrées et produire une sortie.
Quand l'utiliser
- Oui : une logique déterministe que vous savez décrire précisément, mais qui dépasse les opérations
computelivrées (réconciliation de plusieurs listes, règle métier composite, format propriétaire). - Non : un simple filtre, une agrégation, une projection → un opérateur
computesuffit. - Non : une tâche qui demande du jugement ou de la rédaction → c'est un agent, pas du code.