S03E10 · Un plan de carrière passe-t-il forcément par du management ?

0:05 Ouais, et puis surtout, ça t'apprend un truc, c'est que c'est pas le code le problème, en fait. C'est la communication autour de tout ça. Je me suis retrouvé avec des gars qui faisaient de l'informatique complètement différemment de ce que j'avais pu faire depuis 3-4 ans. Et c'est là où j'ai pris une grosse claque, je me rappelle. Ils faisaient des trucs qui s'appelaient des stand-up, c'était un peu bizarre. Je me rappelle, j'étais allé dans une mission une fois où le gars disait, il faut que mes murs soient blancs, qu'ils soient absolument parfaits, mes murs doivent être impeccables, nickels. Et moi, j'ai arrivé, j'ai dit, bah non, on va mettre des post-it au mur, je suis désolé. Bonjour à tous, je suis Dimitri Baeli, CPO chez Aramis Auto et un des cofondateurs de Tech.Rocks. J'ai le plaisir aujourd'hui d'accueillir Jean-Laurent de Morlhon. Jean-Laurent, bonjour. Est-ce que tu peux te présenter? Bonjour Dimitri, bonjour à tous. Donc moi c'est Jean-Laurent de Morlhon, je suis le VP Engineering chez Docker. Et voilà, je suis ravi de discuter avec toi aujourd'hui, Dimitri.

1:06 Ravi aussi. Alors, on se connaît depuis un bon moment, a priori. On n'a pas retrouvé la date exacte de nos premières rencontres, mais ça doit se situer aux alentours de 2008. Ce qui m'intéresse, c'est un petit peu ton parcours, de savoir un peu avant qu'on se rencontre au sein de l'OSSGTP, dont on reparlera, comment tu es arrivé un peu dans le milieu professionnel et tes premières... Rencontre avec le domaine. Oui, c'est vrai que ça remonte à un petit moment. J'écoutais des gars sur Clubhouse l'autre jour qui racontaient que ça fait quand même presque 10 ans qu'ils étaient dans l'informatique. Maintenant, c'est vrai qu'on prend un coup de vieux quand on réfléchit. Pourquoi ça ne fait pas 10 ans? Ça fait vachement plus que ça. Parce que je crois que mes premières armes, c'était que je commençais à rire sur le marché du boulot au moment du passage à l'an 2000. Ça y est, je prends un autre coup de vieux. Et effectivement, 99, je pense, 98, c'est pas mal. Le premier moment où j'ai commencé à bosser. Moi, j'ai bossé au début dans une société de... Une agence web, c'était à l'époque. On faisait de l'Internet avec du dial-up, là.

2:08 Et tu avais droit à 8 heures de connexion par semaine, un truc comme ça. Il y avait des choses comme ça, c'était très rigolo. Et donc moi, j'ai commencé à faire des sites web. J'ai un diplôme d'ingénieur, c'est classique, généraliste. J'ai commencé là-dessus. Et en fait, j'ai passé plusieurs années à faire 2, 3 trucs comme ça. Et puis, c'est vrai qu'à un moment donné, j'ai voulu rentrer... Après quelques années de Web Agency, j'ai voulu rentrer dans une boîte qui faisait de la tech. Un éditeur de soft, je m'étais dit que c'était là où ça allait être le plus rigolo. Et par le hasard de la vie, je suis tombé sur une équipe dans un énorme projet gigantesque à la BNP, en service évidemment, c'était un peu le quid de l'histoire. Je me suis retrouvé avec des gars qui faisaient de l'informatique complètement différemment de ce que j'avais pu faire depuis 3-4 ans. Et c'est là où j'ai pris une grosse claque. Je me rappelle, ils faisaient des trucs qui s'appelaient des stand-up. C'était un peu bizarre. Ils se mettaient debout pendant des réunions pendant 2-3 minutes, ils se synchronisaient et ils partaient faire autre chose. Et je me suis dit, tiens, ces mecs-là, ils sont venus faire des trucs un peu particuliers. Et il parlait des patterns du Goff à l'époque, donc il balançait les patterns du Goff.

