A la croisée des chemins entre la tech et le management

0:03 C'est plus compliqué de trouver des gens techniques qui font du management que de trouver uniquement des gens techniques. Moi, j'ai plutôt l'habitude de dire qu'un lead, quel que soit son niveau dans une entreprise, un lead technique, c'est surtout aider à faire en sorte que les développeurs travaillent le mieux possible. Je suis convaincu que chaque équipe doit trouver la façon de travailler qui sera la plus pertinente. Bonjour, nous sommes ravis aujourd'hui de démarrer le troisième épisode Tech.Rocks de notre série sur les techs nantais avec le collectif Indjaba Nantes qui anime l'un des écosystèmes les plus dynamiques en France. Ce collectif existe depuis trois ans, il a été créé par l'agence de développement économique Nantes La Nazar Développement et par la cantine numérique. Son objectif est de mettre en place des actions de communication pour promouvoir la marque employeur des entreprises du territoire, de parler de Nantes et de son écosystème tech, et bien sûr de pousser des offres d'emploi tech. Et aujourd'hui, je suis très heureuse d'accueillir Antonin Lacombe, qui est VP Engineering chez Langou.

1:05 Bonjour Antonin! Bonjour Marie-Caroline, bonjour Tech.Rocks. Oui, donc je suis Antonin Racombe, VP Engineering chez Lengow depuis quelques mois. Je manage directement ou indirectement une trentaine de personnes. Alors, dehors du travail, je vis sur la côte vendéenne et je suis papa de deux enfants. Et accessoirement, je suis aussi pompier volontaire. Merci Antonin de te prêter à l'exercice et on est très heureux de t'avoir aujourd'hui. Tu nous as dit où tu travaillais, mais peut-être pour commencer ce podcast, j'aurais aimé revenir à... avec toi sur ton parcours et que tu nous racontes par où tu as commencé et d'où tu viens. Oui, alors moi j'ai fait toutes mes études et j'ai grandi à Nantes et j'ai un parcours un peu particulier. Je n'ai pas fait de grandes études, j'ai fait un BTS à Nantes et une licence pro en alternance. Et j'ai commencé à travailler dans une boîte marthaise qui s'appelle People Motion, qui existe toujours. J'ai fait un petit tour à Londres pendant un an et demi, un peu plus d'un an et demi. Et puis, je suis rentré en France, j'ai travaillé à Bordeaux pour plusieurs entreprises, notamment une qui s'appelle Yescapa, qui était une chouette expérience. Et puis, à partir de 2018, j'ai commencé à faire du télétravail pour une boîte américaine.

2:09 Et donc, depuis 2018, je fais du full remote, full remote ou presque full remote, ça dépend pour les boîtes françaises un peu moins. Depuis, je travaille pour des boîtes françaises, mais toujours en full remote, principalement. Et depuis quelques mois, pour Lengow à Nantes, mais comme je ne vis pas personnellement à Nantes, principalement en remote. Et donc, j'ai commencé par être développeur, comme beaucoup, développeur back-end, principalement Python. Et puis, au fur et à mesure, prendre un peu plus le lead sur les projets, chef d'équipe et maintenant VP Engineering. Ce qui est hyper intéressant dans ton profil, c'est que tu as travaillé pour une variété de dimensions d'entreprise assez fortes. Le thème aujourd'hui, c'est Nantes. Aujourd'hui, tu travailles pour une boîte nantaise. Mais ce qui est super... Précieux c'est d'avoir ton feedback et de comparer les cultures d'entreprise et on y reviendra parce que ça fait partie des questions que je brûle d'impatience de te poser. Peut-être si on reste sur ton parcours, est-ce que tu nous as dit rapidement que tu avais commencé développeur, spécialiste back-end avec une spécialité type Python

