On croit souvent qu’un firmware fiable est un firmware qui ne perd jamais le réseau. C’est l’inverse. Sur le terrain, vous ne maîtrisez ni la couverture, ni les interférences, ni l’opérateur qui renégocie une session au pire moment. Le lien tombe, revient, retombe. Un firmware sérieux ne cherche pas à empêcher ça, il part du principe que ça va arriver et continue de fonctionner quand même.
Un firmware de production traite la coupure réseau comme l’état normal de l’objet sur le terrain : il se reconnecte seul, garde ses mesures en local le temps de la panne, et reprend où il s’était arrêté sans doublon.
Le prototype, lui, raisonne autrement : « je suis connecté, j’envoie ». Tant que vous le testez au bureau, à côté du point d’accès, il a toujours raison. Posez le même objet à trois kilomètres d’une antenne, derrière un mur de béton, et la première coupure le fige ou lui fait perdre ses mesures. Toute la différence entre les deux tient dans l’hypothèse de départ. En production, je retourne la phrase : l’objet peut perdre le lien à n’importe quel instant, et son travail ne s’arrête pas pour autant. Trois comportements en découlent.
D’abord, il se reconnecte seul. Personne ne va sur place relancer un capteur. L’objet détecte la perte et retente, mais pas n’importe comment : une boucle serrée qui réessaie toutes les 200 ms vide la batterie et harcèle un réseau déjà fragile. On espace les tentatives, avec un intervalle qui grandit à chaque échec. J’ai vu une boucle de reconnexion mal écrite diviser par trois l’autonomie d’un objet sur batterie : trois ans prévus, treize mois sur le terrain. Le genre de bug qu’on ne voit jamais au labo, parce qu’au labo, le réseau ne coupe pas.
Ensuite, il garde ses mesures. Pendant la coupure, rien n’est jeté. Les relevés vont en mémoire vive pour les courtes absences, sur flash non volatile (une mémoire qui conserve son contenu même hors tension, comme une carte SD) si vous voulez survivre à plusieurs heures hors ligne, et l’objet vide cette réserve au retour. La taille de ce tampon (la file d’attente des mesures non encore transmises) se cale sur la durée de coupure que vous acceptez de couvrir. Un capteur qui relève toutes les dix minutes et doit tenir vingt-quatre heures hors ligne, ça fait moins de 150 enregistrements, quelques kilo-octets. Ce n’est presque jamais la place qui manque. C’est d’avoir oublié de la prévoir.
Reste la reprise, et c’est là que se cache la subtilité la plus coûteuse. Au retour du réseau, l’objet doit repartir d’où il s’était arrêté, sans rejouer ce qui est déjà passé ni laisser de trou. Cela suppose de savoir ce que le serveur a réellement reçu et acquitté, c’est-à-dire confirmé par un accusé de réception, pas seulement ce qui a été émis. Un objet qui confond « envoyé » et « reçu » fabrique un doublon à chaque reconnexion. Ce point se conçoit dès le départ ; le rajouter une fois la flotte déployée, c’est une mise à jour de firmware sur des milliers d’objets éparpillés dans la nature.
Et il y a un piège plus vicieux encore, celui qu’on découvre en général le jour où il fait mal. Une panne d’infrastructure ne touche pas un objet, elle met à terre toute la flotte d’un coup. Au rétablissement, mille objets se reconnectent dans la même seconde et déversent leur tampon ensemble. Le serveur, qui digérait tranquillement un flux régulier, reçoit tout d’un bloc : il sature, refuse des connexions, des objets retentent, la vague grossit. La parade tient en peu de chose, un décalage aléatoire propre à chaque objet avant de réémettre. Quelques secondes de dispersion suffisent à lisser le pic. Une ligne de code à la conception, ou une nuit blanche en exploitation.
Un projet récent illustre tout ça mieux qu’un schéma. Des relais de mesure répartis sur une zone rurale, liaison cellulaire, autonomie sur batterie visée à plusieurs années. En recette, tout passait : on coupait le réseau proprement, l’objet bufferisait, reprenait, parfait. Le premier orage sérieux a mis l’opérateur local à genoux pendant deux heures. Au retour, le serveur a encaissé toute la flotte en même temps et a commencé à refuser des connexions ; les objets ont retenté en boucle, et c’est la batterie qui a payé l’addition, pas le réseau. Aucune mesure n’a été perdue, le tampon avait bien fait son travail. Mais il a fallu déployer un correctif OTA pour ajouter le décalage aléatoire et calmer les tentatives. Deux lignes qui auraient coûté une heure au début du projet en ont coûté plusieurs, à distance, sur des objets déjà posés. La coupure, on l’avait anticipée. C’est le retour qu’on avait oublié.