Université Mohammed-V - Rabat

École Nationale Supérieure d’Informatique

et d’Analyse des Systèmes

Architecture distribuée
Filière :

Génie de la Data
Sujet :

Système distribué pour la gestion

d’une ville intelligente
et l’optimisation des ressources
urbaines

Encadré par :
M. Hatim GUERMAH

Réalisé par :
Marouane BATRONE
Rachid BENHSINA
Younes ICHQARRANE

Année universitaire 2024-2025

Résumé

Ce projet a pour objectif de développer une ville intelligente capable de collecter,

traiter, visualiser et générer des alertes en temps réel à partir de données provenant de
capteurs simulés. Pour cela, une architecture distribuée a été mise en place, combinant
un serveur TCP multiclient, une plateforme de streaming Kafka Serverless, une base de
données PostgreSQL, ainsi que des tableaux de bord interactifs via Grafana. Par ailleurs,
un système d’alerte automatique, basé sur AWS Lambda et EventBridge, permet de dé-
tecter les anomalies en fonction de seuils critiques. Ce projet propose ainsi une solution
performante et évolutive pour le suivi intelligent des ressources telles que l’eau, l’énergie
et les déchets.

Mots clés : Kafka, PostgreSQL, Grafana, AWS Lambda, , IoT.

I
Abstract

This project aims to develop a smart city capable of collecting, processing, visuali-
zing, and generating real-time alerts based on data from simulated sensors. To achieve
this, a distributed architecture was implemented, combining a multi-client TCP server,
a Kafka Serverless streaming platform, a PostgreSQL database, and interactive dash-
boards via Grafana. Additionally, an automated alert system based on AWS Lambda and
EventBridge detects anomalies according to critical thresholds. This project thus offers
an efficient and scalable solution for intelligent monitoring of resources such as water,
energy, and waste.

Keywords : Kafka, PostgreSQL, Grafana, AWS Lambda, , IoT.

II
Table des matières

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

Chapitre 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapitre 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Schéma d’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Simulation des capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Description des programmes de simulation . . . . . . . . . . . . . . 7
2.4.2 Mécanisme de transmission des données . . . . . . . . . . . . . . . 7
2.4.3 Fréquence et format des données . . . . . . . . . . . . . . . . . . . 8
2.5 Serveur TCP multiclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Transmission des données via Kafka . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Stockage des données dans PostgreSQL . . . . . . . . . . . . . . . . . . . . 9
2.8 Visualisation avec Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.9 Système d’alerte avec AWS Lambda . . . . . . . . . . . . . . . . . . . . . 10
2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapitre 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Envoi des données des capteurs au serveur . . . . . . . . . . . . . . . . . . 12
3.2 Réception des données par le serveur TCP . . . . . . . . . . . . . . . . . . 13
3.3 Gestion des flux de données avec Kafka . . . . . . . . . . . . . . . . . . . . 13
3.4 Stockage des données dans la base de données . . . . . . . . . . . . . . . . 14
3.5 Tableaux de bord Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

III
Table des matières

Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

IV
Liste des figures

2.1 Schéma global de l’architecture du système . . . . . . . . . . . . . . . . . . 6

3.1 Les capteurs de gestion de l’eau. . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Les capteurs de gestion de l’énergie. . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Les capteurs de gestion des déchets . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Réception des données des capteurs par le serveur TCP . . . . . . . . . . . 13
3.5 Gestion du flux de données par Kafka . . . . . . . . . . . . . . . . . . . . . 14
3.6 Stockage des mesures de gestion de l’eau . . . . . . . . . . . . . . . . . . . 14
3.7 Stockage des mesures de gestion de l’énergie . . . . . . . . . . . . . . . . . 14
3.8 Stockage des mesures de gestion des déchets . . . . . . . . . . . . . . . . . 15
3.9 Capture d’écran du tableau de bord de l’eau . . . . . . . . . . . . . . . . . 15
3.10 Capture d’écran du tableau de bord d’énergie . . . . . . . . . . . . . . . . 16
3.11 Capture d’écran du tableau de bord des dechets . . . . . . . . . . . . . . . 16

V
Chapitre 1

Introduction

1
Chapitre 1. Introduction

1.1 Introduction
Dans le cadre du développement des villes intelligentes, la gestion efficace des res-
sources urbaines en temps réel devient une nécessité. Ce projet s’inscrit dans cette dyna-
mique en proposant un système distribué de collecte, traitement, visualisation et alerte
basé sur des capteurs simulés. Il vise à fournir un outil de supervision performant pour
une prise de décision rapide et éclairée.

1.2 Contexte général

