Nicolas de Nayer (Doctolib) : L’art du scaling des équipes tech ! (script complet)

On connait tous Doctolib. Certains depuis quelques années. Pour d’autres, l’expérience Doctolib est plus récente et découle de son lien avec la pandémie Covid-19. S’il y a une boîte tech en France qui incarne le succès et la scalabilité, c’est Doctolib. Pour vous donner un ordre d’idée, on parle de 40 à 50 millions de rendez-vous pris par mois en 2021. Alors je vous propose de parler d’engineering et de scalabilité, avec Nicolas de Nayer, VP Engineering chez Doctolib.  

Tu as joué un rôle clé dans le groupe parce que tu as participé à la construction des équipes et au déploiement de la dimension tech de l’entreprise. Avant de parler de ton rôle, peux-tu nous synthétiser en quelques mots ton parcours et tes expériences avant que tu rejoignes Doctolib ? 

Je suis développeur avant tout. Pour des raisons personnelles, je suis venu sur Paris et c’est là que j’ai découvert Octo Technology. Je suis tombé amoureux de cette entreprise et de leur méthodologie qui était très innovante pour l’époque. J’ai décidé de les rejoindre et j’y ai passé trois années très intenses qui m’ont beaucoup appris en tant que coach agile, architecte et tech lead. En tant que consultant, j’ai été envoyé chez Viadeo pour une mission de transformation agile à grande échelle. Cette mission était très intéressante et variée. Et ça s’est tellement bien passé que Viadeo m’a offert la possibilité de reprendre un bureau à San Francisco. Là-bas, j’ai arrêté le conseil pour m’investir plus dans la boîte. Je manageais une dizaine de collaborateurs avec une autre personne issue de Octo Technology. On s’est régalés !  

Et puis, été 2015, Jessy de Doctolib est venu me chercher et m’a un pitché Doctolib. Je connaissais Ivan et Jessy, deux des fondateurs de Doctolib. Ils m’ont expliqué le projet et en quoi je pouvais être complémentaire dans cette aventure. J’ai décidé d’abandonner le surf et le soleil de San Francisco pour revenir sous la grisaille parisienne pour les aider dans cette aventure. 

Tu avais quelle mission ? 

Je pense qu’ils ne m’en voudront pas de dire ça mais je suis arrivé pour les rendre inutiles et même pour me rendre moi-même inutile. A cette époque-là, Doctolib, c’était 80 personnes mais au niveau tech et produit, il n’y avait que trois personnes : Ivan et Jessy avec un stagiaire et un freelance. A eux 4, ils rassemblaient la service tech et produit. 

Et le reste des équipes faisaient quoi ? 

Le CEO, Stanislas, a commencé par faire de Doctolib une machine de guerre commerciale. Il a recruté d’excellents profils et a créé quelque chose de vraiment très efficace d’un point de vue commercial et opérationnel. Ces 80 personnes, c’était le support, l’administration et le business. Et j’ai été surpris ! Je savais que côté tech et produit il n’y avait pas beaucoup de process en place mais que ça fonctionnait. Mais j’ai surtout été étonné de la maturité de l’entreprise sur la partie hors tech et produit. C’était très bien géré.  

Côté tech et produit, il y avait de très bonnes bases et de bonnes pratiques. Le code était déjà testé et des tests et des déploiements automatisés étaient déjà en place. Mais là où ça marchait moins bien, c’était au niveau du management, des méthodologies et du recrutement. Et c’est normal, car ceux qui géraient étaient très bons en technique et en produit. Ce sont les meilleurs développeurs que j’ai jamais vus ! Les deux premières années, ils ont quasiment tout fait. Et c’était impressionnant que la boîte soit allée si loin avec si peu de personnes.  

Et toi, donc, tu as apporté de la maturité sur la partie processus et organisationnelle ? 

