← Retour au blog

SQLVantage : un système de reporting qui simplifie la conception et la livraison de rapports de données

经验分享 626 lectures

Cet article présente SQLVantage, un système de reporting web léger au prêt-à-l'emploi. Il décrit comment l'outil intègre la requête SQL, le formulaire de paramètres et la présentation des résultats dans une interface unifiée, avec un déploiement par simple décompression, une gestion des rapports pilotée par les états, une configuration des métadonnées de colonnes pour l'export Excel, un chaînage de paramètres sans JavaScript et une isolation des permissions. Une référence utile pour les équipes souhaitant centraliser la gestion de leurs rapports, notamment sous Oracle EBS.

SQLVantage : un système de reporting qui simplifie la conception et la livraison de rapports de données

Un outil de reporting web prêt à l'emploi qui vous permet de gérer facilement l'ensemble de la chaîne : requêtes de données, formulaires de paramètres et présentation des résultats.

Pourquoi avoir besoin d'un système de reporting indépendant ?

Dans les opérations quotidiennes des entreprises, les rapports de données sont un élément indispensable. Qu'il s'agisse de rapprochement financier, d'analyse des ventes ou de surveillance opérationnelle, presque tous les départements dépendent de diverses formes de rapports.

Cependant, lors de la mise en pratique, nous rencontrons fréquemment ces problèmes :

  • Dispersion des données : les SQL des rapports sont éparpillés dans des e-mails, des historiques de messagerie et des fichiers de scripts, difficiles à centraliser et à réutiliser ;
  • Transmission fastidieuse des paramètres : à chaque requête, il faut assembler manuellement le SQL ou modifier le code, ce qui est source d'erreurs ;
  • Formats d'exportation incohérents : Excel, PDF et HTML fonctionnent chacun de leur côté, rendant la maintenance des styles difficile ;
  • Contrôle d'accès insuffisant : qui a consulté quelles données, les traces d'opérations ne sont pas claires ;
  • Développement redondant : pour des besoins similaires, chaque projet doit réécrire le code front-end et back-end.

Ainsi, un système de reporting léger capable de gérer de manière centralisée les définitions de rapports, de prendre en charge les requêtes paramétrées, de générer automatiquement plusieurs formats de résultats et d'assurer l'isolation des permissions devient vraiment nécessaire.

Récemment, j'ai découvert un système de reporting nommé SQLVantage (version v1.0.2, publiée le 2026-07-15) qui résout précisément ces points de douleur. Sa philosophie de conception est très claire : utiliser un processus standardisé pour relier les trois étapes que sont « requête SQL, formulaire de paramètres et présentation des résultats », afin que tout le cycle de vie du rapport soit traçable.

Dans cet article, je vais synthétiser sa conception et ses cas d'usage à partir de sa documentation officielle, pour vous aider à déterminer rapidement s'il convient à votre équipe.

1. Qu'est-ce que SQLVantage ?

SQLVantage est un système de reporting basé sur une architecture purement web. Ses caractéristiques principales sont :

  • côté navigateur, aucun plugin à installer ; un navigateur moderne suffit pour y accéder ;
  • côté serveur, un seul exécutable et un répertoire de configuration suffisent, sans nécessiter d'environnement d'exécution supplémentaire (Java, Python, Node.js, etc.) ;
  • déploiement pris en charge sur Windows et Linux ;
  • connexion par défaut à une base de données Oracle (particulièrement adapté aux environnements Oracle EBS), avec la possibilité d'étendre à d'autres bases.

Aperçu des concepts clés

Concept Description
Rapport Un rapport = requête SQL + formulaire de paramètres (FORM) + présentation des résultats (HTML) + trois configurations JSON de format, rattaché à une « responsabilité »
Responsabilité Répertoire de classification des rapports, correspondant au concept de responsabilité dans Oracle EBS, utilisé pour regrouper les rapports par module
Paramètre Condition de requête (date, client, organisation, etc.), lié à l'exécution SQL en tant que paramètre nommé après soumission par l'utilisateur
Requête Une tâche d'exécution de rapport spécifique soumise par l'utilisateur, exécutée de manière asynchrone par le système qui génère le fichier résultat
Licence Fichier License qui contrôle le nombre maximal de rapports et la durée d'utilisation

Rôles utilisateurs

