Le Big Data touche le paroxysme de sa médiatisation. Tout est devenu Big Data, mélangeant nouvelles approches métiers, technologies et business models. De vraies opportunités se présentent toutefois. Ainsi, la capacité à suivre en temps réel les indicateurs clés du business à partir d’un nombre croissant de sources de données est un challenge que le « Big Data » peut relever. Découvrez, au travers d'un retour d'expérience commun EDF R&D/OCTO Technology, comment Storm peut vous permettre de relever ce défi. Compte-rendu du petit-déjeuner : http://bit.ly/1dpbNgF

1. Calculez vos indicateurs en temps réel
En partenariat avec EDF R&D
1
© OCTO 2013

2. OCTO et le Big Data
Une offre cohérente entre technologie et analyse prédictive
DIRECTION SI
CONSEIL EN SI BIG DATA
 Etude et positionnement des solutions
en fonction de votre contexte
 Transformation de SI Décisionnel vers le
Big Data
 Cadrage de projets Big Data
ARCHITECTURE DES SYSTÈMES BIG DATA
 POC sur Hadoop et NoSQL
 Conception et réalisation de systèmes
sous Hadoop et NoSQL
 Formation Hadoop
2
© OCTO 2013
DIRECTION MÉTIER
CONSEIL EN ANALYSE DE DONNÉES AVANCÉES
 Benchmarks de projets Big Data par
secteur
 Formation des équipes de datamining
aux techniques Big Data
 Accompagnent des projets pilote
métiers
COLLECTE DE DONNÉES EXTERNES
 Identification de sources de données
 Collecte et traitements de données non
structurées
 Recherche de corrélations économiques

3. L’équipe OCTO Big Data Analytics
Une équipe dédiée, composée de
Experts et architectes sur les clusters de stockage et de calcul
Statisticiens et consultants en machine learning
Une R&D spécifique sur Hadoop, NoSQL et le machine learning
Des relations très approfondies avec les équipes R&D de nos
partenaires
Hortonworks
MapR
Cloudera
10Gen Mongodb
Datastax Cassandra
3
© OCTO 2013

4. Intervenants
Julien CABOT
Directeur Big Data Analytics
OCTO
jcabot@octo.com
Marie-Luce PICARD
Chef de projet
EDF R&D
marie-luce.picard@edf.fr
Benoît Grossin
Ingénieur Chercheur
EDF R&D
benoit.grossin@edf.fr
4
© OCTO 2013
Rémy SAISSY
Architecte
OCTO
rsaissy@octo.com

5. Agenda
Etat des lieux du Big Data
Les enjeux du Big Data chez EDF par EDF R&D
Questions/réponses
Retour d’expérience sur une expérimentation d’analyse
d’indicateurs en temps réel avec Storm chez EDF R&D
Questions/réponses
Bilan
5
© OCTO 2013

6. Etat des lieux du Big Data
6
© OCTO 2013

7. Big Data, une écosystème multiple
WEB
Google, Amazon,
Facebook, Twitter,
…
Management
McKinsey, BC
G, Deloitte, …
Logiciel IT
IBM, Teradata,
Vmware, EMC,
…
Un concept devenant une réalité pour les entreprises
françaises
7
© OCTO 2013

8. Projets Big Data en 2013-2014
Le Data mining sur signaux forts et faibles
Données exogènes
Données issues des infrastructures de production
Le dépassement du « mur capacitaire » des
appliances décisionnelles
Stocker plus pour un coût significativement inférieur
Banalisation des technologies de calculs
8
© OCTO 2013

9. Big Data, un univers technologique pour construire
des systèmes à haute performance
Au-delà de 10 To en ligne, les
architectures « classiques »
nécessitent des adaptations
logiques et matérielles très
importantes.
Application
orientée Flux
évènementiel
Event Stream
Processing
Au-delà de 1 000
évènements/seconde, les
architectures « classiques »
nécessitent des adaptations
logiques et matérielles très
importantes.
9
© OCTO 2013
Application orientée Au-delà de 1 000
transactions/seconde, les
Stockage
architectures « classiques » des
Stockage
adaptations logiques et
distribué
matérielles très importantes
Share
nothing
Univers
« standard »
SGBDR,
Serveur d’application,
ETL, ESB
Programmation
parallèle
Application
orientée Calculs
XTP
Application orientée
Transaction
Au-delà de 10 threads/Core
CPU, la programmation
séquentielle classique atteint
ses limites (IO).

