Power management embarqué : faire durer votre batterie 3 ans et plus

Votre produit doit tenir 3 ans sur une pile bouton ou une demi-AA. Le marketing annonce « basse consommation ». L’ingénierie répond « ça dépend ». De quoi exactement ? Du courant de veille, du duty cycle, du régulateur de tension, de la chimie de la batterie, de la température de fonctionnement, du firmware — et de la façon dont tout cela interagit.

En réalité, la durée de vie sur batterie ne se devine pas : elle se calcule, se mesure et se valide. Un écart de 2 µA en mode veille peut faire la différence entre un produit qui tient 5 ans et un produit qu’il faut remplacer au bout de 18 mois. Et cette différence se joue dès les premières décisions de conception.

Chez AESTECHNO, nous concevons des produits IoT sur batterie depuis plus de 10 ans. Nous avons mesuré des courants de veille au nanoampère près, optimisé des régulateurs pour grappiller chaque point de rendement, et validé des durées de vie sur batterie par des tests de plusieurs mois. Cet article condense cette expérience en un guide pratique pour tout directeur technique qui conçoit un produit embarqué alimenté par batterie.

Le bilan énergétique : la méthode qui dimensionne tout

Le bilan énergétique est le calcul fondamental qui détermine la durée de vie d’un produit sur batterie. Il consiste à modéliser le profil de consommation complet du système — courant actif, courant de veille, durée et fréquence de chaque phase — puis à le confronter à la capacité réelle de la batterie, en intégrant les marges de température, d’auto-décharge et de vieillissement.

Le principe est simple :

• Courant actif × durée active par cycle : c’est l’énergie consommée pendant les phases de réveil, mesure, calcul et transmission
• Courant de veille × durée de veille : c’est l’énergie consommée pendant que le système dort entre deux cycles
• Courant moyen = somme pondérée : I_avg = (I_active × t_active + I_sleep × t_sleep) / (t_active + t_sleep)
• Autonomie = capacité batterie / courant moyen : C (mAh) / I_avg (mA) = durée de vie (heures)

Exemple concret : un capteur IoT se réveille toutes les 10 minutes, mesure une température, transmet en BLE, puis se rendort.

• Phase active : 15 mA pendant 200 ms → charge = 15 × 0,2/3600 = 0,83 µAh par cycle
• Phase veille : 3 µA pendant 599,8 s → charge = 0,003 × 599,8/3600 = 0,50 µAh par cycle
• Charge totale par cycle : 1,33 µAh. Période : 600 s
• Courant moyen : 1,33 / (600/3600) = 7,98 µA ≈ 8 µA
• Avec une pile ER14250 (1 200 mAh) : 1 200 000 / 8 = 150 000 heures ≈ 17 ans théoriques

Mais la théorie n’est jamais la réalité. Il faut intégrer les marges :

• Auto-décharge : les piles lithium thionyl perdent environ 1 % par an. Sur 10 ans, c’est 10 % de capacité en moins
• Dérating en température : à -20 °C, une pile lithium thionyl perd 30 à 50 % de sa capacité nominale
• Vieillissement : la résistance interne augmente avec le temps, ce qui réduit la capacité utilisable en charge pulsée
• Marge de sécurité : nous appliquons typiquement un facteur 0,6 à 0,7 sur la capacité nominale pour obtenir une estimation réaliste

Avec un facteur de 0,65, notre capteur tiendrait environ 11 ans — largement au-delà de l’objectif de 3 ans. Mais si le courant de veille passe de 3 µA à 30 µA (un GPIO mal configuré, un régulateur avec un courant de repos trop élevé), l’autonomie chute à 3,5 ans théoriques — soit environ 2,3 ans réels. C’est pourquoi chaque microampère compte.

Les modes de veille : de l’idle au shutdown

Les modes de veille du microcontrôleur déterminent le courant de base du système lorsqu’il ne fait rien — c’est-à-dire pendant 99 % du temps dans un produit IoT typique. Comprendre les différences entre Idle, Deep Sleep, System OFF et Hibernate est essentiel pour dimensionner correctement le bilan énergétique et choisir le bon compromis entre latence de réveil et consommation.

Idle / Sleep (~100 µA) : le CPU est arrêté, mais tous les périphériques restent alimentés et actifs. Les horloges haute fréquence continuent de tourner. Le réveil est quasi instantané (quelques microsecondes). Ce mode est utile pour les attentes courtes au sein d’un même cycle d’activité, mais il est insuffisant pour de l’autonomie longue durée.

