Ce que fait Semavex

Semavex est une plateforme de rapports et d'analytique qui se connecte directement à la base de données SQL Server ou PostgreSQL de votre entreprise. Une fois connectée, vos équipes génèrent des rapports en formulant des demandes en langage courant. Vexon, l'agent IA intégré, prend en charge l'ensemble du processus entre la demande et le rapport livré : il lit votre schéma, planifie une stratégie de requête, génère du SQL optimisé, met en forme le résultat et le livre selon la planification définie par courriel.

Le cycle principal est simple. Un utilisateur saisit une demande décrivant le rapport dont il a besoin. Vexon inspecte le schéma de la base de données connectée, y compris les métadonnées d'index, et génère du SQL à la fois logiquement correct et opérationnellement efficace. Le résultat est mis en forme sous la forme d'un rapport structuré, puis retourné immédiatement dans l'interface ou mis en file d'attente pour une livraison planifiée à un ou plusieurs destinataires par courriel.

Trois profils d'utilisateurs se servent de Semavex. Les décideurs techniques qui veulent comprendre l'architecture avant de signer un contrat. Les ingénieurs de données qui configurent et maintiennent la connexion à la base de données. Et les analystes ou membres d'équipes BI qui génèrent des rapports au quotidien. Cette documentation est organisée pour servir ces trois profils : des explications d'architecture pour le premier groupe, des détails de configuration pour le deuxième, et des conseils pratiques pour le troisième.

Comment fonctionne la plateforme

Le frontend de Semavex est construit avec Next.js 15. Il communique avec un backend .NET 10 qui sert de couche API, orchestrant la génération de rapports, la planification et la livraison. Le backend se connecte à la base de données SQL Server ou PostgreSQL du client pour les données de rapport, et utilise sa propre base de données PostgreSQL pour l'état de la plateforme : comptes utilisateurs, rapports sauvegardés, définitions de planification et instantanés de schéma.

Les rapports planifiés sont gérés par Hangfire, un système de tâches en arrière-plan intégré au backend .NET. Lorsqu'un rapport est dû, Hangfire déclenche Vexon pour générer le rapport et le transmettre à Resend pour la livraison par courriel. Le frontend, le backend, Hangfire et Vexon forment une boucle fermée : les demandes de rapports arrivent depuis l'interface, Vexon les traite sur la base de données du client, et les résultats reviennent sous forme de rapports formatés ou de livraisons planifiées.

Vexon ne fonctionne pas via une interface de conversation. Chaque action de Vexon est un appel d'outil structuré défini dans le code source de Semavex. Le backend expose un ensemble spécifique d'outils, incluant l'exécution de requêtes, l'inspection de schéma, la livraison par courriel et la planification de tâches. Vexon appelle ces outils en séquence, et chaque appel est journalisé. Cela signifie que le comportement de Vexon est encadré, déterministe et vérifiable. Il n'improvise pas, et ses capacités correspondent exactement à ce que l'équipe d'ingénierie de Semavex a construit, et non à la surface complète d'un modèle d'IA généraliste.

Connecter votre base de données

Semavex prend en charge SQL Server et PostgreSQL. La configuration de la connexion nécessite une chaîne de connexion et un compte de service de base de données. Nous recommandons d'utiliser un compte de service en lecture seule limité au schéma ou aux schémas que vous souhaitez que Vexon interroge. Vexon ne fait que lire des données. Il n'insère, ne met à jour et ne supprime rien. Un compte en lecture seule impose cette contrainte au niveau de la base de données et élimine tout risque d'écriture accidentelle, quelle que soit la situation au niveau de la couche applicative.

Lors de la première connexion, Vexon effectue une inspection unique du schéma. Il lit les noms de tables, les noms et types de colonnes, les relations de clés étrangères, les définitions d'index (y compris les index composites et partiels) et les statistiques de base. Cette inspection est en lecture seule et légère. Les requêtes que Vexon exécute sur le catalogue système sont les mêmes qu'un DBA exécuterait manuellement, et elles se terminent en quelques secondes même sur de grandes bases de données.

