Nom de l’équipe : BREIZH4LINE

 

Membres de l’équipe : 

Axelle Mellier, FISE A2 IMT Atlantique

Jean-Louis Dje, FISE A2 IMT Atlantique

Lise Pelletier, FISE A2 IMT Atlantique

Romain Christol, FISE A2 IMT Atlantique

Samuel Pooda, FISE A2 IMT Atlantique

 

I – CONTEXTE

 

Cet article s’inscrit dans le cadre du Projet Fil Rouge de la TAF COUAD. L’objectif de ce projet est de partir d’une problématique réelle et locale, de la formaliser, puis de concevoir et de mettre en œuvre une solution technique adaptée.

Cela dit, notre équipe a choisi de s’intéresser au gaspillage de l’eau dans les ménages et aux conséquences environnementales associées, notamment le risque de pénurie d’eau dans certaines localités françaises. À partir de ce constat, nous avons conçu une solution technique visant à mesurer, centraliser et exploiter les données de consommation d’eau domestique.

Ainsi, la solution repose sur quatre composantes centrales, chacune ayant un rôle bien défini :

• un capteur de volume d’eau consommée par utilisation, fixé directement sur un robinet

• un afficheur, placé à proximité du robinet, permettant de visualiser localement les données mesurées 

• un serveur web local, chargé de centraliser l’ensemble des données de consommation sans recours à Internet 

• une application web, hébergée sur ce serveur, offrant une interface de gestion détaillée de la consommation d’eau

Par conséquent, l’application web permet plusieurs fonctionnalités essentielles : la visualisation des données en temps réel, la consultation des coûts financiers associés à la consommation, ainsi que l’accès à des recommandations personnalisées visant à améliorer les habitudes de consommation à partir des données personnelles collectées

De plus, l’ensemble des composantes du système communique entre elles selon un schéma de communication bien précis. Le capteur mesure le volume d’eau utilisé et transmet ces données aux autres éléments du système. L’afficheur reçoit ces informations afin de les présenter immédiatement à l’utilisateur, tandis que le serveur web local joue le rôle de point central : il collecte, stocke et met à disposition les données pour l’application web. Cette organisation permet un fonctionnement autonome, sans dépendance à une connexion Internet.

Par ailleurs, la solution est structurée autour de deux grandes approches complémentaires. D’une part, les composantes matérielles regroupent la conception électronique ainsi que la modélisation et l’impression 3D des éléments physiques, à savoir le serveur, le capteur et l’afficheur. D’autre part, les composantes logicielles concernent l’ensemble de la plateforme web développée pour l’exploitation des données.

En outre, la réalisation d’un premier prototype a nécessité l’ensemble du matériel suivant : 

• une (1) Raspberry Pi 3B+
• deux (2) cartes ESP32
• deux (2) modules Bluetooth HC-05
• un (1) élévateur de tension U3V40F5 
• un (1) afficheur 7 segments 4 digits TM1637 
• une (1) batterie lithium 3.7v 2200mAh
• un (1) débitmètre commercial Titan
• un (1) module de charge de batterie 
• un (1) interrupteur 
• des câbles

Enfin, toutes les pièces physiques utilisées dans ce tutoriel ont été modélisées à l’aide du logiciel Fusion 360, puis exportées au format .stl afin d’être imprimées en 3D. Le traitement de ces fichiers a été réalisé avec le logiciel Ultimaker Cura, permettant de vérifier la faisabilité des impressions, d’optimiser l’orientation des pièces et d’ajouter, si nécessaire, des supports pour garantir une impression correcte.

 

II – SERVEUR

 

Le serveur local de notre solution repose sur une Raspberry Pi 3B+, sur laquelle est déployé un serveur web hébergeant notre application web de gestion de la consommation d’eau.

La mise en œuvre de ce serveur s’articule autour de deux éléments clés. Il s’agit notamment de la carte Raspberry Pi, de son support physique ainsi que des composants électroniques associés.

 