10. Types de solutions
Application orientée
Stockage
Parrallel database
Stream Processing
Base de données
Application
orientée Flux
évènementiel
Application orientée
Transaction
NoSQL
NewSQL
Hadoop
Application orientée
Calculs
10
© OCTO 2013
Grid Computing
GPU

11. Une limite commune aux
systèmes informatique!
La racine commune à toutes ces limites est le
« throughput » des I/O
11
© OCTO 2013

12. Le problème : le gain en débit des
disques est très en retard par
rapport à leur capacité
70
Seagate
Barracuda
7200.10
64 MB/s
60
Gain : x100 000
Débit (MB/s)
50
40
Gain : < x100
seulement !
Seagate
Barracuda
ATA IV
30
Gain : x91
20
IBM DTTA
35010
10
0,7 MB/s
0
1991
1990
12
© OCTO 2013
1996
1998
2001
2006

13. Stratégies pour dépasser les
limites du troughput
Architecture InMemory
Architecture en grille
• Réduire la latence en utilisant
des supports plus rapide
(DRAM, SSD)
• Paralléliser les accès IO en
divisant les volumes (sharding)
• Bénéficier de l’évolution des
capacités des composants
• La limite structurelle n’est pas
que déplacée
• Pour évoluer, l’architecture doit
devenir une grille InMemory
• Bénéficier du différentiel de
coût entre commodity
hardware et haut de gamme
• Le réseau de la grille devient
un composant
principal, nécessitant colocalisation des données et
des traitements
• Permet de scaler à l’infini, c’est
le Warehouse scale
computing!
13
© OCTO 2013

14. Familles de solutions d’analyse en
streaming
Complex Event
Processing
•
•
•
•
Solution dédiée au stream
processing
Pas de capacité de
stockage
Architecture orientée
serveur
Options de streaming
Streaming Grid
In Memory
•
•
•
•
Base de données In Memory
Event triggers
Partitionnement
Le temps comme une
dimension d’analyse
HANA
•
•
•
•
Grille de traitement In memory
Event triggers, pub/sub
Share nothing sharding
Le Temps comme une partie de la
clef
STORM
STREAMS
14
© OCTO 2013

15. LES ENJEUX DU BIG DATA À
EDF, LE POINT DE VUE
D’EDF R&D

16. SMART GRIDS SMART METERS  SMART DATA
Partout dans le monde des projets smart-grids voient le jour, motivés par des contraintes
économiques ou régulatoires, ou encore par des besoins environnementaux. Avec le développement
de nouveaux usages comme le véhicule électrique, avec l’augmentation des moyens de production
décentralisée, de nouvelles perspectives apparaissent pour la gestion de l’énergie. Un très grand
nombre de compteurs communicants, et plus généralement de capteurs vont être déployés: ils vont
| 16
provoquer un déluge de données auquel les compagnies énergétiques vont devoir faire face.
•

17. SMART METERING: UN DELUGE DE DONNEES
En France : 35+ millions de
compteurs intelligents  des
milliards d’enregistrements
Actuellement, un projet pilote a
déployé 300K compteurs
•
•
| 17

18. DONNÉES MASSIVES DANS
LE DOMAINE DE L’ ÉNERGIE
 Enjeux, challenges:
 Plus de complexité dans le système électrique (production décentralisée, gestion de la
demande ….)
 Multiplication des acteurs
 Push technologique (compteurs communicants, internet des objets ….)
 Nécessité d’une bonne traçabilité des actions
 Le management des données et les nouvelles technologies vont être au cœur des
métiers d’EDF
EDF R&D SIGMA² | 18

19. DONNÉES MASSIVES DANS LE DOMAINE DE
L’ ÉNERGIE
 Qu’y a-t-il de nouveau ?
 Nouvelles sources de données (données de comptage, données de consommation
détaillées, services, données web, open data, …)
 ‘Digital utility’ : les systèmes physiques s’accompagnent de systèmes numériques
(transport, distribution, production), nouveaux acteurs, process de décisions plus
rapides
 Difficultés et opportunités
 (facile) La technologie est là
 (difficile) Savoir quoi faire de la donnée?
