73 000 compteurs « intelligents » se sont éteints en une nuit — révélant tout ce qui cloche dans notre façon de concevoir l'IA pour les infrastructures

Un ami qui dirige les opérations d'un service public de l'eau de taille moyenne m'a appelé un samedi matin. Pas pour prendre des nouvelles — pour vider son sac. Son équipe venait de découvrir qu'une mise à jour de micrologiciel déployée la semaine précédente sur leur parc de compteurs intelligents avait discrètement corrompu les données de facturation de milliers de comptes. Les compteurs semblaient parfaitement normaux sur le tableau de bord. Des voyants verts partout. Mais les chiffres qui alimentaient le système de facturation étaient erronés, et personne ne s'en est rendu compte jusqu'à ce qu'une vague de plaintes de clients ne survienne.

« Le fournisseur dit que c'est un problème connu », m'a-t-il dit. « Ils travaillent sur un correctif. »

Je lui ai demandé depuis combien de temps les compteurs envoyaient de mauvaises données. Il a marqué une pause. « Environ neuf jours, pensons-nous. »

Cette conversation m'est restée en tête — non pas parce que la technologie avait échoué, mais en raison du caractère à ce point invisible de cette défaillance. Il ne s'agissait pas de compteurs qui s'étaient déconnectés. C'étaient des compteurs qui continuaient de ronronner, transmettant des données qui semblaient plausibles mais qui étaient silencieusement erronées. Et lorsque j'ai commencé à tirer le fil des défaillances de compteurs intelligents en Amérique du Nord et au Royaume-Uni, j'ai réalisé que la crise du samedi matin de mon ami n'était qu'une note de bas de page dans une histoire bien plus vaste.

La nuit où 73 000 compteurs sont devenus muets

À Plano, au Texas, la ville avait dépensé 10,2 millions de dollars pour 87 000 compteurs d'eau intelligents d'Aclara Technologies, en s'attendant à ce qu'ils durent vingt ans. Dès 2023, les batteries mouraient prématurément. La solution du fournisseur ? Une mise à jour de micrologiciel à distance déployée en novembre 2024 pour optimiser la consommation d'énergie.

Cette mise à jour a rendu 73 000 compteurs inutilisables.

Pas des « performances dégradées ». Pas des « problèmes intermittents ». Les systèmes de transmission électronique ont tout bonnement cessé de fonctionner. Plano — une ville de près de 300 000 habitants dans la métropole de Dallas-Fort Worth — a dû embaucher 20 releveurs de compteurs temporaires et revenir à des tournées à pied, de porte en porte. Coût : 765 000 $ sur deux ans, rien que pour la main-d'œuvre manuelle.

Je reviens sans cesse à l'amère ironie de la chose. Le micrologiciel était censé corriger le problème de batterie. Au lieu de cela, il a transformé un problème matériel localisé en un effondrement à l'échelle de tout le réseau. J'ai commencé à appeler cela le Paradoxe Micrologiciel-Batterie — le logiciel conçu pour prolonger la durée de vie du matériel devient le principal mécanisme de sa défaillance.

Le logiciel conçu pour prolonger la durée de vie du matériel devient souvent le principal mécanisme de sa défaillance.

Et Plano n'est pas un cas isolé. Toronto a perdu 470 000 transmetteurs à cause d'une dégradation précoce — 5,6 millions de dollars de coûts initiaux de remédiation. Memphis Light, Gas and Water a fait face à un taux de défaillance systémique de 8 % sur l'ensemble de son parc de compteurs intelligents, provisionnant 9 millions de dollars pour les réparations. Au Royaume-Uni, plus de 900 000 compteurs intelligents ont été réparés ou remplacés depuis que les régulateurs ont commencé à s'y intéresser.

J'ai décrit plus en détail l'architecture technique à l'origine de ces défaillances dans la version interactive de notre étude, mais le schéma est le même partout où je regarde : les services publics ont dépensé des milliards pour numériser leurs réseaux, et l'infrastructure « intelligente » tombe en panne plus vite que les compteurs mécaniques qu'elle a remplacés.

