Reconnaître l’objet filmé.> 


Recommendations

Objectif :

  • Reconnaître l’objet filmé.
  • Générer automatiquement des recommandations adaptées.
  • Effectuer un mapping direct vers des autoslides OdoLearn (sous-chapitres).

Contexte matériel :

  • Smartphone  à l’utilisateur.
  • fournir des  Lunettes connectées comme alternative.

Synthèse : 

  • 👉 Oui, c’est faisable aujourd’hui : WebRTC pour transporter, edge + cloud vision pour reconnaître, règles + RAG pour mapper vers vos autoslides OdoLearn, et retour instantané (WhatsApp ou AR)


Vue d’ensemble

1- Capture (smartphone / lunettes)
  •  Capture (smartphone / lunettes) → WebRTC en temps réel (vidéo + audio optionnel).
2-Transport
  •  Transport via STUN/TURN/SFU (selon réseau).



Conseil de souches 

  • : libwebrtc + Coturn (STUN/TURN). SFU : LiveKit / mediasoup (très pratique).

Code WebRTC 

3- Analyse des images/frames :


  • Edge/on-device (Vision/ML local) pour latence faible, ou
  • Cloud (API vision temps réel : OpenAI / Google / etc.) pour richesse de reconnaissance

Conseil de souches 

  • Edge : MediaPipe Tasks, ONNX Runtime Mobile, CoreML / Vision, TensorRT (lunettes Android/Jetson).
4- Interpréteur (règles + RAG)
  •  → mapping objet → slide_ref OdoLearn.

Conseil de souches

  • OpenAI (vision multimodale temps réel) pour compréhension riche,
  • Google Vertex AI (Gemini/vision) pour robustesse Google,
  • Apple : plutôt on-device (Vision/CoreML).

RAG

  • embeddings + pgvector/Qdrant ; index des slides Odoo.
5- Retour à l’utilisateur (WhatsApp, overlay AR, ou app)
  •  Retour à l’utilisateur (WhatsApp, overlay AR, ou app) + deep link vers le sous-chapitre.

UI de retour (exemples)

  • WhatsApp : bouton “Ouvrir le sous-chapitre” + “Autres options” (comme dans vos templates).
  • Lunettes : petit overlay (titre du slide + QR/URL courte) + commande vocale “ouvrir”.
PS/ Orchestration
  • .Conseil de souches 
    • Orchestration : Node.js/TypeScript (Express + ws) ou Python (FastAPI).

.

Architecture recommandée

Côté client (smartphone ou lunettes)

Grâce à notre API, les développeurs peuvent construire leurs solutions quatre fois plus vite. Découvrez comment et pourquoi.

Côté serveur

Probablement le seul CRM avec une expérience mobile complète. Vous ne vous êtes jamais demandé comment cela fonctionnait ? Tout simplement, parce que cela fonctionne

Équipe d'assistance

Notre équipe d'assistance met tout en œuvre pour vous répondre aussi rapidement que les assistants vocaux.

.

Latence & budget de bande passante (ordre de grandeur)

WebRTC HD :
  • WebRTC HD : 300–1500 kbps typique (réduire à 240–480p pour l’analyse).
Edge → cloud
  •  Edge → cloud (vignettes 320–512 px @ 1–2 fps) : 50–150 kbps suffisent.
Objectif latence E2E :
  • Objectif latence E2E : 300–800 ms (edge-assisté) ; 1–2 s (full cloud, réseau moyen). 

.

Mapping « vision → autoslides » (concret)

Détection (objets / texte / schémas)
  •  Détection (objets / texte / schémas) → ex. “panneau PV”, “onduleur hybride”, “borne MC4”, OCR d’une référence produit.
Normalisation (ontologie)
  •  Normalisation (ontologie) → category=pv_inverter; brand=Growatt; model=SPF 5000 ES.
Règles (rapides) :
  • Si category=pv_connector & issue=overheat → slide_ref = PV-SAFETY-MC4-02.


  • Si brand/model match → slide_ref = VENDOR-GROWATT-SPF5000-01.
RAG fallback :
  •  RAG fallback : requête sémantique avec le contexte (photo + texte) pour choisir le meilleur slide_ref.

Code “RAG fallback” multimodal (photo + texte) 

> Renvoi : deep link
  • Renvoi : deep link https://learn.ex.com/fr/slides/<slug>-<channel_id>?slide=<slide_id>.
.

.

Sécurité, conformité, vie privée

  • Consentement explicite (RGPD) + bannière “caméra active”.
  • Minimiser : envoyer crops/vignettes, pas le flux complet, si non nécessaire.
  • Chiffrement : WebRTC DTLS-SRTP ; possibilité d’E2EE via Insertable Streams.
  • Stockage : par défaut aucun enregistrement ; si enregistrement, chiffré + durée limitée.
  • Cas sensible (visages) : flou on-device avant envoi.

Limites & garde-fous

  • Réseau faible : basculer automatique en mode photo à la demande (prendre un cliché, pas de stream).
  • Confidentialité clients : masquage/blur on-device (plaques, visages).
  • Vision ambiguë : demande de précision côté utilisateur (“onduleur ou coffret DC ?”).
  • Accès Odoo privé : utiliser un proxy signé (/go/<token>) pour rediriger après authentification.

POC en 10 étapes (très concret)


  1. Signaling WebSocket + Coturn prêt.
  2. Client web : getUserMedia({ video: { width: 640, height: 360, frameRate: 15 } }).
  3. MediaStreamTrackProcessor → échantillonner 1–2 fps → ImageBitmap → JPEG 60–75%.
  4. Envoyez ces vignettes vers /vision/ingest (WebSocket) avec contexte texte de l’utilisateur.
  5. L’API vision renvoie {objects:[], ocr:[], caption: ""}.
  6. Normalisation (regex/ontologie/NER).
  7. Règles → tentative de slide_ref.
  8. Si ambigu → RAG top-k sur l’index OdoLearn.
  9. Résolution Odoo (slide_id, website_url).
  10. Retour (WhatsApp bouton + deep link) ou overlay AR (affichage dans lunettes)

En savoir plus