Intégration des données ; Sécurité et
privacy; Culture de la donnée; Compétences;
comment encourager l’innovation ?
 Opportunités: voir “Utility AMI analytics
for the smart grid”
•
| 19

20. DONNÉES MASSIVES DANS LE DOMAINE DE
L’ ÉNERGIE
 Un volume très important de données
à gérer (smart
meters, capteurs, …), mais les
volumes ne sont pourtant pas si gros
 Des traitements complexes :
 Séries temporelles
 Données distribuées, analyses
multi-échelles, niveaux local et
global (analytics, optimisation)
 Temps réel
Demain
Decision
support
Integrated
communication
AMI / smart metering
Aujourd’hui
| 20

21. PROJET DE RECHERCHE À EDF R&D : SIGMA²
Objectifs :
 Maîtriser les techniques associées au Big Data, assurer veille/anticipation, développer
des méthodes innovantes
 Poursuivre et renforcer la diffusion et l’intégration de ces approches au sein de
l’entreprise
• Ces objectifs passent par la réalisation de prototypes, d’études de faisabilité, d’expérimentations en réponse à
des problématiques métiers
EDF R&D SIGMA² | 21

22. POC STORM : ENJEUX POUR EDF R&D
Le « Proof Of Concept » (POC) Storm s’inscrit pleinement dans les objectifs de
SIGMA² , notamment la maîtrise des technologies Big Data en lien avec le
contexte EDF présent ou à venir
Les solutions Stream Processing / CEP déjà maitrisées :
StreamBase (TIBCO) et InfoSphere Streams (IBM)
Objectifs du POC :
Mieux connaître Storm et le positionner par rapport aux outils déjà maitrisés
Juger de la capacité de Storm à répondre à un scénario riche de « traitements
EDF » à la volée sur des données en provenance de compteurs communicants :
couverture fonctionnelle ? Capacité à absorber le flux ?
EDF R&D SIGMA² | 22

23. POC STORM : SCHEMA FONCTIONNEL GLOBAL
Data in motion
Entrées
Smart Metering
Data Stream
Sorties
• Agrégats simples
: ex. synchrone
globale
http://storm-project.net/ •Agrégats ventilés
: ex. synchrones
par groupe tarifaire
Data at rest
Prévisions Météo
Tarifs
statiques / dynamiques
•Analytics :
ex. scoring par
compteur
•Prévisions :
ex. Prévisions J+1
en Wh et en CA
Données clients
(par exemple tarif)
EDF R&D - SIGMA - FROST | 23

24. Focus sur 3 points clefs
Sorties
1
Smart Metering
Data Stream
DATA
• Agrégats simples
: ex. synchrone
globale
10
5
0
1
229
457
685
913
1141
1369
1597
1825
2053
2281
2509
2737
2965
3193
3421
3649
3877
4105
Data in motion
Entrées
Prévisions Météo
Data at rest
ANALYTICS
Tarifs
statiques / dynamiques
FORECASTING
•Agrégats ventilés
: ex. synchrones
par groupe tarifaire
2
•Analytics :
ex. scoring par
compteur
3
•Prévisions :
ex. Prévisions J+1
en Wh et en CA
Données clients
(par exemple tarif)
EDF R&D - SIGMA - FROST | 24

25. 1- DATA : SIMULER MASSIVEMENT ET FIDELEMENT LES
COURBES DE CONSOMMATION ELECTIQUE
 Utilisation d’un générateur / simulateur de courbes de charges
électrique, développé par EDF R&D
Consommations
individuelles
réelles
Consommations
individuelles
simulées
Modèle
génératif
Apprentissage
Utilisations possibles :
Simulation •
CARACTERISTIQUE DU GENERATEUR :
•Conserver la diversité des comportements individuels
•Reproduire des courbes ayant une volatilité comparable aux courbes
réelles
•Conserver le comportement global de l’agrégation des courbes
individuelles
• sans paramètres utilisateurs
•Simuler rapidement de gros volumes de données
•
Tester des outils
informatiques et des
méthodes statistiques
Echanger des
données simulées
EDF R&D - SIGMA - FROST | 25

26. 1 - DATA : EXEMPLES DE COURBES INDIVIDUELLES
GENEREES
 Performance du processus de génération :

Code JAVA

CPU 2 GHz (Xenon E5405)

360.000 tuples / seconde / CPU

