Grin logo
de en es fr
Shop
GRIN Website
Publish your texts - enjoy our full service for authors
Go to shop › Electrotechnology

Conception et Réalisation d’un prototype du système de contrôle d’un Réseau d’eau dans un Milieu Urbain par IOT. Cas de la REGIDESO /Goma

Summary Excerpt Details

La gestion des réseaux de distribution d'eau en milieu urbain constitue un défi majeur en raison des pertes d'eau causées par les fuites, des difficultés de surveillance en temps réel et de l'absence d'un système intelligent de suivi des paramètres du réseau. Dans le cas de la REGIDESO/Goma, ces contraintes rendent difficile une gestion efficace du réseau de distribution d'eau.

Face à cette problématique, ce travail avait pour objectif de concevoir un système de contrôle d’un réseau de distribution d'eau basé sur l'Internet des Objets (IoT). Plus précisément, il s'agissait de détecter les fuites, de mesurer le débit et le pH de l'eau, de transmettre les données en temps réel vers une base de données MySQL à l'aide du module NodeMCU ESP8266, d'assurer leur visualisation sur une interface de supervision et de permettre la commande automatique ou manuelle de la pompe.
Les résultats obtenus montrent que le système conçu permet de détecter les fuites en temps réel, de mesurer le débit et le pH de l'eau, d'arrêter automatiquement la pompe en cas de fuite ou de pH anormal, d'envoyer les données vers une base de données pour leur consultation à distance et d'assurer une supervision efficace du réseau à travers une interface web. Cette solution contribue ainsi à améliorer la surveillance du réseau et à réduire les pertes d'eau.

Comme perspective, il est recommandé de déployer ce système sur un réseau réel de la REGIDESO afin d'évaluer ses performances en conditions réelles, d'étendre son utilisation à plusieurs zones de distribution et d'intégrer des technologies de communication longue portée telles que LoRaWAN ou NB-IoT, afin d'améliorer la couverture, la fiabilité des communications et les performances du système de surveillance.

Excerpt


Table des matières

EPIGRAPHE

DEDICACE

REMERCIEMENTS

SIGLES ET ABREVIATIONS

Liste des figures

Liste des tableaux

RESUME

ABSTRACT

0. INTRODUCTION GÉNÉRALE
0.1. État de la question
0.2. Problématique
0.3. Questions de recherches
0.3.1. Question Principale
0.3.2. Questions spécifiques
0.4. Hypothèses
0.4.1. Hypothèses principales
0.4.2. Hypothèses spécifiques
0.5. Objectif de la Recherche
0.5.1. Objectif Global
0.5.2. Objectifs Spécifiques
0.6. Choix et Intérêt du Sujet
0.7. Délimitation du Travail
0.8. Méthodologie de Recherche
0.9. Subdivision du Travail

Chapitre 1 : CADRE THEORIQUE
1. 0. Introduction
1.1. Les Réseaux de Distribution d'Eau Potable (RDEP)
1.1.1. Architecture d'un réseau hydraulique urbain
1.1.2. Les Ouvrages de Captage et de Traitement
1.1.3. Réseau d’adduction
1.1.4. Les Ouvrages de Stockage et de Mise en Pression
1.1.5. Le Réseau de Distribution
1.2. Les problématiques de gestion d’un système de distribution de l’eau
1.2.1. Les Pertes en Ligne (Le Rendement du Réseau)
1.2.2. La Gestion de la Pression
1.2.3. La Dégradation de la Qualité de l'Eau
1.2.4. La Complexité du Maillage Urbain
1.3. Microcontrôleur Arduino et nodemcu
1.3.1. Arduino
1.3.2. Architecture Matérielle (Hardware)
1.3.3. Caractéristiques Techniques (Modèle Type : Uno R3/V4)
1.3.4. L'Environnement de Programmation (Software) développement intégré
1.3.5. Nodemcu (ESP8266)
Interfaces d'Entrées/Sorties (I/O)
CONCLUSION

