- Data
- SEA
- SEO
Table des matières
Table des matières
La Data Science, c’est un peu comme la Rolex à 50 ans. Si tu es une grande entreprise et que tu n’es pas en train de mener un projet IA, tu as un peu raté ta vie. Pourtant, les échecs sont nombreux. Nous vous livrons dans ce troisième article notre vision du cycle de vie d’un projet Data Science.
Data Science, Intelligence Artificielle, Machine Learning… Impossible d’échapper à ces buzzwords du moment. La data est le nouvel or noir et les entreprises veulent leur part du gâteau.
Les grandes organisations se jettent alors à corps perdu dans la bataille et engloutissent des sommes faramineuses… et une bonne partie de leurs illusions.
Comme l’illustre un article du Journal du Net en 2017 au sujet des projets DMP (Data Management Platform), beaucoup d’annonceurs ont préféré faire machine arrière la faute à un manque de données, une organisation interne non préparée voire même une absence de besoin réel !
Les projets de Data Science sont en effet extrêmement risqués et complexes, car leur réussite dépend de nombreux facteurs incertains :
- La véracité des hypothèses de départ ;
- La capacité du projet à casser les silos organisationnels (la donnée est partout et “détenue” par des services qui n’ont pas pour habitude de communiquer) ;
- Un volume de données disponibles pour répondre aux cas d’usages envisagés ;
- Le maintien de la qualité de la donnée dans le temps ;
- La capacité des algorithmes à produire les résultats attendus ;
Face à un tel océan d’incertitude, la seule réponse est d’adopter une démarche itérative et agile qui minimise les risques d’échec et de gouffre financier.
Chez Empirik, nous envisageons le cycle de vie d’un projet de Data Science en 6 étapes :
1. Comprendre & définir
Il s’agit selon nous de l’étape la plus importante du projet. Négligez-la et vous pouvez être sûr que vous aurez jeté l’argent par la fenêtre.
Cela peut paraître tellement évident, mais un projet de Data Science doit être là pour régler un problème !
Il est donc fondamental de passer du temps dans l’organisation, de comprendre ses enjeux business, d’identifier les douleurs des équipes et de recenser les données existantes.
Cette phase de découverte permettra ainsi de définir les cas d’usages marketing prioritaires.
Analyse du contexte et définition des objectifs
Un projet Data Science doit être aligné avec les enjeux business d’une organisation.
Comme nous l’avons décrit dans notre dernier article sur les bénéfices et cas d’usages, nous pensons qu’un projet Data Science peut répondre à un ou plusieurs objectifs stratégiques :
- Optimisation de la performance : augmentation du chiffre d’affaires, réduction des coûts d’acquisition…
- Amélioration de l’expérience client : amélioration de l’indicateur de satisfaction, le NPS (Net Promoter Score), baisse du taux d’attrition (départ client)…
- Gain de temps : rapidité de lancement d’une campagne, économie de temps pour réaliser une action précise…
- Aide à l’analyse et à la décision : vitesse de détection et de résolution d’un problème, fiabilité des prédictions de performance vs les résultats réels…
Cet objectif doit évidemment être SMART (Spécifique – Mesurable – Atteignable – Réaliste – Temporel) afin que le Retour sur Investissement (ROI) puisse être facilement mesuré à la fin de la boucle projet.
Il est également impératif que l’objectif soit formalisé de façon claire et régulièrement communiqué aux acteurs du projet. Les difficultés techniques risquent en effet de rapidement prendre le pas et envoyer aux oubliettes l’objectif principal de la mission. Mais le perdre de vue est le meilleur moyen pour se prendre un mur !
Le choix des objectifs peut être imposé par le donneur d’ordre ou défini à la suite d’entretiens avec les équipes de direction.
Ces échanges peuvent être menés par le data scientist mais aussi par des profils moins techniques qui disposent de bonnes connaissances analytiques et marketing.
Analyse des données existantes
On pourrait dans l’absolu commencer à faire un peu de science-fiction et rêver de cas d’usages qui révolutionneraient votre quotidien.
Mais il nous semble plus prudent de faire un point sur les données existantes. C’est probablement moins glamour mais nécessaire à la réussite du projet.
Le recensement des données permettra en effet de définir et prioriser des cas d’usages réalistes.
Les données à disposition des entreprises sont classées en 3 catégories :
- Données First party : il s’agit des données clients/prospects collectées par l’entreprise (analytics, CRM…).
- Données Second party : il s’agit des données 1st party qu’un partenaire (media par exemple) partage.
- Données Third Party : ce sont des données achetées auprès de brokers spécialisés
Ces données fournissent de multiples informations sur le profil des internautes (catégorie socio-démographique, géolocalisation, centre d’intérêts…) et leurs comportements en ligne (préférences d’achats, sites consultés…).
Ce travail de recensement des données ne peut ignorer les contraintes du RGPD : est-ce que les données ont été collectées après le recueil d’un consentement explicite ? Est-ce que la finalité de traitement est claire…? Autant de points à vérifier en amont et qui peuvent constituer des premiers points de blocage.
Il est enfin possible d’envisager un projet Data Science avec des données qui ne sont pas encore collectées mais le risque est évidemment plus important.
Définition des cas d’usages
Une bonne connaissance des données à disposition permettra ensuite de pouvoir imaginer des premiers cas d’usages d’application.
Pour ce faire, des séances de brainstorming peuvent être organisées entre les équipes métier et le data scientist afin de :
Définir les familles de cas d’usages pertinents par rapport à l’objectif stratégique. Par exemple, si l’objectif stratégique est d’améliorer la rentabilité des investissements digitaux, les familles de cas d’usages peuvent être la réduction des CPA des campagnes payantes ou l’amélioration du taux de conversion.
Réfléchir aux cas d’usages concrets par famille. La personnalisation des messages publicitaires ou d’une landing page selon le profil et le comportement d’un internaute sont des exemples de cas d’usages adaptés aux objectifs stratégiques.
Évaluer chaque cas d’usage selon son impact potentiel sur l’objectif stratégique, la difficulté de mise en oeuvre (qualité des données, complexité des algorithmes, coûts…) et le délai d’obtention des résultats.
Les résultats peuvent enfin restitués sur une matrice de cette forme :
Evidemment, les cas d’usages situés dans le carré en bas à droite sont à privilégier afin d’obtenir un ROI rapide, apprendre, abandonner ou optimiser.
2. Collecter & centraliser
Dès lors que les données nécessaires à la réalisation du projet ont été définies lors de l’étape de compréhension, il faut mettre les mains dans le cambouis pour rechercher les sources de données, les modalités d’accès et définir leur mode de stockage pour une utilisation optimale.
Les sources de données vont être le plus souvent dispersées, silotées, structurées ou non, de qualité variable et utilisant des nomenclatures sans rapport entre elles. Pire, les données nécessaires peuvent ne pas encore avoir été collectées !
De plus, l’accès aux données peut prendre des formes très diverses : accès programmatique (APIs, connecteurs spécifiques), bases de données, tableur, exports de fichiers exotiques en tout genre….
Mise en place des connecteurs
Cette étape va donc être très technique, aussi bien lors de la mise en place des connecteurs pour la récolte que pour le choix des infrastructures de stockage.
Il va donc falloir en premier lieu identifier où et comment récupérer les données voulues. On peut distinguer les données internes et externes.
La présence de base de données existantes en interne peut être un avantage et un gain de temps, mais vous ne couperez pas à un long travail d’analyse de l’existant pour s’assurer que les données soient exploitables. Et dans le cas de données peu structurées, le travail de récupération des données sera plus long, car impliquant de nombreuses étapes intermédiaires pour regrouper des données disparates.
De la même façon, si vous avez l’habitude de stocker vos données internes dans des tableurs dispersés aux quatre coins de votre entreprise, attendez-vous à entendre votre data scientist hurler à la mort.
Un process sera nécessaire pour centraliser les modifications de données et s’assurer de leur intégrité puis automatiser leur stockage. On passera par l’utilisation d’outils et services dédiées [Spark, Hadoop, Dataflow, BigQuery, EMR…], ou par des développements maison.
La connexion à votre CRM, ERP ou tout autre outil dont vous souhaitez extraire les données peut s’avérer chronophage également selon leur possibilités natives d’export et d’automatisation mais également par les structures de données très variables d’un outil à l’autre pouvant rendre la réconciliation très complexe. On utilisera ici les procédures ETL : Extract-Transform-Load permettant de synchroniser les données entre les outils et votre stockage.
Très fréquemment, les données “externes”, provenant d’outils que vous utilisez ou de sources tierces que vous souhaitez interroger (météo, news…) sont accessibles via des API : en clair des points de connexion aux données, mis en place par les développeurs, vous permettant d’accéder programmatiquement à des données constamment mises à jour.
A nouveau, par le développement de routines internes ou l’utilisation de services du cloud, vous pourrez automatiser la récolte et le stockage de ces données. En web-marketing, les exemples les plus frappants sous les outils Google qui proposent tous une API pour faciliter l’accès aux données, Analytics, Search Console, Ads… Les concurrents ne sont bien-sûr pas en reste.
Dans le cas des données encore non-existantes, le data scientist va être amené à déterminer la méthode de récolte (scraping, par exemple), ou l’adoption d’un outil spécifique permettant d’obtenir les données.
Stockage des données
Data lake, data hub, data warehouse, data mart, data-store… Difficile de s’y retrouver dans les subtilités en terme de stockage des données. L’idée sous-jacente restera toujours la centralisation de données disparates pour optimiser l’analyse des données et la prise de décision.
Un data-store va par exemple aller plus loin que la simple base de données et stocker des fichiers, des mails, etc. La data-warehouse va se focaliser sur la centralisation en un seul endroit l’intégralité des données…
Au-delà de ces considérations, il va falloir choisir une infrastructure, un hébergement pour ces données. De nombreux paramètres vont entrer en ligne de compte (sécurité, confidentialité, coût, performance…)
Les acteurs sont nombreux sur le marché, et les approches tout intégrées se multiplient chez les mastodontes de la discipline.
Google (Cloud), Amazon (AWS), Microsoft (Azure) proposent en effet des plateformes offrant des services allant du data-store à la base de données massive, couplées à des possibilités d’automatisation et d’industrialisation des connecteurs de données et permettant l’accès facile à des solutions de Machine Learning (librairies standardisées, utilisation de machines dites “virtuelles” pour exécuter les algorithmes à distance).
3. Fiabiliser & normaliser
Pour s’assurer de l’efficacité des algorithmes et méthodes utilisées lors de l’analyse de données, le data scientist doit passer par une phase de préparation des données.
Certains algorithmes ne vont par exemple accepter que des données numériques alors que d’autres traiteront des données catégorisées. D’autres encore refusent de travailler avec des données manquantes.
Plus prosaïquement, la récolte des données de l’étape précédente ne garantit en aucun cas l’absence de problèmes dans les données (doublons, erreurs, données manquantes, disparité d’intitulés…)
Le data scientist s’attelle donc à la phase la moins excitante, la plus longue du projet. Elle est bien évidemment indispensable et la qualité de la préparation impactera directement la qualité de l’analyse.
Le data scientist va ici commencer à utiliser ses connaissances en SQL (pour manipuler les données en base) et les langages Python et R, principalement, qui proposent des librairies permettant de manipuler, re-traiter, nettoyer des ensembles de données massifs en quelques (dizaines de) lignes de code.
Les actions principales vont consister à :
- Unifier les intitulés disparates pour les normaliser (exemple Google Analytics : traiter l’url avec ou sans slash final comme la même page) ;
- Identifier des données aberrantes (erreur de saisie, outliers) ;
- Traiter les données numériques dans le cas où les échelles de grandeur sont incompatibles (normalisation) ;
- Décider du scénario pour les données manquantes : suppression, remplissage avec données calculées, aléatoires, etc.
- Supprimer les doublons.
L’objectif est bien d’optimiser l’efficacité des algorithmes et les méthodes employées ensuite. En effet, ces méthodes appliquées sur des données non préparées vont présenter des biais qui pourront ensuite fausser l’analyse ou même la rendre impossible.
4. Analyser & apprendre
Ici va entrer en jeu la compétence scientifique de notre ami data scientist.
A la lumière de premières analyses des données préparées et nettoyées, le data scientist va dégager des hypothèses sur les données. Pour donner un exemple simple : une corrélation entre deux indicateurs, ou la présence d’un pattern. Ces hypothèses prennent souvent naissance dès la phase de préparation des données.
Le data scientist peut aussi s’appuyer sur les observations formulées à priori par un expert métier, par exemple un consultant SEA qui pense qu’il y a une forte corrélation entre la météo et le taux de clics de ses campagnes.
Analyse & hypothèses
Avant de formuler puis tester des hypothèses, l’analyse va impliquer la visualisation des données sous des formes variées, la création éventuelle de variables explicatives (features) permettant de synthétiser les données (pour un classique, l’Analyse en Composantes Principales, mais de nombreuses méthodes existent).
Lorsqu’une hypothèse est formulée, le data scientist va décider de la méthode qui semble la plus à même d’y répondre. Classiquement, s’il a identifié une corrélation possible entre deux indicateurs, il envisagera l’utilisation de la régression pour valider l’hypothèse. Il pourra avoir pour but de classer les données en groupe ou en hiérarchie, des algorithmes spécifiques existent alors.
Modélisation
Dans le cas d’application Machine Learning, une préparation des ensembles de données d’apprentissage et de test est nécessaire. On va séparer les données en plusieurs jeux de données dont certains ne seront présentés à la machine qu’après apprentissage, pour valider ses performances.
L’application de l’algorithme envisagé va ensuite à nouveau mobiliser des compétences en développement, Python et R tenant encore le haut du pavé sur ces sujets, mais des alternatives existent (Julia, Scala, ainsi que des langages plus classiques : C++, Java).
On retrouve ici les facilités de développement par la présence de nombreuses librairies éprouvées et testées permettant d’éviter de réinventer la roue et se concentrer sur l’application de l’algorithme sans le recoder intégralement.
Par ailleurs, par souci de performance, les algorithmes peuvent être exécutés à distance sur des machines temporaires hébergées dans le cloud, permettant de disposer à moindre coût d’une puissance de calcul importante, simplement pour un temps limité, réduisant les investissements en terme de matériel.
Il faut en effet noter que toutes ces méthodes sont extrêmement gourmandes en termes de ressources machines. Vous ne ferez pas tourner un algorithme sur des données sérieuses sur votre PC portable.
Évaluation de la performance
Le résultat de l’application de l’algorithme va être un modèle qui va être utilisé sur des données de test pour évaluer la performance à partir du du taux d’erreur, de la proportion de faux-positifs et faux-négatifs. De nombreux indicateurs sont utilisés. L’évaluation de la performance des modèles est une discipline à part entière.
L’hypothèse peut être confirmée si les performances sont jugées satisfaisantes sur le jeu de test, et à condition que les conditions d’apprentissage aient été respectées (Tester un algorithme sur des données qu’il a déjà vu entraînera un score élevé, mais ne permet de prouver aucune hypothèse).
5. Déployer & restituer
Mise en production
Si l’hypothèse est confirmée, elle peut alors être utilisée dans la prise de décision.
On peut donc appliquer le modèle et ses prédictions à des données du monde réel : prédiction du revenu, du trafic d’un site, de l’intérêt d’un utilisateur pour un produit…
Si l’approche industrielle du déploiement va consister à utiliser le modèle sous forme de service web distant, intégré dans des objets connectés ou des smartphones, l’approche la plus appropriée nous semble reposer sur une démarche agile et itérative.
Ainsi, à partir d’une preuve de concept générant un premier modèle, on pourra construire par suite d’itérations simples, un modèle de plus en plus complexe, enrichi par les retours d’expérience, l’analyse des erreurs, l’ajout de nouvelles données…
Data vizualisation et data storytelling
La capacité du data scientist à présenter les résultats de façon claire et pédagogique est au moins aussi importante que sa capacité technique à collecter et à analyser les données.
Cet enjeu de “data-démocratisation” est fondamental si on souhaite que la data irrigue les processus métiers et qu’une organisation passe du statut de “doigt mouillé-driven” à celui de data-driven.
Cet objectif peut s’appuyer sur deux types d’outils :
- La Data-Visualisation qui consiste à représenter de façon visuelle les données sous forme de courbes, histogrammes, camemberts, etc. La Data-Visualisation peut être réalisées sous R/Python ou exploiter des outils de Business Intelligence tels que Google Data Studio, QlikView, Tableau Software ou Power BI.
- Le Data Storytelling désigne la capacité à raconter des histoires à partir des données. Le Data-Storytelling est tourné vers l’utilisateur et présente les résultats de façon visuelle (via la dataviz) mais surtout personnalisé selon le profil et la maturité du destinataire. Le Data- Storytelling est à la dataviz ce que l’UX est au design. Il s’agit d’une discipline émergente avec des outils spécialisés comme Toucan Toco qui se posent en concurrence frontale face aux acteurs classiques de la BI.
6. Enrichir & améliorer
Data-quality & data-governance
Le maintien dans le temps de la qualité de la donnée collectée est évidemment une condition nécessaire à la stabilité et à l’amélioration de la pertinence des analyses.
Cet enjeu de data-quality est une des principales composantes des démarches de data-gouvernance.
La Data governance correspond à l’ensemble des procédures mises en place au sein d’une entreprise afin d’encadrer la collecte de données et leur utilisation selon des contraintes de qualité, de disponibilité, d’intégrité, de sécurité et du respect des contraintes règlementaires (RGPD).
Les enjeux autour de la data-gouvernance ont vu l’émergence des “Chief Data Officers” (CDO), véritables gardiens du temple de la donnée.
Le CDO peut utiliser des outils chargés de “crawler” la donnée et de repérer d’éventuelles incohérences et mettre en place des reportings et baromètres de qualité de la donnée.
Amélioration continue
En terme de modélisation, l’amélioration continue est indispensable via la mise en place d’une boucle de feedback permettant d’améliorer le modèle en fonction de ses résultats dans le monde réel.
De la même façon, le modèle a tout intérêt à continuer à être enrichi, ré-entraîné avec les nouvelles données peuplant votre data-warehouse chaque jour pour affiner encore vos prédictions.
Par exemple si vous avez établi un modèle qui classe un nouvel arrivant en tant que prospect chaud ou froid, vous avez tout intérêt à analyser les résultats, les erreurs inévitables, pour enrichir le modèle par la présentation de nouvelles données, appliquer des correctifs aux paramètres divers de l’algorithme, etc. et obtenir une classification de plus en plus efficace.
Par ailleurs, vous éviterez ainsi plus aisément les biais pouvant survenir lors de l’application aveugle d’un modèle (liés par exemple à un échantillon d’apprentissage trop restreint).
Vous avez aimé cet article sur la data science ? Consultez les deux premiers articles de la série :
