Dans un format intimiste, Tech4Exec démystifie, le temps d’une matinée, les sujets et technologies stratégiques du moment, pour en comprendre les implications, les déclinaisons opérationnelles concrètes et leur intérêt pour l’entreprise. Le format est simple et efficace : 15 mn de vulgarisation, 25 mn de mise en oeuvre et 1h de retours d’expérience client. La vidéo est disponible ici : https://youtu.be/U79Dp7xiF4E https://tech4exec.fr/

1. #Tech4Exec
OUI.sncf propose des voyages moins chers grâce
au Big Data et au Machine Learning

2. Agenda
•Contexte Data OUI.sncf
•Exemple « Trajets alternatifs »
•Conclusion & Questions

3. Contexte Data OUI.sncf

4. Chiffres
•1,5 Mds de recherches d’itinéraires /
an
•33 M de possibilités de voyages
•100 To de données / mois
Usages
•Assurer la QoS de nos SI
•Centralisation des LOGs
•Hypervision
•Personnaliser les Offres
•Prédiction des prix et Propositions de trajets alternatifs

5. Focus sur la Proposition de trajets alternatifs
2013 – 2015 : POC par une « Component Team »
•6 mois pour explorer la donnée
•18 mois pour construire et prouver la fiabilité du nouveau système
2016 – aujourd’hui : Indus. et Valorisation par une « Feature Team »
•Construction de fonctionnalités
•Exposition de service

6. Trajets alternatifs
Et autres contributions de la Data et du Machine Learning au développement de l’Offre OUI.sncf

7. Problème : un cache de données inadapté
Contraintes
•Distributeur contractuellement limité dans sa capacité de
requêter le Catalogue du transporteur
•Refonte Offre SNCF avec effet volume sur l’Entrepôt d’Offres
•Cache limité à 200 trajets
•Asset peu résiliant
Innovation
•Créer un cache avec un volume de prix suffisant pour proposer
le meilleur prix à la journée
Décision
•Utiliser le trafic naturel du passé pour remplacer l’EO
Une expérimentation sur 6 mois pour dire si le produit est viable
et mérite une équipe à plein temps

8. Proof of Concept - Démarche
Démarche Agile Exploratoire
•Kanban sur la totalité du projet
Atelier initiaux pour déterminer les objectifs => Fonction du coût
Puis cadencée par des paliers et des “ stop ou encore “ mensuels

9. Proof of Concept - Dispositif
Une mini équipe :
● 1 Architecte et Dev Sénior (compétences
écosystème Hadoop)
● 1 Data Scientist (issu de la finance et du
marketing)
● 1 Dev plus junior (réparti sur 2 personnes)
● 1 Scrum Master
● Des contacts métiers pour aider le Data
Scientist à décoder les modèles de données
Objectif : articuler ces compétences
autour d’objectifs communs

10. Step 1 : Analyse exploratoire & Data Cleaning
•Analyse exploratoire des LOGs
•Statistiques de fréquence de renouvellement des informations
(trajets/tarifs)
•Data Cleaning
•Facteurs d'influence sur la vitesse de disparition d'un trajet/tarif
(saisonnalité, classes de tarifs, comportements clients)
•Analyse de l'évolution du stock
•Tech : Flume, Hadoop & Jobs Map/Reduce
•Technos déjà en place chez OUI.sncf en 2013
•Résilientes – Tolérance à la panne
1

11. Step 2 : Système naïf / Modélisation
•Une architecture sans intelligence « Machine Learning »
•On reçoit un historique de donnée et on publie la plus « fraiche »
•Aucune règle
•Construction de la Mesure du taux d’erreurs
•Quels sont les taux d'erreurs ?
•Déduire les axes d'amélioration
•Modélisation et développement de la fonction de coût
•Ce qu’on va chercher à optimiser
•Comment faire progresser la fiabilité de la donnée sans retomber
dans un cache basique ou tout est requêté à période fixe
•Tech : ELS, Greenplum, Spark, Mahout, Akka
2

