Google Glass : quand le futur se sentait maladroit en public

Ce que Glass essayait vraiment d’être (et pourquoi c’était important)

Google Glass n’était pas « un petit téléphone sur votre visage ». Ce cadrage l’a tué deux fois : d’abord dans les attentes, puis dans la planification opérationnelle. Glass se rapprochait davantage d’un appareil monté sur la tête pour notifications et capture : interactions brèves, interface lisible en un coup d’œil, comportement centré sur la caméra, et capteurs toujours actifs qui grignotent la batterie même quand l’utilisateur pense « ne rien faire ».

Voici la première leçon pour quiconque construit ou exploite des wearables : vous ne pouvez pas copier le playbook du smartphone et espérer qu’il tienne. Les smartphones ont des batteries généreuses, des piles radio matures, et des utilisateurs qui tolèrent des interactions tactiles fréquentes. Les lunettes intelligentes n’ont aucune de ces luxes, et elles ajoutent un nouveau facteur : toute personne autour du porteur devient un acteur involontaire.

Au moment où vous attachez du calcul à un visage, vos contraintes de conception changent :

• La latence est émotionnelle. Si une commande vocale prend une seconde de plus, ce n’est pas « lent », c’est « j’ai l’air ridicule à parler tout seul ».
• La décharge de batterie devient une politique. Quand l’appareil meurt en plein service, ce n’est pas une simple gêne — c’est un arrêt de processus.
• La confidentialité n’est pas une fonctionnalité ; c’est une porte d’entrée au déploiement. Vous pouvez avoir la meilleure architecture de sécurité au monde et quand même vous faire jeter hors d’un bar.
• L’observabilité est contrainte. Vous ne pouvez pas expédier un agent de 200 Mo et l’appeler monitoring. Votre budget de logs se mesure en milliwatts.

Donc oui, Glass était un produit. Mais c’était aussi une tentative très précoce de ce que nous appelons aujourd’hui « edge computing avec un humain dans la boucle ». Et les humains, comme on sait, refusent de se comporter comme des nœuds Kubernetes.

Faits et contexte intéressants à utiliser en réunion

Points contextuels courts et concrets qui gardent les conversations ancrées :

1. Le projet Glass est devenu public en 2012 avec une démo en parachute qui faisait paraître le futur sans effort — parce que les cascades cachent bien les contraintes opérationnelles.
2. Les unités Explorer Edition coûtaient 1 500 $, ce qui positionnait Glass comme un kit développeur, mais il a atterri culturellement comme un produit grand public soumis à un examen public.
3. « Glasshole » est entré dans le lexique comme raccourci pour la friction sociale des caméras portables — un dommage de marque qu’aucune mise à jour ne répare.
4. Les premiers Glass s’appuyaient fortement sur l’appairage Bluetooth à un téléphone pour la connectivité, ce qui signifiait que vous exploitiez en réalité un système distribué à deux appareils.
5. Le matériel original utilisait un petit prisme d’affichage qui projetait l’information dans la vision périphérique — excellent pour des aperçus rapides, maladroit pour une lecture prolongée.
6. L’autonomie de la batterie était souvent critiquée, surtout lors de l’utilisation de la caméra ; la capture vidéo est le pire cas en termes de charge thermique et électrique.
7. Google a mis fin au programme Explorer consumer en 2015, ce que beaucoup ont lu comme « le produit a échoué », mais les cas d’usage sous-jacents n’ont pas disparu.
8. Glass a réapparu comme produit pour l’entreprise (Glass Enterprise Edition) ciblant la logistique, l’assistance à distance et la fabrication — des contextes où la gêne est tolérée si cela fait gagner des minutes.
9. Plusieurs lieux ont interdit Glass ou demandé aux porteurs de l’enlever ; la politique publique est devenue une dépendance d’exécution.

Rien de tout cela n’est du trivia. Chacun se traduit par une contrainte opérationnelle : le prix change les attentes, l’appairage introduit des domaines de panne, et l’acceptabilité sociale est effectivement le « temps de disponibilité » pour l’usage public.

Pourquoi le futur paraissait maladroit en public : l’« ops » de l’acceptation sociale

Glass ne devait pas seulement fonctionner. Il devait fonctionner tout en ayant l’air normal sur son porteur. C’est une exigence impitoyable, car « normal » est un algorithme de consensus distribué avec des conditions réseau hostiles.

Commencez par l’évidence : une caméra sur le visage de quelqu’un change le comportement de tous ceux qui l’entourent. Même si vous n’enregistrez pas, vous avez l’air d’être susceptible de le faire. Cela suffit. Les systèmes sociaux n’attendent pas votre document de modèle de menace.

Ajoutez maintenant une interface qui invite aux commandes vocales. La voix est parfaite dans un entrepôt. Elle n’est pas idéale dans un train silencieux. L’écart entre « c’est techniquement impressionnant » et « je veux faire ça en public » est l’endroit où beaucoup de produits futurs vont mourir.

