République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Carthage

Faculté des Sciences de Bizerte

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme de Licence en Ingénierie des systèmes informatiques

Spécialité : Système embarqué et internet des objets (SEIoT)

Mohamed Demni

Conception et developpement d’un système de

surveillance d’incendies de forêts

Encadrant professionnel : Monsieur Karim Fathallah Maître Assistant

Encadrant académique : Madame Mouna Abdelmoumen Maître Assistante

Réalisé au sein de Smart For Green

Cadre réservé à l’encadrant académique

i
Dédicaces

Du fond de mon cœur, je dédie ce travail

À ma très chère mère Salwa,

Tu as été ma source inépuisable de soutien, d’amour et de conseils tout au long

de ce voyage. Vos encouragements constants et votre gentillesse sont mes points

forts. Que Dieu vous protège et remplisse votre vie de bonheur et de réussite.

À mon très cher père M’hamed,

Aucun dévouement ne peut exprimer mon infinie gratitude envers vous. Vous

m’avez montré l’importance du travail acharné et de l’intégrité. Que Dieu vous

garde et vous comble de bénédictions.

À mes sœurs Farah et Zahra,

Merci pour votre amour inconditionnel et votre présence constante dans ma vie.

Que vos vies soient remplies de joie, de réussite et d’épanouissement.

À ma famille,

Je tiens à exprimer ma profonde gratitude envers tous les membres de ma

famille pour leur soutien indéfectible. Votre amour, vos encouragements et votre

confiance ont été des piliers essentiels dans la réalisation de ce projet.

À mes amis,

Je vous remercie du fond du cœur pour votre amitié sincère et votre soutien
constant. Vos encouragements et vos conseils ont été précieux.

Demni Mohamed

ii
 Remerciements

En tout premier lieu, je remercie le bon Dieu, tout puissant, de m’avoir

donné la force et l’audace pour dépasser les difficultés.

Je souhaite rendre hommage à tous ceux qui ont contribué de près ou de

loin à la réalisation de ce travail.

Je remercie tout d’abord mon encadrante académique, Mme Mouna

Abdelmoumen, pour son soutien, sa disponibilité et ses précieux conseils tout au

long de ce projet. Ses encouragements ont été une source de motivation et

d’inspiration pour moi.

Je remercie également mon encadrant professionnel Mr Karim Fathallah et

tous les membres de l’équipe Smart For Green, qui ont partagé leur expertise et
leurs connaissances avec moi, et ont contribué à la réussite de ce projet.

J’adresse aussi mes remerciements aux membres de jury pour avoir accepté
de juger, d’évaluer et d’enrichir ce travail.

Par la même occasion, je présente mes sincères reconnaissances à tous mes

enseignants qui m’ont soutenu au long de mon cursus estudiantin et à tous ceux
qui m’ont porté aide et soutien durant mes études.

iii
Table des matières

Introduction générale 1

1 Contexte général du projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1.1 OFIDIA2, Greece-Italy (2014) . . . . . . . . . . . . . . . . . . . 4
1.4.1.2 Lesnoy Dozor, Russia (2018) . . . . . . . . . . . . . . . . . . . . 5
1.4.1.3 Milesight IoT’s(2020) . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1.4 DRYAD, Allemagne (2020) . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Etat de l’art 10
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Les réseaux LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Les réseaux cellulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Les réseaux non cellulaires . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Choix du Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 LoraWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4.1 Architecture de réseau LoRaWAN : . . . . . . . . . . . . . . . . 13
2.2.4.2 La Technologie LoRa : . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4.3 Les paramètres de LoRa : . . . . . . . . . . . . . . . . . . . . . 15
2.2.4.4 Le Protocole LoRaWAN : . . . . . . . . . . . . . . . . . . . . . 16
2.2.4.5 La securité de LoraWAN : . . . . . . . . . . . . . . . . . . . . . 17
2.3 Protocole de communication : MQTT . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Modélisation du risque de départ du feu . . . . . . . . . . . . . . . . . . . . . . 20

iv
 2.4.1 La méthode d’Angström de calcul du risque de départ de feu . . . . . . 20
2.4.2 La méthode Américaine de calcul du risque de départ de feu . . . . . . . 20
2.4.3 La méthode de Baumgartner de calcul du risque de départ de feu . . . . 20
2.4.4 La méthode Canadienne de calcul du risque de départ de feu . . . . . . 21
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Étude Conceptuelle 25
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1 Vue statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2 Vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2.1 Diagrammes des séquences . . . . . . . . . . . . . . . . . . . . . 35
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Réalisation 41
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Scénarios et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 La mise en oeuvres des noeuds . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1.1 Étapes de mise en œuvre des nœuds du projet . . . . . . . . . . 48
4.3.1.2 Montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.1.3 Illustration du déploiement du système en pratique . . . . . . . 49
4.3.2 Réalisation de la partie développement . . . . . . . . . . . . . . . . . . . 50
4.3.2.1 Interface page d’accueil . . . . . . . . . . . . . . . . . . . . . . 50
4.3.2.2 Interface de sélection du rôle utilisateur . . . . . . . . . . . . . 51

v
 4.3.2.3 Interface s’authentifier . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2.4 Interface consulter liste des projets . . . . . . . . . . . . . . . . 52
4.3.2.5 Interface ajout d’un projet . . . . . . . . . . . . . . . . . . . . 52
4.3.2.6 Interface ajout d’un client . . . . . . . . . . . . . . . . . . . . . 53
4.3.2.7 Interface ajout des parcelles . . . . . . . . . . . . . . . . . . . . 53
4.3.2.8 Interface ajout des noeuds . . . . . . . . . . . . . . . . . . . . . 54
4.3.2.9 Interfaces d’affichage . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2.10 Interface client consulter la liste des noeuds . . . . . . . . . . . 55
4.3.2.11 Interface client pour consulter les détailles d’un noeud . . . . . 55
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Conclusion générale 57

vi
Table des figures

1.1 Logo Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Projet OFIDIA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Projet Lesnoy Dozor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Architecture du projet Milesight IoT’s . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Projet DRYAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Architecture générale de la solution proposée . . . . . . . . . . . . . . . . . . . . 9

2.1 Architecture de LoraWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Logo TTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Logo Lora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Les couches protocolaires LoRa. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Procédure OTAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Architecture du protocole MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Risques feu forets avec FWI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Structure du FWI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Diagramme de cas d’utilisation Global . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Cas d’utilisation : gestion des superviseurs . . . . . . . . . . . . . . . . . . . . . 30
3.3 Cas d’utilisation : gestion des projets de supervision . . . . . . . . . . . . . . . . 31
3.4 Cas d’utilisation : gestion des clients . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Cas d’utilisation : gestion des noeuds . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Cas d’utilisation : gestion des paramètres climatiques . . . . . . . . . . . . . . . 33
3.7 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Diagramme de séquence : S’authentifier . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Diagramme de séquence :Ajouter un client . . . . . . . . . . . . . . . . . . . . . 36
3.10 Diagramme de séquence : Ajouter un noeud . . . . . . . . . . . . . . . . . . . . 37
3.11 Diagramme de séquence : Ajouter un projet de supervision . . . . . . . . . . . . 38
3.12 Diagramme de séquence : modifier un projet de supervision . . . . . . . . . . . . 39

