========== CHAPITRE 2 ==========

\chapter{APPROCHE METHODOMOGIQUE}

\label{chap:APPROCHE METHODOMOGIQUE}

\section{introduction}

Dans cette partie, nous présentons notre approche méthodologique à suivre pour la mise en place de
notre modèle de prédiction de la consommation énergétique. Cette approche méthodologique est
constituée de plusieurs étapes détaillées

dans la suite du chapitre. Dans un premier temps, nous faisons une description globale de notre
approche, puis par la suite, nous décrivons les étapes importantes de celle-ci.

\section{démarche}

\begin{figure}[htbp]

\centering

\includegraphics[width=0.9\textwidth]{[Link]}

\caption{ demarche proposée}

\label{fig:architecture}

\end{figure}

\subsection{Visualisation des données}

La visualisation constitue la première étape critique de notre pipeline. Elle vise à :

\begin{itemize}[left=0pt]

\item Comprendre la \textbf{structure temporelle} de la consommation énergétique,

\item Identifier les \textbf{tendances saisonnières} (journalières, hebdomadaires),

\item Détecter d’éventuelles \textbf{anomalies ou données manquantes}.

\end{itemize}

Nous utilisons des séries temporelles horaires pour mettre en évidence le rythme d’occupation
typique des bâtiments tertiaires (activité en semaine, repos le week-end).

\subsection{Prétraitement des données}

Le prétraitement assure la qualité et la compatibilité des données avec les exigences des algorithmes
d’apprentissage automatique. Il comprend :

\begin{itemize}[left=0pt]

\item \textbf{Nettoyage} : suppression des colonnes non numériques ,

\item \textbf{Gestion des valeurs manquantes} : interpolation ou suppression ,

 \item \textbf{Feature engineering temporel} : création de variables dérivées essentielles à la
prédiction univariée :

\begin{itemize}

\item \textbf{Lags} : \texttt{lag\_1} (1h), \texttt{lag\_24} (24h), \texttt{lag\_168} (1 semaine),

\item \textbf{Variables calendaires} : \texttt{hour}, \texttt{dayofweek}, \texttt{is\_weekend}.

\end{itemize}

\end{itemize}

% ------------------------------------------------------------

\subsection{Choix des modèles}

Pour comparer ces modèles, une stratégie expérimentale est définie :

\begin{itemize}[left=0pt]

\item \textbf{Séparation du jeu de données en trois sous-ensembles :}

Entraînement (train),

Validation (val),

Test (test), en respectant l’ordre temporel pour éviter les fuites d’information.

\item \textbf{Évaluation à l’aide de métriques de régression standardisées:}

MAE, RMSE, éventuellement MAPE et R2 .

À l’issue de ces expériences, un modèle final est retenu en fonction :

de ses performances moyennes sur le jeu de test ;

de sa stabilité (faible variance entre différentes périodes) ;

et de sa faisabilité de déploiement dans un environnement de bâtiment intelligent (sur serveur ou en

lien avec un système embarqué de type ESP32)

Trois algorithmes représentatifs ont été comparés pour évaluer le meilleur compromis
performance/simplicité :

\begin{itemize}[left=0pt]

\item \textbf{Régression linéaire} : baseline simple, interprétable, .

 \item \textbf{Random Forest} : modèle ensembliste robuste, capable de capturer les seuils discrets
(ex: activation de la climatisation).

\item \textbf{XGBoost} : état de l’art en compétition, mais plus complexe.

\end{itemize}

\subsection{Entraînement et validation du modèle}

Le modèle est entraîné sur \textbf{80 \% des données} (période chronologique initiale) et validé sur
les \textbf{20 \% restants} (période ultérieure), garantissant l’absence de fuite temporelle. Cette
division stricte simule un scénario réel où le modèle doit prédire l’avenir à partir du passé. La
validation croisée n’est pas utilisée, car inadaptée aux séries temporelles.

% ------------------------------------------------------------

\subsection{Embarquement du modèle sur microcontrôleur}

Pour répondre aux contraintes du terrain (budget limité, connectivité intermittente), le modèle final
est exporté vers un \textbf{ESP32} via la bibliothèque \texttt{micromlgen} :

\begin{itemize}[left=0pt]

\item Le modèle Random Forest est converti en code C++ léger (< 50 Ko),

\item L’historique de consommation est stocké localement dans la mémoire de l’ESP32,

\item Les features (\texttt{lag\_1}, \texttt{hour}, etc.) sont calculées en temps réel à partir de
l’horloge interne et des mesures du capteur de courant.

