S01E04 · Leçons de Facebook et de Twitter, et rôle du CTO

0:03 Parole de Tech Leaders, le podcast Tech.Rocks qui donne la parole aux Tech Leaders. Tech.Rocks, la communauté qui rassemble, connecte et valorise les tech leaders d'aujourd'hui et de demain. Bonjour, je suis Hervé Lourdin, CTO et co-directeur de VideDressing, et pour ce nouvel épisode, j'ai le plaisir de recevoir Charles Gorintin, co-founder et CTO d'Alan. Bonjour Charles. Bonjour Hervé. Eh bien écoute, je te propose de commencer dans le vif du sujet en nous racontant un petit peu plus sur toi. Qui es-tu? Donc j'ai 32 ans, j'ai un enfant de 1 an, je suis passionné de foot, d'échecs et de littérature romantique française du 19e siècle, plus précisément Balzac. Chouette, aucune place à l'informatique dans cette description, c'est bien, ça change. Je te propose du coup d'aller un petit peu plus dans le détail de nos métiers, puisqu'on est là pour échanger autour de nos pratiques de tech leaders. Quel est ton parcours? J'ai commencé par étudier à l'école des ponts. Ensuite, j'ai fait un master de machine learning à Paris.

1:06 Et puis je suis parti à San Francisco, à Berkeley plus précisément, pour aller faire une business school là-bas. Alors que tous mes camarades partaient dans des banques, dans des hedge funds, moi j'ai décidé d'aller travailler en tant que data scientist chez Facebook. C'était un petit peu une évidence pour moi à l'époque, parce qu'ils avaient des pétaoctets de données, des outils pour pouvoir les analyser, et surtout un milliard de personnes sur qui on pouvait avoir un impact. Et donc j'ai rejoint Facebook, j'ai commencé à travailler chez eux sur la lutte contre les faux comptes, avant que ce soit la mode, ainsi qu'un projet qui s'appelait Compassion, où on travaillait avec des psychologues sociaux de Berkeley, de Yale, pour aider les gens à résoudre leurs problèmes sur Facebook. Ensuite, je suis allé chez Instagram, où j'ai travaillé sur la première plateforme de pub. À l'époque, le CEO d'Instagram, Kevin Systrom, validait chaque pub qui s'affichait sur Instagram. Ce n'est plus le cas aujourd'hui. Et puis, je me suis fait débaucher par Twitter pour gérer leur équipe de data science en growth.

2:08 J'ai passé deux ans chez Twitter. On a résolu pas mal de problèmes. Ça s'est super bien passé. Et puis, mi-2015, Jean-Charles Samuelian, que je connaissais depuis l'école des ponts, est venu me voir pour qu'on crée ensemble Alan. Et donc, en janvier 2016, je suis rentré en France. On a créé Alan. Et depuis, ça fait trois ans et demi qu'on travaille dessus. Chouette parcours, on peut dire que c'est un joli pédigré, c'est quand même des très très jolies entreprises à ton actif. Ça m'intéresse qu'on creuse un tout petit peu ça, parce que finalement c'est un peu inédit, ou en tout cas on est toujours curieux de savoir ce qui se fait outre-Atlantique. Est-ce qu'il y a des pratiques particulières que tu as retenues de ces années chez Facebook, Instagram ou Twitter que tu as eu envie d'importer chez Alan? Il y a quelque chose qui est important, c'est que moi, c'était mon premier job à plein temps chez Facebook. Ce qui veut dire que... Je n'avais pas vraiment de très bon référentiel sur ce que devrait être un milieu où on travaille qui est sain. Et donc, chez Facebook, j'ai appris surtout la responsabilité, l'autonomie, le fait de faire confiance aux personnes avec qui on travaille, une culture de l'ingénieur qui est un petit peu unique.

3:19 En fait, je m'en suis rendu compte au moment où je suis rentré en France. Donner beaucoup de moyens à l'ingénieur. Et typiquement, le genre de choses qu'on entendait là-bas, c'est qu'un prototype vaut 1000 images. Et comme on sait, une image vaut 1000 mots. Donc un prototype valait un million de mots. Donc en fait, ça donnait beaucoup, beaucoup de... De valeur aux ingénieurs qui pouvaient construire, essayer et faire évoluer le produit. Et ça, c'était vraiment une grande force. Ensuite, d'avoir fait et Facebook et Twitter, c'était extrêmement intéressant parce que ça m'a permis de pouvoir comparer deux cultures. De pouvoir comprendre ce qui marchait dans l'une, ce qui ne marchait pas dans l'autre. C'était assez intéressant, en particulier Facebook et Twitter, parce que Twitter avait beaucoup d'anciens de Google, donc c'était un petit peu la culture Google, alors que Facebook est un petit peu sorti du chapeau, il y avait la plupart des ingénieurs chez Facebook, sortaient tout juste d'université et ont dû inventer une culture de zéro.

