Patrick Chatain, VP Engineering chez ContentSquare : “penser davantage amélioration continue que révolution constante”

Tout sourire, Patrick m’accueille pour un après-midi dans leurs récents locaux du quartier de la Madeleine. ContentSquare a levé 42M de $ en début d’année et se retrouve avec de nouveaux enjeux de taille et de croissance. A l’instar de Datadog (voir leur interview), ils arrivent aux limites des solutions classiques qui répondent bien aux besoins du plus grand nombre. Des contraintes qui les poussent à innover et prendre davantage de risques dans leurs choix techniques. Après tout, c’est la rançon de la gloire ? Pour la première fois j’aborde l’interview avec une légère connaissance de l’architecture de la solution. En effet j’ai eu le plaisir de rencontrer l’équipe lors du meetup ClickHouse organisé en leurs locaux il y a quelques semaines à peine (cherchez pas, vous l’avez loupé). Découvrez pourquoi et comment ce DBMS encore confidentiel est devenu le nouveau pilier de l’architecture de ContentSquare.

 

Patrick, tu es VP Engineering chez ContentSquare depuis 1 an, peux-tu nous parler de toi et de ton parcours ?

Après une formation à Supélec, j’ai démarré ma carrière en tant qu’architecte réseau IP, donc pas du tout du dev. Je suis resté dans ce domaine pendant 12 ans, j’ai travaillé sur les sujets d’innovation de l’époque comme l’internet sur les mobiles avec le wap/i-mode, la modernisation des réseaux telecom et triple play. J’étais un peu frustré de ne pas être assez proche de la technique. Dans les télécoms on fait de l’assemblage de briques qui reposent sur des fournisseurs mais on ne conçoit pas soi-même les solutions. J’ai donc commencé à développer à cette époque et j’ai créé un store de BD numérique : BDBuzz. C’était juste avant la sortie de l’ipad en 2010, ça a plutôt bien marché, mais le marché de la BD en ligne un peu moins !

J’ai quitté l’aventure et je suis entré comme CTO chez FullSix, une agence spécialisée dans la data, où j’étais en charge de l’équipe de dev. J’y suis resté 4 ans, c’est là que j’ai découvert le marché de la data. Le métier d’agence n’était pas ma tasse de thé : je trouvais ça frustrant de construire des projets pour des clients et qu’ensuite cela m’échappe.

Quand j’ai découvert ContentSquare et la solution, ça a été une évidence pour moi : la réponse exacte à tous les échecs que j’avais eus avec FullSix pendant les 4 ans qui ont précédé.

C’est comme si on appliquait le plan de tag à la volée sur l’arriéré de données et qu’on obtenait immédiatement le résultat.

De quel point de vue ?

Pour tous les projets data, je rencontrais la même problématique. Au départ le client ne sait pas trop ce qu’il veut faire : on lui construit une solution technique, on collecte de la data, on la structure, on la modélise et on imagine des use cases. Mais le client est souvent dans l’impossibilité d’imaginer et définir ses cas d’usage en amont. Une fois que tout est prêt, qu’il est en situation, il voit les choses un peu différemment, parce qu’il commence à tester et à utiliser. On n’est jamais dans le bon tempo : on lui dit « ok, il faut qu’on retravaille ». Ca prend 1 à 3 mois avant qu’on revienne le voir et entre temps son besoin a encore évolué.

 

C’est comme cela que tu positionnes la solution ContentSquare ? Itérer sur le design d’un produit ?

La solution permet d’analyser l’expérience des clients sur les sites web et applications mobiles. On peut analyser les parcours utilisateurs, les endroits où ça transforme ou pas. C’est hyper visuel, utilisable par tout le monde dans une entreprise pour alimenter les décisions d’évolution. Toutes les métriques apparaissent  en surimpression sur le site ou l’application. L’intégration se fait par un tag javascript ou un SDK pour les applications mobiles.

ContentSquare permet de faire une chose unique : ne pas réfléchir en amont à ce qu’on veut analyser ce qui est une vraie force et une réelle différence. Je n’ai pas à taguer mon site en amont, laisser tourner pendant 2 mois pour collecter des métriques, constater ce qu’il se passe, réaliser que j’ai oublié de taguer certains éléments pour le cas d’usage qui m’intéresse et recommencer. C’est comme si on appliquait le plan de tag à la volée sur l’arriéré de données et qu’on obtenait immédiatement le résultat.

Les méthodes agiles ont un travers important : il manque une vision du projet de bout en bout

Vous collectez et conservez la totalité des données pour proposer toutes les combinaisons d’analyse possibles et imaginables ?