1 – Raspberry Pi

 

Premièrement, la carte Raspberry Pi 3B+, qui est un micro-ordinateur monocarte (single-board computer). Compacte et peu coûteuse, elle intègre un processeur ARM, de la mémoire vive (RAM), des interfaces réseau filaires et sans fil (Ethernet et Wi-Fi) ainsi que divers ports d’entrées/sorties, lui permettant d’exécuter un système d’exploitation et des applications serveur.

Cette carte, que nous appellerons RPI dans la suite de ce tutoriel, dispose donc de ressources suffisantes pour héberger un serveur web et le rendre accessible sur un réseau local, créé à partir d’un point d’accès Wi-Fi partagé entre l’Afficheur et nos terminaux mobiles.

Dans notre configuration, la RPI émule son propre point d’accès Wi-Fi, ce qui permet de s’affranchir de l’utilisation d’une box Internet ou d’un point d’accès mobile externe. Nous avions initialement opté pour cette solution ; cependant, après plusieurs jours de développement, ce point d’accès s’est révélé instable, puis inutilisable. Néanmoins, lorsqu’elle est correctement configurée et maîtrisée, cette approche demeure l’une des meilleures alternatives dans un contexte autonome.

Afin de permettre les échanges de données entre l’Afficheur et le serveur local, mais également l’accès à l’application web hébergée, il était indispensable de relier l’ensemble des composants par un support de communication commun. Le support retenu est le Wi-Fi.

Ce choix s’explique, dans un premier temps, par la nécessité d’utiliser le protocole HTTP, indispensable à l’accès à une application web. HTTP est en effet le protocole standard des communications web, reposant principalement sur une architecture client–serveur, et il s’appuie sur des réseaux IP, dont le Wi-Fi constitue un moyen d’accès courant.

Dans un second temps, le Wi-Fi permet également d’assurer la communication entre l’Afficheur, qui héberge un client web, et le serveur web. Bien que le volume d’eau mesuré par le capteur, puis relayé à l’Afficheur, aurait pu être transmis au serveur via d’autres technologies de communication telles que le Bluetooth, l’utilisation de plusieurs canaux distincts aurait été inutilement complexe. Le Wi-Fi, déjà employé pour l’accès à l’application web, s’est donc imposé comme une solution unique et cohérente.

Notre application web nécessitant le stockage de données structurées — notamment les données personnelles des utilisateurs sous forme de textes et de valeurs numériques, ainsi que l’ensemble des informations requises par les différentes fonctionnalités — nous avons implémenté une base de données sur le serveur. Nous avons opté pour une base de données relationnelle de type SQL, en l’occurrence MariaDB. MariaDB étant facile à déployer sur notre RPI grâce à des bibliothèques existantes et compatibles avec le système d’exploitation.

La mise en œuvre de la base de données et du serveur web sur la RPI s’est déroulée comme décrit ci-dessous.

Pour tout le tutoriel, nous utiliserons le terminal de la Raspberry Pi via SSH, sauf indication contraire.

SSH (Secure Shell) est un protocole de communication sécurisé qui permet d’accéder à distance à la ligne de commande d’un autre ordinateur à travers un réseau, tout en chiffrant les échanges afin de garantir la confidentialité et l’intégrité des données.

Bien qu’il soit parfois plus simple d’utiliser l’interface graphique, l’usage du terminal via SSH présente l’avantage de pouvoir administrer la RPI sans écran, clavier ni souris, évitant ainsi de devoir transporter du matériel supplémentaire.

 

2 – Support physique

Le support physique prend la forme d’un boîtier comportant, à l’arrière, des orifices permettant l’accès aux ports physiques de la Raspberry Pi. À ce boîtier est associé un couvercle faisant également office de support au sol, assurant la stabilité de l’ensemble du serveur.

Le serveur présente un volume approximatif de 150 × 104 × 50 mm.

