J'ai construit la route avant les capteurs
La première donnée qui fait tout le voyage, du terrain au cloud, et pourquoi j'ai commencé par la partie la moins spectaculaire.
Il y a une tentation, quand on construit un objet connecté : partir de la partie qui se voit. Le capteur, le chiffre, le graphique qui fait “wow”. J’ai fait l’inverse. Avant les capteurs, j’ai construit la route que les données parcourront, et je l’ai construite en pensant à la façon dont elle casse.
Parce que le vrai problème d’une ruche au milieu d’un champ n’est pas de lire une valeur une fois. C’est de ne jamais perdre cette donnée, pendant des mois, tandis que la connectivité va et vient, que le signal vacille, que quelque chose redémarre. Le plus dur n’est pas la première donnée : c’est la dix-millième, prise un après-midi de pluie sans réseau.
J’ai donc commencé par la colonne vertébrale. Et ces jours-ci, pour la première fois, une donnée a fait tout le voyage, d’un bout à l’autre.
Le parcours, étape par étape
Sur le terrain, un émetteur envoie la donnée par radio, à longue portée. Près du bâtiment, un récepteur la capte et la transmet à un petit pont : un ordinateur minuscule, toujours allumé, qui ne traite rien, il transporte, c’est tout. Sur ce pont tourne un programme léger qui fait une seule chose, mais la fait bien : il prend la donnée entrante, vérifie son intégrité (il écarte ce qui arrive abîmé) et la met en file d’attente, en l’enregistrant sur le disque. Ce n’est qu’alors qu’il tente de l’envoyer au serveur dans le cloud, sur un canal chiffré. Quand le serveur confirme l’avoir reçue, la donnée est marquée comme “livrée”.
Le détail qui compte, c’est cette file d’attente. Si le réseau tombe, les données ne se perdent pas : elles restent en file, dans l’ordre, et repartent dès que la connexion revient. Si le pont redémarre, la file est toujours là. Le pont lui-même est pensé pour être remplaçable : s’il tombe en panne, on le remet en place et il redémarre, et entre-temps rien n’a été perdu.
Vérifié d’un bout à l’autre : terrain, pont, file, cloud, confirmation, sans une seule donnée perdue.
Pourquoi commencer par la partie “ennuyeuse”
Parce que c’est la partie qui décide si un projet comme celui-ci est un jouet ou un outil. Enregistrer le bourdonnement d’une ruche pendant quelques minutes, sa voix, c’est (relativement) facile. Garantir que cette voix, et les milliers de fragments qui arriveront au fil des mois, parviennent vraiment jusqu’à l’écran de l’apiculteur même quand la journée tourne mal : voilà le vrai travail. J’ai choisi de le mettre en premier.
Honnête sur l’état des choses
La donnée qui fait ce voyage aujourd’hui est encore factice : elle est produite par une source de test, pas par un vrai nœud fixé à une ruche. La prochaine pièce, c’est précisément cela : le vrai capteur qui écoute, mesure et transmet depuis le terrain. Mais la route que ces données parcourront est déjà vivante, chiffrée et éprouvée. Quand la première vraie voix de la ruche s’élancera, elle trouvera la voie déjà ouverte.
C’est ainsi que j’imagine une ruche nativement numérique : pas des capteurs collés dessus, mais d’abord un système nerveux fiable, et ensuite les sens.
Si vous suivez le projet depuis un moment, c’est le moment où il commence vraiment à bouger. Et si vous construisez des objets connectés pour votre métier, ou si vous travaillez avec les abeilles, j’aimerais savoir : par où auriez-vous commencé, par les sens ou par le système nerveux ?