01 / Contexte et contrainte métier
Des contrôles à fort enjeu financier, pilotés sans vue d'ensemble
Le service Politique Industrielle oriente les contrôleurs vers les chantiers des entreprises prestataires, et le résultat de ces contrôles pèse sur les futurs contrats négociés avec Enedis. Les informations nécessaires sont réparties dans quatre systèmes indépendants : Racing pour les contrôles, e-Plan pour la planification des chantiers, e-Presta pour le référentiel prestataires, PGI pour les contrats et marchés. La contrainte : produire un outil exploitable au quotidien par les évaluateurs, sans budget de développement applicatif dédié, à partir des briques déjà présentes dans le SI.
02 / Le problème, du point de vue de l'utilisateur
« Je croise Power BI et plusieurs SI à la main, et je choisis à l'aveugle »
Avant l'outil, l'évaluateur qui devait décider quel chantier contrôler croisait manuellement un rapport Power BI et plusieurs applications métier, sans carte ni vue consolidée. Conséquence directe : certains prestataires étaient beaucoup plus contrôlés que d'autres, et certains chantiers n'étaient jamais contrôlés. Une fois l'application en place, un second problème est apparu : l'alimentation reposait sur des exports manuels réalisés chaque semaine, avec une dépendance à un collègue habilité. L'évaluateur avait besoin de données fraîches chaque jour, il travaillait sur des données de la semaine précédente.
03 / Architecture retenue
Une vue Denodo remplace quatre exports, FME Server remplace l'intervention humaine
Les workspaces FME sont versionnés sur le GitLab interne d'Enedis, ce qui trace chaque évolution du traitement et permet de revenir à une version antérieure. FME Server, renommé FME Flow par Safe Software, porte la planification quotidienne, les notifications par mail et les alertes en cas d'échec.
La restitution reste inchangée : une application ArcGIS Experience Builder à quatre vues synchronisées, carte du statut des chantiers, filtres par département, prestataire et statut de contrôle, diagramme des contrôles par contrat, table éditable qui agrège les quatre sources et les indicateurs calculés.
04 / Choix techniques et alternatives écartées
Quatre décisions qui structurent l'outil
Virtualiser avec Denodo plutôt que multiplier les connexions
Une vue unique agrège Racing, e-Plan, e-Presta et PGI. FME l'interroge en tant que reader, sans export ni copie de fichiers.
Écarté : maintenir les exports manuels (dépendance humaine, cadence hebdomadaire) et développer quatre connecteurs directs (quatre habilitations, quatre points de rupture).Exclure les enregistrements défectueux plutôt que les corriger
Les chantiers sans numéro de contrat, sans GPS exploitable ou sans numéro de chantier sont mis de côté et analysés à part pour remonter les causes racines.
Écarté : imputer les valeurs manquantes, ce qui aurait bruité les indicateurs et masqué un vrai problème de saisie en amont.Compter aussi les chantiers jamais contrôlés
L'absence d'identifiant de contrôle est l'information la plus utile au pilotage : elle pointe les contrats et les zones à traiter en priorité.
Écarté : ne compter que les chantiers contrôlés, ce qui rend les trous de couverture invisibles et biaise l'analyse.Trois niveaux d'agrégation, une seule source
Prestataire, contrat, chantier : trois questions de management différentes, servies par les mêmes indicateurs (ListBuilder, ListHistogrammer, ListElementCounter), avec la distinction niveau 1 seul et niveaux 1 et 2.
Écarté : un rapport Power BI, qui répondait au comptage mais pas à la dimension spatiale. C'est précisément cette dimension qui a fait repérer l'outil au national.05 / Une difficulté réelle et sa résolution
Le verrou de l'alimentation, levé par une veille outillée
L'application fonctionnait, mais son alimentation par exports manuels bloquait le passage à l'échelle : impossible de proposer un déploiement national avec une dépendance humaine hebdomadaire. La solution n'était documentée nulle part en interne. Je l'ai construite par une veille en cinq temps : un échange avec un collègue data analyste qui agrégeait déjà des sources pour ses rapports, une recherche ciblée sur la connexion FME et Denodo, la documentation de Safe Software sur le connecteur reader, des retours de pairs sur la communauté FME et Reddit, puis un test réel avec l'accès d'un collègue habilité. Ce test a fourni la preuve concrète que la vue Denodo se lit directement depuis FME. La recommandation a ensuite été structurée en trois phases : sécuriser les habilitations et créer la vue, automatiser via FME Server, nationaliser.
06 / Résultat mesuré
Un outil régional devenu candidat au déploiement national
L'outil est utilisé en production dans la DR, repéré au national pour sa dimension spatiale, intégré à la Ruche, la plateforme des innovations Enedis, et un atelier de nationalisation est engagé avec le référent contrôles national. La vue Denodo et le workspace sont documentés pour être réutilisables par les autres DR.
07 / Ce que je ferais différemment aujourd'hui
Je poserais la question de l'alimentation dès la conception, au lieu de la traiter une fois l'outil en production : partir directement sur la vue Denodo aurait évité de construire puis de démonter le circuit d'exports manuels.
08 / Démo et code
L'application traite des données contractuelles internes à Enedis : pas de démo publique ni de code publiable. La vidéo du workspace FME en section 03 et la capture de l'application en section 06 masquent les informations de connexion, les noms de tables et toute autre donnée sensible.