Mon condo a été inondé deux fois en sept mois. Dans mon test, la caméra Ring a vu l'eau et n'a rien enregistré, alors j'ai bâti l'application qui la force à enregistrer.

Deux inondations, et deux vidéos au téléphone

Mon condo a été inondé le 5 décembre 2025, à cause d'un tuyau d'évacuation mal incliné et d'une fuite de toilette. J'ai rebâti. Le 20 juin 2026, une semaine après la fin des réparations, l'égout municipal a refoulé dans plus de 60 unités, et chez moi l'eau est aussi entrée par les fondations, par des interstices à côté du panneau électrique et par une fenêtre du sous-sol. Le rapport de la compagnie d'assèchement a parlé de fortes pluies, et a évoqué ma remise de cour arrière comme cause. La seule raison pour laquelle ça n'a pas tenu, c'est deux vidéos que j'ai prises au téléphone pendant que ça arrivait, parce que je me trouvais à la maison. Que l'eau vienne d'un refoulement d'égout ou d'eau de pluie propre décidait quelle limite de couverture s'appliquait. La prochaine fois, je ne serai pas là.

Ring le sait déjà. Il n'enregistre juste pas.

Un capteur Ring Flood & Freeze avertit votre téléphone qu'il y a de l'eau. Ce qu'il ne fait pas, c'est forcer une caméra à l'enregistrer. Je l'ai testé avec mes vrais appareils : mon capteur dans un bol, mon Indoor Cam pointée dessus, l'eau versée lentement. L'application Ring a alerté à 20 h 35. Son propre historique d'événements ne montre rien après 20 h 27, et toujours rien à 20 h 38. De l'eau qui monte lentement ne déclenche pas la détection de mouvement, alors la seule caméra qui l'a vue n'a rien gardé. C'est le trou que Watermark comble : quand le capteur se déclenche, il ouvre une session en direct sur la caméra qui voit déjà la pièce, ce qui la force à enregistrer, et continue de tirer des images avec l'heure de Ring jusqu'à ce que le capteur indique sec.

Les images de Ring, avec l'heure de Ring

Chaque image d'un dossier vient d'une session en direct de la Ring Partner API, téléchargée avec le X-Media-Timestamp de Ring incrusté, et toute image à plus de la tolérance documentée de 10 s de la demande est signalée. Mesuré sur le Developer Playground de Ring avec la vraie API, la première image est arrivée 6,85 s après l'événement du capteur, médiane de 10 essais, de 6,6 à 11,2 s. La caméra de ces essais est la sonnette du Playground, ce qui explique pourquoi les images de démo montrent une mangeoire d'oiseaux dans la neige plutôt qu'un sous-sol. Les webhooks sont écrits sur disque avant toute autre chose, parce que Ring ne garde aucun historique des événements de capteur, et une boucle de réconciliation interroge l'état pour qu'un webhook manqué ne puisse ni démarrer ni arrêter une capture en silence.

Amazon Rekognition étiquette ce qu'il y a dans chaque image légendée, et la question sur le plancher dans le dossier cite le matériau qu'il nomme. Je l'ai d'abord testé sur mes propres images de l'inondation de juin : il étiquette une pellicule d'eau sur du bois franc exactement comme le plancher sec. Dans Watermark, il peut donc ajouter « eau visible » mais jamais « pas d'eau », et le capteur reste la preuve de l'humidité. J'avais conçu des légendes en prose pour Amazon Bedrock et le code est toujours là, mais Bedrock est bloqué sur mon compte dans toutes les régions que j'ai essayées.

Le dossier, face aux questions de mon expert en sinistres

Ce qui en sort, c'est un seul dossier de preuves qu'un propriétaire peut imprimer ou envoyer : la chronologie, les images, l'état des appareils, et une section d'intégrité qui liste chaque trou qu'il n'a pas pu vérifier. Ensuite, il se compare aux 7 questions que mon expert en sinistres a réellement posées sur ma réclamation de juin. Sur un des 10 essais (première image en 6,9 s), il répond à 2 : quand l'eau a commencé et combien de temps elle est restée, et où elle était, ce qui correspond aux images qui auraient tranché entre refoulement d'égout et eau de pluie. Il répond en partie à 2 autres, le plancher et les biens, où les images montrent ce qui était là mais où le propriétaire ajoute le reste. Les 3 autres portent sur la maison et la police, et c'est à moi d'y répondre.

Il refuse de nommer une cause

La cause, c'est ce que le rapport d'assèchement s'est trompé à dire, alors Watermark n'en avance jamais. La section « What this record cannot vouch for » du dossier vient avant la correspondance avec la réclamation : les étiquettes d'images décrivent ce qui est visible et ne sont pas des mesures, l'événement de capteur de ces essais est simulé, les événements appris par interrogation plutôt que par webhook sont marqués, et les périodes où la caméra est hors ligne sont signalées comme des trous. Un script, check_claims.py, fait échouer la compilation si un chiffre de la documentation ne concorde pas avec les essais enregistrés.

ringwire, et une demande de tirage à l'exemple d'Amazon

Pour le défi Open Source, j'ai sorti le client Ring de Watermark et je l'ai publié sous le nom ringwire, un client Python typé pour la Ring Partner API conçu autour de la portée Early Access des capteurs : état des capteurs avec inondation, gel, contact et sabotage, webhooks de capteur avec vérification HMAC, lecture sur le carillon, sessions en direct WHEP, téléchargements de médias en deux étapes et nonce de liaison de compte. Il code trois pièges de la documentation des capteurs de Ring pour qu'on ne puisse pas y tomber : l'époque 1970 jamais signalée devient None, le sabotage se lit « detected » plutôt que « faulted », et l'état de signalement n'est jamais traité comme un signe de vie. J'ai aussi ouvert une demande de tirage dans ring-api-helloworld d'Amazon qui ajoute sensor_status.py, le premier script de l'exemple qui lit un capteur. Chacun des 10 essais mesurés est passé par ringwire.

Ce qui n'est pas revendiqué

Le minutage est corrigé par les horodatages de Ring lui-même et l'ablation par l'historique de l'application Ring elle-même, pas par mon code, mais la portée est étroite. Les 10 essais mesurés ont utilisé un événement de capteur simulé et la sonnette du Playground, pas un sous-sol inondé; le test du bol a utilisé mon vrai capteur et ma vraie caméra, mais c'était un test contrôlé, identifié comme tel, avec de l'eau versée lentement. La correspondance avec la réclamation est notée sur les questions d'une seule réclamation, la mienne. Le robot imprimé qui porterait la caméra jusqu'à une pièce qu'aucune caméra fixe ne couvre a son code et sa répartition AWS IoT Core dans le dépôt (un événement d'inondation l'a atteint par IoT Core et il s'est signalé en position 7,7 s après le capteur, avec la conduite simulée), mais il n'a pas roulé sur un vrai plancher, alors il n'est pas dans la démo. La lecture sur le carillon fonctionne par l'API, mais le Playground n'a pas de carillon, alors la démo ne la montre pas. Et Watermark ne dit jamais ce qui a causé l'eau; ça reste à l'expert en sinistres.