Exactement. Seul, on va vite, ensemble, on va loin. A deux, ils étaient déjà allés très vite. Mais à un moment, le modèle a atteint des limites. Il fallait donc scaler et pour une boîte comme Doctolib, il faut le faire avec plus de gens. Ce qui veut dire plus de process, plus de méthodes, plus de structure au niveau du recrutement, etc. C’est à ce moment-là que je suis arrivé. Depuis le début, mon rôle est de trouver le meilleur process et la meilleure méthodologie pour que Doctolib puisse fonctionner, mais, au fond, je recherche une efficacité perdue qu’on ne retrouvera jamais. Ça ne pourra jamais être plus efficace que deux personnes qui ont fait la même école au même moment et qui ont déjà créé des entreprises ensemble. Ivan et Jessy, c’est comme un vieux couple. Ils ne parlent pas, ils se comprennent. A l’époque, il n’y avait aucun process pour la tech et le produit. Et ça marchait bien à 2 mais quand on est 350 dans le service, c’est nécessaire. Sinon, tout s’écroule !  

Au niveau du business, tu peux nous parler du positionnement Doctolib aujourd’hui ?  

Avant que j’arrive et pendant les premières années où j’étais là, Doctolib était un agenda pour les praticiens. On le faisait bien. Les docteurs payaient pour un service qui les aidait à optimiser leur cabinet. Le fait qu’on ait eu un focus très clair, c’était très bien, car ça nous a évité de nous éparpiller et on a été très efficaces. Au moment où on s’est dit, c’est ok, notre service est suffisant, on cartonne partout en France, maintenant, on peut commencer à s’ouvrir à l’international. Mais là encore, on a choisi d’y aller progressivement et on a fait étape par étape, prudemment. Et il y a à peu près un an et demi, on a revu un peu notre vision. Aujourd’hui, notre mission est de faciliter l’accès aux soins pour les patients et aider les praticiens et les professionnels de santé à prendre le temps d’exercer leur métier sans se soucier des tâches administratives. Aujourd’hui, la stratégie de Doctolib est de proposer des produits pertinents aux praticiens et professionnels de santé tout en facilitant l’accès aux soins aux patients. C’est un cercle vertueux qui est très bon pour les praticiens et pour les patients. Et tant mieux aussi pour la croissance de Doctolib ! 

Et au niveau des chiffres, tu peux nous donner un peu la dimension de l’univers dans lequel tu es ? Tu disais que vous êtes passés de 3 à 350 en 5/6 ans. Concrètement, aujourd’hui, de quoi parle-t-on en termes d’usage de la plateforme, de trafic, etc… ? 

Quand je suis arrivé, on avait passé la limite des 3000 praticiens qui payaient Doctolib. Aujourd’hui, on est à 150 000. Mais en fait, les chiffres doublent tous les ans depuis que je suis là que ce soit en termes de taille des équipes mais aussi en termes de trafic. Et de temps en temps, on a des surprises comme la campagne de vaccination où tout s’accélère encore plus. Depuis le début, on regarde la croissance de la croissance. On va regarder de combien on accélère. Le rythme quotidien est de 20 millions de rendez-vous pris par mois, 10 000 requêtes HTTP par seconde le lundi matin, plus de 100 millions de visites par mois, 500 000 lignes de code, 350 000 lignes de code de tests et trois mises en production par jour.  

Et elle ressemble à quoi l’architecture qui permet de faire tourner ce business ? 

Aujourd’hui, on a réussi à garder une architecture très simple. La plus simple possible pour le degré de complexité qu’on essaye d’adresser. Pour la grande majorité de Doctolib, c’est un Monolith Rails avec du code front dessus en JavaScript React et on utilise aussi des Single Page Application. On a des SPA côté patient, d’autres SPA côté docteur. Et derrière, c’est servi par un backend Ruby on Rails. 90% du code et de la logique métier s’exécutent là-dedans. A côté, il y a des petites applications un peu hybrides. Pour assurer le fonctionnement, on en prend grand soin ! C’est un moteur assez simple mais qui optimisé et soigné. Et tout ça, on le fait sans cache applicatif. Les rendez-vous et les disponibilités sont calculés à chaque fois qu’un internaute va sur le site. Et à côté, pour tout ce qui est en asynchrone, on va avoir du Redis et des frameworks standards sur Rails. On va commencer à mettre du texte script à quelques endroits. On a aussi du Elasticsearch sur la partie recherche essentiellement.  

Votre vision simple de l’architecture a-t-elle été posée dès le départ ou bien vous l’avez choisie après plusieurs échecs et prises de conscience ? Votre architecture a-t-elle toujours été ainsi ou bien a-t-elle évolué ?  

