Comment développer un logiciel sur mesure pour Rokid AI Glasses Enterprise

Synthèse

Rokid AI Glasses Enterprise peut devenir un appareil professionnel conçu sur mesure, plutôt que d'être utilisé uniquement avec des applications préconfigurées. La documentation actuelle de Rokid Sprite Enterprise met à disposition un SDK Glasses pour les applications exécutées directement sur Glass3, un SDK Phone pour les applications compagnons Android et des services OpenAPI pour les intégrations côté cloud. Ensemble, ces couches prennent en charge la connectivité de l'appareil, la messagerie, le transfert de fichiers, la caméra et la capture multimédia, la vidéo en direct, les fonctions vocales, les services d'IA, la reconnaissance, l'état de l'appareil et les workflows d'entreprise.

Pour une équipe de développement, la démarche concrète est familière : créer des projets Android natifs dans Android Studio, ajouter le dépôt Maven et les dépendances SDK de Rokid, exécuter la démo officielle de Rokid composée de deux projets, établir une connexion Bluetooth pour la découverte et le contrôle, passer au Wi-Fi P2P pour les fichiers volumineux et l'audio/vidéo, puis connecter le workflow au back-end de l'entreprise. Une application autonome sur les lunettes est également possible lorsque le cas d'usage ne nécessite pas de téléphone compagnon.

Au-delà du SDK, la valeur principale vient du remplacement d'une expérience wearable générique par un workflow maîtrisé. Un technicien peut recevoir un ordre de travail, voir l'instruction suivante sur l'écran, valider une étape par la voix ou via une commande matérielle, capturer des preuves visuelles et envoyer le résultat vers une GMAO, un ERP ou une plateforme sur mesure. Les lunettes deviennent ainsi pertinentes pour les inspections, l'intervention terrain, le travail guidé, la logistique, la documentation et d'autres processus mains libres. Les principales réserves concernent la prise en charge du SDK natif limitée à Android, la compatibilité des versions et des mises à jour OTA, l'exigence d'une clé API pour certains services en ligne, et un écran compact de 480 x 640 qui impose une conception d'interface réfléchie.

Ce que Rokid met à la disposition des développeurs

Rokid divise sa pile entreprise en un SDK à deux volets, complété par une plateforme OpenAPI distincte. Comprendre cette répartition avant d'écrire du code évite une erreur courante : vouloir tout faire faire aux lunettes alors qu'un téléphone ou un back-end est mieux adapté à la mise en réseau, à l'authentification, au stockage ou à l'intégration avec les systèmes métier.

Application sur les lunettes :

• S'exécute sur : Rokid Glass3
• Rôle type : Affiche l'interface sur les lunettes et accède aux fonctionnalités côté lunettes, telles que caméra/multimédia, état de l'appareil, messages, voix, IA et reconnaissance, via le SDK Glasses.

Application compagnon :

• S'exécute sur : Téléphone Android
• Rôle type : Découvre Glass3 et s'y connecte, gère le Bluetooth et le Wi-Fi P2P, échange des messages et des fichiers, reçoit les flux multimédias et peut relayer les données métier.

Couche cloud / métier :

• S'exécute sur : Votre back-end + Rokid OpenAPI le cas échéant
• Rôle type : Stocke les données métier, authentifie les utilisateurs, connecte les systèmes ERP/GMAO/CRM et peut utiliser des modules Rokid OpenAPI, tels que la messagerie ou les API d'appareils, lorsqu'ils sont provisionnés.

Verdict pratique : Pour un logiciel d'entreprise sur mesure, l'architecture la plus utile est généralement « interface légère sur les lunettes + services d'appareil fiables + logique métier sur le téléphone/back-end ». Garder une expérience ciblée sur les lunettes réduit la complexité de l'interface et facilite la maintenance du projet, tout en préservant l'interaction mains libres là où elle compte.

La pile de développement en un coup d'œil

• Matériel cible dans la documentation entreprise publique : Rokid Glass3
• Modèle de développement : Développement d'applications Android natives
• Artefact du SDK Glasses : com.rokid.security:glass3.open.sdk
• Artefact du SDK Phone : com.rokid.security:phone.sdk
• Dépendance indiquée dans le Quick Start actuel : 2.2.0-E pour les deux SDK
• Entrée la plus récente visible dans le changelog au moment de nos recherches : V2.2.0-E, datée du 6 août 2026, avec l'OTA 1.19.e006-20260806-150201 ou ultérieure recommandée.
• Outils recommandés : Android Studio 2022+, JDK 17+
• Environnement de démo : Android SDK 34, JDK 17, téléphone Android, Rokid Glass3
• Système de coordonnées de l'écran des lunettes : 480 x 640 fixe, en portrait
• Principaux transports locaux : Bluetooth classique et Wi-Fi P2P
• Authentification cloud : Clé API entreprise pour Rokid OpenAPI et certains services en ligne
• Plateforme téléphone prise en charge : Android ; la FAQ publique indique qu'iOS et HarmonyOS natif ne sont pas pris en charge par le SDK Glass3

Que pouvez-vous créer avec Rokid AI Glasses Enterprise ?

Le SDK public est suffisamment riche pour aller au-delà d'une simple application de démonstration. Le produit que vous développerez dépend précisément des fonctionnalités que vous combinez et de la part de logique que vous conservez sur les lunettes.

