Aligner la tech sur les vrais enjeux business

0:03 Être entrepreneur très jeune, je pense qu'il faut être très naïf. C'est-à-dire qu'on ne mesure absolument pas le niveau de difficulté que ça représente, en plus dans la tech, puisqu'on cumule à la fois les enjeux du développement du business, comment développer une activité, comment bien se positionner, comment se promouvoir, comment se vendre, et en même temps tous les enjeux de la technique, comment développer un produit qui soit pertinent, qui soit fiable, qui soit utilisable par les utilisateurs et qui soit bien cohérent avec les enjeux du business et du développement de la société. Néanmoins, ça reste une école et une base d'apprentissage, si tu veux, qui est d'une richesse absolument incroyable. Mais si le marché n'est pas prêt pour le produit que tu es en train de développer, ça ne va pas marcher. Ça ne veut pas dire que tu n'as pas raison, ça veut dire que tu arrives trop tôt, pas dans les bonnes conditions de marché, pas au bon moment. Bonjour à tous, je suis très heureuse de vous retrouver pour un nouvel épisode du podcast de Tech.Rocks. Je suis Marie-Caroline Benezet, directrice des opérations et de la transformation du groupe SMCP. Je suis très heureuse aujourd'hui de recevoir Antoine Buhl, qui est CTO de Lean Tech Leaders et qui va nous raconter un peu plus de choses sur son parcours.

1:13 Bonjour Antoine! Bonjour Marie-Caroline, très heureux d'être avec toi aujourd'hui. Alors Antoine, est-ce que pour commencer tu peux nous raconter ce que tu fais aujourd'hui et puis un peu plus généralement d'où tu viens et ce que tu as fait dans ta carrière? Avec plaisir, écoute, je suis aujourd'hui CTO de LinkTech Leaders, en fait je suis CTO indépendant, je travaille à accompagner des startups dans leur développement, en particulier sur les sujets tech et produits. J'ai un profil très CTO et entrepreneur. J'accompagne des sociétés qui sont soit en train de se monter, soit en phase de croissance, pour essayer de leur permettre de gagner du temps sur les développements tech, l'organisation tech et la gestion de la croissance autour de tous ces sujets. J'ai été CTO de différentes aventures, principalement dans l'écosystème startup. Depuis plus de 20 ans. Et oui, j'ai compris que tu étais tombé dans la marmite de l'entrepreneuriat très jeune. Absolument. J'ai travaillé sur la création d'une première société avant d'être sorti de l'école avec certains de mes collègues étudiants.

2:15 Et on a monté notre première boîte vraiment en sortant de l'école. On a fait notre premier levier de fonds à peine deux ans plus tard. On a levé 6 millions d'euros à l'époque. C'était une grosse levée, grosse série A et grosse croissance. Ce qui a été une école très jeune de la gestion d'une startup, de l'organisation des équipes tech et de ce rôle très particulier de manager tech et produit. Et j'ai continué à vraiment évoluer quasiment toute ma carrière dans cet environnement, ensuite monter une autre aventure, travailler auprès d'autres sociétés et d'autres startups, jusqu'à rejoindre un projet auquel j'ai été associé et qui s'est développé énormément, qui est devenu une grosse scale-up et qu'on a fini par revendre il y a quelques années. On va y revenir. Le projet que vous avez revendu à Accor, c'est ça? Oui, absolument. On y reviendra. Moi, ce que je trouve intéressant pour démarrer, c'est que tu reviennes un peu sur les premières expériences, parce que quand on préparait, tu me racontais que ça a été un apprentissage assez rapide de plein de choses, mais notamment des premiers échecs qui t'ont permis de prendre du recul et de trouver la bonne manière de...

3:21 De gérer son timing ou en tout cas de gérer ses attentes par rapport à des projets qui croient très vite et qui avancent très très vite? Absolument. Être entrepreneur très jeune, je pense qu'il faut être très naïf. C'est-à-dire qu'on ne mesure absolument pas le niveau de difficulté que ça représente, en plus dans la tech, puisqu'on cumule à la fois les enjeux du... du développement du business, comment développer une activité, comment bien se positionner, comment se promouvoir, comment se vendre, et en même temps tous les enjeux de la technique, comment développer un produit qui soit pertinent, qui soit fiable, qui soit utilisable par les utilisateurs et qui soit bien cohérent avec les enjeux du business et du développement de la société. Tout ça est d'une complexité énorme et les entrepreneurs ou les très jeunes entrepreneurs qui démarrent, Je pense qu'on a tous été très naïfs en ne mesurant absolument pas le niveau de difficulté et de complexité que ça représente. Néanmoins, ça reste une école et une base d'apprentissage, si tu veux, qui est d'une richesse absolument incroyable, parce que tu es confronté de manière très directe et très intense, très concentré. À toutes ces problématiques qui se posent à toi et il faut bien les gérer et en général on se trompe beaucoup.

4:28 Et donc ces premières expériences pour moi ont été des apprentissages extrêmement riches, extrêmement durs aussi à la fois en termes d'intensité du travail et aussi de difficultés que tu as à surmonter. Je pense que la plupart d'entre nous et de mes collègues ont fait ça plus progressivement Et je pense que quand ils deviennent entrepreneurs ou quand ils contribuent à la création de sociétés, ils sont mieux armés qu'on ne l'était en sortant de l'école. Et donc, c'est vraiment des expériences qui ont probablement accéléré un peu notre, collectivement en tant que fondateur, notre courbe d'apprentissage. Comment vous étiez répartis les rôles ? Moi, j'ai toujours eu ce rôle de chef d'orchestre sur les aspects produits et tech. Je travaillais à l'époque et j'ai travaillé très longtemps ensuite avec Jérémy Chassin et Eric Bézine. Qui était dans la même promo que moi à l'époque et avec qui on a vécu ces aventures. Et dans l'équipe, on a très rapidement aussi complété l'équipe avec un autre fondateur qui avait un profil beaucoup plus business et qui lui apportait cette fibre-là de compréhension du marché, des enjeux financiers, cette capacité à piloter une levée de fonds auprès d'investisseurs institutionnels.

5:34 Quand on a moins de 25 ans, c'est juste pas du tout évident. Les deux autres, tes associés de l'école, ils étaient sur la partie tech? Oui, j'ai eu la chance de travailler avec eux très longtemps et encore jusqu'à récemment. Jérémy est un très brillant développeur et architecte technique qui fait encore autorité aujourd'hui sur des sujets d'architecture comme le domaine driven design, CQRS, etc. Et Eric Bézine qui a des capacités techniques extrêmement larges et qui aura travaillé avec moi sur des sujets tech qui vont du développement assez poussé à l'infrastructure. En passant par DevOps, etc. Avec un niveau de maîtrise et de profondeur de maîtrise de tous ces sujets très impressionnants. Ce que je comprends dans ce que tu viens de dire, c'est que vous étiez sur les aspects tech et produits, un trio avec toi plus sur le volet produit et fonctionnel et technique, Jérémy plus sur ce sujet. sur les questions d'architecture. Et puis le troisième, Eric, sur tout le domaine tech plus large.

