Une startup IoT m’a envoyé son prototype le printemps dernier. Trois piles AA, un capteur de température, une radio LoRa, et une cible d’autonomie de trois ans. Les piles mouraient en deux semaines.

Le hardware était correct. Le firmware ne dormait jamais. Le MCU roulait à pleine clock, polling le capteur dans une boucle serrée, avec la radio idle mais alimentée. Une fois qu’on a mis le système en sleep correctement, le courant moyen est passé de 14 mA à moins de 30 µA. Trois ans devenait soudainement réaliste sur le même hardware.

C’est un pattern que j’ai vu, et que j’ai moi-même mis dans mes propres prototypes plus d’une fois. L’instinct, c’est de regarder la batterie en premier : peut-être un plus gros pack, peut-être une autre chimie, peut-être une pile primaire au lieu de rechargeable. Presque toujours, le plus gros levier est du côté firmware. Le produit se réveille trop souvent, reste éveillé trop longtemps, ou allume des choses qui n’ont pas besoin d’être allumées.

La vie d’une batterie, c’est surtout un problème de firmware. Voici ce que je regarde, dans l’ordre où je le regarde.

Le sleep n’est pas optionnel, et le sleep demande du ménage

Les MCU modernes restent en idle dans la zone sous le µA quand tu les mets correctement en sleep. Le mot-clé, c’est correctement. Appeler deep_sleep() n’est pas suffisant en soi. Le MCU peut tirer 1 µA pendant que le reste de la carte tire cinquante fois ça, et le courant système finit par n’avoir rien à voir avec le chiffre du datasheet.

Quelques affaires que je vérifie toujours avant de signer un design low-power.

Mettre les périphériques en reset avant de dormir. Capteurs, ADC, level shifters, flash externe, tous. Beaucoup de puces ont un courant “idle” qui est dramatiquement plus élevé que leur vrai courant de reset. Si un composant a un pin RESET, le tenir à zéro pendant que le système dort sauve souvent plus de courant que n’importe quel tweak firmware. S’il a un chip-select, mets-le à l’état inactif. La section standby du datasheet vaut la peine d’être lue lentement, puis de relire les petits caractères en dessous.

Dimensionner tes pull-ups pour le sleep, pas juste pour l’intégrité du signal. Un pull-up de 10 kΩ sur un rail 3.3V tire 330 µA quand le pin est tenu à zéro. Cette seule résistance peut faire exploser ton budget sleep complet sur trois piles AAA. Sur des lignes qui n’ont pas besoin de fronts rapides (I2C à 100 kHz, straps de configuration, entrées de boutons), 100 kΩ ou même 1 MΩ fonctionne habituellement très bien. Fais le calcul : V/R, c’est ta perte continue tant que la ligne est dans son état actif. C’est un détail facile à manquer quand tu te concentres sur la qualité du signal.

Planifier les LED avec soin. La plupart des cartes de prototype ont au moins un LED indicateur toujours allumé sur un rail d’alimentation. Il tire deux à cinq milliampères, et c’est parfaitement correct en développement. La piste, c’est de planifier la transition : les LED de rail d’alimentation, les headers de breakout et les test points sont essentiels pour le design for testing, mais un LED de 2 mA toujours allumé va manger l’année d’autonomie que tu as soigneusement designée dans le système. Habituellement, je planifie le BOM avec deux configurations dès le départ (populé pour le développement, populé pour la production), ou j’utilise des jumpers 0Ω que je peux dépopuler plus tard. Le prototype reste observable, l’unité de production reste efficace.

Interruptions, pas polling

Un microcontrôleur endormi qui attend une interruption tire quelques µA. Le même microcontrôleur dans une boucle while(1) qui check un registre à pleine clock peut tirer 5 à 10 mA. Même job, trois ordres de grandeur de différence.

Le polling a sa place (boucles critiques en timing, certaines implémentations de protocole), mais dans un produit alimenté par batterie, c’est une des premières affaires que je regarde. Le modèle que je vise : le produit est endormi par défaut, et ne se réveille que pour un événement spécifique. Pression de bouton : interruption GPIO. Donnée capteur prête : ligne d’interruption du capteur (la plupart des capteurs modernes en ont une, et l’utiliser se paye vite). Timer expiré : alarme RTC réveille le MCU. Le CPU fait son travail, retourne dormir, recommence.

Quand un système est structuré dans l’autre sens (en marche par défaut, qui se repose à l’occasion), la majorité du budget batterie finit par financer du temps idle. Restructurer tôt est beaucoup moins cher que d’essayer de récupérer du courant à la fin.

Éteins la radio