Pourquoi les compteurs intelligents meurent-ils prématurément ?

Lorsque mon équipe a commencé à analyser les causes profondes, nous nous attendions à trouver une fabrication bâclée ou des composants bon marché. La réalité était plus troublante.

Les compteurs intelligents ne sont pas de simples appareils de mesure. Ce sont des ordinateurs en réseau — processeurs intégrés, puces d'IA en périphérie, protocoles de communication sécurisés, mémoire flash pour le stockage des données. Et comme tout ordinateur, ils sont sujets à des modes de défaillance que les compteurs mécaniques n'ont jamais connus.

Le problème de la mémoire flash est particulièrement insidieux. Les compteurs intelligents utilisent de la mémoire flash NAND pour stocker le micrologiciel et les journaux de diagnostic. Chaque opération d'écriture génère des données obsolètes qui sont effacées par un processus appelé garbage collection, lequel use physiquement les cellules mémoire. Si les systèmes de fichiers embarqués ne sont pas optimisés — et dans de nombreux compteurs déployés, ils ne le sont pas — le stockage commence à corrompre les données des années avant la fin de vie théorique de l'appareil.

C'est là que l'appel du samedi matin de mon ami prend tout son sens. La corruption est souvent silencieuse. Le compteur ne génère pas d'erreur. Il ne se déconnecte pas. Il se met simplement à transmettre des chiffres légèrement erronés. Le temps que quelqu'un s'en aperçoive, vous vous retrouvez avec neuf jours — ou neuf mois — de données de facturation erronées et un problème de confiance client qu'aucun correctif de micrologiciel ne peut résoudre.

Il y a ensuite la crise des cas limites. La complexité logicielle des compteurs intelligents a grosso modo doublé ces dernières années, mais les méthodologies de test n'ont pas suivi le rythme. Une mise à jour de micrologiciel fonctionne parfaitement en laboratoire, mais déployez-la sur un compteur doté d'une batterie légèrement dégradée dans une zone rurale à faible signal, et vous obtenez Plano.

Un détail de l'étude qui m'a véritablement alarmé : les compteurs intelligents modernes intègrent un interrupteur « OFF » à distance, par commodité administrative. Si une erreur de logique dans le micrologiciel déclenche accidentellement cet interrupteur à grande échelle, vous ne faites pas face à des inexactitudes de facturation — vous faites face à des millions de foyers privés d'électricité simultanément.

Que se passe-t-il lorsque les régulateurs commencent à compter ?

Le régulateur britannique de l'énergie, l'Ofgem, a décidé qu'il en avait assez vu. À partir de février 2026, il applique des normes de performance garanties (Guaranteed Standards of Performance) qui imposent des paiements automatiques de 40 £ aux clients lorsque les standards de service des compteurs intelligents ne sont pas respectés. Attendre plus de six semaines un rendez-vous d'installation ? Paiement automatique. L'installation échoue parce que le fournisseur s'est présenté sans le bon équipement ? Paiement automatique. Une panne de compteur signalée sans plan de résolution sous cinq jours ouvrables ? Paiement automatique.

Ce n'est pas une simple tape sur les doigts. Pour un service public comptant des millions de clients et un parc de compteurs intelligents vieillissants, le calcul devient terrifiant très vite. La pression réglementaire a déjà entraîné la réparation de plus de 900 000 compteurs auparavant hors service au Royaume-Uni.

Je pense que l'initiative de l'Ofgem signale quelque chose de plus grand qu'un simple régulateur qui durcit le ton. C'est la formalisation d'un principe qui aurait dû être évident dès le départ : si vous déployez une infrastructure « intelligente », vous êtes responsable de la maintenir intelligente. L'ère qui consistait à installer du matériel, à partir et à espérer que tout se passe bien est révolue.