3:11 Je sais qu'après la première semaine, je suis allé m'acheter le pattern du Goff, je suis allé regarder en me disant« merde, il y a quand même un truc que j'ai loupé». Et ces gars-là, c'était effectivement Vincent Massol et quelques autres. Et du coup, derrière, je suis rentré dans OSSGTP, là où on s'est vus nous tous les deux. Donc OSSGTP, c'est le... L'open source Get Together Paris, qui était un des groupes dans lequel on pouvait se retrouver pour discuter tech. Parce qu'à l'époque, il n'y avait pas tout ce qu'on a aujourd'hui. Tu sais, il y avait le... Comment ça s'appelait? Le Java User Group. Le club Java, qui était très professionnel et qu'on n'arrivait pas à se motiver à aller. Effectivement, je me souviens bien de l'intention de OSSGTP, qui ressemble pas mal à Tech.Rocks, c'est pour ça que je voulais qu'on en reparle un petit peu. C'est un besoin de se rencontrer entre pairs de gens qui essayent de comprendre comment marche le domaine de l'informatique, et là de l'open source à l'époque. Toi, tu finis chez Docker quelques années après et ça fait partie des étapes qui t'ont éduqué sur le sujet.

4:21 Comment tu as découvert un peu l'open source? Oui, l'open source, je l'en ai fait pas tellement parce que j'avais envie de faire plaisir aux gens. En donnant des trucs gratuitement ou en partageant ma passion. C'était honnêtement, moi, la première fois où j'ai fait un projet open source, c'était en me disant, ça doit être un peu rigolo de proposer du code et que d'autres regardent ce que tu fais, te critiquent, et que du coup, tu puisses peut-être écrire du code qui était mieux ou un outil qui était plus utile. L'idée, c'était... C'est de se dire, quand tu partages du code au sein d'une boîte dans ta mission, là où tu es, c'est sympa. Il y a 10, 20, 30, 50. 100, 200 personnes qui peuvent regarder. À partir du moment où tu travailles sur un projet open source, il y a tout de suite un facteur multiplicateur gigantesque sur tous ces trucs-là. Moi, c'était ça qui m'avait motivé. Ça, puis le fait que pour rentrer au CGTP à l'époque, il fallait aussi faire des projets open source. C'était aussi une de mes motivations. d'essayer de faire partie de ce groupe-là et d'échanger et de progresser en me disant, je ne sais pas à quoi ça me mène, mais j'ai envie de partager ce truc-là et de regarder.

5:22 Et c'est vrai que les conversations que j'avais avec les gars de CGTP à l'époque, on les retrouve tous, Guillaume Laforge, Vincent Massac que j'ai déjà cité, Alexis Mifine et plein d'autres, Didier Girard qui est là aussi. Oui, Didier Girard qui est à Tech.Rocks aussi. C'est vrai que le niveau des conversations, il était un petit peu différent. Il y avait toute une vision un peu plus long terme, une vision plus stratégique, un vrai partage d'expérience. Tout le monde était là pour partager. C'était super. D'ailleurs, c'était dans les locaux d'Octo à l'époque, je me rappelle, sur le champ de l'idée. Et donc, ouais, l'open source, c'est toujours rigolo, quoi. Tu donnes un truc gratuitement pour... Enfin, librement, pour... Pour faire de l'argent après, derrière, quelque part. En tout cas, Docker, c'est clairement ça, puisque l'engine, la CLA, tout ce que produit Docker, enfin, une grosse partie de ce que produit Docker a été open source, en tout cas, dans les premières années. À y réfléchir, pour moi, c'est un peu notre formation de tech leader qu'on a fait par ce biais, par des pairs. Quelles sont, toi, tes expériences autres pour grandir dans l'accompagnement d'équipe?

6:27 Parce que tu as dû accompagner des équipes. diverses expériences. Quoi nous raconter sur le sujet? Mon parcours à moi, c'était assez rigolo parce que pour comprendre le métier, on m'avait dit va faire du service. Donc au début, j'ai fait un peu de service. Puis je n'ai pas arrêté en fait tout le temps dans ma carrière de sauter de 3 ans dans du service, 4-5 ans sur un éditeur de soft. Et puis 2-3 ans, je fais du service. Et puis comme ça, il y a une espèce de boucle qui continue. Et c'est vrai que le service c'est sympa parce que tu vois plein de choses différentes, mais c'est vrai que c'est pas tout à fait la même chose que quand t'es en boîte qui fait un éditeur de soft. T'as pas les mêmes contraintes, t'as pas le même budget, t'as pas... Donc moi j'ai pas arrêté de faire ça et donc effectivement, moi j'ai atterri chez Vidal où j'ai géré une équipe de dev, enfin l'équipe de dev de Vidal, donc Vidal c'est le dictionnaire des médicaments mais version numérisée. Et c'est vrai que là, j'ai pu faire plein d'expériences d'organisation d'équipe où je fais du Scrum by the book complet pour voir où ça nous amenait.

