Contexte technique
Je m'attarde immédiatement non pas sur le mot « chiffrement », mais sur l'effet : l'appareil ne sort pas les données brutes, seul le pouls est exposé. Pour toute implémentation sérieuse d'IA dans les neurointerfaces, c'est presque une impasse, car on travaille non pas avec le signal, mais avec l'interprétation que d'autres en font.
Et c'est là que ça devient vraiment gênant. Si le protocole BLE est fermé ou chiffré au point que le flux ne peut pas être analysé, je ne peux pas vérifier la fréquence d'échantillonnage, les artefacts, les pertes de paquets, la qualité du contact, la structure des canaux, ni même comprendre ce que le fabricant mesure réellement.
Le pouls seul ne sauve pas grand-chose. Il convient à quelques scénarios bien-être, mais pas au développement d'applications où j'ai besoin d'accéder à l'EEG brut, à la PPG ou au moins à des caractéristiques intermédiaires pour construire mon propre traitement, filtrage et détection d'états.
J'ai spécifiquement comparé ce contexte avec ce que je vois habituellement sur le marché des neurotrackers grand public. Le récit selon lequel « tout le monde chiffre et ne donne pas de raw » n'est pas universel : chez Muse, par exemple, l'EEG brut est généralement accessible, et le protocole a été analysé par la communauté depuis longtemps. Le problème n'est donc pas la classe d'appareils en soi, mais l'architecture produit spécifique et la décision du fabricant de verrouiller le canal.
Pour un ingénieur, cela signifie une chose simple : sans données brutes, je ne peux pas valider un modèle ni assembler correctement mon pipeline. Il ne reste plus qu'à vivre avec un SDK limité, ou à bricoler des solutions de contournement autour de métriques toutes faites impossibles à vérifier indépendamment.
Ce que cela change pour les entreprises et l'automatisation
Le premier impact concerne la vitesse de développement. L'équipe passe des semaines non pas sur le produit, mais sur la rétro-ingénierie, le sniffing et les tentatives pour déterminer si un flux utile peut être extrait.
Le deuxième impact est architectural. Si le fabricant ne fournit que des agrégats, l'automatisation de l'IA au-dessus d'un tel appareil devient fragile : impossible de réentraîner les modèles pour son propre cas d'usage, impossible d'ajuster les seuils de manière fiable, et impossible d'expliquer les échecs au client.
Seul le fabricant du matériel, qui garde le contrôle de l'écosystème, y gagne. Les chercheurs, les startups et tous ceux qui espéraient construire rapidement des solutions d'IA pour les entreprises à partir de biosignaux réels – et non d'API marketing – y perdent.
Chez Nahornyi AI Lab, je démonte justement ces goulets d'étranglement jusqu'aux vis : là où l'architecture permet de contourner la limitation, là où un autre capteur est nécessaire, et là où il est plus honnête de ne pas investir dès le départ dans une intégration sans issue. Si vous avez une histoire similaire avec un appareil qui a l'air parfait en démo mais casse l'automatisation IA au niveau des données, examinons la pile lucidement et construisons un chemin viable sans perdre des mois dans le vide.