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

C’est le rêve absolu de tout CTO : être embarqué dans un projet dès ses débuts, le voir naître, évoluer, le faire grandir. Et se découvrir un jour aux commandes technos d’une des plus grandes réussites de la galaxie startup française. C’est l’histoire de Laure Némée, CTO de Leetchi et MANGOPAY, embarquée dans l’aventure par Céline Lazorthes, fondatrice, lorsque Leetchi ne comptait que 3 employés, toujours là alors que le compteur est à 80 ! D’elle, Céline Lazorthes a dit à l’occasion d’un meetup à Station F: « Laure est CTO depuis 8 ans et elle est la personne la plus intelligente que je connaisse ».

Après celui de CriteoLeBonCoin et JobTeaser, levons le capot de cette pépite de la Fintech pour en découvrir son fonctionnement, ses spécificités, son architecture et les technologies qu’elle affectionne.

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 🙂

Laure, comment en es-tu arrivée là, comment t’es-tu orientée vers ce métier et pourquoi ?

J’ai un parcours très classique : classe préparatoire, école d’ingénieurs Supelec. J’étais bonne en maths au collège et au lycée donc la suite naturelle était d’intégrer une prépa. En école d’ingénieurs, j’étais partie pour me spécialiser dans le traitement du signal et puis je me suis-réorientée vers l’informatique car les perspectives étaient plus claires et plus intéressantes à cette période. C’était les années 2000 : l’informatique était en pleine expansion.

Quel est ton parcours professionnel ?

Après mes études, j’ai passé 7 ans dans une startup dans le domaine de la TV interactive. A l’époque il s’agissait de déployer des logiciels sur les décodeurs satellites pour fournir du contenu additionnel : l’interaction était très limitée, rien à voir avec le web aujourd’hui ! Il y avait des tas de décodeurs différents : donc la problématique du multi-plateforme était déjà d’actualité. Puis je suis entrée dans une startup qui faisait des sites de vidéos pour des marques.

Tu n’as connu que des startups : est-ce par choix ?

Oui, clairement. L’idée d’avoir un réel impact sur la boite était intéressante pour moi : c’était plus concret.

Pour ceux qui seraient tentés de devenir CTO, as-tu des conseils pour évaluer et bien choisir sa startup ? Faut-il forcément tomber amoureux du projet ?

Je dirais plutôt oui ! J’aurais du mal à mettre ma motivation dans un projet auquel je ne crois pas. Les technos sont moins importantes : j’ai complètement changé de socle techno quand je suis arrivée chez Leetchi ; en 15 jours je suis passée du monde Java au C#.

Le rôle de CTO implique d’être touche à tout : si tu n’as pas conscience que ce que tu fais c’est pour le business, c’est problématique. Il ne s’agit pas de jouer avec des technos mais de faire grandir la boîte.

Comment cela se concrétise-t-il au quotidien ?

Je suis arrivée en tant que responsable technique en 2010 : on était 3 personnes. J’ai codé pendant 2 ans à peu près, puis j’ai évolué vers un rôle d’architecte. Aujourd’hui mon travail consiste essentiellement à donner les moyens aux différentes équipes techniques de répondre au besoin métier. Les choix d’architecture se font par les équipes elles-mêmes : on a 15 cerveaux qui planchent dessus ! Je suis maintenant CTO Leetchi Group et MANGOPAY : j’ai aussi la responsabilité managériale de l’équipe de dev MANGOPAY et de l’équipe Ops, qui est au Luxembourg. L’équipe dev Leetchi a pris son autonomie et reporte directement au COO Leetchi depuis quelques mois.  Tout cela a pas mal évolué depuis 6 mois, je fais du mentorat avec les lead dev pour les faire monter en compétence et les faire gagner en autonomie, c’est un changement de paradigme qui est assez intéressant.

Comment t’es-tu formée sur le volet management ?

Je me fonde sur mon expérience et beaucoup d’apprentissage sur le tas ! Mais mieux vaut tard que jamais : je viens de faire ma première formation management…

Parlons de Leetchi et vos produits : quelles solutions éditez-vous ?

Leetchi est l’offre B2C historique pour simplifier la création de cagnottes entre des particuliers. MANGOPAY est une solution B2B qui se positionne comme un intermédiaire de confiance pour collecter des fonds.