\end{itemize}

Cette architecture garantit une \textbf{autonomie totale}, sans dépendance au cloud ni à une
infrastructure réseau.

% ------------------------------------------------------------

\subsection{Prédiction et détection de gaspillage en temps réel}

Le système embarqué exécute deux tâches clés :

\begin{enumerate}[left=0pt]

\item \textbf{Prédiction horaire} de la consommation, permettant d’anticiper les pics.

\item \textbf{Détection de gaspillage} via une règle métier simple mais efficace :

\begin{quote}
 \textit{« Si la consommation actuelle dépasse 1,5 fois la consommation typique à cette heure et
ce jour, et que le bâtiment est vide, alors il y a gaspillage. »}

\end{quote}

\end{enumerate}

En cas de détection, une \textbf{alerte locale} est déclenchée (LED, buzzer, ou SMS via module GSM
optionnel), permettant une intervention immédiate.

% ------------------------------------------------------------

\begin{figure}[h]

\centering

\begin{tikzpicture}[

node distance=1.2cm and 1.5cm,

box/.style={rectangle, draw, rounded corners, minimum width=2.5cm, minimum height=1cm,

align=center},

arrow/.style={->, >=Stealth, thick}

% Nœuds

\node[box] (sensor) {Capteur de\\courant\\(SCT-013)};

\node[box, right=of sensor] (esp32) {Microcontrôleur\\ESP32};

\node[box, above=of esp32] (model) {Modèle embarqué\\(Random Forest)};

\node[box, right=of esp32] (alert) {Alerte\\locale\\(LED/Buzzer)};

% Flèches

\draw[arrow] (sensor) -- (esp32) node[midway, below] {Données};

\draw[arrow] (esp32) -- (model) node[midway, left] {Calculs};

\draw[arrow] (model) -- (alert) node[midway, above] {Détection\\de gaspillage};

% Annotations

\node[above=0.2cm of model] {\footnotesize Prédiction \& détection};

\node[below=0.2cm of sensor] {\footnotesize Consommation réelle};

\end{tikzpicture}

\caption{Architecture proposée : système embarqué autonome pour la détection de gaspillage

énergétique}

\label{fig:architecture}

\end{figure}

\subsection*{Conclusion de la méthodologie}

Cette démarche en six étapes incarne notre philosophie : \textbf{maximiser l’impact énergétique
avec un minimum de ressources}. En combinant une analyse rigoureuse des données, un modèle
performant mais léger, et un déploiement embarqué autonome, nous proposons une solution
réaliste, maintenable localement, et directement applicable dans le contexte burkinabè.

\end{enumerate}

\section{donnees et clarification}

Clarification sur les données et les features utilisées pour l’apprentissage :Le modèle présenté dans ce
mémoire est entraîné et évalué sur le jeu de données public ASHRAE (bâtiment 120). Les variables
d’entrée adoptées pour l’entraînement sont : variables calendaires (hour, dayofweek, is_weekend),
valeurs retardées de la consommation (lag_1, lag_24, lag_168), et des statistiques glissantes
(rolling_mean). Les capteurs embarqués (présence, température locale, humidité) font partie de
l’architecture proposée mais ne sont pas inclus dans les features d’entraînement en l’absence de jeu
de données local accessible. Par conséquent, toutes les métriques de performance reportées (MAE,
RMSE, R²) se rapportent exclusivement au modèle entraîné avec les variables ci-dessus sur ASHRAE

\section{approche}

L'architecture proposée pour le modèle de prédiction de la consommation d'énergie se compose de

plusieurs couches. La couche de collecte utilise un ESP32 équipé de capteurs de température,
d'humidité, d'un compteur d'énergie et d'un détecteur de présence. Les données collectées sont
envoyées via Wi-Fi à une base de données où elles sont stockées.

Une étape de prétraitement est ensuite appliquée pour nettoyer et normaliser les données. Ces
données préparées sont utilisées pour entraîner un modèle de prédiction basé sur un algorithme de
régression (ou réseau de neurones). Le modèle entraîné est intégré dans une application mobile qui
permet de visualiser les prédictions de consommation d'énergie.

L'utilisateur peut interagir avec ces prédictions via une interface graphique et contrôler des
actionneurs comme une lampe et un climatiseur en fonction des recommandations du modèle."
En clarifiant ces points, tes professeurs devraient mieux comprendre ton architecture et son
application dans le cadre de ton mémoire.

\section{Approche et architecture proposée pour traiter la problématique}

\label{sec:approche_architecture}

La problématique de ce mémoire est de disposer d’un système capable de

\textbf{prédire la consommation énergétique} d’un bâtiment, puis d’utiliser ces

prédictions pour \textbf{détecter les gaspillages} et, le cas échéant,

\textbf{agir automatiquement sur les actionneurs} (lampes, climatiseurs,

appareils) ou proposer des recommandations à l’utilisateur.

L’architecture proposée, représentée à la Figure~\ref{fig:architecture_systeme},

met en \oe uvre une chaîne complète allant de la collecte des données jusqu’au

pilotage des charges électriques. Elle est organisée autour de six blocs

principaux :

\begin{itemize}

\item les \textbf{capteurs}, qui mesurent l’état du bâtiment et des usages ;

\item le \textbf{microcontrôleur}, qui centralise ces mesures, applique un traitement local et

exécute le modèle embarqué ;

\item la \textbf{base de données}, qui stocke l’historique des mesures pour l’analyse et le
réentraînement du modèle ;

\item le module \textbf{affichage mobile / web}, qui expose les prédictions, les alertes et les
tableaux de contrôle ;

\item le module de \textbf{visualisation}, qui fournit des graphiques et tableaux d’analyse ;

\item les \textbf{actionneurs}, qui permettent de traduire les recommandations en actions

concrètes sur le bâtiment.

\end{itemize}

\begin{figure}[H]

\centering

\includegraphics[width=0.95\textwidth]{[Link]} % nom de ton fichier

 \caption{Architecture fonctionnelle du système de prédiction, de recommandation et de pilotage
énergétique}

\label{fig:architecture_systeme}

\end{figure}

Cette architecture permet d’implémenter une boucle fermée :

\begin{center}

\textbf{mesurer $\rightarrow$ prédire $\rightarrow$ recommander / décider $\rightarrow$ agir

sur les actionneurs.}

\end{center}

%----------------------------------------------------------------

\subsection{Bloc capteurs : perception de l’environnement}

Le premier bloc de l’architecture est constitué des \textbf{capteurs}, qui

fournissent les informations nécessaires à la prédiction et à la détection de

gaspillage. On distingue principalement :

\begin{itemize}

\item un \textbf{capteur de présence}, utilisé pour savoir si le local est occupé ou non ;

\item un \textbf{compteur d’énergie}, qui mesure la tension, le courant, la puissance instantanée et

l’énergie consommée ;

\item un capteur d’\textbf{humidité} et un capteur de \textbf{température}, qui renseignent sur les

conditions de confort thermique.

\end{itemize}

Ces capteurs produisent des mesures périodiques, horodatées, qui sont

directement envoyées vers le microcontrôleur. Ils constituent la

\textbf{couche de perception} du système.

%----------------------------------------------------------------

\subsection{Bloc microcontrôleur : traitement local et modèle embarqué}

Le \textbf{microcontrôleur} (ESP32 dans le cadre de ce travail) occupe une

position centrale dans l’architecture. Il assure plusieurs fonctions :

\begin{itemize}

\item \textbf{réception des données capteurs} : l’ESP32 lit en continu les

valeurs fournies par le capteur de présence, le compteur d’énergie et les

capteurs environnementaux ;

\item \textbf{traitement local} : un premier prétraitement est appliqué

(filtrage de valeurs aberrantes, agrégation sur un pas de temps donné,

mise en forme des données). L’ESP32 peut également calculer des indicateurs

simples (moyenne glissante, comparaison par rapport à une valeur de

référence, etc.) ;

\item \textbf{exécution du modèle embarqué} : une version adaptée du

modèle de prédiction (par exemple un Random Forest simplifié ou un modèle

plus léger) est intégrée dans le microcontrôleur. À partir des mesures

courantes et d’un historique réduit, il calcule la \textbf{consommation

attendue} et la compare à la consommation réelle.

\end{itemize}

C’est à ce niveau que s’effectue la première étape clé de la démarche :

\textbf{prédire} la consommation future ou typique, afin de pouvoir ensuite

détecter les écarts significatifs et déclencher des recommandations.

L’ESP32 joue également le rôle de \textbf{passerelle de communication} vers la

base de données (en envoyant les mesures horodatées) et vers l’interface

mobile/web (en publiant les prédictions et les états des actionneurs).

%----------------------------------------------------------------
\subsection{Bloc base de données : historique et réentraînement du modèle}

Les données envoyées par le microcontrôleur sont stockées dans une

\textbf{base de données}. Cette base remplit deux fonctions principales :

\begin{itemize}

\item \textbf{stockage de l’historique} des mesures (consommation, présence,

température, humidité, états des actionneurs). Cet historique est

indispensable pour analyser les profils de consommation et évaluer les

performances du système ;

\item \textbf{support au réentraînement du modèle} : les données historiques

peuvent être exportées vers un environnement d’expérimentation (par

exemple Google Colab) afin de tester de nouveaux modèles ou de

réentraîner le modèle existant pour l’adapter à l’évolution des usages

(saisons, changement d’occupation, ajout d’équipements, etc.).

\end{itemize}

Ce bloc garantit que le système reste \textbf{évolutif} : au lieu d’un modèle

figé, il est possible d’améliorer périodiquement la qualité des prédictions en

tirant parti des nouvelles données collectées.

%----------------------------------------------------------------

\subsection{Bloc affichage mobile / web : interface de prédiction et de contrôle}

Le bloc \textbf{affichage mobile / web} constitue le point d’entrée pour

l’utilisateur final. Il reçoit les informations publiées par le

microcontrôleur (ou par un serveur intermédiaire) et les présente de manière

synthétique. Il assure trois fonctions :

\begin{itemize}
 \item \textbf{affichage des prédictions} : l’utilisateur visualise la

consommation prévue à court terme et peut comparer ces prédictions aux

mesures réelles ;

\item \textbf{tableaux de contrôle des actionneurs} : l’interface offre des

commandes (boutons, interrupteurs virtuels) pour allumer ou éteindre

certaines charges, modifier des consignes, ou passer d’un mode manuel à

un mode automatique ;

\item \textbf{gestion des alertes} : en cas de détection de gaspillage

(par exemple consommation anormalement élevée alors qu’aucune présence

n’est détectée), des messages d’alerte sont affichés à l’écran. L’utilisateur

peut alors valider ou non l’action proposée (extinction d’une lampe,

réduction de la climatisation, etc.).

\end{itemize}

Ce bloc matérialise la phase \textbf{faire des recommandations} de la boucle :

les prédictions et les règles de décision sont traduites en informations

compréhensibles et en options d’action pour l’occupant ou le gestionnaire du

bâtiment.

%----------------------------------------------------------------

\subsection{Bloc visualisation : analyse avancée des données}

En complément de l’affichage opérationnel, un bloc \textbf{visualisation}

permet une analyse plus approfondie des données historiques et des

performances du système. Il propose notamment :

\begin{itemize}

\item des \textbf{graphiques} montrant l’évolution de la consommation sur

différentes échelles de temps (heure, jour, semaine, mois) ;

 \item des \textbf{alertes historiques} (fréquence et durée des épisodes de

gaspillage détectés, périodes critiques, etc.) ;

\item des \textbf{tableaux} récapitulatifs (indicateurs de performance,

économies potentielles, statistiques sur l’utilisation des actionneurs).

\end{itemize}

Cette visualisation est particulièrement utile pour la phase

\textbf{évaluation} et pour la rédaction de rapports destinés aux décideurs.

%----------------------------------------------------------------

\subsection{Bloc actionneurs : passage à l’action sur le bâtiment}

Enfin, le bloc \textbf{actionneurs} regroupe les différents équipements

pilotables du bâtiment :

\begin{itemize}

\item \textbf{lampes} et éclairages divers ;

\item \textbf{climatiseurs} et autres systèmes de refroidissement ou de chauffage ;

\item \textbf{appareils électriques} non critiques pouvant être arrêtés ou décalés dans le temps.

\end{itemize}

Ces actionneurs sont généralement commandés via un \textbf{module de relais}

connecté au microcontrôleur. Les décisions issues du modèle de prédiction et

des règles métier peuvent se traduire de deux manières :

\begin{itemize}

\item en mode \textbf{assisté}, où le système propose une action (par

exemple : « éteindre la lampe du bureau 2 ») et attend la validation de

l’utilisateur ;
 \item en mode \textbf{automatique}, où certaines actions sont déclenchées

directement si les conditions sont réunies (absence prolongée, dépassement

d’un seuil de consommation, etc.).

\end{itemize}

Ce bloc réalise la dernière étape de la boucle : \textbf{agir sur les

actionneurs} pour réduire effectivement la consommation et les gaspillages.

%----------------------------------------------------------------

\subsection{Synthèse de l’approche}

En résumé, l’architecture proposée met en correspondance :

\begin{itemize}

\item la \textbf{collecte fine de données} (capteurs) ;

\item la \textbf{prédiction en temps réel} (modèle embarqué sur le microcontrôleur) ;

\item la \textbf{recommandation et l’aide à la décision} (interface mobile / web, visualisation) ;

\item et le \textbf{pilotage automatique des charges} (actionneurs).

\end{itemize}

Elle permet ainsi de traiter de manière cohérente la problématique de ce

mémoire : \textit{prédire la consommation énergétique dans un bâtiment

intelligent, puis utiliser ces prédictions pour recommander et déclencher des

actions concrètes visant à réduire les gaspillages}.

\section{dataset}

Les données utilisées dans cette étude sont un dataset contenant des données de

consommation d'énergie Interconnection LLC (PJM) », une

organisation régionale de transmission aux États-Unis qui exploite un système de

transmission électrique résidentiel. Cet ensemble de données s'étend sur plus de 15

ans et fournit des informations précieuses sur les tendances de consommation

d'énergie.

Les données de consommation d'énergie électrique horaire proviennent du site Web

de PJM et sont accessibles au public sous la licence "CC0 : domaine public", ce qui les

rend accessibles à des fins de recherche. L'ensemble de données est extrait de Kaggle

et peut être trouvé sur le lien [39 ,40].

Il s'agit d'un ensemble de données de séries chronologiques univariées qui contient

des données de consommation d'énergie horaire en mégawatts (MW). Nous avons

choisi cette dataset pour notre travail pour les raisons suivantes :

• Pertinence : Le dataset est pertinent pour notre recherche, il fournit une

ressource précieuse pour l'utilisation afin de prévoir ; et pour les techniques

de prétraitement et d'analyse de données.

• Taille : dataset est suffisamment grand pour être un défi intéressant à

travailler avec, et pour l'utiliser afin de former et de tester notre modèle.

• Disponibilité : dataset est disponible publiquement ce qui permet d'une

utilisation académique, il est souvent utilisé dans les travaux universitaires et

a été utilisé dans des études de recherche précédentes, ce qui peut fournir un

point de référence utile ; il est connu aussi pour sa grande qualité.

\section{methodologie}

Ce travail est basé sur trois phases clés : l’exploitation du modèle, et

l’optimisation ,la mise en situation

La Figure 2.1 illustre le processus de choix du modele

\begin{figure}[htbp]

\centering

\includegraphics[width=0.9\textwidth]{[Link]}

\caption{Description de l'image ( Architecture proposée du système embarqué)}

\label{fig:architecture}

\end{figure}

\begin{figure}[htbp]

\centering

\includegraphics[width=0.9\textwidth]{[Link]}
 \caption{Description de l'image ( Architecture proposée du système embarqué)}

\label{fig:architecture}

\end{figure}

\newpage

\section{Visualisation de données}

Variables influentes :

Données de consommation

consommation totale (smart meter)

consommation par équipement

historique (séries temporelles)

Données météo

température

humidité

vent

heure / saison / jour

Caractéristiques du bâtiment

présence (occupation)

\section{ar}

\section{Prétraitement des données}

Les étapes de nettoyage et préparation des données...

\section{Sélection des modèles}

Justification du choix des modèles de machine learning...

% ========== CHAPITRE 3 ==========

\chapter{Implémentation}

\label{chap:implementation}

Ce chapitre se divise en deux parties : la première partie est consacrée à l’implémentation de

du modèle proposé. Là où les différents choix d’implémentation sont présentés comme

l’environnement de développement, les bibliothèques utilisées et les résultats de paramétrage

effectué. La deuxième partie montre les différents tests réalisés, les résultats obtenus avec les

discussions et les comparaisons avec des travaux reliés

\section{Environnement materiel}

Tout au long de notre projet, nous avons utilisé un ordinateur dont les caractéristiques sont les

suivantes :

HP core i5 @2.60GHz, 8.00Go de RAM, système d’exploitation Windows 10 Professionnel

Présentation des outils et technologies utilisés...

entre la précision et la charge de traitement sur l'ESP32. Le tableau~\ref{tab:capteurs} résume les

caractéristiques techniques.

\begin{table}[H]

\centering

\caption{Spécifications techniques des capteurs utilisés.}

\label{tab:capteurs}

\begin{tabular}{lccl}

\toprule

\textbf{Capteur} & \textbf{Modèle} & \textbf{Plage de Mesure} & \textbf{Précision} \\

\midrule

Présence & HC-SR501 & 7 m (cône 110°) & -- \\

Énergie & PZEM-004T & 0-100A / 0-300V & $\pm$0.5\% \\

Humidité/Température & DHT22 & 0-100\% HR / -40°C à 80°C & $\pm$2\% HR / $\

pm$0.5°C \\

\bottomrule

\end{tabular}

\end{table}

\section{Environnement technique}

\subsection{Plateforme d’exécution : Google Colaboratory}

Google Colaboratory, souvent appelé Colab, a été choisi comme plateforme principale d’exécution
pour les expériences. Colab offre un environnement cloud qui permet de rédiger et d’exécuter du
code Python directement dans un navigateur, sans configuration préalable. L’un des principaux
avantages de Colab est son accès gratuit aux ressources matérielles avancées, telles que les GPU
(Graphics Processing Units) et TPU (Tensor Processing Units), qui sont essentielles pour les tâches
nécessitant une puissance de calcul élevée. En outre, les fonctionnalités intégrées, telles que l’accès à
des bibliothèques populaires préinstallées, la compatibilité avec Python et la gestion des
dépendances via des commandes pip, en font une solution pratique pour les projets de Machine
Learning.

\subsection{Langage de programmation : Python,arduino}

Python a été sélectionné comme langage de programmation en raison de sa simplicité et de sa large

adoption dans la communauté scientifique. Sa syntaxe intuitive le rend accessible, même pour les
débutants, tout en offrant une puissance suffisante pour les applications avancées. Python dispose
d’un écosystème riche en bibliothèques.

`\section{arduino}

Outils de développement embarqué

Arduino IDE pour la programmation de l’ESP32 en C/C++ ;

Bibliothèques spécifiques :

bibliothèque pour le capteur DHT22,

bibliothèque pour le module PZEM-004T (communication série),

bibliothèque pour le capteur HC-SR501 (entrée numérique),

bibliothèque pour le module Wi-Fi de l’ESP32 (envoi de données via HTTP/MQTT).

\subsection{Bibliothèques de modélisation : Scikit-Learn}

Python dispose de nombreux frameworks dédiés au traitement des données, à la modélisation et à la

visualisation, ce qui en fait un langage de référence pour les projets de Machine Learning. Sa
compatibilité avec Google Colaboratory, ainsi que le large soutien de la communauté open source,
offrent un accès permanent à une documentation riche, des tutoriels et des solutions facilitant la
résolution des problèmes rencontrés lors du développement.

Scikit-Learn est une bibliothèque essentielle pour l’apprentissage automatique classique. Elle met à
disposition une vaste collection d’algorithmes de Machine Learning couvrant la régression, la
classification et le clustering. Elle est largement utilisée pour les étapes de prétraitement des
données, telles que la normalisation, ainsi que pour l’entraînement et l’évaluation de modèles
reposant sur des algorithmes éprouvés .

\subsection{Bibliothèques d'analyse de données : Pandas et NumPy}

Pandas est une bibliothèque essentielle pour la manipulation et l’analyse des ensembles de données.
Elle fournit des structures de données telles que les DataFrames, qui permettent d’effectuer
facilement des opérations telles que le nettoyage, le tri et la transformation des données. Cette
bibliothèque nous a permis d’explorer les données, de gérer les valeurs manquantes et de préparer
les ensembles de données d’entraînement et de test

NumPy est une bibliothèque dédiée aux calculs numériques performants. Elle est utilisée pour
réaliser des opérations matricielles et vectorielles, qui sont au cœur des algorithmes d’apprentissage
automatique et de Deep Learning. NumPy constitue également une base pour d’autres bibliothèques,
telles que TensorFlow et Pandas, ce qui renforce son importance dans cet environnement

\section{Architecture du système}

% -------------------------------------------------------------

% Figure 3.1 : Architecture fonctionnelle globale

% -------------------------------------------------------------

\begin{figure}[h]

\centering

% \includegraphics[width=0.9\textwidth]{schema synoptique .jpeg}

\caption{Architecture fonctionnelle globale du système de prédiction et de pilotage énergétique}

\label{fig:architecture_fonctionnelle}

\end{figure}

La Figure~\ref{fig:architecture_fonctionnelle} illustre l’architecture fonctionnelle globale :

\begin{itemize}

\item \textbf{Couche capteurs} : mesure de la présence, de la consommation, de la température,

de l’humidité ;

\item \textbf{Microcontrôleur (ESP32)} : collecte des données, pré-traitement léger, envoi au

serveur, réception des commandes pour les relais ;

\item \textbf{Base de données} : stockage historique des mesures et des prédictions ;

\item \textbf{Module de prédiction} : exécution des modèles d’apprentissage automatique (sur

serveur) ;

\item \textbf{Interface web / mobile} : visualisation, alertes, contrôle des actionneurs ;

\item \textbf{Actionneurs} : lampes, climatiseurs, autres appareils pilotés via le module relais.

\end{itemize}

Cette architecture met en cohérence la partie IoT (Chapitre~3) et la partie prédiction (Chapitres~2
et~4).
% -------------------------------------------------------------

% 3.4 Implémentation du pipeline de données et des modèles

% -------------------------------------------------------------

\section{Implémentation du pipeline de données et des modèles}

\label{sec:pipeline_donnees_modeles}

\subsection{Organisation du code}

\label{subsec:organisation_code}

Le code est structuré en plusieurs modules Python :

\begin{itemize}

\item \texttt{data\_loader.py} : chargement des données brutes (fichiers, base de données) ;

\item \texttt{[Link]} : nettoyage, création de variables de retard, encodage,

normalisation ;

\item \texttt{[Link]} : définition des trois modèles (régression linéaire, Random Forest,
XGBoost) et des grilles d’hyperparamètres ;

\item \texttt{train\_eval.py} : script d’entraînement, de validation et d’évaluation ;

\item \texttt{[Link]} : sérialisation du Random Forest final et mise à disposition (API ou script
d’inférence).

\end{itemize}

Cette structuration permet de séparer clairement les responsabilités (prétraitement, modélisation,

déploiement) et de faciliter les réutilisations futures.

\subsection{Entraînement des modèles}

\label{subsec:entrainement_modeles}

Les principales étapes de l’entraînement sont les suivantes.

\paragraph{Chargement et prétraitement}
\begin{itemize}

\item Lecture des données ;

\item application des étapes définies au Chapitre~2 (nettoyage, \emph{feature engineering},

normalisation) ;

\item construction des matrices $X$ (entrées) et $y$ (consommation future).

\end{itemize}

\paragraph{Découpage temporel}

\begin{itemize}

\item les premières observations (environ $70~\%$) forment le jeu d’entraînement ;

\item les observations suivantes (environ $15~\%$) sont utilisées pour la validation (réglage
d’hyperparamètres) ;

\item les dernières observations (environ $15~\%$) constituent le jeu de test final.

\end{itemize}

\paragraph{Définition des modèles}

Trois modèles de régression sont considérés :

\begin{itemize}

\item \textbf{Régression linéaire multiple} :

\begin{verbatim}

from sklearn.linear_model import LinearRegression

model_lr = LinearRegression()

\end{verbatim}

\item \textbf{Random Forest Regressor} :

\begin{verbatim}

from [Link] import RandomForestRegressor

model_rf = RandomForestRegressor(

n_estimators=200,
 max_depth=None,

min_samples_split=2,

min_samples_leaf=1,

random_state=42

\end{verbatim}

\item \textbf{XGBoost Regressor} :

\begin{verbatim}

from xgboost import XGBRegressor

model_xgb = XGBRegressor(

n_estimators=300,

learning_rate=0.05,

max_depth=6,

subsample=0.8,

colsample_bytree=0.8,

random_state=42

\end{verbatim}

\end{itemize}

\paragraph{Recherche d’hyperparamètres}

Une recherche d’hyperparamètres est réalisée au moyen des outils \texttt{GridSearchCV} ou \

texttt{RandomizedSearchCV}, avec une validation croisée adaptée aux séries temporelles (par
exemple \texttt{TimeSeriesSplit}). Les hyperparamètres sont ajustés séparément pour le Random
Forest et pour XGBoost.

\paragraph{Entraînement final}

\begin{itemize}
 \item chaque modèle est ré-entraîné avec les meilleurs hyperparamètres sur l’ensemble \
emph{entraînement + validation} ;

\item les performances finales sont ensuite évaluées sur l’ensemble de test.

\end{itemize}

\subsection{Évaluation et comparaison}

\label{subsec:evaluation_comparaison}

Pour chaque modèle, nous calculons sur le jeu de test les métriques suivantes.

\paragraph{Erreur absolue moyenne (MAE)}

\[

\text{MAE} = \frac{1}{N} \sum_{i=1}^{N} \left| y_i - \hat{y}_i \right|

\]

\paragraph{Erreur quadratique moyenne (RMSE)}

\[

\text{RMSE} =

\sqrt{

\frac{1}{N} \sum_{i=1}^{N} \left( y_i - \hat{y}_i \right)^2

\]

\paragraph{Coefficient de détermination ($R^2$)}

\[

R^2 = 1 -

\frac{\displaystyle\sum_{i=1}^{N} \left( y_i - \hat{y}_i \right)^2}

{\displaystyle\sum_{i=1}^{N} \left( y_i - \bar{y} \right)^2}

\]

où $y_i$ désigne la valeur réelle, $\hat{y}_i$ la valeur prédite et $\bar{y}$ la moyenne des valeurs
réelles sur le jeu de test.

Nous comparons ensuite :

\begin{itemize}

\item la régression linéaire (modèle de base / \emph{baseline}) ;

\item le Random Forest ;

\item XGBoost.

\end{itemize}

Les résultats montrent généralement :

\begin{itemize}

\item une amélioration nette du MAE et du RMSE en passant de la régression linéaire aux modèles
d’ensemble ;

\item des performances très proches entre Random Forest et XGBoost, avec parfois un léger
avantage du Random Forest en termes de robustesse (moins sensible aux variations de configuration)
;

\item un meilleur compromis global pour le Random Forest, qui est donc retenu comme modèle
final pour la suite du mémoire.

\end{itemize}

Le Chapitre~4 fournira les valeurs numériques détaillées et les graphiques de comparaison.

% -------------------------------------------------------------

% 3.5 Implémentation du prototype embarqué (résumé)

% -------------------------------------------------------------

\section{Implémentation du prototype embarqué (résumé)}

\label{sec:prototype_embarque}

Cette partie décrit rapidement :

\begin{itemize}
 \item le câblage de l’ESP32 avec les capteurs (DHT22, HC-SR501, PZEM-004T) et le module relais ;

\item le programme embarqué (lecture périodique, envoi des mesures, réception de commandes) ;

\item la façon dont les prédictions (calculées côté serveur) peuvent être utilisées pour générer des
consignes envoyées à l’ESP32 (par exemple extinction automatique de charges lors de pics prévus).

\end{itemize}

% -------------------------------------------------------------

% 3.6 Scénarios de test

% -------------------------------------------------------------

\section{Scénarios de test}

\label{sec:scenarios_test}

Un ou plusieurs scénarios de test sont définis afin de :

\begin{itemize}

\item observer le comportement du système sur une période donnée (jour, semaine) ;

\item comparer la consommation réelle et la consommation prédite par le modèle Random Forest
retenu ;

\item évaluer, à titre exploratoire, le potentiel de réduction de la consommation si les décisions

proposées par le modèle étaient effectivement appliquées.

\end{itemize}

% -------------------------------------------------------------

% 3.7 Conclusion du chapitre

% -------------------------------------------------------------

\section{Conclusion du chapitre}

\label{sec:conclusion_chapitre3}

Ce chapitre a présenté l’implémentation concrète du système de prédiction et son intégration dans

une architecture de bâtiment intelligent. Trois modèles de régression (régression linéaire, Random
Forest, XGBoost) ont été implémentés et évalués, conduisant au choix du \emph{Random Forest
Regressor} comme modèle final, en raison de ses bonnes performances et de sa robustesse.

Le chapitre suivant analysera en détail les résultats expérimentaux, discutera des forces et des limites
du modèle retenu, et proposera des pistes d’amélioration.
\section{dataset}

Les données utilisées dans cette étude sont un dataset contenant des données de

consommation d'énergie Interconnection LLC (PJM) », une

organisation régionale de transmission aux États-Unis qui exploite un système de

transmission électrique résidentiel. Cet ensemble de données s'étend sur plus de 15

ans et fournit des informations précieuses sur les tendances de consommation

d'énergie.

Les données de consommation d'énergie électrique horaire proviennent du site Web

de PJM et sont accessibles au public sous la licence "CC0 : domaine public", ce qui les

rend accessibles à des fins de recherche. L'ensemble de données est extrait de Kaggle

et peut être trouvé sur le lien [39 ,40].

Il s'agit d'un ensemble de données de séries chronologiques univariées qui contient

des données de consommation d'énergie horaire en mégawatts (MW). Nous avons

choisi cette dataset pour notre travail pour les raisons suivantes :

• Pertinence : Le dataset est pertinent pour notre recherche, il fournit une

ressource précieuse pour l'utilisation afin de prévoir ; et pour les techniques

de prétraitement et d'analyse de données.

• Taille : dataset est suffisamment grand pour être un défi intéressant à

travailler avec, et pour l'utiliser afin de former et de tester notre modèle.

• Disponibilité : dataset est disponible publiquement ce qui permet d'une

utilisation académique, il est souvent utilisé dans les travaux universitaires et

a été utilisé dans des études de recherche précédentes, ce qui peut fournir un

point de référence utile ; il est connu aussi pour sa grande qualité

Description de l'architecture globale du système...