Université de la Réunion

UFR Sciences et Technologies

Rapport de stage de Master M2 INFORMATIQUE

SYDNE

Mise en place d’un outil informatique de gestion des

données du SYDNE relatives au traitement des
déchets

Auteur :
Encadrants :
Farda HOUMADI
Maxime LECLERCQ
no étudiant : 33002162

Responsable de stage UFR Sciences et Technologies :

Pr. Frederic MESNARD

Période du stage : Du 02 janvier 2018 au 29 juin 2018

La patience est une lumière !

Moslim
Remerciements
J’adresse mes sincères remerciements à toutes les personnes qui ont contribué à la réa-
lisation de mon stage.

En premier lieu, j’exprime ma profonde gratitude à mon tuteur de stage M. Maxime

LECLERQ, Chef de projet équipements de traitement des déchets, avec qui j’ai bénéficié
d’un soutien de qualité, de sa disponibilité et de son temps pour le bon déroulement du
stage. Mais aussi, de ses précieux conseils et de son énergie déployée pour ma réussite.

Ensuite, M. Yoland SAVRIMOUTOU, Directeur Général des Services, qui m’a fait confiance
tout au long de ce stage. J’exprime mes remerciements à M. Joël FONTAINE Contrôleur
d’exploitation, avec qui j’effectué l’ensemble des visites des infrastructures du SYDNE.
Je remercie également tous les membres du SYDNE, qui m’ont accueilli chaleureusement
pendant la période du stage et qui ont pris du temps pour répondre à mes questions malgré
leurs plannings chargés.

Je tiens à remercier tous les partenaires qui sont intervenus pour m’aiguiller, me conseiller
dans la partie technique du stage.

Je remercie également toute l’équipe pédagogique de sciences et technologiques pour son

accompagnement.

Et enfin, ma famille qui m’a soutenu et encouragé tout au long de ma formation.

H.F

3
4
Résumé
C’est au sein de l’organisme SYDNE (Syndicat intercommunal de traitement des dé-
chets du Nord et de l’Est de la Réunion), que j’ai effectué mon stage de fin d’études de
Master Informatique. Le SYDNE est une collectivité récente, qui a la compétence de la
gestion de traitement et de valorisation des déchets ménagers et assimilés dans le Nord
et Est de La Réunion. L’organisme a pour projet de structurer ses données internes et de
mettre en place un outil informatique pour les exploiter.

L’objectif de mon stage consistait donc à concevoir une base de données et à développer
un outil informatique d’analyse, de suivi et de reporting de données. Pour cela, plusieurs
étapes étaient nécessaires comme l’analyse de l’existant, la modélisation de la base de
données ou encore le développement de l’outil selon les besoins définis par les agents. Ce
rapport ne présente qu’une première version de l’outil.

Mots-clés
: base de données, analyse des données, déchets ménagers et assimilés, SQL, Python

Abstract
It is within the organization SYDNE, that I did my internship end of studies of Mas-
ter’s degree in Computer Science. The SYDNE is a young community, which has the skill
of the management of treatment and recovery of household and similar waste in the North
and East of Reunion Island. The organization plans to structure its internal data and put
in place a computer tool to exploit them.

The objective of my internship was to design a database and develop a computer tool
for analysis, monitoring and reporting of data. For this, several steps were needed such as
the analysis of the existing, the modeling of the database or the development of the tool
according to the needs defined by the agents. This report presents only a first version of
the tool.

Keywords
: database, data analysis, household and similar waste, SQL, Python

5
6
Table des matières

1 Contexte 3
1.1 Structure d’accueil : le SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation du SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Compétences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Compétence DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Absence de maîtrise de gestion de BD . . . . . . . . . . . . . . . . . 4
1.3.2 Objectif du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Outils et organisations 6
2.1 Déroulé de la commande du SYDNE . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Moyen pour y répondre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Méthode gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Cycle de vie d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Démarche suivie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Analyse préalable 10
3.1 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Étude des outils existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Outils commerciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Outils relatifs au déchets . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Mise en œuvre des outils 15

4.1 Choix du système de gestion de base de données (SGBD) . . . . . . . . . . 15
4.1.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3 Microsoft Acces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4 Choix et justification . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
 4.2.1 Présentation des technologies web . . . . . . . . . . . . . . . . . . . 17
4.2.2 Framework utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Outils complémentaires . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Développement de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1 Configuration minimale requise . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.3 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.4 Architecture Matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Modélisation du système et de la base de données . . . . . . . . . . . . . . . 23
4.4.1 Représentation du système . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.2 Modélisation avec SQL Power Architect . . . . . . . . . . . . . . . . 27
4.4.3 Base de données : version 1 . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.4 Base de données : version 2 . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.5 Administration de la base avec PostgreSQL . . . . . . . . . . . . . . 33

5 Résultats 34
5.1 Déroulement du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1 Constat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Outil final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.1 Interface de connexion utilisateur . . . . . . . . . . . . . . . . . . . . 36
5.3.2 Interface de saisie utilisateur . . . . . . . . . . . . . . . . . . . . . . 37
5.3.3 Interface administrateur : importation des données . . . . . . . . . . 37
5.4 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Bibliographie 41

Annexes 44
A Le SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1 Organisation institutionnelle : le comité syndical . . . . . . . . . . . 44
A.2 Territoire du SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.3 Bilan annuel des quantités des déchets . . . . . . . . . . . . . . . . . 46
B Documents réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.1 Présentation des objectifs du stage aux agents . . . . . . . . . . . . . 48
B.2 Recueil des besoins : questionnaire . . . . . . . . . . . . . . . . . . . 50
B.3 Note d’avancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.4 Présentation des solutions techniques . . . . . . . . . . . . . . . . . . 57
C Visite des installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.1 Déchet entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.2 Déchet sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
D Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
D.1 Turoriel Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.2 Personnalisation de l’interface administrateur . . . . . . . . . . . . . 65
 D.3 Script sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
E MOOC (massive open online course) . . . . . . . . . . . . . . . . . . . . . . 68
Table des figures

1.1 Organigramme du SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Exemple cycle de vie d’un projet : démarche en V . . . . . . . . . . . . . . . 7

2.2 Planning prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Modèle vue contrôleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Ecosystème d’un projet Django . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Diagramme de cas d’utilisation du système . . . . . . . . . . . . . . . . . . 25
4.7 Modélisation : ajout d’une colonne . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Définition des règles entre deux tables . . . . . . . . . . . . . . . . . . . . . 28
4.9 Connexion BD PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10 Génération script SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11 Modélisation logique BD : version 1 . . . . . . . . . . . . . . . . . . . . . . 30
4.12 Modélisation logique BD : version 2 . . . . . . . . . . . . . . . . . . . . . . 32
4.13 Exemple de requête dans pgAdmin . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Diagramme de Gantt : déroulé réel du stage . . . . . . . . . . . . . . . . . . 35

5.2 Page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Interface de saisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Interface administrateur : importation . . . . . . . . . . . . . . . . . . . . . 38
5.5 Interface administrateur : adminconfirmation . . . . . . . . . . . . . . . . . 38
6 Membre du comité syndical . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7 Carte du territoire SYDNE . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8 Quantités des déchets : année 2016 . . . . . . . . . . . . . . . . . . . . . . . 46
9 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10 Déchet issus de la collecte sélective . . . . . . . . . . . . . . . . . . . . . . . 60
11 Déchet vert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12 Compost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13 Balle de déchet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14 Script SQL : BD version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10
Liste des tableaux

3.1 Tableau comparatif solution commercial . . . . . . . . . . . . . . . . . . . . 11

3.2 Expression des besoins en fonction des agents . . . . . . . . . . . . . . . . . 13

4.1 Configuration minimale requise du serveur . . . . . . . . . . . . . . . . . . . 20

4.2 Configuration minimale requise pour l’utilisateur . . . . . . . . . . . . . . . 21
4.3 Règle de gestion du système . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

11
Introduction

