Accueil > Ressources > Technologies pour mise en place de tableaux de bord de gestion

Technologies pour mise en place de tableaux de bord de gestion

jeudi 14 janvier 2010, par Eric Sanjuan

Les tableaux de bords de gestion ont été introduits par analogie avec les tableaux de bord des véhicules. Nous abordons cette notion dans le cas de plus en plus répandu où le système d’information, de l’organisme se trouve sur des serveurs dédiés délocalisés dans un nuage informatique.

Un tableau de bord de gestion (ou d’aide à la décision pour être plus généraliste) doit reprendre de manière la plus synthétique et lisible possible, des indicateurs simples et très régulièrement actualisés de l’état des comptes, stocks, ressources, disponibilité, etc. d’un organisme.
Si le système d’information de cet organisme repose sur des des bases de données relationnelles, alors ces indicateurs peuvent généralement être calculés par de simples requêtes SQL. Dans le cas où des informations sont générées par des applications propres de gestion ou d’organisation du personnel, il n’est pas toujours possible d’accéder aux données via une interface SQL. Il faut alors passer par des client spécifiques, souvent hétéroclites. L’installation d’un tableau de bord repose donc sur :
- des moyens sécurisés d’accès aux différentes sources de données
- une méthode d’affichage synthétique des résultats

Interface locale avec accès sécurisé

L’accès sécurisé est important car de plus en plus les systèmes d’information des entreprises sont délocalisés sur des nuages informatiques (des serveurs dédiés ou partagés chez des hébergeurs).

Dans un environnement local Windows, l’outil de bureautique ACCESS utilisé avec ODBC permet d’accéder via une interface SQL unifié à de multiples sources de données déclarées dans ODBC et réparties en réseau local. Sur le réseau local il peut s’agir d’application windows ou d’application serveurs (services sur tout type de système d’exploitation), disposant d’un module client ODBC, actuellement un quasi standard.

ACCESS permet ensuite de concevoir facilement des écrans d’affichage très ergonomiques, et s’intègre parfaitement au reste de l’application bureautique de Microsoft. La suite bureautique OpenOffice lancée par Sun et disponible sur presque tout type de système d’exploitation, offre le très grand intérêt d’utiliser strictement des formats XML de données ouverts et libres. Cela permet d’intervenir directement sur les fichiers, avec ses propres outils XML sans devoir passer par le logiciel OpenOffice. Pour ACCESS cela n’est possible que si on achète les outils de développement validés par Microsoft et que l’on se restreint strictement à ceux-ci. La contrainte de travailler sur un XML ouvert et cohérent, est qu’il n’est pas possible de prendre des raccourcis pour développer des interfaces souples. Actuellement la suite OpenOffice, même couplé à JDBC, l’alter ego JAVA de ODBC ne permets pas, pour le moment, de gérer avec autant de facilité de multiples sources de données comme ACCESS.

Comment étendre cet environnement au cas où les serveurs de bases de données ne sont plus sur le réseau local. Le plus direct est d’ouvrir des tunnels ssh (voir aussi le document joint rédigé par Amri ou cet article ici) vers les serveurs externalisés. Ces tunnels sont faciles à ouvrir avec putty dans le cas de windows. Dans le cas de LINUX la commande ssh gère cela et on dispose d’outils de contrôle de ces tunnels qui les re-ouvrent automatiquement en cas de coupure. Compte tenu des facilités offertes par LINUX pour gérer le réseau et les connexions cryptés avec Open SSH, il est toujours envisageable d’installer dans un réseau local (câble ou wifi) une machine LINUX qui ouvre les tunnels sur les serveurs distants. Les postes clients accèdent aux données en se connectant en local, à cette machine passerelle, comme si toutes les bases de données étaient installées sur celle-ci.

Interface côté serveur

Une autre solution, pour ne pas gérer de tunnels, est d’utiliser côté serveur, un générateur de document bureautique. Ce programme à faire tourner sur le serveur doit extraire automatiquement les différentes données, et générer un document à récupérer et à ouvrir dans l’outil bureautique choisi. Dans ce cas, le choix d’un format ouvert est plus que préférable et l’on travaille plus facilement avec des suites bureautiques tels que OpenOffice commeici.

Cette approche côté serveur n’est cependant pas la plus simple. Il est beaucoup plus naturel dans ce cas d’installer un serveur Web et de créer une page HTML dynamique. Comme le tableau de bord est destiné à être simplement consulté et non pas modifié, l’interface web s’impose de manière assez logique.

Deux approches sont possibles :
- l’application CGI
- la programmation php (libre), asp (windows)

Voir cet article pour un rapide historique de perl, CGI et php.

Dans le cas CGI le serveur Web est seulement utilisé pour lancer un exécutable côté serveur qui va produire la page à afficher. Sur une machine serveur LINUX, cet exécutable peut être un script shell qui va lancer successivement tous les programmes permettant l’accès aux données (par exemple des clients mysql, oracle, SAS etc.) et ceux permettant de les synthétiser en tableaux et graphiques cohérents intégrables dans une page html (par exemple R avec R2HTML). C’est ce qui demande le moins de programmation, cependant l’utilisation directe de CGI peut engendrer de grandes failles de sécurité, le serveur web ne contrôlant pas l’exécution du programme. Une solution est de passer par un programme intermédiaire. Le serveur lance uniquement ce programme chargé de vérifier l’origine de la requête, la bonne disponibilité des données et des programmes puis d’en contrôler leur bon déroulement. Dans ce cas on obtient un bonne sécurité et de plus on peut utiliser des commandes permettant de faire exécuter les programmes sous un autre utilisateur que le serveur web.

Dans la cas php et asp on peut aussi lancer un long script sur la machine serveur, mais en général, cette possibilité est désactivée par l’administrateur du serveur. Le php a plutôt été fait pour être directement et intégralement exécuté par la serveur Web (Apache à l’origine). Il dispose par ailleurs d’une multiplicité de bibliothèques d’accès à tout type de bases de données et de bibliothèque graphiques. Le temps de développement dans ce cas est certes supérieur, on est aussi tributaire des bibliothèques existantes, mais le tableau de bord qui en résulte gagne certainement en rapidité et stabilité.