Qui est responsable de l'algorithme ? Dispatching électrique agentique

Introduction

Les systèmes électriques utilisent déjà l'automatisation. Les relais de protection agissent en millisecondes, la régulation automatique de la production ajuste la puissance, les systèmes de gestion de l'énergie assistent les salles de contrôle, et les plateformes de marché répartissent les ressources au moyen de règles codifiées. L'intelligence artificielle agentique introduit une combinaison différente de capacités. Un système peut interpréter un objectif, récupérer des données, choisir des outils analytiques, générer un plan, communiquer avec d'autres systèmes et recommander ou déclencher une action. Cette combinaison peut comprimer le temps de décision et coordonner des portefeuilles complexes. Elle peut aussi masquer l'entrée, le modèle, l'appel d'outil ou l'approbation qui a produit l'instruction finale.

Les opérations électriques exigent une responsabilité avant le passage à l'échelle. Une action de répartition peut modifier les flux physiques, l'exposition au marché et la performance contractuelle. Une erreur peut rester locale, ou interagir avec la congestion, des contrôles corrélés et des conditions système sous tension. Les travaux de l'Agence internationale de l'énergie sur la modernisation des réseaux identifient des solutions améliorées par AI sur l'ensemble de la planification, de l'exploitation et de la maintenance, tout en soulignant l'importance de la gouvernance à mesure que les applications deviennent plus critiques pour la sécurité. Le Department of Energy des États-Unis teste des capacités de grands modèles de langage et agentiques pour les environnements d'infrastructure critique. Les institutions énergétiques européennes élaborent une politique pour la numérisation et AI, tandis que les gestionnaires de réseau ont demandé une responsabilité claire, une auditabilité et une supervision humaine.

La question d'investissement va au-delà de la capacité d'un modèle à produire une recommandation utile. Le propriétaire d'actifs doit savoir qui approuve l'objectif, qui définit la limite d'autorité, qui valide la performance, qui peut passer outre le système, qui enregistre les preuves, qui supporte la perte et qui finance la remédiation. Un prêteur doit savoir si l'emprunteur peut continuer à opérer lorsque l'agent, le service de données ou le fournisseur fait défaut. Un régulateur doit pouvoir identifier l'entité qui reste responsable de la conformité.

Cet article répond à ces questions au moyen d'une architecture de gouvernance et de financement conçue pour des décisions d'exploitation réelles.

1 Définir précisément la répartition agentique

La répartition agentique est l'utilisation d'un système activé par AI qui effectue plus qu'une simple prédiction. Il peut décomposer un objectif d'exploitation, rassembler des informations, invoquer des outils analytiques ou transactionnels, évaluer des alternatives et produire une recommandation ou une action. L'objectif peut être de maintenir un profil de livraison contractuel, de minimiser le coût d'équilibrage, de préserver l'état de charge d'une batterie, de répondre à une instruction du système ou de coordonner une demande flexible.

Le terme ne doit pas s'appliquer à tout contrôle automatisé. Un relais de protection déterministe, une routine d'optimisation à entrées et contraintes fixes, et une prévision par apprentissage automatique présentent des risques différents. La gouvernance commence par un inventaire fonctionnel qui identifie chaque composant et son autorité. L'inventaire doit distinguer l'ingestion de données, la prévision, l'optimisation, les interfaces linguistiques, la planification, la sélection d'outils, l'approbation des actions, l'exécution et la surveillance.

L'attribut décisif est l'autorité. Un système qui rédige une explication pour un opérateur dispose d'une autorité opérationnelle limitée. Un système qui peut soumettre une offre, modifier une consigne ou engager une batterie dispose d'une autorité matérielle, même lorsque sa sortie ressemble à une recommandation. La direction doit classifier le chemin d'autorisation réel, y compris les identifiants API, les approbations par défaut et les temps de réponse des opérateurs. Des descriptions telles que l'aide à la décision peuvent devenir trompeuses lorsque le flux de travail rend le rejet humain impraticable.

2 Maintenir la responsabilité rattachée aux entités juridiques et aux rôles nommés

Un algorithme ne peut pas détenir un mandat du conseil d'administration, une licence réglementaire, un certificat d'exploitation ou une obligation contractuelle. La responsabilité doit rester attribuée aux entités juridiques et aux rôles nommés. L'opérateur réglementé reste responsable de ses obligations d'exploitation. Le propriétaire d'actifs reste responsable de l'installation et des contrats. Un fournisseur reste responsable des obligations qu'il accepte. Les personnes restent responsables des décisions relevant de leur autorité déléguée.

Le conseil d'administration doit approuver l'appétit pour le risque et la classe d'autonomie maximale autorisée. Un dirigeant responsable doit assumer le cas d'usage et le résultat économique. Le responsable de la salle de contrôle ou des opérations de marché doit assumer les procédures d'exploitation et l'autorité. Un propriétaire du modèle doit maintenir le système. Un validateur indépendant doit remettre en question la performance et les limites. Les responsables de la cybersécurité et des technologies opérationnelles doivent contrôler l'accès et la résilience. Les équipes juridiques, de conformité et d'assurance doivent répartir les obligations avant le déploiement.

Cette répartition évite un échec de gouvernance courant : une participation collective sans propriété décisionnelle identifiable. Un comité peut examiner les preuves, mais un dirigeant responsable doit accepter le risque résiduel. L'escalade doit nommer la personne autorisée à suspendre le système. Les protocoles d'incident doivent identifier le responsable opérationnel, le responsable de l'enquête technique, le responsable des notifications réglementaires et le responsable des pertes financières.

3 Classifier l'autonomie selon l'autorité opérationnelle

Tableau 1. Classes d'autonomie pour la répartition électrique agentique

La classification est un cadre de gouvernance élaboré par l'auteur. Les règles opérationnelles, licences et exigences d'approbation applicables varient selon la juridiction et le système.

La classe doit suivre l'autorité la plus élevée que le système peut exercer, et non celle que la direction s'attend à ce qu'il utilise. Les identifiants, les chemins réseau et la conception de l'intégration déterminent la capacité. Un moteur de recommandation relié à un script d'approbation automatique doit être classé comme exécution.