Des cylindres solidaires du boîtier, visibles sur la dernière image, permettent de fixer la RPI.

 

III – AFFICHEUR

 

L’Afficheur est la composante du système qui permet de visualiser, en temps quasi réel, le volume d’eau mesuré par le capteur. Il est installé à proximité du capteur et assure un rôle d’interface entre celui-ci et le serveur local.

L’Afficheur est connecté au capteur via Bluetooth et au serveur local via Wi-Fi.

Concernant la communication entre l’Afficheur et le capteur, nous avons opté pour le Bluetooth, car cette technologie est particulièrement adaptée aux communications de courte portée, sans obstacle majeur, tout en offrant une connexion active et stable entre les deux dispositifs.

Ce choix est également motivé par nos perspectives d’évolution : le capteur pourrait, à terme, être intégré à un pommeau de douche. Dans ce contexte, une éventuelle chute ou manipulation du capteur ne devrait pas entraîner de rupture de la communication. Le Bluetooth présente ainsi une bonne robustesse, une faible consommation énergétique et une portée suffisante pour ce type d’usage.

Nous avons donc privilégié cette solution, peu coûteuse en énergie, adaptée à la distance et fiable, au détriment d’autres technologies telles que le Wi-Fi ou l’infrarouge. En effet, bien que le Wi-Fi soit déjà utilisé par l’Afficheur pour communiquer avec le serveur local, son utilisation pour la communication avec le capteur aurait nécessité la mise en place d’un serveur sur l’un des deux dispositifs, impliquant une complexité logicielle supplémentaire incompatible avec les objectifs de simplicité et de robustesse de notre projet.

La mise en œuvre de l’Afficheur repose sur trois éléments principaux : le réceptacle contenant l’électronique, l’électronique embarquée elle-même, et le programme implémenté sur la carte programmable.

 

1 – Électronique

 

L’Afficheur est basé sur une carte programmable ESP32, un microcontrôleur 32 bits développé par Espressif Systems. L’ESP32 intègre un processeur double cœur, de la mémoire, ainsi que des interfaces de communication natives telles que le Wi-Fi, le Bluetooth et plusieurs bus de communication (UART, SPI, I²C). Ces caractéristiques en font une solution particulièrement adaptée aux systèmes embarqués connectés, offrant une faible consommation énergétique et une grande flexibilité pour le développement.

Bien que l’ESP32 intègre nativement le Bluetooth, nous avons choisi d’ajouter un module Bluetooth HC-05 externe. Cette décision est motivée par le fait que l’utilisation simultanée du Wi-Fi et du Bluetooth sur l’ESP32 n’est pas optimale pour notre projet : la carte utilise la même antenne pour les deux types de communication, ce qui peut provoquer des interférences et rendre les échanges moins fiables, en particulier dans un système nécessitant un temps réel quasi instantané. L’utilisation du HC-05 externe nous permet ainsi de séparer les flux Bluetooth et Wi-Fi, garantissant stabilité et fiabilité de la communication avec le capteur et le serveur.

Le module HC-05 est un module Bluetooth classique (Bluetooth 2.0 + EDR) fonctionnant en mode maître ou esclave, largement utilisé pour sa simplicité d’intégration, sa stabilité et son faible coût. Il communique avec l’ESP32 via le protocole UART (Universal Asynchronous Receiver/Transmitter), un protocole série asynchrone permettant l’échange de données bit par bit entre l’émetteur et le récepteur sans signal d’horloge partagé. L’UART est fiable, simple à mettre en œuvre et adapté aux communications avec des périphériques embarqués.

L’Afficheur intègre également un afficheur 7 segments à 4 digits, le TM1637 de la gamme Grove. Ce module permet d’afficher des valeurs numériques de manière lisible et claire, et communique avec le microcontrôleur via une interface série à deux fils (CLK et DIO), ce qui simplifie le câblage et limite l’usage de broches.