7:32 On faisait des trucs qui s'appelaient, je me rappelle, on prenait des photos de nos boards et on les publiait sur Twitter, j'imagine, à l'époque. Et il y avait un truc qui avait marqué les gens, c'est qu'on avait marqué quelque chose sur un ticket qui s'appelait« Refactor Architecture». Alors les gens avaient rigolé en disant« Comment tu refactor ton architecture? »« Architecture», c'est le truc que je pense que ça bouge un peu moins quand même. Et donc à Vidal, ouais, pas mal d'années. À travailler sur des... Des refontes de soft assez intéressantes, avec aussi ce plaisir que tu as toujours en éditeur de logiciel, qui est quand tu vas chez ton médecin, tu vois, à l'époque, on distribuait ça sur des CD-ROM, pardon. Et donc, tu vas chez ton médecin et tu vois qu'il y a le CD qui traîne sur son bureau et tu fais, ah tiens, c'est cool, mon boulot sert à quelque chose, il est là. D'accord. Et en termes d'apprentissage de leader tech, donc tu avais cette notion d'expertise technologique, ce qu'on appellerait un peu le craftman maintenant, et le pilotage d'équipe.

8:33 En tant que tech leader, chez Vidal, tu as appris quoi? Chez Vidal, c'était plus la première vraie expérience de management un peu longue. Avant, j'étais plus, on va dire, un contributeur individuel, comme on dit aujourd'hui, dans des mots polissés, dans des boîtes américaines. Mais c'est vrai que la partie management d'équipe de dev, elle est super sympa. Moi, j'aimais beaucoup faire quelque chose dans lequel, et c'est ce qui est aujourd'hui, je pense, le terme d'engineering manager, que je retrouve beaucoup dans beaucoup d'organisations, où tu as un gros pied dans la tech et aussi la responsabilité de personne. C'est-à-dire que tu n'es pas juste un manager, tu n'es pas juste un contributeur individuel, tu fais les deux. Et en fait, le fait de faire les deux te permet d'être vraiment au clair et vraiment de comprendre comment les équipes fonctionnent ou comment les équipes que tu gères fonctionnent. Parce qu'à la fois, tu participes avec eux dans les travaux. Tu es pertinent dans les conversations que tu peux avoir avec eux, avec les gens.

9:35 Et en même temps, tu as quand même la responsabilité de les aider dans leur carrière. Et donc, d'avoir cette double casquette, elle est vachement importante pour rester… Quand on fait un métier aussi compliqué et qui évolue aussi vite que le nôtre, Moi, j'ai toujours trouvé que c'était hyper important d'avoir des managers qui étaient capables de coder aussi, sans que ce soit ridicule. Il faut que le gars soit compétent. Si je me rappelle bien, en tant que codeur, tu as poussé le bouchon un petit peu loin avec un compère qui s'appelle David Gageau. Tu peux nous raconter cette histoire de comment tu te retrouves à coder toute une journée dans une conférence telle que DevOps dans une salle? C'est là où on s'est rencontrés, surtout. C'est là où on a commencé à vraiment discuter, Dimitri, toi et moi, parce que je crois que tu faisais à peu près quelque chose de similaire de ton côté. Dans la partie DevOps, oui, sur 8 heures, dans la salle d'à côté. En fait, on a fait un truc qui s'appelle Code Story. En fait, on connaît un peu de manière particulière. Mon livre de chevet, c'est le bouquin d'XP de Ken Beck, avec Extreme Programming.

10:38 Je pense que c'est... C'est la base un peu de tout ce qu'on doit, devrait tous faire. Et donc notamment des cycles courts, des tests, des sprints d'une semaine. Oui, je sais, ça paraît dingo aujourd'hui. Et en fait, on voulait se marrer, essayer de montrer si on était, est-ce qu'on serait capable de démocratiser un peu ce qu'on fait dans XP, tout en prenant du, tout en s'amusant. Donc, on prenait des bouts de code qu'on avait écrits dans des stacks super modernes. On faisait du JS avec du Java à l'époque. À l'époque où JS a commencé à avoir, ça ne commençait plus à être un gros mot, et on passait une journée à coder en live avec des séances d'une heure ou 45 minutes, je ne me rappelle plus très bien, et on faisait du pair programming en partageant tout ce qu'on faisait, et donc les gens regardaient à la fois le procès, mais aussi ce qu'on codait, les stacks qu'on utilisait. Je me rappelle que les gens venaient nous poser des tonnes de questions sur les outils qu'on utilisait pour coder, nos layouts de clavier, nos raccourcis, chacune des petites bibliothèques qu'on utilisait à droite à gauche.

