Une certaine vision du développement – Retranscription du Podcast avec Hugo Venturni, CTO chez Qwant

Nous vous proposons une retranscription complète du podcast avec Hugo Venturini, CTO de Qwant et ancien de chez Microsoft et Facebook. 

Voici la liste des sujets abordés :

  • Releases monde chez Microsoft (ownership par équipe) & Facebook (une seule code base)
  • Lead by example, ownership dans la culture
  • Pragmatisme dans la tech plutôt que de faire les choses by the book
  • Code review et TDD
  • Mentoring entre pair
  • Recrutement
  • Le mentoring
  • Être un faiseur/faiseuse (pour apprendre), être curieux, se poser des questions
  • La spécialisation
  • Fail & learn
  • Égo des développeurs
  • Octogone chez Qwant : Go x Rust
  • Évolution de l’écosystème Tech français

César (C)

« Hugo bonjour, merci d’avoir accepté de faire ce podcast. On s’est rencontré il y a quelques années, et je pense que plus simple, c’est peut-être que tu te présentes. 

 

Hugo Venturini (H)

Effectivement, on s’est croisés il y a plusieurs années. Je devais travailler à l’époque pour Microsoft. J’étais ingénieur, puis manager chez Microsoft. J’ai commencé par Xbox, puis je suis passé manageur d’une des équipes sur le store en ligne de Windows 10. 

C’est une sacrée aventure d’être embarqué sur la sortie de Windows 10 parce qu’évidemment, c’était pour la grande release de 27 juillet 2015. Parce que c’est le genre de projet sur lequel on fixe une deadline et on ne la bouge pas. Il faut s’arranger pour que ça rentre dans les clous et si possible en qualité... Parce que ce n‘est pas pour mon équipe qu’on allait dépassé la sortie mondiale. Ça, c’est clair.  

Donc, après cette expérience qui a duré cinq ans chez Microsoft, j‘ai intégré Facebook en tant qu’ingénieur. J’ai travaillé d’abord sur la géolocalisation. Ensuite, j’ai intégré l’équipe plateforme HHVM dont je suis devenu le manager. Pendant deux ans, on a réécrit tout le HHVM, toute la partie compilation et interprétation du PHP et du hack en Caml, pour une release en mars 2018.  

Et, en mars 2018, Facebook n’est pas tombé, c’est que ça a fonctionné (rires). Ça aussi, c’est une expérience assez incroyable. Une release Monde avec autant d’impact 

A ce moment-là, j‘ai monté une équipe de recherche en langage de programmation, à Paris, pour Facebook. On est passé de moi seul, à 6 personnes, puis redescendu à 4. Au bout de quelques mois, j’ai décidé de partir pour essayer de monter ma boite, qui a duré 1 an.  

Au bout d’un an, je n’ai pas réussi à faire décoller la chose telle que je le voulais, par rapport à des objectifs assez clairs que je m’étais fixé, et qui pour moi étaient la borne limite de ce qui était acceptable. J’ai donc décidé de rejoindre une équipe déjà formée. C’est là que Qwant m’a contacté, et j’ai été saisi par l’aventure, le défi que cela représentait. Qwant, début 2020, il y a des remous, des choses à faire, beaucoup de challenges à relever : l’infrastructure, la culture, en passant par la recherche et le développement. C’est une belle aventure. Je suis rentré chez Qwant en tant que CTO, et cela fait bientôt 1 an que j’y œuvre dans l’optique de créer ce moteur de recherche souverain, et européen. 

Avant ça donc, j’ai fait un Magister à l’Ecole Normale Supérieure de Lyon, et un doctorat. Puis, après la défense de ma thèse, j’ai rejoint Dassault Système où j’ai été ingénieur pendant 2 ans, et enseignant à l’Ecole Polytechnique en cycle ‘polytechnicien en informatique’. Ce fut une expérience assez intéressante, je pense que dans l’enseignement, il y a beaucoup à retirer et presque autant à apprendre qu’à enseigner.  

Après 2 ans chez Dassault, j’ai décidé de de partir pour rejoindre une startup qui était technologiquement incroyable, mais qui m’a mis dehors au bout d’un an pour raisons économiques. C’est là que j’ai rejoint Microsoft, et la boucle est bouclée. 

 

C – D’accord. Pour rebondir sur ce que tu disais. Souvent, on dit que le meilleur moyen d’apprendre c’est d’enseigner, donc je pense que tu as pu expérimenter ça ?  

 

H – Donc j’ai été enseignant à l’école Polytechnique, et à l’ Ensimag Grenoble pendant ma thèse. 

C – Ça me donne envie de te poser une question. Au tout début tu parlais, que ce soit chez Microsoft ou Facebook, de deadline sur des sujets de très grandes importances. Et pour autant, une absolue nécessité de maintenir une forme de qualité. Au-delà de ce challenge là, comment Est-ce que c’est quelque chose qui peut être réalisé de manière pérenne avec des équipes parfois dans des contextes internationaux très différents. Comment tu résous une problématique de ce type ? 

 

H – Il y a plusieurs angles qu’il faut aborder. Le premier si on peut, c’est le recrutement. Je pense que la qualité c’est un état d’esprit, c’est pas une question d’outils. J’ai vu des horreurs alors qu’on avait des outils incroyables dans certaines entreprises. Quand certains décident de ne pas les utiliser, ou de mal les utiliser, ou vraiment de se moquer du monde, c’est possible. Je te donne un exemple simple : j’ai vu une série de tests de couverture basée sur des points d’arrêts qui étaient à la ligne. Il y a des ingénieurs qui ont décidé d’avoir une couverture de 100% en écrivant tout leur code sur une seul ligne. Donc il avait le code à 100%, la qualité était là, et dans le dashboard des managers c’était absolument incroyable, “une super équipe”. 

