Productivité sans IA : Le mythe de la productivité

Bruno — En ce moment, dans les comités de direction, on les voit tous jouer à la même surenchère avec la productivité des devs. Avec l'IA, on va augmenter la productivité de 50%, annonce le Borde en janvier. Six mois plus tard, on est passé à 100% et puis des Borde vraiment très motivés peuvent monter jusqu'à 200% avant la fin de l'année. Le chiffre est gonflé à chaque restitution, mais personne ne se pose vraiment la question de qu'est-ce qu'on mesure. La productivité d'un dev, c'est quoi concrètement ? Des lignes de code ? Des tickets fermés ? Des nombres de vendredi soir où la prod tient sans qu'on ait besoin de sortir la streinte ? Mais tout ça sans jamais chercher la bonne définition. Ce board, lui, a toujours la même réponse. On va y arriver grâce à l'IA. Mais alors, est-ce que l'IA est vraiment le seul levier pour qu'un dev travaille mieux ? Ou c'est juste le plus facile à vendre en comité de direction ? Et si le vrai problème, ce n'était pas les devs, mais la façon dont on leur donne du travail, et surtout la vraie martingale, ce ne serait pas plutôt de faire croire à la direction qu'on gagne en productivité sans vraiment utiliser l'IA au final. Pour répondre à ces questions gonflées, je ne reçois pas le baron de Munchausen, mais il s'y connaît en personne qui exagère. Bastien, bonjour.

Bastien — Bonjour Bruno.

Bruno — Alors Bastien, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Bastien — Je pense qu'il y en a un certain nombre, bien sûr. Je suis une forme d'appartement. Je suis un ancien appartement atypique. J'ai passé la moitié de ma vie dans l'entrepreneuriat et dans le conseil et l'autre moitié de ma vie dans des rôles de leadership tech dans différentes industries aujourd'hui mon actualité c'est que je suis le CIO, d'une entreprise qui s'appelle lesfurets.com que t'as bien connu et il y a quelques camarades qui sont passés sur ton podcast, et qu'est-ce que ça veut dire CIO, desfurets.com ça veut dire que je suis en charge de la tech desfurets.com donc de toutes les équipes d'ingénierie, de data qui contribuent à fabriquer les solutions que lesfurets.com mettre à disposition du marché nos utilisateurs, clients finaux, peut-être vous en ligne, et puis nos partenaires, notamment les assureurs. Je m'occupe aussi du développement de l'IA au sein des ferrets.com, donc je pense la thématique notamment d'épisodes. Et je dis que je suis un appartement atypique juste pour la petite taille où je suis ingénieur de formation, ça c'est un truc pas original. Mais j'ai commencé par faire des études de droit. Mais comme j'étais un geek dans ma chambre, j'ai fini mes études de droit et je me suis, il a raté un truc donc je suis retourné à l'école et avant de travailler donc voilà qui je suis.

Bruno — Donc effectivement l'idée c'est de parler de cette tendance qu'on voit beaucoup d'entreprises qui disent les développeurs et développeuses doivent travailler plus vite, grâce à l'IA donc effectivement moi j'ai été au sein des furets pendant l'année à peu près 2025 de souvenirs, c'était effectivement des sujets qui commençaient à popper assez fortement j'ai quitté les furets au moment où Claude Code a fait sa grosse livraison sa grosse sortie, effectivement j'ai eu beaucoup de plaisir à travailler avec les équipes chez LF, qu'est-ce que Claude Code a changé dans la manière de travailler chez LF et aussi dans ses objectifs qui ont été donnés aux équipes de dev.

Bastien — Alors il y a une réponse courte à ta question rien, rien et potentiellement tout alors. Effectivement Effectivement, pour des raisons assez simples et des raisons de conviction. C'est-à-dire que, comme toutes les entreprises, et particulièrement les entreprises de tech, on a un challenge qui est la productivité, la capacité à mettre en marché un certain nombre de solutions. Et ce qu'on voit, c'est que l'identification assez naturelle, c'est le temps long, il vient du dev. En fait, c'est toujours inacceptable que quand on a une opportunité business, ou quand on a une opportunité parce qu'on a le flair, qu'il y a une feature qui va tout tuer et que les utilisateurs c'est ce dont ils ont besoin, etc. », Et bien le problème, c'est le dev. Et donc effectivement, moi, quand j'arrive chez les Furets, juste après toi. La thématique, c'est on a plein de talents, on a une équipe, mais on a une frustration qui est on n'arrive pas à être assez rapide. C'est pas intentionnel on n'est pas content des équipes c'est en fait on a des nouveaux entrants et on se dit aussi que les IA potentiellement elles peuvent faire la même chose que nous en tant qu'entreprise en tant que service et donc tu vois, tu parles en introduction très rigolote tu parles du fait que les boards en fait insistent, bah le board se pose la question, en fait est-ce qu'on a un avenir et donc le problème c'est que pour avoir un avenir ou prouver qu'on a un avenir, il faut augmenter quelque part la productivité c'est une des hypothèses assez évidentes et donc le point dur ça devient comment on fait pour accélérer le dev. C'est pas notre première année dans le travail il y a des années c'était, est-ce qu'on peut recruter des gens et puis on peut pas tout de suite, alors on va prendre des consultants et en fait on augmentait le nombre de personnes, en réalité on augmentait la complexité on augmentait plein d'autres trucs qui faisaient qu'au final on était jamais content donc il y a une forme de constance de toute façon je suis jamais content c'est jamais assez rapide, c'est jamais assez bien et puis c'est pas ce que j'ai demandé bref il y a toujours ces problèmes là, et effectivement l'IA elle apportait ce côté un peu nouveau, mais aussi de nouvelles questions, c'est à dire oui quand je démarre on me dit est-ce qu'une des hypothèses c'est pas de fournir des outils aux développeurs, mais la réponse elle est pas si simple que ça parce que, on va développer mais t'as un, est-ce que les développeurs sont prêts, Ça, c'est vraiment un vrai sujet. Sauf, dans une relation maître-esclave, ça ne marche pas aussi facilement comme ça, avec l'être humain. Il y a une nouvelle économie qui est basée sur le token. Toujours la deuxième question qui vient, c'est est-ce qu'on peut le mettre ? Et alors, combien ça coûte ? Et après, c'est alors, combien de temps ça va prendre ? Et donc, tu n'as pas cette réponse. Ce n'est pas si évidente, cette réponse. Puis en plus, c'est une réponse qui évolue dans le temps avec plein de facteurs et plein de variables que tu ne peux pas maîtriser, comme par exemple le fait que l'orchestration côté logiciel chez Anthropik, en fait, elle change. Donc, en fait, la consommation de tokens pour une tâche constante, elle n'est pas la même dans le temps. Tu as aussi des évolutions arbitraires parce que peut-être que les investisseurs d'Anthropik, ils disent au bout d'un moment, ce serait bien que vous gagnez un peu d'argent. Donc, venez, on monte le prix du token. Enfin, il y a plein de paramètres. Donc il y a ça, il y a la question de c'est quoi le bon outil, qu'est-ce qu'on doit faire, etc. Donc voilà, oui, quand je suis arrivé effectivement chez les furets, après ton passage, on en avait parlé entre le moment où je suis arrivé et où tu es parti, il n'y avait pas vraiment de réponse. Moi, il y avait une chose qui était sûre chez moi, c'est que le temps a renforcé ma conviction, c'est que je ne suis pas sûr qu'on pose bien le problème quand on voit les choses comme ça.

Bruno — Alors c'est vrai que la première objection qu'on pourrait avoir c'est de dire en fait si tu veux augmenter la productivité des devs. Le truc est loin parce que comme tu le dis le propos dans la majeur des cas je dis pas que c'est toujours le cas mais dans la majeur des cas quand un board dit il faut augmenter la productivité, des développeurs et développeuses c'est jamais pour dire ils sont trop lents, ils sont mauvais, ils savent pas faire leur boulot c'est juste pour dire on a des outils qui nous permettent peut-être de faire plus vite ce qu'on faisait avant dans un temps donné. Mais quand on dit ça en fait il faut définir comment est-ce qu'on mesure la productivité en tant que telle d'un dev, c'est aussi une espèce de truc après lequel on court en permanence, c'est comment est-ce que tu peux considérer qu'un développeur ou une développeuse est effectivement productif par rapport à une autre. On a plein de métriques qui existent, mais on a parfois l'impression que c'est impalpable. Et tu as évoqué tout à l'heure aussi cette capacité à pouvoir... Produire plus vite. Mais est-ce qu'au final, dans tous les métiers où il y a de la production, que ce soit la production d'une voiture, d'une montre, comme on l'évoquait tout à l'heure, ou d'autres objets, tu as toujours ce sujet-là, en fait, de te dire... En fait, tu as une capacité contrainte, que tu ne peux pas compresser, à produire des choses. Donc est-ce qu'il n'y a pas aussi un problème de compréhension de notre métier ? Parce qu'effectivement, je suis d'accord avec toi, je partage ça depuis des années, les gens trouvent que le dev, c'est toujours trop long, on met toujours trop de temps à faire un truc, mais est-ce que c'est pas aussi parce qu'on a quoi qu'il arrive un métier d'expertise, d'un certain niveau de complexité et qu'en fait il y a des choses qui sont incompressibles, mais que du coup on n'arrive pas à expliquer pour pouvoir dire bah en fait mesure-nous sur tel, tel critère tu vois peut-être pas très clair comme question si si je pense qu'il y a en tout.

Bastien — Cas peut-être que je ne l'ai pas comprise mais je te ferai une réponse j'espère.

Bruno — Que ce sera.