Après l'inspection initiale, Vexon actualise périodiquement sa connaissance du schéma. Si vous ajoutez de nouvelles tables, créez de nouveaux index ou modifiez des types de colonnes après l'intégration, Vexon détectera ces changements automatiquement lors de son prochain cycle d'actualisation. Vous n'avez pas besoin de déclencher manuellement une nouvelle inspection, bien que l'option soit disponible dans les paramètres de la plateforme si vous souhaitez forcer une actualisation immédiate.

Votre premier rapport

Ouvrez le générateur de rapports depuis le tableau de bord et saisissez une demande en langage courant décrivant les données dont vous avez besoin. Soyez précis sur la métrique, l'entité, la période et tout regroupement ou tri souhaité. Voici trois exemples représentant des cas d'utilisation réalistes :

Après votre soumission, Vexon traite la demande. Il analyse votre intention, inspecte le schéma pertinent, planifie et vérifie la requête par rapport à la topologie des index, génère le SQL pour votre moteur de base de données spécifique, l'exécute et retourne le résultat formaté. Pour un rapport simple, cela prend quelques secondes. Les requêtes complexes impliquant des agrégations sur de grandes tables peuvent prendre plus de temps, selon les performances de la base de données et la couverture des index.

Vos premiers rapports sur une base de données fraîchement connectée sont un bon moyen de vérifier que Vexon a correctement compris le schéma. Si un résultat semble incorrect, vérifiez d'abord deux choses : l'état d'actualisation du schéma (pour vous assurer que Vexon dispose des dernières définitions de tables et de colonnes) et la formulation de la demande (pour vous assurer que la requête est suffisamment précise pour que Vexon l'interprète sans ambiguïté).

Qu'est-ce que Vexon

Vexon n'est pas un chatbot. Ce n'est pas un assistant IA généraliste avec un plugin de base de données. Vexon est un agent structuré avec une mission précise : transformer une demande de rapport en un rapport livré. Il ne répond pas aux questions générales, ne génère pas de contenu créatif et n'improvise pas. Chaque action qu'il effectue est une étape définie dans un processus contrôlé.

Sur le plan architectural, Vexon est construit sur Claude via l'appel d'outils. Le backend de Semavex expose un ensemble d'outils : interroger la base de données, lire les métadonnées du schéma, planifier une tâche de livraison, envoyer un courriel. Vexon appelle ces outils en séquence pour compléter une demande de rapport. Il ne peut pas appeler des outils qui n'existent pas dans le code source de Semavex. Cette distinction est importante : les capacités de Vexon correspondent exactement à ce que l'équipe d'ingénierie a construit et exposé, et non à la surface ouverte d'un modèle d'IA généraliste.

Pour les acheteurs entreprise, cette architecture offre une garantie concrète. Chaque appel d'outil effectué par Vexon est journalisé avec ses entrées et ses sorties. Chaque rapport est traçable jusqu'au SQL spécifique qui l'a produit, aux métadonnées du schéma qui ont informé le plan de requête, et aux appels d'outils qui ont orchestré le flux de travail. Il n'y a pas de boîte noire. La piste d'audit est complète.

Comment Vexon traite une requête

Lorsqu'une demande de rapport arrive, Vexon suit une séquence spécifique. Chaque étape est une opération distincte avec des entrées et des sorties définies.