Intervention terrain guidée : afficher une instruction à la fois, confirmer la réalisation, capturer des photos ou des vidéos et renvoyer des preuves structurées vers un système de gestion des ordres de travail.

Inspection et conformité : présenter des checklists, utiliser la capture caméra ou la reconnaissance, joindre des preuves horodatées et faire remonter les anomalies.

Workflows d'entrepôt et de logistique : afficher les informations de préparation ou de tâche, échanger des commandes légères via Bluetooth et utiliser des intégrations de scan spécialisées si nécessaire.

Assistance visuelle à distance : recevoir un flux vidéo en direct côté compagnon ou intégrer une solution dédiée de collaboration à distance. Rokid a retiré les appels RTC du SDK Phone de base dans la version 2.1.7-E ; la collaboration en temps réel doit donc être conçue autour d'Android et du Web : le Remote Collaboration SDK de Rokid ou votre propre transport approuvé, plutôt que de supposer qu'elle est intégrée au SDK de base.

Assistant IA d'entreprise : combiner saisie vocale, TTS, chat IA ou services d'IA propres à l'entreprise avec une interface adaptée au workflow, au lieu de confronter les utilisateurs à un chatbot générique.

Capture de preuves et documentation : déclencher des images, de la vidéo ou de l'audio, transférer les médias volumineux via P2P et synchroniser les résultats avec un back-end.

Appareil portable dédié à une seule fonction : lancer automatiquement l'application de l'entreprise après un redémarrage et associer les événements matériels pris en charge à des actions du workflow, sous réserve de validation sur le firmware cible.

Étape par étape : comment développer un logiciel sur mesure pour Rokid AI Glasses Enterprise

Étape 1 : définir le workflow avant de choisir l'architecture

Partez du processus opérationnel, pas de la liste des SDK. Notez précisément ce que l'opérateur doit voir, dire, capturer et confirmer. Décidez ensuite quel appareil doit prendre en charge chaque responsabilité. Une application pour lunettes bien cadrée affiche généralement des informations concises et recueille les saisies, tandis que le téléphone ou le back-end gère la logique métier plus lourde.

Application autonome sur les lunettes :

• Idéal pour : Workflow local simple, capture côté appareil, fonctionnement hors ligne ou avec une connectivité limitée
• Avantages : Moins de composants, expérience directe sur les lunettes
• Contrepartie : Vous devez gérer davantage de logique de stockage/réseau sur les lunettes ; certaines fonctions en ligne nécessitent toujours des identifiants ou une connexion

Lunettes + téléphone Android :

• Idéal pour : La plupart des pilotes en entreprise, médias en direct, transfert de fichiers, contrôle à distance, compagnon d'application métier
• Avantages : Voie de connectivité la mieux documentée ; le téléphone peut gérer l'authentification, la mise en réseau et l'interface qui n'ont pas leur place dans le verre
• Contrepartie : Nécessite un téléphone Android et une logique de reconnexion robuste

Lunettes + téléphone + back-end :

• Idéal pour : Intégration ERP/GMAO/CRM, piste d'audit, ordres de travail gérés de manière centralisée, services d'IA
• Avantages : Solution la mieux adaptée aux workflows métier évolutifs et à la gouvernance des données
• Contrepartie : Davantage d'intégration, de sécurité et d'ingénierie back-end nécessaires

Recommandation : Pour une première preuve de concept B2B, utilisez le modèle lunettes + téléphone Android + back-end, sauf si le cas d'usage tire clairement profit de lunettes autonomes. Ce modèle correspond étroitement au flux à deux appareils documenté par Rokid et laisse à l'équipe de développement la latitude de déporter la mise en réseau, les identifiants et le stockage des données hors des lunettes.

Étape 2 : se procurer le bon matériel et les bons accès

Avant d'installer Android Studio, vérifiez que le matériel est bien sur la branche logicielle entreprise. La FAQ de Rokid indique que les versions entreprise/professionnelles contiennent généralement un « e » dans la version système. La documentation du SDK distingue également les systèmes entreprise et grand public : l'identification du firmware fait donc partie de la mise en place du projet et ne doit pas venir après coup.

Rokid AI Glasses Enterprise (le matériel Rokid Glasses) avec la version système / le firmware entreprise (version système se terminant par « e »).

Le câble de débogage de données Glass3. Rokid précise explicitement que le câble de charge standard peut alimenter les lunettes, mais ne peut pas être utilisé par Android Studio pour le débogage.

Un téléphone Android si vous utilisez le SDK Phone.

Un PC de développement avec Android Studio et JDK 17.

Un compte entreprise et une clé API si le projet doit utiliser Rokid OpenAPI ou des fonctionnalités en ligne nécessitant une authentification.

L'accès à la version OTA exacte que vous prévoyez de déployer sur l'ensemble de la flotte pilote.

Ne négligez pas la vérification du câble : Rokid indique que le câble de débogage de données est indispensable, car il permet à Android Studio de reconnaître les lunettes, d'installer des APK et de consulter les logs. Si les lunettes se chargent mais n'apparaissent pas comme appareil, vérifiez le câble avant de déboguer Gradle, ADB ou le SDK.

Étape 3 : préparer l'environnement de développement Android

