D.E.B.O. : Un agent vocal à qui confier son magasin

D.E.B.O. (Data Enhanced Business Operator) est un agent vocal pour un rayon de magasin. Dites ce que vous voulez vérifier ou changer, et il vous répond, puis le fait vraiment : récupère un instantané caméra et signale ce qui ne va pas, fait clignoter l'étiquette électronique à côté d'un produit, met à jour un prix, ou affiche un plan du magasin sur un second écran pour un client.

Il tourne sur une démo de coin retail que j'ai construite pendant mon stage chez Tata Consultancy Services, comme un élément d'une plateforme plus large qui intègre aussi des capteurs RFID et VOC pour le suivi des stocks et de la fraîcheur. Cette page couvre l'agent vocal lui-même et ShelfWatch, le système de vision qui lui donne des yeux.

Un employé de magasin qui vérifie un rayon touche trois ou quatre systèmes distincts : un flux caméra pour le voir, une console de gestion ESL pour corriger un prix, un tableur de planogramme pour savoir ce qui devrait s'y trouver, et une radio pour dire à quelqu'un où se trouvent les balles en mousse. Aucun de ces systèmes ne communique avec les autres.

Corriger une étiquette mal tarifée signifie un détour par un outil back-office conçu pour le personnel d'entrepôt, pas pour quelqu'un debout dans l'allée. D.E.B.O. réduit ce détour à une phrase.

Deux processus tournent en parallèle : une application Next.js 16 pour l'interface, et un serveur vocal FastAPI qui communique via WebSocket. Parlez dans le navigateur, et l'audio est diffusé vers le serveur en PCM brut. faster-whisper le transcrit.

La plupart des commandes de rayon — « fais clignoter ipuro », « vérifie les caméras », « change le prix à 5,99 » — correspondent à un motif regex et s'exécutent immédiatement, sans passer du tout par le modèle de langage. Tout le reste part vers Gemma 4 via Ollama, exécuté localement avec un petit registre d'outils. Kokoro transforme la réponse en voix et la diffuse phrase par phrase.

Ce chemin rapide existe pour deux raisons. Les modèles de langage refusent parfois de « prendre des actions physiques » quand on le leur demande directement, et même un modèle coopératif ajoute un aller-retour complet de latence à une tâche qui devrait sembler instantanée. Faire correspondre la commande en premier signifie qu'une étiquette ESL clignote en moins d'une seconde.