En fait, l’architecture va bouger et elle est déjà en train de bouger. On met en place plein de chantiers en ce moment pour la faire évoluer, mais ce n’est que la continuité des principes qui ont été établis avant. On a toujours eu cette volonté de toujours essayer de garder l’architecture la plus simple possible. Par exemple, pour répondre très localement à un problème, on a conscience que c’est plus simple d’aller chercher un autre outil. Mais après il faut faire appel à des personnes pour développer et maintenir ces outils en termes de code et de run une fois en production. Alors, au bout d’un moment, on finit par utiliser mille outils pour mille problèmes différents et il n’y a plus de cohérence. Et je pense que c’est là où il faut se forcer à garder une stack simple et compréhensible par tout le monde. C’est ce qui permet d’aller très loin. Aussi, souvent dans ce type de situation, on finit par se rendre compte que l’on n’est même pas allés au bout des outils. Néanmoins, à un moment, il faut aussi savoir lâcher l’affaire et changer d’outil sans pousser à l’extrême optimisation des outils finalement inadaptés. 

Quels sont les autres grands aspects ou les grands piliers de la philosophie de la tech chez Doctolib? 

Pour moi, le premier, c’est ce que je viens d’évoquer : keep the stack simple. C’est une valeur qu’on affiche sur nos murs et qu’on essaie de garder en tête. Et c’est une volonté qui été présente avant moi ! C’est quelque chose que j’ai repris et sur laquelle je communique.

Une autre valeur qui est très chère à nos équipes : user first. Le principe est d’essayer de reproduire ce combo magique que j’expliquais plus haut de Tech and Product. Quand des développeurs sont capables d’avoir du recul sur pourquoi on fait une fonctionnalité, ils sont 100 fois plus efficaces. Si un développeur a bien compris le besoin exprimé par l’équipe produit ou par la stratégie, il aura une solution simple et efficace à fournir avec son prisme technique. On essaye vraiment d’avoir des développeurs qui soient capables de penser et de challenger les produits pour trouver des raccourcis et gagner un temps considérable. 

Ça implique que les équipes soient capables de proposer des initiatives et de challenger le use case qu’on leur demande…  

Oui, et ça m’amène d’ailleurs à une autre valeur qui est très chère aux équipes. C’est le côté ownership. On veut vraiment que tour à tour, chaque développeur prenne en main un projet. Qu’il soit new joiner ou bien un développeur expérimenté, peu importe. Chez nous, il n’y a pas un seul et unique tech lead qui va cadrer un projet en amont et le gérer. Ce rôle tourne et, tour à tour, chacun est le pilote du projet avec l’équipe produit. Ce développeur va être le tech holder pour ce projet et va faire des vis ma vie du côté produit pour parler, être en contact avec les hôpitaux, les patients ou les docteurs, et essayer de comprendre le besoin avec son prisme technique. Ainsi, il aura des bonnes idées et pourra challenger le produit. Ensuite, il va cadrer le projet avec l’équipe produit et aura la charge de le piloter.

Quand je dis projet, ce sont toujours des petites fonctionnalités avec une durée de développement de maximum 3 semaines. Et même une fois en production, c’est ce même développeur qui va s’assurer de son bon fonctionnement. You build it, you run it. Il va donc vérifier les performances et vérifier les erreurs lorsque ce sera en production. Mais ce n’est pas lui qui va le forcément faire. Il va plutôt s’assurer que l’équipe le fait bien. On veut vraiment responsabiliser tous les développeurs.  

Une autre valeur très importante à nos yeux :  security and reliability. C’est le côté sécurité des données. On investit énormément dessus mais on ne peut jamais être parfaits sur la sécurité. C’est vraiment un sujet très sensible et on se force à passer du temps dessus. D’ailleurs, c’est 15% de notre de temps de feature. C’est beaucoup, mais comme on n’est jamais parfaits, on veut toujours essayer d’aller plus loin. D’autant plus qu’on est plus en plus sous le feu des projecteurs. On doit toujours essayer de se rapprocher de la perfection et je pense qu’on en est sur la bonne voie même si on ne l’atteindra jamais. Le côté reliability, c’est la notion de fiabilité. On est de plus en plus déployés dans les hôpitaux et chez les praticiens, et ils doivent pour nous faire confiance. Si les serveurs ne fonctionnent pas par exemple, ça peut avoir des impacts très forts. On a vraiment une grande responsabilité et nos systèmes doivent être incassables.  