On collecte absolument tout : les mouvements de la souris, les clics, les hover, tout ce que fait l’utilisateur. On peut rejouer la vidéo si besoin. C’est la force de l’outil de tout collecter et de restituer la donnée avec l’analyse à la volée dans un temps très court. Quand je l’ai vu, ça m’a paru évident.

 

Tu as donc découvert la solution quand tu as été recruté ?

Oui, j’ai été chassé et j’ai rejoint une jeune R&D. Il fallait passer de la startup qui a construit un produit à la phase d’industrialisation. Nous avons de gros clients avec des contraintes fortes, il fallait changer notre manière de travailler. C’est un défi de gérer les changements techniques et délivrer en même temps de nouvelles fonctionnalités dans la roadmap.

Comme dans toutes les entreprises de nouvelles technologies, la technique est ce qu’il y a de plus critique et si on ne sait pas scaler, le business ne marchera pas.

Comment as-tu réussi ce changement : qu’as-tu mis en place à ton arrivée ?

Essentiellement de l’organisation. J’essaie de mélanger les méthodes classiques de pilotage vécues dans l’industrie et celles plus agiles et rapides des développeurs.

Dans le monde du dev on a tendance à rejeter entièrement une méthode pour en prendre une nouvelle sans conserver ce qu’il y avait de bon dans la précédente. Les méthodes agiles ont un travers important : il manque une vision du projet de bout en bout. On raisonne de sprint en sprint sans visibilité de ce qu’il se passera dans 2 mois.

La méthode en “V” a d’autres travers et notamment l’effet tunnel que tout le monde a bien compris. En revanche elle permet une meilleure anticipation et gestion des coûts. J’essaie de prendre le meilleur des deux mondes. En particulier, le rôle de Scrum Master était attribué à un développeur qui pouvait changer toutes les 2 semaines. J’ai renforcé ce pilotage de projet avec des chefs de projet techniques au-delà du scrum master et en anticipant mieux les phases de tests pour améliorer l’analyse de risque. Nos jeux de données sont gigantesques : si on n’anticipe pas et qu’en début de sprint on se demande comment tester, on se plante.

Le second point a été de remettre plus de management dans les équipes. Faire comprendre qu’un manager n’était pas le meilleur développeur de l’équipe et recruter quelques profils plus seniors.

Enfin on a beaucoup travaillé la communication pour mettre en lumière tous les chantiers techniques. C’était un défaut de la R&D où le travail sur la dette et les refontes d’archi étaient fait un peu sous le manteau. Personne ne comprenait qu’il fallait du temps pour faire cela. Expliquer les apports business a permis de re-mener des projets de fond sur l’architecture de manière plus sereine. Cette année on a revu l’archi pour passer en micro services côté application. On a re-fondu toute l’architecture du pipeline de données vers des solutions plus pérennes qui répondent à notre besoin de croissance.

Démontrer qu’il y a des intérêts business réels permet de gagner la confiance de tous et simplifie les arbitrages.

Cette idée de communiquer davantage sur les chantiers techniques est intéressante. Comment avez-vous mis cela en place concrètement ?

Notre unique roadmap contient les projets aussi bien techniques que fonctionnels. Ils sont arbitrés de manière similaire et au même niveau. Nous, R&D, défendons nos projets techniques dans les réunions d’arbitrage : pourquoi il faut les faire, combien ils coûtent et les impacts s’ils ne sont pas faits. On s’aperçoit qu’ils gagnent quasiment toujours. Comme dans toutes les entreprises de nouvelles technologies, la technique est ce qu’il y a de plus critique et si on ne sait pas scaler, le business ne marchera pas.

Il faut être très transparent sur la raison des projets techniques, ce qu’ils apportent et venir le prouver une fois que c’est fait. Démontrer qu’il y a des intérêts business réels permet de gagner la confiance de tous et simplifie les arbitrages.

Nous avons aussi tué le mot de “dette technique” qui était un fourre tout. Avant que j’arrive il y avait des sprints dédiés à cela. Le dev pouvait y passer 2 ou 3 semaines mais comme personne ne comprenait ce qu’on y faisait, le reste de la boîte considérait que c’était un temps donné pour nous faire plaisir, ce qui n’avait aucun sens. En même temps, de notre côté, cette dette était abordée sans être bien préparée, ce qui se traduisait souvent par des coups d’épée dans l’eau. On ne savait pas vraiment si l’on travaillait sur les bons sujets. Maintenant on identifie des projets, on les valide, on les porte et ça se passe beaucoup mieux.

 

Quels sont vos prochains challenges ?

