Bruno:
Une cathédrale gothique, ça tient debout depuis 800 ans, pas parce que le maître d'œuvre connaît chaque pierre par cœur, mais parce qu'il maîtrise la poussée des arcs, la répartition de charges, le compromis permanent entre l'ambition du commanditaire et l'implacable gravité. Il ne taillait pas les pierres lui-même, il ne coulait pas les vitraux, mais quand une fissure apparaissait, il savait si c'était juste un détail ou le début de la fin. Il connaissait les principes, pas tous les gestes, et c'est précisément cette connaissance des fondamentaux qui lui permettait de juger un matériau qu'il n'avait pas forcément déjà utilisé ou une technique qu'on venait d'inventer dans l'atelier d'à côté. Mais alors, l'architecte logiciel doit-il vraiment tout connaître du TCP jusqu'au dernier framework à la mode ? La théorie suffit-elle ou faut-il s'être brûlé les doigts pour vraiment bien comprendre les choses ? Et surtout, le métier d'architecte, est-ce que c'est de trouver la solution ou de laisser les autres trouver ? Pour répondre à ces questions de structure, je ne reçois pas Eugène Violet-le-Duc, mais il s'y connaît en édifice qui tienne. Thomas, bonjour.
Thomas:
Bonjour.
Bruno:
Alors Thomas, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Thomas:
Oui, Thomas Pierrin, ça fait presque 30 ans, ça fait 29 ans que je fais ce métier. J'ai fait plein de choses très diverses et variées. Mais j'ai travaillé notamment dans la finance de marché à la partie banque d'investissement de la Société Générale pendant 12 ans où j'ai découvert des sujets faible latence, haute disponibilité, programmation réactive des choses comme ça qui changeaient des applications que j'avais l'habitude de faire ça m'a mis une claque et c'était cool j'ai appris plein de trucs et puis pas mal d'infra aussi à ce moment là, après j'ai monté ma boîte pour accompagner des clients à sécuriser des projets un peu critiques je montais des équipes, j'en faisais partie et on sécurisait un projet, ça a duré un an et demi deux ans à peu près et puis j'ai rejoint une scale up européenne pendant quatre ans en tant vipy of engineering dans hyper croissance tu passes de 50 à 150 à 120 personnes au début et, c'était fou donc ça c'était une expérience assez folle et assez intéressante et puis ben là depuis début d'année je suis chez je suis donc je suis vipy of tech chez chodo une scène un peu militante qui aiment bien faire bouger les lignes, que ce soit sur le modèle social et la tech aussi, on a envie de secouer un peu plein de trucs, donc voilà.
Bruno:
Et donc là, aujourd'hui chez Shodo, t'es sur un rôle d'architecte, enfin c'est quoi ton quotidien ?
Thomas:
Non, alors je suis vipitech du coup ça veut dire en gros, j'accompagne Julien Topsul, CTO sur faire grandir un peu la boîte la structurée, donc je fais partie de la direction technique Shodo c'est une boîte avec plein de filiales, donc voilà, c'est une boîte qui est en train c'est à dire que dans une période où les autres ESN galèrent, force à eux, là chez Shodo, je crois qu'ils n'ont jamais fait les meilleures années et ça marche bien, donc c'est comprendre pourquoi et puis surtout, en fait, les idées à développer encore, voilà, et à muscler une partie technique aussi, peut-être encore plus, quoi. On a vraiment essayé de jouer avec les copains et copines sur ces sujets-là. Donc ça, c'est le pendant-chaudo, et le reste du temps, je travaille quand même chez des clients, ce qu'on appelle être staffé chez un client, et donc là, j'accompagne une scale-up française, en tant que responsable de l'ingénierie. Au début, c'était 3 jours sur 5, maintenant, je suis en train de passer à 4 jours sur 5. Pour les accompagner à croître, à grandir, à se structurer.
Bruno:
Et donc ça veut dire que tu interviens sur des sujets techniques, mais pas que. Dans cette notion d'ingénierie, il y a aussi comment organiser le travail, en fait.
Thomas:
C'est ça. Comment se structurer, comment organiser toute la partie sociothèque, comment on fait pour avoir une tech qui soit hyper efficace par rapport aux contraintes et aux objectifs qu'on a. La relation tech-produit aussi, qui est une articulation de charnière qui est quand même cruciale. Et c'est un peu le nerf de la guerre, je trouve, souvent. Donc c'est des sujets, comment on mesure l'impact comment on est sûr qu'on travaille sur les bons sujets et comment être efficace surtout en gros, qu'est-ce que je peux faire pour que vous soyez toutes et tous efficaces pour...
Bruno:
Est-ce que tu penses que la majorité de la complexité sur ces rôles-là quand on lead une équipe technique elle est plus sur les sujets purement humains d'organisation du travail ou ce genre de choses ou plutôt sur les sujets de, s'assurer qu'on fait du produit de qualité qu'on dev de la bonne manière qu'on a une bonne CI qu'on choisit la bonne technologie, mon frère mort, ce genre de choses.
Thomas:
Indéniablement l'humain je pense que c'est le truc, je l'avais parlé dans une conférence une fois les sujets tech c'est de la rigolade par rapport aux sujets humains et quand je dis sujets humains ça peut être plein de choses mais ça peut être des enjeux culturels très souvent, tu vois il y a des sujets, moi j'ai accompagné beaucoup de clients sur le continuous delivery c'est comment tu passes d'une organisation où tu shippes bon en ballant. Dans cette scale-up où j'ai bossé 4 ans, au début c'était une release tous les deux semaines. Là, j'entends des anciens collègues qui font 6 releases le matin, 4 releases le soir, et c'est plus un événement. Donc, comment accompagner ça ? Et mine de rien, il y a tellement de choses qui peuvent freiner, bloquer, rendre compliqué ce changement de culture. Là, l'IA, en ce moment, c'est pareil. Ça amorte une autre dimension en plus, puisqu'il y a des craintes existentielles. Il y a plein de choses. Puis il y a des questions éthiques. Il y a plein de choses qui se posent. Donc, pour moi, c'est le plus compliqué, mais c'est presque le plus intéressant. Alors moi j'ai une double casquette je sais pas comment définir j'aime autant l'étudier très très très technique l'architecture technique des fondamentaux je pense être le sujet du jour et d'autres sujets très métier je suis aussi fan de domaine design de sociothèque et d'intelligence collective en gros c'est ça c'est un sujet qui m'intéresse que ce soit pour une petite équipe xp voilà 5 à 8 ou que ce soit pour une scale up 250 tech c'est des sujets qui j'aime les deux et voilà je me nourris des deux quoi.
Bruno:
Alors effectivement on avait prévu de se voir pour parler de ce métier d'architecture sur un aspect très tech mais tu me lents sur des sujets qui parlent d'autre chose donc forcément moi j'ai envie d'y aller et surtout tu m'évoques le domaine du vent design.
Thomas:
J'en.
Bruno:
Ai parlé plusieurs fois sur ce podcast, Moi, je trouve que c'est une approche qui est hyper intéressante et je me demande même si ce n'est pas d'une certaine manière, alors je vais prendre une position peut-être un peu forte, mais je me demande si le DDD, ce n'est pas l'aboutissement logique de toute carrière de développeur ou développeuse, dans le sens où c'est la réalisation que notre métier tech, en fait, ce n'est pas d'écrire des lignes de code, c'est d'apporter une réponse à un produit, c'est de comprendre un métier, que le DDD t'oblige à comprendre le métier faire en sorte que les gens qui lisent le code comprennent le métier que les gens dont c'est le métier puissent potentiellement aussi lire ton code, ça t'oblige à structurer les choses comme les gens qui vont utiliser ton produit enfin je trouve qu'il y a tout un tas de philosophies et on l'a déjà dit et redit sur ce podcast qui existe depuis 7 ans maintenant, que effectivement notre métier c'est pas juste d'écrire des lignes de code et vu l'époque c'est encore plus vrai, et qu'on est là avant tout pour apporter une solution à une problématique Et je pense vraiment que le DDD, c'est un aboutissement auquel tout développeur ou développeuse arrive forcément à un moment.
Thomas:
C'est effectivement dans la route longue, pour apprendre des choses, être efficace, c'est une étape importante à laquelle j'ai l'impression qu'on est nombreux et nombreux à converger. C'est cardinal pour moi. Vraiment, c'est comprendre et réaliser qu'on est là pour résoudre le problème des gens. Moi, je kiffe la techno, j'adore la techno, et c'est un moyen très puissant pour arriver à résoudre les problèmes des gens. Mais si on n'arrive pas à comprendre ça, qu'on est là pour résoudre le problème des gens. Et du coup, pour résoudre un problème, il faut déjà le comprendre. Du coup, il faut s'y pencher. Mon client actuel, c'est dans la compta et la fiscalité. Ce sont des domaines qui sont très très riches. Et comme le dit le CTO chez nous, on n'est pas là pour écrire des lignes de code, on, Pour résoudre des problèmes de comptabilité et de fiscalité pour nos clients. Et en fait, ça, c'est un message qui est assez fort. Et quand je vois ce qu'ils ont été capables de faire, ça a apporté des fruits vraiment très intéressants. Par rapport à d'autres boîtes qui se perdent dans la tech et qui font la tech pour la tech. Et qui font des modèles anémiques, qui ne comprennent pas trop. Ou le logiciel, il n'est pas aligné par rapport aux besoins. Donc en gros le risque de bug il est énorme parce que le code, et ce que tu as comme discussion avec les customers success ou avec les clients ça n'a rien à voir donc nous on devient complètement, je ne sais pas si c'est schizophrène non c'est peut-être pas le bon terme mais en gros nous on s'arrache les cheveux c'est à dire qu'on parle d'un côté avec les produits et avec les clients de plein de trucs et quand on est devant notre IDE bah en fait, c'est pas du tout la même chose donc on passe notre temps à faire des ponts, des mappings mentaux entre des concepts qui auraient dû être codés comme ça ou qui auraient dû s'appeler comme ça dans le code, Avec l'IA, ça commence à... C'est un des problèmes qu'on peut arriver à mitiger bien mieux, mais néanmoins, c'est quand même compliqué.
Bruno:
C'est-à-dire qu'avec l'IA, tu penses qu'on peut réécrire facilement une codebase dans un contexte DDD, c'est ça ?
Thomas:
On peut refacto de manière... Avant, il fallait... Vraiment, il fallait trouver un business case de fou, ou trouver des bons arguments pour arriver à justifier peut-être une période de refacto, ou des moments un peu plus intenses de refacto, ici ou là. Là, avec de l'IA générative, il y a des trucs... C'est presque plus un sujet. Alors, il y a comment tu le fais et comment tu le fais bien. Ça reste un vrai sujet. Mais on est capable de... Des sujets qu'on avait depuis des années... J'ai des anciens collègues avec qui j'échange un peu aussi. Il y a un truc qui était très legacy, sur lequel il y avait vraiment des difficultés. Donc, on y est allé quand même et vraiment là, avec les efforts d'huile de coude, des stratégies de zinzin pour faire du refacto et tout. Ça marchait, mais c'était très lent. Et comme, en plus, on ne peut pas s'arrêter de shipper, il faut délivrer, tu vois, c'est un peu cours alternatif, quoi. On glisse ça un peu. Là, il y a des sujets entiers qui deviennent presque des non-sujets. Donc ça, c'est un des trucs positifs. Il y a plein de trucs positifs, mais c'est un des trucs positifs. Je trouve que reprendre un peu la main sur une code blesse. Ne serait-ce que, un Gitini, un repo d'un bout de code, il n'y avait que Jean-Jacques ou Martine, qui étaient les deux seuls qui avaient travaillé sur le sujet. Et donc, on était... Enfin, vraiment, on fouettait tous, parce qu'on disait, voilà, si ça, ça prend tant de choses, comment on va faire ? La personne n'est plus là ou en vacances et tout. En fait, reprendre du contrôle sur tous ces vieux legacy, etc., à un coût qui est quand même vraiment très bas. Quand bien même, peut-être, tous les tokens, d'un coup, ça ne devient plus utilisable, on s'arrête tout et on reprend comme on faisait avant, déjà, tous les gens qui auront pris le temps de cartographier tous leurs composants avec ça aujourd'hui, au moment où c'est possible de le faire, je pense qu'ils auront gagné un sacré edge par rapport à tous les autres.
Bruno:
— Oui, parce qu'effectivement, on se dirige peut-être vers une période où le coût du token va un peu exploser. Donc il faudra revoir notre usage. Pour le moment, on est un peu en mode open bar par rapport à ce que ça apporte.
Thomas:
— Oui, on dit ça. Mais en même temps, il y a des... Alors moi, je n'ai pas fait tout le travail de veille pointilleux, de rechercher tout. Donc je parle avec un gros disclaimer. Mais il y a plein de modèles ou de trucs intéressants qui, en Chine, sont en train d'émerger, avec des modèles qui coûtent beaucoup moins cher à entraîner, beaucoup moins cher à opérer aussi. Donc en fait si ça se trouve il y a aussi de la recherche sur autre chose que sur des GPU on n'est pas à l'abri finalement qu'on se retrouve avec des trucs qui, alors ça va faire mal aux acteurs qui ont investi massivement sur cette architecture qui pourrait devenir legacy tu vois donc eux ils ne seront pas bien mais ça se trouve il y a un moyen que ça continue, bon je mets des guillemets parce que c'est que de la prospective mais il ne faut pas l'exclure Parce qu'en fait, moi, s'il y a trois ans, on m'avait expliqué quel était mon quotidien, ce que j'étais capable de faire aujourd'hui avec de l'IA, etc., J'ai eu du mal à le croire, déjà. Donc, ça va vraiment très, très vite.
Bruno:
Et surtout aussi vite, complètement.
Thomas:
Bien malin, c'est celui qui s'est prédit pendant longtemps sur les réseaux sociaux. Ça me fatiguait de lire mes collègues. Ouais, de toute façon, ça ne remplacera jamais les devs. Ça fera l'IA, c'est n'importe quoi. Il y a des gens qui avaient des avis très tranchés, etc. Et j'ai dit, wow, ils sont quand même... Moi, s'il y a bien un seul sujet où je n'ai pas envie de l'ouvrir, vraiment en ce moment, j'ai plein d'incertitudes, tu vois, c'est ça. C'est en train un peu de se dissiper, tu vois, les nuages, il y a deux, trois trucs qui commencent à devenir un peu plus concrets, mais ouais, c'est quand même rempli de surprises, donc...
Bruno:
Il faut être prudent en tout moment.
Thomas:
Carpe diem, pour l'instant, je fais avec ce que j'ai sous la main, et puis, voilà.
Bruno:
— Tu as évoqué, quand je pose la question sur le DDD, tu t'as dit que c'était effectivement une longue route d'apprentissage. Parce qu'on a effectivement... Alors on peut parler du DDD, mais tu vois, on peut aussi cumuler ça. Ta carrière qui a duré plus de 30 ans moins de 30 ans on s'en rapproche tu disais, t'as vu pas mal de contexte, pas mal de choses dans des métiers différents des niveaux différents des tailles différentes aussi, j'imagine que t'as eu des contextes aussi de mise en preuve foireuse, d'attaque de bugs catastrophiques qui sont aussi des choses qui nous permettent d'apprendre, est-ce que tu penses que c'est nécessaire dans notre métier d'apprendre.
Thomas:
D'avoir un apprentissage.
Bruno:
Qui soit long et effectivement un apprentissage qui soit autant dans la douleur aussi par moment.
Thomas:
Alors je ne souhaite pas la douleur mais je pense qu'effectivement de tomber, que quand on tombe c'est là où on apprend plein de trucs je pense que ça fait mal et on n'a plus du tout jamais envie de tomber à ce point et de se faire mal, sans se dire ah qu'est-ce que j'ai raté comment je peux moins tomber donc oui je pense que c'est en tout cas moi pour retenir des leçons, Ce n'est pas parce que j'ai un grand ton qui m'a dit « Fais gaffe à ça, je te mets en garde. », Je vais peut-être te retenir ça pendant quelques temps et puis après ça va sortir de ma tête. Par contre, il y a des souvenirs qui ne disparaissent pas, il y a des trucs qui te marquent. Je sais que moi, la partie banque d'investissement, à un moment donné, on se retrouvait à devoir tester des trucs sur des plateformes, sur des marchés électroniques. Là où tu as des traders et des sales qui manipulent des chiffres colossaux. Et il y avait un outil qui s'appelait Bloomberg qui n'était pas très bien. C'était numéro un sur leur marché, donc ils faisaient ce qu'ils voulaient, ils faisaient la pluie de beau temps. Et du coup, il n'y avait pas d'environnement de dev vraiment. Il y avait juste un commutateur dans la console de prod où tu faisais slash dev sur certains trucs. Et là, tu passais en mode dev. Et donc, il y avait plein de tests en grandeur nature qu'on devait faire avec ça. Et ça sautait. Donc, il fallait tout le temps checker si tu étais bien en mode dev, slash dev et tout. Et je me rappelle lors de mon onboarding j'ai l'architecte qui était sur l'équipe que je rejoignais qui me faisait la démo, qui me disait exactement la même chose on était devant la console Bloomberg, et tout d'un coup il s'appelait Pierre s'il entend ce podcast, et il me dit tu vois alors faut faire gaffe à ça etc et tout donc il me fait 2-3 manips et puis au bout de 5 minutes il continue à faire une autre manip moi je regarde l'écran et puis je dis écoute on est pas censé avoir le slash dev là sur le truc Et là, je le vois blémir. Donc là, l'onboarding s'est arrêté tout de suite. Il m'a tourné le dos, il s'est mis devant la console, etc. Il a tout de suite décroché son téléphone, il a appelé la salle de marché. Et heureusement pour lui, c'était un trader de l'Institut Général qui avait fait affaire avec lui, qui était en train de mettre des faux... Enfin, il pensait mettre des faux prix sur un faux produit, tu vois, sur un environnement de dev. Et en fait, il venait de se faire exécuter par quelqu'un. Et en fait, les traders, ce n'est pas des gens très gentillets, machin, très souples. Et du coup là il a dû négocier pendant longtemps parce que l'autre il pensait qu'il avait fait. Son deal de l'année tu vois donc là il l'a appelé très vite très tôt donc avant que l'autre il se ridiculise et qu'il offre le champagne à toute la salle et puis pour pouvoir annuler tout ce qui avait été fait et en fait le fait de l'avoir vu alors là c'est pas moi qui l'ai vécu, mais j'ai cru même c'était mon premier jour tu vois genre bah.
Bruno:
J'étais quand même.
Thomas:
Impressionnable et voilà donc, ça c'était un cas mais tu vois je m'en rappelle encore presque chaque chacune de son visage et donc oui je pense que c'est mieux d'expérimenter se tromper pour retenir après si on peut éviter de se faire trop mal c'est quand même bien mais.
Bruno:
Tu vois après on vit aussi une époque, Il y a des niveaux d'extraction supplémentaires sur plein de sujets. Les technos ont quand même beaucoup changé. Aujourd'hui, faire un... Je prends un tout bête, mais faire un buffer overflow en 2026, c'est plus compliqué que de le faire début des années 2000, voire début des années 90. Parce qu'en fait, tu as des outils qui sont tellement haut niveau, tu as tellement de sujets. Et donc la question qui peut se poser, c'est est-ce que tu as besoin d'avoir connu ces éléments-là ? Est-ce que ça veut dire que tu as une partie de l'apprentissage que nous on a expérimenté dont les jeunes n'ont plus besoin, ou est-ce que on peut, ou est-ce qu'il faut devenir des vieux cons et dire c'est dommage parce que les jeunes ils ne connaissent pas, ils n'ont pas expérimenté le buffer overflow et du coup ils ne savent pas ce que ça veut dire et tout ce que ça... Tu vois ce que je veux dire ou pas ?
Thomas:
Ouais complètement. Alors vieux cons non en tout cas on essaie de limiter l'effet naturel qui nous pousse inlassablement dans ce truc là. Ce que tu me dis ça m'évoque un peu par exemple la relation avec les devs moi dans la scale up c'était sur tout le monde utilisait un ORM avec l'accès à la base, et du coup cet outil là moi j'ai jamais été vraiment fan des ORM pour plein de raisons mais cet outil là ce qu'il a fait c'est qu'il a distendu le lien entre le ou la dev et le sous-jacent qui est en l'occurrence une base de données relationnelle, le nombre de problèmes de prod et de perf J'ai pu constater, qu'on a pu constater et vivre, parce qu'en fait, on n'avait plus ces fondamentaux. Tu vois, comment ça fonctionne, qu'est-ce qu'il vaut mieux pas faire, etc. Avec l'utilisation d'un ORM qui est une sorte d'obstraction qui rend plein de services. Mais je crois que c'était Jean-Baptiste Dussault, un copain qui est à Bordeaux, qui avait l'habitude de dire, l'ORM, ça rend les choses simples... Facile, gratos, et puis les choses compliquées, quasiment impossible. On dit que tu veux vraiment... Alors, tu peux devenir spécialiste, spécialiste du SGBD, relationnel en dessous, spécialiste de l'ORM, fine-tuné comme un... Là, c'est sur les cas, tu vois. Donc, le coup, il est questionnable. Mais, en tout cas, il y avait plein de choses qui étaient, par exemple, les modèles, de lecture, les différents modèles, ça, ça fait partie du LGBT. Quand tu manipules qu'un ORM, tu ne le vois pas. Et du coup, tu peux te retrouver confronté à des trucs où tu vas générer des verrous pour rien parce que tu es dans des stratégies d'acquisition de verrous systématiques pour de la lecture, alors qu'en fait, toi, tu n'en as rien à faire. Et donc, tant que tu n'as pas été confronté à ça, c'est compliqué. C'est pour ça qu'il y a un truc que moi, j'avais bien aimé. J'ai découvert ça à l'époque où je travaillais dans la société générale c'était un middleware antémessage donc là-bas ils avaient pas mal de PCTAS comme on dit et donc en termes de techno c'était c'était fou. Hardware, software donc c'est des solutions qui coûtaient extrêmement cher, c'est des middleware antémessage faible latence, sur du multicast et ça coûtait certaines d'entre elles ça coûtait 5 millions par an d'abonnement ça c'était pour les premiers qui ont payé le truc, pas pour ceux qui sont arrivés après et qui ont réussi à négo, mais... Et il y avait une solution qui s'appelait 29 West à l'époque, qui avait une stratégie que j'aimais bien. Par défaut, tous les settings de la librairie étaient très très très très bas, presque fait pour que très vite, dès tes premiers usages, tu sois confronté à une limite, tu vois, une taille de buffer, au bout de combien de... Tu vois, t'as des buffers avant d'envoyer, tu fais des send, tu fais des send, etc. Mais si tu envoies un message à chaque fois que tu fais un send, quand tu fais de la faible latence, c'est compliqué parce que tu passes du user space au kernel space et ça coûte cher. Et finalement, tu dis que c'est malin, du point de vue de la latence, d'envoyer tout le message sur la carte réseau quand je veux faire un send. Et en fait, non, parce que t'as des frais de bouche, t'as des frais de ph pour passer ton user space vers le kernel, du coup t'as des stratégies de smart batching comme on appelle et donc en gros c'est la librerie qui va décider pour toi avec des, paramètres que tu vas lui préciser et qui va dire bon Thomas il a voulu faire un send d'un message là on va attendre deux choses soit que la taille du buffer avant envoie soit dépassée soit que le délai d'attente avant envoie parce que s'il n'envoie qu'un seul message on va attendre. On va quand même flusher tu vois le message et donc ce truc là, très vite toutes les settings étaient très très bas par défaut toutes les valeurs par défaut étaient vraiment faites pour que dès les premiers usages en dev tu te rendes compte que ça marche pas mais attends comment ça fait comment c'est possible que ça marche pas comment ça se fait que la latence elle est nulle comment ça se fait ah bah tu regardes la doc, tfm tu regardes la doc et tu dis ah putain, Pourquoi ils ont mis des réglages comme ça ? Et en fait, c'était presque une courbe d'apprentissage. Tout leur valeur par défaut nulle te forçait à découvrir des choses vraiment fondamentales dans l'usage de la librairie. Donc ça, j'aimais bien ce côté, tu sens le gravier, tu touches un peu les murs. Et quand t'arrives en prod, en fait, t'as déjà vu, tu t'es posé plein de questions, que sinon, genre, bien packagé, on se les posait pas.
Bruno:
Et
Thomas:
Sur l'ORM j'avais l'impression que souvent c'était des ORM en mode valeur par défaut et on allait en prod gaiement avec ça jusqu'à ce qu'on ait des problèmes vraiment plus.
Bruno:
Pourquoi est-ce que dans notre métier il est nécessaire de se poser autant de questions et de creuser autant de sujets, je connais pas les autres métiers bien évidemment j'ai pratiqué celui-là aussi une bonne partie de ma vie, mais j'ai quand même l'impression que, il y a beaucoup d'autres métiers où, en fait, t'apprends les choses à l'école ou en formation et puis une fois que t'es sur le marché du travail, en fait, ce que t'apprends, c'est... C'est pas l'impression que t'as besoin de te poser autant de questions sur d'autres métiers artisanaux ou ce genre de choses, à te demander, tiens, pourquoi est-ce que ça, ça a été fait comme ça ? Parce qu'en fait, tu vois, je...
Thomas:
Moi, j'en vois plein d'autres qui sont comme ça. la médecine par exemple les médecins qui ne se mettent jamais à jour qui ne vont pas dans les conventions etc.
Bruno:
Je ne parle pas de se mettre à jour parce que ça je suis d'accord il n'y a pas de métier où c'est nécessaire de s'intéresser aux nouvelles techniques, aux nouveaux moyens aux nouvelles technologies qui sortent mais de.
Thomas:
Se poser des questions tu dis.
Bruno:
Sur comment ça marche pendant un moment j'avais établi de manière empirique une règle qui me permettait de dire en fonction de la durée de l'onboarding d'un nouveau salarié je savais si la personne allait être performante ou pas. Et ma règle c'était que plus l'onboarding est long, plus la personne sera performante. Parce qu'en général, un onboarding qui est long, c'est que la personne, elle t'a posé plein de questions. On te demande, tiens, mais pourquoi t'as fait ça ? Pourquoi ça s'est fait comme ça ? Pourquoi c'est organisé comme ça ? Alors qu'à la personne qui ne te pose aucune question, en fait, du coup, ton onboarding, il est bâclé en un jour et demi. Mais la personne n'a posé aucune question et du coup, en fait, elle ne sait rien. Tu vois ce que je veux dire ? Il y a des tas de trucs où, pour bien comprendre notre métier, il faut aller se poser la question de, en fait, le garbage collector, comment il fonctionne ? C'est quoi une heap ? C'est quoi un buffer overflow ? Pourquoi est-ce que dans notre métier, est-ce que c'est qu'on aime ça ? Est-ce qu'on est tous des ferrues de casse-tête ? Ou est-ce qu'il y a une nécessité dans notre métier à se poser des questions ? Il y a mille personnes qui écoutent ce podcast et je vous en remercie. Vous êtes des gens formidables. Je vous adore. Mais pourquoi vous avez besoin d'écouter deux personnes chaque semaine qui vont parler d'un sujet technique dont peut-être vous n'aurez jamais besoin ?
Thomas:
Je pense qu'on adore se poser la question, en termes de sociologie, quand je discute avec des collègues depuis longtemps, je pense qu'il y a un truc autour de la curiosité, autour de aimer découvrir, apprendre, des nouvelles choses. Moi, c'est un moteur, chez moi, d'aimer apprendre. Et d'ailleurs, tu vois, avec l'IA, c'est un autre truc, c'est que j'apprends au quotidien encore. Malgré mes 29 ans d'expérience, il y a plein de trucs que j'apprends aux autres, mais j'ai toujours faim d'apprendre et tout. Et ça, c'est cool. Je pense qu'on a quelque chose autour de ça. Après, on manipule beaucoup d'abstractions, vraiment, et des abstractions qui se construisent... Qui se rajoutent assez facilement. Du coup, en fait, on arrive à faire des systèmes de relative complexité et donc, ça nous force à nous poser automatiquement des questions, parce qu'il y a toutes les couches entre le hardware, le software, la virtualisation et tout, le nombre de trucs qui sont mis en oeuvre pour que ça marche. On est loin de la cuisine, tu vois. Donc, en termes de nombre d'éléments auxquels on doit faire face et qu'on doit manipuler, donc je pense que c'est obligé de se poser, beaucoup de questions si on va arriver à un résultat à peu près potable et j'ai mentionné la cuisine, moi j'adore la cuisine, en fait en vrai je pense que les bons cuisiniers ou cuisinières c'est les gens qui continuent à se poser plein de questions et à essayer de trouver et donc à interroger en tout cas j'ai l'impression pour avoir écouté quelques interviews de chefs, c'est un truc qu'ils ont en commun c'est une route qui n'est jamais finie des questions qui seront toujours ouvertes et qui se posent. Donc, je sais pas. Je pense que dans d'autres métiers, mais c'est sûr que nous, avec toutes ces abstractions qu'on doit gérer, comprendre, digérer, assembler, fonctionner, machin, tout, les gens qui se posent des questions par rapport à ceux qui s'en posent pas, peut-être c'est plus dur à vivre, dans certains cas. Je sais qu'il y a des gens que ça consomme, tu vois. Mais c'est plus efficace.
Bruno:
— Mais ce qui est aussi paradoxal, je trouve, c'est qu'on semble tous et toutes avoir une capacité naturelle à savoir quand est-ce qu'on va arrêter de creuser. Parce qu'un truc que j'ai réalisé récemment, je demande à plusieurs invités s'ils savent comment fonctionne un processeur. Et en fait, très souvent, on connaît un peu la théorie, mais au-delà de ça, pas beaucoup plus. Il y a quand même un moment où on se dit, en tant que dev, je n'ai pas besoin d'aller... Ça me suffit. Pourtant, notre abstraction, la seule partie qui est non abstraite, c'est le processeur. Tout le reste n'est qu'une abstraction et un empilement d'abstractions.
Thomas:
Oui alors pareil moi je pense que je suis biaisé parce que le détour que j'ai fait en finance, fait que dans les problématiques qui étaient les nôtres de faible attence et de haut dispo etc t'es obligé d'aller très très bas t'es obligé de comprendre parce qu'en fait certains mauvais choix à la base sur un sous-jacent hardware ou machin, ou logiciel ça va te coûter cher tu vois le simple fait d'utiliser TCP ou UDP sur certains cas d'usage ça va te changer ça va avoir des conséquences radicales tu vois par rapport aux problématiques que tu vois. Il y a un mec que j'aime bien c'est Martin Thompson je sais pas si tu vois qui c'est c'est un peu une sorte de gourou de la perf donc c'est quelqu'un qui vient du monde Java plutôt à la base mais c'est vraiment un software engineer au sens vraiment l'ingénieur, et il a un peu bouleversé plein notre champ, notre activité et en particulier sur tout ce qui est faible latence parce qu'il y a quelques années il a montré que en Java, il arrivait à faire des systèmes qui poutraient, des systèmes qui auraient dû. Tout cartonner par rapport au sien. Et en fait, il a fait des résultats en termes de latence et de débit. En général, si tu as gros débit, c'est dur d'avoir une faible latence. Et si tu as une faible latence... Et lui, il arrivait à concilier de manière surprenante les deux. Et donc, il a inventé un patin qui s'appelle le Disruptor. une sorte de ring buffer circulaire c'est un truc vraiment, ce truc là à l'époque on était tous quand on a découvert ça à travers un talk à travers un truc sur un Focue on s'est dit mais qu'est-ce que c'est que ce truc là le mec ce qu'il raconte c'est super intéressant, Et il explique des chiffres qui sont incroyables. Et en fait, ce type-là, il a une métaphore, et je crois que c'est le nom de son blog, c'est Mechanical Simpathy. En gros, il est féru de F1, comme beaucoup d'ingénieurs, je pense. Et du coup, il y a apparemment un pilote qui a dit, en tant que pilote, pour être un bon pilote, il faut avoir une sorte de proximité avec comment on fait des moteurs, comment marche la machine. Et que c'est que ces gens-là qui vont réussir à donner le meilleur d'eux-mêmes et de la machine plus l'équipe et bien en fait il a basé, toute sa carrière sur ce concept de mechanical sympathy qui est comprendre les sous-jacents en dessous pour pouvoir faire des choses efficaces et les faire de manière maligne, etc et ça c'est un truc qui m'a marqué j'avoue c'est.
Bruno:
Marrant parce qu'effectivement il y a quelques épisodes j'ai eu un invité qui me disait que quand Lewis Hamilton il a un problème sur un tour de test il ne va pas voir les ingénieurs en disant il y a un clink clink quand je tourne à gauche il sait exactement qu'est-ce qui se passe à quel moment parce qu'il a une connaissance de la mécanique, de tout son véhicule d'un niveau de détail qui est absolument.
Thomas:
Pointu et tu vois Martin Thompson il expliquait des trucs de manière contre-intuitive être solide, c'est bon pour la latence il expliquait pourquoi c'est ça dans le code Et en Java particulièrement parce que si la donnée, Qui est censé être sollicité à peu près au même moment et colocalisé, en fait, tu as des invalidations de cache qui ne se font pas au niveau des processeurs. Il avait été assez loin dans la démarche on parlait de false sharing aussi c'est quand tu as parlé de processeur t'as différents niveaux de cache dans un processeur et sur des trucs de faible latence, quand tu paralélises aussi le truc que ton ennemi c'est des invalidations de cache t'as les données qui sont quasiment prêtes à être consommées au niveau de ton processeur et puis tout d'un coup c'était L2 le niveau de cache, il y a différents niveaux, et ben en fait si tu passes ton temps par ton code et ta façon de coder à faire invalider des caches en fait tes caches ils servent à rien et du coup tu vas souffrir en termes de latence alors là je te parle d'un truc c'est quand même c'est pas pour une appli de gestion c'est.
Bruno:
Exactement ce que j'allais dire c'est que là tu parles quand même de choses qui sont d'un niveau de détail en dehors de ces contextes là tu l'as jamais.
Thomas:
Réutilisé non c'est ça alors après tu peux l'avoir sur certains trucs de paralélisation en fait, Certaines notions que ça m'a appris, son principe c'était de dire que tu vas beaucoup plus vite en monosthread qu'en paralysant trop. Donc il expliquait pourquoi, de manière empirique, et puis aussi avec la théorie, etc. Et du coup, de retenir ça, de retenir que moi je pensais que quand on paralysait ça allait plus vite. Face à des gros volumes, j'entends. Lui il explique qu'en fait, un seul thread bien optimisé avec tout un tas de trucs qui ne sont pas pour les enfants, en termes d'applémentation il redéfinissait certaines collections il y avait des trucs mais il arrivait à montrer qu'avec un seul thread qui patate, le débit tu l'absores vachement plus vite qu'avec du multithread qui, va passer son temps à faire de l'administratif des contextes switch entre tel thread je te donne la priorité, attends-toi il y a un agent de la circulation qui dit au thread, vas-y toi, reprends recharge tout ton contexte en mémoire et en fait moi ça m'a aidé dans ma mentale de développeur à me dire, en fait, parfois, c'est contre-intuitif. Et parfois, même, ça vaut le coup d'aller expérimenter des choses parce que j'ai une croyance que ça, c'est mieux que ça, c'est plus rapide que ça. Et en fait, non. Ça, ça m'a été très utile aussi, cette approche-là qui l'a poussé.
Bruno:
Oui, mais tu vois, j'ai presque... Pour continuer sur l'analogie de la Formule 1, c'est comme si tu me disais que t'as eu besoin d'aller te frotter à Lewis Hamilton en pole position — On croit que j'étais nul. — Pour comprendre qu'il fallait mettre ton clignotant quand tu veux tourner à droite. Parce qu'en fait, tu vois, le niveau de technicité que t'évoques... Alors tu vois, je comprends. Je trouve ça hyper intéressant. J'ai appris les trucs en t'écoutant. Mais si ce que tu me dis, c'est que ça t'a permis d'apprendre que les solutions sont pas toujours évidentes dans notre métier... Tu vois, au final, la solution...
Thomas:
Elle est peut-être moins chère. Elle est peut-être plus simple pour arriver à cette conclusion.
Bruno:
Mais en même temps, est-ce qu'il y a moins cher pour arriver à cette conclusion ?
Thomas:
En tout cas, moi, ça m'a aidé... Alors oui, je te rejoins. C'est complètement biaisé. C'est sur un truc de niche. C'est peut-être 2% de tous les ingénieurs logiciels qui travaillent sur des sujets de faible latence et tout. Mais par contre, le truc que j'ai trouvé intéressant, c'était de me dire lutter contre ses croyances, penser contre soi. Donc moi, ça m'a été utile pour ça. Il m'est arrivé après dans d'autres sujets d'être confronté à des problématiques de performance, et c'est là où vraiment ce modèle mental de aller en parallèle ça va aller mieux, il est ultra répandu en fait et donc en fait ça m'a été quand même utile, sur des gros imports de fichiers sur tout un tas de trucs avec vraiment des volumes de me resservir de quelques observations faites par monsieur Martin Thompson et d'autres, pour au lieu de gérer au niveau logiciel même une problématique ? De me dire tiens à la base est-ce que le stockage qu'on a, est-ce que le modèle de stockage est-ce que le middleware ou est-ce que le protocole qu'on utilise et tout il est adapté, et donc est-ce que le format de sérialisation qu'on utilise est adapté là par contre ça m'a été utile même sur des applis dites de gestion, dans des scale-ups etc, bon après même dans cette scale-up c'est peut-être aller 10% des problématiques de la scale-up.
Bruno:
Ce qui reste quand même déjà en proportion plutôt pas mal.
Thomas:
Parce que les autres dépendaient de ça. Là par contre c'était 10% en termes de personnes concernées mais qui impactaient quasiment tout le monde.
Bruno:
Ce qui pose du coup aussi la question de est-ce que ça veut dire que, enfin pas ça veut dire mais est-ce que pour toi, le fait d'avoir vécu tout ça est aussi une nécessité pour arriver à des niveaux de poste et de responsabilité comme ce que tu as aujourd'hui. C'est-à-dire que tu ne peux pas être VP Engineering si t'as pas fait un peu de finance peut-être aussi un peu de hardware est-ce qu'on a vraiment besoin, d'avoir touché à tous ces sujets là ou sinon.
Thomas:
Est-ce qu'on peut l'apprendre autrement oui je pense qu'on peut l'apprendre autrement et en vrai je pense pas qu'on ait besoin de ça pour être en fait il y a plein de choses que tu peux apporter de valeur que tu peux apporter en tant que VPF Engineering, sans avoir fait ça c'est juste que moi c'était mon, c'était mon chemin c'était ma route, Un des trucs que j'apporte, c'est tout ce qui est les sujets problématiques d'infra, d'architecture technique et tout, c'est des trucs qui, souvent, j'arrive à spotter des trucs assez vite sur ça, les amis. Vous allez être motivé, mais je pense que... Est-ce que vous avez pensé à ça ? Est-ce que vous avez pensé à ci ? Au début, j'étais un peu en mode naïf, genre, non, mais ça, ça marchera jamais, attendez... Je l'ai fait de cette guerre, machin, tout.
Bruno:
Souvenez-vous en 82.
Thomas:
Il s'en fout, je regarde nos yeux, il dit, ok. C'est la dernière fois qu'on l'invite dans ce meeting, tu vois. Après, quand tu comprends comment... Faire évoquer ces questions-là aux gens et faire en sorte qu'ils se posent ces questions-là à tout, c'est mieux. Mais non, il y a plein de... Moi, j'en croise plein des VP of Engineering ou des Head of Engineering qui n'ont pas cette expérience-là et qui apportent quand même plein de valeurs. Ça dépend des sujets, je crois qu'ils bossent. Et puis, qui savent s'entourer des bonnes personnes aussi, puisque dans les équipes, tu as toujours des super experts ou experts, tu vois, qui... Donc là, être capable de capitaliser sur les bonnes personnes, sur les bons sujets, je pense que c'est primordial ça.
Bruno:
C'est vrai qu'on revient en fait à le côté très humain de notre métier en fait, d'autant qu'on a un métier aussi on passe beaucoup de temps aussi de transmission dans l'apprentissage, tu le disais tout à l'heure que tu transmets beaucoup à tes équipes on apprend beaucoup au contact des autres.
Thomas:
En fait ça c'est un truc que je me suis rendu compte assez tôt dans ma carrière, c'est que quand tu veux expliquer quelque chose à quelqu'un ça te force à enfin en tout cas moi c'était comme ça je le vivais ça me force à creuser un peu le sujet et donc je crois que c'est richard feyman le physicien qui a donné un truc je crois un principe de son de son de son nom là dessus il avait une méthode. Pour être sûr que ce sur quoi il réfléchissait et qu'il n'y avait pas de trou, pas d'angle mort, etc., il essayait d'expliquer. Il avait un petit carnet, a priori, la légende raconte un petit carnet, où il se parlait à lui-même comme s'il expliquait à sa grand-mère le concept. Bon, sauf que c'est de la physique fondamentale ou machin, mais en gros, son obsession, c'était d'arriver à formuler avec des mots simples et précis une problématique et de se dire, oula, quand j'ai des blancs, c'est un smell, quoi. Il y a un truc que je n'ai pas compris. Ou il y a un truc qui ne s'articule pas bien encore, et peut-être que j'ai un angle mort et qu'il faut que j'aille le creuser. Mais en fait, que ce soit pour construire des formations pour mes collègues, ou que ce soit pour construire des talks, ou que ce soit pour écrire des articles sur les sujets qui me tenaient à cœur et tout. Moi, j'ai toujours bien aimé regarder sous le tapis, regarder comment c'était fait, assembler et tout. Et bien en fait parfois ça m'est arrivé, de me dire ce truc là, c'était I think a weight, en dotnet quand c'est sorti etc, il y avait un truc dans mon modèle mental que j'arrivais pas à enfin j'arrivais pas à tout capter de qu'est-ce qui se passait, qu'est-ce qui était mobilisé au niveau du dotnet au niveau du système d'exploitation on.
Bruno:
A tous des histoires comme ça d'un concept qui paraît simple, qu'on a pas réussi à appréhender pour une raison expérée à.
Thomas:
Expliquer ces choses, Et donc, je m'étais dit, non, mais moi, il y a plein de fois dans mes journées où je me disais, mais comment ça marche, putain, et je n'y arrivais pas. Donc, je me suis dit, il faut absolument que j'arrive à comprendre comment ça marche. Et pour y arriver, je me suis dit, il faut que j'arrive à expliquer à un autre collègue que moi-même le truc. Et que, quelque soit ces questions, en gros, j'ai fait un peu le tour du truc. Et une fois que j'aurais fait ça, peut-être que je pourrais me dire que j'ai bien compris, que j'ai bien digéré. En fait, moi, ça a fait effectivement cet effet-là. Ça m'a forcé à me poser des questions. Mais qu'est-ce qui se passe ? quand il y a tel primitif qui est appelé en dotnet, au niveau du système d'exploitation, qu'est-ce qui se passe, et puis comment ça revient, et comment c'est géré, en termes de modèle de threading, j'avais fait beaucoup de multi-threadings aussi dans la finance, ça c'était à peu près ça allait quoi, mais malgré ces primitifs que j'avais déjà bien intégrés et digérés, il y a des trucs que j'arrivais pas à comprendre, comment se faisaient les retours, avec les I.O., avec le programme et tout, et donc ouais, expliquer. Une techno à soi-même ou aux autres je pense que c'est un bon moyen d'arriver à la comprendre enfin en tout cas si t'es rentier t'es rentière faut pas le faire sur tous les sujets et machin mais sur les trucs qui te grattent un peu les trucs où tu, où t'es le moins à l'aise pour expliquer à quelqu'un que tu onboardrais dans une équipe, quelqu'un, une junior ou un junior qui a débarqué dans l'équipe, et si on disait, tiens Thomas, c'est toi qui vas expliquer ça à cette personne-là, si tu sens qu'il y a 2-3 sujets, alors que tu les manipules au quotidien, où t'es pas capable de le faire, je pense que c'est le bon endroit pour essayer de faire ça.
Bruno:
Mais c'est d'ailleurs aussi un truc qui commence à émerger aussi dans la pratique du coding assisted by AI, c'est de dire que si tu peux pas expliquer en 30 secondes le code que t'as généré, tu vas commencer à empiler de la merde donc ça va être capable d'expliquer si c'est pas toi qui l'a écrit c'est pas grave mais il faut être capable d'expliquer.
Thomas:
Il y a un truc que je fais souvent de plus en plus souvent c'est les ADR mais donc les ADR c'est génial pour réfléchir et structurer sa pensée donc architecture, décision, d'accord pour les auditrices et auditeurs qui connaitraient pas encore, c'est de se dire sur une décision on va la documenter, déjà parce qu'en la documentant on va essayer de lutter contre nos angles morts et contre nos biais parce qu'en l'écrivant, si on n'a qu'un truc à dire c'est Jean-Michel qui adore ça et c'est le seul argument donc on va le faire et donc ça nous force à nous poser des questions, et en plus de ça, comme c'est documenté les nouvelles personnes qui arrivent sur le périmètre, elles s'enbordent plus rapidement et surtout ça évite souvent, je ne sais pas si c'était arrivé, tu travailles sur un projet puis quelqu'un qui dit putain mais qu'est-ce que c'est que ce truc qu'ils ont fait là mais c'est n'importe quoi mais comment c'est possible d'avoir fait un truc aussi bête, souvent en fait on a un biais de rétrospection c'est à dire qu'on ne sait pas ce qui était connu à l'époque au moment où la décision était prise est-ce qu'il y avait des contraintes est-ce qu'il y avait des choses qui et à l'époque ça avait du sens et c'est juste que ça a dérivé qu'on n'ait jamais revenu sur le sujet et qu'il y a eu d'autres trucs qui se sont greffés donc ça aide aussi. À prendre un peu de recul et... Et à intégrer un peu mieux la complexité de notre métier, etc. Et donc, du coup, peut-être avoir un peu plus d'humilité, je pense, par rapport aux gens qui étaient là avant nous. Mais ouais, donc, je reviens à mon truc d'ADR. Avant, c'était, on le faisait entre nous en équipe. Et puis, c'est quand même très cher parce que c'est beaucoup de discussions. Déjà, il faut prendre du recul face à la problématique. Déjà, il faut se rendre conflit avec problématique. Après, il faut prendre du recul. Après, il faut en discuter. Il faut se mettre d'accord. Il faut s'aligner. Et hop, on signe l'ADR et machin. Donc autant dire qu'on le faisait pas tous les 4 matins non plus, on le fait sur des trucs vraiment cardinaux importants sur le projet mais en fait avec l'IA ce que je me suis aperçu c'est que comme tout va très vite etc, il y a des choses, il y a des implicites que j'ai moi que ce soit en design, en termes de design en termes de fondamentaux ils sont tellement imprégnés en moi que je les vois plus il y a des choses, ça fait partie de ton quotidien tu les vois plus. Le fait de régulièrement demander à Claude de m'aider à formuler certains ADR sur certains sujets, en fait, il me pop des choses que lui, il voit, alors que moi, c'est un implicite. Et donc là, je trouve ça assez intéressant, parce que de plus en plus, j'arrive à prendre du recul par rapport à mes réflexes et à tout ce que je charge en moi et que je mets en moi dans mes solutions. Ça me permet de prendre un peu du recul. C'est comme si j'avais un copain ou un collègue qui me dit « Hum, en fait, ce que t'as fait, c'est ça. Et ça. Et ça. » Et en vrai, je suis très souvent d'accord avec même les arguments. C'est exactement pour les raisons qui m'évoquent que j'ai fait ces choix-là. Et donc ça, je trouve ça très agréable pour continuer d'apprendre et voir une grammaire, en fait. Une grammaire sur des principes de base et important.
Bruno:
Est-ce que tu auras un exemple précis d'un moment où ça t'a...
Thomas:
Un exemple précis, récent... C'est peut-être moins intéressant parce que c'est moins technique, mais en ce moment, je suis en train de travailler sur un second cerveau. En tant qu'Aid of Engineering, j'ai besoin d'avoir de l'outillage qui m'aide à survivre dans un environnement où il y a de l'info qui coule. Il n'y a pas dans l'Evelle, mais dans les Slack, dans les meetings, dans les transcripts, dans les Notions, dans les mails.
Bruno:
Il y a un nombre de robins d'informations.
Thomas:
C'est fou. et donc du coup si je veux pouvoir ne pas avoir toujours un petit temps de retard et comprendre ce qui se passe et pouvoir être proactif aussi par rapport au sujet comment je fais ? En fait je me suis fait un truc qui j'ai fait un truc un peu spécifique mais avec 2-3 idées que j'avais piochées à droite à gauche mais pas en mode cargo culte, vraiment en mode tiens ça c'est intéressant, une petite intuition et je pense qu'il me faut un système que je puisse requêter à tout moment à tout moment je lui pose une question il me répond immédiatement sur la base de tout ce qu'il a déjà appris jusqu'à maintenant, et qu'en parallèle, il me lance 2-3 agents qui vont aller sniffer tout ce qui s'est passé depuis la dernière fois pour en delta, rattraper le retard et mettre à jour toujours mon subtrat d'informations, et me dire au bout d'une minute ou deux, en fait, la réponse qui vient de te formuler, désolé, mais il y a eu un changement, entre-temps, il y a eu un meeting, ils ont pris telle décision. Donc ça, c'est le truc sur lequel je bosse et du coup, j'ai voulu le packager. Pour des product managers, pour des profils qui, vu que j'ai bien itéré pendant des mois, presque, maintenant, avec ce truc-là pour moi, je vois la valeur, et je vois la valeur pour les autres engineering managers qu'on a chez mon client, pour les product managers et product managers aussi. Et donc, je me suis dit, tiens, comment je peux le packager ce truc-là, sachant que c'est quand même un truc qui est... C'est comme un cerveau, ça doit être un peu souple. Moi, j'ai des problématiques en tant que head-off, que n'auront pas des engineering managers, que n'auront pas des product managers. Et donc, comment rester à un truc souple, mais qui apporte quand même de la valeur tout de suite, etc. Donc j'ai beaucoup travaillé, c'était la semaine dernière, pour packager ce truc-là, pour que tu puisses l'installer en une seule ligne. Genre, tu ouvres un clos, tu dis, je voudrais installer un second cerveau avec ce nom-là, en suivant l'URL de mon repo GitHub. Je voulais presque que mon père ou ma mère puissent l'installer, si j'exagère un peu. Et donc du coup j'ai travaillé là dessus et j'ai fait pas mal de choix sur comment je fais un installer, dans ce contexte il y a plein de trucs, il y a des plugins il y a des machins, mais ça ça nécessite quand même une connaissance de l'écosystème alors déjà c'est une dépendance avec l'écosystème cloud et puis ça nécessite une connaissance est-ce que des managers, vont aller à ce point dans le niveau de détail non, moi je veux quelque chose, j'ai une seule phrase à copier-coller et le truc va s'occuper de ça pour eux et du coup j'avais plein de choix. Qui était à prendre entre eux, ben... Je veux un seul repo, comment ça s'installe ? Initialement, Claude, il me proposait des designs vraiment genre... Le mieux et l'ennemi du bien, tu vois. Et donc, en gros, il essayait de me dire, OK, les gens, ils vont cloner ton repo, qui va être à la fois l'installeur et à la fois leur futur cerveau. Et du coup, une fois installé, il va falloir le modifier, l'arranger, et puis couper le lien, le cordon ombilical avec mon repo, tu vois, originel, etc. Et pour y arriver, ça nécessitait, en fait, il y avait des risques. Soit les gens, ils restaient connectés à mon repo et ils m'envoyaient possiblement des données sur mon repo. Parce que moi, dans mon harnais, il y a de l'autocommite push systématique pour tout, pour que l'afférence t'as rien à faire je pose des questions et ça sauvegarde tout, etc. Donc soit il y avait des trucs qui remontaient sur mon repo donc au risque pour les gens, et puis même j'ai pas envie puisque ça reste de voir leur truc, soit il y avait un risque de, des stratégies où ils coupent le truc, ils suppriment certains fichiers ils suppriment le repo guide par exemple de l'installeur, pour que le truc il vive sa vie, tu vois, machin puis d'un moment je me dis mais en fait de, complètement compte, parce que là, il essaie d'optimiser un truc. En fait, il y a deux problématiques. J'ai une problématique de, je veux un installeur, et j'ai une problématique de, l'installeur va générer un second cerveau pour la personne qui va l'utiliser. Et du coup, en découpant ce truc-là, ça a résolu plein de problèmes qu'il n'y avait plus, en fait. L'installeur, tu le mets dans un répertoire temporaire, tu peux l'enlever après. Et ton second cerveau, il n'aura jamais de lien avec moi, Thomas Pyrin. Et dans cette problématique bon après je le fais le soir donc peut-être que c'est ça qui fait que. Le soir t'es un peu plus feignant, enfin en tout cas moi je suis un peu plus feignant et donc je lui demande un peu plus d'aide que peut-être le matin tu vois si le matin je me force moi à driver un peu plus le design, la soirée je dis ah c'est quoi ton avis là tu... Après c'est moi qui décide mais bon en fait il y a eu pas mal de choix de design sur la langue, parce que je vais un report en anglais pour l'instant il est en français etc sur la découpage entre l'installeur et le second cerveau etc, où en fait je me suis dit ou la dépense avec la techno ce que j'ai fait mon second cerveau en fait il dépend quasiment pas de Claude, mais dans l'écosystème pour qu'il marche bien il y a des hooks, il y a des trucs pour l'autocomite et tout donc tu vois en fait les décisions de ça je le prends pas aujourd'hui mon second cerveau il marche que sur cloud, Et basta, donc faire un ADR où je l'exprime. Je m'étais dit dans ma tête, mais je ne l'avais pas inscrit. Le fait de lui demander de me faire des ADR sur ce truc-là, c'est que tous les gens qui voudraient venir maintenir ce truc-là, ils ne seront pas à faire toc-toc-toc dans ma tête. Je trouve ça très agréable, parce que ça fait ramasse-miettes tous les trucs. Les trucs que j'avais en tête, c'est l'ADR initial, où je l'ai sollicité. Il y a tous les autres trucs qui m'ont dit, mais au fait, t'as pas fait que ça comme choix. T'as fait ça, ça, ça. Est-ce que j'en fais des ADR ou pas ? Ah, intéressant. Et donc voilà.
Bruno:
— OK. Hyper intéressant. Pour terminer, pour essayer de conclure, parce que dans les auditeurs et auditrices d'ICTTD, il n'y a pas que des gens, forcément expérimentés. On a plein de gens qui sont actuellement étudiants ou jeunes diplômés. Alors certes, on fait un métier où on est senior au bout de 5 ans d'expérience, mais ça, c'est un autre débat. Qu'est-ce que tu donnerais comme conseil à des gens plus jeunes dans le métier pour qu'ils puissent facilement ou rapidement atteindre un niveau de maturité comme le tien sur des sujets techniques, d'organisation, d'avoir toute cette expérience-là.
Thomas:
Peut-être s'intéresser aux fondamentaux. Il y a plein de trucs qui sortent, des fraînements, des machins, des trucs, c'est super, c'est génial, c'est pratique, mais s'intéresser à certains fondamentaux techniques d'ingénieur et tout, je pense que c'est plus important, parce que pour un fondamental que tu apprends, tu as parfois 10 technos qui en découlent, et tu vois, donc en fait, le même, le retour sur investissement, entre guillemets, il est intéressant. Sur des fondamentaux techniques comment fonctionnent les choses, certains patterns aussi, donc ça je pense que c'est et d'ailleurs c'était un peu une obsession que moi j'avais, pareil pour un enjeu d'efficacité j'avais envie de retenir les fondamentaux et de pouvoir jouer avec une grammaire de base qui permettait en tant qu'architecte technique de proposer des solutions qui n'étaient pas trop déconnantes pour y arriver du coup en 2026 et plus, en fait c'est de capitaliser sur la partie IA, qui de toute façon s'impose à nous. Autant en faire quelque chose de bien et donc du coup moi à chaque fois que je fais des sessions, avec un Claude je veux apprendre des trucs je veux apprendre des trucs donc en fait c'est poser des questions, vraiment échanger, poser des questions et c'est surprenant tout ce qu'on arrive à apprendre, en fait, pour autant qu'on sache poser des questions. Voilà. Donc... Et si on ne sait pas quelles questions poser, on peut lui... Icebreaker, aller demander... Jamais creuser, poser des questions, etc. En fait, en vrai, il n'y a quasiment plus d'excuses pour pas y arriver, j'ai l'impression. Tu vois, on a... Même tout seul, même sans idées, en fait, c'est assez simple d'arriver à...
Bruno:
On peut poser des questions sans fin à un système qui a des réponses à apporter sur toi.
Thomas:
Bon, idéalement, par rapport au sujet qu'on est en train de faire, etc. Parce que c'est quand même là où, en fait, c'est là où quand tu vas poser les questions, tu vas pouvoir mettre en application, ou tu vas pouvoir te mettre en mouvement avec ce truc-là. Ça va venir enrichir ta réflexion et ta réalisation. Mais ouais, donc fondamentaux, et pour y arriver, c'est découvrir. Parce qu'en fait, je pense que c'est important en T, d'avoir une connaissance assez large de plein de sujets, et puis d'avoir quelques zones de profondeur, des zones où ça va t'intéresser plus et tu vas être un peu plus spécialiste. Je pense que c'est plus intéressant de travailler ça. Vraiment, déjà de savoir que les choses existent. Et après, tu sauras les trouver facilement.
Bruno:
Canon. Merci beaucoup, Thomas, pour toute cette discussion. J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu voudrais partager avec l'ensemble des auditeuristes ?
Thomas:
Alors, oui, c'est ce qu'on disait tout à l'heure. En commençant, je... Alors, j'ai pas d'idée en ce moment. Si, peut-être un film, du coup. Un film, Escape from the 20th Century. C'est un film chinois. c'est un film totalement barré c'est un premier film de quelqu'un dont j'ai oublié le nom, qui a été pas super bien distribué maintenant ça se trouve en VOD et c'est un mélange de Quentin Tarantino de Kung Fu Shaolin et de science fiction, donc c'est autant dire, je suis pas sûr de le vendre bien comme ça mais en gros c'est complètement barré, c'est très créatif c'est un mélange fond et forme, et le pitch c'est trois adolescents en Chine qui découvrent en tombant C'est comme Spider-Man, ils tombent dans un truc, ça leur donne un super pouvoir. Le super pouvoir, c'est à chaque fois qu'ils éternuent, ils se projettent 20 ans ou 25 ans dans le futur. Et quand ils éternuent dans le futur, ils se reviennent dans leur peau et donc ils passent leur temps de passer de adolescent à adulte et de voir ce qu'ils sont devenus. Ce que ça veut dire de vieillir, ce que ça veut dire de... Et en fait, c'est à la fois intéressant sur le fond, sur la forme, c'est à hurler de rire, on passe des rires aux larmes, c'est fou. C'est une expérience que je trouve assez chouette.
Bruno:
On mettra quelques liens en description pour que j'en puisse le retrouver, bien évidemment. Et dernière question la plus importante de ce podcast, Thomas, est-ce que tu es plutôt espace ou tabulation ?
Thomas:
En fait, je m'en fous. Moi, ce qui m'intéresse plus, c'est la convention de l'équipe. Donc voilà. Même depuis que chez l'XP, l'équipe, c'est... Donc, allez, si mon cœur parlait, ça serait la tabulation, peut-être. Par contre, en fait, je m'en fous, parce que de toute façon, j'utilise des outils, même avant l'IA, on utilisait des outils, des linter, des machins, des trucs qui auto-formataient. On se met d'accord avec l'équipe et on l'applique. Moi, ça me va très bien.
Bruno:
Merci beaucoup, Thomas. Merci à tous d'avoir suivi cet épisode. On a appris plein de trucs, on n'a pas évoqué tous les sujets qu'on ait prévu d'évoquer avec Thomas, mais je pense qu'il y a beaucoup d'apprentissage et je pense qu'effectivement il faut en fait, je pense que le truc fondamental de notre métier c'est d'aller poser des questions, que ce soit à votre IA ou à d'autres développeurs ou développeuses. C'est comme ça qu'on apprend énormément de choses, il faut creuser, il faut aller chercher c'est très certainement des choses que vous faites déjà parce que vous écoutez ce podcast donc a priori vous êtes quand même dans une démarche de vous poser des questions, mais il y a d'autres contenus qui existent aussi pour le faire donc restez sur celui-là mais ajoutez-en c'est aussi hyper intéressant moi je vous remercie comme toujours de partager ce podcast autour de vous je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.