Le Quick Start de Rokid recommande Android Studio 2022 ou ultérieur et JDK 17 ou ultérieur, et indique que le SDK Glass3 prend en charge Android 8.0 ou ultérieur. Le guide officiel de la démo utilise actuellement Android SDK 34. La FAQ de Rokid recommande par ailleurs Android 7.0 / API 24 ou ultérieur et invite à vérifier la configuration Gradle dans le package SDK et la démo actuels. Pour un projet réel, considérez les fichiers Gradle de la démo comme la référence pour la version exacte que vous intégrez.

1. Installez Android Studio 2022 ou une version plus récente.

1. Installez JDK 17 ou une version plus récente et sélectionnez-le pour Gradle.

1. Installez la version d'Android SDK requise par la démo Rokid actuelle. Le guide de démo actuel indique SDK 34.

1. Activez le débogage Android standard sur le téléphone de développement.

1. Connectez Glass3 à l'aide du câble de débogage de données et vérifiez qu'Android Studio détecte une cible du type « Rokid RG-glasses ».

1. Installez l'outil de projection / duplication d'écran de Rokid si vous souhaitez visualiser l'interface des lunettes depuis le PC. Rokid recommande vivement la projection pendant le développement.

Étape 4 : exécuter la démo officielle de Rokid avant de créer votre propre application

C'est l'étape pratique la plus importante de tout le processus. La démo officielle valide l'environnement de développement, les binaires du SDK, les autorisations, les liaisons matérielles et la combinaison de versions avant que votre propre code ne vienne ajouter une variable supplémentaire.

git clone https://gitee.com/as_pixar/glass3sdkdemo.git

# Démo lunettes
cd glassdemo
./gradlew assembleDebug

# Démo téléphone
cd ../glass3sdkphonedemo
./gradlew assembleDebug

Le dépôt contient deux projets Android distincts : l'un pour les lunettes, l'autre pour le téléphone Android. Rokid recommande d'exécuter d'abord la démo côté téléphone, puis la démo côté lunettes. Une fois les deux installées, recherchez Glass3 depuis la démo téléphone et établissez la connexion.

1. Initialisation du SDK. Critère de réussite : les deux projets démarrent et signalent un état du SDK valide.
2. Bluetooth. Critère de réussite : le téléphone trouve Glass3 et s'y connecte.
3. Messagerie. Critère de réussite : des messages texte ou de contrôle peuvent circuler entre le téléphone et les lunettes.
4. Transfert de petits fichiers. Critère de réussite : un petit fichier peut être échangé sans erreur.
5. Wi-Fi P2P. Critère de réussite : un canal P2P peut être établi pour les opérations à haut débit.
6. Médias. Critère de réussite : une photo, une vidéo ou un aperçu en direct peut être déclenché et reçu.

Pourquoi c'est important d'un point de vue commercial : Une preuve de concept client est beaucoup plus facile à cadrer lorsque les fonctions de base de l'appareil sont validées en amont. Vous pouvez alors consacrer le temps du projet au workflow lui-même, à l'intégration et à l'expérience utilisateur, plutôt qu'à diagnostiquer une configuration SDK non vérifiée.

Étape 5 : créer vos propres projets et ajouter le dépôt Maven de Rokid

Une fois la démo fonctionnelle, créez ou ouvrez vos propres projets Android. Rokid publie les artefacts du SDK via son dépôt Maven. Ajoutez ce dépôt à côté de Google et Maven Central, puis ajoutez la dépendance lunettes à l'application des lunettes et la dépendance téléphone à l'application compagnon.

// settings.gradle - exemple simplifié
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://maven.rokid.com/repository/maven-public/' }
    }
}

// Application lunettes
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

// Application téléphone Android
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
    exclude group: "org.slf4j"
}

Le Quick Start actuel de Rokid indique la version 2.2.0-E, avec une OTA recommandée 1.19.e006-20260806-150201 ou ultérieure. Les équipes en entreprise doivent figer et tester une combinaison SDK + OTA connue, plutôt que de mettre à jour automatiquement chaque composant indépendamment.

Règle de gestion des versions : Avant un pilote ou une mise en production, consignez dans une seule matrice de compatibilité la build OTA des lunettes, la version du SDK Glasses, la version du SDK Phone, le commit de la démo et les versions des éventuels SDK spécialisés. Relancez les tests de base de connexion et de médias dès que l'un de ces composants change.

Étape 6 : ne déclarer que les autorisations Android nécessaires à votre workflow

Le Quick Start de Rokid liste les autorisations courantes pour l'accès réseau, le Wi-Fi, la caméra, le micro, le stockage, le Bluetooth et les appareils à proximité. Sur les versions récentes d'Android, déclarer une autorisation dans le manifeste ne suffit pas pour les autorisations dangereuses. Vos applications téléphone et lunettes doivent demander les autorisations requises à l'exécution et gérer proprement les refus.

• Recherche/connexion Bluetooth : Découverte des appareils, appairage, petits messages et contrôle
• Wi-Fi à proximité / Wi-Fi Direct : Connexion P2P pour les fichiers, images, vidéos et flux en temps réel
• Caméra : Capture photo/vidéo et flux de reconnaissance visuelle
• Micro : Enregistrement audio, ASR et interaction vocale
• Réseau / Internet : API back-end, services en ligne Rokid, synchronisation cloud
• Stockage : Gestion des médias et des fichiers transférés, selon le comportement de la version d'Android / du SDK cible