La classe 3 peut créer une valeur substantielle tout en conservant des limites gouvernables. Elle peut permettre à une batterie de répondre dans les limites de puissance, d'énergie, de dégradation, de réserve et contractuelles. Les contraintes strictes doivent se situer en dehors du processus de raisonnement modifiable de l'agent. La classe 4 s'applique à des fonctions étroites de protection ou de réserve où la vitesse est essentielle et où les garde-fous déterministes dominent. La classe 5 exige une base de preuves beaucoup plus solide, car le système peut modifier des objectifs, coordonner des ressources ou prendre des mesures au-delà d'un périmètre restreint.

4 Construire l'architecture de responsabilité du dispatching

La figure est un modèle de contrôle élaboré par l'auteur. Chaque couche exige des éléments de preuve juridiques, techniques, opérationnels et contractuels propres à l'actif.

L'architecture est cumulative. Une validation robuste du modèle ne peut pas compenser un objectif non défini. Un objectif clair ne peut pas compenser des contrôles d'exécution faibles. Des journaux complets ne peuvent pas rétablir la responsabilité si personne n'assume la responsabilité de la décision opérationnelle.

La couche supérieure relie le cas d'usage à l'appétit pour le risque du conseil d'administration, aux obligations réglementaires et à la fiabilité du système. La deuxième attribue un dirigeant responsable. La troisième traduit la politique en limites exécutables. La quatrième valide les modèles, les données et les outils. La cinquième définit la supervision humaine et les procédures opérationnelles. La sixième applique des contraintes techniques indépendantes. La septième produit des éléments de preuve et répartit la réponse aux incidents et les conséquences financières.

Un comité d'investissement doit évaluer chaque couche. Une notation rouge au niveau de l'autorité, de l'exécution ou de la couche de repli doit empêcher le déploiement en production. Une faiblesse dans l'attribution économique peut empêcher l'approbation du capital même lorsque le système est techniquement sûr. Cette séparation empêche que l'approbation de sécurité soit considérée comme une preuve de valeur et empêche qu'un dossier d'investissement attrayant contourne les contrôles opérationnels.

5 Spécifier l'objectif opérationnel et les objectifs interdits

Un agent exige un objectif. Des objectifs tels que minimiser les coûts ou maximiser les revenus sont incomplets, car ils peuvent entrer en conflit avec la fiabilité, les contrats, les limites des équipements et la conduite sur le marché. L'objectif approuvé doit exprimer un ordre de priorité : respecter les instructions du système ; préserver une exploitation sûre ; respecter les obligations contractuelles ; maintenir les réserves requises ; puis optimiser le résultat économique dans les limites de risque.

Les objectifs interdits doivent être tout aussi clairs. Le système ne doit pas apprendre à retenir de la capacité, à créer des offres trompeuses, à contourner l'écrêtement, à exploiter des données indisponibles aux acteurs de marché autorisés ou à négocier au-delà des limites déléguées. Il ne doit pas modifier sa propre politique de contrôle, ses identifiants ou ses contraintes de sécurité. Toute mise à jour d'apprentissage ou de configuration doit passer par un processus de changement contrôlé.

Les conflits d'objectifs nécessitent une résolution déterministe. Lorsqu'une instruction commerciale entre en conflit avec une instruction système ou de sécurité, la hiérarchie doit déterminer l'issue. L'agent doit identifier le conflit, arrêter l'action concernée lorsque cela est requis et escalader vers le rôle désigné. Le journal doit conserver les preuves disponibles à ce moment-là.

6 Définir l'enveloppe d'autorité en termes applicables par machine

Les documents de politique sont insuffisants lorsque l'exécution passe par un logiciel. L'enveloppe d'autorité doit être traduite en contrôles que l'agent ne peut pas modifier. Les limites peuvent inclure les actifs, les marchés, les instruments, les horizons temporels, les mégawatts, l'état de charge, les taux de rampe, les bornes de prix, l'exposition au risque de crédit, les engagements de réserve, les autorisations de contrepartie et la perte cumulée.

L'enveloppe doit prendre en compte les combinaisons. Une série d'actions autorisées individuellement peut créer une position agrégée non autorisée. Les contrôles de portefeuille doivent calculer l'exposition physique et financière totale avant exécution. Les agents corrélés doivent partager les informations de contrainte via un service de contrôle indépendant plutôt que de compter sur chaque agent pour déduire l'état du portefeuille.

Le temps compte. Une exigence d'approbation humaine n'a de sens que si l'opérateur dispose de suffisamment de temps et d'informations pour décider. Pour les actions rapides, l'enveloppe approuvée doit porter une plus grande part de la charge de contrôle. En cas d'échec de communication, le système doit basculer dans un état prédéfini reflétant les besoins physiques et contractuels de l'actif. La sécurité ne signifie pas toujours une production nulle ; elle peut consister à maintenir le dernier point de consigne valide, à suivre une courbe de statisme locale ou à revenir à un contrôleur certifié.

7 Séparer l'agent de la couche de sécurité indépendante

Un même système ne doit pas proposer une action, définir les limites et certifier la conformité. Des contrôles indépendants de sécurité et de risque de marché doivent évaluer l'instruction proposée. Les systèmes de protection, les verrouillages d'équipement et les contrôleurs d'installation certifiés doivent rester indépendants lorsque les pratiques d'ingénierie et la réglementation l'exigent.

Une passerelle d'exécution peut vérifier l'identité, la disponibilité de l'actif, les limites techniques, les autorisations de marché, les limites de crédit et la fraîcheur des données. Elle doit rejeter les instructions mal formées ou obsolètes et consigner le motif. Les mécanismes d'arrêt d'urgence et de retour arrière doivent fonctionner sans dépendre du modèle de langage ni du service de planification de l'agent.

L'indépendance s'applique aussi à la validation. L'équipe de développement peut tester le système, tandis qu'une fonction compétente distincte doit valider les performances du modèle, les modes de défaillance, la sécurité et les facteurs humains. Les modifications importantes apportées aux modèles, prompts, outils, sources de données ou autorisations doivent déclencher une réévaluation proportionnée au risque.