4.1 Wio-E5 Développement Kit [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 La carte lora E5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Dragino passerelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

vii
4.4 Capteur de température et d’humidité Grove - DHT22 . . . . . . . . . . . . . . 44
4.5 Montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Cablage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8 Interface « sélection du rôle utilisateur » . . . . . . . . . . . . . . . . . . . . . . 51
4.9 Interface « S’authentifier » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.10 Interface Superviseur « Consulter la liste des projets » . . . . . . . . . . . . . . 52
4.11 Interface Superviseur « Ajout projet » . . . . . . . . . . . . . . . . . . . . . . . 52
4.12 Interface Superviseur « Ajout client » . . . . . . . . . . . . . . . . . . . . . . . . 53
4.13 Interface Superviseur « Ajout parcelles » . . . . . . . . . . . . . . . . . . . . . . 53
4.14 Interface Superviseur « Ajout noeuds » . . . . . . . . . . . . . . . . . . . . . . . 54
4.15 Interface Superviseur « localiser un nœud » . . . . . . . . . . . . . . . . . . . . 54
4.16 Interface Superviseur « Consulter les détails d’un nœud » . . . . . . . . . . . . . 55
4.17 Interface Client « Consulter la liste des noeuds » . . . . . . . . . . . . . . . . . 55
4.18 Interface Client «Consulter les détailles d’un noeud» . . . . . . . . . . . . . . . 56

viii
Liste des tableaux

1.1 Comparaison des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Les caractéristique des technologies LPWAN . . . . . . . . . . . . . . . . . . . . 11

3.1 Cas d’utilisation : gestion des superviseurs . . . . . . . . . . . . . . . . . . . . . 30

3.2 Cas d’utilisation : gestion des projets de supervision . . . . . . . . . . . . . . . . 31
3.3 Cas d’utilisation : Ajouter un client . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Cas d’utilisation : gestion des projets de supervision . . . . . . . . . . . . . . . . 33
3.5 Cas d’utilisation :gestion des paramètres climatiques . . . . . . . . . . . . . . . . 33

4.1 Branchement du capteur DHT22 avec Lora E5 . . . . . . . . . . . . . . . . . . . 49

ix
Liste des abréviations

— IOT : Internet Of Things

— LPWAN : Low Power Wide Area Network

— MQTT : Message Queuing Telemetry Transport

— LoRaWAN : Long Range Wide Area Network

— OTAA : Over The Air Activation

— ABP : Activation By Personnalisation

— TTN : The Things Network

— FWI : Fire Weather Index

— FFMC : Fire Fuel Moisture Code

— DMC : Duff Moisture Code

— DC : Drought Code

— ISI : Initial Spread Index

— BUI : Buildup Index

x
Introduction générale

L’Internet des objets (IdO) ou Internet of Things (IoT) est un réseau d’objets physiques
tels que les appareils électroménagers les véhicules et autres dotés de capteurs et/ou actionneur,
des logiciels et d’une connectivité leur permettant de collecter, d’échanger et de recevoir de
donner d’autres objets connectés ou du réseau.

Un domaine où l’IoT peut avoir un impact significatif est la protection de l’environnement.

En connectant des appareils qui surveillent la qualité de l’air, la qualité de l’eau et d’autres
facteurs environnementaux, nous pouvons recueillir des données pour mieux comprendre l’état
de notre environnement et prendre des mesures pour le protéger.

C’est dans ce contexte et dans le cadre de notre formation de licence en ingénierie des
systèmes informatiques à la faculté des sciences de Bizerte que nous avons suivi un stage de fin
d’études au sein de la startup Smart For Green. En effet, le projet de notre stage consiste à la
conception et le développement d’un système de prédiction des incendies de forêt.

Pour atteindre notre but, le présent rapport décrit le travail réalisé. Il se compose de
quatre chapitres.
Le premier chapitre est un chapitre introductif qui sert à exposer l’étude préalable. Il
comprend la présentation de la société d’accueil, une étude et critique de l’existant. À la fin,
les solutions qu’on a dégagées pour répondre à la problématique de notre projet et le choix de
la solution adéquate ont été décrits.
Dans le deuxième chapitre, l’état de l’art . On va parler des réseaux de courte et de
longue portée, de la technologie LoRa et du protocole LoRaWan.
Le troisième chapitre est consacré à la conception de notre solution, les besoins fonctionnels,
les besoins non fonctionnels et les acteurs qui vont agir avec notre système sont décrits. En plus,
le plan d’action adopté et les diagrammes de cas d’utilisation sont illustrés.
Dans le quatrième chapitre, nous présentons les environnements matériels et logiciels de
développement, les technologies adoptées et la mise en œuvre de notre système.

1
 Chapitre 1

Contexte général du projet

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1.1 OFIDIA2, Greece-Italy (2014) . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1.2 Lesnoy Dozor, Russia (2018) . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1.3 Milesight IoT’s(2020) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1.4 DRYAD, Allemagne (2020) . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1. Contexte général du projet

1.1 Introduction

Dans ce chapitre, nous exposons le cadre général du projet. Nous présentons en premier
lieu l’organisme d’accueil. En deuxième lieu, nous expliquant la problématique ainsi que la
solution proposée.

1.2 Organisme d’accueil

Smart for Green est une Startup créée en 2022 au sein du centre local d’innovations de
Ras Djebel,Bizerte. Son activité principale est de proposer une multitude de services concernant
l’environnement et l’agriculture.
En effet, Smart for Green propose des solutions pour le secteur de l’agriculture. Le
concept vise à optimiser les pratiques agricoles en utilisant les technologies de l’information
et de la communication (TIC) pour collecter, analyser et utiliser les données sur les terres,
les cultures et les conditions météorologiques. L’objectif est d’améliorer la productivité, la
qualité des produits agricoles, la durabilité et la rentabilité de l’agriculture tout en préservant
l’environnement.
Par conséquent, Smart for Green propose également des activités axées sur la préservation
de notre écosystème. La startup s’engage à développer des solutions durables et respectueuses
de l’environnement pour relever les défis liés à la protection de notre environnement. Elle met
l’accent sur la gestion efficace des ressources naturelles, la réduction des déchets et la promotion
de pratiques respectueuses de l’écosystème. Grâce à ces initiatives, Smart for Green contribue à
la préservation de l’environnement et à la création d’un avenir plus durable pour les générations
futures.

Figure 1.1 : Logo Entreprise

3
Chapitre 1. Contexte général du projet

1.3 Problématique

Les incendies de forêt sont un problème majeur dans de nombreuses régions du monde,
causant des dégâts considérables à la faune et à la flore, aux habitations et aux infrastructures,
ainsi qu’à la santé humaine.
On constate que ce phénomène se multiplie dans le monde entier au cours des dernières
décennies en raison du changement climatique, de la déforestation, de l’urbanisation, de la
croissance démographique.
En effet, les incendies enregistrés au cours de l’été 2022, en Tunisie, ont détruit 5900
hectares de zones forestières, et ce, dans différents gouvernorats du pays[1]. C’est pour cela que
les incendies de forêt peuvent avoir des impacts sur la qualité de l’air, la santé humaine, la
biodiversité, la qualité de l’eau, le cycle du carbone et le changement climatique.
Ainsi, l’objectif de notre projet est de concevoir et de développer un système de surveillance
des incendies de forêt basé sur des capteurs afin de permettre une rapidité dans la prédiction
des départs de feu et de l’intervention des équipes de secours pour limiter leur propagation.

1.4 Étude et critique de l’existant

L’étude de l’existant permet de spécifier les solutions ayant le même objectif que la notre
ou un objectif rapproché. Ainsi, on peut dégager les points forts et faibles de ces solutions et
les utiliser dans la conception de notre solution.

1.4.1 Étude de l’existant

Dans le monde entier, les incendies de forêt sont un problème environnemental majeur qui
peut causer des dommages écologiques, économiques et humains considérables. Pour surveiller
et prévenir les incendies de forêt, de nombreuses initiatives ont été lancées dans différents pays.
Parmi ces initiatives, on peut citer des solutions dans ce qui suit.

1.4.1.1 OFIDIA2, Greece-Italy (2014)

OFIDIA2 [2] est une version élargie du projet OFIDIA, axée sur les régions des Pouilles et
de l’Épire, visant à améliorer la capacité opérationnelle des parties prenantes dans la détection
et la lutte contre les incendies de forêt afin de préserver l’environnement naturel et ses avantages
associés.
Le système effectue une surveillance en temps réel grâce à des données de capteurs et fournit
des prévisions météorologiques dans les deux régions. il comprend un modèle de projection de

4
Chapitre 1. Contexte général du projet

comportement d’incendie spécialement développé et une nouvelle salle de contrôle des feux de
forêt à la Protection civile des Pouilles. Le réseau offre une surveillance environnementale en
temps réel pour prévoir les risques d’incendie et adopter des stratégies de lutte efficaces. À
l’aide de caméras vidéo HD, de réseaux de capteurs sans fil et de drones, les parties prenantes
peuvent patrouiller efficacement les zones à haut risque et éloignées.
La figure 1.2 montre le résultat final du projet OFIDIA2.

Figure 1.2 : Projet OFIDIA2

1.4.1.2 Lesnoy Dozor, Russia (2018)

Le système « Lesnoy Dozor » [3] est un système automatisé d’alertes rapides aux incendies
de forêt. Il est conçu pour la prévention et la détection précoce des incendies de forêt en mode
en ligne.
En général, des capteurs "Lesnoy Dozor" sont installés sur tous les bâtiments de grande hauteur
alimentés en électricité.
Dans le "Lesnoy Dozor",les capteurs sont télécommandés et permet de faire des rotations (360°
– plan horizontal, minimum 90° – plan vertical,avec zoom). Bien qu’il n’y ait aucune limitation
d’équipement pour le système, les développeurs de la solution recommandent un certain type de
capteurs. Les capteurs qui sont installés sur les tours (ou similaires) à une hauteur suffisante (30
m) ont une zone de détection dans un rayon de 20-35 km. Naturellement, les caractéristiques
du système dépendent des conditions météorologiques et de la configuration du terrain.
La figure 1.3 montre le résultat final du projet Lesnoy Dozor.

5
Chapitre 1. Contexte général du projet

Figure 1.3 : Projet Lesnoy Dozor

1.4.1.3 Milesight IoT’s(2020)

La solution Milesight IoT’s [4] utilise le réseau LoRaWAN 1 pour surveiller le CO2
atmosphérique (dioxyde de carbone), la température, l’humidité et la pression barométrique
dans un capteur tout-en-un EM500-CO2. Il s’agit d’un capteur de dioxyde de carbone simple
d’utilisation, adapté à la détection de concentrations de CO2 (dioxyde de carbone) allant de
400 à 5000ppm.
La variation correspondante du niveau de CO2 (dioxyde de carbone) est détectée par le
capteur. le dernier recueille des données à un intervalle minimum de 2 minutes ou à un intervalle
maximum de 30 minutes. Une fois le niveau du CO2 dépasse les limites de tolérance prédéfinies,
le capteur signale la passerelle en temps opportun. Milesight Cloud obtient les données de la
passerelle et envoie une notification aux destinataires de l’alerte comme explique dans la figure
1.4 suivante.

Figure 1.4 : Architecture du projet Milesight IoT’s

1. LoRaWAN :Long Range Wide Area Network

6
Chapitre 1. Contexte général du projet

1.4.1.4 DRYAD, Allemagne (2020)

Le capteur de feux de forêt Silvanet est conçu pour détecter les incendies de forêt en
quelques minutes, souvent au début de leur phase de combustion, ce qui réduit considérablement
le risque de propagation incontrôlée. Il surveille également le microclimat de la forêt, en
mesurant la température, l’humidité et la pression atmosphérique. Le capteur combine une
détection de la qualité de l’air de très faible puissance avec un mode de détection de gaz précis.
Il détecte l’hydrogène, le monoxyde de carbone et d’autres gaz et est livré avec l’intelligence
artificielle intégrée pour détecter de manière fiable un incendie et éviter les faux positifs.
L’objet formé par le capteur de feux de forêt utilise les communications LoRaWAN pour la
transmission de données sans fil et peut fonctionner sans entretien pendant 15 ans sans avoir
besoin de piles, évitant ainsi l’utilisation de lithium et d’autres matières toxiques.
La figure 1.5 montre le résultat final du projet DRYAD [5].

Figure 1.5 : Projet DRYAD

1.4.2 Critique de l’existant

Dans le tableau 1.1 on peut voir les solutions existantes et leurs points faibles et forts

7
Chapitre 1. Contexte général du projet

Tableau 1.1 : Comparaison des projets

Prédiction détection Faible consommation d’énergie Module de communication

Milesight IoT’s - + - +

Lesnoy Dozor - + + -

OFIDIA2 - + - +

DRYRD - + + +

D’autre part, il convient de mentionner certaines limitations supplémentaires :

• Les coûts d’installation et de maintenance d’un système de surveillance des incendies de

forêt peuvent être très élevés. Cela peut être un obstacle pour les gouvernements et les
organisations qui ne disposent pas d’un budget suffisant pour financer un tel projet.

• L’installation d’un système de surveillance des incendies de forêt peut être difficile dans
des zones reculées et accidentées, ce qui peut rendre le projet plus coûteux et plus difficile
à mettre en place.

• Il existe des obstacles liés à la portée des systèmes de surveillance des incendies de forêt.
On parle ici de la couverture du réseau. Les zones forestières sont souvent isolées et
éloignées des centres urbains, ce qui peut rendre difficile l’accès à une infrastructure de
communication fiable. De plus, la topographie du terrain, les obstacles naturels tels que les
collines, les montagnes et les arbres, ainsi que les conditions météorologiques défavorables
peuvent affecter la portée du signal et rendre la surveillance plus difficile. Ce qui cause le
problème de fiabilité et de précision des données collectées

• La consommation d’énergie, le facteur le plus important dans les projets de l’Internet des
objets, est la capacité du Hardur à fonctionner le plus longtemps possible sans interférence
humaine pour alimenter. Par exemple, les drones qui utilisent la surveillance forestière ne
sont pas conformes à cette norme parce qu’ils devront recharger les batteries périodiquement.

Ces limitations soulignent les défis auxquels sont confrontés les projets existants et mettent en
évidence la nécessité de trouver des solutions efficaces et adaptées pour une surveillance des
incendies de forêt plus fiable et durable.

1.4.3 Solution proposée

Suite à l’étude que nous avons mené sur la solution existante et au regard des inconvénients
recensés plus haut, il est primordial de proposer une solution qui pourra mieux répondre
aux besoins actuels. Nous proposons un système intelligent basé sur l’IoT. notre système est

8
Chapitre 1. Contexte général du projet

un noeud capteur Lora qui mesure les paramètres climatiques permettant la prédiction des
incendies de forêts et des grandes cultures.
Ces caractéristiques peuvent ensuite être utilisées pour déclencher des alertes pour prédire
un incendie de forêt.
De plus, notre solution consiste à concevoir une application web qui permet aux utilisateurs
de visualiser les caractéristiques nécessaires des forêts ou fermes.
La figure 1.6 présente l’architecture générale de notre solution. Dans la figure 1.6, nous
décrivons de façon détailler le fonctionnement de notre système. La présentation des éléments
de la figure 1.6 vont faire l’objet du chapitre suivant, état de l’art. La conception et la réalisation
de notre solution seront faits dans les chapitres 3 et 4.

Figure 1.6 : Architecture générale de la solution proposée

1.5 Conclusion

Ce chapitre a introduit le contexte général du projet en présentant l’organisme d’accueil

et en exposant la problématique à résoudre ainsi que la solution proposée. L’organisme d’accueil
a été présenté avec ses objectifs en lien avec la protection de l’environnement et le développement
durable. La problématique a été identifiée, soulignant les défis existants, et la solution proposée
a été présentée comme une réponse efficace et durable à ces problèmes. Ces éléments fournissent
une base solide pour la suite du document, où les détails opérationnels du projet seront
approfondis.

9
 Chapitre 2

Etat de l’art

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Les réseaux LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Les réseaux cellulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Les réseaux non cellulaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Choix du Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.4 LoraWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.4.1 Architecture de réseau LoRaWAN : . . . . . . . . . . . . . . . . . . . 13

2.2.4.2 La Technologie LoRa : . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4.3 Les paramètres de LoRa : . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4.4 Le Protocole LoRaWAN : . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4.5 La securité de LoraWAN : . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Protocole de communication : MQTT . . . . . . . . . . . . . . . . . . . . . . 18

2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Modélisation du risque de départ du feu . . . . . . . . . . . . . . . . . . . . 20

2.4.1 La méthode d’Angström de calcul du risque de départ de feu . . . . . . . . . . 20

2.4.2 La méthode Américaine de calcul du risque de départ de feu . . . . . . . . . . 20

2.4.3 La méthode de Baumgartner de calcul du risque de départ de feu . . . . . . . 20

2.4.4 La méthode Canadienne de calcul du risque de départ de feu . . . . . . . . . . 21

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapitre 2. Etat de l’art

2.1 Introduction

Dans ce chapitre, nous nous intéressons aux concepts de base liés à notre travail.Nous
commencerons par un aperçu général sur les LPWAN. Ensuite, nous introduisons quelques
aspects de notre réseau utilisé LoraWAN. Puis, nous présentant le protocole de communication
utilisé. Enfin,Nous examinerons également la modélisation du risque de départ de feu.

2.2 Les réseaux LPWAN

Les technologies cellulaires classiques sont efficaces pour couvrir de larges distances et ont
été conçues pour transmettre sur des grandes distances. Ces technologies ont été conçues pour
transmettre des grandes quantités d’informations. Elles sont ainsi gourmandes en consommation
d’énergie avec des coûts matériels élevés.
Pour résoudre ce problème, un nouveau réseau a été développé : LPWAN 1 [6] ou réseau étendu
à faible consommation d’énergie. Les réseaux LPWAN sont une classe de technologies de réseau
sans fil étendu à faible consommation. Depuis lors, le LPWAN est devenu la meilleure solution
pour les systèmes IoT et M2M qui nécessitent une faible consommation d’énergie tout en ayant
une large porté.
Le tableau 2.1 présent les technologies LPWAN qui sont les plus utilisé

Tableau 2.1 : Les caractéristique des technologies LPWAN

Technologies sans fil Topologie de réseau Débit Bandes de fréquences Norme Couverture Consommation d’énergie
LoRaWAN Etoile des Etoiles 0,2-27 Kbps Divers, sub-gighertz LoRaWAN 5Km urbain, 15Km rural Trés faible
Sigfox Etoile 100 bitps 868 MHz Sigfox 10Km urbain 50Km rural Trés faible
LTE-M 1 Mbps 2.4GHz IEEE 802.15.4 10-300m Trés faible

On distingue deux catégories de réseau LPWAN :

• Les réseaux LPWAN cellulaires comme LTE-M, NB-IoT. . .

• Les réseaux LPWAN non-cellulaire, des réseaux dédiés à l’IoT comme le réseau sigfox et

le réseau ouvert LoRaWAN de l’entreprise Semtech.

2.2.1 Les réseaux cellulaires

La LPWAN cellulaire est une technologie de communication à faible consommation

d’énergie utilisée pour les applications IoT et M2M. Elle utilise les réseaux cellulaires existants
1. LPWAN :Low Power Wide Area Network

11
Chapitre 2. Etat de l’art

pour permettre la transmission de données à longue distance et à faible coût. Des technologies
telles que le Nb-IoT et le LTE-M ont été développées pour améliorer les communications
machine dans ce domaine.

2.2.2 Les réseaux non cellulaires

Ils sont prévus pour remonter des informations simples de capteurs et de localisation.
Les principaux objectifs de ces protocoles sont :

• Une faible consommation

• Une grande distance de communication (plusieurs km)
• La très forte densité d’objets connectables

Parmi les réseaux non cellulaires on a :

• Sigfox : Sigfox est un opérateur IoT français propriétaire de sa technologie qui a été créé

en 2009. Les objets connectés avec ce protocole peuvent émettre 12 octets max et cela 140
fois par jour, et recevoir 8 octets. La portée atteint 10km en ville et 30 à 50km en milieu
rural.
• LoRa : La technologie LoRa permet notamment la transmission de données de faible

volume par des capteurs fixes. Le principe est de transmettre des données par liaison
hertzienne depuis des capteurs à faible puissance d’émission, potentiellement isolés ou
difficile d’accès, fonctionnant sur batterie pour 5 à 10 ans [7] . LoRa utilise le protocole
LoraWAN.

2.2.3 Choix du Réseau

Les raisons pour lesquelles nous avons choisi LoRa plutôt que SigFox sont :
• Portée plus longue : LoRa offre généralement une portée plus longue que SigFox. Il peut
transmettre des données sur plusieurs kilomètres dans un environnement ouvert, ce qui le rend
adapté aux applications nécessitant une connectivité longue portée.
• Personnalisation et évolutivité : LoRa offre une plus grande flexibilité dans la personnalisation
et l’évolutivité. Vous pouvez créer et gérer votre propre réseau LoRaWAN ou choisir parmi
différents fournisseurs de services LoRaWAN. Cela vous donne plus de contrôle sur les paramètres
réseau, les débits de données et les fonctionnalités de sécurité.

2.2.4 LoraWAN

LoraWAN opère dans la gamme de fréquences ISM sans licence, qui utilise 868 MHz en
Europe et 915 MHz en Amérique du Nord.

12
Chapitre 2. Etat de l’art

Il convient de noter que LoRa représente la couche physique radiofréquence et LoRaWAN

représente la couche protocole.

2.2.4.1 Architecture de réseau LoRaWAN :

Les réseaux LoRaWAN sont déployés selon une topologie en et se compose des éléments
suivants :

- Les noeuds ou les terminaux (peuvent être des capteurs ou actionneurs) ;

- Gateways ;
- Serveur de réseau (un logiciel fonctionnant sur un serveur qui gère tout le réseau) ;
- Serveurs d’application.

La figure 2.1 montre l’architecture de LoraWAN :

Figure 2.1 : Architecture de LoraWAN

• Les noeuds :

Un noeud LoRaWAN peut être un capteur, un actionneur ou les deux simultanément.

Ils fonctionnent souvent sur batterie. Ces terminaux sont connectés sans fil au réseau
LoRaWAN par des Gateways.
• Les passerelles :

Chaque gateway est enregistrée (à l’aide de paramètres de configuration) sur un serveur

de réseau LoRaWAN. Une gateway reçoit les messages des terminaux et les transmet
simplement au serveur de réseau LoRaWAN. Les Gateways sont connectées au serveur
de réseau à l’aide d’un lien tel qu’un lien cellulaire (3G/4G/5G), WLAN, Ethernet, fibre
optique ou radio 2,4 GHz.

13
Chapitre 2. Etat de l’art

• Serveur réseau

Le serveur de réseau typique gère les Gateways, les terminaux, les applications et les
utilisateurs de l’ensemble du réseau LoRaWAN, en fait Il agit comme un point central de
contrôle et de coordination pour le réseau et fournit des fonctionnalités clés telles que la
gestion des protocoles de communication, la sécurité, l’authentification des dispositifs et
le routage des données.

The Things Network : example d’un serveur réseau.

The Things Network TTN 2 est une infrastructure de réseau ouvert et participatif pour
l’Internet des Objets. Elle est basée sur la technologie LoRaWAN.
Le réseau TTN offre une gamme de services et de fonctionnalités, notamment une communication
sécurisée de bout en bout, des services de localisation et une intégration avec des services
cloud tels qu’Amazon Web Services et Microsoft Azure. Il offre également une gamme
d’outils de développement et de ressources, tels que des API, des bibliothèques de logiciels
et des tutoriels, pour aider les développeurs à se lancer dans la création d’applications
IoT.

Figure 2.2 : Logo TTN

• Serveur d’application :

Le serveur d’application joue le rôle d’interface utilisateur, il traite les messages de données
spécifiques reçus des terminaux et génère également toutes les charges utiles de downlink
de la couche application et les envoie aux terminaux connectés par l’intermédiaire du
serveur de réseau. Un réseau LoRaWAN peut comporter plus d’un serveur d’application.

2.2.4.2 La Technologie LoRa :

c’une technique de modulation sans fil dérivée de la technologie CSS 3 , elle code les
informations sur les ondes radio à l’aide d’impulsions chirp. La transmission modulée LoRa
est robuste contre les perturbations et peut être reçue sur de grandes distances. Un chirp est
2. TTN :The Things Network
3. CSS :Chirp Spread Spectrum

14
Chapitre 2. Etat de l’art

un signal pseudopériodique modulé en fréquence autour d’une fréquence porteuse et également

modulé en amplitude, donc c’est une sorte de fusion des modulations fréquence et amplitude
en même temps. LoRa fonctionne dans la bande ISM : 868 MHz et 433 MHz pour l’Europe et
915 MHz pour l’USA et 430 MHZ pour l’Asie.

Figure 2.3 : Logo Lora

2.2.4.3 Les paramètres de LoRa :

Le duty cycle, le taux de transmission TX 4 et le facteur d’étalement SF 5 sont tous des

paramètres importants dans la modulation lora.

• Le duty cycle : Le duty cycle fait référence à la proportion de temps pendant laquelle un

dispositif LoRa peut transmettre des données par rapport à la durée totale de l’intervalle
de temps. Cette limite est souvent réglementée par les organismes de régulation en matière
de fréquences radio pour éviter les interférences avec d’autres dispositifs utilisant les mêmes
fréquences. Il est donc important de respecter cette limite pour garantir un fonctionnement
fiable et éviter les pénalités légales.

• Le taux de transmission (TX) : Le taux de transmission fait référence à la vitesse à

laquelle les données sont transmises sur le réseau LoRaWAN. Plus le taux de transmission
est élevé, plus la quantité de données transmises est grande et plus la durée de transmission
est courte. Cependant, un taux de transmission élevé peut entraîner une diminution de la
portée du signal, ce qui peut limiter la couverture du réseau.

• Le facteur d’étalement (SF) : Le facteur d’étalement détermine la vitesse de propagation

des données sur le réseau LoRaWAN. Plus le SF est élevé, plus la portée du signal est
grande, mais le temps nécessaire pour transmettre les données est également plus long.
Le choix du SF doit donc être optimisé en fonction de la distance de transmission, de la
taille des données à transmettre et de la durée de transmission souhaitée.

En somme, ces paramètres doivent être soigneusement configurés pour assurer une communication
fiable et efficace dans un réseau LoRaWAN, tout en respectant les réglementations en matière
4. TX :Transmission
5. SF :Spreading Factor

15
Chapitre 2. Etat de l’art

de fréquences radio.

2.2.4.4 Le Protocole LoRaWAN :

LoRaWAN est un protocole de couche de contrôle d’accès au média MAC 6 construit

sur la modulation LoRa. Il s’agit d’une couche logicielle qui définit la façon dont les appareils
utilisent le matériel LoRa, par exemple quand ils transmettent, et le format des messages.
LoRaWAN est un protocole ouvert et standardisé, ce qui signifie qu’il est compatible avec un
large éventail de dispositifs IoT et peut être utilisé dans de nombreuses applications différentes,
telles que la surveillance de la santé des récoltes, la gestion de la consommation d’énergie, la
surveillance des réseaux de transport, etc. La couche protocolaire de réseau LoRa est organisée
en trois couches principales :

• La couche physique :
Elle définit la modulation radio utilisée pour transmettre les données, ainsi que les paramètres
de transmission tels que la puissance de transmission, la largeur de bande et le débit
binaire. La couche physique de LoRa utilise une modulation à spectre étalé chirp pour
transmettre des signaux sur de longues distances.
• La couche liaison de données (Data Link Layer) :
Elle gère la communication entre les noeuds LoRa et les passerelles LoRa. Cette couche
est responsable de la gestion de l’accès au canal radio partagé, de la gestion des collisions
et de l’assurance qualité de la transmission des données. Elle est basée sur le protocole
LoRaWAN qui utilise la technique d’évitement de collisions ALOHA.
• La couche application :
Cette couche est responsable de la gestion des données d’application qui sont échangées
entre les noeuds finaux et les serveurs de réseau, elle utilise un format de message appelé «
payload » pour encapsuler les données de l’application. Le payload peut contenir différents
types de données, tels que des capteurs, des commandes, des notifications, etc. Ces données
sont envoyées sous forme de trames radio LoRa, qui sont transmises à travers le réseau
LoRaWAN jusqu’à leur destination.
La figure 2.4 montre les couches protocolaires de LoRa c’est l’équivalent de modèle OSI :[8]

6. MAC :Media Access Control

16
Chapitre 2. Etat de l’art

Figure 2.4 : Les couches protocolaires LoRa.

2.2.4.5 La securité de LoraWAN :

Lorsque nous parlons de la sécurité de LoRaWAN, l’une des choses les plus importantes
à considérer sont les méthodes d’activation des nœuds. LoRaWAN propose deux méthodes
principales : OTAA 7 et ABP 8 .

• OTAA : Cette méthode d’activation est la plus courante dans les réseaux LoRaWAN. Avec
OTAA, le nœud LoRaWAN envoie une demande d’activation au réseau. Le réseau répond
en envoyant une clé de session temporaire (AppSKey) et une clé de réseau (NwkSKey) au
nœud. Le nœud utilise ensuite ces clés pour chiffrer et déchiffrer les messages qui seront
envoyés au réseau. L’OTAA est considérée comme plus sécurisée que l’ABP car elle génère
des clés de session temporaires à chaque activation, réduisant ainsi les risques de piratage
et d’espionnage. La figure 2.5 illustre le procedure de l’activation OTAA dans le protocole
LoRaWAN version 1.0.x. [9]
7. OTAA :Over-The-Air Activation
8. Activation By Personalization

17
Chapitre 2. Etat de l’art

Figure 2.5 : Procédure OTAA.

• ABP : les clés de session (AppSKey et NwkSKey) sont préconfigurées sur le nœud LoRaWAN.
Le nœud utilise ces clés pour chiffrer et déchiffrer les messages envoyés au réseau. L’ABP
est considérée comme moins sécurisée que l’OTAA car les clés de session sont statiques et
peuvent être plus facilement compromises.

Les deux méthodes d’activation ont leurs avantages et leurs inconvénients. L’OTAA est plus
sécurisée mais nécessite une étape d’activation supplémentaire, qui peut prendre plus de temps
et consommer plus d’énergie. L’ABP, en revanche, est plus rapide et plus simple, mais est moins
sécurisée.

2.3 Protocole de communication : MQTT

2.3.1 Description

MQTT 9 est un protocole de communication léger et distribué qui permet la transmission

de messages entre des appareils connectés à Internet des objets ou à d’autres réseaux. MQTT est
souvent utilisé dans les applications IoT pour la collecte de données, la surveillance à distance
et la commande d’appareils.
MQTT est conçu pour être très peu gourmand en bande passante, ce qui le rend
adapté aux réseaux à faible débit et à faible puissance, tels que les réseaux LoRaWAN et
les réseaux de capteurs. Il est également sécurisé grâce à des fonctionnalités de chiffrement et
9. MQTT :Message Queuing Telemetry Transport

18
Chapitre 2. Etat de l’art

d’authentification, ce qui le rend adapté à une large gamme d’applications IoT.

2.3.2 Architecture

L’architecture de MQTT est basée sur un modèle de publication/abonnement ou les

appareils connectés peuvent envoyer des messages à des canaux appelés "topics", et les autres
appareils peuvent s’abonner à ces topics pour recevoir les messages.
Le modèle de publication/abonnement est composé de trois éléments principaux : le broker,
les clients publish et les clients subscribe.

• Broker : Le broker MQTT est un serveur qui gère la communication entre les clients publish
et les clients subscribe. Le broker reçoit les messages publiés par les clients publish et les
transmet aux clients subscribe qui sont abonnés aux mêmes topics.
• Clients publish : Les clients publish sont des appareils qui envoient des messages à des
topics spécifiques. Les messages peuvent contenir des données telles que des informations
de capteurs.
• Clients subscribe : Les clients subscribe sont des appareils qui s’abonnent à des topics
spécifiques pour recevoir les messages publiés sur ces topics. Les messages peuvent être
utilisés pour afficher des informations.

Les clients MQTT peuvent être des appareils physiques tels que des capteurs, des actionneurs
ou des passerelles IoT, ou des applications logicielles qui utilisent le protocole MQTT pour
communiquer avec des appareils IoT.
La figure 2.6 illustre l’architecture du protocole MQTT.[10]

Figure 2.6 : Architecture du protocole MQTT

19
Chapitre 2. Etat de l’art

2.4 Modélisation du risque de départ du feu

2.4.1 La méthode d’Angström de calcul du risque de départ de feu

L’indice d’Angström est un indice d’incendie très simple développé en Suède et conçu
pour être calculé mentalement. Il ne nécessite que l’humidité relative et la température comme
variables d’entrée. Il a été utilisé dans certaines régions de Scandinavie pour indiquer les
départs de feu prévus un jour donné. L’un des inconvénients de l’indice d’Angström est qu’il ne
reflète pas correctement la relation entre l’humidité relative, la température et l’humidité du
combustible.

2.4.2 La méthode Américaine de calcul du risque de départ de feu

Le système national d’évaluation du danger d’incendie (NFDRS) a été développé aux

États-Unis à la fin des années 1960 et est devenu opérationnel en 1972. Le NFDRS a été mis à
jour en 1977, puis révisé afin de mieux fonctionner dans les conditions humides qui prévalent
dans l’est des États-Unis.
Le NFDRS évalue le danger d’incendie en évaluant la limite supérieure du comportement
des incendies potentiels dans la zone d’évaluation et vise à fournir des orientations pour la
planification des mesures de pré-suppression et de suppression.

2.4.3 La méthode de Baumgartner de calcul du risque de départ de feu

L’indice de Baumgartner est un indice de danger d’incendie développé en Bavière (Allemagne),

basé sur le concept selon lequel le danger d’incendie est principalement conditionné par la
sécheresse du combustible qui, à son tour, dépend de l’évapotranspiration. Baumgartner a
donc conçu un indice constitué de la différence entre l’évapotranspiration potentielle et les
précipitations. Le calcul de l’indice de Baumgartner nécessite les précipitations quotidiennes et
l’évapotranspiration potentielle comme variables d’entrée. Bien qu’il y ait été conçu, Langholz et
Schmidtmayer ont trouvé l’indice de Baumgartner relativement inadapté pour prédire le danger
d’incendie en Bavière, surtout au printemps où l’inflammabilité de la litière morte dépend moins
des précipitations des cinq derniers jours que des conditions de sécheresse actuelles ou à court
terme.

20
Chapitre 2. Etat de l’art

2.4.4 La méthode Canadienne de calcul du risque de départ de feu

La méthode canadienne de calcul du risque de départ de feu FWI est un système d’indice
de danger météorologique utilisé pour évaluer le potentiel de départ de feu et de propagation
dans les forêts. Le système a été développé par le Service canadien des forêts en 1961 et il a été
modifié ou amélioré plusieurs fois depuis lors.
La méthode FWI utilise des données météorologiques telles que la température, l’humidité
relative, le vent et les précipitations pour calculer deux indices : l’indice d’humidité des combustibles
(FFMC) et l’indice de danger d’incendie (FWI).
Dans notre solution, nous allons utiliser le système FWI car il est largement utilisé, avec
ou sans adaptation aux conditions locales, dans d’autres régions ou pays que le Canada, comme
l’Alaska, certains États du nord de l’Amérique, le Mexique, la Nouvelle-Zélande, la France, le
Portugal ou l’Asie du sud-est.
La figure 2.7 illustre les degrés du risque coloriés basant sur l’indice de danger FWI.

Figure 2.7 : Risques feu forets avec FWI

21
Chapitre 2. Etat de l’art

• Structure du FWI

La figure 2.8 illustre la structure de l’indice de danger des incendies FWI.[11]

Figure 2.8 : Structure du FWI

FFMC 10 DMC 11 DC 12 ISI 13 BUI 14 FWI 15

10. FFMC :Fire Fuel Moisture Code

11. DMC :Duff Moisture Code
12. DC :Drought Code
13. ISI :Initial Spread Index
14. BUI :Buildup Index
15. FWI :Fire Weather Index

22
Chapitre 2. Etat de l’art

Nous expliquons dans ce qui suit les paramètres de la figure 2.8 :

• FFMC :

Il s’agit d’une évaluation numérique de la teneur en humidité de la litière de surface et d’autres

combustibles fins durcis. Il montre la facilité relative d’inflammation et d’ inflammabilité des
combustibles fins. La teneur en humidité des combustibles fins est très sensible à la météo. Même
un jour de pluie, ou de temps fin et venteux, affectera de manière significative le classement
FFMC. Le système utilise un décalage de deux tiers d’une journée pour mesurer avec précision
la teneur en humidité des combustibles fins. La notation FFMC est sur une échelle de 0 à 99.
Tout chiffre supérieur à 70 est élevé, et supérieur à 90 est extrême.

• DMC :

C’est une estimation numérique de la teneur en humidité moyenne des couches organiques
faiblement compactées de profondeur modérée. Le code indique la profondeur que le feu va
brûler dans les couches modérées du duvet. Les couches prennent plus de temps que les
combustibles de surface à s’assécher, mais les conditions météorologiques du passé c’est à dire
environs quelques semaines affectera de manière significative le DMC. Le système applique un
délai de 12 jours pour calculer le DMC. Une note de DMC de plus de 30 est sèche, et plus de
40 indique qu’un brûlage intensif se produira

• DC :

C’est une estimation numérique de la teneur en humidité des couches organiques profondes et
compactes. C’est un indicateur de la sécheresse saisonnière et montre la probabilité d’incendie
impliquant les couches profondes . Une longue période de temps sec (le système utilise 52 jours)
est nécessaire pour assécher les végétaux et les affecter Le code de sécheresse de 200 est élevé, et
300 ou plus est extrême indiquant que le feu impliquera les sous-sols profonds et les combustibles
lourds.

• ISI :

Il indique la propagation du feu à ses débuts. Il est calculé à partir de la notation FFMC et du
facteur vent. L’échelle ISI commence à 0 et une note de 10 indique un taux de propagation élevé
peu après le départ de feu. Une note de 16 ou plus indique un taux de propagation extrêmement
rapide.

• BUI :

23
Chapitre 2. Etat de l’art

Cette valeur indique comment le feu se développera après propagation initiale. Il est calculé à
partir du Duff Moisture Code et du code de sécheresse. L’échelle BUI commence à 0. Une note
supérieure à 40 est élevée, une valeur de 60 est extrême.

• FWI :

L’information provenant de l’ISI et du BUI est combinée pour fournir une évaluation numérique
de l’intensité du feu. L’IFM indique l’intensité probable d’un incendie. L’IFM est divisé en 5
classes de danger d’incendie :
BAS 0 - 7
MODERE 8 - 16
HAUT 17 - 25
TRES HAUT 26 - 31
EXTREME 31+

2.5 Conclusion

Ce chapitre constitue un point de départ essentiel pour notre travail. Il nous permet de
comprendre les concepts de base du réseau LoraWAN, du protocole d’échange des données et
de la modélisation du risque de départ de feu. Dans le chapitre suivant, nous nous intéressons
à l’étude conceptuelle de notre système.

24
 Chapitre 3

Étude Conceptuelle

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.3 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 Vue statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.2 Vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.2.1 Diagrammes des séquences . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapitre 3. Étude Conceptuelle

3.1 Introduction

Dans ce chapitre, nous allons d’abord identifier les acteurs de notre système et détailler
ensuite leurs besoins fonctionnels, non fonctionnels. Par la suite, nous allons présenter la
conception et l’architecture de la solution afin de rapprocher au plus près d’une vision concrète
du système à mettre en place.

3.2 Analyse et spécification des besoins

3.2.1 Identification des acteurs

Les acteurs qui interagissent avec notre système sont :

• Administrateur : C’est le responsable de la gestion des superviseurs.
• Superviseur :Un utilisateur de l’application se charge principalement de gérer les projets
de surveillance, gérer les noeuds et gérer les clients.
• Client : Sera capable de consulter le tableau de bord et recevoir des alertes de prédiction.
• noeud : des acteurs secondaires qui envoient périodiquement les informations climatiques
nécessaires collectées .
• service météo : acteur secondaire qu’on interroge périodiquement pour obtenir les
informations climatiques nécessaires.

3.2.2 Spécification des besoins

Cette étape consiste à déterminer les fonctionnalités attendues par les utilisateurs de
notre application et les contraintes régissant notre système. Dans ce qui suit, nous allons
présenter les spécifications fonctionnelles , non fonctionnelles de notre projet.

3.2.2.1 Besoins fonctionnels

Dans cette partie, nous définissons les exigences fonctionnelles qui représentent les actions
que le système doit garantir afin de satisfaire les besoins de ses utilisateurs.
Notre système de surveillance des incendies de forêts se répartit en deux modules fondamentaux :
— Module de système embarqué et IoT.
— Module d’application web.
Les besoins fonctionnels concernant le système embarqué et IoT sont liés à la carte
utilisée se résument-en :
- L’alimentation en énergie pour pouvoir actionner les capteurs.

26
Chapitre 3. Étude Conceptuelle

- La récupération des valeurs des différents capteurs, les paramètres climatiques (température
, humidité).
Les besoins fonctionnels concernant l’application web sont classés par acteur :

• Administrateur

- S’authentifier : L’application doit garantir aux administrateurs l’accès à la base de

donnée en faisant remplir un champ identifiant et un champ mot de passe.
- gérer les superviseurs :

- Ajouter de nouveaux superviseurs

- Supprimer des superviseurs
- Modifier les données des superviseurs
- Consulter la liste des superviseurs
• Superviseur

- S’authentifier L’application doit garantir aux superviseurs l’accès à l’application en

faisant remplir un champ pseudo et un champ mot de passe.
- gérer les projets de supervision :
- Ajouter un nouveau projet de supervision
- Supprimer un projet de supervision
- Modifier un projet de supervision
- Consulter un projet de supervision
- gérer les clients
- Ajouter un nouveau client
- Consulter un client
- gérer les noeuds :
- Ajouter un nouveau noeud
- Supprimer un noeud
• client :forestier/fermier/citoyens/visiteurs

- S’authentifier L’application doit garantir au client l’accès à l’application en faisant

remplir un champ pseudo et un champ mot de passe.
- consulter le tableau de bord du projet pour la prédiction des incendies
- recevoir des alerte de prédiction en cas de feu

3.2.2.2 Besoins non fonctionnels

Dans cette partie, nous allons traiter les besoins non fonctionnels de notre solution.
Les besoins non fonctionnels concernant le système embarqué et IoT :

27
Chapitre 3. Étude Conceptuelle

• Fiabilité : Le système doit être fiable et fournir des résultats précis et cohérents en tout

temps. Les erreurs de détection ou de prévision peuvent avoir des conséquences graves, il
est donc essentiel que le système fonctionne de manière fiable.
• Performance : le système doit être capable de traiter rapidement les données collectées et

d’envoyer des alertes en temps réel.

• Disponibilité : le système doit être disponible 24 heures sur 24 et 7 jours sur 7 pour garantir

une surveillance constante des forêts.

• Évolutivité : le système doit être évolutif et être capable de gérer des forêts de différentes

tailles et de s’adapter à des environnements différents.

Les besoins non fonctionnels concernant l’application web :

• Sécurité : l’application web doit être sécurisée pour protéger les données sensibles des

utilisateurs et prévenir les attaques malveillantes.

• Maintenance : l’application web doit être facile à maintenir et à mettre à jour pour garantir

sa stabilité et sa disponibilité à long terme.

3.2.3 Modélisation des besoins

Après avoir citer les fonctionnalités de notre système, nous allons les modéliser à l’aide
des diagrammes de cas d’utilisation en utilisant le langage UML pour mieux comprendre les
interactions entre l’utilisateur et le système.

• Diagramme de cas d’utilisation Global

Nous présentons par la figure 3.1 le diagramme de cas d’utilisation global qui donne une
vue générale sur le comportement fonctionnel de notre système.
Le diagramme de cas d’utilisation général montre trois acteurs de même type utilisateur.
Tous les cas d’utilisation sont conditionnés par l’authentification, ce qui est exprimé par
une relation include entre tous les cas d’utilisation et le cas d’utilisation «s’authentifier»

28
Chapitre 3. Étude Conceptuelle

Figure 3.1 : Diagramme de cas d’utilisation Global

Afin d’expliquer les droits d’accès pour chaque acteur, nous présenterons dans la suite les
diagrammes des cas d’utilisation détaillés.

• Gestion des superviseurs

La figure 3.2 explique le cas d’utilisation "gestion des superviseurs".

Le tableau 3.1 représente la description textuelle du cas d’utilisation "gestion des superviseurs"

29
Chapitre 3. Étude Conceptuelle

Figure 3.2 : Cas d’utilisation : gestion des superviseurs

Tableau 3.1 : Cas d’utilisation : gestion des superviseurs

Titre Gestion des superviseurs

Acteurs Administrateur

Pré condition Administrateur authentifié

Post condition Action de gestion effectuée sur le superviseur :

superviseur créé ou supprimé ou modifié

Scénario principal La possibilité de :

1- Ajout d’un nouveau superviseur
2- Modification des données d’un superviseur
3- Suppression d’un superviseur
4- Consultation d’un superviseur

Exception 1.1- Erreur de saisie lors de l’ajout

2.2- Erreur de saisie lors de la modification

• Gestion des projets de supervision

La figure 3.3 explique le cas d’utilisation "gestion des projets de supervision".

Le tableau 3.2 représente la description textuelle du cas d’utilisation "gestion des projets
de supervision"

30
Chapitre 3. Étude Conceptuelle

Figure 3.3 : Cas d’utilisation : gestion des projets de supervision

Tableau 3.2 : Cas d’utilisation : gestion des projets de supervision

Titre Gestion des projets de supervision

Acteurs Administrateur , Superviseur

Pré condition Administrateur ou Superviseur authentifié

Post condition Action de gestion effectuée sur le projet de

supervision : projet créé ou supprimé ou modifié

Scénario principal La possibilité de :

1- Ajout d’un nouveau projet de supervision
2- Modification d’un projet de supervision
3- Suppression d’un projet de supervision
4- Consultation d’un projet de supervision

Exception 1.1- Erreur de saisie lors de l’ajout

2.2- Erreur de saisie lors de la modification

• Gestion des clients

La figure 3.4 explique le cas d’utilisation "gestion des clients".

Le tableau 3.3 représente la description textuelle du cas d’utilisation "Ajouter un client"

31
Chapitre 3. Étude Conceptuelle

Figure 3.4 : Cas d’utilisation : gestion des clients

Tableau 3.3 : Cas d’utilisation : Ajouter un client

Titre Ajouter un client

Acteurs Administrateur , Superviseur

Pré condition Administrateur ou Superviseur authentifié

Post condition Client créé

Scénario principal 1- Le superviseur remplit les champs nécessaires

2- Il confirme

Exception 1.1- Erreur de saisie lors

2.1- Client existe déjà

• Gestion des noeuds

La figure 3.5 explique le cas d’utilisation "gestion des noeuds".

Figure 3.5 : Cas d’utilisation : gestion des noeuds

Le tableau 3.4 représente la description textuelle du cas d’utilisation "consulter un noeud"

32
Chapitre 3. Étude Conceptuelle

Tableau 3.4 : Cas d’utilisation : gestion des projets de supervision

Titre Consulter un noeud

Acteurs Administrateur , Superviseur

Pré condition Administrateur ou Superviseur authentifié

Post condition Noeud consulté

Scénario principal 1- En cliquant sue le bouton "visualize" le superviseur

peut visualiser le noeud qu’il a créé.

Exception

• Gestion des paramètres climatiques

La figure 3.6 explique le cas d’utilisation "gestion des paramètres climatiques".

Figure 3.6 : Cas d’utilisation : gestion des paramètres climatiques

Le tableau 3.5 représente la description textuelle du cas d’utilisation "gestion des paramètres
climatiques"

Tableau 3.5 : Cas d’utilisation :gestion des paramètres climatiques

Titre Gestion des paramètres climatiques

Acteurs Capteurs , service météo

Pré condition -

Post condition -

Scénario principal 1- Dans cette partie, le serveur va vérifier les données

climatiques prévenant des capteurs et les données
prévenant du l’API "openWeather" puis les enregistrer
dans sa base de données.

Exception

33
Chapitre 3. Étude Conceptuelle

3.3 Conception détaillée

En se basant sur les informations précédentes, nous avons eu une vision plus concrète des
besoins de notre application. Dans cette partie nous abordons la conception du projet,
dans laquelle, nous détaillons les différents éléments de conception, à savoir les diagrammes
de séquences, et le diagramme de classe.

3.3.1 Vue statique

3.3.1.1 Diagramme de classe

Le diagramme de classe correspond à la représentation de la structure statique du système.

Il représente les différentes entités intervenantes et les relations entre elles. La figure 3.8
suivante représente le diagramme de classe global :

34
Chapitre 3. Étude Conceptuelle

Figure 3.7 : Diagramme de classe globale

3.3.2 Vue dynamique

3.3.2.1 Diagrammes des séquences

• Diagramme de séquence : "S’authentifier"

La figure 3.9 illustre le diagramme de séquence "s’authentifier"

35
Chapitre 3. Étude Conceptuelle

Figure 3.8 : Diagramme de séquence : S’authentifier

• Diagramme de séquence : "Ajouter un client"

La figure 3.10 illustre le diagramme de séquence "Ajouter un client"

Figure 3.9 : Diagramme de séquence :Ajouter un client

• Diagramme de séquence : "Ajouter un noeud"

La figure 3.11 illustre le diagramme de séquence "Ajouter un noeud"

36
Chapitre 3. Étude Conceptuelle

Figure 3.10 : Diagramme de séquence : Ajouter un noeud

• Diagramme de séquence : Ajouter un projet de supervision

La figure 3.12 illustre le diagramme de séquence "Ajouter un projet de supervision"

37
Chapitre 3. Étude Conceptuelle

Figure 3.11 : Diagramme de séquence : Ajouter un projet de supervision

• Diagramme de séquence : modifier un projet de supervision

La figure 3.13 illustre le diagramme de séquence "modifier un projet de supervision"

38
Chapitre 3. Étude Conceptuelle

Figure 3.12 : Diagramme de séquence : modifier un projet de supervision

39
Chapitre 3. Étude Conceptuelle

3.4 Conclusion

Dans ce chapitre, nous avons exposé l’architecture globale de notre solution, ainsi que les
besoins fonctionnels et non fonctionnels, nécessaires pour spécifier les différents diagrammes
élaborés lors de notre étude conceptuelle du projet. Cette étape nous a permis de présenter
plusieurs fonctionnalités de notre système. Dans le prochain chapitre, nous entamons la
phase de réalisation de notre solution et nous présentons les outils qui ont été utilisés
pendant le développement de notre application.

40
 Chapitre 4

Réalisation

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3 Scénarios et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 La mise en oeuvres des noeuds . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1.1 Étapes de mise en œuvre des nœuds du projet . . . . . . . . . . . . . 48

4.3.1.2 Montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1.3 Illustration du déploiement du système en pratique . . . . . . . . . . 49

4.3.2 Réalisation de la partie développement . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.2.1 Interface page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.2.2 Interface de sélection du rôle utilisateur . . . . . . . . . . . . . . . . . 51

4.3.2.3 Interface s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.2.4 Interface consulter liste des projets . . . . . . . . . . . . . . . . . . . . 52

4.3.2.5 Interface ajout d’un projet . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2.6 Interface ajout d’un client . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.2.7 Interface ajout des parcelles . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.2.8 Interface ajout des noeuds . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.2.9 Interfaces d’affichage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.2.10 Interface client consulter la liste des noeuds . . . . . . . . . . . . . . . 55

4.3.2.11 Interface client pour consulter les détailles d’un noeud . . . . . . . . 55

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapitre 4. Réalisation

4.1 Introduction

Ce dernier chapitre est consacré à la description de la solution proposée Pour cela,

nous précisions en premier lieu, l’environnement de travail utilisé. En second lieu, nous allons
présenter la réalisation de la partie IOT et la réalisation de la partie développement de notre
solution.

4.2 Environnement de travail

Pour faire tourner notre application , nous avons choisi un ensemble de matériel et des
logiciels bien déterminés.

4.2.1 Environnement matériel

Pour la réalisation du projet, nous avons utilisé la liste de matériels suivants :

• Wio-E5 Développement Kit

Figure 4.1 : Wio-E5 Développement Kit [12]

Le kit de développement LoRa-E5 STM32WLE5JC - LoRaWAN 868/915 MHz est

une plate forme de développement conçue pour faciliter la création et le prototypage rapide
d’applications IoT utilisant la technologie LoRaWAN.
fabriqué par Seeed Studio, une entreprise spécialisée dans la conception et la fabrication de
matériels et de logiciels pour l’IOT.
Le kit de développement comprend :

- une carte de développement LoRa-E5 STM32WLE5JC équipée d’un microcontrôleur

STM32WLE5JC intégré et d’un module LoRaWAN de haute performance permettant des

42
Chapitre 4. Réalisation

communications longue portée à faible consommation d’énergie. La carte est compatible

avec les réseaux LoRaWAN 868/915 MHz.
La figure 4.2 montre la carte LoRa-E5

Figure 4.2 : La carte lora E5

- une antenne LoRaWAN adaptée aux fréquences EU868 et US915

- câble USB Type-Cde 20 cm pour la connexion à un ordinateur.
- Porte-piles pour 2 piles AA 3V

Voici quelques avantages à utiliser le kit de développement LoRa-E5 STM32WLE5JC :

- Performances LoRa élevées :

La carte LoRa-E5 utilise une technologie LoRa de pointe qui permet des transmissions
longue portée avec une faible consommation d’énergie. Cela en fait un choix idéal pour
les applications IoT qui nécessitent une communication longue portée.

- Puissant microcontrôleur STM32 :

La carte LoRa-E5 est basée sur le microcontrôleur STM32WLE5JC, qui offre des performances
élevées et une faible consommation d’énergie. En fait, le microcontrôleur prend en charge
plusieurs modes de sommeil, notamment le mode Stop, le mode Standby et le mode
Hibernate, qui permettent de réduire considérablement la consommation d’énergie de la
carte LoRa-E5 lorsque l’application est en veille.

• Passerelle

Figure 4.3 : Dragino passerelle

43
Chapitre 4. Réalisation

Le Dragino passerelle LoRa est un équipement de passerelle qui permet de connecter

des dispositifs LoRa à un réseau LoRaWAN. Le Dragino passerelle LoRa prend en charge
les fréquences de bande ISM (industrielle, scientifique et médicale) 433 MHz, 868 MHz et 915
MHz, et utilise le protocole LoRaWAN 1.0.2 pour la communication avec les dispositifs LoRa. La
passerelle dispose d’un module de communication sans fil LoRa concentrator, qui est capable de
recevoir des données LoRa à partir de plusieurs dispositifs de nœud LoRa et de les transmettre
à un serveur central LoRaWAN via une connexion Ethernet.

• Capteur de température et d’humidité Grove - DHT22

Figure 4.4 : Capteur de température et d’humidité Grove - DHT22

Le capteur de température et d’humidité Grove - DHT22 est un module qui permet de

mesurer à la fois la température et l’humidité relative de l’air ambiant. Ce capteur est basé
sur le composant électronique DHT22 (également connu sous le nom d’AM2302), qui est un
capteur de température et d’humidité numérique haute précision. Pour plus détails voir annexe
4.2

4.2.2 Environnement logiciel

Dans cette partie, nous mettons l’accent aux langages, aux bibliothèques utilisées pendant
la réalisation de notre projet.

• C embarqué
C embarqué est un langage de programmation couramment utilisé pour les systèmes
embarqués, tels que les microcontrôleurs, les processeurs sans système d’exploitation et les
systèmes en temps réel. Il offre une combinaison de faible surcharge, de fonctionnalités de bas
niveau et de contrôle précis des ressources matérielles, ce qui le rend très adapté pour les
applications en temps réel et à faible consommation d’énergie.
motivation du choix :

44
Chapitre 4. Réalisation

En utilisant le C embarqué pour programmer la carte électronique, nous pouvons accéder

directement aux ressources matérielles de la carte pour gérer la communication sans fil, les
entrées/sorties et d’autres tâches importantes pour notre application IoT. Le C embarqué nous
permet également d’optimiser l’utilisation de la mémoire et de la puissance de traitement pour
notre application, ce qui est essentiel pour les dispositifs IoT à faible consommation d’énergie.

• Python
Python est un langage de programmation objet, multi-paradigme et multiplateformes. Il favorise
la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté d’un typage
dynamique fort, d’une gestion automatique de la mémoire par ramasse-miettes et d’un système
de gestion d’exceptions.
motivation du choix :
C’est la langage la plus propriété pour tous ce qui est communication avec les noeuds capteurs.
Elle dispose les bibliothèques les plus riches parmi les autre langages de programmation dans
la communications avec le réseau capteur et internet objet, etc. Ce langage de programmation
est open source.

• Django
Django est un framework de développement web écrit en Python, il est simple d’accès, rapide et
il fournit les outils nécessaires à sécuriser notre application, à gérer la structure de nos modèles
(base de données). Sa capacité impressionnante est de s’adapter rapidement et flexiblement
aux demandes de trafic les plus lourdes. Il prend la sécurité au sérieux et nous aide à éviter de
nombreuses erreurs de sécurité courantes comme "Cross site request forgery (CSRF) protection"
ou empêcher un utilisateur malveillant d’exécuter des actions en utilisant les informations
d’identification d’un autre utilisateur sans la connaissance ou le consentement de l’utilisateur.
motivation du choix :
C’est un framework idéal pour réaliser un projet collaboratif avec la moins sécurité nécessaire
et qui permet de gérer les bases des données spatiales en utilisant le module GeoDjango. Il
y a une plus grande liberté dans la gestion du code et en plus un système d’administration
y est déjà pré-construite. Ce framework est simple à déboguer. Le module GeoDjango a pour
but de constituer un cadre applicatif Web géographique de classe mondiale, il vise à faciliter au
maximum la création d’application WebGIS et l’exploitation du potentiel de données géolocalisées.

45
Chapitre 4. Réalisation

• PostgreSQL
PostgreSQL est un système gratuit de gestion de base de données relationnelle et objet (SGBDRO)
robuste et puissant, aux fonctionnalités riches et avancées. Il peut stocker plus de types de
données que les types simples traditionnels (entiers, caractères, etc).
PostGIS :
C’est le module spatial qui confère à PostgreSQL le statut de système de gestion de base de
données relationnelle (SGDBR) spatial.
pgAdmin :
Cette interface d’utilisateur est un outil d’administration graphique pour PostgreSQL.
motivation du choix :
PostgreSQL permet une meilleure prise en charge des données volumineuses par rapport au
mySQL. Il permet la gestion des relations entre données géographiques et données attributaires,
la gestion des accès concurrentiels et la gestion fine possible des droits d’accès. Il possédé la
possibilité de disposer des ’vues’ (tableaux virtuelles résultantes d’une requête SQL de type
SELECT). Grâce au lien fort avec QGIS, ses fonctions spatiales sont plus étendues que sous
QGIS natif.
QGIS : QGIS est un Système d’Information Géographique (SIG) convivial distribué sous
licence publique générale GNU. C’est un projet officiel de la fondation Open Source Geospatial
(OSGeo). Il est compatible avec Linux, Unix, Mac OS X, Windows et Android et intègre de
nombreux formats vecteur, raster, base de données et fonctionnalités.

• Leaflet
Leaflet est la principale bibliothèque JavaScript open-source pour les cartes interactives adaptées
aux téléphones portables. Avec un poids d’environ 42 Ko de JS, elle dispose de toutes les
fonctionnalités cartographiques dont la plupart des développeurs ont besoin.

• HTML5 :HyperText Markup Language

HTML est un langage de balisage utilisé pour structurer le contenu d’une page web. Il s’agit
d’un langage de base pour la création de sites internet. Il utilise des balises pour décrire les
éléments de la page, tels que les titres, les paragraphes, les images et les liens. Chaque balise a
une signification spécifique et est encadrée par des chevrons (< et >).

46
Chapitre 4. Réalisation

• CSS :Cascading Style Sheets

CSS, également appelé feuilles de style en cascade, est un langage utilisé pour décrire la
présentation visuelle d’une page web écrite en HTML. Il permet de contrôler l’apparence des
éléments HTML telle que la couleur, la taille, la police, la disposition et les effets visuels. Avec
CSS, vous pouvez définir des règles de style qui seront appliquées à des éléments spécifiques ou
à des groupes d’éléments sur votre page web. Les règles CSS sont généralement écrites sous la
forme d’une propriété (comme la couleur du texte) suivie de sa valeur (comme le rouge) et sont
placées à l’intérieur d’un bloc de déclaration.

• JavaScript
Javascript désigne un langage de développement Web indépendant de HTML qui nous permet
d’ajouter de l’animation et des fonctions dynamiques à nos pages web en accédant directement
aux éléments HTML et les manipuler .

4.2.3 Outils de développement

Dans cette partie , nous mettons l’accent sur les logiciels utilisés tout au long de la
réalisation de notre projet .

• Stm32CubeIDE :
STM32CubeIDE est un environnement de développement intégré (IDE) gratuit pour la programmation
de microcontrôleurs STM32 de la société STMicroelectronics. Cet IDE est basé sur la plate-forme
de développement Eclipse et offre une interface utilisateur conviviale pour développer, déboguer
et déployer des applications sur les microcontrôleurs STM32.

• Stm32CubeProgrammer :
STM32CubeProgrammer est un logiciel de programmation de microcontrôleurs STM32, développé
par STMicroelectronics. Il est utilisé pour programmer et déboguer les microcontrôleurs STM32.

• VScode :
Visual Studio Code est un éditeur de code simplifié, qui est gratuit et développé en open source

47
Chapitre 4. Réalisation

par Microsoft. Il fonctionne sous Windows, mac OS et Linux. Il fournit aux développeurs à la
fois un environnement de développement intégré avec des outils permettant de faire avancer les
projets techniques, de l’édition, à la construction, jusqu’au débogage.[13]

• :
Git est un système de contrôle de version qui a été inventé et développé par Linus Torvalds,
également connu pour l’invention du noyau Linux, en 2005.
Il s’agit d’un outil de développement qui aide une équipe de développeurs à gérer les
changements apportés au code source au fil du temps.[14]

4.3 Scénarios et résultats

Dans cette partie, nous présentons la démarche que nous avons suivie pour la réalisation
de notre solution IoT, ainsi que les étapes et les résultats du développement de notre application.

4.3.1 La mise en oeuvres des noeuds

4.3.1.1 Étapes de mise en œuvre des nœuds du projet

La mise en oeuvre des noeuds de notre projet se décompose en plusieurs étapes, comprenant :

• Configuration des paramètres du réseau LoRaWAN et du mode basse consommation.

• Développement du code du capteur DHT22 en utilisant les fichiers spécifiés.
• Compilation du code avec STM32CubeIDE et programmation de la carte STM32 à l’aide

de STM32CubeProgrammer.
• Collecte en temps réel des données de température et d’humidité à l’aide du capteur

DHT22.
• Transmission des données via LoRaWAN en utilisant le transceiver intégré de la carte

LoRa-E5.
• Réception des données par la passerelle LoRaWAN et les transmettre au réseau TTN.
• Authentification sécurisée avec TTN en utilisant le mode d’activation OTAA.
• Intégration du protocole MQTT pour lier les données des capteurs à une application web

dédiée.
• Mise à jour en temps réel des informations de température et d’humidité dans la base de

données à partir des messages MQTT.

48
Chapitre 4. Réalisation

4.3.1.2 Montage

Figure 4.5 : Montage

Le tableau 4.1 présente le schéma de branchement entre la carte LoRa E5 et le capteur

DHT22. Il indique les connexions nécessaires pour assurer la communication entre les deux
composants.

Tableau 4.1 : Branchement du capteur DHT22 avec Lora E5

LoRa E5 DHT22

Sig D0(PA0)

VCC 5V

GND GND

4.3.1.3 Illustration du déploiement du système en pratique

La figure 4.6 illustre la configuration câblée de notre système. Nous soigneusement

connectons les différents composants pour assurer leur bon fonctionnement. La carte LoRa
E5 est reliée au capteur DHT22 via les broches appropriées, comme indiqué dans la figure 4.5,
permettant ainsi la collecte précise des données de température et d’humidité. De plus, nous
connectons la batterie au système pour assurer son alimentation autonome.

49
Chapitre 4. Réalisation

Figure 4.6 : Cablage du système

4.3.2 Réalisation de la partie développement

Dans cette section, nous présentons les interfaces de notre application en fournissant des
captures d’écran pour illustrer leur apparence.

4.3.2.1 Interface page d’accueil

La figure 4.7 illustre l’interface de la page d’accueil, qui est la première interface de notre
application. (superviseurs ou clients), peuvent y trouver des informations pertinentes sur notre
startup, ainsi qu’une description détaillée de notre solution.

Figure 4.7 : Page d’accueil

50
Chapitre 4. Réalisation

4.3.2.2 Interface de sélection du rôle utilisateur

Une fois que les utilisateurs ont cliqué sur le bouton de connexion, ils peuvent sélectionner
leur rôle (superviseur ou client), comme illustré dans la Figure 4.8.

Figure 4.8 : Interface « sélection du rôle utilisateur »

4.3.2.3 Interface s’authentifier

Afin de garantir un accès sécurisé à toutes les fonctionnalités de l’application, l’utilisateur

doit s’authentifier en saisissant un pseudo et un mot de passe, comme indiqué dans la figure
4.9.

Figure 4.9 : Interface « S’authentifier »

51
Chapitre 4. Réalisation

4.3.2.4 Interface consulter liste des projets

La figure 4.10 illustre l’interface de la liste des projets du superviseur. Cette interface
permet au superviseur d’accéder facilement à tous les projets qu’il gère. De plus, elle offre une
description détaillée des étapes à suivre pour créer un nouveau projet.

Figure 4.10 : Interface Superviseur « Consulter la liste des projets »

4.3.2.5 Interface ajout d’un projet

La figure 4.11 illustre l’interface d’ajout d’un projet de supervision. Cette interface
permet au superviseur de renseigner les détails du projet, tels que le nom, la description, les
dates importantes, etc. Une fois les informations saisies, le superviseur peut passer à l’étape
suivante du processus.

Figure 4.11 : Interface Superviseur « Ajout projet »

52
Chapitre 4. Réalisation

4.3.2.6 Interface ajout d’un client

Après l’ajout du projet, si aucun client existant n’a été sélectionné, le superviseur accède
à l’interface d’ajout d’un nouveau client, où il saisit les informations nécessaires avant de passer
à l’étape suivante, comme indiqué dans la figure 4.12.

Figure 4.12 : Interface Superviseur « Ajout client »

4.3.2.7 Interface ajout des parcelles

La figure 4.13 illustre l’interface d’ajout des parcelles. Après avoir créé un projet et
attribué un client, le superviseur utilise cette interface pour dessiner les limites des différentes
parcelles du terrain sous sa supervision. Cela lui permet de cartographier les différentes zones
du terrain avec précision.

Figure 4.13 : Interface Superviseur « Ajout parcelles »

53
Chapitre 4. Réalisation

4.3.2.8 Interface ajout des noeuds

La figure 4.14 représente l’ajout des nœuds. Après avoir dessiné les limites des parcelles,
le superviseur accède à cette interface pour placer un nœud sur chaque parcelle et spécifier leurs
caractéristiques spécifiques.

Figure 4.14 : Interface Superviseur « Ajout noeuds »

4.3.2.9 Interfaces d’affichage

La figure 4.15 représente l’interface utilisée pour localiser un nœud sur une parcelle. En
cliquant sur "Locate" le superviseur peut afficher l’emplacement précis du nœud. Cela permet
de définir la position du nœud sur le terrain supervisé.

Figure 4.15 : Interface Superviseur « localiser un nœud »

La figure 4.16 représente l’interface affichant les détails spécifiques d’un nœud sélectionné.
En cliquant sur le bouton "Details", le superviseur peut accéder aux informations importantes

54
Chapitre 4. Réalisation

liées au nœud.

Figure 4.16 : Interface Superviseur « Consulter les détails d’un nœud »

4.3.2.10 Interface client consulter la liste des noeuds

La figure 4.17 représente l’interface "Consulter la liste des noeuds, qui permet au client
de visualiser la liste des noeuds disponibles.

Figure 4.17 : Interface Client « Consulter la liste des noeuds »

4.3.2.11 Interface client pour consulter les détailles d’un noeud

La figure 4.18 représente l’interface "Consulter les détails d’un noeud", qui affiche les
informations détaillées d’un noeud sélectionné par le client.

55
Chapitre 4. Réalisation

Figure 4.18 : Interface Client «Consulter les détailles d’un noeud»

4.4 Conclusion

Dans ce dernier chapitre, nous avons tout d’abord présenté en détail les différents outils
et concepts qui ont permis d’aboutir à la réalisation de notre projet. Par la suite, nous avons
montré les résultats de cette réalisation à travers les différentes captures d’écran des interfaces
de notre application.

56
Conclusion générale et perspectives

Notre projet de fin d’études, réalisé au sein de Smart For Green dans le cadre de
l’obtention du diplôme de Licence en Ingénierie des Systèmes Informatiques, visait à mettre
en place une solution IoT pour la prédiction des incendies de forêt. Ce rapport réparti en
quatre chapitres distincts a décrit le cycle de développement de notre projet, en mettant en
évidence ses étapes clés. En effet, le premier chapitre a présenté le cadre du projet tout en se
focalisant sur l’étude de l’existant et son critique, étape fondamentale pour tout projet. Dans
le même chapitre et en se basant sur les critiques faites sur l’existant, nous avons détaillé notre
solution. Le deuxième chapitre s’est concentré, alors, sur l’étude des besoins fonctionnels et non
fonctionnels, ainsi que l’identification des acteurs impliqués. Nous avons détaillé également la
spécification formelle de ces besoins à travers des diagrammes des cas d’utilisation. Ensuite, dans
le troisième chapitre, nous avons abordé l’architecture fonctionnelle du projet et développé la
conception en utilisant des diagrammes de modélisation des systèmes. Enfin, le dernier chapitre
a été dédié à la réalisation de notre projet.
Comme tout projet, nous avons rencontré des contraintes spécifiquement lors de la phase
de développement. En effet, nous avons consacré beaucoup de temps à nous familiariser avec
la programmation de la carte LoRa E5. La manipulation de cette carte étant nouvelle pour
nous, nous a permis d’ajouter de nouvelles connaissances à celles déjà acquises durant notre
formation académique.
Cette expérience a été extrêmement enrichissante et formatrice pour nous. En effet, nous
avons eu l’opportunité d’apprendre différentes technologies, tant du côté embarqué que du côté
développement d’application. Cela nous a permis de consolider nos connaissances théoriques
acquises tout au long de notre formation.
Sur le plan personnel, ce stage, nous a offert l’opportunité d’améliorer nos capacités de
communication et au travail en équipe, ce qui sera un atout dans un future proche.
Certes, la solution que nous avons développée lors de ce stage va être améliorée en
ajoutant d’autres fonctionnalités et services selon les besoins de nos clients et nos partenaires.
En effet, diverses perspectives sont envisagées. En effet, il est possible d’ajouter une
application mobile capable de prendre en charge quelques opérations de surveillance et de
recevoir sous forme de notifications les alertes en cas de risque de feu. En plus, et plus bénéfique,
nous pouvons ajouter un module qui permet la détection des incendies en se basant sur une

57
Conclusion générale

caméra intelligente utilisant la reconnaissance d’images par l’apprentissage automatique (Tiny

ML).

58
Webographie

[1] kapitalis. adresse : https://kapitalis.com/tunisie/2022/09/01/ete-2022-les-incendies-

ont-detruit-5900-hectares-de-forets-en-tunisie/ (visité le 25/01/2023).

[2] Fire Weather Index, https://www.eurekalert.org/news-releases/604607, [En ligne ; accès

le 17-avril-2023].