La dernière valeur, c’est learn and grow. Moi, ça m’est très cher. Quand je fais des one to one avec mes équipes, je pose toujours les mêmes questions : est-ce que tu te plais dans l’entreprise et est-ce que tu t’embêtes ? Un développeur qui s’ennuie, c’est quelqu’un qui part. Donc, le côté croissance pour nos équipes, c’est indispensable. Si un développeur vient chez Doctolib en nous disant qu’il veut apprendre à nos côtés puis qu’il envisage de créer sa boîte, ça nous convient très bien. C’est l’attitude qu’on veut. En fait, on veut que les membres de nos équipes aient cette envie. Et de toute façon, on scale tellement vite qu’ils ne cesseront jamais d’apprendre et pourront rester longtemps chez nous. D’ailleurs, c’est ce qui m’arrive. Ça fait six ans que je suis là et j’apprends tous les jours. 

Quand tu parles d’autonomie des équipes, qu’est-ce que ça veut dire ? Comment tu gères cette autonomie ? Est-ce que tu recrutes des seniors ou bien est-ce que tu accompagnes les nouveaux entrants vers plus de responsabilités ? Et comment tu gères les on boarding pour leur transmettre la culture de Doctolib ?  

Concernant l’onboarding, déjà, avant que j’arrive, il y avait déjà ce qu’on appelle la Doctolib Academy. C’est un programme qui s’adresse à toutes les personnes qui rejoignent d’Doctolib. Les participants suivent un tronc commun, font des vis ma vie dans les autres services, écoutent des intervenants parler du monde médical et sont formés à la culture et au monde Doctolib. Cette académie existe depuis plusieurs années. On a même créé la Tech Doctolib Academy qui est aujourd’hui devenue le Tech and Product Camp. C’est un programme de formation de deux semaines qui s’ajoutent aux deux semaines de la Doctolib Academy et qui introduit à la mécanique Tech and Product de Doctolib.

On essaye de rendre les gens efficaces et autonomes le plus vite possible. Pour favoriser l’autonomie, on essaye aussi de se rapprocher du modèle initial qu’il y avait au départ dans l’entreprise en rassemblant tous les corps de métier au sein d’une même équipe, une feature team : la stratégie, le produit, le design, la tech… Comment ces équipes fonctionnent ? En donnant un KPI par équipe qui a initialement été défini dans la stratégie. Plutôt que de donner 10 sujets à chaque équipe, on leur en donne un avec une seule mesure. Et ensuite, chaque équipe avance, priorise et gère comme elle le souhaite tant qu’elle garde le résultat en tête. On essaye de tendre de plus en plus vers ce modèle. Et chaque équipe doit rendre des comptes sur le KPI et pas sur les projets livrés. 

Au niveau des KPI, comment sont-ils gérés ? Sont-ils annuels ou avec une fréquence différente ? 

On veut que nos KPI soient actionnables et facilement re-challengeables. Il n’y a pas de règles fortes. On n’organise pas de grandes réunions dédiées aux KPI ou de rituels précis. Pour nous, un KPI doit être dans un ordre de grandeur et on espère qu’il tienne environ neuf mois. Mais en réalité, on s’adapte à chaque KPI et chaque projet. Avec les évènements externes et notre croissance rapide, on n’a pas le choix que d’être capable de se remettre en question si nécessaire.   

Tu parles de feature team, comment sont-elles composées ?  

On applique la règle de Pizza Team qui nous vient de Jeff Bezos. Chaque équipe contient environ 10 personnes dont, d’un point de vue full stack, minimum 3 développeurs et maximum 6. Dès qu’une équipe arrive à 6 développeurs, il est temps de la diviser en deux équipes. Une bonne équipe, c’est 5 développeurs, 1 ou 2 product manager, un data manager, un designer et, parfois d’autres fonctions selon les besoins. Côté data, on peut de temps en temps s’adapter et avoir des profils un peu plus atypiques. Et on évite de réorganiser les équipes. On privilégie la stabilité. Pour moi, c’est une mauvaise idée de réorganiser les équipes à chaque projet. Une équipe doit apprendre à travailler ensemble et à trouver des mécanismes d’efficacité. Casser une équipe et une dynamique, c’est, selon moi, une erreur. On souhaite que nos équipes soient stables dans le temps.

