Documentation Semavex — Vexon, SQL optimisé pour les index et planification des rapports

Ce que fait Semavex

Semavex est une plateforme de rapports et d'analytique qui se connecte directement à la base de données PostgreSQL, SQL Server ou MySQL de votre entreprise (Snowflake bientôt disponible). 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 et produit un plan de requête structuré que la plateforme valide puis traduit en SQL paramétré et optimisé, avant de mettre en forme le résultat et de le livrer selon la planification définie par courriel.

Le cycle principal est simple. Un utilisateur sélectionne une source de données et saisit une demande décrivant le rapport dont il a besoin. Vexon inspecte le modèle sémantique et le schéma de cette source, y compris les métadonnées d'index, et produit un plan de requête que la plateforme traduit en 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 PostgreSQL, SQL Server ou MySQL 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, modèles sémantiques, 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 comme un agent conversationnel libre. Sa sortie est contrainte à un plan de requête structuré — il ne peut ni produire de SQL ni du texte libre. Le backend .NET effectue ensuite le travail déterministe : il valide le plan, le traduit en SQL paramétré, l'exécute en lecture seule, planifie les tâches de livraison et envoie les courriels, et chaque étape est journalisée. Cela signifie que le comportement de Vexon est encadré, déterministe et vérifiable. Il n'improvise pas, et son influence se limite au plan structuré autorisé par le contrat défini par l'équipe d'ingénierie, 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 PostgreSQL, SQL Server et MySQL, avec Snowflake bientôt disponible. 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. Semavex 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

Avant votre premier rapport, construisez un modèle sémantique pour la source de données connectée — un dictionnaire métier de ses tables, colonnes, mesures et de sa terminologie — puis activez-le. Chaque source de données possède exactement un modèle sémantique, et Vexon ne peut répondre aux questions qu'une fois ce modèle actif ; vous sélectionnez la source de données et la plateforme résout son modèle pour vous. Ouvrez ensuite 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 modèle sémantique et le schéma pertinents, et produit un plan de requête aligné sur la topologie des index ; la plateforme valide ce plan, le traduit en SQL pour votre moteur de base de données spécifique, l'exécute en lecture seule 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, contraint par la bibliothèque instructor à émettre un plan de requête structuré plutôt que du texte libre ou du SQL. Le backend de Semavex valide ce plan par rapport au modèle sémantique et à une liste blanche d'opérations autorisées, puis le traduit de façon déterministe en SQL paramétré et prend en charge l'exécution, la planification et la livraison par courriel. Vexon ne peut pas produire de SQL, modifier des données, ni agir en dehors de ce contrat structuré. Cette distinction est importante : l'influence de Vexon correspond exactement au plan structuré défini par l'équipe d'ingénierie, 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 demande est journalisée avec ses entrées et ses sorties. Chaque rapport est traçable jusqu'au plan de requête produit par Vexon, aux métadonnées de schéma et de modèle sémantique qui l'ont informé, et au SQL paramétré que la plateforme a généré et exécuté. 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. Génération du plan de requête. Vexon émet un plan de requête structuré — les tables, métriques, dimensions, filtres, jointures et la période — via une sortie structurée contrainte. Il n'écrit jamais de SQL ; le plan est un objet typé, et non une chaîne de requête. La conscience des index (préfixes d'index composites, prédicats d'index partiels, ordre de jointure) est intégrée au plan à partir des métadonnées de schéma et d'index lues à l'étape précédente.
4. 4. Validation déterministe. Le backend .NET valide le plan par rapport au modèle sémantique et à une liste blanche d'opérateurs, d'agrégations et de transformations autorisés — aucun LLM n'intervient à cette étape, on ne peut donc pas la persuader de contourner une règle. Un plan invalide est rejeté, ou le modèle est invité une seule fois à le corriger, avant qu'aucun SQL n'existe.
5. 5. Traduction SQL. Le plan validé est traduit de façon déterministe en SQL paramétré pour le moteur connecté — T-SQL pour SQL Server, SQL standard pour PostgreSQL et MySQL. Toutes les valeurs de filtre sont liées en tant que paramètres et les identifiants proviennent uniquement du modèle sémantique de confiance, ce qui rend l'injection SQL structurellement impossible.
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

En réponse à une seule demande de rapport, Semavex enchaîne les opérations suivantes dans un flux de travail coordonné — piloté par la sortie structurée de Vexon, sans intervention humaine intermédiaire.