1. 1. Analyse de l'intention. Vexon lit la demande en langage naturel et en extrait une intention structurée : les tables concernées, les filtres applicables, l'agrégation nécessaire et la période spécifiée.
2. 2. Inspection du schéma. Vexon lit les métadonnées du schéma en direct pour les tables identifiées. Cela inclut les noms et types de colonnes, les relations de clés étrangères, et les définitions d'index avec l'ordre des colonnes et les conditions de filtre.
3. 3. Planification de la requête (première passe). Le planificateur ébauche une approche de requête abstraite : quelles tables joindre, dans quel ordre, avec quels prédicats de filtre. À ce stade, le plan est structurel et n'est pas encore du SQL.
4. 4. Révision des index (deuxième passe). Le réviseur vérifie le plan provisoire par rapport à la topologie réelle des index. Il s'assure que les prédicats de filtre correspondent aux préfixes des index composites, que l'ordre de jointure tire parti des index disponibles, et qu'aucun schéma défavorable aux index n'est présent. Si le plan échoue à la révision, il est révisé avant de poursuivre.
5. 5. Génération SQL. Le plan révisé est matérialisé en SQL, écrit pour le moteur de base de données connecté. Les requêtes SQL Server utilisent la syntaxe T-SQL. Les requêtes PostgreSQL utilisent le SQL standard. La requête générée respecte le comportement et les références de catalogue spécifiques au moteur.
6. 6. Exécution et mise en forme. La requête s'exécute sur la base de données connectée. Le jeu de résultats est formaté sous forme de rapport structuré avec les en-têtes, le regroupement et le formatage numérique appropriés.
7. 7. Livraison. Le rapport est retourné à l'utilisateur dans l'interface, envoyé immédiatement par courriel via Resend, ou mis en file d'attente comme tâche planifiée dans Hangfire, selon la configuration de la demande.

Ce que Vexon peut faire de manière autonome

Vexon peut exécuter les actions suivantes sans nécessiter d'intervention humaine intermédiaire. En réponse à une seule demande de rapport, il peut enchaîner toutes ces actions dans un flux de travail coordonné.

Il génère et exécute des requêtes SQL sur la base de données connectée. Il lit les métadonnées du schéma et des index depuis le catalogue système de la base de données. Il planifie des tâches de livraison récurrentes via le système de tâches en arrière-plan Hangfire. Il envoie des courriels de rapport via Resend à un ou plusieurs destinataires spécifiés. Et il coordonne l'ensemble de ces opérations comme des appels d'outils séquentiels au sein d'un seul flux de travail de rapport.

Vexon ne peut pas modifier les données dans la base de données connectée. Il ne peut pas changer la configuration de la plateforme, les permissions des utilisateurs ou les paramètres de facturation. Il ne peut accéder à aucun système en dehors des outils que le backend de Semavex a définis pour lui. Ces limites sont imposées au niveau de l'appel d'outils. Les outils que Vexon peut invoquer sont explicitement enregistrés dans le code source, et aucun outil n'existe pour la modification de données, les changements de configuration ou l'accès externe. Il s'agit d'une contrainte structurelle, et non d'une instruction de prompt.

Rédiger des requêtes efficaces

La différence entre une requête vague et une requête précise est la différence entre Vexon qui devine ce que vous voulez et Vexon qui sait exactement quoi générer. Une bonne requête inclut quatre éléments : la métrique ou la mesure souhaitée (revenu, nombre, taux), l'entité mesurée (clients, commandes, transactions), une période et un regroupement ou un ordre de tri.

Vague vs. Précis

La version précise donne à Vexon une période (T3 2024), une dimension de regroupement (catégorie de produit), une métrique (revenu total) et un ordre de tri (décroissant par revenu). Il n'y a aucune ambiguïté sur les tables à interroger, l'agrégation à effectuer ou la façon de présenter le résultat.

Trois formulations qui fonctionnent bien

Tendance dans le temps : Utilisateurs actifs mensuels pour les 12 derniers mois. Cela donne à Vexon une structure de série temporelle avec un grain clair (mensuel) et une période de recul claire.

Top N par métrique : Top 10 des produits par unités vendues au T4 2024. Cela indique à Vexon de classer, limiter et trier, avec une période spécifique.

Répartition par catégorie : Nombre de commandes par méthode de paiement pour les 30 derniers jours. Cela demande une ventilation catégorielle avec une contrainte temporelle.