6:36 Et la méthode, j'imagine, faire travailler des gens ensemble aussi, ça relève… Ça fait partie des sujets que moi, j'ai énormément travaillé, à la fois l'organisation, les process et le management. Oui, parce que ce que tu dis, quand j'entends que c'est allé très vite, vous avez levé de l'argent, c'est que très rapidement, vous avez été plusieurs à travailler ensemble sur la tech, une équipe à recruter. C'est aussi pas évident quand on est jeune de faire et de faire faire en même temps qu'on réfléchit à qui on le vend et pourquoi on le fait. Exactement. Et on a recruté une équipe de 20 personnes suite à celle de Levetron directement. C'est ta première expérience, comment est-ce que tu recrutes? Qui tu recrutes? Comment est-ce que tu organises l'équipe? Quels sont les process que tu mets en place? Comment est-ce que tu t'assures de délivrer? Comment tu assures un certain niveau de qualité? Il faut apprendre tout ça très très très rapidement. On apprend vraiment sur le tas. J'imagine que tu fais des erreurs, par exemple, tu recrutes des profils qui ne sont pas les bons? Tu fais beaucoup d'erreurs. Moi, j'avais quelques obsessions. J'avais une obsession des compétences techniques de ceux qu'on recrutait.

7:40 Donc, bien les évaluer et être capable de vraiment recruter des très bons. J'étais assez focalisé et concentré sur les enjeux de process. Donc, à l'époque, c'était Extreme Programming. Mais on a beaucoup travaillé là-dessus sur comment organiser le développement de manière efficace, quelles sont les bonnes méthodes de cycle itéral. C'était avant Scrum, qui permet de délivrer efficacement et régulièrement. Et j'ai eu très tôt aussi un gros tropisme autour de la qualité et du test, avec l'intuition que plus on était efficace, automatisé et organisé pour le test, plus on était capable de délivrer fréquemment, plus on était capable d'être performant et rapide. On s'est beaucoup penché sur ces sujets, au point d'ailleurs qu'on a même développé certains outils d'organisation du développement à l'époque. Avant que Jira apparaisse, on s'était développé notre propre plateforme qui permettait de gérer les tickets de développement. Et tout ça a fait qu'en termes de... De nos projets à l'époque. On développait un produit dans le streaming et la vidéo sur Internet au début des années 2000, ce qui est assez important dans l'histoire parce que c'était extrêmement tôt.

8:47 Donc à l'époque, il faut se remettre dans le contexte. Ce qu'on appelait le broadband, donc le haut débit, commençait à se déployer mais existait encore assez peu. Ça veut dire que les débits de connexion de la plupart des gens étaient très faibles et les vidéos étaient d'une qualité absolument déplorable et toute petite. Et donc, nos clients, nos prospects nous disaient, mais vous rêvez, personne ne regardera jamais des vidéos sur des écrans d'ordinateur avec cette pixelisation absolument monstrueuse et ces petits formats ridicules, ça ne marchera jamais. Le fait est qu'au global, l'aventure s'est terminée un peu prématurément. Mais la leçon a été que le timing dans la création d'une société et d'un produit par rapport à la maturité du marché est une composante super importante. Et c'est très bien d'innover. Mais avoir raison trop tôt, c'est un problème d'un point de vue business parce que tu ne pourras pas développer et vendre ton produit suffisamment. Les clients ou les prospects ne sont pas encore au stade où ils comprennent l'intérêt et la valeur que ça va leur apporter. Au final, tes détracteurs, si on peut les appeler comme ça, ils avaient tort parce que l'histoire a montré que tout le monde s'est mis à regarder des vidéos, même pixelisées, et sur de plus en plus petits écrans.

9:59 Alors maintenant, ce n'est plus le cas. parce qu'elles sont beaucoup moins pixelisées, la qualité de la captation a énormément évolué. Mais l'histoire a montré quand même qu'ils avaient tort. Mais en pratique, ils ont eu raison sur la question du timing. C'est-à-dire que vous étiez trop tôt. Est-ce que c'est ça? Vous étiez trop tôt sur un produit qui n'était pas encore attendu ou en tout cas… dont l'heure n'était pas encore arrivée. Exactement. Ça a été une des grandes leçons de mon point de vue sur la façon dont tu construis un produit innovant. C'est-à-dire que tu peux avoir une certaine idée de la façon dont le marché va évoluer et les besoins futurs vont se créer, mais si le marché n'est pas prêt pour le produit que tu es en train de développer, ça ne va pas marcher. Ça ne veut pas dire que tu n'as pas raison, ça veut dire que tu arrives trop tôt, pas dans les bonnes conditions de marché, pas au bon moment. Et trop tôt dans un contexte dans lequel tu as, par exemple, levé beaucoup d'argent et des objectifs de revenus et de génération de chiffre d'affaires qui sont très élevés avec une pression importante, en fait, ça te tue. C'est-à-dire que tu ne pourras pas, compte tenu de la maturité du marché, produire ce chiffre d'affaires.

11:00 Tu n'as pas assez de réserve et de ressources pour tenir le temps que le marché te rattrape. Exactement. Et c'est très intéressant de garder tout ça en tête parce que, tu vois, même dans une vague dans laquelle on est en ce moment de l'AI, etc., regardez bien quand est-ce qu'elle a été créée, OpenAI, depuis combien de temps est-ce qu'ils travaillent sur ces sujets, etc. Des enjeux de timing, de maturité du marché, des technos, de comment est-ce que tout cet écosystème évolue, est en fait extrêmement important. Tu m'en parlais, je trouvais intéressant les enseignements que tu as. attiré sur la qualité du produit. Quand tu me disais, en fait, l'approche ingénieure qui voudrait que je crée le produit le plus parfait possible, ce n'est pas la seule et surtout, ce n'est pas toujours la bonne. Parce qu'en fait, un produit parfait, s'il n'a pas rencontré son marché, il ne sert absolument à rien. Est-ce que tu peux développer un peu avec ton exemple personnel, sur cette boîte-là ou sur la prochaine? Moi, j'ai eu le sentiment d'avoir, pendant une partie de ma carrière, besoin de désapprendre un certain nombre de choses pour lesquelles j'avais été formé en tant qu'ingénieur, sorti d'école d'ingénieur, ayant passé des années à travailler les maths et la physique.

12:09 Pour la petite anecdote, on partage la même école d'ingénieur. Absolument. Pourquoi désapprendre? Parce qu'on apprend effectivement beaucoup de capacités à construire de manière rigoureuse, extrêmement pointue et qualitative, des mécaniques techniques qui visent à être parfaites, c'est-à-dire à parfaitement bien fonctionner, à avoir de défauts et à être les plus performantes possibles. Et sortant de là, moi j'étais… C'est ça pour toi, c'est théorique en fait. Exactement, c'est vraiment théorique. Ça nous a beaucoup aussi inculqué l'idée que si tu développes le produit techniquement parfait, qui répond parfaitement aux besoins en particulier de ce que tu anticipes comme étant un besoin futur, tout va très bien se passer parce que ça va être un besoin du marché et puis ton produit est génial. Manque de peau, ça ne marche pas comme ça. C'est un besoin. mais s'il est trop futur, ça ne marche pas. Et le produit parfait, cette perfection, en fait, ce n'est absolument pas du tout la bonne échelle de valeur.

