Ni accuchek ni Glucofi ne sont des dispositifs médicaux. Ils ne remplacent ni le lecteur, ni l'avis du médecin. Toutes les valeurs importantes se vérifient sur l'écran du lecteur, et toute décision sur l'insuline reste celle du médecin.
### Au programme 1. Pourquoi ce projet ? (vous êtes ici) [](https://librenard.fr/wiki/uploads/images/gallery/2026-10/universite.png) 2. Le lecteur vu par Linux 3. La langue du lecteur : ISO/IEEE 11073 4. La conversation, pas à pas 5. Identité, horloge et marqueurs repas 6. Blinder le code : tests, traces et fuzzing 7. Installer et utiliser accuchek 8. Et ensuite : Glucofi # Le lecteur vu par Linux Avant de parler au lecteur, il faut d'abord savoir comment Linux le voit. Et la bonne nouvelle, c'est que Linux, c'est trop bien et nous donne déjà plein d'indices, il suffit de les lire. ### Ce que dit le noyau au branchement Quand on branche l'Accu-Chek Guide, le noyau l'annonce tout de suite dans ses journaux (`dmesg` ou `journalctl -k`) : ```bash usb 3-1: new full-speed USB device number 59 using xhci_hcd usb 3-1: New USB device found, idVendor=173a, idProduct=21d5, bcdDevice= 1.00 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-1: Product: ACCU-CHEK Guide usb 3-1: Manufacturer: Roche ``` Deux numéros sont importants ici : - **idVendor = 173a** : c'est l'identifiant du fabricant, Roche ; - **idProduct = 21d5** : c'est le modèle, ici l'Accu-Chek Guide. Ce couple `173a:21d5`, c'est un peu la plaque d'immatriculation du lecteur. accuchek s'en sert pour savoir à qui il a affaire, et il ne touche à **aucun autre** périphérique USB. ### Regarder sous le capot avec lsusb Pour avoir plus de détails, la commande `lsusb -v` décrit tout ce que le lecteur déclare. Voici les parties qui nous intéressent : ```bash Bus 003 Device 118: ID 173a:21d5 Roche bNumConfigurations 1 Configuration Descriptor: bNumInterfaces 1 bConfigurationValue 1 Interface Descriptor: bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 15 iInterface 4 Personal Healthcare Device Class Endpoint Descriptor: bEndpointAddress 0x81 EP 1 IN Transfer Type Bulk wMaxPacketSize 0x0040 1x 64 bytes Endpoint Descriptor: bEndpointAddress 0x01 EP 1 OUT Transfer Type Bulk wMaxPacketSize 0x0040 1x 64 bytes ``` Il y a une ligne qui m'a mis sur la piste : **bInterfaceClass 15, "Personal Healthcare Device Class"** (PHDC). Ce n'est pas un protocole maison bricolé par Roche (ce qui nous arrange pas mal), c'est une classe USB standard faite pour les appareils de santé personnels : tensiomètres, balances, glucomètres... On y reviendra au chapitre suivant. Le reste se lit assez facilement : - **une seule configuration, une seule interface** : le lecteur ne sait faire qu'une chose ; - **deux "endpoints"** (des tuyaux) de type **Bulk** : `0x81` pour recevoir (du lecteur vers le PC, "IN") et `0x01` pour envoyer (du PC vers le lecteur, "OUT") ; - **64 octets** maximum par paquet.Petite astuce pour s'y retrouver : en USB, le sens est toujours vu depuis le PC. "IN" veut dire "qui rentre dans le PC", donc ce que le lecteur nous envoie. Le bit de poids fort de l'adresse (le `8` de `0x81`) indique justement ce sens.
### Comment accuchek reconnaît le lecteur Dans `main.cpp`, la fonction `addDeviceIfAccuChek` passe en revue tous les périphériques USB et applique une série de filtres. Un périphérique n'est retenu que s'il coche toutes les cases : 1. [](https://librenard.fr/wiki/uploads/images/gallery/2026-10/cle-usb.png) son couple vendeur:produit est dans la liste des lecteurs connus (sinon on ne l'ouvre même pas) ; 2. il a exactement 1 configuration, 1 interface et 1 "alt setting" ; 3. il a exactement 2 endpoints de 64 octets, qui ne sont pas de type "interrupt" ; 4. il y en a un dans chaque sens (un IN et un OUT) ; 5. on arrive à l'ouvrir et à lire son nom de fabricant et de produit. La liste des lecteurs connus est intégrée au programme :| Identifiant USB | Lecteur |
|---|---|
173a:21d5 | Accu-Chek Guide (modèle 925), testé |
173a:21d7 | modèle Roche similaire, non testé |
173a:21d8 | Relion Platinum (modèle 982) |
Le préfixe `70-` du fichier n'est pas là par hasard : la règle doit passer avant `73-seat-late.rules`, celle qui applique réellement les étiquettes `uaccess`. Avec un numéro plus grand, la règle serait lue trop tard et ne servirait à rien.
Après l'installation de la règle, on recharge udev : ```bash sudo udevadm control --reload sudo udevadm trigger --subsystem-match=usb ``` Puis on débranche et on rebranche le lecteur. À partir de là, accuchek tourne avec les droits normaux de l'utilisateur. ### Savoir pourquoi ça ne marche pas J'ai aussi fait en sorte qu'accuchek distingue bien les cas "pas de lecteur" et "lecteur trouvé mais accès refusé". Si un lecteur connu est sur le bus mais que `libusb_open` répond `LIBUSB_ERROR_ACCESS`, le programme le retient et le dit clairement : ```bash $ accuchek accuchek: permission denied on USB meter 173a:21d5 on bus 003 device 118 $ echo $? 3 ``` Le code de sortie **3** veut dire "la règle udev manque ou n'est pas chargée", alors que le code **2** veut dire "aucun lecteur connu sur le bus". Ça a l'air d'un détail, mais c'est ce qui permet à Glucofi d'afficher le bon message ("rebranchez le lecteur" ou "relancez l'installation") au lieu d'une erreur qu'on ne comprendrait pas forcément. # La langue du lecteur : ISO/IEEE 11073 Ouvrir le tuyau USB, c'est bien. Mais si on envoie n'importe quoi dedans, le lecteur ne répond rien, ou pire, il coupe la communication. Il faut parler sa langue. Et c'est là que commence vraiment le **reverse engineering**. ### D'où vient la connaissance du protocole ?[](https://librenard.fr/wiki/uploads/images/gallery/2026-10/medecin.png) Roche ne publie pas de documentation sur le protocole de ses lecteurs. Par contre, il existe un endroit où quelqu'un l'a déjà implémenté : le pilote Roche du [Tidepool uploader](https://github.com/tidepool-org/uploader/tree/master/lib/drivers/roche), écrit en JavaScript. Le chemin a donc été le suivant : 1. **emogenet**, l'auteur d'origine, a lu le code JavaScript de Tidepool, récupéré les constantes et l'ordre des messages, et réécrit l'ensemble en C++ au-dessus de libusb. Il le dit lui-même en commentaire dans le code : le pilote Tidepool "ne marche que dans Chrome", et son auteur "avait sans doute accès à un manuel décrivant le protocole". 2. En lisant ces constantes, on retrouve des noms comme `MDC_ATTR_TIME_ABS` ou `MDC_MOC_VMO_PMSTORE`. En cherchant ces noms, on tombe sur la norme **ISO/IEEE 11073-20601**, celle des "Personal Health Devices" de la [Continua Health Alliance](https://en.wikipedia.org/wiki/Continua_Health_Alliance). C'est le protocole qui va avec la classe USB PHDC qu'on a vue dans `lsusb`. 3. Pour tout ce que Tidepool ne lisait pas (l'identité du lecteur, son horloge, les marqueurs repas), je suis reparti de la norme et des projets libres qui l'implémentent, comme [Antidote](https://github.com/signove/antidote), puis j'ai comparé avec les vraies réponses de notre Accu-Chek Guide, capturés octets par octet.Pour voir passer chaque paquet, il suffit de lancer `ACCUCHEK_DBG=1 accuchek`. Le programme écrit alors sur la sortie d'erreur un "hexdump" de chaque message envoyé et reçu, avec le numéro de l'étape. C'est l'outil principal de tout ce travail : on regarde les octets, on fait une hypothèse, on vérifie sur le message suivant.
### Le principe : un "agent" et un "manager" Dans cette norme, il y a deux rôles : - **l'agent** : l'appareil de santé, ici le lecteur. C'est lui qui a les données ; - **le manager** : celui qui les récupère, ici notre PC. Le lecteur ne se contente pas d'envoyer une liste de chiffres. Il se décrit comme un ensemble d'**objets**, un peu comme une petite base de données : - l'objet **MDS** (Medical Device System, handle 0) : le lecteur lui-même, avec son fabricant, son modèle, son numéro de série, son horloge ; - l'objet **PM-Store** (Persistent Metric Store) : la mémoire où sont rangées les mesures ; - des **segments** à l'intérieur du PM-Store : un segment pour les glycémies, un pour les mesures de contrôle, un pour les erreurs, un pour les marqueurs repas... Chaque objet a un numéro (son "handle") et des **attributs**. Chaque attribut a un identifiant numérique standard, c'est la "nomenclature MDC". Par exemple :| Nom | Valeur | Ce que c'est |
|---|---|---|
MDC_MOC_VMO_PMSTORE | 61 | la classe "PM-Store", la mémoire des mesures |
MDC_ATTR_NUM_SEG | 2385 | nombre de segments dans le PM-Store |
MDC_ATTR_ID_MODEL | 2344 | fabricant et modèle |
MDC_ATTR_TIME_ABS | 2439 | l'horloge du lecteur |
MDC_ATTR_SEG_USAGE_CNT | 2427 | nombre d'entrées dans un segment |
MDC_CTXT_GLU_MEAL_FASTING | 29268 | marqueur "à jeun" |
| Type | Message | Qui l'envoie |
|---|---|---|
E2 00 | demande d'association ("on se connecte ?") | le lecteur |
E3 00 | réponse d'association ("d'accord") | le PC |
E4 00 | demande de fin d'association ("on raccroche") | le PC |
E5 00 | réponse de fin d'association | le lecteur |
E6 00 | abandon ("je coupe tout") | l'un ou l'autre |
E7 00 | message de données (tout le reste) | les deux |
| Code | Signification |
|---|---|
01 01 | le lecteur signale un événement et attend un accusé de réception |
02 01 | l'accusé de réception de cet événement |
01 03 | demande de lecture d'attributs (GET) |
02 03 | réponse à cette lecture |
01 07 | demande d'action (lister les segments, lancer un transfert, régler l'heure...) |
02 07 | réponse à cette action |
Une trace enregistrée sur un vrai lecteur contient **toutes** les mesures de la personne. Ce sont des données de santé : on ne la publie pas, on ne la met pas dans un dépôt Git. Le `.gitignore` d'accuchek ignore d'ailleurs les fichiers `*.trace` en dehors des exemples de test.
#### Vue d'ensemble| Étape | Sens | Message |
|---|---|---|
| 1 | PC → lecteur | "toc toc" : requête USB GET_STATUS |
| 2 | lecteur → PC | demande d'association |
| 3 | PC → lecteur | association acceptée |
| 4 | lecteur → PC | description de ses objets (configuration) |
| 5 | PC → lecteur | "configuration bien reçue" |
| 6-7 | aller-retour | identité et horloge du lecteur (MDS) |
| 8-9 | aller-retour | liste des segments de la mémoire |
| (10-11) | aller-retour | mise à l'heure, seulement si demandée et utile |
| 12... | boucle | transfert des glycémies, avec accusé de réception à chaque paquet |
| ... | boucle | transfert des marqueurs repas |
| fin | aller-retour | fin d'association, on raccroche |
| Instance | Nom | Contenu |
|---|---|---|
| 0 | PMSegGluc | les glycémies |
| 1 | PMSegCtrl | les mesures de contrôle (solution de test) |
| 2 | PMSegError | les erreurs |
| 3 | PMSegCMeal | les marqueurs repas |
Petite anecdote de reverse engineering : dans le code d'origine (et dans Tidepool), ces champs s'appelaient simplement `u0`, `u1` et `u2`, des valeurs "qu'on renvoie telles quelles" sans trop savoir ce qu'elles sont. En les comparant à la norme, on comprend que ce sont l'instance du segment, l'index de la première entrée, le nombre d'entrées et le statut du paquet. Le code garde ces noms, mais on sait maintenant ce qu'il recopie.
La boucle continue jusqu'au paquet dont le statut a le bit `0x40` ("dernier paquet"). Détail qui m'a fait chercher un moment : pendant cette boucle, les invoke-id sont ceux du **lecteur** (`00 20`, `00 21`...). Une fois le segment terminé, il faut revenir à *notre* numérotation, celle de la réponse au déclenchement du transfert. C'est le rôle de la variable `answerInvokeId` dans `transferSegment`. ### Le transfert des marqueurs repas Si le lecteur a un segment de marqueurs repas non vide, on recommence exactement la même danse avec son instance (ici la 3). Les entrées sont plus petites, **10 octets** : ```bash 20 26 09 30 07 31 12 00 date BCD : 2026/09/30 07:31:12 72 54 code repas : 29268 = à jeun ``` Il n'y a pas de valeur de glycémie ici : juste une date et un code. Comment on relie ce marqueur à la bonne mesure ? Je l'explique au chapitre suivant. ### Fin. On raccroche proprement ```bash > E40000020000 < E50000020000 ``` On envoie une demande de fin d'association (`E4 00`, "fin normale") et le lecteur confirme (`E5 00`). Transfert terminé s'affiche sur l'écran du glucomètre Un choix que j'ai fait ici : si cette toute dernière étape échoue (lecteur débranché un poil trop tôt, par exemple), on **garde** quand même les mesures. Tous les paquets ont déjà été confirmés, les données sont complètes, il n'y a aucune raison de les jeter pour un "au revoir" manqué. ### Et si le lecteur coupe en plein milieu ? À n'importe quelle étape, le lecteur peut envoyer un abandon (`E6 00`) au lieu de la réponse attendue. La fonction `receive` le détecte à chaque message reçu et arrête tout avec un message précis, du genre `received association abort request instead of MDS attribute answer`. Pas de mesures à moitié lues : on recommencera. # Identité, horloge et marqueurs repas La version d'origine savait récupérer les glycémies, et c'était déjà beaucoup. Mais pour le suivi de mon proche, il me fallait trois choses en plus : savoir **quel lecteur** on lit, savoir si son **horloge est juste**, et récupérer les **marqueurs repas**. Sans ces marqueurs, impossible de savoir quelle mesure est "la glycémie du matin à jeun", celle sur laquelle repose tout le protocole du médecin. Ce chapitre, c'est la partie que Tidepool ne m'a pas mâchée. Il a fallu repartir de la norme et des vrais octets.[](https://librenard.fr/wiki/uploads/images/gallery/2026-10/universite-1.png) ### Décortiquer la carte d'identité du lecteur Voici la réponse d'un vrai Accu-Chek Guide (modèle 925, firmware v1.9.6) à la demande d'attributs MDS. Le numéro de série, l'identifiant système et l'horloge ont été remplacés, mais la structure est d'origine : ```bash E700 00D4 00D2 00A4 0203 00CC 0000 0008 00C6 en-tête : réponse GET, 8 attributs 0928 000E 0006 526F63686500 0004 39323500 ID_MODEL 0984 000A 0008 0060190000000042 SYS_ID 0A44 0002 4000 DEV_CONFIG_ID 092D 0056 0003 0052 ID_PROD_SPECN, 3 entrées : 0001 0000 001A 73657269616C2D6E756D6265723A20393235303030303030343200 0003 1000 0012 68772D7265766973696F6E3A2047000000000000 0005 0000 0014 66772D7265766973696F6E3A2076312E392E3600 0987 0008 2026100121065800 TIME_ABS 0A45 0010 C000 1F00 FFFFFFFF 0064 000000000000 MDS_TIME_INFO 0A4B 0016 ... REG_CERT_DATA_LIST 0A5A 0008 0001 0004 1011 0002 SYS_TYPE_SPEC_LIST ``` Chaque attribut suit le même schéma : 2 octets d'identifiant, 2 octets de longueur, puis la valeur. Ligne par ligne : - `02 03` : c'est bien la réponse à notre GET. `00 08` : elle contient 8 attributs. - `09 28` (2344, `ID_MODEL`) : deux chaînes de caractères. `526F636865` en ASCII donne **"Roche"**, `393235` donne **"925"**. - `09 84` (2436, `SYS_ID`) : l'identifiant système du lecteur sur 8 octets (un EUI-64), écrit en hexadécimal dans la sortie. - `09 2D` (2349, `ID_PROD_SPECN`) : une liste de "spécifications de production". Chaque entrée a un type : **1** pour le numéro de série, **3** pour la version matérielle, **5** pour le firmware. En ASCII : `serial-number: 92500000042`, `hw-revision: G`, `fw-revision: v1.9.6`. Roche met une étiquette devant la valeur, la fonction `afterLabel` garde ce qui suit le `": "`. - `09 87` (2439, `TIME_ABS`) : l'horloge du lecteur, en BCD : **2026/10/01 21:06:58**. - `0A 45` (2629, `MDS_TIME_INFO`) : les capacités de l'horloge. Les deux premiers octets, `C0 00`, sont des bits. `0x8000` veut dire "j'ai une horloge temps réel" et `0x4000` veut dire **"on peut me mettre à l'heure"**. C'est ce bit que teste le code. - `0A 5A` (2650, `SYS_TYPE_SPEC_LIST`) : le profil d'appareil. `10 11` (4113) correspond au profil "glucomètre" de la norme (ISO/IEEE 11073-10417), en version 2. La confirmation que l'on parle bien à un appareil standard, et pas à un protocole maison. Le décodage est fait par `parseMdsAnswer`, qui parcourt les attributs un par un et ignore ceux qu'il ne connaît pas. Si un lecteur ne donne pas certains attributs, les champs restent vides, et si la réponse n'est pas compréhensible du tout, la sortie indique simplement `"meter": null`. On ne bloque pas le téléchargement des mesures pour une carte d'identité mal lue. ### L'horloge : un détail qui n'en est pas un Le lecteur date chaque mesure avec **sa propre horloge**. Si elle a 25 minutes d'avance, toutes les mesures ont 25 minutes d'avance. Et si elle n'a pas été changée au passage à l'heure d'hiver, une glycémie faite à 6h45 apparaît à 7h45... ou une mesure de 11h30 bascule après midi et sort de la plage "matin". Pour un protocole qui repose sur "la glycémie du matin", c'est gênant. accuchek lit donc l'horloge du lecteur au début de la session et la compare à celle du PC. La sortie JSON le montre : ```json "clock": {"meter": "2026/10/01 21:06:58", "pc": "2026/10/01 20:42:52", "offset_s": 1446, "settable": true, "pc_synchronized": true, "action": "set"} ``` Ici, le lecteur avait 1446 secondes d'avance, soit un peu plus de 24 minutes. [](https://librenard.fr/wiki/uploads/images/gallery/2026-10/temps.png) ### Remettre le lecteur à l'heure, mais prudemment Avec l'option `--set-time`, accuchek peut corriger l'horloge du lecteur. Le message est construit par `buildSetTime` : une action `0C 17` sur l'objet MDS (handle 0), avec la nouvelle date en BCD. Écrire dans un appareil médical, ce n'est pas anodin. J'ai donc mis plusieurs garde-fous, testés dans cet ordre par `decideClock` : 1. on n'a rien demandé : on ne touche à rien (`not_requested`) ; 2. le lecteur n'a pas donné son heure : on ne sait pas, on ne touche à rien (`unknown`) ; 3. le lecteur ne déclare pas le bit "on peut me mettre à l'heure" : on ne touche à rien (`not_settable`) ; 4. l'heure du PC est inconnue : on ne touche à rien (`pc_unknown`) ; 5. l'heure du PC **n'est pas synchronisée par NTP** : on ne touche à rien (`pc_not_synchronized`). Pas question de recopier sur le lecteur l'heure d'un PC lui-même déréglé ; 6. l'écart est de 60 secondes ou moins : inutile, on laisse (`within_tolerance`) ; 7. sinon, on règle l'horloge (`set`). Pour savoir si le PC est synchronisé, pas besoin d'être root : la fonction `systemClock` appelle `adjtimex` en lecture seule et vérifie que le noyau ne répond pas `TIME_ERROR`, c'est-à-dire que l'horloge est bien tenue à jour par NTP. ```cpp PcClock systemClock() { struct timex tx; memset(&tx, 0, sizeof(tx)); // modes = 0 : lecture seule, aucun privilège auto state = adjtimex(&tx); return {time(0), true, 0<=state && TIME_ERROR!=state}; } ``` Si le lecteur refuse quand même la mise à l'heure, le téléchargement continue normalement et la sortie indique `"action": "rejected"`. Une horloge pas corrigée, ce n'est pas une raison de perdre les mesures.L'option `--now`, qui permet de simuler une heure de PC, n'est acceptée qu'avec `--replay` (le rejeu d'une trace enregistrée). Une fausse heure ne doit jamais pouvoir atteindre un vrai lecteur.
### Les marqueurs repas Sur l'Accu-Chek Guide, après une mesure, on peut indiquer le moment : à jeun, avant repas, après repas... Ces marqueurs ne sont pas rangés avec les glycémies, mais dans **leur propre segment** (`PMSegCMeal`). Chaque entrée fait 10 octets : la date en BCD et un code de la nomenclature ISO/IEEE 11073-10417 (le profil "glucomètre" de la norme).| Code | Hexa | Dans la sortie | Signification |
|---|---|---|---|
| 29260 | 72 4C | before_meal | avant repas |
| 29264 | 72 50 | after_meal | après repas |
| 29268 | 72 54 | fasting | à jeun |
| 29272 | 72 58 | casual | moment quelconque |
| 29300 | 72 74 | bedtime | coucher |
| autre | other | code inconnu |
| Code | Signification |
|---|---|
| 0 | succès, y compris un lecteur vide ("readings": []) |
| 1 | mauvaise utilisation : option inconnue, fichier de config ou trace illisible |
| 2 | aucun lecteur connu sur le bus USB |
| 3 | lecteur trouvé mais accès refusé : règle udev absente ou pas chargée |
| 4 | transfert USB échoué : délai dépassé, lecteur débranché |
| 5 | protocole : le lecteur a abandonné ou a répondu quelque chose d'inattendu |
Au final, il n'y a plus beaucoup de place pour la surprise. Si le lecteur répond quelque chose d'inattendu, accuchek s'arrête proprement, dit pourquoi, et n'écrit rien. Si tout se passe bien, on a la totalité des mesures, ni plus, ni moins.
# Installer et utiliser accuchek Assez de théorie, place à la pratique. Voici comment installer accuchek sur sa machine et récupérer ses mesures. Tout se passe dans un terminal, et il n'y a besoin des droits administrateur que pour l'installation. ### Les prérequis accuchek a besoin d'un compilateur C++ (C++17), de `make` et des en-têtes de **libusb**. Selon la distribution :| Distribution | Paquets |
|---|---|
| Debian, Ubuntu | g++ make libusb-1.0-0-dev |
| Fedora | gcc-c++ make libusb1-devel |
| Arch | gcc make libusb |
| Mageia | gcc-c++ make lib64usb1.0-devel |
Pour les curieux et les empaqueteurs : `make install` respecte les variables `PREFIX`, `DESTDIR` et `UDEVDIR` (par exemple `UDEVDIR=/usr/lib/udev/rules.d`). Par défaut, le binaire est compilé de façon portable, et `make OPTFLAGS="-O3 -march=native"` l'optimise pour la machine qui compile.
### Première lecture On branche le lecteur en USB. Son écran affiche "transfert de données". On lance alors : ```bash accuchek > mesures.json ``` Selon le nombre de mesures en mémoire, ça prend quelques secondes. Si la commande ne dit rien et que `echo $?` affiche `0`, c'est gagné : tout est dans `mesures.json`. ### Les commandes utiles ```bash accuchek > mesures.json # le premier lecteur connu trouvé accuchek 1 > mesures.json # le deuxième, si plusieurs sont branchés accuchek --set-time > mesures.json # remet aussi l'horloge du lecteur à l'heure si besoin accuchek --capture session.trace > mesures.json # enregistre aussi l'échange USB accuchek --replay session.trace > mesures.json # rejoue un enregistrement, sans lecteur accuchek --known-devices # liste des lecteurs acceptés accuchek --config mes-lecteurs.txt # ajouter ou désactiver des modèles accuchek --help ``` ### Ce qu'on obtient Un seul objet JSON, toujours avec la même forme : ```json { "format": 2, "meter": {"manufacturer": "Roche", "model": "925", "serial": "...", "firmware": "v1.9.6", "hardware": "G", "software": "", "system_id": "..."}, "clock": {"meter": "2026/10/01 21:06:58", "pc": "2026/10/01 20:42:52", "offset_s": 1446, "settable": true, "pc_synchronized": true, "action": "set"}, "glucose": {"announced": 638, "received": 638}, "meal": {"announced": 576, "received": 576, "unmatched": 0}, "readings": [ {"id": 0, "epoch": 1617009120, "timestamp": "2021/03/29 11:12", "mg/dL": 133, "mmol/L": 7.388889, "status": 0, "meal": "before_meal"} ] } ``` - `meter` : la carte d'identité du lecteur ; - `clock` : son horloge, l'écart avec le PC, et ce qui a été fait (`set`, `within_tolerance`, `not_settable`, `pc_not_synchronized`...) ; - `glucose` et `meal` : ce que le lecteur annonce et ce qu'on a reçu. Si les deux nombres diffèrent, il y a un souci ; - `readings` : les mesures. `timestamp` est l'heure affichée par le lecteur, `epoch` la même heure convertie dans le fuseau horaire du PC, heure d'été comprise. ### Jouer avec les données grâce à jq Le JSON se prête très bien à `jq`, l'outil en ligne de commande pour manipuler du JSON. Quelques exemples : ```bash # la dernière mesure jq '.readings[-1]' mesures.json # uniquement les mesures à jeun jq '.readings[] | select(.meal == "fasting") | {timestamp, "mg/dL"}' mesures.json # les mesures hors échelle (HI ou LO) jq '.readings[] | select(.range)' mesures.json # un CSV date;valeur, à ouvrir dans un tableur jq -r '.readings[] | select(.epoch) | [.timestamp, ."mg/dL"] | join(";")' mesures.json > mesures.csv ``` ### Quand ça ne marche pas| Code de sortie | Que faire |
|---|---|
| 2 | Le lecteur n'est pas vu. Vérifier le câble (certains câbles micro-USB ne font que la charge), et regarder si lsusb affiche bien 173a:21d5. |
| 3 | Accès refusé : installer la règle udev (voir plus haut), puis débrancher et rebrancher le lecteur. |
| 4 ou 5 | Débrancher le lecteur, attendre que son écran s'éteigne, le rebrancher et attendre "transfert de données" avant de relancer. |
Un fichier `mesures.json`, une trace `.trace` ou un `debug.log` contiennent des données de santé. On les garde pour soi, on ne les colle pas dans un ticket ou un forum sans avoir retiré les mesures.
# Et ensuite : Glucofi Avoir un fichier JSON, c'est parfait pour moi. Pour mon proche, beaucoup moins. Lui, ce qu'il veut, c'est brancher son lecteur, cliquer sur un bouton, et voir où il en est. C'est pour ça que j'ai construit **Glucofi**, une petite application de bureau pour Linux (GTK4 / libadwaita, donc parfaitement à sa place sous Gnome), qui utilise accuchek en coulisses. [](https://librenard.fr/wiki/uploads/images/gallery/2026-10/image.png) ### Comment accuchek a été importé Plutôt que de copier-coller le code, je l'ai intégré avec un **git subtree** dans `services/device/accuchek-src`. Le code d'accuchek vit toujours dans son propre dépôt, et je peux récupérer ses mises à jour d'une seule commande : ```bash git subtree pull --prefix=services/device/accuchek-src https://github.com/Ronnarrdd/accuchek.git main --squash ``` Il est compilé et installé dans `/usr/local/bin/accuchek` au moment de l'installation de Glucofi, avec sa règle udev. ### Glucofi ne parle jamais au lecteur directement C'est un choix volontaire. Glucofi (en Python) ne touche pas à l'USB : il lance accuchek comme un programme séparé, avec les droits de l'utilisateur, et lit sa sortie. Tout ce qui décode des octets venus de l'extérieur reste dans le petit programme C++ testé et fuzzé, jamais en root. Côté Python, tout est dans `services/device/accuchek.py` : 1. **Le lecteur est-il branché ?** Avant même de lancer quoi que ce soit, Glucofi regarde dans `/sys/bus/usb/devices/*/idVendor` s'il y a un périphérique Roche (`173a`). Pas besoin de droits particuliers pour ça. 2. **Lancer la lecture.** Il exécute `accuchek --set-time`, avec un délai maximum de 3 minutes. L'horloge du lecteur est donc corrigée au passage, si le PC est synchronisé et que l'écart dépasse 60 secondes. 3. **Interpréter le code de sortie.** Chaque code devient un message clair pour l'utilisateur. Le code 3, par exemple, donne "Accès USB au lecteur refusé : débranchez puis rebranchez le lecteur", ou indique la commande d'installation à relancer si la règle udev manque. 4. **Garder une copie brute.** Chaque lecture réussie est sauvegardée telle quelle dans `~/.local/share/glucofi/raw/`. Si un jour il y a un doute, on peut revenir à la source. 5. **Valider chaque mesure.** Le JSON est relu avec méfiance : types vérifiés, mesures avec un statut non nul ou une date invalide écartées (et listées), valeurs HI et LO reconnues grâce au champ `range`. 6. **Prévenir quand quelque chose cloche.** Si le lecteur annonce 638 mesures et qu'on en a reçu moins, si des marqueurs repas sont orphelins, ou si l'horloge du lecteur a plus de 5 minutes d'écart et n'a pas pu être corrigée, Glucofi l'affiche. ### Ce que fait Glucofi avec les mesures Une fois les mesures récupérées, Glucofi : - les range dans une base **SQLite locale** (`~/.local/share/glucofi/glucofi.db`). Les doublons sont ignorés, on peut donc relire le lecteur autant de fois qu'on veut ; - retrouve chaque jour la **glycémie du matin** : la première mesure entre 5h et midi marquée "à jeun", sinon "avant repas" ou sans marqueur. C'est là que les marqueurs repas du chapitre 5 servent vraiment ; - applique le **protocole recopié depuis l'ordonnance** (seuils, pas d'ajustement, nombre de jours) pour **proposer** un ajustement de la dose du soir. Rien n'est appliqué sans un clic sur "Valider" ; - affiche des **graphiques** sur 14, 30 ou 90 jours ; - exporte un **PDF** à apporter au médecin. [](https://librenard.fr/wiki/uploads/images/gallery/2026-10/idTimage.png) Et surtout, tout reste sur la machine. Aucune donnée n'est envoyée nulle part, ça marche sans connexion Internet.Glucofi ne contient aucun protocole médical. Il applique uniquement les valeurs recopiées depuis une ordonnance écrite, et une proposition n'est jamais appliquée sans validation. Il ne remplace pas l'avis du médecin, et en cas d'hypoglycémie répétée ou de glycémie très élevée, appelez votre médecin (s'il vous plait).
### Ce que j'en retiens Ce projet m'a appris pas mal de choses, et pas seulement sur l'USB : - **Le reverse engineering, c'est surtout de la lecture.** Lire le code des autres (Tidepool, emogenet), retrouver la norme derrière des noms de constantes, puis confronter tout ça aux vrais octets. L'hexdump de `ACCUCHEK_DBG=1` a été mon meilleur ami. - **Un protocole "propriétaire" ne l'est pas toujours.** Derrière le lecteur Roche, il y a une norme publique, ISO/IEEE 11073. Une fois qu'on le sait, tout devient beaucoup plus lisible. - **Pouvoir travailler sans le matériel change tout.** Les traces enregistrées et le simulateur m'ont permis de tester des centaines de scénarios sans emprunter le lecteur une seule fois de plus. - **Quand il s'agit de santé, "ça marche" ne suffit pas.** Il faut que ça échoue proprement : pas de données à moitié lues, pas de mesures inventées, pas d'erreur ### Conclusion Maintenant, quand mon proche veut faire le point, il branche son lecteur sur le PC, clique sur "Récupérer", et quelques secondes plus tard, ses glycémies du matin sont là, avec les graphiques et la proposition pour la dose du soir. Le carnet papier a pris sa retraite, et le jour de la consultation, il n'y a plus qu'à imprimer le PDF. Le code est libre : accuchek est dans le domaine public (Unlicense), comme le projet d'origine d'emogenet, et Glucofi est sous licence GPL-3.0. Si vous avez un autre lecteur Roche, n'hésitez pas à essayer avec `--config` et à me faire un retour. #### Liens utiles - [Ronnarrdd/accuchek](https://github.com/Ronnarrdd/accuchek) : mon fork d'accuchek - [emogenet/accuchek](https://github.com/emogenet/accuchek) : le projet d'origine - [Pilote Roche du Tidepool uploader](https://github.com/tidepool-org/uploader/tree/master/lib/drivers/roche) : là où tout a commencé - [Antidote](https://github.com/signove/antidote) : une implémentation libre de la norme ISO/IEEE 11073 - [libusb](https://libusb.info/) : la bibliothèque qui permet de parler à l'USB depuis un programme