Bastien — À peu près clair en fait, la façon où je vois le sujet, elle est protéiforme. Développeur, c'est pas notaire. On pourrait résumer ça comme ça. Je t'ai dit, moi j'ai fait des études de droit. Être avocat, par exemple, c'est avoir passé un diplôme qui a un nom, qui est standard, qui est le même pour tout le monde, peu importe l'école qu'il délivre. En fait, t'as un certain nombre de fondamentaux et t'as un certain nombre de procédures à respecter qui sont définies comme une loi, ça s'impose. Le développement, c'est quelque chose qui est ouvert à tout le monde. Pas besoin d'être ingénieur, il n'y a pas de titre nécessaire pour être développeur. Il y a des gens qui sont développeurs qui sont excellents et qui ne sont pas du tout ingénieurs. Il y a des gens qui sont des ingénieurs généralistes qui sont d'excellents développeurs. On parlait de Fabien justement pour un autre épisode. Et donc, ça crée déjà quelque chose, une forme d'impossibilité à parler un langage qu'on comprend. Un langage, c'est codifié. Une syntaxe dans nos métiers, c'est codifié. Quand on dit un développeur dans la bouche de quelqu'un, même d'un développeur, ce n'est pas une réalité unique. Donc il y a déjà un problème dans la qualification je vais plus loin c'est long le dev mais des fois le dev est fait, c'est la mise en prod c'est le déploiement qui est long parce que peut-être on est en train de faire évoluer la plateforme et qu'on veut standardiser quelque chose ou qu'en fait on reprend des services on avait un service monolithique puis on a des services serverless qui sont, nouveaux et qu'on essaye de packager, de rendre plus autonome et en fait on a fait le dev mais on ne livre pas parce qu'il y a d'autres travaux sur le chemin critique qui nécessitent d'être fait, en fait c'est pas un dev le problème, tu vois, donc il y a déjà moi quand on me le dit et pour travailler, pour arrêter moi-même développeur à travailler avec ces équipes là déjà pour moi la proposition enfin l'assertion, si tu veux, elle est mal posée, donc ça il y a déjà ce phénomène là de quoi on parle, est-ce que c'est le dev est-ce que c'est le déploiement, est-ce que c'est autre chose, est-ce que c'est l'ingénierie produit est-ce que c'est le truc un peu typique c'est tu vas voir un dev parce qu'effectivement on est long. Et il dit, je ne comprends pas l'aspect. L'aspect, ce n'est pas le dev qui l'a fait. Parfois, ça pourrait être le dev qui l'a fait. On reviendra plus tard. Donc déjà, premièrement, il y a un sujet de qu'est-ce que c'est que le dev. Ensuite, oui, tu as raison. Quelle est la mesure ? En fait, je reviens à l'exemple du notaire ou de l'avocat, surtout de l'avocat. L'avocat, la mesure, c'est t'as gagné ou t'as perdu ton procès ou t'as peut-être économiquement, entre j'ai gagné, j'ai dépensé tant, tu sais que t'as à peu près des standards pour dire que c'est un bon avocat ou un mauvais avocat. Nous, dans notre métier, il y a plein de frameworks, il y a corps forts, il y a des gens qui sont à fond sur les métriques de Scrum, par exemple, des points de complexité, des tableaux qui vont démontrer qu'en fait on a été super bon, quand tu racontes ça à un DAF ça n'a aucun sens tu vois, on a fait des tailles de t-shirt combien de temps ça va prendre ? Bah c'est L on a un problème où les gens ne se comprennent pas, c'est à dire que je pense qu'entre nous des fois on se comprend pas, entre nous c'est à dire nous le monde tech, il n'y a pas que le développeur il y a, moi j'associe les gens qui font du produit, au monde tech j'associe des fois des business analystes ou des technicaux je sais pas quoi, ça porte plein de noms dans plein d'entreprises différentes, les équipes plutôt infra les équipes cyber les seules qui arrivent souvent à comprendre c'est des gens qui sont un peu touche à tout, il y en a encore encore une fois, dans notre épisode on parlait de. Du fait qu'une certaine époque en fait quand on était développeur, on était bidouilleur on touche à tout, on le fait de moins en moins en fait parce qu'on a spécialisé les rôles donc en fait pour moi, quand on parle de ce truc là on parle d'un truc qui est déjà mal défini parce qu'il n'y a pas une mesure, il n'y a pas une définition et il n'y a pas de standard ou de contrat d'établissement donc tu vois quand t'arrives moi j'ai toujours entendu, j'ai fait quelques entreprises dans ma vie, là si je prends les trois dernières entreprises dans lesquelles je suis arrivé j'ai toujours entendu la même chose, c'est pas assez rapide on se comprend pas, et pour autant ça n'a jamais été la même cause et la solution qui a été mise en oeuvre il y a une constante et moi j'en fais pas une théorie mais c'est une conviction forte chez moi j'y reviendrai tout à l'heure. Et il y a eu des solutions quand même qui ont varié il y a un sujet qui est, est-ce qu'on pense que tu vois je sais pas quand tu lis, là j'ai lu cette semaine qu'aux Etats-Unis, il y avait des chercheurs qui avaient trouvé un médicament pour résoudre ou améliorer le traitement du cancer du pancréas. Alors, c'est bon, on est tranquille quand on a un cancer du pancréas, on est détendu. Non, parce que c'est de la médecine et que c'est aussi compliqué et que c'est une science qui est évolutive. J'aime pas trop la définition de science exacte et pas exacte, mais c'est une science évolutive. Et nous, notre métier, c'est un métier qui a toujours une part d'artisanat, qui a évolué dans le temps, qui s'est développé, en fait on est quand même dans un nouveau métier moi quand j'ai commencé je me rappelle que j'allais au, je sais pas comment ça s'appelle le CDI ou je sais pas quoi, quand tu cherchais tes formations, tes machins, quand d'abord j'ai fait des études de droit à Sciences Po c'était marqué dans les métiers bien stables bien compris etc, les nouveaux métiers les nouveaux métiers c'était les métiers du numérique et du numérique en digital, tout a évolué et s'est développé je pense que déjà il y a une vraie conscience à avoir nous il faut qu'on ait cette conscience là je rajoute un dernier point euh, L'archétype du développeur pour les gens qui ne sont pas développeurs, c'est quoi ? C'est un peu comme l'archétype du hacker, tu vois le gars avec un hoodie qui est dans l'ombre...

Bruno — Il est seul face à son écran.

Bastien — Seul face à son écran, tu vois. Et on dit souvent que les techs, c'est des introvertis, etc. Ça, c'est une caricature, parce que c'est vrai et faux. Mais un truc qui est sûr, c'est qu'on n'est généralement pas bon dans la communication. Et que... On va plutôt avoir tendance à prendre la sauce entre nous, à chercher un peu les coupables, voilà. Mais on ne va pas forcément communiquer au sens où on va se rapprocher des autres, essayer de parler le même langage. Et il y a eu plein de tentatives, les méthodes agiles, les trucs comme ça, etc. Mais je ne suis pas sûr qu'on n'a pas recréé le même contexte avec autant de silos. Déjà pour moi, la question n'est pas bien posée, si tu veux.

Bruno — Il y a aussi un cliché qu'on nous rend souvent, c'est que pour les développeurs et développeuses, rien n'est jamais possible. Quand on vient voir un développeur ou une développeuse en disant j'aimerais faire ça c'est pas possible.

Bastien — C'est très compliqué même pas de réponse parfois un truc que ça m'inspirait quand t'as dit j'avais pas forcément pensé dans la préparation mais, en fait on dit je suis au métier quel que soit je suis au board, je suis au métier, c'est trop long, mais t'as aussi un inconfort que le développeur doit toujours anticiper qui est il y a trop d'incidents ou ça bug et en fait il y a toujours ce côté time to market versus, industrialisation, robustesse des fois des certifications encore une fois de contexte moi je suis lesfuret.com, c'est l'image d'une marque forte que je mets en défaut si ce que je livre ça plante le site est down on va avoir des articles dans la presse, pas parce qu'on est méta ou je sais pas quoi c'est parce qu'on est une marque, les furets c'est une marque hyper connue moi c'est la première fois de ma vie j'ai travaillé dans des grands groupes c'est la première fois de ma vie que quand je dis je travaille là les gens savent où je travaille.

Bruno — Ce qui est assez dingue et encore parce que le site est down au final c'est un petit problème, parce que tu pourras avoir bien pire tu peux avoir un leak de data tu, fais une mauvaise réponse aux mauvais clients aux mauvais moments ça peut être catastrophique mais là où je te rejoins moi je peux.

Bastien — Me le permettre ce que je veux dire c'est que si je suis dans la pharma, Et que, tu vois, par exemple, j'ai un traitement qui va avec une application comme ça commence à se développer. Je ne peux pas me permettre d'avoir fait quelque chose qui expose un risque. Donc, en fait, quand la même personne ou quelqu'un qui a, admettons, quelqu'un qui travaille au marketing chez les furets, puis qui va travailler au marketing chez Pierre Fabre après et qui va dire la même, qui va avoir la même affirmation, c'est trop long. En fait la longueur sera beaucoup plus négociable chez les furets qu'elle ne le sera par nature, tu vois, chez Pierre Fab parce qu'en fait le contexte et le risque associé à ça n'est pas le même tu vois, il y a cette espèce de mauvaise définition du problème et, du sentiment associé alors.

Bruno — Je suis entièrement d'accord avec toi on s'écarte peut-être un peu du sujet mais en fait, ce que ça ce que tu évoques que je trouve intéressant. C'est qu'effectivement je pense qu'on a un métier en fait on est associé tu le, disais que dans la tech quand tu parles de la tech t'associes aussi bien les gens côté produit que les développeurs développeuses que les gens à la data, les gens à l'infra, les gens à la cyber donc effectivement on a beaucoup de métiers et effectivement quand les gens disent la tech c'est trop long le truc c'est que ça englobe tout ça et en fait je pense qu'on a aussi un métier je l'ai évoqué dans pas mal de podcasts. Et d'ailleurs on l'a redit aussi tout à l'heure c'est que effectivement toi et moi quand on a commencé à notre métier, on pouvait tout savoir. C'est-à-dire que le nombre de choses à savoir était quand même, c'était conséquent, mais c'était relativement restreint, surtout par rapport à aujourd'hui. Aujourd'hui, je trouve qu'il y a une complexité du métier, c'est-à-dire qu'on nous demande de maîtriser des patterns d'architecture, des patterns de déploiement, des concepts de cybersécurité, des concepts de data, d'intégrité de la donnée, de pérennité de l'information. Enfin, il y a tout un ensemble de choses qu'il faut pouvoir maîtriser. Et je pense qu'effectivement, quand quelqu'un dit « Attends, moi j'ai une super idée, il faudrait une feature, parce que quand je clique là, l'écran devient bleu. Super idée, sauf qu'en fait, il y a tout un ensemble d'arborescences que les gens ne voient pas. Et du coup, la question, c'est est-ce qu'il faut qu'on éclate complètement les métiers ? C'est-à-dire que du coup, le board se retrouve à traiter avec un réseau de la data, un réseau de la cyber. Et donc, ils comprennent pourquoi est-ce que ça passe par tout ce chemin-là. Ou est-ce qu'il faut qu'on arrive à mieux expliquer pourquoi notre métier est vraiment compliqué ? Ou encore, autre option, peut-être qu'en fait, notre métier n'est pas si compliqué que ça. Mais que c'est nous, ingénieurs, entre autres, qui avons tendance à nous dire non mais en fait c'est compliqué parce qu'il faut faire tout ça alors qu'en fait il n'y a peut-être pas besoin de faire tout ça.

