kiss my frogs
Contribuer
Twitter Facebook LinkedIn RSS
[ Rechercher ]
Accueil Contribuer TwitterTwitter FacebookFacebook LinkedInLinkedIn RSSRSS

Cette interview très tech est la première de la série « Sous le capot ». Le but : jeter la lumière sur une communauté qui oeuvre à l’abri du regard des médias : le CTO et son équipe technique. Peu friands des projecteurs, perfectionnistes, méticuleux et discrets, ces héros du quotidien pratiquent plus volontiers meetups techniques avec ses bières-pizzas tièdes que les cocktails d’investisseurs arrosés de champagne. 

Ces gens-là sont clefs : je les aime et je les connais bien, car j’en fais partie et travaille avec eux dans le cadre de mon job d’architecte cloud. A force de discussions techniques passionnantes, j’ai eu envie de partager ce qui se passe sous le capot de boites qui font les gros titres dans la presse business. 

Par choix, les anglicismes, termes techniques et raccourcis de vocabulaire sont laissés tels quels – incontournables dans n’importe quelle discussion technique un peu réaliste 🙂

Hello Nicolas. Qui es-tu ? D’où viens-tu ?

Je suis Nicolas Helleringer. J’ai fait Supélec comme ma femme, Laure Nemée qui est CTO de Leetchi. Cela fait 3 ans que je suis chez Criteo, soit l’équivalent de 20 ans dans une autre société si l’on considère le nombre et la diversité des technologies. Je suis Engineering Director, c’est-à-dire responsable d’un département DevOps regroupant 14 équipes et 3 middle managers : ça fait 70 personnes au total.

« On ne cherche pas à savoir qui sont les gens, par contre on veut savoir ce qu’ils font »

Auparavant j’ai eu 2 grosses expériences. D’abord 7 ans chez Mappy où j’ai fait des bases de données géographiques, de la logique floue et l’infrastructure. J’avais déjà une double casquette entre le dev et l’ops et je n’ai toujours pas vraiment choisi depuis. Puis j’ai passé 5 ans dans une société de conseil que j’ai co-créée, pour aider les startups dans leur bootstrap.

Quel est le produit conçu par Criteo ?

Notre métier, c’est prédire l’avenir dans le secteur de la publicité et les intentions d’achat, de clic, de conversion. On ne cherche pas à savoir qui sont les gens, par contre on veut savoir ce qu’ils font, ce qu’ils cherchent à acheter, et ce de façon complètement anonyme. Imagine une matrice, composée en ligne de 1,3 milliards d’utilisateurs et en colonne, de 16 millions d’indicateurs possibles. Eh bien notre métier est d’y chercher des groupes de comportement.

C’est de la segmentation ?

Pas au sens habituel. On va détecter les groupes de façon dynamique, avec de l’évolutivité et de la mutation, au lieu de considérer des caractéristiques statiques comme par-exemple « les ménagères de moins de 50 ans ». Dans les faits, c’est de la descente de gradient : on recherche un minimum local dans une abscisse curviligne dans un espace de dimension 16 millions. C’est quelque chose qu’un cerveau humain n’est pas capable de se représenter.

Criteo c'est:
900 personnes sur le site de Paris

2700 employés dans le monde (dont 500 à la R&D)

Fondé en 2005

http://www.criteo.com/fr et http://labs.criteo.com/

Criteo est-elle encore une startup ?

Tout dépend ce qu’on appelle startup ! J’ai relevé récemment cette définition : « une boite à fort potentiel qui ne gagne pas encore d’argent ». Fort potentiel : oui, mais qui ne gagne pas encore d’argent, ça fait un moment que ce n’est plus le cas ! On est donc une startup « grown up ».

Une licorne alors, tu préfères ?

J’ai horreur de ce terme-là ! On est coté en bourse, donc ce terme ne s’applique plus à nous car on ne parle plus de valorisation potentielle mais réelle. Ensuite, juger la valeur d’une société en fonction de la quantité d’argent que des gens ont mis dedans… je trouve que c’est une analyse très limitée. Il y a d’autres indicateurs qui permettent de voir si une société va bien, le revenu, le ROI, etc… De ce point de vue, Criteo a toujours été au-dessus de nos prévisions depuis qu’on est coté en bourse (octobre 2013), fait très rare dans l’écosystème marketing et ad tech. En fait, si l’on somme l’ensemble des  valorisations boursières dans notre secteur, c’est moins que la valeur de Criteo aujourd’hui.