11:44 Et c'était plein d'échanges sympas. Et c'est vrai qu'on faisait ça côte à côte. Nous, on avait une salle où on passait la journée à coder comme ça, quand je racontais ça aux gens à côté de moi, ils étaient fous. Et toi, tu faisais ça avec les mercenaires du DevOps, je crois? Oui, c'est ça. On a fait un peu plus sur la présentation de tous les concepts DevOps. Mais là, ce qui était impressionnant sur ta session, c'était vraiment le live coding, pair programming, TDD, appliqué vraiment sur quelque chose de pas juste 10 minutes, le tutorial du TDD, mais c'était vraiment l'appliquer à une échelle réelle. Ça a dû te marquer en termes d'expérience, dans une conférence, de faire un live coding comme ça. Qu'est-ce que tu en retires une dizaine d'années après, j'imagine? C'est sûr que maintenant, quand je dois faire une démo ou un live coding, c'est plus facile. Une fois que tu as appris ça, parce qu'on a fait ça quand même 3-4 ans d'affilée, ou 3 ans peut-être, on est allé le faire aussi en Belgique, au grand DevOps, Papa France.

12:49 Java Police. Ouais, le feu Java Police. Et le fait d'avoir... Le fait, tu sais, c'est toujours pareil, là, quand tu... Quand tu as lu trois articles, bouquin, que tu as fait un peu de code dans ton coin, c'est bien, tu sais faire des choses, mais en fait, tu sais que quand tu es capable de l'expliquer aux gens et que les gens le comprennent, c'est là où tu as vraiment fait le tour du sujet. Et ça m'a amené à ça, en fait. Ça m'a amené à vraiment réfléchir à... Moi, j'allais aussi à des conférences de craft en Angleterre pour peaufiner tout ça et prendre des idées d'exercice et tout ça. Je ne sais plus où j'étais à l'époque, mais je prenais un petit train. J'allais passer une journée ou deux dans la banlieue de Londres, à Belchil Park. Et il y avait des confs un peu… On codait toute la journée sur des exercices divers et variés. Il doit rester des traces de ça encore aujourd'hui. C'était super intéressant pour voir. Parce que la communauté de Londres autour du craft, c'était un peu en Europe celle qui drive et tout.

13:51 Et donc, c'était aller rencontrer ces gars-là encore une fois. C'est dans le même esprit que au CGTP. Tu peux rencontrer les gars qui font l'industrie, discuter avec eux. Ça désacralise un peu le truc. Et puis, tu vois un petit peu en échangeant directement avec eux comment ils pensent et qu'est-ce que tu peux en retirer. C'est là, je pense, qu'on a des points communs sur la volonté d'avoir un réseau autour de nous, de connaître les personnes qui font le domaine. Je pense que Tech.Rocks est né aussi de cette idée-là, de mettre des personnes en relation. Tu as rencontré, donc tu es allé te former toi-même en Angleterre. Sur une intuition que c'est le domaine qui t'intéressait. Comment tu arrives à... Retrouver en Angleterre, quelle démarche tu peux conseiller à d'autres tech leads pour aller se former sur des sujets ? C'était quoi le déclencheur? Moi, c'était en fait, il y avait cette histoire d'XP toujours, de Craftman, et donc comment tu peux faire à la fois du code qui était essentiel, mais aussi de le faire de manière soutenable, bien testée.

14:54 Et quand même, quand tu parles de TDD, même encore aujourd'hui, il y a quand même la plupart des gens qui disent« Ouais, d'accord, mais moi, ça ne marche pas parce que…» Je suis dans le cas d'exception numéro 4012-1544. Et du coup, je m'étais dit, bon, alors attends, il y a quand même un truc bizarre là-dedans. Est-ce que finalement, ça marche vraiment ou pas? Et donc, à aller voir les gens qui le font pour vérifier cette hypothèse. Et en allant demander et en pairant avec ces gens-là, parce que finalement, les stick freemen et les gars qui ont écrit tous ces bouquins, ils étaient là-bas, tu les croises, tu discutes avec eux. C'est sûr que quand tu te pointes avec un clavier français, avec un laptop français, pour faire programme avec des anglais là-bas, tu passes un peu pour un mozo, mais bon, bref, c'était génial. Donc, accessible. Ces personnes-là étaient finalement accessibles et tu as creusé une piste pour aller les rencontrer. Oui. L'idée, c'est de... Pourquoi ne pas aller rencontrer directement les gens qui font l'industrie à partir du moment où ils sont dans une notion de partage?