Au cours de ces dernières années, la problématique autour des déchets a fait la une
de l’actualité de plus en plus régulièrement. En effet, l’organisation liée à la gestion des
déchets a fortement progressé sur le territoire français, en matière de maîtrise des coûts,
d’amélioration de la qualité et des quantité de déchets triés, de la valorisation organique
et matière.
Ces différentes évolutions entraînent nécessairement la production d’une masse importante
de données. De plus, les organisations produisent, collectent quotidiennement des données.
Savoir les organiser, les structurer puis les valoriser, mais aussi les exploiter et les analy-
ser constitue un réel défi pour elles. C’est pourquoi, il est essentiel de disposer des outils
informatiques adaptés pour répondre à ce besoin grandissant.

Dans le cadre du cursus de Master 2 Informatique à l’Université de la Réunion, j’ai

effectuée un stage de fin d’études d’une durée de 6 mois au sein de l’une de ces structures.
L’objet du stage est de mettre en pratique les connaissances théoriques et pratiques ac-
quises durant la formation.

Le stage a été réalisé au sein de l’organisme du Syndicat intercommunal de traitement

des Déchets du Nord et de l’Est de la Réunion (SYDNE). Le SYDNE possède la compé-
tence de traitement et de valorisation des déchets ménagers et assimilés sur le territoire
Nord et Est de La Réunion.
Centré sur la base de données, l’analyse des données, la prédiction et le développement,
j’ai choisi d’effectuer mon stage au sein cet organisme, car le cœur du sujet est l’une des
filières en informatique en forte croissance.
Mon maître de stage étant M. Maxime LECLERCQ, chef de projet équipements de traite-
ment des déchets, j’ai pu mettre en pratique mes connaissances dans d’excellentes condi-
tions ; j’ai également bénéficié d’un soutien de qualité.

Le stage consistait à mettre en place une base de données et un outil informatique

pour exploiter pleinement ces données. Pour cela, plusieurs tâches m’ont été confiées. On
peut citer la mise en place d’une méthode de gestion de projet ou encore le diagnostic du
mode de gestion actuel des données.
Au-delà de vouloir enrichir mes connaissances dans le domaine de l’informatique, ce stage
m’a permis de comprendre les enjeux liés à la gestion des déchets.

1
 Le présent document est organisé comme suit. Dans un premier temps, j’y présente le
contexte du stage suivi de la présentation de la structure d’accueil et des objectifs attendu.
Ensuite, outils et organisations dans laquelle, j’explicite les besoins du SYDNE ainsi que
les moyens mis à ma disposition pour y répondre. J’évoque également dans cette partie la
méthode de gestion de projet mise en place avec mon tuteur de stage. Et enfin, avant de
conclure, je présente les résultats obtenus du projet et les difficultés rencontrées.

2
Chapitre 1

Contexte

1.1 Structure d’accueil : le SYDNE

1.1.1 Présentation du SYDNE

SYDNE

Autrefois gérée par la CINOR et la CIREST, la compétence de traitement et de valorisa-

tion des déchets ménagers et assimilés, est aujourd’hui exercée par le SYDNE (Syndicat
intercommunal de traitement des déchets du Nord et de l’Est de la Réunion).
Le SYDNE est une jeune collectivité créée en janvier 2015 par les deux EPCI (établis-
sement public de coopération intercommunale), dans l’objectif de mutualiser les moyens
actuels et équipements de traitement de déchets qui restent à développer.
Il exerce cette compétence sur neuf communes (Saint-Denis, Sainte-Marie, Sainte-Suzanne,
Saint-André, Salazie, Bras-Panon, Saint-Benoît, La Plaine des Palmistes, Sainte-Rose),
soit environ une population de 325 000 habitants (source INSEE 2016 ; population légale
en janvier 2013).

1.1.2 Compétences
Ayant transféré la compétence de traitement des déchets ménagers et assimilés, les
deux EPCI, ont conservé la charge des différents modes de collecte dont la gestion des
déchetteries. Ainsi la compétence du SYDNE comprend :
• Le tri des déchets recyclables issus des collectes sélectives ;
• La valorisation matière des déchets recyclables ;
• La valorisation organique des déchets verts ;
• La valorisation énergétique ;
• L’élimination par enfouissement des ordures ménagères et des refus de tri.
Le SYDNE traite les déchets ménagers et assimilés soit, les déchets recyclables, les ordures
ménagères résiduelles, les encombrants, les déchets verts collectés en porte à porte qu’en
déchetterie.

3
1.1.3 Organisation
La structure du SYDNE repose sur deux organisations. Une organisation institution-
nelle (comité syndical), qui définit la politique du syndicat, vote le budget, décide des
investissements et de modalités de gestion du service. Il est composé de délégués désignés
par les assemblées délibérantes de chacun des adhérents du syndicat.

Et une organisation administrative qui exécute les décisions du comité syndical. Son
effectif est de dix membres.

Figure 1.1 – Organigramme du SYDNE

1.2 Problématique
L’objectif du SYDNE, dans les années à venir, est d’assurer une continuité du service
public du traitement des DMA, en intégrants les futurs projet, dans des conditions tech-
niques financières et environnementales maîtrisées.
L’architecture SI actuelle du SYDNE, n’intègre pas un système de gestion de base de don-
nées. Les données stockées et archivées dans le serveur de fichier, ne leur permettent pas
d’effectuer des analyses dans l’optique d’optimiser les activités de traitement des déchets.

1.3 Compétence DMA

1.3.1 Absence de maîtrise de gestion de BD
L’un des enjeux majeurs pour le SYDNE est de capitaliser de manière opportune
l’information acquise à travers ses activités (tonnages traités, données financières. . .). C’est
actuellement une des lacunes du syndicat, puisque les données acquises sont archivées de
manière non standardisée, isolée et non concertée. Par exemple, le pôle technique tendra
à archiver des données quantitatives (tonnages de déchets) alors que le pôle administratif

4
tendra à archiver des données financières (factures des prestataires). Il conviendrait de
regrouper ces informations dans un outil informatique commun, mutualisé et standardisé.
Cela implique un savoir-faire et des compétences informatiques, qui ne sont actuellement
pas présentes en interne.

1.3.2 Objectif du stage

Le projet consiste donc à structurer les données du syndicat en mettant en œuvre
une base de données et développer un outil informatique de capitalisation et d’analyse de
données relatives aux déchets.
En outre, l’objectif global du stage est d’effectuer des analyses statistiques et de calibrer
les données à partager avec les différents acteurs tels que les partenaires, les organismes
et le grand public.
Afin d’atteindre cet objectif, la contribution des spécifications suivantes sont nécessaires :
• Faire l’inventaire des données ;
• Structurer les données ;
• Créer la base de données ;
• Mettre en place un protocole de standardisation des données ;
• Alimenter la base de données avec les données existantes ;
• Développer l’interface graphique afin de faciliter l’extraction, l’analyse des données.

5
Chapitre 2

Outils et organisations

2.1 Déroulé de la commande du SYDNE

Le déroulé de la commande du SYDNE est comme suit :

En premier lieu, découvrir le métier de l’activité du syndicat, le métier des agents, les
sites d’exploitation, la terminologie et les caractéristiques des activités relatives au traite-
ment des déchets. Il s’agit ici de comprendre les concepts principaux liés aux déchets pour
la mise en place de la base de données et le développement de l’outil.

En deuxième lieu, identifier et diagnostiquer le mode de gestion actuel des données et

les besoins de la structure et des agents. L’objectif de cette étape est de recueillir les
besoins des agents de manière exhaustive pour le développement de l’outil et d’effectuer
l’état des lieux des données que possède SYDNE pour la création et l’alimentation de la
base de données.

Ensuite, effectuer l’état de l’art des outils existant de capitalisation de données relatives
au traitement de déchets au niveau local, régional, national. L’activité consiste à contac-
ter, rencontrer des acteurs et expérimentés pour échanger sur le fonctionnement de leur
structure, sur le processus suivie pour la centralisation des données, sur la structuration
et de la nomenclature de la base des données et des technologies utilisées.

Puis, concevoir et mettre en place une base de données. Le choix des technologies, la
standardisation des fichiers, la collecte des données ainsi que la conception et l’architec-
ture de la base de données sont au cœur de cette tâche.

Et enfin, développer et déployer l’outil afin de réponde aux besoins des agents. Mais éga-
lement, faire une demande de subvention auprès des organismes pour le développement de
l’outil.