13:10 C'est-à-dire que la perfection technique n'intéresse en réalité absolument personne. Oui, à part quelques chercheurs. À part quelques chercheurs qui travaillent sur ces sujets, tu as raison. La seule chose qui intéresse les utilisateurs, c'est est-ce que ça résout mon problème? Est-ce que ça répond à mon besoin? Est-ce que ça me permet d'accéder à des réponses plus rapides? Oui, la notion de prix aussi. C'est-à-dire, est-ce que je peux me le payer? Et est-ce que je suis d'accord pour payer ce prix-là pour ça? Parce que cette dimension, elle complète aussi ton raisonnement. Bien sûr. Est-ce que l'effort que je vais devoir mettre pour l'utiliser est suffisamment faible pour que ça vaille le coup, que je le fasse et que j'investisse le temps que ça va nécessiter de comprendre comment ça marche? Cette valeur de ce qui est une bonne solution par rapport à une mauvaise solution, cette échelle de valeur, pour moi, elle était en réalité totalement faussée. Quand je suis sorti de l'école et il a vraiment fallu travailler à changer complètement de prisme et à beaucoup travailler et comprendre ce que c'est qu'un marché, un besoin de marché, un timing pour sortir un produit, un besoin utilisateur, un focus sur les besoins des utilisateurs et leurs problèmes et la bonne façon de les résoudre.

14:22 Et vraiment partir de cette obsession d'utilisateur et du client, qui est une des clés de la réussite. beaucoup de startups, de scale-up tech, et qui, à mon sens, est absolument fondamentale. Alors, est-ce qu'on peut faire un flash forward un peu dans le temps et que tu nous racontes, donc là, on était assez concentré sur ta première expérience, même si je pense que ces enseignements, tu as continué de les vivre dans les expériences suivantes. Est-ce que tu peux nous parler de l'aventure entrepreneuriale qui a suivi dans le domaine de l'hospitalité? Tout à fait. Donc, on a rejoint une équipe qui était en train de monter un projet de plateforme. pour les hôtels qui permettait de gérer les réservations hôtelières. À l'époque du début de la digitalisation de tout le procès de réservation, on pouvait commencer à réserver un hôtel en ligne plutôt que de l'appeler au téléphone. Et les grandes plateformes de réservation qu'on connaît aujourd'hui, Booking.com en premier, étaient émergentes. C'est une start-up néerlandaise qui commençait à peine à se déployer hors des Pays-Bas.

15:22 Et on travaillait à développer une plateforme qui permettait à tous les hôtels de Paris, pour commencer, d'avoir un site internet qui permettait de réserver directement, dynamiquement, avec les prix directement affichés, les disponibilités, etc. Et donc, on a rejoint les fondateurs de cette société qui s'appelait Avelpro à l'époque. En tête des fondateurs, Philippe Lamarche était un multi-récidiviste de l'entrepreneuriat extrêmement brillant et qui avait déjà vraiment très bien réussi. Un certain nombre de fois, et avec qui j'ai appris énormément de choses sur ces dynamiques de marché notamment, et qui avait un sens, et qui a toujours d'ailleurs, un sens absolument surnaturel sur la capacité à détecter des opportunités commerciales, à construire un business performant et à bien comprendre comment naviguer dans ces enjeux de l'entreprise. C'est une des conclusions que j'en ai tirées, c'est que je n'avais pas ce talent. En se rapprochant de lui, tu t'es rapproché de quelqu'un qui t'a aidé à raccourcir le timing entre ce que tu construis comme produit et le marché qui va l'acheter.

16:29 Exactement. Et quel produit? produit, tu construis quand, pour quel marché, comment tu le commercialises et comment tu avances dans ce monde sans pitié du business. Et tu as pu te concentrer sur le produit. Et j'ai pu me concentrer sur le produit et beaucoup l'écouter et beaucoup apprendre sur ces volets-là et veiller à ce que cette cohérence et cet alignement entre la stratégie de business et comment tu développes une société et tous les enjeux produits et tech, comment est-ce que tu construis les produits qui vont être capables d'être vendus avec le bon niveau de qualité en fournissant les bonnes fonctionnalités et en faisant en sorte que les clients soient contents. Je pense que c'est cette approche qui a fait aussi le succès d'Avelpro. Il y a eu une petite levée de fonds au milieu de la croissance de la société qui a permis d'accélérer à une certaine phase. Je pense qu'on avait dû passer de 20 et quelques à un peu plus de 30 ou 40 grâce à cette levée de fonds. Donc, ça a permis d'accélérer un petit peu la croissance et de faciliter les choses. Mais le gros de la croissance a vraiment été organique et progressif au fur et à mesure du déploiement de nos solutions dans les hôtels français, parisiens d'abord, français, espagnols, Europe de l'Est, etc.

17:38 Ce que je comprends en comparant un peu les deux expériences, même si elles n'ont rien à voir en termes de maturité pour toi, c'est que vous avez levé beaucoup moins d'argent. Ce que je comprends entre les deux, il y avait moins d'argent levé et donc vous vous appuyez sur une croissance qui est beaucoup plus durable que celle des clients apportée par les ventes auprès des clients. Exactement. Et la particularité de... de Davel Pro à l'époque, et ce qui aussi moi m'a beaucoup convaincu que c'était des fondateurs avec qui il fallait qu'on travaille, c'est qu'on sentait très bien que la traction commerciale était là, le besoin était là, les premiers clients étaient très demandeurs, il y avait une vraie condition de marché favorable qui faisait que le produit se vendait. Et on était dans la bonne dynamique commerciale, ce qui concrètement m'a manqué dans toutes mes expériences précédentes. Et le problème d'Avelpro à l'époque, c'était une super bonne dynamique commerciale, mais une tech qui était globalement à la traîne, qui avait énormément de mal à monter à l'échelle. De plus en plus de clients, de plus en plus de réservations, de plus en plus de besoins, une croissance relativement rapide, une pression sur la tech très élevée, à la fois sur les fonctionnalités et sur la gestion du volume de données.

18:48 Qui commençaient à les dépasser. Et donc, là, je me suis dit… Tu vois, c'est marrant, parce que tu le présentes en disant le problème d'Avelpro, c'était ça. Mais moi, j'ai presque envie de dire, c'est une bonne nouvelle, parce que ça veut dire que tu as déjà le chiffre d'affaires qui va te permettre d'investir sur ta tech et non pas l'inverse, parce que l'inverse est hyper dangereux. En fait, d'être trop bon en tech et de ne pas avoir encore les clients, c'est une capacité importante, une priorité importante que tu te trompes de direction dans ce que tu développes. Absolument. Et nous, en tant que techniciens, modestement, je pense qu'on accorde un peu trop de valeur à la technique dans la vie d'une société et d'une startup. Je vais peut-être décevoir certains et en froisser certains. Malheureusement, le premier critère de succès d'une société, il est commercial. Et c'était vraiment cette capacité à avoir un produit qui se vend chez des clients qui ont une demande et à laquelle on répond bien, etc. Et il y a un certain nombre de succès, de très grands succès de la tech qui se sont faits sur des bases, c'est construit sur des bases techniques qui n'étaient vraiment pas terribles et qui ont pu être rattrapées ensuite parce que ça a...