Bastien — Ouais en fait c'est une bonne question j'ai une sensation assez dingue depuis 5 ans qui est, qu'on a créé un sacré sac de nœuds. Et je dis on, c'est-à-dire tous les gens qui travaillent dans cet écosystème tech. À partir du moment où on a commencé à considérer la notion de produit, nous, quand on a commencé, il y avait un certain nombre de langages, il n'y avait pas tant de séparation que ça entre la logique, les règles, l'algorithmique, l'accès à la donnée, la présentation dans des interfaces. Puis ça a beaucoup évolué. Aujourd'hui on est dans des paradigmes éclatés plutôt microscopiques donc avec de l'orchestration l'orchestration c'est énormément, complexifié il y a des pratiques, des méthodologies qui sont rajoutées avec un jargon à chaque fois chaque truc vient avec son jargon les langages viennent avec leur syntaxe et ensuite nous tous les concepts qu'on a rajoutés dessus viennent avec leur, viennent avec leur propre jargon je me rappelle moi quand j'ai bossé en 2018 j'ai commencé dans une boîte de médias. On a construit les premières API avec des ingénieurs qui sont complètement capables de comprendre ce que c'est qu'une API mais c'était, à l'eau Houston c'était une dinguerie il y avait une fierté d'avoir fait une API alors que c'est quelque chose de, quand même relativement trivial etc mais on a je pense séparé ou créé de la complexité techniquement ou architecturalement de plus en plus, on a été poussé par des paradigmes notamment de boîtes très pointues dans la tech tu vois c'est comme les concepts par exemple modern data stack etc où en fait on a sur-séparé des concepts, on a commencé à spécialiser les métiers, nous les tech je prends l'exemple du développeur et du data engineer, et on en a fait deux mondes différents c'est un monde différent.

Bruno — Qui se parlent de moins en moins en plus.

Bastien — Qui se parlent de moins en moins et qui sont aidés par moi je ne suis pas un grand fan de l'agilité, telle qu'elle est définie dans les méthodes je pense que c'est mon avis personnel je pense que c'est plutôt des usines à fabriquer des silos et à séparer les gens de la tech du reste de l'écosystème avec lequel ils doivent interagir que ce soit tes collègues qui ont dit métier ou que ce soit tes clients, tes utilisateurs je trouve que ça t'éloigne de ça, parce que ça recrée des micro-silos avec leur propre jargon, leur propre machin, encore une fois je reprends l'exemple du, PM ou du dev qui dit au DAF, c'est elle de quoi tu parles ? Je comprends rien à la compta mais je comprends, les bits d'ail sont définis d'une manière unique, moi quand tu me dis elle et que elle c'est pas la même chose dans tel contexte et dans tel contexte mais que tu sais pas me l'expliquer c'est pas quelque chose qui crée la confiance Donc je pense qu'on a trop spécialisé les métiers. Encore une fois, j'ai quelqu'un que je connais et que j'aime bien, qui est l'ancien CIO de la SCORE, qui m'a dit un jour « Bastien, moi j'ai les équipes data à ce moment-là à la SCORE ». Il me dit « Explique-moi ce que c'est qu'un data engineer s'il te plaît ». C'est pas la différence. Et après, on commence à regarder parce qu'on a commencé à faire un data engineer, c'est devenu un analytics engineer, s'il fait ci ou s'il fait ça, et des fois, il y a un BI engineer, il y a un data ops, etc. Alors que je reviens à ce que tu disais au début, en fait, quand on a été formé, beaucoup de gens qui font ça aujourd'hui, et je n'ai rien contre ces métiers-là, et j'en ai dans mes équipes, mais ils savent ce que je dis, là-dessus, je ne m'en cache pas, c'est des gens qui ont commencé à faire tout ça, en fait, et à relativement maîtriser. Encore une fois, c'est comme dans la médecine, sans doute, on ne peut pas être bon à tout, tu as le médecin généraliste qui te réoriente vers quelqu'un qui est plus spécialisé dans un truc, ça je pense que c'est toujours bon, mais je pense qu'on est allé à une extrême qui a tendu à dégrader la productivité. Tu fabriques ta montre, tu sais comment tu fabriques ta montre, ton processus il est défini par ton produit. Nous, dans la tech, je trouve que ce qu'on a fait, c'est qu'on n'a pas défini notre processus par rapport à notre produit. On a plutôt défini notre processus par rapport à des problèmes granulaires qu'on a voulu adresser par des méthodologies donc en fait je trouve qu'on a contribué à créer une grande complexité humaine architecturale, et qui du coup aujourd'hui fait que tu vois moi des fois il y a des réunions et tout le monde doit avoir voix au chapitre, parce que c'est l'angle du spécialiste et il y a des gens qui ont bien un avis, mais qui l'expriment pas parce que c'est pas le spécialiste et qu'il faut laisser exister tout le monde ce qui est très bien moi je suis pour, le débat d'idées et puis l'émulation collective l'intelligence collective ça fait du sens mais tu vois je trouve qu'il y a un phénomène qui est on a beaucoup trop compliqué le truc mais en.

Bruno — Fait ce qui est compliqué si je reprends ton analogique avec la création des montres, Ta montre, en fait, c'est un objet qui a un but précis. Là où aussi la difficulté, entre guillemets, avec le code, je pense que c'est là aussi où on a ajouté beaucoup de complexité, c'est que tu peux écrire du code aussi bien pour guider un missile, que pour faire une application qui te fait un bruit de prout quand tu appuies sur un bouton sur ton téléphone. Tu vois, le delta est fou. Et quand tu parles aussi de la complexification, enfin, de ces hyper spécialisations, je pense qu'il y a aussi un autre biais qui est arrivé, c'est que je pense que t'as besoin d'avoir ces niveaux d'expertise hyper précis sur certains métiers, parce que quand t'as une équipe d'ingénieurs où t'as 400 personnes, et que t'as des infras, alors en Facebook c'est encore plus sûr mais quand t'as des boîtes de cette taille là en fait t'as des problématiques qui sont tellement folles que t'as besoin d'avoir, ce découpage, ces niveaux d'expertise mais qu'en fait je pense qu'on a redescendu cette expertise, enfin ce besoin d'expertise trop bas, je pense que t'as des boîtes, ou t'as des équipes tech de peut-être 10, 15, 20 personnes qui ont pas besoin, qui devraient pas avoir besoin des méthodes Scrum, de ces trucs-là, parce que ça devrait être plus simple.

Bastien — En fait, j'ai, dans mon parcours, quand je faisais du conseil, je faisais du conseil un peu spécial, parce que c'est du genre du conseil où on fabriquait des trucs au final, c'est du conseil plutôt de l'ingénierie dans le conseil, bref. Mais j'ai eu un truc qui m'a pas mal marqué, j'ai bossé pas mal dans l'énergie. Et moi je suis passionné d'automobiles j'adore les bagnoles et donc tout ce qui me rapprochait du monde d'automobiles moi m'excite, alors c'est pas très contemporain et sexy ce que je vais dire mais j'ai bossé pour une compagnie pétrolière, en mission et j'étais presque excité parce que j'étais pas loin, c'était pas des voitures c'était des camions et c'était sur des énergies, renouvelables mais j'ai travaillé avec ces équipes là, donc des équipes d'ingénierie des grands plateaux d'ingénierie qui fabriquaient l'infrastructure pour, fournir l'énergie au destinataire qui était la compagnie avec sa flotte de camions, et qui réfléchissait à leur processus. Ils avaient une ingénierie du planning. Moi qui viens du code, je suis ingénieur, j'ai trouvé ça complètement farfelu la première fois que je l'ai vu. Ce qui était intéressant en rencontrant les gens, c'est qu'il y avait plein de gens qui étaient là, qui étaient des ingénieurs méca souvent et qui avaient avant travaillé chez Volkswagen, qui avaient ensuite bossé chez Technip FMC, dans la construction de plateformes et qui travaillait là chez l'énergéticien. Donc, ils avaient fait trois métiers différents. Le premier truc qu'ils me disaient, quand je leur demandais, mais c'est quoi dire entre votre truc là ? Ils me disaient, nous, on fait l'ingénierie du processus. Et en fait, notre processus, avant de commencer à produire. On réfléchit à ce qu'on doit produire. Et je leur dis, mais dans votre monde, il n'y a pas des concepts ou des paradigmes. C'était à fond, moi, quand j'ai fait ces missions-là, c'était à fond Scrum, Scrum at scale, safe et tout. Et moi, j'avais tout le monde autour de moi qui, dès qu'il y avait un projet, tu vois, dans les boîtes, commençait à dire, c'est la tribe bidule, le machin. Bah non, ça, c'est une guilde. Ah bah non, attends, c'est, je sais pas quoi, avec toujours, moi, la sensation que, déjà, moi, j'étais là, genre, attends, c'est quoi déjà le truc qui est marqué dans le machin, sachant que Spotify Ce qui faille modèle dit, c'est surtout pas un modèle. Mais nous, on l'applique, nous les techs, comme un modèle à la lettre. Et les boîtes qui, mal aidées par des gens qui les ont mal conseillées, je pense, en ont fait des orgas durs alors que c'est des orgas molles. Moi, je suis un grand fan de Dali. La matière molle, les Dali, c'est fondamental. Donc, tu vois, moi, j'ai beaucoup été inspiré par ces gens-là de l'industrie qui me disaient en fait, on se remet toujours en question en tant qu'ingénieur sur notre processus de travail. Et à un problème, ils reviennent aux problèmes c'est notre métier de résoudre des problèmes à un problème, une solution une hypothèse, une solution et nous ce qu'on fait souvent dans la tech c'est alors on fait du produit. Donc, comme on fait du produit, et peu importe le produit, tu fais un logiciel comptable ou tu fais un système embarqué pour ce que tu disais, c'est toujours du code et ce n'est pas la même chose, mais la destination du code, elle change quand même beaucoup. Et donc le processus nécessaire, l'homologation par exemple dans la santé pour des questions réglementaires ou dans la banque, versus t'es une start-up et tu lances un produit, machin c'est pas la même chose donc pour moi, je reviens à ce qu'on disait au début mais time to market se définit pas en soi, et ça peut pas être une impression de le processus, ça devrait pas être supplément l'application d'une méthode parce que t'as un coach agile en interne ou que t'as un, tu vois il y a eu beaucoup de gens je trouve qu'ils se sont cherchés, qu'ils étaient devs qui se sont dit, tiens, qu'est-ce que je vais devenir ? Je vais devenir freelance. Et puis tiens, il y a un bon credo avec l'agilité et tout. Plein de gens qui se sont dit, on va faire de l'agilité parce qu'en fait, on n'arrive pas à se parler. C'est comme si, tu vois, c'est de la thérapie de couple. Je n'arrive pas à parler à ma femme, je vais aller voir un coach qui va me dire, applique Scrum, fais des daily avec ta femme pour t'aligner. Enfin, j'exagère, tu vois, mais c'est un peu ça le truc. Et donc, pour moi, dans nos métiers, je trouve qu'on gagnerait à s'inspirer, qu'on soit ingénieur ou pas. Encore une fois on a un métier artisanal et c'est toute la beauté de la fabrication, du code quoi et les IA je pense qu'elles changent pas tant ça que, enfin c'est des c'est des automates qui fabriquent du truc artisanal en fait et. On gagnerait, et moi c'est un peu, tu vois, encore une fois, pas du tout la prétention d'avoir réussi des trucs fantastiques, mais les quelques réussites que j'ai avec les équipes, où on a réussi à créer la confiance, parce que le premier signal c'est j'ai confiance, mon écosystème me fait confiance, mes utilisateurs ils ont confiance en mon produit, mes collègues, mes partenaires en interne ils ont confiance en moi, etc. C'est là où tu vois que ça commence à frémir puis après quand ton produit, il évolue, il scale t'en fous d'avoir appliqué telle ou telle méthode, c'est ça le but quand toi en tant qu'ingénieur t'as compris ça je pense que t'as tout compris et après l'IA elle peut s'inscrire là dedans mais la première chose à comprendre c'est qu'est-ce qu'on attend de moi quel problème je dois vraiment résoudre et un truc je pense qu'on fait pas assez, dans le dev c'est la remise en question on parlait de l'épisode avec Fabien sur l'open source, c'est un gars qui se remet en question parce que c'est un gars brillant qui dit j'ai le syndrome de l'imposteur, je sais, plus j'avance en âge, plus je sais que je sais rien et je prends un exemple t'es dans, moi j'ai vécu des post-mortem tu vois on fait des post-mortem, plein de fois on a un incident, on fait un post-mortem mais on le fait mal, moi j'ai vu des vrais post-mortem j'ai vu sur des plateaux où ils fabriquaient des plateformes pétrolières, les ingénieurs faire des post-mortem parce qu'il y avait un tuyau qui avait transpiré. Tu vois, ils transpirent, ça a telle et telle propriété, ça change la qualité du produit, ça n'a pas été déclaré, ça n'a pas été senti, le client n'a rien vu. Eux l'ont détecté, donc ils ont mis des mesures et ils ne savent pas quelles mesures ils vont mettre. Tu reviens aux questions de c'est quoi la mesure ? Ils n'en savent rien la mesure qu'ils vont mettre, ils n'ont pas de mesure standard. Ils font l'ingénierie de la mesure parce qu'elle correspond au niveau de risque, elle correspond au niveau d'attendu, au niveau de qualité attendue qui se discute avec les parties prenantes. Nous on fait rarement ça. Je ne dis pas jamais parce que ça doit exister, mais on le fait rarement. Et quand on traite un problème souvent on a tendance à l'isoler, on a le ticket de bug, alors oui il y a route cause analysis, il y a machin, on fait la réunion puis alors au pire des cas on va prendre j'ai rien contre les coachs agiles je tiens à le dire bravo les coachs agiles mais parfois ça arrive, on va avoir quelqu'un, un intermédiaire qui va nous aider. Mais en fait on regarde pas le problème on regarde un ticket on va le corriger, je l'ai corrigé et en fait on a, à minima on est content parce qu'on l'a corrigé, on va dire c'est corrigé sauf qu'on a cassé la confiance, tu vois et je pense qu'il y a un truc dans nos métiers qui est l'ingénierie du problème, et l'inspiration sur l'ingénierie en général et je pense qu'il y a des belles inspirations dans d'autres pratiques d'ingénierie qui sont moins, elles ont des dogmes aussi ils ont des méthodes projet, des trucs comme ça, PMP je sais pas quoi, très bien nous on attend, c'est-à-dire il y a des frameworks par exemple CMMI ou des trucs comme ça, pour moi ça c'est la mort je le dis parce que je veux pas, rien contre les gens qui le mettent en place mais pour moi on arrête de réfléchir. Et donc c'est pas vraiment ce que j'aime faire mais voilà je pense que tu vois il y a un premier truc l'IA elle s'inscrit dans une ingénierie de problème qu'est-ce que je veux réussir et pour moi la question un board me dit bah voilà il faut aller plus vite quel est ton appétit au risque ? Combien de temps j'ai pour aller plus vite aussi ? Quel est ton appétit au risque ? A quel point c'est tolérable que ce soit cassé ? Et souvent tu te rends compte, les équipes d'ingénierie, elles ont envie en fait. Les devs, ils ont envie que ça se passe bien. Toujours.

