Quand la tech et le produit ne font qu'un

0:02 Je pense que la technique pour la technique a peu d'intérêt. De plus en plus, je commence à parler d'équipe produit seulement. Je ne suis pas sûr que j'arrive à vivre plusieurs fois dans ma carrière et rejoindre une boîte de 5 personnes qui finit cotée en bourse. Tout mon enjeu en ce moment, c'est de réussir à prendre plus de hauteur stratégique, d'apprendre aussi à confier l'équipe que j'ai créée avec passion à quelqu'un d'autre qui la managera au moins aussi bien que moi. Bonjour à toutes et à tous, je suis Hervé Lourdin, CTO de Batch, et aujourd'hui, pour ce nouvel épisode de Tech.Rocks, j'ai le plaisir d'accueillir Adrien, CTO du Permis Libre. Adrien, bienvenue et je te laisse te présenter en quelques mots et raconter ce que fait le Permis Libre. Merci, bonjour à toutes et à tous. Adrien Blandin, sitio pour le Permis Libre. Le Permis Libre, c'est une auto-école en ligne, mais qui permet de conduire en vrai. C'est une entreprise que j'ai rejoint il y a 7 ans maintenant et pour laquelle je dirige une équipe d'à peu près 25 personnes.

1:05 La subtilité chez le Permis Libre, c'est que l'équipe technique contient le produit et la data. D'accord, merci. Et alors, une question que je t'ai posée quand on a papoté un peu avant cet échange, pourquoi ça s'appelle le permis libre? En quoi il est libre ce permis? C'est, je pense, une anecdote historique, c'est que le permis libre, ça a été créé en 2014 suite à une loi de Macron qui a permis à n'importe qui de passer son permis de conduire en candidat libre. Donc un peu comme ce qui se fait pour le baccalauréat, ça a donné la possibilité à des élèves de réserver eux-mêmes leur examen. On s'est appelé le permis libre en hommage en partie aux candidats libres. Mais depuis quelques temps, la situation législative a un petit peu changé. Pourtant, le nom est resté. Et ce qui est un petit peu rigolo, c'est que c'est devenu notre marque de fabrique en interne, puisque tous nos projets s'appellent quelque chose de libre. Pour la data, c'est con, mais ça s'appelle la statistique libre. Aujourd'hui, ce sera l'épisode de Tech.Rocks libre. Avec plaisir. Dans ta description, tu mentionnes qu'au sein de tes équipes, tu as la tech, la data, c'est relativement standard, mais tu as aussi le produit.

2:09 Et puis, j'ai noté que tu ne disais pas que tu étais CPO. Est-ce qu'il y a une raison à ça? Probablement un peu de pudeur au tout début. Pendant longtemps, le CPO a été le CEO de la boîte. Et il y a un petit peu plus de deux ans, on a commencé à repenser l'organisation des équipes produits et design pour résoudre un petit peu les conflits qu'on pouvait avoir où le produit trouve toujours que les features ne sont pas assez bien à cause de la tech. La tech trouve toujours que les features sont trop complexes à cause du produit. Et on s'est dit, on va fusionner un petit peu toutes ces équipes dans des squads. Et du coup, toutes ces squads sont arrivées sous ma juridiction, sous ma responsabilité. Ce qui fait qu'aujourd'hui, on a le produit et la technique. Mais au fil des années, je commence de moins en moins finalement à distinguer ces deux équipes. On essaie de leur donner des noms, qu'est-ce qui fusionne le produit et la technique. On n'arrive pas à trouver, on tombe toujours sur produit ou technique. Mais le mot d'ordre que je passe, c'est ma conviction, c'est que tout le monde construit des applications.

3:12 C'est juste que chacun a un rôle différent dans ses applications. Et comme je pense que la technique pour la technique a peu d'intérêt, de plus en plus, je commence à parler d'équipe produit seulement. Super, j'aime beaucoup cette posture. On va faire un peu la figure de style imposée de ces épisodes de Tech.Rocks et puis te demander un petit peu quel a été ton parcours pour en arriver au job que tu as aujourd'hui. J'ai un parcours très classique. J'ai fait une école d'ingénieur et un BTS au milieu, donc en cinq ans. Suite à ça, j'étais passionné par l'entrepreneuriat, donc j'ai tenté de créer ma première startup à ma sortie d'école. Ça a duré six ou neuf mois. Ensuite, j'ai rejoint une entreprise que tu connais très bien puisque tu en es CTO aujourd'hui. J'ai fait ce qu'on peut appeler mes armes chez Batch, qui à l'époque s'appelait App Gratis, où je suis resté presque deux ans. Ensuite, j'ai retenté une aventure entrepreneuriale en me basant un petit peu sur les échecs de la première pour ne pas les refaire. Ça a mieux marché, mais ce n'était toujours pas un succès. Et finalement, ça m'a permis de rejoindre lePERMISLIBRE il y a 7 ans.