4:25 Et c'était quoi, du coup, les grandes différences pour toi, marquantes entre ces... Deux cultures ? Alors, ce qui était intéressant, c'est que Facebook, c'est très... On va essayer et ensuite on voit comment ça se passe, on voit si les utilisateurs suivent. Alors que Twitter et en fait la culture Google, c'est plutôt on va réfléchir très fort, on va tout définir. Comme ça, on va savoir si on va construire quelque chose qui est théoriquement sain avant de l'appliquer en pratique. Super intéressant comme retour. Je pense qu'on a rarement l'occasion d'avoir ces deux points de vue-là. Tu avais cette opportunité de vivre. deux cultures assez différentes dans des boîtes qui sont plutôt références, en tout cas dont on s'inspire souvent et dont on parle souvent. Merci. Qu'est-ce que tu as ramené dans tes valises et que tu as essayé d'implémenter chez Alan? En fait, c'est assez intéressant chez Alan. Donc, on avait un petit peu une combinaison de deux cultures. Donc, mon cofondateur, Jean-Charles Samuelian, qui avait déjà créé une entreprise avant, qui s'appelait Explicit, en fait, qui fait toujours des sièges d'avion.

5:27 Il a fait toutes les erreurs qu'on a su ensuite éviter en termes de start-up. Et moi, je venais avec mon bagage d'entreprise américaine, avec des cultures qui étaient très établies, des entreprises qui avaient déjà plusieurs milliers de personnes. Et donc, ce qui me permettait de voir le milieu de l'aventure, on va dire. Et donc, la combinaison des deux, avoir appris exactement cette autonomie, cette responsabilisation et en même temps le... La sensation de comment est-ce qu'on construit une startup, cette combinaison a été extrêmement puissante et à mon avis nous a aidé dans la construction d'Alan. Est-ce que tu as constaté une différence culturelle quand tu es arrivé en France et que finalement tu t'es replongé dans la tech mais en France? Est-ce qu'il y a des choses qui te paraissaient évidentes aux Etats-Unis et en arrivant en France tu te dis tiens c'est bizarre ça n'a pas l'air de marcher? Je pense que c'est vraiment sur le rôle de l'ingénieur. C'est vraiment un petit peu différent. En fait, moi, ma culture, c'est qu'un ingénieur va avoir beaucoup de...

6:30 beaucoup d'autonomie, beaucoup d'opportunités de pousser, construire du produit, décider de ce sur quoi il doit travailler. Alors qu'en face, en France, on a plutôt eu tendance à avoir des personnes à qui on préparait le travail pour qu'ils puissent se concentrer sur du code. Pour moi, le rôle de l'ingénieur est beaucoup plus large que le code. Merci, je pense qu'on va recreuser ça un petit peu plus tard dans l'entretien, ça m'apparaît un point super intéressant. Mais je propose qu'on avance un petit peu plus sur Alan cette fois-ci. Est-ce que tu peux nous raconter un petit peu plus ce qu'est Alan, quel est ton job aujourd'hui, la boîte, sa taille? Pour créer Alan, en fait, on est parti d'un constat qui était simple, c'est que le système de santé était complètement enrayé, que les personnes étaient de plus en plus victimes du système. On a pu le voir récemment avec la crise des urgentistes. Et donc, avec Alan, on s'est mis en quête de réinventer le système de santé pour pouvoir le recentrer sur les utilisateurs. Pour faire ça, on a commencé par construire la meilleure assurance santé, que certains appellent mutuelle, et on a essayé de la créer d'une certaine manière où c'est l'assurance santé qu'on voudrait avoir nous.

7:41 Donc on a créé ça depuis zéro, on a obtenu un agrément d'assurance. Il n'y avait pas eu de nouvelle assurance indépendante en France depuis 1986. J'étais même pas né. Et donc, on a recréé cette assurance de zéro. Et le but, c'est de fournir à nos utilisateurs... des services pour qu'ils soient en meilleure santé. Et en fait, c'est pour ça qu'on parle maintenant de Alan comme l'assurance santé qui fait du bien. Plus en détail sur ton job de CTO, quels sont les votes de stack, tu as combien d'équipes? Mon rôle aujourd'hui, c'est à la fois CTO et cofondateur. Mon rôle est un petit peu plus large que celui classique de CTO. Je travaille surtout sur la construction de l'équipe d'ingénieurs. Un petit peu de produits, un petit peu de customer service, parce que je pense que c'est très important, un petit peu de data, parce que c'est aussi mon background. Et donc, plus précisément sur mon rôle de CTO, aujourd'hui, l'équipe d'ingénieurs d'Alan, c'est 30 personnes.