3:16 et tu es passé très rapidement sur le fait qu'aujourd'hui tu occupais une fonction de management importante. Est-ce que tu peux nous expliquer un peu comment s'est fait la transition? Comment tu as fait pour apprendre et pour te nourrir, passer d'un rôle à l'autre? Oui, en fait, cette transition, elle a mis, j'allais dire, quelques années à se faire, parce que je pense que je n'étais pas prêt dans un premier temps. Je m'accrochais un petit peu à ma vision technique et à rester fort dans la technique. Je sentais cet appel du management. Donc, c'était principalement, je dirais, dans les années... En 2020, je travaillais pour une entreprise qui s'appelait FCT. J'étais architecte logiciel. Et là, j'étais vraiment à la croisée des deux chemins entre choisir entre la technique et le management. Et à ce moment-là, je n'avais pas envie de choisir. Donc, je faisais un peu les deux. Et ça m'a poursuivi à ma boîte d'après. Donc, chez Guide Guardian, j'étais engineering lead. Où là c'était exactement le type de poste qu'on demandait. C'était à peu près 50% management, 50% technique. Et là, ça m'a permis vraiment de faire un choix, de me rendre aussi compte qu'aujourd'hui, c'est plus compliqué de trouver des gens techniques qui font du management que de trouver uniquement des gens techniques et que ma plus-value était certainement ici pour une entreprise.

4:26 Et en plus, c'est ce que j'aimais faire. Donc en fait, ce choix, c'est fait. assez naturellement, mais il a pris 2-3 ans, au moins 3 ans, pour que moi je l'accepte. Et parle-nous de ce que tu as dû apprendre ou de ce à quoi tu as dû renoncer pour justement être un bon manager technique. Ce que j'ai dû apprendre, c'est travailler avec des personnes, parce que je pense que c'est une des facettes qui est à la fois la plus intéressante et à la fois la plus compliquée quand on fait du management, c'est de gérer l'humain. Ça fait un peu cliché de dire ça, mais je pense que c'est vrai, surtout quand on vient de la partie technique où on a... L'habitude d'avoir une action et une réaction. Quand on fait quelque chose, on a l'habitude à ce qu'on ait toujours la même réaction, ce qui n'est pas du tout vrai avec des humains. Et donc, dans un premier temps, ce que j'ai dû apprendre sur la partie management, en tout cas, c'était gérer, je n'allais pas dire forcément des conflits, mais gérer des situations dans lesquelles il faut souvent avoir du tact, savoir approcher les gens potentiellement de différentes manières en fonction du moment en fonction des personnes.

5:29 Et ça, c'est quelque chose que j'allais dire que moi, je n'ai pas appris en tant que tel. C'est assez naturel. Et pour le coup, je pense que ça aide vraiment de ne pas avoir à apprendre ces choses-là. Je ne sais même pas si on peut vraiment les apprendre. On peut peut-être s'entraîner ou plutôt acquérir de l'expérience. Est-ce que tu peux nous décrire en quoi consiste ton rôle aujourd'hui? Chez Lengow ou peut-être dans ton expérience précédente si tu préfères? Oui, on va parler chez Lengow. Aujourd'hui, c'est VP Engineering chez Lengow. C'est quatre équipes. Moi, je chapeaute quatre équipes. J'aide les tech leads à travailler, à gérer eux-mêmes leur propre équipe. Et je suis aussi garant d'une certaine cohérence technique entre les équipes. Donc, c'est aussi amener des outils. Moi, j'ai plutôt l'habitude de dire qu'un lead, quel que soit son niveau dans une entreprise, un lead technique, c'est surtout aider à faire en sorte que les développeurs travaillent le mieux possible. Et donc, pour le coup, mon métier aujourd'hui, c'est d'aider les leads dans leur métier pour que les...

6:30 les leads puissent eux-mêmes aider leurs développeurs. Donc c'est amener à chacune des équipes, j'allais dire la façon de travailler qui leur permet de travailler le plus efficacement et le mieux possible, tout en gardant une certaine cohérence au sein de l'entreprise. J'ai l'impression que tu es au moins autant attentif aux méthodes qu'aux questions technologiques. Tu parlais de cohérence technologique. Oui, alors pour moi, les méthodes, c'est hyper important parce qu'on peut avoir les meilleurs développeurs s'ils n'arrivent pas à travailler ensemble. En fait, ils ne feront rien. Je suis assez convaincu de ça. Et donc, pour moi, les méthodes, certains appelleront ça process. C'est vrai que méthode, c'est bien plus... Je préfère le mot méthode à process. Je suis convaincu que chaque équipe doit trouver la façon de travailler qui sera la plus pertinente. Moi, j'en connais, j'en ai déjà mis en place qui marchent. Je sais qu'elles marchent pour moi, qui ont marché pour plusieurs équipes. Et donc après, c'est toujours jongler entre mes convictions personnelles, des techniques et des méthodes. Qui ont marché pour moi et que j'ai vu marcher, celles que j'ai pu voir ou que j'ai pu lire dans des livres ou d'autres expériences, la façon dont veulent travailler les développeurs de cette équipe.