15:59 Voilà, et de faire sa propre avis et de discuter avec eux. Moi, je n'en ai pas forcément retiré un grand network avec eux aujourd'hui. Mais en tout cas, j'ai pu voir comment ils enseignaient, leur manière d'approche. Moi, j'ai retiré une tonne de petits trucs et astuces sur comment tu perds, comment tu vends le pairing, comment tu fais des tests. Et puis même, c'est les exercices en tant que tels qui étaient proposés là-bas. Et puis, c'est intéressant dans le sens où ça t'obligeait à réfléchir à un point très particulier et à coder un peu différemment. Les acteurs du domaine. Donc, ça, c'est intéressant. C'est intéressant. Une autre aventure qui m'avait marqué quand on s'est croisés régulièrement, c'était ton approche pour le Xevia Studio. Ça m'intéresserait de comprendre un petit peu la genèse de ce que tu avais mis en place, surtout autour de l'organisation des équipes que vous aviez. Oui, Xavier, c'était une boîte, moi quand je suis rentré, on était 35-40, c'était une boîte de services, de conseils, qui était très marquée technologiquement, avec une vraie machine de guerre autour des blogs, pour se faire connaître, parce qu'à l'époque, il fallait faire sa place.

17:03 Dans l'industrie du service de l'époque, pour se démarquer, pour progresser, il fallait être un peu différent. Et c'est vrai qu'au bout de quelques années, au bout de deux ans, on faisait 100% de régie, donc on allait se promener dans des projets, on avait des approches novatrices dans plein de choses, mais moi j'avais envie d'essayer autre chose, et ce que je voyais c'était ces espèces de contraintes quand tu es en service, où tu es systématiquement sur un laptop tout vieux, avec un projet dans lequel tu ne peux pas toucher sur le processus projet en tant que tel, tu es forcément un parmi plusieurs, même si Xavier vendait parfois des équipes entières de... De consultants. Et donc là, on arrivait à peu près à faire quelque chose, mais on était toujours contraints par l'environnement que la société qui t'emploie t'impose. Donc en gros, on était vus comme ceux qui allaient régler un gros problème technique ou qui allaient régler un logiciel, mais on te filait des tonnes de contraintes du style« Oye, mais t'as arrêté derrière un firewall de taré» ou« De toute façon, ta machine, c'est forcément…» vieux Windows et on ne mettra pas à jour parce que X ou Y, ou tu as 2 Go de RAM parce que c'est comme ça.

18:06 Mais je m'étais dit, en fait, il faut casser ce truc-là et il faut... Un projet, ça se passe aussi quand tu maîtrises 100% de l'environnement. Et donc, on a monté un truc qui s'appelle le Xavier Studio où en fait, on faisait des projets, on va dire, de la façon, je vais te le dire, on faisait des forfaits. La vraie façon, l'esprit qui était derrière, c'était d'appliquer tout ce qu'on avait vu dans le craftman et tout ça, mais de l'impliquer dans des bureaux qui étaient les nôtres. Donc, au lieu de vendre une équipe qui était logée chez le client, on vendait une équipe qui était dans nos locaux. C'est le client qui venait régulièrement, bien sûr, si vous dites XP, la proximité avec le client, elle est quotidienne. Et donc, on a transposé ça dans l'autre sens. Donc, à l'époque, avec Luc Le Garder, il a fait le pari de me suivre et de monter des bureaux au boulevard Haussmann, où on a monté deux, trois bureaux complets, où on mettait des équipes qui faisaient des projets pour des clients. Et je crois que ça a beaucoup impacté les revenus que vous avez bien à un moment donné. Ça a bien marché.

19:07 Je ne sais plus combien était le pourcentage exactement. Mais plus de la moitié des revenus étaient faits sur les biens. Donc, c'était un succès. Métier et au niveau de l'organisation c'était quoi les quelques marqueurs que tu as eu parce que tu étais libre de l'organisation des équipes donc là en tant que leader tech tu as pu choisir ton organisation complètement et quels étaient Les marqueurs que tu as gardés à ce moment-là ? D'abord, c'était des petites équipes. C'était 4-5 personnes grand max. Tout le monde qui programme. Il y avait toute la proximité avec le client. On accueillait le client en permanence. On le voyait tout le temps. Et ce qui était rigolo, c'était en interne, parce qu'en fait, tu avais tous les ingénieurs qui étaient hyper intéressés par tout ça, parce qu'on faisait du craft à droite à gauche, mais ce truc-là, c'était le fait, enfin, ce Divas Studio, c'était la façon de le faire à la maison. Donc, un des problèmes qu'on avait, c'était de faire des rotations, parce qu'on avait... J'avais tous les ingénieurs qui étaient en service. Ils avaient tous envie de venir faire ça au moins une fois dans l'année, de venir participer au moins à un projet. Donc, il fallait organiser les trucs. Donc, il fallait prendre les gars qui étaient bons, qui avaient le bon état d'esprit, mais aussi être prêts à en tourner les choses.

