Le coût d’un projet Data Warehouse peut varier de 1 à 100, alors forcément impossible de donner une réponse toute faite. Nous allons vous partager les infos clés à connaître pour comprendre ce qui impacte le coût d’un Data Warehouse : les différents postes de coûts à anticiper, la différence importante à faire entre coût de stockage et coût de computing, batch et streaming de données…
En fin d’article, on a voulu vous présenter le prix des principales solutions data warehouse cloud du marché : BigQuery, Snowflake, Azure, Redshift (mais, spoiler alert, n’oubliez jamais que le coût d’un Data Warehouse ne se réduit jamais au seul coût de la licence…)

L’essentiel à retenir sur le coût d’un Data Warehouse

La création et la gestion d’un data warehouse peuvent être coûteuses pour une entreprise. Ces coûts peuvent varier considérablement en fonction de plusieurs facteurs clés.

• Taille du Data Warehouse. La taille du data warehouse est l’un des principaux facteurs qui influenceant les coûts. Plus il est grand, plus il nécessitera de ressources. Cela implique une augmentation des frais de stockage, des coûts d’acquisition de matériel et de logiciels supplémentaires, et des coûts de maintenance.
• Coût du matériel et des logiciels. Le choix du matériel et des logiciels utilisés pour votre data warehouse est un autre facteur important pouvant affecter votre budget. Les coûts peuvent varier considérablement selon les fournisseurs et les technologies utilisées. Il est donc important de sélectionner le bon fournisseur et la bonne technologie pour répondre aux besoins de l’entreprise.
• Coût de la gestion des données. La gestion des données implique de nombreux coûts dus à la collecte, au nettoyage, à la normalisation et à la sécurité des données. Ces coûts peuvent également inclure les frais d’audit et de conformité réglementaire.
• Coût de la main-d’œuvre. La main-d’œuvre est un autre élément important des coûts associés au développement d’un data warehouse. Les entreprises doivent disposer de personnel qualifié pour configurer, maintenir et mettre à jour le data warehouse. Il faut inclure dans le budget des coûts dus à la formation, au recrutement et aux salaires du personnel.
• Évolutivité. L’évolutivité est un facteur clé à prendre en compte dans la création et la gestion d’un data warehouse. Les entreprises doivent être en mesure de faire face à la croissance continue de leurs données et d’adapter leur infrastructure de données en conséquence. Les coûts peuvent être dus à l’ajout de matériel et de logiciels supplémentaires, ainsi qu’à la mise à niveau de l’infrastructure existante.

En résumé, la création et la gestion d’un data warehouse peuvent être coûteuses pour une entreprise. Ces coûts dépendent de la taille du data warehouse, du choix du matériel et des logiciels, des coûts de main-d’œuvre, de la gestion des données et de l’évolutivité. Les entreprises doivent prendre en compte ces facteurs clés pour anticiper les coûts et déterminer la meilleure stratégie pour la mise en place et la gestion de leur data warehouse.

Estimer le coût du déploiement de votre Data Warehouse

Le coût de la licence

Une composante importante du coût total est la licence d’exploitation. La plupart des fournisseurs proposent une licence annuelle ou pluriannuelle, dont le coût dépend des besoins spécifiques de l’entreprise. Le prix varie en fonction de la taille du data warehouse, du nombre d’utilisateurs, des fonctionnalités nécessaires, la durée de la licence, de la région d’hébergement…

Pour un data warehouse de taille moyenne, le coût d’une licence annuelle s’élève généralement à quelques milliers d’euros. Les frais de maintenance peuvent être inclus dans le coût de la licence, ou facturés séparément. Il est important de noter que le coût des licences peut également varier en fonction du fournisseur.

Il est donc nécessaire de comparer les offres et de choisir un fournisseur qui répond aux besoins spécifiques de l’entreprise, tout en offrant des prix compétitifs et des fonctionnalités adaptées. Certains fournisseurs de plateformes cloud proposent même des programmes de tarification qui permettent de réaliser des économies en fonction de la quantité d’utilisation.

Le coût des outils connexes : ETL, BI…

En plus des coûts de licence et de la plateforme cloud, il faut considérer les coûts des outils supplémentaires nécessaires pour gérer et optimiser le data warehouse et utiliser vos données. Ces outils supplémentaires incluent des outils d’intégration de données pour charger et transformer les données, des outils de gestion des métadonnées, et des outils de BI pour permettre aux utilisateurs de requêter et d’analyser les données.

Le coût de ces outils supplémentaires peut varier là aussi en fonction du fournisseur et de la quantité de données traitées. Par exemple, les outils d’intégration de données peuvent coûter environ 20 000 par an. Les outils de gestion des métadonnées et d’analyse peuvent coûter entre 5 000 et 50 000 dollars par an en fonction de la complexité de l’environnement et du volume de données traitées. Il existe 4 types de facturations principaux que nous vous présentons ci-dessous.

Le coût des ressources humaines

La construction d’un data warehouse peut impliquer des coûts significatifs en termes de ressources humaines. Ces coûts peuvent varier en fonction de la taille et de la complexité du projet, ainsi que du niveau d’expertise technique nécessaire. Voici quelques-unes des ressources humaines qui peuvent être impliquées dans la construction d’un data warehouse :

1. Chef de projet : les responsables de la gestion globale du projet. Il travaille avec les parties prenantes pour comprendre les exigences commerciales, développer un plan de projet et assurer la coordination de l’équipe de projet.
2. Architecte de données : les responsables de la conception du data warehouse, y compris la modélisation de données, la définition de la structure de stockage des données et la conception de l’architecture globale.
3. Analyste de données : ils analyses des données pour identifier les tendances et les modèles. Ils peuvent être nécessaires pour aider à la conception des modèles de données, la rédaction des spécifications et la validation des données.
4. Ingénieur en informatique : ils permettent la mise en œuvre de l’architecture technique du data warehouse. Ils peuvent être nécessaires pour travailler sur la mise en place de bases de données, la configuration de serveurs et la gestion des interfaces de programmation d’applications (API).
5. Testeur : Les testeurs assurent la qualité du data warehouse. Ils travaillent avec l’équipe de développement pour tester les données et les fonctionnalités pour s’assurer qu’elles répondent aux exigences spécifiées.
6. Formateur : Les formateurs sont responsables de la formation des utilisateurs sur l’utilisation du data warehouse. Le coût des formateurs dépend du niveau d’expertise requis et de la méthode de formation choisie. En outre, il est important de considérer les coûts de formation qui peuvent varier en fonction de la complexité du data warehouse et du nombre d’utilisateurs.

En fin de compte, le coût total des ressources humaines nécessaires pour construire un data warehouse dépendra des spécificités de chaque projet. Cependant, il est important de comprendre que la construction d’un data warehouse peut nécessiter une équipe de personnes qualifiées et spécialisées pour garantir un projet réussi qui répond aux besoins commerciaux.

Le coût de la maintenance du Data Warehouse

La maintenance d’un data warehouse est également un coût important à prendre en compte. Cela peut inclure des coûts pour le personnel de maintenance, des mises à jour logicielles, des réparations matérielles, etc.

En résumé, il est important de considérer l’ensemble des coûts liés à la mise en place et à la gestion d’un data warehouse, y compris les coûts de licence, les coûts de la plateforme cloud, les coûts des outils supplémentaires et les coûts de formation. En prenant en compte tous ces facteurs, les entreprises peuvent élaborer un budget réaliste pour leur projet de data warehouse et s’assurer que leur investissement est rentable.

Comprendre la facture de votre Data Warehouse

Le prix du stockage

La première composante de la facture de votre data warehouse est le prix du stockage. Ce coût du stockage dépendra de plusieurs facteurs, notamment la quantité de données stockées, la fréquence d’accès aux données, le type de stockage utilisé, etc. Le stockage peut être effectué en interne, en utilisant des disques durs, ou via un stockage en cloud, en utilisant des services de stockage tels que Amazon S3, Google Cloud Storage ou Microsoft Azure Blob Storage. Le site Light IT propose une analyse détaillée des différents providers clouds.

Si vous optez pour un stockage en cloud, les coûts seront souvent basés sur la quantité de données stockées et la fréquence d’accès aux données. Les fournisseurs de cloud peuvent également facturer des coûts supplémentaires pour les opérations de lecture et d’écriture, les transferts de données et les frais de gestion. En revanche, si vous optez pour un stockage en interne, vous devrez prendre en compte les coûts de l’achat de disques durs, de la maintenance, de l’espace physique nécessaire, etc.

Les frais de stockage peuvent varier en fonction de la quantité de données stockées et du type de stockage utilisé. Pour un stockage cloud, les coûts peuvent varier de 20 à 25 dollars par téraoctet par mois. Pour un stockage sur site, les coûts incluent d’abord la mise de départ, qui débute à 3 500 $. Les coûts mensuels peuvent varier, et inclus l’électricité, la maintenance… Ils peuvent dépasser les 1 000 $ par mois.

Le prix des ressources de calcul (compute)

La deuxième composante de la facture de votre data warehouse est le prix des ressources de calcul. En effet, le traitement des données nécessite souvent des ressources de calcul importantes pour effectuer des requêtes complexes et générer des rapports.

Le coût des ressources de calcul dépendra de plusieurs facteurs, notamment la quantité de données à traiter, la complexité des requêtes, la fréquence d’exécution des requêtes, etc. Les ressources de calcul peuvent être fournies par des serveurs internes ou des services de cloud computing tels que Amazon EC2, Google Compute Engine ou Microsoft Azure Virtual Machines.

Si vous optez pour un service de cloud computing, les coûts seront souvent basés sur la quantité de ressources utilisées, la durée d’utilisation, la complexité des requêtes et les frais de gestion. Les fournisseurs de cloud peuvent également proposer des options de tarification à la demande ou réservées, qui peuvent permettre de réduire les coûts. En revanche, si vous optez pour des serveurs internes, vous devrez prendre en compte les coûts de l’achat de serveurs, de la maintenance, de l’espace physique nécessaire, etc.

En résumé, le coût des ressources de calcul est une composante importante de la facture de votre data warehouse. Il est important de comprendre les coûts associés à chaque option de traitement disponible et de déterminer celle qui convient le mieux aux besoins de votre entreprise.

La tendance moderne : la décorrélation du stockage et du compute

La tendance moderne en matière de data warehouse est la décorrélation du stockage et du compute. Cette tendance permet de séparer la gestion du stockage des données de la gestion du traitement de ces données, deux tâches distinctes qui peuvent être effectuées de manière indépendante. La décorrélation de ces tâches permet de traiter les données sans avoir à les déplacer vers un emplacement centralisé, ce qui peut être bénéfique en termes de coûts et de performances.

Cette tendance se manifeste souvent par l’utilisation de services de cloud computing tels que Amazon Redshift, Google BigQuery ou Microsoft Azure Synapse Analytics. Ces services offrent une séparation du stockage et du traitement, ce qui permet d’optimiser les coûts en payant uniquement pour les ressources de traitement nécessaires. En effet, avec cette approche, le stockage des données peut être effectué dans un emplacement centralisé et économique, tandis que le traitement peut être effectué de manière distribuée et à la demande, en fonction des besoins de l’entreprise.

Batch VS Streaming

Le quatrième point à considérer est le choix entre le traitement par lot (batch) ou le traitement en continu (streaming) des données.

Le traitement par lot est le traitement de grands volumes de données en une seule fois, généralement sur une période donnée, comme une journée ou une semaine. Cette approche est souvent utilisée pour des tâches d’analyse historique ou de génération de rapports réguliers, qui n’ont pas besoin d’une réponse en temps réel. Le traitement par lot peut être moins coûteux que le traitement en continu, car il peut être effectué en dehors des heures de pointe et ne nécessite pas de ressources en continu.

En revanche, le traitement en continu est le traitement de données en temps réel, au fur et à mesure de leur arrivée. Cette approche est souvent utilisée pour des tâches qui nécessitent une réponse en temps réel, comme la surveillance des données, les alertes et les notifications. Le traitement en continu peut être plus coûteux que le traitement par lot, car il nécessite des ressources en continu.

Le choix entre le traitement par lot et le traitement en continu dépendra des besoins de votre entreprise. Si vous avez besoin d’analyser de grands volumes de données historiques de manière régulière, le traitement par lot peut être une option plus économique. Si vous avez besoin d’une réponse en temps réel, le traitement en continu peut être plus approprié. Il est important de noter que certains services de data warehouse proposent des options hybrides combinant le traitement par lot et le traitement en continu. Ces options peuvent être utiles pour les entreprises qui ont besoin de répondre à des besoins variés.

