Vous concevez un produit qui doit tenir des mois, voire des années, sur deux piles ? Alors la première chose à comprendre est contre-intuitive : l’autonomie ne se gagne pas dans le code qui tourne, mais dans le temps que l’objet passe à ne rien faire. Voici la méthode que je déroule, dans l’ordre.
Sur un objet sur batterie, l’autonomie se joue sur le temps passé en veille profonde, pas sur la finesse du code actif : on dessine le cycle de sommeil, on traque les réveils parasites, on débusque les fuites à la pince, puis on arbitre le rythme de la radio.
1. Dessiner le cycle de sommeil avant la moindre fonctionnalité. Un objet bien pensé pour la pile passe la quasi-totalité de sa vie en veille profonde, dans un état où il ne tire presque rien. Il se réveille un court instant, mesure, parfois transmet, puis replonge. Le rapport entre la durée du sommeil et celle de l’activité pèse davantage que la qualité du code exécuté pendant les phases éveillées. Donc on commence par là : combien de temps il dort, ce qui le réveille, le travail minimal à abattre avant de se rendormir.
2. Traquer les réveils parasites. Une veille parfaite sur le papier se fait anéantir par trois fois rien. Un objet censé dormir une heure qui se relève chaque minute pour une broutille, et l’économie s’évapore. On remonte la chaîne des interruptions, ligne par ligne s’il le faut, jusqu’à n’avoir plus que les réveils voulus.
3. Débusquer les fuites à la pince. Restent les consommations résiduelles, plus sournoises encore. Un capteur laissé sous tension pendant la veille, une entrée flottante qui fuit, une LED de debug qu’on a oublié de retirer : pendant un sommeil censé être profond, ces quelques microampères vident la pile en silence. Le piège, c’est qu’ils n’apparaissent pas dans le code. Ils apparaissent à la pince ampèremétrique, l’instrument qui mesure le courant réellement tiré par la carte. D’où une discipline que je ne lâche jamais : mesurer le courant réel en veille, au banc, sur la carte assemblée, avant de prononcer le moindre chiffre d’autonomie. Cette mesure m’a déjà fait reculer une mise en production de deux semaines.
4. Arbitrer le rythme de la radio. C’est presque toujours elle qui domine la facture, Wi-Fi, cellulaire ou LoRa (une radio longue portée à très bas débit, prisée des capteurs isolés), et surtout à l’émission : allumer le module, négocier avec le réseau, pousser les octets, tout cela coûte. Deux leviers. D’abord, accumuler les mesures et les envoyer par lots espacés plutôt qu’une par une, parce que dix mesures poussées d’un coup reviennent bien moins cher que dix envois séparés. Ensuite, couper franchement la radio entre deux transmissions. Sur un capteur agricole enterré que j’ai suivi, passer d’un envoi toutes les cinq minutes à un envoi groupé horaire a multiplié l’autonomie par un facteur de l’ordre de dix, sans toucher une seule ligne de code métier.
5. Caler le curseur autonomie / fraîcheur des données. Ce compromis-là, on ne peut pas l’esquiver. Dormir plus longtemps économise la pile mais espace les mesures et retarde les remontées. Un capteur de température relevé une fois l’heure peut dormir comme une souche ; un objet qui doit réagir vite à un événement reste plus disponible, donc plus gourmand. Le bon réglage se cale sur l’usage réel, pas sur la valeur par défaut du SDK.
Avant d’annoncer une autonomie, je branche la pince et je lis le courant en veille sur la carte vraie. Le reste, ce sont des suppositions.