GOLDGUARD
L'intelligence de la bijouterie. En temps réel.
Un système de sécurité IA + matériel + vision par ordinateur qui transforme les surfaces d'exposition d'une bijouterie en zones pesées en continu, afin qu'une pièce qui quitte un plateau devienne un événement plutôt qu'une découverte à la fermeture.
GoldGuard est une plateforme d'intelligence d'inventaire physique et de prévention des pertes en temps réel pour les bijouteries. Quatre zones à cellules de charge sous une surface d'exposition alimentent un CAN delta-sigma 24 bits et un contrôleur ESP32-S3 ; le backend exécute une cascade de filtres DSP, une machine à états de stabilité, un classificateur d'événements et un moteur de corrélation inter-zones qui reconnaît les transferts internes sans perte. Les résultats sont diffusés via WebSocket vers un tableau de bord React avec rôles, liens de partage et rapport du matin.
Un sous-système de vision parallèle ajoute le suivi des personnes et des mains par caméra, la cellule de charge restant l'autorité de référence : une association erronée se dégrade en AMBIGUOUS, jamais en fausse alerte de vol. Le dépôt s'auto-audite quant à son propre état — la plateforme logicielle est fonctionnelle et couverte par une suite automatisée, la simulation est vérifiée, le firmware compile pour ESP32-S3, et la validation physique est explicitement en attente du matériel.
Vue d'ensemble
L'or lui-même est le bouclier. GoldGuard transforme chaque gramme d'une vitrine en données — pesé en continu, classé en événements métier, corrélé entre les zones et livré au magasin en temps réel.
Problème
La perte en bijouterie se découvre à la fermeture, quand un comptage ne tombe pas juste et que personne ne peut dire quel plateau, quelle heure ni quelle main. Les caméras enregistrent tout et n'expliquent rien. Une balance sous un seul plateau vous donne un poids, pas un événement.
“Une pièce qui quitte un plateau devient un événement — ITEM_REMOVED, ITEM_ADDED, INTERNAL_TRANSFER, TRAY_REMOVED, TAMPER_EVENT — plutôt qu'une découverte à la fermeture.”
Système
La couche 1 est celle des transducteurs : quatre cellules de charge à jauge de contrainte monopoint de 5 kg par zone, un capteur de température TMP117 et un accéléromètre LIS2DW12 pour les vibrations et la détection de sabotage. La couche 2 est le firmware embarqué ESP32-S3, qui échantillonne à 10–80 Hz par canal avec un DSP sur l'appareil et une machine à états de stabilité. La couche 3 est un backend en architecture propre — domaine, application, infrastructure, API — avec Express, un hub ws et PostgreSQL derrière un contrat de dépôt avec repli en mémoire.
Le pipeline de pesée est une cascade rejet des valeurs aberrantes → médiane glissante → EMA → moyenne mobile, puis compensation de dérive, puis un moteur de stabilité statistique et un classificateur d'événements. Un moteur de corrélation inter-zones fait correspondre ΣΔW ≈ 0 entre les zones dans une fenêtre de 1,5 s pour reconnaître une pièce déplacée d'un plateau à un autre comme un transfert interne, et non comme une perte.
Architecture
- CELLULES DE CHARGE ×45 kg / zone
- CAN 24 BITS ADS1234gain 128
- FIRMWARE ESP32-S3DSP · FSM · file d'attente hors ligne
- INGESTION STORE-AND-FORWARDgarde de séquence
- MOTEUR DE PESÉEfiltres · dérive · stabilité · classificateur
- CORRÉLATION INTER-ZONESΣΔW ≈ 0 en 1,5 s
- FUSION VISIONidentité portée par la main · cellules faisant autorité
- POSTGRESQL27 tables · migrations
- HUB WEBSOCKETprotégé par jeton
- TABLEAU DE BORD · BUREAU · PORTAILReact · Tauri · Cloudflare
Surface du dépôt
- 01backend — API Express, hub ws, moteurs, migrations, 36 fichiers de tests
- 02frontend/goldguard-dashboard — React 19 + Vite, 23+ vues, arabe / hébreu / anglais
- 03apps/marketing — export statique Next.js, récit produit three.js piloté par le défilement, 5 langues
- 04apps/desktop — coquille Tauri 2 avec workflows de publication Windows et macOS
- 05apps/twin-studio + simulator/goldguard-twin — jumeau numérique visuel et headless
- 06services/goldguard-vision + goldguard-vision-runtime — domaine de vision en TS pur et runtime ONNX
- 07services/goldguard-vision/ml — entraînement PyTorch, évaluation, export ONNX
- 08firmware/goldguard-controller — C++ ESP-IDF pour ESP32-S3
- 09hardware/cad/fusion360 — scripts Fusion 360 paramétriques ; géométrie exportée vers le web
IA & Vision
L'architecture de vision part d'une contrainte mesurée plutôt que d'une liste de souhaits : sur des images de boutique en 3840×2160, une bague sur le plateau a une empreinte médiane de 28 px et, après le redimensionnement à 800 px du détecteur, elle ne fait plus que 5,8 px face à une plus petite ancre de 32 px. L'inférence sur l'image entière a trouvé 0 bague là où 32 tuiles natives en ont trouvé 7. La conception fait donc tourner deux flux — personnes et mains sur une image réduite à 10 Hz, recensement des plateaux sur des tuiles en résolution native conditionné par la présence d'une main — et laisse une pièce hériter de l'identité de la main qui l'a portée.
“L'identité continue individuelle d'environ 50 bagues statiques, en contact et quasi identiques est une dégénérescence du problème, pas une limite de qualité du modèle. Suivez la main ; laissez la pièce hériter de l'identité de son porteur.”
Design
L'or lui-même est le bouclier.
Deux faces d'or opposées forment un bouclier, avec un lingot sur une plateforme de pesée en son cœur sombre. Géométrie droite uniquement, lisible d'un panneau d'affichage jusqu'à un favicon de 16 px. Le cyan capteur est réservé à la mesure en direct dans le tableau de bord et délibérément tenu à l'écart du logo.
- —GOLD en #F5F7FA, GUARD dans le dégradé or
- —Inter ExtraBold, interlettrage 2,5
- —Version compacte pour 16–31 px, version mono pour la gravure
Défis
- 01Un premier réglage des filtres annulait les variations de poids réelles en les prenant pour des valeurs aberrantes — un retrait de 8 g produisait 0 événement. Corrigé le 2026-08-23 ; le même retrait produit désormais exactement un ITEM_REMOVED avec Δ −8,05 g.
- 02La v1.0.0-rc affichait 67/67 au vert alors que le chemin PostgreSQL était cassé : des tests verts qui ne touchent jamais le chemin de production ne prouvent rien à son sujet. La suite sur Postgres réel fait désormais partie de la CI.
- 03Le produit s'est brièvement scindé en deux arborescences avec 44 fichiers en conflit et six conflits sémantiques qu'aucun outil de fusion ne signalerait. Un plan de fusion écrit et un audit d'architecture précèdent la fusion.
- 04Aucune cellule de charge n'a encore été connectée. Chaque valeur de masse, de bruit et de latence du dépôt est étiquetée comme cible de conception, pas comme mesure.
Résultats
Le client reçoit un portail de suivi permanent, sans tunnel, sur Cloudflare Workers — pourcentage, plan sur cinq semaines, ce qui a été accompli et ce qui vient ensuite — tandis que les mesures en direct et la console opérationnelle ne l'atteignent jamais.