20:00 Ça se rattrape, ça se retravaille, la dette technique, ça se gère, etc. Et ça ne t'empêche pas nécessairement de réussir d'un point de vue commercial. Et j'ai travaillé avec des grosses startups, des startups américaines très connues dans le monde de l'hospitalité en général, pas des hôtels. Je ne vais pas les citer là pour ne pas les froisser, mais qui sont très connues et qui ont révolutionné l'hospitalité en général il y a quelques années. Que vous avez tous utilisé très certainement. Avec un petit logo rose. Voilà, sur le plan technique, ils étaient extrêmement mauvais. C'est-à-dire qu'on a travaillé avec eux, on a développé des interfaces, etc. Ce n'est pas du tout l'image qu'on se fait d'une boîte de tech américaine. C'est marrant parce que j'avais cet exemple en tête tout à l'heure, même si je suis beaucoup moins... Connaisseuse que toi, mais j'ai cette intuition que le succès commercial vient quand même d'abord d'une expérience client et de ce que tu offres à des clients. La partie tech, elle est très importante quand tu vas devoir faire de la croissance et quand tu vas vivre la vraie vie de l'exploitation avec beaucoup de charges, beaucoup d'interfaces, etc.

21:07 Tu es obligé de t'appuyer sur un cœur technique performant. Ce n'est pas préalable. Ça arrive après. D'ailleurs, il y a quelque chose d'assez intéressant. J'aimerais qu'on passe à un autre volet qui est celui de l'exploitation. Parce que dans ce que tu racontes, c'est assez intéressant, c'est le prisme business. Comment je fais pour que l'entreprise, le projet auquel je compte, contribue, soit le bon, au bon moment, avec le bon produit, ça c'est une chose. Mais une fois que tu y arrives, on va dire, d'une manière ou d'une autre, tu développes un produit qui a trouvé un marché, qui a des clients. Pour moi, on arrive dans un autre univers qui est celui de comment je fais pour que ça marche tous les jours, 24 heures sur 24, 7 jours sur 7, et si en plus on rajoute la dimension internationale avec tous les fuseaux horaires, tous les... Type de clients possibles qui vont se connecter, venir la mettre sous pression d'une manière ou d'une autre. Moi, je vis beaucoup cette vie-là et c'est hyper difficile. Qu'est-ce que tu peux nous raconter sur tes enseignements sur la vie de l'exploitation d'un produit?

22:08 Dans un contexte dans lequel c'est plus ou moins le cas de la totalité des applications SaaS, C'est encore pire quand c'est des applications SaaS qui sont potentiellement utilisées partout dans le monde avec les décalages de fuseau horaire, comme tu le disais, et qui sont en plus business critical, c'est-à-dire qu'utilisées très quotidiennement et qui font vivre. Si elle ne fonctionne pas, il n'y a plus de business. Donc, ça doit fonctionner 24-7. Et quand tu es CTO, c'est effectivement ton boulot de veiller à ce que ça fonctionne 24-7. Et si ce n'est pas le cas, tu risques d'être, en particulier quand la boîte est petite, à t'appeler à n'importe quelle heure du jour et de la nuit et de la semaine pour régler les problèmes. Et donc cet apprentissage-là, quand tu es dans une boîte en croissance, tu commences par le prendre en direct de manière un peu brutale. C'est-à-dire que ça commence par des messages à n'importe quel jour et n'importe quelle heure parce qu'il y a un problème ici ou là. Et là, tu commences à te préoccuper justement de ces gens. enjeu de fiabilité d'une part et de gestion des problèmes quand il y en a d'autre part. Et donc sur les enjeux de fiabilité, c'est vraiment l'approche qui pour moi était assez évidente de partir du principe qu'à partir du moment où tu as des plateformes qui sont complexes,

23:19 les problèmes et les erreurs et les plantages arrivent. Tu peux faire tout ce que tu veux, et tu le fais, en termes de tests, de validation, de vérification, etc. Tu vas planter à un moment ou à un autre, à un endroit. Donc la seule manière dont tu peux gérer ce problème-là, c'est de gérer les plantages. d'assurer une redondance, de faire en sorte que si un composant meurt à un endroit, à un moment, ce n'est pas grave. Tu peux continuer à fonctionner de manière idéalement automatique, en mode dégradé éventuellement pendant quelques heures, mais il faut que ça continue à tourner. Et donc, comment est-ce que tu crées un système robuste? Robuste, ça veut dire que quand il y a un problème, en quelque sorte... Ça ne veut pas dire parfait. Ça veut dire capable de planter tranquillement. Capable de planter silencieusement et tranquillement. Et donc, à partir de là, la question, c'est quels sont les dispositifs qui sont à mettre en place? Quels sont les points vraiment critiques dans ton système? Comment est-ce que tu gères la redondance? Comment est-ce que tu répartis la charge? Quels sont les outils que tu peux mettre en place pour le faire? Et quelle est l'architecture aussi qui permet de le faire? Et ça, c'est un des premiers sujets en général qui pose un problème.

24:21 C'est-à-dire que tu as des plateformes qui sont plus ou moins distribuées, dans lesquelles la redondance de services est plus ou moins facile à faire. Et ça, ça fait partie de la question. C'est un sujet qu'il faut traiter extrêmement tôt dans les process de croissance parce que pas d'architecture inadaptée au scale. Typiquement, tu es dans une situation dans laquelle tu peux complètement bloquer le business de la société parce que tu ne tiens pas les pics de charge et tu vas exploser en vol régulièrement. En plus, c'est rageant parce que les pires moments, c'est ceux où on gagne le plus d'argent. Les moments les plus critiques, c'est toujours ceux où il y a le plus de business. Là, on était relativement préservé par rapport à, par exemple, des activités super existantes. comme le e-commerce, où tu vas te retrouver avec certaines périodes de l'année, le Black Friday, Noël, où tu vas avoir des pics de charges concentrés dans des périodes très courtes. Et si tu te loupes à ce moment-là, tu vas perdre un quart, un tiers du chiffre d'affaires de l'année. Je pense que c'est de moins en moins vrai pour tout le monde, malgré tout, je trouve. Mais nous, on était préservé de ça, c'est-à-dire que la croissance, elle était relativement lissée et elle s'est faite de manière assez progressive.