6
2.2 Moyen pour y répondre
Le projet requiert les moyens matériels suivants :

— un ordinateur muni d’un système d’exploitation, une base de données et un serveur

d’application afin de permettre aux utilisateurs d’effectuer les opérations basiques
telles que : la suppression, la consultation, la modification et l’enregistrement
— un poste de téléphone fixe et une boîte mail, afin d’échanger avec les partenaires
potentiels

2.3 Méthode gestion de projet

2.3.1 Cycle de vie d’un projet
La production d’un produit informatique (logiciels, système information. . .) passe par
différentes étapes. Ces étapes constituent un processus de développement qui met en évi-
dence l’analyse de besoin, la conception et la validation. Certaines de ces étapes peuvent
déclencher le retour sur les étapes précédentes. Toutes ces phases définissent le cycle de
vie. Celui-ci spécifie les étapes de développement du produit de sa conception jusqu’à sa
disparition.

Figure 2.1 – Exemple cycle de vie d’un projet : démarche en V

7
2.3.2 Démarche suivie
Dans cette démarche de méthodologie, nous avons mis en place un planning prévision-
nel au début du stage.

Puis, nous avons suivi le modèle d’organisation interne pour la validation des étapes du
projet. Cette méthode consiste à la rédaction d’une note d’avancement (en annexe), qui
est soumis dans un premier temps au tuteur de stage puis au directeur général des services
afin de valider ou non l’étape et les solutions proposées.

8
9
Figure 2.2 – Planning prévisionnel
Chapitre 3

Analyse préalable

3.1 Diagnostic
La structuration des données dans le serveur interne, est organisée de la manière sui-
vante : les données sont stockées dans le serveur de fichiers, et plus précisément dans le
disque PROD. Ces données sont rangées en arborescence et classées par type de service.
Toutes les informations dans ce disque sont accessibles à tous les agents sauf quelques
dossiers confidentiels.
La problématique relevé dans ce modèle est la duplication des fichiers et le même fichier
peut exister sous différents noms. Un autre point très important est la sécurisation des
fichiers. Le fait est que chaque agent a accès aux fichiers et ces fichiers ne sont pas sécurisés
en écriture.
Pour compléter ce diagnostic, je constate que l’historique de la majorité des données date
d’environ un ans. Les données manipulées sont majoritairement sous le format excel, pdf
et word. Pour le pôle technique, les données sont collectées mensuellement auprès des
prestataires. Les données reçues peuvent être brutes et/ou agrégées. Au niveau du pôle
finance, les factures contenant les éléments essentiels au DMA sont transmises et reçues
mensuellement.

3.2 Étude des outils existants

L’étape d’étude de l’existant consistait à identifier les outils de capitalisation de don-
nées relatives au traitement de déchets au niveau local, régional, national.

3.2.1 Outils commerciaux

L’acquisition des outils commerciaux nécessite une étude approfondie de chaque solu-
tion. En effet, ce type d’outil est souvent très coûteux, ce qui crée le frein pour de nom-
breux organismes ayant des ressources financières limités. Ici, nous comparons brièvement
quelques solutions commerciales parmi tant d’autre.

10
 Previsoft Tennaxia / Everhse Caktus
Type Logiciel Logiciel Logiciel
Démo Sur demande Sur demande Sur demande
Accès à la consultation des
Simple et ergonomique Intégration des données historiques
données aux prestataires,
Avantage Vue personnalisé Comparaison sur plusieurs années
publics sur une période :
Service d’intégration Intégration de la réglementation
collecte, valorisation, facture
Design de l’interface terne
Inconvénients
de la version actuelle
Traçabilité des déchets
Suivi statistique
Respect de la réglementation
Réduction des coûts
Objectif Maîtrise des coûts Gestion des déchets
Répondre aux différents
Production de déclaration et
11

exigences réglementaires
document administratif
Plateforme Desktop et web web Desktop et web
Enregistrements des données :
Ajout et description des déchets déchets, prestataire...
Suivi des tonnages
Quelques Déclaration annuel des rejets Edition du registre des déchets et
Statistique reporting
fonctionnalités Suivi des coûts déclarations
Registre, BSD
Analyse Gestion des coûts
Analyse
Table 3.1 – Tableau comparatif solution commercial

11
3.2.2 Outils relatifs au déchets
PEIGEO
Au niveau local, l’observatoire réunionnais des déchets (ORD) crée par l’AGORAH (agence
urbanisme de La Réunion) en 2014, a développé un outil, PEIGEO (Plateforme d’Echange
de l’Information GEOgraphique) pour valoriser les données géographiques de la Réunion.
Cet outil a pour vocation d’informer, de partager, de mutualiser, de coordonner et diffu-
ser l’information géographique de la Réunion. L’outil permet de géolocaliser et visualiser
quelques installations relatives au traitement des déchets et d’autres informations liées à
l’urbanisme de la Réunion.

Outil de l’ORDIF
Au niveau régional, j’ai opté pour l’ORDIF (observatoire régional des déchets en Île-de-
France) pour son expérience de plus de 20 ans dans le domaine.
L’ORDIF possède un outil d’analyse et de suivi. À partir de cet outil, on peut réaliser des
bilans, des synthèses, documents rédigés, graphiques et cartographiques.

SINOE
Au niveau national, SINOE mis en place par l’ADEME (Agence de l’environnement et
de la maîtrise de l’énergie), est un outil d’analyse principalement destiné aux collectivités
territoriales en charge de la gestion des DMA. Il a pour but d’optimiser la politique de
gestion des déchets et également à améliorer le service notamment pour la maîtrise des
coûts.
Les opérations que nous pouvons effectuer sur SINOE sont nombreuses. Et parmi elles, la
visualisation du bilan annuel et de l’historique des flux, le partage des données entre les
collectivités, l’affichage des informations administratives et techniques sur les installations.
Il présente aussi un outil d’aide à la décision pour les analyses, indicateurs, les coûts, les
cartes et graphiques.

3.3 Expression des besoins

Afin de recueillir les besoins de chaque agent du SYDNE, j’ai choisi de les interviewers
individuellement en mettant en place un questionnaire commun, puisque le personnel n’est
pas nombreux. Les besoins formulés sont les suivantes :

12
 Besoins Nombre d’occurence
Projection, visant à estimer les gisements de déchets à court terme
(au mois suivant par exemple), mais également à moyen et 4
long terme (10 - 20 - 30 ans par exemple)
Une interface de saisie rapide et ergonomique des données 4
Tableau de suivi des marchés publics en cours 4
Analyse des données, pour permettre par exemple la production
d’analyses statistiques, de tableaux de bord, d’indicateurs, 3
de ratios (tonnes/habitants, e/tonnes, etc.)
Edition du rapport annuel d’activité du SYDNE 3
Suivi de l’évolution budgétaire avec projection et rétrospective,
3
des factures et rapport mensuel des prestataires
Fiche d’information et historique des événements par site 3
Alerte en cas de dépassement du seuil minimum fixé pour les
3
sites par exemple
Suivi recette éco-organisme 2
Suive facture par marché 2
Transportable sur SIG 2
Suivi des demandes des usagers (appel numéros vert,
2
courrier, contact via site web)
Opération basique et avancée sur les données : écart-variation,
2
somme,. . .
L’archivage sécurisé de la données 2
Automatisation des tâches financières : calcul révision
1
des prix, . . .
Comparaison prix unitaire de l’ancien marché avec le
1
nouveau marché
Référencement par mot-clé des rapports comité syndicaux 1
Evolutif, pour permettre de s’adapter aux nouveau besoins du SYDNE 1
Table 3.2 – Expression des besoins en fonction des agents

13
3.4 Problématique
Nous allons nous fixer sur les problématiques suivantes :
— Le choix sur le logiciel de modélisation de la base de données et le système de gestion
de base de données
— Le choix du langage de programmation et les outils de développement

3.5 Analyse de l’existant

Les agents s’appuient sur les fichiers excel transmises par les prestataires et des feuilles
de calcul pour contrôler, traiter et analyser les données. Effectuer les opérations basiques
telles que la recherche, la modification, la suppression, l’affichage ou encore la comparaison
des données ou documents des années antérieures, s’avère long et fastidieux car les tableaux
dynamiques croisés ou encore les macros dans excel sont les seuls outils dont les agents
disposent. De plus, il n’y a aucun système de gestion de bases de données mise en place.
Nous pouvons souligner également le manque de sécurisation de la données, des fichiers
en écriture dans le serveur de fichier. En effet, tous agents ont accès à toutes les donnée
sauf certains dossier confidentiels.