ShelfWatch est la pièce qui permet à D.E.B.O. de voir le rayon. Dites « vérifie les caméras », et il récupère un instantané en direct depuis une caméra IP Axis (l'authentification digest est gérée dans une route proxy, car la caméra ne facilite pas la chose), l'affiche dans le panneau de discussion, et le passe dans le mode vision de Gemma 4 par rapport à un planogramme fixe : deux boîtes d'Ipuro Lavender Touch, un flacon de dissolvant à ongles Lakme.

L'appel de vision s'exécute sur un thread en arrière-plan, si bien que le flux caméra et un état de chargement apparaissent immédiatement au lieu de figer l'interface pendant l'inférence. Il renvoie l'un de quatre états : LOW_STOCK, STOCKOUT, FALLEN_OBJECT, ou SHELF_NOT_VISIBLE si la caméra ne voit aucun rayon valide. Un rayon en ordre reçoit une simple bannière « aucune alerte » plutôt qu'un mur de coches.

Les étiquettes électroniques du coin retail tournent sur une plateforme fournisseur sans documentation d'API publique. Pour que D.E.B.O. puisse faire clignoter une étiquette ou pousser un prix, il a fallu ouvrir la console web du fournisseur lui-même, observer son trafic réseau, et éplucher les DevTools jusqu'à ce que les points d'accès non documentés et leur flux d'authentification soient assez clairs pour être appelés directement.

C'est cette API rétro-conçue à laquelle les outils d'étiquette et de tarification de l'agent parlent réellement, sous la conversation.

Tous les changements de prix ne devraient pas se produire à l'instant où quelqu'un le demande. Le flux de conformité détecte une incohérence, puis fait dire oui à un humain avant que quoi que ce soit ne touche à l'étiquette.

Demandez « mes étiquettes sont-elles conformes ? » et D.E.B.O. affiche une image de référence de l'étiquette, signale que le dissolvant à ongles est mal tarifé, et demande s'il faut corriger. Dites oui, et il corrige l'étiquette via la même API. Dites non, et il laisse le rayon tranquille.

Les utilisateurs avancés peuvent passer directement à une commande directe, comme « change le prix de ipuro à 15,99 », qui ne met à jour que le champ prix, jamais le nom du produit ni aucune autre donnée de l'étiquette. La distinction repose sur la certitude : exécution directe quand la demande est sans ambiguïté, et un point de contrôle partout ailleurs.

Un écran séparé destiné aux clients écoute sur son propre canal WebSocket. Demandez où sont les balles en mousse, et D.E.B.O. répond à voix haute sur l'écran principal tout en diffusant un plan sur le second, pour qu'un client obtienne une réponse visuelle sans que l'employé ne lui tende son téléphone ou ne marche jusqu'à l'allée lui-même.

La séparation entre chemin rapide et chemin LLM fonctionne pour une démo avec deux produits et une poignée de formulations. Elle cesse de fonctionner dès qu'un vrai magasin ajoute mille SKU et cent façons de les demander : plus de correspondances d'alias, plus de formulations pour le même changement de prix, un planogramme qui doit venir d'une base de données plutôt que de deux noms de produits codés en dur dans un fichier Python.

Les alertes de vision sont mieux traitées comme une invitation à aller vérifier que comme un verdict. Un rayon obstrué ou une présentation promotionnelle peuvent encore les tromper, ce qui justifie de garder un humain dans le flux de changement de prix plutôt que de laisser le modèle agir seul.

La solution au problème d'échelle est la même séparation que la démo utilise déjà pour la voix, remontée d'un niveau : chemin rapide pour ce qu'on peut définir, modèle pour ce qu'on ne peut pas.

La conformité au planogramme est un problème à ensemble fermé. Les SKU sont connus, la disposition des emplacements est connue, et la seule question est de savoir si la bonne boîte est au bon endroit. Un détecteur YOLOv8 affiné répond à cela en 20 à 40 millisecondes sur un Jetson Orin posé dans l'arrière-boutique, à un coût par image qui rend son exécution continue raisonnable plutôt que quelque chose qu'on déclenche à la main.

Le modèle vision-langage justifie sa place sur les questions qui n'ont pas d'ensemble de réponses fixe. Un client demandant où sont les pâtes sans gluten. Un employé qui photographie une tête de gondole abîmée et demande ce qui ne va pas. Cela ne peut pas être énuméré à l'avance, ce qui est le véritable test pour savoir si une tâche relève d'un modèle ou d'un détecteur.

Qwen2.5-VL-7B utilise une attention par fenêtre dans son encodeur visuel, si bien que le calcul augmente linéairement avec le nombre de patchs d'image plutôt que quadratiquement. C'est la propriété précise qui rend une inférence sous 200 ms sur un seul GPU local plausible plutôt qu'aspirationnelle. Il devance aussi les modèles open source sur les benchmarks à forte composante OCR, ce qui n'est pas un argument de qualité générale, c'est exactement la capacité dont ce système a besoin, puisque presque chaque tâche de vision ici se termine par la lecture d'une étiquette de rayon, d'un prix, ou d'un panneau directionnel.

InternVL2.5-8B et LLaVA-1.6-7B sont compétitifs sur le VQA général et prennent du retard sur l'OCR sous quantification. Florence-2 est plus rapide qu'eux tous et trop faible en raisonnement ouvert pour porter une conversation d'orientation.