De plus, on a fait le choix de les localiser au même endroit. Puisque les développeurs ont une tendance naturelle à se regrouper avec leur corps de métier de base, on préfère par défaut les rassembler par équipe pour qu’ils soient là, et qu’ils puissent participer. Aujourd’hui, au niveau technique, tout le monde est soit sous le CTO/COO, soit le CPO/CSO. Ensuite, il y a plein de mécanismes et de rituels pour que tout fonctionne bien. Et après, il y a aussi la hiérarchie design et la hiérarchie product. Et au niveau de la sécurité, elle est gérée par une équipe centrale qui s’occupent d’autres choses en parallèle. Nous avons aussi des security ambassador au sein de toutes les équipes qui sont des relais, ainsi que des feature team entièrement dédiées aux sujets autour de la sécurité.  

Côté tech, la qualité de l’organisation est très importante à tes yeux. Comment est-ce qu’elle se concrétise ? 

Dans les principes un peu immuables chez nous, il y a : du code qui n’est pas testé n’est pas du code, tout simplement. S’il n’y a pas de test automatisé, ça ne sert à rien, et ce code ne doit pas aller en production. C’est une pierre angulaire qui était là avant moi et qui est toujours là. C’est pour ça qu’on fait autant de tests. Mais c’est aussi pour ça qu’avec nos 150 développeurs, dont la moitié n’était pas là l’année dernière, on est capable de mettre en production trois fois par jour.  

D’un autre côté, sur cette dimension, on fait attention à la work distribution. Un développeur passe 50% de son temps à faire des nouvelles fonctionnalités. 10% de son temps est consacré à la sécurité qu’on évoquait plus tôt. Ensuite, 15% de son temps est dédié à la correction des bugs.  Et après, il a 10% où il doit faire de la tâche technique, soit de l’optimisation, de l’amélioration et de la mise à jour de l’existant devenu obsolète. Le côté test, c’est non négociable. Il y a autre chose de très important pour nous, c’est la code review. Absolument aucun code ne peut partir sans avoir été revu par quelqu’un d’autre. Et cette code review, c’est bien plus que détecter des bugs. C’est aussi du partage de connaissances. Celui qui écrit code peut être junior ou senior et celui qui relie le code peut être également junior ou senior. En fait, toutes les configurations sont acceptables pour une code review. Ça peut être le classique : un senior qui revoit un junior. Il connaît les bonnes pratiques de la boite et va pouvoir lui prodiguer des conseils, le coacher, etc. Mais ça peut être dans l’autre sens ! Un junior aime toujours trouver le défaut dans le code d’un senior et du coup, il va être plus subtil, plus précis, etc. En revoyant son code, il va voir comment le senior travaille mais il va aussi s’amuser à aller plus loin pour trouver les petits défauts. Et autre configuration possible, deux juniors qui travaillent ensemble. Dans ce cas, ils vont s’auto challenger et être plus prudents car ils ont une grande responsabilité. Toutes les configurations sont top. 

Comment est géré la montée en compétences des équipes ? 

Comme je le disais, il y a la Doctolib Tech Académy qui est maintenant le Tech and Product Camp. Toutes les sessions sont documentées pour que chacun puisse y retourner si besoin. Mais il y a autre chose chez Doctolib que j’aime beaucoup aussi. Historiquement, ça s’appelait Starsky et Hutch, aujourd’hui, ça s’appelle Unique. Au fur et à mesure que l’on a été confrontés à des problématiques de recrutement, de croissance et de formation, on a mis en place un programme qui consiste à apprendre en duo avec une autre personne de Doctolib un ensemble de compétences (Elastic Search, React…) pour être performant au sein de l’entreprise. L’idée est de se challenger à deux sur ces sujets jusqu’à ce que chacun ait atteint le niveau minimum requis. C’est basé sur le volontariat, mais finalement tous les développeurs suivent cette co-formation. C’est une vraie opportunité ! Nous avons aussi mis en place un tech time. Toutes les deux semaines, chaque équipe partage des fails ou des succès. On a aussi des moments durant lesquels les tech holder partagent leurs projets au reste des équipes.   

