Quand le modèle se trompe et que la lumière compte

En février 2021, le Texas est passé à quelques minutes d'un blackout total de son réseau. ERCOT (Electric Reliability Council of Texas, le gestionnaire de réseau de la majeure partie de l'État) disposait de prévisions de charge et de production qui sous-estimaient largement la capacité qui allait geler et sortir du réseau pendant la tempête hivernale Uri. Résultat : des coupures tournantes pour des millions de personnes, plus de 200 morts selon le décompte officiel, et des dizaines de milliards de dommages. Aucun modèle d'IA n'a causé Uri à lui seul. Mais l'épisode est la meilleure illustration disponible de ce qui se produit quand une erreur de prévision rencontre un système physique dépourvu de bouton d'annulation. C'est le scénario autour duquel cette leçon est construite : ce qui arrive quand un modèle de prévision de charge ou de prédiction de panne se trompe, et comment classer le risque avant plutôt qu'après.

La cascade, étape par étape

Les gestionnaires de réseau modernes s'appuient sur le machine learning pour trois tâches de prévision essentielles : la prévision de charge à court terme (anticiper la demande à quelques heures ou jours), la prévision de production renouvelable (production éolienne et solaire), et la prédiction de panne ou de défaut (quelles lignes ou quels transformateurs risquent de tomber).

Voici une chaîne de défaillance plausible, tirée de catégories réelles d'incidents :

1. Un modèle de prévision de charge, entraîné surtout sur des données d'hivers doux, sous-estime le pic de demande pendant une vague de froid extrême.
2. Les gestionnaires engagent moins de réserve de production que nécessaire, parce que le modèle annonce une demande modérée.
3. La demande dépasse la prévision. Les réserves sont minces.
4. Les opérateurs doivent délester (coupures volontaires) pour éviter une défaillance en cascade, où le déséquilibre fait déclencher les relais de protection sur une vaste zone, mode de défaillance qui a produit le blackout du Nord-Est en 2003 touchant 50 millions de personnes.
5. Hôpitaux, stations de pompage d'eau et stations de compression de gaz (qui ont besoin d'électricité pour continuer d'acheminer le gaz vers les centrales) perdent leur alimentation, aggravant la crise.

L'erreur de modèle à l'étape 1 paraît minime : une prévision fausse de 10 à 15 %. La conséquence à l'étape 5 n'est pas minime du tout. Cet écart entre la taille de l'erreur en entrée et la taille de la conséquence en sortie, c'est tout le propos de cette leçon.

Classer le risque IA : blast radius et réversibilité

Empruntez deux dimensions à l'ingénierie de la sûreté, plutôt qu'aux listes génériques d'éthique de l'IA, parce qu'elles correspondent directement à la physique du réseau.

Blast radius : combien de personnes, d'actifs ou de systèmes sont touchés si le modèle se trompe.

• Étroit : le planning de maintenance d'un seul poste électrique.
• Large : des décisions de dispatch régional affectant des millions de clients.

Réversibilité : la facilité avec laquelle on peut défaire la conséquence une fois survenue.

• Réversible : un signal de demand-response mal tarifé qui coûte de l'argent et se corrige au cycle suivant.
• IrrIrrLe taux de rendement interne est le taux d'actualisation qui annule la valeur actuelle nette d'un projet. Il exprime le rendement annualisé attendu d'un investissement.Voir la définition complète →éversible ou lent à réparer : un blackout avec dommages matériels en cascade, ou un incident de sécurité sur un poste électrique.

Placez n'importe quel cas d'usage d'IA énergétique sur cette matrice 2x2, et vous obtenez une règle de gouvernance opérationnelle : plus le blast radius est élevé et la réversibilité faible, plus vous exigez de supervision humaine et de tests avant déploiement, quelle que soit la qualité des métriques de précision du modèle en laboratoire.

C'est la même logique que celle des catégories de risque de l'AI Act européen (la réglementation de l'Union européenne à niveaux de risque, en vigueur depuis 2024 avec des obligations échelonnées jusqu'en 2027). La gestion des infrastructures énergétiques y est explicitement citée comme un domaine pouvant déclencher une classification « haut risque », imposant des évaluations de conformité, une supervision humaine et une gestion documentée des risques avant déploiement. Voir la présentation par la Commission européenne de l'approche par les risques de l'AI Act pour le texte source.

Ce que disent réellement les règles américaines et européennes

Ne partez pas du principe qu'il existe une loi unique sur « l'IA dans l'énergie ». Il n'y en a pas, dans aucune des deux juridictions, en 2026. À la place :