7:41 Et potentiellement, leurs contraintes techniques aussi, qu'ils peuvent avoir. Par exemple, les équipes d'infra ont des contraintes un peu spécifiques par rapport aux développeurs. On ne travaille pas forcément de la même façon. Et donc, c'est aussi savoir jongler avec ça. Et des fois, c'est aussi savoir laisser. On recoupe un peu avec la question de tout à l'heure, mais c'est... C'est aussi savoir laisser un peu ses convictions de côté, essayer des choses et admettre qu'elles marchent, même si ce n'était pas notre idée. Moi, j'ai la conviction que la méthode, elle doit aussi se contextualiser et que la contextualisation dans une entreprise, c'est quand même qu'est-ce que fait l'entreprise, quel est le business de l'entreprise. Donc, j'en profite pour te poser la question de qu'est-ce que fait Lengow pour que tu puisses un peu plus nous donner d'explications sur ce que font les différentes équipes que tu encadres. Oui, donc en fait, Lengow, c'est une boîte qui a une quinzaine d'années, qui a été créée à Nantes, toujours à Nantes aujourd'hui. Et donc en fait, Lengow, le but premier de Lengow, pour faire simple, c'est de diffuser un catalogue de produits d'un site de e-commerce sur un ensemble de marketplaces.

8:44 Ça, c'est vraiment les très grosses lignes. Vous avez un site de e-commerce, vous voulez diffuser sur... Je prends les marketplaces, je ne sais pas si on peut les nommer trop. Amazon, c'est discount, Mano Mano, j'en cite trois. Mais en fait, on en gère une soixantaine au niveau mondial. Et donc, en fait, c'est de la diffusion de catalogues produits. Et au milieu, il y a tout un ensemble de règles qui s'appliquent, qui sont un peu compliquées, pour diviser ces catalogues, ne pas tout envoyer sur chaque marketplace, pouvoir décider un peu des stratégies de pricing sur chaque marketplace. Et puis j'imagine reformater les données pour que la marketplace sache les lire. Alors ça, c'est la partie compliquée de chez Lengow, c'est que les catalogues d'entrée peuvent avoir des formats très différents en fonction des sources, des CSV, des JSON, des... XML jamais formaté pareil. On a un peu plus de chance quand ça vient de plugins Shopify ou e-commerce, des choses un peu plus normées. On a une équipe qui travaille uniquement sur le développement des plugins de sites e-commerce, Shopify ou e-commerce, toutes ces...

9:46 Tous ces plugins de sites de e-commerce, mais on gère aussi des sources qui peuvent venir directement créées par des personnes à la main. Ça peut être des Google Sheets, ça peut être tout un tas de sources différentes. Et donc, il y a un gros travail. de restructuration et de merge, de matching, on va dire, de toutes les catégories exactement, pour arriver sur un espèce de modèle un peu standard. Et puis en sortie, on a, comme je disais, une soixantaine de marketplaces gérées. Chaque marketplace a une implémentation différente, chaque marketplace attend un format différent, a des connecteurs différents, et donc autant de travail que de renvoyer ses produits sur chacune des marketplaces. Et donc, comment est structurée ton équipe par rapport à ça? En fait, nous, on a une équipe qui ne travaille que sur les plugins. Donc, ça, c'était que les plugins entrants. Ensuite, on a une équipe qui s'appelle Front, qui fait principalement toute la partie Front, comme son nom l'indique, qui est le back-office que les personnes de Shell& Go utilisent, mais aussi les clients. On a une équipe back-end qui gère toute la partie règles, application des règles, découpe des catalogues, on va dire l'algorithmie centrale du produit.

10:53 Et puis, on a une grosse équipe marketplace qui, elle, développe, maintient et fait un peu le travail en avance de phase pour le développement de chacune des marketplaces, on va dire avec le flux sortant des catalogues. Et puis, on a une petite équipe infra avec un DBA, des SRE. Et en termes de compétences et d'expertise technique? C'est quoi les plus grandes expertises que vous avez dans l'équipe? Les développeurs sont principalement des développeurs Python chez nous, puisque tous les développeurs de chez Marketplace et Backend sont des développeurs Python, mais on a aussi des développeurs PHP parce qu'on a une partie du front qui est en symphonie et nos plugins de sites de e-commerce qui sont faits en PHP aussi. Donc on a un peu deux profils de développeurs. On a les développeurs un peu plus PHP, les développeurs plus Python dans nos équipes. C'est un peu des topologies, des types de développeurs qu'on a. Merci de nous avoir éclairé sur ce que vous faisiez chez Lengow et en quoi consistait ton rôle. Peut-être maintenant, j'aimerais bien te poser des questions qui remettent un peu en perspective ce que tu as fait avant.