Continuer à faire des calculs en quelques secondes sur des volumes toujours plus gros de données, sans que ça nous coûte trop cher. Je prends toujours l’image suivante : d’un côté il y a les datamarts avec des requêtes longues et compliquées où l’on accepte de voir le résultat sous 24h. De l’autre, les sites d’analytics où l’on définit à l’avance ce qu’on veut voir, permettant ainsi des résultats immédiats. Avec ContentSquare c’est un mix des 2 mondes : on fait des trucs compliqués, lourds et on veut le résultat de suite. Réussir cela tout en gérant la croissance, c’est notre plus gros challenge.

Les choix d’implémentation doivent intégrer les contraintes de croissance

Quelle architecture avez-vous mise en place pour répondre à cette contrainte ?

Notre pipeline de données est un enchaînement de mise en queue Kafka et de traitements pour  structurer la data. Tout la donnée est stockée sans pré-calculs dans des clusters Elastic Search sur lesquels des requêtes sont appliquées à la volée. Fonctionner sans pré-calcul est lourd et dangereux. Notre objectif demain est d’en ajouter un peu sur une archi où l’on sera capables de mieux gérer leur priorité.

 

Votre principal moteur de processing est donc Elasticsearch ? Quelle a été la raison de ce choix ?

C’était il y a 3 ans, je ne connais pas la raison exacte de choix mais je sais qu’ES répondait au besoin. A la base l’archi était entièrement basée sur Redshift avec de gros batchs de calculs par 24h pour calculer toutes les combinaisons possibles. La bascule sur ES a permis d’avoir une fraîcheur de la donnée en dessous de l’heure en faisant uniquement du calcul live. Depuis on a poussé le moteur au-delà des limites et même Elastic nous dit que nos Use Cases vont trop loin et ne sont pas adaptés à ce moteur.

On réfléchit à des architectures plus scalables et plus contrôlables. Sur ES on ne sait pas gérer la priorité des requêtes. Quand ES lance son calcul, il n’est pas possible de l’arrêter ce qui est gênant dans une archi scalable.

Après une étude de plusieurs mois, notre choix s’est arrêté sur ClickHouse et on travaille activement sur l’évolution de l’archi dans ce sens.

 

C’est un gros challenge : vous changez la plus grosse partie de votre stack technique ?

Notre archi changera tous les 3 ans car on grossit trop vite et les technos qui évoluent en parallèle offrent de nouvelles possibilités. Les choix d’implémentation doivent intégrer les contraintes de croissance. Avec des facteurs de 10, on ne réfléchit pas de la même manière. Si un coût de 100K double l’année suivante,  ça peut s’assumer mais s’il passe à 1M c’est plus grave.

 

Pourquoi le choix de ClickHouse ?

ES fait énormément de choses et nécessite donc de maîtriser une complexité dont on n’a pas réellement besoin. ClickHouse est une techno hyper simple basée sur notre use case, que l’on peut améliorer plus facilement. C’est important pour nous de rester sur un technologie opensource et les benchmarks de performance étaient excellents par-rapport aux autres bases de données.

Avec ES on a une contrainte sur le volume de données qu’on peut stocker par cluster. Non seulement on doit le dimensionner en terme de compute mais aussi en terme de stockage car tout va être monté en mémoire. Sur un cluster ClickHouse on peut mettre davantage de données pour un compute équivalent et donner accès aux 2 volants de dimensionnement : storage et compute. Le gain financier attendu est très important.

Un dev ne devrait pas être attaché à une techno mais les connaître assez pour prendre celle qui correspond le mieux au besoin

Quel est le use case type pour ClickHouse ?

Je ne suis pas le plus calé pour en parler ! C’est une base de données orientée colonne pensée pour l’analytics. La solution permet de gérer les priorités et les ressources par type de requête. Elle est développée en C++ et on n’a pas l’hérésie de tourner sur des JVMs alors qu’on veut de la super haute performance pour le coût le plus bas.

 

Tu parles des performances des requêtes : faites-vous aussi du stream processing pour améliorer la prise en compte des données live ou certains indicateurs majeurs du dashboard utilisateur p.ex ?

A partir du moment où le client fait sa config : “ je veux voir le taux de clic pour telle zone pour les utilisateurs qui sont passées par telle page et qui ont fini par transformer un panier”, on va calculer le résultat en live sur la donnée brute.

Nos jobs Spark tournent et insèrent la donnée toutes les heures. Cela nous amène à 1h de décalage entre les events du clients et la disponibilité des données pour analyse. La piste du stream processing n’a pas été envisagée : on a besoin de consolider les données sur des plages de temps qui peuvent être assez longues puisque liées à la session de l’utilisateur. Même si on faisait du stream processing on serait obligés de consolider par batch pour corréler les informations relatives à une session.