L’optique de confidentialité l’emporte sur l’ingénierie de la confidentialité

Les ingénieurs aiment les contrôles : LED, indicateurs, permissions, sandboxing, journaux d’audit. Tout cela est bien. Mais Glass a affronté une vérité désagréable : la violation perçue de la confidentialité l’emporte sur la posture réelle de confidentialité, dans le tribunal de l’opinion publique. Si les gens pensent que vous enregistrez, vous enregistrez. Ce n’est pas juste. C’est la réalité.

Opérationnellement, cela compte parce que votre courbe d’adoption devient non déterministe. Vous ne pouvez pas planifier la capacité d’un déploiement de flotte si les managers locaux improvisent des politiques : « Pas de Glass en réunion », « Seulement au bureau arrière », « Pas près des clients », « Évidemment pas dans les toilettes, pourquoi c’est un point à l’ordre du jour ? » L’appareil devient un aimant à politiques.

L’illusion du « toujours disponible » et le piège de la fiabilité

Les wearables vantent « toujours disponible ». L’utilisateur entend : « Ça ne me lâchera pas ». Le matériel entend : « Bonne chance avec ça. »

Les lunettes intelligentes sont presque toujours contraintes par :

• La capacité de la batterie (petit facteur de forme)
• L’enveloppe thermique (proximité de la peau humaine)
• La variabilité sans fil (mouvement, interférences, roaming)
• L’ambiguïté des entrées (voix, gestes de tête, pavé tactile)

En public, chacune de ces contraintes devient visible. L’appareil chauffe, réduit sa fréquence, et votre UI saccade. Le micro capte la machine à espresso et décide que vous avez demandé « enregistrer ». L’utilisateur répète la commande, plus fort. Maintenant tout le monde regarde.

Blague #1 : Rien ne vous fait sentir plus cyborg que de crier « OK GLASS » dans une pièce pleine d’humains qui préféreraient que vous ne le fassiez pas.

Le décalage : optimisme des développeurs vs tolérance du public

Les utilisateurs de l’Explorer Edition étaient, par définition, tolérants. Ils avaient payé pour être bêta-testeurs. Le public ne s’est pas inscrit à ce programme. Si vous déployez un produit dans l’espace public, vous le déployez dans l’environnement de mise en scène le plus chaotique du monde — sans possibilité de rollback.

Du point de vue SRE, « la gêne » est un signal de fiabilité. Elle prédit l’abandon. Si les utilisateurs évitent une fonctionnalité dans les environnements pour lesquels elle a été conçue, la disponibilité effective de votre produit est faible, même si vos tableaux de bord sont verts.

Vue système : batterie, thermique, réseau et I/O humain

Si vous voulez comprendre Glass, ne commencez pas par la RA. Commencez par les contraintes. La pile est une négociation entre la physique et le comportement.

Batterie : le SLO le moins indulgent

Sur un serveur, l’alimentation est une ligne budgétaire. Sur un wearable, c’est le produit. Vous ne pouvez pas « simplement ajouter une batterie plus grosse » sans changer le poids, l’équilibre et la chaleur. Vous vous retrouvez donc avec des micro-décisions : gardons-nous le scan Wi‑Fi agressif pour des connexions plus rapides, ou laissons-nous les connexions être plus lentes pour économiser de l’énergie ? Gardons-nous la pipeline caméra chaude, ou payons-nous la latence du démarrage à froid ? Chacune affecte la qualité perçue.

La décharge de la batterie complique aussi le support. Les utilisateurs rapportent « ça meurt vite », mais la cause racine peut être :

• une application d’arrière-plan maintenant un wake lock
• une radio bloquée en mode de nouvelle tentative à haute puissance en raison d’un signal faible
• une boucle serrée qui réessaye un envoi échoué
• la limitation thermique qui prolonge le temps actif pour le même travail

C’est pourquoi les opérations sur wearables doivent traiter l’énergie comme une métrique de première classe, pas comme une plainte vague.

Thermiques : le gouverneur caché

Les contraintes thermiques expliquent pourquoi « ça marche bien sur mon bureau » vous ment. L’appareil est sur une tête, souvent sous un éclairage, parfois près de machinerie, et toujours près de la peau. Les thermiques affectent la fréquence CPU, la stabilité de la caméra, et la chimie de la batterie. Cela se traduit par des saccades — le pire comportement au moment même où vous voulez de la constance.

Réseau : le roaming est un mode de panne, pas une fonctionnalité

Le roaming entre points d’accès est facile sur le papier. Dans de vrais bâtiments, c’est là où les sessions viennent mourir.

Les wearables de l’ère Glass s’appuyaient sur le tethering au téléphone ou sur de petites piles Wi‑Fi. Cela introduit une panne multi-sauts : batterie du téléphone, limites d’arrière-plan de l’OS du téléphone, qualité du lien Bluetooth, et portails captifs Wi‑Fi. Votre « panne d’application » peut être une tempête de reconnexions Bluetooth dans la poche de quelqu’un.