20:12 Donc ça, ce n'était pas complètement… Ce n'était pas l'intercontra, c'était du coup, c'était les projets préférés. Oui, et puis de toute façon, il fallait aussi les vendre. On n'avait pas non plus au début, quand on commence, on avait peu de projets. Donc, c'était… Voilà, il fallait… Tu commences avec un projet, avec deux gars, et puis après, avec un projet avec trois, quatre, et puis à la fin, ça se démocratise. Il y a eu pas mal de choses faites aussi sur les applications mobiles, à un moment donné. Donc, c'était complexe à organiser. Il y a certains clients qui adhéraient complètement. C'était vraiment chouette. Il y en a qui ont dit, faites pareil, mais chez nous. Donc, on revenait dans l'autre. La boule s'inversait. Donc, on a essayé de rester quand même dans nos locaux dans la plupart du temps. C'était ça, le vrai esprit. Et du coup, on était libre de faire ce qu'on voulait. Il n'y a pas de problème. Je me rappelle, j'étais allé dans une mission une fois où le gars disait, il faut que mes murs soient blancs, il faut que ce soit absolument parfait, mes murs doivent être impeccables, nickel. Et moi, j'y arrivais, j'ai dit, ben non, on va mettre des post-it au mur, je suis désolé. Et les gars ont dit non, et ils ont fait venir un... Un petit chariot avec un tableau blanc sur roulette.

21:17 Et donc, c'est là où on avait le droit de mettre notre truc. Ça gâchait quand même le mur, je n'ai pas tout compris. Mais écoute, à la fin, on a mis l'opposé, c'était essentiel. Donc, de mémoire, il y avait une répartition des seniors et des juniors dans l'équipe qui était particulière. Vous aviez un peu des critères comme ça d'intégrer un junior pour trois seniors ou c'est une légende que j'ai gardée ? Oui, je pense que c'est une légende la vie. D'accord. Bon, dommage, elle m'a bien servi par la suite. C'est vrai que moi, là-dessus, en tout cas, j'ai un gros biais. C'est que... Moi, je pense qu'avant 10 ans d'expérience de code, on n'a pas complètement fait le tour du domaine encore. Ou alors, c'est moi qui suis loin à la détente, je ne sais pas. En tout cas, moi, c'est mon impression profonde et ça construit complètement la façon dont je fais du recrutement encore aujourd'hui. Quand j'ai commencé Docker en 2015, ou quand j'ai commencé à démarrer le bureau parisien de Docker, au bout de quelques mois, on s'est retrouvé à être que des gars qui avaient 10-15 ans de bouteille.

22:26 Avec personne qui était plus jeune. Et donc, c'est un problème, un vrai biais de recrutement compliqué. Il faut des équipes plus hétérogènes que ça. Et c'est difficile de sortir de ce module. Mais moi, j'ai toujours tendance à penser qu'effectivement, il faut rouler sa bosse, il faut être patient, il faut apprendre longtemps, il faut faire plein d'expériences différentes. Et ingénieur, c'est un vrai métier. Et on n'est pas obligé de faire du management et tout ça, obligatoirement. Et d'ailleurs, aujourd'hui, quand tu vois l'industrie, notamment si tu regardes... Ça se passe aux États-Unis avec des grosses boîtes comme Amazon, tous les GAFAM. Tu vois qu'il y a des vrais tracks de progression de carrière pour des gens qui restent contributeurs individuels toute leur vie. Parce qu'ils n'ont pas envie de faire du management, ils n'ont pas envie de s'occuper de gérer des gens, ils n'ont pas envie de faire ça. Et ce n'est pas pour ça qu'ils ne gagnent pas moins d'argent, ils n'ont pas moins de reconnaissance. Oui, c'est ça, c'est surtout la formation des juniors dans une équipe pleine de juniors.