4:16 J'ai passé 3 ans en tant que développeur backend chez lePERMISLIBRE et bientôt 4 ans en tant que CTO. Super, très bonne idée d'être passé dans les équipes de batch, je te félicite. J'espère que l'expérience n'aura pas été trop difficile. Non, pas du tout. C'était vraiment une expérience formatrice pour moi. Depuis que tu as pris cette casquette de CTO au Permis Libre, qu'est-ce qui t'a le plus marqué, les moments les plus importants pour toi? Il y en a eu beaucoup. Sept ans, moi j'ai rejoint une boîte qui contenait six personnes à l'origine. Quand je suis arrivé, aujourd'hui on est 70. Donc ça fait quand même un sacré scale qui s'est fait aussi en grande partie sur les dernières années où la croissance s'est accélérée. Du coup, déjà, ne serait-ce que de vivre cette évolution d'une boîte qui passe de 5 à 70, la boîte où je travaille aujourd'hui, ce n'est pas du tout la boîte que j'ai rejoint. Et ça, c'est assez incroyable de pouvoir vivre ça. La situation à l'époque, pour nous, elle était un petit peu plus difficile puisque le concept était nouveau et il se passait un petit peu ce qui s'est passé avec Uber et les taxis, notamment au Airbnb et les hôtels.

5:23 C'est que le marché de l'auto-école traditionnel ne voyait pas forcément d'un bon oeil notre activité. Donc, il y a eu pas mal de manifs, d'opérations escargots, de choses comme ça qui finalement ont demandé beaucoup de temps, surtout aux fondateurs qui n'étaient pas consacrés au business. C'était vraiment de la gestion de lobbying. Voir ça, c'était aussi quelque chose d'assez incroyable. Ils ont fait preuve d'une très grande résignation et d'une grande force pour réussir à traverser cette période. C'est quelque chose qui m'a toujours laissé admiratif. Et dernièrement, cette année, ce qui est un peu une petite célébration pour nous, ce n'est pas un aboutissement en soi, mais on en est plutôt fiers, c'est qu'on a quand même réussi à faire notre IPO. On est entré en bourse en février de cette année. C'est assez incroyable aussi de vivre ça, parce que je ne suis pas sûr que j'arrive à vivre plusieurs fois dans ma carrière de rejoindre une boîte de cinq personnes qui finit côté en bourse. Un grand bravo pour ça. Effectivement, je ne pense pas qu'on soit beaucoup de gens à, un, vivre cet événement et encore moins le vivre deux fois. Donc, félicitations.

6:24 Je pense que ça a dû être un grand moment intense de boulot et d'émotion. C'est le cas. Une question qu'on pose souvent aux tech leaders qu'on interview, est-ce que tu codes encore ? Ou si tu ne codes plus, à partir de combien de personnes tu n'as plus trouvé le temps nécessaire pour le faire? Alors ça va dépendre de ce qu'on appelle coder, mais si c'est plus qu'une heure toutes les trois semaines, non, je ne code plus. J'ai arrêté en grande partie quand il a commencé à avoir à peu près une dizaine de personnes dans l'équipe. Donc jusqu'à 10 personnes, je faisais à moitié de la gestion d'équipe, du management, de la gestion de projet. J'avais encore un petit peu de temps pour développer. À partir de 9-10, ça a commencé à devenir assez difficile et je me suis concentré plutôt sur la dimension. managerial, gestion de projet. Et depuis peu, j'ai commencé à lâcher même ces deux thématiques de management et de gestion de projet. C'est à peu près les ratios qu'on a un peu en tête, où ça y est, c'est plus possible d'avoir les mains vraiment dans le code.