Si vous déployez une infrastructure « intelligente », vous êtes responsable de la maintenir intelligente. L'ère de l'« installer et oublier » est révolue.

Pour les dirigeants de services publics qui lisent ces lignes, l'implication est brutale. Le coût de la gestion d'un compteur défaillant — en pénalités réglementaires, en remédiation manuelle, en attrition des clients et en litiges de facturation — dépasse désormais le coût de la mise en place de diagnostics en temps réel pilotés par l'IA. L'équation économique s'est inversée.

« Utilisez simplement GPT » — le conseil qui m'empêche de dormir

Après avoir publié quelques premiers résultats sur la fragilité des compteurs intelligents, j'ai eu une conversation avec un investisseur potentiel à laquelle je repense encore. Il avait vu les données sur les défaillances de micrologiciel, convenu que le problème était réel, puis avait dit : « Construisez donc un wrapper ChatGPT qui analyse les données des compteurs. Livrez-le en trois mois. »

J'ai essayé d'expliquer pourquoi cela ne fonctionnerait pas. Il m'a coupé la parole. « Toutes les startups d'IA disent qu'elles ont besoin de construire des modèles sur mesure. La plupart d'entre elles se compliquent tout simplement la vie. »

Je comprends sa logique. Le marché est inondé d'entreprises qui ne sont essentiellement que de fines interfaces au-dessus des API d'OpenAI ou d'Anthropic — ce que le secteur appelle des « wrappers LLM ». Certaines d'entre elles sont réellement utiles pour des applications à faibles enjeux. Mais pour une infrastructure critique ? L'approche est fondamentalement défaillante, et je dois expliquer pourquoi.

Où vont les données ?

Lorsque vous utilisez une API d'IA publique, vos données quittent votre réseau et pénètrent dans les serveurs d'un tiers. Pour un service public, ces données comprennent l'architecture du réseau, les profils de consommation des clients, le code de micrologiciel propriétaire et, potentiellement, des vulnérabilités d'infrastructure classifiées. Ce n'est pas un risque hypothétique — c'est une exposition au US CLOUD Act et à toutes les politiques de conservation des données que le fournisseur d'API se trouve avoir ce trimestre-là.

J'appelle cela du « théâtre de la sécurité ». L'outil ressemble à une application d'entreprise privée et en donne toutes les apparences. Le tableau de bord affiche le logo de votre entreprise. Mais le backend, lui, est une infrastructure publique partagée, et vos données opérationnelles les plus sensibles transitent par l'infrastructure de quelqu'un d'autre.

Un modèle générique peut-il comprendre votre réseau ?

Un LLM public a lu Internet. Il sait ce qu'est un compteur intelligent dans l'abstrait. Ce qu'il ne sait pas, c'est la version précise du micrologiciel qui tourne sur vos compteurs Aclara du quadrant nord-est, l'historique de maintenance des transformateurs qui alimentent ce quartier, ou le fait que votre système de facturation hérité tronque les décimales d'une manière qui masque de petites erreurs de mesure.

La fenêtre de contexte d'une API publique oublie les subtilités de votre infrastructure spécifique. Elle ne peut pas effectuer l'analyse binaire nécessaire pour vérifier si une mise à jour de micrologiciel est sûre pour une révision matérielle particulière déployée dans une zone climatique particulière. Le lui demander revient à demander son chemin à un touriste — il peut avoir l'air sûr de lui, mais il ne sait pas vraiment où il va.

Que se passe-t-il lorsque l'API change ?

C'est l'aspect auquel les dirigeants de services publics pensent rarement avant qu'il ne soit trop tard. Si votre « solution d'IA » n'est qu'une couche de prompts au-dessus du modèle de quelqu'un d'autre, vous dépendez de sa tarification, de ses mises à jour de modèle, de sa disponibilité et de ses décisions commerciales. Lorsque OpenAI modifie la structure de son API ou abandonne une version de modèle, votre outil d'infrastructure critique cesse de fonctionner jusqu'à ce que quelqu'un réécrive les prompts.

