Analyse et mise en place de l’infrastructure et de l’environnement de développement

Analyse de la structure de phonoWriter

Architecture Orientée Services

Une architecture orientée services (SOA) est une architecture logicielle s’appuyant sur un ensemble de services simples (Pillou, 2017). L’idée d’une SOA est de séparer une fonctionnalité en un ensemble de services qui peuvent interagir entre eux. Elle permet d’obtenir tous les avantages d’une architecture client-serveur comme une modularité permettant de remplacer facilement un composant, une réutilisabilité possible des composants ou encore une maintenance facilitée. Les services Web communiquent via un ensemble de technologies fondamentales qui partagent une architecture commune basée sur SOA. Les technologies utilisées par les services Web sont Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Universal Description Discovery and Integration (UDDI) et Representational State Transfer (REST). Les trois premières technologies utilisent de nouveaux protocoles. Les services REST utilisent uniquement des méthodes standards du W3C. SOAP est un protocole standard de communication décrit en XML.

Il permet d’échanger de l’information entre différents ordinateurs et d’effectuer des appels de méthodes à distance. WSDL est un langage de description standard et indique comment utiliser le service Web et comment interagir avec lui. UDDI est un annuaire de services. Il est utilisé pour la publication et la découverte des services Web. Enfin, REST est une architecture de services Web. Dans une SOA, on retrouve les notions de la description, la publication, la découverte ainsi que l’invocation du service. La description du service contient les paramètres d’entrée du service ainsi que le format et le type des données (WSDL). La publication consiste à publier le service dans un registre (WSDL). La découverte sert à rechercher un service parmi ceux qui ont été publiés dans le registre (UDDI) et l’invocation représente la connexion et l’interaction du client avec le service.

Une applet Java est-elle adaptée ? Les applets Java sont aisément intégrables dans des pages Web au format HTML et peuvent fournir une fonctionnalité spécifique comme notre outil. Seulement, pour fonctionner sur un navigateur Web, il faut le plug-in Java qui est basé sur l’architecture de plug-in NPAPI (Netscapte Plugin Application Programming Interface). Un plug-in est un « composant logiciel d’extension » (Vast, 2017). C’est un module d’extension qui vient se greffer à un logiciel afin de lui ajouter des fonctionnalités qui ne sont pas proposées nativement. En septembre 2015, Google a supprimé les applications Java du Web au profit de son propre système d’extensions en nettoyant le NPAPI de leur navigateur. L’entreprise américaine a en effet remplacé le mode NPAPI par celui de PPAPI (Peper Plugin Application Programming Interface) utilisable uniquement sur le navigateur Google Chrome et qui disparu totalement fin 2016. Chez Mozilla, la dernière version qui permet l’usage d’applets Java est la version 52 qui devrait être obsolète en mai 2018. La version 53 n’a plus le code applicatif pour NPAPI et l’utilisation d’applets Java sur le navigateur Mozilla Firefox n’est plus possible. Quant à Microsoft, les applets Java ne peuvent être exécutées uniquement avec la version 11 d’Internet Explorer. Microsoft Edge disponible avec Windows 10 ne supporte pas non plus NPAPI, donc pas de système de plug-in Java. Une applet Java est donc simple à intégrer sur un site internet mais il ne reste plus que Internet Explorer 11, Safari ainsi que Mozilla Firefox tout en sachant que ce dernier a prévu de supprimer les applets Java sur son navigateur. Cette technologie n’est donc pas optimale et adaptée pour notre outil.

Page de connexion

L’image ci-dessus montre la page de connexion. Cette page offre la possibilité à l’utilisateur de se connecter en tant que porteur de projet, élu communal ou administrateur communal. En fonction de la connexion choisie, les droits et les tâches à réaliser ne seront pas pareils. En effet, le porteur de projet a la possibilité de créer un nouveau projet et de répondre à un questionnaire préalable en rapport avec ce projet. Ceci oblige le porteur de projet à réfléchir à un certain nombre de questions en lien avec sa proposition. Il peut aussi transférer un éventuel fichier complémentaire au format PDF pour donner une source d’information supplémentaire au conseil communal. L’élu communal va analyser ces questions sous un point de vue « développement durable » et exécuter une pondération sur ces questions à l’aide d’une grille prédéterminée pour arriver sur une première évaluation nommée analyse initiale. Il va également analyser des questions principalement axées sur l’analyse des conflits potentiels et évaluer le projet en fonction de la politique communale toujours en mettant des pondérations.