Conseil pour la production : Ne copiez pas aveuglément l'intégralité du manifeste de la démo. Réduire les autorisations au minimum facilite l'audit de sécurité et diminue le risque que les utilisateurs refusent une autorisation dont le workflow n'a en réalité pas besoin.

Étape 7 : initialiser le SDK Glasses et enregistrer l'identité de votre application

L'application des lunettes se lie au service de sécurité de Rokid, puis enregistre un identifiant client. La règle d'architecture essentielle est que ce même identifiant client doit être connu de l'application compagnon sur le téléphone lorsque les deux côtés échangent des messages propres à l'application.

// Structure illustrative, simplifiée à partir du flux d'initialisation de Rokid
if (!GlassSdk.isReady()) {
    GlassSdk.bindSecurityService(context, object : IServiceConnectionCallback {
        override fun onServiceConnected() {
            GlassSdk.registerClient("FieldServiceApp", messageCallback)
        }
    })
}

Après l'initialisation, les fonctionnalités côté lunettes sont accessibles via les points d'entrée de service exposés par GlassSdk. Les groupes d'API publics comprennent les fonctions communes/d'appareil, le Bluetooth classique, le P2P, la messagerie, les médias, la gestion de fichiers, la voix/l'IA, la reconnaissance et d'autres services. N'initialisez pas toutes les fonctionnalités au démarrage. N'obtenez et n'activez que les services nécessaires à l'écran ou à l'étape du workflow en cours.

Contrôle de santé : Utilisez GlassSdk.isReady() comme simple indicateur de diagnostic avant d'appeler les services de fonctionnalités. S'il renvoie false, corrigez l'initialisation ou la liaison au service avant de tester les fonctions de plus haut niveau.

Étape 8 : initialiser le SDK Phone Android avec des identifiants client correspondants

Côté téléphone, initialisez le moteur mobile Rokid et enregistrez les identifiants client avec lesquels le téléphone communiquera. Le SDK Phone de Rokid constitue la couche de connexion et de contrôle pour la découverte d'appareils, le Bluetooth/P2P, la messagerie, les fichiers, la réception des médias, la synchronisation de la configuration et les opérations associées.

// Esquisse au niveau de l'application
val engineParam = EngineParam.Builder()
    .setClientIds(listOf("FieldServiceApp"))
    .setApiKeyCredentials(apiKeyCredentials)
    .build()
IMobileEngine.initSDK(engineParam)

// Vérification de diagnostic
val ready = PSecuritySDK.getMobileEngineService().isInit()

Si certaines fonctionnalités en ligne nécessitent des API Key Credentials, la démo contient des informations d'authentification fictives qui doivent être remplacées par des identifiants obtenus via le processus commercial de Rokid. Tenez les secrets cloud à l'écart du contrôle de source et évitez d'intégrer des clés API de plateforme à longue durée de vie dans une application cliente distribuable.

Étape 9 : se connecter d'abord en Bluetooth, puis utiliser le P2P pour la bande passante

Rokid documente deux modes de transport local aux rôles différents. Le Bluetooth classique convient à la découverte, à la connexion, aux messages de contrôle et aux petits fichiers. Le Wi-Fi P2P est le canal le plus adapté aux images, aux fichiers volumineux, à la vidéo et aux médias en temps réel. Utiliser le mauvais transport est un moyen facile d'obtenir une application qui fonctionne en démo, mais paraît peu fiable sur le terrain.

Bluetooth classique :

• À utiliser pour : Découverte, appairage, commandes de contrôle, messages JSON compacts, petits fichiers
• Rôle dans la conception : Plan de contrôle à faible bande passante

Wi-Fi P2P :

• À utiliser pour : Fichiers volumineux, images, vidéo, flux audio/vidéo, synchronisation à haut débit
• Rôle dans la conception : Plan de données à large bande passante

Connexion Wi-Fi directe des lunettes :

• À utiliser pour : Accès au back-end depuis une application des lunettes lorsque l'appareil est connecté au Wi-Fi
• Rôle dans la conception : Utile pour certains flux autonomes ; prévoyez tout de même un comportement hors ligne et de nouvelle tentative

Une application d'entreprise robuste doit traiter les connexions comme des machines à états plutôt que comme des événements ponctuels. Gérez explicitement la perte du Bluetooth, la fermeture du P2P, la mise en veille du téléphone, les changements de Wi-Fi et le redémarrage des lunettes. L'utilisateur doit recevoir un statut simple, comme « reconnexion en cours » ou « synchronisation en attente », et non une exception Android ou un échec silencieux.

Étape 10 : définir un protocole applicatif simple pour les messages métier

Rokid fournit les services de transport et de messagerie, mais votre application a toujours besoin d'un contrat définissant la signification d'un message métier. Gardez ce contrat compact, versionné et indépendant de l'interface. JSON est un choix pratique pour les premiers projets, car il est facile à inspecter, même si le format exact de la charge utile relève de la conception de votre application et non d'une exigence de Rokid.

{
  "schema": 1,
  "type": "WORK_STEP",
  "workOrderId": "WO-10458",
  "step": 3,
  "title": "Check valve pressure",
  "requiresPhoto": true
}

Une fois l'étape terminée, les lunettes peuvent renvoyer un court message de statut faisant référence à l'identifiant de l'ordre de travail et au numéro d'étape. Le fichier multimédia lui-même doit transiter par le canal P2P de fichiers/médias au lieu d'être intégré au message de contrôle. Cette séparation préserve la réactivité du canal de commande et simplifie les nouvelles tentatives.