25:26 Tu dis ça parce que, par exemple, la réservation, elle s'étale, étant donné qu'elle se fait à l'avance par rapport à la période d'activité forte que sont les vacances scolaires, typiquement. Exactement. Donc, on avait une saisonnalité, oui, avec les mois d'avril, mai, juin et puis d'octobre, novembre, particulièrement actifs. Mais globalement, la croissance s'est faite de manière progressive, ce qui a facilité un peu ce travail. La gestion humaine, organisationnelle de ces sujets, elle est très compliquée. J'ai été beaucoup inspiré aussi à l'époque par Marc Benioff et Salesforce, qui s'est heurté très très tôt dans l'histoire de Salesforce à ce problème-là. De succès commercial qui enclenche la surutilisation des plateformes, qui enclenche des plantages, qui crée de l'insatisfaction, qui énerve tout le monde, etc. Et il avait une approche que je trouvais hyper intéressante, qui était d'être très transparent. Sur ce qui marche, ce qui ne marche pas. Et donc, au-delà d'être un pionnier du SaaS, ça a été aussi un pionnier de la transparence, de la disponibilité des services SaaS avec des dashboards accessibles à tout le monde pour dire, on est accessible, on n'est pas accessible, il y a tel service qui est...

26:30 On est en train de le remonter, etc. Et donc, on a eu beaucoup cette approche. C'est super intéressant cette approche de transparence, mais pour moi, elle est particulièrement pertinente et utile dans le B2B. En B2C, si tu fais de la réservation de chambre d'hôtel, tu as beau être transparent sur les raisons pour lesquelles ça ne marche pas, tu n'as pas de résa et puis c'est fini. Absolument. En B2B, tu peux faire patienter un peu, tu peux… Exactement. Et tant les hôtels, ça faisait sens et c'était pertinent. Mais ça rejoint une approche qui est toujours extrêmement efficace, qui est de matérialiser la performance par un KPI ou un indicateur que tout le monde peut voir. Et rien que de le faire très proprement, de bien le communiquer, de bien le partager et d'être très transparent, mécaniquement, il s'améliore. Pourquoi? Parce que tout le monde est aligné autour de ce qu'est la performance, tout le monde a envie de faire mieux et ça aligne toutes les organisations autour de l'amélioration du problème. Humainement, je trouve, là tu parles de l'interne et je te rejoins pas mal, humainement, ça crée de l'alignement entre les gens.

27:31 C'est-à-dire que je trouve qu'il y a aussi, sur les sujets complexes, qui sont donc difficiles à appréhender et à comprendre, il y a très souvent des fausses idées qui se véhiculent, du style« ça ne marche jamais»,« ce n'est pas bon», etc. Alors que quand tu les objectives, parfois tu te rassures en disant« ça ne marche jamais»,« non, c'est juste que ça a planté deux fois»,« c'est les deux fois où tu regardais». Parce que, je ne sais pas, il y a peut-être une bonne raison pour laquelle c'était les deux fois où tu regardais, mais au final, ça n'a planté que deux fois en trois mois. Et ça, ça fait redescendre un peu la pression entre les gens et ça permet de se réaligner sur la direction dans laquelle on travaille en interne. Absolument, et ça c'est vraiment important et ça fait partie aussi, je trouve, de notre rôle de CTO, d'être très pédagogue sur ces sujets-là auprès d'une population non tech qui a tendance à faire ses raccourcis, qui a de dire ça marche ou ça ne marche pas. En fait, il n'y a pas que deux états, ça marche ou ça ne marche pas, il y a plein de degrés entre les deux. Et voilà où on en est dans ces degrés-là. Donc, objectiver vraiment ça, expliquer aux autres comment on le mesure et qu'est-ce que ça veut dire.

28:32 Expliquer à tout le monde à partir de quand est-ce qu'on est content, le client est content, etc. Et tout ça, c'est très important. Et si tu regardes aujourd'hui les taux de disponibilité contractuelle de plateformes de cloud public comme AWS ou Azure ou GCP, tu vas voir que les taux de dispo contractuel auxquels ils s'engagent, ils ne sont pas fous. Alors que c'est typiquement des services qui sont réputés comme étant parfaitement fiables et sur lesquels tout le monde est en train de construire. Pour rester sur la question de l'exploitation, tu avais une anecdote dont on avait un petit peu parlé quand je te demandais, mais c'est quoi un exemple d'un plantage pour toi qui t'a fait des sueurs froides et qui t'a… Et quels sont les apprentissages liés à ce plantage? Tu me parlais d'un jour avec une surcharge. Oui, absolument. On a vécu des périodes difficiles dans ces phases de croissance avec des surcharges très importantes à certains moments qui ont vraiment mis à genoux la plateforme. perturber le business pendant parfois plusieurs heures, même une fois pendant 48 heures.

29:34 Et ça a beaucoup modelé notre approche de la performance en général et de la capacité à gérer l'optimisation. C'est-à-dire que quand tu es face à un problème de performance, pour une raison ou une autre, le système est beaucoup trop lent, ne traite pas assez vite, fait des erreurs, etc. On a beaucoup tendance, et c'est un biais à mon avis, de se dire, en fait, je sais, J'ai une idée de pourquoi ça ne marche pas. En fait, il faudrait que ce soit architecturé différemment ou c'est parce qu'on utilise tel outil plutôt que tel autre. Donc, on va en changer et puis on… On rajoute des serveurs. Alors, on peut en rajouter des serveurs. Le billet de base, pour moi, c'est ça. C'est rajouter de la bande passante. Rajoute de la bande passante, rajoute des serveurs, et puis on va se lancer dans ce chantier. Dans ce que j'ai pu observer dans mes équipes, dans les réflexes de mes équipes et dans d'autres sociétés, en fait, on est beaucoup trop rapide à agir pour gérer ces enjeux de performance basés sur des idées préconçues ou des idées externes qui ne sont pas en fait la réalité de la façon dont fonctionnent ces plateformes-là.

30:37 Et la vraie approche pour moi de l'optimisation et de la gestion de la performance, c'est d'analyser vraiment dans le détail ce qui se passe, où sont les goulets d'étranglement, où est-ce qu'on perd le temps, et essayer de comprendre où est-ce qu'il faut agir et de quelle manière est-ce qu'on peut optimiser. Et dans ce cas-là en particulier, on s'est retrouvé pendant 48 heures complètement surchargé avec une plateforme quasiment à plat, où on s'est dit en fait il faut qu'on change ça, il faut qu'on rajoute tel et tel serveur, il faut qu'on… En fait, on a fini par se pencher vraiment dans le détail sur l'investigation de toute la chaîne, de bien comprendre où étaient les goulets d'étranglement, etc. Pour finir par se rendre compte qu'on avait un système de filtrage en entrée des informations qu'on recevait, d'informations de prix en l'occurrence, et de disponibilité qu'on recevait des hôtels, qui étaient défaillants et qui ne filtraient pas du tout la bonne proportion des informations redondantes et qui du coup avaient multiplié par N% la charge qu'on subissait par rapport à juste avant. C'est de la charge inutile. De la charge complètement inutile. Et cet aspect-là était un peu noyé dans les indicateurs qu'on regardait et pas facilement identifiables.