7:26 Du coup, comment tu as pris ce virage, en fait, où tu changes du rôle de contributeur individuel au rôle de manager? En quoi tu me disais, c'est vraiment pas un virage simple? En quoi tu le trouves pas simple et comment tu l'as opéré, ce virage? Non, ça a été difficile parce que c'est deux métiers qui sont fondamentalement différents. Manager, c'est souvent l'évolution naturelle dans une carrière technique ou une des évolutions naturelles puisqu'on peut rester dans l'expertise technique ou s'orienter vers du leadership. Mais manager, ce n'est pas du tout les mêmes skills que développeur, même si développeur, ça aide. derrière être un bon manager, je pense. Ça a été assez dur, surtout que je suis dans une entreprise où l'équipe de direction est plutôt jeune, où il n'y avait pas vraiment pour moi de... Si ce n'est les dirigeants qui eux aussi ont eu ce travail d'apprentissage et de progression. Je n'ai pas eu de modèle ou de référent particulier. Donc, c'est vraiment un apprentissage sur le tas avec du coup beaucoup de veille sur des podcasts comme Tech.Rocks, sur des articles, sur des livres, enfin tout ce qui peut servir comme

8:33 retour d'expérience de personnes qui sont passées là avant, qui peuvent servir d'apprentissage. Et puis après, il ne faut pas le négliger, mais c'est aussi en faisant beaucoup, beaucoup d'erreurs et en tirant des leçons de toutes ces erreurs qu'on arrive à progresser. Un point que tu soulèves et que je trouve intéressant, tu disais le changement de contributeur individuel à manager, il s'incarne assez rapidement par la boucle de feedback. Notamment, tu dis quand tu fais du dev, c'est cool, tu as des résultats assez rapidement. Quand tu es manager, ce n'est pas la même histoire. Oui, carrément. Je prends souvent cet exemple parce que je le trouve assez marquant, mais j'avais monté un chantier d'amélioration des perfs de toute notre réservation de leçons. Chez nous, les candidats peuvent trouver des créneaux sur lesquels réserver des leçons avec des enseignants. Et à l'époque, une recherche mettait à peu près 8 secondes. Donc après un gros travail de rifacto de la feature, on arrive à des recherches qui mettent 500 millisecondes. En fait, au moment où tu envoies ta feature en prod, tu vois sur ton système, de monitoring que tu vas passer de 8 secondes par requête à 500 millisecondes par requête.

9:36 Et ça, c'est hyper gratifiant, je trouve, parce que tu as un résultat immédiat sur la feature que tu viens de développer et que tu mets en prod. Et ce résultat immédiat, je trouve que tu l'as beaucoup moins quand tu es manager parce que tu es plus sur un feedback qui va mettre six mois à un an. Pour obtenir des résultats. Quand on a commencé à retravailler l'organisation sous forme de squad, Donc pour un peu améliorer les échanges, la communication entre les... équipes produits et techniques. Il nous a fallu facilement neuf mois, ne serait-ce que pour mettre en place ces squads, faire l'accompagnement aux changements, recruter les profils dont on avait besoin. Et même une fois que les squads sont en place, le temps qu'elles-mêmes apprennent à travailler ensemble, que chacun... Apprennent à connaître son rôle dans l'équipe, comment communiquer, collaborer avec les autres, tu vas rajouter encore 3 à 6 mois. Et entre le moment où on a émis l'idée de cette réorganisation et le moment où je me suis dit, c'est cool, je peux commencer à me mettre en retrait parce que les équipes gèrent bien, il s'est passé au moins un an et demi. Et comme tu vois toute cette progression petit à petit, Ce n'est pas comme quand tu réalises ta feature où tu as vraiment un marqueur, un instant T qui dit ça y est, c'est terminé, c'est réussi.

10:45 Là, finalement, tu t'habitues en permanence à une situation un petit peu nouvelle et tu n'as jamais ce moment où tu te dis, c'est bon, vraiment, c'est cool ce que j'ai fait. Et parfois, on se retrouve un petit peu seul ou en tout cas, il faut structurer énormément ce moment où on veut collecter du feedback parce que… Au-delà du côté gratifiant de mettre en prod un truc qui marche, qui va vite, qui est plus performant, quand on fait du management, le gros défi, c'est de savoir ce qui ne marche pas, de demander des retours aux autres et essayer de s'améliorer, de se changer soi, ce qui est déjà toujours un gros défi. Mais cette boucle, elle est effectivement très, très lente. Est-ce que tu as mis en place des choses pour collecter? Des retours réguliers de ton équipe? Oui, alors moi je suis un glouton de retour. Plus j'en ai, plus ça me donne la possibilité de faire une... synthèse de ce qui marche ou ce qui marche moins bien et d'essayer d'ajuster tout ça, d'ajuster le tir pour la suite. Donc, je faisais beaucoup de one-to-one avec tous les membres de l'équipe. Donc, chaque équipe fait des daily. Donc, je demande que chaque daily, il y ait un compte rendu qui soit envoyé sur Slack chaque jour sur les sujets en cours, les problèmes rencontrés, etc., que je lis.