11:56 J'ai une conviction, c'est qu'on progresse beaucoup de rencontre en rencontre. Et c'est une question que j'aime bien poser. Est-ce qu'il y a eu des rencontres clés pour toi, des gens qui t'ont marqué? Est-ce que tu peux nous en parler un peu et nous dire en quoi, qu'est-ce qui t'ont apporté? Moi, je pense pouvoir nommer trois personnes qui ont un peu marqué ma carrière. Je ne sais pas si elles sont elles-mêmes au courant, mais en tout cas, moi, je pense qu'elles ont marqué ma carrière. Il y en a trois. Ça a été mon premier directeur technique. Directeur technique chez Ripple Motion à Nantes, qui s'appelle Olivier Tabonne. En fait, qui a été la première personne à m'avoir vraiment, j'allais dire, mentoré sur la partie technique quand je suis sorti de l'école. C'était aussi forcément mon premier directeur technique. Et pour le coup, c'était vraiment un... Et c'est resté pendant très longtemps, et je pense toujours aujourd'hui, pour moi, une référence en me disant comment Olivier aurait fait cette implémentation, comment il aurait réfléchi à une solution élégante pour faire ça. Je suis toujours en contact avec lui, on s'entend très bien. Et il m'est arrivé par le passé de lui demander son avis sur certains points, parce que je pense que...

13:01 Ça reste quelqu'un d'important pour moi sur la partie technique. Désolé Olivier, mais un peu moins sur la partie management, mais peut-être que tu as évolué là-dessus. Entre temps, une deuxième personne qui était aussi un référent pour moi techniquement et moins sur la partie management, on y viendra un peu après, c'est Jean Gabès qui travaille, qui avait monté Shinkon Solutions. C'est quand je travaillais à Bordeaux à l'époque, je travaillais avec lui en 2017. Et pareil, c'était vraiment quelqu'un de très fort techniquement. Et avec qui on s'entendait très bien. Et encore une fois, sur un axe purement technique, qui avait beaucoup de répondants sur la partie technique. Et pour le coup, Jean était lui-même très au courant que la partie management n'était pas son truc. Donc en fait, très tôt dans la création de Shinken, il avait embauché un manager, un engineering manager, pour gérer les équipes. Et lui se focalisait pleinement sur la technique. C'était clair dès le début. Et puis la troisième personne, c'est quelqu'un que j'ai croisé dans ma vie assez peu de temps, chez Guide Guardian.

14:05 C'était mon VP Engineering chez Guide Guardian quand je suis arrivé. C'est Julien Pley. Et pour le coup, ça a été, j'allais dire, une révélation, mais en tout cas, ça a été, pour moi, ça reste un petit peu l'exemple du manager que je voudrais être. Donc avec un gros background technique, mais en même temps, une très grosse partie perfecte. De gestion des process, de gestion des équipes. Et puis sur les one-to-one, une partie... Très humaine. Et c'est en ça, tout à l'heure, que je disais que c'est assez rare et que c'est comme ça que j'aimerais devenir. C'est ça que tu essaies de développer. Exactement. D'avoir une partie humaine assez importante, tout en ayant un background technique et pouvoir rentrer dans les conversations d'implémentation ou d'architecture. Et puis pouvoir suivre les personnes en one-to-one sur leurs évolutions de carrière, sur leurs problèmes perso. Avoir un peu cette double casquette, je trouve ça hyper intéressant et assez rare. Il y a un truc qui m'a marquée quand on a préparé et qu'on discutait, tu me parlais d'une sorte de avant-après sur ta gestion des one-to-one.