1 CPU = 18 x plus rapide que le temps réel
(35 M de compteurs, au pas demi-horaire)
| 26

27. 2 – ANALYTICS : TRAVAILLER SUR DES SERIES
TEMPORELLES SIMPLIFIEES
Les Séries temporellessont des données de forte
dimentionnalité, difficile à exploiter dans un contexte
Big Data
Notre approche ici :
SIMPLIFIER l’objet « Courbe de Charge » pour faciliter
sa manipulation et son analyse, surtout quand on
travaille avec plusieurs millions de séries temporelles
SAX : Passer d’une série de mesures à un mot plus
compact
Ensuite, nous utilisons cette forme plus simple pour
« scorer » chaque courbe selon que la forme de la
courbe est plus ou moins commun dans l’ensemble de
la population
Principe de la transformée SAX
EDF R&D - SIGMA - FROST | 27

28. 3 – FORECASTING : LES MODELES GAM
GAM = Generalized Additive Model
Modèles étudiés depuis 2006 à EDF R&D (Dépt. OSIRIS) et à EDF depuis quelques
années
Utilisés sur de nombreux signaux : consommation Electrique au niveau agrégé et niveau
local, consommation de Gaz, …
Structure très générique:

Fonction de transferts linéaires ou non-linéaires

Effets mono ou multi-varies
Littérature scientifique sur le sujet: Hastie and Tibshirani (1986), Hastie and Tibshirani
(1990), plus récemment Wood (2006)
EDF R&D - SIGMA - FROST | 28

29. 3 – FORECASTING : EXEMPLE DE MODÈLE GAM
•
Le Département OSIRIS utilise R pour la modélisation GAM
EDF R&D - SIGMA - FROST | 29

30. Questions / Réponses
30
© OCTO 2013

31. Retour d’expérience sur une
expérimentation d’analyse
d’indicateurs en temps réel avec
Storm chez EDF R&D
31
© OCTO 2013

32. Sommaire
Contexte
Présentation de Storm
Déroulement du projet
Méthodologie de travail
Choix de l’architecture
Déploiement de Storm
Fonctionnalités implémentées
Spécificités et limites d’une implémentation Storm
Tests de performances
Bilan
32
© OCTO 2013

33. Contexte
33
© OCTO 2013

34. Contexte
Durée : 3 mois, entre Juillet et Septembre 2013
Client : Le projet SIGMA² de EDF R&D
Sujet :
Etude du positionnement des solutions CEP dans un contexte Hadoop
Performance et la scalabilité de Twitter Storm
Equipe : 3 OCTOs
Traitements à réaliser :
Agrégats en temps réel par dimension géographique, tarifaire sur la base des attributs attachés aux
courbes de charges
Scoring en temps réel, basé sur des règles en partie définies à l’avance et en partie évolutives
Prévisions de charge basées sur des fonctions R développées par EDF R&D
Développement d’une interface de restitution
34
© OCTO 2013

35. Contexte
Les moyens logiciels et humains fournis par EDF R&D
Des moyens humains en support
2 experts système & réseaux
2 experts métiers pour le scoring et le modèle de prédiction R
L’auteur du générateur de relevés de consommation
Du logiciel fourni
Un générateur réaliste de relevés de consommation
Des modèles de prédictions fixes et adaptatifs ainsi que des codes source en R
les exploitant
Des CSV contenant des données de références
Jointures groupe tarifaire / compteur
Données météo
Des codes sources d’exemple
D’utilisation du générateur de relevés de consommation
D’implémentation de SAX
35
© OCTO 2013

36. Contexte
Caractéristiques du cluster
8 serveurs « commodity »
2 noeuds maître
CPU : AMD Opteron Processor 6128
Mémoire : 64Go
Réseau : 1Gb/s
6 noeuds de traitement
CPU : AMD Opteron Processor 6128
Mémoire : 32Go
Réseau : 1Gb/s
Autres caractéristiques
co-localisation sur le même rack
Livrés installés avec une distribution CentOS 64bits
Accès réseau limité en dehors du centre R&D
Accès total de l’équipe sur le cluster
36
© OCTO 2013

37. Présentation de Storm
37
© OCTO 2013

38. Présentation de Storm
Storm est une solution de traitement de données orientée flux
Caractérisques principales de Storm
Garantie de traitement des données
Scalabilité horizontale
Tolérance aux pannes et transactionnalité
Pas d’intermédiaire
Abstraction plus haut niveau que le message passing
Robustesse
Traitement de Flux
38
© OCTO 2013
RPC Distribués
Calcul en continu