8:45 On est en train de la faire grandir beaucoup. C'était que... 7 personnes début 2018 et on veut aller à 42 personnes à la fin de l'année. Et donc tu me demandais par rapport à notre stack, aujourd'hui on utilise Postgres, Python Flask et dans le front React et React Native sur les applis. Tout ça hébergé sur AWS et ERO. Et donc du coup, dans tes équipes, en filigrame, j'ai l'impression que chez Alan, on essaie de demander un peu plus aux développeurs, et d'ailleurs, on en reviendra après, parce que le titre en tant que tel n'existe pas forcément, le produit est intégré dans les équipes de la technique, ou est-ce qu'il y a une entité produit, ou est-ce qu'en fait, c'est les ingénieurs qui font et le code et le code? Le product management, tonership ? En fait, la manière dont on l'a pensé, on a défini ce qu'on a appelé des crews. C'est équivalent à des feature teams ou des squads, mais on a voulu mettre notre propre mot, comme ça on pouvait contrôler la définition.

9:47 Et donc chaque crew est composé d'un crew lead qui en général est un ingénieur, plus de quatre autres ingénieurs, un demi-product manager, un demi-designer, un demi-data scientist. Et ce petit groupe va aller travailler sur un sujet de manière hyper focalisée. Et notre petit twist, c'est qu'au bout de trois mois, on fait expirer ces crews. D'accord, donc les équipes se disloquent tous les trois mois. Voilà, elles se dissolvent tous les trois mois. Après, on peut reconduire certaines crews. Mais ça nous permet de choisir les sujets sur lesquels on a envie de travailler. Ça permet de créer beaucoup de mobilité entre les équipes et qu'on partage la connaissance de manière beaucoup plus forte. Et ensuite, ça permet d'avoir ces rôles, comme je l'ai dit, il y a beaucoup d'ingénieurs par rapport au nombre de product managers. Ça permet que les ingénieurs aient un rôle produit qui soit très fort. Ok, très très clair. On a vu un peu ce genre de pratique chez Bestcamp, où effectivement ils ont ces équipes qui se créent puis se disloquent fréquemment.

10:51 J'ai l'impression que c'est une mouvance assez intéressante dans les orgas et ça fait tourner beaucoup de choses. La petite différence avec Bestcamp, c'est qu'en fait Bestcamp ils sont restés une entreprise relativement petite en termes de taille. Ils sont une soixantaine. Et donc nous aujourd'hui on est 150 et on va continuer à grandir. Donc il va falloir à tout moment qu'on continue à faire évoluer ces pratiques et à repartir des premiers principes pour pouvoir construire notre organisation de demain. Petite question, figure de style imposée de l'interview, est-ce que tu codes encore? Alors, je ne code plus rien qui soit critique. ou qui soit sur le passage critique. Je fais de temps en temps des petits outils. Je fais de temps en temps des petits tickets de on-call, en fait, résoudre des bugs pour notre équipe de customer service, parce que j'aime ça et ça me permet de garder la main. Mais après, je sais que de toute façon, je ne suis pas le meilleur ingénieur. Encore moins aujourd'hui.

11:53 Et donc, je suis très content d'avoir laissé la main. Qu'est-ce que ça serait pour toi un tech leader ou un CTO? Est-ce que tu saurais nous donner ta définition du CTO? Les définitions de CTO, en général, il y a plus de définitions que de personnes dans la salle. Chaque personne a une définition différente. Moi, ma définition du CTO, elle change à peu près tous les six mois. En fait, mon background est un petit peu particulier parce que je n'avais jamais été software engineer avant de devenir CTO. Donc, ce qui fait que mon rôle a toujours été de me mettre dans une position d'humilité où je vais poser des questions et essayer de trouver la meilleure réponse d'une façon un petit peu socratique avec des ingénieurs qui étaient, dès le début, plus forts que moi. Et donc, moi, je vois vraiment le rôle du CTO comme quelqu'un qui va aider toute l'équipe à shipper plus de produits. Et en fait, mon rôle, c'est d'être sûr qu'on optimise à quel point on shippe du produit, non seulement aujourd'hui, mais demain et après-demain et dans 10 ans.

12:57 Quand on a un peu discuté avant l'entretien, tu me partageais aussi nos... de pratiques que j'avais déjà entendues auprès d'autres connaissances, tu essaies de faire en sorte de te virer tous les six mois ? Oui. Alors, je pense que c'est hyper important. Et ce que j'ai essayé d'expliquer un petit peu en disant que le rôle de CTO change tout le temps, c'est que tous les six mois, comme notre entreprise grandit, il faut que je change de travail. Si je continue de faire quelque chose six mois plus tard, ça veut dire que j'ai raté soit à déléguer cette chose-là et donc d'avoir trouvé quelqu'un de plus fort que moi pour travailler sur cette chose-là. Soit qu'on n'a pas résolu le problème. Et donc, c'est hyper important pour moi de ne plus faire de six mois en six mois le même rôle. Et c'est pour ça que le rôle de CTO, pour moi, est mouvant, d'une certaine manière. Super intéressant. J'aime beaucoup cette définition de CTO. Quelle est selon toi la qualité la plus importante à avoir en tant que CTO? Je pense que c'est l'ouverture.

