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.

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 :

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.

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 : mon fork d'accuchek
• emogenet/accuchek : le projet d'origine
• Pilote Roche du Tidepool uploader : là où tout a commencé
• Antidote : une implémentation libre de la norme ISO/IEEE 11073
• libusb : la bibliothèque qui permet de parler à l'USB depuis un programme