I/O humain : votre UI est un canal d’incident

Les wearables ont peu de méthodes d’entrée. Quand l’entrée échoue, les utilisateurs compensent par le comportement : répéter les commandes, taper plus fort, tourner la tête, s’approcher du routeur, ou — le plus courant — abandonner. Chaque contournement change le profil de charge. Plus de réessais signifie plus de consommation d’énergie. Plus d’enregistrements signifie plus d’envois. Plus d’envois signifie plus de charge thermique.

Traitez donc l’UX comme faisant partie des opérations. Une mauvaise UX génère une charge opérationnelle de la même façon qu’un client bogué génère des hordes.

Une citation sur la fiabilité à garder sur votre mur

L’espoir n’est pas une stratégie. — Gene Kranz

Elle s’applique ici brutalement : espérer que les utilisateurs « chargeront juste », « trouveront un meilleur Wi‑Fi », ou « l’utiliseront aux bons endroits » n’est pas un plan opérationnel.

Trois mini-récits d’entreprise issus des tranchées des wearables

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de maintenance sur le terrain de taille moyenne a testé des lunettes intelligentes pour l’assistance à distance. Le plan était simple : les techniciens diffusent la vidéo vers un centre de support ; le centre annote des captures d’écran ; les réparations sont plus rapides. Ils ont acheté une petite flotte, inscrit les appareils dans la gestion, et mené un pilote de deux semaines dans trois régions.

L’hypothèse erronée était subtile : ils ont supposé que « connectivité » voulait dire « le réseau fonctionne ». En pratique, les techniciens se déplaçaient entre des sous-sols, des salles machines et des toits. Le Wi‑Fi disparaissait. Le cellulaire était inconsistent. Les lunettes continuaient à tenter de se reconnecter et reprendre le flux, consommant la batterie et générant des réessais qui semblaient être de « l’instabilité applicative ».

Le support a commencé à voir des sessions abandonnées et a accusé le backend. L’équipe backend a mis à l’échelle le service de signalisation, augmenté les timeouts, et activé plus de logs. L’incident s’est aggravé. Des timeouts plus longs signifiaient plus de sessions suspendues sur l’appareil, donc plus de temps radio actif, donc plus de chaleur et plus de throttling, donc un débit effectif plus faible. Une boucle de rétroaction parfaite.

Finalement, quelqu’un a posé la question ennuyeuse : « Quelle est la puissance du signal là où ça échoue ? » Ils ont corrélé les coupures avec les types d’emplacements et découvert le vrai coupable : zones RF mortes et bugs de roaming AP sur quelques sites clients. La solution n’était pas « plus de backend ». C’était un mode cache local avec comportement hors-ligne explicite, plus une règle : ne pas tenter le streaming en direct sous un seuil de signal ; passer au stockage-et-transmission différée.

La leçon du postmortem : si votre appareil se déplace dans le monde physique, la variabilité réseau n’est pas un cas limite. C’est votre charge de travail principale.

Mini-récit 2 : L’optimisation qui s’est retournée contre vous

Une entreprise logistique voulait une acquisition de codes-barres plus rapide sur lunettes intelligentes. L’équipe a optimisé agressivement : garder la preview caméra « chaude », précharger le modèle ML, et exécuter l’autofocus en continu. La démo était magnifique. La latence des scans a chuté. Les gens ont applaudi. Quelqu’un a écrit « game changer » dans une présentation, ce qui est un bon prédicteur de douleurs futures.

En production, l’optimisation s’est transformée en désastre pour la batterie et le thermique. Garder la pipeline chaude signifiait que l’appareil ne s’ennuyait jamais vraiment. L’autofocus continu impliquait une activité moteur constante et un traitement d’images supplémentaire. Les lunettes chauffaient, se bridaient, et commençaient à perdre des images — exactement ce que l’optimisation était censée empêcher.

Les opérateurs ont aussi observé une nouvelle classe de panne : les appareils ne terminaient pas la journée sans charge intermédiaire, donc les travailleurs ont commencé à les brancher sur des ports USB aléatoires. Certains ports étaient « charge-only », d’autres derrière des armoires verrouillées, d’autres sur des PC qui appliquaient des mises à jour non autorisées. L’optimisation a indirectement augmenté la surface d’attaque et la charge de support.

La correction finale a été de traiter « prêt à scanner » comme une machine à états. La pipeline caméra ne pouvait se chauffer que lorsque l’utilisateur entrait dans un workflow de scan, et elle devait refroidir agressivement en en sortant. Ils ont aussi ajouté un garde‑fou thermique : si la température cutanée ou celle de l’appareil franchissait un seuil, l’interface dégradait gracieusement au lieu de prétendre que les performances étaient stables.

