Actions réutilisables

La même étape revient généralement dans plusieurs automatisations. Une alerte Slack, une écriture dans un journal d'audit, un appel à une API interne. Copier cette étape dans chaque automatisation oblige à répercuter chaque changement futur dans chaque copie.

app.actions est une bibliothèque de modèles nommés. Définissez l'étape une seule fois, avec des espaces réservés $variable là où les entrées diffèrent :

actions:
  - name: notify-slack
    action:
      type: http
      operator: post
      props:
        url: $env.SLACK_WEBHOOK_URL
        body: { text: '$message' }

Invoquez-la ensuite depuis n'importe quelle automatisation avec une action ref, en passant les valeurs :

automations:
  - name: order-alert
    trigger: { type: record, table: orders, events: [create] }
    actions:
      - name: alert
        $ref: notify-slack
        $vars: { message: 'New order recorded.' }

Propriétés d'un modèle

Invoquer un modèle

L'action ref est la seule action sans operator. Elle transporte une référence et, si besoin, les valeurs propres à ce site d'appel :

Écrire type: ref reste facultatif. Un $ref est déjà sans ambiguïté : { name: alert, $ref: notify-slack } et la forme explicite { name: alert, type: ref, $ref: notify-slack } désignent la même action.

Variables

Un espace réservé est un $ suivi d'un nom alphanumérique ($message, $channel). À l'invocation, les variables fusionnées fournissent les valeurs :

Cette dernière règle est ce qui permet à un modèle de mêler les trois familles de références. Déclarez les valeurs par défaut qui vous intéressent, et laissez les références d'environnement et les variables de gabarit d'automatisation être résolues plus tard par leurs propres moteurs.

Le même modèle avec des variables différentes produit des étapes différentes :

actions:
  - name: notify-team
    variables:
      channel: general
      message: Something happened.
    action:
      type: http
      operator: post
      props:
        url: $env.SLACK_WEBHOOK_URL
        body: { channel: '$channel', text: '$message' }

automations:
  - name: order-alert
    trigger: { type: record, table: orders, events: [create] }
    actions:
      - { name: alert, $ref: notify-team, $vars: { message: 'New order.' } }
      - { name: escalate, $ref: notify-team, $vars: { channel: ops, message: 'Check stock.' } }

Exposer un modèle à l'IA

Un modèle doté d'un bloc aiAccess devient un outil MCP directement invocable. Ses variables deviennent les paramètres de l'outil : la déclaration qui rend une étape réutilisable la rend donc aussi appelable.

actions:
  - name: archive-order
    variables:
      reference: ''
    action:
      type: record
      operator: update
      props:
        table: orders
        filter:
          conditions: [{ field: reference, operator: equals, value: '$reference' }]
        data: { archived: true }
    aiAccess:
      description: Archive one order by its reference.
      annotations: { readOnly: false, destructive: false, idempotent: true }

Le fait que le serveur monte réellement ces outils relève de l'exploitant, via MCP_ENABLED. Voir Serveur MCP.

Validation

Pages connexes

• Vue d'ensemble des actions — le modèle d'action et les ~22 familles qu'un modèle peut envelopper.
• Vue d'ensemble des automatisations — l'anatomie déclencheur + actions.
• Composants réutilisables — le même principe pour l'arbre de composants d'une page.
• Serveur MCP — les modèles d'action exposés comme outils IA.
• Variables d'environnement — les références $env.NAME que porte le corps d'un modèle.