3.6 Solution proposée

La solution serait de centraliser toutes les données dans une base de données et de
créer un outil pour visualiser de manière générale les données importantes.
Cette solution laisse la possibilité aux futurs utilisateurs de modifier et d’interagir avec
les différents indicateurs (sélection ou dé-sélection d’un élément dans la légende d’un gra-
phique, choisir le pas de temps, filtrage. . .) dans le but d’afficher dynamiquement les
informations en fonction de leur besoin.
De plus l’avantage de la mise en place d’un système de gestion de base de données est
l’accélération dans le processus d’analyse et d’aide à la décision.

L’accès de la base de données en fonction des rôles de chaque agent semble la méthode
la plus pertinente puisque les objectifs finaux de chaque agent diffèrent.
Le niveau de sécurité sera élevé car les données seront affichées en fonction des permissions
de chacun.

14
Chapitre 4

Mise en œuvre des outils

4.1 Choix du système de gestion de base de données (SGBD)

Avant de pouvoir choisir un système de gestion de base de données, la comparaison
entre les différentes solutions est indispensable.

4.1.1 MySQL

MySQL

MySQL est un système de gestion de base de données relationnelle éditée par Oracle
corporation.

C’est l’une des SGBD le plus utilisée. Il est distribué sous deux licences, que sont GPL
(publique) et propriétaire. MySQL possède de nombreuses avantages comme par exemple :
— intégration parfaite dans l’environnement Apache (serveur web) et PHP (langage
programmation coté serveur) ;
— open source et multiplateforme ;
— déploiement facilité.

Mais également, dispose des inconvénients tels que :

— peu de richesse fonctionnelle ;
— le manque de robustesse pour les grosses bases de données ;
— il ne supporte pas l’héritage des tables.

4.1.2 PostgreSQL

PostgreSQL

15
C’est un SGBD créé par la société PostgreSQL. Il est open source, gratuit et multiplate-
forme.

Il est le plus complet des SGBD gratuits.

Ses avantages, sont :
— la fiabilité et la performance ;
— la majorité du standard SQL-92 est supportée ;
— la richesse fonctionnelle et la possession d’une multitude de modules ;
— l’héritage des tables est supporté ;
— simple à administrer ;
— son extension PostGIS est en relation avec QGIS.

Cependant, PostgreSQL a aussi certains inconvénients :

— il n’offre pas de services web ;
— les solutions de réplication ne sont pas encore totalement packagées ;
— il est efficace avec des bases de taille moyenne voire plus.

4.1.3 Microsoft Acces

Acces

Microsoft Access est une application de gestion base de données relationnelle édité par
Microsoft. Cependant, il est propriétaire et payant.

Parmi les avantages de Microsoft Access citons :

— une interface graphique intuitive et ludique ;
— facile à mettre en œuvre ;
— l’installation et l’intégration sont simplifiées.

Malgré tous ses avantages, MS Access a des inconvénients :

— il est monoplateforme et payant ;
— il n’implémente pas totalement les normes SQL ;
— les données sont enregistrées dans un seul fichier.

4.1.4 Choix et justification

Pour la réalisation de l’outil, nous avons sélectionné le SGBD PostgreSQL du fait :
— qu’il est open source et gratuit ;
— qu’il est fiable et performant, mais aussi simple d’utilisation ;
— qu’il est très riche fonctionnellement ;

16
 — que la prise en main est facile ;
— que son extension PostGIS soit en lien avec QGIS.

D’après les avantages et les inconvénients de chacune des solutions présentées, PostgreSQL
est le plus convenable et offre plus d’avantage à notre projet puisqu’il est facile à utiliser,
flexible, open source, gratuit et multiplateforme.

4.2 Technologies utilisées

4.2.1 Présentation des technologies web

HTML5 et CSS3

HTML et CSS sont la base pour tout projet de développement web, car les navigateurs tels
que Google Chrome ou encore Safari par exemple, vont interpréter le code pour afficher
les pages web.

Le langage HTML (HyperText Markup Language) a été inventé en 1990 par Tim
Berners-Lee. Le HTML est un fichier texte contenant des balises permettant de mettre en
forme (texte, image. . . ) et structurer le contenu des pages web.

Le CSS (Cascading Style Sheets) consiste à attribuer dans un même document des ca-
ractéristiques de mise en forme à tout un groupe d’éléments de la page web. Il est utilisé
conjointement avec HTML pour modifier le design (la couleur, la police, bordure, etc.) de
la page web. Il permet de réduire la taille et la complexité du code HTML. Utilisé CSS,
c’est :
— se focaliser sur la conception sans se soucier de la forme
— une mise à jour de l’apparence du site facilité
— une plus grande lisibilité du code HTML

JavaScript

Le JavaScript est un langage de script orienté objet, crée dans les années 1990 par Brendan
Eich. C’est un langage qui est inclut dans le code HTML et interprété par le navigateur.
Le JavaScript est un langage coté client, c’est-à-dire que les scripts sont exécutés par le
navigateur. Il permet de dynamiser la page web en intégrant des interactions avec l’utili-
sateur, des animations. Par exemple, la création des infobulles ou le défilement des images.

Bootstrap

17
Bootstrap est un framework qui permet de créer le design des sites et d’application web
plus aisément. Il a été créé en 2010 par deux développeurs travaillant chez Twitter. C’est
une bibliothèque qui contient du CSS pour la mise en forme du texte, tableau et les for-
mulaires. Il inclut également les librairies JavaScript pour dynamiser les pages web. Il est
mis à disposition du public sous la licence MIT.
Bootstrap fournit : une mise en page basée sur une grille de 12 colonnes, une bibliothèque
open source, une bonne documentation, etc.

4.2.2 Framework utilisé

Django

Afin d’éviter de répéter les mêmes étapes lors de la réalisation d’une solution web (la
gestion d’authentification des utilisateurs, des formulaires, . . . ), nous avons choisi d’uti-
liser un framework. Face à une multitude de framework web existant et ceux dans de
différents langages de programmations, mon choix s’est porté sur Django. D’une part,
parce qu’il est développé en Python, un langage de programmation que je maîtrise.
Python est un langage de programmation interprété, c’est-à-dire qu’il n’est pas nécessaire
de le compiler avant de l’exécuter. C’est également un langage de haut niveau et orienté-
objet.
Et d’autre part, parce qu’il est simple à l’apprentissage, garanti la sécurité du site final et
facilite la maintenance des solutions développées sur la durée.

Django a été créé en 2003 par les développeurs Adrian Holovaty et Simon Willison
pour le journal local dans le Kansas : World Online. C’est un framework open source dé-
veloppée en Python. Il est consacré au développement web et conçu pour réduire le temps
de développement et permet de simplifier la conception d’un site.

Par ailleurs, Django utilise un modèle MVT (Modèle Vue Template). Ce modèle s’ins-
pire du modèle MVC (Modèle Vue Contrôleur). Le MVC sépare le modèle (accès et mis à
jour des données) de la vue (interface utilisateur) et du contrôleur (action des utilisateurs).

18
 Figure 4.1 – Modèle vue contrôleur

Cette spécificité réside dans le fait que Django gère lui-même le contrôleur. L’image
ci-dessous illustre l’écosystème d’un projet dans Django.

Figure 4.2 – Ecosystème d’un projet Django

Le développement d’une application web est faite sous forme de projet. En effet, le
projet regroupe l’ensemble des configurations et des applications. Un projet peut contenir
zéro à plusieurs applications. Contrairement à l’application qui ne peut exister sans le
projet.
Quant à l’application, c’est un dossier qui contient plusieurs fichiers de code ( views.py,
models.py, admin.py, . . . ). Chacune de ces fichiers appartient à une composante dans le
MVT.
Un template est un fichier HTML. Il est récupéré par la vue et avant d’être envoyé à la
vue, il est analysé et exécuté par le framework.

19
4.2.3 Outils complémentaires