Étape 11 : concevoir l'interface des lunettes pour du 480 x 640, pas comme une application mobile

L'écran de Glass3 utilise un système de coordonnées fixe de 480 x 640 en portrait. La FAQ de Rokid recommande de placer le contenu principal dans la zone centrale de 480 x 400, d'utiliser les 160 pixels du haut et les 80 pixels du bas pour les informations secondaires, et de décaler les contenus importants vers le bas, car les quelque 40 pixels supérieurs peuvent présenter un reflet optique. Le système d'exploitation ne propose pas de rotation d'écran classique : les mises en page larges doivent donc être conçues à l'intérieur du canevas portrait.

Affichez une seule tâche, instruction ou décision à la fois. Les longs tableaux de bord sont mal adaptés au verre.

Utilisez un fond noir dans la mesure du possible. Rokid le recommande pour réduire l'impression de clignotement au démarrage ou lors des transitions.

Ne placez pas de texte ou de boutons essentiels dans la zone de reflet d'environ 40 px en haut de l'écran.

Rendez les changements d'état évidents sans recourir à un code couleur complexe. Rokid recommande le vert comme style visuel principal.

Affichez clairement l'état de la connexion et l'état « synchronisé / en attente » des données métier.

Prévoyez des cibles d'interaction suffisamment simples pour être utilisées avec les commandes matérielles prises en charge ou la voix, sans imposer une navigation précise de type tactile.

Conséquence pour l'entreprise : L'écran est petit, mais cela peut être un avantage pour le travail procédural. Cela incite les équipes logicielles à supprimer les informations non essentielles et à n'afficher que la prochaine action dont l'opérateur a besoin.

Étape 12 : ajouter les fonctions caméra, photo, vidéo et aperçu en direct

Le SDK Glasses expose des fonctionnalités multimédias pour la photo, la vidéo, l'audio et l'aperçu. Le SDK Phone peut recevoir des flux multimédias provenant des lunettes. La FAQ de Rokid indique un flux vidéo par défaut en 1080P à environ 15 à 19 images par seconde, avec une latence de lecture sur le téléphone d'environ 300 ms, et précise que la sortie peut être en H.264 ou en NV21 décodé selon l'API et le parcours de démo. Considérez ces chiffres comme des indications de mise en œuvre actuelles plutôt que comme un SLA garanti.

Utilisez la capture d'images fixes pour les preuves d'inspection, les justificatifs de réalisation et le traitement ultérieur par IA.

Utilisez le H.264 lorsque le téléphone ou le back-end doit principalement transférer ou stocker le flux. Le changelog 2.1.8-E de Rokid a ajouté un contrôle du décodage automatique H.264 vers NV21, afin d'éviter les décodages inutiles.

Utilisez le NV21 lorsqu'un pipeline de vision par ordinateur côté téléphone a besoin d'images décodées.

Utilisez le Wi-Fi P2P plutôt que le Bluetooth classique pour l'aperçu en direct et le transfert de médias.

Si vous avez besoin de la caméra et d'une superposition à l'écran dans l'enregistrement, consultez les API AR Mix / enregistrement AR actuelles de Rokid et faites-les correspondre à la version du SDK installée.

Un détail pratique tiré de la FAQ de Rokid est important pour les workflows de preuves : après un envoi P2P réussi, les images présentes sur les lunettes peuvent être supprimées par le système. Considérez la copie reçue avec succès sur le téléphone ou le back-end comme la source de référence métier et confirmez la fin de l'envoi avant de faire avancer l'ordre de travail.

Étape 13 : ajouter la voix, la TTS et l'IA de manière réfléchie

La voix peut être précieuse lorsque les opérateurs ne peuvent pas utiliser leurs mains, mais elle doit être liée à des actions explicites du workflow. La documentation du SDK côté lunettes expose des fonctionnalités d'ASR, de TTS, de gestion de commandes hors ligne et de chat IA. Actuellement, la FAQ indique que la TTS hors ligne nécessite le SDK 2.2.0 ou ultérieur, bien que le changelog mentionne le service de TTS hors ligne dès la version 2.1.2 ; testez-la sur votre version figée. L'ASR hors ligne en langage libre n'est pas prise en charge par défaut à l'heure actuelle. Pour la reconnaissance vocale hors ligne, Rokid oriente les développeurs vers des services ASR/TTS privés, plutôt que d'annoncer une solution d'ASR hors ligne intégrée.

Mots de commande hors ligne :

• Bon usage : Commandes courtes et fixes, comme « suivant », « retour », « capturer »
• Note de conception pour l'entreprise : Adapté à un contrôle mains libres déterministe

ASR en ligne :

• Bon usage : Transcription vocale en langage libre
• Note de conception pour l'entreprise : Nécessite une configuration réseau/service et doit prévoir un comportement de repli

TTS / TTS hors ligne :

• Bon usage : Lecture d'invites, d'avertissements ou de courtes confirmations
• Note de conception pour l'entreprise : Utile lorsque l'affichage doit rester minimal

Chat IA / IA privée :

• Bon usage : Assistance contextuelle ou interprétation
• Note de conception pour l'entreprise : Le modèle doit rester au service du workflow. Validez le traitement des données, la latence et les limites des réponses.

Étape 14 : connecter le workflow à votre back-end en toute sécurité