Le système distingue deux rôles, dont les points d'entrée et les permissions sont totalement séparés :

  • Administrateur (/admin/login) : gère les utilisateurs, les responsabilités, les rapports, les licences et les paramètres système ; peut consulter les requêtes de tous les utilisateurs ;
  • Utilisateur standard (/login) : sélectionne les rapports, remplit les paramètres, soumet les requêtes, consulte ses propres requêtes, télécharge les résultats et modifie son mot de passe.

2. Installation et déploiement : véritablement « décompresser et utiliser »

Le mode de déploiement de SQLVantage peut être qualifié de très « pragmatique ».

Windows

Décompressez le paquet de publication dans un répertoire quelconque (par exemple D:\SQLVantage), puis double-cliquez sur SQLVantage.exe pour le lancer. Par défaut, il écoute sur 127.0.0.1:8080 ; il suffit d'ouvrir un navigateur pour y accéder.

Linux

Décompressez dans /opt/sqlvantage, accordez les droits d'exécution, puis lancez en arrière-plan avec nohup ou systemd. Le port par défaut est également 8080.

Initialisation automatique au premier démarrage

Lors du premier démarrage, le système effectue automatiquement les actions suivantes, ce qui est très appréciable pour les équipes d'exploitation :

  1. vérification de l'existence de conf/data.dat (la base de données métier fournie avec le paquet) ;
  2. création automatique de quatre tables : user, responsibility, report et request ;
  3. création automatique du compte administrateur root, avec le mot de passe initial SQLVantage (à modifier impérativement après connexion) ;
  4. en l'absence de fichier de licence, un avertissement est affiché, mais le système reste fonctionnel (soumis uniquement à la limite du nombre de rapports).

Cette conception réduit au minimum le coût d'une « prise en main à partir de zéro ».

3. Du côté de l'administrateur : gestion du cycle de vie complet des rapports

3.1 Gestion des utilisateurs et des responsabilités

L'administrateur peut créer des utilisateurs standards (rôle normal) et définir leur statut comme active ou inactive (désactivation en cas de départ, sans suppression de compte).

La gestion des responsabilités correspond au concept de responsabilité d'Oracle EBS et peut également être créée manuellement. Les rapports doivent être rattachés à une responsabilité, de sorte que côté utilisateur standard, le menu des rapports s'affiche automatiquement groupé par responsabilité, offrant une expérience claire.

3.2 Gestion des rapports : pilotée par les états

Les rapports ont trois états :

  • Draft (brouillon) : phase de conception, invisible pour les utilisateurs ;
  • Release (publié) : visible et exécutable par les utilisateurs ;
  • Discard (abandonné) : invisible pour les utilisateurs, mais l'historique est conservé.

Un rapport publié ne peut pas être supprimé directement : il faut d'abord le repasser en brouillon ou en abandonné — cette conception évite efficacement la suppression accidentelle de rapports en production.

La page de liste permet de « double-cliquer sur une cellule pour éditer directement » le nom, la description et le statut, un détail qui améliore l'efficacité opérationnelle.

3.3 Gestion des licences (License)

Le fichier de licence conf/license.dat contrôle le nombre maximal de rapports et la période de validité. Sans licence ou en cas d'expiration, le système limite la création à 3 rapports maximum ; au-delà, il est impossible d'en créer de nouveaux ou de soumettre des requêtes.

Ce mécanisme est très utile pour les versions commerciales ou les scénarios d'essai interne — il conserve toutes les fonctionnalités tout en fixant un seuil de limitation raisonnable.

4. Le concepteur de rapports : le point fort le plus marquant

S'il y a une fonctionnalité de SQLVantage qui mérite qu'on s'y attarde, c'est bien son concepteur de rapports.

Il décompose le processus de développement en trois modules indépendants mais interconnectés, tous réalisables dans une seule interface.

4.1 Disposition du concepteur

Depuis la liste des rapports, cliquez sur le bouton « Code » (en violet) dans la ligne du rapport : un grand concepteur occupant environ 98 % de l'écran s'ouvre. L'interface se compose de :

  • partie supérieure : liste déroulante de changement de mode (SQL / FORM / HTML) + bouton « Tout enregistrer » ;
  • panneau gauche : éditeur de code (le contenu change selon le mode) ;
  • panneau droit : panneau de configuration dynamique (affiche différents tableaux de configuration et un aperçu en temps réel selon le mode).