Structure de prix des principaux Data Warehouses du marché

Tableau de synthèse

Google BigQuery

BigQuery est un data warehouse basé sur le cloud qui fait partie de la Google Cloud Platform. L’un des principaux avantages de BigQuery est son modèle de tarification « pay-as-you-go », qui permet aux utilisateurs de ne payer que pour les ressources informatiques qu’ils utilisent. Il s’agit donc d’une option rentable pour les entreprises de toutes tailles. BigQuery propose également des tarifs forfaitaires pour les clients qui souhaitent une tarification mensuelle prévisible.

BigQuery offre plusieurs fonctionnalités qui en font un outil puissant pour l’analyse des données, notamment la prise en charge du langage SQL et le flux de données en temps réel. Il s’intègre également à d’autres services de Google Cloud Platform, tels que Google Cloud Storage, Dataflow et Dataproc. En outre, BigQuery offre plusieurs fonctions de sécurité, de contrôles d’accès et d’audit. Il est également conforme à plusieurs normes et réglementations du secteur, telles que SOC 2, HIPAA et GDPR.

Dans l’ensemble, le modèle de tarification « pay-as-you-go » de BigQuery, ses puissantes fonctionnalités et sa sécurité robuste en font un choix populaire pour l’entreposage et l’analyse de données dans le cloud. Son intégration avec d’autres services de Google Cloud Platform le rend facile à utiliser et offre une expérience utilisateur simple.

Snowflake

Snowflake est un data warehouse moderne basé sur le cloud qui offre une architecture distincte pour le stockage de masse et le calcul. Il propose une variété de fonctionnalités pour la gestion, l’analyse, le stockage et la recherche de données. L’un des principaux avantages de Snowflake est qu’il offre des ressources informatiques dédiées, ce qui garantit de meilleures performances et des temps de traitement des requêtes plus rapides. Ce datawarehouse est strcturé en 3 couches :

Snowflake propose plusieurs modèles de paiement, dont le stockage à la demande et le stockage de capacité, qui sont basés sur la quantité de données stockées dans l’entrepôt. En outre, il existe quatre modèles de tarification qui offrent différents niveaux de fonctionnalité : Standard, Enterprise, Business Critical et Virtual Private Snowflake.

• Le modèle Standard offre les fonctionnalités de base de l’entrepôt de données, notamment le stockage, le traitement et l’interrogation des données. Ensuite, le modèle Enterprise comprend des fonctionnalités avancées telles que le partage de données, le voyage dans le temps et l’échange sécurisé de données.
• Le modèle Business Critical est conçu pour les charges de travail critiques et offre des fonctionnalités supplémentaires telles que le clonage sans copie et l’échange de données accéléré.
• Enfin, le modèle Virtual Private Snowflake offre un environnement dédié et isolé aux clients qui exigent une sécurité et une conformité maximales.

Dans l’ensemble, les modèles de tarification flexibles et les ressources informatiques dédiées de Snowflake en font un choix populaire pour les besoins d’entreposage de données modernes. La plateforme offre une gamme de caractéristiques et de fonctionnalités qui peuvent répondre aux besoins des entreprises de toutes tailles et de tous secteurs, des startups aux grandes entreprises.

Amazon Redshift

Amazon Redshift est un entrepôt de données basé sur le cloud qui fait partie de la plateforme Amazon Web Services (AWS). Il s’agit d’une solution évolutive et entièrement gérée pour l’entreposage et l’analyse de données.

Redshift utilise un format de stockage et une architecture de traitement massivement parallèle qui lui permet de traiter rapidement et efficacement de grands ensembles de données. Il offre plusieurs fonctionnalités qui en font un outil puissant, notamment l’intégration avec d’autres services AWS tels que S3, Lambda et Glue. Redshift offre également plusieurs fonctionnalités de sécurité et la conformité à plusieurs normes et réglementations sectorielles telles que SOC 2, PCI DSS et HIPAA.

L’un des principaux avantages de Redshift est sa compatibilité avec un large éventail d’outils de BI et d’analyse, notamment Tableau, Power BI et Looker. Cela permet aux entreprises d’intégrer facilement Redshift dans leurs flux de travail analytiques existants.

Redshift propose plusieurs modèles de tarification, notamment la tarification à la demande, qui permet aux utilisateurs de ne payer que pour les ressources qu’ils utilisent, et la tarification des instances réservées, qui offre des réductions importantes aux clients qui s’engagent à utiliser Redshift pendant une certaine période. En outre, Redshift offre un éventail de types de nœuds, allant des petits nœuds avec quelques téraoctets de stockage aux grands nœuds avec des pétaoctets de stockage.

Dans l’ensemble, l’évolutivité de Redshift, sa flexibilité tarifaire et sa compatibilité avec les outils d’analyse les plus courants en font un choix populaire pour l’entreposage de données et l’analyse dans le cloud. Son intégration avec d’autres services AWS et sa conformité aux normes de l’industrie en font une solution sûre et fiable pour les entreprises de toutes tailles.

Microsoft Azure

Azure Synapse Analytics, anciennement connu sous le nom d’Azure SQL Data Warehouse, est une solution d’entreposage de données basée sur le cloud proposée par Microsoft Azure. Il s’agit d’un service entièrement géré et hautement évolutif qui s’intègre à d’autres services Azure et offre de bonnes performances sur de grands ensembles de données.

L’un des principaux avantages d’Azure Synapse Analytics est sa capacité à traiter des données structurées et non structurées, y compris des données provenant d’Azure Data Lake Storage. Il offre plusieurs options de tarification, notamment le paiement à l’utilisation, le calcul provisionné et les instances réservées, ce qui permet aux clients de choisir le modèle qui correspond le mieux à leurs besoins.

Azure Synapse Analytics permet l’intégration avec d’autres services Azure tels qu’Azure Data Factory, Azure Stream Analytics et Azure Databricks. Un autre avantage de ce data warehouse est son intégration avec Power BI, qui permet aux entreprises de créer facilement des tableaux de bord et des rapports interactifs pour mieux comprendre leurs données. Il prend également en charge plusieurs langages de programmation, notamment SQL, .NET et Python, ce qui le rend flexible et facile à utiliser pour les data scientist et engineer.

Dans l’ensemble, Azure Synapse Analytics est une solution puissante et flexible pour l’entreposage de données et l’analyse dans le nuage. Son intégration avec d’autres services Azure et sa compatibilité avec les outils d’analyse les plus courants en font un choix populaire pour les entreprises de toutes tailles. Ses options tarifaires et ses fonctions de sécurité en font une solution rentable et sûre pour la gestion et l’analyse de grands ensembles de données.

La gestion des coûts est un élément crucial lors de la mise en place d’un data warehouse pour les entreprises. Il est important de comprendre les différents postes de coûts associés à la construction, l’hébergement et la maintenance.

Les entreprises doivent choisir la bonne plate-forme de data warehouse en fonction de leurs besoins spécifiques, en tenant compte des coûts de licence, des frais de gestion et des coûts de stockage et de traitement des données.

Les options de pricing flexibles offertes par les fournisseurs de cloud computing peuvent aider les entreprises à s’adapter à l’évolution de leurs besoins en matière de données et à maîtriser leurs dépenses. En somme, une planification minutieuse, une évaluation des coûts et un choix judicieux de plate-forme peuvent aider les entreprises à améliorer leur efficacité et leur rentabilité en matière de gestion de données.

Les entreprises qui veulent s’équiper d’un logiciel CRM ont tendance à faire l’erreur de se concentrer, dans les appels d’offres, sur l’étude et la comparaison des fonctionnalités. C’est négliger un élément déterminant : le modèle de données.

Le modèle de données conditionne en grande partie ce que vous allez pouvoir faire avec votre CRM.

En deux mots, le modèle de données décrit la manière dont vos informations clients sont organisées dans la base de données du CRM. La majorité des CRM proposent (imposent) un modèle de données fermé, ce qui signifie que vous n’allez pas pouvoir ajouter de nouvelles tables, créer tous les types d’attributs que vous voulez, construire toutes les relations entre objets que vous imaginez. Cela peut être très contraignant et compromettre la mise en oeuvre de certains de vos cas d’usage.

Nous allons revenir dans cet article sur la définition d’un modèle de données CRM et vous présenter les 3 principales approches utilisées par les éditeurs CRM. Nous terminerons par quelques conseils pour vous aider à choisir le modèle de données le plus approprié à votre besoin.

Qu’est-ce qu’un modèle de données en CRM ?

Tout d’abord, il est nécessaire de rappeler qu’un CRM est avant tout une base de données permettant de gérer des interactions avec des clients, d’envoyer des emails et, notamment en B2B, de collecter, organiser et analyser des données sur les clients. Cependant, l’organisation de la base de données du CRM est sensiblement différente selon le type d’activité : B2C ou B2B. Malgré cela, le socle d’un CRM reste une base de données constituée de tables, de façon similaire à un fichier Excel avec des onglets.

Néanmoins, et contrairement à un fichier Excel, l’utilisateur n’a pas toujours la possibilité de créer ses propres onglets et bénéficie de moins de flexibilité quant à l’organisation des données. Cette organisation prédéfinie des données et la manière dont les données sont organisées dans un CRM correspond à ce que l’on appelle un “modèle de données”. L’éditeur du CRM fixe ce modèle de données, même s’il laisse parfois une certaine souplesse et quelques marges de manœuvre.

Le modèle de données du CRM est la structure fondamentale sur laquelle les données sont stockées et organisées. Plus ou moins souple et plus ou moins rigide, il permet aux entreprises de mieux comprendre leurs clients et leurs besoins, et leur fournit les informations nécessaires pour améliorer leurs produits et services, ou pour créer des profils détaillés de leurs clients. Ces profils peuvent être utilisés pour cibler les clients et leur offrir des produits et services plus adaptés à leurs besoins.

Ce modèle de données est composé de plusieurs éléments différents, tels que les personnes, les objets, les événements et les relations entre ces éléments. Ces éléments sont liés entre eux par des liens qui peuvent être définis par l’utilisateur dans le cas d’un système souple. Ces liens peuvent ensuite être analysés pour fournir des informations précieuses sur les clients et leurs achats. Concrètement, le modèle de données est constitué de différentes tables qui sont liées d’une certaine manière, selon certains schémas. On y trouve souvent, par exemple :

• Une table contacts,
• Une table achats,
• Une table organisant les données d’interactions sur le site web.

L’organisation des données est un sujet critique dans un CRM, bien que fréquemment négligé. En effet, la capacité à organiser les données détermine la flexibilité dont l’utilisateur disposera pour segmenter et trier les informations.

Les 3 principales approches de modèle de données CRM

Il existe 3 principaux types d’approches pour structurer le modèle de données au sein d’un CRM.

L’approche multi-tables “fermée”

L’approche multi-tables « fermée » est la plus courante, et on peut la retrouver sur la plupart des éditeurs CRM. C’est un modèle multi-tables, ce qui signifie que le modèle ne repose pas sur une table unique avec les contacts, mais intègre aussi un certain nombre de tables supplémentaires, contenant par exemple les achats, les tickets de caisse, les boutiques… Dans ce modèle, les tables sont prédéfinies par l’éditeur CRM. On ne peut pas créer de nouvelles tables, et en cela, c’est un modèle “fermé”.

Ainsi, dans un modèle CRM classique pour du B2B, les tables seront constituées de leads, d’entreprises, de clients, de factures et d’interactions. Dans un modèle B2C, les tables seront constituées de contacts, de commandes, de tickets de caisse, de boutiques et d’interactions. Cependant, l’utilisateur n’a pas la possibilité de créer de nouvelles tables et doit donc se contenter des tables pré-existantes. Il n’est par exemple pas possible de créer une nouvelle table “Abonnements” afin gérer des données d’abonnement. Il faut nécessairement considérer les abonnements comme des commandes, et ceux-ci apparaîtront alors dans la table « Orders ».

De la même manière, les « avis clients » entreront dans la table des interactions, au même titre que les autres événements sur le site web (pages vues, etc.). L’utilisateur est ainsi obligé de s’adapter au modèle de données rigide du CRM.

L’approche multi-tables “ouverte”

