Architecture
Comment Scrydon est organisé au sein de votre cluster — zones de confiance, sous-systèmes, traversées de trafic et où trouver quoi.
Scrydon est une plateforme Kubernetes déployée chez le client. Cette section est la référence architecturale du système que vous exploitez.
Zones de confiance
Trois zones, avec une frontière explicite et configurable entre elles :
| Zone | Propriétaire | Ce qui s'y trouve |
|---|---|---|
| Scrydon | Scrydon (le fournisseur) | Serveur de licences (license.scrydon.com). Le seul point de terminaison que votre cluster contacte. Aucune donnée client ne transite ici. |
| Client | Vous — votre cluster Kubernetes | L'ensemble de la plateforme Scrydon : ingress, authentification, workflows agentiques, analytics, ontologie, stockage de documents et (en option) un pool GPU appartenant au client pour l'inférence auto-hébergée. |
| Fournisseurs externes | Tiers — OpenAI, Anthropic, Microsoft, Azure OpenAI, AWS Bedrock, ElevenLabs, Microsoft Graph, … | API cloud LLM / embeddings / STT / TTS / GPU. Accessibles depuis la zone client uniquement lorsque vous activez une intégration. |
Vue simplifiée
Le schéma à insérer dans une présentation :
Traversées de trafic entre zones
Seules trois traversées existent :
| Direction | Requis / Optionnel | Objectif |
|---|---|---|
| Client → Scrydon | Requis pour le fonctionnement sous licence (trafic de licence uniquement) | Validation quotidienne de la licence (POST /api/license/validate, fenêtre de grâce de 30 jours). |
| Client → Fournisseurs externes | Optionnel par intégration | LLM cloud / embeddings / STT / TTS / GPU / Microsoft Graph — résolu via le registre d'intégrations. Jamais codé en dur. |
| Utilisateur → Client | Requis | Tout le trafic produit — chat, documents, voix. Se termine à Traefik dans votre cluster. |
Aucune donnée ne franchit la frontière Client → Scrydon en dehors du heartbeat de licence. Aucune donnée ne franchit Client → Fournisseurs externes à moins que votre organisation n'installe et sélectionne explicitement cette intégration.
Sous-systèmes
Agentic
Le moteur de workflows. Éditeur visuel, automatisations et moteur d'exécution des workflows.
Pile Analytics
Tables gérées, inférence de schéma, classification et la couche OLAP qui les sous-tend.
Ontologie
Couche d'objets, liens et actions typés au-dessus de vos tables gérées et bases de connaissances.
Cortex (passerelle LLM)
Le saut interne emprunté par chaque appel LLM, embedding et image.
Copilot
Assistant piloté par l'IA intégré à l'éditeur de workflows — modes Demander, Construire et Planifier.
Voix en temps réel
Pipeline WebRTC à faible latence pour les agents vocaux.
Comment une requête circule
Une requête typique — « l'utilisateur pose une question à l'agent de chat qui nécessite une recherche dans une table gérée » — touche une poignée de sous-systèmes dans cet ordre :
- Traefik termine TLS et route vers Platform (auth + session).
- Platform authentifie l'utilisateur, évalue le registre de politiques et transfère vers Agentic.
- Agentic exécute le workflow. Le bloc Agent achemine son appel LLM via Cortex.
- Cortex choisit le modèle — inférence auto-hébergée ou fournisseur cloud externe — et retourne la réponse.
- L'agent appelle un outil qui lit une table gérée. Analytics projette le résultat typé via la couche Ontologie (si le workflow en utilise une), en appliquant au passage les labels DLP et le masquage de colonnes.
- La réponse est diffusée en streaming vers l'utilisateur par le même chemin.
Chaque étape est autorisée, chaque appel inter-services est mutuellement authentifié, et chaque opération sensible atterrit dans le journal d'audit.
Sections associées
- Déploiement — installer Scrydon sur votre cluster (Helm, Azure Marketplace, Zarf air-gapped).
- Sécurité — DLP, autorisation, secrets, audit, mTLS, durcissement de l'ingress.
- Conformité — ISO 27001 / 42001, EU AI Act, RGPD, SOC 2, SecNumCloud, NIST, CRA, AIUC-1.
- Plateforme — identité, espaces de travail, paramètres, licences.