8 Rendre la supervision humaine crédible sur le plan opérationnel

La loi AI de l'Union européenne exige des déployeurs de systèmes à haut risque qu'ils confient la supervision humaine à des personnes compétentes disposant de l'autorité et du soutien nécessaires. Ce principe est utile au-delà de son champ d'application juridique direct. Une personne à qui l'on présente une recommandation complexe quelques secondes avant l'exécution peut exercer une supervision nominale et disposer de peu de contrôle pratique.

Une supervision crédible exige des informations compréhensibles, un délai de réponse adéquat, l'autorité de rejeter, une alternative claire et une protection contre le biais d'automatisation. L'interface doit afficher l'action proposée, l'objectif, les contraintes impératives, les données d'entrée déterminantes, le degré de confiance ou d'incertitude, la conséquence attendue et la raison de l'escalade. Les opérateurs doivent être formés au moyen de scénarios normaux, de tension et de défaillance.

La charge de travail doit être mesurée. Un nombre excessif d'alertes peut rendre la supervision inefficace. De longues périodes d'automatisation correcte peuvent réduire la vigilance des opérateurs. La rotation des équipes, la simulation et l'exploitation manuelle périodique peuvent maintenir les compétences. La direction doit vérifier si un opérateur peut détecter une recommandation erronée plausible, intervenir dans le temps disponible et rétablir un mode de fonctionnement sûr.

9 Gouverner la fraîcheur, la provenance et l'accès aux données

La répartition dépend de données sensibles au facteur temps. La télémétrie, la topologie, les pannes, la météo, les prix, les nominations et les contraintes des actifs peuvent évoluer à des rythmes différents. Chaque entrée devrait avoir un seuil de fraîcheur. L'agent devrait rejeter ou déclasser les actions lorsque des entrées critiques dépassent ce seuil.

Les enregistrements de provenance devraient identifier la source, l'heure de collecte, la transformation, l'indicateur de qualité et la version. Les données externes et les services de modèles devraient être couverts par des niveaux de service, des exigences de sécurité et des dispositifs de continuité. Une panne d'un fournisseur ne devrait pas empêcher l'actif de récupérer son propre historique d'exploitation.

L'accès devrait suivre le principe du moindre privilège. Les accès en lecture, aux recommandations et à l'exécution devraient être séparés. Les identifiants devraient avoir une durée de vie courte lorsque cela est réalisable, être protégés en dehors des prompts et être renouvelés selon des procédures contrôlées. Les appels d'outils devraient être limités aux fonctions et paramètres approuvés. Une interface linguistique ne devrait pas offrir un accès non restreint à la technologie opérationnelle.

10 Valider le système complet, pas seulement le modèle

La précision des composants ne suffit pas. La validation devrait tester le parcours intégré, des données au plan, à la sélection des outils, au contrôle des contraintes, à la décision humaine, à l'exécution et aux preuves. Une prévision exacte peut néanmoins produire une mauvaise recommandation de répartition si les données de prix sont obsolètes ou si l'optimiseur interprète mal un contrat.

Les tests devraient couvrir l'exploitation normale, des conditions de réseau sous tension, des données manquantes, des instructions contradictoires, des entrées malveillantes, une défaillance d'outil, un retard réseau et des prix de marché inhabituels. Le rejeu historique devrait préserver les informations disponibles au moment de la décision d'origine. La simulation et les tests en boucle matérielle peuvent examiner les conséquences physiques avant le contrôle en conditions réelles.

Les systèmes agentiques peuvent produire des chemins de raisonnement variables. La validation devrait se concentrer sur le comportement observable, les autorisations et les résultats. Une suite de tests représentative devrait être conservée et répétée après des modifications substantielles. Le dossier d'approbation devrait indiquer les limitations connues et les conditions dans lesquelles le système doit être désactivé.

11 Maîtriser les évolutions de modèle et de flux de travail

Un agent peut dépendre d'un modèle de fondation, d'un modèle métier, d'une bibliothèque de prompts, d'une source de récupération, d'un optimiseur, d'outils et d'une logique d'orchestration. Chacun de ces éléments peut modifier le comportement. La configuration devrait être versionnée comme une version complète, avec un historique reproductible des dépendances.

Les mises à jour de modèle d'un fournisseur exigent une notification et une évaluation lorsqu'elles affectent un cas d'usage en production. Les mises à niveau automatiques peuvent compromettre la validation antérieure. Les contrats devraient prévoir des contrôles de version, un accès aux tests, une notification d'incident, une remédiation des vulnérabilités et un accompagnement à la transition. L'opérateur devrait conserver le droit de suspendre, de revenir en arrière ou de remplacer un composant.

La surveillance de la dérive devrait couvrir les données, les performances et le comportement. Un modèle peut rester statistiquement exact tandis que les actions qu'il recommande perdent de leur valeur après des changements de marché ou de contrat. Les limites d'exploitation devraient se resserrer lorsque l'incertitude augmente. Une dérive importante devrait déclencher une enquête, un réentraînement ou une revalidation avant que l'autorisation ne soit rétablie.

12 Concevoir le registre de preuves

Chaque recommandation et action importante devrait pouvoir être reconstituée. Le registre de preuves devrait relier l'objectif, la version du système, l'instantané des entrées, les documents récupérés, les appels d'outils, l'action proposée, les résultats des contraintes, la décision humaine, l'instruction exécutée, la réponse de l'actif, le règlement et le statut de l'incident.

Les journaux devraient être à l'épreuve des altérations, synchronisés sur une horloge de référence et conservés conformément aux exigences légales, réglementaires, de marché et contractuelles. Les informations sensibles devraient être protégées. L'accès aux preuves devrait être surveillé, car les journaux peuvent contenir la topologie du système, des identifiants, des données personnelles ou des informations de négociation.

L'explication a ses limites. Un récit fluide généré après un événement peut ne pas refléter le chemin causal. Les preuves devraient donner la priorité aux entrées réelles, aux autorisations, aux appels d'outils et aux instructions exécutées. Une explication concise destinée à l'opérateur peut soutenir la supervision ; elle ne devrait pas remplacer l'enregistrement technique.