12. Step 3 : Machine Learning
•La machine ne suffit pas
→ des « sachants » métiers pour révéler le sens des données
•Le Data Scientist cherche des logiques pour générer l’information qu’on
n’a pas
•Ex. : on a reconstruit toute la matrice de corrélation des gammes de services
•Le ML a montré les modèles qui permettaient de générer de l’information
d’aussi bonne qualité que si on l’avait reçue
•Ex. : déduire les prix « avec cartes de fidélité » (peu de volumes) à partir du flux « sans cartes »
… simulation du volume
•On a cherché à prédire le prix suivant
•Rétro-engineering sur le Yield
•Remarque : parfois les modèles pensés par le Data Scientist n’étaient pas
automatisables → introductions des compétences de Data Engineers
•Pragmatisme & Culture du quick win
•Réduction du nombre de requêtes au catalogue
3

13. Step 3 : Machine Learning
•Les services historiques du cache portés sur le nouveau système
•Volume : 200 à 2000 trajets proposés
• Le système devient ouvert et force de potentiel grâce au Big Data
•« Meilleur tarif pour un trajet » devient le « Flux Trains » càd « le meilleur tarif pour 10 trajets
différent », avec le même niveau d’expérience client
•À ce stade on propose de nouvelles Feature en Production directement à
partir du gisement de données
•« Meilleur prix du jour » + « n clients ont vu la même chose que vous »
•« Jauge de prix » pour aider les clients à fixer leurs seuils d’alerte sur les tarifs
4

14. Step 3 : Machine Learning
•L’équipe est devenue une « Feature Team »
•Compétences Front
•API Management
•Service évolué d’alerte sur le Petits prix
•Propositions de trajets alternatifs, moins chers et plus longs
•Services Front :
•Meilleur prix du jour, du mois
•Meilleur prix des trains de la journée
•toute variété tarifaire confondue
•Au lieu de 6 propositions dans un devis standard
•Flux comparateurs et Ciblages proposés à des partenaires
5

15. Depuis 2016
•Le système est très évolutif et les métiers ont pleins d’idées J
•Passer en mode « push » (Kafka)
•Répliquer rapidement sur un autre transporteur (les BUS)
•On refait en quelques sprints le parcours de initial de plusieurs mois
•Donnée plus volatile → mise en qualité ; confirme l’importance du Data Engineer
•Réinjecter du Machine Learning
•Privilégier la Data Analyse pour anticiper les changements plutôt que de repartir
d’une copie blanche en Data Science
•Data ré-engineering sous contrainte pour rafraichir nos données avant le client
(INRIA – Tech : Algo. Random Forest)
•Prioriser nos prochains Dévs par la mesure
•mieux isoler les pbs, analyser dans le détail (Tech : Kibana, Grafana)

16. Le système aujourd’hui
Data
•7 M de Logs traités / jour ; chaque Log est traité et indexé en 1,5s
•22 M de propositions Train
•2 M de propositions Bus
•78 M de préférences utilisateurs
•500 K statistiques de prix
•250 K trajets trains
•Cluster Elasticsearch de Production : 200 M de documents
•Hadoop/HDFS : 64 TO de données ; une dizaine de traitements Spark
•Kafka : 300 messages/s

17. Conclusions et enseignements
Le chemin est long … mais nécessaire
•La valeur se développe au fur et à mesure, différemment de ce qu’on
imagine au départ
•donc il ne faut rien promettre au départ J mais prouver
progressivement (mesures)
•au final : des règles assez simples
•Equipe évolutive : Component & Tech → Feature &
Multi-compétences
•La vraie Data Science est nécessaire mais ponctuellement
•Il faut orienter les Data Scientist vers la Data Analyse
•C’est là qu’on a le plus de valeur, par incréments
•C’est aussi leur meilleur apprentissage
Aujourd’hui chez OUI.sncf
•30 collaborateurs font du Big Data toutes disciplines et
territoires confondus

18. Des questions