Bruno — Et puis on a envie d'aller vite aussi.

Bastien — Oui, bien sûr. Mais des fois, on ne se sent pas autorisé à prendre un risque. Et moi, tout le monde réunion que j'ai faite, où le reproche qu'on fait souvent aux équipes, c'est pas chez Furesse, et en général, c'est... Je reprends ton exemple. Bon, alors, je veux ça. J'ai cette idée. Combien de temps ça prend ? Et on va avoir tendance à répondre comme ça en live. Déjà, un, pourquoi on répond tout de suite ? Des fois, la bonne réponse, c'est un, très intéressant. Donne-moi un jour. Je te pose des questions ou je peux m'asseoir à côté de toi, combien de fois on dit ça ? Attends, ok, très bien, j'ai compris tu veux bien que je m'assoie à côté de toi ? Moi ça c'est un truc que j'ai appris mon premier job, j'ai fait ce qu'on appelait du commando le commando c'est quoi dans la finance ? C'est dans la finance l'archétype du commando c'est dans la banque d'investissement t'es assis à côté d'un trader qui veut faire quelque chose et qui te demande de faire du VBA rapido pour le fabriquer donc je l'ai fait ça, dans d'autres trucs mais pour des gérants alors c'était pas aussi rapide que le trader qui souvent te hurle dessus pour te demander un truc mais au delà des hurlements ça t'apprend deux choses, ça t'apprend déjà à te détendre parce que tu te fais crier dessus que les gens sont pas contents et à pas le prendre personnellement, parce que des fois nous, quand on dit du mal de notre code.

Bruno — On prend personne c'est moi que.

Bastien — T'attaques c'est dur parce que c'est pas bien ce que j'ai fait, je suis nul et déjà ça tue toute possibilité de collaborer correctement parce que tu l'as mal pris donc ça c'est une bonne école parce qu'on se prend tellement plein la tronche qu'au bout d'un moment on dit non mais c'est lui qui a un problème, ou on a un problème ensemble mais on va y arriver tu vois il y a ça deuxième truc c'est que, t'es assis à côté des gens et tu comprends et tu vois je revends mon exemple des plateformes pétrolières, bah les mecs ils allaient voir le tuyau le tuyau il était au milieu d'une il était à 200 mètres de profondeur dans une mer glaciale il allait mettre son scaphandre le gars il descendait il allait voir le tuyau alors qu'il y avait une caméra qui lui avait filmé le truc il avait toutes les mesures et tout, il allait voir. Et moi, je me disais, c'est fou, il va voir. Et ils répondaient, ils avaient des gars, c'était des millions d'euros à l'heure, qui partaient quand tu pouvais pas avancer sur un chantier comme ça. C'était, je crois, 7 ou 8 millions d'euros par heure.

Bruno — Oui, parce que la plateforme est arrêtée le temps qu'il descend et qu'il regardait le tuyau.

Bastien — Dans la minute, t'avais le CEO d'une grande compagnie pétrolière qui tutoyait, tous les dirigeants de la planète, qui t'appelait avec ton boss qui descendait et qui était vraiment pas sympa. Et le gars disait, Je n'ai pas la réponse, je vais aller voir le tuyau. Et il allait voir le tuyau et il investissait du temps. Et en fait, il ne laissait pas d'autres possibilités. C'était en gros, tapez-moi dessus, faites ce que vous voulez, je vais aller voir le tuyau. Il allait voir le tuyau, il revenait, il débriefait avec les équipes, paf, et ils y teraient. Ils n'avaient pas tout de suite la réponse. Mais là, par contre, ils avaient une capacité à aller super vite, à sortir plein d'hypothèses en brainstorm, machin, sur des plateaux énormes. Et moi, tu vois, c'est un truc que j'essaye de reproduire avec les équipes en disant, ok on a ça mais on arrête de penser par rapport aux bonnes pratiques, et j'adore les Brandball Lunch les bonnes pratiques et tout, je suis le premier consommateur de ça c'est des inspirations pour moi qui te donnent des idées pour générer des hypothèses mais c'est pas des règles à appliquer c'est pas de la jurisprudence, c'est pas un texte et ce qui marche pour Spotify, marche pas pour les Furet, marche pas pour Spaki, Doctolib ou je sais pas quoi et en fait ça tu vois ce travail là fondamental c'est un vrai truc, et c'est une de mes convictions pour lesquelles, tu peux mettre toute l'IA que tu veux si tu continues à fonctionner comme ça c'est à dire répondre. Injonction-réponse injonction-réponse, injonction-réponse tu continues à faire ce qu'on a toujours fait, et c'est ce qui crée la dette technique souvent dans le code c'est un patch pour un problème qu'on a vu à un endroit et on a pourtant, dans plein de méthodos, la route cause la route cause, la route cause, oui mais la dette technique le temps, on n'a plus le temps, on ne peut plus arbitrer, c'est plus le moment on n'a pas d'appétit au risque, etc, alors que sur une plateforme pétrolière ou tu vois quand ils sont dans l'espace là et qu'il y a un problème, ils paniquent pas les gens, et c'est pas trivial parce que t'es je sais pas où moi j'ai le vertige déjà là sur une chaise t'imagines tu vois et il y a ça il y a cette question de gérer le temps, c'est je vais avoir une attitude et je pense que ça c'est un truc qu'on devrait plus reproduire et je reviens, à ce qu'on disait sur la spécialisation des métiers, pour moi ça ça enlève un truc fondamental pour nous qui est la responsabilité parce que quand le gars qui s'occupe de l'extraction et de l'orchestration de la donnée, c'est deux personnes, c'est plus de ta faute. Et quand tu fais ça à multiples échelles, t'as beau bien t'entendre et tout, ce que tu vas envoyer comme message, c'est pas de ma faute. Et donc, où est l'ownership, où est la responsabilité, où est le rôle ? Donc ça, pour moi, c'est le premier truc qu'il faut adresser dans ces cas.

Bruno — Donc, quand on te dit qu'il faut augmenter la productivité grâce à l'IA, toi, ta première réponse, c'est de réorganiser la manière dont on travaille, et de voir peut-être plus tard si on ajoute de l'IA dans tout ça.

