Principe de capture
FogCam ne conserve qu’une seule image à la fois, la supprime dès qu’une nouvelle est disponible. Fog-Bank intercepte chaque image grâce à quatre « catchers » répartis sur trois réseaux. Un poller local interroge le serveur toutes les 7 seconds, le service fogline hébergé chez Cloudflare le fait toutes les 15 seconds (avec un tampon de 30 jours), un worker Cloudflare exécute une requête toutes les 20 seconds et écrit directement en stockage permanent, et enfin une machine domestique effectue une requête toutes les 15 seconds. Chaque requête force le serveur de la caméra à renvoyer le fichier réel en ajoutant un paramètre de requête unique et en imposant des en‑têtes no‑cache, suite à la découverte d’un cache serveur qui renvoyait des images obsolètes en août.
Architecture de l'archivage
À chaque réception, l’image est nommée d’après l’horodatage d’upload fourni par FogCam, puis fingerprinted avec un hash SHA‑256. Le fichier est stocké sans recompression au format JPEG XL lossless, garantissant une conservation bit‑exacte. La même minute, une copie est répliquée vers Cloudflare R2, assurant une redondance géographique. Un processus de nettoyage s’exécute toutes les 5 minutes et chaque nuit pour récupérer d’éventuels éléments perdus lors d’un push, maintenant ainsi l’intégrité du dépôt.
Gestion de la résilience et du suivi
Un tableau de bord de statut interroge chaque étape du pipeline – de la caméra jusqu’à la diffusion sur YouTube – à intervalles de quelques minutes. En cas d’échec, il déclenche une alerte Telegram adressée à l’opérateur. Le tableau consigne chaque interruption, en distinguant les pannes du serveur FogCam (ex. 13 août, gel de 64 heures du 8 au 10 septembre) des pannes locales (ex. disque plein pendant 40 heures). Cette traçabilité permet d’attribuer rapidement la responsabilité d’une perte de flux.
Limites et perspectives
Le modèle repose sur un polling actif, ce qui génère un trafic constant (≈ 4 requêtes × 60 ≈ 240 requêtes /minute). Aucun mécanisme de push natif n’est exploité, limitant la réactivité en cas de panne brève entre deux intervalles. De plus, la dépendance à Cloudflare R2 implique un verrouillage fournisseur et une facturation liée au volume stocké, bien que le format JPEG XL minimise la taille des fichiers. Enfin, l’absence de métadonnées supplémentaires (ex. géolocalisation, conditions d’éclairage) restreint les usages analytiques futurs. Une évolution possible serait d’intégrer un protocole de diffusion en temps réel (WebRTC ou MQTT) afin de réduire la latence et le coût de bande passante, tout en conservant le même schéma de hachage et de stockage pour la traçabilité.