Deep Sleep / System ON (~1-10 µA) : la RAM est conservée, le RTC continue de compter, mais les horloges rapides et la plupart des périphériques sont éteints. Le temps de réveil est de l’ordre de quelques centaines de microsecondes. C’est le mode le plus courant pour les capteurs IoT : le firmware reprend exactement là où il s’était arrêté.

System OFF / Shutdown (~0,3-1 µA) : tout est éteint sauf la source de réveil (RTC, broche GPIO, watchdog). La RAM est perdue. Au réveil, le système redémarre complètement (reset). Ce mode offre la consommation la plus basse sur la plupart des MCU. Sur un nRF52832, la différence entre System ON (1,5 µA avec RAM retenue) et System OFF (0,3 µA) est un facteur 5×.

Hibernate : certains MCU récents (nRF54, STM32U5, NXP LPC55) proposent un mode encore plus profond, avec un courant inférieur à 100 nA. Seules quelques broches de réveil et un compteur minimal restent actifs. C’est le mode ultime pour les produits qui restent en veille pendant des heures ou des jours entre deux activations.

Sources de réveil :

• Timer RTC : réveil périodique programmé — la source la plus courante pour le duty cycling
• Interruption GPIO : réveil sur événement externe (appui bouton, signal capteur, détection de mouvement)
• Watchdog : réveil de sécurité en cas de blocage du système

Le point critique : la différence entre System ON et System OFF est souvent un facteur 10× en courant de veille. Pour un produit qui dort 99,97 % du temps (réveil toutes les 10 minutes pendant 200 ms), c’est cette consommation de veille qui domine le bilan énergétique. Passer de 3 µA à 0,3 µA de veille peut doubler l’autonomie réelle.

Régulateurs de tension : DCDC vs LDO

Le régulateur de tension convertit la tension de la batterie en tension d’alimentation stable pour le MCU et les périphériques. C’est un composant critique du bilan énergétique : un mauvais choix de régulateur peut gaspiller 20 à 40 % de l’énergie disponible avant même que le microcontrôleur ne fasse quoi que ce soit. Le choix entre LDO et DCDC — ou une combinaison des deux — dépend du rendement visé, du bruit toléré et du profil de charge.

LDO (Low Dropout Regulator) :

• Simple, compact, silencieux — pas de bruit de commutation
• Rendement = V_out / V_in. Avec 3,3 V en sortie et 4,2 V en entrée (LiPo pleine charge), le rendement est de 78 %. Cela signifie que 22 % de l’énergie est dissipée en chaleur
• Idéal pour alimenter des circuits analogiques sensibles ou des étages RF
• Courant de repos typique : 1 à 50 µA selon le modèle

DCDC buck (abaisseur) :

• Rendement de 85 à 95 % sur une large plage de tensions d’entrée
• Génère du bruit de commutation (ripple) qui peut perturber les mesures analogiques et la radio
• Plus complexe : nécessite une inductance, des capacités de filtrage, et un layout soigné
• Indispensable quand la différence V_in – V_out est importante (ex : pile 3,6 V → 1,8 V MCU)

DCDC boost (élévateur) :

• Nécessaire quand la tension batterie descend en dessous de la tension d’alimentation requise
• Cas typique : pile lithium en fin de vie (1,2 V) → alimentation MCU à 1,8 V
• Permet d’exploiter la totalité de la capacité de la batterie au lieu de couper prématurément

Approche hybride (notre recommandation) :

• DCDC pour le rail principal : maximise le rendement global
• LDO en sortie du DCDC pour les blocs sensibles : étage analogique, front-end RF. Le LDO filtre le ripple du DCDC

PWM vs PFM : les régulateurs DCDC modernes offrent deux modes de fonctionnement. En PWM (Pulse Width Modulation), la fréquence de commutation est fixe — bon pour les charges élevées et la radio (spectre prévisible). En PFM (Pulse Frequency Modulation), le régulateur ne commute que quand nécessaire — rendement excellent à très faible charge, mais spectre de bruit imprévisible. La stratégie optimale : PFM en veille, basculement automatique en PWM pendant les bursts radio.