Une infrastructure critique ne peut pas dépendre de la continuité d'activité de la page de tarification d'API d'une startup de la Silicon Valley.

À quoi ressemble vraiment la Deep AI

Après cette conversation avec l'investisseur, j'ai passé une semaine frustré. Puis j'ai passé trois mois à construire ce qui, selon moi, constitue réellement la réponse.

Chez Veriprajna, nous ne revendons pas de clés d'API. Nous ne construisons pas de wrappers. Nous déployons l'intégralité de la pile d'inférence d'IA — des moteurs comme vLLM, Text Generation Inference et BentoML — directement sur l'infrastructure du client. Ses clusters Kubernetes. Ses GPU bare-metal. Son Cloud Privé Virtuel.

La première fois que nous avons configuré un VPC à zéro sortie (zero-egress) pour un client de services publics — c'est-à-dire que le réseau était physiquement configuré de sorte que les données ne pouvaient pas quitter leur environnement même si quelqu'un configurait mal quelque chose — l'un de leurs ingénieurs en sécurité a regardé le schéma d'architecture et a dit : « C'est la première fois qu'un fournisseur d'IA ne me demande pas de faire une exception à notre politique de données. » Ce moment m'a fait comprendre que nous étions sur la bonne voie.

Construire un cerveau sémantique

Le problème du contexte — celui qui rend les LLM génériques inutiles pour un vrai travail sur l'infrastructure — nous le résolvons avec ce que je conçois comme un « cerveau sémantique ». Nous ingérons les documents propriétaires du service public : manuels techniques, rapports de maintenance historiques, code source de micrologiciel, registres d'incidents. Tout cela est indexé dans des bases de données vectorielles locales comme Milvus ou Qdrant, sans jamais quitter l'environnement du client.

Mais voici l'aspect dont je suis le plus fier : le système respecte les contrôles d'accès existants. Si un employé n'a pas la permission de consulter un document dans SharePoint, l'IA n'ira pas récupérer cette information pour répondre à sa requête. Nous n'avons pas greffé la sécurité après coup — nous avons conçu la couche d'intelligence pour qu'elle hérite de la posture de sécurité existante de l'organisation.

Le dernier kilomètre de la précision

Nous prenons des modèles de fondation ouverts comme Llama 3 et nous les affinons sur le corpus spécifique du service public à l'aide de techniques comme LoRA (Low-Rank Adaptation). Le résultat est un modèle sur mesure qui comprend la nomenclature du client, ses systèmes hérités, ses particularités opérationnelles. Lors de nos tests, cet affinage spécifique au domaine augmente la précision des tâches spécialisées jusqu'à 15 % par rapport au modèle de base.

Ces 15 % peuvent sembler marginaux. Ils ne le sont pas. En matière de vérification de micrologiciel, la différence entre 85 % et 100 % de précision, c'est la différence entre intercepter une mise à jour dangereuse et la laisser rendre 73 000 compteurs inutilisables.

Comment détecter un bug de micrologiciel avant qu'il n'atteigne le terrain ?

C'est la question qui m'a animé après avoir étudié le désastre de Plano. La mise à jour de micrologiciel qui a tué ces compteurs n'était pas malveillante. Elle n'avait pas été écrite par des ingénieurs incompétents. Elle n'avait tout simplement pas été testée face à l'ensemble des conditions réelles qu'elle allait rencontrer.

Nous avons construit un pipeline pour cela. Il commence par l'identification du binaire — à l'aide d'outils comme EMBA et Firmwalker pour extraire et analyser les systèmes de fichiers du micrologiciel, même lorsque le code source n'est pas disponible. Ensuite, nous décompilons le binaire avec Ghidra, et notre LLM privé analyse le code décompilé à la recherche de failles logiques, de pratiques non sécurisées et de vulnérabilités potentielles.

