73 000 compteurs intelligents éteints en une nuit — et le firmware avait réussi tous les tests en laboratoire

En novembre 2024, un service public de Plano, au Texas, a déployé une mise à jour de firmware de routine sur 88 000 compteurs d'eau. Cette mise à jour était censée corriger une décharge prématurée des batteries — une réparation de bonne foi d'un problème connu. En laboratoire, elle fonctionnait. Sur le terrain, 73 000 compteurs se sont éteints et ne sont jamais revenus.

Je reviens sans cesse à ce chiffre à cause de ce qu'il implique. Ce n'était ni un piratage, ni une tempête, ni un défaut de fabrication. C'était une mise à jour logicielle testée et approuvée, se comportant exactement comme prévu — et elle a tout de même briqué 83 % d'un parc. Cet écart entre « validé en laboratoire » et « fatal sur le terrain » est tout le problème de l'IA des compteurs intelligents, et c'est pourquoi nous avons construit un système de maintenance prédictive AMI chez Veriprajna qui surveille les signaux qu'un tableau de bord analytique n'a jamais été conçu pour voir.

La première fois que je me suis assis avec le responsable des opérations d'un service public municipal pour examiner leur tête de réseau AMI — le système qui collecte les relevés de chaque compteur —, je m'attendais à une salle de contrôle. Ce que j'ai eu, c'était un tableur. Des horodatages de dernière communication, une ligne par compteur, et un lent défilement de cellules qui devenaient obsolètes. Il pouvait me dire, précisément, quels compteurs avaient cessé de communiquer. Il ne pouvait pas me dire lesquels s'arrêteraient ensuite. Cette asymétrie — une rétrospection parfaite, une prévision nulle — constitue tout le marché.

Pourquoi un firmware qui réussit les tests en laboratoire brique-t-il le terrain ?

Voici ce qui s'est réellement passé à Plano, et c'est l'histoire la plus instructive de ce domaine.

Le firmware avait été testé sur des compteurs équipés de batteries neuves et d'un signal radio fort — un banc d'essai impeccable. Mais le parc déployé avait quatre à cinq ans, et la plupart de ces batteries se situaient à 60 à 75 % de leur capacité d'origine. Les routines de gestion de l'alimentation mises à jour tiraient un peu plus de courant lors de la première écriture en mémoire flash. Sur une batterie neuve, sans importance. Sur une batterie dégradée, ce surcroît de consommation suffisait à déclencher la protection contre les baisses de tension. Les modules de transmission se réinitialisaient, perdaient leur enregistrement réseau et ne récupéraient jamais.

Le firmware n'a pas échoué. Il respectait les spécifications. Le parc avait simplement vieilli au-delà de ce que couvrait le banc d'essai, et personne ne modélisait cela.

Cette phrase est la thèse de tout ce que nous construisons. Le défaut n'était pas dans le code. Il résidait dans l'hypothèse qu'un compteur de laboratoire et un compteur de terrain sont la même machine. Ce n'est pas le cas, et la différence s'accumule silencieusement pendant des années avant que quelqu'un n'appuie sur le bouton qui la révèle.

Ces défaillances se regroupent. Le firmware du même fournisseur a provoqué des incidents similaires à Minneapolis, Toronto et New York. Toronto Hydro a découvert qu'environ 470 000 émetteurs se dégradaient prématurément et a dépensé 5,6 millions de dollars rien que pour la première phase de remédiation. Memphis a connu un taux de défaillance systémique de 8 % et a mis en place un fonds de réparation de 9 millions de dollars. Au Royaume-Uni, environ un compteur intelligent sur cinq ne fonctionne pas comme il le devrait ; plus de 600 000 ont été reconnectés depuis juillet 2024. Aucun de ces services publics ne manquait de plateforme analytique. Ils en avaient tous une. La plateforme ne surveillait simplement pas ce qui est tombé en panne.

L'erreur que j'ai défendue bien trop longtemps

Je veux être honnête au sujet de la version que nous avons ratée, car c'est la partie que la plupart des gens passent sous silence.

Quand nous avons commencé, le choix évident était la détection d'anomalies. Un compteur sur le point de tomber en panne devrait paraître bizarre dans ses données — relevés de consommation dérivant, lacunes dans les remontées, schémas étranges. Nous avons donc construit un modèle qui surveillait le flux de consommation et signalait les anomalies. C'était propre. La démonstration était superbe. Je l'ai défendu réunion après réunion.