15:07 Je ne sais pas si c'est en rapport avec la rencontre dont tu viens de parler, mais j'aimerais bien te refaire parler de ça. Tu disais, en fait, jusqu'à un certain point, j'avais toujours pensé que le one-to-one, c'était l'endroit où on rendait compte sur ce qu'on avait fait. Et en fait, je me suis rendue compte, maintenant que je suis côté manager, que le one-to-one, ça devait nourrir toute autre chose. Oui, en fait, ça, ça a été… Pour le coup, jusqu'en 2018, j'ai travaillé quasiment exclusivement pour des boîtes françaises et qui étaient, j'allais dire, plutôt des petites boîtes. Donc, c'était des startups de, on va dire, moins de 50 salariés. Et même quand je travaillais en Angleterre, c'était relativement des petites boîtes. Et en 2018, j'ai commencé à travailler en full remote pour une boîte qui était basée à Philadelphie. J'étais le seul développeur en France. J'ai une équipe un peu particulière. Pour le coup, on était six développeurs, six personnes dans l'équipe. On était dans cinq pays et six time zones différentes. C'est vraiment le... Le full remote.

16:08 Extrême. Oui, voilà. Pour une première expérience, ça m'a mis dans le bain tout de suite. Et ça m'a mis aussi dans le bain un truc que je n'avais pas vraiment réalisé, qui était la différence culturelle de management entre une équipe américaine et ce que j'avais pu voir en France. Et pour le coup, mon manager de l'époque, Pour le coup, lui avait déjà fait du full remote depuis un moment. et était habitué à manager en full remote. Et donc, j'ai commencé à faire des one-to-one avec lui. Je ne connaissais pas tellement le principe. Pour moi, la relation avec le manager, elle était très factuelle sur qu'est-ce qu'on a délivré. Voilà, c'était vraiment l'humain rentrait très peu là-dedans. Tu t'apprêtais à lister tout ce que tu avais fait dans la semaine pour le rendre des comptes. Exactement. Et en fait, lui avait une approche beaucoup plus humaine en disant, les one-to-one, on va parler un petit peu de ce que tu as fait, avec une approche un peu particulière qui était, pour toi, pourquoi ça s'est bien passé, pourquoi ça s'est mal passé, qu'est-ce qu'on peut changer à nos process? Qu'est-ce qui t'a demandé le plus d'efforts, qu'est-ce qui t'a coûté? Exactement. Et donc, il y avait vraiment cette approche, j'allais dire humaine, sur le travail, c'est le travail.

17:13 Ce que tu as délivré, ce n'est pas on le met de côté, mais en fait, ce n'est pas le sujet de notre conversation pendant la prochaine demi-heure. Le sujet de notre conversation, c'est comment tu as ressenti, comment tu voudrais que ça se passe. Le sous-texte de ça, c'était qu'est-ce que je peux faire pour te faire rester le plus longtemps parmi nous? Et je pense que ça, c'est quelque chose qu'on a culturellement assez peu en France, de par les lois de travail, et qu'en fait, aux États-Unis, ils sont un petit peu obligés d'avoir, de par la mobilité juridique ou le cadre juridique du travail. Et en fait, lui, son point, c'était je veux le moins de turnover possible. Il faut que mes développeurs restent le plus longtemps possible avec moi, parce que c'est comme ça qu'on va construire un produit solide, en ayant des gens d'expérience qui connaissent le produit, et qui ont une très bonne relation entre eux. Et pour faire ça, il faut que... Je leur pose la question. Oui, et c'est ça. Il faut que tout le monde soit aligné. Il faut que je sache quand les gens aillent bien, quand les gens n'aillent pas bien, comment faire en sorte qu'ils aillent mieux. Et en fait, pour moi, ça a été un petit peu un déclic du... Ah oui, en fait, c'est ça un manager. Et c'est à partir de ce moment-là où je me suis vraiment posé la question, pour moi, c'est ça le manager que je voudrais être.

18:21 C'est savoir, encore une fois, gérer l'humain d'un côté, gérer la technique de l'autre. Mais à certains moments, il faut savoir laisser la technique pour rentrer un peu plus dans le côté humain, parce qu'on est tous au courant qu'il y a beaucoup de problèmes de rétention et que c'est un des points, les recrutements sont un point. j'allais dire problématique, en tout cas un point clé, c'est ça. Et donc, plus on garde et plus nos développeurs sont contents, en tout cas les gens avec qui on travaille sont contents de venir au travail, je suis assez convaincu que c'est le mieux ils travaillent et en plus ils resteront avec nous plus longtemps, donc c'est gagnant-gagnant. Est-ce que tu peux enchaîner en nous parlant des projets dont tu es le plus fier en termes de réalisation? Je vais en citer deux. Je vais citer IESCAPA. C'est une entreprise qui existe toujours, qui est basée à Bordeaux, quand je travaillais à Bordeaux. Et en fait, moi, je suis arrivé tech lead. Je crois que j'étais le premier ou le deuxième CDI de la boîte. C'était vraiment une toute petite boîte quand je suis arrivé. Et donc, il y a ce qu'après, ils font de l'allocation de camping-cars entre particuliers, l'Airbnb du camping-car.