Courant de repos ultra-bas : les régulateurs de dernière génération atteignent des courants quiescents remarquables. Le TPS62840 de Texas Instruments consomme moins de 60 nA au repos. Le MAX38640 de Analog Devices descend sous 330 nA. À ces niveaux, le régulateur lui-même ne contribue quasiment plus au bilan énergétique de veille — c’est le MCU et les capteurs qui dominent.

Chimie des batteries : choisir la bonne cellule

Le choix de la batterie détermine non seulement la capacité énergétique disponible, mais aussi la tension de fonctionnement, la capacité en courant pulsé, la plage de température et la durée de stockage. Chaque chimie présente des compromis spécifiques, et un mauvais choix peut réduire drastiquement l’autonomie réelle par rapport aux calculs théoriques.

CR2032 (lithium coin cell) :

• Capacité : 225 mAh. Tension : 3,0 V
• Peu coûteuse, disponible partout, format compact
• Limitation majeure : courant de décharge pulsé limité à environ 15-20 mA. Au-delà, la tension chute brutalement. Les transmissions radio (BLE, LoRa) tirent facilement 30-50 mA → il faut un condensateur de découplage (100-470 µF) pour fournir le pic
• Adaptée aux produits à très faible activité (beacon BLE, capteur avec transmission rare)

ER14250 (half-AA, lithium thionyl chloride) :

• Capacité : 1 200 mAh. Tension : 3,6 V avec une courbe de décharge très plate
• Plage de température : -55 °C à +85 °C — excellent pour les applications industrielles et extérieures
• Effet de passivation : après un long stockage, une couche de passivation se forme sur l’anode. Le premier pulse de courant voit une chute de tension temporaire. Il faut en tenir compte dans le design (seuil de brown-out, condensateur tampon)
• Non rechargeable. Courant continu limité (~25 mA max)

ER14505 (AA, lithium thionyl chloride) :

• Capacité : 2 600 mAh. Mêmes caractéristiques que l’ER14250 en format AA
• Le choix standard pour les compteurs intelligents, capteurs industriels et dispositifs télécom

AA Energizer L91 (lithium iron disulfide) :

• Capacité : ~3 000 mAh. Tension initiale : 1,8 V (format AA standard)
• Excellente capacité en courant pulsé — supporte des pics de plusieurs centaines de milliampères
• Format grand public, remplacement facile sur le terrain

LiPo rechargeable :

• Pour les produits avec recharge solaire ou USB
• Nécessite un circuit de charge (BQ25170, MCP73831) et une protection (surcharge, décharge profonde, surcourant)
• Complexité accrue, mais permet des cycles d’utilisation plus intenses

Primaire vs rechargeable : pour un produit IoT qui doit durer 3 à 10 ans sans intervention, les piles primaires (non rechargeables) restent le choix le plus fiable. Pas de circuit de charge, pas de dégradation cyclique, durée de stockage supérieure. Les rechargeables n’ont de sens que si le produit dispose d’une source d’énergie ambiante (solaire, vibration) ou d’un accès régulier à l’utilisateur.

Dérating en température : c’est le piège le plus fréquent. À -20 °C, une pile lithium thionyl chloride perd 30 à 50 % de sa capacité nominale. Une CR2032 peut perdre jusqu’à 70 % à -30 °C. Si votre produit est déployé en extérieur ou en chambre froide, le bilan énergétique doit être calculé à la température minimale de fonctionnement, pas à 25 °C.

Optimisation firmware : les techniques qui comptent

Le firmware est le chef d’orchestre de la consommation énergétique. Même avec un hardware parfaitement optimisé, un firmware mal écrit peut multiplier la consommation par 10 ou plus. L’optimisation firmware repose sur un principe fondamental : minimiser le temps passé en mode actif et maximiser le temps passé dans le mode de veille le plus profond possible.

Duty cycling — le cycle fondamental :

Le schéma de base d’un capteur IoT est : réveil → mesure → traitement → transmission → retour en veille. Chaque milliseconde de moins en mode actif se traduit directement en mois d’autonomie supplémentaire. Chez AESTECHNO, nous avons constaté que l’optimisation du duty cycle est souvent le levier le plus efficace — bien plus que le choix du MCU.

Power gating des périphériques :

• Éteindre physiquement les capteurs entre les mesures (via un MOSFET de commutation ou une broche d’enable)
• Un capteur de température ou d’humidité laissé alimenté en permanence peut consommer 1 à 50 µA — même en « standby »
• Couper l’alimentation plutôt que de se fier au mode basse consommation du capteur : certains datasheets sont optimistes