Pourquoi entend-on si souvent parler de Criteo comme d’une des “plus belles startup françaises” ?

Les gens nous voient toujours comme une startup car on se renouvelle en permanence, que ce soit sur le business ou la techno. On n’est pas à la même échelle que les géants tech et pourtant, on joue dans leur cour. Criteo combine un métier technique avec une forte croissance et un potentiel encore très fort à bouleverser le marché : on a encore moins de 20% de part de marché à ce jour.

« Dans les faits il n’y a pas de recette magique, les algos de machine learning sont connus. Ce qui fait toute la différence c’est l’exécution et donc l’équipe et son assemblage. »

En interne, ce qui caractérise le côté startup c’est l’état d’esprit, l’ambiance et la façon de bosser. On privilégie les idées ! Notre hackathon annuel en est une bonne illustration : certains produits Criteo sont nés de la volonté de quelques personnes, aussi bien côté produit que côté R&D. Par exemple, l’adaptation automatique des tailles des bannières est issue d’un projet du hackathon il y a 2 ans. Autre exemple : notre projet Darwin (depuis devenu Criteo Kinetic Design) qui ajoute de l’évolution génétique dans les pubs. De temps en temps elles « essaient des choses », elles mutent.

Parlez-vous librement de votre architecture et de vos choix technologiques ?

Oui, on fait beaucoup de meetups et de conférences : en ligne on trouve des tonnes de vidéos.

Dans les faits il n’y a pas de recette magique, les algos de machine learning sont connus, c’est de la régression logistique apprise en descente de gradient – presque un des premiers cours de data science. On utilise des technos très classiques : des web services avec IIS en C#, il y a plein de bouquins là-dessus. Ce qui fait toute la différence c’est l’exécution et donc l’équipe et son assemblage. Tu as beau suivre une recette de gâteau au chocolat, au final ce qui compte, c’est le tour de main.

Mettez-vous des briques en open source ? Qui d’autre a profité de ces contributions ?

Oui, par exemple BigGraphite avec Cassandra. Un des gros acteurs type GAFA nous a appelés à peine 2 jours après sa sortie sur github car ça les intéressait. Et principalement aussi les cookbooks.

Comment êtes-vous organisés ?

Engine (côté off-line), Platform (côté “on-line”), Infra, SRE (l’industrialisation). Voici le dessin que je fais à toutes les personnes que je vois en entretien d’embauche pour expliquer la R&D.

Comment fonctionne l’intéraction entre un site web et votre solution ?

Nos balises javascript placées sur les sites web de nos clients et publishers permettent de capter les événements provenant de l’utilisateur final. Ca remonte sur notre Web Service DIS développé en C# qui tourne sur Windows et IIS. De là, on va utiliser une double couche Memcached – car rapide – et CouchBase – car persistée ! Un événement arrivé côté service web va aussi générer un évènement métier qui part dans Kafka pour servir Hadoop côté « off line »: on est capable d’ingérer 8 millions de messages à la seconde. Sur les catalogues de produit et les données clients, on est passé sur Hadoop et NoSql depuis 2012.

Sur la partie web et « on-line », on repose sur Sql Server. 2 des 3 ingénieurs co-fondateurs viennent de Microsoft Research : on a commencé avec du C#, Windows et Sql Server. Aujourd’hui, on y est toujours pour les données métier et relationnelles: on a 300 serveurs configurés avec de la réplication et du Always On, et ça marche plutôt bien.

« On est nos propres hébergeurs. »

Le seul service web ouvert à l’extérieur qui n’est pas en C# c’est PIX qui traite les images pour les bannières et qui est fait en Scala sur du Mesos avec Marathon.

Quel format utilisez-vous pour interagir avec les catalogues de vos clients  ?

Pour les fiches produits, c’est le format de catalogue de Google qui est incontournable pour nos clients. Pour la problématique de la volumétrie, on met tous les catalogues dans Hadoop et on crunche dedans. Contrairement à la partie connectée à Internet décrite plus haut qui est utilisée par les end-users et nos clients, la partie Hadoop, c’est du “off-line” qu’on traite en Batch. Pour stocker et traiter tout cela, on est nos propres hébergeurs : on loue les locaux mais c’est nous qui faisons tout le reste. On passe par des prestataires locaux pour la maintenance.

Pourquoi avez-vous vos propres datacenters ?