Vexon comprend la terminologie commerciale courante : MRR, churn, LTV, GMV et taux de conversion. Si le schéma connecté contient les données sous-jacentes nécessaires au calcul de ces métriques, Vexon associera la terminologie à l'agrégation appropriée. Si le schéma ne contient pas les données nécessaires, Vexon l'indiquera clairement plutôt que de retourner une approximation incorrecte.

Si un résultat de rapport ne semble pas correct, affiner la requête avec plus de précisions est presque toujours la bonne première étape. L'état d'actualisation du schéma est la deuxième chose à vérifier. Dans la plupart des cas, le problème est que la requête était suffisamment ambiguë pour que Vexon l'interprète différemment de ce que vous aviez prévu.

Pourquoi la sensibilité aux index est importante

Le SQL généré par l'IA tend à être logiquement correct mais opérationnellement coûteux. Une requête qui filtre sur la deuxième colonne d'un index composite, applique une fonction à une colonne indexée, ou joint des tables dans un ordre qui force l'optimiseur à effectuer des balayages en boucles imbriquées du mauvais côté, retournera les bonnes données. Mais elle prendra aussi 40 secondes au lieu de 200 millisecondes sur une table de 50 millions de lignes.

Ce n'est pas un cas limite hypothétique. Sur des bases de données de production contenant des dizaines de millions de lignes, la différence entre une requête optimisée pour les index et une requête naïve se cumule avec chaque rapport que chaque équipe génère chaque jour. Une plateforme qui génère 50 rapports par jour dans une organisation, chacun prenant 30 secondes de plus que nécessaire, gaspille 25 minutes de calcul de base de données quotidiennement et dégrade l'expérience pour toutes les autres charges de travail partageant cette base de données.

Semavex résout ce problème au niveau de la planification des requêtes, et non au niveau du prompt. Les utilisateurs n'ont pas besoin de rédiger des requêtes conscientes des index. Ils n'ont pas besoin de savoir quels index existent sur leur base de données. Vexon lit les métadonnées d'index en interne lors de chaque cycle de planification de requête et génère du SQL aligné sur la topologie réelle de stockage et de récupération de la base de données.

Comment Vexon lit votre schéma

Vexon lit les métadonnées du schéma et des index depuis le catalogue système de la base de données. Les vues spécifiques dépendent du moteur de base de données.

SQL Server

sys.tables et sys.columns fournissent l'inventaire des tables et des colonnes. sys.indexes et sys.index_columns décrivent chaque index : son type (clustered, nonclustered, filtré), les colonnes qu'il couvre et l'ordre des colonnes au sein des index composites. sys.foreign_keys cartographie les relations entre les tables. sys.stats fournit des estimations de cardinalité qui orientent les décisions d'ordre de jointure.

PostgreSQL

information_schema.columns et information_schema.table_constraints fournissent l'inventaire des colonnes et les définitions de contraintes. pg_indexes décrit les définitions d'index, y compris les prédicats des index partiels. pg_stats fournit des statistiques au niveau des colonnes, y compris le nombre de valeurs distinctes et les valeurs les plus courantes, que Vexon utilise pour l'estimation de cardinalité dans la planification des jointures.

Cette inspection s'exécute lors de la première connexion et s'actualise périodiquement. Les requêtes sur les catalogues système sont légères, en lecture seule et se terminent en quelques secondes. Elles ne verrouillent pas les tables, ne consomment pas de ressources significatives et ne s'exécutent pas à chaque demande de rapport. Vexon met en cache l'instantané du schéma et ne le relit qu'au prochain cycle d'actualisation planifié ou lorsque vous déclenchez une actualisation manuelle depuis les paramètres de la plateforme.

Index composites et partiels

Index composites

Un index composite sur (column_a, column_b, column_c) n'est utilisé efficacement que lorsque les requêtes filtrent sur un préfixe de cette séquence de colonnes. Un filtre sur column_a seul utilise l'index. Un filtre sur column_a et column_b l'utilise de manière plus sélective. Un filtre sur column_b seul ne l'utilise pas du tout, car l'arbre B de l'index est ordonné par column_a en premier. Vexon lit l'ordre des colonnes depuis le catalogue système et construit des prédicats de filtre qui correspondent au préfixe de l'index. Lorsqu'une requête implique plusieurs colonnes d'un index composite, Vexon ordonne les prédicats pour les aligner sur la structure de l'index.