Ce modèle permet de créer de nouvelles tables d’une manière similaire à la création de nouveaux onglets dans un tableau Excel. Il est théoriquement possible d’ajouter n’importe quel type de table pour ensuite les organiser d’une façon personnalisable. Actito est un exemple d’éditeur proposant ce modèle ouvert, permettant à l’utilisateur de créer de nouvelles tables dans son modèle de données, depuis le Datamart Studio.

Dans les faits cependant, il n’est pas toujours possible de créer toutes les tables que l’on souhaite. Il est même parfois impossible de les relier entre elles de la façon désirée ou d’ajouter des champs calculés dans les nouvelles tables. Les modèles “ouverts” ne sont donc pas toujours aussi complets qu’il pourrait sembler. Or, lors de la sélection d’un CRM, l’un des principaux éléments à analyser au moment de l’appel d’offres est justement le degré d’ouverture du modèle.

L’approche event-centric

Cette approche a été popularisée il y a une dizaine d’années, notamment par des éditeurs comme Segment ou Klaviyo, Sendinblue… L’idée fondamentale derrière ce type de modèle de données est qu’il n’est pas nécessaire d’avoir une multitude de tables pour représenter tout un business model.

Toute interaction peut être représentée par un événement. Dans la base de données, chaque interaction est associée à une date et contient certaines propriétés. L’intérêt majeur de cette approche est que les propriétés des événements n’ont pas besoin d’être définies à l’avance. Par exemple, il est possible de créer un event nommé “vue produit” et faire en sorte que les attributs de l’événement soit le nom du produit, son prix, sa catégorie, sa couleur.

Le modèle event-centric associe donc des contacts à des événements. Le modèle de données correspond alors à une table de contacts avec l’ensemble des événements associés à chaque contact. Ces événements peuvent avoir une structure différente selon l’event. De plus, il est possible de s’appuyer sur les propriétés de l’événement avec plus ou moins de fonctionnalités selon l’éditeur logiciel.

Ce que rend possible l’approche event-centric

La plupart des logiciels permettent par exemple de réagir aux événements en mettant en place des scénarios prédéfinis. Ainsi, l’entrée d’un event type A dans la base de données entraine le déclenchement d’une action. Cette action peut elle-même être modifiée selon les propriétés X ou Y de l’event A. Par exemple, une demande de devis par un client entraîne automatiquement une première prise de contact, par SMS ou par email selon le choix du client. Certains CRM plus avancés permettent d’utiliser les propriétés des événements comme variables de personnalisation dans un template avec un important niveau de granularité.

De plus, ces events peuvent servir de fondement pour la segmentation client. Là encore, l’efficacité du CRM pour cette fonctionnalité varie grandement selon l’éditeur. Des éditeurs très matures tels que Braze sont vraiment excellents et vont permettre de réaliser des segmentations sur n’importe quelle propriété de tous les événements. Il est par exemple possible de développer un segment en sélectionnant tous les clients ayant consulté un produit d’une catégorie A avec la couleur XYZ. Il est même possible d’actualiser ces segments selon une temporalité pré-définie.

Notez aussi que les acteurs qui ont une approche event-centric comme Klaviyo ont aussi souvent une autre approche supplémentaire. Cela permet principalement de récupérer le catalogue produit qui est extrait depuis un PIM ou depuis un CMS.

Conseils pour choisir le modèle de données CRM le plus pertinent

Les 3 types de modèles définis ci-dessus offrent chacun un certain nombre d’avantages et d’inconvénients. Comme pour toute autre brique du SI, le choix mal avisé d’un outil peut avoir des conséquences très néfastes et à long terme pour votre entreprise. Dès lors, il faut s’assurer que le CRM que vous choisissez repose sur un modèle de données pertinent pour votre activité.

Simplicité Vs Flexibilité

Essentiellement, le choix consiste en un dilemme entre simplicité du CRM et flexibilité du modèle de données. Plus le modèle de données est figé et prédéfini, plus il sera simple d’utiliser le CRM et de travailler avec la base de données. Cependant, cette simplicité au sein du logiciel peut trouver de nombreuses limites dans les cas d’usages de l’entreprise. Un modèle fermé peut être extrêmement éloigné des besoins d’une entreprise au business model complexe. L’entreprise a alors intérêt à se tourner vers un modèle plus souple. On peut ainsi résumer ce dilemme dans un graphique en deux dimensions :

Puisque le modèle en multi-table fermé est contraint par de nombreuses limites, la mise en place d’un modèle « event-centric » pourrait paraitre comme une bonne solution par défaut qui couvrirait les besoins supplémentaires qui pourraient apparaitre avec le temps. Cependant, adopter une telle solution peut nécessiter de mettre en place une CDP (Customer Data Plateform) en amont, et de revoir son dispositif data. Cela représente donc de nombreuses exigences et implique de nombreux efforts – inutiles si cela ne répond pas à un besoin réel de l’entreprise.

Comment procéder pour choisir son modèle ?

Pour savoir quelle approche est la plus pertinente dans votre métier, il faut alors partir de vos besoins. Vous pouvez suivre cette liste d’étapes pour définir le modèle vous correspondant le mieux :

• Lister les “Entités” sur lesquels vous aurez besoin de segmenter.
• Lister des exemples de segmentation :
• Lister les variables dont vous aurez besoin pour vos principaux scénarios / campagnes.
• Demander à l’éditeur d’expliquer comment vos exemples peuvent être réalisés avec sa solution OU essayer de le faire vous-même.
• Anticiper le travail de préparation de données qui peut être nécessaire, notamment dans un modèle event centric qui suppose.

Une fois ce travail de reflexion fait, vous pouvez comparer vos besoins aux fonctionnalités proposées par les éditeurs de CRM. Il ne s’agit pas seulement de prendre en compte les informations nécessaire au suivi de l’activité, mais aussi d’inclure les variables dont vous aurez besoin pour vos différentes campagnes CRM ou marketing. Après avoir défini clairement ces éléments, vous devez vous informer quant au travail de transformation nécessaire pour les intégrer dans le CRM.

Le niveau de complexité de ce travail varie grandement. Il est parfois indispensable de transformer certaines informations en objets JavaScript dans le cadre de modèle de données event-centric. En utilisant conjointement un CRM efficace et un pipeline de transformation des données, il est possible de réaliser un très grand nombre de tâches. Il est toutefois nécessaire d’avoir suffisament prévu ces use-cases en amont et d’avoir anticiper toutes les difficultés majeures.

En définitive, il faut donc précisement définir ses besoins pour choisir un CRM au modèle de données capable d’y répondre. Cela permet aussi d’éviter des manipulations et des transformations complexes des données et du SI qui seraient inutiles l’entreprise. Négliger la phase de réflexion peut s’avérer coûteux et très pénalisant pour votre activité.

Le CRM a longtemps constitué le pivot du SI Client, avant que les Customer Data Platforms viennent changer le jeu dans les années 2015. Aujourd’hui, une nouvelle approche s’impose, plus souple, souvent moins coûteuse également, mettant au centre du SI Client le Data Warehouse. Nous allons retracer ensemble l’évolution des architectures IT utilisées par les entreprises pour collecter, stocker, transformer et exploiter les données clients.

Si le SI Client a toujours été un ensemble plus ou moins connecté d’outils, de bases de données et de fichiers, la manière d’organiser ces différentes composantes au service du stockage, du traitement et de la valorisation des données a beaucoup évolué.

Le SI client a une double fonction qui offre deux 2 leviers d’actions :

• La fonction d’activation : Un SI Client sert in fine à animer une relation clients efficace à travers une variété d’outils de la grande famille du « CRM » (dans lequel on inclut le marketing automation, le helpdesk…).
• La fonction décisionnelle : Le SI Client sert également à mieux connaître ses clients (grâce aux données), à générer de la connaissance client, à faire des analyses, de la BI…

Révolution digitale : des solutions monolithiques aux écosystèmes

La révolution digitale qui s’est opérée il y a une bonne vingtaine années a fait évoluer de manière significative l’organisation du SI Client. Il y a une véritable scission entre l’avant et l’après.

1995 – 2010 = Une solution monolithique pour gérer une relation clients principalement offline

À partir du milieu des années 1990 jusqu’au milieu/fin des années 2000, les logiciels CRM sont la clef de voute du SI Client, et parfois même l’unique composante de ce système. Le logiciel CRM sert à centraliser toutes les données collectées sur les clients. À l’époque, les CRM n’avaient pas la légèreté des outils type SaaS d’aujourd’hui, ils étaient assez lourds et peu flexibles. Les principaux éditeurs de ces logiciels étaient Salesforce, Siebel, SAP, Oracle… De véritables mastodontes qui commercialisaient des solutions très onéreuses. Les coûts liés à ces solutions étaient élevés : coût de la licence logiciel bien sûr, mais aussi et surtout un coût élevé d’implémentation et de maintenance.

De ce fait, les outils CRM ont d’abord été réservés aux plus grandes entreprises, et présentaient de nombreuses limites :

• Faible flexibilité : Difficile à adapter aux besoins spécifiques de l’entreprise et proposant peu d’intégrations à des outils tiers.
• Faible accessibilité : Installés localement, ces logiciels n’étaient pas accessibles en dehors de l’entreprise. On parle ici de logiciels “On Premise”, installés sur les serveurs de l’entreprise, à l’opposé de l’approche moderne basée sur le cloud et le modèle SaaS.
• Pas de gestion des données online : données comportementales, web, trafic, etc.
• Faible collaboration : pas ou peu de fonctionnalités de partage de données.
• Principaux acteurs formant un oligopole : Siebel, SAP, Oracle…

2010 – Aujourd’hui = Multiplication des outils et montée en puissance de l’approche “Best of Breed”

La multiplication des outils MarTech / Data Tech

Au cours de la dernière décennie, le nombre d’outils MarTech & DataTech a augmenté de plus de 6 000 % ! On assiste en parallèle de ce développement à une diversification importante du marché des technologies CRM & Marketing. Il y a désormais près de 10 000 solutions stables sur le marché, chacune proposant ses spécificités. Le site Chief Martec présente une étude approfondie de l’évolution de ces outils depuis les années 2010.

Une nouvelle approche du SI Client

Grâce à cette multiplication des services, l’approche moderne consiste à présent à construire son SI Client à partir de briques outils modulaires et spécialisées sur un type de relation ou de support d’interaction. On peut ainsi citer :

• Les CRM Marketing, aussi appelés plateformes de “Marketing Automation” pour gérer la relation clients digital : campagnes marketing, scénarios relationnels sur les points de contact digitaux.
• Le CRM Commercial pour gérer la relation clients offline, surtout utilisé en B2B. Le CRM Commercial permet d’historiser les échanges avec les prospects et les clients, de centraliser toutes les infos sur les clients dans des fiches clients.
• Les logiciels de Helpdesk qui sont utilisés par le service client, par les conseillers, et qui permettent de gérer les tickets clients, les demandes et réclamations…

Il existe de nombreux autres cas d’usages tels que les plateformes publicitaires, des logiciels e-commerce, des plateformes de gestion des réseaux sociaux, etc.

Les nouveaux défis technologiques

L’organisation des SI clients autour d’une multiplicité d’outils a fait apparaitre de nouveaux défis technologiques :

• Une dissémination de l’information : les données ont tendance à être éparpillées à travers les différents outils et bases de données de l’entreprise. Il n’y a plus de vision globale ni de lieu de centralisation des données.
• Un challenge : l’unification des données clients. Ce sujet est de plus en plus prégnant dans les structures SI, et représente la clef d’une exploitation efficace des données clients.

2010 – 2015 : Le CRM comme base clients principale

Durant la première moitié des années 2010, la tendance était d’utiliser le logiciel CRM comme base de données clients principale. Le CRM s’est ainsi imposé comme plateforme pivot du SI Client. Pour autant, utiliser un même outil en tant que base de données et logiciel d’activation ne fait plus nécessairement sens aujourd’hui et peut même complexifier le SI clients.

Description du SI Client CRM-centric

Les différentes sources de données (e-commerce, ERP, Google Analytics, magasins, etc.) viennent alimenter le logiciel CRM via un outil “ETL” (Extract – Transform – Load) qui permet de gérer les flux et d’intégrer les données au bon format. Ce processus permet de centraliser les données clients dans le CRM. Elles sont ensuite exportées vers les outils d’activation (emailing, marketing automation…) par APIs ou via des connecteurs natifs développés par les éditeurs.