Voilà, je pense que l’outil en fait peut répondre correctement que si on a l’état d’esprit par équipe. Ça c’est le point de départ. Maintenant, on choisi pas forcément tout de suite toujours, même pratiquement jamais réellement, toute son équipe. Et dans tous les cas faut composer avec ça, et ça s’insuffle d’abord par sa façon de faire, le fameux lead by example. Montrer, être exigent sur les codes reviews. Ne pas laisser passer, ne pas se dire tant pis je le ferais plus tard. Ce sont des habitudes à apprendre, c’est vraiment un quotidien. Je pense vraiment que la qualité c’est un état d’esprit et une façon de faire au quotidien. On ne peut pas se dire “on verra demain”. Ça ne marche pas. 

 

C – C’est hyper intéressant ce que tu dis parce que tu mêle à la fois la culture – donc tu parlais de ça tout à l’heure en disant que ça pouvait être des chantiers sur lesquels Qwant pouvait continuer de travailler.  Sur la partie recrutement, c’est en fait, pour toi, instaurer des normes au niveau des différentes équipes et faire en sorte que le lead by example soit utilisé. Je crois que ça avait été le challenge chez Microsoft, de se passer quelque part de chefs de projet pour qu’il y ait des Team lead et avoir vraiment cette identification par l’équipe, du fait de se dire que les décisions étaient prises ensemble, pour justement être un peu garant de manière collective de la qualité. 

 

H- Je pense que la qualité, il faut que l’équipe, il faut que les faiseurs, il faut que les gens qui aient les mains dedans le prenne à bras le corps et ai la formule qui leur convienne. Toutes les façons de faire ne conviennent pas à tout le monde et quelques unes avec lequel j’ai du mal à comprendre que ça puisse pas convenir du coup j’ai une tendance à les pousser un peu plus fort que d’autres. Je pense vraiment au code review par exemple. Mais sinon, la façon de procéder est vraiment propre à chaque équipe. 

Et, sur chaque projet, on va d’abord se mettre d’accord sur une façon de procéder pour que tout le monde soit d’accord et embrasse le projet. Si je ne suis pas, si un tech lead n’est pas là, si un senior n’est pas là, les autres savent quoi faire parce qu’ils étaient là, “on a entendu, on sait faire, pas de problèmes”.  Et surtout du coup, les autres ont confiance dans le fait que le process est respecté. 

 

C – D’accord, et justement autour de ces bonnes pratiques. Tu en cites une avec les codes review, quelles sont celles qui a tes yeux ont le plus d’importance aujourd’hui, si mettons que demain tu créé une équipe de 0, et eux ont besoin de recommandations sur ce qui serait les bonnes normes d’équipes à avoir. Quelles pourraient être les propositions que tu pourrais leur faire ?

 

H – Il y a plusieurs choses que j’ai constaté marcher. Pas toujours avec autant de succès que j’aurai espéré, mais en tout cas qui marchait pas mal. Par exemple, quand on a refait HHVM, la première version ne pouvait compiler que Echo & string sans rien dedans. J’ai mis ça en place, ensuite j’ai pris tous les éléments, créé toute une série de tests unitaires qui devaient passer par défaut ; Et j’ai créé un graff qui montrais que ça passait de nombreux échecs. Ensuite on a regardé la courbe converger au fur et à mesure qu’on implémentait les choses et les tests qui passaient. C’est plutôt du TDD comme approche.  

En unitaire, ce qui n’excluait pas d’autres types de tests qu’on avait autour. Celui-là était un peu le Dashboard principal d’observation. Ça a bien fonctionné. Au fur et à mesure on a raffiné nos tests qu’on avait peut-être un peu oublié de côté. C’est une façon de faire que j’ai vu fonctionner correctement 

Un truc qui aide c’est d’avoir les mêmes outils en local. Je pense à un LINKER, selon le langage qu’on utilise. Être d’accord si on met “espace” ou “tabulation”, ça parait idiot et détaillé, mais en fait ça fait une vraie différence quand on commence à pouvoir et vouloir forcer des choses dans la chaine de compilation Quand on fait l’intégration, rajouter des éléments de validation. Il faut être sûr que la lecture du code puisse être efficace. A force de lire du code on finit par obtenir des réflexes de lecture, et c’est pour ça qu’on lit très vite du code que l’on connait ou qui est formaté tel qu’on sait l’écrire nous-même. Et si tout le monde l’écrit de la même manière ou dans des zones très proches, ça permet d’aller vite quand on lit le code des autres parce qu’on sait ou aller regarder, on sait comment sont les imports s’il y en a, les names specs comment elles sont déclarées, le naming, les conventions. C’est tout un travail de convergence dans les méthodes de programmation. C’est une deuxième façon de faire. Un deuxième truc que j’ai vu fonctionner. 

 

C – Super intéressant, tu parlais à la fois de normes dans l’équipe, en disant que chacun pourrait créer un roman avec sa manière de faire. Là dans une équipe, les gens doivent en tout cas voir les mêmes préceptes sur la manière dont ils vont pouvoir écrire les mêmes spécificités. Tu parlais aussi du TTD, pour ceux qui nous lisentj’imagine qu’ils savent que c’est du Test Driven Development

Beaucoup de choses sont dites à propos de cette approche, beaucoup décoles : les Mochistes, tous ceux qui vont se référer à Ken Beck, ceux qui vont se référer à Sandro Mancuso… Aujourd’hui, quel est ton point de vue par rapport à ça ? Est-ce que finalement beaucoup de devse rendent compte que c’est une approche qui semble un peu  panacée mais en même temps qui n’est pas forcément accessible, qui demande énormément de préceptes en amont, de respect de bonnes pratiques, et qui est plutôt une finalité. Comment est-ce que toi tu vois ça, et Est-ce que tu as eu des contre-exemple dans certaines des équipes dans lesquelles tu as pu évoluer ? Tu me prenais l’exemple d’un code ridiculement couvert avec une seule ligne de code. Quel est un peu ton mindset par rapport à cette approche ? 

 