On n’imaginait pas du tout faire MANGOPAY. On pensait proposer  le principe des cagnottes à des sites e-commerce : ça n’a jamais pris, malgré plusieurs tentatives ! MANGOPAY est une solution en marque blanche née des demandes explicites de nos clients. Ils avaient besoin d’une techno permettant d’accepter les paiements et de cantonner des fonds en passant par un tiers de confiance. Typiquement ce sont des acteurs qui font du crowdfunding, des places de marché, etc.

Quelles sont les spécificités de votre métier ?

On est une fintech et on fait du paiement avec des clients « pro » sur MANGOPAY : notre service répond donc à un besoin qui est ultra critique pour eux. Pour nous ça se traduit par des contraintes de délais de livraison et haute-disponibilité. A côté de cela on a aussi des contraintes qualité et réglementaires qui sont assez fortes – On a un agrément bancaire au Luxembourg. La frontière du monde bancaire avec le monde web est assez compliquée : les obligations sont parfois contradictoires.

Un agrément d’émetteur de monnaie électronique :  tu peux m’expliquer ?

Nous sommes autorisés à garder sur nos comptes des fonds qui ne sont pas à nous. Cela entraîne un certain nombre d’obligations, comme garantir les fonds aux personnes à qui ils appartiennent.

Nous sommes soumis à une réglementation européenne ou plus exactement à une directive européenne sur l’émission de monnaie électronique, transcrite par chaque pays européen. Lorsque nous avons cherché à obtenir l’agrément, le Luxembourg a été très réactif et nous a ainsi permis d’avancer très rapidement. On a des audits très fréquents faits par l’autorité de régulation du Luxembourg. Cet agrément nous permet d’avoir des clients dans toute l’Europe.

Je suppose que vous avez des contraintes particulières en terme d’hébergement de votre solution ?

Pour respecter les obligations réglementaires on est maintenant hébergé au Luxembourg chez EBRC : une filiale des postes luxembourgeoises qui est elle-même agréée par l’autorité de régulation bancaire du Luxembourg. Il y a un statut spécifique pour cela : Professionnel du secteur financier (PSF). Chez cet hébergeur on utilise une solution virtualisée VMWare.

Nous avons fait un passage sur le cloud Azure en 2010. En effet nous avions été sélectionnés par Microsoft pour intégrer le programme Idees, destiné à favoriser chaque année le développement de vingt-cinq start-up innovantes de l’industrie française du logiciel.

Raconte-moi l’architecture du produit 🙂

Quand je suis arrivée il y avait déjà une solution en place : du pur Microsoft avec du C#, c’était une architecture plutôt conventionnelle et robuste de type 3 tiers avec Sql Server pour la base de données. Nous avons conservé cette base avec aujourd’hui une application web ASP.Net MVC 5 et Web API 2 ainsi qu’un peu d’OWIN. On a aussi quelques serveurs avec des workers en C#. Pour la base de données métier c’est Sql Server en version 2014 depuis 1 an. On utilise des fonctionnalités de réplication sur plusieurs sites et du AlwaysOn.

On est dans une période de transition et en plein réflexion pour faire évoluer cette architecture assez monolithique et splitter l’existant en services.On passe par RabbitMQ pour la communication entre les différents services et l’asynchrone. On a aussi du cache REDIS pour les questions de « rate limiting » : cela a d’ailleurs donné lieu à une session à Devoxx cette année : une histoire de rate-limiting, ou comment les sysadmins de MANGOPAY ont retrouvé le sommeil.

On passe par une stack Elastic Search pour les logs. Elle peut ainsi être utilisée par les opérationnels comme les account managers, pour suivre les activités des clients : cela nous évite de maintenir un backoffice dédié sur le sujet.

Votre solution est-elle multi-tenant ?

Oui c’est la même solution SaaS qui sert tous nos clients, c’est du mutualisé de bout en bout y compris pour la base de données. Nos clients sont en silo d’un point de vue applicatif mais l’architecture n’a pas été pensée pour faire du single-tenant. Néanmoins cela fait partie des pistes de réflexion à venir, car cela pourrait être intéressant pour séparer l’infrastructure de nos clients les plus importants.

Y a-t-il une base commune entre MANGOPAY et Leetchi ?

On est parti d’une base de code commune, mais c’est de moins en moins le cas, les fonctionnalités ayant évolué vraiment différemment.  

Comment allez-vous décider du découpage des différents services ?

L’architecte de l’équipe MANGOPAY a beaucoup bossé sur ce point et forme les autres sur ce sujet : il insiste beaucoup sur une séparation prioritairement fonctionnelle.