13 Attribuer la responsabilité des incidents avant le déploiement

Tableau 2. Matrice illustrative de responsabilité en cas d’incident

Cette matrice est un point de départ élaboré par l'auteur. La répartition finale dépend du droit applicable, des licences, des contrats, des assurances et des faits d'un incident.

La matrice évite les retards lors d'un incident. Elle identifie qui pilote la réponse immédiate tout en préservant la possibilité d'une enquête factuelle et juridique ultérieure. La priorité absolue est une exploitation sûre et conforme. La répartition financière suit les éléments de preuve et les accords applicables.

Les contrats doivent éviter les formulations ambiguës qui transfèrent tout le risque AI à une partie incapable de le maîtriser. Les obligations doivent suivre le contrôle : le propriétaire de l'actif contrôle l'autorité d'exploitation ; le fournisseur contrôle les logiciels et services spécifiés ; le fournisseur de données contrôle la qualité des données contractuellement convenue ; l'intégrateur contrôle les travaux de mise en œuvre convenus. Les causes partagées exigent une coopération, un accès aux preuves et des procédures de résolution des litiges définies.

14 Traiter la responsabilité du fait des produits, la responsabilité professionnelle et la responsabilité opérationnelle

La directive de l'Union européenne relative à la responsabilité du fait des produits inclut expressément les logiciels dans la notion de produit et traite des services associés, des mises à jour et de la capacité de certains systèmes à évoluer après leur mise sur le marché. L'effet juridique dépend de la juridiction, de la mise en œuvre et des faits. Les organisations doivent obtenir des conseils qualifiés pour chaque déploiement.

La responsabilité opérationnelle peut également découler de la réglementation de l’électricité, des codes de réseau, des règles de marché, du contrat, de la négligence, des obligations en matière d’emploi, des obligations de cybersécurité et des services professionnels. Une limitation de responsabilité consentie par un fournisseur ne supprime pas les obligations réglementaires de l’exploitant. Une indemnisation accordée par l’exploitant n’exonère pas un fournisseur de ses obligations légales.

L’architecture contractuelle devrait définir l’usage prévu, l’usage exclu, les mesures de performance, la responsabilité en matière de données, la sécurité, le contrôle des changements, l’audit, la coopération en cas d’incident, les droits de propriété intellectuelle, l’assurance, les indemnités, les plafonds de responsabilité, les pertes indirectes, la résiliation et le support de sortie. Les plafonds devraient refléter les pertes plausibles et la disponibilité de l’assurance. Certaines obligations peuvent nécessiter des plafonds distincts ou des exclusions d’un plafond général.

15 Traiter la cybersécurité comme une condition opérationnelle et de financement

Les systèmes agentiques élargissent la surface d’attaque par les flux de données, les modèles, les plugins, les API et les identifiants d’outils. L’injection de prompt, le contenu récupéré malveillant, les données empoisonnées, les chaînes d’approvisionnement logicielles compromises et les identifiants d’exécution volés peuvent devenir des risques opérationnels. Les recommandations en matière d’infrastructures critiques de la CISA, du NIST, de la NERC et des agences nationales de cybersécurité favorisent le développement sécurisé, les contrôles de la chaîne d’approvisionnement, la segmentation et la réponse aux incidents.

L’architecture devrait isoler les services AI d’entreprise de la technologie opérationnelle. Les chemins de communication devraient être autorisés par liste blanche et surveillés. L’agent ne devrait recevoir que les outils et autorisations minimaux. Les commandes à fort impact devraient exiger une passerelle indépendante, une source authentifiée et une validation du contexte.

Les prêteurs devraient examiner les contrôles cyber, car une attaque réussie peut affecter la disponibilité, les revenus, le coût de remédiation et l’assurance. Le modèle de financement devrait inclure des hypothèses réalistes d’indisponibilité et de restauration. La couverture d’assurance, les exclusions et les exigences de notification d’incident devraient être conciliées avec les accords conclus avec les fournisseurs et les accords de financement.

16 Mesurer les conséquences opérationnelles avant la sophistication du modèle

L’effort de gouvernance devrait être proportionné aux conséquences. Un système qui résume des notes de maintenance peut tolérer une incertitude différente d’un système qui modifie une consigne de répartition. L’organisation devrait noter la sécurité, la fiabilité du système, l’exposition contractuelle, l’exposition de marché, l’impact sur les clients, la réversibilité, la vitesse et la portée géographique.

La réversibilité est importante. Une recommandation peut être examinée ; un ordre de marché exécuté peut être compensé à un coût ; une action de batterie peut être inversée dans les limites physiques ; une action de protection peut se produire avant l’intervention humaine. Le score devrait refléter le temps disponible pour détecter et corriger une erreur.

L’échelle corrélée peut rendre matériel un risque modeste au niveau unitaire. De nombreux agents utilisant des modèles et des signaux similaires peuvent agir ensemble. Les tests de portefeuille devraient examiner les pannes de données communes, les erreurs de modèle partagées, les réponses de trading surpeuplées et le repli simultané. Les gestionnaires de réseau peuvent avoir besoin de visibilité sur le comportement autonome agrégé.

17 Utiliser une courbe de maturité technologique pour l’autorité

Les scores sont des valeurs hypothétiques élaborées par l’auteur sur une échelle de 0 à 100. Ils illustrent la manière dont les preuves et les contrôles devraient se renforcer à mesure que l’autorité augmente.

La courbe illustre un concept de seuil plutôt qu’un score universel. Les systèmes de recommandation nécessitent une validation crédible et une supervision. L’exécution contrainte exige des limites indépendantes, une assurance cyber, un repli et des exercices d’incident. Une action automatique étroite exige des preuves d’ingénierie de niveau sectoriel. Une large autonomie exige des preuves proches de la norme la plus élevée disponible dans chaque dimension.