Bastien — Ouais, moi je tenais un exemple concret. que tu connais, mais je pense que les auditeurs ne connaissent pas le nerf de la guerre de notre métier à nous et ce sur quoi on est jugé en fait, un site comme un comparateur et ça c'est d'ailleurs un truc qui m'a choqué c'est que plein de gens dans l'équipe mais choqués pas négativement je l'ai dit à, l'équipe ils ne sont pas étonnés c'est que plein de gens ne savaient pas comment gagner de l'argent, Et toute notre énergie est tournée vers l'utilisateur final qui nous rapporte zéro. En fait, quand les gens comparent des assurances, ce n'est pas l'utilisateur directement qui nous ramène de l'argent. Ce qui nous ramène de l'argent, c'est le partenaire au final qui a bénéficié d'un nouveau contrat et d'un nouveau client. Et ça va dépendre de plein de paramètres qui sont très différents de ce que les gens peuvent imaginer comme dans les mécaniques de marketplace. En fait, la comparaison, c'est très en faveur des utilisateurs. Et le client et celui qu'on doit chouchouter plus, normalement, c'est l'assureur pour nous parce que c'est lui qui nous paye. Et nous, on chouchoute les deux côtés. On considère que pour que ça se passe bien avec un assureur, il faut que ça se passe hyper bien avec un utilisateur. Mais moi, mes devs, certains, voyaient la source de revenus directement chez l'utilisateur. En fait, un truc fondamental pour nous, c'est notre capacité à intégrer des nouvelles offres de partenaires et c'est ça qui crée la confiance pour que les partenaires nous donnent des meilleures conditions qui vont générer des meilleurs tarifs pour les utilisateurs. Et un des problèmes qu'on avait, c'était le time to market d'une intégration. En fait, moi, de manière très candide, quand je suis arrivé, quand on m'a expliqué qu'on faisait du développement de backend spécifique pour s'intégrer avec un partenaire, Je me suis dit, mais what ? On ramène du business à des gens et on fait de leur fèvrerie. Donc, on a des centaines de back-end, de services spécialisés. Des fois, 10, 20, 30, 40, 50 pour un même partenaire parce qu'on s'adapte à eux. Et on fait du sur-mesure. Et la méthode, c'est la leur, etc. Et donc, on a une équipe interne plus une équipe offshore plus une équipe côté commercial qui fait la relation avec le client. Enfin, il y a trois ou quatre équipes côté commerce. Il y a au moins deux équipes côté tech chez nous qui font ça et ce que j'entends c'est quatre types de trucs c'est franchement les gens des furets que ce soit au commerce, c'est la voix des partenaires, ils sont hyper sympas vous êtes super réactifs mais qu'est-ce que c'est long vous êtes les plus longs, j'ai les équipes commerciales qui disent nous ça commence à être un problème parce que. Notre concurrent direct ou nos concurrents directs sont hyper bons là-dedans, et je dis c'est quoi être bon ? Bah une intégration c'est à peu près deux mois quand je regarde il y en a qui font deux mois on arrive à les faire en deux mois, mais bon déjà on mesure pas très bien parce que je vois que le ticket il a été créé il y a un an mais on l'a fait en deux mois donc en fait il y a déjà une mauvaise perception, des gens qui disent bah c'est hyper long ça dure un an, non c'est à dire pas un an ça a duré deux mois et demi mais le ticket il a été créé il y a un an et tout le reporting il est fait sur le ticket et la date de création du ticket dans Jira, sauf qu'on a oublié de se dire que en fait on l'a créé comme un playsolder, Donc déjà, ça génère non-confiance entre le commerce et la tech et les gens de la tech commencent à s'énerver parce qu'ils sont tenus responsables de trucs, dont ils ne sont pas responsables, ce n'est pas eux qui ont créé ce ticket. Et jusque-là, on n'a pas forcément eu le temps de faire le travail de se dire « mais en fait, regardez, on l'a créé, ce n'est pas grave, tout va bien. Ah, c'est que ça ! » Déjà, ça met les gens dans un mindset un peu différent. Voilà. Et donc, on se dit, qu'est-ce qu'on fait ? En fait, ça, on se rend compte que... Enfin, moi, je me rends compte que c'est un truc super important, ce time-to-market de l'intégration. Et que ce truc-là, ça va avoir deux ou trois bénéfices pour nous. Premier, c'est restaurer la confiance ou améliorer la confiance entre le commerce et la tech pour faire plus de choses ensemble. Deux, satisfaire les partenaires. Trois, générer du business. Voilà. Et donc, c'est ce truc-là. Après, on fait une analyse, comme tout le monde. Ok c'est quoi la situation, on se rend compte qu'on a une architecture monolithique que l'orchestration elle est faite en dur dans le code il y a plein de trucs comme ça qui sont ok, qui ont été fait à une époque pour une bonne raison, on regarde ça a été fait comme ça, alors la méthode et les paradigmes modernes me disent que c'est pas comme ça qu'il faut faire, mais bon la résolution du problème elle m'explique quand même que c'est comme ça donc moi j'ai des gens, des tiers notamment on a une société sœur en Angleterre avec des gens avec qui on collabore beaucoup, on a un même actionnaire, un même honneur, eux me disent tu peux pas fonctionner comme ça il faut découpler en théorie c'est vrai.

Bruno — Et la théorie est toujours vraie sauf dans la pratique.

Bastien — Exactement et j'ai pas le passeport pour la théorie donc je leur dis super très bien j'en discute avec les équipes et il y a plusieurs points de vue il y a ceux qui disent ouais il faut le faire mais c'est un an et demi, donc en fait ça veut dire que moi je dois dire aux commerces et aux clients vous attendez un an et demi dans un an et demi on vous fait ça en deux mois comme vous l'avez demandé mais qu'est-ce qui me dit que dans un an le partenaire en face, il ne mettra pas deux jours ou deux heures. Il y en a d'autres qui me disent, il faut faire un truc standard, tu vas vendre au partenaire le fait qu'il va s'adapter à nous. J'ai essayé. Je me dis merci, mais non merci. Très bien, ce n'est pas ça qu'on attend de vous. Je comprends. Et donc, tu te dis, je ne peux pas augmenter les équipes, je ne peux pas investir plus. Faire des travaux de restructuring ou de refactoring trop profond, ça ne marche pas. Il y a l'IA. Donc, on se dit, tiens, on va utiliser l'IA. Mais on n'a pas vraiment fait de test, on n'a pas choisi les outils. Et la première question qu'on se pose, c'est, quel outil ? Comment je fais ? Où est-ce que je le mets ? Je vois qu'il y a des gens, en creusant toujours, Je vois qu'il y a des gens qui ont testé des trucs, mais je suis dans une situation un peu compliquée. Et je continue à creuser avec les équipes. Quand je dis « Jeux », c'est vraiment collectif. Puis, je dis « Ok, on va regarder. Je veux des mauvais signaux. Je prends les pires dossiers. Je prends des dossiers moyens et je les analyse, je revois. Les tickets ne me donnent rien, donc j'appelle les gens, je vais les voir. Je m'assois à côté des gens du commerce. On rencontre des clients, on va les voir, on discute avec eux et tout. », Et je me dis, mais on fait mal les choses, il y a notre processus qui n'est pas adapté, donc on avait des steps rigides qu'on suivait, et en fait, on créait du temps, parce qu'on avait créé des séquences, et on faisait avancer ces séquences qui déclenchaient la mesure, alors qu'en réalité. Aucun travail au préparatoire n'était déjà prêt. La readiness n'était pas là, mais dans Jira, ça disait qu'on avait commencé. Donc on lançait un truc, la step one, parce qu'on voulait prendre de l'avance, ça ne servait à rien du tout. Puis la step 2, la step 3, la step 4 donc j'ai dit est-ce qu'il y a un monde dans lequel on fait voler ça et on réinvente le process donc on a beaucoup travaillé sur c'est quoi le bon process pour intégrer un partenaire, et quand tu tapes au process c'est les rôles, les responsabilités aussi c'est qui fait quoi, à quel moment, etc et en réalité je te fais l'histoire courte ce qui marche c'est de simplifier le process d'avoir moins d'étapes, d'en faire plus d'éviter les temps morts de démarrer le compte, au bon moment et de le terminer au bon moment quand tu as la maîtrise du process Un exemple, moi je livre en recette, des intégrations, les gens vont tester les prix. Mais moi si le partenaire qui est un grand établissement, un grand assureur, il n'a pas le temps de le faire et qu'il y a 150 personnes chez eux, j'ai aucune capacité de leur dire soyez un ou si vous voulez je le teste pour vous, c'est contractuel, c'est compliqué, c'est leur process. Donc moi je peux pas être mesuré là dessus ça marche pas, c'est pas un truc sur lequel j'ai la main je ne peux pas résoudre ce problème et je le dis, donc on se dit nous notre responsabilité elle est là et là dessus voilà ce qu'est la mesure qu'on attend, comment on définit la mesure, bah pas avec corps fort ou je sais pas quoi je suis retourné voir le commerce et j'ai dit c'est quoi que vous voulez atteindre vous voulez être comme les autres ou vous voulez être les meilleurs ils me disent on veut être les meilleurs sur le marché j'ai dit ok combien de temps. 15 jours 15 jours, ok donc ça veut dire que si on fait 15 jours sur le pipe d'intégration qu'on a là combien il faut qu'on en fasse en 6 mois ? 15 le semestre précédent on en avait fait 2. Bon, histoire courte, on en a fait 24. Avec deux recettes, déjà une négative, zéro IA, zéro, pas volontairement. Juste, ça c'est un plus, mais on ne va pas chercher le plus quand on ne sait pas faire les fondations. Donc on a fait, on a revu le process, on l'a simplifié, on a changé les choses, on a rassemblé les étapes, on les a parallélisées au lieu de les mettre en séquence, on a fait un travail de réflexion, bon sens. Deux on a responsabilité les ingénieurs, un truc qui était compliqué c'est que en gros le partenaire il a un modèle de données nous on a un modèle de données et donc on doit faire un mapping entre les deux, pas fondamental sauf qu'on a des objets qui sont compliqués on a des définitions qui sont compliquées en fait on a des fichiers Excel horribles avec 35 onglets et je sais pas combien de milliers de lignes à chaque fois, et ce truc là était envoyé par un commercial à quelqu'un qui était quelqu'un du marketing chez le partenaire qui allait à quelqu'un à la tech mais qui n'était pas tech, c'était un business analyst qui ne connaissait pas l'API, qui l'envoyait à quelqu'un et donc ça avait un temps fou et c'était faux on s'est dit ok, est-ce qu'il y a un partenaire qui est ok de nous voir et moi j'avais plein de gens qui sont hyper connaissants enfin hyper sachants d'un point de vue métier d'un point de vue technique côté commerce mais ils ne sont pas techniques. Qu'est-ce qu'on fait, c'est pas mieux de rapprocher des gens techniques et de les mettre ensemble donc on a responsabilisé les ingénieurs et on leur a dit, vous allez aller voir directement vos homologues chez les partenaires et c'est vous qui le faites Vous n'attendez pas que ce soit fait et que ce soit mal fait. Ils ne se plaignaient pas méchamment. Mais j'avoue, quand on vous reproche à bon escient, encore une fois, personne n'avait tort. Mais quand on vous reproche de ne pas l'avoir fait assez vite, vous vous dites, c'est mal rempli, tu m'envoies un truc boisé et moi, je vais payer le but pour caisser. Donc, on a changé ça et on a réussi à obtenir des résultats incroyables. Là, par exemple, ce mois-ci, c'est dingue. C'est le mois d'août, tout est fermé. Tu connais le mois d'août. Moi, je suis parti en vacances le 7 août. Le 4 août, on me dit qu'il faut qu'on fasse 7 back-end pour un partenaire pour le 10 septembre. Il y a un an, tu peux en attester, on aurait dit... Bon courage.