Sur votre nouvelle architecture à base de (micro) services, allez-vous rester sur les mêmes technologies ?

Oui probablement, comme on a une équipe “ops” assez restreinte, j’essaie de rationaliser en évitant de multiplier les technologies et systèmes à maintenir. On l’a fait pour Redis et ELK, par exemple : la règle jusque-là c’était que ça serve au moins deux fonctionnalités intéressantes.

Côté langage on va rester en C# même si les devs vont certainement commencer par faire aussi des trucs en F# : ça les démange ! Ils vont m’expliquer qu’ils en ont VRAIMENT besoin et je vais finir par les laisser faire 🙂

Comment avez-vous géré la mise à l’échelle de vos produits qui ont connu un succès assez fulgurant ?

Sur MANGOPAY on fait du x2,5 par an donc ça donne des discussions assez amusantes du genre : on purge l’historique ou pas ? Sauf que notre problème est plutôt dans le futur et pas dans le passé !

Ça se joue sur plusieurs tableaux : décomplexifier notre code, vérifier finement ce qui se passe côté BDD, etc.

Et d’un point de vue infra ? Comment avez-vous réussi à absorber la charge, les requêtes ?

Notre système d’hébergement nécessite qu’on fasse une demande d’achat de ressources supplémentaires, cela prend à peu près 1 semaine. Ce sont les « ops » qui surveillent l’utilisation effective des ressources et qui nous signalent les nouveaux besoins de CPU, de RAM pour qu’on les commande. On a essentiellement 2 types de monitoring : zabbix pour les métriques techniques (CPU, disque). La stack ELK pour le diagnostic. Ce qui nous manque un petit peu c’est du monitoring d’activité métier : c’est un de nos chantiers en cours. En complément on a aussi les reports de l’hébergeur lui-même. Si on rentre un gros client on n’a pas de souci, on n’est pas limité sur la plateforme. C’est plutôt l’évolution du produit et l’ajout de nouvelles fonctionnalités qui engendrent des besoins d’infrastructure supplémentaires.

Quel est le processus de commande auprès de votre hébergeur ?

En gros, on envoie un mail avec nos besoins. Suite à cela on obtient un chiffrage du coût de location des ressources. Et voilà. Actuellement les tarifs sont à peu près stables mais ce n’était pas forcément le cas au départ car leur offre n’était pas très mature. Du coup on commande des ressources en avance ce qui nous permet d’avoir toujours un peu de réserve. Sur un besoin ponctuel particulier (charge ou autre) il nous est arrivé de couper tel ou tel serveur qui ne sert qu’à du backoffice pour déporter les ressources sur les serveurs de production mais cela fait longtemps que ce n’est pas arrivé : on arrive à prévoir bien en amont en général.

Quelle est la composition de l’équipe “ops” et comment travaillez-vous avec eux ?

Cette équipe-là se trouve au Luxembourg. Ils sont trois. Deux purs sysadmin et une DBA qui les a rejoints très récemment. Ils sont assez autonomes et comme ils sont loin, ça vaut mieux ! On a un Slack qui favorise bien la communication à distance. L’équipe “ops” s’occupe à la fois de ses propres projets sur l’infrastructure et également des projets communs qui demandent davantage de synchronisation avec les développeurs. Pour cela, on fait des points hebdo avec les équipes de dev et eux.

Tu as évoqué un prochain chantier côté télémétrie ?

Tout à fait : dans ELK on a toutes les requêtes IIS, les logs E/S de l’API : ça permet d’avoir un bon volume de données concernant l’activité d’un client.

Donc toutes vos données passées, historisées, sont stockées de manière structurée ?

Les fichiers de log sont à plat et le reste est dans ELK. On préfère avoir les données déjà structurées  mais on ne stocke pas énormément d’historique : une fenêtre de quelques mois à peine.

Pour faire de l’analytics sur les données : qu’est-ce qui manque ?

La BI c’est le point que l’on voudrait améliorer.

Cela vous permettrait-il de proposer de nouveaux services à vos clients ?

Oui typiquement la lutte contre la fraude : on s’appuie beaucoup sur les fonctionnalités de notre prestataire de paiement mais on voudrait avoir une vision qui nous est propre et qui soit plus fine du sujet.

Et la sécurité ? Je suppose que c’est un sujet crucial ? Avez-vous mis en place des choses particulières pour répondre à cette problématique ?