En parallèle, les sources de données clients sont également chargées, toujours via un ETL, dans un data warehouse, un entrepôt de données qui permet d’organiser les données dans des tables. Le data warehouse n’a alors qu’une fonction : il sert à faire de la Business Intelligence, à créer des reportings grâce à des outils directement connectés au data warehouse.

Les limites de l’approche CRM-centric

Alors que l’utilisation des CRM comme bases de données est encore très présente dans les entreprises, de nombreuses limites à cette pratique apparaissent. Nous avons traité ce sujet de façon exhaustive dans notre article CRM vs CDP. En résumé, voici les principales limites de cette approche :

• Les CRM imposent un modèle de données rigide.
• Le CRM gère mal les données comportementales web et ne peut donc pas raisonnablement être utilisé comme référentiel client.
• La réconciliation multi-sources est complexe, voire impossible, ce qui exige souvent de dupliquer des données.
• Les fonctionnalités de normalisation et de nettoyage des données sont rares et peu efficaces.
• Il n’est pas possible de créer des champs calculés et des scorings dans un logiciel CRM.
• Il n’est pas possible d’utiliser la BDD clients du CRM pour créer des reportings et faire de la BI.

Ces deux derniers points conduisent à une gestion complexe de la data : il existe désormais 2 sources de vérité, 2 bases de données clients qui ne sont pas gérées par les mêmes équipes :

• Le CRM qui sert pour l’activation (utilisé par le marketing, les commerciaux, le service client).
• Le Data Warehouse qui sert à faire de la Data Analysis (utilisé par l’équipe IT / data).

À partir de 2015 – La montée en régime des Customer Data Platforms

C’est en 2015 qu’apparait une nouvelle famille d’outils : les Customer Data Platforms (CDP). Il s’agit de plateformes qui permettent d’ingérer facilement toutes les données (online et offline) de l’entreprise et de les unifier afin de créer des agrégats que l’on peut ensuite synchroniser dans les outils d’activation (marketing – ventes – service client – publicité). Entre 2015 et 2020, la CDP apparaît comme la solution miracle pour unifier toutes les données clients.

Description du SI Client CDP-centric

Les CDP sont des logiciels Saas prêts à l’emploi et à être intégré à votre dispositif data marketing actuel. Ils reposent sur des briques fonctionnelles pré-construites qui facilitent le déploiement et permettent une prise en main rapide par les équipes métiers. Les CDP offrent ainsi une réponse à la problématique de la réconciliation des données clients. En clair, il s’agit d’une vue d’ensemble, qui relie toutes les informations relatives à un client donné. Cette vision à 360° de vos clients vous permet de contrôler la pression marketing et vos échanges.

Vos données clients sont donc centralisées, normalisées, enrichies et ce, continuellement. En synchronisant les données évoquées en temps réel (ou presque), une CDP vous permet d’accéder à une vision exhaustive et à jour de vos clients. Une Customer Data Platform ne se contente pas d’ingérer des données, mais les restructure, ajoute des champs calculés tels que des tendances ou des modèles de scoring, puis les rend exploitables par vos autres outils et systèmes à travers des segments ou des agrégats.

Les limites de l’approche CDP-centric

Les CDP ont été un temps la promesse d’une révolution dans le SI clients. Cependant, des limites à cette approche ont très rapidement fait leur apparition. Nous détaillons les avantages et inconvénients des CPD dans cet article. Voici les principales limites que nous trouvons aux CDP.

• Tout d’abord, il apparait clairement que les Customer Data Platforms ne sont pas des plateformes mais en réalité des suites de logiciels qui consitituent un environnement rigide.
• Les CDP ne sont pas des sources de vérité unique, mais un point de convergence de différentes sources. Cela peut conduire à des contradictions lors de requêtes, comme l’apparition de multiples points de contact pour un client.
• La promesse de développer un software qui s’intègre dans la stack data et qui s’utilise sans avoir besoin de faire recours aux fonctions IT de l’entreprise n’a pas pu être tenue et constitue finalement un challenge supplémentaire pour les équipes marketings.
• Les CDP ne sont pas des outils flexibles. Ils imposent leurs modèles de données et ne laissent que peu de marges de manœuvre dans la personnalisation de la plateforme.
• Les CDP sont des solutions coûteuses.

Ces limites font qu’il est aujourd’hui bien plus pertinent d’adopter une approche se concentrant sur les Data Warehouse.

Pourquoi le SI client moderne doit être “Data Warehouse centric”

Description du SI Client Data Warehouse-centric

Historiquement, le data warehouse est une base de données qui regroupe les informations nécessaires aux analyses. Ces solutions devaient pouvoir supporter des requêtes ponctuelles, mais volumineuses, avec un rythme de mise à jour modéré. Désormais, les data warehouses modernes peuvent supporter tout type de requêtes, en quasi-temps réel, à un prix beaucoup plus compétitif et sans effort de maintenance. C’est d’ailleurs parce que la datawarehouse moderne a pris une telle importance qu’Octolis a centré son offre autour de ce sujet. Octolis permet ainsi d’utiliser les données du data warehouse pour les cas d’usage opérationnels et de créer à partir de là une vision client 360.

La nouveauté majeure concernant les datawarehouse est l’irruption des data warehouse cloud sur le marché depuis les années 2020. Cette nouvelle génération de datawarehouses cloud dispose de 3 avantages majeurs :

• Rapidité / puissance : Les serveurs mis à disposition donnent accès à une puissance de calcul phénoménale.
• Prix : la facturation se fait à l’usage et le coût de stockage a été significativement réduit.
• Accessibilité : la mise en place et la maintenance sont beaucoup plus simples.

L’approche Data Warehouse centric décrit l’architecture du SI Client moderne

Adopter une approche data warehouse centric permet de solutionner la plupart des problèmes et limites rencontrées par les approches du passé. C’est pour cette raison qu’elle s’impose, aussi bien auprès des entreprises mid-market que des grands groupes, dans le Retail et dans bien d’autres secteurs.

Ce n’est pas un hasard d’ailleurs si certaines CDP ont fait évoluer leur offre pour permettre à l’utilisateur d’utiliser son Data Warehouse comme base de données principale et indépendante connectée à la CDP en streaming. C’est l’approche sur laquelle nous avons basé Octolis.

Construire une roadmap data est un jeu d’équilibre où l’on cherche à la fois à répondre aux besoins business immédiats mais aussi à poser des bases stables pour l’architecture du système de données. Il y a cependant deux écueils majeurs lorsque l’on établit sa roadmap :

• Se concentrer principalement sur les enjeux à court terme. La prise de décisions fondées sur des exigences à court terme risque très probablement d’apporter des incohérences à long terme, qui vont peu à peu se transformer en dette technique.
• Se projeter trop loin et se déconnecter de l’activité métier. Réfléchir à une construction optimale de l’infrastructure data sans prendre en compte les besoins actuels des équipes métiers va pénaliser l’ensemble de l’entreprise. En effet, les autres acteurs ne pourront pas tirer partir du dispositif data avant un certain temps, ce qui rend impossible le développement d’une activité « data centric ».

Il est donc nécessaire de naviguer entre ces deux extrêmes pour développer une roadmap data équilibrée qui porte ses fruits à court terme, tout en offrant une architecture stable sur le long terme. Pour cela, nous avons établi un framework vous permettant de trouver cet équilibre précieux et de construire une roadmap data adaptée à vos besoins.

Construire votre roadmap data : le guide étape par étape

Pour clarifier le processus de construction d’une roadmap data, nous avons choisi de prendre l’exemple d’une équipe data fictive de 10 personnes pour laquelle on construit une roadmap sur 12 mois. Les besoins de cette équipe sont ceux que l’on observe le plus fréquemment. Le développement de cette feuille de route se fait en 5 étapes :

#1 – Recenser les besoins métiers

La première étape de la construction d’une roadmap data consiste évidemment à recenser les besoins métiers. Cela passe d’abord par des entretiens avec les principaux responsables des sujets nécessitant une intervention de l’équipe data. Le lead de l’équipe data se doit ainsi de rencontrer les responsables métiers des équipes support, sales, marketing…

Lors de ces réunions, l’accent doit être mis sur les exigences à 12 mois qu’il faut réussir à identifier et à prioriser. Cela permet de déterminer les « besoins data » qui incombent à votre équipe et d’estimer le nombre de projets sur lesquels il est nécessaire d’intervenir.

Une bonne pratique est de collecter les retours de ces échanges dans un tableur où l’on décrit les objectifs des projets, les principaux KPIs qui y sont liés, les leviers d’actions… Ainsi, il est plus facile de se rendre compte de la charge de travail requise par chaque business unit et de regrouper les projets similaires.

#2 – Filtrer les besoins

Après avoir collecté l’ensemble des requêtes, il est nécessaire d’appliquer un ensemble de filtres sur celles-ci afin de pouvoir les prioriser. Yann-Erlé le Roux propose ainsi un système de « tamis » permettant in fine d’attribuer à chaque tâche un degré de priorité.

Le tamis est constitué de 4 filtres :

• Alignement avec le plan stratégique de l’entreprise
• Valeur Business
• Degré de difficulté de mise en œuvre
• Capacité à s’intégrer dans l’architecture data de l’organisation

Pour chaque intervention, on associe un score de 1 à 3 à chaque filtre. Il s’agit ensuite de sommer l’ensemble pour obtenir une note allant de 4 à 12. En opérant ainsi, il est possible de classer directement les projets par un tri décroissant. On obtient alors directement un premier ordre de priorité sur les tâches.

#3 – Définition des priorités

Une fois la liste triée par ordre décroissant des notes, on peut ajouter une valeur de priorité qui permet d’affiner ce classement. 5 degrés de priorité suffisent à classer l’ensemble des projets :

• P0 : Cas d’usage priorisé par le COMEX dans le cadre d’un plan global de transformation ou d’un virage stratégique.
• P1 : Cas d’usage « Must », le projet est essentiel dans l’entreprise et permet d’améliorer significativement l’efficacité d’une équipe.
• P2 : Cas d’usage « Should », le projet est pertinent et son impact dans les équipes est non négligeable.
• P3 : Cas d’usage « Nice to have/Bonus », l’idée est intéressante mais l’impact est difficile à évaluer ou trop faible pour justifier de mobiliser d’importantes ressources
• P4 : Projet abandonné

En établissant ainsi un classement en 5 niveaux, on obtient une version « 1.0 » de la roadmap data et surtout un premier éclairage quant à la charge de travail.

#4 – Estimation de la charge de travail

Après avoir déterminé l’ordre de priorité des UC, il faut définir pour chacun une estimation de la charge de travail en jours travaillés. Une bonne façon de procéder est d’établir un classement en « taille de tee-shirt » :

• XS : 10 JH
• S : 20 JH
• M : 40 JH
• L : 60 JH
• XL : 100 JH
• XXL : 150 JH

Il suffit alors de sommer les jours travaillés pour obtenir la charge totale, tout en tenant compte de la charge de travail maximale. Dans notre cas par exemple, la limite est de 2060 JH (10 ETP x 206 jours travaillés).

#5 – Attribution des sujets

Maintenant que les sujets sont ordonnés par ordre de priorité et que la charge de travail a été définie, il faut les attribuer aux équipes correspondantes. On les réparti généralement ainsi :

• Equipe data seule,
• Avec la DSI sans code projet,
• Avec la DSI avec code projet,
• Les parties prenantes : contributeurs, owner industrialisation, owner R&D…

Pour clarifier la portée du projet auprès des équipes, il est nécessaire de déterminer le degré de maturité du projet :

• Exploration,
• POC,
• Industrialisation,
• Run

Il faut ensuite segmenter entre les différents métiers concernés :

• Data analyst,
• Data scientist,
• Data engineer,
• Scrum master…

Lorsque toutes ces étapes ont été réalisées, il est enfin possible de choisir le timing pour les projets, que l’on organise en trimestre généralement, mais dont le maillage peut être adapté aux besoins. Il s’agit ensuite d’adapter ces use cases à la méthodologie de gestion de projet que vous utilisez : en Agile, on regroupe les use cases en groupes appelés EPIC qui sont associés à des grands thèmes (par exemple : projets transverses, stratégie entreprise, efficacité du développement, efficacité des opérations, connaissance clients).

Construire votre roadmap data : s’adapter aux besoins de votre organisation

Le rôle de l’équipe data