19:26 Et donc, en fait, assez rapidement, ça a assez bien marché. Et donc, on a dû penser à l'international très vite. Et donc là, on est assez vite rentré dans les problèmes d'internationalisation, qui pour moi étaient entre guillemets nouveaux, c'est-à-dire que je les connaissais, mais je ne les avais jamais forcément mis en œuvre. Et là, on est rentré dans les différents problèmes de localisation, d'internationalisation. Les systèmes de paiement, les différentes time zones, les différentes devises et comment on fait matcher tout ça avec une équipe assez restreinte pour le coup. Donc c'était hyper... formateur, c'était pas de tout repos mais c'était hyper formateur. C'était des challenges de conception et puis aussi, en tout cas pour le vivre un tout petit peu, l'internationalisation, il y a un truc qui est difficile humainement, c'est qu'il faut penser à des questions que tu ne connais même pas, il faut trouver la réponse à une question que tu ne connais pas. Quelles sont les pratiques dans tel pays sur tel et tel sujet, tu ne sais même pas que c'est différent de chez toi et en fait tu commences à savoir comment ça se passe. Oui, et puis les différences culturelles, les différences dont on ne pense pas.

20:31 En Allemagne, tous les mots font un tiers de plus de longueur. Donc tous vos boutons vont exploser, il n'y a rien qui va matcher. Et en fait, c'est beaucoup de die and retry. On essaye, ça ne marche pas, on avise, on modifie. Et ouais, c'est hyper formateur. Et l'autre projet, c'est un projet qui a un peu plus d'un an maintenant, c'est quand j'étais chez Guide Guardian. On a monté une équipe, j'étais Engineering Lead de l'équipe Core pendant une certaine période, et puis à un moment, on a voulu lancer un nouveau produit. Et la particularité, c'était qu'en décembre, on est venu me voir pour me dire qu'on allait créer un nouveau produit. Qui s'appellera Leonie Token, où on va poser des clés AWS dans le code des développeurs, dans les repos de nos clients, et on va faire en sorte que si jamais on trouve ces clés-là, nous, parce qu'en fait on est une petite gardienne, on scanne les repos publics, GitHub en l'occurrence, c'est que si on trouve ces clés-là, c'est que le code de nos clients va affluer. Vous cherchez à faire un détecteur de fuite de code, c'est ça ?

21:33 Exactement. Parce que Guide Guardian, le principe, c'est qu'on fait de la détection de secrets. On est hooké sur les VCS de nos clients et on détecte les secrets que les développeurs pourraient committer. Donc là, c'était une approche un peu particulière. C'était, on va se servir du moteur de détection de secrets pour aller voir si le code de notre client a fuité sur des repos publics. Ce n'est pas le seul cas d'usage, mais c'est le cas d'usage principal. Et la seule particularité, c'est que là, on était en mode décembre. Et en fait On savait déjà qu'il fallait avoir une démo montrable parce que le slot pour une... Donc c'était le RSA, une grosse conférence de cybersécurité à San Francisco, était déjà réservé pour le 12 avril. Donc on était en décembre, il fallait qu'on ait quelque chose d'utilisable en avril. Et on était deux développeurs, moi et un PM. Et puis on s'est retroussé les manches. Le timeboxing appliqué à la sortie de produit. Oui, et donc ça a été exactement, ça a été comment on peut rationaliser les choses un maximum, il n'y a rien qui dépasse, et puis il faut qu'on s'assure d'avoir quelque chose à la fin.

