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

Pour réaliser l’interview de LeBonCoin, j’ai naturellement pensé à Stéphanie Baltus que je connaissais comme leur Data Lead. Elle m’annonce alors qu’elle vient tout juste de quitter LeBonCoin pour rejoindre JobTeaser, une startup de 80 personnes « qui monte, qui monte ! » dans le domaine RH. Dans cette interview à deux voix, où l’on retrouve le CTO de JobTeaser Romain aux côtés de Stéphanie, Data Engineer, il est question des défis techniques et stratégiques d’une startup en plein essor. Et où parfois les codes s’inversent : serait-il plus épanouissant de coder que de manager ?

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 🙂

Stéphanie Hertrich : Romain, qui es-tu, d’où viens-tu ?

Romain Champourlier : Je suis Romain Champourlier, CTO de JobTeaser depuis 4 ans.

J’ai fait une école d’ingénieur –  l’ENSI de Caen – avec une spécialité en sécurité et transactions bancaires. J’ai commencé mon parcours professionnel dans un petit cabinet de conseil où j’étais en mission chez BNP Paribas. J’ai appris la gestion de projet classique, à l’ancienne avec le cycle en V mais ça a été très formateur et m’a permis d’acquérir de bonnes bases. J’ai eu envie de repartir davantage dans la technique et l’entrepreneuriat : j’ai passé 3 ans à essayer de monter des projets seul ou avec des associés, mais rien n’a vraiment décollé. En parallèle, j’ai été chassé par Urban Linker pour entrer chez JobTeaser. On me proposait d’être CTO dans une boite qui avait la maturité que j’essayais d’avoir avec mes projets, c’était juste parfait !

Stéphanie, peux-tu te présenter à ton tour ?

Stéphanie Baltus : J’ai commencé par la gestion avec un DUT GEA et un Master MIAGE : difficile de commencer le Java à ce niveau mais quand on a envie, on y va ! J’ai initié ma carrière dans la BI avec un passage à la SNCF puis je suis restée en SSII quelques années. J’ai pu toucher à pas mal de domaines : le luxe, l’industrie…et de technologies (Microsoft, IBM, etc). J’ai ensuite été embauchée chez LeBonCoin en tant que chef de projet BI technique, pour y monter l’équipe.

Nous avons pu livrer une stack BI, mais tout ce que j’avais mis en oeuvre auparavant était inutilisable au regard des volumétries qu’on peut rencontrer chez LeBonCoin ! Je me suis retrouvée face à des challenges inédits. Par exemple, on est arrivé aux limites des solutions classiques comme Pentaho ou PostgreSQL : notre datawarehouse faisait alors 7 To.

On s’est penché sur les technologies Big Data et on a sorti une architecture cible servant aussi bien les besoins business et d’agilité que ceux du produit. On s’est pas mal amusés avec la stack AWS, Elasticsearch, Spark, Airflow que j’aime beaucoup. Je suis devenue de plus en plus manager et chef de projet alors que j’avais de plus en plus envie de mettre les mains dedans ! C’est comme cela que je me suis retrouvée tout récemment chez JobTeaser. Je suis là pour mettre en place une architecture scalable qui va répondre à nos besoins d’expansion.

Pouvez-vous présenter JobTeaser ?

Romain : JobTeaser existe depuis 2008 et a bien grossi puisque nous sommes maintenant 80 employés dont 30 à la R&D. A la base c’était un media RH et diffusion de marque employeur, avec l’objectif d’aider les étudiants à faire le choix de leur stage et leur premier emploi. La croissance était assez tranquille jusqu’au pivot en 2013, où l’on est passés en SaaS et à une plateforme à destination des universités. Aujourd’hui on a 3 interlocuteurs : les étudiants, les écoles et les entreprises. Ce sont ces dernières qui financent tout ce modèle en diffusant leurs offres d’emploi et leur marque employeur. Ce virage s’est associé à une levée de fond de 3M en 2015 et c’est ce qui nous a permis d’accélérer. On a levé à nouveau 15 millions en mai pour continuer notre développement sur le marché européen.

Quels sont vos enjeux tech ou business majeurs ?

Romain :  Côté dev et produit, nos enjeux sont de répondre à la stratégie de conquête de l’Europe. On est leader en France, mais à l’étranger il nous reste des écoles stratégiques à conquérir. Sur l’expérience utilisateur, on est meilleur que nos concurrents.

Stéphanie : Côté data c’est l’IA, et construire une stack qui supportera une expansion internationale : je ne suis pas sûre que l’architecture actuelle tiendra si on gagne 80% des écoles européennes !  On veut être scalable sans pour autant créer de la complexité pour rien.