Puis nous l'avons confronté à une véritable vague de dégradation sur un parc pilote, et il est resté au vert pendant que les compteurs se détérioraient discrètement en dessous. Je me souviens de la sensation précise de regarder le tableau de bord rester calme en étant certain que le modèle était défaillant. Le modèle n'était pas défaillant. Je l'avais pointé vers le mauvais signal.

La détection d'anomalies de consommation est exactement ce que font déjà les systèmes de gestion des données de comptage existants. Oracle a livré une détection d'anomalies alimentée par l'IA pour sa plateforme dédiée aux services publics en juin 2025 ; SAP est un leader de l'IDC MarketScape dans cette catégorie. Ces outils sont bons dans ce qu'ils font — ils repèrent un compteur qui remonte des chiffres étranges. Le problème, c'est qu'un compteur qui se dirige vers une mort par firmware ne remonte pas de chiffres étranges. Il remonte des chiffres parfaitement normaux, jusqu'au moment où il ne remonte plus rien. Nous avions reconstruit ce qui existait déjà et hérité de nouveau de son angle mort.

Un compteur défaillant n'a pas l'air malade dans ses données de consommation. Il paraît sain, puis il disparaît. Le signal dont vous avez besoin se trouve là où le flux de facturation ne peut pas voir.

Ce que le MDMS ne peut pas voir : deux signaux qui prédisent réellement la défaillance

Le tournant s'est produit quand nous avons cessé de demander « ce relevé est-il anormal ? » pour commencer à demander « qu'est-ce qui s'use physiquement dans un compteur, et pouvons-nous le mesurer avant qu'il ne casse ? »

Deux réponses comptaient.

La première est l'état de charge de la batterie, modélisé par cohorte de déploiement plutôt que comme une moyenne du parc. La leçon de Plano, c'est qu'un déploiement de firmware n'est dangereux que face à une distribution particulière de l'état de santé des batteries — et cette distribution est connaissable. Si vous regroupez chaque point terminal par date d'installation et construisez des histogrammes d'état de charge par cohorte, vous pouvez voir venir la falaise de baisse de tension avant de flasher quoi que ce soit. Nous avons commencé à mettre en scène les firmwares face au profil réel d'âge et de capacité du parc, et non face à un banc rempli d'unités neuves.

Le second est l'usure silencieuse de la mémoire flash NAND, et celui-ci a véritablement changé ma façon de concevoir toute la catégorie. Les compteurs intelligents enregistrent des données dans la mémoire flash — chaque relevé, chaque événement, à intervalles de 15 minutes pour la réponse à la demande. Chaque écriture use physiquement les cellules. Les fabricants annoncent des durées de vie de 20 ans, mais l'enregistrement à haute fréquence épuise les cycles d'écriture bien plus vite que ne le supposaient ces projections. Et voici la partie insidieuse : à mesure que la mémoire flash se dégrade, les relevés de consommation stockés dérivent de 2 à 8 % alors que le compteur continue de remonter normalement des données. La radio communique toujours. Le MDMS affiche un point terminal sain et communicant. Pendant ce temps, les chiffres sont discrètement faux, les litiges de facturation s'accumulent et la confiance du public s'érode — et lorsque le compteur devient totalement silencieux, la mémoire flash est trop dégradée pour même accepter un correctif de firmware. Cette unité nécessite un camion et un remplacement à 650 à 1 400 dollars pièce.

Ainsi, la colonne « compteur actif » du tableau de bord et sa colonne « qualité des données » peuvent se contredire pendant des mois, et presque personne ne lit la seconde. Nous avons fait de la contradiction entre ces deux colonnes l'alarme la plus forte du système.

« Oracle fait déjà cela. Pourquoi le construisez-vous ? »

Un conseiller que je respecte l'a formulé sans détour dès le début : le marché de l'analytique est encombré, les acteurs en place sont sérieux, pourquoi construire ?