31:39 Mais en fait, du coup, l'action à prendre pour optimiser, elle était très simple. Et c'était un débuggage très simple qui a permis de résoudre le problème. Et donc, dans ces enjeux-là de performance de manière générale, et je suis toujours extrêmement surpris des réflexes des équipes qui se sont confrontées à ces problèmes-là, c'est vraiment de comprendre et passer le temps de traitement, analyser les performances dans le détail des différents étages de traitement et de comprendre là où ça coince, là où il y a un problème, là où potentiellement il faut agir. Et en général, c'est un endroit. C'est-à-dire que les goulets d'étranglement, les process de gestion de données en général ont tous des capacités très différentes. Donc quand ça coince, c'est qu'il y a un endroit où on atteint un seuil qui est le goulet d'étranglement du moment. Il peut y en avoir d'autres après, bien sûr. Et c'est juste à cet endroit-là, de manière chirurgicale, que tu peux agir pour améliorer la situation. Ce n'est pas la peine de se lancer dans un gros chantier d'envergure à court terme pour résoudre le problème. Ce qui n'empêche pas les chantiers par ailleurs pour, par exemple, préparer pour le futur. Mais en tout cas, pour résoudre ta crise, ce n'était pas le bon truc.

32:41 Mais ce que je me dis en t'écoutant, c'est finalement le meilleur investissement que tu puisses faire, c'est d'envoyer les gens de l'équipe en immersion dans la compréhension du produit de manière hyper régulière. Parce que, en tout cas, moi qui ai beaucoup travaillé sur des systèmes legacy et qui ai encadré des équipes qui géraient des systèmes qui existent depuis... parfois 20 ou 30 ans quand j'étais à la SNCF. En réalité, il y a plein de bouts de ton système que plus personne ne connaît bien, qui n'ont jamais planté, donc qui n'ont jamais donné l'occasion à quelqu'un de comprendre comment il fonctionne, mais qui est le prochain qui va planter sur la liste et donc je vais devoir l'apprendre en urgence quand je vais devoir l'investiguer. Je me dis finalement, plutôt que de se former à des process, des nouvelles méthodes, etc., peut-être déjà se former à connaître ce sur quoi je travaille, même quand je n'en ai pas besoin, c'est le meilleur investissement. Exactement. Et bien comprendre les problèmes. Et je passe généralement toujours beaucoup de temps à me faire expliquer dans le détail. Qui pose un problème, ce qui n'est pas assez performant, ce qui n'est pas assez fiable, etc.

33:43 En rentrant vraiment dans le détail du détail, pour à la fois moi le comprendre, et puis obliger chacun aussi à comprendre et à creuser dans le fonctionnement des systèmes et des plateformes, pour ensuite, une fois qu'on a très bien compris le problème, en général, la solution devient beaucoup plus simple. Et ça peut se décliner, c'est exactement ce que tu dis, sur deux axes, des actions très tactiques qui vont avoir un effet court terme et qui vont être minimales, et après, des stratégies de fond, d'amélioration des architectures qui vont être beaucoup plus long terme. Mais qui sont nécessaires pour scaler quand on est dans des courbes de croissance qui sont très exigeantes. Alors justement, c'est le dernier aspect que je voulais aborder dans ce podcast, c'est comment tu fais pour t'assurer que tu es sur les bons sujets pour le futur? Là, tu viens d'évoquer... Les bons sujets pour le futur, ça peut être quoi ? Ça peut être les sujets qui vont te permettre de tenir la charge, donc la scalabilité, l'évolution de l'entreprise. Mais il y a d'autres aspects aussi. Comment est-ce que tu t'assures que tu es sur les bons thèmes de travail, les bons thèmes d'innovation, les bons features, etc.

34:47 Pour que tu continues à aller aussi vite et de manière aussi précise dans l'évolution du produit. Pour moi, tout découle de manière beaucoup plus directe qu'on parfois le pense. du business et du développement de la société et de son marché. C'est-à-dire qu'une fois que tu as une vision très claire de quel est ton positionnement, quel est ton marché, comment est-ce que tu vas te développer dans ce marché, et que tu comprends bien tes clients. Et ça fait partie des choses qui sont absolument cruciales dans nos rôles de CTO, qui sont d'aller sur le terrain, de rencontrer nos clients, nos utilisateurs, mais vraiment de les rencontrer en vrai, pas simplement par l'intermédiaire d'équipes commerciales ou d'autres managers. Pour bien comprendre cette dynamique-là, Et ensuite, c'est ça qui, pour moi, guide les choix sur le produit et sur la tech. Cette relation est beaucoup plus directe qu'on ne le croit, c'est-à-dire que dans le moindre choix d'architecture technique, qu'on le veuille ou non, il y a des parties prises.

35:52 Qui sont sur une échelle de, est-ce qu'on est en train de s'engager dans une solution qui va être très chère ou pas très chère? Est-ce qu'on s'engage dans une solution qui va être capable de scaler à très grande échelle ou pas? Est-ce qu'elle va être très complexe à maintenir et va nécessiter des compétences très pointues ou pas? Est-ce que c'est sur le bon sujet qui est vraiment différenciant pour nous, pour le business, qui du coup nécessite qu'on se focalise vraiment de manière importante dessus? Tous ces arbitrages-là, tous ces trade-offs, parce que la technique, c'est d'abord des décisions de compromis, d'une certaine manière, à 95%, vont se faire... la perspective du développement du business. Et faire ce lien et faire les bons arbitrages et les bons choix sont pour moi très importants. Et pour donner un exemple très simple qui pour moi est vraiment super emblématique, quand tu regardes la plateforme de Netflix par exemple, sur la question de est-ce que je déploie ma plateforme sur le cloud, est-ce que je ne déploie pas sur le cloud,

36:55 La plateforme de Netflix est faite de deux parties. Une partie qui est l'application que tu utilises pour choisir ton film, une application tout ce qu'il y a de plus hosté sur AWS, standard, qui utilise des stacks qu'on utilise tous tous les jours. Et la partie qui stream les vidéos, qui est complètement propriétaire, avec des serveurs de Netflix qui sont installés dans tous les data centers de la Terre, au plus près des opérateurs et des consommateurs, de manière à optimiser à la fois la performance, la fiabilité et le coût de toute cette infrastructure de diffusion. Pour deux parties de leur service, ils ont fait des choix techniques qui sont radicalement opposés. Et ça, si tu veux, pour être capable de faire ça, il faut avoir un niveau d'alignement entre les enjeux de ton business qui sont« je ne veux jamais avoir la moindre coupure de la vidéo d'un spectateur qui est en train de regarder un film» ou qu'il soit, quel que soit le moment, il faut que ça continue en permanence. Et c'est cet enjeu de service que tu veux rendre et les choix techniques qui sont tout au bout de la chaîne. Et très honnêtement, j'ai connu très peu de contextes dans lesquels ce genre de décision peut vraiment être...