22:34 Donc ça a été vraiment découper le projet. Moquer le moins possible, mais un peu particulier. Et en fait, la finalité, c'est qu'on y est arrivé, et on est même allé un tout petit peu plus loin, c'est qu'en avril, c'était même quasiment prêt, parce qu'on a ouvert la bêta à nos gros clients le 15 mai. Donc un mois après, c'était ouvert en bêta aux clients, et ça a été ouvert au public le 15 août. On a ouvert à tous les clients, payant et gratuit. Donc là, c'est une bonne idée. Qu'est-ce que tu en tires comme conclusion? Est-ce que tu dirais que le timeboxing, c'est une bonne manière de faire ou est-ce que malgré tout, ce n'est pas la bonne manière de packager un projet? Moi, je pense que c'est une très bonne manière de le faire. Je pense que c'est une bonne manière de le faire parce qu'en fait, c'est plus facile pour tout le monde d'avoir un objectif et un cap défini. Et c'est encore plus facile pour tout le monde quand on sait où est la ligne d'arrivée. En tout cas, ça permet de jalonner un peu plus les choses et de paver le projet de différentes étapes pour arriver à cette ligne d'arrivée.

23:36 Donc, je ne dis pas que le projet était fini, mais en tout cas, on avait un POC montrable et testable par des clients en bêta. En fait, c'était ça notre objectif. Est-ce que c'est une question d'adrénaline ou est-ce que c'est juste une question de clarification de vision, de plan? Je pense qu'il y a les deux. Il y a aussi une question de beaucoup d'heures de travail. Je pense que le plan et la façon dont on va adresser le problème, il y est pour beaucoup. Notamment, on a un peu ces questions-là chez Lengow en ce moment, mais c'est comment on va faire en sorte que même si on se rate, en fait, on ne se rate pas de beaucoup. Donc en fait, on va faire plein d'itérations différentes et on va s'assurer qu'à chaque itération, le produit soit presque utilisable. Et on va éviter, pour le coup, moi je suis très contre ça, et ça tombe bien, pour le coup, ce qu'il ne fallait pas faire, on va éviter un gros waterfall de trois mois en disant on va livrer 15 jours avant et puis c'est sûr que tout va marcher. Pour moi, c'est ça. C'est la seule solution. C'est la solution qui ne va pas marcher de toute façon. Donc, c'était vraiment faire des petites itérations, y aller petit à petit et toujours s'assurer que ça va marcher.

24:40 Je trouve que ce serait super intéressant de revenir sur le full remote et notamment sur les conditions qui rendent ça possible. Est-ce que dans les dernières minutes qui nous restent, tu peux nous expliquer tes rituels, comment tu t'organises et comment tu fais en sorte que tes collègues à Nantes travaillent avec toi le plus efficacement possible? Oui, on va. En fait, pour moi, le full remote, je suis convaincu que ça marche. Mais par contre, il faut mettre en place quelques outils. Un des outils, pour moi, c'est hyper important de mettre en place des daily ou des daily tous les deux jours. Je ne sais pas comment on appelle ça. Mais en tout cas, de mettre en place des réunions où les gens des équipes se voient. Parle entre elles et on fait un point sur les projets parce qu'on n'a pas ça, on n'est pas l'un à côté de l'autre au bureau. Et donc, c'est hyper important d'avoir des points de synchronisation, pour moi, au moins une fois par jour, sur les projets. Il y a un deuxième truc qui est important pour moi, c'est, tout le monde n'est pas forcément d'accord, mais c'est, si on le peut, d'imposer ou en tout cas de faire en sorte que les équipes se retrouvent une fois tous les 15 jours, une fois par mois, pour travailler un peu ensemble et même dans l'idéal,

25:48 pour faire du non-job, se voir à l'extérieur. Ensemble. Exactement, pour se voir un peu à l'extérieur du boulot. Donc ça, c'est quelque chose qui était très bien fait chez Kid Guardian. Tous les mois, il y avait un event d'entreprise avec l'équipe en full remote. Donc on était à la moitié en full remote, la moitié sur site. Et on se retrouvait pendant trois jours. Et pendant ces trois jours, il y avait toujours un événement d'entreprise pour voir les autres. Et puis nous, on organisait toujours dans l'équipe aussi un repas d'équipe, que ce soit un midi ou un soir, mais pour échanger entre nous sur autre chose que le travail et apprendre à se connaître un petit peu différemment. Parce que pour moi, la plus grosse différence, c'est ça. C'est que quand on fait du full remote, on ne parle que de travail avec ses collègues. Et en fait, La vie avec ses collègues, ce n'est pas... que par les travails. Et la différence, c'est qu'il faut les provoquer. C'est-à-dire que quand tu croises tes collègues tous les jours, tu sociabilises naturellement. C'est ce qu'on appelle la machine à café dans les couloirs, etc. Alors que quand tu ne les croises pas, il faut le provoquer. Ce que tu dis, c'est une fois par mois. Et ce n'est pas seulement des réunions de travail. Ça peut, en partie, mais pas que.