Sur la partie process/organisation, comment tu abordes la méthodologie agile ? Est-ce que tu l’appliques à la lettre ou bien est-ce que tu l’as adaptée à Doctolib ?  

Quand j’ai découvert ces méthodologies agiles il y a longtemps, je suis devenu fan et je voulais les appliquer partout. Puis, en fait, au fur et à mesure de mes expériences, je me suis rendu compte que c’était contextuel. En arrivant chez Doctolib, j’étais assez mûr pour savoir qu’il fallait s’adapter. On a commencé par une méthodologie à l’arrache qui représentait le minimum puis on l’a fait évoluer au fur et à mesure des années. La seule chose qu’il faut appliquer dès le départ, c’est l’amélioration continue. Et le plus simple, c’est une rétrospective et peu importe son format. 

Aujourd’hui, chez Doctolib, toutes les équipes possèdent un socle commun. Mon travail est d’arriver à préserver ce socle commun pour m’assurer qu’on peut contrôler, que les équipes restent dans les règles, éviter de les réinventer à chaque fois et piloter plus facilement au niveau macro. Il y a un socle commun mais, dans les grands principes, chaque équipe choisit la méthodologie qu’elle veut. Certaines vont préférer Scrum by the book avec des sprints très définis de deux semaines. D’autres vont faire des planning poker alors que d’autres pas du tout. Certaines équipes utilisent la méthodologie Kanban. D’autres consacrent une journée entière aux bugs pour être certaines d’avoir fait leur 20% quand d’autres attribuent ce travail à une seule et même personne. Les équipes s’adaptent. Et pour moi, c’est le plus important. Il n’y a jamais une méthodologie unique qu’on peut trouver dans un livre et l’appliquer tel quel. C’est très contextuel et ça se fait forcément pas après pas. 

Quelles ont été pour toi les bonnes décisions en termes de management de la tech chez Doctolib ? 

Pour moi, le mieux, c’est responsabiliser les équipes. Et ça peut être effrayant ! Doctolib, c’est une grosse machine. Quand on buggue en pleine journée, l’impact, le stress et la pression générés sont impressionnants. On peut avoir peur, avoir envie de se protéger et de laisser que les choses importantes aux sachants. Mais en vrai, nous, ce qu’on fait depuis le début, c’est responsabiliser le plus possible. Et ça a plein de vertus ! Par contre, il faut encadrer et accompagner mais c’est extrêmement puissant. Ça aide les équipes à prendre conscience de ce qu’ils font et c’est fun pour eux. En général, plus on donne de responsabilités, plus elles s’épanouissent, grandissent et restent. 

Avec un peu de recul, il y a des choses que tu aurais fait différemment ?  

Oui, il y a ce côté middle management qui est très dur et long à construire. Et sur ce côté-là, j’ai trop traîné. Je n’ai pas été assez rapide sur les perspectives d’évolution possible. Même si j’avais la vision, j’ai mis du temps à la partager et à l’exécuter. Et c’est arrivé dans les premières années où j’avais quasiment 20 personnes en direct report. Et je savais que la bonne limite, c’est environ 7 personnes. Mais ne trouvant pas de relais au niveau du management, ça a pris énormément de temps. Surtout qu’il ne faut jamais baisser la barre sur le recrutement. Je ne trouvais pas de manager au niveau et ça a commencé à devenir compliqué à gérer.

C’est tellement long et compliqué de trouver les bons managers qui sont en adéquation avec les valeurs et qui sont assez pertinents. Et j’ai commis cette erreur à deux moments différents ! Aujourd’hui, je suis content de mon équipe de management mais ça a été très laborieux pour la construire. Je pense que j’aurais pu mieux anticiper la stack managériale. Quand tu commences à te dire que ça commence à être compliqué, c’est déjà trop tard. Tu peux mettre des années à construire la bonne équipe.  

En tant que VP Engineering, quels sont tes objectifs ? 

