On va passer un bon moment à décortiquer ensemble le modèle et les raisons du succès d’un acteur clé de la tech française. Une jeune pousse qui n’a pas froid aux yeux et qui joue la carte de la différence, de la culture et de l’innovation pour bousculer les codes de l’assurance. Mais pas que ! Bousculer les codes de l’entreprise en règle générale, bousculer les codes de l’organisation et du management. Dans cet épisode, nous recevons Charles Gorintin, CTO et cofondateur d’Alan.
Avant de commencer et avant de parler d’Alan, j’aimerais bien que tu me parles de toi en quelques mots. Quel est ton parcours ? Qui est le Charles avant Alan ?
J’ai toujours été passionné par l’utilisation des maths et des données pour résoudre des problèmes complexes. Après avoir fait une école d’ingénieurs, l’École des ponts, où j’ai d’ailleurs rencontré Jean-Charles Samuelian-Werve, je suis parti à San Francisco pour faire un Master en finance. Ensuite, alors que tous mes camarades partaient travailler dans des banques, j’ai décidé d’aller travailler chez Facebook en tant que data scientist.
J’ai d’abord lutté contre les faux comptes, le spam et le porno sur Facebook, c’était assez passionnant. Puis j’ai travaillé à rendre Facebook un peu plus compassionate, c’est-à-dire à aider les gens à résoudre leurs problèmes directement sur Facebook. Ensuite, je suis passé par Instagram et puis par Twitter, toujours en tant que data scientist, puis je suis rentré en France en janvier 2016 pour créer la boite avec Jean-Charles.
Tu découvres le job de data scientist sur ton contrat de travail. Ça ressemblait à quoi la data science à l’époque ?
Je pense qu’on disait statisticien. Il y avait ce fameux article de Hal Varian qui disait que statisticien, ça allait être le job le plus sexy du XXIe siècle. Et à ce moment-là, je n’avais jamais vu le terme data science, qui a été inventé chez Facebook d’ailleurs. Donc je me suis lancé là-dedans parce que j’avais un background en machine learning et c’était beaucoup de l’analyse de données.
T’en as retenu quoi de tes années à San Francisco ?
C’est hyper intéressant parce que c’est une autre manière de voir les choses. Déjà, il y a un multiculturalisme assez exceptionnel. J’étais dans une équipe, notamment chez Twitter, où chacun venait différents continents. On parlait la même langue, on interagissait tous, on arrivait à se comprendre, mais c’est quelque chose qu’on n’avait pas nécessairement en restant près de Paris.
Il y a aussi cette culture de la prise de risque, de faire les choses en grand, d’essayer de voir le futur, notamment chez Facebook qui le faisait très bien. Ils ne communiquent pas énormément dessus, mais j’ai vraiment pu comprendre comment est-ce qu’on construit une culture et comment est-ce qu’on embarque des personnes dans cette culture.
Ça n’a pas été trop dur pour toi de t’intégrer dans cet univers et cette culture américaine ?
Quand je suis allé faire un entretien chez Facebook, j’étais hyper relax et j’ai vraiment matché avec la culture et avec les gens. Je me suis rendu compte que cette contre-culture de la tech, qui n’était pas du tout arrivée en France à ce moment-là, était celle que je recherchais.
Comment tu as trouvé des groupes avec lesquels tu étais en phase au niveau des valeurs ?
D’un point de vue valeur, c’est toujours un petit peu difficile parce que j’étais sur les lignes de front. Je n’étais pas forcément dans les décisions dans ces entreprises. En fait, ce qu’on remarque, c’est qu’il y a certains symptômes qui sont dus à des choix très forts qui ont été faits.
Typiquement, une des grandes valeurs chez Facebook, c’était move fast and break things. Ils ont arrêté d’utiliser ça à partir de 2014 à peu près, mais le concept de base était extrêmement intéressant. L’idée, c’est que comme ils étaient en train de construire sur du web, ils pouvaient aller très vite et réparer les bugs aussi rapidement. Le but, c’est d’aller chercher les bugs pour réparer et aller toujours plus vite. Aller plus lentement et faire moins d’erreurs, c’est apprendre moins vite.
Mais ce concept du move fast and break things, c’est ça qui a créé un peu ces problématiques autour de la confidentialité des données. Certains ingénieurs chez Facebook ne réfléchissaient pas aux effets de l’abus de certaines fonctionnalités. Et c’est notamment là-dessus que je travaillais en tant que data scientist, sur comment on protégeait les membres de Facebook. Parce que le concept marche pour des systèmes informatiques, mais beaucoup moins quand on a affaire à des personnes.
Est-ce que tu peux nous dire un peu qu’est-ce qu’Alan aujourd’hui ? Quelle est la vision de cette assurance et quels sont les services que vous proposez aujourd’hui ?
La vision qu’on a pour Alan, c’est d’en faire la super arme de santé qui permet de fournir à ses membres des services médicaux pour pouvoir gérer sa santé directement depuis son téléphone. Donc les services vont d’une assurance qui est très simple à des moyens de pouvoir parler à des médecins en moins de 2h, avoir accès à une carte des médecins, recevoir des notifications de prévention : c’est vraiment avoir un partenaire de santé directement dans sa poche. On a décidé de construire en premier une assurance, parce que l’assurance est au cœur de tout le système de santé. On parle à tous les acteurs du système de santé, à la fois les médecins, les patients, les hôpitaux, la Sécu…
Vous couvrez quoi comme pays ?
Aujourd’hui, Alan, c’est en France. C’est là où on a commencé. Mais on a ouvert deux nouveaux pays depuis 2020 : la Belgique et l’Espagne.
Tu peux nous donner un peu de contexte autour de la création d’Alan ?
Si je remets un peu les choses en contexte, on est en 2016 et avec Jean-Charles, on veut frapper fort. On est posés et réfléchis, mais on a de l’ambition et on voit les choses en grand. Moi, je bossais pour des GAFAM et Jean-Charles dans les moteurs et les sièges d’avion. On n’y connaissait rien en assurance ! Mais on se lance là-dedans quand même, et on arrive à sécuriser un tour de table de 12 millions d’euros. Et on finit par obtenir un agrément d’assurance, la première depuis 1986 ! Dès le départ, on s’est fixés des objectifs hyper hauts, et en 5 ans, on est à peu près à 100 millions d’euros de chiffre d’affaires.
À ton avis, qu’est-ce qui vous a permis d’être là où vous en êtes aujourd’hui ?
Dès le début, on a décidé d’écrire des valeurs alors qu’on avait zéro employé dans l’entreprise. Et il y a une valeur en particulier qu’on a écrite, qui était fearless ambition. On s’est dit que si on voulait faire quelque chose qui vaille le coup de prendre le risque, il fallait qu’on aille taper très, très, très fort. Donc construire une assurance santé alors que ça n’avait pas été fait depuis 30 ans, c’est quelque chose qui nous passionnait.
Jean-Charles a passé son automne 2015 à lire le code des assurances. On a recruté quelqu’un qui avait fait 25 ans dans l’assurance pour nous accompagner et s’occuper des opérations. On a recruté des anciens, des régulateurs et des ingénieurs qu’on a fait revenir de San Francisco. C’est comme ça qu’on a réussi à obtenir cet agrément en moins de six mois. Tout ça parce qu’on n’a pas eu peur de notre ambition !
Au départ, tu avais l’intention de travailler plutôt sur des algorithmes qui permettraient d’améliorer la santé des personnes. Tu peux m’en dire plus sur ce pivot ?
Avec Jean-Charles, on a toujours voulu travailler dans la santé. Quand on a reconnecté après dix ans, en 2015, on s’est rendu compte qu’on avait envie de travailler en santé en utilisant les données médicales des gens. Parce que dans nos familles respectives, il y a eu des événements de santé qui auraient pu être mieux traités ou mieux anticipés si on avait mieux utilisé ces données.
Mais pour utiliser des données, il faut y avoir accès. Trois moyens sont possibles : les individus, les professionnels de santé ou les assurances. Le problème, c’est que les individus et les professionnels de santé ne sont pas prêts à payer pour de la prévention, et ne possèdent même pas leurs propres données de santé la plupart du temps. Donc la solution, c’était de passer par les assurances qui ont à la fois les données et l’argent.
C’est là qu’on a réalisé que leurs infrastructures dataient des années 90 et qu’elles étaient incapables de bouger en moins d’un an. C’était donc l’occasion rêvée de construire notre propre assurance pour pallier ce problème ! Notre vision a toujours été d’améliorer la santé des personnes et on est encore sur ce cap aujourd’hui.
Comment on s’y prend pour concevoir l’architecture tech d’un assureur en partant de zéro ?
C’était assez particulier, parce que je n’étais pas software engineer à l’époque. Ma première grande décision a donc été de recruter les bonnes personnes. On s’est fait accompagner par un expert en assurance avec qui on a beaucoup échangé pour pouvoir construire le modèle de données. On a aussi décrit ce modèle de données qui serait théorique en fonction de ce que l’expert nous expliquait.
Ensuite, on a essayé de simplifier au maximum ce qu’on devrait avoir chez nous, en travaillant avec modularité et incrémentalité. En gros, ça veut dire qu’on pose les rails du train pendant que le train avance. Par exemple, quand on a commencé, on était 3 et on comptait recruter, donc on a construit un onboarding. On s’est rendu compte qu’on n’avait pas de dashboard pour ça, donc on l’a construit pour que nos nouveaux arrivants aient une bonne expérience d’arrivée. Quand on a commencé à assurer des personnes, on n’avait aucun moyen de les facturer, donc on a construit un module pour ça et ainsi de suite. L’idée globale, c’est de construire différentes briques pour les intégrer, construire un savoir commun et une expertise et mieux appréhender les problèmes avant d’en construire d’autres.
Aujourd’hui, on a tout intégré niveau assurance. Et ça a pris du temps ! D’abord, on a intégré les calculs de facturation, puis les remboursements. On est désormais capables de rembourser 75 % des sinistres en moins d’une heure. Mais ce qui reste au cœur de nos préoccupations et de notre plateforme, c’est de donner toujours plus de valeur et de continuer à innover.
Ça te donne des avantages concurrentiels cette façon de procéder ?
Carrément ! C’est assez intéressant de revenir sur l’historique d’AXA notamment, qui a vraiment émergé dans les années 90, à une époque ils rachetaient énormément de plus petites mutuelles. Mais ça implique de fusionner des systèmes d’information qui formaient une sorte de patchwork. Et je pense qu’aujourd’hui encore, il y a des restes de ça. Nous, on a eu la chance de vraiment construire quelque chose from scratch, parce qu’on n’avait quasiment pas de membres. C’est une vraie force qui nous permet de vraiment repenser les problèmes, de repartir des premiers principes à chaque fois et de résoudre ces problèmes de la meilleure façon avec les outils de l’état de l’art.
Comment tu as préparé ton passage à l’échelle d’un point de vue tech, en démarrant de si peu ?
En ce qui concerne l’assurance santé, il y a assez peu de passage à l’échelle qui est nécessaire. Grosso modo, nos membres ne se connectent pas en même temps, ce qui était le cas chez Instagram, Twitter et Facebook. Pour Alan, au mieux, les personnes vont revenir une ou deux fois par semaine sur leur dashboard, donc on n’a pas énormément de trafic. Aujourd’hui, on a 150 000 utilisateurs : on n’a pas de gros problème de passage à l’échelle. Notre idée, ça a toujours été de se focaliser sur ce qui était simple. En règle générale, j’aime bien les choses simples et j’aime beaucoup le concept des vertus du software engineer qui sont la paresse, l’impatience et l’hubris qui s’équilibrent. On se concentre sur ce qu’il faut faire pour résoudre les problèmes d’aujourd’hui sans essayer d’anticiper les problèmes de demain, parce qu’on sait qu’ils ne vont pas arriver tout d’un coup. On ne va pas avoir x10 de charge qui va arriver du jour au lendemain, ce qui nous permet de pouvoir anticiper une échelle de temps plus longue et donc de pouvoir prendre des décisions plus pragmatiques.
Comment vous vous y prenez pour déployer Alan dans d’autres zones ?
Les systèmes de santé en France et dans les autres pays sont complètement différents. Il n’y a aucune norme commune. Il y a plein de modèles différents. Ce qu’on a décidé de faire, c’était de lancer et partir de zéro pour l’Espagne et la Belgique. Et à partir de là, on a essayé de factoriser ce combat en regardant comment les choses se structuraient pour ensuite les reproduire. L’objectif est de construire quelque chose qui derrière va pouvoir à la fois avoir des constantes, les choses qui vont rester d’un pays à l’autre, et en même temps avoir la flexibilité d’absorber les idiosyncrasies de chacun de ces pays.
Comment tu t’y prends pour gérer la nécessaire évolution de ton rôle et t’adapter en permanence ?
Déjà, il faut savoir rester humble. C’est extrêmement important pour moi. Je sais que je ne suis pas un spécialiste. Je n’ai jamais été manager à ce niveau-là et donc il faut que je sois transparent avec toutes les personnes chez Alan et avec les personnes que je vais recruter, pour apprendre un maximum. C’est vraiment la clé. Je considère même que le fait de ne pas avoir eu cette expérience est une chance, parce que ça me permet d’apprendre un maximum vis-à-vis de mon contexte. Alors que quelqu’un qui aurait déjà une expérience essaierait de la calquer à ce nouveau contexte. Je peux aller piocher dans des bouquins et parler à des gens qui ont fait des choses similaires pour construire ma propre expérience et compréhension du rôle.
Mon autre truc, c’est d’essayer de me virer de mon rôle tous les six mois. Dans toute la trajectoire d’Alan, j’ai essayé de me virer de mon rôle de CTO tous les six mois. Au début, je devais coder. Je pense que je n’étais pas le meilleur développeur, mais on avait besoin que je participe. Ensuite, j’ai dû recruter des gens qui étaient toujours plus forts que moi. C’est là où c’est assez important de ne pas être le plus fort de l’équipe, parce que ça ne met pas un plafond de verre pour les gens qu’on va pouvoir recruter. Si je me considérais comme le plus fort de l’équipe, ce serait difficile de recruter quelqu’un de meilleur que moi.
Mon objectif a toujours été de poser la première brique pour ensuite trouver des personnes qui vont être plus fortes que moi et qui vont avoir plus de temps que moi pour plonger dans le sujet, pour se l’approprier. Me virer du boulot, c’est les laisser prendre leur place et être plus performant que moi. L’avantage derrière, c’est que j’ai du contexte, donc je peux leur donner des directions vis-à-vis du business, les comprendre, leur donner du feedback et les aider sur certains sujets. Et derrière, j’ai une vue assez globale, sans me surcharger au niveau du travail.
Quelles ont été les choses les plus complexes qui t’ont été données de vivre au sein d’Alan ?
En tant que CTO et cofondateur, j’ai dû trouver un équilibre, m’investir sur l’orientation, sur la culture… Et pour le coup, je me suis rendu compte que le rôle de CTO est très mal défini. Comme je le disais tout à l’heure, mon rôle a évolué à peu près tous les six mois et savoir ce sur quoi je devrais me focaliser, c’est toujours une sorte de précipice vertigineux en face de moi. Une fois que j’ai complètement délégué, je me retrouve face à un vide. Il faut que je décide : maintenant, qu’est-ce que je fais ? Quel est mon nouveau chantier ? Plusieurs fois je me suis demandé à quoi je servais !
Mais en fait, ne plus rien avoir à faire, c’est justement montrer que l’organisation tourne, qu’elle est capable de fonctionner sans moi. Je peux donc me libérer du temps pour pouvoir derrière créer quelque chose de nouveau et poser de nouvelles briques. Je lutte activement contre la maladie de la valeur ajoutée. Il faut réussir à se dire que le mieux, c’est de ne plus avoir de valeur ajoutée. Il faut que l’organisation soit suffisamment mature pour que l’on n’ait plus besoin de Charles le CTO pour prendre des décisions. Un autre challenge qui est extrêmement difficile pour moi, c’est le focus. Je suis quelqu’un de très curieux et j’aime beaucoup me lancer dans les nouveaux sujets et c’est quelque chose sur lequel Jean-Charles me reprend parfois. J’apprends encore à me concentrer, pour faire moins de choses et plus intensément.
Comment tu organises tes équipes ?
Aujourd’hui, Alan, c’est à peu près 70 ingénieurs, une douzaine de product managers, une douzaine de designers et une douzaine de data scientists. On a décidé de construire notre organisation autour d’une brique élémentaire qu’on a appelé crew. En gros, c’est l’équivalent des Squads chez Spotify : une petite équipe de huit personnes maximum. On aime beaucoup le concept de two pizzas team, des équipes qu’on pourrait nourrir avec deux pizzas. Ces crews ont comme particularité d’expirer au bout de 7 semaines par défaut. Ça nous force à être très intenses dans la manière dont on va résoudre les problèmes et essayer de ne pas passer du temps sur des problèmes qui vont durer énormément dans le temps, toujours dans cette idée de garder le focus.
Cependant, avec le temps, on s’est retrouvé avec une douzaine de crews, et ça faisait trop de briques élémentaires avec lesquelles interagir directement. Donc, on a créé une abstraction au-dessus qu’on a appelé unit, qui prend en charge 4 ou 5 crews. Par exemple, on va avoir une unit sur les offres d’assurance, une autre sur les services de santé, une pour l’infrastructure… Une unit va avoir une durée de vie plus longue et stable qu’un crew afin d’accompagner tout un produit, notamment l’assurance, un sujet qu’on ne peut pas complètement laisser en jachère.
Ensuite, niveau orga des équipes, on a un designer et un PM pour 6 software engineers. Un des trucs qui est aussi un peu particulier chez nous, c’est que comme on a toute cette fluidité avec les crews qui expirent, on a décidé que tous les ingénieurs chez Alan seraient full stack. En réalité, ce sont plus des spécialistes qui se déguisent en généralistes. On essaie toujours de matcher les sujets avec les préférences des personnes, mais on attend que chacun soit au moins capable ou full stack curious. S’il y a quelqu’un qui a construit un système dans le back et qui doit ajouter un bouton dans le front, il ne doit pas attendre qu’une autre personne le fasse.
Sur quelle stack vous bossez ?
On travaille avec Flask dans le back end. C’est hébergé sur AWS, donc avec une base de données PostgreSQL. Dans le front, on est avec React. Et sur les applis, on est sur React Native.
Ça faisait partie du cahier des charges initial et des valeurs que vous aviez définies au départ, ce côté unique de votre approche managériale ?
Ouais, clairement. En fait, comme je le disais un petit peu tout à l’heure, on a créé ces valeurs tout au début. Il y avait 0 employé chez Alan et on a tout de suite voulu se mettre d’accord avec Jean-Charles sur la façon dont on voulait construire l’entreprise. On a eu la chance d’avoir une alchimie qui fonctionne et que Jean-Charles avait déjà monté une startup avant : il connaissait déjà un peu les erreurs à ne pas faire. De mon côté, j’avais vu des painpoints dans des cultures qui étaient devenues matures et quel impact pouvaient avoir des décisions qui étaient prises très tôt dans l’entreprise. La combinaison des deux a été très forte et ça nous a permis de construire des valeurs pérennes.
La première de nos valeurs, c’est members first : on veut se focaliser sur nos utilisateurs en premier, plus que sur nos besoins en tant qu’équipe, et surtout plus que les besoins de nos actionnaires. Deuxième point extrêmement important, c’est radical transparency : on donne accès à tout. Troisième point, c’est distributed ownership : on essaye de construire une organisation qui est innovante où on donne le pouvoir de décision à la personne qui fait. Et ça, c’est extrêmement important dans notre ADN et notre vision. On ne veut pas qu’il y ait ce genre de flux où toutes les décisions doivent être approuvées avec un petit tampon rouge par Jean-Charles ou par moi. C’est assez lié à ce que je disais tout à l’heure : si on veut pouvoir scaler, on doit tout faire pour avoir confiance en les personnes de l’équipe. Et le meilleur moyen de le faire, c’est de construire cette responsabilité distribuée. Quatrième valeur, fearless ambition. Et la dernière valeur, c’est personal and community growth. On tient à faire grandir les personnes avec l’entreprise. Parce que si l’entreprise grandit beaucoup et que l’équipe ne suit pas, on aura tout perdu.
À partir de ces valeurs, on a construit des leadership principles qu’on a publié dans le bouquin signé par Jean-Charles, Healthy Business. L’idée, c’est surtout d’évangéliser ces valeurs pour faire rayonner notre culture qui, étant assez particulière, peut surprendre les gens qui ne nous connaissent pas. Et derrière, ça permet aussi à d’autres entreprises d’adopter potentiellement cette culture, de créer un mouvement et d’avoir beaucoup plus de personnes qui réinventent ce futur du travail. Ça nous permet ensuite de pouvoir s’inspirer des idées qu’ils auront pu appliquer dans leur contexte !
Est-ce que c’est une démarche qui vous tient à cœur ?
Oui, c’est extrêmement important. Notre entreprise a beaucoup changé. Ce n’était pas du tout la même chose quand on était deux, quand on était huit, quand on était 40, quand on était 150 et maintenant quand on est 300. Ça n’a rien à voir. Il faut absolument que tous les process changent au fur et à mesure que la boite grandit.
Il y a une métaphore que j’aime beaucoup, c’est la métaphore du bateau de Thésée qui tue le Minotaure qui rentre à Athènes. Les Athéniens conservent son bateau et au fur et à mesure, certaines parties du bateau commencent à pourrir. Pour garder le bateau intact, les Athéniens décident de remplacer la planche, et ainsi de suite avec toutes les autres pièces du navire, jusqu’à ce que toutes les planches du bateau original aient été remplacées. La question, c’est : est-ce que ça reste le bateau Thésée ?
Pour Alan, c’est un peu la même chose. Si on ne changeait pas les process, le bateau coulerait. Alan reste Alan parce qu’on change les process. Si on restait exactement la même chose qu’en 2017 par exemple, on ne serait plus Alan. Après, ce qui est extrêmement important, c’est de continuer à suivre les valeurs dont je parlais tout à l’heure !
Quelles sont les boîtes qui sont pour toi des références sur ces sujets ?
Comme je te l’ai dit, j’ai un peu été élevé à la sauce Facebook, donc j’en connais les limites, notamment sur la confidentialité. Même si j’essaye fortement de contrer ces limites, je trouve le sujet fascinant chez Facebook : au final, ils parlent assez peu de leur culture, notamment en software engineering. On est pas mal fascinés aussi par Amazon, par Netflix, parce qu’ils ont réussi à construire des choses assez surprenantes sur la durée. Une boite un peu plus jeune, mais qui est vraiment exceptionnelle, c’est Stripe.
Vous êtes connus pour ne jamais faire de réunions. Concrètement, vous la mettez en place comment cette culture de l’écrit ?
On considère qu’une décision qui se prendrait à l’oral, notamment dans une réunion, n’existe pas. Pour prendre des décisions, on utilise un outil qui s’appelle GitHub Issues. Là, par exemple, on en est à notre 10 000ᵉ GitHub Issue, donc ça veut dire qu’on a pris 10 000 décisions à l’écrit. On a une sorte de template où la personne qui ouvre le sujet va décrire le scope du problème, son objectif, le contexte puis faire une proposition. Ensuite, elle va poser des questions aux personnes qui sont importantes pour la décision et fixer une deadline.
Ce qui est capital et lié à la responsabilité distribuée, c’est que c’est la personne qui signale le problème qui prend la décision finale. Mais sa responsabilité, c’est aussi de faire ce qui s’appelle le advice process : elle doit aller recueillir les conseils et les arguments des personnes qui sont expertes dans le sujet. Si on ne fait pas ça, la décision sera forcément mauvaise. Par contre, si on a récupéré les opinions des bonnes personnes, on peut avoir une décision très aboutie à la fin. En plus, la personne qui signale un problème peut ne pas être experte du sujet, donc tout le monde apprend !
Toutes ces décisions sont ouvertes en interne. N’importe qui peut voir une décision qui est en train d’être prise ou qui a été prise. On peut remonter jusqu’à début 2017 pour avoir le résultat de ces 10 000 décisions, ce qui permet de pouvoir faire de l’archéologie et de comprendre pourquoi telle décision a été prise. Tout est écrit et expliqué. Derrière, ça permet à chacun de pouvoir s’organiser comme il veut, de manière asynchrone, plutôt que de devoir faire partie de ce meeting important. On veut que les personnes puissent travailler d’une part quand ils veulent ou aussi d’où ils veulent, tout ça de manière asynchrone. Moins de perte de temps et plus de valeur !
Comment vous le mettez en place ce remote complet ?
Initialement, on voulait que les gens viennent à peu près 20% du temps au bureau. Mais quand la pandémie est arrivée, on s’est dit que cette barrière mentale était complètement artificielle. Du coup, on a mis en place ce qu’on a appelé « travaillez d’où vous voulez » tout en gardant des bureaux. C’est important pour nous, parce qu’il y a des personnes qui préfèrent travailler d’un bureau et je pense que c’est assez naturel. D’ailleurs, je fais partie de ces personnes !
Les seuls points sur lesquels on est très à cheval, c’est qu’il faut qu’il y ait une très bonne connectivité. On ne peut pas accepter que quelqu’un puisse ne pas communiquer avec les autres parce qu’il y a une mauvaise connexion. Ensuite, il faut que la personne travaille sur les fuseaux horaires européens, parce que si on a un shift de jour et un shift de nuit, on se prend un peu un jour de décalage à chaque fois qu’on doit faire un back & forth et c’est pas très efficace. Plutôt que d’avoir des bureaux et de mettre des gens dedans, on a retourné le truc et on fait en fonction d’où les gens habitent. Par exemple, il y a quatre personnes qui habitent à Nantes, donc on a construit un co-working autour d’eux.
Comment vous faites pour garantir la montée en compétence des équipes sur les éléments technologiques notamment ?
Chaque personne chez Alan a un coach, qui va être une autre personne chez Alan. On a essayé de déconstruire le rôle du manager. Traditionnellement, un manager a deux casquettes, c’est à la fois le côté delivery, donc faire que les trains arrivent à l’heure et que la qualité du produit soit garantie, et le côté coaching, c’est-à-dire aider les personnes à grandir dans l’équipe. Souvent, c’est très difficile de séparer les deux quand c’est la même personne qui fait les deux choses. Du coup, on a vraiment séparé les deux et chacun a un coach qui ne va pas être prescriptif, mais qui va être là exclusivement pour aider la personne à se confier et à grandir dans l’entreprise : lui suggérer des bouquins, des personnes à qui parler…
À quoi ressemble votre process de recrutement ?
On a essayé d’avoir une approche assez normalisée pour enlever le maximum de biais. On envoie des questions en anglais parce que c’est notre langue de travail. Ensuite, on procède à un entretien technique qui dépend du rôle. Le but, c’est de savoir ce que la personne va apporter à la culture d’Alan. Enfin, le plus gros morceau de notre process, c’est ce qu’on appelle un full day : l’idée, c’est que la personne passe une journée avec nous pour voir si on a envie de bosser avec la personne, et peut-être encore plus important, si la personne a envie de bosser avec nous. Avant de s’engager pendant trois, cinq ou dix ans avec une entreprise, je pense que c’est assez important de tester durant une journée. Ce sont toujours les mêmes exercices, ce n’est pas du travail gratuit, mais c’est vraiment hyper important de pouvoir faire ce test. Ça prend du temps, ça prend de l’énergie, mais à la fin, tout le monde est content parce qu’on peut vraiment décider en connaissance de cause si on a envie de travailler ensemble.
À plus long-terme, on encourage pas mal les personnes à partir de chez Alan, parce que ça nous met une bonne pression pour leur donner le meilleur environnement possible, leur permettre de vraiment s’épanouir et qu’ils soient sûrs d’être chez Alan pour les bonnes raisons. On a d’ailleurs écrit un plaidoyer pour la liberté des talents, qui dit que les autres entreprises peuvent très bien aller chasser chez nous, et on l’encourage, parce que ça permet d’avoir des discussions transparentes avec notre équipe.
Est-ce que la notion de prévention est d’actualité pour vous ?
Aujourd’hui, on demande le consentement des personnes dans notre appli. On leur dit qu’on va regarder leurs remboursements de santé pour faire tourner un petit algo qui va leur dire quand aller chez le dentiste par exemple. Si je prends mon cas personnel, j’ai reçu cette notification en octobre. J’y suis allé, et ils m’ont trouvé des caries qui venaient de se développer. Ça m’a permis d’être traité et donc de coûter moins cher à la fin, à la fois à moi, parce que je n’ai pas envie d’avoir des gros prix, et à la fois à Alan parce qu’on ne va pas devoir mettre des couronnes si ça avait continué à se développer.
Mais il faut qu’on fasse très attention, parce qu’on ne peut pas se permettre de faire des mauvaises recommandations. Donc, on est très méticuleux dans la manière dont, d’une part, on utilise les données, toujours avec le consentement, et d’autre part dans les recommandations qu’on va faire : on a des médecins dans l’équipe qui nous permettent d’éviter de faire des ratés.
Quels sont les services game changer que vous allez proposer prochainement ?
On commence à proposer des services qui se focalisent sur les jeunes parents. On a lancé une appli qui s’appelle Alan Baby où tous les jeunes parents peuvent parler et poser une question à un médecin et à avoir une réponse en moins de 2h. Notre objectif, c’est d’acquérir une communauté de parents à qui poser des questions avec qui interagir et leur proposer du contenu adapté à l’âge du bébé et aux choix des parents. Le but, c’est de continuer à se développer, niche par niche, pour pouvoir offrir vraiment une expérience de santé complète directement dans l’appli Alan.