H  – J’ai une culture assez pauvre de la littérature des méthodes à utiliser. Tu cites Ken Beck, les méthodes agiles. Par exemple, l’implémentation du Scrum au sens théorique de la chose, je ne crois pas l’avoir déjà vu quelque part, ni que quelqu’un l’ai fait. PAr contre, ce qui est intéressant c’est d’avoir assez de cilture pour pouvoir en extraire les éléments qui fonctionnent bien et bien saisir les éléments qui marchent bien que s’ils ne sont joints à d’autres. 

 

C – Pas By the Book mais au contraire, plutôt par l’acculturation 

 

H – Par l’appropriation 

 

C – Exactement 

 

H – Il faut s’approprier le process. J’ai fait une forme de TDD, que j’ai vu fonctionner, et à l’inverse, dans une autre boîte, il y avait un nombre ridicule de tests qui avaient été implémentés, qui se passaient les uns sur les autres, qui étaient en redondance, en triple, en quadruple… Qui rendaient très difficile la modification du reste du code pour une raison simple – alors on pourrait se dire ce n’est pas grave, il suffit de tout virer – mais non. Il y avait une culture de l’ownership qui faisait que certains tests tu pouvais les modifier, d’autres il fallait demander. Donc, d’un coup lorsque tu poussais ton code, il était – par effet de bord -testé et possédé par d’autres équipes. On se retrouvait donc à leur demander de modifier leurs tests ; sauf qu’eux avait l’effet de bord de modifier leur test qui créait des chaînes de dépendancetrès longues. C’est l’exemple tupe ou deux bonnes idées ne fonctionnent pas. C’est à dire que l’ownership maximise la fierté ; et quand on maximise la fierté on minimise les problématiques sur le code. Et quand on fait du TDD, du coup c’est très bien, mais celui pas si bien fait avec de l’ownership un peu fort, ça paralyse les équipes. Pas de bol. 

C – Est-ce que  l’ownership finalement ce n’est pas une qualité qui est impropre au développement ? Est-ce qu’elle n’est pas mal placée dans certains cadres ? N’y avait-il pas une contradiction entre l’approche autour du TDD et le fait de ne pas pouvoir les autres changer quelque chose ? C’est un petit peu ce qui est dit par Richard Sheridan lorsqu’il parle d’Xtrem Programming, en disant qu’on fait toujours du code pour les autres, et que si on fait quelque chose qui n’est pas compréhensible ou modifiable par les autres, ont créé déjà de la dette technique. 

 

H – J’ai vu deux façons de faire, au moins très séparées. La première c’était  à des abus de bonnes pratiques. Parce que l’on peut très bien abuser des bonnes pratiques. Mais, je vais comparer deux entreprises plus larges qui sont Microsoft et Facebook. Chez Microsoft y’a un ownership par équipe du code, et c’est assez bien séparé ce qui fait qu’il n’y a pas le problème d’entrelacement de tests avec le code des autres. Ça ce n’est pas si grave. Et ce qui permet de se sentir autonome. Ça a un effet de bord désagréable qui est que si ce sur quoi on travaille n’est pas dans la priorité des gens dont ont dépend, et bien ça veut dire que les demandes que l’on peut avoir sont relayées aux calandres grecques. Et ça a une tendance à encourager les devs un peu pressés à By Passer ces limitations et donc quelques verrues apparaissent à droite à gauche. Ce qui encore une fois n’est pas si grave que ça. 

A l’inverse, chez Facebook, il y avait une seule code base, en mono-repository, avec 1 million de fichiers de Hack. Quand j’en suis parti, il en restait peut-être 9% de PHP, et ça convergeait en descendant le PHP.  Et là par contre, 0 ownership, on était possesseur de la feature mais pas du code. Quand il y a un truc à coder, on ouvre le code, tout le monde à accès à tout, et c’est parti on y va. Il fallait être sacrément agile et sacrément flexible quand on voyait du code passer dans nos fichiers. Quelqu’un va rajoute run truc, une ligne, un patch, un “if”… Donc on regardait qui avait modifié le fichier et on demandait à cette personne de revoir le code, du moins on lui envoyait 

Il y avait également la culture du on a mieux fait de demander pardon que de demander la permission”

Du coup, un code review était envoyée : 1 jours, 2 jours… pas de nouvelles, il avait qu’à lire le code et s’il n’est pas content je m’excuserai et je pourrai le justifier. Ça rend une entreprise, qui bougeait vraiment très vite, moi j’ai trouvé ça formidable en interne. C’est vraiment la culture interne qui m’a le plus influencé aujourd’hui. Celle dont je retire le plus de chose. En revanche, ça demande aussi des devs qu’ils soient très flexibles par rapport à ce qui peut se passer dans la ligne de code et être capable d’aller mettre les mains n’importe  et de se balader dans des choses qu’ils n’ont pas écrite avec un nombre incroyable de livre. 

 

C – Absolument ! C’est intéressant de voir que les cultures et l’approche par rapport à ça est très différent d’une boite à l’autre. Est-ce que tu le lis au fait de la qualité intrinsèques des devs de Facebook qui finalement peuvent s’autoriser à avoir une culture qui fonctionne comme telle ? J’imagine que dans beaucoup d’autres sociétés où la rigueur, le niveau d’expertise, n’est pas tout à fait le même. Pour le coup ce qui fonctionne très bien chez Facebook n’aurait peut-être pas tendance à fonctionner, à produire les mêmes résultats, ailleurs ? Tu dis que ça t’a influencé, mais de quelle manière ? 

 