Si les besoins de chaque entreprise différent en termes de données, quelques règles générales peuvent être adoptées pour s’assurer de développer une roadmap data s’inscrivant dans la stratégie générale de la firme. Essentiellement, cela se résume à se demander pourquoi l’équipe data existe au sein de votre société. Quelles sont les problématiques centrales ? Quels problèmes devez-vous résoudre ? Quelles solutions pouvez-vous apporter ?

Ces questions permettent de classifier l’ensemble des sujets en trois catégories :

Adopter cette grille de lecture lors de la construction de votre roadmap permet de gagner en pertinence. Ainsi, vous pouvez prendre du recul sur chaque sujet que vous devez intégrer à votre roadmap. De cette façon, vous vous assurez que votre feuille de route conduise au développement et renforcement du rôle central de votre équipe au sein de l’entreprise.

Les éléments à considérer en amont

Lorsque l’on se pose la question de la place de l’équipe data au sein de l’entreprise pour construire une roadmap pertinente, il faut aussi considérer un certain nombre de motivations en amont et d’influences extérieurs qui affectent fortement la construction de cette feuille de route. Les équipes de Teradata proposent une structure en trois parties pour bien différencier ces éléments.

Les drivers sont à l’origine des besoins data et justifient la mise en place d’une roadmap. Ils permettent également un mécanisme crucial de cadrage. Chaque projet déployé, chaque problème de qualité des données traité et chaque politique de gouvernance des données établie doivent avoir un lien clair avec l’activité de l’entreprise.

• Business Initiatives and Use Cases. S’il peut être utile et pertinent de proposer de nouvelles initiatives, il est encore plus crucial d’identifier les activités commerciales déjà planifiées et financées de l’entreprise nécessitant l’intervention de l’équipe data. Ce faisant, la roadmap data prend une place centrale dans la stratégie d’entreprise. Elle intervient à tous les niveaux pour proposer des leviers d’actions novateurs dont les effets sont rapidement observables.
• Corporate Objectives. Il faut ici rechercher les objectifs définis par la direction qui s’appliquent de façon transversale dans l’entreprise. Cela peut être par exemple une migration généralisée vers le cloud ou une nouvelle approche managériale. L’équipe data a alors la possibilité d’intervenir sur des sujets de large envergure.
• Business Use Case Prioritization. Une fois ces éléments pris en compte, il faut organiser ces tâches par ordre d’importance. Vous pouvez alors vous référer au point #3 de l’établissement de la roadmap data.

Une fois les drivers pris en compte, il faut s’intéresser aux nombreux éléments qui viennent influencer la roadmap et la capacité à développer et à mettre en place de nouveaux projets.

• Information Prioritization. Les données que requièrent les différentes équipes se recoupent très régulièrement (données clients et produits pour les sales ou le marketing, données de production pour la direction financière et les opérations…). Ainsi, lorsque l’on prévoit de créer de nouvelles sources d’informations, il est particulièrement utile de recenser tous les use cases possibles et de comptabiliser les utilisateurs finaux. Cela permet d’évaluer l’impact final du projet, auquel s’ajoutent souvent des externalités positives.
• Current State Architecture. Ici, l’équipe acquiert une compréhension de l’état actuel de la technologie, des données et d’autres facteurs qui affectent l’architecture data. Le degré de précision de cette analyse se fait en fonction des besoins spécifiques. Une description détaillée n’est utile que lorsque les projets data doivent être intégrer dans un écosystème complexe.
• Capability Assessment. La réussite de ses projets dépend du travail commun de personnes aux compétences techniques et non techniques, telles que la gouvernance des données, les capacités analytiques, les processus organisationnels… L’idée est de ne planifier que ce qui est nécessaire quand c’est nécessaire, tout en améliorant continuellement les capacités générales de votre équipe. Cela permet de bénéficier d’une plus grande flexibilité, tout en conservant un cap précis.

Enfin, lorsque vous avez une compréhension suffisante de ces sujets, vous pouvez prendre certaines décisions et évaluer l’impact de celles-ci.

• Implementation Alternatives. Lorsque l’on réfléchi à l’implémentation des nouvelles technologies et des nouveaux projets dans le SI, un certain nombre d’alternatives à l’infrastructure actuelle apparaissent. Il faut alors choisir entre l’architecture déjà en place ou l’utilisation de nouvelles solutions. Nous avons déjà abordé ce sujet dans un article sur la construction de son propre dispositif data.
• Future State Architecture.L’équipe doit avoir une vision précise de l’état futur de l’architecture de data. Cette vision doit clairement indiquer comment les initiatives et les cas d’usage seront intégrés dans l’écosystème, et doit prévoir l’évolution de l’architecture pour répondre aux besoins de la manière la plus rentable et efficace possible.
• Data and Analytics Roadmap. La feuille de route finale reprend tous ces éléments pour définir précisément les projets et nommer des responsables qui devront respecter un agenda clairement établi. Construire cette roadmap doit se faire de manière structurée, et c’est pourquoi nous vous conseillons vivement d’utiliser le framework présenté ci-dessus.

Construire une roadmap data est loin d’être un exercice trivial, et le succès des projets entrepris par l’équipe data dépend très fortement de la qualité de cette feuille de route. Pour cette raison nous vous conseillons fortement d’appliquer le cadre que nous vous avons proposé pour procéder par étapes. Ainsi vous vous assurez d’avoir :

• Une vision claire et précise des projets à entreprendre,
• Une estimation fiable de la charge de travail,
• Une classification des tâches par ordre de priorité et d’importance,
• Un calendrier précis de votre année permettant de suivre attentivement l’avancée des projets

Ces trois avantages sont décisifs pour la réussite de votre équipe et pour le développement de la data dans votre organisation. Répéter ce processus est la garantie d’avoir une équipe fiable année après année, capable de tenir ses engagements et de fournir des leviers d’actions efficaces qui s’intègrent parfaitement dans un écosystème que vous pouvez alors faire évoluer.

Ainsi, le développement de votre roadmap data doit être une de vos préoccupations majeurs. Plus encore, il est absolument nécessaire de revenir régulièrement sur cette roadmap pour pouvoir l’adapter, la corriger ou la préciser afin d’avoir toujours une vision claire des projets à venir et d’être capable de guider au mieux votre équipe.

Définir le salaire de votre prochain data analyst est loin d’être aisé. Pour cela, vous devez d’abord établir une fourchette salariale en fonction d’un ensemble de facteurs qui vous sont propres :

• Le niveau développement de la fonction analytique au sein de votre organisation. En effet, plus votre équipe data est structurée, plus il est facile pour un nouveau membre de s’y intégrer – d’un point de vue opérationnel comme technique. Cela affecte nécessairement le niveau d’expérience que vous devez exiger du candidat, et donc directement le salaire que vous pouvez proposer.
• L’industrie dans laquelle vous évoluez, ainsi que la spécialisation que vous attendez. Ces critères déterminent votre nombre de candidat potentiel, une industrie spécialisée étant naturellement plus restrictive qu’un marché très ouvert. Aussi les analystes spécialisés sont très prisés et bénéficient d’un effet d’enchères de la part des entreprises qui les démarchent.
• Votre besoin réel en termes d’analytics. Parfois l’intervention d’un free-lance peut s’avérer être une solution moins coûteuse, mais tout aussi efficace.

Une fois ces critères établis, il est possible de se comparer au marché et de déterminer une fourchette salariale suffisamment compétitive pour attirer les talents dont vous avez besoin. Nous vous proposons donc des chiffres précis à partir de ces observations afin de vous aider à fixer un intervalle en fonction de vos besoins.

Pourquoi vous en entendez tant parler aujourd’hui ?

La data analyse a pris une place centrale dans les entreprises au cours de la dernière décennie, et le data analyst est devenu incontournable pour toute entreprise en phase de croissance.

C’est lui qui assure le traitement des données afin de livrer des conclusions visant à améliorer l’activité de l’organisation. Il peut intervenir à tous les niveaux pour étudier les processus, le marché ou les ventes. Il doit aussi interagir avec tous les métiers, des équipes financières aux équipes marketing et commerciales.

Les missions des data analysts sont variées :

• Collecte de données,
• Création de dashboard pour faciliter la transmission des conclusions des analyses
• Reporting auprès des équipes métiers ou de la direction
• …

Il est toutefois important de noter une distinction entre deux rôles essentiels : le data analyst et le data scientist. Le second s’applique principalement à l’élaboration de modèles prédictifs et d’algorithmes d’intelligence artificielle en utilisant pour cela un large panel d’outils techniques et mathématiques. Le data scientist a donc un profil plus scientifique et une expertise plus importante dans le domaine de la data, ce qui justifie que sa rémunération soit généralement plus élevée.

Les data scientists et les data analysts se sont imposés dans les entreprises au point de devenir des pierres angulaires des organisations les plus performantes. Leurs apports sont essentiels pour toute entreprise souhaitant rester compétitive, et leur rémunération fait, par conséquent, l’objet de nombreuses considérations.

Salaire d’un data analyst, quelles différences en fonction du profil ?

RollThePay établit le salaire moyen d’un data analyst en France à 43 370 € par an avec une fourchette allant de 26 520 € à 68 172 €.

À cette large fourchette s’ajoutent les bonus et l’intéressement, qui sont aussi dispersés.

La dispersion des salaires des data analystes est donc importante, mais elle s’explique par des variations de l’expérience, des compétences et du type de contrat de l’employé.

Salaire d’un data Analyst en fonction de l’expérience

Le premier facteur de différenciation de salaire pour un data analyst est l’expérience. L’expérience d’un data analyst se traduit par une meilleure compréhension des besoins des équipes et la production d’analyses plus pertinentes. Il est donc naturel que ce soit une qualité récompensée par un salaire plus intéressant.

La croissance de la rémunération au cours de la carrière d’un data analyst n’est pas linéaire. Après quelques années d’expérience – environ 5 ans – on peut observer une marche qui peut être interprétée comme un point pivot dans la progression de l’analyste.

Cette importante augmentation (+20 à +25%) s’explique par l’apport certain qu’offre l’expérience au terme des premières années de carrière. En effet, la data analyse étant à la fois un métier technique et analytique, ce n’est que lorsque l’employé est capable de créer de véritables synergies entre ces deux facettes, et entre les différents acteurs avec lesquels il travaille, qu’il maximise la valeur ajoutée de l’analyse de données. À partir de ce moment, votre data analyst sera capable de proposer des leviers d’actions efficaces à partir d’observations factuelles.

Transformer les données brutes de la sorte implique d’avoir une certaine expérience de terrain. Après quelques années de pratique, l’analyste acquiert une intuition plus précise permettant à la fois de saisir rapidement les besoins métiers et de savoir de façon presque instinctive ce que les données peuvent offrir comme éléments de réponse.

En plus de ces critères et de ces points de référence, vous devez vous interroger sur le rôle que vous souhaitez donner à votre futur data analyst. Si vous souhaitez mettre sur pied une équipe data, à l’initiative de votre future recrue, cette dernière doit être capable de faire preuve de leadership, d’un profond sens business et d’une grande maîtrise de l’ensemble de l’écosystème technologique. Ces compétences rares doivent naturellement être valorisées dans la rémunération pour attirer les meilleurs talents.

Les principales compétences impactant le salaire d’un data analyst

L’exposition à des outils technologiques de pointes pour les data analysts explique les fortes disparités des salaires. En effet, si certains se contentent d’effectuer des analyses simples avec des outils facilement accessibles, d’autres choisissent de recourir à des softwares plus complexes et offrent ainsi des conclusions plus poussées et pertinentes. Dans le second cas, le data analyst, conscient de sa maîtrise technique, exige bien souvent une rémunération supérieure.

Les outils techniques qu’utilisent les data scientists sont particulièrement variés, du langage de programmation (R ou python généralement) aux outils de Business Intelligence (Power BI, Tableau) en passant par la gestion de base de données. Cependant tous ces outils n’offrent pas les mêmes avantages de rémunération. Lorsque les compétences techniques recherchées sont rares sur le marché, on observe une véritable inflation des salaires.

Plus encore, la maîtrise d’outils technologiques de pointes affecte fortement la rémunération des data analysts. O’Reilly a ainsi pu déterminer dans un sondage que les data analysts maîtrisant Hadoop, Spark ou Python étaient deux fois plus à avoir obtenu une importante augmentation au cours des trois dernières années. Ainsi on peut observer de fortes disparités selon les softwares utilisés.

Énumérer les compétences essentielles pour un data analyst est une tâche assez longue compte tenu de la diversité des outils et des compétences requises. De plus, la seule maîtrise de certains softwares recherchés par les entreprises ne suffit pas à être un data analyst hors pair. La data analyse est un métier complet et vaste, et un bon analyste doit savoir utiliser des techniques lui permettant de faire face à des défis aussi variés.

Il existe aussi d’importantes disparités en fonction de la zone géographique et les secteurs d’activité, avec en tête la finance et le service aux entreprises.

Salaire d’un data Analyst Freelance

Une alternative à l’embauche d’un data analyst est le free-lance. Ce choix peut-être pertinent pour répondre à des besoins plus spécifiques ou ponctuels. La question de la rémunération se pose néanmoins. La plateforme codeur permet de trouver des free-lances et présente publiquement la grille tarifaire des data analysts selon leur expérience. En septembre, le tarif journalier s’élevait à 310€, soit 44€/heure, et le coût moyen des projets était de 4 100€.

Cette solution permet donc de bénéficier ponctuellement de l’expertise d’analystes compétents tout en limitant le coût de développement du projet.

Salaire d’un data analyst, quelles différences en fonction de l’industrie ?

Si la data analyse représente un enjeu considérable dans toutes les industries, cet or digital prend une place encore plus stratégique dans certains secteurs. De manière générale, l’importance accordée à la data, et donc la rémunération octroyée aux analystes, dépend du volume de données et de l’avantage que procure la maîtrise de celles-ci.

Ainsi, dans un secteur comme la finance, où le volume d’informations croît sans cesse, la gestion des données est devenue la clé de domination du marché. Il serait impensable aujourd’hui de voir prospérer une banque d’investissement qui ne disposerait pas d’un pôle data de pointe. Le secteur bancaire dispose de sources innombrables pour alimenter les datalakes, des données de marchés obtenues en temps réels aux informations liées aux clients. Ces données ont autant d’usages que de sources : ciblage marketing, détection d’investissement potentiel, prédiction de l’orientation des marchés…

Un deuxième secteur où l’utilisation de la data analyse est devenue centrale est celui de la santé. Là encore les sources et usages de la data sont multiples : analyses d’épidémies, aide au diagnostic, suivi de traitements… Une utilisation efficace de ces données permet d’avoir une meilleure compréhension des maladies et de proposer des traitements plus efficaces.

La data analyse est donc essentielle pour ces deux secteurs, qui ont en commun une abondance de sources d’information. Les entreprises maîtrisant ces données disposent d’un avantage concurrentiel certain. Cela provoque naturellement une inflation des salaires dans ces milieux où il faut absolument embaucher les meilleurs talents.

Plus encore, il est possible de se spécialiser au sein des industries afin de développer une véritable expertise pour certains outils. Ainsi un data analyst se spécialisant en finance, dans l’étude des marchés ou dans le domaine de la santé peut accéder à une rémunération supérieure à la moyenne. Cela s’explique principalement par des responsabilités plus importantes ou des tâches plus complexes.

Salaire d’un data analyst en France : comparaison avec l’étranger

Salaire moyen d’un data analyst junior en Europe

Selon Glassdoor, en 2021, voici la répartition des premiers salaires en euros en fonction des pays :

Il existe une grande volatilité des salaires entre les pays, mais aussi au sein des pays. Certains sont sujets à une plus grande variance dans la fourchette salariale, comme le révèle l’étude d’O’Reily :

Toutefois, ces résultats sont à mettre en perspective avec le PIB de chaque pays. On peut observer une corrélation très nette entre PIB/habitant et salaire du data analyst. Cela se traduit par une rémunération similaire pour les data analysts en comparaison du niveau de vie du pays.

Salaire moyen d’un data analyst aux Etats-Unis

C’est aux États-Unis que l’on trouve le plus d’offres aux salaires élevés. Il peut être compliqué d’y estimer le salaire d’un data analyst compte tenu de la largeur de la fourchette salariale. La rémunération dépend principalement de deux facteurs : la ville et l’entreprise. Voici la rémunération moyenne selon la ville d’après une étude de Etudes tech:

• Seattle : 150 000$ par an ;
• San Francisco : 135 000$ par an ;
• Los Angeles : 135 000$ par an ;
• New York : 100 000$ par an ;
• Phoenix : 96 000$ par an ;
• Washington : 87 000$ par an ;

Le salaire du data analyst dépend aussi fortement de l’entreprise dans laquelle celui-ci travaille. Les salaires dans les réputées GAFAM sont généralement les plus élevés (jusqu’à 140 000$ chez Meta). Les cabinets de conseils ou les grandes entreprises américaines telles que Target offrent aussi de très importantes rémunérations.

Ainsi, le salaire d’un data analyst varie grandement en fonction de l’entreprise, de l’industrie et de l’expérience. Il faut donc prendre en compte chacun de ces critères pour estimer la juste rémunération d’un candidat ou pour se fixer un objectif de revenu.

La data analyse est un métier varié qui permet d’évoluer rapidement en progressant sur des thématiques techniques et business, et pour lequel de nombreuses formations existent, quel que soit le niveau !

Recruter son premier data analyst est un défi de taille aux conséquences importantes pour l’entreprise. C’est lui qui va poser les fondations de votre équipe data sur deux aspects à la fois :

• D’un point de vue humain : développement de l’équipe
• D’un point de vue technique : choix des technologies et de l’architecture pour construire un système data stable, viable et pertinent.

Un véritable challenge en somme, mais qui peut être résolu si l’on possède les bonnes clefs de compréhension.

Nous avons donc développé pour vous un guide complet en s’appuyant sur les sources les plus pertinentes et notre expérience afin de vous aider à définir les compétences dont votre premier data analyst doit disposer et de vous accompagner dans le processus de recrutement et d’intégration de votre futur collaborateur !

Identifiez de qui vous avez besoin

Quand recruter un data analyst ?

Trouver LA bonne personne dans une entreprise grandissante signifie d’abord trouver la personne qui s’inscrit le mieux dans votre lancée. Il faut employer l’individu dont les compétences et l’expérience sont la clef pour accélérer votre croissance. Ces critères sont évidemment variables en fonction du stade de développement de votre entreprise.

Tristan Hardy a établi une classification des besoins en data analyse pour une entreprise selon sa taille. Il rappelle ainsi que la majorité des start-up recrutent leur premier data analyst alors qu’elles sont encore en « early stage ».

Le moment idéal pour recruter son premier data analyst est lorsque l’entreprise a dépassé ses tout premiers stades et qu’elle compte entre 20 et 50 employés. À ce niveau, les données dont elle dispose émanent principalement des applications utilisées pour votre activité (un dashboard Stripe ou Facebook…). Si la plupart des entreprises à ce stade de développement disposent des principaux outils analytiques (Google analytics, Mixpanel…), très peu ont une infrastructure data complète avec un data warehouse et des outils BI.

C’est donc une problématique qui intervient rapidement dans le développement de la structure et qu’il est nécessaire d’anticiper.

Qu’attendre de son premier data analyst ?

Définir clairement les tâches dont votre premier data analyst doit s’acquitter est essentiel pour exploiter efficacement vos données et apporter une véritable plus-value aux équipes métiers. Puisque c’est cet analyst qui va poser les fondations de votre infrastructure data, il doit être capable de :

• Avoir une approche transverse et communiquer avec toutes les équipes.

Cela est primordial afin de comprendre précisément les besoins des équipes et de transmettre clairement les résultats des analyses. De plus, il est nécessaire d’être capable de s’adresser à toutes les équipes pour ancrer la data analyse dans la culture de l’entreprise et les processus métiers.

• Construire des modèles de données optimaux.

La structure que met en place le premier data analyst sera utilisée pendant plusieurs années. Il faut donc qu’elle soit résiliente et parfaitement adaptée aux besoins commerciaux. Pour cela, le premier data analyst doit être compétent dans l’usage de Git et de SQL et doit aussi savoir construire des tables de données. Un candidat incapable de se servir de Git manque très certainement d’expérience avec les autres outils plus complexes, il est donc essentiel de tester ces compétences lors du recrutement. Une infrastructure data mal conçue peut avoir des répercussions sur plusieurs années et des coûts de restructuration particulièrement importants.

Il faut ainsi choisir quelqu’un pouvant endosser les rôles d’analyst et d’analytics engineer, c’est-à-dire quelqu’un capable de mettre en place une infrastructure propice à l’usage de la data et de réaliser des analyses pertinentes.

Andrew Bartholomew positionne ainsi ce qui doit être le premier analyst dans l’écosystème data :

La question de la séniorité se pose aussi lors du recrutement. Deux aspects doivent être pris en compte :

• L’expérience :

Le candidat est-il capable de construire une infrastructure complexe répondant aux besoins de l’entreprise avec les contraintes qui lui sont imposées ? Nous considérons qu’il faut avoir pour cela au moins 4 ans d’expérience. Il est peu probable qu’un candidat ayant moins d’expérience puisse mener le développement d’un tel projet efficacement et prendre les décisions les plus optimales pour l’entreprise.

• Le management :

Bien que le sujet ici soit le premier data analyst, il faut aussi considérer l’évolution de votre équipe data. Le candidat est-il capable de manager une équipe de 5 personnes, de trouver les talents nécessaires à son équipe et de les recruter ?

Le processus de recrutement d’un data analyst décrypté

#1 La structure de l’offre d’emploi

Pour convaincre les meilleurs candidats de postuler, il est crucial d’avoir une offre d’emploi structurée afin que les lecteurs comprennent la teneur du rôle. Trop d’offres n’apportent pas assez de précisions ou de détails, ce qui rebute les candidats qui craignent d’arriver dans une entreprise où la place de l’équipe data n’a pas été véritablement définie.

Nous avons trouvé une structure en 5 parties, particulièrement efficace pour ce type d’offre :

• Présentation générale et contexte :

Dans cette première partie, il faut présenter l’entreprise au candidat ainsi que vous attentez pour ce rôle. Vous pouvez préciser le degré de spécificité de l’emploi (est-ce que cela porte sur un domaine en particulier), et la structure actuelle de votre équipe. Il faut aussi expliquer les besoins que vous avez dans votre équipe.

• Exigences :

Cette partie permet de présenter vos attentes techniques au candidat. Vous devez y lister les technologies qu’il est essentiel de maîtriser, et celles qui sont « un plus » – attention à bien séparer ces deux catégories.

La difficulté de cet exercice est de trouver le bon degré de précision. Une liste trop abstraite conduirait des candidats trop peu expérimentés à postuler, quand une liste trop précise risquerait de vous priver de bons éléments. Il faut donc déterminer si, pour une technologie donnée, vous souhaitez avoir un candidat maîtrisant l’outil exact ou ayant de l’expérience avec ce type de software. Par exemple, si vous utilisez Airflow, voulez-vous d’un candidat sachant maîtriser cette plateforme, ou d’une personne expérimentée avec les outils d’orchestration des données ?

Nous recommandons de lister entre 5 et 10 technologies pour être précis et concis.

• Responsabilités :

Cette partie est probablement la plus importante pour le candidat. C’est là qu’il détermine si le rôle l’intéresse. Il faut donc être spécifique et surtout pertinent pour que celui-ci puisse se projeter et désirer obtenir l’emploi. Mettez en avant les missions intéressantes qui seront confiées à l’employé.

• Processus de recrutement :

Un candidat séduit par les points précédents va naturellement se demander comment postuler et se préparer aux entretiens. Il faut donc dédier une partie entière de l’offre à la présentation du processus de recrutement.

Les candidats sont bien plus susceptibles de postuler s’ils connaissent la teneur du processus de recrutement. Cela permet donc d’avoir plus de candidats, qui sont eux-mêmes mieux préparés. C’est donc le meilleur moyen pour vous, in fine, de sélectionner le candidat le plus apte.

• Vos premiers mois :

Cette partie permet de se différencier de la majorité des offres d’emploi. En présentant aux candidats la teneur de leurs premiers mois, vous les aider à la fois à se projeter et en même temps à se rassurer.

Plus encore, en définissant les principaux points qui vont occuper les premiers mois de la personne recrutée, vous prouvez aux candidats que l’emploi que vous proposez est intéressant et nécessaire pour votre activité.

Emilie Schario propose plusieurs exemples d’offres d’emploi suivant cette structure.

#2 Partager la meilleure offre d’emploi n’est pas suffisant

Les data analysts font partie des emplois les plus difficiles à recruter. Même en ayant une offre d’emploi de très bonne qualité, il n’est pas certain que vous trouviez la personne adaptée à vos besoins.

Nous vous proposons donc un ensemble de conseils supplémentaires afin de vous aider dans cette tâche.

Se rapprocher de la communauté data

La meilleure façon de rencontrer l’individu capable de répondre à vos besoins est de chercher directement au sein de la communauté data et dans les groupes de data analysts. Il existe de nombreuses communautés en ligne, dont le degré d’engagement varie. LinkedIn est l’une des ressources les plus efficaces pour cela, avec de nombreux groupes d’échanges au sein desquels les membres partagent leurs projets. Vous avez ainsi directement aux profils des individus et à leurs portfolios.

D’autres plateformes permettent de découvrir des individus très engagés dans cette communauté, à l’instar de Quora ou de StackOverflow.

Enfin, il existe des rencontres et des évènements en physique durant lesquels sont présentés les outils les plus en vogue, l’évolution des techniques et des plateformes data… Y assister permet de mieux comprendre cet écosystème, de savoir que chercher et peut-être de rencontrer votre futur data analyst.

Juger les projets, pas seulement les CV

L’Analytics requiert de nombreuses compétences techniques qu’il est très difficile d’évaluer sur un CV. Chaque candidat s’évalue de sa propre manière, et le niveau mis en avant sur le CV ne reflète pas nécessairement la réalité. Pour cette raison, il est souvent plus pertinent de juger un candidat sur ses projets, ou du moins d’y prêter une grande attention.

Les développeurs incluent très généralement leur portfolio dans leurs candidatures. Vous pouvez aussi le demander dans les éléments du dossier. Ces portfolios permettent de se rendre compte du niveau réel de l’individu, d’avoir une idée de son expérience et même de mieux connaître le candidat.

Plus encore, vous pouvez proposer un jeu de données en libre accès en ligne, sur Kaggle par exemple. Cela permet aux candidats de montrer leur expertise sur des données réelles et similaires à celles qu’ils pourraient exploiter chez vous. Vous pouvez même organiser des compétitions à partir de ces data sets afin de détecter des data analysts possédants les compétences recherchées.

> Compétences Comportementales 

> Compétences Relationnelles

Ainsi, le recrutement de votre premier data analyst est aussi crucial que complexe. Afin d’embaucher le talent capable d’utiliser de façon optimale vos données, il est nécessaire de :

• Publier une offre claire et structurée
• Se rapprocher des groupes de data analysts
• Mettre en place un processus de recrutement visant à évaluer les compétences techniques, comportementales et relationnelles du candidat
• Préparer son intégration afin de suivre sa progression au cours des premiers mois.

Dans la course vers une relation client toujours plus personnalisée et omnicanale, les programmes de fidélisation qui visent à récompenser les clients réguliers et à instaurer avec eux une relation durable jouent un rôle de plus en plus important.

Ces programmes répondent à un constat simple, 15 à 20% de clients qui représentent 50 à 80% de votre chiffre d’affaires : il est donc nécessaire de valoriser le plus possible vos meilleurs clients.

L’objectif de ces programmes est triple :

• Augmenter la rétention
• Faire croître leur panier moyen et leur Lifetime Value (LTV)
• Diminuer le coût d’acquisition client.

Les programmes de fidélités modernes, auxquels les clients sont plus sensibles, dépassent le simple avantage économique. Plus encore, l’éternelle « carte de fidélité » n’est plus un élément indispensable d’un programme. Il vaut mieux désormais se recentrer sur la relation avec le client pour proposer une expérience unique qui vous permettra de vous distinguer de la concurrence.

Nous avons donc sélectionné les exemples les plus réussis dont vous pouvez vous inspirer pour vos programmes de fidélités.

#1 Appartenance à un club avec le Nike+ Run Club

Le Nike+ Run club permet à tous les utilisateurs de l’application Nike, débutant ou confirmé, d’appartenir à un « club » et d’être accompagné dans la pratique de leur sport. Le mot d’ordre dans la description de l’application par Nike : « nous sommes là pour vous », est représentatif de cette volonté.

Les utilisateurs font ainsi partie d’une très large communauté organisée autour de la marque de sport. On peut y enregistrer ses chaussures, suivre le détail de ses performances et partager chacune de ses courses.

L’une des forces de cette application est sa gratuité : même un utilisateur qui n’est pas encore client chez Nike peut s’inscrire et faire partie de cette communauté. Une fois membre, l’utilisateur est plus susceptible de devenir client ou de le rester.

L’autre atout de cette application est le coaching personnalisé – là encore accessible gratuitement. Chaque utilisateur est donc accompagné dans la pratique de son sport par un « coach » virtuel de Nike, une voix qui guide l’utilisateur lors de ses courses. Nike prend ainsi une place importante dans la pratique du sport par l’utilisateur, qui associe alors la marque à sa progression.

#2 Les programmes à points, le club Oh My Cream

Le programme à point est un système simple grâce auquel le client va gagner un certain nombre de points par euro dépensé, en échange desquels il peut bénéficier d’avantages exclusifs et de réductions.

Ce système permet d’inciter directement le client à accroître la taille de son panier, ce dernier étant récompensé en fonction de la valeur de ses achats. De plus, le fonctionnement simple et clair de ce type de programme facilite l’adhésion des utilisateurs qui ont facilement accès à la grille de récompenses.

Un exemple de programme à points est le club Oh My Cream, de la marque de soin skincare. Ce club repose sur 3 niveaux – Argent, Or et Platine – qui offrent des réductions, mais donnent également accès à des ventes privées et même à des initiations exclusives et des journées privilèges.

Ainsi, pour chaque euro dépensé, le client gagne un point. Parvenu à 220 points, le client entre dans le programme au niveau Argent et reçoit un bon de réduction de 10% utilisable sur la commande de son choix. Ce système continue jusqu’à ce que le client atteigne les 1300 points – le niveau Platine – lorsque sa fidélité est récompensée par des invitations exclusives à des évènements privés, et où chacune de ses commandes est agrémentée d’une surprise.

Le club Oh My Cream est donc un exemple intéressant de programme à points. Facilement compréhensible et transparent, les clients y adhérent rapidement. Plus encore, ce système ne repose pas seulement sur une offre économique, mais propose aussi des expériences uniques aux clients les plus fidèles.

#3 Le parrainage avec Mon Petit Placement

Les programmes de parrainage récompensent une autre facette de la fidélité du client : les recommandations. Leur objectif premier est d’accroître la base de clients en se reposant sur les utilisateurs existants. Cela présente plusieurs avantages :

• Réduction du coût d’acquisition client :

En laissant les utilisateurs promouvoir eux-mêmes la plateforme, l’entreprise réalise des économies significatives. Pour que cela soit effectivement rentable, il est nécessaire de calculer l’avantage qu’en retirent les parrains pour que l’offre soit incitative et en même temps intéressante économiquement pour l’entreprise.

• Sélection des clients potentiels :

Les utilisateurs qui recommandent la plateforme le font à des individus très susceptibles d’être intéressé par le service. C’est donc un moyen indirect mais précis de sélectionner les clients potentiels.

• Récompense pour l’attachement à l’entreprise :

Ce système de récompense dépasse les simples récompenses liées aux achats et encourage les clients à recommander le service, créant de fait un plus grand attachement à la marque.

Le programme de fidélité de Mon Petit Placement est un exemple de système de parrainage efficace. Chaque parrain bénéficie de 15% de réduction à vie par filleul sur ses frais de gestion, et chaque filleul reçoit à son tour cette réduction de 15% lors de la création de son compte. Plus encore ces réductions sont cumulables ! C’est donc un système simple dont les utilisateurs bénéficient directement et qui récompense de façon importante les individus qui recommandent Mon Petit Placement.

#4 Mettre en avant les valeurs partagées : Body Shop

Tous les programmes de fidélités ne sont pas construits seulement autour d’avantages économiques. The body shop par exemple a centré son offre de fidélité autour de ses valeurs d’entreprise, notamment la lutte contre les violences sexuelles.

Le programme de fidélité The Body Shop offre la possibilité de convertir ses points de récompenses en dons. Ainsi, les récompenses ne bénéficient pas directement au client mais sont transmises à une association de son choix.

En opérant ainsi, l’entreprise se rapproche de ses clients à travers une lutte commune pour des valeurs partagées. Ce système reposant sur la charité permet donc de créer une relation plus profonde avec le client qui développe alors un attachement plus important pour la marque. Les clients sont généralement sensibles à ce type de programme qui permet de dépasser la simple relation commerciale et de mettre en avant des valeurs importantes pour l’entreprise.

#5 Le programme de fidélité par palier : Philosophy

La marque de produits cosmétiques Philosophy a choisi un type de programme de fidélité semblable à celui à points, mais en y incluant un système supplémentaire de paliers. Comme pour le système à points, le client dispose d’une certaine cagnotte liée à son activité lui permettant d’accéder à des avantages exclusifs. Cependant, le programme de Philosophy présente deux différences notables :

• Le multiplicateur de points :

Les clients sont répartis en 3 niveaux en fonction du nombre de points dont ils disposent. A chaque niveau est associé un multiplicateur de points. Ainsi, un client au premier niveau gagne des points à chaque achat selon une grille, au deuxième niveau le nombre de points gagnés est multiplié par 1,25 et au troisième niveau par 1,5. Les avantages du multiplicateur sont même renforcés pendant le mois de l’anniversaire du client.

Ce système récompense ainsi les clients à la hauteur de leur fidélité. Plus encore la marque les incite directement à passer à l’échelon supérieur en leur envoyant mensuellement un « compteur de gratitude » et surtout en proposant une gamme d’articles sélectionnés pour le client à partir de ses commandes passées.

• Gain de points supplémentaires :

Philosophy ne récompense pas seulement les achats mais aussi l’activité de ses clients sur les réseaux sociaux. Des points supplémentaires peuvent être gagnés en échanges d’actions en ligne, comme le fait de suivre la marque sur les réseaux ou d’écrire un avis. De plus, la marque a intégré le parrainage dans son système à points.

Philosophy a donc mis en place un programme de fidélité très complet, qui récompense les différentes facettes de la fidélité du client à la hauteur de son attachement à la marque.

#6 Le programme de fidélité payant avec Barnes & Noble

Ce type de programme de fidélité se distingue sensiblement de ceux évoqués précédemment, car le client doit ici payer pour en faire partie. Si cette stratégie peut sembler contre intuitive au premier abord, elle peut cependant s’avérer très efficace pour inciter le client à finaliser sa commande et ainsi augmenter la LTV des membres du programme.

En effet, en rendant payant l’accès à des avantages exclusifs, l’entreprise est en mesure de proposer un service plus complet et plus attrayant. Ces avantages permettent de réduire le taux d’abandon de panier – de plus de 75% – en réduisant drastiquement le nombre de barrières à l’achat. Ces barrières à l’achat, telles que les frais et délais de livraison, peuvent ainsi être supprimées avec des offres de livraison gratuite et/ou prioritaire, des coupons de réductions …

Barnes and Noble propose un tel type de programme de fidélité : pour 25€ par an, le client a accès à un service de livraison gratuit, à des ventes exclusives et à de nombreuses réductions.

Il est cependant primordial de porter une attention particulière à la valeur que l’offre représente pour un client lorsque l’on met en place ce type de programme. Les économies potentiellement réalisées grâce à ce type d’offre doivent être suffisamment supérieures au coût de l’abonnement pour convaincre le client d’y souscrire.

#7 Autre type de programme de fidélité : les abonnements

Les abonnements peuvent être considérés comme une forme de programme de fidélité qui donne un accès exclusif à un service uniquement réservé aux clients abonnés.

Ce type d’offre présente un avantage particulier par rapport aux autres programmes : en engageant les clients sur une certaine durée, une entreprise va mécaniquement augmenter la LTV de sa clientèle. Généralement, le coût mensuel d’un abonnement est inversement proportionnel à la durée de l’engagement. Ainsi l’entreprise fidélise ses clients sur la durée et les incite à rester sur le long terme.

Le petit ballon, une marque permettant de découvrir chaque mois des bouteilles de vin livrées à domicile, fidélise sa clientèle au travers d’abonnements. Il n’est pas possible d’avoir accès à ce service pour une durée inférieure à 3 mois, ce qui garantit à l’entreprise un minimum de 3 achats par clients abonnés.

Le système d’abonnement suppose néanmoins que le client est disposé à payer de manière régulière pour avoir accès aux produits de l’entreprise. C’est donc un programme de fidélité particulièrement efficace, mais dont la mise en place dépend évidemment du type de service que propose la marque.

En conclusion : cherchez la simplicité

Il existe de nombreuses variantes des programmes de fidélités, chacune ayant ses spécificités, qui permettent d’attirer les clients auprès de la marque et d’accroître leur Lifetime Value.

Cependant, la condition nécessaire à la réussite de tous ces programmes reste l’engagement des clients. Un membre d’un programme de fidélité doit y souscrire et en faire usage pour que la mise en place d’un tel système soit source de valeur pour l’entreprise.

Notre recommandation principale, quel que soit le type de programme, est donc : la simplicité. Il est nécessaire de mettre en place un système simple et facile à comprendre pour que le client y adhère et en fasse usage régulièrement.

De l’application Nike à l’offre d’abonnement Le petit ballon, tous les exemples que nous avons sélectionnés proposent une offre que l’on comprend instantanément – coach running, livraison gratuite, ventes privées… – et dont on saisit directement la valeur. Le client peut ainsi facilement se projeter et est alors plus susceptible de devenir membre du programme.

Construire son propre dispositif data est un projet ambitieux et complexe nécessitant de nombreuses ressources. Pourtant de multiples entreprises, souvent poussées par les data engineers, font le choix de développer leur propre outil. Cette décision peut s’avérer néfaste pour l’entreprise si elle n’est pas motivée par les bonnes raisons.

Mettre en place un dispositif data nécessite d’assembler de nombreux composants cloud et/ou open source, souvent plus d’une douzaine : Kubernetes, KubeFlow, AWS ECR, Elasticsearch, Airflow, Kafka, AWS Cloudwatch, AWS IAM, DBT et Redshift. Ces éléments sont ensuite liés entre eux à travers une brique de code, avec Terraform par exemple. Ce type d’architecture est d’autant plus complexe qu’il se doit d’offrir à chaque équipe, et donc à chaque compte, un accès sécurisé à l’outil.

A l’inverse, lorsque l’on utilise une solution déjà existante, il est seulement nécessaire de configurer ses accès AWS et d’utiliser un outil tel que Terraform. Il ne reste qu’à connecter les bases de données aux outils d’analyses, par exemple Azure Data Lake et Azure Data Factory. Aucun outil ne permet d’éliminer totalement ces étapes, mais la mise en place générale du dispositif est grandement simplifiée et accélérée.

Dans cet article inspiré de l’excellent Niels Claeys, on évoque dans le détail les raisons qui poussent les organisations à se tourner vers la construction d’un dispositif data ‘best of breed’ ainsi que les obstacles qui se dressent devant cette construction.

La passion de vos data engineers est un frein

La majorité des data engineers considèrent la construction d’un dispositif data comme un véritable challenge, un projet leur permettant de développer et d’éprouver leurs compétences. C’est même probablement dans l’ADN d’un ingénieur de vouloir construire ses propres outils.

Par conséquent, la plupart d’entre eux risquent de ne pas être totalement neutres lorsqu’ils considèrent les avantages et les inconvénients d’un tel projet. Leurs objectifs ne sont alors pas parfaitement alignés avec ceux de l’entreprise, ce qu’il est nécessaire de prendre en compte.

Voici les raisons pour lesquels les data engineers risquent de manquer d’objectivité :

Les data engineers ❤️ les nouveaux outils

Dans l’écosystème data, les technologies évoluent rapidement et la popularité des outils varie constamment. La maîtrise d’un nouveau software populaire est souvent valorisée sur un CV. De ce fait, de nombreux programmeurs vont chercher à utiliser les nouveaux outils en vogue pour en avoir une bonne compréhension au minimum.

Il est important pour une entreprise de permettre à ses développeurs de continuer à apprendre de nouvelles technologies, mais employer de nouveaux outils lors du développement d’une plateforme data complexe n’est certainement pas le cadre le plus optimal pour permettre cet apprentissage.

De plus, la découverte et la prise en main d’un nouvel outil représentent un défi souvent ludique pour un développeur. Mais l’excitation que peut éprouver le data engineer lors de la première utilisation d’une nouvelle technologie ne dure qu’un temps, et l’envie de travailler avec l’outil peut décroître à mesure que celui-ci devient familier et l’apprentissage plus sporadique.

De ce fait, construire une plateforme data représente pour un ingénieur l’opportunité d’acquérir de nouvelles compétences tout en travaillant sur un projet stimulant. Les développeurs préfèrent donc naturellement développer eux-mêmes leur dispositif data et soutiennent ce choix sans que cela soit nécessairement favorable pour l’entreprise.

Les data engineers ❤️ toujours leur propre code

Il est fréquent d’entendre des développeurs critiquer la qualité du code d’un produit ou la solution en elle-même. Nombreux sont ceux préférant leur code et leur solution à ce qui existe sur le marché, se targuant – à tort ou à raison – d’être capable de développer des outils de meilleure qualité.

L’objectif ici n’est pas de comparer la qualité des codes ou le niveau des développeurs, mais de réfléchir aux intérêts de l’entreprise sur le long terme. Même en acceptant le postulat que vos développeurs seraient plus compétents que ceux ayant développé la solution déjà existante, choisir de construire son propre dispositif peut être contre-productif pour plusieurs raisons :

• La durée de développement :

Développer une plateforme data complète, utile et capable de rivaliser avec les solutions du marché est un projet de grande envergure risquant de s’étaler sur plusieurs années et de monopoliser des ressources sur le long terme. Il faut plus longtemps encore pour en mesurer les bénéfices.

• La maintenance de la plateforme :

Créer sa propre solution implique aussi de s’assurer de la maintenance du code sur le long terme. Cela impose d’avoir une excellente documentation et un code legacy de grande qualité ainsi que d’avoir toujours un développeur capable de mettre à jour le software.

• La persistance des développeurs :

Les data engineers à l’origine de la plateforme sont susceptibles de changer de projet/équipe/entreprise au court de la vie du dispositif data. La transmission du projet s’en trouve alors complexifiée. De plus, les nouveaux développeurs risquent de vouloir à leur tour adapter le code et l’architecture du projet.

Ainsi, faire le choix de développer son propre outil représente le risque d’avoir une plateforme instable et difficile à maintenir. De plus, les développeurs comparent plus généralement la qualité intrinsèque du code, mais négligent la capacité de l’entreprise à maintenir l’outil et à le faire évoluer pour répondre à de nouveaux besoins.

Faire le choix d’une solution existante, c’est réduire le temps de développement et accroître la stabilité de ses outils.

Les data engineers ❤️ la liberté

Construire son propre outil, c’est aussi choisir les technologies mises à contribution dans le projet. Mais la diversité des IDE, des langages, des frameworks et des softwares rend ce choix complexe. En outre, les préférences individuelles des développeurs sont multiples et peuvent très souvent donner lieu à d’intenses débats. Ainsi la stack data de la plateforme risque d’être pensé en fonction des habitudes du data engineer plutôt que sur des critères objectifs de maintenance et scalabilité au sein de l’entreprise.

Exemple d’architecture data moderne

Plus encore, le fait de développer la solution offre une grande liberté quant à l’architecture de la plateforme. C’est parce que les développeurs savent qu’ils pourront coder avec les langages de leur choix et assembler les différentes briques à leur manière qu’ils préfèrent construire eux-mêmes le dispositif data.

Mais cette liberté pour le développeur peut rapidement se transformer en contraintes pour l’entreprise. En effet, le choix du data engineer va dépendre de plusieurs critères susmentionnés, tels que la popularité de l’outil, la possibilité d’utiliser son propre code… A l’inverse, l’entreprise doit considérer avant tout l’intégration du dispositif data dans son SI, la possibilité de le faire évoluer et de le maintenir à jour.

En résumé, l’entreprise est soumise à des contraintes quand le développeur cherche à être libre dans son travail. Cette opposition peut conduire à un choix contre-productif de la part du data engineer.

Les obstacles liés à la construction d’une plateforme data

Les considérations des data engineers ne sont pas les seules raisons pour lesquels construire son propre dispositif data n’est pas une bonne idée. D’autres problématiques s’ajoutent à ces considérations :

Les coûts d’exploitation sont supérieurs aux coûts de construction

Construire une ébauche de dispositif data est l’affaire de quelques jours pour un data engineer expérimenté. C’est probablement pour cette raison que le temps de développement est très souvent grandement sous-estimé. En effet, s’il est relativement facile de mettre en place un premier MVP, il est autrement plus complexe de coder une plateforme complète, stable et facile à maintenir.

Coûts d’une plateforme data au cours de son cycle de vie complet (Source)

Une fois la première version live déployée, il est nécessaire de s’assurer qu’une équipe soit responsable de :

• Maintenir le code à jour :

Mettre à jour les dépendances, corriger les vulnérabilités et les failles de sécurités…

• Gérer les bugs :

Au cours de son cycle de vie, la plateforme va subir de nombreux bugs qu’il faut fixer rapidement pour assurer la disponibilité du dispositif. Il est donc nécessaire d’avoir en permanence un développeur ayant une connaissance précise du code et capable d’intervenir rapidement.

• Faire évoluer le dispositif :

Pour transformer le MVP en dispositif complet, il est nécessaire de prendre en compte les retours des utilisateurs et d’y ajouter les fonctionnalités manquantes. Il est aussi important de s’assurer que l’usage de la data par les équipes métiers n’est pas redondant et de proposer des solutions le cas échéant.

Ainsi, les coûts d’exploitation de la plateforme risquent d’être nettement supérieurs aux coûts de construction. Ces coûts d’exploitation sont généralement sous-estimés et le coût total du projet sera probablement bien supérieur aux estimations. De plus, si l’investissement initial pour construire la plateforme peut sembler légitime face à l’acquisition d’un software, il est cependant plus difficile de justifier les coûts d’exploitation par rapport à un abonnement à une solution existante (surtout si celle-ci est plus complète).

Au cours du cycle de vie du dispositif, il est probable que l’entreprise ne perçoive pas un retour sur investissement suffisant pour justifier les dépenses d’exploitation. Le projet est alors véritablement vain.

Votre plateforme data ne sera pas pensée comme un produit

Lorsque le dispositif data n’est pas une finalité, mais un moyen de répondre à des problématiques rencontrées par les employés, le résultat est souvent fragmentaire et présente de nombreuses limites.

• Une plateforme peu fonctionnelle

Dans une entreprise où la plateforme data n’est pas le produit final, mais seulement un support pour les équipes métiers, il est très probable que l’outil ne soit pensé qu’en réponse à des cas d’usages précis. Le dispositif final risque alors de ressembler plus à un assemblage disparate de fonctionnalités qu’à un produit complet.

Dans ce cas, il est assez rare de travailler à améliorer les performances globales de l’application ou de proposer des fonctionnalités plus globales visant à faciliter l’expérience de l’utilisateur final. L’accent est mis sur les cas d’usages restant, au détriment de la cohérence globale du dispositif et de sa fonctionnalité.

• Une solution peu efficace pour améliorer la productivité

Proposer une plateforme pour répondre à des cas d’usages spécifiques permettra aux équipes métiers de réaliser certaines tâches plus facilement, mais n’est pas suffisant pour accroître sensiblement leur productivité. De plus, les ressources étant limitées lors du développement d’une application en interne, il est probable que les solutions visant à réellement augmenter la productivité soient reléguées au second plan, l’accent étant mis sur la capacité à répondre aux besoins spécifiques à l’origine de la plateforme.

En effet, proposer un service permettant d’augmenter la productivité requiert le développement d’outils encore plus complexe venant s’ajouter au dispositif en construction. Il est peu probable qu’une entreprise dont l’activité n’est pas directement en lien avec la construction d’un tel software dispose des ressources suffisantes pour s’emparer d’un projet de grande envergure et le mener convenablement à son terme.

Conclusion

Construire un dispositif data entier est un projet souvent plus complexe et coûteux que prévu. Pour cette raison, il est nécessaire de définir très clairement ses besoins et de s’assurer que le ROI du projet soit particulièrement important avant d’entamer la construction d’un dispositif data.

Dans la majorité des cas, il sera possible de trouver une solution existante répondant à ces besoins et de constater que la mise en place d’une telle solution offre un retour sur investissement plus important. Nous conseillons donc de s’orienter vers de telles solutions qui permettront des économies de temps, d’argent et de ressources.