Tu me parles d’IA: cela signifie que tu utilises du machine learning ou plus largement des technologies de Data Science dans la solution ? Cela vous permet-il de vous différencier de vos concurrents ?

Romain : C’est dans nos ambitions. On a fait un test de ML l’été dernier mais ce n’est pas en production. On en utilise ponctuellement quand par exemple on a des offres à classifier. En effet, aujourd’hui les offres d’emploi que l’on diffuse proviennent de sources diverses  : de recruteurs, de partenaires et aussi de crawling de sites corporate. Nos offres arrivent souvent avec peu de métadonnées, ce qui ne nous permet pas toujours de rattacher une offre à une fiche métier : c’est ce que nous permet de faire le ML aujourd’hui. On utilise des algorithmes assez classiques de classification en python et des solutions pré-packagées. Nous sommes persuadés qu’on aurait une grande valeur ajoutée à traiter des flux événementiels avec du machine learning, et c’est la direction que l’on souhaite prendre. C’est un sujet qui est porté par l’équipe data : les data engineers préparent le socle pour stocker la donnée et les data scientists construisent les algos, les approches de ML et d’analyse de données un peu poussées.

Comment a été conçue votre solution web et avec quelles technologies ?

Romain : Notre équipe est très backend avec du Ruby on Rails. On a recruté un développeur frontend il y a peu pour travailler sur du Single Page Application (SPA) et dialoguer avec des APIs, plutôt que de faires des pages rendues côté serveur. On switche vers de l’API-first et un développement d’application web en JS, react.js et redux. Le choix d’angular ne s’est même pas posé : personne ne voulait en faire dans l’équipe.

Côté mobile on est en train de faire développer une application react native en externe. On pourra ainsi s’approprier la solution assez facilement sans devoir repartir dans des patterns ou langages spécifiques. Notre stratégie initiale était le développement natif, mais on a eu du mal à recruter des développeurs iOS, Android et on a perdu un peu de temps. Ca s’est avéré être une chance, car à l’époque react native n’était pas aussi mûr qu’aujourd’hui et on préfère largement ce choix au final.

Côté base de données c’est du mySQL et pour la recherche dans l’application on utilise Elasticsearch, tout cela sur des serveurs loués chez un des grands hébergeurs du marché.

Aujourd’hui notre application a  un scope fonctionnel large :  on atteint les limites avec nos choix d’architecture sur ruby on rails. L’application a 8 ans, c’est toujours le même code, et on n’a jamais fait de refonte du site, donc ça fait partie de nos challenges aujourd’hui. Il faut se rappeler qu’on a commencé comme un media qui s’adressait à une audience, et maintenant on est devenu une un véritable outil pour les écoles. On va devoir faire des compromis, car on ne peut pas faire de freeze dans notre croissance fonctionnelle, et pourtant, il y a des choses qu’il faudra repenser tant du point de vue business que technique.

Comment envisagez-vous ce découpage à terme ?

Romain : On réfléchit d’abord en terme d’organisation, en suivant la logique de la loi de Conway : ton organisation dirige ton architecture de code et réciproquement. Comme on a fait bouger l’organisation en la structurant autour des produits – une partie Offre, une partie Career Services pour les écoles et universités, un espace Entreprise et marque employeur, chaque produit correspond à une sous-partie du site et à des utilisateurs différents. On va donc découper l’architecture par produit, avec des équipes dédiées appelées “tribus”. On est convaincu que ça permettra à ces 3 grosses briques de ressortir de ce monolithe comme des services indépendants. On se verrait bien avoir un data analyst dans chacune des tribus qui aiderait le produit au quotidien avec une vision BI et analytique que le produit n’aura pas forcément, et projeter cette vision avec l’équipe de dev.

Comment faites-vous l’acquisition de la donnée, avez-vous de l’évènementiel qui transite ?

Stéphanie : On a 2 sources d’acquisition. Tout ce qui est traffic sur le site est récupéré via la data layer de Google Tag Manager et poussé dans API Gateway. A ce jour, on capte les événements en frontend, mais le but est de les capter en backend. On a une autre source de gestion d’events par segment qui permet de récupérer des évènements et de les pousser dans Redshift : on utilise pas mal de briques de la stack data AWS. Côté back, on utilise ELK pour le monitoring de la plateforme et la gestion des logs.

On a prévu de se faire accompagner pour aller vers une approche DDD/event-sourcing et voir ce que cela peut apporter. On ira donc certainement vers un bus d’event type kafka ou rabbitmq.

