Des caméras qui vérifient les procédures,
une vidéo qui reste en magasin.
Absar transforme la vidéosurveillance déjà en place d'une chaîne de cafés en contrôles en direct de ses procédures opérationnelles (SOP). Un petit boîtier NVIDIA Jetson installé dans le magasin observe les caméras et signale les écarts dès qu'ils surviennent : une charlotte oubliée, une boisson sans couvercle, du lait laissé dehors, une commande au drive remise sans ticket. Je suis responsable de la couche vision, c'est-à-dire de chaque contrôle qui tourne sur ce boîtier.
01La contrainte qui a tout façonné
La loi saoudienne sur les données personnelles (PDPL) traite la vidéo de personnes identifiables comme une donnée personnelle, et flouter les visages ne vaut pas anonymisation : un flou est une transformation, pas une garantie. Il n'y a donc aucun flux vidéo en direct qui sorte du magasin. Ni vers un GPU dans le cloud, ni vers un point d'accès régional.
Ce seul fait inverse la construction habituelle. Au lieu d'amener la vidéo vers le calcul, on amène le calcul dans le magasin. Ce qui sort, c'est la conclusion : un enregistrement d'événement, plus une image par alerte pour que le responsable voie ce qui s'est passé.
« Flouter un visage n'est pas de l'anonymisation. Une fois ce point acquis, le flux vidéo ne peut plus quitter le bâtiment, et toutes les autres décisions en découlent. »
02Ce qu'il surveille
Onze contrôles, chacun écrit à partir d'une procédure du registre SOP du client : tenue d'hygiène du personnel (charlotte, masque, gants), boissons laissées sans couvercle, lait sorti du réfrigérateur, bac à glace ou porte arrière laissés ouverts, barista qui fait mousser le lait sans regarder, et commandes au drive payées sans remise de ticket. Le boîtier compte aussi les passages à la porte et les voitures au drive.
Les alertes arrivent aux responsables sur un tableau de bord web, une application mobile et Telegram. Le premier boîtier de production gère 8 caméras à 16 images par seconde chacune, derrière 36 règles configurables.
03Ce que j'ai construit
J'ai écrit les onze services de contrôle et le worker GPU partagé qui les héberge, choisi et réentraîné les modèles, et validé les zones de détection de chaque caméra. Nous étions une équipe de quatre : d'autres ont construit le tableau de bord, l'application mobile et l'outillage de déploiement vers le boîtier.
Deux décisions que je mettrais en avant. D'abord, un benchmark qui a fixé l'architecture : faire tourner les modèles de contrôle sur le GPU du Jetson plutôt que sur son CPU était 17× plus rapide, mais chaque processus GPU coûte de la mémoire. Les contrôles partagent donc un seul worker GPU au lieu d'en avoir un chacun. Ensuite, la licence des modèles : j'ai basculé la détection sur des modèles sous licence permissive, parce que plusieurs choix évidents portent des clauses copyleft qui vous suivent jusque dans un produit commercial.
Volontairement peu de détails d'architecture ici. C'est un produit commercial en service, la conception reste à l'entreprise.
04Résultats
Chaque chiffre ci-dessous vient d'images de magasin réservées à l'évaluation ou du rejeu d'alertes réelles, jamais des données d'entraînement. La disponibilité en production et la latence caméra → téléphone sont en cours d'instrumentation, elles ne figurent donc pas encore ici.
Sur ce qu'un Jetson sait vraiment faire, et ne sait pas faire, une fois DeepStream et TensorRT dans la boucle : Ce qu'un boîtier à 250 $ sait vraiment faire.