C'est une question légitime, et la réponse honnête est que les acteurs en place se pressent autour d'un autre problème. La plateforme Distributed Intelligence d'Itron est réellement impressionnante — plus de 16 millions de compteurs activés, plus de 100 millions de points terminaux gérés, un partenariat de mars 2026 avec NVIDIA pour exécuter de l'IA à la périphérie du réseau. Revelo de Landis+Gyr, avec une collaboration Sense, réalise une désagrégation de charge au niveau des appareils à 1 mégahertz. Sensus a lancé Evolve début 2026 pour repositionner les compteurs comme des capteurs actifs du réseau. Toute l'industrie, comme l'a officialisé le thème 2026 de DistribuTECH, passe « de l'AMI à l'IA ».

Mais chacune de ces piles analytiques ne fonctionne qu'avec les points terminaux du fournisseur concerné. L'intelligence d'Itron voit les compteurs Itron. Celle de Landis+Gyr voit ceux de Landis+Gyr. Les vrais services publics exploitent des parcs mixtes constitués au fil d'une décennie de cycles d'approvisionnement — des Aclara, des Itron, des Sensus — et l'analytique d'aucun fournisseur unique ne les couvre tous. Et aucune d'elles, propriétaire ou non, n'offre de simulation de firmware avant déploiement face à votre parc vieillissant spécifique. La faille qui a briqué Plano n'appartient, structurellement, à personne.

Les acteurs en place vous diront qu'un compteur remonte des données. Les outils de sécurité OT vous diront qu'il exécute un firmware vulnérable. Aucun ne vous dira qu'il est à trois mois d'une mort matérielle.

Les fournisseurs de sécurité méritent d'être nommés ici, car on suppose qu'ils couvrent ce point. Claroty, Nozomi, Armis — ils réalisent une excellente découverte des actifs, jusqu'à la version du firmware sur chaque point terminal, et ils maîtrisent les protocoles industriels. Mais ils sont conçus pour repérer le compteur qui exécute une version de firmware exploitable, pas le compteur dont la cohorte de batteries ne survivra pas à la prochaine écriture flash. La maintenance et la sécurité regardent le même appareil et posent des questions différentes. Nous avions besoin de la question de la maintenance, et elle n'était pas posée.

Le banc où le firmware va échouer volontairement

L'élément dont je suis le plus fier est le moins glamour : un banc d'émulation où le firmware échoue avant d'atteindre le compteur d'un client.

Nous mettons en place un environnement QEMU — un logiciel qui émule le matériel réel du compteur — et flashons une image de firmware candidate sur des points terminaux simulés portant les véritables profils de batterie et de signal du parc. La cohorte à batterie dégradée, la cohorte à RF faible, la cohorte à cycles d'écriture élevés. La première nuit où nous avons exécuté un profil modélisé sur un parc vieillissant et regardé l'unité émulée subir une baisse de tension exactement comme le fait le terrain et jamais le laboratoire, j'ai enfin compris que Plano n'était pas un accident. C'était reproductible. Cela n'avait simplement jamais été reproduit avant le déploiement, parce que l'environnement de test n'existait pas.

C'est là l'inversion. Aujourd'hui, le terrain est l'environnement de test, et les clients sont les sujets d'essai. Nous déplaçons la défaillance dans un laboratoire où briquer un millier de compteurs simulés ne coûte rien et vous apprend tout.

La maintenance prédictive ne signifie-t-elle pas simplement plus de fausses alertes ?

L'objection que j'entends le plus souvent de la part des opérationnels — ceux qui se sont fait échauder par des outils qui crient au loup — est que la prédiction n'est qu'une façon plus sophistiquée de générer du bruit.

C'est la bonne inquiétude. Un modèle de notation de santé qui signale 30 % de votre parc chaque semaine est pire qu'inutile ; les équipes apprennent à l'ignorer, et vous avez dépensé du budget pour recréer la fatigue d'alerte dont vous êtes parti. Nous avons donc calibré sur le coût, et non sur le nombre d'anomalies. Le critère n'était pas « combien de défaillances avons-nous détectées » mais « combien d'interventions sur site avons-nous évitées par rapport à celles que nous avons déclenchées ». Les données du secteur sur la maintenance prédictive pilotée par l'IA font état de réductions allant jusqu'à 30 % des coûts de maintenance et de baisses significatives des temps d'arrêt lorsqu'elle s'appuie sur le bon signal — et le bon signal, encore une fois, est l'usure physique, pas la bizarrerie des données. Une prédiction qui ne change pas une décision de répartition n'est pas une prédiction. C'est une notification. C'est, je crois, pourquoi tant de services publics expérimentent la maintenance par IA puis stagnent — les travaux de BCG de 2026 sur les services publics pointent explicitement l'écart entre le pilote et la production — ils prouvent qu'un modèle peut signaler des défaillances, puis ne peuvent pas justifier le déploiement parce que les signalements n'ont jamais été reliés à une répartition à laquelle un chef d'équipe ferait réellement confiance.