13:58 C'est être capable d'accepter un petit peu toutes les idées, être honnête intellectuellement et être capable d'avoir des gens autour de soi qui soient plus forts que soi, qui peuvent apporter les solutions et essayer de les aider à accoucher de la meilleure solution. Je te propose de zoomer un petit peu plus sur la culture et les pratiques chez Alan. Je lis assez régulièrement vos posts, ce que je trouve plutôt intéressant. Vous avez une... position assez franc-tireur, un peu poil à gratter, je trouve, dans les posts qu'on peut lire plus classiquement autour de nous, sur la scène des leaders techniques en France et ailleurs. Et du coup, j'avais un peu envie de creuser ça. Quand on lit un peu vos posts, et j'imagine qu'en tant que cofondateur, tu y es pour quelque chose, la transparence est quelque chose de très fort chez vous, vraisemblablement. Vous y êtes très attaché. Et vous avez... Décider un feu de pratiquer, on ouvre tout, notamment à l'image de Buffet, couvrait ses salaires, la distribution des quittes, etc.

15:03 Vous, vous avez une grille de salaire qui est ouverte et vous avez décidé de faire ça avec tout. Toute la boîte? Alors, on a fait ça, et c'était un grand avantage, c'est qu'on l'a fait, il y avait juste Jean-Charles et moi dans la boîte, zéro personne qui était salariée, et on a décidé de créer cette grille qui soit transparente, qu'on puisse partager à l'extérieur, et donc on l'a publiée. Ce qui est assez drôle, tu as mentionné Buffer, mais on a recruté plus tard une responsable RH de chez Buffer qui gère les people chez nous, Deborah et Paul. Et donc, en fait, on a défini depuis le début quatre valeurs qui sont très importantes pour nous. La première étant... Radical Transparency. Cette valeur, on l'utilise, on essaye de pousser jusqu'au bout à quel point on peut être transparent. Et typiquement, les salaires, c'est quelque chose, tout le monde va savoir combien chacun va gagner dans une entreprise, parce que les gens parlent, parce que ça se sait au bout d'un moment.

16:06 Donc on s'est dit, pourquoi pas le rendre complètement public, En fait, ça a de multiples avantages. D'une part, ça permet d'être sûr que les personnes soient payées à leur juste valeur. En fait, on peut leur dire avant même qu'ils commencent le processus de recrutement, voilà les différents niveaux, voilà à quoi tu peux t'attendre. Et voilà la définition des grilles de niveau. Comme ça, tu as des niveaux. Tu peux savoir qu'est-ce que tu gagnerais si tu rejoignais Alan. Ensuite, c'est hyper important pour recruter des personnes à l'étranger. Dans l'équipe, on a beaucoup d'Américains, notamment des gens qui reviennent de Silicon Valley. Moi, j'étais un petit peu le premier exemple. Pour rentrer en France, il fallait que je divise par quatre mon salaire. Ce qui est OK parce qu'en fait, le coût de la vie en France est beaucoup plus faible qu'à San Francisco. Mais tout de go, c'est assez difficile de s'en rendre compte quand on est un Américain qui vit à San Francisco. Et donc, notre capacité de montrer cette grille et de dire, voilà, les personnes que tu respectes qui sont dans cette grille, dans notre entreprise, gagnent la même chose que toi.

17:15 On ne va pas essayer de t'escroquer quand tu vas arriver chez Alan. Et donc, avoir cette grille transparente, ça aide vachement de ce point de vue-là. Ensuite, autre chose qui est très importante, c'est que ça permet d'éviter toute négociation. Et la négociation, en général, ça fait que les personnes qui sont le plus fort et talentueuses en négociation vont être payées plus que les autres. Et typiquement, en termes de diversité, c'est très mauvais parce que les gens qui sont moins bien payés parce que... Dans la société, ils sont moins bien payés, ne vont pas être payés à leur bon niveau. Alors que nous, avec notre grille, on dit, voilà ton niveau d'expérience, ton niveau de compétence, tu reçois ce salaire. Et parfois, ça peut être 20 000 euros de plus que... leur ancien salaire. Et pour nous, c'est totalement acceptable. Alors, deux questions. Une première très opérationnelle. Vous faites comment quand le marché a tendance un peu à gonfler? Vous augmentez tout le monde d'un coup? On essaye de rester toujours légèrement au-dessus du marché. Plusieurs fois, on a réévalué notre grille au fur et à mesure des levées de notre capacité à payer, mais aussi en fonction du risque que les personnes prennent.