Bruno — 2027 ?

Bastien — Ouais.

Bruno — On aurait dit 7 ans, 2027, ça marche.

Bastien — C'est fait, on n'est pas le 10, c'est déjà fait. Et on a mis 0 IA, etc. On n'a pas encore revu... Il y a plein de choses qu'on a faites maintenant en parallèle pour améliorer l'architecture, mais tout ce temps qu'on a gagné, il a eu plusieurs effets. C'est un, on a responsabilisé les devs. Aujourd'hui, le dev, il a un vrai rôle, il est identifié par le commerce, c'est beaucoup plus valorisant, ils font des trucs beaucoup plus intéressants. Cette tâche, elle était vraiment ingrate, donc on avait tendance à l'obscuriser pour que nos ressources internes elles travaillent sur des trucs à plus haute valeur ajoutée il y a une valeur ajoutée à ça, ça permet de mieux comprendre les choses quand on revoit l'architecture de notre plateforme en fait quand on connait ça très bien, on a de meilleures idées et ça vient générer de la valeur ajoutée pas uniquement pour le tech lead mais vraiment pour tous les lèvres plus de responsabilité et beaucoup plus de business aujourd'hui on est dans une posture, on a une offre commerciale, où on a mis en place une relation avec les ingénieurs En fait, on ne fait plus que vendre des leads qualifiés à nos partenaires, on vend des projets tech. Aujourd'hui, on résout des problèmes. Si un de nos partenaires a un problème en GIO. On va essayer de résoudre le problème avec eux en envoyant nos ingénieurs et en réfléchissant avec une méthode. Donc on a réfléchi à, c'est différent comme problème, donc c'est pas la même méthode. J'ai pas la méthode A qui s'applique à tous mes cas, donc Scrum ou je sais pas quoi. J'ai Scrum qui s'applique à certaines choses. J'ai la méthode d'intégration qui s'applique aux intégrations et j'ai pour les projets partenaires la même méthode. Et ça nous a poussé à réfléchir à quel est le rôle du dev, est-ce que c'est le même rôle et donc il y a des conséquences là-dessus comme on déspécialise les rôles, donc le premier phénomène, j'ai recruté un VP Engineering moi et tu sais, le rôle était ouvert. Quand je suis arrivé et c'était pour prendre en charge les devs et la raison c'était tout le monde peut pas reporter au CTO parce que c'est pas possible et c'est vrai et faux, selon moi parce que c'est pareil est-ce qu'on a les bonnes conversations est-ce qu'on se pose des bons trucs, est-ce que c'est vraiment à moi de valider un truc qui aurait pu être fait même s'ils se sont plantés mais il y avait une forme de peur de se planter pas le droit, bref la première chose que j'ai fait c'est que j'ai dit, je réunis toutes les équipes j'avais trois équipes séparées j'avais une équipe dev que tu connais, j'avais une équipe data engineering et j'avais une équipe analytics and science, j'ai fusionné les trois équipes même patron, que je place pas comme un patron au sens il s'assoit, il tient audience sous un arbre quoi, mais c'est quelqu'un qui a fait ces métiers là. Qui pratique, qui est proche du problème, qui est aussi impliqué dans les projets. En fait, il n'attend pas que les équipes lui disent voilà quel a été le problème. En fait, il est avec les équipes. Donc la discussion, ce n'est pas la même. Ce n'est pas je te raconte, attends, je réfléchis. Enfin, tu me racontes, attends, je réfléchis. C'est ok les gars, moi j'ai pensé à ça. Qu'est-ce que vous avez comme idée ? Je vais essayer de le faire et vous ? Donc on avance beaucoup plus vite. On a réuni les équipes. Ce n'est pas encore complet cet effort-là. mais moi pour moi on avait des squads très dev tu le sais, moi je veux que dans la squad alors pas un pour un etc parce qu'on a plusieurs squads comme plein de boîtes mais à notre échelle que les gens de l'infra soient là parce que j'ai aussi le problème avec le fait que ils sont pas au bon moment donc des fois on les met trop tôt des fois on les met trop tard 90% du temps on les met trop tard, et donc après on gère on s'est plus priorisé ils ont pas l'historique ils ont pas transpiré ou suer le problème ils le connaissent pas ils savent pas le pitcher donc ils entendent du téléphone arabe qui leur dit, c'est ça le truc moi je pense que et ça peut fausser, ça peut biaiser le truc mon idée c'est rapprocher les gens les faire bosser ensemble, et les responsabiliser c'est à dire que j'ai pas besoin que tout le monde soit impliqué sur chacun des sujets par contre je veux que les sujets soient directs que les gens soient directement en prise avec les sujets donc ils sont. Presque les égaux aujourd'hui des PM c'est à dire qu'on est capable de faire un ticket tout seul sans le PM on est capable d'aller dans un meeting sans le PM avec un client On est capable d'aller avec le commercial voir un client chez le client. Donc ça, ça a changé et ça a changé, si ça t'intéresse, la perspective aussi de carrière, je pourrais y revenir, mais voilà un peu le succès. Et encore une fois, ça part pas d'un principe qui est je veux pas dire et je crois pas à l'IA. Moi, je crois beaucoup à l'IA et en parallèle, on en a fait un peu, mais l'IA va pas me faire gagner ce temps.

Bruno — L'idée c'était de se dire, vaut mieux revoir la manière dont on travaille avant de mettre de l'IA, parce qu'en fait l'IA, on le dit tout le temps, c'est garbage in, garbage out, c'est-à-dire qu'en fait, si tu accélères un process qui ne fonctionne pas, en fait tu vas juste plus vite dans le mur, ou tu accélères la production de dettes techniques ou de merde, tout genre de choses.