Pour les enchères en temps réel, on doit répondre en maximum 100ms : l’implantation de chacun de nos DCs a été pensée pour être proche des réseaux RTB (real time bidding). On vise un horizon de 20 à 30ms maximum A/R (on compte 20ms/2000 km). Nous prenons 10 à 15ms : la moitié d’un DC dont on ne choisirait pas la localisation. Il nous resterait 40ms pour du boulot intelligent contre 70ms aujourd’hui ! Les « spots » RTB sont clairement : New-York, Californie, Paris, Amsterdam, Shanghai, Tokyo, Hong-Kong. Mais aussi, quand on est dans un environnement Cloud, on a besoin de virtualisation, c’est le principe du multi-tenant. Notre DC nous est entièrement dédié, on gratte aussi de la latence sur ces couches.

Je comprends les contraintes sur la partie temps réel et retargeting, mais pour le reste ?

Aujourd’hui cela nous coûte moins cher car l’effort de mise en œuvre des DCs a déjà été réalisé. Néanmoins, on se repose la question tous les 6 mois. Mon architecture big data par contre, je pourrais la mettre partout dans le monde du moment que j’ai une bonne connectivité. En ce qui concerne les clusters Hadoop : ils sont utilisés à 100%, 100% du temps, donc on ne profiterait pas de l’économie permise par l’élasticité des clusters dans le cloud. Pour le « back », on a des clusters de 1000 machines à Amsterdam et 1300 autres deux fois plus grosses à Pantin. En Europe on ne connaît pas d’autre acteur privé plus gros, même pas Yahoo qui est très “fluent” Hadoop : on joue avec les limites de ce système.

« Tirer des câbles, c’est un métier à part entière que très peu de gens font, on n’est pas Google ! »

En revanche on discute régulièrement avec AWS et Microsoft : l’usage du cloud nous permettrait d’avoir une capacité de débordement. Cela concerne surtout la partie dev, test et intégration, très sujette aux charges ponctuelles. Aujourd’hui on est obligé de prévoir très en amont si l’on veut faire grossir un DC et cela nous force à avoir une marge pour absorber les pics. Les hackathons par exemple, sont faits entièrement dans le cloud.

Côté connectivité réseau cette fois ? Etes-vous également sur une infrastructure dédiée ? Tirez-vous vos propres câbles ?

Ça, c’est un métier à part entière et très peu de gens tirent leurs propres câbles, on n’est pas Google !

« On a commencé avec une équipe très orientée Microsoft et aujourd’hui, 12 ans plus tard, on est complètement techno-agnostique. »

On a des partenaires d’interconnexion dans les différents DCs, et un réseau privé entre nos DCs qui est redondé. On a une boucle à 100Gbps entre nos 3 DCs aux Etats-Unis. Sur le reste on est surtout à 10Gpbs et encore un peu de 1Gbps qui tend à disparaître. On a des points d’interconnexion avec les FAI et on fait à la fois du peering et du routage de trafic.

Parlons de l’architecture de votre solution et de vos technos !

Si on schématise il y a une partie Machine Learning « lente » qui calcule des modèles mathématiques. Ceux-ci sont utilisés ensuite en production via les web services et sont capables de réagir de manière « rapide » en 5 à 6 ms.

On n’a pas de religion en technologie. On a commencé avec une équipe très orientée Microsoft et aujourd’hui, 12 ans plus tard, on est complètement techno-agnostique. Clairement côté back c’est Hadoop et donc HDFS. L’ordre de grandeur pour la capacité de stockage c’est la centaine de pétaoctet (redondance comprise). Pour l’exécution on a du yarn avec du map/reduce pur, du scalding en scala, et alors là, accroche-toi bien : du C# avec Mono (beaucoup ! pour des questions d’héritage). Par ailleurs on attend .Net Core avec beaucoup d’impatience. On a aussi du Spark over Yarn, du python natif avec quelques libs et les stacks classiques du machine learning. On a un scheduler spécial pour enchaîner les phases de transformation de la data pour le billing et la BI : le scheduler yarn n’était pas suffisant en termes de garantie de convergence dans les temps quand il essayait d’enchaîner les tâches sur un pipeline.

Tu parles notamment de C# sur Mono pour l' »exécution » Hadoop : comment accèdes-tu à la data depuis C# ?

On la lit directement, c’est du JSON gzipé. Mais on est en phase de transition pour passer à du protobuf pour des problématiques de taille, de performance, de gestion des schémas et pour assurer une meilleure cohérence. On a aussi du Parquet.

Ca fait un gros volume d’informations : sur quelle fenêtre d’historique travaillez-vous ?