H – D’abord, il ne faut pas se tromper. Pour créer une culture, c’est plus facile de partir de 0 et de prendre les bonnes personnes qui ont directement le bon état d’esprit en faisant une sélection très claire au recrutement. C’est plus facile à faire que de prendre une équipe et dire ‘maintenant on va faire les choses complètement différemment, vous allez voir ça va être formidable’ pour es convaincre un par un. La transition, le changement d’équipe, de culture, est un process très long. Même si tout le monde est d’accord, on est tous lent à changer nos vieilles habitudes ancrées. Ça peut être difficile et donc, du coup, ça peut être une question d’équipe. A trois c’est facile d’être super flexible et de ne pas avoir d’ownership ; la Facebook je parle d’équipes bien plus grosses que ça. Nous étions plusieurs centaines… Et malgré ça, ça marchait assez bien. Ça ne convient pas à tout le monde c’est vrai, et il faut l’entendre. C’est pour ça qu’on voit des gens partir de Facebook et rejoindre Microsoft et réciproquement, sans compter les autres GAFA qui ont des cultures encore différentes. J’ai envie d’encourager n’importe qui à ne pas négliger la culture que vous allez rejoindre. Pendant vos entretiens, vous sélectionnez aussi une entreprise dans laquelle vous allez donner du temps de cerveau de l’énergie, et que la culture que vous allez rejoindre doit vous convenir. 

 

C – De toute façon on rejoint une boîte pour le challenge technique, et on y reste pour la culture ? 

 

H – Et on part à cause du management. Et je ne me leurre pas quand quelqu’un part et dit “non mais ce n’est pas toi..”, il y a un peu de moi quand même. Je le prends et j’essaye de comprendre pourquoi. Du moins quand je suis manager. 

Tu parlais des différences finalement entre Facebook, Microsoft ; et des pratiques agiles en disant ‘effectivement il ne faut pas être By the Book et puis être pragmatique, s’adapter aux différents contextes et à la manière de faire. Et c’est ce qui nous rend agiles, qui est surement un mot galvaudé et employé par le métier. Ça avait été une méthode du manifeste agile inventé par les développeurs initialement sur la manière dont une équipe peut aider à faire monter en compétences à travers d’autres pratiques comme le pair programming, Est-ce que c’est quelque chose que tu as encouragé ? Au-delà du fait de pouvoir faire des revues de codes, comment est-ce que ça a été implanté dans les équipes ou tu as été ? Quel regard tu portes là-dessus ? 

 

H – Je suis un fervent ambassadeur du mentoring. Du mentoring entre pair. C’est à dire que les seniors vont aider les plus juniors et les très seniors les seniors, et même les seniors entre eux puisque nous ne sommes pas tous seniors de la même manière avec les mêmes forces et faiblesses. Ça peut être du One shot, ça peut être sur la longueur, je suis très fan de faire des pairs, des duos, dans les entreprises au travers des équipes. C’est à dire trouvé un ingénieur fort du côté du front par exemple, et qui va faire du coaching près du Back. Alors ils n’ont pas les mêmes techniques mais l’état d’esprit de création d’un logiciel reste proche. La gestion de sa carrière aussi ! Ne pas oublier que nous ne sommes pas là que pour écrire du code mais aussi porter des valeurs, créé des produits, répondre à des demandes. On à l’immense chance d’être dans un domaine, pour ceux qui sont dans la Tech, qui est porteur, qui peut payer ! On peut être au cœur de beaucoup de changements, de beaucoup de ‘révolutions’. Il y a une certaine cassure d’habitudes auprès des gens. Il ne faut pas se leurrer, tout le monde n’a pas cette chance dans son corps de métier, il faut en profiter. Ça veut dire aussi qu’il faut choisir l’endroit où l’on va travailler. 

 

C – Hyper intéressant ! Ça me fait poser une autre question, au-delà de ton background, pour revenir un petit peu sur ce que tu avais fait au début et à l’enseignement. Quels conseils, toi qui a pu travailler avec des dévs français et internationaux, tu donnerais à un jeune développeur.se pour finalement monter le plus possible en compétences ? Pour quelqu’un qui est vraiment avide d’expertise. 

H – Il faut faire des choses. Il faut être une faiseuse, un faiseur. ll faut mettre les mains dedans, il faut récupérer le code, le compiler, le faire sauter, le modifier. Je vais utiliser des mots qui ont là aussi été récupérer et montés sous formes de “religion” ou de “dogme”, de “mouvance”. C’est l’artisanat, c’est du Lego c’est du jeu, c’est de la brique, c’est des puzzles, du Rubik Cube. Appelez ça comme vous voulez mais l’idée c’est d’emboiter des choses de différentes tailles. On peut prendre des gros morceaux comme des gros frameworks, faire de l’intégration. On peut aussi descendre très bas au niveau de la data, faire des algorithmes absolument fous. Peu importe on est en train d’emboiter des choses basées sur des briques qui nous sont fournies. On a le droit de sortir de ces briques là et de penser différemment. Le vrai truc c’est d’être curieux, poser des questions. L’autre chose c’est de ne jamais oublier que c’est en s’interrogeant et en interrogeant que l’on devient meilleur. Essayer de mettre le plus tôt possible dans sa carrière son égo de côté. Au début on a tous un égo assez fort, voire de l’orgueil. Je vois toujours ça comme un signe de maturité lorsque les gens arrêtent de défendre une techno et commence à défendre une intention, un produit qu’il va faire au-delà de la techno usitée.  

Moi aussi j’ai mes coups de cœur, mais ce n’est pas pour autant que c’est mon premier choix si ça ne répond pas exactement à ce que c’est censé faire. J’ai envie de donner comme conseil : faites des choses, soyez curieux, devenez bons au moins dans un domaine. Ne restez pas non plus en surface trop longtemps. Allez jusqu’au bout de vos projets, intéressez-vous aux projets Open-Source, allez y contribuer, poser des questions. Aller à des meetups 

Par exemple, je connais un senior, un directeur, chez Oracle, qui propose des 30mn et 1h de mentoring à qui veut. Allez le voir ! Vous ne le connaissez pas, vous êtes loin, ça n’a rien à voir avec ce que vous faites. Peu importe, ne loupez pas une occasion d’avoir un regard neuf sur votre façon de voir votre carrière et vos envies. 

 

C – Est-ce que tu as justement des gens qui ont été soient des mentors, soit des inspirations pour toi ? Des personnes qui t’ont donné cette curiosité, ce goût du fait de faire, du fait d’apprendre par toi-même, et d’avoir in fine cette envie de partager ? 

 