26:51 Exactement. Et je pense que c'est un des points qui fait que pas mal de boîtes, ils ont l'impression que le full remote ne marche pas pour ces raisons-là, parce que ce n'est pas forcément des tips, mais c'est quelque chose à mettre en place. Oui, mais c'est pour maintenir l'âme. Parce que souvent, la critique principale qu'on fait, c'est qu'il n'y a pas d'âme. L'appartenance à l'entreprise. Oui, un problème d'appartenance ou un désengagement de certaines personnes. Or, tu le recrées grâce à ces événements-là. Et je voulais te faire parler de l'écrit et de l'oral, parce que pour moi, c'est un des grands challenges du full remote. C'est de redonner son rôle à l'écrit et son rôle à l'oral, qui ne sont pas forcément les mêmes que pour le travail en présentiel. Oui, c'est important de travailler en asynchrone quand on fait du full remote, parce que c'est aussi une des choses qu'on cherche quand on fait du full remote. Et donc, pour faire de l'asynchrone, il faut faire de l'écrit. Et ça, il n'y a pas de secret. Il faut écrire les choses. Il faut que ce soit un Slack, un Teams, whatever, en tout cas, une channel de communication qui soit rapide. Et puis, il faut aussi écrire des choses qui soient un peu plus gravées dans le marbre et qui restent plus longtemps, en confluence, en ocean, quoi que ce soit.

27:58 Mais en tout cas, il faut un peu ces... et deux façons d'écrit différentes, soit de l'écrit rapide chat et de l'écrit qui persiste, soit de la documentation, soit du long terme. Et puis l'oral, il vient pour agrémenter ça, mais on ne doit pas prendre de décision à l'oral qui ne serait pas passée par écrit, parce qu'en fait, tout ce qui est dit à l'oral est oublié assez rapidement. Mais surtout, il n'est pas partagé. Oui, exactement. Et puis est soumis à interprétation de temps en temps. L'écrit aussi. Ça demande de l'exercice de bien écrire pour qu'il n'y ait pas d'interprétation. Oui, mais l'écrit peut être soumis à relecture. Oui, pas l'oral. Ce que ça permet, ce que tu viens de dire, c'est d'utiliser l'oral pour tout le reste. c'est-à-dire la sociabilisation, ce que tu disais tout à l'heure sur les one-to-one, c'est-à-dire le ressenti, l'émotionnel. Dans le one-to-one, finalement, tout ce que tu as délivré, je l'ai vu, c'était écrit, je l'ai vu dans le code que tu as soumis, la liste des tests qui ont été faits, tout ce que tu as, ta performance ou plutôt ta quantité délivrée, je l'ai déjà lu.

29:06 En revanche, la difficulté que tu as eu à le faire, l'insatisfaction que tu as eue à certaines choses, ça, je ne le vois pas. Raconte-le-moi. Exactement, tout à fait. Eh bien, merci, c'était très riche. Peut-être en guise de conclusion, une petite question un peu anecdotique qui est typique des questions qu'on pose très souvent chez Tech.Rocks, qui est est-ce que tu codes encore? Et puis, à ton avis, est-ce qu'il y a… Un tech leader doit coder ? Pour faire très court, non, je ne code plus. Et est-ce qu'un tech leader doit coder? Ça dépend du temps qu'il a pour le faire. S'il a du temps pour le faire, je pense que grand bien lui fasse. Et s'il n'a plus de temps pour le faire, je lui dirais que sa plus-value n'est pas forcément là. Que s'il veut le faire sur son temps perso, qu'il le fasse, mais ce n'est pas grave de ne plus le faire. Eh bien, écoute, merci beaucoup Antonin. C'était super sympa de préparer ce podcast avec toi et super intéressant de le faire aujourd'hui. J'espère que ça t'a... apporter aussi et j'espère que nos auditeurs seront heureux de l'écouter. En tout cas, moi, je serais ravie de poursuivre la conversation à un autre moment avec toi.

30:10 Merci beaucoup. Merci Marie-Caroline.