Le logiciel de l’Afficheur suit le cycle suivant :

1. Réception du volume d’eau via Bluetooth : le HC-05 reçoit en continu les mesures envoyées par le capteur et les transmet à l’ESP32 via UART.
2. Traitement des données : l’ESP32 convertit et formate les valeurs reçues pour l’affichage, gère les éventuelles erreurs de transmission et met à jour les variables internes.
3. Affichage sur le TM1637 : les données traitées sont envoyées à l’afficheur 7 segments pour une visualisation en temps quasi réel.
4. Transmission au serveur via Wi-Fi : simultanément, l’ESP32 envoie les valeurs reçues au serveur local via Wi-Fi, permettant leur enregistrement dans la base de données et leur consultation via l’application web.

Cette architecture logicielle garantit que les mesures sont affichées et transmises au serveur de manière fluide et fiable, tout en séparant les communications Bluetooth (capteur → Afficheur) et Wi-Fi (Afficheur → serveur) pour éviter les interférences.

 

2 – Support physique

 

Le support physique de l’Afficheur présente un volume approximatif de 53 × 47 × 40 mm. Il est constitué d’un boîtier et d’un couvercle, chacun percé de trous permettant de les fixer ensemble à l’aide de vis.

Enfin, l’avant du boîtier comporte une cavité rectangulaire dans laquelle l’afficheur TM1637 vient se loger, garantissant une installation stable et sécurisée de la partie visible du dispositif.

3 – Programme : Code Arduino

 

Le code de l’afficheur se trouve sur le Github dont le lien suit : https://github.com/Jean-Louis-DJE/brz-fil-rouge.git

 

IV – CAPTEUR

 

Le Capteur est la composante du système que nous avons conçue pour être fixée directement sur un robinet, à la sortie du jet d’eau. Il s’agit d’un débitmètre auquel nous avons ajouté des fonctions de communication et de calcul afin de mesurer le volume d’eau écoulé et de transmettre cette information aux autres éléments du système.

 

Nous avons choisi d’utiliser un débitmètre commercial pour la version finale du projet. Le modèle retenu est un débitmètre de l’entreprise Titan, initialement conçu pour la mesure de boissons comestibles. Ce choix s’est révélé pertinent, mais il a imposé certaines contraintes d’intégration qui ont conduit à modifier les dimensions prévues pour le Capteur.

En effet, ce débitmètre nécessite une stabilité de l’écoulement du liquide afin de fournir des mesures fiables. Pour cela, le guide d’utilisation recommande d’ajouter, de chaque côté du débitmètre, un tuyau dont la longueur est égale à dix fois le diamètre d’un de ses orifices, afin de stabiliser le flux d’eau.

Par ailleurs, le débitmètre fonctionne à l’aide d’un capteur à effet Hall, qui permet de mesurer le débit en détectant la rotation d’un élément interne soumis à un champ magnétique. Pour limiter les risques d’interférences magnétiques, nous avons choisi de ne pas sectionner les câbles d’alimentation et de données, dont la longueur dépasse un mètre, bien que des calculs plus précis auraient pu permettre de les raccourcir.

Ainsi, nous avons suivi les recommandations du fabricant concernant le câblage et l’utilisation du débitmètre. Cela nous a conduits à séparer physiquement le débitmètre du reste de l’électronique. Nous avons néanmoins modélisé et imprimé un réceptacle destiné à contenir les composants électroniques, sans détailler ce boîtier dans ce tutoriel.

Ensuite, le débitmètre a été connecté à une carte programmable ESP32, à laquelle nous avons ajouté un module Bluetooth HC-05 externe. Bien que l’ESP32 intègre nativement le Bluetooth, nous avons fait ce choix afin de tester différents scénarios de communication, et nous avons conservé cette configuration jusqu’à la version finale du projet.

De plus, le Capteur est alimenté par une batterie Li-Po de 3,7 V et 2200 mAh, ce qui lui permet de fonctionner de manière autonome. 