Cela fait partie de nos obligations : c’est vérifié par audit et par pentest (tests de pénétration) de manière très régulière. Sur Leetchi on utilise Cloudflare. Sur MANGOPAY on ne peut pas passer par un site externe donc on s’appuie essentiellement sur les fonctionnalités DDoS de notre hébergeur. On fait aussi de l’analyse de trafic a posteriori sur Elastic Search.

Quels sont vos enjeux majeurs ? Vos challenges ?

Côté tech, c’est la scalabilité de l’application et aussi l’agilité pour le métier.

On a énormément travaillé la partie automatisation des tests : depuis 4 ans, on essaie d’augmenter la couverture au maximum. On a commencé par des tests unitaires mais c’était compliqué à mettre en place et à maintenir. On est vite passé sur des tests d’APIs en partant de l’équipe Produit : ce sont eux qui font les tests de validation. Ils faisaient cela de manière manuelle jusqu’à ce qu’on mette en place Runscope. C’est une solution qui fait du test d’APIs et permet de créer des jeux de tests via une interface web. On a branché ça dans notre intégration continue TeamCity. Comme Runscope n’avait pas de plugin avec TeamCity, on l’a développé nous-même et on l’a open-sourcé : ils étaient assez contents !

Notre vrai premier niveau de test c’est ça. Sur Leetchi on utilise aussi Selenium. On a aussi pas mal de Gherkin qui est un DSL métier pour les docs et tests : ça se fait conjointement entre les équipes Produit et Tech, en particulier pour tout ce qui est services.

On fait vraiment beaucoup d’effort sur la couverture de tests et cela porte ses fruits. A côté de cela on fait aussi des code reviews.

Comment se passe un cycle de release ? Est-ce que tout est livré en un seul bloc ?

Le cycle est de 3 semaines en principe. Certains services sont maintenant releasés séparément mais pas tout. Typiquement, tout ce qui est sur le même modèle de BDD est sur le même cycle de release, pour le reste c’est plus facile de séparer. En terme d’outillage on utilise Octopus pour le déploiement ainsi que TeamCity comme je l’ai déjà indiqué.

On a un environnement de dev, de recette,  de prod, de sandbox pour les clients. On met en sandbox après avoir mis en prod uniquement : on considère que ce n’est pas à nos clients de valider nos releases. On vient de rajouter un environnement intermédiaire entre la recette et la prod : à volume égal avec la production pour aller détecter des choses qu’on sait pas bien détecter en recette, notamment en ce qui concerne la performance.

Quel est ton avis sur les tendances ? Serverless, conteneurs, etc.

Ici on n’a pas de défi techno hyper important. Le point capital c’est la scalabilité. Du coup j’ai une attitude un peu conservatrice : je laisse les autres tester et j’évite de me jeter sur les dernières technos si ça ne sert pas le business.

Quelle est la prochaine techno que tu aurais envie de tester ?

Dans le contexte de Leetchi, clairement la blockchain ! Je vois des points qui pourraient être très intéressants pour nous. L’équipe ops a aussi commencé à tester docker. Ils l’ont fait sur ELK et ont trouvé que c’était pas forcément une solution intéressante dans ce contexte. Mais ça va finir par venir, d’ailleurs les devs l’utilisent déjà pour les environnements de tests sur leur machine.

La dernière techno que tu as kiffé ?

J’ai entendu parler des macarons d’authentification et ça m’a beaucoup intéressée, notamment pour l’authentification entre services.

Que considères-tu être le plus compliqué ?

Nos équipes ont doublé de taille très récemment : on est à peu près 70 personnes dont 45 à Paris avec 12 devs, une entité « Legal » et les “ops” au Luxembourg . On a aussi des bureaux commerciaux à Londres et à Berlin. La communication entre équipes est en évolution et on doit revoir nos process autour de cela.

J’ai toujours une réunion hebdo avec tout le monde : c’est très court ça prend 15 min. Avant on faisait un tour de table où chacun prenait la parole ce qui prenait bien trop de temps : maintenant ce sont les lead dev de chaque équipe qui le font même si n’importe qui peut faire une intervention s’il a quelque chose à dire.

Aurais-tu un fail à partager ?