18:25 Plus les personnes arrivent tard, moins elles vont avoir de stock, des coûts. Et donc, plus on va compenser en salaire. Et autant cette pratique, elle a l'air assez... Parler d'argent est quelque chose de relativement simple, outre-Atlantique. En France, c'est autre chose. On a une culture un peu différente là-dessus. Est-ce que ça a valu des déconvenus ou est-ce qu'au contraire, du coup, c'est une espèce de filtre à l'entrée que vous souhaitez poser? Alors la difficulté, c'est quand on a un candidat qui s'attend à avoir 10 000 euros de plus que ce qu'on lui offre, On se dit, nous, c'est impossible, on ne peut pas négocier sur la grille. Donc, on perd certains candidats comme ça. Ok. Et c'est un filtre aux valeurs, j'imagine? Ça filtre aussi par rapport aux valeurs, mais ça aide certaines négociations aussi, parce que comme on est très transparent et clair sur notre règle qu'on ne négocie pas, en fait, ça permet à ce que la personne derrière n'essaie pas de négocier à tout prix. Super retour d'expérience. Il y a quelques boîtes sur la place française qui font ça et je pense que vous faites partie de ces rares boîtes qui ont cette audace de le faire.

19:29 Je suis très curieux qu'on en ait. On reparle dans quelques années, de voir un peu comment ça vit en grandissant. Autre point, il y a quelques mois, j'ai vu un de vos posts qui m'a interpellé, qui était, en fait, ma compréhension, c'est que vous n'étiez pas très fan du distinguo front-end, back-end, dans les descriptions, dans les job titles, et prenez plutôt de dire, on est tous des software engineers. Qu'est-ce qui se cache derrière ça? C'est quoi votre volonté quand vous essayez de lutter contre cette séparation-là? En fait, j'essaye d'éviter qu'il y ait des silos dans l'entreprise. Donc ce qu'on a décidé, c'est... était de recruter tout le monde en tant que full stack. En réalité, c'est plutôt des spécialistes qui se déguisent en généralistes. quelqu'un qui connaîtra très bien une petite partie du code, mais qui est suffisamment curieuse pour aller... Par exemple back-end developer, pour aller faire son bouton dans le front parce qu'il en a besoin, plutôt que de balancer la tâche au-dessus de la barrière et attendre que quelqu'un d'autre vienne et prendre deux, trois semaines de retard. Et donc, c'est pour moi extrêmement important de voir si ces personnes sont prêtes.

20:34 À toucher un petit peu à tout. Après, dans les faits, les personnes qui adorent faire du back-end vont plus faire du back-end, les personnes qui adorent faire du front-end vont plus faire du front-end, et je pense que c'est très bien. Mais casser les lignes, pour moi, est extrêmement important. Autre chose que j'ai appris à Facebook quand j'y étais, À Facebook, quand on est recruté en tant que software engineer, on passe tous par la même pipeline de recrutement. Et donc, une fois qu'on est recruté, on n'est pas recruté pour une équipe, on est recruté dans ce qu'ils ont appelé bootcamp. Et donc, pendant six semaines, on passe du temps à... Réparer des bugs un petit peu partout dans la code base avec différentes équipes. On passe des moments où on apprend parce qu'il y a des classes pour apprendre les différentes parties de la code base. Et à la fin des six semaines, on choisit son équipe. En fait, c'est une sorte de... de bourse de travail et on choisit son équipe à la fin des six semaines. Comme ça, on a suffisamment de contexte sur comment les équipes travaillent.

21:38 Et en fait, nous, on essaye de construire la même chose chez Alan. Donc, on a défini ce qu'on a appelé un Woodchuck programme où pendant six semaines, les personnes vont voir les différentes crews. Et à la fin, intègre une des crews pour pouvoir commencer à travailler à plein temps. Autre petite question qu'on aime bien poser pendant ces podcasts, il y a toujours beaucoup de responsabilités qui pèsent sur les épaules d'un CTO, et certains sont plus lourds que d'autres. Qu'est-ce qui t'empêche de dormir en ce moment? Si je prends la question de façon littérale, il y a mon fils. Mais de manière un petit peu... Non, il est très gentil en fait, il dort très bien. Si je la prends de manière figurée, je pense que c'était la question. En fait, il y a plusieurs sujets qui sont d'actualité en ce moment. On va ouvrir deux pays l'année prochaine. On va en Espagne et en Belgique. C'est la première fois dans l'histoire d'Alan qu'on va à l'étranger. Et donc, ça représente des challenges techniques et organisationnels qui sont un petit peu inédits pour nous.

