RTE

Du producteur au distributeur

• Stockage en grande quantité impossible
• Equilibre offre/demande
• Accès fiable, économique, propre et équitable

1

RTE en chiffres

105 000 km de lignes

2 710 postes

50 lignes transfrontalières

Investissement 2016 :

1 500 M €

9 000 salariés

CA 2016 :

4 400 M €

501 clients

Les clients

Structure de la DSIT

2

Le Département Programme Outils Industriels

(DPOI)

• Applications liées au patrimoine de RTE
• Développement externalisé à des Entreprises de Services du Numérique (ESN)

3

L'équipe PARIS

(PAtrimoine pRocess Industriel poSte)

• Description du patrimoine Postes, Télécommunications et activités de la Maintenance
• Mode projet pour une nouvelle application ou une refonte
• Mode Maintien en Condition Opérationnelle (MCO) pour l'évolution d'une application déjà en production

4

Structure de RTE

La maintenance du patrimoine

Maintenance

Patrimoine de RTE

• Curative

• Préventive

• Evolutive

5

La France de la maintenance

7 Centres Maintenance

75 Groupements de Postes

30 Groupes de Maintenance Réseau

6

• Réseau télécom indépendant des opérateurs
• Télécommande du réseau électrique
• Maintenance par des équipes spécialisées

La maintenance télécom

7

La maintenance télécom

Incident niveau 1&2

Incident niveau 3

Décision de réparation

Aistel, 5 ans de vie

• Gestion informatisée des incidents
• Progiciel BMC Remedy V8
• Démarche Télécommunications-Téléconduite (2009)

8

Limites d'Aistel

9

Limites d'Aistel

Mise en place de MyIT, surcouche ergonomique

10

• Communication avec d'autres applications :  Infotel, InfoPoste

Échanges entre Aistel et son environnement

11

Application Programming Interface : ensemble organisé et normalisé de classes/méthodes/fonctions

Demain, les API

12

Échanges entre Aistel et son environnement

Pas de réplication des données

Développement indépendant

Tolérance au changement

REST & SOAP

• Besoin de modernisation des échanges Aistel - InfoPoste

Demain, les API

13

Échanges entre Aistel et son environnement

Développer le principe d'OpenData

Enjeux et objectifs du projet

14

Promouvoir la démarche API

Acquérir un

retour d’expérience

Objectif principal : Automatiser le processus d'échanges

Objectif secondaire : Disposer des équipements dans AISTEL

Contraintes et risques

Contraintes temporelles

• Jalon de feuille de route DPOI : étude fin novembre 2017
• Faisabilité vérifiée = jalon de mise en place 

16

Contraintes et risques

Contraintes financières

Hors Main d'Oeuvre

17

Plusieurs 100 K€

Main d'Oeuvre RTE

Contraintes et risques

Contraintes financières

MO

1 ETP

18

0,2 

Equivalent Temps Plein

Contraintes et risques

Contraintes financières

HMO

• Experts progiciels (BMC et SAP) déjà présents
• Coût déterminé par un chiffrage sur base des EdB

19

Aistel

InfoPoste

Contraintes et risques

Contraintes techniques

• Respect des règles du SI de RTE
• Architecture REST : sujet nouveau pour la DSIT
• REST entre progiciels

20

• Pas d'impact sur les fonctionnalités disponibles
• Pas d'altération des échanges avec les autres applications

Contraintes et risques

Contraintes techniques du POC

• Aucun déploiement en production
• Négociations des technologies utilisées :

21

Justifiées par mon expérience pour un développement rapide

Contraintes et risques

Risques

Standard REST impossible

Budget insuffisant

API non standardisée

22

Règles du SI de RTE

• Serveur
  • OS RedHat Enterprise Linux 7 ou 7.2
  • Apache 2.4
  • Serveur applicatif Tomcat 8.0.2
  • JRE 1.7u76, 1.8u74 ou supérieur
  • Base de données Oracle 12c avec encodage UTF-8 et technologie Exadata

Etude de l'architecture

25

Flux entre InfoPoste et SIDONI

26

Extraction de SIDONI 

 & Conversion d'Excel à CSV

27

Rapport spécifique Excel

• Données vides, renommage de colonnes et modification de l'ordre des colonnes
• Entre 30 minutes et 1 heure
• Entorse aux bonnes pratiques d'un SI