Avec la croissance rapide de la population urbaine, les villes font face à des défis ma-
jeurs liés à la gestion des ressources telles que l’eau, l’énergie et les déchets. Pour répondre
à ces enjeux, les villes dites intelligentes s’appuient sur les technologies de l’information et
des capteurs pour collecter des données en temps réel et optimiser les services urbains. Ces
capteurs, répartis à travers la ville, permettent de surveiller les niveaux de consommation,
détecter les anomalies, et déclencher des actions correctives de manière automatisée.
Cependant, la mise en place d’un tel système nécessite une infrastructure technique
robuste capable d’assurer la transmission, le traitement, la visualisation et l’analyse conti-
nue des données générées. Le projet présenté dans ce rapport s’inscrit dans cette logique
et propose une architecture distribuée exploitant des outils modernes comme Kafka, Post-
greSQL, Grafana et AWS pour répondre à ces exigences.

1.3 Problématique
La gestion traditionnelle des ressources urbaines repose souvent sur des méthodes
manuelles ou semi-automatisées, avec des interventions humaines fréquentes et des prises
de décision basées sur des données retardées ou incomplètes. Cette approche entraîne
une réactivité limitée face aux incidents tels que les fuites d’eau, les débordements de
déchets ou les pics de consommation énergétique. De plus, l’absence d’un système unifié
de surveillance complique la coordination entre les différents services de la ville.
Dans un contexte de ville intelligente, il devient indispensable de disposer d’un système
capable de collecter automatiquement les données en temps réel, de les traiter efficace-
ment, de les visualiser de manière claire, et de générer des alertes immédiates en cas
d’anomalies. La problématique principale abordée dans ce projet est donc la suivante :
comment concevoir une architecture distribuée, robuste et évolutive, permettant la su-
pervision en temps réel des ressources urbaines à partir de capteurs, tout en assurant la
fiabilité du traitement et la réactivité des alertes ?
Ce défi implique de combiner plusieurs technologies et composants – tels que la simu-
lation de capteurs, la communication réseau, le streaming de données, la gestion de base
de données, les visualisations dynamiques et l’automatisation des alertes – dans une seule
solution cohérente et performante.

2
Chapitre 1. Introduction

1.4 Objectifs du projet

L’objectif principal de ce projet est de concevoir et de mettre en œuvre un système
distribué capable de superviser en temps réel les données issues de capteurs simulant la
consommation d’eau, d’énergie et le niveau des déchets, tout en assurant un traitement
fiable, une visualisation dynamique et un mécanisme d’alerte automatisé.
Plus précisément, les objectifs sont les suivants :

• Simuler des capteurs générant des données en continu relatives à des ressources
urbaines critiques (eau, déchets, énergie).

• Assurer la transmission des données en temps réel via des sockets TCP vers un
serveur central.

• Intégrer un système de streaming distribué, basé sur Kafka Serverless, pour la ges-
tion des flux de données entrants.

• Stocker les données collectées dans une base de données relationnelle (PostgreSQL)
de manière structurée et évolutive.

• Mettre en place un tableau de bord interactif avec Grafana pour visualiser les don-
nées en temps réel et suivre l’évolution des indicateurs.

• Développer un mécanisme d’alerte automatique via AWS Lambda et Amazon SES

pour informer les gestionnaires en cas de dépassement de seuils critiques.

Ce projet vise ainsi à fournir une solution technologique complète, utile à la gestion
proactive des ressources dans un contexte de ville intelligente.

1.5 Conclusion
Ce chapitre a présenté le contexte, la problématique et les objectifs du projet. Il a posé
les bases nécessaires à la compréhension du système à développer. Le chapitre suivant
détaillera l’architecture technique mise en place.

3
Chapitre 2

Architecture du projet

4
Chapitre 2. Architecture du projet

2.1 Introduction
Ce chapitre détaille l’architecture technique mise en œuvre pour la collecte, le trai-
tement, la visualisation et la gestion des alertes des données issues des capteurs simulés.
Chaque composant, du serveur TCP aux fonctions AWS Lambda, est présenté afin de
comprendre le flux complet des données en temps réel. Cette architecture distribuée as-
sure robustesse, scalabilité et réactivité du système.

2.2 Vue d’ensemble de l’architecture