H – Oui. Il y a un groupe d’ingénieurs dans une entreprise pour laquelle j’ai bossé qui s’appelait ML State (maintenant fermée). Ce groupe avait une approche des choses que j’ai trouvé être révélatrice pour moi. Cet aspect de “faire”, de mettre les mains dedans, d’aller chercher, et surtout cet aspect d’oser se tromper et de dire ‘ce n’est pas grave, je vais refaire, ou alors j’ai appris et je continue à avancer’. L’important c’est de tenir compte de l’apprentissage en sortant du jugement. Pour élargir cette question et revenir à ce que tu me demandais par rapport aux devs français ; ça commence à changer mais j’ai encore cette sensation qu’en France on reste dans un esprit dans lequel si à 18 ans on n’a pas intégré la bonne prépa, et à 20 ans la bonne école, c’est un peu tard pour être bon, ou pour faire ce qu’il faut. J’ai vu des gens arriver ils avaient 35, 40 ans et sur leur Cv ils commençaient par nous dire quelle école ils avaient fait. Je trouve ça un peu triste de commencer par ce qu’on a fait il y a 20 ans et pas ce qu’on a fait la semaine dernière. On devrait être passionné de ce que l’on est en train de faire, on a le droit de se re-former, de faire des choses.  

Les gens qui ont pu m’inspirer, il y a aussi l’un de mes encadrants de doctorat qui était très humain chez Apple. Un développeur IN-CRO-YABLE, brillant. Quand on code à côté de lui on a l’impression d’être très mauvais, jusqu’au jour où l’on rencontre le reste du monde et qu’on se dit “ah, en fait c’est vraiment lui qui est très bon”. Et il y a plein de choses, plein de très bons conseils. C’était quelqu’un qui n’hésitait pas à ouvrir son éditeur et écrire un bout de code, essayer des choses. 

Il y a eu l’un de mes managers chez Microsoft qui est quelqu’un qui m’a fait énormément confiance. Je me suis rendu compte que j’étais complément de ce que lui apportait à son propre manager. Je me suis rendu compte que la confiance changeait tout par rapport à l’envie que l’on peut avoir. J’en avais des notions avant, et d’un coup je l’ai vécu. J’ai vécu cette confiance et ça m’a donné envie de faire confiance à tous les gens pour essayer de voir un peu ce que je pouvais en tirer quand je suis devenu leur manager derrière. C’était très inspirant. On sort du code et de la façon de faire mais on parle du fait d’avoir confiance en son équipe, en son manager, et répondre positivement à la confiance que l’on peut vous accorder pour l’entretenir. 

 

C – Ce que tu dis est très vrai, et j’en ai un exemple très récent puisque j’ai échangé avec un développeur assez junior mais qui a beaucoup de potentiel et qui expliquait qu’il a eu un déclic au moment d’un stage à Barcelone. Un dév plus expérimenté l’a pris sous son aile ou l s’est intéressé aux patterns, à l’architecture, à la qualité de code. Ça a été un déclencheur chez lui de s’intéresser à beaucoup plus de choses. Je rebondis sur ce que tu disais par rapport à l’éducation. Effectivement, je ne sais pas si toi tu le vois, j’imagine que oui, mais beaucoup de choses changent notamment au travers des différentes écoles.  

Je prends l’exemple de 42 qui est dans cette notion méthodologie de “pair” par “projet’ où il y a beaucoup de bas niveau qui est fait et correspond au “latin” par rapport au “français” et qui permet d’intégrer des langages plus simplement par la suite. C’est vraiment dans cette dynamique de dire “on va s’d’adresser à des gens qui n’ont pas forcément un background académique super conventionnel” (voir level de 42). Cette culture là et ce schéma-là de 42 qui a formidablement fonctionné et qui maintenant est en train de s’implanter dans pas mal de pays, quel regard tu portes sur ça et sur la créativité que ça peut amener par rapport à des développeurs qui parfois sont un peu formés dans un même moule. Là  on va avoir des gens avec background très différents et pour autant pourront apporter des choses pertinentes. 

 

H – J’ai un regard positif sur cette façon différente d’aborder. Je pense que ça apporte à notre écosystème. Je parle en frontières techs. C’est vachement positif d’avoir des gens qui pensent différemment, la diversité c’est enrichissant. Tout à l’heure je te disais que je trouvais ça dommage quand on se présentait par son école d’il y a 20 ans. Ce n’est pas grave en soi, c’est juste un peu symptomatique. J’aime bien dire que lorsque je reçois un CV je regarde les dernières années, je remonte jusqu’à 5 ans si c’est possible, et sur ces 5 dernières années je regarde ce qui a été fait.  

Je vais m’interroger de savoir si la personne a le bon état d’esprit. Les cultures sont différentes, je ne recrute pas les mêmes personnes dans les différentes entreprises ou j’ai pu travailler. C’est une très bonne chose c’est école là. Les écoles n’ont pas vocation à être toutes les mêmes. Il y a donc maintenant un groupe de personnes qui ont trouvé leur manière d’avancer grâce à ces écoles qui n’existaient pas avant. 

 

C – C’est hyper intéressant quand tu parles de ça. Du coup, toi, les profils que tu peux voir, qu’est-ce que tu vas regarder ? J’imagine que tes équipes les tests évidemment techniquement. Sur quels détails tu vas être toi plus attentif au regard de ce que tu essayes de construire à l’heure actuelle. 

 

H – La culture ! Je pense qu’il y a des éléments de tech, mais quand on n’a pas le bon état d’esprit c’est très difficile à changer, à faire évoluer. De mon côté, je vais faire attention à des éléments qui vont être d’abord l’humilité l quand on s’est trompé on s’est trompé. Je pose toujours ‘”parle-moi d’un projet que tu as salement gaufré. Et toi, pas l’équipe, toi ?” Quand est-ce qu’a un moment donné tu as vraiment merdé ?”. Ok, “Quelles leçons t’en a tiré ? Tu as eu l’occasion d’appliquer cette leçon plus tard ?”  