Leçon : optimiser une interaction unique sans prendre en compte la puissance et la chaleur, c’est comme optimiser une requête de base de données en désactivant la durabilité. Ça marche jusqu’au moment où ça compte.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Un groupe de maintenance industrielle a déployé des lunettes intelligentes dans plusieurs usines. Leur direction voulait de la vitesse, mais un chef ops chevronné a insisté sur un déploiement terne : inventorier chaque appareil, appliquer des builds OS cohérents, et phaser les mises à jour en anneaux. Pas d’héroïsme. Juste de la discipline.

Ils ont établi trois anneaux : labo, pilote, large. Chaque mise à jour — OS, politique MDM, leur app — devait tremper une semaine en labo, puis une semaine en pilote, avant un déploiement large. Ils ont aussi collecté des métriques de santé device (cycles de batterie, compte de crashs, pics de température) dans un tableau de bord central.

Un mois après, une mise à jour a introduit une régression Bluetooth qui provoquait des déconnexions fréquentes avec des radios appairées sur des chariots élévateurs. En large déploiement, cela aurait été un incident de productivité de flotte. Dans l’anneau pilote, ce n’étaient que deux techniciens irrités et un rollback propre. Ils ont pausé le déploiement, collecté les logs, et expédié un contournement sans déclencher toute l’organisation.

La pratique ennuyeuse — anneaux, inventaire et métriques — a transformé une panne potentielle en un désagrément mineur. Personne n’a célébré. C’est comme ça qu’on sait que c’était du bon SRE.

Tâches pratiques : commandes, sorties et décisions (12+)

L’exploitation des lunettes intelligentes, c’est l’exploitation de flotte plus le débogage mobile plus la réalité réseau. Ci‑dessous des tâches pratiques que vous pouvez exécuter aujourd’hui avec des outils Linux standard et Android Debug Bridge (ADB). Le but n’est pas de jouer au hacker. C’est de prendre des décisions rapides et défendables avec des preuves.

Tâche 1 : Vérifier que l’appareil est joignable via ADB (USB)

cr0x@server:~$ adb devices
List of devices attached
8a3f21d2	device

Ce que signifie la sortie : L’ID de l’appareil apparaît en tant que device, pas unauthorized ou vide.

Décision : S’il est unauthorized, corrigez l’appairage/les invites de confiance avant de blâmer l’application. S’il manque, vérifiez le câble/le driver/le mode USB.

Tâche 2 : Capturer l’identité basique de l’appareil (OS/build)

cr0x@server:~$ adb shell getprop ro.build.fingerprint
google/glass_enterprise/glass:10/QP1A.190711.020/6789012:user/release-keys

Ce que cela signifie : Empreinte exacte du build OS pour corrélation.

Décision : Si des incidents se corrèlent à une empreinte spécifique, arrêtez le déploiement et isolez.

Tâche 3 : Vérifier l’espace libre (les tempêtes de logs aiment les disques pleins)

cr0x@server:~$ adb shell df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/dm-0  24G   22G  1.8G  93% /data

Ce que cela signifie : /data est presque plein ; les apps peuvent planter, les mises à jour échouer, les bases de données se corrompre.

Décision : Si >90%, nettoyez caches/logs, faites pivoter les médias locaux, ou augmentez les contrôles de rétention avant de courir après des « plantages aléatoires ».

Tâche 4 : Identifier les plus gros consommateurs CPU (précurseur du throttling thermique)

cr0x@server:~$ adb shell top -b -n 1 | head -n 12
Tasks: 279 total,   2 running, 277 sleeping,   0 stopped,   0 zombie
%Cpu(s): 38.0 us,  8.0 sy,  0.0 ni, 54.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER         PR  NI  VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
 3124 u0_a133      10 -10 2.1G  188M  92M R 28.5  3.2   0:43.12 com.company.assist
  987 system       20   0  132M   34M  18M S  6.2  0.6   2:10.44 surfaceflinger

Ce que cela signifie : Votre application consomme du CPU. La charge de SurfaceFlinger suggère un rendu UI intensif.

Décision : Si le CPU est élevé pendant « l’inactivité », cherchez les wake locks, les boucles de preview caméra, ou les tempêtes de réessais.

Tâche 5 : Vérifier le statut thermique et les signaux de throttling

cr0x@server:~$ adb shell dumpsys thermalservice | head -n 20
IsStatusOverride: false
Thermal Status: 2
Temperature{mValue=41.5, mType=CPU, mName=cpu-0, mStatus=2}
Temperature{mValue=39.0, mType=SKIN, mName=skin, mStatus=1}

Ce que cela signifie : Température CPU élevée ; le statut thermique indique un risque de throttling modéré.

Décision : Si le statut grimpe pendant la caméra ou les réessais Wi‑Fi, appliquez de l’allègement de charge (baisser le framerate, mettre en pause les uploads, différer le ML).

Tâche 6 : Instantané de santé de la batterie (trouver les coupables des wake locks)

cr0x@server:~$ adb shell dumpsys batterystats --charged | head -n 25
Battery Statistics (Charged):
  Estimated power use (mAh):
    Capacity: 780, Computed drain: 612, actual drain: 590
  Per-app estimated power use (mAh):
    com.company.assist: 210
    com.android.systemui: 68