L’architecture du système développé repose sur une approche distribuée, conçue pour
assurer la collecte, le traitement, le stockage, la visualisation et l’alerte en temps réel des
données issues de capteurs simulés. Ces capteurs génèrent des données relatives à trois
ressources urbaines essentielles : l’eau, les déchets et l’énergie.
Le système est composé de plusieurs modules interconnectés :
• Des programmes Java simulant les capteurs, qui envoient les données via des sockets
TCP.
• Un serveur TCP multiclient chargé de recevoir les données et de les publier sur
Kafka Serverless.
• Une infrastructure Kafka assurant la diffusion des flux de données en temps réel.
• Un consommateur Kafka développé en Java qui extrait les messages et les insère
dans une base de données PostgreSQL.
• Un outil de visualisation (Grafana) connecté à la base de données pour permettre
l’affichage en temps réel des indicateurs.
• Un système d’alerte basé sur AWS Lambda, EventBridge et SES, qui surveille les
données et déclenche des notifications par e-mail en cas de dépassement de seuils
critiques.
Cette architecture modulaire permet une supervision efficace des ressources et peut
être étendue à d’autres types de données ou services dans le futur.

5
Chapitre 2. Architecture du projet

2.3 Schéma d’architecture

Fig. 2.1 : Schéma global de l’architecture du système

L’architecture du système repose sur une chaîne de traitement en temps réel, divisée en
plusieurs couches fonctionnelles interconnectées. Elle suit un modèle distribué assurant
modularité, scalabilité et réactivité. Voici les principaux composants et leur rôle :

• Sensors : Trois programmes Java (EauClient, DechetsClient et EnergyClient) gé-

nèrent des données périodiques en simulant des mesures réelles. Chaque client envoie
ses données via un socket TCP vers le serveur central.
• TCP Server : Ce serveur Java écoute sur un port défini et accepte plusieurs
connexions simultanées. Il réceptionne les messages des capteurs, les identifie se-
lon leur type, puis les publie sur les topics correspondants dans Kafka Serverless.
• AWS Managed Apache kafka : Ce composant joue le rôle de bus de données en
temps réel. Il permet la diffusion fiable des messages vers les consommateurs. Trois
topics sont créés : capteurs, dechets et energy, chacun recevant les données d’une
source précise.
• Consumer Kafka (KafkaToPostgres) : Un programme Java agit comme consom-
mateur des trois topics. Il extrait les messages, les parse et insère les données dans
la base de données PostgreSQL.
• Base de données PostgreSQL (RDS) : Les données sont stockées dans des
tables distinctes selon leur nature. Chaque entrée est horodatée, permettant un
suivi temporel précis.
• Grafana : Outil de visualisation des données. Il est connecté à PostgreSQL et
permet de créer des tableaux de bord temps réel pour afficher le niveau d’eau, le
niveau de déchets, la consommation énergétique, le courant et la tension.

6
Chapitre 2. Architecture du projet

• AWS Lambda : Un mécanisme d’alerte analyse périodiquement les données sto-

ckées. Si un seuil critique est atteint (ex. : énergie trop élevée, niveau d’eau trop
bas), une fonction Lambda est déclenchée par EventBridge, et un e-mail est envoyé
via Amazon SES.

Cette architecture permet une gestion proactive des ressources, un suivi en temps réel et
une réactivité optimale en cas d’anomalie.

2.4 Simulation des capteurs

Dans le cadre de ce projet, la génération des données capteurs a été simulée afin de
reproduire des mesures en temps réel sur trois domaines : l’eau, les déchets, et l’énergie.
Cette simulation permet de tester l’architecture distribuée sans dépendre de capteurs
physiques.

2.4.1 Description des programmes de simulation

Trois programmes Java distincts ont été développés, chacun simulant un type de cap-
teur :

• EauClient : Ce programme génère en continu deux paramètres clés liés à l’eau,

à savoir le débit et le niveau d’eau. Ces données représentent par exemple le flux
d’eau dans une canalisation et le niveau dans un réservoir.

• DechetsClient : Ce client simule le niveau des déchets dans un conteneur ou un

site de collecte. Seul le paramètre « niveau » est généré de manière continue.

• EnergyClient : Ce client produit plusieurs mesures liées à la consommation élec-

trique, notamment :

– énergie consommée en kW (energie_consomme_kW),

– courant en ampères (courant_A),
– tension en volts (tension_V).

2.4.2 Mécanisme de transmission des données

Chaque client simule l’envoi des données en continu vers le serveur central via des
sockets TCP. La connexion TCP est choisie pour sa simplicité et sa capacité à gérer un
flux continu et fiable de données entre les capteurs simulés et le serveur.
Les programmes clients établissent une connexion persistante avec le serveur TCP, et
transmettent périodiquement les mesures au format texte. Ce format contient le type de
capteur (via un préfixe), suivi des valeurs mesurées, ce qui permettra au serveur de diriger
les données vers les bons topics Kafka.

7
Chapitre 2. Architecture du projet