Ces pondérations vont lui permettre de comparer l’analyse initiale et l’état souhaité par la commune. Enfin, l’élu communal va répondre à des questions pour avoir une idée sur la cohérence du projet et peut aussi proposer des améliorations ou des suggestions par rapport au projet. L’administrateur communal peut gérer les différents projets proposés sur sa commune. Il peut les supprimer et/ou les archiver. Il a également la possibilité de modifier les accès utilisateurs pour sa commune. L’image ci-dessous montre le formulaire de connexion. En cas d’erreur de saisie, l’utilisateur en est informé par un message d’erreur ou d’information.

SYNTHÈSE GÉNÉRALE

Une des idées de départ de ce travail consistait à créer un outil libre et aisément intégrable dans les systèmes d’information des communes. Une première analyse a été réalisée sur les travaux en « marque blanche » et il s’est avéré que ce ne fut pas la solution pour ce travail. Une deuxième analyse a été réalisée sur les services Web et l’utilisation d’une API REST. Après plusieurs recherches et tests effectués, la décision de partir sur cette solution a été prise et ce fut un choix optimal. En effet, l’utilisation de l’API REST permet à l’administrateur général de créer son outil comme il le désire en insérant les questions et les axes souhaités dans la partie administrative de l’outil (côté serveur). Une interface client est ensuite proposée aux porteurs de projet, aux élus communaux ainsi qu’aux administrateurs communaux afin qu’ils puissent utiliser l’outil correctement. Au niveau du stockage des données, le choix s’est porté sur le fait de stocker les données de l’application au même endroit que l’application elle-même.

Comme un système de comptes généraux a été mis en place, les données peuvent être stockées sur le réseau sans souci de sécurité. Un système de droits d’accès a tout de même été configuré pour autoriser l’administrateur général à modifier les accès des utilisateurs. La création et l’utilisation d’un Product Backlog a également permis d’avoir une vision globale et bien précise du projet en début de travail puis d’avoir ensuite un suivi constant du développement de l’outil durant chaque itération. Cette technique a été utile pour la planification du développement et pour s’assurer d’atteindre les objectifs fixés au début du travail. Enfin, dans une dernière phase, le travail a pu être déployé sur un serveur physique mis à disposition par la HES-SO. Ce déploiement a permis une réalisation de tests réels auprès des clients et ainsi d’obtenir des retours quant à l’utilisation de l’application.

RECOMMANDATIONS : VS-OADE est un outil unique et très adaptable pour aider les élus communaux à prendre de bonnes décisions lorsqu’un projet leur est présenté. Par sa capacité d’adaptation, l’outil peut être utilisé en tout temps en fonction de l’évolution de la situation en Valais par rapport au développement durable de notre région. Il permet aux porteurs de projet de se poser plusieurs questions sérieuses en rapport avec la proposition pour déjà se faire une idée claire et précise du projet. Il va ensuite permettre aux élus communaux de débattre sur le projet, d’avoir plusieurs discussions et échanges d’idées par rapport au projet et ainsi aborder tous les points nécessaires pour être sûr de prendre les bonnes décisions. Enfin, c’est un outil qui est aisément intégrable dans les systèmes d’information des communes puisqu’il serait déjà hébergé sur le réseau et les utilisateurs concernés n’auraient besoin que d’une Uniform Resource Locator (URL) et des droits d’accès pour se connecter à l’outil. Un simple lien intégré dans les systèmes d’information des communes pourrait rediriger les utilisateurs sur VSOADE et ainsi leur permettre d’utiliser l’outil.

RESPECT DU CAHIER DES CHARGES : Tous les objectifs du cahier des charges en Annexe I ont été atteints et toutes les fonctionnalités minimales ont été implémentées. En effet, une analyse et un apprentissage de ce qu’implique un développement en « marque blanche » ont été faits. Des analyses et recherches sur des technologies à utiliser pour ce travail ont également été réalisées dans le but de travailler avec les meilleures technologies actuelles en lien avec les besoins de notre outil. Une dernière analyse sur l’hébergement des applications ainsi que le stockage et la sécurité des données a également été faite de façon à disposer d’une infrastructure optimale pour le développement de cet outil. L’éventuelle analyse de certains systèmes d’information utilisés dans quelques communes n’a tout de même pas été réalisée pour éviter de perdre trop de temps. La décision de partir sur une application Web a été prise car la plupart des communes possèdent un site internet. La création d’un Product Backlog priorisé avec le professeur a également été rédigé et validé au début du travail. Le développement de l’application en lien avec les user stories du Product Backlog s’est déroulé plus ou moins comme prévu et a pu être terminé à temps sans de gros problèmes rencontrés. L’application terminée et déployée a enfin pu être réellement testée par les clients.

Table des matières

