Fournisseurs

Un fournisseur est un système tiers (ou interne) avec lequel Scrydon communique — Google, OpenAI, Salesforce, Mistral, le noyau scrydon intégré, etc. Chaque bloc, outil et capacité d'exécution que vous pouvez utiliser dans un workflow est exposé par un fournisseur.

Le modèle

Vendor                    e.g. google, openai, scrydon
└── Product               e.g. gmail, sheets, drive — one per vendor area
      ├── Block           workflow-editor card (one per product)
      ├── Tools           individual operations the agent can call
      ├── Triggers        webhook + polling triggers
      └── Capabilities    runtime contracts: LLM, STT, TTS, embeddings, image, video, OCR, webhooks, discovery

Un workflow qui « envoie un Gmail » utilise vendor=google → product=gmail → tool=send-mail. La carte « Gmail » sur le canvas correspond à google → gmail → block. Le registre des extensions de la plateforme résout tout cela — vous ne codez jamais les noms de fournisseurs en dur dans le code de workflow.

Catalogue

Intégré (toujours disponible)

Productivité & Stockage

IA & LLMs

Cloud

Observabilité

Niveaux d'isolation

Une définition de fournisseur peut déclarer comment la plateforme isole son archive à l'exécution :

defineExtension({
  // ...
  isolation: "microvm", // optional — defaults to "memory"
})

• memory (déclaration historique par défaut) — le manifeste ne renforce pas le minimum du déploiement ou de l'organisation. Le résolveur partagé lie quand même l'exécution à microvm ou managed_process ; cette valeur ne désigne jamais un Worker Thread en cours de processus.
• microvm — l'archive exige une microVM dédiée. Si ce niveau n'est pas autorisé, prouvé et prêt, l'exécution est refusée ; il n'existe aucune rétrogradation.

Le champ du manifeste déclare un niveau minimal d'isolation ; ce n'est pas un sélecteur de backend. Les administrateurs peuvent consulter le niveau d'exécution effectif dans le journal d'audit.

Origine des fournisseurs

Les deux approches produisent le même type d'artefact (une définition defineExtension()) ; la seule différence est l'endroit où l'archive est stockée.

Résolution des capacités (LLM, STT, TTS, embeddings, …)

Les capacités sont résolues via le registre des extensions, dans cet ordre :

1. Surcharge par appel (ex. un paramètre de bloc qui fixe un modèle)
2. Politique d'organisation (valeurs par défaut configurées par un administrateur)
3. Sélection automatique parmi les candidats installés (le premier correspondant à la capacité demandée)
4. null — la plateforme répond 409 CAPABILITY_NOT_CONFIGURED (« aucun fournisseur configuré »)

Les capacités se résolvent via vos extensions installées — aucun fournisseur n'est codé en dur et aucun repli silencieux ne se produit. Les requêtes de reconnaissance vocale (speech-to-text) sont relayées côté serveur par la plateforme (les identifiants ne quittent jamais le serveur) ; les autres capacités (LLM, embedding, OCR) se résolvent via vos extensions installées au moment de la requête. N'importez jamais un SDK fournisseur directement dans le code produit, ne codez jamais un fournisseur en dur, ne revenez jamais silencieusement à un fournisseur que l'organisation n'a pas installé.