2.4.3 Fréquence et format des données

• La fréquence d’émission des données est configurée pour simuler une collecte en
quasi-temps réel, généralement plusieurs fois par seconde ou par minute selon la
capacité de traitement.

• Chaque message suit un format standardisé permettant un traitement aisé en aval,

par exemple :

capteurs;debit=15.3;niveau=4.2
dechets;niveau=75.0
energy;energie_consomme_kW=5.7;courant_A=10.2;tension_V=230.0

Ce format facilite le parsing côté serveur TCP et le routage vers les topics Kafka
correspondants.

2.5 Serveur TCP multiclient

Le serveur TCP joue un rôle central dans l’architecture du projet. Il agit comme point
de collecte des données envoyées par les différents clients simulant les capteurs. Sa fonction
principale est de recevoir, traiter et router ces données vers la plateforme de streaming
Kafka.
Pour permettre la réception simultanée de données provenant de multiples clients, le
serveur est conçu selon un modèle multithread. Chaque nouvelle connexion client est
gérée par un thread dédié, ce qui garantit que plusieurs clients peuvent envoyer leurs flux
de données en parallèle sans blocage.
La communication entre les clients et le serveur s’effectue via des sockets TCP, un
protocole fiable orienté connexion qui assure l’intégrité et l’ordre des messages transmis.
À la réception d’un message, le serveur analyse le préfixe (par exemple capteurs,
dechets ou energy) pour identifier la catégorie des données. En fonction de ce préfixe, il
publie ensuite le message dans le topic Kafka correspondant.
Cette architecture permet un traitement temps réel efficace et scalable des données
issues des capteurs.

2.6 Transmission des données via Kafka

La transmission des données capteurs vers la plateforme de traitement en temps réel
est assurée par Kafka Serverless (Amazon MSK). Kafka permet de gérer un flux important
de données avec une faible latence et une haute disponibilité.
Les topics Kafka sont configurés pour correspondre aux différents types de données :

• capteurs pour les données liées à l’eau,

8
Chapitre 2. Architecture du projet

• dechets pour les données concernant les déchets,

• energy pour les mesures d’énergie.

L’authentification avec Kafka est assurée via AWS IAM, garantissant une sécurité
renforcée grâce au fichier [Link] qui permet la connexion
sécurisée entre le serveur TCP et Kafka.
Le serveur TCP agit comme producteur Kafka : il publie les messages reçus dans
les topics correspondants en fonction du préfixe contenu dans chaque message. Cette
intégration permet un traitement et une consommation des données en temps réel par la
suite.

2.7 Stockage des données dans PostgreSQL

Les données transmises via Kafka sont consommées par un consommateur Java (Kaf-
kaToPostgres) chargé d’insérer les mesures dans une base de données relationnelle Post-
greSQL.
La structure des tables a été définie pour optimiser la gestion des données capteurs :

• eau_capteurs : stocke le débit et le niveau d’eau,

• dechets_capteurs : stocke le niveau des déchets,

• energy_capteurs : stocke la consommation d’énergie, le courant et la tension.

Chaque table contient un identifiant unique, les mesures, ainsi qu’un timestamp au-
tomatique pour horodater chaque enregistrement.
Le consommateur Kafka lit les messages des topics, les parse, et insère les données
dans les tables correspondantes en temps réel, garantissant la cohérence et la persistance
des informations.

2.8 Visualisation avec Grafana

Grafana est utilisé pour visualiser en temps réel les données collectées et stockées
dans PostgreSQL. La connexion à la base de données est configurée via un datasource
PostgreSQL.
Les dashboards Grafana présentent plusieurs graphiques :

• Niveau d’eau dans le temps,

• Niveau des déchets dans le temps,

• Énergie consommée, courant et tension affichés en temps réel.

Les requêtes SQL typiques utilisées pour alimenter les graphiques sont, par exemple :

9
Chapitre 2. Architecture du projet

SELECT timestamp, niveau FROM eau_capteurs ORDER BY timestamp DESC LIMIT 100;
SELECT timestamp, niveau FROM dechets_capteurs ORDER BY timestamp DESC LIMIT 100;
SELECT timestamp, energie_consomme_kW, courant_A, tension_V FROM energy_capteurs ORDER

Cette visualisation permet un suivi dynamique des mesures et facilite la prise de

décision en fonction des données observées.

2.9 Système d’alerte avec AWS Lambda

Pour assurer la surveillance proactive des données, un système d’alerte a été mis en
place à l’aide des fonctions AWS Lambda.
Ces fonctions sont déclenchées périodiquement via Amazon EventBridge, toutes les
minutes, pour analyser les données dans PostgreSQL.
Les conditions d’alerte définies sont les suivantes :