GIT

Git est un logiciel de gestion de versions décentralisé. Il est open source et gratuit. Il a
été créé vers 2005 par Linus Torvalds le développeur du noyau Linux. Il permet de suivre
l’évolution d’un fichier, texte ligne de code par ligne de code.
Ce logiciel est très utilisé pour la gestion d’un projet informatique en équipe ou indivi-
duellement.

SQL Power Architect

SQL Power Architect est un outil multiplateforme (Linux, OS X, Windows). Il propose

une version gratuite et open source (sous licence GPL v3) permettant de réaliser la MPD
(modèle pysique des données) mais également de générer automatiquement le script SQL
de création du schéma de la base de données (tables, clés étrangères, index. . .).

4.3 Développement de l’outil

4.3.1 Configuration minimale requise
Serveur
Le tableau suivant définit la configuration minimale requise pour le serveur.

Version
Système d’exploitation
Linux Toute distribution
Windows 2000 ou supérieur
Serveur web
Apache 2
Gunicorn 19.8
SGBD
PostgreSQL 10
Framework
Django 1.10.1
Table 4.1 – Configuration minimale requise du serveur

Utilisateur
Concernant les postes utilisateurs, la configuration requise est la suivante :

20
 Système d’exploitation Linux, Windows, Mac os x
Mémoire 1024 Mo
Navigateur Google Chrome, Mozilla
Table 4.2 – Configuration minimale requise pour l’utilisateur

4.3.2 Architecture du système

Le système utilise l’architecture à trois niveaux (appelée architecture 3-tier).
Dans cette architecture, nous avons :
— Un client (utilisateur) qui effectue une demande de ressources à partir de son interface
utilisateur (navigateur web par exemple) ;
— Un serveur d’application qui est chargé de fournir la ressource en faisant appel à un
autre serveur ;
— Le serveur de données qui fournit au serveur d’application les données demandées.

Figure 4.3 – Architecture du système

21
4.3.3 Architecture logicielle
L’outil utilise le serveur SGBD PostgreSQL. La communication entre l’outil et le ser-
veur repose sur l’architecture suivante.

Figure 4.4 – Architecture logicielle

Dans cette architecture, le modèle est connecté au serveur grâce au pilote postgreSQL
permettant ainsi une communication directe avec le serveur des données. Le serveur post-
greSQL a comme nom d’hôte : localhost. Il écoute sur le port 5432.

4.3.4 Architecture Matérielle

L’architecture matérielle est basée sur ce modèle :

22
 Figure 4.5 – Architecture matérielle

L’architecture s’appuie sur l’architecture client (utilisateur) / serveur. Ici, l’utilisateur

envoie des requêtes SQL au serveur de base de données. Le serveur les traite et envoie à son
tour les réponses à l’utilisateur. Dans ce système, c’est l’utilisateur qui initie le dialogue
puisque le serveur, n’est qu’en écoute.

4.4 Modélisation du système et de la base de données

4.4.1 Représentation du système
Avant de définir le fonctionnement du système, voici les règles de gestion que les prin-
cipaux acteurs doivent respecter.

Nom de la règle Description

RG1 L’administrateur inscrit le nouveau utilisateur dans la base de données
Les utilisateurs doivent s’authentifier avec les identifiants fournis par
RG2
l’administrateur
RG3 Un utilisateur ne peut pas avoir deux responsabilités simultanément
RG4 Les utilisateurs du système sont classés selon leur profil
RG5 Tous les utilisateurs peuvent consulter les données
RG6 Seul les utilisateurs ayant le profil de gestionnaire pourront saisir les données
RG7 Avant de faire des analyses, les utilisateurs doivent sélectionner les données
Pour importer les données à partir d’un fichier, l’administrateur doit respecter
RG8
le fichier standard mis en place
RG9 L’utilisateur peut exporter des données
Table 4.3 – Règle de gestion du système

En UML (Unified Modeling Language ), le diagramme de cas d’utilisation permet de

représenter les principaux acteurs du système. Ici, nous avons l’utilisateur et l’administra-
teur.

23
Dans notre système l’utilisateur s’authentifie avec les identifiants fourni par l’administra-
teur. Selon le profil, l’utilisateur pourra effectuer les actions suivantes :
• consulter les données depuis le tableau de bord ;
• saisir les données
• analyser les données à partir des indicateurs
• faire une projection des données
• exporter les données

24
25
Figure 4.6 – Diagramme de cas d’utilisation du système
 Dictionnaire de données

Le dictionnaire de données contient les noms mnémoniques des données ainsi que la des-
cription correspondant.

Nom mnémonique Description

numero_delib Numéro de délibération
id_event id événement
nom_event Nom événement
description_event Description de l’événement
ref_commande Référence de commande
libelle_nom Libelle nommenclature
date_prelev Date de prélèvement
date_caract Date de caractérisation
type_mat Type de matériel
etat_mat Etat matériel
categorie_mat Catégorie du matériel
type_trans Type transporteur
nom_trans Nom transporteur
immat Immatriculation
nom_part Nom partenaire
description_part Description partenaire
adresse_part Adresse partenaire
param_indice Nom paramètre indice révision
Table 4.4 – Dictionnaire de données

26
4.4.2 Modélisation avec SQL Power Architect
Pour l’ajout d’une nouvelle colonne dans la base, nous avons plusieurs paramètres que
nous pouvons définir. Nous devons indiquer son nom, préciser s’il est clé primaire, s’il doit
s’incrémenter automatiquement ou encore s’il est obligatoire de le renseigner ou non au
moment de l’insertion des données.

Figure 4.7 – Modélisation : ajout d’une colonne

27
 La définition d’une relation d’association entre deux tables s’effectue de cette façon.
Nous déterminons le type de la relation c’est-à-dire s’il doit être considérer en tant qu’iden-
tifiant de la table ou en tant que clé étrangère. Nous spécifions également la cardinalité
entre les deux tables. Puis la règle lorsqu’on modifie ou supprime la donnée.

Figure 4.8 – Définition des règles entre deux tables

Après la modélisation, nous intégrons les tables dans la base de données PostgreSQL.
Pour ce faire, nous saisissons toutes les informations de Connexion liées à la base.

Figure 4.9 – Connexion BD PostgreSQL

28
 Enfin, l’édition du script sql. Avec la commande execute, les tables sont ajoutées di-
rectement dans la base.

Figure 4.10 – Génération script SQL

4.4.3 Base de données : version 1

Cette première version a été effectuée après une analyse globale des données. Dans un
premier temps, les relations d’associations définis entre les tables ne sont pas prises en
compte.

29
30
Figure 4.11 – Modélisation logique BD : version 1
4.4.4 Base de données : version 2
Dans cette seconde version, plusieurs corrections ont été apportées. Tout d’abord la
suppression de la table epci. Cette table est intégré dans la table commune en tant que
champ. Dans cette même table le champ année a été ajouter.
Ensuite, la modification des tables comme analyse, facture, site, etc.
Et enfin, l’ajout des nouvelles tables telles que estExploitant, conclu pour référencer les
marchés établis avec les partenaires.

31
32
Figure 4.12 – Modélisation logique BD : version 2
4.4.5 Administration de la base avec PostgreSQL
Dans un premier temps la base de données a été administrer depuis l’interface pgAdmin.

Figure 4.13 – Exemple de requête dans pgAdmin

33
Chapitre 5

Résultats

5.1 Déroulement du projet

L’image ci-dessous montre le déroulé réel du stage. Celui-ci prend en compte les dif-
férents obstacles rencontrés. Le stage a été découpé en plusieurs phases. Dans chacune
d’elles, une segmentation en différentes tâches a également été opérée.

34
35
Figure 5.1 – Diagramme de Gantt : déroulé réel du stage
5.2 Difficultés rencontrées
5.2.1 Constat
Durant le stage, plusieurs difficultés se sont présentées.

En premier lieu, lors de la mise en place du planning prévisionnel, j’appréhendais le

risque de dérive du temps nécessaire de développement car des imprévus peuvent appa-
raître à tout moment durant cette phase. Ce fut le cas d’avoir omis l’étape, à savoir de ne
pas avoir inclus dans le planning la durée d’apprentissage du framework utilisé.