22:44 Ils sont non seulement inédits pour nous, mais ils sont aussi très rares pour les autres entreprises parce qu'on a une particularité chez Alan, c'est qu'on travaille avec un système de santé et les systèmes de santé sont très différents d'un pays à l'autre. Là, ce qui m'empêche de dormir en ce moment, c'est savoir comment est-ce qu'on va pouvoir séparer notre code base, qui est aujourd'hui un monolithe qui travaille sur le système de santé français. Comment est-ce qu'on va extraire certaines parties? Qui seront utiles pour la France, pour l'Espagne, pour la Belgique, et d'autres parties qui sont utiles dans chaque pays. Et donc ça, c'est la partie technique. Ça fait des challenges techniques assez intéressants et assez uniques. Et ensuite, de manière organisationnelle, comment est-ce qu'on doit s'établir entre les différents pays? Est-ce qu'on met tous les ingénieurs à Paris? Est-ce qu'on met des ingénieurs en Espagne pour travailler sur l'Espagne, en Belgique pour travailler sur la Belgique?

23:49 Ou alors, et c'est là qu'on essaye d'explorer une nouvelle façon de faire, de faire quelque chose d'hybride. Donc, placer des ingénieurs en Espagne qui travaillent sur le repo central. Et garder certains ingénieurs en France qui vont travailler sur l'Espagne. Et comme ça, chaque équipe, chaque pays va pouvoir connaître les autres et créer beaucoup plus de communion dans notre équipe d'ingénieurs. C'est un peu une dérivée de cette pratique d'équipe de crew qui va se disloquer tous les trois mois. Et là, vous essayez de le porter à l'échelle de l'international. C'est un joli challenge. Et effectivement, ça soulève une grosse question qui est l'adéquation des équipes avec l'architecture. Une question qu'on se pose tous dans notre job dès lors où on commence à faire des choses un peu... Un peu difficile avec notre archi. Et du coup, là, vous avez une solution qui commence à émerger plus qu'une autre ou c'est encore à l'état de la réflexion? C'est encore à l'état de la réflexion. C'est mon thème des trois prochains mois. Et donc, on continue à recruter des gens qui ont de l'expérience là-dedans.

24:53 On est ravis de leur parler. Et en fait, c'est assez intéressant ce que tu disais sur l'adéquation entre l'architecture entre l'architecture. et les personnes. C'est aussi le deuxième point que je voulais aborder. Donc on a établi cette culture où on est très volatile, on va être très focalisé sur certains sujets pendant un certain temps. Mais la question qui doit être un petit peu naturelle, c'est qu'est-ce qui devient des crews qui ont fermé? Qu'est-ce qu'on fait de ce morceau de code? Comment on entretient l'asset? Exactement. Une des choses aussi qui m'empêche de dormir, c'est comment garder cette maintenance. Et donc la solution qu'on a trouvée aujourd'hui, c'est d'essayer d'avoir des owners. Donc c'est la deuxième de nos valeurs, distributed ownership. C'est que chaque personne dans l'équipe d'ingénieurs puisse être owner. Donc je ne saurais pas le traduire en français. D'une partie du système, d'une partie du code, et que chacune de ces personnes ait un backup, quelqu'un qui pourra la remplacer, ce qui permet d'augmenter le facteur bus.

26:02 Donc le facteur bus, typiquement, c'est si jamais un nombre de personnes N se faisait renverser par un bus demain, est-ce qu'on devrait fermer la boîte? Et donc, typiquement, on a envie de maximiser ce facteur pour que le plus de personnes puissent se faire renverser. On n'espère pas, mais qu'on puisse continuer à travailler. Et donc, pour revenir sur la maintenance, c'est vraiment essayer d'avoir un honneur, quelqu'un qui va... C'est le sujet qui va y passer à peu près 10% de son temps. Et un backup qui peut être quelqu'un de plus junior qui va être formé par l'honneur. Et comme ça, le jour où l'honneur... Et plus là, se fait renverser par un bus, décide d'aller travailler dans une autre entreprise, ou décide d'aller travailler sur autre chose chez Alan, il y a quelqu'un qui peut reprendre le flambeau et former à son tour quelqu'un d'autre. Très clair et super intéressant. Je pense qu'on traverse tous un peu ces moments, ces petits points de rupture dans l'histoire. Et on a vu que vous êtes en plein milieu d'un virage là. Ça va être intéressant de voir comment vous allez négocier à l'avenir.

27:04 Quelle est ta plus grande fierté après ces quelques années chez Alan? Je pense que c'est l'équipe. On a créé une équipe d'ingénieurs avec un équilibre qui est assez bon entre presque 50% de l'équipe qui est senior. Donc on définit senior comme équivalent à senior software engineer chez Google ou chez Facebook. Avoir cette équipe senior, c'est extrêmement important pour moi, parce que ça veut dire que derrière, on peut offrir une opportunité aux gens qui sont plus juniors d'apprendre et leur donner une bonne expérience pour qu'ils puissent grandir très vite. Et donc là, on peut revenir à notre grille de salaire et d'écoutis. C'est qu'on a des niveaux. Et tous les six mois, on revoit les niveaux pour tout le monde. Et notamment, on promeut les personnes sur la grille. Et donc déjà aujourd'hui, il y a eu sept fois des ingénieurs qui ont été promus sur cette grille. Et moi, ça me rend extrêmement fier d'avoir pu faire grandir des personnes dans cette équipe.