11:52 systématiquement, même si ça commence à être dense. On a des weekly qui lancent un peu la semaine, où pareil, j'encourage tout le monde à mettre leur critique positive et négative de la semaine passée pour en tirer des... Alors, je ne prends pas tout, mais des fois, il y a des problèmes de fond qui émergent, qui méritent d'aller être corrigés. On a des entretiens trimestriels, semestriels. On a mis beaucoup de rituels en place pour aller chercher du feedback, pour aller creuser. Maintenant, je fais moins de management. J'ai délégué ça au directeur of engineering qui nous a rejoints en début d'année, qui a pris la relève sur tous ces sujets. Mais par contre, du coup, ce que j'ai instauré, c'est des one-to-one, ce qu'on appelle skip level. Donc, c'est une fois tous les six mois, globalement. Je retourne voir toute l'équipe en one-to-one pour faire un peu le bilan du semestre et voir les problématiques de fond. Qui mériterait d'être améliorée. Cool comme pratique et tu réussis toujours à avoir un bon canal de communication. Les gens te racontent toujours un petit peu le dessous des cartes avec sincérité? J'espère.

12:53 En tout cas, je les encourage à le faire et j'essaye de ne pas trop juger leur retour. Et de plus en plus, j'essaye de ne pas non plus d'essayer d'essayer. de répondre tout de suite, plus pour les laisser parler et ensuite essayer de faire une synthèse de mon côté, mais de ne pas apporter de justification immédiate à quoi que ce soit, pour essayer de créer un petit peu un climat de confiance où chacun peut dire ce qu'il a à dire. Est-ce que ça marche ou pas, je ne sais pas encore. Et pour moi, ça reste une situation relativement nouvelle parce que cette transition et cette délégation du management, finalement, c'est quelque chose que j'ai commencé à opérer cette année et qui s'est amplifiée depuis seulement le début de l'été. En tant que CTO, maintenant que tu es dedans, c'est quoi ton plus gros challenge personnel ou les plus grosses difficultés que tu rencontres à titre personnel? C'est exactement ce dont on vient de parler, c'est d'apprendre à déléguer. Je suis ce qu'on appelle un contrôle fric à tous les sujets. Et du coup, faire confiance et déléguer, ce n'est pas des qualités qui sont naturelles chez moi. Et pourtant, c'est des choses qui sont nécessaires aujourd'hui, que j'apprenne à faire, que je réussisse à faire.

13:59 Et donc, tout mon enjeu en ce moment, c'est de réussir à prendre plus de hauteur stratégique, d'apprendre aussi à confier l'équipe que j'ai créée avec passion à quelqu'un d'autre qui la managera au moins aussi bien que moi. Alors comment tu fais pour déléguer? Comment tout repasse ce réflexe pas si naturel? C'est ce que j'apprends à faire avec beaucoup d'erreurs en ce moment, mais ma conclusion en ce moment et les outils que j'essaye de mettre en place, c'est plutôt de définir un peu quelle est ma vision. Quelle est ma stratégie ? Comme je suis un contrôle fric, je travaille beaucoup avec des règles, avec un cadre, avec des contraintes. Et donc, c'est de poser en fait quelles sont ces règles, quel est le cadre, quelles sont les contraintes pour que chacun puisse trouver son terrain de jeu en respectant ces règles et ce cadre imposé. C'est un petit peu comme quand tu veux monter une entreprise, tu as une législation qui t'empêche de faire tout et n'importe quoi. Ce n'est pas pour ça que tu n'as pas un terrain de jeu pour réussir à construire la boîte qui te plaît. C'est un peu ce que j'essaye de faire. Donc, ça consiste à mettre des...