Deuxièmement, pendant la conception de la base de données. Ayant choisi d’utiliser un

logiciel générique de modélisation indépendamment de la base de données final, j’ai fait
face aux problèmes suivants :
• L’impossibilité d’exploiter toutes les fonctionnalités spécifiques à la base. Prenons
l’exemple d’une colonne qui a pour type "texte". Il existe deux manières dans SQL
Power Architect pour définir le type texte . L’une est de d’utiliser VARCHAR en
définissant la précision. L’autre est d’utiliser le type LONGVARCHAR. Or, ce der-
nier, n’est pas reconnu par PostgreSQL. La solution serait de mettre une valeur
suffisamment grande dans la "precision" du VACHAR.
• Le logiciel utilisé ne supporte pas les types de champs postgis permettant ainsi de
modéliser les champs géométriques. L’alternative est d’ajouter des champs supplé-
mentaires dans les tables.

5.2.2 Analyse
Malgré les quelques complications que j’ai eu, cela n’a pas empêché l’atteinte des
objectifs fixés. Ainsi, face à ces problèmes, j’ai apporté des solutions concluantes qui m’ont
permis d’avancer rapidement.

5.3 Outil final

Dans cette partie, quelques interfaces fonctionnelles sont présentées. A ce stade, le
design de l’interface utilisateur est en cours d’intégration.

5.3.1 Interface de connexion utilisateur

Étant donné que c’est une application web, elle est accessible via un navigateur web. Il
est essentiel d’avoir un système de sécurisation lors de l’authentification afin de protéger
les informations confidentielles des utilisateurs contre les personnes malveillantes. De ce
fait, Django fournit une technique de sécurisation des formulaires et d’authentification.
Pour cela, l’utilisateur doit tout d’abord se connecter en saisissant obligatoirement ses
identifiants comme ci-dessous.

36
 Figure 5.2 – Page d’authentification

5.3.2 Interface de saisie utilisateur

L’interface de saisie se présente de cette façon. Selon le profil, l’utilisateur pourra

saisir les données dans les catégories suivantes : techniques, finance et administrative. Le

cas présent, j’affiche quelques onglets pour illustrer le type de données à saisir, sans tenir

compte du profil utilisateur.

Figure 5.3 – Interface de saisie

5.3.3 Interface administrateur : importation des données

Depuis cet interface, l’administrateur pourra effectuer les opérations basiques telles que

l’ajout, la suppression, la modification et la lecture des données. Comme fonctionnalité, il

a le choix de saisir les données ou de les importer à partir d’un fichier excel. Nous pouvons

voir dans l’image qui suit les champs qu’il doit respecter. Une demande de confirmation

est demandée. De plus, l’administrateur est informé si les données importées sont une mise

à jour ou un nouvel ajout.

37
 Figure 5.4 – Interface administrateur : importation

Figure 5.5 – Interface administrateur : adminconfirmation

5.4 Perspectives

Les évolutions qui pourrait être emmenées dans l’outil sont :

• Créer une interface exclusive aux partenaires. Dans cette interface, les partenaires

déposeraient les fichiers de données, saisiraient les données qui seront par la suite

validées par l’administrateur. Ils pourraient également avoir un tableau de bord avec

leurs données (tonnages, marchés publics en cours, etc.) afin d’avoir un suivi plus

dynamique.

38
• L’enregistrement des requêtes effectuées à partir des analyses, voire les partager avec

les autres utilisateurs.

• Rendre plus souple l’importation des données. Actuellement, les champs des en-

têtes sont imposés dans le fichier. Cependant, le mieux est de laisser à l’utilisateur

de choisir dynamiquement les entêtes au moment de l’import des données et ainsi

que les colonnes souhaitées.

39
Conclusion

En résumé, les éléments suivants ont été traités : l’analyse de l’existant, la mise en

place des outils pour le développement, la création de la base de données et l’aperçu visuel

de l’outil dans lequel l’utilisateur pourrait analyser les données.

Les objectifs fixés sont atteints omis quelques fonctionnalités qui restent à développer.

Ces objectifs sont :

X un diagnostic sur l’état actuel des données ;

X mise en place d’une base de données ;

X développement d’un outil informatique répondant aux besoins des agents ;

X le volet subvention.

A propos du déploiement de l’outil, cela se fera sous l’autorisation du service informatique

en charge du système informatique du SYDNE.

Ce stage m’a permis de mettre en avant mes connaissances théoriques et techniques dans

la structure du SYDNE.

Durant ce stage, j’ai acquis des compétences au niveau informatique qui sont :

X gestion de projet informatique de sa conception à sa réalisation ;

X l’administration de la base de données mise en place ;

X développement d’une application web.

Mais également, une culture sur l’aménagement du territoire.

40
Bibliographie

[1] SYDNE. Site officiel.

http://www.sydne.re/.

[2] SINOE. Site officiel.

http://www.sinoe.org/.

[3] AGORAH. Peigeo.

http://www.peigeo.re/accueil.

[4] ORDIF. Accueil.

http://www.ordif.com/.

[5] ADEME. Subvention.

http://www.ademe.fr/collectivites-secteur-public/

collectivites-lademe-finance-projets.

[6] Région Réunion. Subvention feder.

http://www.regionreunion.com/sites/feder/.

[7] Open classerooms. Mooc.

https://openclassrooms.com/courses/introduction-au-framework-django.

[8] Developpez.com. Sgbd.

https://fadace.developpez.com/sgbdcmp/.

[9] Formation Django. Django.

http:

//www.formation-django.fr/framework-django/zoom-sur/orm-django.html.

[10] Django. Packages.

https://djangopackages.org/.

[11] Django. Documentation.

https://docs.djangoproject.com/fr/2.0/.

41
[12] Python. Documentation.

https://docs.python.org/fr/3/.

[13] SQL Power Architect. Guide.

http://do-we-know-how.bring.out.ba/file/2011/09/

7335282-PowerArchitectUserGuide.pdf.

42
Glossaire

Framework : désigne un ensemble cohérent de composants logiciels structurels, qui sert

à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel

(architecture).

Déchet : " Tout résidu d’un processus de production, de transformation ou d’utilisation,

toute substance, matériau, produit, ou plus généralement tout bien meuble abandonné ou

que le détenteur destine à l’abandon " (article L.541-1-1 du Code de l’environnement).

Déchets ménagers et assimilés (DMA) : sont des déchets issus des ménages et des

déchets assimilés. Les déchets produits par les services municipaux, déchets de l’assainisse-

ment collectif, déchets de nettoyage des rues, de marchés ne relèvent pas de ce périmètre.

Système de Gestion de Bases de Données ( SGBD) : est un logiciel qui prend

en charge la structuration, le stockage, la mise à jour et la maintenance d’une base de

données.

Modèle physique des données (MPD) : consiste à implanter une base de données

dans un SGBDR.

43
A Le SYDNE

A.1 Organisation institutionnelle : le comité syndical

Figure 6 – Membre du comité syndical

44
A.2 Territoire du SYDNE

Figure 7 – Carte du territoire SYDNE

45
A.3 Bilan annuel des quantités des déchets

Figure 8 – Quantités des déchets : année 2016

46
B Documents réalisés

47
 24/05/2018

B.1 Présentation des objectifs du stage aux agents

1) Contexte du SYDNE
2) Objectif
PROJET BD DMA 3) Exemple
MISE EN PLACE D’UN OUTIL INFORMATIQUE DE GESTION DES DONNÉES 4) Déroulé

STAGE SYDNE – UNIVERSITÉ DE LA RÉUNION – LABORATOIRE D’INFORMATIQUE ET DE

MATHÉMATIQUES (LIM)
DU 02/01/2018 AU 29/06/2018

Projet BD DMA 2
29 JANVIER 2018 FARDA HOUMADI/ STAGIAIRE

CONTEXTE DU SYDNE RECRUTEMENT STAGIAIRE

• Capitalisation de l’information « déchet » acquise à travers ses • Formation : Master

activités • Spécialité : Informatique
• Archivage non standardisé, isolé et éparse • Domaine : Base de données, développement, gestion de projet
• Peu d’analyse possible sur les données archivées informatique

Projet BD DMA 3 Projet BD DMA 4

OBJECTIF