On a eu un gros incident en octobre dernier : un truc moche au moment d’une release, sur un script de migration. Évidemment c’est tombé pile à un moment où je n’étais pas sur place. Ça a été un grand bazar en terme d’organisation et de décision prise car nous n’avions jamais été impacté aussi fortement. On s’est rendu compte qu’on n’était pas assez organisé pour gérer ce genre de d’événements et pour la remontée d’information aux autres équipes. Et on n’a pas su prendre une décision dure mais qui aurait été nécessaire : typiquement c’est le genre de situation où on aurait dû couper le service ; de toute façon ça ne marche pas : on arrête et on règle le problème. Tout serait rentré dans l’ordre beaucoup plus rapidement. Mais c’est une décision qu’on n’a pas su prendre : on était dans l’idée que l’uptime était le plus important et on ne voulait surtout pas gêner nos clients. On a beaucoup appris à cette occasion, et lancé un certain nombre de chantiers d’amélioration pour minimiser ce risque, et être mieux préparé et prendre les bonnes décisions.

De quoi es-tu la plus fière ?

D’avoir participé à cette boite passée de 3 à 80 personnes, d’avoir créé des produits qui marchent plutôt bien, d’avoir une équipe de dev qui grandit en nombre mais aussi en  maturité : les pratiques, les manières de travailler, l’industrialisation, la communication, etc. J’essaie de leur laisser du champ libre pour qu’ils se sentent investis, qu’ils puissent être force de proposition et d’amélioration.

Comment recrutez-vous ?

Au départ on passait par un cabinet de recrutement, mais maintenant on passe par Talent.io. On le fait  quasiment depuis la création de leur site d’ailleurs. Cela nous permet de rencontrer des candidats qu’on n’aurait pas vus via le cabinet et qui sont réellement motivés à bouger. On fonctionne aussi pas mal par cooptation.

Tu es une CTO femme ce qui est rare : y a-t-il une meilleure parité dans les équipes : en d’autres termes, penses-tu que tu recrutes différemment ?

J’essaie ! Chez Leetchi au total, on a 45% de femmes. Mais au départ on a eu du mal et jusqu’en 2015 il n’y avait pas de femme dans les équipes techniques à part moi. Actuellement il y a une dev dans chaque équipe Leetchi et MANGOPAY et une DBA que l’on a recrutée enceinte !

Est-ce que tu mets plus d’énergie pour recruter des femmes ?

On essaie de considérer les profils de femmes sélectionnés d’un œil bienveillant : ne pas se fixer sur des listes de technos. Ce n’est pas spécifique à la parité de genre : on croit beaucoup que notre environnement de travail permet aux gens de donner le meilleur d’eux-même et de se développer. On fait passer des tests techniques mais je vais surtout chercher les bons réflexes sur la manière de faire les choses : quand est-ce que je considère que mon code est terminé par exemple.

Typiquement je ne vais pas hésiter à contacter des femmes même si elles sont plus junior. Pour autant, une fois qu’on décide de les recruter, on n’a pas de doute sur la pertinence de notre choix : on ne les recrute clairement pas parce que ce sont des femmes ! Il faut dire aussi qu’une femme qui arrive dans une boite avec un-e CEO et un-e CTO se sent peut-être rassurée sur le sujet.

A l’inverse : est-ce qu’en tant que femme CTO tu as l’impression d’avoir plus de mal à être crédible quand tu recrutes un homme ?

Sûrement mais comme je n’ai aucune envie de recruter des gens pour lesquels c’est décrédibilisant d’être une femme, c’est juste parfait ! Il m’est arrivé qu’un candidat me demande s’il pouvait me parler technique : j’ai vite écourté l’entretien…

Est-ce que tu dors bien la nuit ?

Oui ! Avec mon mari Nicolas, on a tous les deux de la « prod », sauf que lui a des équipes beaucoup plus grandes, alors que moi si j’ai un problème en cours, je ne dors pas !

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

Je suis ici depuis 7 ans mais mon métier n’a pas arrêté de changer. Donc si ça continue comme cela et que je ne m’ennuie pas dans ce que je fais, je me vois bien continuer à évoluer dans ce rôle là.

Tu es CTO : est-ce que tu bosses H24 ? As-tu encore une vie ?

Oui ! Ca a changé au fil de la vie de la boite : au début j’ai vraiment bossé comme une dingue, maintenant ça va mieux.

As-tu une startup dont tu souhaiterais découvrir l’architecture dans une prochaine interview ?

Des startups qui proposent des solutions de machine learning en SaaS : Dataiku, Saagie. Ce sont des sujets qui nous intéressent fortement. Ou des startups dont l’activité est très ancrée dans le réel : foodtech & co.

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

Les commentaires sont fermés pour cet article