L’émetteur-récepteur sans fil est presque toujours le plus gros puits de courant sur un produit connecté. Le WiFi tire typiquement 150 mA ou plus pendant la transmission. Le BLE en advertising tire autour de 5 à 15 mA selon l’intervalle. Même la LoRa peut tirer 40 mA pendant une rafale de transmission.

Sur un ESP32, la radio est l’endroit le plus facile pour laisser du courant sur la table. La puce peut tirer 30 à 80 mA juste à garder le stack WiFi en vie entre les transmissions. Si ton produit envoie de la donnée à toutes les cinq minutes, la radio devrait être complètement éteinte pendant quatre minutes et cinquante-quelques secondes. La couper explicitement entre les transmissions (pas juste “arrêter d’envoyer”) est habituellement un refactoring d’une journée qui te rachète une portion significative d’autonomie.

Un cadre utile : combien de temps la radio passe-t-elle vraiment à transmettre des bits utiles par heure ? Pour la plupart des capteurs IoT, la réponse, c’est “quelques centaines de millisecondes”. Les 3 599 secondes et quelques qui restent sont une opportunité.

Choisis le bon protocole pour le job

C’est la décision qui fait le plus varier l’autonomie, et elle mérite une vraie conversation tôt dans le projet plutôt qu’un défaut qui n’est jamais revisité.

WiFi. Débit élevé, infrastructure déjà existante, intégration facile. Dur sur la batterie. L’association est coûteuse (des centaines de ms à courant de pointe), et même le modem sleep s’assoit dans les centaines de µA. Un excellent fit quand le produit est alimenté par le secteur, ou quand il vit sur un chargeur entre les événements.

ESP-NOW. Protocole sans connexion à la couche WiFi. Pas de handshake d’association, donc une transmission prend autour de 10 ms au lieu d’une seconde complète. Un bon entre-deux quand tu contrôles les deux bouts et qu’ils partagent un même bâtiment.

BLE. Conçu pour la basse consommation dès le départ. L’advertising peut être ajusté pour balancer la découvrabilité contre la consommation. Réaliste d’obtenir des années d’autonomie sur une pile bouton pour un capteur qui se réveille quelques fois par jour. La portée est le compromis (dizaines de mètres en intérieur).

LoRa / LoRaWAN. Des kilomètres de portée, du standby sous le µA, mais lent (quelques octets par seconde) et avec une consommation en rafale pendant la transmission. Un fit solide pour des capteurs qui envoient de petits payloads occasionnellement sur de longues distances. Pas le bon outil si tu dois pousser des images ou streamer de la donnée.

Match le protocole avec la vraie donnée que le produit doit envoyer et la vraie portée qu’il doit couvrir. La bonne réponse devient habituellement évidente une fois que ces deux chiffres sont écrits sur papier.

Le paysage continue de bouger

Aucun de ces chiffres n’est figé. De nouvelles familles de MCU sortent chaque année avec de meilleurs courants idle et des périphériques plus intelligents. Les standards radio continuent d’évoluer : Thread et Matter côté smart-home, Wi-Fi HaLow pour de l’IoT longue portée à basse consommation, la LoRa qui pousse vers la bande 2.4 GHz, le BLE 5.x qui devient plus capable en mesh. Le meilleur choix d’il y a deux ans n’est peut-être plus le meilleur choix aujourd’hui, et ce qui semble idéal sur un nouveau projet cette année vaudra un nouveau regard dans deux ou trois ans.

C’est pour ça que j’essaie d’ancrer le design low-power dans des principes plutôt que dans des numéros de pièces spécifiques. Les questions restent les mêmes : qui alimente ça, à quelle fréquence, c’est quoi le travail minimum que le produit a vraiment à faire, et à quelle fréquence la radio a vraiment besoin de parler ? Mets ça au clair et la technologie peut bouger en dessous sans casser l’architecture. Les chiffres vont bouger ; la discipline de poser les bonnes questions, non.

Où je commence sur un nouveau projet low-power

Avant d’écrire une ligne de firmware, je trace le duty cycle sur papier. Combien de temps le MCU est-il réveillé par heure ? Combien de temps la radio est-elle allumée ? Ça me donne quel courant moyen, et ça se traduit en quoi en mois ou en années sur la batterie choisie ?

Si la réponse ne rentre pas, l’architecture a probablement besoin d’être repensée, et c’est beaucoup mieux de le découvrir tôt qu’après le premier prototype. La partie encourageante, c’est qu’avec les familles de MCU actuelles et une radio bien choisie, “des années sur une petite batterie” est vraiment atteignable. Ça arrive juste rarement par accident.

La batterie, c’est la partie facile. La partie plus intéressante, c’est de designer un produit qui passe la majorité de sa vie à ne rien faire, exprès.