Les progrès doivent être suspendus lorsqu’une dimension est à la traîne. De solides performances techniques ne peuvent compenser l’absence d’une solution de repli disponible. Une politique exhaustive ne peut compenser une exécution non testée. Le jalon de décision doit évaluer le contrôle critique le plus faible.

18 Construire un dossier économique qui chiffre le coût des contrôles

La répartition agentique peut créer de la valeur grâce à une réponse plus rapide, à la coordination du portefeuille, à un coût de déséquilibre réduit, à une meilleure utilisation du stockage, à une réduction de l’écrêtement, à une meilleure participation aux réserves et à une charge de travail courante réduite. Le dossier doit déduire le coût complet des données, de l’intégration, de la validation, de l’ingénierie des contrôles, de la cybersécurité, des licences, de la formation, de la surveillance, de l’assurance et du repli.

La direction devrait distinguer la trésorerie réalisée, les coûts évités, la valeur de capacité et la valeur d’option. Une amélioration modélisée ne constitue pas de la trésorerie réalisée. Une estimation des gains de temps doit préciser si les effectifs, les heures supplémentaires, la capacité de réponse ou la qualité changent. Les avantages de fiabilité doivent utiliser une méthode de valorisation approuvée et éviter tout double comptage avec les assurances ou les protections contractuelles.

La référence de base doit pouvoir être reconstituée. L’exploitation en mode miroir peut comparer les recommandations aux décisions réelles tout en neutralisant l’effet des informations devenues disponibles ultérieurement. Un test en conditions réelles et contrôlé peut mesurer les résultats dans une enveloppe d’autorisation restreinte. Le dossier commercial doit rendre compte des résultats défavorables et des occasions manquées ainsi que des succès.

19 Illustrer le dossier échelonné de valeur et de contrôle

Les valeurs sont des illustrations élaborées par les auteurs en millions de USD. Elles ne représentent ni un client, ni un actif, ni une prévision de marché, ni une cotation actuelle.

L’étape hypothétique en mode miroir a une valeur nette négative parce que les coûts d’assurance qualité, d’intégration et de surveillance dépassent le bénéfice direct. Ce résultat peut être rationnel lorsque l’étape produit des preuves et évite une autorisation prématurée. L’étape supervisée produit une valeur positive limitée. Une exécution encadrée augmente la valeur après que l’organisation a démontré ses contrôles. L’échelle du portefeuille crée la valeur brute la plus élevée et la provision pour risques la plus importante.

L’approbation des investissements doit utiliser un capital propre à chaque étape. La tranche suivante doit dépendre de preuves : qualité des décisions, intervention de l’opérateur, fiabilité de l’exécution, performance en matière d’incidents, attribution de la trésorerie et achèvement des contrôles. Un programme qui échoue à un jalon de décision doit réduire son périmètre d’autorisation, revoir son flux de travail ou s’arrêter.

20 Relier la gouvernance au financement de projet

Les prêteurs en financement de projet évaluent les risques de construction, de technologie, d’exploitation, de revenus, de contrepartie, de cybersécurité et juridiques. La répartition agentique peut affecter plusieurs de ces risques simultanément. Elle peut améliorer la marge opérationnelle tout en introduisant une dépendance à l’égard des données, des logiciels, de l’infrastructure cloud ou d’un fournisseur spécialisé.

Le dossier de financement doit déterminer si la valeur agentique est nécessaire au service de la dette. Un scénario de base prudent peut considérer les bénéfices précoces comme un potentiel de hausse jusqu’à ce que les preuves soient suffisamment étayées. Si le bénéfice sert au dimensionnement de la dette, les prêteurs peuvent exiger un historique de performances, un examen indépendant, des décotes prudentes, des comptes de réserve, la continuité de service, des droits d’intervention et des dispositifs de remplacement.

Les documents de financement doivent traiter les changements importants des systèmes opérationnels, les incidents cyber, la perte de licences clés, la résiliation de fournisseurs et les violations de conformité. Des accords directs peuvent être pertinents lorsqu’un fournisseur critique ne peut pas être remplacé facilement. Le projet doit conserver des données, une configuration et un support de transition suffisants pour assurer la continuité.

21 Répartir le risque dans les achats

Les achats doivent partir du cas d'usage et de l'architecture de contrôle, plutôt que d'une demande générique portant sur une plateforme AI. La spécification doit préciser l'objectif opérationnel, la classe d'autonomie, les environnements, les interfaces, les indicateurs de performance, les limites d'autorité, les contrôles de sécurité, la journalisation, la cybersécurité, les tests et les exigences de sortie.

L'acceptation doit se faire par étapes. La revue documentaire et de sécurité précède les tests en bac à sable. Le rejeu historique précède l'exploitation en mode miroir. Les preuves issues du mode miroir précèdent l'utilisation supervisée. L'exécution sous contraintes n'intervient qu'après approbation. Chaque étape doit comporter des critères d'entrée et de sortie mesurables.

Les modèles commerciaux peuvent combiner des honoraires fixes, des niveaux de service et des composantes de résultat soigneusement conçues. Les honoraires au résultat exigent une base de référence figée et une protection contre le transfert de risque. Un fournisseur ne doit pas être rémunéré sur les gains bruts de trading alors que le propriétaire d'actifs supporte les pertes, la dégradation et l'exposition au risque de conformité. Le partage des gains doit être fondé sur une valeur nette vérifiée dans les limites convenues.

22 Préserver l'intégrité du marché

Un agent participant aux marchés de l'électricité doit respecter les règles d'offre, de programmation, de communication d'informations, de tenue de registres et de conduite sur le marché. L'organisation doit empêcher toute coordination fondée sur des informations confidentielles, des schémas manipulatoires et des actions incompatibles avec la capacité physique.

La surveillance du marché doit intégrer l'identité de l'agent, la version de la stratégie et les appels d'outils. Les limites doivent couvrir le prix, le volume, la fréquence, l'annulation et la concentration. Les nouvelles stratégies doivent être testées dans des conditions de liquidité sous tension et de prix inhabituels. La conformité doit pouvoir suspendre une stratégie indépendamment du responsable commercial.