Ce que cela signifie : Votre app est un consommateur majeur d’énergie.

Décision : Si votre app domine, priorisez la réduction du travail en arrière-plan et de l’utilisation radio avant d’optimiser la micro-latence.

Tâche 7 : Inspecter les wake locks (classique bug « toujours allumé »)

cr0x@server:~$ adb shell dumpsys power | sed -n '1,120p'
Power Manager State:
  mWakefulness=Awake
  Wake Locks: size=2
  * WakeLock{c11a2b1 held=true flags=0x1 tag="com.company.assist:stream" uid=10133}
  * WakeLock{a84f21d held=false flags=0x1 tag="AudioMix" uid=1041}

Ce que cela signifie : Votre app tient un wake lock nommé stream.

Décision : Si un wake lock persiste en dehors de l’usage actif, corrigez la gestion du cycle de vie ; sinon votre SLO batterie est une fiction.

Tâche 8 : Valider l’état de l’interface réseau et l’attribution IP

cr0x@server:~$ adb shell ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 3000
    inet 10.42.18.77/24 brd 10.42.18.255 scope global wlan0

Ce que cela signifie : Le Wi‑Fi est actif avec une IP ; la connectivité L3 de base est plausible.

Décision : S’il n’y a pas d’IP, dépannez DHCP, portails captifs, ou profils Wi‑Fi MDM avant de toucher le code applicatif.

Tâche 9 : Mesurer la perte de paquets/la latence vers votre API (depuis l’appareil)

cr0x@server:~$ adb shell ping -c 5 api.internal
PING api.internal (10.42.50.12): 56 data bytes
64 bytes from 10.42.50.12: icmp_seq=0 ttl=63 time=18.4 ms
64 bytes from 10.42.50.12: icmp_seq=1 ttl=63 time=220.1 ms
64 bytes from 10.42.50.12: icmp_seq=2 ttl=63 time=19.2 ms
64 bytes from 10.42.50.12: icmp_seq=3 ttl=63 time=21.0 ms
64 bytes from 10.42.50.12: icmp_seq=4 ttl=63 time=19.1 ms

--- api.internal ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
round-trip min/avg/max = 18.4/59.5/220.1 ms

Ce que cela signifie : Pas de perte, mais le jitter est élevé ; ce RTT max est une « pause » visible par l’utilisateur.

Décision : Si le jitter monte en flèche, ajustez retry/backoff, préférez les appels idempotents, et mettez en cache local ; n’augmentez pas aveuglément les timeouts.

Tâche 10 : Inspecter la résolution DNS (fréquent sur les réseaux verrouillés)

cr0x@server:~$ adb shell getprop net.dns1
10.42.0.2

Ce que cela signifie : L’appareil a un résolveur DNS configuré.

Décision : Si le DNS est vide ou pointe vers un résolveur de portail captif, corrigez le provisioning Wi‑Fi et les hypothèses de DNS à horizon partagé.

Tâche 11 : Récupérer les logs pour une fenêtre de crash spécifique

cr0x@server:~$ adb logcat -d -t 200 | tail -n 30
01-21 10:14:22.884  3124  3180 E AssistStream: upload failed: java.net.SocketTimeoutException
01-21 10:14:22.886  3124  3180 W AssistStream: retrying in 0ms
01-21 10:14:22.901  3124  3180 E AssistStream: upload failed: java.net.SocketTimeoutException
01-21 10:14:22.902  3124  3180 W AssistStream: retrying in 0ms

Ce que cela signifie : Une boucle de réessai avec 0ms de backoff est un bug qui fait fondre la radio.

Décision : Ajoutez un backoff exponentiel avec jitter et un coupe‑circuit ; limitez aussi les uploads concurrents.

Tâche 12 : Confirmer si l’appareil effectue du roaming entre APs

cr0x@server:~$ adb shell dumpsys wifi | sed -n '1,140p'
Wi-Fi is enabled
Current network: "CorpWiFi" WPA2
RSSI: -76
BSSID: 8c:3b:ad:11:22:33
Supplicant state: COMPLETED
Roam count: 9

Ce que cela signifie : Signal faible et roaming fréquent ; recette parfaite pour les coupures de flux.

Décision : Améliorez le placement des APs, ajustez les seuils de roaming, ou concevez l’app pour tolérer le roaming (uploads segmentés, sessions reprenables).

Tâche 13 : Vérifier la poignée TLS et la chaîne de certificats depuis une machine ops

cr0x@server:~$ openssl s_client -connect api.internal:443 -servername api.internal -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer certificate: CN = api.internal
Verification: OK

Ce que cela signifie : TLS est propre du point de vue réseau ; les échecs sont probablement côté client ou dus à une interception proxy ailleurs.

Décision : Si la vérification échoue seulement sur les appareils, cherchez des certificats intermédiaires manquants, des stores de confiance obsolètes, ou un MITM via portail captif.

