Quelques milliers de capteurs, une mise à jour poussée sans contrôle après redémarrage. La nouvelle version bootait correctement, sauf qu’elle ne retrouvait jamais le réseau. Une flotte vivante mais sourde, sans aucun moyen de revenir en arrière à distance. Il a fallu envoyer des gens sur site, armoire par armoire. Cette tournée-là m’a rappelé, vingt ans après mes débuts, pourquoi l’OTA est le mécanisme embarqué qui demande le plus de prudence.
Reprenons depuis le début. Tant qu’un prototype traîne sur un bureau, on le flashe par câble et tout va bien. Mais le jour où deux cents exemplaires sont répartis dans des sous-sols, des armoires techniques ou des champs, ce câble n’existe plus. Chaque correctif deviendrait un déplacement. La mise à jour à distance (OTA, « over-the-air ») cesse alors d’être une option.
Une mise à jour OTA sûre tient en trois réflexes : signer les firmwares et les vérifier côté objet, prévoir un retour arrière automatique quand la nouvelle version ne démarre pas, et ne jamais pousser à toute la flotte d’un coup.
Ce qu’on risque vraiment
Une OTA ratée donne un objet qui se coupe au mauvais moment et ne redémarre plus. On dit qu’il est « briqué », bon pour la déchetterie. Le pire, c’est qu’il devient injoignable précisément quand on aurait besoin de l’atteindre pour le réparer. Un objet isolé se remplace sans drame. À l’échelle d’une flotte, ça se chiffre en tournées de techniciens et en factures qui grimpent.
Signer, et vérifier côté objet
Chaque firmware part avec une signature produite par votre clé privée. Avant d’écrire quoi que ce soit, l’objet vérifie cette signature avec la clé publique embarquée. En cas de désaccord, il refuse, sans discussion. Deux garanties d’un coup : le firmware vient bien de vous, et il est arrivé intact. Négligez ce contrôle et votre canal de mise à jour se transforme en porte ouverte sur tout le parc, car il suffit alors d’y injecter n’importe quel binaire pour qu’il soit accepté partout.
Le double bank, le filet de sécurité
Voici la protection qui évite le briquage. On réserve deux emplacements de firmware, deux « banques » :
- la nouvelle version s’écrit dans la banque libre, pendant que l’ancienne reste là, intacte, prête à reprendre la main ;
- l’objet redémarre sur la nouvelle, mais ne la considère comme définitive qu’après l’avoir vue démarrer et tourner pour de bon ;
- en cas de plantage, ou si l’écriture a été coupée en cours de route, le bootloader (le petit programme de démarrage qui choisit quelle banque lancer) rebascule de lui-même sur l’ancienne banque.
Une mise à jour ratée redevient alors un non-événement. L’objet repart sur l’ancienne version, reste joignable, et on réessaie quand on veut. C’est ce qui transforme une opération stressante en routine.
Reste à définir ce que veut dire « tourner pour de bon ». Démarrer ne suffit pas : c’était exactement le piège de mon client industriel, dont le firmware bootait sans jamais joindre le serveur. La nouvelle version ne doit se déclarer valide qu’après avoir prouvé qu’elle fait son travail, autrement dit se reconnecter et recevoir un acquittement. Tant que cette preuve manque, l’ancien firmware garde la main. Sur certains microcontrôleurs on parle de watchdog applicatif ; le principe est le même.
Pousser par petits paquets
On ne diffuse jamais une mise à jour à toute la flotte d’un coup. Je démarre sur un lot réduit, de l’ordre de 2 à 3 % des objets, je laisse tourner un jour ou deux, et je surveille les remontées. Un défaut passé entre les mailles des tests ne touchera qu’une poignée d’objets, au lieu de coucher tout le parc un vendredi soir. Le premier lot une fois stable, j’élargis par paliers.
Une limite qu’il faut assumer
Tout ce que je viens de décrire suppose que l’objet sache, par lui-même, distinguer un firmware « qui marche » d’un firmware « qui démarre ». Et c’est précisément là que la méthode a ses angles morts. Un firmware peut se reconnecter, envoyer son acquittement, valider sa propre bascule, puis dériver trois jours plus tard sous une condition qu’aucun critère de démarrage n’avait anticipée : une fuite de mémoire lente, un cas réseau rare, ou un capteur qui se met à mentir au bout de quelques jours. Le retour arrière automatique ne couvre pas ces lentes dérives. Pour celles-là, il n’existe pas de filet magique, seulement une supervision attentive de la flotte après chaque palier, et l’humilité d’admettre qu’une version « validée » peut encore vous surprendre.