Comme le module Bluetooth nécessite une tension comprise entre 3,6 V et 6 V, nous avons intégré un élévateur de tension U3V40F5 du fabricant Pololu afin d’adapter la tension fournie par la batterie.

Cependant, cet élévateur de tension ne dispose pas de circuit de charge intégré pour la batterie. Nous avons donc utilisé un module de charge externe pour batterie Li-Po, équipé d’un port Micro-USB, afin de permettre la recharge de la batterie en toute sécurité même avec un adaptateur de téléphone.

Finalement, le Capteur se compose de deux parties principales : l’électronique, qui regroupe le débitmètre, la carte programmable, le module Bluetooth et le système d’alimentation, et le programme embarqué, qui est exécuté sur la carte programmable.

 

1 – Schéma électronique 

NB : veillez à mettre une résistance de pull-up sur DATA. L’interrupteur permet de mettre l’élévateur hors tension lorsque nous voulons programmer la carte afin d’éviter qu’un courant le traverse dans le sens inverse – de la sortie VOUT vers son circuit –. Ce modèle n’est pas équipé d’une protection de courant inverse.

 

2 – Programme

 

Le code du Capteur se trouve sur le Github dont le lien suit : https://github.com/Jean-Louis-DJE/brz-fil-rouge.git

 

V – COMPOSANTES LOGICIELLES

 

1 – Interfaces graphiques

 

A. Maquette

 

Nous avons tout d’abord réalisé une maquette de l’application car elle permet de visualiser, avant même d’écrire une ligne de code, l’organisation des informations, la navigation entre les écrans et l’expérience utilisateur et d’anticiper les contraintes techniques (taille de l’écran, fréquence des mises à jour, lisibilité des mesures en temps réel) et de réduire le temps de développement en validant l’ergonomie en amont.

Pour cela, nous avons utilisé Figma, un outil de prototypage moderne, car il permet de créer des interfaces rapidement, d’obtenir un rendu réaliste et de partager les écrans facilement entre les membres de l’équipe.

B. Interface finale

 

Après plusieurs discussions et modifications, nous nous sommes arrêtés sur cette version finale de l’interface :

• Le menu permettant d’accéder aux différents onglets de l’application

 

• Le compteur principal affichant le volume consommé total du foyer sur une période souhaitée

 

• Un dashboard pour consulter les consommations des différents points d’eau sur une période souhaitée

 

• Un dashboard pour consulter les coûts associés aux consommations des différents points d’eau sur une période souhaitée

 

• Des conseils et recommandations lorsque l’utilisateur se fixe un objectif

 

• Un dashboard permettant d’avoir une analyse de la consommation du foyer (par rapport à des données moyennes de référence) et de consulter les objectifs que l’utilisateur s’est fixé

 

• Une interface permettant d’associer un capteur au point d’eau qu’il analyse

 

• Une section profil pour que l’utilisateur renseigne des informations sur son foyer afin que les analyses soient adaptées à ce dernier

 

2 – Base de données

 

Ce diagramme UML correspond au modèle de départ du projet. Il a été conçu en début de conception afin de structurer le système et d’identifier les principales entités : utilisateur, points d’eau, capteurs, consommations, alertes, serveur et interfaces d’affichage.

Ce modèle nous a permis de poser une vision globale du fonctionnement du système, en distinguant clairement les données métier (consommation, alertes), les composants techniques (capteur, serveur, Wi-Fi) et l’interface utilisateur.

Au cours du projet, ce diagramme a ensuite été ajusté afin de mieux correspondre aux usages réels et à l’approche low-tech retenue. Certains choix ont été simplifiés, notamment sur la gestion des utilisateurs ou des composants, afin de réduire la complexité, faciliter l’installation par un utilisateur non expert et améliorer la maintenabilité du système.