• Développer & mettre en place un outil informatique permettant de

capitaliser, archiver l’information
• Faciliter les tâches administratives
• Effectuer des analyses statistiques

3. EXEMPLE

Projet BD DMA 5 Projet BD DMA 6

48
1
 24/05/2018

EXEMPLE

• Analyse rapide, dynamique et intuitive des données

• Projection
• Edition interactive du RA & les déclarations périodiques
• Exportation des données sous différents formats

4. DÉROULÉ

Projet BD DMA 7 Projet BD DMA 8

DÉROULÉ

Fin :
Début : Today Questionnaires 16/02/2018

Entretiens des Vos besoins

agents du FARDA HOUMADI
SYDNE
STAGIAIRE

FARDA.HOUMADI@SYDNE.RE

Projet BD DMA 9

2
B.2 Recueil des besoins : questionnaire

26/05/2018

Figure 9 – Questionnaire

50
 B.3 Note d’avancement

NOTE D’AVANCEMENT DE PROJET

De : F Houmadi OBJET : PROJET DMA Date : 14/03/2018

(mise en place d’une base de données)
A : Y Savrimoutou Version 1
M Leclercq
G Roussel
J Fontaine
N Gobarden
Pièces jointes : cf. annexes

1 OBJECTIF DE LA NOTE :
Point d’avancement sur le projet de la mise en place d’une base de données et d’un outil informatique.

2 CONTEXTE / AVANCEMENT
En bref, le projet consiste à :
• Développer & mettre en place un outil informatique permettant de capitaliser, archiver l’information
• Faciliter les tâches administratives
• Effectuer des analyses statistiques
En termes d’avancement, les besoins de chaque agent du SYDNE ont été recueillis. Ces besoins sont traduits en
fonctionnalités pour le développement de l’outil. La conception et la mise en place de la base de données sont
en cours. Le développement de l’outil se fera en parallèle de cette mise en place afin d’éviter tout retard sur le
projet.

3 EXPRESSION DES BESOINS

Les besoins exprimés sont les suivants :

 Une interface de saisie rapide et ergonomique des données

 L'archivage sécurisé de la donnée
 L'analyse des données à partir des indicateurs
 La projection des données sur plusieurs années
 Transportable sur SIG
 Suivi de l'évolution budgétaire, de l'évolution du tonnage, de la réalisation budgétaire, des
subventions pour les projets, rapport mensuel des prestataires
 Une fiche d'information des sites (installations), le prix unitaire et autres
 Alerte en cas de dépassement du seuil minimum fixé pour les sites
 Rappel mensuel au prestataire pour l'envoie des données
 L'historique des évènements sur chaque site
 Tableau suivi des marchés en cours
 Interface version tablette de la grille audit réglementaire pour inspection
 Recherche par mot-clé, nom, année rapport CS

SYDNE/FH 1

51
  Eco-organisme : tonnage valorisé
 Édition du rapport annuel
 Compatible avec le site web du SYDNE
 Évolutif
 Suivi des demandes des usagers (appel numéros vert, courrier)
 Référencement par mot-clé des rapports comité syndicaux
 Suivi recette éco-organisme
 Automatisation de tâches financières : calcul révision des prix,
 Contrôle cohérence
 Matrice des coûts HT
 Suivie facture par marché
 Opération basique et avancé sur les données : écart-variation, somme
 Vérification de la donnée
 Comparaison prix unitaire de l’ancien marché avec le nouveau marché

4 MAQUETTE / INTERFACE DE L’OUTIL

Détail non définitif de quelques interfaces :

1. Connexion
2. Choix des informations à afficher dans le tableau de bord
3. Accueil de l'outil
4. Interface de saisie : choix catégorie
5. Interface analyse
6. Paramètres : modification mot de passe…

SYDNE/FH 2
 7. Interface de l'historique

5 ANALYSE FONCTIONNEL

SYDNE/FH 3
 Nom de la fonctionnalité Description Nécessaire ? Priorité Planification
Oui/non Faible,
moyen, forte
Gestion des utilisateurs et Identification de l'utilisateur : identifiant et mot de passe oui Forte Mars
droits Quatre niveaux de profils :
• Administrateur : à tous les droits sur l'outil, gère les
utilisateurs, délègue certain droit au responsable de service
• Gestionnaire des données
• Utilisateur : exportation des données, tableau/graphique
obtenu après analyse
• Visiteur : consultation des données

Modification du mot de passe dans les paramètres

Connexion / Déconnexion Connexion : identifiant et mot de passe fourni par oui Forte Mars
l'administrateur
Déconnexion : manuelle ou automatique après un temps de
non activité dans l'outil
Tableau de bord Première connexion : oui Moyen Mai
• Choix tableau de bord par défaut ou personnalisation
• Choix de la catégorie de la donnée et mode d'affichage
Modification du choix dans les paramètres
Saisies des données Choix de la catégorie de la donnée : technique, financier, oui Forte Mars
rejet
Formulaire pré-rempli avec des valeurs par défauts
Affichage du récapitulatif de la saisie avant envoie des
données
Affichage d'une notification de succès ou d'échec

Modification ou annulation de l'action avant validation

Importation des données Insertion des données à partir d'un modèle Excel prédéfini non Faible -
depuis un fichier Excel Limitation du nombre d'enregistrement dans la base
Visualisation des données importées dans un tableau

SYDNE/FH 4
 Validation ou annulation de l'action

Affichage d'une notification de succès ou d'échec

Analyse des données Superposition de plusieurs jeux de données oui Forte Mai
Sélection/désélection individuelle des indicateurs
Enregistrement paramètre des analyses
Affichage du résultat dans un tableau ou sous différent format
graphique
Combinaison de différent format de graphique
Commenter le résultat et le partager
Exportation au format image, pdf, excel
Archivage des données L'utilisateur défini les données à archiver et le temps de non Faible -
stockage
Sécurisation des données :
• Processus automatique et crypté pour l'archivage
• Données disponibles en lecture seule
• Système d'alerte lors consultation ou modification des
données sensibles
Journal détaillé du processus d'archivage
Recherche : type de données, auteur du document, mots-clés
Historique des évènements Evènement sur les sites : oui Moyen Mai
• Ajouter, modifier, supprimer, rechercher
• Affichage sous forme de liste toutes les évènements
Visualisation des modifications dans la base des données
• Nom, date, description
Alerte/notification Notification : oui Moyen Mai
• Lors d'une modification dans la base de données
Alerte :
• Seuil minimum fixé est atteint
Information L'utilisateur recherche, sélection et applique des filtres afin oui Faible Juin
d'obtenir les informations souhaitées sur les sites, prix
unitaire etc.

SYDNE/FH 5
6 CONCEPTION DE LA BASE DE DONNEES

SYDNE/FH 7
 B.4 Présentation des solutions techniques

NOTE D’AVANCEMENT DE PROJET

De : F Houmadi OBJET : PROJET DMA Date : 12/04/2018

(mise en place d’une base de données)
A : Y Savrimoutou Version 1
M Leclercq
G Roussel
J Fontaine
N Gobarden
Pièces jointes : cf. annexes

1 OBJECTIF DE LA NOTE :
Présentation de deux solutions dans l’objectif d’effectuer un choix pour le développement et la mise en place de
l’outil.

2 CONTEXTE / AVANCEMENT
En bref, le projet consiste à :
• Développer & mettre en place un outil informatique permettant de capitaliser, archiver l’information
• Faciliter les tâches administratives
• Effectuer des analyses statistiques
En termes d’avancement, les besoins de chaque agent du SYDNE ont été recueillis. Ces besoins sont traduits en
fonctionnalités pour le développement de l’outil. La conception et la mise en place de la base de données sont
en cours. Le développement de l’outil est également en cours.

3 PRELIMINAIRE

❖ Base de données
Une base de données est un système qui enregistre des données de manière structurée.

❖ Système de gestion de base de données (SGBD)

Le SGBD est un logiciel système conçu pour créer et gérer des bases de données. Il permet :
- de stocker des informations dans une base de données
- d’accéder aux données de manière simplifiée
- d’autoriser un accès aux informations à de multiples utilisateurs
- de manipuler les données présentes dans la base de données (insertion, suppression,
modification)
Il joue le rôle d’interface entre les utilisateurs de la base de données et les programmes d’application.