• L’énergie consommée dépasse un seuil critique,

• Le niveau d’eau descend en dessous d’un seuil minimal,

• Le niveau des déchets dépasse un seuil maximal.

Lorsque ces conditions sont remplies, AWS Lambda déclenche l’envoi automatique
d’e-mails d’alerte via Amazon Simple Email Service (SES) pour notifier les opérateurs
responsables.
Ce système garantit une réaction rapide face aux anomalies détectées dans les données
capteurs.

2.10 Conclusion
L’architecture conçue permet une gestion efficace des données capteurs en temps réel,
depuis la réception via sockets TCP jusqu’à la visualisation et la génération d’alertes
automatisées. L’utilisation combinée de technologies comme Kafka, PostgreSQL, Grafana
et AWS Lambda garantit une solution évolutive et fiable. Ce socle technique ouvre la voie
à des extensions futures pour un monitoring encore plus avancé.

10
Chapitre 3

Réalisation

11
Chapitre 3. Réalisation

Introduction

Ce chapitre décrit en détail le processus de mise en œuvre du système développé.

Chaque étape, depuis la génération des données jusqu’à leur visualisation, est présentée
en mettant en lumière les choix techniques adoptés et les outils utilisés.

3.1 Envoi des données des capteurs au serveur

Les captures d’écran suivantes montrent l’envoi des données par les programmes locaux
qui simulent le fonctionnement des capteurs dans la ville intelligente.

Fig. 3.1 : Les capteurs de gestion de l’eau.

Fig. 3.2 : Les capteurs de gestion de l’énergie.

12
Chapitre 3. Réalisation

Fig. 3.3 : Les capteurs de gestion des déchets

3.2 Réception des données par le serveur TCP

Cette capture d’écran montre le bon fonctionnement du serveur TCP à recevoir les
données des capteurs.

Fig. 3.4 : Réception des données des capteurs par le serveur TCP

3.3 Gestion des flux de données avec Kafka

Cette capture d’écran montre la bonne réception des données depuis le serveur et leur
insertion dans AWS RDS.

13
Chapitre 3. Réalisation

Fig. 3.5 : Gestion du flux de données par Kafka

3.4 Stockage des données dans la base de données

Fig. 3.6 : Stockage des mesures de gestion de l’eau

Fig. 3.7 : Stockage des mesures de gestion de l’énergie

14
Chapitre 3. Réalisation

Fig. 3.8 : Stockage des mesures de gestion des déchets

3.5 Tableaux de bord Grafana

Après l’insertion des données sur l’eau, l’énergie et les déchets dans AWS RDS postgres
dans une base de données, nous avons créé 3 tableaux de bord sur Grafana pour chaque
service avec différentes visualisations, les voici :

Fig. 3.9 : Capture d’écran du tableau de bord de l’eau

15
Chapitre 3. Réalisation

Fig. 3.10 : Capture d’écran du tableau de bord d’énergie

Fig. 3.11 : Capture d’écran du tableau de bord des dechets

Conclusion
Cette phase de réalisation a permis d’intégrer les différents composants du système
de manière cohérente et fonctionnelle. Le pipeline complet assure un traitement fluide et
automatisé des données en temps réel. Les résultats obtenus montrent la robustesse et la
réactivité de l’architecture développée.

16
Conclusion générale

Ce projet a permis de concevoir et de déployer une architecture distribuée complète

dédiée à la collecte, au traitement, à la visualisation et à la surveillance des données de
capteurs en temps réel. En simulant les données relatives à l’eau, l’énergie et les déchets,
puis en les intégrant dans un pipeline technologique combinant un serveur TCP multi-
client, Kafka Serverless, PostgreSQL, Grafana, et AWS Lambda, nous avons mis en œuvre
une solution moderne, automatisée et extensible pour la gestion intelligente des ressources.
Ce système démontre non seulement la faisabilité d’un tel écosystème technologique
dans un contexte d’IoT, mais aussi sa pertinence pour le suivi environnemental, la main-
tenance prédictive ou encore la gestion intelligente des infrastructures urbaines.
En perspective, plusieurs axes d’amélioration sont envisageables : remplacer les cap-
teurs simulés par des capteurs physiques connectés (IoT), intégrer des modèles d’appren-
tissage automatique pour anticiper les anomalies, ou encore étendre la plateforme à une
architecture multi-utilisateurs avec authentification et tableaux de bord personnalisés. Ce
projet constitue ainsi une base solide pour le développement de solutions intelligentes à
grande échelle.

17