150 000 systèmes IoT par an : ce que 9 ans d'embarqué m'ont appris sur la fiabilité

La phrase qui change tout

"En web, tu pousses un commit et le bug est corrigé. En embarqué, ton bug part chez 150 000 clients — et il y reste."

C'est la première chose que l'embarqué industriel apprend, et c'est la plus structurante. J'ai passé une partie de ma carrière sur du firmware — le logiciel qui tourne directement sur le matériel, au plus près du capteur et de l'actionneur — chez un fabricant qui produit ses systèmes de contrôle à l'échelle de l'ordre de 150 000 unités par an.

Cette contrainte-là ne se négocie pas. Et elle change complètement la façon d'écrire du code.

Pourquoi l'embarqué est un autre métier

Sur un backend web, la boucle de correction est courte : un incident, un hotfix, un redéploiement, et en quelques minutes tout le parc tourne sur le code corrigé. On peut donc se permettre une culture du « on verra en prod » — pas idéale, mais viable.

Sur du firmware déployé à grande échelle, cette boucle n'existe pas :

• Une mise à jour à distance (OTA, over-the-air) doit être infaillible : une update qui se passe mal ne « rollback » pas, elle transforme l'appareil en presse-papier — chez le client, sur un équipement qu'il a payé.
• Parfois il n'y a aucune mise à jour possible : le défaut reste figé dans le matériel livré pour toute sa durée de vie.
• Le coût d'une régression n'est pas un ticket de support : c'est un rappel terrain, de la logistique, de la réputation.

Conséquence directe : on ne livre pas une feature en espérant qu'elle marche. On la livre en ayant prouvé qu'elle ne peut pas casser.

Les contraintes concrètes

Le contexte technique de l'embarqué industriel n'a rien à voir avec un serveur qui dispose de gigaoctets de RAM et d'un GC qui ramasse les miettes :

• C bas niveau + RTOS (ici FreeRTOS) : pas de filet, on gère la mémoire à la main, on raisonne en octets et en cycles.
• Déterminisme temps réel : le système doit réagir dans une fenêtre garantie. Pas « en moyenne rapide » — garantie. Un retard, et l'actionneur physique rate sa fenêtre.
• Mémoire et CPU comptés : pas de marge pour l'allocation paresseuse, pas de « ça passe, on optimisera plus tard ».
• Robustesse aux états dégradés : coupure réseau, coupure d'alimentation en plein milieu d'une écriture, capteur qui renvoie n'importe quoi. Le système doit rester cohérent dans tous ces cas, pas seulement dans le cas heureux.
• Connectivité à grande échelle : remonter la télémétrie d'un parc massif vers le cloud sans saturer ni le réseau ni le backend.

Les trois réflexes que j'en ai gardés

1. Penser les états de panne d'abord, pas la feature d'abord

En embarqué, on commence par lister comment ça peut casser : coupure pendant l'écriture flash, message réseau tronqué, valeur capteur aberrante. La feature n'est conçue qu'après avoir cadré ces cas. C'est l'inverse du réflexe web (« je fais marcher le cas nominal, je durcis après »).

Je retrouve exactement ça quand je conçois un invariant métier : sur Vouch, la garantie « une réponse haute confiance cite sa source ou est rejetée » vit sur l'objet métier lui-même — elle est posée avant tout le reste, comme un état de panne qu'on rend impossible par construction.

2. Les marges ne sont pas optionnelles

Compter la mémoire et le CPU sur un microcontrôleur apprend qu'une ressource finie se gère explicitement. C'est la même logique qui me fait traiter le coût des appels IA comme une contrainte d'architecture sur Matchr : quotas, plans et marge minimale vérifiés avant la mise en production, pas un détail qu'on découvre sur la facture.

3. L'autorité et le déterminisme

Un système embarqué bien conçu a une source de vérité claire et un comportement déterministe — l'inverse d'un état qui « diverge » selon l'ordre des événements. Ce réflexe, je l'ai transposé tel quel sur OneRP : serveur autoritaire, état poussé qui s'invalide tout seul, zéro divergence possible entre les écrans.

Pourquoi je le raconte

On me connaît aujourd'hui pour le .NET et la GenAI. Mais la raison pour laquelle mes systèmes serveur tiennent en production, ce n'est pas le langage — c'est une discipline de fiabilité forgée là où l'erreur coûte le plus cher : sur du matériel qu'on ne peut pas redéployer d'un clic.

L'IoT industriel n'apprend pas à coder vite. Il apprend à coder pour que ça tienne — et c'est précisément ce qu'on cherche chez un senior à qui on confie un système critique.

Si votre produit a une composante embarquée, edge ou IoT — ou simplement un backend où une panne coûte cher — c'est ce terrain-là que j'ai déjà arpenté.