SYDNE/FH 1

57
 C’est un SGBD open source, gratuite et multiplateforme. Il est le plus complet des SGBD gratuits. Il
convient aux bases de données volumineuses.

5 PRESENTATION DES SOLUTIONS

Figure 1 : Ecosystème du SGBD Pré-requis Avantage Inconvénients

Outil pour la Optimisé et rapide : Mono-plateforme :

Exemple de logiciel SGBD connus : plateforme utilisation de la compatibilité restreinte
- Propriétaire : Microsoft Acces Windows performance de la au système
- Libre : MySQL, PostgreSQL machine/système d’exploitation.
d’exploitation. L’outil de
Répartition du code développement Visual
❖ Serveur d’application, web entre le serveur et le studio est gourmant en
Un serveur web permet de rendre un site web accessible aux utilisateurs via un navigateur. client : cela permet au ressources.
Un serveur d’application permet de déployer et d’exécuter des applications. client de solliciter les Maintenance
ressources du serveur compliquée.
❖ Framework seulement pour les
Un framework est : traitements par
- un ensemble cohérent de composants logiciels et réutilisable exemple.
- un ensemble de préconisations pour la conception et le développement

❖ Modèle vue contrôleur (MVC)

Le MVC est un patron de conception pour la réalisation des applications. Il permet de séparer : Application web Installation des Multiplateforme : Utilisation de l’outil
- l’affichage des informations (vue) services dans le accessible depuis un Susceptible d’être
- les actions de l’utilisateur (contrôleur) serveur navigateur web attaqué par des
- l’accès aux données (modèle) (chrome, Mozilla…). personnes malveillantes
Lors de l'utilisation en si le niveau de sécurité
❖ Liaison entre chaque couche interne l'application est faible.
2 peut fonctionner sans
1
connexion internet.

3 6 PRECONISATION DE LA SOLUTION
4
Figure 2 : Exemple d'architecture d'une application web

La solution que j’ai choisie en termes de SGBD est PostgreSQL pour ses nombreuses fonctionnalités.
Pour l’outil une application web, qui sera développé avec le langage Python et utilisant le framework
4 PRESENTATION DES SGBD Django. Les fonctionnalités disponibles dans Django permettent de créer une application web très
❖ MySQL rapidement. Le framework dispose d’une interface administrateur pour la gestion du projet et des
MySQL est un SGBD open source, gratuite et multiplateforme (Windows, Linux, MacOSX, Unix). Il est données. Dans cette interface, plusieurs fonctionnalités sont déjà disponibles telles que :
adapté pour les petites bases de données avec un nombre faible de connexion simultané. - la gestion des utilisateurs en leur attribuant les droits, les actions qu’ils pourront
effectuer dans l’outil
❖ Microsoft Acces - l’import/export des données à partir d’un fichier Excel/PDF
Il est propriétaire, payant et disponible uniquement sur la plateforme Windows. Il est complet, intuitif - prévisualisation des données importées avant enregistrement dans la base
et simple à déployer.
Quelques performances que le framework dispose :
❖ PostgreSQL
- la sécurisation de l’application finale
- la maintenance est facilitée sur la durée

SYDNE/FH 2 SYDNE/FH 3
7 SUITE A DONNEES
La confirmation de la solution choisie par le DGS. Suivi du projet par le service informatique de la CINOR.

SYDNE/FH 4
C Visite des installations

C.1 Déchet entrant

Figure 10 – Déchet issus de la collecte sélective

Figure 11 – Déchet vert

60
C.2 Déchet sortant

Figure 12 – Compost

Figure 13 – Balle de déchet

D Développement

61
 D.1 Turoriel Django
Installation de Django

C:\Users\sydne>pip install django~=1.10.0

Downloading/unpacking django==1.10
Installing collected packages: Django
Successfully installed Django
Cleaning up...

Création du projet

C:\Users\sydne>django-admin startproject projetDMA

Création de l’application

C:\Users\sydne\projetDMA>python manage.py startapp mainDMA

Organisation du projet

Installation de l’application dans le projet. Dans le fichier setting.py, ajouter le nom de l’application.

# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',

62
 'django.contrib.staticfiles',
'mainDMA',
]

Configuration de la base de données selon les caractéristiques de PostgreSQL. Par défaut, Django
utilise la base de données SQLite.

# Database
# https://docs.djangoproject.com/en/1.10/ref/settings/#databases
DATABASES = {
'default' : {
'ENGINE' : 'django.db.backends.postgresql',
'NAME' : 'dma',
'USER' : 'postgres',
'PASSWORD' : 'sydne',
'HOST' : 'localhost',
'PORT' : '',
}
}

Migration des tables (admin, auth, contentypes, sessions) dans la base. La migration est obligatoire
pour pouvoir définir les identifiants de l’administrateur.

C:\Users\sydne\projetDMA>python manage.py makemigrations

No changes detected

C:\Users\sydne\projetDMA>python manage.py migrate

Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying sessions.0001_initial... OK

Création du profil administrateur.

C:\Users\sydne\projetDMA>python manage.py createsuperuser

Username (leave blank to use 'farda'): sydneAdmin

Email address: sydne.admin@sydne.re

Password:

Password (again):

Superuser created successfully.

Lancement du serveur.

C:\Users\sydne\projetDMA>python manage.py runserver

Performing system checks...

System check identified no issues (0 silenced).

May 25, 2018 - 15:09:28

Django version 1.10.8, using settings 'projetDMA.settings'

Starting development server at http://127.0.0.1:8000/

Quit the server with CTRL-BREAK.

 D.2 Personnalisation de l’interface administrateur
class ListAdminMixin(object):
def __init__(self, model, admin_site):
# Affichage des noms des tables
self.list_display = [field.name for field in model._meta.fields +
model._meta.many_to_many if field.name != ("id" and r'(id\w+)\W(\w+)' )]
# Filtre les elements dans la table par les champs defini : epci,
date...
self.list_filter = [field.name for field in model._meta.fields if
field.name != "id" ]
# Ordonne les elements dans la table avec les champs defini : nom,
date...
self.ordering = [field.name for field in model._meta.fields if
field.name != "id" ]
# Recherche par les elements dans la table avec les champs defini
self.search_fields = [field.name for field in model._meta.fields if
field.name != "id" ]
super(ListAdminMixin, self).__init__(model, admin_site)

class Commune(resources.ModelResource):
class Meta:
# Nom du modele de la table
model = Commune
exclude = ('id')
# Champs a afficher
fields = ('id_commune','nom_commune','code_postal', 'code_insee',
'nombre_habitant','nom_epci',)
import_id_fields = ['id_commune',]
# Specification des champs a filtre
list_filter = ['nom_commune', 'nom_epci',]

class ImpExp(ImportExportModelAdmin):
resource_class = Commune
# pass

# Recupere tous les elements de la base et les affiche dans l interface

administrateur
models = apps.get_models()
for model in models:
admin_class = type('AdminClass', (ListAdminMixin, ImpExp,
admin.ModelAdmin), {})
# Si le modele n existe pas alors, il est ajoute
try:
admin.site.register(model,admin_class)
# Sinon, on ne fait rien
except admin.sites.AlreadyRegistered:
pass

65
# register all adminactions
# Ajout des actions : supprimer, ajouter, exporter
actions.add_to_site(site)
admin.site.site_header = "Projet DMA Administration"
admin.site.site_title = "Projet DMA Administration"
D.3 Script sql

Figure 14 – Script SQL : BD version 2

67
E MOOC (massive open online course)

J’ai suivi les MOOCs « Déccouvrez le framework Django » et « Développez votre site

web avec le framework Django » sur le site d’Open Classerooms. Ces cours m’ont permis

de comprendre et d’acquérir les bases pour développer une application web avec le frame-

work Django.

Les objectifs pédagogiques étaient :

• Utiliser Django pour créer une application professionnelle ;

• Organiser un projet Django en suivant de bonnes pratiques ;

• Utiliser l’ORM de Django pour interagir avec la base de données ;

• Créer des gabarits ;

• Tester un projet Django avec des tests unitaires ;

• Mettre en ligne une application Django sur Heroku.

68