Aujourd’hui, je pense qu’ils sont très hétérogènes. Les premières années, ça tourne beaucoup autour du recrutement, de la gestion, de la structuration… Aujourd’hui, il y a toujours le recrutement et le suivi des KPI. Je dois aussi m’assurer que les équipes sont en phase et qu’on partage le même point de vue.  Et en ce moment, je travaille avec l’équipe sur une nouvelle mission. Aujourd’hui, Doctolib n’est plus une start-up, c’est une scale-up avec des ambitions très fortes. Et pour aller plus loin et continuer d’évoluer, on cherche l’inspiration à l’étranger. Notre moteur est très bien huilé mais ne sera probablement pas suffisant pour nos ambitions. Alors on réfléchit en ce moment à faire une transition vers quelque chose capable de supporter notre croissance. Je regarde donc du côté de Netfix, Airbnb… Des entreprises qui ont vécu un scale vers lequel on tend.  

Aujourd’hui, tu échanges avec eux pour connaître leur expérience et leur retour ?  

Clairement, oui. C’est ça que j’adore déjà en France. Je trouve qu’il y a une très bonne communauté tech. C’est un petit monde et tout le monde se parle et est ouvert. Franchement, il ne se passe presque pas une semaine sans que je parle à un CTO d’une autre entreprise, ou un VP, ou un director en France. Et ensuite, il y a beaucoup d’ingénieurs français dans les start-ups américaines. C’est très facile de trouver un contact. En plus, comme on est beaucoup aujourd’hui chez Doctolib, on profite du réseau de nos collaborateurs. Avoir une discussion informelle avec ces entreprises, c’est franchement possible et toujours super enrichissant. 

Lorsqu’on évolue comme toi, on se rend compte, à titre personnel, que ses limites peuvent être atteintes. Des limites techniques, de compétences ou bien en management. Comment tu gères l’évolution de ta carrière et le fait que parfois tu peux être amené à recruter ton propre patron ? Ça demande une grande acceptation de ses limites ? 

Le premier truc, c’était l’exemplarité d’Ivan et Jessy. Ils étaient co-fondateurs mais ils sont venus me chercher pour les aider. Et finalement, notre trio fonctionnait plutôt bien, on a réussi à créer une organisation from scratch de 0 à 80 au niveau du Tech and Product. C’est un beau challenge ! Mais à un moment donné, on a fait face aux ambitions de notre CEO qui voulait nous faire passer à 160 l’année prochaine, 320 l’année d’après, puis 600, puis 1000. Alors on s’est remis en question. Jusque-là, j’avais déjà utilisé toutes mes compétences et mes outils pour passer de 0 à 80. C’était déjà génial ! On a donc pris la décision de recruter quelqu’un pour passer au niveau supérieur. Ivan et Jessy, ça leur allait bien car ils aiment rester près du code et du produit. Et, même s’il faut rester objectif dans le recrutement, je ne vais pas mentir, en rencontrant Philippe, j’ai tout de suite senti un feeling. Il avait de sérieuses compétences et on s’est bien trouvés et on s’est fait confiance. Lui, il a soulevé le capot, il a vu qu’il y avait un bon moteur qui fonctionnait bien donc il m’a fait confiance et laissé beaucoup de liberté. Et moi, j’étais très content d’avoir quelqu’un qui me faisait des retours sur mon travail, qui me confirmait que j’allais dans la bonne direction et qui me recommandait parfois quelques ajustements.

D’un autre côté, le fait que je sois là et que tout marche bien, ça lui a aussi permis d’occuper d’autres rôles dans l’organisation. On est passé à un niveau supérieur grâce à sa séniorité et ses expériences. Et moi, j’ai retrouvé un mentor. Ce que je n’avais plus depuis quelques années ! Et ça, c’est top ! C’est donc une décision au départ qui peut sembler dure, et si le feeling n’était pas passé avec Philippe ça aurait été compliqué, mais en vrai, c’était nécessaire. Il faut accepter d’avoir encore plein de choses à apprendre. On en aura toujours ! 

Comment tu vois l’évolution de ton rôle ? Est-ce que tu te dois d’être toujours à la pointe, de continuer de coder et de comprendre vraiment la tech ? Ou est-ce que tu laisses ça aux autres ?  