Optimisation BLE :

• Réduire l’intervalle d’advertising : passer de 100 ms à 1 000 ms divise la consommation radio par ~10×
• Optimiser les paramètres de connexion : interval, latence esclave, timeout de supervision
• Utiliser le coded PHY (BLE 5.0) pour augmenter la portée sans augmenter la puissance d’émission
• Pour en savoir plus sur les architectures Bluetooth et BLE embarqué

Gestion des horloges :

• Utiliser l’oscillateur RC basse fréquence (32 kHz) chaque fois que possible
• Éteindre le cristal haute fréquence (16/32 MHz) dès que le traitement est terminé
• Sur les MCU Nordic, la différence entre HFCLK actif et LFCLK seul est de plusieurs milliampères

Éviter le busy-waiting :

• Tout délai doit être implémenté par timer + interruption, jamais par boucle active
• Utiliser une architecture événementielle : le MCU dort, se réveille sur interruption, traite l’événement, se rendort
• Les RTOS comme Zephyr ou FreeRTOS facilitent cette approche avec leurs mécanismes de tickless idle

Batching des données :

• La radio est le poste de consommation le plus élevé. Chaque transmission a un coût fixe (réveil radio, rampe de puissance, overhead protocolaire)
• Accumuler plusieurs mesures en RAM et les envoyer en une seule transmission réduit drastiquement le nombre de réveils radio
• Exemple : au lieu de transmettre toutes les 10 minutes, stocker 6 mesures et transmettre toutes les heures. Le nombre de transmissions est divisé par 6, mais les données arrivent avec le même intervalle effectif

Mesure et validation : ne faites jamais confiance au calcul seul

La validation par mesure réelle est l’étape qui sépare un prototype de laboratoire d’un produit fiable sur le terrain. Les calculs théoriques donnent une estimation, mais seule la mesure confirme que le hardware et le firmware se comportent réellement comme prévu. Chez AESTECHNO, nous avons vu des écarts de facteur 3 à 10 entre le courant de veille attendu et le courant réel mesuré — souvent à cause d’un périphérique mal éteint ou d’un pull-up oublié.

Nordic Power Profiler Kit II (PPK2) :

• Mesure de courant en temps réel, de 200 nA à 1 A, avec un taux d’échantillonnage de 100 kHz
• Visualisation du profil de consommation complet : on voit chaque phase (réveil, mesure, transmission, retour en veille)
• Peut fonctionner en mode source (alimentation) ou en mode ampèremètre (en série)
• Outil de référence pour le développement sur plateformes Nordic, mais utilisable avec n’importe quel MCU

Joulescope :

• Analyseur de puissance de précision avec une dynamique de courant de 9 décades
• Mesure simultanée du courant, de la tension et de l’énergie
• Interface logicielle avec export des données pour analyse statistique
• Particulièrement adapté aux mesures longue durée et aux profils de consommation complexes

Limitations du multimètre :

• Un multimètre standard est trop lent pour mesurer des courants pulsés. Un burst BLE de 5 ms à 15 mA sera moyenné avec les phases de veille et donnera une lecture faussement basse
• Le multimètre ne capture pas les pics : il est impossible de savoir si un pulse de 50 mA dure 1 ms ou 100 ms
• Utile uniquement pour vérifier le courant de veille stable sur une longue durée

Oscilloscope + résistance shunt :

• Insérer une résistance de faible valeur (1-10 Ω) en série avec l’alimentation et mesurer la tension à ses bornes
• Excellent pour caractériser les pulses de courant : forme, durée, amplitude
• Limitation : la chute de tension de la résistance shunt peut perturber le comportement du circuit si elle est trop élevée

Test de soak longue durée :

• Faire tourner le prototype pendant plusieurs semaines en conditions réelles
• Mesurer la courbe de tension batterie au fil du temps
• Corréler la décharge mesurée avec le bilan énergétique calculé. Si les deux divergent de plus de 20 %, quelque chose ne va pas — et il faut trouver quoi avant la production

L’approche AESTECHNO : du cahier des charges à la validation terrain

La gestion de l’énergie n’est pas une optimisation de dernière minute : c’est une discipline qui structure l’ensemble du projet, depuis le choix de la batterie et du régulateur jusqu’à la dernière ligne de firmware. Chez AESTECHNO, nous intégrons le bilan énergétique dès la rédaction du cahier des charges et nous le validons par mesure réelle avant chaque jalon.

