Projet réalisé par  Patrice Eugène, ing.
🧊

Smart Fridge

Système de surveillance de réfrigérateur à base d'ESP32-CAM, avec analyse automatique du contenu par intelligence artificielle.

Aucune activité récente
284
photos au total
3 min
intervalle photos
11:56
dernière photo

Accès rapide

À propos du projet

Ce projet utilise 6 module(s) ESP32-CAM placé(s) dans un réfrigérateur. À intervalle régulier, chaque caméra prend une photo et l'envoie de façon sécurisée (HTTPS) vers ce serveur. Chaque image passe d'abord par une détection de personne (application Python locale) : toute photo où quelqu'un apparaît est immédiatement rejetée et n'est jamais enregistrée, pour préserver la vie privée. Les autres images sont ensuite analysées par Claude AI, qui identifie les aliments présents. Une sonde de température mesure aussi l'intérieur du réfrigérateur en continu.

Technologies utilisées

🔌 Électronique & matériel
  • Microcontrôleur ESP32-WROVER : puce avec WiFi intégré, mémoire PSRAM et connecteur caméra.
  • Capteurs d'image (connecteur 24 broches) :
    • OV2640 : 2 mégapixels, objectif standard à 68° d'angle de vue.
    • OV5640 : 5 mégapixels, objectif grand-angle 160° (vision large pour couvrir tout l'intérieur du réfrigérateur).
    Les deux modules se branchent sur le même connecteur 24 broches de l'ESP32 (bus parallèle dédié).
  • Sonde de température DS18B20 : capteur numérique étanche en protocole 1-Wire (un seul fil de données + résistance pull-up 4,7 kΩ).
  • GPIO & ADC : gestion des broches d'entrée/sortie de l'ESP32, avec les contraintes de l'ADC1 quand le WiFi est actif.
  • Alimentation 3,3 V : régulation de tension et câblage (VCC, GND, lignes de données).
  • Lecture de schémas & brochage (pinout) : interprétation des datasheets pour relier chaque composant correctement.
  • Réfrigérateur de développement — Whirlpool WRF560SEHZ02 : frigo à portes françaises (~20 pi³, 2022) servant de banc d'essai réel. Alimenté en 115 V / 60 Hz, 6,5 A à pleine charge — une prise standard que partagent les cartes caméras, ce qui oriente la conception basse consommation et alimentée par USB de l'électronique.
  • Conception 3D paramétrique (OpenSCAD) : le boîtier de caméra est écrit sous forme de code plutôt que dessiné, de sorte que chaque dimension — taille de la carte, position de l'objectif, épaisseur du balconnet, tolérance d'impression — est une variable en tête de fichier. On mesure le matériel réel, on change un nombre, on régénère : la pièce s'adapte au lieu d'être redessinée.
  • Impression 3D des supports de frigo : pièces imprimées en PLA sur une Bambu Lab X1C, conçues autour des contraintes du procédé — un clip à ressort dont l'ouverture est volontairement plus étroite que le balconnet pour qu'il pince, un congé au raccord le plus sollicité pour que le clip ne casse pas net, un chanfrein autour de l'objectif pour que la paroi ne rogne pas le champ de vision, et des fentes d'aération parce qu'un boîtier étanche dans un frigo invite la condensation sur l'objectif.
💻 Logiciel & informatique
  • Programmation embarquée : firmware en C/C++ via l'environnement Arduino (cycle setup/loop, gestion du temps sans blocage avec millis()).
  • Communication réseau : WiFi, requêtes HTTPS multipart pour l'envoi des photos, synchronisation horaire NTP.
  • Bibliothèques embarquées : OneWire et DallasTemperature (sonde), pilote caméra esp_camera.
  • Backend PHP : réception des images, journalisation, configuration à distance, API de données.
  • Détection de personne (Python / OpenCV) : application Flask locale qui analyse chaque photo avec des réseaux de neurones DNN (modèle res10 pour les visages, MobileNet-SSD pour les corps). Toute photo où une personne apparaît est rejetée — protection de la vie privée, gratuite et instantanée.
  • Intelligence artificielle : API Claude (vision) pour décrire le contenu du réfrigérateur (identification des aliments).
  • Filtrage intelligent des images : détection de luminosité (images trop sombres ou surexposées ignorées) et comparaison par empreinte perceptuelle (hash) pour éviter de réanalyser des images identiques — réduction des coûts d'API.
  • Mesure de température : historisation, graphiques interactifs (Canvas) avec moyenne, export CSV/JSON.
  • Front-end web : HTML/CSS/JavaScript, interface responsive (mobile et bureau), navigation tactile, défilement fluide.
  • Identifiants uniques : chaque caméra s'identifie par son adresse MAC, pour un déploiement à grande échelle.
  • Mises à jour OTA (Over-The-Air) : les caméras mettent à jour leur firmware sans fil, avec ciblage global ou par caméra et détection automatique de la version depuis le nom du fichier.
  • Interface bilingue (EN/FR) : moteur de traduction centralisé, détection automatique de la langue (navigateur, cookie) et sélecteur de langue sur chaque page.
  • Journal d'événements centralisé : les caméras et le serveur écrivent dans un journal de transactions commun (téléversements, température, qualité WiFi, événements OTA), consultable et filtrable sur le web.
  • Formulaire de contact avec double opt-in : confirmation par courriel avant livraison, géolocalisation IP pour le suivi, et authentification du domaine (SPF/DKIM/DMARC) pour la délivrabilité.
  • Configuration à distance : intervalle des photos, activation des caméras, pause de l'analyse/téléversement, et réglages d'image par caméra, tous ajustables depuis le web sans reflasher.
  • Protection du serveur & contrôle de la charge réseau : vérifications OTA espacées, envois par lots et essais ralentis, avec des valeurs minimales verrouillées pour éviter de déclencher le pare-feu de l'hébergeur (qui bloque les IP générant trop de requêtes).
  • Courriels transactionnels authentifiés : messages de confirmation et de surveillance envoyés via SMTP authentifié (PHPMailer), avec gabarits HTML stylisés, images de carte statique Geoapify, comparaison d'identité et rapport quotidien par cron.
  • Chiffrement des identifiants : les identifiants sensibles sont stockés chiffrés (AES-256) plutôt qu'en clair.
  • Gestion de flotte & export de données : inventaire OTA suivant la version réelle, la dernière mise à jour et l'IP locale de chaque caméra, un déploiement global qu'on peut mettre en pause, et des exports CSV (Excel) du journal et de l'inventaire.
  • Géolocalisation IP : l'IP du visiteur est résolue en ville, pays et fournisseur via ip-api.com, avec un lien interactif OpenStreetMap et une image de carte statique Geoapify intégrée dans les courriels de surveillance.
  • Configuration WiFi sans fil par Bluetooth : aucun réseau n'est codé en dur dans le firmware. Une carte maître dédiée reçoit le WiFi depuis l'application mobile officielle ESP BLE Provisioning (sécurité par Proof-of-Possession), puis ferme le Bluetooth pour libérer la mémoire.
  • Architecture maître/esclave avec partage ESP-NOW : le maître diffuse le WiFi (mot de passe chiffré) à toutes les caméras du frigo via ESP-NOW, de sorte qu'une seule configuration paramètre chaque caméra. Séparer le Bluetooth (maître) et la caméra (esclaves) permet à chaque carte de tenir dans sa mémoire.
  • Code QR par frigo : chaque maître dérive une identité Bluetooth unique de son adresse MAC, encodée dans un code QR à coller sur le frigo, pour une configuration en un scan dans l'application sans taper aucun code.
  • Reconnexion robuste : lors d'une coupure WiFi temporaire, le réseau enregistré est conservé et la caméra se reconnecte automatiquement, au lieu d'effacer sa configuration ; le maître apparaît comme appareil connecté dans l'inventaire OTA (marqué maître, jamais mis à jour).
  • Gestion du code sur GitHub : l'ensemble du projet (micrologiciel ESP32, pages PHP, modèles 3D) est versionné dans un dépôt Git, avec l'historique complet de chaque modification, la possibilité de revenir en arrière sur une version défectueuse, et des branches pour développer une fonctionnalité sans casser ce qui fonctionne déjà.
  • Intégration continue avec GitHub Actions : chaque envoi de code déclenche automatiquement des vérifications (syntaxe PHP, compilation du micrologiciel), afin qu'une erreur soit détectée avant d'atteindre le site en ligne ou une caméra, plutôt que d'être découverte en production.
  • Suivi des tâches dans Jira : fonctionnalités, bogues et améliorations sont consignés sous forme de tickets, priorisés et suivis jusqu'à leur réalisation — la méthode employée dans les équipes logicielles professionnelles, appliquée ici à un projet personnel.
  • Documentation dans Confluence : les décisions d'architecture, les schémas de câblage, les protocoles réseau et les procédures de configuration sont écrits plutôt que gardés en tête, afin que le projet reste compréhensible des mois plus tard et puisse être repris par quelqu'un d'autre.
  • Assistant « Mon frigo » : une page qui relit toutes les descriptions rédigées par Claude sur une période choisie (semaine, deux semaines, mois, ou tout) et transforme ce texte libre en liste d'épicerie structurée — uniquement des produits réellement achetables en magasin, les contenants opaques et les restes non identifiables étant écartés. Chaque article indique sa fréquence d'apparition, ce qui fait ressortir les essentiels du ménage.
  • Suggestions de recettes issues de vrais sites : Claude cherche sur le web des recettes existantes qui utilisent ce qu'il y a réellement dans le frigo, filtrées selon les goûts et contraintes du ménage. Chaque suggestion renvoie à sa source (Ricardo et autres sites québécois) plutôt que de reproduire la recette, et la consigne valorise explicitement l'originalité par rapport au plat évident.
  • Descriptions autonomes : chaque analyse enregistre désormais sa propre date et sa caméra à côté du texte, au lieu de dépendre du nom de la photo. Les photos sont plafonnées et supprimées à mesure que de nouvelles arrivent, mais les descriptions subsistent — elles deviennent la mémoire durable de ce qui est passé dans le frigo. Les deux formats de stockage, ancien et nouveau, sont lus indifféremment, ce qui garde des années d'historique exploitables.
  • Chargement non bloquant : la page de surveillance attendait auparavant chaque analyse Claude en attente avant d'afficher quoi que ce soit, soit plusieurs secondes d'écran vide. Elle s'affiche maintenant immédiatement à partir des descriptions en cache et récupère les manquantes en arrière-plan, une à la fois, en les remplissant à mesure — y compris en direct dans une photo déjà ouverte.
  • Données hors de la racine web : photos, fichiers JSON, micrologiciels et clés d'API ont été sortis du dossier public. Rien de l'installation — nombre de frigos, adresses MAC des caméras, nombre de clients — ne peut être déduit d'un balayage du site. Les images transitent par un script qui valide chaque requête et résout le chemin pour garantir qu'il ne peut sortir du dossier des photos.
  • Épiceries à proximité et rabais en cours : la liste d'épicerie rejoint le monde réel grâce à la géolocalisation du navigateur (ou un code postal) pour trouver les supermarchés dans un rayon de cinq kilomètres, et une recherche web des rabais sur ces produits précis, affichant le prix courant barré à côté du prix en rabais avec l'économie calculée.

Le futur du projet

L'architecture actuelle convient pour une maison. Passer à 500 000 caméras nécessiterait de quitter le serveur unique partagé pour une plateforme distribuée native du cloud. Voici la direction technique qui rendrait cela possible.
🚀 Mise à l'échelle & architecture
  • Microservices sans état : découper le backend PHP monolithique en services indépendants (ingestion, analyse, notifications) qui peuvent chacun monter en charge horizontalement derrière un répartiteur de charge.
  • File de messages : les caméras publient photos et événements dans une file (Kafka / AWS SQS) au lieu de frapper le serveur directement — lissant les pics de trafic et découplant la capture du traitement.
  • Mise à l'échelle automatique & conteneurs : services empaquetés en Docker et orchestrés avec Kubernetes (EKS), ajoutant automatiquement de la capacité à mesure que le nombre de caméras augmente.
  • Réseau de diffusion (CDN) : images et pages statiques servies depuis des points de présence proches des utilisateurs, réduisant la latence et la charge du serveur d'origine.
  • Déploiements OTA progressifs : firmware poussé par étapes (canari → pourcentage → flotte complète) avec retour arrière automatique, pour qu'une mauvaise mise à jour n'atteigne jamais les 500 000 caméras d'un coup.
🗃 Données distribuées
  • Base NoSQL distribuée : métadonnées, versions et événements des caméras stockés dans DynamoDB ou Cassandra, qui répartissent les données sur de nombreux nœuds et montent à des milliards d'enregistrements.
  • Stockage objet : photos stockées dans Amazon S3 (quasi illimité) avec des règles de cycle de vie pour archiver ou supprimer automatiquement les anciennes images.
  • Base temporelle : relevés de température et de capteurs stockés dans un moteur spécialisé (TimescaleDB / Amazon Timestream) conçu pour les données de capteurs à haut volume.
  • Partitionnement & réplicas de lecture : données partitionnées par région/compte et répliquées pour que les lectures montent en charge indépendamment des écritures, sans goulot unique.
☁ Intégration cloud AWS
  • Ingestion gérée : AWS IoT Core pour connecter et authentifier des millions d'appareils via MQTT, avec des certificats par appareil.
  • Traitement serverless : fonctions AWS Lambda déclenchées par événement (analyser une photo, envoyer un courriel) — payer seulement ce qui s'exécute, monte de zéro à des millions automatiquement.
  • IA gérée : Amazon Rekognition pour la détection de personnes et Amazon Bedrock (Claude) pour la description du contenu, supprimant le besoin de l'app Python/Flask locale.
  • Infrastructure en code : toute la plateforme définie en Terraform / CloudFormation, reproductible sur plusieurs régions et environnements en quelques minutes.
  • Observabilité : métriques, journaux et alertes centralisés (CloudWatch, Prometheus, Grafana) pour surveiller la santé de toute la flotte en temps réel.
🔒 Sécurité renforcée
  • Identité par appareil : chaque caméra détient un certificat X.509 unique ; un appareil compromis peut être révoqué individuellement sans affecter la flotte.
  • Chiffrement de bout en bout : TLS en transit et chiffrement au repos (S3, base de données) avec des clés gérées par AWS KMS — aucun secret jamais stocké en clair.
  • Firmware signé : binaires OTA signés cryptographiquement et vérifiés par l'appareil avant installation, empêchant les mises à jour malveillantes ou altérées.
  • Accès zéro-confiance & IAM : rôles précis et permissions au moindre privilège pour chaque service et utilisateur, avec authentification multifacteur pour les administrateurs.
  • Protection DDoS & limitation de débit : AWS WAF et Shield en périphérie pour absorber les attaques et brider le trafic abusif avant qu'il n'atteigne les services.
  • Vie privée & conformité par conception : filtrage des personnes conservé sur l'appareil, résidence des données par région, pistes d'audit, et alignement avec des normes comme le RGPD et SOC 2.
🔐 Sécurité des appareils (défense en profondeur)

Au-delà du cloud, les caméras elles-mêmes seraient renforcées en trois couches complémentaires. Chaque couche protège contre une menace différente, et la couche matérielle protège les secrets utilisés par les deux autres — un attaquant devrait donc franchir les trois à la fois.

  • Couche 1 — Jeton unique par caméra (niveau applicatif) : au lieu d'un secret partagé, chaque caméra dérive son propre jeton de son adresse MAC combinée à un secret côté serveur (HMAC-SHA256). Le serveur le recalcule et le vérifie à chaque requête. Un jeton volé ne fonctionne que pour une seule caméra, et n'importe quelle caméra peut être révoquée individuellement. Le coût est négligeable (~2 Ko de RAM, le SHA-256 est intégré à l'ESP32) et c'est entièrement réversible, ce qui en fait une première étape sans risque.
  • Couche 2 — TLS mutuel avec certificats client signés (niveau connexion) : chaque caméra porterait un certificat X.509 unique signé par une autorité de certification privée (PKI). Le serveur rejetterait toute connexion ne présentant pas un certificat signé par cette autorité ; un ESP32 étranger ou contrefait ne peut donc tout simplement pas établir de session. C'est la solution classique du « certificat signé » ; son coût principal est la RAM pendant la poignée de main TLS (~40–50 Ko), que le WROVER absorbe grâce à ses 8 Mo de PSRAM. Le vrai effort est opérationnel : gérer une PKI, émettre un certificat par caméra et gérer la révocation.
  • Couche 3 — Secure Boot + chiffrement de la flash (niveau matériel) : les eFuses matériels de l'ESP32 (bits programmables une seule fois, physiquement irréversibles) stockeraient des clés qui (a) font que la puce n'exécute que du firmware signé avec la clé privée du fabricant, refusant au démarrage toute version modifiée ou infectée, et (b) chiffrent la flash pour que le firmware — et les secrets des couches 1 et 2 — soient illisibles même en dessoudant la puce. C'est ce qui répond vraiment à « ne pas laisser entrer un appareil infecté », car cela garantit que seul le firmware authentique s'exécute et que ses secrets restent dans le silicium.
  • Pourquoi les trois ensemble : la couche 3 protège les couches 1 et 2 — sans elle, le jeton par caméra et la clé privée du certificat pourraient être extraits du firmware ; avec elle, ils deviennent inextractibles. Un intrus aurait besoin d'un firmware signé par nous, d'un certificat signé par notre autorité et d'un jeton valide, tout en même temps. Elles se déploient dans l'ordre (jeton d'abord, TLS mutuel ensuite, scellement matériel en dernier) car le Secure Boot est irréversible et ne s'applique qu'une fois le firmware final — comme couler le béton des fondations une fois les plans figés.
Projet réalisé par Patrice Eugène, ing.

Ce site utilise des témoins (cookies) pour assurer son bon fonctionnement et améliorer votre expérience. En savoir plus.

Politique sur les témoins

Un témoin (cookie) est un petit fichier stocké sur votre appareil. Ce site en utilise pour retenir votre choix de consentement, et assurer le fonctionnement des pages. Nous n'utilisons pas de témoins à des fins publicitaires. Vous pouvez refuser : le site restera fonctionnel. Vous pouvez aussi effacer les témoins via les réglages de votre navigateur.