38:01 Ça nécessite un niveau d'alignement très fort, mais ça montre très bien le lien direct et l'importance de cette stratégie business dans les choix techniques très profonds. Super intéressant, parce que c'est vrai que quand tu fais trop de raccourcis sur les enjeux tech, tu peux très rapidement te retrouver à dire, bon, l'escalabilité, ce n'est qu'un ajout de serveur pour augmenter ma bande passante, et la fonctionnalité, ce n'est qu'un rythme de livraison de new features, donc une célérité dans ta capacité à rajouter des nouveaux features. Et donc, le raccourci de base voudrait qu'un bon produit, c'est beaucoup de serveurs et une équipe qui va très vite à faire des new features. Sauf que, en fait, ce n'est pas ça la réalité. La réalité, c'est la juste architecture qui va te permettre de déployer le moins d'efforts à chaque étape pour passer à l'étape d'après. Exactement. Et la qualité de service qui est la bonne pour chaque moment du service. Parce que ce que tu décris de Netflix, c'est assez intéressant. C'est que ton choix de film, c'est une chose, mais c'est, on va dire, c'est une partie du service.

39:08 Le gros du service, c'est le film. Et ils ont découpé ces deux parties avec une notion du service qui est… elles-mêmes différentes. Et ça répond à ta question de où est-ce qu'il faut mettre le focus? Il faut mettre le focus là où les enjeux du business sont les plus importants et là où tu répondras le mieux. Comprendre le business, être le plus proche possible de tes commerciaux. même des clients, pour que tu saches en même temps que ce dont ils ont envie et puis surtout ce qu'ils valorisent dans ton produit. Parce qu'ils peuvent avoir envie d'un certain nombre de choses qu'ils ne valoriseront jamais chez toi, par exemple. Absolument. Et je pense qu'il y a certains choix et certains efforts que tu vas mettre sur des sujets qui vont faire une différence sur le marché. Parce que tu vas les faire différemment pour des bonnes raisons qui sont parfaitement alignées et qui sont d'un point de vue concurrentiel différenciantes. Et là, tu vas commencer à faire une grosse différence. Moi, j'ai vécu ça sur un des points qui a contribué à la réussite d'Avelpro à l'époque. C'est un sujet qui nous a bloqué à un moment, qui était une certification de sécurité.

40:11 La certification de sécurité pour la gestion des données de cartes bancaires. On gérait les cartes bancaires des clients qui réservaient. Et comme tu peux l'imaginer, il y a une certification qui s'appelle PCI qui normalise la sécurité de gestion de ces données-là, qui est ultra lourde. Et quand on a travaillé dessus il y a une dizaine d'années, qui était quasi inabordable pour une startup de, à l'époque, 30 personnes, ou 40, dont 10-15 à la tech. Et à l'époque, ce sujet-là nous bloquait pour à la fois des partenariats avec des partenaires, gros partenaires, c'est un acteur important, pour des gros clients qui nous disaient« mais vous êtes bien gentils avec votre petite solution de start-up, mais on ne va jamais de la vie, si vous n'êtes pas certifié, on va pouvoir travailler avec vous». Et donc là, on a vraiment dû travailler énormément et essayer de traiter ce problème-là. Ça demandait un investissement énorme. D'abord, il a fallu trouver des partenaires avec lesquels travailler sur le sujet. Et quand on est une petite startup et qu'on va voir des très grosses sociétés de sécurité, moi, je me suis retrouvé en face de grosses sociétés, je ne citerai pas, dont le consultant m'a dit, quand je lui ai expliqué notre enjeu de certification, il s'est mis littéralement à rigoler.

41:19 En me disant, mais vous savez, cette certification, elle va vous coûter 1 million d'euros. Vous faites 3 millions d'euros de chiffre d'affaires. Jamais de la vie, vous pourrez l'atteindre. C'est juste hors de portée pour vous, donc vous n'y arriverez pas. Et donc, on a largement persévéré. On a trouvé le bon partenaire qui était une petite société de cybersécurité parisienne hyper bien. Et je peux citer d'ailleurs Adrien Guinaud qui nous a accompagnés sur ce projet qui nous a beaucoup éclairé sur tous les enjeux de cybersécurité. On a travaillé sur des solutions techniques qui étaient hyper pointues. Parce qu'un des gros enjeux sur la compliance, c'est que quand tu es une startup super agile et que ton agilité fait aussi ton efficacité, d'embarquer une norme de sécurité ultra contraignante sur les process extrêmement bureaucratiques, ça peut te ralentir, voire te paralyser dans des proportions qui sont considérables. On a abordé le sujet de manière extrêmement pointue techniquement, en se disant qu'on va filtrer toutes ces données sensibles à l'entrée de la plateforme, et puis on les remettra à la sortie de manière la plus automatique et la plus seamless possible.

42:26 Donc là, c'est typiquement dans notre équipe, c'est typiquement Jérémy qui s'y colle et très brillamment arrive à développer l'algorithme qui nous a permis de faire ça. Moi, j'avais vraiment la certitude qu'alourdir nos process, c'était dangereux et qu'il fallait faire très attention. Eric a orchestré le projet d'un point de vue technique et on a fini par arriver à cette certification qui nous a débloqué d'un point de vue business et croissance un nombre de projets très importants dans les années suivantes et qui a fait une différence par rapport à la concurrence. C'est-à-dire que c'est là qu'on a laissé sur le carreau un certain nombre de... petites startups concurrentes qui n'ont jamais réussi réellement à passer ce cap. Ce que tu décris, il y a quand même une partie un peu qui relève de la prouesse technique ou du génie des choix techniques, et puis une partie qui est de la persévérance en disant que c'est le choix qu'il faut qu'on fasse. En gros, c'est notre point de salut. Si on y arrive, l'avenir est à nous, et puis si on n'y arrive pas, c'est la fin. Exactement. Exactement. Et ce n'est pas du tout facile dans un contexte de startup de se dire, en fait, il y a un sujet sur lequel il va vraiment falloir qu'on mette des efforts considérables.

43:32 C'est, je ne sais pas, ça doit être la moitié ou les deux tiers de notre bande passante sur un certain nombre de mois pour une petite startup. C'est juste absolument colossal. Parce que c'est clé, il va falloir être super persévérant, il va falloir trouver des solutions innovantes, mais c'est là qu'il faut qu'on se concentre. De toute façon, c'est très cohérent avec ce que tu racontais tout à l'heure, puisque ce qui t'a fait faire le choix, c'est un enjeu business. Tu ne l'as pas fait pour la beauté du geste, pour être compliant et être parfait. Tu l'as fait parce que tu savais que c'était la seule façon de continuer de croître en termes de business. Au final, c'est très cohérent avec ce que tu disais au début. Exactement. Merci. On arrive à la fin du podcast, mais j'avais encore une petite question quand même à te poser. Moi, ce que j'aime bien faire pour boucler la boucle à la fin d'un épisode, c'est te demander quels sont les conseils que tu donnerais à un entrepreneur qui te ressemble, ou pas d'ailleurs, mais qui se lance pour la première fois dans son aventure entrepreneuriale. Comment tu lui conseillerais de se muscler ou de s'entourer? Pour réussir? J'ai beaucoup réfléchi à cette question parce qu'elle était assez difficile pour moi. J'ai fini par me rappeler d'une situation à laquelle j'ai beaucoup repensé par la suite, qui m'a énormément marqué dans mon évolution de manager.

