Étude de cas / Enedis

Diagnostic HTA : donner une lecture territoriale aux incidents du réseau 20 kV

Client Enedis, Maîtrise d'Ouvrage de Décision (MOAD) Rôle Modélisation et réalisation de l'ETL, restitution cartographique Période 2025, intégré à la plateforme PVR

01 / Contexte et contrainte métier

Des incidents tabulaires, sans lecture géographique

Le programme Rénovation Programmée pilote les investissements de modernisation du réseau HTA 20 kV. Pour arbitrer entre les départs à rénover, la MOAD a besoin de savoir où le réseau tombe en panne, à quelle fréquence et pourquoi. Or les incidents remontés par les organes de manœuvre existaient sous forme tabulaire, incident par incident, sans lecture géographique ni agrégation par portion de réseau.

02 / Le problème, du point de vue de l'utilisateur

« Je vois qu'un départ cumule les incidents, mais pas s'investir dessus changera quelque chose »

Sans lecture territoriale, deux questions restaient sans réponse objectivée : quels départs concentrent les incidents récurrents, et lesquels de ces incidents relèvent de causes sur lesquelles un investissement agit réellement. Un départ frappé par un aléa climatique exceptionnel et un départ dégradé chaque année par la végétation n'appellent pas la même décision, mais le tableau brut ne les distinguait pas.

03 / Architecture retenue

Deux mailles d'analyse, une classification des causes, une seule chaîne

J'ai structuré le diagnostic autour de deux mailles d'analyse complémentaires. La maille départ HTA répond à la question du pilotage : quel départ prioriser dans le programme. La maille tronçon répond à la question opérationnelle : quelle section précise traiter, et comment. Une seule chaîne de traitement alimente les deux niveaux, ce qui garantit leur cohérence.

Diagnostic HTA, spatialisation des incidents Réseau 20 kV, programme Rénovation Programmée Incidents réseauorganes de manœuvre ETL FME spatialisation classification des causes agrégation deux mailles Maille départpriorisation programme Maille tronçonsections à traiter PVRPartage Vision Réseaux Sortie : diagnostic territorial à deux mailles, intégré à la plateforme existante
Une chaîne unique alimente les deux mailles d'analyse, restituées dans la plateforme PVR.

La classification des causes constitue le second axe. J'ai séparé les incidents d'origine climatique des incidents non climatiques, puis isolé au sein de ces derniers les causes récurrentes liées à la végétation. Ce sont ces sections, où la végétation provoque des incidents répétés sur du réseau aérien, qui deviennent candidates à l'enfouissement : l'investissement y supprime la cause plutôt que d'en réparer les effets.

L'ETL rattache chaque incident à sa position sur le réseau à partir des organes de manœuvre concernés, applique la classification climatique et non climatique, puis agrège les résultats aux deux mailles. La restitution s'intègre à PVR, Partage Vision Réseaux, la plateforme cartographique existante de la Direction Régionale. Ce choix évite de créer une application de plus : les utilisateurs retrouvent le diagnostic dans l'outil qu'ils consultent déjà, en regard des autres couches réseau.

04 / Choix techniques et alternatives écartées

Trois décisions qui orientent le diagnostic vers la décision

Deux mailles, une seule source

Produire les deux niveaux d'agrégation depuis la même chaîne évite les diagnostics divergents. Quand la MOAD priorise un départ et que l'exploitation cherche la section à traiter, les deux raisonnent sur les mêmes chiffres.

Écarté : deux chaînes séparées par maille, au risque de produire des chiffres divergents entre pilotage et exploitation.

La cause avant la fréquence

Un simple comptage d'incidents aurait mis en tête des départs frappés par des aléas exceptionnels, sur lesquels l'enfouissement n'a pas d'effet préventif rentable. Classer les causes d'abord, compter ensuite, oriente l'investissement vers les sections où il supprime réellement le problème.

Écarté : un classement par simple fréquence d'incidents, qui aurait priorisé des départs où l'enfouissement n'apporte rien.

S'intégrer plutôt que créer

Livrer le diagnostic dans PVR plutôt que dans une application dédiée a réduit le coût d'adoption à zéro et inscrit le travail dans un patrimoine applicatif maintenu.

Écarté : une application cartographique dédiée, qui aurait ajouté un outil de plus à apprendre pour les utilisateurs.

05 / Résultat mesuré

Un diagnostic en appui direct des arbitrages d'investissement

2 mailles
départ et tronçon, produites par une seule chaîne pour rester cohérentes entre pilotage et exploitation
Intégré à PVR
consulté en regard des autres couches d'exploitation du réseau, sans nouvelle application
Causes classées
climatique contre non climatique, sections à végétation récurrente identifiées pour l'enfouissement

Des sections candidates à l'enfouissement sont identifiées sur le critère des incidents végétation récurrents, en appui direct des arbitrages du programme Rénovation Programmée.

06 / Ce que j'en retiens

Ce projet m'a appris à modéliser pour la décision et non pour la donnée. La question structurante n'était pas comment spatialiser des incidents mais quelle décision chaque maille devait éclairer. C'est ce cadrage qui a dicté la classification des causes, le choix des deux niveaux d'agrégation et l'intégration dans PVR.

07 / Démo et code

L'application traite des données d'exploitation réseau internes à Enedis : pas de démo publique ni de code publiable. Le schéma d'architecture en section 03 est une représentation que j'ai redessinée moi-même, sans capture de l'interface réelle.

← Étude précédente : OptiControl-PGOC Étude suivante : Éclairage public →