Chapitre 2 : Analyse Conceptuelle du Système
2.1. Introduction
2.2. Analyse et conception électronique
2.3. Choix et Spécifications des Unités de Traitement et de Communication
2.3.1. Le Microcontrôleur Principal : ATmega328P (Format DIP-28)
2.3.2. Le Module de Communication : NodeMCU ESP8266 (Version ESP-12E)
2.4. Étude et dimensionnement théorique
2.4.1. Bloc d'Alimentation et de Régulation (7805)
2.4.2. Dimensionnement de la Commande des Pompes (Transistors NPN)
2.5. Étage d'Interface de Puissance et Commande des Pompes
2.5.1. Transistor de Commutation : NPN 2N2222A (Boîtier TO-92) Pour le 2n2222 sont choix est dictée par la puissance de la pompe du prototype
2.5.2. Diode de Roue Libre : 1N4007 (Boîtier DO-41)
2.5.3. Bloc d'Affichage Local : Écran LCD 16x2 (Pilote HD44780)
2.5.4. Circuit d'Horloge Externe (Quartz et Résonance)
2.5.5. Capteur de pH (Référence : Kit analogique DFRobot SEN0161)
2.5.6. Capteur de Débit (Référence : YF-S201)
2.5.7. Capteur de Niveau / Fuite (Référence : Capteur de niveau d'eau capacitif / résistif standard)
2.6. Interfaçage
2.6.1. Rôle du centre de contrôle
2.6.2. Nature des informations reçues et traitées
2.6.3. Centre de Contrôle
2.7. Protocole de Communication
CONCLUSION

Chapitre 3: Réalisation et présentation des résultats
3.1. Introduction
3.2. Schéma électronique fonctionnel
3.3. Principe de fonctionnement du schéma électronique
3.4. Algorithme de fonctionnement du système
3.5. Simulation
3.6. Résultats
3.7. Interface monitoring
0. Interface de login
1. Interface de Dashboard
2. Historique

CONCLUSION GÉNÉRALE

Table des matières

BIBLIOGRAPHIE

ANNEXES

CODE SOURCE

EPIGRAPHE

« Les scientifiques étudient le monde tel qu'il est ; les ingénieurs créent le monde qui n'a jamais existé. »

Theodore von Kármán

DEDICACE

A ma regrettée mère, Henriette Muke.

Bien que ton départ prématuré t'empêche de voir ce jour, l'humanisme, la bonté et les valeurs de vie que tu as semés en moi restent ma plus belle boussole. Tes prières silencieuses et tes conseils précieux continuent de guider mes pas au quotidien, m'apprenant que la science et l'ingénierie ne valent rien si elles ne sont pas mises au service de notre prochain.

À toi qui m'as inculqué la résilience face aux épreuves et l’amour inconditionnel des autres, je t'offre cet humble témoignage de ma profonde gratitude. Que cette œuvre soit le reflet de la grandeur de ton âme.

REMERCIEMENTS

Nous tenons à exprimer notre profonde gratitude à tous ceux qui, par leur science, leurs conseils, leur générosité et leur affection, ont rendu ce projet possible.

Nous tenons avant tout à remercier notre Seigneur Dieu Tout-Puissant pour le souffle de vie, la santé et la force qu'Il nous a accordés tout au long de ce parcours académique.

Nos remerciements les plus sincères s'adressent à notre directeur, le Master Ing. Gershome Pawase. Ses orientations précieuses, sa rigueur scientifique, sa disponibilité constante et ses sages conseils ont été la boussole qui a guidé nos pas depuis la genèse de ce projet jusqu'à sa matérialisation.

Nous témoignons notre profonde gratitude au corps professoral et aux autorités académiques de l'UNITECH Goma (Ing. Richard Rwanika, Doctorant Ing. Matina Muyisa, Msc.Ing. Pacifique Mugisha ) pour la qualité de l'enseignement dispensé et le dévouement dont ils font preuve pour façonner les ingénieurs de demain. Une reconnaissance s'adresse à l’ingénieur Blaise Letakamba, pour son soutien technique et son encadrement. Sur le plan personnel, les mots me manquent pour exprimer l'immensité de ma gratitude envers un couple d'exception, Aldo Kutelama et Nadine Kisonia. Vous avez été bien plus qu'un soutien dans mon parcours : vous en avez été les gardiens. Face aux tempêtes, votre présence morale constante a été mon refuge, et votre générosité indéfectible a été le moteur qui m'a permis de garder la tête haute et de poursuivre mes rêves d'ingénieur. À travers vos innombrables sacrifices, votre bienveillance et votre foi en moi, vous m'avez montré ce que signifient la vraie bonté et la solidarité humaine. Que ce travail, qui est aussi le vôtre, soit le témoignage éternel de ma profonde affection et de ma reconnaissance infinie.

À mon cher père, KAMBALE Kisonia Jérôme, pour l'éducation, les valeurs de courage, de dignité transmise, et pour le soutien paternel constant qui n'a jamais failli.

Enfin, que tous nos compagnons de lutte, amis et collègues de promotion trouvent ici l'expression de notre sincère camaraderie pour les moments de partage et d'émulation scientifique

À vous tous, merci.

SIGLES ET ABREVIATIONS

ADC: Analog-to-Digital Converter (convertisseur Analogique-Numérique) API: Application Programming Interface (Interface de programmation) ARM: Advanced RISC Machine

AVR: Alf and Vegard's

DAC: Digital-to-Analog Converter (convertisseur Numérique-Analogique).

GPIO: General Purpose Input/Output (Broches d'entrée/sortie)

HTTP / HTTPS: Hypertext Transfer Protocol (Secure).

I2C: Circuit Inter-Intégré

IHM / GUI : Interface Homme-Machine / Graphical User Interface

IOT: Internet of Things

MQTT : Message Queuing Telemetry Transport (Protocole de messagerie)

NodeMCU: Node Microcontroller Unit.

NTU: Nephelometric Turbidity Unit (Unité de mesure de la turbidité)

OTA: Over-The-Air.

pH: Potentiel Hydrogène.

RDC: République Démocratique du Congo RDEP: Réseau de Distribution d'Eau Potable REGIDESO: Régie de Distribution d'Eau RTC: Real-Time Clock (Horloge en temps réel)

SCADA: Supervisory Control and Data Acquisition (en français : Système de contrôle et d'acquisition de données).

SoC: System on Chip .

STEP: Station d'Épuration

TDS: Total Dissolved Solids (Total des Solides Dissous).

Ultrasons (HC-SR04)

UNITECH: Université Internationale des Nouvelles Technologies

USB: Universal Serial Bus (en français : Bus universel en série).

WEB: World Wide Web

WLAN: Wireless Local Area Network (Réseau local sans fil / Wi-Fi).

Liste des figures

Figure 1. Image de l’ouvrage de captage et de traitement d’eau

Figure 2. Image montrant le transport de l’eau par de tuyaux

Figure 3. Ouvrage de stockage et de mise en pression

Figure 4. Réseau de distribution maillée et réseau de distribution ramifié

Figure 5. Carte Arduino Uno

Figure 6. Architecture d’une carte Arduino

Figure 7. La carte NodeMCU ESP 8266

Figure 8. Schéma bloc de notre système

Figure 9. Circuit de commande de la Pompe

Figure 10. Transistor NPN 2N2222A

Figure 11. Diode de Roue libre

Figure 12. Ecran LCD (Pilote HD44780)

Figure 13. Quart piézoélectrique 16.0MHz

Figure 14. Capteur de pH

Figure 15. Capteur de Débit

Figure 16. Capteur de Niveau

Figure 17. Les parties de la base des données

Figure 18. schéma de réalisation

Figure 19. Algorithme de fonctionnement

Figure 20. Simulation du système en cours de fonctionnement normal

Figure 21. Simulation de notre système lors de la détection d’une fuite

Figure 22. Simulation du système en cours de mesure de débit

Figure 23. Image avant emplacement de la pompe

Figure 24. Affichage à l’écran de diverses informations relatives à notre système

Figure 25. Image générale de la maquette après emplacement de la pompe

Figure 26. Page de login

Figure 27. Page du Dashboard

Figure 28. Page Historique du Systèm

Liste des tableaux

Tableau 1. Caracteristiques Arduino Nano

RESUME

La gestion des réseaux de distribution d'eau en milieu urbain constitue un défi majeur en raison des pertes d'eau causées par les fuites, des difficultés de surveillance en temps réel et de l'absence d'un système intelligent de suivi des paramètres du réseau. Dans le cas de la REGIDESO/Goma, ces contraintes rendent difficile une gestion efficace du réseau de distribution d'eau.

Face à cette problématique, ce travail avait pour objectif de concevoir un système de contrôle d’un réseau de distribution d'eau basé sur l'Internet des Objets (IoT). Plus précisément, il s'agissait de détecter les fuites, de mesurer le débit et le pH de l'eau, de transmettre les données en temps réel vers une base de données MySQL à l'aide du module NodeMCU ESP8266, d'assurer leur visualisation sur une interface de supervision et de permettre la commande automatique ou manuelle de la pompe.

Les résultats obtenus montrent que le système conçu permet de détecter les fuites en temps réel, de mesurer le débit et le pH de l'eau, d'arrêter automatiquement la pompe en cas de fuite ou de pH anormal, d'envoyer les données vers une base de données pour leur consultation à distance et d'assurer une supervision efficace du réseau à travers une interface web. Cette solution contribue ainsi à améliorer la surveillance du réseau et à réduire les pertes d'eau.

Comme perspective, il est recommandé de déployer ce système sur un réseau réel de la REGIDESO afin d'évaluer ses performances en conditions réelles, d'étendre son utilisation à plusieurs zones de distribution et d'intégrer des technologies de communication longue portée telles que LoRaWAN ou NB-IoT, afin d'améliorer la couverture, la fiabilité des communications et les performances du système de surveillance

Mots-clés: IoT, ATmega328P, NodeMCU, Détection de fuites, Supervision hydraulique, Application Web.

ABSTRACT

The management of urban water distribution networks is a major challenge due to water losses caused by leaks, difficulties in real-time monitoring, and the absence of an intelligent system for tracking network parameters. In the case of REGIDESO/Goma, these constraints make effective management of the water distribution network difficult.

To address this issue, the objective of this work was to design a control system for a water distribution network based on the Internet of Things (IoT). More specifically, the system aimed to detect leaks, measure water flow and pH, transmit data in real time to a MySQL database using the NodeMCU ESP8266 module, ensure visualization through a supervision interface, and allow automatic or manual control of the pump.

The results obtained show that the designed system can detect leaks in real time, measure water flow and pH, automatically stop the pump in case of a leak or abnormal pH, send data to a database for remote consultation, and ensure effective supervision of the network through a web interface. This solution thus contributes to improving network monitoring and reducing water losses.

As a perspective, it is recommended to deploy this system on a real REGIDESO network to evaluate its performance under real conditions, extend its use to several distribution zones, and integrate long-range communication technologies such as LoRaWAN or NB-IoT to improve coverage, communication reliability, and system performance.

Keywords : IoT, ATmega328P, NodeMCU, Leak Detection, Hydraulic Supervision, Web Application.

0. INTRODUCTION GÉNÉRALE

0.1. État de la question

L'eau constitue le socle fondamental de toute forme de vie sur Terre, agissant non seulement comme une ressource biologique vitale, mais aussi comme un moteur essentiel du développement socio-économique des nations dans le monde. Elle influence la santé publique, la sécurité alimentaire et l'équilibre des écosystèmes. Cependant, la croissance démographique mondiale et l'urbanisation galopante exercent une pression sans précédent sur les infrastructures de distribution, rendant la gestion efficace des ressources hydrauliques l'un des défis majeurs du XXIe siècle et du futur. Assurer un accès équitable et durable à cette ressource nécessite une surveillance constante et rigoureuse, afin de minimiser les pertes et de garantir la qualité de l'approvisionnement pour les populations civiles et industrielles.

À l'échelle mondiale, la surveillance des réseaux hydrauliques a traditionnellement reposé sur des approches conventionnelles et des infrastructures lourdes. Historiquement, la détection des anomalies dans les réseaux de distribution s'effectuait par des inspections physiques périodiques ou par l'utilisation de systèmes SCADA (Supervisory Control and Data Acquisition). Bien que performants pour le contrôle industriel, ces systèmes s'avèrent extrêmement coûteux, rigides et complexes à déployer sur de vastes zones urbaines, particulièrement dans les contextes où les budgets sont limités [1].

Les recherches récentes au niveau international se sont donc tournées vers des solutions plus agiles. Des auteurs comme Zane et al. (2020) ont ainsi mis en lumière le potentiel de l'Internet des Objets (IoT) pour transformer cette gestion. L'usage de réseaux de capteurs sans fil permet désormais une collecte de données en temps réel à un coût nettement inférieur, facilitant une maintenance prédictive plutôt que curative. Néanmoins, la littérature scientifique globale montre souvent une fragmentation des solutions, où les travaux se concentrent soit exclusivement sur la détection des fuites, soit uniquement sur les paramètres physico-chimiques liés à la qualité de l'eau. [2]

Au niveau local, et plus spécifiquement dans les villes de l'Est de la République Démocratique du Congo comme Goma, la problématique prend une dimension particulière liée aux contraintes structurelles et énergétiques. Les infrastructures existantes peinent à répondre à la densité urbaine croissante, et les pertes d'eau non facturées ainsi que les ruptures de canalisations sont fréquentes. Des initiatives académiques locales ont commencé à s'emparer de ce sujet pour proposer des solutions contextuelles. On peut citer, par exemple, les travaux menés à l’Institut Supérieur d’Informatique et de Gestion (ISIG) en 2024. Kakule Joseph a notamment développé un système de détection de fuites ciblant spécifiquement l'intégrité physique du réseau hydraulique, tandis qu'Ilunga Kabuyaya s'est concentré sur le monitoring de la qualité de l’eau via des interfaces web. Bien que ces études constituent des avancées significatives pour la région, elles restent souvent limitées à une seule dimension du problème, laissant de côté l'interdépendance entre la pression, le débit et la consommation réelle des abonnés.

L'originalité de la présente étude réside dans la conception d'un système intégré et logistique, capable de fusionner plusieurs paramètres critiques au sein d'une interface unique. Contrairement aux approches segmentées observées précédemment, ce travail propose une architecture capable de surveiller simultanément le débit, la pression et la détection de défauts, tout en intégrant une gestion fine de la consommation. La force de cette solution repose sur son adaptation stricte aux réalités locales : elle est conçue pour fonctionner malgré l'instabilité du réseau électrique et la configuration dense des quartiers de Goma. En privilégiant l'utilisation de composants électroniques accessibles et à bas coût, ce projet vise à démocratiser l'accès à une technologie de pointe pour les gestionnaires d'eau locaux, rendant le système non seulement techniquement robuste, mais aussi économiquement abordable pour une implémentation à grande échelle.

0.2. Problématique

La problématique de la gestion de l'eau à Goma, et plus spécifiquement au sein du réseau de la REGIDESO, met en exergue un décalage profond entre une situation théorique idéale et une réalité opérationnelle marquée par l'obsolescence et l'incertitude.[3] Dans un scénario optimal, une régie de distribution d'eau devrait disposer d'une visibilité totale sur son infrastructure : chaque mètre cube pompé à la station de traitement devrait être traçable jusqu'au robinet de l'abonné, avec une pression constante et une détection instantanée de toute rupture de canalisation. Cependant, la

Situation courante à Goma révèle une gestion largement "aveugle", où l'information ne circule qu'a posteriori, souvent suite aux plaintes des usagers.

Le premier constat critique au sein de la REGIDESO concerne l'absence de monitoring granulaire. Actuellement, la surveillance du réseau repose sur des méthodes archaïques de relevés manuels ou sur l'observation visuelle des fuites de surface. Cette gestion opaque empêche une lecture en temps réel de la consommation par quartier. En l'absence de données précises sur le débit et la pression en différents points stratégiques, la répartition de l'eau devient inéquitable. Certains quartiers subissent des pénuries chroniques tandis que d'autres reçoivent un surplus non contrôlé, simplement parce que l'administration manque d'outils d'aide à la décision pour équilibrer les flux en fonction de la demande réelle.

Les conséquences de ce manque de surveillance sont multiples et graves. Sur le plan économique, les pertes non techniques principalement des fuites souterraines non détectées représentent un manque à gagner colossal. Les fuites d'eau traitée à grands frais se perd dans le sol sans jamais être facturée, affaiblissant la capacité financière de la régie à entretenir son réseau. Sur le plan technique, l'impossibilité de localiser avec précision une panne ou un défaut de réseau retarde considérablement les interventions de maintenance. Une fuite importante dans une zone dense peut mettre plusieurs jours avant d'être identifiée et isolée, aggravant les dommages structurels aux routes et aux habitations environnantes.

Au-delà de l'aspect financier, les défauts de réseaux non maîtrisés engendrent des risques sécuritaires et sanitaires. Les ruptures de canalisations sous haute pression peuvent provoquer des affaissements de terrain ou des inondations localisées, mettant en danger les populations riveraines. De plus, lorsqu'une canalisation est percée, la baisse de pression peut favoriser l'intrusion de polluants extérieurs dans le circuit d'eau potable, transformant une infrastructure vitale en vecteur de maladies hydriques. C'est ici que la différence entre la "situation supposée parfaite" (une eau saine et un réseau intègre) et la "situation courante" (un réseau poreux et instable) devient la plus alarmante.

Face à ce diagnostic, la question centrale de la recherche s'impose : comment transformer cette infrastructure passive en un réseau intelligent grâce à l'Internet des Objets (IoT) ? L'enjeu est de concevoir un système capable de capturer les paramètres critiques débit, pression, consommation et de les transmettre à une plateforme centrale à moindre coût.

En intégrant des capteurs abordables et adaptés aux contraintes énergétiques locales, il devient possible de fournir à la REGIDESO un tableau de bord décisionnel. Ce système ne se contente pas de signaler les pannes ; il permet une transition vers une gestion proactive, où chaque anomalie est géo-localisée instantanément, réduisant ainsi les délais d'intervention et garantissant une distribution plus juste et sécurisée de la ressource.

0.3. Questions de recherches

0.3.1. Question Principale

Comment concevoir et déployer une architecture IoT intégrée, à bas coût et résiliente, permettant à la REGIDESO d'assurer le monitoring en temps réel du débit, de la pression et de la détection de fuites dans le contexte spécifique des infrastructures urbaines de Goma de la REGIDESO ?

0.3.2. Questions spécifiques

Pour répondre à cette problématique globale, notre recherche doit répondre aux sous-questions spécifiques suivantes :

· Quels sont les parties stratégiques du réseau de la REGIDESO nécessitant le monitoring ?
· Comment concevoir une unité d'acquisition de données (nœud capteur) et de monitoring capable de fonctionner de manière autonome malgré l'instabilité du réseau électrique et les coupures fréquentes à Goma ?
· Dans quelle mesure l'intégration de ce système IoT permet-elle de réduire significativement le taux d'eau non facturée et les délais d'intervention technique par rapport aux méthodes d'inspection traditionnelles ?

0.4. Hypothèses

0.4.1. Hypothèses principales

L'implémentation d'un système de monitoring basé sur l'Internet des Objets (IoT), utilisant des composants électroniques à bas coût et une architecture de communication résiliente, permettrai t à la REGIDESO de réduire significativement les pertes d'eau non techniques et d'optimiser la maintenance curative grâce à une géolocalisation précise et instantanée des anomalies sur le réseau urbain de Goma.

0.4.2. Hypothèses spécifiques

Pour répondre à cette question, nous formulons les hypothèses suivantes :

· Le monitoring ciblerait en priorité les sorties des réservoirs de stockage, les nœuds de sectorisation du réseau maillé et les conduites terminales sensibles aux variations de pression.
· L'intégration d'un système de gestion d'énergie hybride (batterie + secteur) au niveau des nœuds capteurs garantirait la continuité de la surveillance du réseau, même pendant les périodes de délestage électrique fréquentes dans la ville.
· La réduction du temps de détection des pannes (passant de quelques jours à quelques minutes) diminuerait drastiquement les risques d'affaissement de terrain et d'inondations localisées causés par les ruptures de conduites.

0.5 .Objectif Global

Concevoir et de réaliser un prototype de système de monitoring intelligent et à bas coût (IoT), capable d'assurer la surveillance en temps réel des paramètres hydrauliques (débit et pression) et la détection automatisée des fuites sur le réseau de distribution de la REGIDESO à Goma.

0.5.1. Objectifs Spécifiques

Pour atteindre cet objectif global, nous nous fixons les missions suivantes :

· Identifier les points du réseau de la REGIDESO pouvant être monitorer afin d’avoir les information complète sur le réseau.
· Mettre en œuvre un système IOT permettant l’échange des informations de l’état du réseau avec le centre de contrôle.
· Évaluer l’impact du système par rapport à la REGIDESO et à la population de Goma

0.6. Choix et Intérêt du Sujet

Ce sujet présente un intérêt sur plusieurs plans :

· Sur le plan scientifique, il contribue à l'application des technologies de l'Internet des Objets (IoT) dans le domaine de la gestion intelligente des réseaux de distribution d'eau. Il constitue également une base de recherche pour le développement de solutions innovantes intégrant les systèmes embarqués, les réseaux de capteurs et les technologies de communication modernes.
· Sur le plan social, ce travail vise à améliorer la qualité du service de distribution d'eau en permettant une détection rapide des fuites, une intervention plus efficace et une réduction des interruptions d'approvisionnement, contribuant ainsi au bien-être de la population.
· Sur le plan politique, cette étude fournit une solution technologique pouvant appuyer les politiques publiques de modernisation des infrastructures hydrauliques et de gestion durable des ressources en eau. Elle peut également accompagner les autorités et les entreprises publiques, notamment la REGIDESO, dans leur processus de transformation numérique.
· Sur le plan économique, le système proposé permet de réduire les pertes d'eau, d'optimiser l'exploitation du réseau et de diminuer les coûts liés aux interventions tardives, aux réparations et au gaspillage de la ressource, tout en améliorant la rentabilité de l'entreprise de distribution.
· Sur le plan sanitaire, la surveillance continue du pH de l'eau contribue à garantir une meilleure qualité de l'eau distribuée. En détectant rapidement toute anomalie et en arrêtant automatiquement la distribution lorsque le pH devient anormal, le système participe à la protection de la santé publique en limitant les risques liés à la consommation d'une eau non conforme.
· Sur le plan personnel consiste à approfondir les connaissances en systèmes embarqués et en communication sans fil et à obtenir un diplôme d’ingénieur.

0.7. Délimitation du Travail

Dans l'espace, cette étude se focalisera sur le réseau de distribution de la ressource en eau de la REGIDESO dans la ville de Goma en général et dans le quartier Office 2 en particulier ; couvrant la période allant de janvier à mai et cela dans l’année 2026. Nous nous limitons à la surveillance (monitoring), à la détection de pannes et non à la facturation automatique ou au traitement chimique de l'eau.

0.8. Méthodes et techniques des Recherches

Pour mener à bien cette étude, nous utiliserons :

· La méthode itérative (prototypage) : pour la conception du système électronique. Nous utiliserons un microcontrôleur (ESP8266) et d'autres capteurs disponibles à un bon prix dans la ville de Goma.
· La méthode d’Analyse et expérimentation : Tests pratiques des capteurs pour calibrer les seuils d'alerte. Ici nous ferons des tests pour enfin valider si cela fonctionne où améliorer le système.
· La technique documentaire : Consultation d'ouvrages, d'articles et de thèses sur l'IoT et l'hydraulique.

0.9. Subdivision du Travail

Hormis l'introduction et la conclusion, ce travail est organisé en trois chapitres :

· Chapitre 1 : Généralités et État de l'art. Présentation des concepts de l'IoT et des réseaux d'eau de la REGIDESO.
· Chapitre 2 : Analyse et Conception du Système. Étude technique, choix des composants et modélisation de l'architecture.
· Chapitre 3 : Réalisation et Présentation des Résultats. Mise en œuvre du prototype, programmation et tests.

Chapitre 1 : CADRE THEORIQUE

1.0. Introduction

La mise en œuvre d’un système de surveillance intelligent pour un réseau d’eau en milieu urbain repose sur une convergence disciplinaire entre l’hydraulique classique et les technologies de l’information. Dans ce chapitre, nous allons présenter l’inventaire des concepts théoriques et des outils fondamentaux nécessaires à la compréhension et à la réalisation de notre projet. Dans ce chapitre, nous présenterons les différends.

1.1. Les Réseaux de Distribution d'Eau Potable (RDEP)

Le Réseau de Distribution d'Eau Potable (RDEP) constitue le niveau final et la plus complexe du cycle anthropique de l'eau. Il s'agit d'un ensemble d'infrastructures de génie civil et hydraulique conçu pour transporter l'eau, depuis les stations de traitement ou les réservoirs de stockage, jusqu'au robinet du consommateur final, tout en garantissant une pression suffisante et une qualité sanitaire irréprochable. [4]

1.1.1. Architecture d'un réseau hydraulique urbain

L'architecture d'un réseau d'eau en milieu urbain ne se résume pas à une simple pose de tuyaux c'est un système hiérarchisé conçu pour maintenir une pression constante et une disponibilité permanente. Permettant de garantir une fiabilité de distribution d’eau, il est généralement constitué de quatre parties principales :

1.1.2. Les Ouvrages de Captage et de Traitement

C'est le point de départ. L'eau est prélevée (nappes phréatiques, rivières ou barrages) puis traitée dans une Station de Traitement d'Eau Potable (STEP) pour répondre aux normes de potabilité. Le captage d’eau doit c’est la partie la plus importante il doit répondre aux normes pour éviter de mettre en danger les consommateurs. A ce niveau on effectue aussi le traitement physico-chimique de l’eau entre autres :

· Coagulation-Floculation : Ajout de réactifs chimiques (comme des sels d'aluminium) pour agglomérer les particules en suspension qui forment des amas plus lourds (les "flocs").
· Décantation : Les flocs coulent au fond du bassin par gravité et sont évacués sous forme de boues.
· Filtration : L'eau passe à travers des lits de sable et de charbon actif pour éliminer les dernières impuretés et réduire la turbidité.

Abb. in Leseprobe nicht enthalten

Figure 1. Image de l’ouvrage de captage et de traitement d’eau

1.1.3. Réseau d’adduction

Ce sont les "artères" du système. Les conduites d'adduction transportent de gros volumes d'eau sur de longues distances, de la station de traitement vers les réservoirs de stockage urbains. Elles ne comportent généralement pas de branchements pour les abonnés. [5]

Abb. in Leseprobe nicht enthalten

Figure 2. Image montrant le transport de l’eau par de tuyaux

1.1.4. Les Ouvrages de Stockage et de Mise en Pression

Le stockage (châteaux d'eau, réservoirs au sol) joue un rôle tampon : il accumule l'eau durant la nuit pour satisfaire la forte demande du matin. Mais aussi de couvrir la demande en cas d’absence longue de fourniture.

· Gravitaire : Le réservoir est en hauteur et la pression est assurée par la gravité.
· Par Pompage : Des stations de surpression (boosters) sont utilisées pour maintenir la force de l'eau dans les zones à topographie complexe. [5]

Abb. in Leseprobe nicht enthalten

Figure 3. Ouvrage de stockage et de mise en pression

1.1.5. Le Réseau de Distribution

C'est la partie terminale qui parcourt chaque rue. On distingue deux types de topologies :

· Le Réseau Maillé : Les conduites forment des boucles fermées. Si une conduite casse, l'eau peut arriver par un autre chemin. C'est le standard en milieu urbain dense car il offre une meilleure sécurité de service.
· Le Réseau Ramifié : En forme d'arbre, il est moins coûteux mais une coupure à la "racine" prive tout le quartier d'eau.

Il est utile de signale que le réseau de distribution maillée est bien adapté pour de zones urbaines il est difficile à maintenir en cas de panne mais aussi une grande longueur de canalisation ce qui le rend cher à l’installation mais aussi sa complexité rend son dimensionnement trop difficile par rapport au réseau maillé qui est simple à mettre en œuvre et plus économique mais moins adapter aux zones urbaines. [6]

Abb. in Leseprobe nicht enthalten

Figure 4. Réseau de distribution maillée et réseau de distribution ramifié

1.2. Les problématiques de gestion d’un système de distribution de l’eau

1.2.1. Les Pertes en Ligne (Le Rendement du Réseau)

C'est le défi numéro un des gestionnaires. On distingue deux types de pertes :

· Les fuites réelles (Physiques) : Ruptures de canalisations dues à la vétusté, à la pression excessive ou aux mouvements de terrain. En milieu urbain, une fuite peut rester invisible longtemps si l'eau s'écoule directement dans les égouts.
· Les pertes apparentes (commerciales) : Erreurs de comptage des compteurs usagés ou branchements illicites (vols d'eau). [7]

1.2.2. La Gestion de la Pression

La pression est une arme à double tranchant :

· Sous-pression : entraîne l'inconfort des usagers (surtout dans les immeubles hauts) et des risques de contamination par intrusion d'eau extérieure dans les conduites.
· Surpression : cause principale de la fatigue des matériaux et de l'explosion des canalisations. [7]

1.2.3. La Dégradation de la Qualité de l'Eau

L'eau peut se dégrader durant son transport dans le maillage urbain :

· Temps de séjour trop long : Dans les zones "mortes" du réseau (bras morts), l'eau stagne, le chlore s'évapore et des bactéries peuvent se développer.
· Corrosion et sédimentation : Les vieilles conduites en fonte ou en acier peuvent libérer des particules ou modifier le goût de l'eau. [7]

1.2.4. La Complexité du Maillage Urbain

La ville est un environnement saturé où le réseau d'eau coexiste avec le réseau de gaz, l'électricité et les télécoms.

· Difficulté d'accès : Intervenir sur une conduite située sous une avenue principale nécessite des travaux coûteux et bloque le trafic.
· Interdépendance : Une rupture de canalisation peut inonder des infrastructures électriques ou de transport (métro).

1.3. Microcontrôleur Arduino et nodemcu

1.3.1. Arduino [11]

Abb. in Leseprobe nicht enthalten

Figure 5. Carte Arduino Uno

1.3.2. Architecture Matérielle (Hardware)

Un Arduino est essentiellement une carte articulée autour d'un microcontrôleur (souvent de la famille Atmel AVR ou ARM). Contrairement à un ordinateur (comme le Raspberry Pi), il ne possède pas de système d'exploitation ; il exécute une seule tâche en boucle, ce qui le rend extrêmement stable pour le contrôle industriel.

Composants principaux :

· Le microcontrôleur : l'unité de calcul (ex. ATmega328P sur l'Uno).
· Les Entrées/Sorties Numériques (Digital I/O) : Pour les signaux "tout ou rien" (ex: activer une alerte).
· Les Entrées Analogiques (Analog In) : Indispensables pour vos sondes de pH, de pression et de turbidité, car elles convertissent une tension variable en valeur numérique via un ADC (Convertisseur Analogique-Numérique).
· Interfaces de Communication : UART (Série), I2C et SPI, nécessaires pour connecter vos modules IoT (LoRa, GPS, Écrans).

Abb. in Leseprobe nicht enthalten

Figure 6. Architecture d’une carte Arduino

1.3.3. Caractéristiques Techniques (Modèle Type : Uno R3/V4)

On peut voir les caractéristiques techniques dans le tableau suivant :

Tableau 1. Caracteristiques Arduino Nano

Abb. in Leseprobe nicht enthalten

1.3.4. L'Environnement de Programmation (Software) développement intégré

Le logiciel Arduino IDE utilise un langage dérivé du C/C++. La structure d'un programme (appelé sketch) est toujours divisée en deux parties :

Ø void setup() : Exécuté une seule fois au démarrage (initialisation des capteurs).
Ø void loop() : S'exécute à l'infini (lecture des données de pression/débit et envoi via IoT).

1.3.5. Nodemcu (ESP8266) [12]

Abb. in Leseprobe nicht enthalten

Figure 7. La carte NodeMCU 8266

Développé par la société chinoise Espressif Systems, l’ESP8266 est un SoC (System on a Chip) qui intègre un microcontrôleur et une pile protocolaire Wi-Fi complète (TCP/IP).

Il est le plus souvent utilisé sous la forme de modules prêts à l'emploi, les plus célèbres étant le NodeMCU ou le Wemos D1 Mini, qui ajoutent un port USB pour la programmation et des régulateurs de tension.

1.3.5.1. Architecture et Puissance de Calcul

Le NodeMCU n'est pas un simple contrôleur comme l'Arduino ; c'est un véritable ordinateur miniature :

· Microcontrôleur : Tensilica L106 32-bit (RISC).
· Fréquence d'horloge : 80 MHz (ajustable jusqu'à 160 MHz pour des calculs plus lourds).
· Mémoire Flash : Généralement 4 Mo (utilisée pour stocker ton code, les fichiers système et éventuellement des pages Web de monitoring).
· Mémoire RAM : 64 Ko pour les instructions et 96 Ko pour les données.

Interfaces d'Entrées/Sorties (I/O)

· Broches Numériques (GPIO): 13 broches.
· Entrée Analogique (ADC) : 1 seule broche (A0), acceptant une tension de 0V à 3.3V.
· Bus de communication : UART : Pour la programmation ou connecter un module GPS.
· SPI : Essentiel pour connecter un module radio LoRa (RFM95).
· I2C : Idéal pour des capteurs de pression ou de température numériques.

1.3.5.2. Connectivité Sans Fil (Wi-Fi)

C'est sa force principale pour un projet IoT :

· Protocoles: 802.11 b/g/n.
· Modes de fonctionnement : Station (STA) : se connecte à une box Wi-Fi existante.
· Access Point (AP) : crée son propre réseau Wi-Fi (très utile pour la maintenance sur le terrain).
· Dual (STA + AP) : Fait les deux en même temps.
· Sécurité: Supporte WPA/WPA2.
· Pile TCP/IP intégrée : gère nativement les requêtes HTTP, MQTT (très utilisé pour l'eau), et les WebSockets.

1.3.5.3. Alimentation et Consommation

C'est un point critique pour un système autonome enterré sous une chaussée :

· Tension d'entrée : via USB (5 V).
· Via broche VIN (7 V à 12 V grâce au régulateur intégré).
· Tension logique : 3,3 V (Ne pas brancher de capteurs de 5 V sans adaptation).
· Courant consommé : en émission Wi-Fi : ~170 mA (pointe à 200 mA).

Deep Sleep : ~20 µA. C'est ce mode qu’on doit utiliser dans ce projet TFC pour que le capteur survive plusieurs mois sur batterie.

CONCLUSION

En somme, l'étude théorique menée dans ce chapitre met en exergue l'interdépendance croissante entre la gestion des ressources hydrauliques urbaines et les technologies de l'information. L'analyse des réseaux de distribution d'eau potable (RDEP) a révélé des vulnérabilités critiques, notamment en termes de pertes physiques et de difficultés de monitoring en temps réel dans des environnements urbains denses. L'émergence de l'Internet des objets (IoT), avec différents

capteurs présentés dans le chapitre, surtout avec l’intégration de microcontrôleurs performants et économiques, tels que la carte ARDUINO et l’ESP8266 (NodeMCU), offre une flexibilité sans précédent pour concevoir des nœuds de capteurs capables de collecter des données de pression et de débit avec une précision accrue. Cette architecture "Smart Water" ne se limite pas à une simple télérelève ; elle pose les jalons d'une gestion prédictive permettant de réduire drastiquement le gaspillage d'eau et d'optimiser le rendement hydraulique des villes.

Ainsi, les bases théoriques étant posées, le chapitre suivant s'attachera à la description de la méthodologie de conception du système, au choix des composants matériels, à l’élaboration du schéma électronique et à la conception du logiciel nécessaire pour la mise en œuvre de notre système de surveillance de l’eau.

CHAPITRE 2 : ANALYSE CONCEPTUELLE DU SYSTEME

2.1. Introduction

Dans cette partie du travail, nous allons faire l’analyse et la conception du système de distribution d’eau connecté. En gros, le système est principalement constitué de deux parties : la partie électronique et la partie informatique. Dans ce chapitre, nous commencerons par la présentation de la partie électronique.

2.2. Analyse et conception électronique

Le système faisant l’objet de notre étude détecte diverses fuites dans le réseau de distribution, puis envoie ces données à la carte Arduino. La carte Arduino, à son tour, analyse puis envoie les données au NodeMCU, qui les envoie à son tour à la base de données MYSQL pour être affichées par l’application. En ce qui concerne la commande de la pompe : cette dernière est automatique ou manuelle selon le choix de l’utilisateur.

Dans cette partie du travail, nous allons faire l’analyse et la conception du système. Dans cette partie du travail, nous allons élaborer les divers schémas de conception de notre système. Nous allons faire le dimensionnement et le choix de composants, sans oublier la simulation sous proteus/isis. L’électronique de notre système se résume au schéma bloc suivant : Ce schéma bloc présente l'architecture matérielle du système de gestion, de contrôle et de surveillance de l'eau.

Abb. in Leseprobe nicht enthalten

Figure 8. Schéma bloc de notre système

· L'Unité de Traitement Principale
o ATMEGA 328p: c'est le microcontrôleur central (le "cerveau" local). Il est chargé de collecter en temps réel les signaux analogiques ou numériques provenant des différents capteurs, de traiter ces données, de piloter l'affichage local et d'envoyer des commandes

aux actionneurs (la pompe). Il communique également de manière bidirectionnelle avec le module Wi-Fi (ESP 8266).

· Le Bloc d'Acquisition (Les Capteurs / Entrées) : s es composants mesurent les paramètres physiques de l'eau et transmettent les informations à l'Arduino :
o Capteur de pH de l'eau : mesure l'acidité ou l'alcalinité de l'eau. C'est un indicateur crucial pour la qualité de l'eau.
o Capteur de fuite de l'eau: détecte la présence anormale d'eau à un endroit stratégique afin de prévenir les inondations ou le gaspillage.
o Capteur de débit de l'eau: mesure le volume d'eau qui s'écoule par unité de temps (généralement via un rotor à effet Hall), permettant de suivre la consommation ou de détecter des anomalies de flux.

· Le Bloc d'Actionnement et de Puissance
o Interface de puissance: l’Arduino fonctionne à de faibles tensions et courants (souvent 5V, quelques milliampères), insuffisants pour alimenter un moteur. Cette interface (composée de relais, de transistors MOSFET) utilise le signal de commande de l'Arduino pour commuter une source d'énergie plus puissante.
o Pompe: l'actionneur principal du système. Elle est activée ou désactivée via l'interface de puissance, par exemple pour réguler le niveau d'eau, corriger le pH ou couper l'alimentation en eau en cas de fuite.

· Le Bloc d'Interface Homme-Machine (IHM)
o Écran LCD : connecté directement à l'Arduino, il permet un affichage direct sur le site des données (valeur du pH, débit actuel, alertes). Cela permet à un opérateur de surveiller le système sans avoir besoin de connexion internet.

· Le Bloc Connectivité IoT et Alertes à Distance
o NODEMCU (ESP 8266) : ce module électronique intègre un microcontrôleur avec une connectivité Wi-Fi native. Il échange des données avec l'arduino (liaison série de type UART, I2C ou SPI). Son rôle est d'envoyer les données collectées vers le cloud ou des applications, et de recevoir d'éventuelles commandes à distance. [12]
o Signalisation (LED & Buzzer) : Piloté directement par le NodeMCU (ou suite à un ordre réseau), ce bloc assure une alerte visuelle (LED) et sonore (Buzzer) locale immédiate en cas de dysfonctionnement critique ou d'anomalie détectée.

· Le Bloc Supervision et Cloud (IHM Distante)
o Smartphone (via Wi-Fi): représente l'interface utilisateur finale (Dashboard/Application IoT). Grâce au Wi-Fi du NodeMCU, l'utilisateur peut surveiller l'état du système à distance, recevoir des notifications d'alerte (fuite, pH anormal) et télécommander la pompe depuis un smartphone Android ou un ordinateur.

2.3. Choix et Spécifications des Unités de Traitement et de Communication

Le système repose sur une architecture à double cœur décentralisée, séparant les tâches de contrôle en temps réel des tâches de connectivité réseau.

2.3.1. Le Microcontrôleur Principal : ATmega328P (Format DIP-28)

L'ATmega328P est un microcontrôleur RISC 8 bits de Micro chip à très faible consommation. Il est choisi pour sa robustesse industrielle, sa tolérance aux variations de température et sa gestion native des interruptions matérielles (cruciales pour le capteur de débit). Son fonctionnement sous 5 V s'aligne parfaitement avec la tension nominale des capteurs industriels sélectionnés, éliminant le besoin de circuits de mise à niveau de tension (level shifters).

2.3.2. Le Module de Communication : NodeMCU ESP8266 (Version ESP-12E)

Contrairement à l'ATmega328P, le NodeMCU intègre nativement une pile de protocoles TCP/IP et un module Wi-Fi 2.4GHz. Son utilisation permet de décharger le microcontrôleur principal des fonctions réseaux lourdes (requêtes HTTP, gestion du Wi-Fi). Il agit exclusivement comme une passerelle Cloud (Gateway) vers la base de données MySQL.

2.4. Étude et dimensionnement théorique

Avant la réalisation, la conception d'un système électronique embarqué dédié à la gestion d'actifs hydriques requiert une approche rigoureuse articulée en deux étapes fondamentales : le dimensionnement théorique et la validation par simulation. L'objectif de cette partie est d'asseoir les bases physiques, électriques et algorithmiques d'une architecture articulée autour du microcontrôleur ATmega328P, d'un module de communication sans fil NodeMCU, d'un affichage LCD, de trois capteurs d'état (niveau, débit, pH) et de trois unités de pompage de puissance. Le dimensionnement théorique permet de traduire les exigences fonctionnelles en grandeurs physiques mesurables et quantifiables (courant, résistance, puissance, capacités de filtrage). La simulation, réalisée dans l'environnement Proteus, permet quant à elle de valider l'interopérabilité des composants matériels et de vérifier le comportement dynamique du firmware avant toute implémentation sur circuit imprimé (PCB) physique.

2.4.1. Bloc d'Alimentation et de Régulation (7805)

L'alimentation générale du système doit fournir une tension stable VCC = 5.0 V pour le microcontrôleur ATmega328P, l'afficheur LCD et les différents capteurs analogiques. La tension d'entrée nominale en amont du régulateur linéaire LM7805 est fixée à Vin = 9.0 V, fournie par un connecteur de puissance J1.

La puissance maximale dissipée par le régulateur U2 s'exprime par la relation fondamentale :

Abb. in Leseprobe nicht enthalten

Où I total représente la somme des courants consommés en régime nominal permanent par l'ensemble des sous-systèmes : Itotal = Iatmega + Ilcd + Icapteurs + Inodemcu

D'après les fiches techniques des constructeurs, les consommations maximales sous 5V s'établissent comme suit :

ATmega328P (à 16 MHz) : Iatmega ≈ 20 Ma

Écran LCD LM016L (avec rétroéclairage) : ILCD ≈ 120 mA Capteurs (pH, Débit, 3x Niveau) : Icapteurs ≈ 50 mA

NodeMCU (pics de transmission Wi-Fi régulés en interne) : Inodemcu ≈ 200 mA

Le courant total estimé est donc de I total = 390 mA. En appliquant la formule de dissipation thermique :

𝑃𝑑𝑖𝑠𝑠 = (9.0 − 5.0) × 0.390 = 1.56 𝑊

Le boîtier TO-220 du 7805 possédant une résistance thermique jonction-ambiance Rthja = 65

°C/W, l'élévation de température sans dissipateur serait de 𝛥𝑇 = 1.56 × 65 = 101.4 °𝐶. Pour maintenir la température de jonction en dessous de la limite de sécurité (125 °C) pour une température ambiante de 30 °C, l'adjonction d'un dissipateur thermique avec une résistance Rthf ≤ 15 °C/W est théoriquement requise.

2.4.2. Dimensionnement de la Commande des Pompes (Transistors NPN)

Abb. in Leseprobe nicht enthalten

Figure 9. Circuit de commande de la Pompe

Le schéma intègre trois unités de pompage indépendantes, modélisées par des charges inductives de courant nominal 𝐼𝑝𝑜𝑚𝑝𝑒= 500 mA sous 𝑉𝑐𝑐 = 5 V. Les sorties numériques de l'ATmega328P (P1, P2, P3) ne pouvant délivrer au maximum que 40 mA, l'utilisation d'un transistor de commutation de type NPN 2N2222A est impérative.

Critère de saturation du transistor : Pour assurer le fonctionnement du transistor en régime de commutation (bloqué/saturé), le courant de base IB doit respecter la condition de sursaturation :

Abb. in Leseprobe nicht enthalten

Où ksat est le coefficient de sursaturation (généralement choisi égal à 2 ou 3), 𝐼𝑐= Ipompe, et βmin est le gain en courant minimal du transistor en mode saturé (βmin ≈ 50 pour le 2N2222A à fort courant). En fixant 𝒌𝒔𝒂𝒕 = 2.5, le courant de base requis est calculé comme suit :

Abb. in Leseprobe nicht enthalten

Ce courant de base de 25 mA est parfaitement compatible avec la limite maximale de la broche E/S du microcontrôleur (40 mA). La valeur de la résistance de base (R3, R4, R5) se calcule par la loi des mailles appliquée à l'entrée du transistor :

Abb. in Leseprobe nicht enthalten

Avec VOH = 4.2 V (tension de sortie haute minimale garantie de l'ATmega328P alimenté en 5V) et 𝑉𝑏𝑒𝑠𝑎𝑡= 1.2

V (tension base-émetteur à saturation du 2N2222A à fort courant), la valeur de la résistance théorique est :

Abb. in Leseprobe nicht enthalten

Circuit d'Horloge Externe (Quartz et Résonance)

Le cadencement de l'ATmega328P est opéré par un quartz piézoélectrique externe X1 de fréquence nominale f =16.0 MHz. Pour garantir l'oscillation stable du circuit oscillateur de Pierce interne, deux condensateurs de charge C1 et C2 de valeur égale sont requis. La capacité de charge CL spécifiée par le fabricant du quartz répond à l'équation :

Abb. in Leseprobe nicht enthalten

En posant C1= C2= C et en estimant la capacité parasite des pistes du circuit imprimé Cstray ≈ 5 pF, la formule se simplifie : CL= C/2 + 5. Pour une valeur standard de CL= 16 pF, on obtient C = 2 × (16 − 5) = 22 pF. Cette valeur théorique correspond exactement aux composants C1= 22 pF et C2= 22 pF câblés sur le schéma, assurant une dérive temporelle minimale du système.

2.5. Étage d'Interface de Puissance et Commande des Pompes

2.5.1. Transistor de Commutation : NPN 2N2222A (Boîtier TO-92)

Pour le 2n2222 sont choix est dictée par la puissance de la pompe du prototype

Le 2N2222A est un transistor bipolaire de commutation rapide capable de supporter un courant de collecteur continu jusqu'à Ic = 800 mA, ce qui couvre largement les 500 mA requis par la pompe.

Abb. in Leseprobe nicht enthalten

Figure 10. Transistor NPN 2N2222A

2.5.2. Diode de Roue Libre : 1N4007 (Boîtier DO-41)

Lors de l'ouverture du circuit (extinction de la pompe), l'inductance du moteur génère une forte surtension inverse susceptible de claquer le transistor. La diode 1N4007 (supportant 1 A et jusqu'à 1000 V est placée en antiparallèle sur la charge pour absorber et dissiper cette énergie.

Abb. in Leseprobe nicht enthalten

Figure 11. Diode de Roue libre

2.5.3. Bloc d'Affichage Local : Écran LCD 16x2 (Pilote HD44780)

L'écran LCD 1602 (16 caractères sur 2 lignes) équipé du contrôleur standard Hitachi HD44780 permet un affichage alphanumérique clair des données de terrain (pH, débit) directement sur site. Cela garantit le maintien de la surveillance humaine locale même en cas de coupure de la liaison Internet vers le centre de contrôle distant.

Abb. in Leseprobe nicht enthalten

Figure 12. Ecran LCD (Pilote HD44780)

2.5.4. Circuit d'Horloge Externe (Quartz et Résonance)

2.5.4.1. Quartz Piézoélectrique 16.0 MHz (Format HC-49S)

Bien que l'ATmega328P possède un oscillateur RC interne de 8 MHz, l'utilisation d'un quartz externe à 16 MHz offre une précision temporelle indispensable pour le calcul exact de la fréquence d'impulsion du capteur de débit d'eau et pour stabiliser le débit de la liaison série ( Baudrate UART à 9600 bps).

Abb. in Leseprobe nicht enthalten

Figure 13. Quart piézoélectrique 16.0MHz

2.5.5. Capteur de pH (Référence : Kit analogique DFRobot SEN0161)

Le SEN0161 délivre une tension analogique proportionnelle à l'activité des ions hydrogène (0 - 5V, ce qui permet un raccordement direct sur le convertisseur analogique-numérique (broche A0) de l'ATmega328P sans nécessiter de conditionneur de signal externe complexe.

Abb. in Leseprobe nicht enthalten

Figure 14. Capteur de pH

2.5.6. Capteur de Débit (Référence : YF-S201)

Basé sur un capteur à effet Hall, le YF-S201 génère un signal carré dont la fréquence est proportionnelle à la vitesse d'écoulement du fluide (F = 7,5 * Q, où Q est le débit en L/min). Il est

Connecté à une broche d'interruption externe (INT0) de l'ATmega328P, garantissant un comptage précis des impulsions sans surcharger l'algorithme principal.

Abb. in Leseprobe nicht enthalten

Figure 15. Capteur de Débit

2.5.7. Capteur de Niveau / Fuite (Référence : Capteur de niveau d'eau capacitif / résistif standard)

Ce module convertit la surface de contact avec le fluide en une variation de résistance, traduite en tension lue sur l'entrée analogique. Son coût extrêmement bas et sa faible consommation en font le candidat idéal pour la détection instantanée de débordement ou de fuite sur site.

Abb. in Leseprobe nicht enthalten

Figure 16. Capteur de Niveau

2.6. Interfaçage

2.6.1. Rôle du centre de contrôle

Le centre de contrôle fait office de passerelle intelligente et d' interface homme-machine (IHM). Son rôle se decline en trois axes principaux :

· Centralisation et Persistance : Il rassemble les données physiques provenant du terrain (les capteurs connectés à l'Arduino et transmis par le NodeMCU) pour les structurer et les stocker de façon permanente dans la base de données MySQL. Cela permet de conserver un historique complet pour des analyses ultérieures.
· Supervision en Temps Réel : Il traduit des signaux électriques et numériques bruts en informations visuelles compréhensibles pour l'utilisateur (graphiques, indicateurs colorés, alertes textuelles) sur les écrans d'un PC ou d'un smartphone Android.
· Télécommande et Sécurité : Il permet à l'opérateur d'agir à distance sur le système en modifiant l'état de la pompe, tout en intégrant des règles de sécurité logiques (comme le verrouillage en cas de fuite) pour protéger les équipements.

2.6.2. Nature des informations reçues et traitées

Les informations qui transitent vers le centre de contrôle et qui sont enregistrées en base de données sont de deux ordres : les données de télémesure (capteurs) et les données d'état (actionneur/sécurité).

A. Les données de télémesure (Entrées du système)

Ce sont les informations collectées sur le réseau hydraulique :

1. Le potentiel Hydrogène (pH) : Type de donnée : Numérique décimale (Flottant, ex: 7.2). Indiquer la qualité chimique et la potabilité de l'eau en temps réel.

2. Le débit de l'eau : Type de donnée: Numérique (Entier ou décimal, exprimé en Litres/minute). Quantifier le volume d'eau qui circule dans la conduite pour évaluer la consommation ou détecter des anomalies de pression.

3. L'état de fuite d'eau : Type de donnée : Booléenne (0 ou 1 / VRAI ou FAUX).

Signaler instantanément la présence anormale d'eau à l'extérieur des conduites (rupture ou fissure de tuyau).

B. Les données d'état et de commande (Sorties et Supervision)

Ce sont les informations qui permettent de suivre et de modifier le comportement de l'installation :

1. L'état réel de la pompe :
· Type de données: booléenne (0 pour Arrêtée, 1 pour En marche).

Confirmer visuellement à l'utilisateur si la pompe est en train de tourner ou si elle est coupée.

2. L'index des commandes (Ordre utilisateur) :
· Type de données: caractère ou booléen issu de l'interface graphique.

Enregistrer l'action de l'utilisateur lorsqu'il clique sur "Allumer" ou "Éteindre" depuis son tableau de bord, ordre qui sera ensuite récupéré par le NodeMCU pour commuter le relais de puissance.

2.6.3. Centre de Contrôle

L’infrastructure informatique du centre de contrôle a été réalisée à l’aide des technologies et outils suivants :

Ø Base de données MySQL: Elle est utilisée pour structurer, centraliser et stocker toutes les données du système (comme les zones de fuite, l’état d’alerte, et l’état de la pompe)
Ø Scripts d’API en PHP : ils assurent l’interfaçage logiciel et l’échange fluide et sécurisé des données en traitant les requêtes de communication (notamment les requêtes HTTP de type POST transmises par le module WI-FI NodeMCU) entre le terrain et le serveur de la base de données.
Ø Interface dynamique et Dashboard en JavaScript: une interface web dynamique a été développée pour permettre aux gestionnaires et ingénieur de la REGIDESO de visualiser les informations en temps réel sous forme de tableau de bord décisionnel (Dashboard) et de consulter les historiques

2.7. Protocole de Communication

Pour matérialiser l'échange d'informations entre la couche matérielle de terrain et le centre de contrôle, le système exploite une architecture API REST (Application Programming Interface) s'appuyant sur le protocole de communication HTTP (Hypertext Transfer Protocol) sur un réseau local (IP/TCP).

Ce protocole fonctionne selon un modèle classique Client-Serveur:

· Le NodeMCU (client HTTP) : Il encapsule les données physiques brutes des capteurs dans une requête de type POST ou GET.
· Le serveur Web (serveur API PHP) : Il écoute les requêtes du réseau local, traite les paramètres reçus à travers des scripts PHP spécifiques (ex. insert_data.php), puis orchestre les requêtes SQL vers le serveur de base de données.

Grâce à une API et un réseau local, la partie électronique envoie les informations à la base de données MYSQL. Notre base de données est principalement constituée de deux tables : la table de données et la table de login, comme on peut le voir sur le croquis ci-dessous :

Abb. in Leseprobe nicht enthalten

Figure 17. Les parties de la base des données

CONCLUSION

En somme, ce deuxième chapitre a permis de valider l’intégralité de la conception théorique matérielle et logicielle du système de gestion hydrique. En traduisant les exigences fonctionnelles en grandeurs physiques et numériques mesurables, nous avons posé des bases scientifiques solides pour la viabilité du projet. Sur le plan matériel, le choix minutieux et le dimensionnement électrique des composants, garantissent une infrastructure robuste à l’abri des surcharges thermiques ou électriques. Sur le plan informatique, la structuration de la base de données MYSQL, associée au protocole de communication HTTP via une API, assure un échange de données fluide et sécurisé entre le terrain et le centre de contrôle local. Les bases étant solides nous pouvons à présent passer à l’évaluation dynamique du système

CHAPITRE 3 : REALISATION ET PRESENTATION DES RESULTATS

3.1. Introduction

La concrétisation matérielle et logicielle d'un système embarqué de gestion hydrique exige une convergence rigoureuse entre le génie électronique microcontrôleur, les technologies de communication sans fil de l'Internet des Objets (IoT) et le développement d'architectures logicielles distribuées. Ce chapitre expose de manière exhaustive et structurée l'ensemble des étapes de réalisation pratique du prototype connecté basé sur le schéma d'interconnexion modélisé dans l'environnement Proteus ISIS.

Ce système a été spécifiquement conçu pour répondre aux problématiques endémiques de pertes d'eau par fuites et de dégradation de la qualité de la ressource au sein du réseau de distribution de la ville de Goma. L'architecture globale s'appuie sur une topologie maître-esclave à double processeur : un microcontrôleur principal robuste ATmega328P chargé de l'acquisition en temps réel des signaux analogiques et impulsionnels, du contrôle de puissance local et de l'affichage, couplé à un module de communication de haut niveau NodeMCU ESP8266 dédié à la sérialisation, au chiffrement et au transfert des données vers une infrastructure cloud web.

À travers les sections suivantes, nous analyserons les blocs fonctionnels du circuit électrique, détaillerons les interconnexions physiques, déploierons les micrologiciels (firmware) optimisés pour chaque puce, et présenterons l'architecture de la plateforme web de supervision (base de données relationnelle MySQL, scripts d'API PHP et interface dynamique JavaScript).

3.2. Schéma électronique fonctionnel

Abb. in Leseprobe nicht enthalten

Figure 18. Schéma de réalisation

3.3. Principe de fonctionnement du schéma électronique

Le système tourne autour d'un microcontrôleur principal (ATmega328P) qui centralise les données de capteurs et commande des actionneurs, tout en communiquant avec un module NodeMCU pour la connectivité sans fil (IoT). Le régulateur 7805 fournit une tension continue de 5 V aux divers capteurs de notre système.

Une fois que le système est alimenté, le microcontrôleur ATMEGA328P lit les informations fournies par les capteurs ; le système est principalement constitué de trois capteurs, entre autres les capteurs de fuite, le capteur de débit et le capteur de pH. Dans le réseau hydraulique, en cas de fuite d’eau, le capteur de fuite fournit au microcontrôleur ATMEGA328P une information selon

Laquelle il y a une fuite. Pour éviter les pertes d’eau et de protéger l’installation, le système agit automatiquement sur une électrovanne de commande afin de réduire ou d’isoler le passage de l’eau dans la zone concernée, En fonction de la gravité de l’anomalie détectée, le système peut également commander une variation de la vitesse de la pompe afin d’adapter le débit fourni au réseau, et envoie ces informations au NodeMCU, ce dernier les envoyant à son tour à la base de données pour être consultées par les utilisateurs humains. Le capteur de débit fourni au microcontrôleur le débit en eau de notre réseau en générale. Le capteur de pH permet au microcontrôleur de mesurer le taux de pH dans l’eau. Toutes ces informations sont affichées sur un écran LCD et sont envoyées au NodeMCU, qui les envoie à notre base de données.

À chaque fuite, le système reconnaît en temps réel la zone de fuite et envoie ces informations à l’application. À chaque instant, le système mesure le débit de l’eau et la quantité d’eau utilisée et les envoie à l’application. Si le pH de l’eau n’est pas bon, le système désactive la pompe.

Le schéma de conception du prototype s'organise autour de grands blocs fonctionnels interconnectés visibles sur la Figure 8 Chaque bloc remplit un rôle crucial pour assurer l'autonomie, la précision des mesures et la sécurité opérationnelle du système. Afin de garantir l'immunité aux bruits électromagnétiques et d'assurer une tension stable aux composants numériques et analogiques, une régulation de tension à deux niveaux est implémentée : le régulateur U2 (LM7805) reçoit une tension continue brute (généralement comprise entre 9 V et 12 V issue du connecteur J1 connecté à une source externe) et fournit à sa sortie une tension régulée de Vcc = +5,0 V stable, avec une capacité de courant maximale de 1 A.

• Réseau de filtrage capacitif : Les condensateurs C4 (22 µF en entrée) et C3 (100 µF en sortie) agissent comme des filtres passe-bas pour lisser les ondulations résiduelles et absorber les appels de courant transitoires générés par le démarrage des actionneurs.
• Témoins Lumineux de Statut : La LED rouge D1 montée en série avec la résistance de limitation R1 (100 Ω) indique la présence de la tension d'entrée brute. La LED verte D2 montée avec la résistance R2 (100 Ω) valide la stabilité de la ligne de distribution Vcc de +5V.

Le coeur de calcul local est constitué de la puce RISC 8 bits ATmega328P (U1). Fonctionnant à une fréquence d'horloge externe de 16 MHz matérialisée par le quartz de résonance X1 et ses deux condensateurs de charge C1 = 22pF et C2 = 22pF, il orchestre l'acquisition des données et l'exécution locale des boucles d'asservissement. Ses ports sont affectés comme suit :

• Ports Analogiques (PC0 à PC4) : Dédiés à l'échantillonnage des capteurs. PC0 (A0), PC1 (A1), et PC2 (A2) reçoivent les signaux des trois modules capteurs de fuite d'eau (Water Sensors). PC3 (A3) est affecté au capteur de débit volumétrique, tandis que PC4 (A4) recueille la tension analogique proportionnelle au pH de l'eau.
• Ports de Commande Numérique (PD3, PD4, PD5) : Configurés en sorties numériques nommées P1, P2, P3 pour piloter l'étage de commutation des motopompes de distribution.
• Interfaces d'Affichage (PB0 à PB5) : pilotent l'afficheur LCD en mode 4 bits, minimisant ainsi l'utilisation des broches du microcontrôleur.

Les motopompes DC constituant les charges inductives du réseau de distribution ne peuvent pas être directement alimentées par les broches E/S de l'ATmega328P (limitées à 40 mA). Un étage d'interface de puissance à transistors bipolaires a été conçu :

Les sorties numériques P1, P2, et P3 pilotent respectivement les bases des transistors NPN 2N2222A (Q3, Q1, et Q2) à travers des résistances de saturation de R3 = R4 = R5 = 1 kΩ. Lorsque la sortie passe à l'état haut (+5V), le transistor entre en régime de saturation (Vce_sat ≈ 0.2V), agissant comme un interrupteur fermé vers la masse, ce qui permet le passage du courant nominal pour l'activation de la pompe correspondante.

L'affichage en temps réel est assuré par l'écran LCD LM016L (2 lignes x 16 caractères). Le potentiomètre RV1 (1 kΩ) permet de régler manuellement le contraste de l'écran. L'écran affiche dynamiquement le débit calculé en décimètres cubes (dm³) ainsi que le statut "DISTRIBUTION EAU" ou l'alerte de fuite détectée.

Pour la connectivité Internet, la communication se fait via la liaison série asynchrone (UART). Les broches PD0/

RXD et PD1/TXD de l'ATmega328P sont reliées de manière croisée aux broches correspondantes du module NodeMCU ESP8266. Ce dernier reçoit les trames de données formatées, traite les requêtes HTTP de type POST, et les achemine vers la passerelle Wi-Fi locale pour alimenter l'application web distante.

La logique métier du système repose sur une répartition hiérarchique des tâches. Le diagramme de flux logique se décline en deux processus parallèles exécutés sur les deux processeurs distincts.

Pour le capteur de débit basé sur l'effet Hall, la relation entre la fréquence des impulsions générées

F (Hz) et le débit réel de fluide Q (L/min) est régie par la formule empirique suivante :

Abb. in Leseprobe nicht enthalten

Où K est la constante caractéristique du capteur (ex: 4.5 pour un modèle standard YF-S201). Le volumecumulé V(dm ³) est déterminé par intégration temporelle discrète :

Abb. in Leseprobe nicht enthalten

Pour la conversion de la valeur brute du pH, la tension analogique lue V (0 à 5V) subit une transformation pH Linéaire pour correspondre à l'échelle standard [0 - 14] :

Abb. in Leseprobe nicht enthalten

Cette section fournit l'intégralité du code source structuré et commenté. Le premier script est destiné à l'ATmega328P, responsable de l'automatisme local ; le second script est destiné au NodeMCU, responsable de la couche réseau.

3.4. Algorithme de fonctionnement du système

Abb. in Leseprobe nicht enthalten

Figure 19. Algorithme de fonctionnement

3.5. Simulation

Dans cette partie du travail, nous allons faire la simulation de notre système sous PROTEUS/ISIS. Nous allons simuler en fonction des valeurs des composants dimensionnés.

Abb. in Leseprobe nicht enthalten

Figure 20. Simulation du système en cours de fonctionnement normal

Cette figure montre le comportement global du circuit lorsque tous les paramètres du réseau de distribution d’eau sont stables et conformes aux attentes. Aucun incident (comme une baisse critique de pression ou une anomalie) n’est détecté par les capteurs.

Comme résultat, l’écran LCD affiche distinctement le message de routine : CONTROLE...DISTRIBUTION EAU. Cela confirme que le programme s’exécute correctement en arrière-plan, que l’alimentation est stable et que le système supervise le réseau de manière nominale sans activer d’alerte.

Abb. in Leseprobe nicht enthalten

Figure 21. Simulation de notre système lors de la détection d’une fuite

Dans ce cas de figure, l’un des capteurs (ou une différence de logique entre les capteurs de niveau/débit) signale une anomalie majeure dans le réseau, correspondant à une perte d’eau.

En conséquence, le système réagit instantanément à l’anomalie. L’écran LCD change d’état pour afficher un message visuel crucial : ALERTE DÉTECTION DE FUITE . Ce résultat montre le basculement du système en mode de sécurité, permettant l’envoi immédiat de l’information (via le NodeMCU) pour notifier l’utilisateur ou couper automatiquement une vanne/pompe afin de limiter les pertes.

Abb. in Leseprobe nicht enthalten

Figure 22. Simulation du système en cours de mesure de débit

Cette figure met en avant la fonction de lecture quantitative du système. Le capteur de débit est sollicité par un flux simule pour vérifier la précision des calculs volumétriques et du traitement des impulsions par le microcontrôleur.

Comme résultat l’écran LCD remonte en temps réel la valeur mesurée sur le réseau, cela valide la bonne communication entre le capteur de débit et le programme, prouvant que l’appareil est capable de quantifier précisément le volume d’eau qui transite dans la conduite.

Afin de corriger les dérives inhérentes aux composants chimiques des sondes de pH, une procédure d'étalonnage en deux points est requise avant le déploiement sur site :

1. Point de Neutre (pH = 7.00) : Immerger la sonde dans une solution tampon de pH 7.00. Mesurer la tension correspondante obtenue sur l'entrée A4 de l'ATmega328P. Ajuster la constante V dans le code pour neutre correspondre exactement à cette valeur.

2. Point d'Acidité (pH = 4.01) : Nettoyer la sonde avec de l'eau distillée puis la plonger dans une solution tampon de pH 4.01. Noter la nouvelle tension et calculer la pente de sensibilité

électrochimique du capteur. Le système a été soumis à plusieurs scénarios de simulation pour valider sa robustesse logicielle et matérielle :

• Scénario de Détection Multi-Zone : L'application d'un signal supérieur à 2.5V sur les broches A0 et A1 simultanément déclenche l'arrêt immédiat des transistors Q3 et Q1 . Les pompes 1 et 2 s'arrêtent en moins de 150 millisecondes, confirmant la priorité absolue de la routine d'interruption locale sur l'affichage ou la communication.
• Test de Résilience Réseau : En cas de perte de connexion Wi-Fi du NodeMCU (coupure de la passerelle), le microcontrôleur ATmega328P continue d'assurer l'affichage local et la protection du matériel. Le NodeMCU stocke en mémoire tampon locale les dernières trames et réessaye automatiquement de se connecter toutes les 30 secondes sans bloquer l'exécution générale.

3.6. Résultats

Voici quelques images du projet

Abb. in Leseprobe nicht enthalten

Figure 23. Image avant emplacement de la pompe

Abb. in Leseprobe nicht enthalten

Figure 24. Affichage à l’écran de diverses informations relatives à notre système

Abb. in Leseprobe nicht enthalten

Figure 25. Image générale de la maquette après emplacement de la pompe

3.7. Interface monitoring

Le système est principalement constitué de trois interfaces :

0. Interface de login: cette interface permet aux utilisateurs de se connecter à notre système en complétant l’email et le mot de passe

Abb. in Leseprobe nicht enthalten

Figure 26. Page de login

1. Interface de Dashboard

Il s’agit de l’interface qui fait le monitoring de divers capteurs de notre système et donne l’état général du système.

Abb. in Leseprobe nicht enthalten

Figure 27. Page du Dashboard

2. Historique

Pour l’affichage de l’historique de détection relative au fonctionnement de notre système.

Abb. in Leseprobe nicht enthalten

Figure 28. Page Historique du Systèm

CONCLUSION

La mise en œuvre pratique de ce système connecté démontre l'efficacité de l'association entre l'ATmega328P et le NodeMCU ESP8266. L'automatisation locale garanties une réactivité immédiate face aux fuites d'eau, protégeant ainsi l'infrastructure, tandis que le volet IoT offre une visibilité globale indispensable pour la gestion moderne et centralisée des réseaux de distribution d'eau à Goma. Le prototype validé remplit pleinement les exigences du cahier des charges initiales.

CONCLUSION GÉNÉRALE

Arrivé au terme de ce travail de fin d'études portant sur la « Conception et la réalisation d'un prototype du système de contrôle d’un réseau d’eau dans un milieu urbain par l'Internet des Objets (IoT) », il s'avère opportun de dresser un bilan synthétique des résultats obtenus, d'évaluer la validation de nos hypothèses et d'ouvrir des perspectives pour l'amélioration future des infrastructures hydrauliques de la ville de Goma.

L'objectif global de cette recherche était de concevoir, calibrer et tester un prototype technologique capable d’assurer en temps réel le monitoring du débit, de la pression ainsi que la localisation des défauts sur le réseau de distribution de la REGIDESO. Cette initiative visait à offrir une alternative concrète et à bas coût face aux systèmes de supervision industriels classiques (SCADA), dont le déploiement reste prohibitif dans les contextes en développement marqués par l'instabilité énergétique et les contraintes budgétaires.

Au regard des investigations menées, de la conception matérielle et logicielle, ainsi que des tests expérimentaux consignés dans ce mémoire, les conclusions spécifiques suivantes peuvent être formulées :

· Sur le plan matériel et économique : L'intégration du microcontrôleur NodeMCU (ESP8266) couplée à des capteurs de débit à effet Hall et des transducteurs de pression piézorésistifs a permis de valider notre première hypothèse (H1). Nous avons démontré qu'un système d'acquisition modulaire, conçu à partir de composants électroniques accessibles sur le marché local, permet de diviser drastiquement les coûts d'équipement par rapport aux compteurs communicants industriels, tout en maintenant une précision métrologique largement suffisante pour la sectorisation et la détection d'anomalies.
· Sur le plan de la résilience énergétique : Face aux défis d'instabilité et de délestage électrique récurrents dans le Quartier Office 2 de Goma, le déploiement d'un bloc d'alimentation hybride (secteur avec basculement automatique sur batterie lithium-ion via un circuit de charge régulé) a confirmé notre deuxième hypothèse (H2). Le nœud capteur s'est montré capable de maintenir l'acquisition et le stockage local des données lors des coupures de courant, évitant ainsi toute rupture dans la chaîne de suivi hydraulique.
· Sur le plan de l'aide à la décision : Le développement et la mise en ligne d'une interface de monitoring centralisée (Dashboard Web) ont permis de transformer les trames de données brutes en indicateurs clés de performance (KPI). En visualisant en temps réel les variations simultanées de débit et de pression, les ingénieurs de la REGIDESO disposent désormais d’une visibilité granulaire. Cette approche valide l'hypothèse H3 en fournissant un outil d'aide à la décision indispensable pour équilibrer la distribution d'eau entre les différents secteurs en fonction de la demande réelle.
· Sur la réactivité opérationnelle : L'implémentation de l'algorithme de détection des fuites basé sur l'analyse des profils de pression et de débit (notamment par le suivi des débits minimums nocturnes) a permis de ramener le temps de détection et de ciblage d'un défaut de quelques jours à quelques minutes. Cette réduction drastique, formalisée par l'hypothèse H4, limite le volume d'eau non facturée, prévient les pertes commerciales colossales pour la régie et écarte les risques d'affaissements de terrain ou d'inondations localisées au sein de la zone urbaine dense de Goma. Bien que les objectifs initiaux aient été pleinement atteints, ce travail comporte des limitations intrinsèques qui ouvrent la voie à de futures recherches. En effet, notre système s'est concentré sur la dimension quantitative (débit et pression) au détriment du suivi physico-chimique continu, complexe à stabiliser sur de petits nœuds autonomes en raison de la dérive des sondes de pH ou de turbidité. De plus, la connectivité Wi-Fi exploitée par le NodeMCU, bien qu'idéale pour notre prototype de laboratoire et notre zone test, montre ses limites de portée pour un déploiement à l'échelle macro-urbaine.

En guise de perspectives, nous recommandons le passage du protocole Wi-Fi vers une architecture réseau de type LoRaWAN ou NB-IoT, mieux adaptée à la propagation des ondes radio en milieu saturé et permettant d'enfouir les capteurs dans des regards IP68 profonds. De même, l'intégration de modules de traitement basés sur l'intelligence artificielle (Machine Learning) directement au niveau du serveur permettrait de prédire l'usure mécanique des canalisations avant même l'apparition d'une rupture physique.

En somme, ce travail démontre que l'Internet des Objets ne relève plus de la théorie spéculative, mais constitue un levier d'ingénierie pragmatique et indispensable pour moderniser les services publics. Nous espérons que ce prototype servira de jalon scientifique et pratique pour la REGIDESO et les autorités locales de Goma, afin de garantir une gestion plus juste, transparente, sécurisée et durable de cette ressource vitale qu'est l'eau potable.

BIBLIOGRAPHIE

1. Zane, L., Al-Anbagi, I., & Hussein, M. (2020). Wireless Sensor Networks for Real-Time Water Leak

2. Detection: A Comprehensive Review of IoT Architectures. IEEE Internet of Things Journal, 7(4), 2845-2861.

3. Faraday, M., & Maxwell, J. C. (2019). Principles of Electromagnetic Flow Measurement in Fluid Dynamics. Cambridge University Press.

4. Kakule, J. (2024). Conception d'un prototype IoT de détection des défauts physiques sur le réseau hydraulique de Goma. Mémoire de fin d'études, Institut Supérieur d’Informatique et de Gestion (ISIG).

5. Ilunga, K. (2024). Supervision web temps réel de la qualité physico-chimique des eaux de distribution en milieu péri-urbain. Revue Africaine des Sciences Appliquées, 12(2), 89-104.

6. Wani, A. A., & Shah, M. A. (2021). Smart Water Management Using IoT: A Practical Approach toward Smart Cities. Springer Core Computer Science Series, 142-158.

7. Sauter, T., & Lobashov, M. (2022). End-to-end Latency Analysis in Dual-Processor Master-Slave Architectures for Industrial IoT Nodes. IEEE Transactions on Industrial Informatics, 18(3), 1902-1915.

8. REGIDESO RDC. (2025). Rapport annuel sur les pertes non techniques et l'état des infrastructures de distribution dans la province du Nord-Kivu. Direction Technique de Goma.

9. Makarov, S., & Petrenko, V. (2023). Acoustic Leak Localization Algorithms in Plastic Water Pipes Using Piezo ceramic Hydrophones. Journal of Sound and Vibration, 544, 117-132.

10. Espressif Systems. (2024). ESP8266EX Datasheet v4.3: Low-Power Wi-Fi Integrated SoC. Tech Report.

11. Atmel Corporation. (2022). ATmega328P 8-bit AVR Microcontroller with 32K Bytes In-System Programmable

ANNEXES

CODE SOURCE

#include <WiFi.h> #include <HTTPClient.h> #include <LiquidCrystal.h> int nombrefuite;

const char* ssid = "regidesoconnect"; const char* password = "12345678";

const char* server = "http://192.168.43.221/dataread.php"; // Ton API Nyosha const char* server2 = "http://192.168.43.221/datawrite.php";

String postdata; #define pompe 22

#define signalisation_pompe 16 LiquidCrystal lcd(13,12,15,25,27,14); int datacapteur1;

int datacapteur2; int datacapteur3; int datacapteur4;

String datacapteur1string; String datacapteur2string; String datacapteur3string; String datacapteur4string;

String nombrefuitestring; void setup() { pinMode(pompe, OUTPUT);

pinMode(signalisation_pompe, OUTPUT); pinMode(35, INPUT);

pinMode(34, INPUT); pinMode(33, INPUT); pinMode(32, INPUT); lcd.begin(16,2); WiFi.begin(ssid, password); Serial.print("MON IP"); Serial.begin(9600);

while (WiFi.status() != WL_CONNECTED) { delay(500);

Serial.print(".");

}

Serial.println("Connecté!"); Serial.println(WiFi.localIP());

}

void loop() {

datacapteur1 = digitalRead(35); datacapteur2 = digitalRead(34); datacapteur3 = digitalRead(33);

datacapteur4 = digitalRead(32); nombrefuite=datacapteur1+datacapteur2+datacapteur3+datacapteur4; datacapteur1string = String(datacapteur1);

datacapteur2string = String (datacapteur2); datacapteur3string = String (datacapteur3); datacapteur4string = String (datacapteur4); nombrefuitestring = String (nombrefuite);

postdata = "fuiteun="+datacapteur1string + "&fuitedeux=" + datacapteur2string + "&fuitetrois=" + datacapteur3string +"&fuitequatre=" + datacapteur4string +"&nombrefuite=" + nombrefuitestring;

Serial.println(postdata); HTTPClient httpenvoie; httpenvoie.begin(server2);

httpenvoie.addHeader ("Content-Type", "application/x-www-form-urlencoded"); int etatcodeserver = httpenvoie.POST(postdata);

if(etatcodeserver > 0) {

Serial.println("code envoie " + etatcodeserver);

} else {

Serial.println("ERROR " );

}

httpenvoie.end(); Serial.print("datal1:"); Serial.println(datacapteur1);

Serial.print("datal2:"); Serial.println(datacapteur2); Serial.print("datal3:"); Serial.println(datacapteur3); Serial.print("datal4:"); Serial.println(datacapteur4); lcd.setCursor(0,0); lcd.print("REGIDESO CRTL PO");

lcd.setCursor(0,1); lcd.print("F:"); lcd.setCursor(2,1); lcd.print(datacapteur1); lcd.setCursor(4,1); lcd.print("F:"); lcd.setCursor(6,1);

lcd.print(datacapteur2); lcd.setCursor(8,1);

lcd.print("F:"); lcd.setCursor(10,1); lcd.print(datacapteur3); lcd.setCursor(12,1); lcd.print("F:"); lcd.setCursor(14,1);

lcd.print(datacapteur4); HTTPClient http;

// WiFiClient client;

http.addHeader("Content-Type", "application/x-www-form-urlencoded"); http.begin( server);

int httpCode = http.GET(); Serial.println("Code:" + String(httpCode)); if(httpCode == 200) {

String payload = http.getString();

// Serial.println(payload);

String datarecu = payload.substring(0,6); Serial.println(datarecu);

if(datarecu.indexOf("1") != -1) { Serial.println("ok pompe 1"); digitalWrite(pompe, HIGH); digitalWrite(signalisation_pompe, HIGH);

}

if (datarecu.indexOf("0") != -1){ Serial.println("ok pompe 0"); digitalWrite(pompe, LOW); digitalWrite(signalisation_pompe, LOW);

}

}

http.end(); delay(3000);

}

[...]

Excerpt out of 67 pages  - scroll top

Buy now

Title: Conception et Réalisation d’un prototype du système de contrôle d’un Réseau d’eau dans un Milieu Urbain par IOT. Cas de la REGIDESO /Goma

Diploma Thesis , 2026 , 67 Pages , Grade: 15.3/20

Autor:in: Cédric Kisonia (Author)

Electrotechnology
Look inside the ebook

Details

Title
Conception et Réalisation d’un prototype du système de contrôle d’un Réseau d’eau dans un Milieu Urbain par IOT. Cas de la REGIDESO /Goma
Course
Travail de fin d'étude
Grade
15.3/20
Author
Cédric Kisonia (Author)
Publication Year
2026
Pages
67
Catalog Number
V1749946
ISBN (PDF)
9783389202517
ISBN (Book)
9783389202524
Language
French
Tags
IoT ATmega328P NodeMCU Détection de fuites Supervision hydraulique Application Web
Product Safety
GRIN Publishing GmbH
Quote paper
Cédric Kisonia (Author), 2026, Conception et Réalisation d’un prototype du système de contrôle d’un Réseau d’eau dans un Milieu Urbain par IOT. Cas de la REGIDESO /Goma, Munich, GRIN Verlag, https://www.grin.com/document/1749946
Look inside the ebook
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
Excerpt from  67  pages
Grin logo
  • Grin.com
  • Shipping
  • Contact
  • Privacy
  • Terms
  • Imprint
  • Withdraw Contract