Le métier se satisfait assez bien d’avoir 1h de décalage sur la mise à disposition des données.

 

Votre solution est utilisée à l’international, proposez-vous plusieurs points de présence ? Comment avez-vous prévu de fonctionner de manière globalisée avec ces clusters ?

Nous proposons des points de présence aux US et en Europe. Notre présence dans différentes régions est nécessaire pour des besoins légaux de stockage de données plus que pour des problématiques de performance ou de latence.

Ce lab dirigé par notre CTO Mathias est finalement très intégré aux équipes de dev. Il permet de ne pas démarrer un projet de manière industrielle tant qu’on n’est pas sûrs de nous et de ce ce que l’on veut faire

ContentSquare est une solution SaaS : où et comment êtes-vous hébergés ?

Nous sommes chez AWS aujourd’hui et on est en train de travailler sur un hébergement alternatif .

On ne veut pas être dépendant d’un seul cloud provider et certains de nos clients ne veulent pas être chez AWS.

 

Utilisez-vous des services managés ?

Assez peu : on utilise S3 évidemment, RedShift côté Datamart et Athena un peu à la marge.

 

Quelle sera votre stratégie pour tourner chez différents cloud providers en ce qui concerne les services managés comme RedShift ou Athena ? Partirez-vous sur des services propriétaires quitte à gérer 2 bases de code ou allez-vous redescendre d’un cran et gérer vos propres clusters ?

L’idée est plutôt d’avoir une seule base de code et la grosse dépendance qu’on voit c’est celle du stockage type S3. Sauf gros bénéfice, on préfère ne pas utiliser de service managé.

Aujourd’hui nous sommes déjà très peu dépendants de ceux-ci et ClickHouse représente le cœur de notre solution : donc c’est un choix qui est simple. Pour le storage, on ne va évidemment pas le re-développer. Pour Kafka, Spark et EMR, la question pourra se poser. On est en train de passer sur Terraform aussi qui simplifiera le déploiement chez les différents cloud providers.

En tant que VP je pousse les gens à réfléchir à la pertinence d’utiliser des services managés quand c’est possible. Suivant les entreprises, il y a des ADNs différents, historiques et pas forcément très rationnels. C’est un point sur lequel on a besoin de s’améliorer car notre culture est plutôt de tout faire nous-même.

Il y a 100 000 choses à faire mais on réussira si on prend en charge les 10 000 bonnes sans se perdre

Sur les tendances : conteneurs, kubernetes : quel est ton avis ?

Je trouve qu’on parle trop de ces sujets d’un point de vue technique et pas assez pour ce qu’ils apporteraient d’un point de vue business. On se convainc que ce qu’on fait depuis des années ne fonctionne plus du tout au point de le remettre entièrement en question.

Le changement corrige des problèmes mais on perd aussi des trucs qui fonctionnaient. Les métiers techniques devraient penser davantage amélioration continue que révolution constante. Je suis assez mal à l’aise par-rapport à ces choix et les push sur le sujet.

Chez ContentSquare on ne fait pas de conteneurisation à ce jour mais comme on tourne sur beaucoup de petites VMs cela peut coûter cher. C’est pourquoi on réfléchit à utiliser K8s dans une optique de mutualisation de services sur une même machine qui permettrait de faire baisser les coûts. Je pense notamment aux scénarios de dev/test : on a beaucoup de modules différents ce qui nous amène facilement à une trentaine de VMs. Si on peut conteneuriser et déployer sur une ou deux machines un peu plus grosses, le gain financier est avéré.

 

Quelle est la dernière techno que tu as kiffé ?

Je suis bien content que ClickHouse soit développé en C++ permettant ainsi des performances maximales. C’est un peu vieux jeu de dire cela mais je trouve qu’on n’utilise pas assez les bonnes technos pour les bonnes choses. Node.js c’est fantastique mais y’a plein de trucs qu’on fait avec qui ne devraient pas l’être. Idem pour Java.

 

Quels langages utilisez-vous chez Content Square ?

Node.js, scala, python. Beaucoup de difficultés découlent d’un choix de technologie fait simplement parce qu’on a envie de travailler avec. On utilise python et scala avec Spark côté data engineering. Pour faire du calcul parallèle, scala c’est une très belle technologie mais on l’utilise aussi pour coder des APIs alors qu’on pourrait très bien le faire en Java. Un dev ne devrait pas être attaché à une techno mais les connaître assez pour prendre celle qui correspond le mieux au besoin. Ces “religions” font faire à l’industrie de mauvais choix.

 

