Application web pour le département Mdpv de Spie
cahier des charges (première ébauche)


Présentation

Le département Mdpv de Spie voudrait inclure, dans son offre au client, un site web dédié.A cette fin, le département Mdpv définit un ensemble de spécifications que devra implémenter l'application web.Ces spécifications se fondent sur la prise en compte des impératifs suivants :- d'une part, répondre aux besoins communs à tous les clients (plannings d'interventions, pv d'interventions etc...)- d'autre part, s'interfacer avec le système d'information du département Mdpv (à savoir l'application Vrdata)La solution retenue devra être unique et généraliste : l'expérience a montré qu'une application "template" que l'on clonerait pour chaque nouveau client est un cauchemar de maintenance.Enfin, la procédure d'intégration de nouveaux clients devra être à la portée d'un non-spécialiste.





Spécifications
1/ fonctionnalités
le client doit pouvoir:- prendre connaissance des dates de passage des techniciens dans les agences (i.e. accéder à un planning des interventions)- prendre connaissance des travaux effectués (accès aux PVs d'intervention)- visualiser l'équipement d'un site- visualiser un "book" d'un site (ensemble de photos d'un site)- effectuer des demandes d'intervention par le canal de l'appli web (cette demande sera bientôt redéfinie plus précisément)- rechercher des agences au moyen d'un filtre par nom d'agence- le client doit pouvoir accéder aux agences de sa juridiction. Il convient donc de définir des profils d'utilisateur adaptés à des types de juridiction (par exemple, directeur national, directeur régional, directeur de groupe), tout en tenant compte du fait que les hiérarchies varient d'un client à l'autre (nombre d'échelons) ...
2/ interfaçage avec le S.I. du département Mdpv
a) l'existantMdpv a adopté le logiciel Vrdata pour la gestion de son activité. Ce logiciel s'appuie sur une base de données relationnelle access et sur un ensemble de fichiers déployés dans le réseau local. Dans la philosophie Vrdata, chaque client a ainsi sa propre arborescence et sa propre base de données. Le serveur web n'est pas intégré au réseau local de Spie. Il n'a pas d'accès direct aux données des clients : il faut donc périodiquement les transférer sur le serveur web.

b) réflexion sur une collaboration avec Street DataAu début, le transfert de données se faisait par ftp. Suite à une intrusion, cette option a été écartée. Actuellement, une solution de "upload" http par le site web existe: elle fonctionne mais n'a pas encore été mise en exploitation. Il semble en fait que sur ce point une réflexion devrait être menée conjointement avec les développeurs de Street Data : puisque le site n'utilise qu'une partie des données de la base (5 tables au maximum), il est tout à fait pertinent d'envisager que l'application web maintienne une base locale, qui serait renseignée en live, par l'envoi depuis Vrdata de requetes http.
Cette solution fait tout à fait sens : elle n'est ni avant-gardiste, ni particulièrement importante en terme de volume de développement. Néanmoins cette solution simple ne gérerait pas le transfert des photos, (pour des raisons de performance évidentes).

Il faudrait demander à Street Data que Vrdata prenne en compte la maintenance d'un index des photos, pour "virtualiser" l'accès aux photos (cet index est déjà en place sur le site bnpp beta).

Il faudrait aussi réfléchir à un planning qui serait intégré à la base de données en remplacement des fichiers excel actuels (le même principe est à l'oeuvre dans le site bnpp beta: les PVs d'intervention ne sont plus des .pdf séparés, mais sont publiés dynamiquement à partir des données de la base access).