On suit la réglementation en vigueur (maximum de 13 mois) mais la plupart de nos processus n’en ont pas besoin. Le comportement qu’une personne a eu il y a 6 mois n’est pas pertinent pour nous aider à déterminer la prédiction d’un clic, maintenant. La donnée d’aujourd’hui a tellement de valeur par-rapport à celle du passé ! Par contre, on a la capacité de faire du split testing ou de l’AB testing en prod, mais aussi off-line ! On sait calculer quel impact un algo aurait eu dans le passé : on en fait plusieurs centaines par semaine pour tester nos modèles mathématiques avant de les passer en production.

Au-dessus d’HDFS, as-tu un modèle de données intermédiaire pour exploiter tes données comme par exemple pour la BI ?

Oui, on a une capacité Hive ouverte à la BI côté produit et finance et après ça on a Vertica de chez HP et un serveur de reporting Tableau. Donc on est capable d’avoir du reporting automatique, des requêtes avec Vertica et potentiellement utiliser Hive pour revenir plus à la donnée source si besoin. Cela permet à chaque équipe d’interagir avec le système selon leur besoin et le profil métier de chacun.

Parlons devops : tu es plutôt « conteneur » ou « pas conteneur » ?

Ca sert à rien les conteneurs ! En fait c’est surtout que je n’ai pas besoin de densité applicative, c’est plutôt l’inverse. Bon, dans les faits, c’est vrai et faux avec le dernier projet qu’on a fait.

Et côté industrialisation ?

Notre outil c’est Chef : quand on a commencé, Ansible n’était pas mature et Chef était le meilleur pour faire à la fois du Windows et du Linux. On utilise aussi Cassandra, Elastic Search et Graphite pour tout ce qui est logs et dashboard de monitoring. On a eu des problèmes d’échelle avec Graphite ce qui nous a forcés à développer une solution open-source qui scale mieux sur Cassandra. On s’occupe aussi de toute la chaîne de Build pour toute la R&D. On fait 300 revues de code par jour : pas une seule ligne n’arrive en production sans avoir été relue 2 fois par 2 personnes différentes. Ensuite on fait des tests unitaires, tests d’intégration, fonctionnels, end-to-end. On passe en pré-production où on rejoue les évènements de la veille, puis en production d’abord avec des services « canaries ». Puis on passe ça à 5%, 10%, 25% du pool pour le rollout final. C’est très cadré, très automatisé : le rollout et le rollback se font sur un clic de bouton. En cas de souci en production, on a une équipe d’escalade dédiée.

Quel contrôleur de sources utilisez-vous ?

On est sur Git, et on utilise Gerrit, l’outil de code review de Google. C’est du compile from source, l’inverse de GitFlow. On n’a pas de gestion de version composant par composant, à chaque commit ça lance un build de 6 minutes : on recompile tout pour s’assurer que tout fonctionne ensemble. Pour le « service discovery », on utilise Consul.

Vous êtes sur une méthodologie agile ? Type Scrum, avec un Product Owner, etc. ?

Oui en principe mais on n’impose pas. Une équipe, c’est au minimum 3-4 personnes et max 8. Le deal avec les chefs d’équipe est le suivant : 50% de management / 50% de contribution technique sur le projet.

Avez-vous une roadmap ? Comment décidez-vous qui travaille sur quoi ?

L’équipe Produit travaille sur un plan à 9 mois. Par trimestre, on a droit à 3 objectifs qui peuvent servir à des besoins internes, de la dette technique ou un planning au niveau Produit.

Peux-tu me donner un exemple concret ?

L’équipe Produit a souhaité faire « Universal Match », c’est-à-dire appliquer un chemin utilisateur quel que soit le device utilité par ce dernier : une pub peut arriver sur son PC et le clic peut se faire sur son mobile. Côté faisabilité et POC, ça a drainé aussi bien dans les équipes Engine, Platform, qu’Infrastructure, puis le schéma d’architecture a été validé. On n’a pas d’architecte, on a une mailing-list : tout le monde peut s’y inscrire. Tout projet qui doit passer en phase réelle fait l’objet d’un kick-off : est-ce faisable, le lance-t-on ou pas ?  Les gens qui ont un avis répondent et participent au kick-off. Il y une short-list de sponsors (les membres du comité de direction de la R&D “TechLeaders”) qui valident et donnent le go. Mais de manière générale c’est très collaboratif et on fait confiance aux gens.

As-tu un fail à partager ?