Une fois j’avais croisé un ingénieur, le mec 10 ans d’exp. Je lui pose la question, et il me répond : ‘je ne sais pas, il n’y a rien qui me vient. 
– Ah tu ne t’es jamais trompé ?” 
Non je ne crois pas….  

Ça va être compliqué… Je pense qu’un mec qui code depuis 10 ans il a forcément fait des bourdes. Je ne pense pas qu’il y ait des gens qui codent sans bugs. C’est impossible, ou du moins ça veut dire qu’au bout de 10 ans de code ça manque d’envie d’aventure de son côté. 

Le deuxième point important, plus technique, c’est que je vais faire attention à la compréhension de certains fondamentaux au-delà des langages que l’on peut maitriser. Le fait de maitriser un langage est une très bonne chose, ça veut dire que la personne s’est intéressée. Mais je vais surement poser des questions derrières : est-ce que cette personne s’est intéressée aux raisons pour lesquelles ce langage propose telle mécanique, telle option, pourquoi, comment s’est implémenté, qu’est-ce que ça veut dire, qu’est-ce que ça induit comme mode de pensée, etc. Ça m’intéresse de savoir si les gens se sont posés des questions au-delà des outils.

C – Ou c’est qu’il n’a pas essayé ce qui pose un autre type de problème ? 

 

H – Voilà ça en fait partie. Par ex si quelqu’un utilise des reverses à tout va dans son langage de liste, bah je lui demande quelle est la complexité, qu’est ce ça implique. Il m’est arrivé d’avoir des supers bonnes surprises et des gens qui ne comprenaient pas ce qu’ils écrivaient. Ils faisaient tomber en marche des choses, mais si je leur montrais les problèmes, ils disaient “Ah, ouais alors ce qu’on peut faire c’est…” et là il patch… AOUTCH ! Je préférerais que tu comprennes et que tu écrives juste. Voilà, ce genre de chose là. Le fait de faire on est censé du coup en tirer des leçons. On peut très bien faire toujours en empilant des éléments de code, alors que ce n’est pas la bonne façon de faire non plus. Quand tout à l’heure je disais qu’il faut trouver des gens qui ‘font’. 

 

C – Oui, puis surtout de se poser les questions et de ne pas réduire tout ce que l’on peut faire. Si tu viens de l’environnement .NET par exemple, beaucoup utilisent ReSharper, sur une utilisation qui nous permettrais d’oublier finalement les fondamentaux, les bonnes façons de faire.  

 

H – Oui, faut se demander pourquoi est-ce que ReSharper est bien, quels sont les bons éléments. Mais, encore une fois je ne demande pas à ce que quelqu’un soit absolument impeccable. Encore une fois : humilité. Quelqu’un qui me dit “je ne sais pas”, ça m’intéresse ! Si des fois j’ai la réponse, je lui explique, et donc ça le motive et il évoque un autre truc. La seule chose que tu peux te dire c’est “il intègre au fur et à mesure, il fait les liens”, et ça c’est super intéressant. C’est quelqu’un qui va vachement enrichir en fait les débats. 

 

C – Toi tu continues à progresser aujourd’hui ? Que ce soit humainement, ou techniquement. 

 

H – Est-ce que je progresse ? En voilà une bonne question. Alors, les choses que j’essaye de faire :  

  • D’abord c’est poser des questions. Il m’arrive régulièrement de m’incruster dans des dailys ou dans des meetings des différentes équipes avec lesquelles je travaille. De tendre une oreille, écouter et poser des questions. Simplement essayer de comprendre un peu. C’est un point important pour essayer de voir un peu où l’on va, si les bons ingrédients sont mis.  
  • Je me rends un maximum disponible pour les gens qui me posent des questions, qui ont besoin de brasser avec moi certaines idées. Ça permet aussi d’essayer de mieux comprendre comment fonctionnent les individus. 
  • J’essaye de passer un temps non-négligeable à écouter les gens pour essayer d’attraper leurs personnalités, la chose qui les motive. Quelle est leur drogue ? Qu’est-ce qui fait que ça les rend joyeux ? Faut que je trouve le bouton sur lequel appuyer qui rend les gens heureux et j’appuie au maximum dessus.  

 

C – Tu penses que c’est cette écoute qui te permet d’avoir ue compréhension et de t’intéresser au fond des choses 

 

H – A une partie du fond des choses. Je pense qu’une équipe c’est avant tout un ensemble d’humains. On peut avoir la meilleure des idées, si on pas le bon casting et pas la bonne équipe, on arrivera difficilement quelque part. Il y a plein de métaphores sportives qu’on peut faire à ce sujet, je vous laisse choisir la vôtre 😉 Avec le mauvais casting, et même avec les individus qui sont les meilleurs du monde dans leur domaine, il faut avant tout s’intéresser aux humains et les souder entre eux pour réussir quelques choses. Ça veut dire passer du temps à les écouter, à essayer de brasser avec eux LEURS idées et pas forcément les miennes. 

Il y a un truc que je fais aussi, c’est que je vais lire des blogs. Je m’interroge, je discute, je code. Il m’arrive encore de faire des tests. Récemment on avait une discussion Go ou Rust en interne. Je me suis amusé à faire le même bout de test en Caml, et j’ai fini bon dernier du concours… Par contre je sais maintenant faire du Gofaire du Rust. 

 

C – Qui a gagné ? 

 

H – C’est toujours difficile à dire, parce que quand le bout de truc qu’on a fait nous a amené à choisir Rust derrière, – c’’était cibler ce qu’on faisait ça ne veut pas dire que c’est la bonne techno pour tout le monde – ça m’a amené à m’interroger ce qu’était Rust, ce que ça faisait, pourquoi, comment, etc. J’ai fait ça un peu avec Go, puis ce qu’on a fait c’est qu’on a créé un meeting qu’on a appelé l’Octogone.  