Index partiels

Un index partiel ne couvre que les lignes qui correspondent à une condition de filtre. Par exemple, un index sur transaction_date WHERE status = 'completed' n'indexe que les lignes dont le statut est 'completed'. Une requête qui n'inclut pas status = 'completed' dans sa clause WHERE ne peut pas utiliser cet index. Vexon lit l'expression de filtre de l'index depuis le catalogue et incorpore le prédicat correspondant dans le SQL généré lorsque l'index partiel est pertinent pour la requête.

Index couvrants

Un index couvrant inclut toutes les colonnes nécessaires pour satisfaire une requête entièrement depuis l'index, sans toucher la table de base. Sur une table contenant des millions de lignes, cela élimine les recherches de clés (key lookups), qui sont l'une des causes les plus courantes de requêtes lentes sur des bases de données bien indexées. Vexon identifie les index couvrants lors de la passe de révision et génère des requêtes qui sélectionnent uniquement les colonnes présentes dans l'index couvrant lorsque c'est possible.

Les décisions d'ordre de jointure sont éclairées par les estimations de cardinalité du catalogue de statistiques. Lorsque plusieurs chemins de jointure existent, Vexon séquence les jointures de sorte que les index à haute sélectivité sur la table directrice réduisent le nombre de lignes qui alimentent les jointures suivantes. Cela maintient les ensembles de résultats intermédiaires petits et évite la dégradation de performance qui survient lorsqu'une jointure à faible sélectivité inonde l'étape suivante avec des millions de lignes.

Planification de requêtes en pratique

Considérez une table appelée transactions contenant 40 millions de lignes. Elle possède un index composite sur (customer_id, transaction_date, status) et un index partiel sur transaction_date WHERE status = 'settled'. Un utilisateur demande : « Montrez-moi le volume de transactions réglées par client pour le mois dernier. »

Un générateur de requêtes naïf pourrait produire quelque chose comme ceci :

Cette requête encapsule transaction_date dans les fonctions MONTH() et YEAR(). Ces appels de fonction empêchent la base de données d'utiliser un balayage par plage d'index sur transaction_date. L'index composite ne peut pas être utilisé car la requête ne filtre pas d'abord sur customer_id (la colonne de tête). L'index partiel sur les transactions réglées est disponible, mais l'encapsulation par fonction sur la colonne de date force quand même un balayage à l'intérieur.

La version optimisée pour les index utilise un prédicat de plage de dates au lieu d'appels de fonction, préservant l'éligibilité à l'index. Le prédicat status = 'settled' qualifie la requête pour l'index partiel sur transaction_date WHERE status = 'settled'. La base de données peut maintenant effectuer un balayage par plage d'index sur la plage de dates au sein de l'index partiel, ne touchant que les lignes pertinentes. Sur une table de 40 millions de lignes, c'est la différence entre une réponse en moins d'une seconde et un balayage complet de plusieurs secondes.

Configurer une planification

Le constructeur de planification est un éditeur visuel CRON. Vous sélectionnez une fréquence (horaire, quotidienne, hebdomadaire, mensuelle ou personnalisée) et le constructeur affiche l'expression CRON correspondante accompagnée d'un libellé lisible. Sélectionner « Chaque lundi à 8 h 00 », par exemple, génère l'expression 0 8 * * 1. Si vous avez besoin d'une planification non standard, vous pouvez saisir une expression CRON personnalisée directement et le constructeur affichera l'interprétation lisible.

Les planifications sont rattachées aux rapports sauvegardés. Tout rapport ayant été généré au moins une fois peut être planifié. Vous sélectionnez le rapport, configurez la fréquence et l'heure, ajoutez les adresses courriel des destinataires et activez la planification. À partir de ce moment, Semavex génère et livre le rapport automatiquement à l'intervalle spécifié.