Ce travail itératif illustre une démarche de conception réaliste : partir d’un modèle complet, puis faire des choix techniques raisonnés en fonction des contraintes du projet et des objectifs finaux.

Le modèle conceptuel de données a été conçu pour rester simple, cohérent et adapté à un usage local, tout en permettant une évolution future du système.

• Séparation des données métier et techniques
  Les entités Consommation, PointEau et Alerte représentent le cœur métier du projet. À l’inverse, WifiCredentials concerne uniquement la configuration réseau du dispositif. Cette séparation permet d’éviter les dépendances inutiles et améliore la maintenabilité du système.
• Lien direct entre point d’eau et capteur
  Chaque point d’eau est associé à un seul capteur afin de garantir la traçabilité des mesures et d’éviter toute ambiguïté dans l’origine des données. Ce choix simplifie également l’installation et le déploiement du dispositif.
• Historique détaillé des consommations
  La table Consommation permet de stocker chaque mesure avec un horodatage précis. Ce choix est essentiel pour fournir un historique exploitable, générer des statistiques et déclencher des alertes basées sur l’usage réel.
• Gestion des alertes indépendante
  Les alertes sont modélisées comme une entité distincte afin de ne pas surcharger les données de consommation. Cela permet de gérer différents types d’anomalies (surconsommation, fuite) et d’adapter les règles de détection sans modifier le reste du modèle.
• Présence de l’entité Utilisateur dans le modèle initial
  L’entité Utilisateur a été intégrée dans la version initiale du MCD afin d’anticiper une éventuelle évolution vers un système multi-utilisateurs. Par la suite, certains scénarios ont été simplifiés pour correspondre à un usage domestique sans authentification.

Dans l’ensemble, ce MCD reflète une approche pragmatique et évolutive, où les choix ont été guidés par les contraintes du terrain, l’objectif low-tech du projet et la volonté de proposer un système compréhensible et facile à maintenir.

 

3 – Architecture logicielle

 

 

L’architecture logicielle du système repose sur une approche modulaire et distribuée, adaptée à un contexte IoT et à une utilisation locale sans dépendance à Internet.
Le capteur de débit, associé à un microcontrôleur, mesure la consommation d’eau et transmet les valeurs au boîtier afficheur via une communication Bluetooth. Ce choix permet de séparer physiquement le point de mesure du point d’affichage, tout en conservant une communication simple et à faible consommation.
Le boîtier afficheur, basé sur un ESP32, joue le rôle de passerelle logicielle. Il reçoit les données du capteur, les affiche en temps réel pour l’utilisateur, puis les transmet au serveur local via une API REST HTTP grâce à une connexion Wi-Fi. Cette passerelle centralise ainsi l’affichage, la communication réseau et la transmission des données.
Le serveur local assure le stockage des informations dans une base de données locale. Il expose également une API REST permettant à l’application web de récupérer les données via des requêtes GET, sans accès direct à la base de données depuis les équipements embarqués.
Enfin, l’application web se connecte au serveur local pour charger et afficher les informations de consommation et l’historique. Cette séparation claire entre acquisition, affichage, stockage et consultation améliore la maintenabilité, la sécurité et l’évolutivité du système, tout en respectant l’esprit low-tech du projet.

 

VI – VIDÉO DE DÉMONSTRATION

 

 

VII – PERSPECTIVES

 

1 – Débitmètre

 

Pour garantir la fiabilité immédiate de notre solution, nous avons intégré un capteur standardisé. Toutefois, une piste d’évolution majeure réside dans l’auto-fabrication de ce composant clé. Nous avons d’ailleurs initié cette démarche avec un premier prototype imprimé en 3D. Bien que les défis d’étanchéité aient nécessité de reporter cette intégration, la conception constitue la prochaine étape logique pour maximiser l’autonomie et la réparabilité de notre système.

 

2 – Interface matérielle du serveur local

 