39. Présentation de Storm
Concepts de Storm
39
© OCTO 2013

40. Présentation de Storm
Trident
Abstraction transactionnelle sur les bolts et les spouts
Traitement par mini-batchs de N tuples
Garantie de traitement ordonné des mini batchs
Facilite les calculs d’agrégation
40
© OCTO 2013

41. Déroulement du projet
41
© OCTO 2013

42. Méthodologie de travail
Une méthodologie itérative
Pourquoi ?
Peu de temps pour tout réaliser
3 sujets dans le projet
Comment ?
Notre storyboard
Equipe Co-localisée
Backlog priorisé
Réunion d’avancement et démo hebdomadaire
Notre lieu de débats
42
© OCTO 2013

43. Méthodologie de travail
Un projet varié
Backlog : 60% des tâches réalisées
55 identifiées, 33 priorisées et réalisées
43
© OCTO 2013

44. Choix de l’architecture
DataFlow fonctionnel
DONNÉES
• Relevés de
compteurs EDF
(générateur)
• 48 points de
mesures en KWh
par jour et par
compteur
• 6 millions de
compteurs
• Les compteurs
sont segmentés par
groupe tarifaire
44
© OCTO 2013
ACQUISITION ET
TRAITEMENT
Calcul de métriques en
continu, par jour et par
groupe tarifaire :
• Moyenne de
consommation
• CA
• Prévision pour les
métriques précédentes
à J+1
• Scoring typicité des
courbes compressées
par SAX
REQUETAGE
• Vues pré calculées
par agrégat
disponibles au
requêtage
• Agrégation des
vues en agrégats
plus grands
• Affichage en
tableaux de bords
(courbes,
histogrammes)

45. Choix de l’architecture
Architecture technique
Interface de
Suivi de restitution
Questionne la topologie
à la demande (DRPC)
Utilisateurs
Calculs
d’agrégats
Calcul
de scores
Calcul de
Prévisions
TridentState
TridentState
TridentState
Tables de
référence
Topologie de
calcul Storm
Générateur
42,63…2,0…24…1,0484,…
45
© OCTO 2013
Envoi du stream
aux différents
TridentStates
Les données générées sont
• regroupées par compteur et
par jour (tuple)
• ajoutées sur une liste Redis
Récupère des
mini batchs
Stockée sur
chaque serveur
en CSV
Spout
A intervalle régulier, les
Spouts lisent entre 500 et
10000 tuples chacun de
la liste Redis

46. Déploiement de Storm
Composants installés
Storm
Nimbus
DRPC
UI
Supervisor(s)
Zookeeper
Support
Redis
Tomcat
Outils de dev : nexus, gitolite
46
© OCTO 2013

47. Déploiement de Storm
Vue physique du cluster
Rack
1Gb/s intra rack
Nœud maître
•
•
Storm
•
Nimbus
•
UI
•
Drpc
Tomcat
Nœud maître
•
•
•
Storm
supervisor
Redis
Zookeeper
Nœuds de traitement
• Storm supervisor
47
© OCTO 2013
Réseau 10Gb/s
Développeurs
et
Utilisateurs

48. Fonctionnalités implémentées
3 traitements à implémenter
Calcul d’agrégats de consommation journalière
par groupe tarifaire et national
Calcul des scores du degré de typicité des consommations
Par compteur et par jour
Calcul des prévisions J+1 de consommation
par groupe tarifaire et national
Sur chaque agrégat disponible
48
© OCTO 2013

49. Fonctionnalités implémentées
Calculs d’agrégats
49
© OCTO 2013

50. Fonctionnalités implémentées
Calculs de scores de normalité des relevés
50
© OCTO 2013

51. Fonctionnalités implémentées
Calculs de prévisions pré-calibrées
51
© OCTO 2013

52. Fonctionnalités implémentées
Calculs de prévisions adaptatives
52
© OCTO 2013

53. Fonctionnalités implémentées
Interface de restitution des moyennes de consommation avec prévision
53
© OCTO 2013

54. Fonctionnalités implémentées
Interface de restitution du nombre de métriques collectées
54
© OCTO 2013