Les planifications s'exécutent dans le fuseau horaire configuré pour votre espace de travail. Le fuseau horaire est affiché clairement dans le constructeur de planification afin qu'il n'y ait aucune ambiguïté sur le moment de la livraison. Si votre équipe couvre plusieurs fuseaux horaires, définissez le fuseau horaire de l'espace de travail sur celui que vos parties prenantes utilisent pour les cadences de rapports.

Gérer les destinataires

Les destinataires sont ajoutés en saisissant des adresses courriel dans le champ destinataire de la configuration de planification. Plusieurs destinataires sont pris en charge. Les destinataires n'ont pas besoin d'être des utilisateurs Semavex. Le rapport est livré sous forme de courriel formaté avec les données du rapport intégrées directement dans le corps du message, de sorte que les destinataires peuvent le lire sans se connecter à aucune plateforme.

Vous pouvez modifier la liste des destinataires à tout moment sans recréer la planification. L'ajout ou la suppression d'un destinataire prend effet au prochain cycle de livraison. La planification elle-même, son expression CRON, sa sélection de rapport et son état d'activation restent inchangés lorsque vous modifiez les destinataires.

Livraison et comportement de réessai

À chaque déclenchement planifié, le système de tâches Hangfire exécute le flux de travail complet du rapport. Vexon génère le rapport en exécutant la requête sauvegardée sur la base de données connectée, et Resend le livre aux destinataires configurés. L'état de livraison, y compris les horodatages et les éventuels messages d'erreur, est journalisé dans la plateforme.

Si la génération du rapport échoue en raison d'un délai d'attente de requête, d'un problème de connexion ou d'une erreur transitoire de la base de données, la tâche est réessayée automatiquement. Le système tente une nouvelle livraison un nombre défini de fois avec un délai croissant entre les tentatives avant de marquer la tâche comme échouée et de journaliser l'erreur. Vous pouvez voir les livraisons échouées dans la vue détaillée de la planification et déclencher un réessai manuel à partir de là.

Si le rapport est généré avec succès mais que la livraison par courriel échoue au niveau de Resend, cet échec est également journalisé séparément. La plateforme distingue les échecs de génération des échecs de livraison afin que vous puissiez diagnostiquer si le problème provient de votre connexion à la base de données ou du routage des courriels.

Mettre en pause et reprendre les planifications

Les planifications peuvent être mises en pause et reprises manuellement à tout moment. Une planification en pause ne génère ni ne livre de rapports. Toute la configuration, y compris l'expression CRON, les destinataires et la sélection de rapport, est préservée pendant la pause. La reprise d'une planification la réactive à partir du prochain intervalle planifié.

Un comportement automatique est important à connaître. Si un abonnement Semavex expire ou qu'un paiement échoue, toutes les tâches de rapport planifiées pour cet espace de travail sont automatiquement mises en pause. Elles reprennent automatiquement lorsque l'abonnement est rétabli. Aucun rapport n'est silencieusement abandonné ou livré en retard pendant une interruption. Les utilisateurs reçoivent une notification indiquant que les livraisons planifiées ont été mises en pause en raison d'un problème de facturation, et les planifications reprennent là où elles s'étaient arrêtées une fois l'abonnement actif à nouveau.

Bases de données prises en charge

Semavex prend en charge SQL Server et PostgreSQL. La plateforme maintient une logique distincte de génération de requêtes et d'inspection de schéma pour chaque moteur. Les requêtes SQL Server utilisent la syntaxe T-SQL et lisent les métadonnées depuis les vues de catalogue sys.*. Les requêtes PostgreSQL utilisent le SQL standard et lisent les métadonnées depuis les tables de catalogue pg_* et les vues information_schema. Les utilisateurs n'ont pas besoin de se soucier de cette distinction. Vexon la gère en fonction du type de base de données spécifié lors de la configuration de la connexion.