Tâche 14 : Inspecter rapidement la saturation côté serveur (CPU, mémoire, I/O disque)

cr0x@server:~$ uptime
 10:22:51 up 41 days,  6:13,  3 users,  load average: 6.42, 6.81, 6.77

Ce que cela signifie : La charge est élevée ; pas une preuve de saturation CPU, mais un indice.

Décision : Si la charge monte avec les sessions wearables, vérifiez l’I/O wait et les pools de threads ; n’ajoutez pas de pods par réflexe.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  1      0 245312  82240 731204    0    0  1240  2110 3810 6120 32  9 44 15  0
 4  2      0 241800  82244 731010    0    0  1420  2380 3992 6450 28 10 43 19  0

Ce que cela signifie : wa (I/O wait) est non négligeable ; le stockage ou les disques réseau pourraient être le goulet.

Décision : Si l’I/O wait est élevé, investiguez la latence disque et la profondeur de file d’attente avant de scaler le compute.

Tâche 15 : Repérer la pression disque sur le serveur (le tueur ennuyeux)

cr0x@server:~$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G  192G  8.0G  97% /var

Ce que cela signifie : Les logs, uploads ou caches remplissent /var.

Décision : Si vous dépassez 90–95%, faites pivoter les logs, déplacez les caches, et ajoutez des alertes. Les disques pleins créent des pannes « aléatoires » qui sont en réalité très déterministes.

Blague #2 : Le moyen le plus rapide de découvrir que vous n’avez pas de rotation de logs, c’est de tomber en panne de disque en plein milieu d’une démo.

Playbook de diagnostic rapide : quoi vérifier en premier, deuxième, troisième

Voici la séquence « arrêtez de débattre et obtenez des données ». Elle suppose une plainte utilisateur du type : « Glass est lent », « les flux tombent », « la batterie meurt », ou « l’app plante ».

Premier : Décidez si le goulot est l’appareil, le réseau ou le backend

1. Instantané santé appareil : principaux consommateurs CPU, statut thermique, espace de stockage libre, décharge batterie par application.
2. Réalité réseau : RSSI, nombre de roaming, jitter de ping, sanity du résolveur DNS.
3. Saturation backend : taux d’erreur, latence, profondeur des files, utilisation disque, I/O wait.

Règle : Si l’appareil est chaud, manque de stockage, ou tient des wake locks, ne perdez pas de temps à blâmer le réseau en premier.

Second : Identifiez le mode de panne (tempête de réessais, throttling, ou crash dur)

• Tempête de réessais : les logs montrent des boucles serrées, des timeouts, des réessais immédiats, des tentatives de reconnexion répétées.
• Throttling : Thermalservice montre un statut qui monte ; le CPU semble « acceptable » mais l’UI saccade ; perte d’images caméra.
• Crash dur : tombstones, exceptions fatales, traces ANR ; souvent déclenchés par mémoire insuffisante ou pression disque.

Troisième : Appliquez la plus petite atténuation sûre

L’atténuation doit réduire la charge, pas l’augmenter.

• Désactiver ou dégrader : baisser le bitrate vidéo, mettre en pause les uploads si RSSI faible, réduire la fréquence de preview caméra, différer l’inférence ML.
• Backoff et plafonnement : backoff exponentiel avec jitter, nombre max de réessais, coupe‑circuit, endpoints idempotents.
• Arrêter l’hémorragie : mettre en pause le déploiement, rollback des builds, quarantainer un changement de politique.

Quatrième : Corriger la cause racine réelle avec des garde‑fous

Quand vous livrez le correctif, ajoutez des garde‑fous pour que la même classe de panne ne revienne pas sournoisement :

• budgets d’énergie par workflow
• seuils thermiques déclenchant une dégradation gracieuse
• comportement priorisant le hors‑ligne avec UX explicite
• gating par qualité réseau (ne pas tenter le streaming en RF faible)
• anneaux de mise à jour et fixation des builds

Erreurs courantes (symptômes → cause racine → correctif)

1) « L’autonomie est terrible, même quand je ne l’utilise pas »

Symptômes : L’appareil meurt en plein service ; chaud en « idle » ; les graphiques d’usage pointent votre app.

Cause racine : Wake locks, pipeline caméra chaude, réessais agressifs, ou scans/ML continus.

Correctif : Retirez les wake locks inutiles ; implémentez une activation basée sur l’état ; ajoutez du backoff ; arrêtez le travail quand l’écran est éteint ou que le workflow est terminé ; mesurez la consommation par fonctionnalité.

2) « Les flux coupent aléatoirement »

Symptômes : Appels vidéo qui gèlent ; boucles de reconnexion ; plaintes liées à certaines salles ou étages.

Cause racine : Roaming, RSSI faible, portails captifs, instabilité du tether Bluetooth, ou band steering des AP.

Correctif : Restreindre le streaming en direct selon la qualité réseau ; supporter les sessions reprenables ; ajuster le Wi‑Fi ; préférer le stockage‑puis‑envoi dans les zones mortes.