Où mets-tu le curseur ? En le poussant à l’extrême pourrait-on imaginer que chaque besoin reposerait sur une techno différente ?

Clairement il ne faut pas 10 technos différentes dans sa stack mais rationaliser avec quelques-unes car ce n’est effectivement pas réaliste d’être experts de tout.

 

Qui fait le choix de la techno pour implémenter une brique ? Comment êtes-vous organisés ?

Globalement les choix sont faits par les équipes ainsi qu’un tech board auquel on vient présenter les choix qu’on valide ensemble. Notre organisation est assez classique et chaque équipe d’ingénierie correspond à une partie de la solution.

  • Collecte de la donnée : développement des SDKs natifs et javascript pour le web,
  • Data engineering : pipeline de traitement, stockage et exposition des données
  • Application : celle que les clients auront dans les mains, la logique métier, la présentation, l’exploitation des données et la data viz.

Une équipe plateforme vient en support pour l’hébergement, le CI/CD et une autre équipe pilote les projets transverses. Cela représente 50 personnes plus un Lab d’une dizaine de personnes.

Tous les projets qui ne sont pas cadrés fonctionnellement ou techniquement passent par le Lab pour être dégrossis et éventuellement lancer un POC. On y trouve des data scientists permanents ainsi que différentes personnes des autres équipes qui collaborent. Ce lab dirigé par notre CTO Mathias est finalement très intégré aux équipes de dev. Il permet de ne pas démarrer un projet de manière industrielle tant qu’on n’est pas sûrs de nous et de ce ce que l’on veut faire. Avant sa naissance il y a 8 mois, ces projets atterrissaient rarement dans la roadmap car, mal définis, on finissait toujours par les arbitrer négativement.

 

Quelle est la prochaine techno que tu voudrais essayer ?

J’aimerais bien voir ce que donne Swift car on aurait vraiment besoin d’une nouvelle techno côté serveur. Javascript, ce n’est pas un cadeau  fait à l’industrie, c’est du bricolage. Merci au passage à Microsoft pour Typescript mais ca reste une surcouche qui rend le truc juste gérable ! On a besoin d’une techno plus solide et Swift pourrait être une réponse à cela.

 

Qu’est-ce que tu considères être le plus compliqué à gérer pour toi aujourd’hui ?

La croissance des équipes avec des attentes marché de plus en plus fortes. Croître en gardant des équipes motivées et un bon niveau technique, c’est très difficile.

Donner du sens aussi : je reste convaincu que le challenge pour des boîtes de notre taille est de se concentrer sur les bons sujets. Il y a 100 000 choses à faire mais on réussira si on prend en charge les 10 000 bonnes sans se perdre. C’est d’ailleurs valable à tous les niveaux de l’entreprise.

 

As-tu un fail à partager ?

Par rapport à ce qu’on a mis en place depuis 1 an on n’a pas encore assez de recul pour voir où on a dérapé. On est dans la phase sympa où l’on construit plein de trucs ! D’ici 9 mois il y aura plus d’éléments pour constater si ça marche ou pas, autant sur le plan organisationnel que sur les choix technologiques qu’on est en train d’adopter.

 

De quoi es-tu le plus fier ?

Notre capacité à changer. Je me souviens du 1er jour où je suis arrivé : comme souvent dans ce type de poste, c’est là qu’on se rend compte de l’étendue du travail à réaliser. Mais tout le monde était prêt à changer, à se remettre en question et ça m’a beaucoup rassuré. Il n’y a aucun frein, une recherche d’amélioration permanente et un super état d’esprit.

 

Comment t’imagines-tu dans 5 ou 10 ans ?

Je m’imagine faire autre chose…pourquoi pas passer dans d’autres domaines. Je suis resté 15 ans dans les télécoms, pourquoi pas 15 ans dans les nouvelles technos et ensuite partir sur un truc complètement différent. Mon métier de VP Engineering c’est 75% de management et 25% de technique. Pourquoi pas directeur des opérations par-exemple, ou du conseil aux jeunes entreprises.

 

Peux-tu citer une startup dont tu voudrais connaître le fonctionnement ?

Strava : c’est un réseau social sur lequel les utilisateurs poussent leur activité sportive. Ils ont un système de collecte des traces GPS et comparent les performances des utilisateurs sur des portions de celles-ci, en temps réel. Ce n’est pas une startup française mais c’est le service qui m’a le plus bluffé, je serais curieux d’en savoir plus d’un point de vue techno.

Les commentaires sont fermés.

Fièrement propulsé par WordPress | Thème : Baskerville 2 par Anders Noren.

Retour en haut ↑