Exigences de connexion

Pour les deux moteurs, vous avez besoin d'une chaîne de connexion et d'un compte de service avec un accès en lecture au schéma cible. Le compte de service a également besoin d'un accès en lecture aux vues de catalogue système que Vexon utilise pour l'inspection du schéma. Sur SQL Server, cela signifie la permission SELECT sur sys.indexes, sys.index_columns, sys.columns, sys.tables, sys.foreign_keys et sys.stats. Sur PostgreSQL, les permissions par défaut pour un utilisateur en lecture seule incluent généralement l'accès à pg_indexes et pg_stats sans autorisations supplémentaires.

Tarification et forfaits

Semavex propose quatre niveaux : Starter, Growth, Professional et Enterprise. Chaque forfait utilise un modèle de tarification hybride. Vous payez un abonnement de base pour l'accès à la plateforme, et gérez séparément un portefeuille de crédits IA qui finance l'utilisation de Vexon pour la génération de rapports. Vous pouvez consulter votre solde de crédits et votre historique d'utilisation dans la plateforme à tout moment. Ce modèle signifie que vous payez pour ce que vous utilisez réellement plutôt que d'absorber les coûts d'IA dans un tarif forfaitaire opaque.

Starter

Pour les petites équipes explorant les rapports automatisés. Inclut l'accès à la plateforme, une connexion unique à une base de données et les fonctionnalités principales de génération de rapports et de planification.

Growth

Pour les équipes de données en croissance avec un volume de rapports plus élevé. Inclut plusieurs connexions à des bases de données et des limites de planification plus élevées.

Professional

Inclut une instance Azure dédiée. Pour les entreprises fintech et autres organisations ayant des exigences de conformité en matière d'isolation des données et de location, il s'agit d'une garantie architecturale significative. Vos données ne partagent jamais les ressources de calcul ou de stockage avec d'autres locataires Semavex. L'instance dédiée fournit également des caractéristiques de performance prévisibles qu'un environnement partagé ne peut pas offrir.

Enterprise

Contrats personnalisés, accords de niveau de service (SLA) et contact de soutien dédié. Les forfaits Enterprise sont négociés individuellement en fonction du volume, des exigences de conformité et des besoins d'intégration.

Tous les forfaits sont facturés annuellement avec un rabais par rapport à la facturation mensuelle. La facturation mensuelle est disponible pour les équipes qui ont besoin de flexibilité.

Sécurité des données

Vexon lit les données de la base de données connectée et les utilise pour générer des rapports. Il ne stocke pas les données de résultat de requête au-delà de la portée du rapport en cours de génération. Le contenu des rapports n'est pas utilisé pour entraîner un modèle d'IA. Les données transitent par la plateforme pendant la durée du processus de génération du rapport et ne sont pas conservées après la livraison.

La connexion à votre base de données utilise les identifiants que vous fournissez lors de la configuration. Semavex stocke ces identifiants chiffrés au repos à l'aide d'AES-256-GCM. Nous recommandons un compte de service en lecture seule limité au schéma pertinent, ce qui limite le rayon d'impact de tout problème d'identifiants à l'accès en lecture sur les tables que vous avez explicitement rendues disponibles.

L'instance Azure dédiée du niveau Professional offre une isolation complète des données. Votre déploiement Semavex s'exécute sur ses propres ressources de calcul et de stockage, séparé de tous les autres locataires. Pour les organisations soumises à SOC 2, PCI DSS ou des cadres de conformité similaires, cette isolation simplifie l'argumentaire d'audit et supprime les considérations de location partagée qui compliquent la conformité sur les plateformes multi-locataires.

Semavex est hébergé sur Azure. Toutes les données en transit sont chiffrées via TLS. Toutes les données au repos, y compris la base de données de métadonnées qui stocke votre compte, vos rapports sauvegardés et vos définitions de planification, sont chiffrées à l'aide du chiffrement de stockage Azure.