Concernant le serveur local, notre roadmap technique inclut l’intégration d’une interface de contrôle physique (LEDs d’état et boutons poussoirs). L’analyse de conception a révélé que l’implémentation optimale nécessite l’insertion d’un circuit de gestion directement sur les lignes d’alimentation de la Raspberry Pi. Cette modification matérielle, trop invasive pour le matériel de prêt utilisé durant le prototypage, permettrait d’offrir un pilotage matériel de la mise sous tension et de l’extinction.

Au-dessus du boîtier, un espace avait été prévu pour l’intégration de l’interface matérielle, destinée à accueillir les voyants lumineux et les boutons de commande.

 

3 – Autonomie de l’afficheur

 

Bien que le prototype actuel dispose d’un passage de câble pour une alimentation USB-A, l’objectif final est d’offrir une liberté totale de placement grâce à une alimentation autonome. Cette transition technologique ne présente aucun risque technique majeur : nous avons déjà implémenté avec succès cette solution d’autonomie sur le module Capteur. L’intégration d’une batterie sur l’Afficheur est donc la prochaine étape logique pour supprimer les contraintes de câblage dans la salle de bain ou la cuisine.

 

4 – Diminution de l’encombrement du système

 

Actuellement, notre architecture repose sur un capteur par point d’eau, ce qui multiplie les dispositifs. Une voie d’optimisation majeure consiste à passer à un unique capteur par pièce humide (ex: arrivée d’eau générale de la salle de bain). Grâce à des algorithmes d’analyse de flux, il est possible de différencier les signatures hydrauliques (le débit d’une douche est différent de celui d’un lavabo) pour réattribuer logiciellement la consommation à chaque équipement. Cela diviserait grandement le nombre de capteurs nécessaires.

 

 

 

VIII – ANNEXES

 

1 – Déploiement du serveur local

 

A. Prérequis

 

• Installer Raspberry Pi OS :

Pour ce faire, vous devez télécharger puis installer Raspberry Pi Imager sur votre ordinateur, de préférence dans sa version la plus récente.
Raspberry Pi Imager est un outil officiel développé par la Raspberry Pi Foundation permettant de préparer une carte SD en y installant facilement un système d’exploitation compatible avec les cartes Raspberry Pi.

Vous devez ensuite vous procurer une carte SD, puis la connecter à votre ordinateur à l’aide d’un lecteur de cartes. Il vous suffit alors de sélectionner la carte SD dans l’option « Stockage » et de lancer l’écriture.

Assurez-vous que « Raspberry Pi OS (Full) » est sélectionné dans l’option « Système d’exploitation », afin de disposer d’un environnement complet incluant l’interface graphique et les outils nécessaires au développement et à l’administration du serveur.

Enfin, insérez la carte SD  dans le support prévu à cet effet sur la Raspberry Pi (RPI) et allumez là.

• Connecter la RPI à un réseau Wi-Fi local via l’interface graphique. En haut à droite de l’écran, cliquez sur l’icône de réseau pour ajouter un nouveau réseau Wi-Fi.

• Activer l’option SSH dans les paramètres « Interfaces » de la RPI.

Vous les trouverez en cliquant sur le logo de la RPI en haut à gauche, indiquant le centre de contrôle, puis en cherchant « interfaces ».

• Connectez votre ordi à la RPI en SSH.

Pour vous connecter en SSH, votre ordinateur doit être connecté au même réseau Wi-Fi que la RPI. Dans le terminal de votre ordinateur (qui doit disposer d’un client SSH), saisissez :
ssh <nom_d’utilisateur_de_la_RPI>@<adresse_IP_de_la_RPI>
Une ligne de saisie apparaît quand vous appuyez sur “Entrer” et vous demande le mot de passe de votre RPI. Vous pouvez maintenant utiliser le terminal de votre RPI depuis votre ordinateur.

 

B. Mettre à jour les dépôts et les paquets

 

Dans le terminal de la RPI, saisissez :