États-Unis : la NERC (North American Electric Reliability Corporation, l'organisme qui fixe les normes de fiabilité obligatoires du réseau de transport) n'a pas encore de norme spécifique à l'IA. Les normes CIP (Critical Infrastructure Protection) existantes encadrent largement la cybersécurité et le risque opérationnel, et la NERC a publié des lignes directrices traitant les outils pilotés par IA utilisés dans l'exploitation du réseau comme soumis aux mêmes exigences de fiabilité et de change management que tout autre logiciel opérationnel. La FERC (Federal Energy Regulatory Commission) a ouvert des consultations sur le rôle de l'IA dans la planification du réseau et la prévision de charge, compte tenu de la poussée de la demande des data centers, mais des règles contraignantes propres à l'IA restent en gestation.

Union européenne : l'AI Act est l'instrument contraignant. Les systèmes de gestion de réseau électrique relèvent des catégories haut risque de l'Annexe III lorsqu'ils affectent la sûreté d'infrastructures critiques. Cela déclenche des exigences de systèmes de gestion des risques, de documentation technique, de supervision humaine et de surveillance après mise sur le marché, obligations qui entrent en vigueur progressivement de 2026 à 2027.

À retenir pour un manager : la réglementation est en retard sur le déploiement. Autrement dit, la gouvernance interne (les contrôles de la section suivante) réduit aujourd'hui plus de risque réel que la loi externe, surtout aux États-Unis.

Les garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → avant de déployer

Une checklist concrète avant déploiement, calibrée selon le blast radius :

• Backtesting sur des événements extrêmes, pas sur des journées moyennes. Un modèle de prévision de charge à 97 % de précision sur des journées typiques ne dit rien de son comportement pendant un vortex polaire ou un dôme de chaleur. Exigez des scénarios de stress-test explicites fondés sur des données historiques de météo extrême.
• Human-in-the-loop pour tout ce qui touche au dispatch ou au délestage. Aucune action totalement autonome sur des décisions à blast radius large et faible réversibilité. Le modèle recommande, un opérateur habilité confirme.
• Monitoring du drift des modèles. Les conditions du réseau changent (plus de solaire distribué, plus de charge de recharge de véhicules électriques) plus vite que les cycles annuels de réentraînement. Mettez en place des alertes automatiques quand les taux d'erreur en production dépassent les seuils issus du backtesting.
• Procédures de repli quand le modèle est indisponible ou clairement faux. ERCOT et d'autres gestionnaires maintiennent des procédures manuelles, sans IA, précisément parce qu'un logiciel peut défaillir ; le garde-fou consiste à disposer d'un repli validé et exercé, pas simplement supposé.
• Validation indépendante des modèles, séparée de l'équipe qui les a construits, à l'image du concept de « deuxième ligne de défense » du model risk management bancaire, adapté ici à l'infrastructure physique plutôt qu'à l'exposition financière.

Un extrait de monitoring simple, du genre qu'un analyste proche des opérations devrait pouvoir lire même s'il ne l'a pas écrit :

# Signaler quand l'erreur de prévision en production dépasse la tolérance issue du backtesting
forecast_error = abs(actual_load - predicted_load) / actual_load

if forecast_error > 0.08:  # seuil de 8 %, calibré sur les extrêmes historiques
    trigger_alert("Load forecast deviation exceeds safe threshold")
    escalate_to_human_operator()

La valeur du seuil (8 % ici, à titre d'illustration) doit provenir de votre propre backtesting, pas d'un réglage par défaut du fournisseur.

Qui porte la responsabilité en cas d'échec

La gouvernance ne fonctionne que si la responsabilité est nommée à l'avance, pas plaidée après coup.

Les utilities qui utilisent des outils de prévision IA tiers (c'est courant : Enel, EDF, et des utilities américaines comme Duke Energy et Southern Company recourent toutes à des modèles fournisseurs externes ou hybrides pour la prévision de charge et de renouvelables) conservent la responsabilité opérationnelle de la fiabilité au titre des normes NERC aux États-Unis, ou de leurs équivalents nationaux dans l'UE. Les contrats fournisseurs devraient préciser les obligations de validation des modèles, mais l'obligation de fiabilité ne quitte pas l'utility au motif que le modèle vient d'un tiers.

C'est la phrase de gouvernance la plus importante de cette leçon : vous ne pouvez pas externaliser la responsabilité d'une décision au motif que vous avez externalisé le modèle qui l'a éclairée.

À retenir

• Classez chaque cas d'usage d'IA énergétique sur deux axes avant déploiement : blast radius (combien de personnes touchées) et réversibilité (difficulté à revenir en arrière). Blast radius élevé plus faible réversibilité signifie supervision humaine obligatoire, pas seulement une bonne précision de modèle.
• Les modèles de prévision entraînés sur des conditions moyennes peuvent défaillir précisément quand cela compte le plus : météo extrême, pics de demande, contrainte sur le matériel. Faites du backtesting sur les extrêmes, pas sur les moyennes.
• La réglementation rattrape son retard mais reste incomplète : l'AI Act européen traite les infrastructures critiques de réseau comme haut risque avec des obligations contraignantes ; aux États-Unis, la supervision NERC/FERC spécifique à l'IA est encore en construction. La gouvernance interne pèse aujourd'hui plus lourd que la loi externe.
• La responsabilité de la fiabilité reste chez l'utility ou le gestionnaire, même quand le modèle est fourni par un fournisseur. Les contrats doivent le refléter, pas le brouiller.
• Construisez et exercez des procédures de repli sans IA pour chaque outil opérationnel piloté par IA. Un modèle dont vous ne pouvez pas vous replier en sécurité est un modèle que vous n'avez pas correctement dérisqué.