Deux questions distinctes se posent côté back-end : comment votre propre application accède à vos systèmes métier, et si vous utilisez Rokid OpenAPI. Votre application peut envoyer des données via le téléphone appairé, ou une application des lunettes peut accéder directement à Internet lorsque Glass3 est connecté au Wi-Fi. Pour les systèmes de l'entreprise, des API back-end standard constituent normalement le point d'intégration le plus propre, car les identifiants, les journaux d'audit, la validation des données et les règles métier restent côté serveur.

Rokid OpenAPI est une couche de plateforme distincte. La documentation officielle exige un compte entreprise activé et une clé API. Les requêtes s'authentifient avec un jeton Bearer, les clés créées expirent et leur validité par défaut est d'un mois, sauf configuration contraire. Rokid met explicitement en garde contre l'exposition des clés API dans des dépôts publics ou des clients.

Règle de sécurité : Utilisez un proxy côté serveur pour les identifiants de la plateforme Rokid chaque fois que l'architecture le permet. Un APK mobile ou de lunettes peut être inspecté. Ne partez pas du principe que cacher une clé API dans du code Kotlin ou natif suffit à la garder secrète.

Les modules actuels de Rokid OpenAPI comprennent des API de messagerie et d'appareils, parmi d'autres fonctions d'entreprise (notez que ces API de messagerie et d'appareils ne sont accessibles que si les appareils sont enregistrés dans la console Lingmou de Rokid). Par exemple, l'API d'appareils peut interroger les unités Glass enregistrées, tandis que l'API de messagerie peut envoyer un message métier à un appareil cible. N'utilisez ces services que lorsqu'ils répondent à un besoin de déploiement réel. Un back-end d'entreprise sur mesure reste l'endroit approprié pour l'ERP, la GMAO, le CRM, la gestion des identités et l'orchestration des workflows.

Étape 15 : configurer les comportements d'entreprise tels que le démarrage automatique et la gestion des touches

Un appareil portable devient plus utile en exploitation lorsque l'utilisateur n'a pas à naviguer chaque matin dans un lanceur de type grand public. Rokid documente un mécanisme de démarrage automatique capable de lancer une application configurée après le démarrage sur les systèmes entreprise pris en charge. Rokid documente également la personnalisation des événements matériels et, dans le changelog 2.1.9-E, des API d'écoute/interception d'événements.

Utilisez le démarrage automatique pour les workflows dédiés d'inspection, de sécurité ou industriels, dans lesquels les lunettes doivent s'ouvrir directement sur l'application métier.

Retardez brièvement les traitements dépendant du SDK après le démarrage et vérifiez que le service est prêt avant de lancer le workflow.

Associez les événements de touches pris en charge à un petit nombre d'actions pertinentes, comme valider, capturer ou annuler.

Validez chaque fonctionnalité de démarrage automatique ou d'interception sur le firmware entreprise cible, car certains comportements au niveau système dépendent de la version.

Prévoyez toujours une voie de support/récupération. Un workflow verrouillé dont un administrateur ne peut pas sortir constitue un risque opérationnel.

Étape 16 : prévoir le fonctionnement hors ligne, les nouvelles tentatives et la reprise

Une démo suppose souvent un Bluetooth, un Wi-Fi et un accès cloud parfaits. Un déploiement sur le terrain ne peut pas se le permettre. Conservez l'état minimal du workflow nécessaire pour résister à une déconnexion du téléphone, à une défaillance du P2P ou à une coupure réseau temporaire. Chaque action métier doit être idempotente dans la mesure du possible, afin qu'une nouvelle tentative ne crée pas d'événements d'ordre de travail ou d'enregistrements de médias en double.

Mettez en cache l'identifiant de l'ordre de travail en cours, l'identifiant de l'étape et la dernière action confirmée.

Placez les résultats non envoyés dans une file d'attente avec un état « synchronisation en attente » visible.

Utilisez des identifiants d'opération uniques pour que le back-end puisse rejeter les doublons en toute sécurité.

Reconnectez d'abord le Bluetooth, puis rétablissez le P2P uniquement si un transfert à haut débit est nécessaire.

Ne marquez jamais une étape dépendant de médias comme terminée tant que la copie cible n'a pas fait l'objet d'un accusé de réception.

Prévoyez une solution de repli sûre pour l'utilisateur lorsque l'ASR en ligne ou l'IA n'est pas disponible. Des commandes hors ligne fixes peuvent toujours couvrir la navigation de base.

Étape 17 : tester sur du matériel réel avec une matrice de tests d'entreprise

Les émulateurs ne suffisent pas pour un projet de lunettes, car l'optique, le comportement thermique, le Bluetooth, le P2P, la caméra, le micro et le confort de port influent tous sur l'expérience logicielle. Testez le système complet sur l'OTA entreprise exacte prévue pour le pilote.

• Démarrage et lancement automatique : Démarrage à froid, lancement de l'application, disponibilité du SDK, reprise si la liaison au service est lente
• Bluetooth : Premier appairage, reconnexion, veille du téléphone, reprise après une sortie de portée
• P2P : Connexions/déconnexions répétées, fichier volumineux, flux en direct, changements de Wi-Fi
• Autorisations : Nouvelle installation, autorisation refusée, autorisation accordée ultérieurement, différences entre versions d'Android
• Médias : Qualité photo/vidéo, accusé de réception des fichiers, nouvelle tentative après un échec d'envoi, nettoyage du stockage
• Voix : Environnement bruyant, absence de réseau, phrase non prise en charge, interruption de la TTS
• Interface / optique : Lisibilité, zone de reflet en haut, texte long, visibilité des statuts, fatigue de l'utilisateur
• Performances : Session longue, température du CPU, mémoire disponible, survie des processus
• Back-end : Réponse lente, requête en double, jeton expiré, serveur indisponible
• Sécurité : Gestion des identifiants, masquage dans les logs, perte d'appareil, révocation de compte

La FAQ de Rokid suggère spécifiquement de surveiller la mémoire et la température du CPU lors du diagnostic des performances, et avertit qu'une mémoire disponible très faible rend plus probable l'arrêt des processus en arrière-plan. C'est une raison supplémentaire de garder l'application des lunettes ciblée et de déporter ailleurs les services non essentiels.

Étape 18 : packager le pilote et maîtriser la configuration de référence du déploiement

Pendant le développement, les APK peuvent être installés via Android Studio à l'aide du câble de débogage de données Glass3. Un déploiement en production nécessite un processus de publication plus rigoureux. Rokid ne documente aucun contrôle des politiques de type MDM (comme le mode kiosque, l'effacement à distance ou les politiques d'applications). Rokid documente en revanche l'enregistrement des appareils et le suivi de leur statut via la console Lingmou et l'OpenAPI, tandis que la version 2.2.0-E permet l'installation d'APK via une application de scan de QR code. Coordonnez le mécanisme de déploiement, les droits de provisionnement, le firmware entreprise et la politique de mise à jour avec Rokid ou le distributeur avant de vous engager sur une architecture de déploiement.

1. Figez les versions SDK et OTA testées pour le pilote.

1. Créez des APK de release signés pour les applications des lunettes et du téléphone.

1. Documentez les identifiants client, les noms de packages et la configuration des environnements back-end.

1. Provisionnez les clés API et les secrets back-end via une infrastructure sécurisée, et non dans le code source.

1. Définissez qui peut mettre à jour les lunettes, l'application téléphone et le back-end, et dans quel ordre.

1. Exécutez des tests de régression après chaque changement d'OTA ou de SDK avant de mettre à jour la flotte.

1. Mettez en place un circuit de support pour les logs, l'identité des appareils, les diagnostics de connectivité et le retour arrière.

Exemple d'architecture : une application sur mesure d'inspection pour l'intervention terrain

Voici un exemple de conception pratique élaboré à partir des fonctionnalités documentées par Rokid. Il ne s'agit pas d'un workflow Rokid prêt à l'emploi. Il montre comment la pile de développement peut transformer les lunettes en terminal métier dédié.

1. Démarrage. Action technique : l'application des lunettes démarre automatiquement et vérifie que le SDK est prêt. Valeur métier : l'opérateur démarre directement dans le workflow de l'entreprise.
2. Attribution de la tâche. Action technique : le téléphone/back-end envoie le résumé de l'ordre de travail sous forme de message compact. Valeur métier : aucune recherche manuelle sur un téléphone n'est nécessaire.
3. Guidage. Action technique : les lunettes affichent une instruction dans la zone centrale de l'écran. Valeur métier : les mains restent libres pour la tâche.
4. Validation. Action technique : l'opérateur prononce une commande fixe ou utilise un événement matériel pris en charge. Valeur métier : interaction rapide et déterministe.
5. Capture de preuves. Action technique : les lunettes prennent une photo ou un court clip. Valeur métier : la preuve visuelle est rattachée à la bonne étape.
6. Transfert. Action technique : les médias transitent via P2P ; un court message de statut confirme l'envoi. Valeur métier : les données volumineuses restent hors du canal de contrôle à faible bande passante.
7. Synchronisation. Action technique : le téléphone ou le back-end publie le résultat sur l'API de la GMAO/de l'ERP. Valeur métier : les systèmes métier existants restent le système de référence.
8. Exception. Action technique : si nécessaire, le téléphone reçoit un flux en direct ou l'application déclenche la solution d'assistance à distance approuvée. Valeur métier : un superviseur peut voir ce que voit l'opérateur.
9. Clôture. Action technique : le back-end accuse réception de la fin de l'intervention et renvoie la tâche suivante. Valeur métier : l'utilisateur dispose d'un état final clair et la piste d'audit est complète.

Pourquoi un logiciel sur mesure change l'équation économique de Rokid AI Glasses Enterprise

La principale valeur pour l'entreprise vient de l'adaptation de l'appareil à un processus opérationnel existant, ou de la refonte de ce processus pour un travail mains libres.

Interface dédiée : supprimer les menus grand public et n'afficher que les informations nécessaires à l'étape en cours.

Intégration aux systèmes métier : relier les preuves capturées et les actions des opérateurs aux ERP, GMAO, CRM ou plateformes sur mesure existants.

Capture de données mains libres : utiliser la caméra, la voix et les commandes des lunettes sans devoir revenir sans cesse à un téléphone ou une tablette.

Connectivité maîtrisée : utiliser le Bluetooth pour les commandes et le P2P pour les données à haut débit, plutôt que de faire passer toutes les fonctions par un seul canal.

Limites d'IA personnalisées : utiliser l'IA là où elle apporte de la valeur, tout en gardant les règles du workflow, les autorisations et la gouvernance des données sous le contrôle de l'entreprise.

Comportement d'appareil dédié : le démarrage automatique et la gestion des événements peuvent réduire les frictions pour les déploiements à usage unique, lorsque le firmware entreprise les prend en charge.

Architecture évolutive : commencer par une preuve de concept locale, puis ajouter l'intégration back-end, les API de plateforme, la collaboration à distance ou des SDK spécialisés à mesure que le workflow gagne en maturité.

L'argument d'achat : Pour les organisations qui ont besoin d'une expérience applicative standard et figée, un développement sur mesure peut être superflu. Pour celles qui veulent que les lunettes IA s'intègrent à un workflow opérationnel maîtrisé, le SDK Glass3 documenté est ce qui rend le matériel plus intéressant. L'entreprise achète un terminal adaptable, et pas seulement un écran ou une caméra portable.

Limites et risques techniques à anticiper

• SDK centré sur Android : Le SDK Glass3 public cible Android natif. La FAQ de Rokid indique qu'iOS et HarmonyOS natif ne sont pas pris en charge. Une intégration uni-app n'est possible qu'en créant votre propre passerelle vers le SDK Android natif.
• Écran compact : Le canevas portrait de 480 x 640 convient à des invites concises, pas à des tableaux de bord d'entreprise denses. Une bonne conception du workflow est indispensable.
• Décalage entre SDK et changelog : Validez ensemble les artefacts du SDK, la démo et l'OTA, en tenant compte des différences de versions entre les changelogs chinois et anglais.
• Dépendance aux services en ligne : Certaines fonctions d'ASR, d'IA et d'OpenAPI nécessitent un accès réseau, des identifiants entreprise ou un provisionnement de service.
• Pas d'ASR hors ligne en langage libre selon la FAQ actuelle : La TTS hors ligne et les commandes hors ligne fixes peuvent assurer une interaction résiliente, mais la transcription vocale hors ligne en langage libre n'est pas actuellement documentée comme intégrée.
• Complexité des transports : Le Bluetooth et le P2P répondent à des problèmes différents. La reconnexion, les autorisations et la synchronisation des états exigent une ingénierie de qualité production.
• Suppression du RTC de base : Rokid a retiré les appels RTC du SDK Phone de base dans la version 2.1.7-E. La collaboration à distance doit s'appuyer sur le Remote Collaboration SDK de Rokid ou sur une solution développée séparément.
• Les détails du déploiement doivent être validés : La documentation publique du SDK est solide sur le développement, mais la gestion de flotte en production et le provisionnement via la console Lingmou ou l'application de scan de QR code doivent être confirmés pour l'environnement du client avant tout passage à l'échelle.

Avantages et inconvénients pour un développement d'entreprise sur mesure

Avantages :

• Modèle de développement Android natif
• Artefacts Maven publics
• Démo officielle lunettes + téléphone
• Bluetooth et P2P
• Messagerie/fichiers/médias
• Caméra et aperçu en direct
• Services de voix/IA/reconnaissance
• Connexion Wi-Fi directe possible
• OpenAPI entreprise
• Possibilités de démarrage automatique et de personnalisation des événements.

Inconvénients :

• Prise en charge du SDK natif limitée à Android
• Écran compact et fixe
• Coordination des versions/OTA
• Certaines fonctionnalités en ligne nécessitent un accès entreprise
• Limitation de l'ASR hors ligne
• Les détails de provisionnement/gestion de flotte en production doivent être confirmés au cas par cas pour chaque projet.

Verdict final

Rokid AI Glasses Enterprise mérite d'être envisagé lorsque l'objectif de l'entreprise est de créer un workflow mains libres dédié plutôt que de déployer une application grand public générique. La pile entreprise actuelle de Glass3 offre aux développeurs Android une voie documentée pour développer sur les lunettes, les associer à un téléphone Android, faire transiter les données de contrôle via Bluetooth, transférer les médias via Wi-Fi P2P et connecter le workflow aux systèmes back-end ou à certains services Rokid OpenAPI.

Les cas d'usage les plus pertinents sont les inspections guidées, l'intervention terrain, la capture de preuves, le travail procédural et d'autres tâches où l'opérateur gagne à voir une instruction à la fois tout en gardant les deux mains libres. La principale limite n'est pas le manque d'API. C'est la rigueur d'ingénierie qu'exigent le petit écran, l'état de la connectivité, les autorisations, la compatibilité SDK/OTA et la dépendance aux services en ligne.

Pour un acheteur professionnel, la question clé de l'évaluation est la suivante : « Pouvons-nous adapter notre workflow à la pile de développement documentée, et sommes-nous en mesure d'assurer le support de l'application tout au long de son cycle de vie ? » Si la réponse est oui, un logiciel sur mesure permet de faire passer Rokid Glass3 du statut de lunettes IA généralistes à celui d'appareil opérationnel dédié.

Pour les entreprises qui évaluent Rokid AI Glasses Enterprise pour des inspections, de l'intervention terrain, de la logistique, du travail guidé ou des workflows d'IA sur mesure, VR Expert peut aider à évaluer le matériel, à définir une preuve de concept et à valider la stratégie de déploiement. Consultez la page produit Rokid AI Glasses Enterprise pour découvrir l'appareil, sa disponibilité et les options d'achat. Pour cadrer un développement sur mesure ou obtenir des conseils de déploiement, contactez VR Expert.