55. Spécificités d’une implémentation sur Storm
Implémentation de calculs sous une forme distribuée
La nature distribuée de Storm rend parfois des algorithmes
relativement « simples » difficiles à implémenter :
Les streams imposent de calculer de manière incrémentale
Trident, la couche transactionnelle de Storm impose primitives
particulières
Spécificités d’utilisation de R avec jRI
55
© OCTO 2013

56. Limites constatées de l’implémentation sur Storm
L’interface de Storm fourni les métriques de latence mais…
D’autres composants entre en jeu (Zookeeper, Redis, …)
Cela rend la mesure de performance globale et fiable
(traitements + comportement du cluster) difficile
56
© OCTO 2013

57. Tests de performances
Source de données
Une journée / compteur
48 relevés de consommation par compteur et par jour + identifiant compteur
300 octets de taille moyenne
Jeux de données pré-générés
Consommation de 1 million de compteurs sur 2 jours
Consommation de 6 millions de compteurs sur 2 jours
57
© OCTO 2013

58. Tests de performances
Performances en lecture de Redis
413 850 journées / compteur / seconde
19 864 800 relevés / seconde
En terme réseau : 120Mo / seconde (max 125Mo/s)
A titre de comparaison, un macbook pro SSD 16Go DDR3 obtient :
791 565 journées / compteur / seconde soit une augmentation de 47%
58
© OCTO 2013

59. Tests de performances
Calculs d’agrégats
4m5s pour traiter 576 millions de relevés
1,98 million de relevés / seconde
Les machines n’étaient pas surchargées : charge CPU < 50%
Nombre de relevés
émis
Temps de traitement
59
© OCTO 2013

60. Tests de performances
Calculs de scores de normalité des relevés
5m27s pour traiter 180 millions de relevés
550 458 relevés / seconde
Nombre de
relevés émis
Temps de
traitement
60
© OCTO 2013

61. Tests de performances
Calculs de prévisions pré-calibrées
4m23s pour traiter 576 millions de relevés
2,19 millions de relevés / seconde
Les machines du cluster n’étaient pas surchargées : charge CPU < 50%
Nombre de
relevés émis
Temps de
traitement
61
© OCTO 2013

62. Tests de performances
Calculs de prévisions adaptatives
6m41s pour traiter 576 millions de relevés
1,43 million de relevés / seconde
Les machines du cluster n’étaient pas surchargées : charge CPU < 50%
Nombre de
relevés émis
Temps de
traitement
62
© OCTO 2013

63. Questions / Réponses
63
© OCTO 2013

64. Conclusion
64
© OCTO 2013

65. Bilan
Sur Storm
Points positifs
Traitement de gros volumes au fil de l’eau
Prévisions en quasi temps réel avec R
Facile à mettre en œuvre, à configurer
Polyvalent
Jeune, pourtant bien documenté et stable
Points à creuser
Mesure de performances
Reprise sur erreur de traitements
Intégration dans Hadoop
65
© OCTO 2013

66. Bilan
Storm dans une perspective industrielle
Hadoop est adapté en traitements batchs mais mauvais en
temps réel
Storm est adapté en temps réel mais n’a pas de couche de
stockage de big data
66
© OCTO 2013

67. BILAN POC STORM PAR EDF R&D
Points positifs :
 Solution crédible, qui couvre le spectre fonctionnel du scénario proposé
Coût , renforcé par l’intégration de Storm dans Hadoop (HDP Q1 2014)
Points négatifs :
Nécessité de s’investir dans un nouvel outil, avec sa logique et sa syntaxe
NB : trident offre cependant un niveau d’abstraction intéressant
Manque d’un studio de développement (cf. Streambase)
Ex : visualiser le graphe de traitements
Suite envisagée :
Prototype STORM d’un système d’estimation temps-réel des volumes
d’effacements électrique
•
EDF R&D SIGMA² | 67

68. Remerciements
L’équipe côté EDF
Alexis BONDU – Ingénieur chercheur, auteur du générateur
Bruno JACQUIN – Ingénieur chercheur
Charles BERNARD – Consultant IT
Leely DAIO PIRES DOS SANTOS – Ingénieur chercheur
Yannig GOUDE – Expert prévision
L’équipe côté OCTO
Simon MABY – Consultant
Cyrille MAILLEY - Consultant
68
© OCTO 2013

69. Merci
69
© OCTO 2013