Vexon lit les métadonnées du schéma et des index depuis le catalogue système de la base de données et produit un plan de requête validé. La plateforme traduit ce plan en SQL paramétré et l'exécute en lecture seule sur la base de données connectée, planifie des tâches de livraison récurrentes via le système de tâches en arrière-plan Hangfire, et envoie des courriels de rapport via Resend à un ou plusieurs destinataires spécifiés. La sortie structurée unique de Vexon orchestre l'ensemble de ces opérations 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 du contrat structuré que le backend de Semavex définit pour lui. Ces limites sont imposées par construction : la seule sortie de Vexon est un plan de requête en lecture seule (ou une classification de conversation de rapport), et le backend n'offre aucun chemin depuis ce plan vers 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 planification de la requête et façonne le plan pour ne sélectionner que 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. La plateforme régénère le rapport en exécutant le plan de requête sauvegardé du rapport sur la base de données connectée — les exécutions planifiées réutilisent le plan stocké et ne font pas appel à Vexon de nouveau — 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 PostgreSQL, SQL Server et MySQL aujourd'hui, Snowflake arrivant bientôt. 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.*, tandis que PostgreSQL et MySQL 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 chaque moteur, 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.

Isolation des requêtes et lectures sans verrou

Semavex exécute des requêtes analytiques en lecture seule sur votre base de données. Par défaut, il utilise l'isolation de transaction READ UNCOMMITTED sur SQL Server pour éviter les blocages ou les interblocages avec les charges d'écriture de votre application. Cela signifie que les requêtes de rapports de Vexon n'attendront jamais les verrous de ligne détenus par des transactions en cours, et ne causeront jamais l'attente des écritures de votre application non plus. Le compromis est que les rapports peuvent occasionnellement inclure des données de transactions qui n'ont pas encore été validées, mais pour les rapports analytiques, cela est rarement un problème.

Pour le meilleur équilibre entre cohérence et performance, nous recommandons d'activer Read Committed Snapshot Isolation (RCSI) sur votre base de données SQL Server. Avec RCSI activé, les requêtes de Semavex voient un instantané cohérent des données validées sans aucun blocage — pas de lectures sales et pas de contention de verrous. Vous pouvez l'activer avec : ALTER DATABASE VotreBaseDeDonnées SET READ_COMMITTED_SNAPSHOT ON. PostgreSQL utilise le contrôle de concurrence multi-versions (MVCC) par défaut, donc aucune configuration supplémentaire n'est nécessaire — les requêtes en lecture ne bloquent jamais les écritures et ne voient jamais les données non validées.

Tarification et forfaits

Semavex propose deux paliers : Professional et Enterprise. Les deux forfaits fonctionnent par contrat annuel à tarification sur mesure — l'abonnement de base couvre l'accès à la plateforme, tandis que l'utilisation de l'IA est mesurée via un portefeuille de crédits distinct qui finance la génération de rapports par Vexon. 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.

Professional

Pour les équipes fintech et e-commerce de petite et moyenne taille qui dépendent de Semavex comme élément central de leur flux de travail en matière de rapports. Fonctionne sur une infrastructure cloud partagée avec jusqu'à 10 utilisateurs, jusqu'à 10 sources de données (chacune avec son propre modèle sémantique), 20 modèles de rapports, 20 planifications de rapports, et 50 $ de crédits IA mensuels. Inclut la suite complète d'agents IA Vexon (constructeur de modèle sémantique, agent de données et agent de rapports), la livraison de rapports planifiés, les tableaux de bord et exports, l'allocation de crédits par utilisateur, un portefeuille à recharge automatique, une revue annuelle de l'état du schéma, un audit annuel de rapports, et une séance d'intégration la première année. Soutien prioritaire par courriel avec un SLA de 24 heures et un SLA de disponibilité de 99,5 %.

Enterprise

Pour les organisations à grande échelle et les fournisseurs de plateformes. Contrats personnalisés avec sièges utilisateurs et limites de sources de données négociables, une instance Azure dédiée avec isolation VNet pour une séparation complète des locataires, des alertes de données en temps réel sur l'activité de la base de données, des revues d'affaires trimestrielles, et quatre séances d'intégration la première année. Canal Slack de soutien dédié avec un SLA de 8 heures, voie d'escalade directe pour les incidents critiques, et un SLA de disponibilité de 99,9 %. Modules complémentaires disponibles : marque blanche, intégrations personnalisées et séances d'intégration supplémentaires. Les forfaits Enterprise sont négociés individuellement selon le volume, les exigences de conformité et les besoins en infrastructure.

Les deux forfaits fonctionnent par contrat annuel — il n'y a pas d'option de facturation mensuelle. La tarification est sur mesure et adaptée à votre nombre d'utilisateurs, votre volume de crédits IA et vos besoins en infrastructure. Contactez l'équipe commerciale pour discuter d'un arrangement.

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 Enterprise 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. (Professional s'exécute sur une infrastructure cloud partagée avec une isolation par schéma propre à chaque locataire.)

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.