Votre architecture est multi-tenant : avez-vous une seule instance de BDD métier ?

Romain : On utilise une BDD mySQL sur nos serveurs. Un partenaire s’occupe de l’infogérance pour l’astreinte 24/7, le monitoring, la configuration et le provisionnement avec Puppet. On a une archi résiliente sur 3 serveurs avec hyperviseurs et 12 VM par serveur physique. Nous avons mis en place de la réplication, mais qui nous sert uniquement à alimenter la data.

Si vous vous ouvrez à l’international : allez-vous modifier votre architecture ?

Stéphanie & Romain : Côté plateforme on s’est posé la question : pour l’instant on va rester sur une seule instance de BDD. Si on devait répliquer, on sait que ça nous demanderait pas mal de dev pour un gain assez faible : notre volume de données n’est pas très important. Par contre si on doit partir sur des pays comme la Russie ou la Chine, si nos données doivent être hébergées dans le pays cible, il faudra que l’on revoie cela.

Côté data, chez AWS, on se pose la question de passer en multi-zone pour garantir la haute dispo, mais ce n’est pas lié à des problématiques de performance.

Vous êtes dans le domaine de l’éducation : avez-vous des pics saisonniers ? Comment avez-vous dimensionné votre infra ?

Romain : Oui, nous avons des pics en novembre et en mars. Simplement, on a dimensionné au plus haut. C’est surtout nos serveurs front ruby/rails qui risquent d’être surchargés. Il faut qu’on soit capables d’ajouter facilement un nouveau serveur pour faire du scale-out.

Vous êtes chez deux hébergeurs différents pour le traitement de la data et pour vos serveurs de production : comment gérez-vous cela ?

Stéphanie : On récupère la base de données anonymisée via S3 : c’est ce qui nous sert d’interface.

Vous êtes plutôt conteneurs ou pas ?

Romain : Côté dev, on aimerait bien avoir cette souplesse-là. Le service de classification a été construit sur Docker, par exemple. Cela nous dispense de monter des scripts puppet pour installer la stack python. Toute cette customisation aurait pu être un frein à la mise en œuvre de technologies et frameworks un peu spécifiques. Là, tout ce dont j’ai besoin sur mes serveurs, c’est qu’ils soient capables de faire tourner des conteneurs.

Tu as un profil dev 🙂 Avez-vous des ops et que pensent-ils de cette approche conteneurs ?

Romain : On passe par un devops en freelance (on recrute un devops d’ailleurs !)  et c’est lui qui a poussé pour les conteneurs. Notre partenaire qui s’occupe de l’infogérance est plutôt contre car il souhaite maîtriser ce qui est installé : ils nous ont clairement dit qu’ils ne souhaitaient pas gérer une infra de production avec des conteneurs. En revanche, sur nos environnements de démo qui ne sont pas critiques, on les utilise. Globalement, d’ici 2018 on va réfléchir à notre architecture infra, en incluant des sujets connexes comme la GDPR. On a des données assez sensibles avec nos partenaires qui sont des écoles et universités : quand tu leur parles de cloud et d’AWS, ils te regardent avec de gros yeux du genre « mais ça va pas non ? » (rires)

Sais-tu qu’un partenariat a été signé entre l’éducation nationale et Microsoft ?

Romain : Non, je ne savais pas. Ca pourrait être un argument intéressant pour justifier l’usage du cloud. On a prévu d’étudier le passage au cloud de toutes façons, mais c’est pas encore dit qu’on y passe ! Il va alors falloir qu’on se pose les bonnes questions. Aujourd’hui leurs DCs sont sous droit américain et c’est notre problème avec AWS.

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

Romain : On fait du custom avec 2 modes de projet . Pour l’opérationnel et le quotidien, on fait du Kanban mais pour tout ce qui nécessite au moins 1 mois de développement, on fait des squads permettant de dédier efficacement les ressources à un sujet. La roadmap porte sur la partie squad : ça reste assez frais, il y a seulement 1 an que l’on fonctionne comme cela et il est possible qu’on refasse des tests avec du scrum d’ici peu.

Avez-vous mis en place de l’intégration continue ? Des tests auto ?