Notre approche repose sur trois piliers :

• Bilan énergétique dès la spécification : avant de choisir un MCU ou un capteur, nous modélisons le profil de consommation complet du système. Cela permet de valider la faisabilité de l’objectif d’autonomie avant d’engager le design hardware
• Validation par mesure réelle : chaque prototype passe sur le banc de mesure. Nous caractérisons le courant dans chaque mode de fonctionnement et nous comparons au bilan théorique. Les écarts sont identifiés et corrigés avant de passer à la phase suivante
• Maîtrise de la chaîne complète : nous concevons le hardware, le circuit RF et le firmware. Cette maîtrise intégrée permet d’optimiser le système dans son ensemble — pas seulement un composant isolé

Nous avons l’expérience des régulateurs ultra-basse consommation, des modes de veille profonde sur nRF, STM32 et NXP, et des technologies de communication LPWAN et cellulaire IoT. Quand un client nous dit « mon produit doit tenir 5 ans sur batterie », nous savons exactement comment y parvenir — et comment le prouver.

Questions fréquentes

Quelle autonomie peut-on attendre d’une CR2032 pour un capteur IoT ?

Avec une capacité de 225 mAh et un courant moyen de 10 µA, une CR2032 tient environ 2,5 ans en théorie — moins en pratique à cause du dérating en température et de la limitation en courant pulsé. Pour des autonomies supérieures à 3 ans, nous recommandons une pile ER14250 (1 200 mAh) ou ER14505 (2 600 mAh) en lithium thionyl chloride.

Quelle est la différence entre System ON et System OFF sur un MCU Nordic ?

En System ON avec rétention RAM, le nRF52832 consomme environ 1,5 µA : la RAM est conservée et le RTC tourne. En System OFF, la consommation descend à 0,3 µA, mais toute la RAM est perdue — le système redémarre complètement au réveil. Le choix dépend de votre besoin : si le firmware doit reprendre exactement où il s’est arrêté, System ON est nécessaire.

DCDC ou LDO : lequel choisir pour un produit sur batterie ?

Pour maximiser l’autonomie, un DCDC buck est presque toujours préférable au LDO : son rendement de 85-95 % surpasse largement le ratio Vout/Vin du LDO. Cependant, le bruit de commutation du DCDC peut perturber les mesures analogiques et la radio. La solution optimale est souvent hybride : DCDC pour le rail principal, LDO en post-régulation pour les blocs sensibles.

Comment mesurer un courant de veille de quelques microampères ?

Un multimètre standard est insuffisant pour les mesures dynamiques. Utilisez un Power Profiler (Nordic PPK2) ou un analyseur de puissance (Joulescope) qui échantillonnent à haute fréquence et capturent les transitions entre veille et mode actif. Pour les pulses rapides, un oscilloscope avec résistance shunt (1-10 Ω) permet de caractériser la forme et la durée des pics de courant.

Le firmware a-t-il vraiment un impact sur l’autonomie batterie ?

Oui, et souvent plus que le choix du hardware. Un GPIO configuré en sortie haute au lieu d’en entrée haute impédance peut ajouter des dizaines de µA. Un peripheral non désactivé en veille, un busy-wait au lieu d’une interruption, un advertising BLE trop fréquent — chacune de ces erreurs peut diviser l’autonomie par 2 ou plus. Le firmware est le chef d’orchestre de la consommation.

AESTECHNO peut-elle concevoir un produit IoT basse consommation ?

Oui. AESTECHNO conçoit des produits IoT sur batterie avec des durées de vie de plusieurs années — du cahier des charges à la validation sur banc. Nous maîtrisons les plateformes nRF, STM32 et NXP, les régulateurs ultra-basse consommation, et les protocoles BLE, LoRaWAN, NB-IoT et LTE-M. Notre bureau d’études à Montpellier conçoit le hardware et le firmware ensemble pour optimiser le système dans son intégralité.

Articles connexes

• Concevoir l’électronique pour réussir dans l’IoT
• Bluetooth et BLE pour l’embarqué
• LPWAN : LoRaWAN, NB-IoT, Sigfox — comparatif
• NB-IoT, LTE-M et satellite : la connectivité cellulaire IoT
• Zephyr vs FreeRTOS vs Linux : quel OS temps réel ?
• Conception de cartes RF et intégration d’antennes
• Bureau d’études électronique AESTECHNO