Bastien — Et tu peux t'en ficher, comme tu l'as dit. Je te donne un autre exemple. Par exemple, on a des interfaces en interne qui sont des back-office qui étaient, pour plein de raisons, c'est sur une URL qui n'a aucun rapport avec le schmilblick, machin, bon bref. On leur a développé ce truc bon ben on a fait un coup de codex on avait nous c'est simple on avait. Via notre société soeur un compte chat GPT que la plupart des gens au métier utilisaient quand codex est sorti il y a un dev puis un deuxième dev qui ont dit tiens j'ai testé un truc ils ont essayé ils ont commencé à le montrer aux autres, 3-4 ont bien aimé c'est le truc parfait où ça vient des gens et ça n'a pas été poussé par le haut Moi je leur disais J'utilisais de plus en plus Et je ne comprenais pas qu'on n'ait pas L'appétit d'aller tester, Quand ChatGPT a fait son public release Je ne sais plus quelle version Fin 2022, Je me rappelle, j'avais dans mon équipe, j'étais en Angleterre à cette époque-là, j'avais dans mon équipe déjà trois mecs qui avaient testé sur le code. Le jour où c'était public release. Moi, je savais pas que ça existait. Enfin, j'avais pas vu la public release. Et donc, j'ai vu ce truc, j'ai dit, c'est quoi ce machin ? Je savais pas ce que c'était. Et c'est eux qui m'ont montré pour du code. Donc, quand je suis arrivé là-bas et que je me suis dit, mais y en a aucun qui n'utilise rien, et qui réfléchissent à comment on fait un bon prompt avant de faire un prompt, ça serait bien d'aller faire une formation. Je me suis dit qu'il y avait un truc qui allait pas. versus ce que j'avais connu ailleurs ou que j'avais vu ailleurs ou partout dans le monde ou même des gens pas tech, ils se sont dit génial, j'ai plus la barrière, j'y vais, donc ils ont commencé comme ça et oui c'est un complément, aujourd'hui honnêtement, je sais pas bien l'utiliser c'est à dire que j'ai pas de truc que je trouve vraiment hyper efficace. Nos petits camarades de la Père Fidalbion, notre société sœur en Angleterre, eux ils ont carrément des équipes d'agents donc ils ont deux types ils ont trois types de délivreries Ils ont fait toute une segmentation par type de criticité, de features, qui est sans doute ce que j'aurais imaginé faire, mais sans me fixer un objectif d'avoir tout couvert, parce que c'est peu usine à gaz aussi. Mais ils ont fait ça. Ils ont donc un mode qui est 100% artisanal, qu'ils appellent de leur vœu à réduire au minimum. Ils ont un mode hybride qui est une augmentation, mais c'est vraiment de l'automatisation. C'est vraiment pas je prompte pour faire du code c'est vraiment le refactor in sur telle feature hop il est automatique après t'as fait des années qu'on peut faire de la génération de code sans faire de l'IA, ou qu'on peut faire de la génération de docs sans faire de l'IA bref ou de l'abstraction de schéma enfin bon bref on peut faire plein de trucs sans avoir appel à l'IA mais ils ont mis tout ça et puis ils ont, vraiment du développement pur agentique où c'est lancé par un PRD donc. C'est fait par n'importe qui même par notre chairman, Et ces produits livrés. Et ça peut faire peur, tu vois, tu peux te dire, mais c'est complètement dingue. Enfin, à quoi on sert dans ce cadre-là ? Mais quand c'est pensé, encore une fois, par rapport à un problème ou par rapport à quelque chose, c'est plutôt bien. Donc, tu vois, nous, on est en train de dire, on a fait ce travail sur notre process, l'organisation aussi, ce qu'on attend d'un ingénieur. Pareil, les carrières changent. Tu vois, enfin, je caricature, mais t'es dans une boîte, sauf si t'es freelance, passionné. Donc t'as les vrais purs et durs qui sont devs comme Fabien qui se présente comme un dev ingénieur développeur et Advitam Eternam, et j'espère qu'on sera tous un peu comme ça et puis t'as les gens dans les entreprises qui veulent évoluer en salaire, évoluer en responsabilité mais c'est quoi la carrière souvent c'est dev, tech lead qui associe un rôle de manager, et puis pour ceux qui sont chauds et qui ont de la chance CTO, engineering VP CIO, je sais pas quoi. Pour moi ça c'est pas forcément la carrière future de tous les développeurs, je pense qu'il y a une voie plus forte vers l'expertise mais qui est expertise qui se déspécialise, une expertise par exemple de généraliste dans l'ingénierie ou dans l'architecture redonner ses lettres de noblesse à l'architecture, on a l'opportunité, c'est génial et puis, je pense que c'est la majorité de la masse des gens, notre métier qui vont tourner vers ça, un rôle beaucoup plus business, C'est-à-dire en prise avec le problème, ça va être métier interne ou carrément le développement business, la proposition de solution. Et les autres autour, tous les spécialistes se déportent aussi. Alors, l'EPM, il va peut-être faire des trucs plus planification stratégique, je ne sais pas quoi. Mais c'est vrai que tu te dis, si j'ai ces IA que je suis capable de faire, je reviens à ce que tu disais tout à l'heure sur tout le monde peut tout faire, à quoi ça sert d'avoir les mêmes rôles ? Je pense que si on raisonne à périmètre constant en même rôle, en fait, oui, on va finir par détruire les gens. Donc nous notre carrière framework aujourd'hui c'est trois types de. De parcours on a un parcours manager, on a quand même des engineering managers mais on n'a pas associé au rôle de tech lead pour moi tech lead c'est une accountability sur une proposition de valeur donc un tech lead il n'est pas manager et en fait tout le monde peut être quelqu'un qui a un rôle et un impact peut être tech lead, sur ce rôle là et tech lead c'est un rôle avec beaucoup de valeur qui est au moins j'ai dit bien au moins l'homologue du PM et qui peut représenter qui peut pitcher le produit qui peut pitcher la feature quand c'est à l'échelle de feature ou d'un groupement de feature donc ça c'est, les carrières managériales c'est peu d'engineering manager et puis après les places du dessus c'est quand les gens partent en retraite ou qu'ils s'en vont et il n'y en a pas trop et, l'idée c'est que tout le monde soit le plus opérationnel possible, moi aussi je dois encore faire des efforts je continue moi plutôt sur mon monde qui est plutôt celui de la donnée plutôt sur l'analytique à produire mais je pense que tout le monde doit produire, même les managers ensuite t'as aussi une voie genre ça c'est on va dire. 3% max des équipes qui sont sur ce type de parcours. Ensuite, tu as peut-être jusqu'à 20% de spécialistes. Nous, on a qualifié, on en a fait du buzz, mais on a appelé ça StaffEng. Donc, le Staff Engineer au sens de quelqu'un qui va traiter des problématiques transverses et qui va réunir les bonnes compétences pour adresser un sujet, mais qui va avoir la responsabilité de définir la solution sur des problèmes complexes. Donc, par exemple, quand nous, on se lance des features d'IA, quand on réfléchit à l'orchestration de plein de trucs, c'est nouveau, on ne l'a jamais fait, c'est un staffenge qui est déjà passé chez toi, qui s'appelle Geoffrey, qui est génial, qui va faire ce travail-là. Et puis. Le gros des équipes, on a créé d'abord un mindset, donc c'est ingénieur, développeur, ou peu importe comment ça s'appelle, senior, machin, et on a créé un truc qu'on a appelé forward, au sens, pour moi, forward engineer, c'est deux choses, c'est un, se lever de sa chaise, et donc, on n'a forcément pas compris ce qu'on nous demande, c'est pas possible d'avoir compris parce que si c'est fini alors il y a un problème parce que c'est quasiment sûr que le client va dire c'est pas ce que je voulais au final donc il faut aller faire l'extra mile aller le chercher, et au sens forward deployed engineering qui est le truc un peu en vogue que Palantir a sorti commercialement plein de plateformes, c'est un peu l'avant-vente du truc avec l'ingénieur malin qui utilise la techno etc mais qui va résoudre les problèmes du client nous on a 7 assets d'être une boîte de tech et d'avoir la capacité à adresser un monde qui est pas tech nous nos clients c'est B2B, ils n'ont pas forcément le luxe d'avoir les gens que moi j'ai dans mon équipe avec le mindset, leurs compétences etc et c'est une nouvelle façon de l'exprimer plutôt de se dire que moi en tant qu'ingénieur je fais tout ce qui est en interne pour les furets, moi en tant qu'ingénieur ce qui est trivial c'est l'IA qui va le faire, et ce qui a beaucoup de valeur ajoutée business pour la valeur ajoutée d'entreprise je vais le faire chez le client donc c'est comme ça tu vois qu'on a fait évoluer, le sujet avec si je résume. Une réflexion sur comment on arrête au mieux le problème, comment on responsabilise les gens. Ça, c'est le cœur. Quels sont les bons outils qui nous accélèrent ? Et des fois, c'est même un outil dans l'environnement de dev classique. Et à côté de ça, c'est effectivement un outillage qui doit être aussi réfléchi. Moi, ce que j'ai trouvé très intéressant sur ce qu'a fait Comper de Marquette, notre société sœur, quand ils sont venus nous présenter ce qu'ils avaient fait, au début, j'avoue ça me paraissait pas très sexy parce que j'avais l'impression que c'était une combinatoire d'outils qui se mis là je voyais pas le truc en réalité ils ont je pense que c'est comme ça qu'ils ont réussi à convaincre les gens de l'utiliser c'est qu'ils ont fabriqué leur. Leur usine logicielle alors c'est derrière c'est du Langraff etc ça a été développé, fabriqué et c'est un produit et c'est un produit qui appartient aux ingénieurs donc forcément les ingénieurs quand ils pitchent leur truc bah, tu vois ils ont la même fierté etc et ça a le même sens ils adressent, ils comprennent le client très bien ce que le client sait, leur collègue, et donc ça ça marche, tu vois ça ça me fait dire que oui cette année on peut réfléchir à aller beaucoup plus loin, on a commencé à y aller maintenant on a que l'autre code. Et puis surtout on réfléchit à comment est-ce que ce qu'on a fait pour notre site ou pour les nouveaux produits qu'on sort pour nos partenaires il y a plein de trucs nouveaux qui sortent depuis un an, comment ce qu'on a fait pour l'extérieur en fait on peut le faire en interne pour améliorer l'industrialisation et donc satisfaire les gens du bord de nos partenaires, et oui ce qu'on constate c'est qu'on a considérablement réduit le time to market, mais à date 99% c'est juste de la méthode et de l'engagement, 1% c'est l'outillage, l'architecture. Là je pense qu'on a commencé à vraiment réinvestir, on a, repensé notre archi, on l'a simplifié, parce qu'il y a de nouveaux paradigmes, c'est un autre thème, mais il y a de nouveaux paradigmes où tu te dis, est-ce que j'ai toujours les mêmes blocs, est-ce que j'ai toujours mes tiers comme ils sont, est-ce que je les repense, est-ce que mon sujet c'est pas plutôt l'orchestration, est-ce que ma valeur ajoutée elle est pas plutôt là, comment je fais, voilà. Avec, on sait que le time to market est important, mais il n'y a pas que ça, il y a la qualité, il y a la conformité, et Et nous, on commence à s'intéresser de plus en plus aussi à la dimension cyber, parce que ce qu'on utilise, si ça produit, ce que ça produit, c'est que la matière d'entraînement, elle est publiquement accessible. Et donc, elle est publiquement accessible à une très, très grande échelle, à une célérité jamais rencontrée, à des gens pas forcément très bien intentionnés et aussi très intelligents. Et on voit de plus en plus, il y a un exemple avec McKinsey qui s'est fait. Bloquer sa plateforme pour un truc débile mais que nous on verrait pas des fois quand tu fais un pentest, tu te rends compte que t'as une config et en fait tu permets sur ton API de créer un compte et tu l'as pas vu parce que c'est un vieux truc de config, ça, ça le voit en 10 secondes donc, l'exposition de ton truc, surtout si tu, je reviens à ce que tu disais tout à l'heure, mais si tu le maîtrises pas.

Bruno — Ça part beaucoup plus vite qu'avant.

Bastien — Quoi et là c'est comme on reparlait de l'exemple site est down 10 minutes ou le site est down avec un leak de données c'est pas le même problème donc nous on se dit aussi l'ingénierie elle est là le problème de l'ingénierie, aujourd'hui la cyber c'est le problème numéro 1 de tout le monde, et en fait t'as des gens qui disent c'est un peu chiant et en réalité quand ils disent c'est un peu chiant c'est plus qu'ils se disent c'est pas trop mon métier si c'est ton métier maintenant, c'est comme ça que moi je le conçois.

Bruno — Ce que je trouve intéressant, tu as évoqué tout à l'heure que sur les différentes bots que tu as faites récemment, tu avais toujours eu quand tu es arrivé le même problème qui t'a été évoqué, on te dit la tech va trop lentement. Du coup, tu as pu nous raconter un peu tout ce que tu as pu mettre en place, chez LF pour reprendre un peu une vraie dynamique et reprendre la confiance comme tu dis de tous les gens qui sont demandeurs que business et autres et sur la fin. Tu as évoqué des aspects qu'on évoque souvent ici, en fait, c'est effectivement de responsabiliser les devs, de leur redonner, le plaisir de ce travail-là qu'on fait, qui est effectivement d'aller, de ne pas être là juste pour pisser du code, mais d'être vraiment là pour résoudre des problèmes, pour comprendre les solutions, enfin, comprendre le contexte client et du coup apporter la bonne solution avec les bons outils au bon endroit. Tu as parlé aussi de remettre la passion. Est-ce qu'au final dans ces différents métiers différentes entreprises que tu as faites avant c'était à chaque fois le même problème parce que tu nous dis que c'était pas la même solution mais est-ce qu'au final c'est pas un peu tout le temps aussi la même solution, c'est de redonner en fait au final, à des équipes de dev qui ont été écrasées par cette approche d'être juste des pisseurs de code et de leur dire non en fait vous êtes pas là pour écrire du code, c'est pas ça notre métier ça fait partie du job, mais en fait notre métier il est là donc de redonner ce côté effectivement de restabilité et de passion de notre métier.