Cette disposition « code à gauche + configuration à droite + aperçu en temps réel » est très intuitive pour les développeurs.

4.2 Module SQL : définir la source de données

Écriture du SQL

Utilisez la syntaxe Oracle, avec des espaces réservés de paramètres nommés au format :nom_du_paramètre pour les conditions de requête :

SELECT company_name, ou_id, amount
  FROM fnd_ou_tl
 WHERE ou_id = :P_OU_ID

Le paramètre P_OU_ID doit être strictement identique au nom de paramètre défini dans le module FORM.

Configuration des métadonnées de colonnes — la clé de l'export Excel

Le panneau de droite permet de configurer pour chaque colonne :

  • field : le nom de la colonne renvoyée par le SQL
  • title : l'en-tête affiché (également l'en-tête Excel)
  • type : text / number / percent / date / month / time / datetime
  • precision : le nombre de décimales
  • format : le format personnalisé Excel (par exemple #,##0.00)
  • align : l'alignement

Cette configuration détermine directement le professionnalisme de l'export Excel — en-têtes localisés, nombres alignés à droite, séparateurs de milliers, formats de pourcentage, tout se règle ici en une seule fois.

Autrement dit, dès que les métadonnées de colonnes sont configurées ici, la qualité de l'export Excel ne dépend plus d'un code back-end supplémentaire.

4.3 Module FORM : concevoir les paramètres de requête

C'est le point d'entrée de l'interaction avec le rapport. Chaque ligne du « tableau de configuration des paramètres » à droite définit un paramètre de requête :

Champ Description
Nom du paramètre field Doit être strictement identique au :nom_du_paramètre du SQL
Libellé affiché label Texte affiché dans le formulaire
Type de composant type text / number / select / radio / date / month / datetime / hidden / temp
Options statiques static_options Format clé:valeur,clé:valeur
API / SQL dynamique Prise en charge des espaces réservés {nom_de_variable} pour le chaînage des paramètres

Chaînage de paramètres (filtrage dépendant)

C'est une fonctionnalité très pratique du module FORM : lorsqu'une liste déroulante aval dépend d'un paramètre amont (par exemple, « sélectionner une organisation » avant de charger la « liste des départements »), il est possible de référencer un espace réservé comme {P_OU_ID} dans api_url ou query_sql.

Lorsque l'utilisateur modifie la valeur amont, le système déclenche automatiquement l'actualisation des options aval — sans qu'aucun code JavaScript supplémentaire ne soit nécessaire.

En bas du panneau de droite se trouve une zone d'aperçu en temps réel : une fois la configuration des paramètres terminée, le rendu réel est visible et le code HTML généré peut être « copié et appliqué » dans l'éditeur en un clic.

4.4 Module HTML : présentation des résultats

Une fois l'exécution du rapport terminée, sous quelle forme les résultats sont-ils présentés à l'utilisateur ? C'est le module HTML qui définit cette couche.

La « configuration des composants de vue HTML » à droite permet de définir plusieurs blocs d'affichage, chacun comprenant :

  • l'identifiant du conteneur
  • le titre
  • la largeur de grille (1 à 12)
  • le type de composant : table (tableau), chart (graphique), card (carte d'indicateur), custom (conteneur personnalisé)
  • le type de graphique (line / bar)
  • le mappage des champs des axes X / Y

Finalement, lorsque l'utilisateur télécharge le résultat HTML, le système génère dynamiquement une page complète contenant des tableaux, des graphiques et des cartes KPI, et les paramètres de requête sont également affichés en haut du résultat.

Cette couche de conception confère au « côté présentation » des rapports une capacité de configuration, éliminant le besoin d'écrire une page front-end spécifique pour chaque rapport.

4.5 Flux de publication

L'ensemble du flux se déroule en ligne droite :

  1. créer un nouveau rapport (statut Draft) ;
  2. entrer dans le concepteur et compléter successivement les configurations SQL → FORM → HTML ;
  3. cliquer sur « Tout enregistrer » ;
  4. revenir à la liste des rapports et changer le statut en Release ;
  5. l'utilisateur standard peut alors voir et exécuter le rapport dans le menu de la responsabilité correspondante après connexion.

5. Du côté de l'utilisateur standard : choisir un rapport → remplir les paramètres → attendre le résultat

Le parcours de l'utilisateur standard est très simple :

  1. se connecter à la page d'accueil du portail (connexion par compte local ou authentification via Oracle EBS ERP) ;
  2. cliquer sur « Nouvelle requête de rapport » ;
  3. parcourir le menu des rapports groupé par responsabilité, ou rechercher par nom ;
  4. sélectionner un rapport et remplir le formulaire de paramètres ;
  5. soumettre ; le système exécute de manière asynchrone ;
  6. consulter le statut dans la liste « Mes requêtes » ; une fois terminé, télécharger les résultats Excel / HTML / JSON / TEXT via le menu déroulant « Sortie ».

Transition des états des requêtes

Queued (en file d'attente) → Processing (en cours) → Success (succès)
                                                → Error (échec)
                                                → Terminated (arrêt pour dépassement de délai)

Le système interroge les tâches en file d'attente toutes les 3 secondes en arrière-plan ; le niveau de concurrence est ajustable, avec un maximum de 3 tâches exécutées simultanément par défaut. Le délai d'expiration est de 30 minutes par défaut et peut être ajusté dans la configuration.

6. Détails de conception dignes d'attention

1. Un rapport = trois codes + trois JSON de format

SQL, FORM et HTML possèdent chacun à la fois un « code » et un « JSON de format », ce qui laisse de la place pour une future gestion des versions et la réutilisation de modèles.

2. L'export Excel dépend strictement des métadonnées de colonnes

Il ne s'agit pas d'un « export puis post-traitement », mais d'une décision prise dès la phase de conception quant au style Excel. Cela signifie que le concepteur du rapport peut entièrement contrôler la qualité de la sortie, sans dépendre de scripts de post-traitement supplémentaires.

3. Le chaînage de paramètres sans écrire de JavaScript

Le mécanisme d'espaces réservés permet d'implémenter les dépendances de paramètres, ce qui abaisse la barrière technique du développement front-end.

4. Isolation des permissions des requêtes

Les utilisateurs standards ne voient que leurs propres requêtes ; l'administrateur peut tout consulter. Lors de la soumission par un utilisateur connecté via ERP, le système vérifie également les permissions d'organisation OU/ORG pour empêcher tout accès non autorisé.

5. Transparence du stockage des données

Toutes les données métier sont stockées dans conf/data.dat, et les fichiers résultats sont générés dans le répertoire data/. Lors d'une migration, il suffit de copier les répertoires conf/ et data/, ce qui est très clair.

7. Cas d'usage et points d'attention

Quels scénarios sont adaptés ?

  • Gestion centralisée des rapports de données d'entreprise, en particulier pour les équipes utilisant déjà Oracle EBS ;
  • Besoin de livrer rapidement des exigences de reporting, avec une traçabilité de la définition, de l'exécution et des résultats ;
  • Souhait de réduire les coûts de développement des rapports, en permettant à des analystes métier ou des DBA maîtrisant le SQL de configurer les rapports de manière autonome.

Points d'attention

  • La version actuelle est adaptée par défaut à Oracle ; pour utiliser d'autres bases de données (MySQL, PostgreSQL, etc.), une adaptation est nécessaire ;
  • Sans licence, le nombre de rapports est limité à 3 ; une utilisation en production nécessite l'importation d'un fichier de licence valide ;
  • Après modification des paramètres système (port, mot de passe Oracle, etc.), le service doit être redémarré pour que les changements prennent effet (à l'exception de la configuration du délai d'expiration de session).

En guise de conclusion

L'impression générale que me laisse SQLVantage est : pragmatique, mesuré et agréable à utiliser.

Il ne cherche pas à tout prix à être « complet », mais se concentre sur le scénario central du « rapport », en reliant les maillons clés — gestion SQL, interaction paramétrique, présentation des résultats et isolation des permissions — en une chaîne claire et complète.

Pour les équipes qui peinent à gérer leurs rapports, il offre une solution de référence intéressante — utilisable directement comme outil de production, mais aussi comme exemple pour comprendre la conception d'un système de reporting web léger.

Si vous cherchez vous aussi un système de reporting simple, facile à utiliser et auto-hébergeable, pourquoi ne pas commencer par SQLVantage ?

Cet article est basé sur la documentation officielle de SQLVantage v1.0.2 (publiée le 2026-07-15). Pour plus de détails, consultez la documentation multilingue fournie avec le projet (répertoire docs/).