C’est un sujet personnel je pense. A titre personnel, je regrette aujourd’hui de ne plus coder. L’autre jour, j’ai bidouillé un truc pour rigoler et j’ai pris beaucoup de plaisir. Mais en vrai, d’un point de vue professionnel, pour moi, c’est une évidence : je ne dois plus coder. Pourquoi ? Parce que ce n’est plus la priorité. Quand on est manager, la première chose à se demander, c’est est-ce que les gens vont bien ? Si tout est ok, alors je peux passer à la mission d’après : est-ce qu’on délivre bien ? Est-ce que la qualité est au rendez-vous ? Si là-dessus, tout va bien, je passe à la suite. Niveau produit, est-ce qu’on fait la bonne chose ? Est-ce qu’on va dans la bonne direction ? Et enfin, après tout ça, il y a encore des choses plus transverses : est-ce que les équipes fonctionnent entre elles ? Etc… Et à la rigueur, si tout cela est bon, alors éventuellement, je peux aller coder. Mais en vrai, quand bien même j’y arrive, il y a forcément une urgence ou un imprévu qui va arriver et que je vais devoir gérer donc ce n’est pas pertinent car je vais finir par laisser tomber, rendre quelque chose de brouillon ou ne pas avoir le temps de le finir.  

Par contre, cette transition est très graduelle. Je pense que quand on devient manager pour la première fois, on code encore 70% de son temps. Et petit à petit, au fur et à mesure du niveau d’abstraction qu’on a en tant que manager, on doit moins coder. Néanmoins, un quart de mon temps, est dédié a de l’impact technique. Ce n’est pas par du code, ni par de la code review, mais c’est par des workshop de cadrage technique, de l’architecture, des grandes décisions sur les scripts, etc… Et je pense que n’étant plus dans le code ; en l’ayant été, mais en n’y étant plus ; on a encore parfois plus de puissance et de recul. On a un degré d’abstraction plus haut et ça permet de prendre de meilleures décisions.  

Un mot sur l’avenir. Les road map, vous les planifiez à quelle échéance ? Parce que finalement, vu votre rythme, vous devez naviguer à un horizon assez proche ? 

Complètement ! On n’est jamais à plus de 3 mois. Bien sûr, on a une stratégie sur le long terme mais sur les fonctionnalités à développer et les projets, ça ne sert à rien de voir plus loin. Tout bouge tellement vite qu’il y a d’autres choses qui vont forcément arriver rapidement comme la téléconsultation, le Covid, la vaccination, etc. Il faut s’adapter au marché ! Et nos road map n’en sont pas vraiment. Comme je l’expliquais, on fonctionne plutôt par des KPI par équipe qu’on remet en question tous les 6/9 mois et les équipes revoient leurs projets toutes les 6 semaines environ. Et il y a toujours des imprévus et des changements de priorité ! 

C’est grisant ou c’est plutôt flippant d’être à ce point visible chez Doctolib ? Ça te plait cette exposition au sein du groupe ? 

Alors, il y a un côté clairement grisant et assez flou. Je me rappelle deux jours après mon arrivée à Doctolib, on m’a prévenu qu’on allait passer sur France 2. Aujourd’hui, c’est un peu plus fréquent mais ça devient le quotidien et on s’habitue. Mais en fait, c’est grisant et passionnant, surtout de sentir qu’on peut avoir un impact positif ! C’est certain, on a un fort degré de visibilité chez Doctolib.

Les premières années, on était considérés comme les sauveurs, la super startup, etc. Et maintenant qu’on est de plus en plus visibles, il y a ce revers de la médaille qui est délicat à gérer. On pointe un peu plus du doigt les mauvais côtés et on nous critique. Mais, je suis chez Doctolib depuis 5 ans, et de mon point de vue le plus sincère du monde, on essaye de faire de nombreuses choses positives. On investit par exemple énormément sur la sécurité et on essaie tous les jours d’aller plus loin pour aider la sécurité dans la tech française et européenne. On a des gens passionnés qui se démènent quand il faut aider le gouvernement pour les centres de vaccination, etc. Et puis, de temps en temps, on reçoit plein de critiques sur les réseaux sociaux ou à la télé, etc. Parfois, c’est clairement injuste. Donc, c’est dur. Mais c’est le revers de la médaille. Et puis, c’est aussi intéressant de vivre ça de l’intérieur. Se rendre compte de comment l’image de Doctolib a changé dans les médias et est passé de la petite start-up toujours adulée à une plus grosse entreprise critiquée, alors qu’à l’intérieur, rien n’a changé. Ce sont les mêmes personnes passionnés et bien intentionnés.  

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.