Master
Reference
Développement de la plateforme « Wicall »
LOGDALI, Zine-El-Abedine
Abstract
Le projet présente le développement d'une application Web pour pratiquer des exercices de langue à l'oral. Celle-ci permet la création et l'utilisation des exercices liés aux fiches du portail «MultiGram» de l'ULB (https://multigram.ulb.ac.be). Chaque exercice est composé d'un ensemble de phrases à oraliser, qui sont créées par un enseignant. Lors de la réponse à un exercice, la plateforme « Wicall » doit effectuer une reconnaissance vocale et une vérification du résultat pour fournir un feedback à l'apprenant. Tout le contenu du projet « Wicall » (code et documentation) est hébergé sur le serveur Gitlab de l'université de Genève, et il est accessible via le lien suivant : https://gitlab.unige.ch/Johanna.Gerlach/multigram
LOGDALI, Zine-El-Abedine. Développement de la plateforme « Wicall ». Master : Univ.
Genève, 2020
Available at:
http://archive-ouverte.unige.ch/unige:132651
Disclaimer: layout of this document may differ from the published version.
1 / 1
Zine-El-Abedine Logdali
Développement de la plateforme « Wicall »
Création d’une plateforme pour pratiquer des exercices d’oralité, basés sur la reconnaissance vocale
Directrice : Pierrette Bouillon Jurée : Johanna Gerlach
Mémoire présenté à la Faculté de traduction et d’interprétation pour l’obtention de la Maîtrise universitaire en Traitement informatique multilingue
Université de Genève Décembre 2019
2
Déclaration attestant le caractère original du travail effectué
J'affirme avoir pris connaissance des documents d'information et de prévention du plagiat émis par l'Université de Genève et la Faculté de traduction et d'interprétation (notamment la Directive en matière de plagiat des étudiant-e-s, le Règlement d'études de la Faculté de traduction et d’interprétation ainsi que l'aide-mémoire à l'intention des étudiants préparant un mémoire en traitement informatique Multilingue).
J'atteste que ce travail est le fruit d'un travail personnel et a été rédigé de manière autonome.
Je déclare que toutes les sources d'information utilisées sont citées de manière complète et précise, y compris les sources sur internet.
Je suis conscient que le fait de ne pas citer une source ou de ne pas la citer correctement est constitutif de plagiat et que le plagiat est considéré comme une faute grave au sein de l'Université, passible de sanctions.
Au vu de ce qui précède, je déclare sur l'honneur que le présent travail est original.
3
Dédicace
Pour ceux, qui m'ont soutenu, conseillé avec patience et qui m'ont orienté vers la bonne voie, pour mes parents, mes encadrants de mémoire, mes professeures, mes collègues, et pour tous ceux qui m'ont épaulé et soutenu durant mon stage, pendant des mois d’études, riches de merveilleux souvenirs gravés à jamais dans ma mémoire.
Je dédie ce modeste travail.
4
Table des matières
DÉDICACE ... 3
TABLES DES MATIÈRES ... 4
LISTE DES FIGURES ... 5
RÉSUMÉ ... 6
INTRODUCTION ... 7
2 DESCRIPTION DU PROJET ... 8
2.1 CONTEXTE ... 8
2.1.1 LES APPLICATIONS CALL ... 8
2.1.2 LE PROJET «MULTIGRAM » ... 9
2.2 L’APPLICATION WICALL ... 9
2.2.1 OBJECTIF ... 9
2.2.2 BESOINS FONCTIONNELS ... 10
2.2.3 BESOINS NON FONCTIONNELS ... 11
3 CONCEPTION DE L’APPLICATION ... 12
3.1 INTRODUCTION ... 12
3.2 ARCHITECTURE ... 12
3.3 LANGAGES ET TECHNOLOGIES UTILISÉES ... 14
3.3.1 CLIENT ... 14
3.3.2 SERVEUR ... 15
3.3.3 BASE DE DONNÉES ... 16
3.3.4 RECONNAISSANCE VOCALE ... 18
3.4 IMPLÉMENTATION... 18
3.4.1 STRUCTURE GLOBALE DU PROJET ... 18
3.4.2 FONCTIONNALITÉS DU CLIENT... 20
3.4.3 FONCTIONNALITÉS DU SERVEUR ... 39
3.5 DÉPLOIEMENT ET GESTION DU CODE ... 49
3.5.1 HEROKU ... 49
3.5.2 INSTALLATION ET DÉMARRAGE DE L’APPLICATION ... 50
3.5.3 CODE SOURCE -GITLAB UNIGE ... 52
4 CONCLUSION ET PERSPECTIVES ... 53
RÉFÉRENCES ... 54
5
Liste des figures
FIGURE 1 : FONCTIONNALITÉS EN FONCTION D'ÉTAT DE CONNEXION ... 10
FIGURE 2 : ARCHITECTURE MVC ... 13
FIGURE 3: STRUCTURE GLOBAL DU PROJET ... 19
FIGURE 4:ORGANISATION DU CODE CLIENT ... 20
FIGURE 5: STRUCTURE DU « FRONT » ... 21
FIGURE 6: INSERTION DES FICHIERS « JAVASCRIPT » ... 22
FIGURE 7: TRAITEMENT DE LA RECONNAISSANCE VOCALE ... 23
FIGURE 8: ACCÈS À L’ESPACE ENSEIGNANT OU L’ESPACE APPRENANT ... 26
FIGURE 9 : CONNEXION D’UN ENSEIGNANT ... 26
FIGURE 10 : CONNEXION D’UN APPRENANT ... 27
FIGURE 11 : ENREGISTREMENT D’UN NOUVEL ENSEIGNANT SECONDAIRE ... 28
FIGURE 12 : INSCRIPTION D’UN APPRENANT ... 29
FIGURE 13: AFFICHAGE DE LA LISTE DES EXERCICES ... 30
FIGURE 14 : AFFICHAGE DU PROFIL APPRENANT ... 30
FIGURE 15 : AFFICHAGE DU PROFIL ENSEIGNANT ... 31
FIGURE 16 : AFFICHAGE DES RÉPONSES DES APPRENANTS ... 32
FIGURE 17 : MODIFICATION D’UN EXERCICE ... 33
FIGURE 18 : PAGE D’ACCUEIL POUR UN ENSEIGNANT ... 34
FIGURE 19: AFFICHAGE DU RÉSULTAT DE LA RÉPONSE DE L’APPRENANT ... 36
FIGURE 20 : MENU DE L’ESPACE « ENSEIGNANT » ... 37
FIGURE 21: MENU DE L’ESPACE « APPRENANT » ... 37
FIGURE 22:ADAPTATION DU CODE CSS POUR LE RESPONSIVE DESIGN ... 38
FIGURE 23:ADAPTATION DES ÉVÈNEMENTS "SWIPERIGHT" ET "SWIPELEFT" ... 39
FIGURE 24: SCHÉMA CONCEPTUEL DES DONNÉES ... 40
FIGURE 25: CODE SQL POUR LA CRÉATION DE LA BASE DE DONNÉES ... 41
FIGURE 26: PRÉVENTION DE L’INJECTION SQL ... 45
FIGURE 27: TRAITEMENT DE LA FAILLE XSS ... 46
FIGURE 28:IMPORTATION DES FICHIERS ET DÉMARRAGE DE L’APPLICATION ... 46
FIGURE 29: FONCTIONS UTILISÉES DIRECTEMENT PAR « WICALL.JS » ... 47
FIGURE 30: CRÉATION DES ÉVÉNEMENTS « REQUEST » POUR LES ROUTES ... 48
FIGURE 31: REQUÊTE POUR DEMANDER L’EXERCICE À FAIRE ... 49
FIGURE 32: REQUÊTE POUR ENREGISTRER LA RÉPONSE ... 49
FIGURE 33: REQUÊTE POUR INSCRIRE UN ENSEIGNANT ... 49
FIGURE 34: LE FICHIER « CONSTANTS-SYSTEM.JS » ... 51
FIGURE 35: LE FICHIER « CONSTANTS-APP.JS » ... 52
6
Résumé
Le projet présente le développement d’une application Web pour pratiquer des exercices de langue à l’oral. Celle-ci permet la création et l’utilisation des exercices liés aux fiches du portail «MultiGram» de l’ULB (https://multigram.ulb.ac.be).
Chaque exercice est composé d’un ensemble de phrases à oraliser, qui sont créées par un enseignant. Lors de la réponse à un exercice, la plateforme « Wicall » doit effectuer une reconnaissance vocale et une vérification du résultat pour fournir un feedback à l’apprenant.
Au moment où nous écrivons ces lignes, L’application «Wicall» est hébergée sur un serveur Web Https de la plateforme «HEROKU», et elle est accessible via le lien suivant :
https://guarded-caverns-60521.herokuapp.com
Tout le contenu du projet « Wicall » (code et documentation) est hébergé sur le serveur Gitlab de l’université de Genève, et il est accessible via le lien suivant :
https://gitlab.unige.ch/Johanna.Gerlach/multigram
7
1- Introduction
L’objectif du travail, est de réaliser une application Web nommée « Wicall », qui permet à des apprenants d’une langue d’exercer à l’oral des compétences communicatives, en accomplissant des exercices d’oralité.
Pour réaliser un tel travail, il faut tout d’abord implémenter une base de données pour la gestion des données de ces exercices ainsi que leurs réponses, puis définir les langages et Framework pour coder l’application, et créer deux espaces de connexion à cette application, un pour les enseignants, qui concerne la création des exercices d’oralité ainsi que leur gestion (suppression, modification, ajout, etc.), et un autre apprenant pour la réalisation de ces exercices. Il faut ensuite définir l’API à utiliser pour faire la reconnaissance vocale (puisqu’on parle d’exercices d’oralité) et savoir l’intégrer correctement dans le code de l’application.
Finalement, il faut réaliser un mécanisme pour enregistrer les réponses obtenues ainsi que leurs résultats, et les rendre consultables, que ça soit par l’enseignant ou l’apprenant. En même temps, l’application doit être extensible afin de pouvoir y ajouter ou modifier des fonctionnalités par un ou plusieurs développeurs.
8
2- Description du projet 2.1 Contexte
2.1.1 Les applications CALL
CALL est l'acronyme de « Computer-Assisted Language Learning », ce qui veut dire apprentissage des langues assisté par ordinateur. Ce terme désigne tout système informatique qui permet à un apprenant de pratiquer une langue cible via un agent conversationnel, c'est-à-dire un programme capable de converser avec un utilisateur de ce programme.
(https://www.digitaweb.com/blog/chatbot-definition, consulté le 17.09.2019)
Depuis les années 1980, le développement de ce genre d’application n’a cessé de se développer. Des chercheurs et développeurs à travers le monde entier travaillent toujours à l’amélioration de ces systèmes. Beaucoup d’efforts ont été faits, à travers différents horizons et perspectives, et plusieurs applications CALL ont été créées sous différents noms, depuis les « chatbots » et les simples agents conversationnels, jusqu’aux robots et systèmes de dialogue.
Au fil des années, les applications CALL sont apparues dans différents domaines et traditions de recherche, basées sur plusieurs technologies et visant différents objectifs (Bibauw et al., 2019).
Au début des années 1980, avec les efforts des développements CALL réalisés par Hart en 1981, et la monte de l’approche communicative dans l’enseignement des langues, les chercheurs ont commencé à s’intéresser à ce genre de système.
Pendant ces années, le travail était plutôt concentré sur le fait d’augmenter l’automatisation et l’intelligence des applications CALL, d’où l’apparition des applications de correction automatique « ICALL » pendant les années 80 et 90, par exemple le programme « FAMILIA », qui était destiné pour l’apprentissage de la langue espagnole en 1982, et le programme « FLUENT » réalisé par Hamburger et Hashim en 1992 (Bibauw et al., 2019).
À la fin des années 90, les chercheurs ont plutôt commencé à s’intéresser aux systèmes CAPT, qui sont des applications CALL dont l’activité principale était de parler avec l’utilisateur. Cet intérêt est né avec le grand avancement qui a été fait sur les algorithmes de traitement de la parole, d’où la réalisation des systèmes comme
« ARTUR », fait par Engwall en 2012, et « Fluency » fait par Eskenazi et Hansma en 1998 (Bibauw et al., 2019).
Au cours de ces dix dernières années, l’exploitation des approches complexes du traitement du langage naturel, a permis l’amélioration des applications CALL, afin de construire des objectifs d’apprentissage plus précis, et avoir des méthodes d’évaluation plus solides, par exemple des systèmes comme « Sasha », réalisé par Peterson en 2010, et le système « IVELL », réalisé par Hassani, Nahvi, et Ahmadi en 2016 (Bibauw et al., 2019).
9
Aujourd’hui, l’application que nous visons à développer à travers ce projet de mémoire, nommée « Wicall », est une application CALL, car elle permet cette conversation entre l’apprenant d’une langue et le système informatique, dont la reconnaissance vocale est la technologie principale sur laquelle est basée l’application « Wicall ».
2.1.2 Le projet « MultiGram »
« Multigram » est une plateforme appartenant à l’université libre de Bruxelles (ULB).
Selon le site de la plateforme, on extrait la citation suivante :
" « MultiGram » est une grammaire communicative multilingue.
Grammaire au sens descriptif et prescriptif, c'est-à-dire les règles de morphologie, de syntaxe et d'usage.
Communicative parce qu'elle décrit, à l'instar de la Communicative « Grammar of English de Leech et Svartvik », les ressources grammaticales requises pour réaliser un nombre d'actes communicatifs (par exemple, marquer son accord/désaccord, poser des questions ou y répondre, ordonner, promettre, souhaiter, ...) et une série d'autres notions nécessaires à qui veut communiquer correctement et efficacement (telles que : amabilité, durée, regret, reproche, ...).
Multilingue : l'aspect contrastif, imaginé par S. Gola, est une nouveauté : en plus de la juxtaposition de plusieurs grammaires, chacune avec sa spécificité et sa propre nomenclature, la grammaire informatisée permet d'établir des liens entre les pages consacrées à des problématiques similaires, et d'attirer l'attention, chaque fois que le format le permet, sur des structures qui diffèrent d'une langue à l'autre, et qu'un apprenant débutant risquerait de projeter d'une langue sur l'autre."
(http://multigram.ulb.ac.be/eng/MultiGram:Qu%27est-ce_%3F, consulté le 08.08.2019)
2.2 L’application « Wicall » 2.2.1 Objectif
Suite aux fiches du portail « Multigram », l’application « Wicall » vient pour permettre la création et l‘utilisation des exercices liés à ces fiches. C’est un système contenant deux espaces, un espace enseignant qui permet de gérer des exercices d’oralité (création, modification et suppression), et un espace apprenant pour faire ces exercices créés par les enseignants. Chaque exercice est composé d’un ensemble de phrases à oraliser.
« Wicall » doit effectuer une reconnaissance vocale et une vérification du résultat pour fournir un feedback à l’apprenant.
Les liens des exercices qui sont créés et gérés par « Wicall » sont publiés sur le portail
« MultiGram » de l’ULB.
L’application peut être utilisée de deux manières, en étant connecté ou pas.
10
Dans l’état de déconnexion, trois activités sont accessibles : faire un exercice sans avoir de compte, créer un compte apprenant, ou se connecter.
Dans l’état de connexion, plusieurs fonctionnalités sont accessibles selon la personne connectée, comme la création d’un exercice, la consultation d’une réponse. La figure 1 illustre bien ce principe.
Fonctionnalités en fonction d'état de connexion
Figure 1 2.2.2 Besoins fonctionnels
L’application « Wicall » doit permettre plusieurs fonctionnalités, dont on cite surtout les besoins fonctionnels suivants :
L'accès à l’espace enseignant ou apprenant par une interface de connexion.
Création d’un compte enseignant ou apprenant.
Création, suppression et modification d’un exercice.
Affichage des exercices créés et des réponses enregistrées.
Sauvegarde de toute réponse à une question.
Chaque enseignant doit pouvoir gérer ses propres exercices, et pas les exercices des autres enseignants.
Chaque exercice doit être accessible via un lien unique pour répondre aux questions qu’il contient.
L’objet de la question contient 3 éléments : la question elle-même, une liste de réponses correctes, et une liste de réponses incorrectes.
11
Chaque élément de la liste des réponses incorrectes se construit de la réponse elle- même et d’un commentaire facultatif qui explique pourquoi cette réponse est incorrecte.
L’apprenant répond à la question par un enregistrement vocale. L’application doit vérifier ensuite si cette réponse existe parmi la liste des réponses correctes ou non, si oui, le système affiche donc que le résultat de l’apprenant est correct, sinon, il affiche que le résultat est incorrect, et dans ce cas l’application doit vérifier si la réponse dite existe parmi la liste des réponses incorrectes, afin d’afficher le commentaire possible de cette réponse.
Toutes ces fonctionnalités doivent être bien organisées et accessibles selon la nature du compte connecté.
2.2.3 Besoins non fonctionnels
Les besoins non fonctionnels, négligés par pas mal de développeurs, sont très importants pour la qualité d’un système informatique, surtout lorsqu’on parle d’une application en ligne ; c’est vrai que ces besoins influencent indirectement sur l’application, mais ils influencent fortement, et s’ils ne sont pas pris en compte, les conséquences sont souvent terribles.
2.2.3.1 Performance et sécurité
L’application « Wicall » doit être exacte dans la présentation des résultats, et les opérations effectuées lors d’une requête Http doivent être rapides et sécurisées en évitant les failles de sécurité possibles, comme les injections SQL lors d’une requête envoyée à la base de données, la faille XSS, l’échappement du code html, etc.
2.2.3.2 Référencement (SEO)
L’application « Wicall » doit respecter les normes de référencement, afin qu’elle soit facilement trouvée sur les moteurs de recherche.
2.2.3.3 Maintenabilité ou extensibilité
Le code de l’application « Wicall » doit être fait en respectant l’architecture « MVC », ce qui permet une détection facile des erreurs, rend le code plus modulaire, et permet à l’application d’être extensible.
2.2.3.4 Compatibilité et probabilité
L’application « Wicall » doit être compatible avec les navigateurs les plus utilisés, comme « Chrome », « Firefox » « Safari » ou « Internet Explorer », ainsi qu’avec les différentes tailles d’écran, comme une tablette ou un téléphone mobile.
2.2.3.5 Ergonomie
L’application doit être accessible facilement, avec une bonne visibilité, et du texte clair.
La navigation doit être facile sur le site avec des liens cliquables et identifiables, en respectant la règle des trois clics, qui consiste à trouver l'information recherchée sur le
12
site en maximum 3 clics. Ceci assure que l'information soit trouvée rapidement par l'internaute.
2- Conception de l’application 3.1 Introduction
Afin d’arriver à réaliser les différentes fonctionnalités citées plus haut, Quels outils nous allons utiliser pour réaliser une telle application ? Quels langages et Framework nous allons utiliser pour programmer les opérations du serveur, ainsi que la programmation coté client, qui représente une interaction instantanée avec l’utilisateur ? La réalisation du projet nécessite aussi une persistance des données, comment donc ces données seront gérées et organisées ?
Une reconnaissance vocale doit être intégrée dans le système pour détecter la réponse de l’apprenant, quelle technologie nous allons utiliser pour faire cette reconnaissance vocale, et comment pouvons-nous l’intégrer dans le code de l’application ?
Tout d’abord, nous allons commencer par la conception de la base de données, ainsi que la définition des différentes techniques que nous allons utiliser pour sa création et son administration. En faisant cette base, on sait par la suite comment les fonctionnalités de toute l’application seront liées, et on sait donc de quelle manière chaque fonctionnalité sera implémentée, c’est vraiment la base de tout le projet. Puis nous allons définir les différents langages de programmation utilisés pour coder l’application, que ça soit pour le coté serveur (coté back) ou pour le navigateur Web (coté front), en même temps, nous citerons des Framework utilisés avec ces langages.
Puis il va falloir définir l’API de la reconnaissance vocale, et savoir comment elle doit être intégrée dans l’application pour obtenir le résultat de la réponse à un exercice de l’application.
La définition de cette méthodologie est primordiale pour la réalisation du projet, ça permet surtout d’aller facilement et rapidement dans la réalisation du code, en obtenant un résultat qui répond aux besoins fonctionnels et non fonctionnels demandés.
3.2 Architecture
Le développement n’importe comment engendre plusieurs problèmes :
● On ne peut pas travailler à plusieurs contributeurs sur un même projet ou une même application (travail en équipe), car chacun va suivre sa propre méthode.
● On ne sera pas capable de faire évoluer notre application après un longtemps de sa création, car on ne va plus pouvoir se repérer.
● Notre application ne peut pas être facilement et rapidement lu par un autre développeur qui sera mené à l’améliorer, et donc, elle ne sera pas extensible.
13
Pour toutes ces raisons, il est nécessaire d'adopter une architecture bien précise pour le code source, permettant de créer une application facile à maintenir.
Le pattern MVC est une bonne solution, car il permet d’organiser le code, et définir le rôle de chaque fichier de l’application.
Le but de MVC est justement de séparer la logique du code en trois parties que l'on retrouve dans des fichiers distincts.
La partie Modèle : cette partie gère les données de la plateforme. Son rôle est d'aller récupérer les informations « brutes » dans la base de données, de les organiser et de les assembler pour que ces données puissent ensuite être traitées par le contrôleur.
On y trouve donc les requêtes SQL.
La partie Vue : cette partie se concentre sur l'affichage. Elle ne fait aucun calcul pour le serveur et se contente de récupérer des variables pour savoir ce qu'elle doit afficher.
On y trouve essentiellement du code HTML, CSS, et de la programmation avec
« Javascript ».
La partie Contrôleur : cette partie gère la logique du code qui prend des décisions. C'est en quelque sorte l'intermédiaire entre le modèle et la vue : le contrôleur demande au modèle les données, les analyses, prend des décisions et renvoie la réponse à la vue.
C'est notamment lui qui détermine si le visiteur a le droit de voir la page ou non (gestion des droits d'accès entre l’apprenant et les enseignants).
Figure 2
(https://openclassrooms.com/fr/courses/2434016-developpez-des-sites-web-avec- java-ee/2438576-le-modele-mvc, consulté le 10.06.2019)
Cette structure et architecture MVC que nous utilisons pour le code, tel qu’elle est illustrée dans la figure 2, permet à l’application d’être facilement extensible et maintenable rapidement par un autre développeur, ou par une équipe de développeurs, afin d’ajouter d’autres fonctionnalités.
Sachant que ça permet aussi de situer l’erreur et savoir sa source rapidement, surtout avec le traçage de la console que nous ajoutons lors de la réalisation du code.
3.3 Langages utilisés pour le développement
14
On sait que « Wicall » est une application Web accessible via réseau internet comme cité plus haut, donc il va falloir des langages de programmation Web, pour cela, il existe plusieurs langages, pour le coté client (navigateur Web), ainsi que pour le coté serveur.
3.3.1 Client
Pour le coté client, il existe des langages standards que tout développeur doit utiliser pour faire tourner son application Web sur un navigateur, ce sont les langages HTML, CSS et « Javascript ».
Pour une application de haute qualité, on va utiliser les dernières versions des langages (CSS3, HTML5, et Javascript (ES6)), sans oublier la gestion de compatibilité avec les anciens navigateurs qui ne comprend pas certaines fonctionnalités de ces nouvelles versions.
Pour simplifier la programmation coté client avec « Javascript », nous utilisons le Framework « JQuery », qui est vraiment puissant et élégant.
Pourquoi « JQuery » ?
● Puissance : « JQuery » est le Framework « Javascript » le plus utilisé de tous : même les plus grands sites du monde en bénéficient, tel que « Google », « Facebook », « Wikipedia », « Twitter », etc. « JQuey » est complet, puissant et élégant. Beaucoup sont ses points forts, et rares sont ses points faibles.
● « Write Less, Do More » : les créateurs de la bibliothèque ont fait une devise : « Write Less, Do More ». Cette devise, on peut la traduire tout bêtement par : "JQuery.
Ecrivez moins, faites plus". Cela résume vraiment ce que « JQuery » nous permet de faire. En l'utilisant dans le code « Javascript » : nous écrivons moins de code et nous sommes beaucoup plus productives.
● Facilité : « JQuery » permet de faciliter extrêmement des tâches qui ont été trop complexe en « Javascript » tel que les appels Ajax, la gestion des événements, etc.
● Compatibilité : la compatibilité inter-navigateurs signifie qu'un code « Javascript » qui fonctionne sur un navigateur Web doit fonctionner sur un autre, et bien « JQuery
» uniformise le tout ! Au final, un code « Javascript » respectant les normes imposées par « JQuery » sera compatible sur tous les navigateurs Web, ce qui est extrêmement important, car un gain de temps et d'énergie plus qu’appréciable, permet de se focaliser vraiment sur le cœur du code, plutôt que sur des questions de compatibilité entre navigateurs.
15
● « JQuery » et l'AJAX : dans le même registre de compatibilité, l'AJAX avec « JQuery
» a été grandement simplifié. Grâce à « JQuery », instancier un objet Ajax est très simple, une seule fonction fait le travail, et couvre tous les navigateurs.
(https://openclassrooms.com/fr/courses/1567926-un-site-web-dynamique-avec- jquery/1568058-jquery-lhistoire-dun-framework, consulté le 10.06.2019)
Une multitude d’outils utilisés pour le développement
Nous utilisons les interpréteurs du langage ci-dessus, pour les deux langages de description HTML et CSS, ainsi que pour le langage de programmation « Javascript » qui permet de rendre l’application Web interactive avec l’utilisateur. Tous ces navigateurs Web contiennent des systèmes de débogage intégrés, qui permettent de détecter les erreurs de programmation et de description des interfaces graphiques.
L’utilisation de différents navigateurs nous permet aussi de vérifier la compatibilité de l’application Web entre eux, ainsi qu’avec les différentes tailles d’écran, que ça soit pour un mobile ou un grand ordinateur.
3.3.2 Serveur
« Wicall » est une application Web, il faut donc utiliser des langages coté serveur. Pour celà, il existe une multitude de langages : PHP, JAVA EE, PYTHON, Ruby ON RAILS, etc.
Ce qui nous concerne, nous utilisons le langage « Javascript » encore une fois, en entend par ça la technologie Node.JS qui permet d’utiliser « Javascript » coté serveur.
L’environnement de travail Node.JS pour le coté serveur
16
Node.JS est un environnement de travail pour coder coté serveur, il représente une manière de coder avec « Javascript » en utilisant les fonctions de ses modules déjà définis.
« JavaScript » est un langage basé sur les évènements, donc Node.js lui-même est basé sur les évènements, par conséquent, c'est toute la façon d'écrire des applications Web qui change ! Et c'est de là que Node.JS tire toute sa puissance et sa rapidité, ayant un fonctionnement non bloquant, en plus de l’utilisation d’un interpréteur extrêmement rapide, qui est le moteur « Javascript V8 ».
(https://nodejs.org/docs/latest-v7.x/api/, consulté le 10/07/2019) Le Framework Express pour le coté serveur
Node.JS est un environnement très bas niveau. Il se rapproche donc en quelque sorte plus au C qu’au PHP, Ruby on Rails ou Django.
Nous utilisons Express, qui est un Framework basé sur Node.JS, pour éviter des tâches répétitives qui nous sont imposées par la nature bas niveau de Node.JS.
3.3.3 Base de données
La conception d’une base de données est une étape primordiale, afin d’avoir un système bien configuré, il est obligatoire (surtout lorsqu’on parle de gros projets) de bien étudier et comprendre sa base de données en passant par une phase de conception, avant de l’implémenter.
Définitions et généralités
"Une base de données est un ensemble de données qui ont été stockées sur un support informatique, organisées et structurées de manière à pouvoir facilement manipuler leur contenu."
(https://openclassrooms.com/fr/courses/1959476-administrez-vos-bases-de- donnees-avec-mysql/1959710-decouvrez-mysql, consulté le 19.07.2019) Il existe 4 types de bases de données :
1. BD Hiérarchiques : les plus anciennes fondées sur une modélisation arborescente des données.
2. BD Relationnelles : organisation des données sous forme de tables.
3. BD Déductives : organisation de données sous forme de table et exploitation à l’aide d’un langage logique.
4. BD Objets : organisation des données sous forme d’instances de classes hiérarchisées qui possèdent leurs propres méthodes d’exploitation.
17
Pour ce qui nous concerne, nous utilisons un SGBD relationnel (SGBDR), puisque nous enregistrons les données dans des tables.
Pourquoi une base de données ?
Ça permet de mettre des données à la disposition d'utilisateurs pour une consultation, une saisie ou bien une mise à jour, tout en s'assurant des droits accordés à ces derniers.
Cela est d'autant plus utile que les données informatiques sont de plus en plus nombreuses.
Cette base peut être locale, c'est-à-dire utilisable sur une machine par un utilisateur, ou bien répartie, c'est-à-dire que les informations sont stockées sur des machines distantes et accessibles par un réseau.
Système de gestion de base de donnes et langage SQL
MySQL est le système que nous utilisons pour gérer les données de l’application
« Wicall », c’est un système de gestion de base de données relationnel (SGBDR), d’où le R de l’acronyme « SGBDR », et ça veut dire que les données sont enregistrées et organisées selon le format des tables. Autrement dit, les données sont contenues dans ce qu'on appelle des relations, qui sont représentées sous forme de tables.
MySQL est un système extrêmement puissant, et utilisé par des grandes entreprises comme « Facebook », sa popularité est due au fait qu'il s'agit d'un logiciel Open Source, ce qui signifie que son code source est librement disponible et que quiconque peut modifier MySQL pour l'améliorer ou l'adapter à ses besoins. Une version gratuite de MySQL est par conséquent disponible. À noter qu'une version commerciale payante existe également.
SQL est un langage pour transmettre des instructions à la base de données (par l'intermédiaire du système de gestion), afin de dire quelle manipulation à faire sur les données, ce qu’on appelle un langage de requête. SQL est le langage de requête que nous utilisons pour le développement.
3.3.4 Reconnaissance vocale
La reconnaissance vocale est une fonctionnalité centrale de l’application « Wicall », car le but est d’aider les apprenants à apprendre la langue française à l’oral et même aussi à l’écrit puisqu’on présente les réponses et les questions sous une forme écrite.
18
L’application doit donc arriver à reconnaitre ce que l’apprenant a dit pour donner un
"feedback" approprié.
3.3.4.1 L’API de Microsoft Speech et une question de correspondance
Nous utilisons l’api de Microsoft pour faire la reconnaissance vocale. Microsoft Speech est représenté par un ensemble de fonctions à utiliser pour réaliser une telle tâche, qu’on peut diviser en deux étapes : enregistrer le son dit et le transformer à une phrase.
Les API de la reconnaissance vocale sont d’une très bonne qualité, mais ne sont pas encore précises à 100% comme étant un être humain, et les développeurs à travers le monde entier, travaillent encore à ce sujet afin d’augmenter la qualité du résultat obtenu. Ce petit manque de précision vient du fait que l’API Microsoft peut rencontrer des perturbations lors de l’enregistrement, ces perturbations peuvent être à cause d’un changement au niveau du volume du son concerné, ou à cause d’un autre son qui vient d’une autre source plus loin, au cours de l’enregistrement du son concerné.
La raison pour laquelle nous ajoutons une notion de correspondance dans cette partie de reconnaissance vocale, c'est-à-dire, à la place de comparer brutalement la phrase reconnue avec la réponse correcte ou incorrecte de la question, nous calculons la correspondance entre les deux phrases, si cette correspondance est supérieure à un taux (défini par l’enseignant primaire), de 80% par exemple, les deux phrases sont considérées similaires, sinon ils ne sont pas.
L’enseignant primaire a aussi accès aux résultats des réponses effectuées, et il peut se baser sur ces données pour augmenter ce taux de correspondance ou le diminuer.
3.4 Implémentation
Nous citons ici les bonnes pratiques et les fonctionnalités les plus importantes que nous utilisons dans l’implémentation de l’application « Wicall », afin d’avoir un code optimal, sécurisé, et qui répond surtout aux besoins non fonctionnels.
Cette partie expliquera par conséquent des lignes de code, où on remarque l’adaptation de ces techniques et bonnes pratiques.
3.4.1 Structure global du projet
19
Figure 3
« Wicall.js » : le point d'entrée de l'application, autrement dit, le point d'entrée de toute requête Http depuis le client vers le serveur, par conséquent c'est ce fichier qui traite le routage, pour savoir vers quel endroit de traitement une telle requête sera traitée.
« Models » : contient toutes les fonctions qui traitent le stockage dans la base de données.
« Views » : rassemble toute la partie « vue » de l’application, dont on trouve principalement les fichiers d’interfaces graphiques (fichiers HTML et CSS), et les fichiers
« Javascript » de programmation coté client.
« Controllers » : contient tous les fichiers contrôleurs de l’application.
« Config » : contient tous les fichiers nécessaires pour la configuration de l’application
« Wicall »
« Lib » : contient un ensemble de fonctions que nous utilisons à travers les dossiers du
"back", ces fonctions sont créées par nous-mêmes et n’appartient à aucun
« Framework ».
« Node_modules » : contient des modules téléchargés pour le fonctionnement de certaines fonctions Nodes.JS à travers les dossiers du "back".
20
Le fichier « package.json » représente une identification de l’application, mais ne rentre pas dans son fonctionnement. Le dossier « doc » contient des documentations pour le projet « Wicall », et n’est pas aussi demandé pour le fonctionnement de l’application. Le fichier « Procfile » contient une simple commande faite pour l’hébergement de l’application sur la plateforme Heroku, donc lui aussi, ne rentre pas dans le fonctionnement de l’application.
Tous les fichiers et dossiers du projet représentent la partie « Backend » de l’application, sauf le dossier « views » qui lui représente la partie « Frontend » (les fichiers qui sont envoyés comme réponses chez le client).
3.4.2 Fonctionnalités du client 3.4.2.1 Organisation du code client
Le contenu du dossier « views », qui est illustré dans la figure 4, représente toute la
« vue » de l’application. Il contient des pages HTML, qui représentent le contenu des pages Web, ces pages HTML sont générées par le moteur « ejs » de l’environnement Node.JS, c’est un langage pour programmer le contenu HTML en fonction des données qui seront affichées sur cette page, la raison pour laquelle ces pages portent l’extension « ejs ».
Le dossier « sources » représente les fichiers "sources" utilisés par les scripts « ejs », il contient des fichiers CSS (pour la mise en forme des pages « ejs »), certains documents (comme des images), et des fichiers « Javascript » pour rendre la page Web interactive (appel Ajax, clique sur des boutons, etc).
Figure 4
21
Tel qu’il est illustré dans la figure 5, le dossier HTML contient les documents utilisés par les pages Web, le dossier CSS contient les fichiers CSS pour la mise en forme, et le dossier JS contient les fichiers « Javascript » pour rendre la page Web interactive avec
l’utilisateur.
Figure 5
(a) Insertion des fichiers « Javascript »
Traditionnellement il était d'usage de placer la balise <script> entre les tags <head> et
</head>, cependant il est recommandé de la placer en fin de document juste avant
</body> pour ne pas bloquer le chargement de la page et exécuter les scripts uniquement lorsque le DOM (le code html) est prêt.
C’est la raison pour laquelle nous mettons les fichiers JS, dans la dernière partie de la page html (directement avant la balise fermante de body), en effet si on place les fichiers JS dans la partie <head>, ce qui est le cas pour pas mal d’applications, nous allons retarder le rechargement de la page HTML, il sera mieux donc que le code qui concerne l’affichage de la page, se télécharge complètement en premier sans qu’il soit ralenti par le téléchargement relativement lourd du code « JavaScript », et dans ce cas l’utilisateur va beaucoup moins attendre pour que la page soit affichée devant ses yeux.
Surtout que nous téléchargeons souvent des Framework et API « Javascript », comme
« Jquery » et l’API de « Microsoft speech », qui sont lourds par rapport au contenu HTML et CSS. La figure six illustre un exemple du code pour cette insertion des fichiers
« Javascript ».
22
Figure 6 3.4.2.2 Reconnaissance vocale
Une question demande à l’apprenant de dire quelque chose, dès que l’apprenant est prêt pour répondre, il clique sur un bouton d’enregistrement vocal. L’enregistrement vocal commence et s’effectue localement (dans le navigateur). Lorsque l’apprenant finit de parler, l’enregistrement s’arrête et le son capturé est envoyé à un serveur Microsoft, qui se charge de faire la reconnaissance vocale, c'est-à-dire transformer le son enregistré à une chaine de caractères, qui représente la phrase dite par l’apprenant.
Cette phrase reconnue est renvoyée par la suite au client (la partie front de l’application), qui lui fait localement sa comparaison avec la liste des réponses correctes et incorrectes, afin de déterminer le résultat de la réponse obtenue, cette comparaison est faite selon la notion de correspondance dont on a parlé plus haut.
Le code du fichier « exercer.js », illustré dans la figure sept, traite toute la programmation client lors de la réalisation d’un exercice.
23
24
25
Figure 7 (a) Appels au serveur Microsoft : Ajax
Pour des raisons de performance et de confort lors de la réponse, les appels au serveur Microsoft, sont effectués par une technique Ajax, qui permet de faire l’appel au serveur depuis le navigateur et obtenir des réponses sans recharger la page, et c’est la même technique d’ailleurs que nous utilisons pour l’enregistrement automatique de la réponse obtenue (directement après l'obtention du résultat de la réponse d'une question, cette réponse est envoyée à la base de données par appel Ajax afin qu'elle soit sauvegardée), sachant que cela évite aussi d’avoir des perturbations et des conflits lors de l’exécution du code.
3.4.2.3 Espace enseignant ou apprenant
Un enseignant ou apprenant peut accéder à son espace via une interface graphique qui lui permet de se connecter (figure 8).
26
Accès à l’espace enseignant ou l’espace apprenant
Figure 8
L’utilisateur se connecte avec un identifiant unique qui représente son compte et un mot de passe qui sécurise l’accès à son compte (figures 9 et 10).
Connexion d’un enseignant
Figure 9
27
Connexion d’un apprenant
Figure 10 (a) Création d’un compte enseignant
Il y a deux niveaux de compte pour un espace enseignant, un enseignant primaire et un autre secondaire. Il y a toujours un seul enseignant primaire qui se charge de créer des enseignants secondaires et d’autres tâches que nous allons détailler par la suite.
Une interface de création d’un enseignant secondaire est dédiée donc spécialement à l’enseignant primaire. Dès la création de ce compte secondaire, l’enseignant concerné est notifié par un mail contenant ses informations pour se connecter sur la plateforme
« Wicall » et commencer à créer des exercices (figure 11).
Comment avoir un compte d’enseignant primaire ?
Lors du démarrage de l’application, cette dernière vérifie s’il y a un compte enseignant primaire créé ; si ce n’est pas le cas, l’application génère un compte primaire avec l’identifiant "primary", ainsi qu’un mot de passe aléatoire. Ces informations sont envoyées par la suite à l’adresse mail indiquée dans le fichier de configuration
« Wicall », afin que l’enseignant primaire puisse se connecter.
28
Enregistrement d’un nouvel enseignant secondaire
Figure 11 (b) Création d’un compte apprenant
Pour avoir un compte apprenant dans l’application, l’utilisateur a seulement besoin de renseigner deux champs : son pseudo unique et son mot de passe (figure 12).
L’application gère une information qui n’est pas présente dans l’interface d’inscription, qui est la date de création du compte.
« Wicall » connecte automatiquement l’apprenant après une inscription réussie.
29
Inscription d’un apprenant
Figure 12 (c) Connexion d’un apprenant
Lorsqu’un apprenant se connecte, l’application le renvoie vers une page d’accueil, où nous lui affichons les exercices classés par ordre de mise à jour (figure 13). Pour répondre à un exercice, un apprenant peut cliquer sur un bloc d’exercices parmi les blocs affichés dans sa page d’accueil, ou utiliser un lien unique qui lui renvoie vers cet exercice.
Affichage de la liste des exercices
30
Figure 13 (d) Paramètres du compte apprenant
Un apprenant a par conséquent accès à une interface de paramètres pour modifier son mot de passe, d'où l'existence de l'interface graphique du profil, comme illustré dans la figure 14.
Affichage du profil d’un apprenant
Figure 14
31
(e) Paramètres du compte enseignant
Un enseignant a accès à une interface de paramètres pour modifier son mot de passe, comme illustré dans la figure 15.
Affichage du profil d’un enseignant
Figure 15 (f) Réponses du compte apprenant
Comme l’enseignant, l’apprenant peut aussi accéder à la liste de ses réponses sauvegardées, qui sont classées par ordre croissant selon la date de réponse. Les réponses sont groupées par exercice (figure 16).
32
Affichage des réponses des apprenants
Figure 16 (g) Déconnexion des comptes
Apprenant ou enseignant peut se déconnecter via un bouton de déconnexion.
3.4.2.4 Création, suppression ou modification d’un exercice
Un enseignant primaire ou secondaire peut créer, supprimer ou modifier ses propres exercices ; chaque enseignant a accès à ses propres exercices.
Chaque exercice est identifié par un identifiant unique, son nom, sa date de création et la date de sa dernière modification.
Même si l’exercice est supprimé, on doit toujours avoir accès aux réponses des apprenants, et par conséquent aux questions auxquelles cet apprenant a répondu.
Donc un exercice peut être supprimé, mais les réponses doivent toujours être accessibles.
Modification d’un exercice
Figure 17
Un exercice peut être modifié par suppression ou modification d’une ou plusieurs questions, comme montré dans la figure 17.
Après la création d’un exercice, le système génère une "url" unique qu’on peut utiliser pour accéder à l’interface qui permet de répondre à cet exercice.
3.4.2.5 Tableau de bord d’un enseignant
Après la connexion d’un enseignant, sa page d’accueil représente l’ensemble des réponses obtenues à ses exercices (figure 18).
Les réponses sont regroupées par compte apprenant, si la réponse est enregistrée dans un mode de déconnexion (pas de compte apprenant concerné), cette réponse est donc classée avec les réponses appartenant au compte anonyme.
Page d’accueil pour un enseignant
Figure 18
35
Lorsque l’enseignant clique sur la ligne d’un apprenant, il accède à ses réponses. Ces réponses sont affichées de la même manière comme dans l’espace apprenant, le plus est que le titre de l’exercice est cliquable afin que l’enseignant puisse accéder à l’interface de modification d’exercice.
3.4.2.6 Répondre à un exercice
Un lien unique pour répondre à un exercice est livré après la création de ce dernier, l’enseignant qui l’a créé, peut utiliser ce lien pour le publier sur le site « Multigram », comme ça un apprenant peut y accéder pour répondre.
L'apprenant peut répondre qu’il soit connecté ou non à son compte, par conséquent toute réponse est toujours enregistrée.
D’autre part, un enseignant connecté ne peut pas faire l’exercice, par conséquent, s’il tente d’y accéder pour tester par exemple, une déconnexion automatique, ainsi qu’une redirection (vers la page de réponse) seront proposées pour tester l’exercice.
Avant de commencer à répondre à l’exercice, le système informe l’apprenant du nombre des questions de l’exercice.
Une fois que l’apprenant donne une réponse, cette réponse est enregistrée automatiquement dans la base des données, sans rechargement de la page courante, pour ne pas perturber l’apprenant lors de la réalisation de l’exercice (figure 19).
36
Affichage du résultat de la réponse de l’apprenant
Figure 19
3.4.2.7 Un menu de navigation
Un menu est réalisé pour organiser l’accès aux différentes fonctionnalités, que ça soit pour le compte enseignant ou apprenant (figures 20 et 21).
Sachant que le menu de l’enseignant secondaire, n’a pas l’onglet « inscrire », et le contenu sa page de profil est différent de celui d’un enseignant primaire.
Il faut aussi savoir que l’espace enseignant comporte un menu horizontal qui comporte trois boutons : un bouton « Profil » pour gérer les informations de son compte, un bouton pour retourner rapidement au contenu précédant la page Web courante, et un bouton pour se déconnecter de son compte.
37
Menu de l’espace « Enseignant » Menu de l’espace « Apprenant
Figure 20 Figure 21
3.4.2.8 Responsive design
Pour rendre l’application « Wicall » responsive, nous nous basons sur quatre points.
Ce sont de bonnes pratiques qui sont puissantes, car elles permettent de rendre l’application facilement responsive, et sont élégantes, car on écrit beaucoup moins de code par rapport à d’autres méthodes, comme l’utilisation du Framework
« Bootstrap », qui charge le code HTML par pas mal de classes, ainsi que le projet par son existence.
Le premier point consiste à ne pas fixer la taille d’un élément HTML si et seulement si on a vraiment besoin, car par défaut, tout élément HTML qui est librement placé dans la balise "<body>" (c’est-à-dire sans contrainte d’un code CSS), se charge tout seul d’avoir la taille compatible avec la taille d’écran existante.
La figure 22 illustre un exemple, où "#sec1" et "#sec2" sont les blocs principaux de l’interface graphique qui permet de répondre à un exercice, leur code CSS appartient au fichier "exercer.css".
Dans cette figure, on voit clairement que nous ne fixons pas une largeur ou hauteur, et nous attribuons plutôt des valeurs en pourcentage pour les marges.
38
Adaptation du code CSS pour le responsive design
Figure 22
Le deuxième point consiste à utiliser certaines propriétés et valeurs CSS qui vont très bien avec le responsive design, comme la propriété "text-align" et sa valeur "center", ou encore l’utilisation des pourcentages pour les marges intérieures et extérieures des blocs HTML (ce qui est d’ailleurs illustré dans la figure 22), ou même pour la largeur et hauteur des blocs, sans oublier de changer certaines valeurs CSS par défaut, qui ne sont pas compatibles avec le responsive design, comme la valeur de la propriété "-webkit-tap-highlight-color" qui permet par défaut de surligner un bloc quand on clique sur ce dernier. On peut voir le traitement de ce genre de cas dans le fichier "zine-css.css" où nous traitons toutes les propriétés de ce genre.
Notre troisième point consiste à utiliser les "media queries" du langage CSS, c’est une technique que nous utilisons lorsque nous sommes obligés de fixer la taille d’un élément par exemple, alors qu’on se sent par la suite le besoin de modifier cette taille pour un écran plus petit ou plus grand, ou pour changer d’autres propriétés de mise en forme en fonction d’une taille précise de l’écran. On peut trouver des exemples d’utilisation des "media queries" dans plusieurs fichiers CSS de l’application.
Le quatrième point qui vient en dernier recours (c’est-à-dire quand nous ne sommes pas en mesure de donner une solution en CSS), consiste à rendre quelques parties de l’application responsives en utilisant « Javascript », ou plutôt des Framework comme « JQuery mobile ». Ceci est vraiment utilisé pour des cas bien précis, comme la gestion des événements mobile "swiperight" et "swipeleft", afin d’avoir la navigation la plus performante possible sur une tablette ou téléphone mobile. La figure 23 illustre un exemple de genre de cas, traité dans l’application « Wicall ».
39
Adaptation des évènements "swiperight" et "swipeleft"
Figure 23 3.4.3 Fonctionnalités du serveur
3.4.3.1 Schéma conceptuel des données
Nous utilisons l’outil « PowerAmc » pour créer le schéma conceptuel de notre base de données, afin d’obtenir le schéma illustré dans la figure 24, où on distingue cinq entités pour l’application « Wicall » :
- Enseignant : celui qui va créer les exercices.
- Exercice : identifié par un identifiant unique, comporte une à plusieurs questions, et chaque question comporte une à plusieurs réponses correctes, et peut aussi comporter une liste de réponses incorrectes.
- Une réponse correcte se construit d’une phrase correcte qui doit être le résultat de la reconnaissance vocale, une réponse incorrecte se construit d’une phrase qui ne répond pas à ce qui est demandé dans la question, et d’un commentaire facultatif.
- Question : qui représente une question crée par un enseignant pour un exercice.
- Réponse obtenue : qui représente la réponse d’un apprenant à un exercice.
- Config : qui rassemble des valeurs de configuration de l’application
« Wicall », et qui sont susceptibles de se varier lors de l’exécution de l’application. Ces valeurs ne sont pas donc des constantes, comme le cas dans un fichier de constantes (qu’on va voir par la suite), qui lui rassemble aussi des valeurs de configuration de l’application, mais ces valeurs restent constantes pendant l’exécution de la plateforme.
40
Figure 24
3.4.3.2 Code SQL pour la création de la base de données
Depuis le schéma conceptuel, on peut obtenir le code SQL pour la création des tables de la base de données, comme illustré dans la figure 25, et où nous expliquons l’existence des différents attributs et associations cités dans le schéma conceptuel.
41
42
43
Figure 25
Nous utilisons le type de donnée « VARCHAR » pour un champ qui peut comporter jusqu’à 255 caractères, c’est le cas des « username » et mots de passe. Le type
« TEXT » permet d’enregistrer plus de 65 000 caractères, comme le cas du feedback qui peut être renseigné par l’enseignant. Le type « DATETIME » est fait pour enregistrer la date et le temps (comme le temps d’enregistrement de la réponse d’un apprenant), et le type « DATE » est utilisé pour enregistrer la date seulement (comme la date d’inscription). Les types numériques « INT », « BIGINT » et
« TINYINT » sont utilisés pour enregistrer des nombres. Le type « BIGINT » permet la plus grande marge d’enregistrement des nombres, le type « INT » vient en deuxième position, puis le type « TINYINT » qui est destiné pour saisir des nombres entre 0 et 100. « TINYINT » est le type de notre champ « correspondance ».
(https://openclassrooms.com/fr/courses/1959476-administrez-vos-bases-de-
donnees-avec-mysql/1960456-distinguez-les-differents-types-de-donnees, consulté le 25/09/2019)
3.4.3.3 L’utilisation du moteur INNODB pour la création de chaque table SQL
Nous utilisons le moteur INNODB (ENGINE = INNODB) pour les tables MySQL, car ce moteur gère les clés étrangères et les transactions. Étant donné que nous nous servons des clés étrangères, c'est celui-là que nous utilisons. De plus, en cas de crash du serveur, ce moteur possède un système de récupération automatique des données.
44
Alors que celui par défaut (moteur MyISAM) ne gère pas certaines fonctionnalités importantes comme les clés étrangères, qui permettent de vérifier l'intégrité d'une référence d'une table à une autre table
(https://openclassrooms.com/fr/courses/1959476-administrez-vos-bases-de- donnees-avec-mysql/1960763-creez-des-tables, consulté le 25/09/2019) 3.4.3.4 Prévention de l’injection SQL
Au cas où une requête SQL contient des données envoyées par l’utilisateur, nous préparons toujours cette requête avant de l’exécuter.
On peut bien lancer cette requête sans la préparer, mais c’est l'illustration parfaite de ce qu'il ne faut pas faire. En effet si les données envoyées par l’utilisateur sont dans une requête SQL, il y a un gros risque de faille de sécurité qu'on appelle injection SQL. Un visiteur pourrait s'amuser à insérer une requête SQL au milieu de notre requête et potentiellement lire tout le contenu de notre base de données, comme par exemple la liste des mots de passe des enseignants.
La solution donc que nous utilisons est la préparation des requêtes, afin d’adapter une requête en fonction d'une ou plusieurs variables. Ce qui permet d’indiquer au SGBD, qu’il faut considérer ces variables comme des données et non pas comme du code SQL même s’ils contiennent du code SQL par un utilisateur mal intentionné.
La figure 26 illustre un exemple de traitement de ce genre de cas.
45
Figure 26 3.4.3.5 Validation des données (Faille XSS)
Il y a une chose cruciale qu’il faut toujours prendre en considération lors de la rédaction du code source.
Il s’agit de la notion de validation des données que nous faisons en « Javascript », avant d’envoyer ces données au serveur. En effet, on doit refaire aussi cette validation en Node.JS coté serveur après la réception de ces données, car l’utilisateur peut toujours nous envoyer un formulaire à notre serveur, tel qu’il utilise une autre page HTML, dont il peut éliminer toutes les fonctions de validation
« Javascript » que nous créons (sur le formulaire d’inscription par exemple).
Si on reçoit donc ces données non validées en Node.JS, on ne doit pas les utiliser directement, car dans ce cas, il est fort probable qu’on reçoit des données erronées qui vont influencer négativement le fonctionnement de l’application par la suite.
Donc la validation doit toujours être faite coté serveur, pour des raisons de sécurité.
La figure 27 illustre un exemple de traitement de ce genre de cas.
46
Figure 27
3.4.3.6 Le fichier d’entré de l’application (wicall.js) et traitement des requêtes Comme dit plus haut, « wicall.js » est le fichier par lequel passe en premier toute requête Http envoyée au serveur, par conséquent, il sera important de le présenter ici, puisque c’est le fichier primordial, dont on peut voir toutes les requêtes (routes) possibles qui sont envoyées à l’application « Wicall », et surtout tous les fichiers utilisés par l’application, afin de traiter ces requêtes.
Le fichier compte plus de 300 lignes de code, par conséquent, les figures 28 à 33 présentent ici les parties les plus importantes du fichier, ainsi que quelques exemples de traitement des requêtes.
Importation des fichiers et démarrage de l’application
Figure 28
47
Fonctions utilisées directement par « wicall.js »
Figure 29
48
Création des événements « request » pour les routes
Figure 30
49
Requête pour demander l’exercice à faire
Figure 31
Requête pour enregistrer la réponse
Figure 32
Requête pour inscrire un enseignant
Figure 33 3.5 Déploiement et gestion du code
3.5.1 Heroku
50
La mise en production se déroulera sur les serveurs d'Heroku, une plateforme gratuite pour tester une application Web comme « Wicall », et l’héberger gratuitement tant qu’elle ne contient pas un très grand nombre de données.
"Lancé en 2007, Heroku est une PaaS (plateforme en tant que service) permettant de déployer des applications sur le Cloud. A la façon dont un hébergeur Web propose d’héberger un site sur ses propres serveurs, cette solution vous permet de déployer votre application sur le Cloud pour permettre aux internautes de l’utiliser.
Les applications sont exécutées dans des « dynos », à savoir des ordinateurs virtuels dont la puissance peut être ajustée en fonction de l’envergure de l’application. Ainsi, les « dynos » peuvent être comparés à des blocs de construction."
(https://www.lebigdata.fr/heroku-definition, consulté le 10.06.2019)
3.5.2 Installation et démarrage de l’application 3.5.2.1 Installation de l’application
Pour mettre l’application sur Heroku, on crée un compte Heroku, on installe localement la ligne de commande d’Heroku , et on se connecte à notre compte via cette ligne de commande, puis il faut surtout ajouter un fichier nommé « Procfile » (sans extension) à la racine de notre projet Node.JS, où on indique le nom du fichier représentant le point d’entrée de l’application « Wicall », afin que Heroku sache depuis quel fichier il va commencer l’interprétation du code pour permettre le démarrage de l’application.
Lorsque le fichier « Procfile » est ajouté au projet, il suffit de lancer la commande
« heroku create » pour créer une application Web liée à notre compte, puis la commande « git push heroku master », pour mettre l’application en ligne.
On peut trouver plus d’information de cette procédure d’installation depuis le lien suivant : https://devcenter.heroku.com/articles/getting-started-with-nodejs
3.5.2.2 Démarrage de l’application
Le démarrage commence par un appel de la méthode « server.getServerApp() », dans le fichier d’entrée « wicall.js ».
Lors du démarrage du serveur (l’appel de la méthode « getServerApp() »), nous appelons la fonction « setDatabase() » pour vérifier l’existence de la base de données, si ce n’est pas créé, nous créons cette base. La requête de création de la base de données est une constante mise dans un fichier séparé (« constants- app.js ») dans le dossier « config ».
La fonction « setDatabase() » vérifie aussi si un enseignant primaire existe dans la base de données, sinon, il est créé selon les informations indiquées dans le fichier de configuration « constants-system.js » dans le dossier « config », ensuite, un mail contenant les coordonnées de connexion de l’enseignant primaire, est envoyé vers sa boite mail, afin qu’il commence à utiliser l’application « Wicall », créer des exercices et inscrire des enseignants secondaires.
51
Donc avant de démarrer l’application « Wicall », il faut vérifier les informations dans le fichier de configuration « constants-system.js », pour voir si le fichier contient bien les informations qu’on souhaite. La figure 34 illustre bien un exemple du contenu de ce fichier.
Le fichier « constants-system.js »
Figure 34
52
On peut aussi vérifier le fichier de configuration « constants-app.js », qui lui, tel qu’il est illustré dans la figure 35, contient des constantes pour définir certains messages de boite de dialogue, en plus des constantes définies purement par le développeur.
Le fichier « constants-app.js »
Figure 35 3.5.3 Code source - GitLab UNIGE
Nous utilisons le serveur « Gitlab » de l’université de Genève pour le « versionning » et la récupération de l’application « Wicall ». Le code « Wicall » sur « GitLab » est