Plusieurs ingénieurs sont venus, on devait être une dizaine. Toute personne qui venait devait prendre la parole et venir contribuer à enfoncer ou sauver une des technos qui était exposé. Il pouvait introduire une nouvelle techno aussi. C’est ce qui est arrivé d’ailleurs 5 mn avant la fin, quelqu’un a fait “et au fait et ça…”, et on l’a bien remercié. Ça ne nous a pas sauvé mais c’était intéressant puisque ça oblige à brasser des idées, à débattre. Pas d’égo, mais des débats très techniques. Si on ne sait pas on ne sait pas. C’est une autre façon aussi de continuer à progresser. Encore une fois c’est d’aller plus loin, rencontre des gens et s’interroger.  

Je passe un temps non négligeable sur Twitter à aller lire plein de choses hyper intéressantes. Je suis plusieurs personnes et régulièrement je refais mon fil aussi de bloggeur, de twittos, de contributeurs, de spécialistes techs. C’est aussi une autre façon je pense de progresser. Je suis sorti des Moochs et des formations depuis bien longtemps, je suis en train de me demander si je ne vais pas avoir besoin prochainement d’y retourner. Si je ne vais pas me faire former sur un truc ou un autre, histoire encore une fois de changer ma façon d’apprendre pour voir si je ne suis pas en train de passer à côté de l’angle mort. En changeant de véhicule, voir quel était mon angle mort du véhicule précédent : où ai-je de vrais gros défauts ? Puisque tout le monde en a. 

 

C – Tu parlais de ces octogones qui sont plutôt des moments des talks ou chacun peut partager des technologies qui maitrise ou il y a une approche pratique ou sur un kata qui peut être fait en commun on va venir challenger quel type de techno est la plus utile ? Du coup, est-ce qu’il y a une mise en pratique ou de vrais essais qui sont faits ? Des pokes, des katas, ou est-ce que finalement c’est plutôt autour du fait de s’intéresser à de nouvelles technos ? 

 

H – A chaque fois pour l’instant, le but c’était de trancher et de prendre une décision. C’est à dire qu’on est en train de bloquer 10 ingénieurs dans une pièce, le but c’est que ça avance et que l’on puisse être pragmatique.  

On ne va pas s’amuser à faire Kubernets VS Javascript, ça n’aurait pas de sens. Ce qu’on a pu faire c’était Go VS Rust, SOLD VS SENSIBLE. C’était plein de choses qui étaient presque pareil, ou du moins il y a moyen avec un chausse-pied de faire rentrer l’un dans l’autre. On veut une techno qui répond pour l’instant, on verra pour la suite. Si tout le monde s’y met, le partage de connaissance fait avancer rapidement. Du coup, prévenir à l’avance quand aura lieu cette rencontre pour que quand elle est lieu, les gens ont pu se préparer. La plupart d’ailleurs ont “fait leurs devoirs” et on a tous brassé un peu de notre côté, regarder des tutos, des blogs., discuter avec des potes de la tech. C’est hyper enrichissant. 

C – Donc c’est vraiment dans le cadre d’arbitrage dans le choix de techno, de Framework, pour définir comment vous avancer sur le projet. Quel regard tu portes sur l’évolution d’écosystème tech en France ? On parle beaucoup – et tant mieux – avec Next40, Qwant, une boîte entièrement partie prenante de cet écosystème. Finalement, quel est ton regard toi qui a bossé dans les grosses GAFA américaine puis aujourd’hui chez Qwant, sur l’évolution de cet écosystème ? 

 

H – Le regard que je porte sur l’écosystème, il est avant tout technologique. Je pense qu’on a les bons acteurs, le bon casting. On a des supers ingénieurs, de supers PO, PM, des gens hyper créatifs, de supers formations. On a plein de gens dans les boîtes où j’ai pu travailler à des postes clés. Il y avait des français pas forcément issus des grandes écoles comme on les connait, qui travaillait au sin de nos équipes. Des gens absolument incroyables, des autodidactes complètement fous mais qui parlaient de la façon dont ils avaient abordé les choses en France. Je pense qu’on a ce qu’il faut sur l’angle tech et produit pour y aller. D’un point de vue marché, la France est un petit marché, éventuellement si on s’intéresse aux francophones, ça s’élargit. Mais, que d’un coup on s’intéresse aux Etats-Unis ou plus largement au monde anglophone ça ouvre quelque chose de beaucoup plus large. Il ne faut pas se leurrer. Un moment donné quand ont créé quelque chose on fait des économies d’échelle.  

Du coup le regard que je porte est plutôt d’un point de vue économique. J’ai la sensation qu’en France ça manque encore un peu d’encouragements à la prise de risque. Peut-être. Donnez-moi tort s’il vous plaît ! Donnez-moi plein d’exemples, changez mon avis, je suis curieux j’ai envie de le voir 

Ma sensation reste tout de même que, par rapport à ce que j’ai vécu ou observé du côté des Etats-Unis et de Londres, il y une liberté plus importante chez les anglo-saxons. Ça monte plus haut, ça se fait plus mal mais ça tente plus. Je n’ai pas la sensation qu’en France on est encore ce changement de culture. On a l’intention, tout le monde dit qu’on veut y aller, on a envie de chérir les gens qui se trompent : “il s’est trompé donc on peut lui faire confiance car il a tiré les leçons”, mais je n’ai pas la sensation qu’on y soit encore. Encore une fois c’est une sensation personnelle. Je suis CTO d’une boîte dans la tech, j’ai fait carrière dans la tech, j’ai fait des sorties au frontière de cette tech là, mais globalement j’aurais peut-être besoin d’avoir l’avis de personnes dans la tech et hors tech en France. On a encore un aspect culturel, certaines peurs qui sont cultivées, des tampons qu’il faut avoir comme notamment le tampon scolaire. Ça évolue, oui, mais le processus n’est pas aussi avancé que chez les anglo-saxons. 

Déjà, il faut sortir des diplômes. 

 

C – Quelque part le moule, le formalisme ? 

 