3) « L’application est lente, mais le backend a l’air ok »

Symptômes : Latence serveur normale ; les utilisateurs perçoivent un lag ; l’appareil donne une impression de « collant ».

Cause racine : Throttling thermique, contention du thread UI, ou CPU appareil saturé par du travail en arrière-plan.

Correctif : Profilez sur l’appareil ; réduisez le framerate ; poussez le travail hors du thread UI ; ajoutez un comportement conscient du thermique ; réduisez le coût de la preview caméra.

4) « Après une mise à jour, tout est bizarre »

Symptômes : Pics de tickets support ; comportement incohérent ; seulement certains appareils touchés.

Cause racine : Déploiement partiel, builds OS mélangés, dérive de politiques, ou régression dans la pile radio/permissions.

Correctif : Utilisez des anneaux de déploiement ; appliquez la fixation des builds ; tenez un inventaire ; validez les politiques sur un groupe pilote ; testez les chemins de rollback.

5) « L’appareil est connecté au Wi‑Fi mais rien ne fonctionne »

Symptômes : Icône Wi‑Fi présente ; timeouts applicatifs ; échecs DNS ; webviews affichant des pages de connexion.

Cause racine : Portail captif, DNS bloqué, besoins proxy, ou règles firewall cassant TLS.

Correctif : Détecter le portail captif ; provisionner correctement le Wi‑Fi entreprise (802.1X si besoin) ; autoriser les endpoints requis ; éviter les hypothèses fragiles sur l’accès Internet ouvert.

6) « Les utilisateurs n’utilisent pas la fonctionnalité que nous avons construite »

Symptômes : La télémétrie montre un faible engagement ; la formation n’a pas aidé ; la fonctionnalité est techniquement solide.

Cause racine : Gêne sociale, signaux de confidentialité peu clairs, ou inadéquation workflow (voix dans des lieux calmes, caméra dans des zones sensibles).

Correctif : Redessinez l’interaction pour l’environnement ; fournissez des indicateurs clairs d’enregistrement ; ajoutez des politiques physiques et de la signalisation ; choisissez des cas d’usage où l’appareil est acceptable.

Checklists / plan étape par étape

Étape par étape : déployer des lunettes intelligentes sans incident au ralenti

1. Choisir le bon cas d’usage. Si la valeur nécessite un enregistrement constant en espaces publics, attendez-vous à des frictions politiques. Commencez dans des environnements contrôlés (entrepôt, service terrain, fabrication).
2. Définir des SLO qui correspondent à la réalité. Inclure la survie de la batterie par poste, le taux de reconnexion, le temps jusqu’à la première image, et l’achèvement des tâches hors‑ligne — pas seulement la disponibilité API.
3. Concevoir pour le hors‑ligne par défaut. Stocker‑puis‑envoyer, uploads reprenables, et retour UX explicite quand le réseau est mauvais.
4. Implémenter des gates de qualité réseau. Ne pas tenter le streaming haut débit en dessous d’un seuil de signal ; dégrader gracieusement.
5. Instrumenter la puissance et les thermiques. Capturer la décharge batterie par workflow, les transitions d’état thermique, et l’utilisation CPU pendant « l’inactivité ».
6. Construire des anneaux de mise à jour. Labo → pilote → large. Fixer les builds. Suivre les empreintes. Faire du rollback une routine, pas un exploit.
7. Hygiène d’identité et de politique de flotte. Enrôler les appareils, imposer des codes, gérer les certificats, et standardiser les profils Wi‑Fi.
8. Budget de logs et rotation. Limiter les logs sur l’appareil, faire pivoter les logs serveur, et alerter sur l’usage disque. L’observabilité ne doit pas brique l’appareil.
9. Sécurité qui respecte l’ergonomie. Un MFA qui exige de taper de longs codes sur un affichage facial n’est pas « sécurisé », c’est « inutilisé ». Utilisez une identité liée à l’appareil et des flux de réauthentification courts.
10. Former sur le comportement, pas sur les fonctionnalités. Apprendre quand ne pas l’utiliser, comment signaler l’enregistrement, et comment gérer les zones sensibles.
11. Planifier la recharge comme on planifie les pièces de rechange. Standardiser les chargeurs, étiqueter les ports, éviter les charges USB aléatoires, et traiter les stations de charge comme de l’infrastructure.
12. Organiser des game days. Simuler portail captif, tempêtes de roaming, et dégradation backend. Confirmer que l’appareil échoue gracieusement.

Checklist : pré‑vol avant un pilote

• Tous les appareils enrôlés, inventorés et étiquetés
• Empreinte build OS unique sur la flotte
• Profils Wi‑Fi testés sur des lieux réels (y compris zones mortes)
• Mode hors‑ligne testé et communiqué aux utilisateurs
• Backoff/circuit breakers validés (pas de boucles 0ms)
• Télémétrie thermique et batterie activée avec tableaux de bord
• Politique de confidentialité documentée pour l’environnement (règles d’enregistrement)
• Plan de rollback répété