La gestion des firmwares vient de devenir un document de conformité

Il y a ici un tournant réglementaire que, je pense, beaucoup de services publics n'ont pas pleinement assimilé, et il augmente considérablement les enjeux.

Depuis le 1er avril 2026, la norme NERC CIP-003-9 est en vigueur. Son exigence R1, partie 1.2.6, impose des contrôles de sécurité sur l'accès à distance des fournisseurs aux systèmes cyber du réseau à faible impact — catégorie dans laquelle la plupart des compteurs intelligents sont classés. En clair : le chemin de mise à jour par voie hertzienne (OTA) que vous utilisez pour déployer les firmwares est désormais une surface de contrôle réglementée, et les sanctions en cas d'erreur peuvent atteindre 1 million de dollars par jour. Le même canal OTA qui a briqué Plano est désormais aussi un artefact de conformité pour lequel vous devez produire des preuves.

Cela change entièrement la conversation avec l'acheteur. La gestion des firmwares était autrefois une corvée opérationnelle. Désormais, les journaux d'accès, les enregistrements de préparation, les procédures de retour arrière — ils vont dans un classeur que lit un auditeur. Un système qui valide le firmware avant déploiement ne se contente plus de prévenir les pannes ; il génère la preuve que vous avez géré le chemin de mise à jour de manière responsable.

Il existe sous celle-ci une norme plus discrète sur laquelle les équipes d'approvisionnement s'interrogent et obtiennent rarement une réponse claire : l'IEC 62443, la norme de cybersécurité industrielle pour l'AMI. Très peu de fournisseurs de compteurs ont visé la certification complète IEC 62443 au niveau du composant — le firmware lui-même. La plupart certifient au niveau du système et laissent le firmware du point terminal non certifié, ce qui signifie que la couche exacte qui a briqué Plano est aussi celle dont l'attestation de sécurité est la plus mince. Cet écart est la raison pour laquelle nous réalisons des audits de sécurité au niveau des composants sur des chaînes d'approvisionnement AMI hétérogènes, pas seulement sur la tête de réseau. De l'autre côté de l'Atlantique, les normes de l'Ofgem au Royaume-Uni imposent désormais une compensation automatique — 40 £ par cas — pour les défaillances de compteurs imputables au fournisseur, versée sous 10 jours ouvrés. Le coût d'un compteur mort n'est plus seulement l'intervention sur site. C'est l'amende, la compensation et le constat d'audit.

Ce que je dirais au responsable des opérations au tableau de bord obsolète

Si je revenais maintenant à ce tableur d'horodatages obsolètes, voici ce que je dirais.

Le chiffre qui devrait vous empêcher de dormir n'est pas celui des compteurs déjà devenus muets. C'est le 29 % — la part des points terminaux que certains services publics ont découvert avoir défailli silencieusement, radios éteintes, sans qu'aucune alerte n'ait jamais été déclenchée, ne refaisant surface que lorsque quelqu'un est allé chercher. Votre plateforme ne vous ment pas. Elle répond à une question plus étroite que celle que vous avez réellement. Elle sait qui a cessé de communiquer. Vous devez savoir qui est sur le point de le faire.

Le marché des compteurs intelligents se dirige vers 112 milliards de dollars d'ici 2035, et la base installée en Amérique du Nord dépasse déjà les 150 millions d'unités. Chacun de ces points terminaux est un petit ordinateur doté d'une batterie vieillissante et d'une puce flash qui s'use, posé sur le flanc d'un bâtiment, attendant un déploiement de firmware testé quelque part où il ne vit pas. Le prochain Plano est déjà provisionné. La seule question ouverte est de savoir si quelqu'un a modélisé le parc sur lequel il est sur le point d'atterrir. Si vous préférez le découvrir sur un banc plutôt que sur les murs de 73 000 clients, c'est le système à construire.

Le firmware qui a briqué Plano a réussi tous les tests qu'on lui a soumis. Nous ne lui avons simplement jamais donné le bon.