Architecture
Ce qui compose beVault, et ce qui reste chez vous.
Cette page décrit l'architecture technique de la plateforme : les composants beVault et leur rôle, les personnes qui les utilisent, et la frontière avec ce qui vous appartient — sources de données, infrastructure, bases cibles, sorties et contexte de déploiement.
Schéma d'architecture
Les composants beVault et votre environnement
Les utilisateurs travaillent dans metaVault et States ; les Workers exécutent les traitements, lisent les sources et chargent la base cible de votre infrastructure, qui alimente ensuite vos sorties.
Le point de départ
La première question d'un architecte
Avant de parler de fonctionnalités, une équipe d'architecture veut savoir ce qui est installé, où cela s'exécute, ce qui traverse le réseau et ce qui reste sous son contrôle. C'est une question d'architecture, pas de licence.
beVault est volontairement resserré : trois composants, des responsabilités séparées, et une frontière explicite avec votre paysage applicatif. Le reste — vos sources, votre infrastructure, vos bases cibles et vos outils de restitution — demeure votre périmètre.
Composants
Trois composants beVault, utilisés par vos équipes
La séparation entre modélisation, définition des workflows et exécution permet de faire évoluer le modèle sans réécrire les traitements.
- 01
metaVault — l'environnement de modélisation
Vos équipes y décrivent le modèle : entités métier, clés métier, relations et attributs. Les métadonnées saisies ici pilotent la génération des structures et du code de chargement.
- 02
States — la définition des workflows
C'est là que sont décrits les workflows d'extraction et d'export : quelles données sont récupérées, dans quel ordre, sous quelles conditions, et vers quelles destinations.
- 03
Workers — l'exécution
Les composants d'exécution. Ils exécutent les workflows définis dans States, appliquent le code généré et effectuent les chargements dans la base cible.
Votre périmètre
Ce qui reste chez vous
Les sources restent vos systèmes : applications métier et fichiers présents dans votre paysage applicatif. Les Workers viennent y lire les données, les déposent en staging, puis appliquent les chargements dans la base cible que vous avez retenue.
Intégration et connectivité- Bases de données cibles
- Snowflake, Amazon Redshift, Microsoft SQL Server et PostgreSQL sont supportés aujourd'hui. Databricks, Microsoft Fabric et Google BigQuery arrivent bientôt.
- Sorties et consommation
- Les données préparées sont mises à disposition des outils de restitution et des systèmes consommateurs de votre environnement.
- Orchestrateur externe
- AWS Step Functions est pris en charge comme orchestrateur externe. Ce n'est pas une base cible.
Contexte de déploiement
Où s'exécute la plateforme
Vous décidez de l'emplacement des composants ; la frontière avec votre environnement reste lisible.
Les composants s'installent dans l'environnement que vous avez choisi — on-premises, cloud, PaaS ou hybride — avec Docker comme technologie de déploiement.
Étape suivante