INTRODUCTION
CONTEXTE GÉNÉRAL DU PROJET
SUJET SPÉCIFIQUE
DÉVELOPPEMENT DE L’OUTIL
DÉLIVERABLES
1. OUTIL EXISTANT
1.1. DESCRIPTION DE L’OUTIL
1.1.1. Processus
2. ANALYSES ET RECHERCHES
2.1. ANALYSE D’UN DÉVELOPPEMENT EN « MARQUE BLANCHE »
2.1.1. La marque blanche
2.1.2. Original Design Manufacturer
2.1.3. Original Equipment Manufacturer
2.1.4. La marque blanche est-elle adaptée pour ce travail ?
2.2. ANALYSE D’UNE PROPOSITION ALTERNATIVE À LA MARQUE BLANCHE – SERVICES WEB
2.2.1. Qu’est-ce qu’un service Web ?
2.2.2. Extensible Markup Language
2.2.3. Architecture Orientée Services
2.2.4. Representational State Transfer
2.2.5. SOAP VS REST
2.2.6. JavaScript Object Notation
2.2.7. Application Programming Interface
2.2.8. L’intérêt d’un service Web avec notre outil
2.3. ANALYSE DES TECHNOLOGIES
2.3.1. Technologie « Applet Java »
2.3.2. Langage Java
2.3.3. Une applet Java est-elle adaptée ?
2.3.4. Technologie « Widget »
2.3.5. Technologie « Docker
2.3.6. Technologie « iFrame
2.3.7. L’utilisation d’une iFrame est-elle adaptée ?
2.4. ANALYSE DES LANGAGES DE DÉVELOPPEMENT – FRAMEWORK – LIBRAIRIES
2.4.1. PHP Hypertext Preprocessor
2.4.2. Un langage de scripts
2.4.3. Pourquoi utiliser PHP ?
2.4.4. JavaScript
2.4.5. Librairie ZingChart
2.4.6. Framework Modèle-Vue-Contrôleur
2.4.7. Framework PHPUnit Framework
2.5. ANALYSE DES MOYENS DE STOCKAGE DES DONNÉES ET HÉBERGEMENT
2.5.1. Hébergement
2.5.2. Stockage et sécurité des données
2.5.3. Situation pour le développement
2.6. ANALYSE ET MISE EN PLACE DE L’INFRASTRUCTURE ET DE L’ENVIRONNEMENT DE
DÉVELOPPEMENT
2.6.1. XAMPP
2.6.2. Pourquoi utiliser XAMPP ?
2.6.3. Quel est le meilleur environnement de développement intégré en PHP ?
2.6.4. NetBeans
2.6.5. GitHub
3. DÉVELOPPEMENT DE L’OUTIL
3.1. APPLICATION CÔTÉ CLIENT – TOUS LES UTILISATEURS
3.1.1. Page d’accueil
3.1.2. Page sur le processus d’évaluation
3.1.3. Page de connexion
3.2. APPLICATION CÔTÉ CLIENT – PORTEUR DE PROJET
3.2.1. Page des projets
3.2.2. Page pour créer un nouveau projet
3.2.3. Page du projet
3.2.4. Page du questionnaire préalable
3.3. APPLICATION CÔTÉ CLIENT – ÉLU COMMUNAL
3.3.1. Page du projet
3.3.2. Page « plus-value »
3.3.3. Page sur l’analyse des conflits potentiels
3.3.4. Page des pondérations
3.3.5. Page sur la cohérence
3.3.6. Page des suggestions et optimisation
3.4. APPLICATION CÔTÉ CLIENT – ADMINISTRATEUR COMMUNAL
3.4.1. Page admin
3.4.2. Page des projets
3.4.3. Page des archives
3.4.4. Page d’une archive
3.4.5. Page des accès utilisateur
3.5. APPLICATION CÔTÉ SERVEUR – ADMINISTRATEUR GÉNÉRAL
3.5.1. Page de connexion
3.5.2. Page du tableau de bord
3.5.3. Gestion des questions
3.5.4. Gestion des axes
3.5.5. Gestion des utilisateurs
3.5.6. Gestion de la langue du site
3.6. STRUCTURE DU PROJET
3.6.1. Application VS-OADE
3.6.2. Application API VS-OADE
3.7. BASES DE DONNÉES
3.7.1. Base de données VS-OADE
3.7.2. Base de données API VS-OADE
CONCLUSION
4.1. SYNTHÈSE GÉNÉRALE
4.2. RETOUR D’EXPÉRIENCE
4.3. RECOMMANDATIONS
4.4. RESPECT DU CAHIER DES CHARGES
4.5. AMÉLIORATIONS ENVISAGEABLES
RÉFÉRENCES
ANNEXES

Télécharger le rapport complet