Criteo est parti sur une technologie NoSQL en particulier en 2013 : ça marchait bien, on l’a mis partout et puis on a franchi un cap d’échelle et là, ça ne marchait plus. Il nous a fallu 2 ans et demi pour éponger la dette technique. C’est un vrai échec de gouvernance : de ne pas avoir, vu, testé, su…

« On fait 300 revues de code par jour : pas une seule ligne n’arrive en production sans avoir été relue 2 fois par 2 personnes différentes. »

Ensuite on a quelques essais en mode incubation provenant des hackathons qui n’ont pas fonctionné, soit parce que le projet n’a pas rencontré son marché ou que les mises à l’échelle ne se passaient pas bien.

Il peut y avoir des freins ou des frustrations : par exemple le rollout du cluster Hadoop de Pantin qui prend plus de temps que prévu. On a la chance d’avoir des équipes brillantes : quand il y a des problèmes on a beaucoup de ressources pour les résoudre.

Justement comment recrutez-vous ?

D’abord on a un marketing « marque employeur » : on participe aux conférences, on parle de nos technos pour montrer qu’on fait des choses intéressantes. Ensuite, le sourcing est traditionnel avec LinkedIn, les réseaux sociaux, github. A un moment, on a organisé des concours de programmation mais ça génère beaucoup de travail.

« De manière générale, on est très collaboratif et on fait confiance aux gens. »

Le protocole débute par 1 ou 2 entretiens Skype : on fait de plus en plus attention à ne pas faire de présentiel trop tôt pour ne pas faire déplacer les gens de trop loin, notamment quand on recrute à l’international. Ensuite le candidat passe 4 entretiens selon sa spécialité technique. On ne demande pas de bachotage, on cherche à savoir comment il réfléchit, s’il sait exprimer ses idées et s’il arrive à échanger avec nous.

Pour proposer un article à KMF…

Est-il possible de travailler à distance ? Du home office une partie de la semaine ?

Non, car le cadre législatif ne le permet pas facilement. Surtout, travailler ensemble a trop de valeur, tant pour l’entreprise que pour les gens. On a 30 bureaux dans le monde. La R&D est répartie entre Paris, Palo Alto, Grenoble, New-York, Ann Arbor près de Détroit, mais la majorité du personnel se trouve à Paris. On peut travailler en remote avec des équipes constituées mais la présence dans les locaux est primordiale.

La dernière techno que tu as kiffé ?

Consul et celle d’avant c’est Kafka.

Conseillerais-tu Consul aussi pour de petits projets ?

Consul oui, c’est facile à mettre en oeuvre et l’intégration est simple côté DNS. Par-contre Kafka, moins, à cause de la gestion des mirrorings, brokers, etc. Les gens l’utilisent à la place de RabbitMQ pour de mauvaises raisons.

La prochaine techno que tu voudrais essayer ?

Ce sera probablement Go et j’ai commencé à installer ce qu’il faut pour ça mais je crise déjà sur le packaging de Google…

Que considères-tu être le plus compliqué pour toi aujourd’hui ?

Le recrutement. C’est difficile de trouver des gens formés au niveau que l’on attend.

Un argument pour donner envie de bosser chez Criteo ?

Travailler avec des gens brillants et progresser, j’ai des feedbacks incroyables de personnes qui ont fait 15 boites et qui n’en reviennent pas du rapport d’entraide et de la cohésion d’équipe.

Le truc dont tu es le plus fier ?

Les équipes ! L’attention portée par le management à l’évolution des gens : on est une société people-centric. Je suis content de faire partie des gens qui pilotent de cette manière-là.

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

Il y a largement de quoi faire chez Criteo d’ici 5 ans. 10 ans, c’est trop loin : ce qui m’intéresse, c’est de travailler avec des gens qui ont envie de faire des choses, ensemble. Être dans le management et aider les gens à faire des choses.

Peux-tu citer une startup dont tu souhaiterais connaitre l’architecture pour une prochaine interview ?

Leetchi : c’est très intéressant de voir comment monter une banque en ligne. Et puis je connais bien sa CTO 🙂

Summary
Criteo : "On n'a pas de religion en technologie"
Article Name
Criteo : "On n'a pas de religion en technologie"
Description
Interview de Nicolas Helleringer Engineering Director chez Criteo. Cette interview très tech est la première de la série "Sous le capot".
Author
Publisher Name
Kiss My Frogs
Publisher Logo
Les commentaires sont fermés pour cet article