15:00 Des grands concepts qui, je pense, ont fait une partie du succès de l'équipe et de la technique qu'on a aujourd'hui. C'est des choses très simples, mais de faire des composants qu'on peut réutiliser. Les développeurs aiment beaucoup l'abstraction, moi je suis fan de ça. Donc d'aller chercher la réutilisabilité de nos fonctionnalités au maximum. Quitte des fois à ne pas avoir le produit le plus parfait du monde, mais c'est beaucoup plus rapide parce qu'on capitalise sur des features existantes et on a moins de temps de maintenance derrière, on a moins de temps de développement et c'est quelque chose qui, moi, me parle et me plaît. Donc j'essaye de mettre un peu ce cadre et ces contraintes pour que chacun demain puisse faire ses propres choix dans le cadre et si jamais je ne suis pas d'accord avec ces choix-là, s'ils sont dans les cadres, je m'en prendrai seulement aux règles que j'ai dictées et pas aux choix qui ont été faits. Tu disais aussi que dans les pratiques ou les éléments du cadre que tu avais mis un peu en place, tu disais souvent non. Oui, je pense que le non, c'est quelque chose de très important. Souvent, c'est plus un moyen de gagner du temps, je pense.

16:01 C'est de dire non à un instant T pour maintenir le statut court, le temps d'avoir le temps de réfléchir à la proposition. Parce que souvent, ce n'est pas tant la proposition qui pose problème, c'est la façon dont on la modélise. Et quand on a réfléchi que cinq minutes à la modélisation, on n'a pas la globalité des possibilités. Des fois, juste prendre deux, trois jours de recul permet de s'ouvrir à d'autres façons de mettre en place quelque chose. Et d'un coup, ça peut rendre possible ce qui était demandé. Donc, un non initial. avec quelques jours de réflexion, peut devenir un oui. Donc j'essaye maintenant de dire un petit peu moins non et d'attendre au moins 5 minutes pour me faire un avis un petit peu plus ouvert sur la question. Et après, il y a des sujets sur lesquels il faut savoir dire non. Et là, pour le coup, c'est non négociable parce que des fois aussi dans les équipes, on n'a pas toute la vision globale. On est un peu sujet à live sur une techno en particulier, mais notre rôle de lead, c'est de faire en sorte que la techno, elle s'inscrive dans un projet de boîte, dans un projet d'équipe, dans un tout. Alors nous, on ne fait pas de full stack, par exemple, on fait beaucoup de front-end et de back-end, mais finalement, c'est les deux phases d'une même pièce.

17:07 Donc les choix front ont des impacts sur le back et vice-versa. Donc quand on choisit quelque chose, il faut que ça s'inscrive dans ce projet global. Effectivement, tu me disais souvent non, et notamment aux nouvelles technos. On échangeait, je disais que ce mantra ressemblait un petit peu à la fameuse boring architecture que Doctolib prône, qui est par défaut, on évite d'ajouter des nouvelles technos. Oui, mais moi, je suis très, très fan de cette boring architecture. Je l'ai présentée à plusieurs personnes en interne. J'ai essayé de la décliner sur, parce que du coup, dans ce cadre que j'essaye de présenter aux équipes, j'ai rédigé ce que j'appelle mon manifeste produit, qui est un peu ma philosophie de conception du produit. Ce qui déplait beaucoup, c'est quand je dis que je veux un produit qui soit chiant. Je veux un produit qui soit chiant parce qu'en fait, il respecte les standards, il respecte l'accessibilité, il respecte des contraintes toutes bêtes comme la pagination, les écrans de chargement, la gestion des erreurs. Ce n'est pas très sexy quand on veut faire du produit, mais c'est ce qui fait que le produit, à la fin, il est pleinement fonctionnel et il peut remplir sa mission avec une charge opérationnelle ou de support client qui est relativement faible.

18:13 Ça nécessite un peu de courage. Ce n'est pas toujours très agréable d'être celui qui dit souvent non, mais c'est à ce prix-là qu'on maintient une cohérence et une plateforme qui tient debout et qui rend les services attendus. Très bien résumé. Une autre question qu'on aime bien souvent poser, c'est si tu pouvais nous confier ton plus gros fail ou un de tes plus gros fails perso. Tu as une anecdote à nous partager? Oui, c'était pendant le confinement. En fait, chez le permis libre, les candidats font des leçons avec des enseignants. Et un des problèmes qui peut se poser par moment, c'est que le candidat va dire que la leçon a eu lieu alors qu'elle n'a pas eu lieu, ou l'enseignant peut dire la même chose de son côté. Donc, on a une situation où on a deux versions différentes d'une même histoire. Ce qui pose derrière pas mal de supports clients pour aller démêler le vrai du faux. Et donc, j'ai voulu récupérer un concept que j'avais mis en place dans ma précédente expérience entrepreneuriale, qui consistait à laisser chacun donner sa version, puis au bout d'une semaine, on arbitre.