Romain : On fait de la relecture de code et du pairing ponctuel si besoin. Par exemple, pour intégrer une nouvelle personne dans l’équipe, on lui fait faire 2 semaines de pairing avec tout le monde. Du coup, tout code sera néanmoins relu une fois avant de passer en production. Sur la partie intégration continue, on fait des tests automatisés type RSpec pour ruby et selenium, donc depuis le test unitaire jusqu’au test end to end. On ne fait pas de déploiement automatique, mais tous les devs peuvent faire du déploiement manuel très simplement avec un script Capistrano. Côté contrôleur de sources, on utilise git/github.

Quelle est la dernière techno vous avez kiffé ?

Stéphanie : AirFlow  qui a été fait par Airbnb pour orchestrer les tâches data et qui a été opensourcé en 2015 par Apache. On commence à l’utiliser pour gérer les dépendances de nos chargements, reprendre sur erreur et réaliser un audit sur nos données. C’est vraiment génial, on a une UI qui permet de bien suivre tous nos flux de données, de les rejouer comme on veut – pour peu que ce soit bien modélisé – de rejouer toutes les erreurs qu’on a pu injecter dans le code. C’est pas une UI faite par des devs front ! Mais ça me suffit amplement.

Romain :  Moi c’est une techno qui m’a redonné goût au front-end : Elm. C’est assez confidentiel pour l’instant : c’est à la fois un langage et une architecture et c’est celle qui a inspiré redux, la partie architecture de flux de données côté front end qui est couplée à react. Ce qui est génial, c’est que c’est un langage fonctionnel qui implémente une architecture. La baseline du langage et du framework est “plus de runtime exception” : on ne peut plus avoir de programme compilé qui génère des erreurs dans le browser de l’utilisateur. C’est un peu le même concept que Typescript dans le sens où ça compile en JS. Au départ, le truc va te casser les pieds : la première fois j’ai mis 2 jours pour réussir à compiler, par contre une fois que c’est fait, ça marche et fonctionnellement c’est juste.

Quelle est la prochaine techno que vous voudriez essayer ?

Stéphanie : Ansible (rires) ! C’est prévu pour bientôt, apparemment c’est un configuration manager assez complet et pourtant simple à prendre en main par les dev.

Romain : TensorFlow ou un équivalent du même style comme CNTK : c’est assez abrupt mais ça m’amuserait de tester cela.

Que considérez-vous comme le plus compliqué aujourd’hui ?

Stéphanie : Établir une archi qui doit être scalable sans y injecter de complexité. Je viens de LeBonCoin où on avait d’énormes problématiques de volumétrie et j’essaie de ne pas faire des choix d’archi qui étaient pertinents là-bas alors que les besoin de JobTeaser sont différents. Il faut que j’arrive à switcher de mindset et ne pas faire de choix overkill.

Romain : Arriver à arbitrer entre les priorités business et ce qu’il faut qu’on fasse évoluer sur la tech : comment introduire un nouveau langage ? Comment démarrer de nouveaux chantiers sans les intégrer dans le monolithe ? Doit-on  prendre des risques en partant sur des choix pour lesquels on n’a pas d’expérience alors qu’il peut y avoir une deadline stratégique pour la boite ? Ce n’est jamais le bon moment et pourtant il faut bien se lancer sinon on ne le fera jamais.

Qui décide du « bon » moment ?

Romain : On n’a pas beaucoup parlé de la partie management et culture ! Pour ma part, je ne décide de rien seul (rires) ! Je suis dans l’intelligence collective et je m’appuie sur l’équipe qui a les mains dans le cambouis au quotidien. Cela étant, quand les équipes de dev proposent une approche, je peux valider moi-même selon le degré de risque. Mais si c’est un gros sujet, qu’il y a une deadline un peu ambitieuse, s’il y a un risque un peu plus important, on va se synchroniser avec le CPO et le CEO. Notre comité de direction regroupe les directeurs de tous les pôles, internes, externes. Ce sont des choses que l’on peut aussi évoquer avec eux, en leur présentant nos choix et les risques, tout dépend du niveau de décision.

Cette question du bon moment est vraiment un gros sujet pour nous en ce moment. Même d’un point de vue recrutement, c’est dur : il faut qu’on arrive à être pertinent face à la concurrence. Ce sont des acteurs importants qui ont fait de grosses levées et qui recrutent en masse des profils comme nous : je pense à Doctolib, Drivy qui font du B2C et qui sont donc plus populaires.

Quelle est votre politique de recrutement ? Avez-vous beaucoup de turn-over ?