Conversion manuelle Excel à CSV

Ajout de colonnes

Etude des données CSV

28

Anomalie présente depuis bientôt 2 ans

Ecart de 6 000 éléments (16%)

Import dans AISTEL

Réservée aux administrateurs

0,5s/ligne

Etude de l'API existante

29

• Élaboration d'un ensemble d'appels à l'API
• Analyse des écarts : méthode actuelle / utilisation de l'API
• Identification de données manquantes ou sous un format non utilisable tel quel

Etude des interactions Aistel/MyIT

30

• Objectif : utiliser l'API
• Etude de la possibilité d'intégrer les appels dans MyIT
• Impossibilité d'ajouter du code appelant l'API

MyIT

Aistel

Prise de décision

31

Intégrer les équipements au sein d'Aistel

Remplacer l'existant en appelant l'API InfoPoste au sein d'Aistel

Un chemin semé d'embûches

33

Impossibilité d'appeler depuis MyIT

• Délégation des actions dans MyIT au coeur d'Aistel
• Décision de mise en place des appels au sein d'Aistel

MyIT

Aistel

Un chemin semé d'embûches

34

Faisabilité d'un appel à l'API

• BMC Remedy version 8 ne permet des appels qu'aux API de type SOAP

Un chemin semé d'embûches

35

Développement du proxy

• Développement par un prestataire envisagé mais trop contraignant (temps & coût)
• Développement à réinternaliser
• Aucune ressource désignée
• Envisagé de m'y faire participer

Un chemin semé d'embûches

36

Stockage des armoires télécoms

• Idée de base : ne plus stocker les armoires télécoms dans Aistel
• Problème : BMC Remedy est un logiciel ITSM
• Besoin de stockage des éléments dans sa base de données
• Impossibilité de supprimer les armoires présentes

Un chemin semé d'embûches

37

Mise à jour des armoires

• Idée de base : mettre à jour les armoires grâce à des appels d'API
• Problème : Impossibilité de mise à jour dynamique de la BDD
• Mise à jour périodique via un programme au sein d'Aistel
  • Appel : "Donnes moi toutes les armoires ayant évolué depuis les dernières 24 heures"

La preuve par les faits

38

Objectifs du POC

Déclarer une anomalie sur une armoire et sur équipement de cette armoire

Déclarer une anomalie avec une interface développée indépendamment d'un éditeur

Démontrer la valeur ajoutée des données des équipements

La preuve par les faits

39

Intérêts du POC

• Démontrer la faisabilité technique des appels d'API IP
• Déceler des problématiques techniques (codification de données)
• Acquérir de l'expérience (REST, Docker)
• Démonstration au métier et déblocage de budget 

La preuve par les faits

40

Technologies utilisées

• PHP 7.0 & Symfony 3.4
• HTML5, CSS3, JavaScript
• Nginx
• Base de données MySQL
• Docker en tant que système de virtualisation

La preuve par les faits

41

Architecture Docker

La preuve par les faits

42

Méthodologie de gestion de projet

La preuve par les faits

43

Exemple d'internalisation

Pas de vocation à aller en production

Aucun processus prévu

Succès du POC

Tendance de fond

La preuve par les faits

Technologies utilisées

• PHP 7.0/Symfony 3.4 côté serveur
• HTML5/CSS3/JS avec JQuery et UI Kit côté client
• YML pour les fichiers de configuration
• Twig pour le templating
• Nginx en tant que gestionnaire des requêtes web (HTTP)
• Base de données MySQL & ORM Doctrine
• Docker en tant que système de conteneurisation

La preuve par les faits

45

Contraintes d'un environnement de grande entreprise

• Processus = maîtrise de l'entreprise
• Frein aux idées hors du cadre
• La DSIT est une entité moins souple que d'autres

La preuve par les faits

46

Contraintes d'un environnement de grande entreprise

Besoin d'un ordinateur avec droit d'administrateur

Sept

Nov

Déc

Oct

Jan

Fev

Mars

Avr

Mai

Juin

Initial

Réel

2017

2018

Bilan de 3 ans à Paris

• Gestion d'un projet en environnement complexe
• Création d'API
• Acquisition de connaissances métier
• Réponse au besoin

Relations humaines

47