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

Fournisseur               ex. google, openai, scrydon
└── Produit               ex. gmail, sheets, drive — un par domaine fournisseur
      ├── Bloc            carte de l'éditeur de workflow (un par produit)
      ├── Outils          opérations individuelles que l'agent peut appeler
      ├── Déclencheurs    déclencheurs webhook + polling
      └── Capacités       contrats d'exécution : LLM, STT, TTS, embeddings, image, vidéo, OCR, webhooks, découverte

Un workflow qui « envoie un Gmail » utilise fournisseur=google → produit=gmail → outil=send-mail. La carte « Gmail » sur le canvas correspond à google → gmail → bloc. Le registre des intégrations 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

Niveaux d'isolation

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

defineExtension({
  // ...
  isolation: "microvm", // facultatif — par défaut "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é.

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

Les capacités sont résolues via le registre des intégrations, 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 — les appelants traduisent cela en HTTP 412 (« aucun fournisseur configuré »)

Les capacités se résolvent via vos intégrations installées — aucun fournisseur n'est codé en dur et aucun repli silencieux ne se produit. Les requêtes de synthèse vocale (STT) sont traité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 intégrations 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é.