Lorsque plusieurs agents interagissent, un comportement émergent peut créer un risque sans instruction explicite de manipulation. La gouvernance doit examiner les résultats collectifs. Les gestionnaires de réseau et les régulateurs peuvent exiger de nouveaux reportings ou tests à mesure que la participation autonome se développe.

23 Prendre en compte les différences réglementaires régionales

Une même architecture peut opérer sous différents régimes juridiques. Le règlement AI de l'UE établit des obligations fondées sur le risque et des exigences de supervision humaine pour certains systèmes à haut risque. Les applications liées aux systèmes électriques nécessitent une classification propre au cas d'usage. La directive sur la responsabilité du fait des produits, les règles de cybersécurité et la réglementation nationale de l'énergie peuvent ajouter des obligations.

Les opérateurs nord-américains doivent prendre en compte les normes de fiabilité approuvées par la FERC, les normes NERC, les règles des marchés régionaux et les exigences des États. Les normes NERC portent sur la planification opérationnelle, la fiabilité en temps réel, la surveillance, la conscience situationnelle et la cybersécurité de la chaîne d'approvisionnement. Un déploiement doit associer chaque fonction aux normes applicables et aux entités responsables.

GCC, le Royaume-Uni, les marchés asiatiques et d'autres marchés ont des exigences distinctes en matière de licences, de codes de réseau, de marché et de données. Les fournisseurs transfrontaliers ne doivent pas supposer qu'un même dossier d'approbation satisfait à toutes les juridictions. Le cadre de contrôle peut rester cohérent tandis que les preuves juridiques et techniques varient selon le lieu.

24 Mettre en place un reporting au conseil d'administration

Le reporting au conseil d'administration doit se concentrer sur les pouvoirs, les conséquences et les preuves. Il doit indiquer quels cas d'usage sont en production, leur classe d'autonomie, les actifs et marchés concernés, les dirigeants responsables, la dernière validation, les changements importants, les dérogations, les incidents, les quasi-incidents, les événements cyber, les tests de repli, la valeur réalisée et les conditions en suspens.

Une exactitude agrégée ne suffit pas. Le reporting doit inclure les performances en conditions de tension et les intervalles à plus forte conséquence. Il doit signaler lorsque l'approbation humaine devient routinière ou anormalement rapide, car cela peut indiquer un biais d'automatisation. Il doit montrer si les opérateurs ont eu recours au dispositif de repli et si celui-ci a fonctionné.

Le conseil d’administration devrait approuver les seuils d’escalade. Un incident grave, une perte de preuves, un contournement des contrôles ou une extension non approuvée des pouvoirs devrait déclencher un examen immédiat. La direction devrait certifier que la configuration en production correspond à la configuration approuvée.

25 Fournir aux prêteurs et aux investisseurs un dossier de due diligence ciblé

Tableau 3. Due diligence des prêteurs et des investisseurs pour le dispatch agentique

Le tableau constitue un cadre de due diligence commerciale et ne remplace pas un conseil juridique, technique, d'assurance ou réglementaire.

Le dossier doit être proportionné au niveau d'autorité. Un outil de conseil de classe 1 peut nécessiter une évaluation concise. Un système d'exécution de classe 3 exige un examen indépendant sur les plans technique, cyber, juridique et commercial. Un système important pour le service de la dette exige un reporting continu et des contrôles des changements.

Les investisseurs doivent se demander si la gouvernance permet de créer de la valeur plutôt que d'ajouter uniquement des coûts. Une autorité claire et des éléments probants permettent à l'actif d'étendre les cas d'usage réussis. Une gouvernance faible peut contraindre un système précieux à rester en phase pilote permanente, car la direction, les prêteurs et les régulateurs ne peuvent pas se fier à ses résultats.

26 Concevoir l'assurance autour des trajectoires de pertes réelles

Les garanties pertinentes peuvent inclure les dommages matériels, les bris de machines, les pertes d'exploitation, les risques cyber, les erreurs et omissions technologiques, la responsabilité civile professionnelle et la responsabilité des dirigeants et administrateurs. Les garanties varient. Les polices peuvent exclure les événements liés aux infrastructures, la technologie opérationnelle, la guerre, les incidents cyber systémiques, les amendes, la responsabilité contractuelle ou les vulnérabilités connues.

L'assuré doit rattacher les scénarios aux polices, aux franchises, aux sous-limites, aux délais de carence et aux exclusions. Les attestations d'assurance des fournisseurs sont insuffisantes sans examen de l'étendue de la garantie et de la base de règlement des sinistres. Les indemnités contractuelles doivent être alignées sur l'assurance disponible tout en préservant le recours pour les obligations importantes.

Les clauses de notification d'incident doivent être coordonnées. Une notification tardive à l'assureur, au régulateur, à l'exploitant du système, au prêteur ou au fournisseur peut porter atteinte aux droits. Le plan de réponse doit attribuer chaque notification et préserver le secret professionnel lorsque cela s'applique.

27 Créer une feuille de route de commercialisation en quatre étapes

La première étape est une exploitation en mode miroir contrôlée. Le système reçoit des données réelles et génère des recommandations sans droits d'exécution. L'organisation teste les données, le comportement, la compréhension par les opérateurs, les éléments probants et les paramètres économiques hypothétiques.

La phase deux est une recommandation supervisée. Des opérateurs nommés peuvent approuver, modifier ou rejeter des actions. Le programme mesure l'intervention, le calendrier, les erreurs et les résultats réalisés. Le système reste dans un périmètre étroit d'actifs et de marchés.

La phase trois est une exécution contrainte. L'agent reçoit des identifiants limités via une passerelle indépendante. Les limites strictes, les alertes, les commandes d'arrêt, le repli et la réponse aux incidents sont éprouvés. L'autorité ne s'étend qu'après validation indépendante et approbation de la gouvernance.

La phase quatre est l'exploitation d'un portefeuille à l'échelle. La mise à l'échelle doit préserver les contraintes au niveau des actifs et les contrôles de risque du portefeuille. Les défaillances de mode commun, les actions corrélées et la concentration des fournisseurs font l'objet de tests supplémentaires. Le conseil d'administration approuve le seuil de mise à l'échelle et l'exposition à l'échelle du système.