23:28 Je ne vois pas comment c'est possible. Donc là, effectivement, d'avoir des juniors dans les équipes, c'est toujours important, mais de ne pas les laisser tout seuls se former entre eux. Donc, notre boulot de tech leader est d'accompagner, de proposer à ces juniors d'avoir accès à des seniors qui les aident, sans que ce soit forcément du management. Donc, moi, c'est un peu ça. Oui, c'est vrai que tu as raison là-dessus. Je pense qu'il faut toujours... C'est vrai que les projets n'ont pas les mêmes prix, parce qu'effectivement, avec l'expérience, on a plus de prétentions. Mais effectivement, je pense que les juniors, ils devraient être minoritaires dans la plupart des choses. Pour terminer un petit peu ce podcast, il y a une notion de projet, un succès ou un échec autour de ton expérience Docker, parce que Docker, c'est quand même assez iconique dans notre domaine. Tu te retrouves la tête de l'équipe tech de Docker. Qu'est-ce que tu pourrais nous raconter comme expérience?

24:31 qu'on ne connaît pas sur le sujet. Qu'on ne connaît pas, je ne sais pas. Mais c'est vrai que Docker, moi je suis arrivé en 2015, au moment où tout le monde s'était en train de monter assez fortement. Et moi, ça a été la progression de ma carrière où j'ai fait beaucoup plus de management qu'avant. En tout cas, pas dans les premières années, parce qu'en les premières années, on causait des trucs dans tous les sens, c'était assez sympa. J'ai fait les premières versions. Docker Desktop pour Windows. Alors, je n'avais jamais fait Windows avant, mais ça, c'était vraiment chouette. Non, mais ce qui était rigolo, c'était surtout l'expérience. Moi, je suis arrivé en me disant, voilà, c'est fantastique. Une boîte de 120 personnes à l'époque, quelques années après on était 350, je me suis dit, j'avais une espèce de passion aveugle pour les américains en me disant, mais ça va être, ils vont être incroyables, ça va trop cartonner, regarde, ils sont trop forts, ils vont être capables d'embaucher 200 gars en une année et ça va trop bien marcher, et ben non, ça fait un four comme partout ailleurs, quand tu progresses trop vite et que tu fais pas gaffe,

25:35 t'embauches des gens qui sont pas les bons et du coup quand tu crois trop vite sans avoir les bonnes valeurs à l'intérieur et sans faire attention tu te plantouilles un peu et ça c'était assez rigolo c'est un peu la magie qui se fane Mais après, Docker, c'est rigolo parce que tu... Je me rappelle que quand on codait, on avait beaucoup d'open source à Docker, surtout au début. Et tu ne pouvais pas émettre une pull request sur GitHub sans que tu aies trois gars qui viennent te dire« Ah, c'est fantastique, c'est génial! » Mais au point où, de toute façon, ils n'ont pas vraiment lu. C'est juste parce que tu as écrit un truc qui peut apparaître bien. Et tu en as forcément trois autres qui vont te dire« Ah oui, mais non, tu ne peux pas faire ça parce que…» Parce que si, parce que oui, parce que dans mon cas d'usage super petit, ça ne marchera pas et tu vas casser tout le projet au secours. Et ça, c'était rigolo parce que typiquement, moi, j'étais un grand fan de refactoring, de testing et tout ça. Et quand tu veux faire des... Le refactoring, c'est une source où tu as 300 000 acteurs qui regardent. Ça monte le niveau.

26:37 Il vaut mieux l'avoir fait en public pendant quelques heures. Oui, et puis surtout, ça t'apprend un truc, c'est que ce n'est pas le code le problème, c'est la communication autour de tout ça. C'est comment tu gères ta communauté de telle manière à arriver là où tu veux. Et ça, ça ne se fait pas par du code. Si tu balances ta pool request comme ça alors que les gens sont attachés au code, tu vas les fâcher. Ou au contraire, tu vas braquer le projet. Et donc, c'est toute la communication autour de ton projet open source qui est capitale pour que tu puisses amener la communauté là où toi aussi, tu as envie d'amener le projet. Donc, il faut être clair sur ta roadmap, il faut être clair sur tout ça. En tant que développeur, en tant que contributeur individuel, tu prends ta pull request et tu communiques autour? Oui, bien sûr. À Docker, aujourd'hui, il y a des gens qui font de la communauté, qui font quasiment que ça, qui gèrent la communauté, en tant que guillemets, c'est-à-dire qu'ils écoutent. La communauté aussi, elle te donne énormément de feedback sur la façon dont on se sert de ton outil. Donc, c'est hyper important. Ils vont capter des trucs que toi, tu ne vois pas, ou que tes équipes de dev ne voient pas, ou parfois, on est aussi un peu aveuglé par ce qu'on est en train de faire.