19:13 Si les deux versions coïncident, on garde les deux parce qu'elles sont bonnes. Et si les deux versions ne coïncident pas, dans ce cas-là, on intervient pour savoir ce qui s'est passé. Et en fait, ça, ça a été très mal perçu par les enseignants, puisqu'ils ont pensé qu'on remettait en question leur pédagogie. confiance qu'on pouvait avoir envers eux. C'est une feature que j'avais portée seule pour des raisons un petit peu produites, des raisons techniques. Et on n'a pas eu le soutien du métier là-dessus. Ce qui fait qu'aussitôt que la feature est sortie, dans les trois heures, on l'avait annulée complètement et définitivement. Et pourtant, j'y ai passé du temps. Et c'est quoi ton learning là-dessus du coup? Aujourd'hui, on a un process de conception de feature qui est quand même un peu plus carré. C'est aussi pour ça qu'on a recruté des product managers. On va mieux communiquer avec le métier, avec le marketing, pour comprendre, eux, quelles sont leurs contraintes. Et du coup, finalement, le job du produit, c'est un petit peu de comprendre les contraintes de tout le monde, les contraintes des développeurs, les contraintes du marketing, les contraintes du service client,

20:18 et de réussir à donner un sens à tout ça et de proposer une solution qui résout la majorité des contraintes. Ça veut dire qu'on ne pourra pas faire la solution parfaite pour le marketing, parce qu'il faut aussi qu'on pense aux opérations, que des fois on va sacrifier un petit peu la technique, mais le learning est notre objectif aujourd'hui, c'est de bien discuter avec nos homologues métiers. Alors, à contrario du fail, c'est quoi ta plus grosse fierté que tu souhaiterais nous partager? Elle a changé, mais pendant longtemps, ça a été, puisque pendant trois ans, j'ai été le développeur backend principal de le permis libre. Donc, pendant longtemps, ça a été la plateforme technique qu'on a mis en place et à laquelle j'ai contribué, puisqu'on s'en félicite assez peu et c'est important, je pense, de le faire. Mais elle n'a jamais été en panne, on n'a quasiment jamais été indisponible. On n'a jamais eu de rifacto majeur à conduire et elle a réussi à nous accompagner dans la croissance et la scalabilité. Donc pendant longtemps, c'est vraiment cette plateforme technique qui m'a rendu fier.

21:21 Mais depuis un an et demi, je commence à être beaucoup plus fier de l'équipe que j'ai construite, des personnes que j'ai recrutées parce que je les vois. aujourd'hui qui travaillent ensemble, main dans la main au quotidien, qui s'écoutent, qui écoutent tout le monde et qui font du travail de qualité. Donc aujourd'hui, ma plus grande fierté chez le Permilip, c'est surtout l'équipe que j'ai construite. Cet épisode touche à sa fin et avec tous les challenges que tu viens d'évoquer et surtout les belles étapes franchies jusqu'à l'intro au bout, c'est quand même assez incroyable à nouveau. J'ai super envie de te demander, c'est quoi pour toi ton prochain challenge? Comme je l'ai dit tout à l'heure, pour moi, la suite, c'est de réussir à prendre plus de hauteur, à prendre plus de leadership. C'est souvent un peu la question des CTO, c'est qu'est-ce que c'est qu'être un CTO? Et il n'y a pas une réponse unique à donner à cette question parce que mon rôle de CTO d'une équipe de trois personnes n'était pas le même que mon rôle de CTO d'une équipe de dix personnes, qui n'était pas le même que mon rôle de CTO à 20 et qui n'est pas le même que mon rôle aujourd'hui.

22:26 Donc mon challenge, c'est juste de réussir à franchir ce nouveau cap et à être le CTO de demain, dont le permis libre a besoin. On te souhaite énormément de réussite dans cette tâche et énormément de succès au permis livre. C'est une super belle initiative, une belle histoire. Encore bravo et tout le meilleur à toi. Je te remercie beaucoup pour cet échange. C'était super intéressant. Et j'en profite pour faire une petite page de pub et inviter tous nos auditeurs à rejoindre en présentiel ou en remote la prochaine édition du Tech.Rocks Summit qui aura lieu les 7 et 8 décembre. Prochain. Adrien, encore merci à toi. Merci à toi, Hervé.