Checklist : quoi logger (et quoi éviter)

• Logger : début/fin de session, tentatives de reconnexion, instantanés de qualité réseau, changements d’état thermique, décharge batterie par workflow, profondeur de la file d’uploads, signatures de crash.
• Éviter : dumps bruts de capteurs à haute fréquence, logs debug non bornés, et contenu personnellement sensible sauf si vous avez une gouvernance explicite et des contrôles de rétention.

FAQ

Est‑ce que Google Glass était « en avance sur son temps » ou juste une mauvaise idée ?

Les deux. L’idée centrale — assistance mains libres et lisible en un coup d’œil — était solide. Le timing a buté sur des batteries immatures, des schémas d’interaction maladroits, et un public qui considérait les caméras faciales comme hostiles.

Pourquoi le rejet public a‑t‑il tant d’impact, techniquement ?

Parce qu’il a réduit l’usage réel, ce qui a tari les boucles de rétroaction naturelles du produit et a normalisé les politiques « ne pas utiliser ici ». C’est effectivement du temps d’arrêt pour le contexte principal dont Glass avait besoin.

Quel était le plus grand défi opérationnel pour les lunettes intelligentes ?

La puissance et la variabilité réseau. Vous pouvez construire un backend stable et quand même échouer si l’appareil passe sa journée à faire du roaming dans le chaos RF en essayant d’exécuter un travail caméra intensif sur une petite batterie.

Pourquoi le tethering à un téléphone pose‑t‑il autant de problèmes ?

Il multiplie les domaines de panne : fiabilité Bluetooth, restrictions d’arrière‑plan de l’OS du téléphone, batterie du téléphone, et comportement utilisateur. Vous exploitez un cluster à deux nœuds dont l’un vit dans une poche.

Comment les déploiements enterprise évitent‑ils le problème « maladroit en public » ?

Ils choisissent des environnements où le contrat social est différent (uniformes, équipement de sécurité, accès contrôlé). Ils établissent aussi des règles explicites d’enregistrement et font de l’appareil une partie intégrante du workflow, pas une déclaration de mode.

Quelle est la première métrique que vous ajouteriez pour une flotte type Glass ?

La survie de la batterie par poste, mesurée par workflow. Pas juste le « pourcentage de batterie », mais « pourcentage consommé par le scan vs le streaming vs l’inactivité ». Ça vous dit ce qu’il faut corriger.

Comment prévenir les tempêtes de réessais sur les wearables ?

Backoff exponentiel avec jitter, un plafond dur sur les réessais, coupe‑circuits, et endpoints serveur idempotents. Puis testez sous perte de paquets et roaming — pas seulement sur un Wi‑Fi parfait.

Quel est un signe courant que vous êtes en throttling thermique ?

Un lag perçu par l’utilisateur qui n’apparaît pas dans la latence backend, plus une montée de la température de l’appareil et des taux d’images incohérents. On a l’impression d’une « lenteur aléatoire » parce que c’est la physique, pas les chemins de code.

Si vous deviez donner un seul conseil avant de développer un logiciel pour lunettes intelligentes ?

Budgétez l’énergie et le réseau comme vous budgétez de l’argent. Si votre conception suppose une connectivité parfaite et une batterie infinie, vous ne construisez pas un produit — vous construisez une démo.

Google Glass a‑t‑il « échoué », ou a‑t‑il simplement changé de marché ?

Glass grand public n’a pas trouvé d’équilibre social acceptable. L’angle entreprise convient mieux parce que le ROI peut compenser la gêne, et les environnements peuvent appliquer des politiques.

Conclusion : prochaines étapes pratiques

Google Glass rappelle que le futur n’est pas bloqué par l’imagination. Il est bloqué par les batteries, les thermiques, le roaming, et le fait que les gens n’aiment pas se sentir enregistrés. Si vous expédiez des wearables — ou tout appareil edge qui vit dans un espace humain désordonné — traitez la « gêne » comme un signal de production, pas comme un problème marketing.

Prochaines étapes que vous pouvez entreprendre cette semaine :

1. Rédiger des SLO qui incluent la survie de la batterie et l’achèvement hors‑ligne.
2. Ajouter la télémétrie thermique et énergétique liée aux workflows.
3. Auditer le comportement de retry du client ; éliminer les réessais 0ms.
4. Cartographier les zones RF mortes et concevoir des modes explicites hors‑ligne / faible signal.
5. Introduire des anneaux de mise à jour et la fixation des builds avant de scaler la flotte.
6. Documenter les règles de confidentialité pour les environnements où vous opérez — et les faire respecter via l’UX, pas l’espoir.

Le futur peut toujours tenir sur votre visage. Mais il doit survivre une journée de travail, un mauvais point d’accès, un client sceptique, et une journée chaude. Ce n’est pas de la science‑fiction. C’est des opérations.