28:08 Des petites questions pratiques. Est-ce qu'il y a des outils ou des routines un peu indispensables dans ton quotidien? En fait, on aime bien un peu divulguer nos tips and tricks. C'est ces petits trucs qui nous facilitent la vie. Il y a des outils ou des routines que tu as dans ton quotidien que tu utilises toi régulièrement? Alors je vais commencer par un truc qui est personnel mais qui est extrêmement utile, c'est l'outil Alfred sur Mac. Oui, on a du mal à vivre sans. C'est extrêmement important, en fait on a même créé des workflows Alfred pour toute l'équipe pour pouvoir améliorer et faire qu'en moins d'une seconde, on puisse sortir quelque chose de sa tête, soit lié à une to-do, soit aller chercher une information. Comme ça, on peut vraiment itérer extrêmement rapidement. Alors que si on doit réfléchir, ouvrir une page et aller chercher quelque chose sur Internet, ça prend beaucoup plus de temps et donc on perd l'immédiateté, l'instantanéité de la pensée. Donc ça, c'est un truc un petit peu plus personnel de productivité.

29:10 Mais après, à l'échelle de la boîte, je pense que notre secret trick chez Alan, c'est qu'on a supprimé les meetings. Et en lieu et place des meetings, on utilise des issues GitHub. Alors, on les utilise non seulement dans l'équipe d'ingénieurs, mais aussi dans... Toutes les personnes de chez Alan, que ce soit en customer service, sales, stratégie, le CEO, tout le monde utilise des issues GitHub pour prendre des décisions. Personne n'a le droit de prendre des décisions en dehors d'une issue GitHub. C'est extrêmement intéressant parce que ça crée de la transparence radicale. Une issue GitHub, tout le monde peut l'avoir dans l'entreprise. On sait exactement ce qui s'est passé parce qu'il y a une personne qui écrit le problème qui est... cherche à résoudre avec un template qui explique le sujet, la proposition, les questions, la timeline. Et en fait, ça permet que tout le monde puisse réagir.

30:13 Les gens qui ont des choses avec lesquelles réagir peuvent réagir, même s'ils n'ont pas été invités au meeting. Donc ça, c'est extrêmement important sur la transparence. Et d'autre part, c'est extrêmement important sur notre valeur d'ownership, dans le sens où c'est toujours la personne qui a ouvert les chiots qui prend la décision à la fin. Donc tout le monde peut prendre une décision chez Alan? Tout le monde peut prendre une décision chez Alan. Et donc un exemple dans l'équipe d'ingénieurs, c'est une personne dans l'équipe qui est relativement junior, qui a décidé d'ouvrir un sujet sur si on devait typer notre piton. Un sujet qui, je pense que tu le sais autant bien que moi, qui peut être assez périlleux, créer pas mal d'émotions dans les deux camps. Mais cette personne a pu décrire le problème, décrire les critères de décision, prendre les feedbacks des différentes personnes qui donnaient des arguments pour pouvoir à la fin prendre une décision. Cette personne, après la décision, contesterait de typer notre piton pendant trois mois. Au bout de trois mois, cette personne-là a fait le point, a vu que les pros n'étaient pas suffisamment bons par rapport aux cons.

31:22 Et cette personne-là, unilatéralement, mais en fait avec les conseils de toutes les personnes, senior et autres de l'entreprise, a pris la décision d'arrêter de typer. De revenir à l'origine. Voilà. Et en fait, pouvoir gérer ces projets alors même qu'on est à un niveau assez junior, je pense que c'est une expérience qui est assez géniale. Et moi, j'ai été vraiment content de pouvoir voir que ce processus pouvait marcher. Sur nos derniers échanges, tu nous as décrit deux des valeurs parmi les quatre d'Alan. La première étant la transparence radicale et la seconde la propriété collective. Quels sont les deux autres? Les deux autres sont Fearless Ambition. On a de grandes ambitions et on se dit que... Jamais rien n'est trop gros pour être cassé. Typiquement, on a réussi à créer une assurance en France alors que ça faisait 30 ans que ça n'avait pas été fait. Et on l'a fait en 6 mois. Donc on se dit, on a toujours une capacité à avoir des grandes ambitions et on trouvera les moyens pour pouvoir les atteindre.