28 Appliquer des conditions d'arrêt explicites

Les conditions d'arrêt doivent être définies avant l'utilisation en conditions réelles. Elles peuvent inclure la perte de données critiques, une défaillance de synchronisation temporelle, un accès inattendu aux outils, le dépassement de limites, une fréquence d'action anormale, un échec de validation, une dérive de performance inexpliquée, une alerte cyber, une défaillance du registre de preuves ou l'impossibilité de joindre un superviseur.

La réponse doit être automatique lorsque le délai crée un risque inacceptable. D'autres conditions peuvent nécessiter un jugement humain rapide. L'arrêt doit placer l'actif dans un état opérationnel connu et préserver les preuves. Le redémarrage doit nécessiter une approbation documentée après analyse des causes racines et remédiation.

Les quasi-accidents comptent. Une recommandation dangereuse rejetée ou un usage abusif d'identifiants empêché démontre la performance des contrôles et révèle une faiblesse du système. Le reporting doit récompenser la détection plutôt que supprimer des preuves gênantes.

29 Utiliser la responsabilité comme actif de création de valeur

Une architecture responsable peut accélérer l'adoption commerciale. Les opérateurs comprennent leur autorité. Les fournisseurs comprennent les critères d'acceptation. Les prêteurs peuvent faire la due diligence de la continuité. Les assureurs peuvent évaluer les trajectoires de perte. Les régulateurs peuvent identifier les entités responsables. La direction peut attribuer la valeur réalisée.

Le registre de preuves améliore aussi l'optimisation. Il montre où les recommandations échouent : données, modèle, contrat, opérateur, liquidité de marché, équipement ou exécution. Le capital peut alors cibler la contrainte limitante. L'organisation peut étendre l'autorité lorsque les preuves le justifient et la réduire lorsque les conditions changent.

Cette approche soutient la due diligence transactionnelle. Un acheteur peut évaluer si une allégation opérationnelle rendue possible par AI est transférable, si les licences et les droits sur les données survivent à un changement de contrôle, si le fournisseur peut résilier et si la valeur historique peut être reproduite. Le système de gouvernance fait partie de la qualité opérationnelle et de la valorisation.

30 Rendre visible la réponse en matière de responsabilité

La réponse à la question de savoir qui est responsable doit être disponible avant un incident. L'entité régulée reste responsable de l'exploitation régulée. Le conseil d'administration définit l'appétit pour le risque. Le dirigeant responsable est propriétaire du cas d'usage. Les opérations sont propriétaires du processus décisionnel en conditions réelles. Le propriétaire du modèle maintient le système. L'assurance indépendante le remet en question. Les fournisseurs et fournisseurs de données portent des obligations contractuelles et légales définies. La cybersécurité protège le chemin d'exécution. La finance mesure la valeur et la résilience.

Ces rôles peuvent varier selon l'organisation, mais la responsabilité ne peut pas disparaître dans l'algorithme. Chaque action matérielle doit être reliée à un objectif approuvé, une enveloppe d'autorité, une entité responsable, un rôle nommé et un enregistrement de preuve.

Conclusion

La répartition agentique de la puissance électrique peut améliorer la coordination et la vitesse dans des systèmes électriques de plus en plus complexes. Sa promesse commerciale dépend d'une réponse crédible en matière de responsabilité. Cette réponse est une architecture opérationnelle, et non un avertissement.

Le cadre de responsabilité de la répartition relie le mandat du conseil d’administration, la propriété des cas d’usage, l’autorité encadrée, l’assurance des modèles et des données, la supervision humaine, les garde-fous indépendants, ainsi que l’affectation des preuves et des incidents. L’autonomie doit augmenter par étapes à mesure que l’assurance, la résilience et la valeur réalisée gagnent en maturité. Le coût total du contrôle doit être intégré au dossier d’investissement. Le financement doit rester susceptible d’être honoré en cas de défaillance d’un agent ou d’un fournisseur.

Les organisations les mieux préparées à utiliser la répartition agentique sauront exactement quelles décisions le système peut prendre, qui peut l’arrêter, comment chaque action est reconstituée, qui supporte chaque perte et comment l’activité se poursuit en cas de défaillance technologique. Cette discipline crée les fondations d’une montée à l’échelle sécurisée, de la confiance des autorités de régulation et d’une valeur finançable.

Références