44:38 Un jour, un manager du comex avec lequel je travaillais, qui est par ailleurs quelqu'un de pas très recommandable de manière générale, qui m'a dit« oui, il faut arrêter d'avoir cette attitude de chef de bande avec ton équipe tech». Et ça m'a un peu perturbé sur le moment et ça m'a énormément fait réfléchir. Et ça m'a, je pense, permis de beaucoup progresser dans ma posture. de CTO et dans la compréhension de ce rôle. Parce que finalement, quand tu es manager, d'ailleurs, de manière générale, tu es pris en sandwich entre les aspirations de l'équipe que tu gères, qui va parfois avoir tendance à dire« je suis l'équipe tech maltraitée par des équipes commerciales ou des dirigeants qui ne comprennent rien à ce que je fais». De l'autre côté, tu as potentiellement un comex quand tu es CTO qui va te dire« mais vos experts, on ne sait pas très bien ce qu'ils font toute la journée, mais on a l'impression que ça ne va pas très vite et qu'on n'est pas sûr qu'ils se passent sur les bons sujets. Et toi, tu es entre les deux et tu as finalement une question qui, quand tu es jeune, peut un peu se poser, de se dire, mais en fait, je suis dans quel camp?

45:41 Je suis de quel côté? Et il faut que je sois de quel côté en réalité? Et cette alerte, tu m'as fait prendre conscience que j'étais un peu trop du côté de l'équipe tech. Et probablement, malgré ce qu'on s'est dit sur le business, pas suffisamment du côté du comex. Et ça pose la question de savoir quelle est la bonne posture et comment est-ce que tu choisis ton camp et où est ton camp. Moi, la façon dont j'ai résolu cette équation, c'est de me dire finalement, moi, mon camp, c'est l'intérêt de la société. Et donc, il faut que je sois capable de dire au COMEX, non, là, les gars, on est vraiment en train de faire fausse route, il faut qu'on s'y prenne différemment. Et inversement, il faut que je sois parfaitement capable de dire à l'équipe tech, non, non, non, vous êtes en train de travailler, on est en train de travailler là-dessus. Vous êtes en train de travailler sur un truc trop pointu et vous n'êtes pas assez rapide sur les choses qu'il faut faire. Exactement. Et c'est un peu difficile, paralysant, compliqué. Je pense que c'est tout ce qui fait la difficulté du rôle. Le manager, mais c'est important de bien être conscient de ça, de cet équilibre qui est assez précaire. Et souvent, je me suis rendu compte que les managers, plus ou moins malgré eux, choisissaient une posture dans un camp ou dans l'autre.

46:45 En fait, ce qu'on souhaite tous, ce serait qu'il n'y ait pas de camp. Enfin, ce qu'on souhaite tous, je ne sais pas, il y a des gens qui peut-être se complaisent dans l'affrontement, un peu plus que les autres. Mais moi, je me dis, en t'écoutant, quand même, la situation idéale, c'est d'arriver à cette one team. Il n'y a pas d'affrontement. Je pense que c'est inhérent à un fonctionnement en équipe, au pluriel, que d'avoir des moments où les visions s'opposent. Et c'est le rôle du manager que de les concilier. Donc, c'est un super conseil. Voilà. Et ce n'est pas facile, mais je pense que… Donc, ce n'était pas littéralement un conseil, mais je pense que ça m'a fait prendre conscience. Le conseil que je reformule en t'écoutant, c'est prendre conscience de ce qui se joue en termes d'opposition et de… d'opposition de vision, allez pour le dire pas dans un langage guerrier, Et déjà, rien que prendre conscience de ce qui se joue, c'est déjà le premier pas, parce que ça permet de prendre le recul et puis de se poser la question, aujourd'hui, j'en suis où? Qu'est-ce que j'en pense réellement, moi, en tant que manager, en me disant que l'objectif, c'est l'équipe, c'est le projet commun.

47:53 Et donc, prendre ce recul pour se dire, un coup, je vais abonder dans un sens, un coup dans l'autre. Parce que, C'est jamais tout noir ou tout blanc, ça change avec le temps. Exactement. Et tu lis, il y a des lectures qui t'aident? Absolument, je lis beaucoup de bouquins autour du business, du management, de la tech, etc. Parmi ceux que j'ai lus et qui m'ont beaucoup marqué, qui sont très peu cités et connus, je voulais parler d'un bouquin de 1987, donc vraiment les débuts de l'informatique, qui s'appelle Peopleware, qui a été écrit par deux consultants de l'époque. Qui sont déjà à l'époque posés la question de qu'est-ce qui faisait l'efficacité ou non d'équipes de développement de software et de tech en général. C'est organisé autour d'études et d'anecdotes et d'explications qui m'ont beaucoup marqué. Sur différents plans autour du recrutement, de la gestion des équipes, du management, des problèmes propres à la tech, qui ont suffisamment de recul pour être toujours d'actualité et qui m'ont fait comprendre, ce qui est important aussi, c'est qu'ils m'ont fait comprendre que

48:58 les livres et l'expérience de ceux qui ont travaillé dans la tech avant, peut valoir beaucoup et beaucoup apporter au nouveau. Et pour la rigolade, je raconte quand même une anecdote d'un des chapitres de ce bouquin qui porte sur le recrutement des techs. Et donc, ce chapitre sur le recrutement s'appelle, donc c'est en anglais, mais il s'appelle« Recruter un jongleur». Il écrit une scène très simple dans laquelle, dans un cirque, il recrute un jongleur. Et donc, l'intervieweur demande« Est-ce que vous savez jongler avec deux quilles? »« Oui. »« Est-ce que vous avez jonglé avec trois quilles? »« Oui. Oui, oui, je sais. Et vous savez jongler avec quatre quilles? Ah oui, super bien. Et vous arrivez à jongler avec quatre quilles en feu? Ah oui, j'arrive à jongler avec quatre quilles en feu, c'est super impressionnant. Ah bah super, vous êtes embauché. Et cet exemple-là, c'est typiquement très, très marquant. Dans cet exercice, et moi ça m'a beaucoup marqué, et construit les process de recrutement qu'on a fait ensuite. Quand tu regardes bien un certain nombre de process de recrutement de développeurs, en fait on recrute des jongleurs, on leur demande...

50:00 juste s'ils savent jongler avec 3 ou 4 quilles et on ne fait pas tellement plus. Et après, on voit, on les met dans la piscine et puis on voit comment... On se rendra compte quand ils sont sur scène de comment ça se passe. Merci Antoine, c'était un super épisode. J'étais hyper contente de pouvoir avoir cette conversation avec toi. J'espère que ça intéressera autant les auditeurs. Je vous souhaite à tous une bonne journée et à bientôt. Un grand merci Marie-Caroline. Très bonne journée à tous, à bientôt.