Romain : Il y a eu quelques rotations récemment dans l’équipe tech, ce qui est nouveau : en 2 ans et demi, on n’avait eu aucun départ. Ce sont des personnes qui sont là depuis 3 ans qui partent : globalement, on a une rétention de 2 ans. Ce qui fait notre force, ce sont l’équipe, l’ambiance et le modèle de management : il y a une vraie cohésion chez nous et je ne parle pas que de la tech mais bien de toute la boite. Les fondateurs ont beaucoup travaillé sur notre vision, nos valeurs… On a encore beaucoup de choses à améliorer mais on a un management bienveillant qui laisse beaucoup d’autonomie aux individus. On commence à héberger des meetups (Devops, Paris Ruby) pour nous faire connaître et toucher plus de monde. En ce moment on recrute tout type de profil et particulièrement des devops et dev front-end.

Avez-vous un fail à partager ?

Stéphanie : Ce n’était pas chez JobTeaser, mais j’ai fait un truncate cascade de la prod qu’on venait tout juste de mettre à disposition ! Les environnements n’étaient pas du tout isolés et je pensais le faire sur la pré-prod… Ca a pris une semaine pour tout remonter, sachant que les ops n’avaient jamais testé les backups.

Romain : Une feature que j’ai laissé faire pour laquelle on s’est rendu compte de la complexité technique en cours de projet. Là où j’ai vraiment failé, c’est que j’ai donné un go alors que les motivations business n’étaient pas suffisantes et pertinentes. On regardait un concurrent qui n’a pas du tout notre taille et notre capacité de développement. Or, on n’a pas la capacité de gérer la complexité qu’on a introduite ! J’aurais mieux fait de dire non et on se serait débrouillés autrement.

Le truc dont vous êtes le plus fiers ?

Stéphanie : Comme je viens d’intégrer très récemment JobTeaser, aujourd’hui je dirais encore que c’est d’avoir monté la stack data de LeBonCoin ! J’ai monté une super équipe et la stack est vachement utilisée, c’est un succès.

Romain : Ce qu’on a construit : l’orga, la culture qu’on a réussi à faire émerger chez JobTeaser.

Est-ce que vous dormez bien la nuit ?

Stéphanie : Depuis que je ne suis plus manager, je dors super bien la nuit !

Romain : Ca dépend des périodes : là ça va mais, quand les 3 annonces de démissions sont arrivées c’était un peu plus dur. Quand on manquait un peu de résilience sur le front aussi…

Comment vous imaginez-vous dans 5 ans, 10 ans ?

Romain : J’aimerais avoir réussi à changer mon quotidien : ne pas être un point de centralisation qui prend des décisions mais plutôt une source d’inspiration et un moteur pour tout le monde. Je voudrais avoir le temps de tester des technos et pouvoir être force de proposition sur le plan de l’innovation. Je me projette toujours chez JobTeaser en tout cas.

Stéphanie : Dans 5 ans je voudrais avoir suffisamment de compétences techniques pour participer à un projet open-source data. J’aimerais aussi monter une belle stack data scalable et qui serve l’international chez JobTeaser. L’année dernière je t’aurais dit complètement autre chose !

Une bonne résolution ?

Stéphanie : Faire plus de dev chez moi !

Romain : Arriver à implémenter des trucs du dernier bouquin que j’ai lu : The Toyota Way.  Il explique le leadership à la Toyota, qui est un bon croisement entre le management par objectifs et celui par les moyens. La pyramide est inversée : les plus importants sont les contributeurs des plus bas niveaux et ceux qui sont en dessous servent le haut de la pyramide. Cette vision n’est pas uniquement bienveillante et aussi orientée métrique et data. C’est une source d’inspiration pour structurer et transformer l’équipe. Il y a aussi le Kaysen pour s’améliorer au quotidien : faire surfacer les problèmes plutôt que de les enfouir et voir comment les résoudre. On entend beaucoup parler du lean mais ils expliquent que ça a été un peu détourné et si on n’a pas les fondamentaux du leadership à la Toyota, le lean ne fonctionnera pas. Je voudrais appliquer ces principes et bien les transmettre pour embarquer les équipes avec moi dans cette démarche.

Des startups dont vous voudriez connaître l’architecture, à nominer une prochaine interview #SousLeCapot ?

Stéphanie : ContentSquare qui est purement data driven et dont je voudrais connaitre l’archi.

Romain : Alkemics car ils sont assez data, et pour avoir un peu discuté avec les fondateurs, je les trouve un peu en avance sur nous côté orga et engineering management. Aussi Talentsoft : c’est une grosse boite française et je suis curieux de savoir comment ils sont structurés et architecturés.

Microsoft respecte votre vie privée. Veuillez consulter notre Déclaration de confidentialité.

Les commentaires sont fermés pour cet article