Bastien — Ouais, il y a une pattern qui est clairement ça. En fait, si je regarde en arrière, oui, c'est une des fondations. Nourrie quand même par. Des expériences des fois où tu... Encore une fois, quand je te dis, je me retrouve sur une plateforme pétrolière avec des gens qui font un autre métier, c'est super inspirant. Je pense que, un des trucs fondamentaux c'est essayer, tu peux pas toujours le faire là pour l'instant au furet j'ai pas tellement eu le temps de le faire ou l'occasion de le faire mais le fait de pouvoir projeter les équipes dans un écosystème qu'elles connaissent pas parce que souvent les développeurs on leur donne pas la chance, l'accès qu'on a nous confortable quand on est VP je sais pas quoi ou CTO, on peut rencontrer plein de gens on est sollicité pour rencontrer des gens on nous propose d'aller voir des choses et on nous accueille correctement les devs on leur dit non non te lève pas 5 minutes parce que sinon tu vas nous mettre en retard sur le projet donc ils ont rarement le temps d'aller voir, autre chose mais des fois tu discutes, tu réfléchis tiens on pourrait changer notre data plateforme, et tu rencontres les ingénieurs de ces boîtes là et tu vois comment ils travaillent et quand t'arrives à faire en sorte que tes équipes soient en prise avec ces gens là quand ils voient comment les autres dans un métier très proche travaillent c'est, un bon truc donc si je dois avoir les patterns oui il y a responsabiliser les gens redonner la passion, moi je communique beaucoup aussi, en exposant les équipes parce que je sais que c'est une bonne façon de montrer en fait, je pense que les métiers ou les parties prenantes en général elles apprécient quand tu dis écoute je vais quand même des erreurs mais voilà j'y vais en fait. C'est comme si t'es chez SFR t'es pas content et c'est ta mère qui te répond tu vas pas hurler dessus de la même manière ça crée de la proximité, ça crée de la bienveillance etc donc ça effectivement c'est des patterns communes donc oui il faut responsabiliser les gens, mais tous les métiers je pense en vrai, mais nous il faut nous responsabiliser particulièrement, il faut donner la chance, pas forcément de logique pyramidale, c'est à dire moi je suis pas fan des experts. Ils ont souvent raison, mais ils ont souvent tort. Et leur tort est souvent de reproduire la même paterne parce qu'ils l'ont vu 15 fois et en fait, ils ne réfléchissent plus au problème. Pas tous, mais ça peut tomber là-dessus. Et surtout, il y a une espèce d'argument d'autorité qui fait que le petit jeune à côté qui dit peut-être un truc un peu faux, mais un peu vrai, il n'a pas voix au chapitre. Ça, c'est un truc qui m'a toujours agacé. Donc, je pense que dans les bonnes paternes, il faut faire confiance des fois à l'apprenti, ou à un jeune apprenti qui vient d'arriver qui fait son truc, il faut lui laisser faire des trucs, et se détendre sur le fait qu'on soit planté, c'est pas grave ça c'est des patterns, générales, après la solution elle a toujours été différente, et tu vois aujourd'hui je sais pas dire si il y a une méthode à un moment donné je me suis dit bah tiens, tu vois des copains qui réussissent dans l'entrepreneuriat et qui font des trucs géniaux, tu te dis bah tiens j'aimerais bien lancer un truc je crois que j'ai un machin, en fait les méthodes agiles c'est des conneries je vais écrire ma propre méthode, le gars qui a fait Scrum ou les gars qui ont fait Scrum, Scrum et l'association ils sont millionnaires, enfin bon bref tu te dis vas-y je vais faire un truc comme ça et je vais partir sur une île déserte dormir à lire des polars bref, j'ai des fois des délires mais j'ai pas trouvé la bonne méthode parce qu'en fait tu vois je reviens aux bonnes valeurs de notre métier d'essayer de contribuer pour la communauté, de travailler ensemble avec humilité etc. Bah j'ai pas trouvé, en fait c'est jamais la même solution le truc que j'ai fait dans les médias c'est pas la même orga, c'est pas les mêmes architecture, c'est pas les mêmes solutions puis, on a un autre phénomène qu'il faut quand même regarder, c'est, tu te rappelles cette époque dont on parle, où on connaissait tout ? On a eu une autre époque où d'un outil à l'autre et ton pouvoir ou de l'économie que tu avais dans une entreprise, quand tu passes de je suis dans ma chambre, je développe mon truc et j'arrive à tout faire. Ah, je travaille pour une boîte, mais la boîte, elle a des contraintes économiques ou budgétaires. Elle ne peut pas se permettre de s'acheter tel ou tel techno. La loi de Moore, elle a quand même fait son effet. Il y a une commoditisation de plein de techno méga puissante. Fabien, dans l'épisode dont on parlait tout à l'heure, il dit que les LLM, ce n'est pas nouveau. Les LLM, ce n'est pas nouveau. Ce qui est nouveau, c'est les mécaniques d'attention, ce qui a été documenté par Google et tout ça, ok, c'est nouveau, ou plus récent. Et la puissance de calcul, aujourd'hui, honnêtement, tu peux refaire, enfin, je reviens à mon truc de ETI, mais tu peux te dire, voilà. Je fabrique, j'achète ou je génère. Et donc, la techno, elle est quand même beaucoup plus accessible, la capacité qu'on a, elle s'est quand même démultipliée, quoi. Donc ça veut dire que notre responsabilité c'est de bien utiliser ça et bien utiliser ça ça recréer une complexité parce que ton arborescence de fichier MD ton truc etc même quand tu fais de l'IA, t'as de l'ingénierie, c'est pas trivial ceux qui le font bien et tu vois moi je considère que ce que j'ai vu des collègues au UK est bien fait dans une certaine mesure bah il y a de la réflexion, il y a de l'ingénierie il y a de l'erreur, il y a de l'engagement, de la résilience, de la responsabilité l'autonomie, de la découverte de la curiosité, tout ça c'est tu vois les bons fondamentaux et il faut les utiliser même dans ce monde.

Bruno — Là un truc que j'ai évoqué plusieurs fois sur ce podcast c'est que on va rentrer dans une époque là où il y a tellement de gens qui vont pouvoir produire plein de trucs en fait on a fait baisser la barrière à l'entrée de manière, c'est à dire que la barrière elle est quasiment au sol là aujourd'hui pour produire une application c'est à dire que, le nombre d'applications, de services de trucs qui vont être imaginés et mis en prod à travers le monde va être colossal et donc là on est dans une période où on a un marché du travail qui est un peu compliqué pour les devs, ce qu'on a jamais connu depuis depuis 50 ans et je pense que dans quelques années ça va repartir de plus belle parce qu'en fait tous ces trucs là vont avoir besoin justement de cette ingénierie, dont tu parles parce qu'en fait quel que soit le contexte, dès que tu passes à l'échelle t'as besoin d'ingénierie parce qu'en fait créer une application qui va être utilisée par 10 personnes c'est facile et en même temps on s'en fout parce que c'est 10 personnes donc t'as pas de risque cyber, t'as pas de.

Bastien — Risque de réglementation.

Bruno — En revanche dès que tu commences à toucher un peu et donc ça va partir de plus belle parce qu'en fait les idées vont être folles ça va être une nouvelle époque de changement.

Bastien — Pour moi on va revivre les subprimes des agents hier tu vois il, y a deux victimes collatérales de la barrière à l'entrée qui est très basse, d'ailleurs j'ai opiné du chef très fort quand t'as dit ça mais c'est vrai et faux parce que, moi je connais des gens qui sont pas tech qui comprennent quand même rien à ce que ça sort et qui sont pas à l'aise à l'aise parce que quand ça commence, quand Claude il t'explique ce qu'il est en train de faire et pourquoi il le fait et qu'il te demande et qu'il te sollicite au début, tu comprends pas un traître mot de ce qu'il te raconte ? C'est pas sûr qu'il y a un truc qui sorte. Il y en a qui arrivent quand même à faire un truc, mais dès qu'ils le modifient, il est pété et ça n'a même pas commencé à sortir. Il faut quand même dire la vérité. Et je pense qu'il y a deux trucs, il y a deux victimes collatérales qui sont notées. Un, on dit les cabinets de conseil, ils n'ont plus de job parce que maintenant tout est fait, etc. En ce moment, ça va être dur. Mais par contre, quand il y a tout le nouveau sac de spaghetti qui aura été créé, je pense qu'il y aura besoin d'aide. Donc je pense qu'ils ont un avenir, il faut juste être résignants. Et les devs, les ingénieurs en général tech, C'est eux qui vont être fondamentaux et qui doivent aujourd'hui jouer ce rôle-là. Je pense qu'il ne faut pas s'arc-bouter sur « Attends, ils essayent de me remplacer. Moi, je ne veux pas ça. Et à quoi je sers ? » Ce n'est pas ça la question qu'il faut se poser. Ce n'est même pas la question à se poser.

Bruno — Notre métier, c'est de résoudre des problèmes.

Bastien — On résout des problèmes et il y en a exponentiellement c'est à dire que, peut-être que dans ta boîte il y a un site web qui finalement permet de créer un compte client et qui permet d'exposer un produit et de le changer et puis, tu vas développer un truc de contrôle tu regardes que ces micros ça fait 100% de ton travail, imagine si 100% de tes collègues construisent des trucs qui vont contribuer aux produits et que tu dois en faire l'orchestration ou l'architecture L'état du problème, en fait, est encore plus important. C'est-à-dire que ton rôle, il est encore plus important. Il est certes différent, ou il se positionne différemment, mais il est encore plus important. Et ça... Je vois encore trop peu de gens me le dire c'est ma sensation moi je suis plutôt excité et je vois quand même pas mal de gens dans la zone de doute à quoi je sers alors que c'est pas logique.

Bruno — Merci beaucoup 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 ou plusieurs contenus que tu souhaiterais partager avec l'ensemble des auditeuristes.

Bastien — Ouais alors deux contenus un peu alors il y a un vraiment tech c'est la newsletter de Ben Stencil que j'aime beaucoup lire qui est très fun c'est pas un truc que personne ne connait, Mais bon, tous les vendredis, c'est mon plaisir. C'est hyper chouette, hyper drôle. Et c'est une bonne prospective sur ce qui se passe dans la tech, avec un petit œil d'avance. Le deuxième, alors on peut lire le profil, ou on peut demander à Tchad GPT de le résumer, mais c'est du contrat social de Jean-Jacques Rousseau, qui est toujours une inspiration. C'est philosophiquement le débat entre l'état de nature et l'état social, donc le fait que les gens soient organisés, l'être humain. C'est il y a des thèses qui s'opposent sur le fait que si tu ne ne fais pas société en fait les gens finissent par se manger les uns des autres, et en fait je pense que le succès des organisations gagnerait à se rappeler de ces fondamentaux là c'est très chiant à lire quand on est au lycée enfin moi j'ai un peu transpiré, un gros mot ce que je dis quand même mais voilà donc je recommande ça ou en tout cas de s'intéresser à la thèse ou aux thèses qui s'opposent derrière ça parce que en fait c'est une très bonne inspiration pour collaborer, donc c'est les deux contenus que je recommanderais.

Bruno — On mettra bien évidemment des liens en description et Bastien la question la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ?

Bastien — Alors tu m'as dit que je t'ai pas obligé d'expliquer pourquoi et je te rassure je vais faire une explication courte qui est la très bonne nouvelle, je suis un flemmard et je trouve que ça va plus vite avec tabulation donc tabulation très bien.

Bruno — Merci beaucoup Bastien merci Bruno et merci à tous d'avoir suivi cet épisode je pense que ça fait plaisir d'entendre qu'on peut augmenter, la productivité je mets des guillemets, sans forcément passer par l'IA et je pense que c'est une bonne réponse à apporter à tous ces sujets qui popent un peu partout, parfois là, revoir la manière dont on travaille et, retrouver ce côté hyper intéressant et hyper passionnant de notre métier est toujours une bonne chose, donc j'espère que Bastien. Vous aura donné quelques pistes comment retrouver ces éléments-là comme toujours je vous remercie 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.