1. National Institute of Standards and Technology, Cadre de gestion des risques liés à l’intelligence artificielle (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. National Institute of Standards and Technology, AI Guide pratique du RMF. https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook
3. National Institute of Standards and Technology, Centre de ressources NIST AI. https://airc.nist.gov/
4. National Institute of Standards and Technology, Cadre de cybersécurité 2.0, 2024. https://www.nist.gov/cyberframework
5. Département de l’Énergie des États-Unis, AI pour l’énergie. https://www.energy.gov/cet/articles/ai-energy
6. Bureau de la cybersécurité, de la sécurité énergétique et des interventions d’urgence du Département de l’Énergie des États-Unis, Stormbreaker : banc d’essai AI pour les infrastructures critiques, 2026. https://www.energy.gov/ceser/stormbreaker
7. Département de l’Énergie des États-Unis, Initiative de modernisation du réseau et inventaire des bancs d’essai du réseau. https://www.energy.gov/gdo/grid-modernization-initiative
8. Agence internationale de l’énergie, Moderniser les réseaux à l’ère de l’électricité, 2026. https://www.iea.org/reports/modernising-grids-in-the-age-of-electricity
9. Agence internationale de l’énergie, Énergie et AI, 2025. https://www.iea.org/reports/energy-and-ai
10. Agence internationale pour les énergies renouvelables, Numérisation et AI pour la transformation du système électrique : perspectives pour le G7, 2025. https://www.irena.org/Publications/2025/Oct/Digitalisation-and-AI-for-power-system-transformation-Perspectives-for-the-G7
11. Commission européenne, Numérisation du système énergétique. https://energy.ec.europa.eu/topics/eus-energy-system/digitalisation-energy-system_en
12. Commission européenne, Loi sur l'AI. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
13. Union européenne, Règlement (UE) 2024/1689 établissant des règles harmonisées sur l'intelligence artificielle. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
14. Union européenne, Directive (UE) 2024/2853 sur la responsabilité du fait des produits défectueux. https://eur-lex.europa.eu/eli/dir/2024/2853/oj
15. Réseau européen des gestionnaires de réseau de transport d'électricité, Vision 2050. https://www.entsoe.eu/publications/system-development-reports/vision-2050/
16. Réseau européen des gestionnaires de réseau de transport d'électricité, Réponse à la consultation de la Commission européenne sur l'AI dans le domaine de l'énergie, 2025. https://www.entsoe.eu/
17. Office des marchés du gaz et de l'électricité, Utilisation éthique de l'AI dans le secteur de l'énergie, mis à jour en 2026. https://www.ofgem.gov.uk/publications/ethical-ai-use-energy-sector
18. Office des marchés du gaz et de l'électricité, Assurance de l'AI dans le secteur de l'énergie, 2026. https://www.ofgem.gov.uk/
19. Organisation internationale de normalisation, ISO/IEC 42001 : Systèmes de management de l'intelligence artificielle. https://www.iso.org/standard/81230.html
20. Organisation internationale de normalisation, ISO 31000 Management du risque. https://www.iso.org/iso-31000-risk-management.html
21. North American Electric Reliability Corporation, Normes de fiabilité. https://www.nerc.com/pa/Stand/Pages/Default.aspx
22. North American Electric Reliability Corporation, TOP-001 Exploitation du transport. https://www.nerc.com/pa/Stand/Reliability%20Standards/TOP-001-6.pdf
23. North American Electric Reliability Corporation, TOP-010 Capacités de surveillance et d'analyse de la fiabilité en temps réel. https://www.nerc.com/pa/Stand/Reliability%20Standards/TOP-010-1(i).pdf
24. North American Electric Reliability Corporation, CIP-013 Gestion des risques liés à la chaîne d'approvisionnement. https://www.nerc.com/pa/Stand/Reliability%20Standards/CIP-013-2.pdf
25. North American Electric Reliability Corporation, Ligne directrice de fiabilité : conscience situationnelle pour l'opérateur du système. https://www.nerc.com/
26. Commission fédérale de régulation de l'énergie, Conférence technique sur l'amélioration de l'efficacité des marchés et de la planification grâce à des logiciels améliorés. https://www.ferc.gov/
27. California Independent System Operator, Guide du système de répartition automatisée. https://www.caiso.com/
28. California Independent System Operator, Répartition exceptionnelle. https://www.caiso.com/market-operations/products-services/exceptional-dispatch
29. Agence de la cybersécurité et de la sécurité des infrastructures, Sécurité dès la conception. https://www.cisa.gov/securebydesign
30. Agence de la cybersécurité et de la sécurité des infrastructures, Systèmes de contrôle industriels. https://www.cisa.gov/topics/industrial-control-systems
31. Agence de cybersécurité et de sécurité des infrastructures, Centre national de cybersécurité et partenaires internationaux, Lignes directrices pour le développement sécurisé de systèmes AI, 2023. https://www.cisa.gov/resources-tools/resources/guidelines-secure-ai-system-development
32. Centre national de cybersécurité, Lignes directrices pour le développement sécurisé de systèmes AI. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
33. Banque mondiale, Bancabilité du projet : allocation des risques et impact sur les prix des PPA, 2023. https://documents1.worldbank.org/curated/en/099120623171525006/pdf/P1742021cf52b60e6196b81854984124388.pdf
34. Banque mondiale, Rendre les projets greenfield bancables, 2021. https://blogs.worldbank.org/en/ppps/making-greenfield-projects-bankable
35. Société financière internationale, Centrales solaires photovoltaïques de grande envergure : guide du développeur de projet. https://www.ifc.org/en/insights-reports/2015/utility-scale-solar-photovoltaic-power-plants
36. Organisation de coopération et de développement économiques, Principes AI de l'OCDE. https://oecd.ai/en/ai-principles
37. Institut des ingénieurs électriciens et électroniciens, Processus 7000-2021 Model de l'IEEE pour traiter les préoccupations éthiques lors de la conception de systèmes. https://standards.ieee.org/ieee/7000/6781/
38. Comité de Bâle sur le contrôle bancaire, Principes pour la résilience opérationnelle, 2021. https://www.bis.org/bcbs/publ/d516.htm

À propos de l'auteur

Chennakeshav (CK) est un dirigeant de la finance d’entreprise et de la banque d’investissement, fort de plus de 25 ans d’expérience internationale dans l’origination, la structuration et l’exécution de transactions couvrant M&A, le capital de croissance et la stratégie d’entreprise. Il a dirigé des mandats de création de valeur pour des fondateurs, des entreprises et des fonds — faisant le lien entre la vision du conseil d’administration et une exécution opérationnelle jusqu’à la clôture.

Sa carrière s’étend à Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, aux sociétés du portefeuille d’ADQ et à Emirates Growth Fund, dans les secteurs des TMT, de l’immobilier, de la fintech, de la deeptech, des technologies propres, des infrastructures et de l’énergie. Il a collaboré avec des dirigeants de la C-suite, des fonds de capital-investissement et de capital-risque, des fonds souverains et des family offices pour financer des levées de fonds complexes et des entreprises en phase de scale-up, et a dirigé des initiatives de due diligence M&A, d’intégration post-fusion et de transformation des activités afin de créer de la valeur.

Chez Matchpoint Partners, il est associé gérant et dirige la pratique de financement d’entreprise, M&A et de levée de capitaux du cabinet. Il est titulaire d’un MBA de London Business School, d’un diplôme d’ingénieur de VTU et d’un Master of Laws (LLM, en cours) de UCL London.

Mentor actif auprès de start-up, CK intervient comme mentor auprès de Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute et IN5, occupe le rôle d’Entrepreneur Mentor in Residence (EMiR) à London Business School et est membre du jury de l’Entrepreneurship World Cup.