32:31 Et la quatrième de nos valeurs, c'est Personal and Community Growth. En fait, c'est extrêmement important pour nous d'être certains que les personnes de l'équipe grandissent et qu'en tant que communauté, on grandisse tous. Donc, ce qui fait qu'on est très à l'aise avec RAT, ce qui rejoint un petit peu nos Fearless Ambition, c'est que parfois, on va avoir des échecs. Et c'est très bien à partir du moment où on a appris. Et si on apprend, on peut grandir, on peut s'améliorer. Et à terme, on peut devenir la meilleure équipe qui puisse exister. Alors, dernière question, pareil, figure-t-il un peu à poser maintenant. Si je te donnais une baguette magique, tu as le droit à un seul vœu, mais tu peux faire ce que tu veux. Qu'est-ce que tu ferais? Ce que je ferais, c'est que je téléporterais tout le talent qui est à San Francisco à Paris. Je pense qu'on est en train de construire vraiment beaucoup de talent, beaucoup de... Il y a beaucoup d'ingénieurs talentueux à Paris, des gens qui ont eu de très bonnes expériences à l'étranger.

33:33 Malheureusement, on a assez peu d'entreprises chez qui on peut piocher à Paris. Si j'étais à San Francisco, j'aurais débauché plusieurs execs de Google et des ingénieurs de Facebook. À Paris, c'est beaucoup plus difficile parce qu'il n'y a pas eu vraiment de très grandes entreprises, de dizaines de milliers de personnes qui ont formé une génération d'ingénieurs et d'exécutifs qui étaient suffisamment seniors. Et donc, si je pouvais rapatrier toutes ces personnes qui sont à San Francisco, qu'ils soient français ou pas français, à Paris, ça me lèverait une belle épine du pied. J'ai l'impression que c'est un vœu qu'on a un peu tous en commun. On aime bien aussi partager un peu la nourriture de l'esprit. Est-ce qu'il y a des bouquins que tu recommanderais dans tes dernières lectures à nos auditeurs? J'ai un peu commencé par ça. J'adore lire. Et je pense que lire, c'est une manière de rentrer dans l'esprit de gens qui l'ont déjà fait. J'adore pouvoir comprendre un petit peu les premiers principes que les personnes ont pu adopter pour créer de superbes entreprises.

34:38 Donc quelques références qui m'ont beaucoup marqué. Une que je trouve extrêmement intéressante, c'est Reinventing Organizations de Frédéric Laloux. C'est un bouquin qui explique déjà l'histoire des organisations, comment elles ont évolué au fur et à mesure, et qui montre un passage vers une meilleure organisation qui soit... basé sur la responsabilité, sur la confiance, et qui pourra faire que les humains soient encore plus productifs qu'ils n'ont été dans le passé. Ce bouquin-là, je le recommande très fortement si on essaye de réfléchir à des organisations. Un peu d'influence du coup de la crassie au sein d'Alan? C'est quelque chose qui... C'est des choses desquelles on s'inspire, on regarde, on repart des premiers principes. Est-ce que ça peut s'appliquer au contexte d'Alan? Est-ce que ces principes sont en accord avec nos valeurs? Et quand certaines techniques marchent, on les applique. Mais j'évite de rentrer dans certaines cases parce que notre culture évolue, notre taille de boîte, notre contexte évolue.

35:43 Et donc, rentrer dans une certaine définition, moi, ça ne m'irait pas. Un deuxième bouquin qui est extrêmement intéressant, c'est High Output Management de Andy Grove, qui était un des exécutifs qui a ensuite été PDG de Intel, qui a un petit peu théorisé tout le management technique moderne. Et donc, c'est extrêmement intéressant de lire ça. Ensuite, plus sur les valeurs, il y a des bouquins comme Radical Candor qui m'ont beaucoup influencé. Donc typiquement, essayer de pouvoir donner du feedback qui soit à la fois honnête et très direct. Et où on a de l'empathie, où on est capable de care personally, Donc d'aider la personne à grandir. Et c'est quelque chose que vous essayez de... Dans votre parcours de bout de choc, ça fait partie des choses que vous essayez de transmettre et d'expliquer aux collaborateurs qui vous rejoignent, parce que c'est bien de l'intégrer pour soi, mais le partager avec les autres, ce n'est pas forcément simple.

36:45 Exactement. On essaye de créer. Donc, on a plusieurs outils dans notre parcours d'onboarding qui sont les one-on-one. Donc, chaque personne va avoir un coach, une personne qui va l'aider à grandir en termes personnels. Un role buddy, donc quelqu'un qui va plutôt l'aider à grandir en termes fonctionnels, donc sur leur rôle. Et puis un culture buddy. En fait, notre culture est assez différente de beaucoup d'entreprises. Donc on a une personne de référence pour chacun qui lui permet de naviguer la culture d'Alan et de s'en imprégner pour être ensuite le prochain promoteur. Super. Mais écoute, on arrive à la fin de cet épisode. C'était extrêmement riche. J'ai beaucoup apprécié entendre tous ces retours d'expérience et la façon dont tu animes tes équipes. Merci beaucoup, Charles, pour ce moment. J'espère à bientôt. Merci de m'avoir reçu.