• sudo apt update
• sudo apt upgrade

 

C. Installer Apache

 

Apache (Apache HTTP Server) est un serveur web open source largement utilisé, dont le rôle est de recevoir les requêtes HTTP des clients (navigateurs web) et de leur fournir les pages web correspondantes. Il constitue l’un des composants fondamentaux d’une architecture web de type client–serveur.

• Dans un terminal, saisir : sudo apt install apache2
• Pour vérifier que tout fonctionne, trouvez l’adresse IP de la RPI, puis tapez dans votre navigateur : http://<adresse_IP_de_la_RPI>

Pour trouver l’adresse IP en ligne de commande, ouvrez un terminal et tapez : ip a. L’adresse IP apparaît après “inet” pour l’interface utilisée (eth0 pour Ethernet, wlan0 pour le Wi-Fi).

En cas de difficulté, vous pouvez consulter : https://raspberrytips.fr/comment-trouver-ip-raspberry-pi/

Vous devriez voir apparaître dans votre navigateur la page suivante :

 

D. Installer PHP

 

PHP est un langage utilisé pour le développement backend des sites Web.

Dans un terminal de la RPI, saisissez :
sudo apt install php libapache2-mod-php

 

E. Installer MySQL (MariaDB)

 

MariaDB est un système de gestion de base de données compatible avec MySQL.

• Installer MariaDB et le module PHP associé :
  sudo apt install mariadb-server php-mysql

• Redémarrer Apache pour appliquer les changements :
  sudo service apache2 restart

• Vous devez maintenant créer un utilisateur MySQL pour gérer vos bases de données.

MySQL nécessite une authentification pour garantir que seules les personnes autorisées peuvent accéder aux données.

Nous devez créer un super-utilisateur que vous utiliserez dans votre code PHP :

• Se connecter à MySQL :
  sudo mysql
• Créer une première base de données :
  CREATE DATABASE test;
• Créer votre premier utilisateur :
  CREATE USER ‘<nom_utilisateur>’@’localhost’ IDENTIFIED BY ‘<mot_de_passe>’;
• Lui donner les permissions sur la base :
  GRANT ALL PRIVILEGES ON test.* TO ‘<nom_utilisateur>’@’localhost’;
• Appliquer les changements :
  FLUSH PRIVILEGES;
• Quitter MySQL :
  quit

 

F. Installer PhpMyAdmin

 

PhpMyAdmin permet de gérer la base de données depuis votre navigateur.

Pour l’installer, saisissez : sudo apt install phpmyadmin

Pendant l’installation :

• Sélectionnez Apache2 (espace puis entrée).
• Pour « Configurer la base de données pour phpmyadmin avec dbconfig-common », choisissez Non.

Après l’installation, rendez-vous sur : http://<adresse_IP_de_la_RPI>/phpMyAdmin

Vous devez voir apparaître la page ci-dessous, saisissez les informations de sécurité que vous avez attribué à votre super utilisateur MariaDB : 

À présent, vous pouvez vous concentrer sur le développement de l’application web à l’aide de votre éditeur de texte ou environnement de développement préféré, puis téléverser le code sur la RPI, en veillant à configurer correctement les accès à la base de données ainsi que les droits d’accès d’Apache2 à l’ensemble des fichiers nécessaires.

Les fichiers du serveur web doivent être placés dans le répertoire : /var/www/html sur la RPI.

Dans notre implémentation, nous avons choisi de structurer l’application en deux répertoires distincts :

• Frontend, contenant l’interface utilisateur (HTML, CSS, JavaScript, etc.) ;
• Backend, regroupant la logique serveur et les scripts d’accès à la base de données tous contenus dans des fichiers PHP.

Ces deux répertoires sont eux-mêmes situés dans le répertoire dédié mentionné ci-dessus, afin d’être accessibles par le serveur web Apache.

 

Series Navigation

<< Breizh4line – Retour enquête terrain