Mais l'aspect qui a changé ma façon de penser la sûreté des micrologiciels, c'est l'approche par jumeau numérique. Tester un micrologiciel sur des appareils physiques sur le terrain est lent, coûteux et risqué. À la place, nous construisons des répliques virtuelles détaillées de maisons intelligentes et de segments de réseau, puis nous déployons des agents d'IA qui utilisent l'apprentissage par renforcement pour interagir avec ces jumeaux numériques — sondant systématiquement les cas limites que les testeurs humains manquent.

Dans notre étude, cette méthode a détecté des vulnérabilités 38 % plus rapidement que les approches de test aléatoire. Pour l'analyse technique complète du pipeline de vérification de micrologiciel et de la méthodologie de jumeau numérique, je vous encourage à lire l'article — mais l'idée clé est la suivante : nous pouvons désormais simuler les conditions qui ont provoqué la défaillance de Plano avant que la mise à jour ne soit déployée.

Nous pouvons désormais simuler les conditions qui ont provoqué des défaillances catastrophiques de micrologiciel avant même que la mise à jour ne soit déployée sur le terrain.

Du réactif au prédictif : ce qui change quand l'IA surveille le réseau

L'approche traditionnelle de la maintenance des services publics est soit réactive (on répare quand ça casse), soit planifiée (on inspecte tous les X mois, que ce soit nécessaire ou non). Les deux sont coûteuses et les deux passent à côté des défaillances qui comptent le plus — les dégradations lentes et silencieuses qui ne se manifestent pas avant d'avoir déjà causé des dommages.

Les modèles de Deep AI entraînés sur des données de capteurs à haute fréquence apprennent à quoi ressemble la « normale » pour chaque appareil, chaque transformateur, chaque segment de réseau. Lorsque quelque chose dévie — un profil de vibration inhabituel, une fluctuation de température qui ne correspond pas à la météo, un parc de compteurs présentant tous une latence de communication accrue au même moment — le système le signale avant que cela ne devienne une crise.

Il y a eu un moment, lors de nos premiers tests, où le système de détection d'anomalies a signalé un groupe de compteurs présentant tous une légère augmentation de la latence de réponse. Rien de dramatique — peut-être 15 millisecondes de plus que la valeur de référence. Mon équipe s'est demandé s'il s'agissait de bruit ou de signal. Notre ingénieur soutenait que c'était environnemental — lié à la température. J'ai insisté pour approfondir. Il s'est avéré que c'était un indicateur précoce de dégradation de la mémoire flash dans un lot spécifique d'appareils. Sans intervention, ces compteurs auraient commencé à corrompre des données en quelques mois.

C'est le genre de détection qui justifie à lui seul l'investissement tout entier. Et les chiffres le confirment : il a été démontré que la maintenance prédictive pilotée par l'IA réduit les défaillances d'infrastructure de 73 %, diminue les coûts de maintenance de 18 à 25 % et prolonge la durée de vie des actifs jusqu'à 40 %.

Le système utilise également une IA explicable — lorsqu'il signale une anomalie, il montre à l'opérateur humain pourquoi, à l'aide d'outils de visualisation comme GradCAM. L'opérateur peut vérifier, corriger ou passer outre le jugement de l'IA. Cette boucle de rétroaction fait que le système devient plus intelligent au fil du temps, réduisant les faux positifs et bâtissant ce type de connaissance institutionnelle qui ne réside habituellement que dans la tête d'ingénieurs chevronnés à cinq ans de la retraite.

Qu'en est-il du ROI ?

Les gens objectent toujours sur le coût du déploiement d'une infrastructure d'IA privée par rapport au simple recours à une API. C'est une question légitime. Faire tourner ses propres clusters de GPU et maintenir ses propres modèles n'a rien de bon marché.

