Public :Ce guide s'adresse aux acheteurs OEM/ODM, aux propriétaires de marques et aux intégrateurs de systèmes scolaires qui évaluent l'architecture cloud derrière un parc de stylos de lecture intelligents. Il suppose une connaissance pratique de MQTT et des bases du réseau cloud, mais chaque concept est ancré dans les onze modèles de production que nous expédions actuellement : B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2 et Y6.
Quand un enfant tape sur un mot à Berlin et qu'un parent ouvre un tableau de bord à Riyad trois secondes plus tard, cette latence n'est pas de la magie. C'est le résultat d'une topologie MQTT soigneusement optimisée fonctionnant sur des courtiers régionaux, avec une conception déterministe des topics, des identifiants par locataire et un ensemble de règles de contre-pression qui empêche une classe de quarante appareils de submerger un seul nœud de bordure. Les importateurs voient rarement cette couche, pourtant elle détermine si un programme scolaire de 5 000 unités survit au contact d'une vraie salle de classe.
Cet article passe en revue l'architecture cloud IoT derrière nos onze modèles de stylos de lecture. Nous couvrons l'espace de noms des topics MQTT, la sélection QoS par classe de charge utile, le dimensionnement du parc de courtiers, la stratégie d'isolation des locataires, le modèle d'ombre d'appareil, le pipeline de télémétrie vers l'analyse, le transfert OTA, la résidence régionale et les tableaux de bord opérationnels que nous exposons aux distributeurs. À la fin, vous saurez exactement quoi demander à un fabricant avant de vous engager sur une seule SKU pour une gamme de stylos de lecture connectés.
1. Pourquoi MQTT est le bon transport pour un stylo de lecture
Le stylo de lecture est un appareil à faible bande passante, tolérant à la latence et à connexion intermittente. Ce profil correspond mieux à MQTT qu'à HTTP/2 ou au streaming gRPC. MQTT est un protocole publish/subscribe fonctionnant sur TCP/TLS via le port 8883 ; l'indicateur de session persistante combiné au QoS 1 nous garantit une livraison au moins une fois pour un résultat de quiz de vocabulaire sans payer le coût d'une requête HTTP complète. Notre benchmark sur les onze modèles affiche une charge utile uplink moyenne de 320 octets pour un événement de tap simple et de 1,8 Ko pour un résumé de session complet ; HTTP consumerait 1,4 Ko d'en-têtes par appel, ce qui fait que MQTT économise environ 70 % des octets sur la radio. Les B1, B2 et P2 utilisent un chemin Wi-Fi uniquement (2,4 GHz, WPA2-Enterprise pris en charge), tandis que les F8, K7, KF1, L5, Q6, Q8, T2 et Y6 ajoutent un compagnon Bluetooth 5.0 LE pour l'appairage avec l'application parentale.
Conseil acheteur : Demandez à tout fabricant candidat si le cloud utilise MQTT 5.0 avec des abonnements partagés et des codes de raison. MQTT 5 est incontournable pour les parcs de plus de 1 000 appareils car le nouveau champ de code de raison élimine les boucles de réessai silencieuses que vous voyez sur les parcs MQTT 3.1.1.
La couche de courtiers que nous exploitons utilise une topologie leader/suiveur : trois grappes régionales à Francfort, Singapour et São Paulo, chacune précédée par un équilibreur de charge anycast mondial. Les appareils résolventmqtt.smartreadingpen.cloudvers la grappe saine la plus proche en utilisant le flux de géolocalisation IP actualisé toutes les six heures. Le temps de connexion médian sur notre parc 2025 de plus de 47 000 stylos déployés est de 412 ms, et le 95e percentile est de 1 180 ms.
2. Espace de noms des topics MQTT sur onze modèles
La conception des topics est l'épine dorsale de toute architecture IoT. Nous suivons un modèle à cinq segments : rp/{region}/{tenant}/{model}/{serial}/{direction}/{event}. Le segment region est l'un de eu, na, la, mea, apac ou cn. Le tenant est le distributeur, le district scolaire ou le propriétaire de la marque. Le model est l'un des onze SKU de production. Le serial est l'identifiant unique à 12 caractères de l'appareil gravé sur le boîtier arrière.
| Direction | Suffixe du topic | QoS | Rétention | Charge utile typique |
|---|---|---|---|---|
| Télééchange uplink | /telemetry/tap |
1 | faux | 320 octets JSON |
| Télééchange uplink | /telemetry/session |
1 | vrai | 1,8 Ko JSON |
| Commande downlink | /cmd/ota |
2 | vrai | 2,4 Ko CBOR |
| Commande downlink | /cmd/policy |
2 | vrai | 0,6 Ko JSON |
| Statut uplink | /status/heartbeat |
0 | faux | 64 B |
| Statut liaison montante | /status/error |
1 | false | 220 B |
Le /status/heartbeat sujet utilise QoS 0 car la perte d'un seul ping de 64 octets est sans conséquence et notre pipeline analytique reconstruit la présence à partir des événements de session. Les commandes OTA empruntent QoS 2 avec rétention afin qu'un appareil se reconnectant après un long sommeil reçoive toujours le pointeur de micrologiciel. Les stylos de référence L5 et T2 émettent environ 1 200 battements de cœur par journée scolaire active ; les stylos d'entrée B1 et P2 en émettent environ 480 car leur cycle de veille profonde par défaut est de 22 secondes contre 8 secondes pour le niveau de référence.
3. Choix de QoS, de rétention et de persistance
Le choix du bon QoS par sujet est un compromis coût versus durabilité. Notre règle empirique interne : QoS 0 pour les heartbeats et les balises de progression, QoS 1 pour toute donnée dont dépend le tableau de bord parental, QoS 2 pour l'OTA, les push de politique et les commandes de wipe à distance parentales. Un district de 5 000 stylos génère environ 14,2 millions de messages QoS 1 par semaine scolaire ; les promouvoir tous en QoS 2 triplerait notre taux d'écriture disque du broker et n'ajouterait aucune durabilité réelle car l'état de session est déjà répliqué en aval.
La rétention n'est utilisée que sur les sujets de commande et sur le sujet de résumé de session. La rétention sur la télémétrie ferait qu'un nouvel abonné recevrait l'historique de contacts obsolète à chaque fois, ce qui corromprait la vue analytique. La rétention sur /telemetry/session est définie sur true afin qu'un enseignant ouvrant le tableau de bord en milieu de cours voie l'état de session actuel sans attendre le prochain événement. Le message rétenu expire après 24 heures et est écrasé par le prochain résumé de session publié.
4. Isolation des locataires et portée des identifiants
L'isolation des locataires est l'exigence la plus difficile pour les déploiements scolaires et éditoriaux. Nous appliquons l'isolation à quatre couches. Premièrement, le nom d'utilisateur de connexion suit le format {tenant_id}:{device_serial} ; l'ACL du broker rejette tout sujet qui ne correspond pas au préfixe du locataire. Deuxièmement, le certificat de l'appareil est lié à une clé par appareil émise par une sous-CA interne, de sorte qu'un identifiant volé ne peut pas être utilisé pour s'abonner au parc d'un autre locataire. Troisièmement, l'entrepôt analytique utilise la sécurité au niveau des lignes indexée par tenant_id dans PostgreSQL. Quatrièmement, le stockage d'objets pour les buckets multimédias des livres OID est espacé de noms par locataire et signé avec des URL pré-signées à courte durée de vie (15 minutes).
Pour les propriétaires de marque exploitant un programme de marque blanche, nous proposons une option Apportez Votre Propre Certificat (BYOC). Le partenaire OEM télécharge une CA racine, nous émettons des certificats d'appareil sous celle-ci, et le broker accepte à la fois la CA d'usine et la CA de marque. Nous avons livré ce modèle à un distributeur du Golfe exploitant 12 000 stylos dans 38 écoles ; leur équipe de sécurité de l'information effectue un test d'intrusion indépendant tous les douze mois et le broker passe proprement avec un CVSS moyen de 1,4 sur les deux derniers audits.
5. Jumeau d'appareil et rejeu hors ligne
Chaque stylo de lecture connecté maintient un document JSON que nous appelons le jumeau d'appareil. Le jumeau est l'état canonique de l'appareil tel que compris par le cloud : version actuelle du micrologiciel (B1/B2 2.4.7, F8 3.1.2, K7/KF1 1.9.5, L5 4.2.0, P2 2.0.3, Q6/Q8 3.3.1, T2/Y6 2.6.4), date de dernière calibration, version de la bibliothèque de livres OID, hachage de la politique parentale et préférence linguistique de l'utilisateur (l'un des 12 paramètres régionaux pris en charge). Le jumeau est miroité sur l'appareil et sur le cloud ; les conflits sont résolus par principe du dernier rédacteur avec le cloud comme auteur.
Lorsqu'un stylo a été hors ligne pendant plus de 30 minutes, le cloud met en file d'attente les commandes entrantes au lieu de les supprimer. Lors de la reconnexion, l'appareil émet une demande de backlog et le broker rejoue la file d'attente de commandes retenues. La fenêtre de rejeu est limitée à 7 jours ; les commandes plus anciennes sont purgées et le tableau de bord affiche un badge « mise à jour de politique manquée » afin que le parent ou l'enseignant puisse les réappliquer manuellement. Ce modèle est essentiel pour les T2 et Y6, qui sont vendus avec des batteries étendues (2 500 mAh et 2 000 mAh respectivement) et peuvent dormir pendant deux à trois semaines dans les scénarios de faible utilisation.
6. Pipeline de télémétrie et couche analytique
Le flux de télémétrie se divise au niveau du broker en deux pipelines. Le chemin chaud est un cluster Apache Kafka avec une rétention de 14 jours ; le chemin froid atterrit dans un entrepôt Parquet partitionné pour l'analyse longitudinale. Le chemin chaud alimente le tableau de bord parental, qui nécessite une fraîcheur inférieure à 3 secondes. Le chemin froid alimente notre analytique produit interne, l'évaluation des tests A/B et les exports de rapports au niveau du district que les écoles demandent à la fin de chaque trimestre.
Chaque événement de télémétrie est enrichi à l'ingestion par tenant_id, modèle, version du micrologiciel et un géohachage grossier (précision 25 km, délibérément flou pour protéger la vie privée de localisation des enfants en vertu de COPPA et GDPR). L'étape d'enrichissement s'exécute en tant que topologie Kafka Streams sur trois pods consommateurs par région. La latence médiane de bout en bout du contact de l'appareil au rendu du tableau de bord est de 2,1 secondes dans le cluster UE et de 2,7 secondes dans le cluster APAC, mesurée au 95e percentile.
7. Transfert OTA et cycle de vie du micrologiciel
Le micrologiciel OTA emprunte un sujet dédié séparé /cmd/ota avec QoS 2 et une rétention de commande de 14 jours. Lorsque nous publions la version 2.4.7 du micrologiciel pour la famille B1/B2, le broker distribue à chaque appareil connecté correspondant à {tenant}/{model}/B1*. Les appareils hors ligne reçoivent la commande à la reconnexion ; les appareils en ligne commencent le téléchargement immédiatement mais diffèrent l'installation jusqu'à ce que l'enfant appuie sur le bouton d'alimentation. Ce modèle d'installation confirmé par l'utilisateur élimine le mode de défaillance « appareil bloqué en cours de classe » qui a historiquement causé des migraines aux équipes informatiques scolaires.
La charge utile OTA elle-même est un manifeste signé pointant vers un binaire morcelé dans le stockage d'objets. Nous divisons le micrologiciel en morceaux de 96 Ko afin qu'une coupure ne coûte qu'un seul morceau plutôt que l'image complète. Les Q6 et Q8 utilisent une taille de morceau légèrement plus grande de 128 Ko car leur module Wi-Fi affiche un débit plus élevé ; les références L5, T2 et Y6 fonctionnent sur un morceau plus petit de 64 Ko pour la résilience dans un Wi-Fi de salle de classe congestionné. Sur nos 86 versions de micrologiciel depuis le lancement, le taux de succès d'installation médian est de 98,7 % et le temps médian d'installation est de 14 minutes de la publication au redémarrage.
8. Résidence régionale et souveraineté des données
Les distributeurs dans l'UE, le Golfe et l'Amérique latine demandent régulièrement où les données se trouvent physiquement. La réponse est que nous proposons trois régions de résidence : UE (Francfort), APAC (Singapour) et une option MEA plus récente à Dubaï lancée au T1 2026. Les appareils destinés à l'Arabie saoudite, aux EAU et à l'Égypte se lient au cluster MEA par défaut. Les appareils vendus au Brésil se lient à un nœud de São Paulo qui fait partie de la région LA. Les locataires peuvent choisir de fixer un seul appareil à une région non par défaut via un ticket de support nécessitant une justification écrite ; la substitution est enregistrée dans notre grand livre de conformité pour audit.
Le cluster de Francfort est certifié selon ISO 27001 et SOC 2 Type II ; le cluster de Singapour est en cours d'attestation SOC 2 avec un achèvement prévu au T4 2026. Nous ne proposons pas encore de région de résidence uniquement aux États-Unis ; l'option la plus proche aujourd'hui est le cluster LA avec réplication inter-régions désactivée. Si vous êtes un district scolaire américain avec des attentes strictes alignées sur FERPA, le cluster LA plus un addenda contractuel de traitement des données est la voie actuelle. L'extension future à une région US-Est est sur la feuille de route 2027 et nous sommes ouverts aux lettres d'intention des districts de plus de 2 000 unités.
9. Planification de la capacité et contre-pression
Une classe de 40 élèves tapotant simultanément produit 40 sessions MQTT concurrentes sur le même fragment de broker. Nous dimensionnons chaque fragment pour 8 000 sessions concurrentes, de sorte qu'un seul fragment peut absorber 200 classes complètes avant saturation. Lorsqu'un district déploie un programme de 12 000 unités (notre plus grand déploiement unique à ce jour est un réseau scolaire de Riyad), nous pré-chauffons trois fragments dans la région cible 48 heures avant le début du déploiement. La contre-pression est implémentée à l'aide des fonctionnalités MQTT 5 receive-maximum et message-alias : lorsqu'un fragment approche 75 % de saturation, le broker limite d'abord les battements de cœur QoS 0 et ne passe au QoS 1 que si la saturation dépasse 90 %.
La contre-pression est également la raison pour laquelle nous décourageons les parcs dépassant 50 000 stylos d'un seul locataire sur un seul cluster de brokers. La clé de fragmentage est tenant_id, donc un grand locataire peut déséquilibrer un cluster. Nous divisons les locataires surdimensionnés sur deux clusters en utilisant un modulo déterministe sur le préfixe de série de l'appareil. La division est invisible pour le locataire ; le tableau de bord voit un parc cohérent unique et le réconciliateur d'entrepôt rassemble les événements par tenant_id plus série.
10. Observabilité, SLO et manuels d'exploitation
La plateforme cloud émet 18 métriques par fragment de broker (CPU, RSS, nombre de descripteurs de fichiers, nombre d'abonnements, octets conservés, nombre de messages QoS 1 en vol, histogramme des codes de retour MQTT 5, etc.). Nous alertons sur le SLO qui compte : 99,5 % de disponibilité mensuelle pour le tableau de bord parental et 99,9 % pour le pipeline OTA. L'écart de 0,4 point de pourcentage reflète la réalité que l'OTA tolère des retry plus longs et est donc soumis à une barre interne plus stricte.
Les manuels d'exploitation couvrent douze scénarios incluant le split-brain du broker, la rotation des certificats, la mauvaise configuration des locataires et l'erreur redoutée « éditeur ayant mal saisi le préfixe du sujet ». Chaque manuel a un test de chaos apparié que nous exécutons en staging chaque dimanche à 03h00 UTC. Le temps moyen de détection sur les 12 scénarios est de 4,8 minutes ; le temps moyen de mitigation est de 22 minutes. Notre parc vivant de 47 000 stylos a généré 23 incidents de broker en 2025, dont 19 ont été atténués dans la cible de 30 minutes et les 4 restants ont été classés comme dégradation partielle sans perte de données.
FAQ : Architecture cloud IoT du stylo de lecture (MQTT)
Lectures complémentaires
- Mécanisme de mise à jour du micrologiciel OTA du stylo de lecture
- Chiffrement des données du stylo de lecture : AES-128 vs AES-256
- Contrôle parental du stylo de lecture et COPPA
- Comment choisir un fabricant de stylos de lecture
- Liste de contrôle des spécifications du stylo de lecture
- Service OEM de marque blanche pour stylo de lecture
- Demander un devis pour les stylos de lecture connectés
Si votre programme nécessite 1 000+ stylos de lecture connectés avec un cluster MQTT dédié, une résidence multi-région ou des certificats BYOC, répondez à tout e-mail de notre équipe avec le mot CONNECT et nous vous enverrons un résumé d'architecture d'une page dimensionné pour votre parc.