En Juin dernier, un journaliste nous a posé la question suivante :
Juvénal, votre ouvrage Hadoop – Devenez opérationnel dans le monde du Big Data aborde le problème de la compréhension des technologies Hadoop. Selon vous, les entreprises françaises ont-elles atteint un niveau de maturité suffisant pour faire éclore des projets en production réelle, et non plus se cantonner aux PoC sans vrai usage à valeur ?
En clair, le journaliste voulait savoir si au-delà des PoC (Proof of Concept), les entreprises avaient réellement des besoins dans le Big Data.
En tant que consultant directement impliqué dans la valorisation des données dans les entreprises, nous pouvons vous assurer que oui, les entreprises ont de réels besoins en matière de Big Data !
En réalité, les besoins des entreprises actuellement en matière de Big Data tourne autour de 2 sujets fortement inter-corrélés : la mise en place d’un data lab pour uniformiser l’utilisation de données et l’industrialisation de la data science pour améliorer la prise de décision.
Dans ce contexte, le data lab intervient à la fois comme le socle infrastructurel sur lequel va s’appuyer l’entreprise pour valoriser les données. Mais au fait, qu’est ce qu’un Data lab ? En quoi est-il différent du Data Lake ? Quel est son intérêt ? Comment on le construit ?
Dans cette chronique, nous allons répondre à ces questions. Nous allons vous montrer l’intérêt d’un Data lab pour des projets data et nous vous indiquerons les approches méthodologiques à suivre pour sa mise en place.
Sommaire
1 – Définition et Intérêt d’un Data Lab
Le driver principal de la mise en place d’un Data lab c’est la data science, plus précisément la valorisation des données.
Il est de coutume dans le milieu de dire « Big Data without Analytics is just data », en d’autres termes : Le « Big » Data sans l’analyse n’est que la donnée. Si l’entreprise n’est pas capable de traiter toutes les données qu’elle collecte à travers son système d’information, alors ces données ne servent à rien, même si elles contiennent le potentiel de fournir à l’entreprise un avantage décisif par rapport à ses concurrents.
Les entreprises sont de plus en plus conscience de cela et c’est pourquoi beaucoup sont en train de quitter le stade du simple reporting classique (comprenez par-là tableaux croisés dynamiques) pour embrasser les techniques plus sophistiques de valorisation de données (IA, Machine Learning, Data mining, apprentissage supervisé, Deep learning, scoring, classification, recommandation, etc…). Par exemple, dans le secteur bancaire, on rencontre de plus en plus d’entreprises qui ont construit des modèles de scoring qu’elles utilisent pour classer les clients en fonction de leur capacité à rembourser les crédits ou pas. Cela n’était pas le cas, il y’a encore quelques années… Pareil dans le secteur de la grande distribution, les modèles de classification et de recommandation sont de plus en plus utilisés pour regrouper les clients en fonction de leurs niveau de similarité et leur recommander des produits sur la base de leur consommation antérieure et celles des personnes qui ont le profil similaire au leur. Il n’y’a qu’à aller faire un achat sur Amazon, cdiscount, la FNAC, ou tout autre grand distributeur pour vous rendre compte de l’apparition systématique de la catégorie « vous aimeriez aussi » ou « produits similaires à ».
Avec le volume de données apporté par le Big Data et la disponibilité de la puissance de calcul, les entreprises veulent même aller encore plus loin et explorer le temps réel, les objets connectés, ou l’industrialisation des modèles statistiques dans le but d’être plus réactive dans l’ordre de la seconde. Mais ce qui les empêche aujourd’hui de le faire c’est deux choses : Les silos de données, et la précision des modèles.
1.1 – le problème de silos de données
Vous devez savoir que l’efficacité des résultats d’un algorithme de data science dépend pour beaucoup de la qualité de données.
De part leur nature fondamentale, pour atteindre leur objectif de gestion, les entreprises spécialisent leur organisation en « directions métiers » qui s’occupent d’un processus particulier de l’activité de l’entreprise. Cette organisation intrinsèque a tendance à « siloter les données » de l’entreprise.
Ainsi, pour pouvoir valoriser les données de l’entreprise, il faut dans un premier temps réussir à les faire converger vers un même référentiel, indépendamment de leur provenance, ni de leur métier (c’est ce qu’on appelle le processus d’uniformisation des données). Le silotage inhérent à l’activité de l’entreprise rend cette tâche de transversalité très compliqué.
De plus, même lorsque l’entreprise dispose d’un ERP qui normalement centralise toutes ses données métiers à cause de son utilisation conjointe par toutes les directions de l’entreprise, chaque direction tend toujours à utiliser au sein de ses services ses propres applications, notamment les tableurs.
La flexibilité des tableurs permet aux utilisateurs métier de créer des applications simples sur les données structurées et d’effectuer leurs propres analyses des problèmes métier qu’ils rencontrent. Il y’a trois autres facteurs qui jouent en faveur de l’utilisation des tableurs dans les directions d’entreprises :
1 – la montée en compétence (ou courbe d’apprentissage) y est très légère, comparé à la prise en main d’un module d’ERP tel que SAP, qui nécessite souvent des professionnels dédiés.
2 – Ils se déploient facilement sur le poste de travail des utilisateurs et s’adaptent parfaitement à leur environnement de travail.
3 – Les utilisateurs ont le contrôle sur les applications qu’ils développent et peuvent facilement les partager.
Malheureusement, cette lassitude offerte par les tableurs (et les outils de type « self service » en général) aux utilisateurs silote encore plus les données de l’entreprise, et rend plus difficile la tâche d’uniformisation des données, indispensable pour la valorisation de données grâce à la data science.
les silos de données créent des doublons (on parle de « plusieurs versions de la vérité » – « many version of Truth ») et des versions incomplètes des données, puisque chaque utilisateur possède sa propre version. Cela créé des problèmes d’incomplétude de données (missing value) préjudiciables aux analyses de données. Jusqu’aujourd’hui encore, plusieurs entreprises souffrent de ces problèmes de silos de données. L’explosion des données dans l’ère du Big Data ont donné ces problèmes, une importance sans précédent.
1.2 – le problème des compétences
Tout comme l’efficacité d’un algorithme de data science dépend de la qualité des données, la pertinence de ses résultats dépend de la précision du modèle dans lequel il est utilisé. Un modèle est une représentation simplifiée de la réalité. Il s’utilise lorsque l’on souhaite avoir une vision macroscopique d’un phénomène. Pour cela, le modèle élimine beaucoup de facteurs et n’en retient que les plus pertinents à la représentation du phénomène.
D’une manière globale, on dit d’un modèle qu’il est précis s’il arrive à représenter de façon plus ou moins claire la réalité qu’il modélise. En analyse de données, la modélisation permet de ressortir les facteurs explicatifs essentiels d’une source de données. L’idée est de comprendre le schéma selon lequel les données sont générées pour pouvoir anticiper ses prochaines valeurs. Par exemple, supposons que vous avez la liste de données suivante :
3 5 8
10 12 15
100 102 105
7 9 12
Vous remarquerez que chaque ligne de données est générée selon un schéma précis. La valeur de la deuxième colonne est toujours égale à la valeur de la première colonne plus 2, tandis que la valeur de la troisième colonne est toujours égale à la valeur de la deuxième colonne plus 3.
Dans ce cas de figure, si on suppose que cette hypothèse (ce constat) est vraie, alors il est facile pour nous d’anticiper que si la valeur de la première colonne est égale à 4, alors la valeur de la deuxième sera égale à 6 et la troisième à 9. Le but d’un modèle de données consiste à ressortir ce genre de relations. Plus il sera capable d’expliquer le schéma selon lequel les données sont générées et plus il sera précis.
Il existe plusieurs techniques et algorithmes de modélisation de données, les techniques de régression, d’arbre de décision, de réseaux de neurones, de machine à vecteur support, etc. Manipuler ces techniques pour trouver le modèle le plus précis exige un certain niveau de compétences. Sans compter les ressources humaines nécessaires dans la gestion entière du cycle de vie du modèle de data science.
Ainsi, pour construire un Data lab qui aura une véritable utilité, il faut être en même de regrouper au sein de ce Lab, des compétences transversales pour l’exploitation des données (data engineers, data scientists, architectes data), et être capable de les faire travailler en équipe (ce qui nécessite le plus souvent d’utiliser une méthodologie de gestion de projet agile, notamment Scrum, grâce à laquelle on pourra combiner les ressources en « feature team »).
1.3 – Définition du Data Lab
Des 2 problèmes précédents que pose l’uniformisation des données, on déduit aisément l’intérêt et la définition d’un Data Lab. Pour tirer profit de ses données, la première étape pour une entreprise revient à mettre en place un point d’accès transversal et unique à toutes les données de l’organisation. Cela passe naturellement par la mise en place d’une sorte de « centre de données ». Certains qualifient ce centre de Data Lab (laboratoire de données), d’autres de Enterprise Data Hub (Hub de données), d’autres encore de Data Lake (Lac de donnée). Vous avez compris l’idée…
Ce Data Lab est absolument nécessaire parce que la dispersion des données résultant du silotage organisationnel ne favorise pas l’exploitation intelligente de la données.
Ainsi, lorsqu’on parle de Data Lab, on fait référence à un endroit physique dans lequel on fait converger toutes les sources de données opérationnelles de l’entreprise afin de les uniformiser pour les valoriser à la fin à l’aide d’algorithmes de Data science.
A la différence d’un Data warehouse où l’uniformisation ne fait pas forcément référence à la centralisation des données vers un lieu (répertoire de stockage unique), dans le Data lab, l’uniformisation fait forcément référence à un lieu physique, pas juste un logiciel ou une couche sémantique harmonisée à travers lequel on enregistre les données, mais un endroit dans lequel travaille une ou plusieurs équipes transverses/pluridisciplinaires.
Le Data lab regroupe des compétences diverses, à savoir les data scientists pour la valorisation en aval des données, les data engineers pour l’uniformisation en amont des données, les chefs de projets/scrum Master pour la gestion des projets adressées au Data lab, ainsi que des architectes et des administrateurs pour la définition et le suivi continu de l’infrastructure technique.
Les enjeux associés au Data Lab sont principalement double :
- avoir une vision globale sur l’activité de l’entreprise afin de soutenir la prise de décision ;
- répondre aux exigences de réglementation en vigueur. Par exemple dans la banque, les réglementations Bâles forcent les entreprises à conserver un historique de leurs données ; les réglementations Sarbannes Oxley ; et récemment les réglementations RGPD (Réglementation Européenne sur la Protection des données), qui obligent les entreprises à indiquer en cas de demande par leurs clients les données qu’elles possèdent les concernant.
Au-delà de l’industrialisation de l’analyse de données, l’idée derrière le data lab c’est également de rapprocher les utilisateurs métier des résultats des analyses de données : c’est la problématique de consommation de l’Analytics. C’est aussi ce qui explique le regain accru du côté de la visualisation des données pour la consommation par les métiers.
Bien que ce soit aussi simplement expliqué, intégrer toutes les données d’une entreprise (répartie dans plusieurs pays sur plusieurs continents) n’est pas une mince affaire, car le Data lab se veut être le quartier général des données de l’entreprise !
2 – Technique de mise en place d’un Data Lab
En dehors de la fonction de « quartier général » de valorisation des données où les métiers de l’entreprise peuvent expérimenter sur les données, tester divers scénarios et précision d’algorithmes de data science, le Data lab a une autre fonction que nous n’avons pas cité précédemment, mais que vous devez comprendre maintenant pour mieux appréhender les techniques que nous allons aborder dans cette partie : permettre à tous les utilisateurs de l’entreprise de traiter les données au niveau départemental tout en conservant une vision unifiée de ces données traitées au niveau corporate. Cela signifie que dans les approches de mise en place d’un Data lab, il faut également prendre en compte la mise à disposition (ou consommation) des données auprès des utilisateurs métier.
Sur la base des enjeux principaux et des contraintes qui pèsent sur le Data Lab, 2 grandes approches peuvent être utilisées pour le construire (d’un point de vue logiciel). Ces approches consistent :
- soit à centraliser l’environnement informatique, restreindre la manipulation des données aux métiers et leur laisser la main uniquement sur les tâches de consultation (auquel cas tous les travaux d’ingénierie des données, de qualité, et de data science sont faits en amont par les équipes dédiées au Data lab) ;
- soit alors à décentraliser l’environnement informatique et laisser totalement la main à l’utilisateur à la fois sur l’environnement, la manipulation des données et le Reporting (dans ce cas de figure, les équipes du Data Lab s’occupent uniquement du pré-traitement, de la qualité et de l’ingénierie des données).
Voyons en profondeur chacune de ces approches.
2.1 – Les approches centralisées de construction du Data Lab
Dans une approche centralisée, les applications des utilisateurs métiers se connectent toutes à un répertoire du Data Lab pour le ravitaillement en données. Ce répertoire peut être un chemin d’accès sur le disque dur du serveur du Data Lab, ou alors une base de données. L’accès à ce répertoire unique est contrôlé, la sécurité est géré par l’équipe des administrateurs du Data Lab, et les droits d’accès sont fournis aux utilisateurs en fonction de leurs privilèges (privilèges qui auront été définis en amont par les équipes d’administrateur du Data Lab). Et même, l’accès au Data Lab (la salle physique) est restreinte uniquement au personnel habilité du Data Lab et protégé par mécanismes sophistiqués de verrous (empreinte digitale, mot de passe, puce électronique, badge d’accès, etc). 3 méthodologies ont été développées selon cette approche :
- L’approche Data Warehouse : la première approche qui a été mise en place consiste à centraliser toutes les données opérationnelles de l’entreprise dans un Système de Gestion de Base de Données et organiser ces données en unités métiers. Les unités métiers sont mises à la disposition des utilisateurs métier correspondant. Par exemple, une unité finance qui regroupe toutes les données liées à la finance, qui est ensuite mise à disposition des analystes financiers. Du coup le Data Lab devient un endroit physique où sont hébergées les données de l’entreprise et dans lequel tous les besoins data sont adressés. Les métiers adressent leurs besoins et cas d’usage aux équipes des data engineers et data scientist du Data Lab, qui les développent entièrement et leur livrent les résultats uniquement pour consommation. D’un point de vue organisationnel, l’entreprise peut utiliser une méthodologie de gestion de projet agile telle que Scrum ou encore se réorganiser complètement (selon la méthode SAFe par exemple), pour être en mesure de former des équipes transversales qui travaillerons à la fois dans dans le Data Lab et avec des métiers.
- L’approche « bac à sable » :La deuxième approche qui a suivi l’approche data Warehouse est l’approche bac-à-sable, de l’anglicisme « Sandbox ». Une approche bac à sable consiste à mettre sur pied un environnement informatique (généralement en Cloud) qui permet à l’utilisateur d’avoir un plus large contrôle sur la manipulation et l’exploitation des données. L’intérêt ici est de donner plus de contrôle aux directions métiers afin qu’elles traitent elles-mêmes les données comme elles l’entendent. Le bac à sable leur permettrait de faire des tests, développer eux-mêmes leurs modèles, bref traiter les données qu’elles souhaitent sans affecter les autres directions, ni les données originales qui sont dans la base de données. D’un point de vue organisationnel, à la différence de l’approche data lake où le data lab a ses propres équipes, ici, c’est chaque métier qui constitue ses propres équipes de Data scientists, de data engineers, etc. Les bacs à sable définissent un environnement informatique qui reste centralisé, mais en même temps permet à toutes les directions métiers d’y accéder sans avoir à créer un environnement spécifique pour chacune d’entre elles. C’est pourquoi les bacs à sable sont généralement des cas de virtualisation ;
- L’approche « Data Lake » : la troisième approche qui a suivi l’approche « bac à sable » est liée à l’explosion du volume des données dans l’ère Numérique. Cette approche est très similaire à la première en ce sens que les données sont centralisées dans un lieu physique – le data lab avec des équipes dédiées. La seule différence est que toutes les données sont centralisées dans un cluster Hadoop indépendamment de leur provenance métier, ensuite les équipes du Data Lab développent des services qui sont déployées sur le cluster et permettent aux utilisateurs d’exploiter ces données. L’intérêt d’un cluster Hadoop se situe sur le stockage efficace de la variété des données et la gestion des différents actifs de données générées par les activités du Numérique. Pour mieux apprivoiser l’approche data lake de construction d’un Data Lab, nous vous recommandons notre ouvrage qui traite exclusivement du sujet : « Big Data Streaming : Approches de traitement streaming & temps réel en Big Data » ;
Les approches centralisées n’ont pas apporté de solution durable au problème de silos et d’exploitation de données, dans l’un des cas, elle a permis de centraliser (ou au mieux d’uniformiser) la donnée, mais dans l’autre elle a restreint, voir frustré les utilisateurs métiers. C’est pourquoi des approches dites « décentralisées » ont été mises au point.
2.2 – Les approches décentralisées de construction du Data Lab
Les approches centralisées n’ont pas réussi à répondre aux promesses du « dé silotage » de l’entreprise et aux enjeux d’exploitation de données que font face les utilisateurs métier. Dans ce paragraphe, nous allons explorer les approches qui ont tenté et tentent toujours d’être des réponses aux limitations imposées par les approches centralisées.
Au lieu de centraliser l’environnement informatique et les données, les approches décentralisées consistent à créer pour chaque utilisateur un environnement informatique directement au niveau de son poste de travail et à alimenter cet environnement de sources de données internes ou externes à l’entreprise, un peu comme dans l’approche « bac à sable », mais en plus petit format pour des équipes à taille plus restreinte. Cet environnement porte généralement le nom de « self-service » ou « libre-service ». Il permet aux utilisateurs d’avoir totalement la main sur ce qu’ils font des données. Il existe actuellement 2 approches décentralisées : la Self-Service BI et la Self-Service Analytics.
- La Self-Service BI ou Self-Service Business Intelligence est une approche décentralisée de valorisation de données qui permettent aux utilisateurs métier d’accéder et travailler avec les données de l’entreprise sans l’intervention du service informatique. Cette approche mise sur la convivialité et la simplicité d’utilisation de l’environnement informatique et laisse la main à l’utilisateur en ce qui concerne la création des rapports personnalisés ;
- Tout comme la Self-Service BI, la Self-Service Analytics est une approche décentralisée de valorisation de données, à la seule différence de cette dernière, elle permet aux utilisateurs de d’aller plus loin en matière d’analyse de données et d’effectuer des analyses statistiques, et du Machine Learning dans un environnement « user-friendly ». Certains éditeurs se sont positionnés sur ce segment de marché pour offrir des solutions self-service BI ou Self-service Analytics. Tout à l’heure, nous allons vous présenter quelques technologies Self Service de Data Lab ;
Que ce soit les approches centralisées ou les approches décentralisées, les approches de construction de Data Lab doivent à la fois permettre de centraliser/uniformiser les données et fournir les fonctionnalités nécessaires pour qu’elles puissent être délocalisées au niveau des utilisateurs.
Voyons maintenant en détail, quelques technologies utilisées pour équiper son Data Lab.
2.3 – Les technologies du Data Lab
Les technologies à utiliser pour son data lab dépend de l’approche choisie pour le construire. Lorsqu’on on est sur une approche centralisée, on va privilégier les technologies spécialisées sur le traitement à large échelle des données. On peut citer :
- Teradata, qui est sans doute leader sur l’interrogation des données relationnelles hébergées dans les sources opérationnelles de l’entreprise. Teradata peut très bien être utilisé comme hub d’interrogation de données structurées. Il possède les capacités analytiques et les performances adéquates pour ce type d’opérations, et de plus a déjà fait ses preuves sur le marché.
- Juste après Teradata, nous pouvons citer EMC GreenPlum, qui est un moteur de calcul analytique très complet et très puissant pour l’analyse de données. Tout comme Teradata, il peut servir de hub d’interrogation de données.
- Hadoop/Spark : si on est dans une approche data lake où on doit valoriser une large variété de données, on peut passer sur un cluster Hadoop ou un cluster Spark pour bénéficier de suffisamment de puissance et d’échelle dans les calculs. Par contre, l’utilisation d’un cluster Spark ou Hadoop ne doit pas être pris à la légère car leur maîtrise demande des compétences pointues au sein du Data Lab. Nous possédons de nombreuses formations pour vous aider vous ou votre équipe à monter en compétence sur Spark. Vous les trouverez ici : Maîtrisez Spark pour le Big Data avec Scala
Au-delà de logiciels spécifiques, certains éditeurs proposent tout un environnement informatique clé en main pour votre data lab (recommandé pour l’approche bac-à-sable). Dans ces environnements, vous avez toutes les technologies dont vous avez besoin pour votre data lab. Cela réduit énormément le TCO et vous évite d’avoir à administrer technologie par technologie. Comme vous l’aurez déviné, les solutions de ces éditeurs sont basées sur du cloud. Les principaux fournisseurs sont :
- Google, avec Google Cloud Datalab, sa solution sur GCP pour le Data lab. Vous avez un infrastructure Cloud à votre portée avec la distribution Hadoop Cloud de Google, GCP.
- Amazon, avec sa solution AWS EMR, dans lequel vous combinez l’infrastructure Cloud AWS avec la distribution Cloud Hadoop d’Amazon, EMR.
- Microsoft, avec sa solution cloud Azure, que vous pouvez coupler avec Azure HDInsight pour obtenir toutes les technologies dont vous avez besoin dans votre Data lab.
Les technologies cloud fournissent l’infrastructure et l’ensemble des logiciels nécessaires pour tout type de cas d’usage d’exploitation de la donnée dans votre Data Lab. Si vous optez plutôt pour une approche décentralisée, aucune de ces solutions ne pourra vous aider. Il vous faudra vous réorienter vers les solutions « Self Service ». Nous pensons par exemple à 3 d’entre elles :
- Microsoft Power BI, anciennement connu sous le nom de PowerPivot, c’est la solution « desktop BI » de Microsoft. Elle est particulièrement puissante, car Microsoft l’a équipé du moteur de sa solution OLAP SSAS (SQL Server Analysis Services). En plus de cela, il bénéficie d’un large panel d’options de visualisation, du VBA et des capacités d’Excel. Pour nous, Microsoft Power BI est la solution Self Service la plus complète et la plus efficace du marché ! (sans aucune publicité de notre part).
- QlikView/QlikSense est une autre très bonne solution Self service qui permet aux utilisateurs de développer des solutions data directement sur leur poste. Ils peuvent déployer ces solutions sur un serveur dédié ou sur leur poste.
- Dataiku : nous ne pouvions pas quitter cette partie sur les technologies self service de Data Lab sans parler de la solution de l’éditeur français du même nom, Dataiku. A la différence de Microsoft Power BI ou Qlik qui sont plus positionné sur la Self-service Business Intelligence, Dataiku est une solution elle, qui est spécifiquement positionné sur le Self-Service Analytics. C’est une plateforme intégrée à toutes les technologies précédentes (Hadoop, Teradata, etc) et aux langages R, Python, qui permet de faire des travaux avancés de Data science directement sur le poste de l’utilisateur métier. C’est un outil qui saura séduire facilement les data scientists dans une équipe métier.
Maintenant que nous avons vu les technologies utilisées dans la construction de Data lab, nous allons conclure cette chronique avec des exemples de concrets de projet de data lab en entreprise.
3 – Quelques exemples de Data Lab
De nombreuses entreprises dans le monde se sont mises à la construction de leur Data Lab. Certaines ont connu plus ou moins de succès. Nous allons prendre 2 cas de succès, 2 entreprises qui se sont lancés dans l’aventure du Data Lab, et qui l’ont construit chacune selon une approche différente.
3.1 – Le Data Innovation Lab d’Axa
Axa fait partie des entreprises qui ont très tôt adopté le concept de Data Lab. Dès 2014, l’entreprise a créé son Data Innovation Lab, un lieu dans lequel elle traite les données relatives à l’assurance automobile. Comme la directrice de l’époque l’indiquait, l’objectif du Lab est de mieux connaitre les clients, mieux prévenir les risques auxquels ils font face, et les aider à prendre les bonnes décisions. Les objectifs de recherche du Data Lab étaient les suivants : fraude, gestion des sinistres, analyse des comportements de conduite pour réduire la prime des conducteurs vertueux, santé connectée, marketing. En fait, l’idée est d’utiliser les données d’assurance pour développer des produits personnalisés et des solutions de prévention. Un exemple de produit issu des analyses faites dans le Data lab serait le lancement d’assurances auto dont le prix changerait selon le comportement du conducteur. Le Data Lab a été lancé à l’époque avec 15 collaborateurs, et aux dernières nouvelles, il en compte plus de 110 aujourd’hui.
3.2 – Le Data Lab RESEAU de la SNCF
SNCF est une entreprise qui de part la nature de ses activités, est appelée à être un hub de données. Selon les informations publiées sur son site, le patrimoine « data » de l’entreprise, c’est les données historiques comme les horaires, les données industrielles archivées de toutes les interventions sur les 15 000 trains, les 30 000 kilomètres de voies, dans les 3 000 gares. Mais ce sont également les données que les clients lui confient à travers les services proposés en gare, et l’expérience à bord (connectivité 3G/4G, Wifi…). Pour valoriser ce patrimoine impressionnant, l’entreprise s’est équipé d’un Data Lab dès 2018. L’objectif pour la SNCF est de fournir un accès à toutes les données de l’entreprise, pas seulement à son personnel, mais également à l’extérieur. Notez qu’à la différence d’Axa, qui est plus dans une logique de centralisation pour favoriser l’expérimentation, la mise en place du Data Lab chez la SNCF est plus dans une démarche d’uniformisation des données afin de les rendre disponibles aux métiers (les agents réseaux), qui pourront eux-mêmes développer des applications de données. Dans cette démarche, un environnement bac-à-sable pourra être mis sur pied pour des utilisateurs d’une unité business, et ceux-ci pourront l’utiliser pour bâtir des applications autour d’un sujet ou cas d’usage. Une fois le développement des applications terminé, celles-ci pourront être consultées par tous les agents. Vous voyez qu’on est là dans la logique « Self service » que nous avons présenté plus haut, et non dans l’approche centralisée ; et vous constaterez également qu’en fonction des objectifs du Lab, l’approche de construction employée n’est pas la même. Le Data Lab de la SNCF est opérationnel depuis 2018, et en 2019, 350 jeux de données avaient été publiées pour consultation et exploitation par les agents.
Nous sommes arrivés au terme de cette chronique. En somme, ce que vous devez retenir c’est que l’intérêt du Data Lab se justifie à partir du moment où une entreprise qui souhaite valoriser ses données grâce aux techniques avancées de data science se retrouve face à des problèmes de silotage de l’information dans ses différents départements. Le Data Lab intervient alors pour uniformiser les données de l’entreprise de façon transverse à toutes les directions métiers. En fonction des objectifs spécifiques de l’entreprise, cette uniformisation ne nécessite pas forcément de se faire dans un lieu physique précis. Il peut aussi se faire de façon décentralisée avec des points d’accès à différentes unités métiers de l’entreprise. L’exemple du Data Lab d’Axa et de la SNCF ont parfaitement illustré cela. Maintenant, c’est à vous de passer à l’action et de bien planifier, car la mise en place d’un Data Lab va presque toujours nécessité un changement organisationnel dans l’entreprise.
Si vous souhaitez vous faire accompagner dans votre projet de Data Lab, n’hésitez pas à nous contacter. Je suis disponible pour vous aider. écrivez-nous sur contact@data-transitionnumerique.com