H – Ouais, exactement. Encore une fois ça évolue, je ne pense pas que ce soit aussi difficile qu’il y a 10, 20 ans. J’aimerai bien voir ça évoluer encore, continuer à le voir évoluer. 

 

C – Le principe de prudence, il est très ancré dans la culture française, même si à plein d’échelle c’est en train d’évoluer, je pense qu’on est très loin de ce qui peut être enseigné dès le plus jeune âge dans les écoles américaines, dans cette culture anglo-saxonne. La preuve ‘take a chance’ chez nous c’est “prendre un risque”… Déjà dans la manière dont s’est traduit, on voit un biais de notre côté. 

H – C’est vrai ! 

 

C – Les choses évoluent là-dessus. Mais pour toi c’est avant tout culturel. Tout à l’heure on parlait un petit peu des technos. Tu me disais la manière dont tu te maintenais informé. C’est quoi ta techno du moment ? 

 

H – Les choses auxquelles je me suis le plus intéressé récemment ont été Rust et Kubernetes. Mais je ne suis pas novateur en annonçant ça, je l’avoue. (Rires). 

 

C – Pourquoi ? Pour la performance, le côté bas niveau ? Quelle a été la logique ?  

 

H – On s’intéresse au Rust parce que c’est un langage de programmation système. Chez Qwant on a des gros besoins à ce niveau-là. Kubernetes c’est pour notre infra, on le gère nous-même de bout en bout. Si on ne s’intéresse pas aux technos que l’on utilise en termes de praticité, ça risque d’être compliqué. 

 

C – Chez Microsoft c’était plutôt un environnement .NET, l’utilisation de JavaScriptTypeScript par la suite. Facebook, j’imagine un ensemble de technos différentes. Toi, tu as pu monter une équipe autour de la recherche. Quelle a été la culture par rapport au fait d’essayer de nouvelles technos dans un écosystème dans un premier temps fermé et qui aura tendance à s’ouvrir et devenir interopérableComment on peut finalement se tenir à jour ? Est-ce que ce n’est pas trop limitant ? 

 

H – C’est très individuel. Il y a deux choses à distinguer. Il y a d’abord l’intention individuelle de ce que l’on souhaite devenir dans la vie. Donc il y a des gens qui aspirent à connaître plein de choses en large afin d’être capable du coup de les aborder et d’avoir une vision plus globale sur les projets. Je prends mon cas par exemple. Dans mes équipes, j’ai un mec qui va brancher des Switch, un autre qui fait des publis en machine Learning, au milieu j’ai de la prog web, de la prog système, un antiscrap. Enfin, je dis ‘j’ai’, mais les gens avec qui je travaille et ou je me situe en soutien. Ça me demande un switch mental qui est parfois difficile mais que je trouve absolument fascinant.  

Il y a d’autres personnes en revanche qui vont creuser un certain domaine et descendre en profondeur et devenir très pointu. Finalement, ça va dépendre de l’état d’esprit et de l’envie que l’on peut avoir.  

Dans mon cas, j’avais une tendance à être simplement curieux et à vouloir essayer. Et après il y a ce que propose l’entreprise. Par exemple, chez Microsoft effectivement beaucoup de .NET. Mais même au travers du /NET il existe pas mal de choses ; on peut s’amuser à avoir des avis très serrés ou très opposés. J’ai vu un combat “à mort” entre C# et C++ qui était assez incroyable dans une des équipes. Ils ont fini par choisir l’une des deux technologies, mais l’ont regretté plus tard puisque les tests n’étaient pas les bons.  

C – Il peut y avoir une guerre d’égo. Tu en parlais en disant que l’humilité permet de se dire que, même si on pense que l’on maitrise mieux cette techno, ou qu’elle est plus pertinente, il faut être capable de se remettre en question. 

 

H – C’est ça. Et chez Facebook, la façon d’aborder était intéressante parce qu’il y avait un truc à faire. Y’a les technos de préférence mais j’ai vu plusieurs fois des éléments intégrés par d’autres personnes parce que les capacités d’exécution le permettaient. Il fallait être convaincant techniquement mais c’était possible. Même si plus on avance sur un projet, plus c’est difficile d’implémenter quelque chose de neuf. 

 

C – Une dernière question avant de conclure. Qu’est-ce que tu donnerais comme conseil finalement aux gens qui auraient envie de postuler chez Qwant ? 

 

H – Ahah. Le conseil que je donnerais aux gens qui ont envie de bosser chez Qwant c’est : attendez-vous à de la houle. Venez parce que vous avez soif d’aventure. Parce que vous avez envie de découvrir de nouveaux continents Attendez-vous du coup à ce que dans cette aventure il y ait des doutes et des difficultés. Il y aura des envies d’arrêter, des incompréhensions, des zones de floues et néanmoins une équipe solide et de gens ultra-motivés et brillante. 

Venir chez Qwant, c’est ne pas vouloir du métro-boulot-dodo. Je pense que nous rejoindre c’est avant tout une envie de faire quelque chose qu’on a rarement l’occasion de faire dans une vie. En plus on s’attaque à un monstre, au kraken, c’est compliqué mais passionnant ! 

 

C – D’où la volonté d’humilité que tu recherches chez les gens que tu challenges ?  

 

H – C’est ça, il faut un esprit d’équipe. Je cherche des gens qui ont le sens du collectif et l’envie d’apprendre et de faire apprendre. Il faut évidemment avoir des bases solides en informatique. Le tout savamment entrelacer dans la personne. 

 

C – Un grand merci pour ton temps Hugo, et on n’hésitera pas à faire suivre les questions ou commentaires qui viendront à la suite de cet article. Encore une fois, un grand merci pour ce moment. 

 

H – Merci beaucoup César, c’était vraiment hyper intéressant de se voir questionner sur ce que l’on est en train de faire et ce que l’on a envie de faire. Et tu ne m’a pas laissé tranquille et c’était chouette, merci ! 

Notez cet article
0/5

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *