ETL & Cloud Unique : connexion et hébergement sur mesure

La société Scal-e a été listée dans deux rapports de l’Institut international de recherche Forrester le “Now Tech: Customer Data Platforms, Q4 2021” pour la région Asie Pacifique (APAC) et le “Now Tech: Customer Data Platforms, Q1 2022” pour la région monde. Pour en parler, le site Martech.cloud a profité du lancement du nouveau site web Scal-e pour proposer une interview.

Témoin privilégié de la révolution opérée chez Scal-e depuis le rachat de la société en 2018, son CEO Christophe ALVES s’est entretenu avec Martech.cloud, blog majeur de l’innovation digitale. Christophe Alves nous parle de la société Scal-e, sa stratégie, l’évolution du marché, son équipe ou bien encore sa vision de l’avenir de l’entreprise.

Cet article et le 4ème d’une série de 5 entretiens publiés tout l’été 2022. Retrouvez les liens vers tous les articles en fin de page à la fin de l’été.

---

Unifier les données, mais pas seulement…

En effet, pour rendre ces données disponibles aussi bien aux équipes marketing qu’à des outils externes, il faut pouvoir les collecter, les traiter : c’est-à-dire les normaliser, parfois même les redresser avant de pouvoir unifier ou dédoublonner. C’est à cet effet que nous avons mis en place un ETL nativement connecté à notre CDP.

Et quand vous parlez d’ETL, vous voulez dire un outil comme Zapier, Segment, Integromat, Leadsbridge ou Mulesoft ?

D’accord, donc comme ces ETL ou IPAAS du marché, votre CDP a mis en place différents connecteurs standards ?

Christophe Alves : Oui en effet, d’ailleurs je vous invite à regarder la liste non exhaustive sur notre nouveau site web ! A l’image de notre stratégie pour les canaux de communication, nous profitons de chaque projet pour identifier de nouveaux moyens pour nous connecter, pour développer des connecteurs standards ou des connecteurs sur mesure.

Qu’entendez-vous par connecteur sur mesure ?

Christophe Alves : Alors, quand on parle de connecteur standard, on entend un connecteur auquel nous pouvons nous connecter en quelques minutes. À l’image grosso modo d’un utilisateur qui a besoin d’un login et password et qui pourrait remplir des préférences d’utilisation d’une solution.

Beaucoup d’outils permettent de modifier leur modèle de donnée. Par exemple, si on prend la plupart des CRM du marché, ils permettent de rajouter des objets ou champs au modèle de donnée initial. Le problème est que via leur API, ces CRM ne permettent pas toujours de récupérer les données des objets ou des champs ajoutés après coup. D’ailleurs si je peux me permettre un aparté, c’est pour cela que nous appelons notre API chez Scal-e une « API polymorphe ». 

C’est-à-dire ? Qu’entendez-vous par « API polymorphe » ?

Christophe Alves : Notre CDP permet la mise en place de modèles de donnée B2B, B2C ou même B2B2C sur mesure, et nous souhaitions faciliter le travail pour les équipes métiers. Donc sans aucune intervention, dès qu’un objet ou champ est paramétré dans la CDP, celui-ci sera accessible en lecture / écriture via notre API. D’où l’idée de polymorphisme car l’API s’adapte au modèle de donnée mis en place dans la CDP.

Nous avions déjà ce genre de demande sur le rajout de champ sur une fiche client ou de champ calculé comme pour l’exemple de l’âge. L’idée est que, dès que l’on ajoute un champ pour mapper de la donnée ou calculer une donnée, celui-ci, sans intervention sur la plateforme, puisse servir pour créer des segmentations, des scores, personnaliser des contenus ou recommander des produits.

Donc si je comprends bien votre approche, pour vous un connecteur sur mesure, sera un connecteur qui devra être mis en place ou adapté pendant le projet.

Christophe Alves : Exactement. D’ailleurs si je peux me permettre, beaucoup d’éditeurs annoncent des connecteurs standards et pourtant, ils indiquent qu’il faudra X jours pour les mettre en place. Ce qui peut se comprendre car une nouvelle fois, si le système avec lequel on doit se connecter ne permet pas facilement de récupérer toutes les données souhaitées, il faut alors adapter son connecteur ou trouver une autre technologie pour récupérer l’information.

Vous voulez dire en plus des connecteurs ?

Christophe Alves : Oui, exactement. Parfois pour se connecter avec une seule source de donnée, il faut utiliser un connecteur et pouvoir faire des requêtes en base de données.

Avez-vous un exemple en tête ?

Donc : rien que pour un site marchand, il faudra 2 outils/technologies différents. C’est l’une des raisons pour lesquelles nous avons souhaité développer un ETL nativement intégré à notre CDP.  Un ETL offrant différentes options en standard, tel que l’API polymorphe dont je parlais, les connecteurs, la capacité de requêter vers des bases externes ou d’importer des flux CSV afin de faciliter la collecte des données à mapper dans la CDP.

N’est-ce pas le cas de toutes les CDP du marché ?
Je veux dire d’offrir un ETL intégré et ce genre de flexibilité ?

Christophe Alves : Non, beaucoup de CDP d’une part viennent avec une approche « sur étagère ». Elles sont prêtes à l’emploi pour un type d’utilisation, on voit beaucoup de CDP par exemple orientées e-commerce. En gros, leur modèle leur permet de collecter des données comportementales ou transactionnelles des plateformes e-commerce, par exemple liées à Shopify. Ce sont de bonnes solutions, le problème commence lorsque la marque souhaite agréger plus de connaissances client en couplant cette CDP à d’autres outils, par exemple un outil de caisse, ou si demain la marque décide de changer Shopify pour  Prestashop, Magento ou tout autre outil de ce genre. Cela sera au mieux très compliqué, nécessitant de gros développements, et au pire une raison pour changer de CDP pour la marque.  Sachant de plus, que la plupart du temps, elles poussent à utiliser d’autres ETL / IPAAS dans ce genre de cas, car elles n’ont pas développé leur propre ETL. Là, le risque est le coût que représente le fait d’empiler les technologies pour la marque.

De plus, peu de CDP aujourd’hui intègrent nativement leur propre module de gestion de politique de confidentialité. Ils ont plutôt tendance à proposer des solutions complémentaires.

Donc avec une CDP Scal-e on ne peut pas utiliser une solution comme Didomi, Axeptio ou OneTrust ?

Christophe Alves : Non, ce n’est pas cela.

Tout d’abord notre philosophie est de dire à nos clients de ne surtout pas changer d’outils comme je l’expliquais, surtout s’ils sont satisfaits des solutions en place. Après, des solutions comme Didomi ou Axeptio, sont très bien et répondent à d’autres cas d’usage. Si une marque possède X site webs, si elle possède une activité offline (magasin par exemple) elle aura de toute façon besoin de connecter son CMS type Axeptio, Didomi à une CDP.

Pour OneTrust, c’est pareil. Même s’il est vrai que leur offre est un peu plus développée car ils vont plus loin que ce que propose un CMS. Maintenant, notre module privacy peut être utilisé en mode maître ou esclave. Si le client possède une solution comme OneTrust, il pourra bénéficier de notre capacité à récupérer ses paramétrages. Sinon, il pourra bénéficier de notre module. Car souvent le problème est bien sûr de pouvoir mettre en place sa politique de confidentialité et ensuite de s’assurer que tous les outils du SI puisse la respecter. C’est là où notre approche nativement intégrée, offre en standard de nombreux avantages. Car même si notre module privacy est utilisé en mode esclave, d’un outil maître développé en interne ou du marché comme onetrust, le fait est que notre plateforme intègre nativement tous ces mécanismes (effacement, anonymisation, blocage, portabilité…) car nous savons également les gérer.

Une histoire de clouds

Vous avez parlé au début de notre interview de Cloud unique ? Est-ce que cela veut dire que vous êtes en concurrence avec des solutions comme Snowflake ou BigQuery ou bien des hyperscalers comme AWS, Azure ou OVH vu que nous sommes entre Français ?

Christophe Alves : Non, pas du tout. Nous avons de nombreux clients, qui utilisent des Snowflake, BigQuery, Databrics etc afin de créer des datalakes ou même des datamarts. Une nouvelle fois, notre fonction sera de nous connecter à ces outils afin de récupérer les données qui permettront aux équipes métiers de mettre en place leur stratégie marketing de façon indépendante. Ces solutions sont très bien, il n’y a qu’à voir leur succès … maintenant un snowflake ou un bigquery, il faut se le dire, est plus adapté à un consultant IT, Data qu’à un responsable marketing.

Sinon pour ce qui est de ce que vous appelez les hyperscalers, vous parliez d’AWS, Azure, OVH mais il en existe plein d’autres, on commence à voir par exemple des clouds souverains. En fonction des pays, d’autres acteurs sont plus intéressants comme Alibaba cloud en Chine. Chez Scal-e on utilise ces acteurs soit pour héberger des données clients, soit pour héberger notre plateforme.

Donc nous sommes plutôt complémentaires et non concurrents !

Donc la base de données unifiée avec toutes les données de la marque peut être hébergée aussi bien chez le client (on premise) que chez un hébergeur de son choix ?

Christophe Alves : C’est exact.

Chaque client, se verra associer un serveur de données (tenant isolation) pour des raisons de sécurité et pour éviter par exemple le dataleakage. Ce serveur de données pourra être domicilié chez le client, ou chez un hébergeur de son choix ou pourra être infogéré par les équipes Scal-e.

Est-ce que le mode d’hébergement à un impact sur le coût ? D’ailleurs quel est le budget minimum à prévoir pour une CDP ?

Christophe Alves : Si on reste sur un hébergement de la plateforme Scal-e chez un hébergeur de notre choix, et si on parle uniquement de la localisation du serveur contenant les données unifiées : Non. Qu’il soit hébergé chez le client ou chez nous : ce choix n’impactera pas le prix. Nous avons souhaité offrir ce service afin d’éviter que cela devienne un critère impactant pour le client.

C’est ce qu’il me semblait avoir vu sur votre site au sujet du cloud privé proposé en standard.

Christophe Alves : Exactement.

---