[3] lesdozor, http://lesdozor.ru/en/, [En ligne ; accès le 17-avril-2023].

[4] milesight, https://www.milesight-iot.com/blog/co2-monitoring-forest-fire-detection/,

[En ligne ; accès le 17-avril-2023].

[5] Dryad, https://www.dryad.net/wildfiresensor, [En ligne ; accès le 17-avril-2023].

[6] matooma. adresse : https : / / www . matooma . com / fr / s - informer / actualites - iot - m2m /
reseaux-lpwa-sommes (visité le 26/01/2023).

[7] idna. adresse : https://www.idna.fr/2020/10/13/objets- connectes- reseaux/ (visité le

10/03/2023).

[8] jarnobaselier. adresse : https://jarnobaselier.nl/lora-lorawan/ (visité le 17/02/2023).

[9] OTAA-procedure, https://www.researchgate.net/figure/OTAA- procedure- in- LoRaWAN-

protocol-version-10x_fig3_354039383, [En ligne ; accès le 09-avril-2023].

[10] dydtjr1128, https://dydtjr1128.github.io/mqtt/2018/01/31/MQTT- and- MQTT- brokers.

html, [En ligne ; accès le 09-avril-2023].

[11] Fire Weather Index, https://www.researchgate.net/figure/Structure-of-the-NZ-Fire-

Weather-Index-From-Anderson-2005-after-Anon-1993_fig2_299855716, [En ligne ; accès le
16-avril-2023].

[12] seedstudio, https : / / wiki . seeedstudio . com / LoRa _ E5 _ Dev _ Board, [En ligne ; accès le
18-avril-2023].

[13] https : / / www . blogdumoderateur . com / tools / visual - studio - code/, [En ligne ; accès le
09-mai-2023].

[14] https://www.next-decision.fr/wiki/qu-est-ce-que-git, [En ligne ; accès le 09-mai-2023].

59
Webographie

60