27:40 Donc, communiquer avec... Quand tu as un projet aussi gros que celui de Docker en open source, écouter la communauté, communiquer avec eux, ça se fait par plein de manières. Donc, à Docker, il y a un truc qui s'appelle les Docker Captains, qui sont des espèces de super utilisateurs. À qui on donne en preview les projets qu'on est en train de faire. Mais ça, c'est qu'une partie. Le vrai deal, il se passe sur GitHub avec les échanges autour des pull requests. Puis même, j'ai envie de dire, sur Twitter aussi, où les gens contribuent un peu comme ça. Mais j'ai envie de dire, la vraie difficulté chez Docker, la vraie truc qui m'a fait vraiment grandir, Ça a été ce qui s'est passé il y a quelques années quand Docker a shifté de position. On était dans une boîte où on vendait essentiellement un énorme logiciel à des grosses entreprises à coût de centaines de milliers de dollars ou de millions de dollars. Et on s'est séparé, donc toute une partie business, entreprise, avec des sites de vente classiques de 6 mois à 1 an.

28:43 Et on s'est séparé de ce business-là, à la fois d'un point de vue propriété intellectuelle, mais aussi des gens et des revenus qui étaient associés, bien sûr. Et on est remonté à un docker il y a un an et demi qui est complètement focalisé sur les développeurs et sur lequel on fait... Ce projet sur le projet open source et sur finalement un business de carte bleue. Tu vas sur le Docker Hub et tu nous donnes 7 dollars ou 5 dollars par mois. Et ça, c'était un vrai changement dans ma carrière parce que j'ai été responsable d'équipe d'Europe Engineering et là, je suis passé VP Engineering de l'ensemble. Et là, c'est un autre shift parce que quand tu commences à gérer à la fois des équipes françaises et anglaises et en même temps américaines, il y a un shift de Q. culture qui a à faire quand tu es un leader où tu es censé représenter les deux parties, les deux parties au sens, les deux cultures. Il faut toujours un peu jongler entre les uns et les autres. Les Américains me disent parfois que je fais mon français et les Français me disent que je suis trop américain.

29:45 Et ça, tu vois, dans une carrière, c'est assez structurant, c'est assez intéressant. De voir que finalement, il n'y a pas qu'un seul mode de fonctionnement qui tourne. Et quand tu es responsable de gens pour les amener à grandir dans une entreprise, il faut que tu sois capable de leur faire Présenter tout le monde, c'était un vrai challenge pour moi et c'est captivant. Donc une carrière vraiment riche, vous faites d'aller-retour de projet tech et de management. Tu codes encore un petit peu? Oui, presque plus. Oui, ils se moquent de moi. Je fais du JavaScript dans des Google Spreadsheets. Tout le monde se moque. Tu as été quand même fort contributeur au sein de Docker. Tu n'es pas arrivé parachuté par le haut. Non, non, j'ai le projet Docker Machine, il y a pas mal de projets, tout le code de Docker Desktop, on a beaucoup travaillé dessus, David Gajou était avec moi à l'époque, parce qu'après une histoire code son, on s'est retrouvé chez Docker, et c'est vrai qu'on a... On a beaucoup contribué là-bas. Mais aujourd'hui, quand tu es responsable, je gère aujourd'hui 40-45 personnes.

30:48 Il n'y a plus d'urgence. Il faut passer du temps à faire de la tech. Peut-être pour une prochaine aventure en tant que... Contributeurs individuels. Merci beaucoup Jean-Laurent pour ce temps passé à nous expliquer un peu ta vie professionnelle et chez Docker, c'était un plaisir. Et on se retrouve bientôt au Summit Tech.Rocks, j'imagine, où peut-être effectivement tu pourras nous faire venir des software craftmans anglais qu'on ne connaît pas. C'est peut-être ça la source d'inspiration que ça pourra nous apporter. Écoute, avec plaisir. Aujourd'hui, je suis vrai que mon réseau est plus aux États-Unis. On discute avec pas mal de figures là-bas. Pour Tech.Rocks, j'espère qu'on aura des belles surprises. Et puis sinon, merci beaucoup pour ce temps passé. Et puis, rappeler les choses qu'on a fait ensemble, c'était sympa. Merci beaucoup, Louis-Guy. À bientôt. Au revoir.