Mais considérez ce que coûte l'alternative. Plano : 765 000 $ pour des releveurs de compteurs manuels, plus l'investissement initial de 10,2 millions de dollars désormais fortement déprécié. Memphis : un fonds de réparation de 9 millions de dollars. Toronto : 5,6 millions de dollars et ce n'est pas fini. Les services publics britanniques : le coût cumulé de 900 000 remplacements de compteurs, plus les amendes réglementaires sur le point de commencer à tomber.

Les industries font état de coûts de panne moyens de 125 000 $ l'heure. Une réduction de 30 à 50 % des temps d'arrêt ne fait pas que rentabiliser l'IA — elle transforme le profil financier du service public. Lorsque vous y ajoutez le report des dépenses d'investissement grâce à un allongement de 40 % de la durée de vie des actifs, une réduction de 28 % des retards dans la chaîne d'approvisionnement des composants et une réduction de 40 % des incidents de sécurité, le calcul du ROI ne fait aucun doute.

La question n'est pas de savoir si les services publics ont les moyens de se doter d'une infrastructure d'IA souveraine. Elle est de savoir s'ils ont les moyens de subir un autre Plano.

Le véritable rempart concurrentiel d'un service public, ce n'est pas le modèle d'IA lui-même — vous pouvez télécharger Llama 3 gratuitement. Le rempart, c'est l'intégration profonde avec les données propriétaires, l'affinage spécifique au domaine, la connaissance institutionnelle encodée dans un système qui vit sur une infrastructure que vous contrôlez. C'est un actif qui prend de la valeur avec le temps. Un abonnement à une API est un coût qui peut vous être retiré.

Le réseau que nous construisons

Avec des appareils IoT dont le nombre devrait dépasser 30 milliards d'ici 2026, le problème de la complexité ne va pas disparaître. Il s'accélère. La prochaine frontière — et ce vers quoi mon équipe travaille activement — ce sont les flux de travail d'IA agentique : des systèmes qui ne se contentent pas de signaler les anomalies, mais qui agissent. Mettre automatiquement en quarantaine un appareil IoT compromis. Ajuster les paramètres d'un transformateur en temps réel en fonction des profils de charge prévus. Exécuter des retours arrière de micrologiciel dès qu'une mise à jour montre des signes de problèmes.

L'Edge AI poussera l'intelligence encore plus loin — des compteurs intelligents fonctionnant comme des micro-moteurs de décision, exécutant une détection d'anomalies locale avec une latence inférieure à 10 millisecondes, prenant des décisions sans attendre un aller-retour vers le cloud.

Mais rien de tout cela ne fonctionne si les fondations sont mauvaises. Et à l'heure actuelle, pour la plupart des services publics, les fondations sont mauvaises. Ils font tourner une infrastructure du XXIe siècle sur des paradigmes de maintenance du XXe siècle, et lorsqu'ils se tournent vers l'IA, ils saisissent l'option la moins chère et la plus commode — un wrapper autour de l'intelligence de quelqu'un d'autre — au lieu de bâtir une capacité souveraine.

Les défaillances de Plano, Toronto, Memphis et de tout le Royaume-Uni ne sont pas des pépins techniques. Elles sont le résultat prévisible d'une inadéquation systémique entre la complexité de l'infrastructure moderne et les outils que nous utilisons pour la gérer. Tout service public qui déploie des compteurs intelligents sans investir dans l'intelligence nécessaire pour réellement les gouverner construit un système conçu pour échouer d'une manière qu'il ne peut pas détecter.

Le choix qui s'offre aux dirigeants de services publics ne se situe pas entre l'IA et l'absence d'IA. Ce débat est clos. Le choix se situe entre louer de l'intelligence auprès de fournisseurs qui n'ont aucun intérêt dans la fiabilité de votre réseau, ou bâtir des capacités souveraines qui transforment vos données opérationnelles en votre actif le plus précieux. L'un de ces chemins mène au prochain Plano. L'autre mène à un réseau véritablement aussi intelligent que nous ne cessons de le promettre.