3.4.1 Technologie de réalisation
Pour la réalisation du projet il est essentiellement utilisé des technologies basées sur le langage python adapté au Framework Django, dont l’Api Twilio.
3.4.1.1 Django
Django est un cadre de développement web source ouverte, en langage Python, qui s’articule complètement autour du modèle logiciel MVT (Model/View/Template) qui est une évolution du modèle logiciel MVC (Model/View/Controller, en français : modèle/vue/contrôleur) . Il a pour but de rendre le développement web 2.0 simple et rapide par ses capacités telles que la gestion automatique des comptes utilisateurs et des fonctionnalités d’administration de la base de données. Un système de validation des données entrées par l’utilisateur est également disponible et permet d’afficher des messages d’erreurs automatiques. Le Framework Django met aussi à la disposition des développeurs un serveur web léger [33] couplé à SQLite qui est une bibliothèque en langage C qui fournit une base de données légère sur disque qui ne nécessite pas de processus serveur distinct et permet d’accéder à la base de données à l’aide d’une variante non standard du langage de requête SQL à travers l’interface SQLite3 [36]. Ceci permettant de développer et tester l’application développée en temps réel sans déploiement.
3.4.1.2 API Twilio
API est l’acronyme d’Application Programming Interface, que l’on traduit en français par in-terface de programmation d’application. L’API peut être résumée à un ensemble de fonctions qui permettent à des applications de communiquer entre elles et de s’échanger mutuellement des services ou des données [35]. L’API Twilio est donc une API de service web de téléphonie qui permet de générer des applications vocales et de SMS.
Ainsi Twilio Voice permet aux applications de passer et de recevoir des appels téléphoniques [34], Twilio SMS leur permet de créer et de recevoir des SMS et Twilio Client permet aux ap-plications d’activer les communications vocales et SMS au moyen de connexions Internet exis-tantes. Cet API a été utilisé afin de rendre possible la connexion de la plate-forme au réseau GSM.
3.4.2 Présentation des outils de développement
3.4.2.1 Sublime text
L’éditeur de texte Sublime text version 3.1 2018 est un outil complet de développement pour la conception d’application web, de Web Services, d’applications desktop et mobiles. Les langages
comme python et HTML peuvent exploiter ce même éditeur, ce qui permet un partage d’outils et une simplicité de création de solutions basées sur plusieurs langages. L’éditeur de texte Su-blime text intègre à part entière le Framework Django, permettant ainsi d’accéder à toutes les technologies clés de ce Framework qui simplifient le développement des applications web.
3.4.2.2 Visuel paradigm
Visual Paradigm est en général un éditeur de diagrammes qui propose une suite logicielle com-posée de plusieurs outils. Pour la modélisation de la plate-forme de gestion centralisée, il est uniquement employé Visual Paradigm for UML dans sa version communautaire 15.2.
3.4.2.3 Google Maps
Google Maps est un service de cartographie en ligne, et donc nous a aidé à réaliser la répartition géographique des feux tricolores et la localisation du centre de gestion centralisée de notre système.
3.4.2.4 AutoCAD
AutoCAD ‘computer-aided design’ pour le CAD est un logiciel de disign professionnel qui aide à créer des images 2D et 3D. Ce logiciel nous a aidé à modéliser le plan du centre de gestion centralisée des feux tricolores.
3.4.3 Environnement de test
3.4.3.1 L’Editeur Arduino 1.0.5
L’éditeur d’Arduino est un logiciel open-source qui rend facile l’édition, la compilation et le transfert de code sur les cartes Arduino. C’est un logiciel multi-plateforme (Windows, Mac OS X, Linux) écrit principalement en Java. Il est utilisable avec tous les modèles de cartes Arduino.
3.4.3.2 La carte Arduino UNO R3 et le module GPRS/GSM SIM 900
Pour une expérimentation, la carte Arduino UNO se présente comme le meilleur choix pour débutant et convient parfaitement à tous ceux qui veulent faire leurs premiers pas avec un microcontrôleur. C’est la carte par excellence pour laquelle de nombreux exemples de montages sont disponibles sur Internet. Elle dispose d’un nombre suffisant de broches d’entrées-sorties pour des projets élémentaires et offre un vaste choix de modules complémentaires (shields) [22] tels que le module GPRS/GSM SIM 900 qui nous a permis d’interconnecter le montage du système de feu tricolore conçu,avec la plate-forme. Par contre, la mémoire disponible risque d’être un peu juste pour des gros projets et la carte n’offre pas beaucoup de périphériques embarqués. Le Tableau 3.2 présente les spécificités techniques de la carte.
TABLEAU3.2 – Spécifications techniques de la carte Arduino UNO
[22]
Microcontrôleur ATmega328P
Tension de service 5V
Tension d’entrée (recommandée) 7-12V
Tension d’entrée (limites) 6-20V
E/S numériques 14 (6 sorties commutables en MLI)
E/S analogiques 6
Courant continu par E/S 20 mA
Mémoire Flash 32 KB (ATmega328P) dont 0.5 KB utilisé pour le bootloader
CSRAM 2 KB (ATmega328P)
EEPROM 1 KB (ATmega328P)
Fréquence d’horloge 16 MHz
Dimensions 68.6 mm x 53.4 mm
Poids 25 g
4
Résultats et discussion
4.1 Présentation de notre plate-forme
4.1.1 Architecture du projet dans Sublime texte
Pour l’implémentation de la plate-forme de gestion centralisée des feux tricolores, nous avons utilisé l’éditeur Sublime Text pour développer l’application. L’architecture du projet Django déployée sous Sublime Text est illustrée à la figure 4.1.
FIGURE4.1 – Architecture du projet dans Sublim Text
Sous Django, un projet comporte, plusieurs applications, le fichier db.sqlite3 où sont stockés les données de la base de données et un fichier manage.py qui contient les outils du Framework Django. Cependant, pour notre étude une seule application a été développée dans le cadre de notre projet « trafic_routier » . Il s’agit de l’application «feuxtri_gestion_centralisée» . L’appli-cation « feuxtri_gestion_centralisée» , contient plusieurs dossiers et fichiers organisés suivant
de conception nous a permis de séparer les logiques de persistance de données (Model), les logiques de traitement de données (View) et les logiques de présentation de données aux utilisa-teurs finaux (Template ). Chaque dossier et fichier de l’application « feuxtri_gestion_centralisée»
rempli un rôle spécifique dans le fonctionnement de la plate-forme de gestion centralisée de notre système. Afin de conserver la simplicité du présent document nous nous sommes focali-sés sur quelques uns des composants du projet. Il s’agit entre autres des dossiers et fichiers :
3 admin.py 3 models.py 3 Setting.py 3 Views.py
3 Dossier Template 3 Dossier Migration
4.1.2 Dossier feuxtri_gestion_centralisée
4.1.2.1 Fichier admin.py
Le fichier admin.py contient les paramètres qui permettent à Framework Django de prendre en charge l’administration de la base de données. Un aperçu du contenu du fichier admin.py est présenté à la figure 4.2.
FIGURE4.2 – Extrait du fichier admin.py
4.1.2.2 Fichier models.py
Le fichier models.py contient les classes présentées dans chapitre 3 pour l’architecture de la base de données. Un aperçu du contenu du fichier models.py est présenté à la figure 4.3.
FIGURE4.3 – Extrait du fichier models.py
4.1.2.3 Fichier Setting.py
Le fichier Setting.py contient les paramètres qui assurent à la plate-forme développée un bon fonctionnement. Un aperçu du contenu du fichier Setting.py est présenté à la figure 4.4.
FIGURE4.4 – Extrait du fichier setting.py
4.1.2.4 Fichier Views.py
Le fichier Views.py contient les contrôleurs définis dans le projet. Les contrôleurs, comme défi-nit dans l’architecture MVT servent d’intermédiaire entre la couche de persistance de données (base de données) et les interfaces utilisateurs. Un aperçu du contenu du fichier Views.py est présenté à la figure 4.5.
FIGURE4.5 – Extrait du fichier views.py
4.1.2.5 Dossier Templates
Le dossier Templates contient des sous-dossiers dans lesquels sont les fichiers dont sont res-ponsables les contrôleurs définis dans le fichier Views.py et qui présentent l’ensemble des vues ou interfaces utilisateurs que ce contrôleur gère. Chaque template est défini par un fichier au format "*.html". Le contenu du dossier Templates est présenté à la figure 4.6.
FIGURE4.6 – Contenu du dossier Templates
4.1.2.6 Dossier Migrations
Le dossier Migrations a pour rôle principal de contenir les versions de migration de la base de données liée au projet. Les migrations sont la manière par laquelle Django propage des modifications qui sont apportées à des modèles (ajout d’un champ, suppression d’un modèle, etc.) dans la base de données. Elles sont conçues pour être quasiment automatiques. Un aperçu de ce dossier est donné par la figure 4.7.
FIGURE4.7 – Contenu du dossier Migrations
4.1.3 Présentation des Interfaces
Afin de mieux exploiter les fonctionnalités de la plate-forme de gestion centralisée de ce sys-tème, les utilisateurs peuvent interagir avec différentes interfaces offrant les différents services de commandes des feux tricolores. Dans cette section, nous présentons les interfaces et les fonc-tionnalités essentielles de notre plate-forme.
4.1.3.1 Page d’authentification
La page d’authentification permet aux utilisateurs de s’authentifier afin d’avoir accès aux
fonc-cessite que l’utilisateur entre un pseudonyme et un mot de passe. Cela est illustré dans la figure 4.8.
FIGURE4.8 – Contenu du dossier Migrations
4.1.3.2 Page d’accueil
La deuxième interface qui accueille un utilisateur après identification sur la plate-forme de gestion centralisée de notre système est la "Page d’accueil ". Comme illustrée sur la figure 4.9 ci-dessous, cette page fournit l’accès aux différentes rubriques de la plate-forme à savoir : la rubrique de contrôle des états des feux tricolores par la sélection d’une zone de regroupement de feux ( un quartier) et la rubrique de commande des feux par la sélection d’un feu tricolore spécifique.
FIGURE4.9 – Page d’accueil de la plate-forme de gestion centralisée des feux tricolores
4.1.3.3 Rubrique de contrôle des état des feux tricolores
L’une des interfaces auquelle donne accès la page d’accueil est la rubrique de contrôle des états des feux qui donne les états des lampes de tous les feux tricolores dans une zone donnée en vue de permettre de prompte intervention de maintenance en cas de besoins . La figure 4.10 ci-dessous illustre cette rubrique.
FIGURE4.10 – Page de contrôle des états des feux tricolores
4.1.3.4 Rubrique de commande des feux tricolores de la plate-forme
Une autre interface auquel donne accès la page d’accueil, est la rubrique de commande des feux. Cette rubrique offre la possibilité en premier lieu, à ce carrefour de connaître l’état des feux tricolores et de visualisé l’effet de leur programmation, mais en second lieu, de pouvoir les commander. Cela peut être soit le passage au vert d’un feu tricolore du carrefour ou du changement de sa programmation. Cette rubrique est illustrée à la figure 4.11.
FIGURE4.11 – Page de commande des états des feux tricolores de la plate-forme
4.1.3.5 Rubrique d’administration
La rubrique d’administration quand à elle, permet à l’administrateur de pouvoir gérer toutes les activités menées sur la plate-forme, à travers des ajouts, des modifications et des suppressions de carrefours, de feux tricolores, de programmations et d’utilisateurs. Mais encore la gestion de l’API Twilio, responsable de l’envoie des commandes par les messages (SMS) à travers le réseau GSM. La figure 4.12 suivante illustre cette rubrique.
FIGURE4.12 – Page d’administration de la plate-forme
4.1.4 Expérimentation
4.1.4.1 Schéma du montage
La Figure 4.13, réalisée avec le logiciel Proteus, présente le schéma du montage de feux tri-colores réalisé dans le cadre de l’expérimentation de notre système. Pour cette expérimentation, les difficultés,tel l’instabilité et les coupures du courant venu de la SBEE et la défaillance de cer-tain de nos relais dû à ces difficultés précédemment citées, nous ont amené à utilisé le courant de tension 12V en utilisant un convertisseur chargeur. Les composants utilisés pour la réalisa-tion sont listés dans le Tableau 4.1.
TABLEAU4.1 – Liste des composants
Composant Quantité
Arduino Uno 1
Module Shield SIM 900 1
Lampes 12V 1W 12
Résistances 12
Phototransistor 3 Modules relais 12
Régistre 4
Convertisseur chargeur 1
FIGURE4.13–SchémadumontageréaliséavecProteus
4.1.5 Sécurité de la plateforme
L’une des questions importantes qui mérite d’être abordée dans tout projet de conception d’ap-plication de base de donnée est celle de la sécurité. Ainsi, afin d’assurer la sécurité globale de la plateforme de gestion centralisée des feux tricolores, trois points essentiels ont été étudiés. Ces points sont les suivants :
3 la sécurité des données ;
3 la sécurité au niveau de l’application ;
3 et la sécurité du réseau d’accès au serveur d’application ;
Voyons en quoi les points énumérés ci-dessus sont importants pour garantir la sécurité et l’in-tégrité des données sur la plateforme.
4.1.5.1 Sécurité des données
Les données sauvegardées et traitées, pour les projets d’applications, sont des ressources sen-sibles dont l’intégrité et la disponibilité doivent être garanties à tout prix. Sur la plateforme de gestion centralisée des feux tricolores, la sécurité des données utilisées peut être menacée de deux façons à savoir :
3 par accès au Système de Gestion de Base de Donnée SQLite ;
3 et par la perte de données due au dysfonctionnement des disques de stockage ;
En ce qui concerne le risque d’accès au Système de Gestion de Base de Donnée SQLite, une multitude de méthodes d’attaque existe. Cependant , le Framework Django offre une protection intégrée contre la majorité des attaques visqnt la base de donnée tel que [39] :
æ le « Cross site scripting » (XSS) : qui consiste à un intrus d’injecter des scripts clients dans les navigateurs des utilisateurs ;
æ le « Cross site request forgery » (CSRF) : qui consiste à une personne malveillante d’exé-cuter des actions en utilisant les données d’authentification d’un autre utilisateur sans que ce dernier s’en rende compte.Il peut en résulter des modifications et des suppressions d’enregistrements ;
æ l’injection SQL :qui consiste à ce qu’un utilisateur malveillant soit capable d’exécuter du code SQL arbitraire sur une base de données ;
æ le détournement de clic (« clickjacking ») : qui consiste à ce qu’un site malveillant intègre un autre site dans un cadre. Cette attaque peut amener un utilisateur à cliquer de manière non désirée pour effectuer des actions non volontaires sur le site ciblé ;
Outre les risques d’accès au SGBD SQL Server, il y a également le risque de perte de données suite à un dysfonctionnement des disques de stockage du serveur qui héberge notre base de données. Ce type de risque peut être très couteux et fatal si les informations stockées sont vo-lumineuses. Ainsi, afin de limiter le risque de perte de données, nous préconisons les systèmes de stockages RAID(Redundant Array of Independent Disks) dans sa version RAID 2 [38]. Cette technologie permet de répartir les données sur plusieurs disques durs afin d’améliorer la sécu-rité et la tolérance aux pannes que peut subir l’ensemble du système de stockage de données.
4.1.5.2 Sécurité de l’application
D’autres sources de menaces peuvent également provenir des interfaces utilisateur de la plate-forme. Parmi les risques de sécurité liés aux utilisateurs, nous avons énuméré :
3 les risques liés aux privilèges accordés aux utilisateurs ;
3 les risques liés aux sources externes des données que traite la plate-forme ;
Les privilèges accordés aux utilisateurs est l’un des facteurs de sécurité les plus difficiles à maitriser et peuvent devenir une véritable source de menaces quand par exemple un compte d’utilisateur est mal utilisé ou a été volé. Pour palier un tant soit peu ce risque, nous avons usé du principe du moindre privilège qui consiste à allouer le moins de privilèges que possible aux utilisateurs courants.Ainsi, pour accéder aux fonctionnalités avancées de la plate-forme, une authentification est requise. Sur notre plate-forme, nous avons deux niveaux de profil d’utilisa-teur qui sont le profil Utilisad’utilisa-teur et le profil Administrad’utilisa-teur.
La seconde source de menace est liée aux sources externes des données que traite la plate-forme qui sont multiples du fait de la communication entre la plateplate-forme et les équipements de contrôle des feux tricolores à travers le réseau GSM. Pour palier un temps soit peu ce risque aussi, le choix s’est tourné dans un premier temps vers un système qui muni chaque équipe-ment de contrôle des feux tricolores d’un numéro de téléphone de réseau GSM unique et dans un second temps, au niveau de l’application web, vers le rejet de toute information provenant de numéro n’existant pas dans la base de données de cette application.
4.1.5.3 Sécurité du réseau
Pour assurer la sécurité du réseau LAN dans lequel notre application sera déployée, nous comptons mettre en place un Reverse-Proxy qui constituera un pont entre les réseaux externes comme Internet et notre LAN. Cette mesure permet en effet d’amoindrir les attaques provenant de réseaux externes denses et incontrôlables comme Internet.