Bruno:
Dans les années 50, chez Toyota, un ingénieur du nom de Taishi Ono arpente l'atelier avec une idée fixe. Ne pas produire forcément plus de voitures, mais produire mieux, et surtout apprendre plus vite que son voisin. Il ne va pas pondre une méthode, il pondra un système, le Toyota Production System. Et comme toute bonne idée japonaise qui va traverser le Pacifique, on va lui coller un nom américain en trois lettres, et on fera un slide PowerPoint, bienvenue dans le monde du Lean. 70 ans plus tard, une nouvelle fournée d'ouvriers débarque sur nos chaînes de production. Ils ne dorment jamais, ne prennent pas de pause café et tapent du code à la vitesse de la lumière. Le hic, c'est que personne ne leur a appris le métier, qu'ils oublient tout entre deux tâches et qu'ils sont capables de livrer 1000 pièces défectueuses avant même que tu aies fini de prendre ton croissant. Nos agents de programmation sont des stagiaires surdoués mais amnésiques. Mais alors, un modèle pensé peut-il vraiment s'appliquer à du code et à des IA ? Comment oublie-t-on ? Ou titons des ouvriers qui produisent 10 fois plus vite qu'on ne sait vérifier ? Et surtout, peut-on bien manager des agents qui ne comprennent pas la subtilité de la question ? Est-ce que tu es plutôt tabulation ou espace ? Pour répondre à ces questions de production, je ne reçois pas Charlie Chaplin, mais il s'y connaît en travail à la chaîne. Yacine, bonjour.
Yacine:
Bonjour.
Bruno:
Alors Yacine, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaissent peut-être pas ?
Yacine:
Alors oui, je m'appelle Yacine. Je suis software ingénieur depuis à peu près une dizaine d'années. Et aujourd'hui, je suis VP Technologies chez Fabrique. Alors Fabrique, c'est une société logicielle. On produit un SaaS pour les entreprises industrielles, notamment pour les aider à appliquer les méthodes liées au Lean. Et c'est comme ça que j'ai découvert le sujet dont je vais vous parler aujourd'hui.
Bruno:
Ok, canon. Alors l'idée, c'est de voir aussi effectivement comment est-ce que le Lean peut s'appliquer dans nos contextes actuels surdosés, surdopés à l'IA. Mais avant peut-être de plonger dans comment ça s'adapte à aujourd'hui, Est-ce que tu peux nous dresser un peu le tableau de c'est quoi le Lean, comment ça fonctionne ?
Yacine:
Alors le Lean, c'est l'application du TPS que tu viens de décrire en dehors de Toyota. L'application et l'étude. Ça peut prendre différentes formes, ça peut avoir différents noms également. Il faut bien comprendre que ce n'est pas nécessairement une méthode, c'est plutôt un modèle de stratégie. C'est-à-dire qu'en fonction de l'industrie, il va falloir adapter certaines choses. En tout cas, il y a des principes qui ne bougent pas. Parmi ces principes, c'est que la chose la plus importante, c'est la satisfaction client. C'est ça qui va dériver le reste. Autre chose également très importante, c'est que l'ensemble des méthodes sont avant tout ici pour servir l'apprentissage des individus qui produisent. Parce que le TPS a été développé dans un contexte de mise à l'échelle d'une production. Et dans un contexte changeant, c'est-à-dire que là où la stratégie qui lui avait précédé, qui était le fordisme, permettait sur un modèle bien établi de produire à la chaîne un même produit, l'auto-utilisme ici doit inventer des chaînes de production qui permettent de s'adapter à la demande du client rapidement. Et c'est là où rapidement on peut faire un parallèle avec notre métier de dev où justement si on a été exposé au monde agile, cette idée de « requirements » qui change tout le temps, en fait elle vient d'où initialement ? Le grand-père de Scrum c'est justement le TPS. Et cette analogie qu'on peut faire entre l'industrie et le software, elle est tout en plus pertinente maintenant avec l'ère des agents de programmation AI Coding Nations.
Bruno:
Donc ce que tu dis, c'est qu'il y a une filiation entre le Scrum et le Lean.
Yacine:
Oui, et d'ailleurs, elle est même documentée. C'est-à-dire qu'on a dans les années 50 Toyota avec le TPS et ensuite on a différentes méthodologies qui émergent. On peut avoir des méthodologies nommées Kanban qui vont venir s'inspirer plutôt de la gestion des flux de Toyota Scrum va au contraire plutôt essayer de ritualiser un certain nombre de choses au sein des équipes de développement et puis après on a même d'autres mouvements qui vont, capturer le non Lean sans pas forcément en incarner l'essentiel des aspects comme le mouvement Lean Startup et donc tout ça nous dans nos métiers on est plutôt confronté à ces différentes pensées plutôt qu'à la pensée originelle du TPS et à son étude. Et c'est pas très étonnant parce qu'étudier le Lean et le TPS en fait c'est étudier un contexte de production industrielle. Ce qui est pas du tout en fait notre quotidien. Et donc on est bien content d'avoir ces un peu méthodes prémâchées. Mais c'est important de revenir à la source parce que cette source là elle vient pas avec des méthodologies établies ou un guide clair comme l'appui de Scrum. Elle vient avec une vision, une grille de lecture qui permet justement ensuite d'inventer sa propre façon d'incarner cela, ses propres méthodes, une forme de flexibilité dont on a bien besoin dans ce contexte changeant avec notre métier qui est en train de se réinventer.
Bruno:
J'ai peut-être mal compris ou peut-être fait une généralité, mais pour moi, le Lean, c'était très associé à... On a un problème ou une erreur, on rencontre une difficulté et on essaye d'apprendre de cette erreur pour ne pas la reproduire plus tard. Et pour moi, c'était ça, cette boucle de feedback autour du Lean. Mais toi, ce que tu décris, c'est quelque chose qui est beaucoup plus vaste et beaucoup plus global que juste cette prise en compte de l'erreur.
Yacine:
Tout à fait. C'est-à-dire qu'on, justement, à des fins de compréhension, va essentialiser ce qu'est le Lean. Et je le fais aussi, à mon avis, dans cet échange. Et on va en prendre certains aspects parce qu'ils sont justement plus palpables, plus pratiques. Et effectivement, le problème solving, cette idée d'amélioration continue, c'est une partie intégrante du Lean. Mais il y a beaucoup d'autres choses dont on n'a pas forcément idée qui viennent supporter cela. Donc par exemple, un concept simple, c'est le poké-yoké. Le poké-yoké, c'est un concept qui consiste à concevoir les choses de façon à ce que quelqu'un qui agirait sans trop réfléchir serait naturellement guidé vers la bonne façon de faire et non pas la mauvaise. L'exemple typique, c'est un micro-onde. Lorsqu'il est ouvert, ne peut pas s'allumer. Voici un exemple de poké-yoké. Plutôt que d'écrire une note pour dire, attention, il faut appuyer sur le bouton que quand la porte est fermée, s'il est ouverte, kaboum. Donc vous voyez, il y a une façon de penser les systèmes qui n'est pas forcément lié uniquement à cette idée d'amélioration continue et on peut, donc il y a une représentation très classique du Lean avec un temple et des piliers il y a tout un ensemble d'éléments, de pratiques qu'on peut venir évoquer peut-être qu'on le fera dans les exemples que je verrai plus tard Mais.
Bruno:
Donc la démarche est de de s'organiser vers une notion de satisfaction client.
Yacine:
C'est ça ? Donc, d'abord, la satisfaction client avant tout. Ensuite, c'est qu'est-ce qui va nous guider vers la satisfaction client ? C'est dans l'ordre, et attention, l'ordre est important, c'est d'assurer d'abord la sécurité de la production, puis ensuite la qualité de ce qui est produit, puis ensuite réduire les délais de production, enfin réduire les coûts de production, et dernièrement, il y a des aspects humains et environnementaux qu'il faut tenir compte. Et la hiérarchie est dans ce sens-là, parce qu'on peut imaginer que c'est très facile de réduire le coût en baissant la qualité. Ou alors, augmenter les volumes en augmentant également les délais. Le fait d'avoir une hiérarchie claire et une grille de lecture ici, ça empêche de faire des mauvais calculs et des mauvais trade-off, justement. Donc ça, ça fait partie du grand principe. Ensuite, ces différents axes, on va chercher à les mesurer. C'est quelque chose qui est très important dans le Lean, la capacité à mesurer ces choses-là. Et on va décliner différentes méthodologies ou différentes pratiques qui vont supporter l'amélioration de ces différentes choses. Notamment le fait de lisser les flux de production afin de pouvoir produire en temps réel éviter les stocks et ça c'est ce qui permet justement d'adapter, la production, de s'adapter au marché de réagir en fait à des imprévus, il y a également des concepts d'auto-qualité comment on s'assure que ce qu'on produit est constamment de meilleure qualité, comment on s'assure de ne pas produire ce qui est de mauvaise qualité, comment on réagit quand on a produit de la mauvaise qualité et ensuite des méthodologies de problème solving et d'autres choses encore.
Bruno:
Ok, hyper intéressant. Alors du coup, ça semble effectivement extrêmement riche. Mais tu vois, dans ces priorités que tu as évoquées, notamment je prends la première de la session de sécurité, Je comprends qu'effectivement, sur une chaîne de montage, d'assemblage de voitures, la notion de sécurité, elle est importante. C'est-à-dire qu'effectivement, tu peux augmenter la production au détriment de la sécurité de tes ouvriers et ouvrières. Et donc forcément, si tu tues des gens, c'est pas fou pour ta chaîne de montage. Mais du coup, ma question, c'est est-ce que ces éléments-là, tu peux vraiment les répliquer dans un contexte de production logicielle, où au final, notamment, cette notion de sécurité, toi et moi, quand on est derrière notre écran, on ne risque pas grand-chose. À part le syndrome du canal carpien tout à fait.
Yacine:
C'est pour ça que le Lean c'est quelque chose qu'il faut vraiment s'approprier la sécurité dans notre contexte on peut l'interpréter comme étant la cybersécurité, si je prends je tombe directement dans l'exemple je pense que c'est un exemple qu'on reprendra, pas mal de fois on pourrait demander à l'IA lorsqu'on reçoit un bug, de juste lui donner le ticket de bug et lui demander de le corriger, pour pouvoir corriger ce bug peut-être qu'on va lui donner accès à différents outils qui vont l'aider à mieux le résoudre. Il y a une façon très simple d'améliorer la qualité d'une correction de bugs et de donner un accès à la proie de l'IA. Mais par contre, on prend un risque de sécurité quand on le fait. Donc là, il y a la hiérarchie tout de suite, c'est qu'on n'essaye pas d'améliorer la qualité au dépend de la sécurité. Et donc, si on doit mettre en place des méthodes ici, on va d'abord mettre en place des méthodes qui, en améliorant la qualité, ne sacrifient pas la sécurité. Et cette logique-là, on va pouvoir la décliner dans l'autre sens. On ne va pas essayer de réduire les délais au détriment de la qualité, on ne va pas essayer d'augmenter la productivité au détriment des délais, et on ne va pas essayer d'augmenter, on ne va pas essayer de... Enfin, je pense qu'à mon avis, ça finit la chaîne d'ailleurs. La productivité, c'est d'ailleurs souvent quelque chose qui différencie un peu ce mode de gestion financiarisée et capitalisée de beaucoup d'entreprises occidentales où la hiérarchie est totalement inversée. C'est-à-dire que la productivité est d'abord le plus important, puisque c'est ce qui se finit dans le PNL au final. Et ensuite, on va du coup décliner les choses au service de la productivité. Et quelque chose que Lili ne fait souvent c'est bien que la productivité soit infinie ce qu'on recherche, il y a toujours des phénomènes de décalage, on va placer notre concentration sur autre chose qui par conviction, empiriquement va nous permettre d'atteindre cet objectif mais on n'essaye jamais de chercher de façon un peu en ligne droite la productivité on va la prendre par ses angles comme je le disais donc sécurité, qualité, délai, coût, enfin donc délai donc.
Bruno:
Productivité J'ai eu le cas dans un autre épisode aussi, J'avais reçu un CTO qui, dans son approche du Lean, avait organisé son entreprise au total dans le concept de se dire que le but du Lean, ça donnait à la direction comme prérogative principale de s'assurer que les gens travaillent sur le bon problème mais de les laisser trouver la solution. Une espèce d'autonomie. Et ce que lui me présentait, c'était la suite logique de l'interprétation normale du Lean. Est-ce que c'est aussi ce que tu décris ?
Yacine:
L'autonomisation des équipes est importante, notamment pour une bonne résolution de problèmes. Il y a une croyance, en tout cas, c'est que... J'emploie le mot « croyance », mais maintenant, c'est même empiriquement observable. C'est que les meilleures personnes pour résoudre un problème sont celles qui le voient, qui le palpent, voire qui le causent. Et ce n'est pas nécessairement en « common and control ». Le problème doit être remonté quelque part, et puis ensuite, c'est quelqu'un d'autre qui s'en occupera. Et pourquoi c'est important que le problème soit résolu localement c'est ce que je disais un peu au début si on veut pouvoir avoir une chaîne de production adaptable, qui doit fonctionner à l'échelle dans un système complexe on ne peut pas rester dans un mode de management, très top down il faut pouvoir autonomiser les équipes mais il faut quand même une façon de contrôler cette production là et c'est là que les indicateurs que j'évoquais avant de qualité, de sécurité de délai, de coût interviennent ça permet d'avoir une idée de la santé de la production, sans forcément être dans le détail de comment les gens doivent produire et comment ils doivent résoudre leurs problèmes.
Bruno:
Mais la personne qui est confrontée au problème, parfois, elle n'a pas la vision globale de peut-être que son problème qu'elle est en train de résoudre, il est dû à un système au global qui a généré ce problème-là à sa place ?
Yacine:
C'est pour ça qu'il est aussi important que les personnes soient entraînées à bien penser les problèmes. Et donc c'est par l'exercice de résolution de problèmes avec les collaborateurs, de façon répétée, qu'on ouvre leur capacité à voir au-delà de leur propre contexte immédiat. Et c'est en sachant qu'il y a un contexte extérieur que ces individus-là vont être en capacité de pouvoir remonter les problèmes. Donc le faire escalader à des personnes qui seront mieux en mesure de le résoudre.
Bruno:
— OK. Donc le Lean, c'est quand même une méthode, pardon, une stratégie qui s'applique assez fréquemment dans le monde du développement logiciel. Mais j'ai l'impression qu'il n'est pas non plus répandu de manière massive. Alors est-ce que c'est comme le Scrum ? C'est que tout le monde en fait en se disant « Ouais, mais en fait, on adapte un peu comme on veut. » Et donc en fait, personne n'en fait vraiment. Ou est-ce que c'est que des gens le font sans le savoir ou est-ce que c'est effectivement quelque chose qui est assez complexe à mettre en place et qui du coup n'est pas encore suffisamment présent dans les entreprises ?
Yacine:
Je pense que ce qui rend la chose difficile de l'adoption du Lean c'est que le Lean et tu l'évoquais rapidement c'est avant tout une discipline du dirigeant, et quand on évoquera l'application du Lean dans les interactions avec les AI coding agents en fait on va s'intéresser à ce qu'on peut apprendre du Lean pour cet exercice là mais le Lean essentiellement c'est une façon de diriger l'entreprise. Et ensuite, ça va trickle down, ça va descendre les couches de management et parce qu'à son échelle, on a un pouvoir de décision et donc on peut aussi adapter la posture du dirigeant. Et je pense que c'est ça avant tout qui empêche l'adoption. C'est pas tant une question de... Il n'y a pas la bonne méthode Lean. Il y a une compréhension des principes sous-jacents, une façon de voir les problèmes, une grille de lecture de comment l'entreprise doit s'organiser. Et ça, même si on peut le voir chez les devs, on le voit très rarement chez les CEOs des boîtes tech.
Bruno:
Donc c'est vraiment un sujet d'organisation totale de l'entreprise ?
Yacine:
C'est un sujet d'organisation totale de l'entreprise parce que vous voulez la satisfaction client, ça ne se limite pas au code que vous allez écrire. Ça va impliquer des composantes de « est-ce qu'on a bien vendu ? Est-ce qu'on a vendu la bonne chose ? Est-ce qu'on n'a pas menti sur ce qu'on vendait ? Est-ce qu'on l'a vendu au bon prix ? » Donc ça fait partie de la satisfaction client. Il y a également des considérations de support. Oui très bien on a produit du code il a l'air d'être de qualité mais est-ce que lorsqu'il y a un problème et on sait très bien que le zéro bug n'existe pas est-ce qu'on va bien s'exprimer auprès du collaborateur pardon auprès du client, est-ce qu'on va lui résoudre son problème dans les temps est-ce qu'on va capturer l'information comme il le faut donc c'est vraiment un sujet d'entreprise finalement le Lean.
Bruno:
Et donc dans une organisation d'équipe de dev traditionnelle avant d'évoquer le cas particulier de chambon de métier.
Yacine:
Actuel qu'apporte l'IA.
Bruno:
Ça se traduit comment dans une équipe, dans une entreprise tech, cette application du Lean ?
Yacine:
Alors c'est une bonne question. Je pense que il faudrait demander à des gens qui l'ont bien fait à l'échelle. Il en existe en France, peut-être que je l'aimerai plus tard. Mais en tout cas, moi, de l'image que je m'en fais, ça passe avant tout vers, un changement de posture du manager. C'est que le manager doit comprendre que que, à son échelle, le Lean, c'est une méthode de management, enfin une méthode. C'est un état d'esprit, en tout cas, du management qui va consister à mettre en place les conditions de la performance de ses collaborateurs tout en permettant leur apprentissage continu. Un exemple très simple, je pense que moi, en tout cas, à mon échelle, j'ai déjà par le passé vécu des situations où je vais travailler avec un collègue et puis il va mal faire quelque chose. Et donc, on va review le travail, on va faire une analyse de la qualité et puis après, peut-être qu'on va se permettre de corriger le problème, en tout cas, les non-qualités qui ont été effectuées. Quand on met les lunettes du Lean, il faut se rendre compte qu'ici, ce que produit le collaborateur, le collègue, qui peut être un peu junior, c'est une pièce. Donc déjà, la question qu'il faut se poser, c'est cette pièce-là, quelle est-elle ? Et qu'est-ce qui fait que c'est une pièce de qualité ? Donc il faut peut-être le documenter, il faut peut-être le lui apprendre. Et ensuite, on va utiliser ce moment de code review, ce moment d'analyse, non pas pour objectif principal de rendre la pièce de meilleure qualité, mais comme l'opportunité pour que le collègue apprenne de ce qu'il a manqué pour que la prochaine fois, il le fasse mieux. Donc dans le détail c'est avant tout en état d'esprit, et donc ça c'est un aspect qualité je pourrais aussi évoquer des aspects flux très souvent dans une organisation dev on peut imaginer de la gestion de projet qui va consister à découper le projet en face puis assigner des personnes et définir un retro planning. Lorsqu'on a mis les lunettes du lean devant les yeux alors on ne dit pas qu'il ne faut pas faire de retro planning nécessairement mais que pour minimiser les délais il faut se poser la question déjà de la qualité et il faut se poser également la question du flux. Donc par quelles étapes va devoir passer la production et comment je mets en place les méthodes pour mesurer afin de minimiser en continu le temps d'exécution de chaque étape. C'est pas du tout la même approche que de se poser la question, prenons un gros projet, décompos-le, estimons-le et espérons qu'on y arrive à temps.
Bruno:
Mais tu prends quand même une notion d'estimation et de rétro-planning. Quand tu parles de ces étapes de production, au final, ça correspond quand même à des jalons auxquels tu donnes une temporalité, comme d'une certaine manière, ou du coup, tu oublies la notion de temporalité. C'est juste qu'il faut produire le jalon dans des critères de qualité.
Yacine:
Ce n'est pas nécessairement un oubli de la temporalité, mais je pense qu'un bon exemple, je ne fais pas honneur à cette merveilleuse femme dont j'ai oublié le nom, mais qui avait comparé la productivité des ouvriers lors de la construction de l'Umpire State Building et des gratte-ciels aujourd'hui. L'Umpire State Building a été fait en un temps record. Ils se sont posés la question, mais comment est-ce qu'on a fait l'Umpire State Building en temps record ? Ça n'a pas été en planifiant pour chaque étage et chaque pièce les dates à laquelle chaque pièce doit être réalisée, puis ensuite comprendre que si la pièce doit être réalisée à telle date, alors les pièces doivent être libérées à telle date, puis être produites à telle date, puis tel ouvrier doit arriver à telle date. La façon dont ils ont produit l'impair state building si rapidement, c'est en comprenant que chaque étage, pour pouvoir produire un étage, il y a toute une logique de flux qu'il va falloir gérer, donc venir cadencer, opérationnaliser, minimiser le temps avec lequel les camions arrivent, les personnes qui vont s'assurer de décharger, les ouvriers qui vont s'assurer d'intervenir, et en développant un système résilient, la question même de se poser à quelle date va être fait chaque sous-partie de ce qu'on cherche à produire derrière devient finalement assez secondaire. Le plus important c'est est-ce qu'on a réussi à créer un système répétable qui lui est rapide et qui continuellement devient de plus en plus rapide, donc c'est un peu prendre de la hauteur être en retard sur un projet est-ce si grave si on a appris ce qu'il fallait pour que le projet suivant soit fait deux fois plus vite. Comment est-ce qu'on considère finalement la temporalité dans ce qu'on produit ? Donc encore une fois, je ne cherche pas à opposer une façon de gérer des projets qui, parfois, pour des contraintes économiques ou physiques, nécessitent une définition claire de jalons de temps à atteindre, mais à aussi ouvrir un autre point de vue qui je pense à l'échelle et sur le temps long donne de meilleurs résultats.
Bruno:
Et donc par rapport à une méthode Scrum que à peu près tous les développeurs et développeuses.
Yacine:
Connaissent.
Bruno:
Maîtrisent et connaissent qu'est-ce que ça change dans le quotidien, dans le métier de dev de travail dans un contexte Lean ?
Yacine:
Alors, je ne peux pas forcément vous le dire parce que, encore une fois, les lignes, ce n'est pas nécessairement une méthode. Et alors, peut-être que je me ferais taper sur les doigts de mon Sensei Lean, mais je ne suis pas sûr que ça s'oppose nécessairement. Le Scrum, ça peut être très bien un point de départ pour avoir un guide rituel très clair de méthode à appliquer. Et ensuite, par-dessus, le manager de cette équipe-là peut utiliser les outils du Lean pour observer les problèmes qui vont émerger suite à cette organisation. Et au fur et à mesure, par une logique d'amélioration continue, les méthodes de l'équipe vont commencer à se morpher, se transformer pour devenir le pseudo-scrum que tout le monde connaît. C'est, on fait du scrum, mais bon, ce qui nous arrange. Ce qui est important, c'est le ce qui nous arrange. Est-ce que c'est fait au bon vouloir des préférences du manager ou est-ce que c'est fait avec une discipline claire d'amélioration qui, de façon certaine, nous permette d'avoir une satisfaction client qui s'améliore ?
Bruno:
— Il y a quand même un élément qui revient souvent dans les éléments que tu as évoqués autour du Lean, c'est quand même cette notion d'apprentissage. Tu as évoqué cette code review. On va non pas corriger le code, mais s'assurer que la personne qui l'a produit puisse en produire du meilleur de qualité plus tard ou que s'il a fait un truc parfait, il puisse apprendre aux autres à faire aussi bien que lui. Je sens qu'il y a quand même aussi une notion très forte autour de l'apprentissage, mais de manière très diffuse, très continue, où il y a quand même des temps de formation associés.
Yacine:
Encore une fois, l'idée, ce n'est pas forcément de mettre en concurrence la formation, on va dire la formation initiale, la formation délibérée avec cet apprentissage continu. Mais ce qu'il est vrai, en tout cas, c'est que dans nos contextes, les adultes professionnels qui passent leur journée à travailler, la façon dont ils apprennent en général, c'est en faisant. Ça ne veut pas dire qu'on ne peut pas apprendre en lisant, ça ne veut pas dire qu'on ne peut pas apprendre en suivant des formations, ça reste toujours important. Par contre, ce que je peux vous dire, c'est que si quelqu'un se contente de lire des livres et de former, mais de ne pas appliquer, il ne sera pas capable, du coup, justement, d'incarner cet apprentissage et d'avoir un résultat pour l'entreprise. Donc, encore une fois, c'est une grille de lecture différente. Je pense qu'il y a beaucoup de réflexes qu'on peut avoir en entreprise de « mes gens ne savent pas faire, je les envoie à la formation ». Peut-être, commençons par les pièces qui sont produites, qu'est-ce qu'ils ne savent pas faire exactement, qu'il y a une formation minimale qu'il faut leur donner pour qu'ils puissent s'exercer. Et puis après, lorsqu'on commence à avoir des points chauds où il y a des fondamentaux qui ne sont pas maîtrisés, là, on peut jouer à la carte de la formation.
Bruno:
Du coup, cette notion d'apprentissage, il y a quand même une impression que c'est très adapté au contexte de nos agents d'IA qui ont ce besoin fort d'apprendre. Il y a quand même une capacité d'une certaine manière d'apprendre avec ces fameuses skills.md, les agents.md. On a une capacité à donner des instructions qui s'en bloquaient. Est-ce que du coup, ça ressemble à une approche Lean ?
Yacine:
Moi, j'ai une question pour toi. C'est lorsque tu écris un skill avec ton agent, qui apprend ?
Bruno:
J'espère surtout l'agent parce que moi j'essaye de transmettre tout ce que j'ai appris, je crois que ça fait 36 ans que j'ai commencé à coder j'espère que c'est moi qui apprend des choses à l'agent surtout.
Yacine:
La posture un peu provocante que je vais prendre ici c'est que la personne qui est le plus appris ici c'est la personne qui a écrit le skill, parce qu'en écrivant, en faisant tester l'écriture du skill on se pose la question quelle est l'information minimale que je dois transmettre à quelqu'un qui va le comprendre de façon très bête, afin de m'assurer que la tâche ou la pièce soit produite de la façon que j'aimerais qu'elle soit produite et par cet exercice, cet exercice de formalisation, on atteint finalement une forme de compréhension supérieure qui permet ensuite d'être le meilleur juge de ce qui sera produit avec ce skill, ce qui n'est pas du tout la même chose à mon avis que quelqu'un qui va produire le skill, le distribuer à des personnes qui ne le méchissent pas, qui vont le donner à une IA, et qui pour le coup, l'IA aura peut-être des capacités supplémentaires parce qu'on lui donnera un contexte plus important pour réaliser des choses, mais la personne qui va utiliser cet agent-là serait-elle en mesure de pouvoir observer et mesurer le résultat de cet agent ?
Bruno:
Alors, je n'ai peut-être pas forcément bien répondu à ta question parce qu'à ce moment-là, moi, j'apprends effectivement, mais j'apprends à créer le bon skills dans le sens où je vais écrire effectivement des principes qui me semblent évidents sur la manière de produire le code dont j'ai besoin. Et en exécutant une commande aidée de ce skill je vois ce qui est produit et du coup je réévalue en disant bon ok là je dois changer tel paramètre peut-être que là il y a eu un truc mais du coup c'est moi dans une démarche d'apprentissage, de la construction de ce skill mais tu vois ce que je dis mais j'apprends pas le contenu que je mets dans le skill c'est peut-être là où j'ai peut-être pas capté à la question.
Yacine:
C'est à dire que il y a différents niveaux de maîtrise. On peut être un compétent conscient, on peut être un compétent inconscient. Et le fait de devoir formaliser à quelqu'un d'incompétent ce qui constitue une bonne pièce ou une bonne tâche, c'est ce qui fait passer la personne d'un compétent inconscient à un compétent conscient. C'est-à-dire que non seulement je maîtrise ce que je fais, mais je suis capable de le transmettre. Et ça, c'est de l'apprentissage en tant que tel. Et c'est pas forcément apprendre à écrire des skills. C'est apprendre pour, alors c'est aussi apprendre à écrire des skills évidemment mais c'est aussi apprendre pour cette chose précise, alors je vais prendre un exemple pour pas que ce soit trop théorique pour les gens qui nous écoutent parce que depuis tout à l'heure on reste des... Mais par exemple une pièce c'est un test unitaire donc je vais apprendre à mon agent à faire des tests unitaires donc je vais écrire du coup ma skill sur un bon test unitaire c'est comme ça alors au début peut-être que je vais dire un test unitaire on a une assertion, d'abord on a un setup des données et puis il faut utiliser les commandes pour les exécuter et puis je l'envoie au skill et puis moi je pense que c'est un bon test unitaire. Puis je regarde l'agent faire et puis l'agent il me produit des tests qui sont tout bidons. Je dis ah non mais ça ah oui c'est vrai ça aussi c'est un bon test. Ça c'est un mauvais test. Et donc je vais inclure dans le skill. N'oublie pas aussi d'écrire de telle façon-là. Quand on fait ton assertion, évite d'en faire des trop grosses. Il faut vraiment juste asserter uniquement le comportement que tu veux mesurer. Et voici un mauvais exemple de truc à faire. Là je passe de moi je sais instinctivement ce qui consiste à mon test à quelqu'un qui a été capable de. De formaliser ce qui consiste à mon test et en étant capable de le formaliser je suis donc capable lorsque j'en vois un, lorsque je l'observe de savoir s'il est bon ou pas et d'expliquer pourquoi.
Bruno:
Et ce que tu disais aussi juste avant notamment sur les skills et autres c'est que si moi j'écris ma skills en étant en mettant toute ma compétence que je peux essayer d'avoir, consciemment ou inconsciemment dedans si je la transmets à quelqu'un d'autre, qui lui ne pourra pas évaluer la qualité de la pièce qui est produite, c'est du coup inefficace en fait.
Yacine:
Il y aura une forme de valeur de toute façon qui sera donnée ici parce que de la connaissance c'est toujours mieux que de ne pas.
Bruno:
En avoir.
Yacine:
Mais encore une fois si on met les lunettes du Lean le but du Lean c'est pas juste d'avoir de la connaissance. C'est de créer un système où la connaissance s'améliore au fur et à mesure. Parce que ce qui fait un bon test unitaire aujourd'hui ne fait pas forcément un bon test unitaire demain puisque la code base dans laquelle ce test serait écrit ou la feature pour laquelle on l'écrirait pourrait changer. Et peut-être qu'en faisant ça, justement, on se tire une balle dans le pied. C'est-à-dire que... Le skill marchait très bien dans un contexte, il est peut-être terrible dans un autre. Et donc ça, il faut être capable de le voir.
Bruno:
Parce que moi, je vois pas mal d'équipes de DX aujourd'hui qui se renforcent avec des gens relativement seniors, qui vont être là justement pour s'assurer que tous les développeurs et développeuses d'une équipe qui utilisent un cloud, un codex ou que sais-je, utilisent tous les mêmes skills, les mêmes agents, pour essayer d'avoir une certaine uniformité de la qualité de ce qui est produit. Mais dans ce que tu dis, si on part du principe qu'il y a une espèce de sachant, de groupe de sachant, qui produisent des grands concepts de comment c'est fait et qui les distribuent sans aller s'assurer que les gens ont la capacité derrière. Si je comprends bien, c'est qu'il faut que les gens derrière soient capables d'identifier quand il y a un problème pour pouvoir le résoudre et remonter la résolution ?
Yacine:
Disons que c'est dommage de faire tout un travail de formalisation de ce qui constitue de bonnes pièces pour les donner des machines, sans faire, l'autre moitié du chemin qui constitue à s'asseoir avec des êtres humains pour leur apprendre ce qui constitue une bonne pièce. Et c'est pour ça que, de façon provoquante, je disais, l'agent n'apprend pas. Alors l'agent, oui, il apprend dans la mesure où il va avoir accès à de nouvelles connaissances, mais il n'est pas capable, sans qu'on lui demande en tout cas, de venir, le contextualiser, le nuancer, se l'approprier le réinventer et ça c'est justement, et c'est un grand parti pris du Lean, en tout cas c'est de croyance c'est que les meilleures personnes pour faire ce genre de choses ce sont les travailleurs ce sont les gens qui sont sur la ligne de production et qui comprennent les choses et qui sont capables de dire à leur boss, non on devrait plutôt faire les choses comme ça.
Bruno:
— Alors ça m'amène deux questions. La première, ce serait... On évoque le fait que l'être humain doit rester en contrôle de ce que l'agent produit pour s'assurer que ça respecte un ensemble de règles de qualité. De ce qu'on voit, on ne va pas se mentir, sur le terrain aujourd'hui, c'est qu'on a des agents qui créent des milliers de lignes de code par jour qu'on est incapable de relire, qu'il y a des gens qui utilisent CloudCode en acceptant tous les trucs qui sont demandés par CloudCode sans forcément relire. Et donc, on perd cette boucle de contrôle. Mais en même temps, on n'a pas le choix, parce que quand t'as un agent qui va créer 10 000 lignes de code par jour, on est incapable, humainement, en fait, de les relire ou de les estimer. Merci.
Yacine:
C'est une question ouverte. Je n'ai pas de réponse à donner sur comment est-ce qu'on gère ce volume ici. Par contre, il y a un éclairage que Lean peut apporter sur comment on arrive à cette situation. Et là, plutôt que de l'angle qualité, c'est l'angle flux qu'il faut regarder. Si on essaie de formaliser le flux classique d'un développement logiciel, on va avoir des premières étapes de conception, des étapes de réalisation, des étapes ensuite de contrôle de la qualité, donc de review. Et en fait avec la façon en tout cas la plus commune dont les agents de code sont utilisés c'est qu'on va prendre la moitié enfin cette partie centrale du flux qui est la plus coûteuse et la plus, consommatrice de temps de manière générale et c'est la raison pour laquelle dans nos équipes on a autant de software ingénieur et on est si bien payé, et là on prend du coup cette partie du flux et on le rend dix fois plus productif, mais c'est un flux, c'est-à-dire que vous pouvez s'imaginer c'est comme des tuyaux qu'on branche les uns les autres. Si le tuyau que vous mettez au milieu avant il était tout petit donc il y avait de la pression en amont donc ça avait du mal à rentrer là maintenant vous faites un gros gros tuyau qu'est-ce qu'il se passe ? La pression elle retombe et vous retrouvez, vous ouvrez le robinet et ça ne se passe pas très bien donc c'est la situation dans laquelle on se trouve finalement d'une certaine façon, on ne prend pas le temps d'analyser le flux et de regarder que cette pression qu'on a réussi à contrôler au milieu quand on la relâche, on la retrouve à la fin, donc sur cette partie contrôle qualité review et là il y a un choix à faire, va-t-on cette étape là qu'on n'aura pas su en tout cas, rendre plus efficace ou en tout cas automatiser autant que la réalisation qu'en fait-on ? Une logique de management, on va dire, financiarisé, c'est un produit plus de code, on a plus de features, on a plus de revenus, on va faire sauter ce truc-là, parce que si on a un pipe en entrée qui fonctionne, économiquement, ça fait sens. On met les lunettes du Lean, et on se dit, oui, mais en fait, cette étape-là, c'est une étape de qualité. La qualité passe avant les délais, elle passe avant l'improductivité. Donc, la question qu'il faut se poser, c'est comment est-ce que je fais en sorte pour que j'adapte la composition de mon flux pour que la pression s'équilibre, pour que le flux se lisse ? Alors il y a une solution un peu évidente, les gens qui faisaient de la production de code maintenant ils font de la revue de code. Donc on va demander à des gens de faire que la revue de code. Est-ce que les software developers s'imaginent que leur carrière se constitue de review du code écrit par l'agent toute la journée ? Probablement pas. Et donc c'est là où on peut utiliser un autre concept de Lean qui est l'autocalité. Le contrôle qualité c'est un outil d'amélioration continue, c'est pas un outil pour s'assurer, on fait pas de la qualité avec du contrôle on fait de la qualité parce que le contrôle nous permet d'identifier les mauvaises pièces, d'apprendre pourquoi ces pièces sont mauvaises et changer le système pour qu'elles ne deviennent plus donc là on met plein de gens en revue de code on regarde ce que l'agent produit, on analyse la qualité de ce qui est produit on se pose la question mais comment est-ce que je vais pouvoir du coup configurer l'agent, lui donner le bon contexte Ou peut-être agir en amont de flux, donc plutôt dans l'étape de conception, afin d'éviter les écueils de qualité. Et ça, ça va permettre justement de lisser le flux comme il faut. Mais en tout cas, la chose qu'il ne faut pas faire, c'est de créer du stock. Et créer du stock qu'on connaît très bien avec des armées de PM qui vont peut-être pondre des specs ou des designers qui vont pondre des wireframes, il n'y a jamais les devs pour les développer. Là, on se retrouve dans la situation où on a des agents qui produisent du code et en fait, on n'a pas les personnes pour le review. C'est les mêmes méthodes à appliquer, je pense, dans ces deux situations.
Bruno:
La deuxième question que j'avais, c'est que tu évoquais tout à l'heure que dans cette stratégie Lean, il faut que ce soit les personnes qui produisent, qui soient autonomisées dans la capacité à identifier les problèmes et à les résoudre. Est-ce que ça veut dire que cette démarche aussi d'apprentissage, on doit aussi la déléguer aux agents parce qu'au final c'est eux qui produisent le code donc c'est eux qui sont le plus proche en fait des problèmes et qui peuvent les identifier donc tu parles cette idée de relecture, est-ce qu'au final si on leur donne pas les bons critères de validation ils peuvent pas en fait d'eux-mêmes apprendre, modifier les règles de validation et progresser Oui.
Yacine:
Tout à fait, c'est là où on peut jouer un jeu dangereux qui consiste à humaniser, l'agent et donc si on humanise l'agent on considère que c'est un ouvrier de la chaîne de production dont ses pièces sont les différentes pièces de code qui peuvent être produites et qu'il est en capacité d'apprentissage, qui sommes-nous alors ? Du coup on est les leads on est les tech leads les managers hands-on de ces agents, Dans ce cas-là, la conclusion, c'est est-ce qu'on ne devient pas tous des managers d'une façon ou d'une autre ? Alors, si tu peux me répéter un petit peu la problématique que tu avais évoquée.
Bruno:
C'est que, comme tu disais que c'est la personne qui produit, qui doit être autonomisée dans sa capacité à identifier un problème et apporter une réponse. Vu que c'est l'agent qui produit le code, peut-être qu'en fait, on peut le laisser libre de dire, ben voilà, moi, je te donne les critères pour estimer qu'une pièce est de qualité. donc je te laisse en fait auto-apprendre et auto-juger et refaire tant que tu n'as pas atteint ces critères là en.
Yacine:
Dépit de l'autonomisation et de l'apprentissage, dans les lignes les équipes ont quand même des tech leads il y a des personnes qui aident les personnes sur le terrain à faire la bonne résolution de problème, à résoudre le bon problème au bon niveau, et donc ces personnes là elles existent toujours et donc avec cet exercice on va dire de translation d'humanisation de l'AI coding agent, c'est nous qui devenons ces personnes-là. En tout cas, ce que je trouve dangereux, mais après, je ferai des exemples où ça peut marcher, c'est que les LLMs, leur processus de génération de tokens, c'est un processus divergent. Donc, en fait, si on lui dit de façon totalement autonome, apprend et continue d'apprendre, il va y avoir juste un phénomène d'accrétion de... Parce que l'apprentissage, on le disait tout à l'heure dans LLM, c'est rajouter de la documentation dont il va avoir accès, finalement. C'est par ce moyen qu'il apprend, vu qu'il est amnésique. Ce qui va se passer, donc, Donc la documentation, elle va juste enfler, enfler, enfler, enfler jusqu'au moment où elle va dépasser la capacité LLM de l'absorber. Et dans ce cas-là, on se retrouve dans une situation de blocage. Et donc, il faut faire quoi ? Il faut revenir sur ce qui a été généré et commencer à faire le tri. Sur bon, ça, c'est bien, ça, c'est pas bien. C'est justement le rôle du manager de déterminer ce que tu as appris. Oui, c'est ça qu'il faut apprendre. C'est ça qu'il faut retenir, en tout cas, du problème et pas ça. J'avais fait une petite expérience qu'on peut parler après si tu le souhaites justement d'une boucle auto-apprenante avec un agent et ça peut marcher mais dans des contextes limités.
Bruno:
Tu peux l'évoquer maintenant ?
Yacine:
Alors, c'est très récent, pour le coup. On avait été surpris par beaucoup d'alertes, de vulnérabilité de nos dépendances récemment. Alors, vous avez vu les supply chain attack en ce moment. Donc, on est en mai 2026. Donc, on vient d'avoir mini Shai Hulud, donc la deuxième version de Shai Hulud qui vient d'arriver. Donc en ce moment il y a une forme d'effervescence dans l'écosystème JS, sur la capacité à une personne de venir empoisonner notre chaîne de dépendance, donc on s'attaque à ce problème chez nous en essayant de mettre à jour nos dépendances et en essayant de contrôler ce genre de choses. Et donc ce que j'ai fait pour traiter du coup toute cette liste d'alerte j'ai demandé à l'agent déjà d'en corriger une en lui donnant du contexte minimal où je lui donne la CVE, un peu de détail, et la code base. Et une fois qu'il a produit la mise à jour et l'explication de pourquoi est-ce qu'on était ou pas impacté par telle vulnérabilité, je lui pose la question y a-t-il quelque chose que si je te l'avais dit au début t'aurait permis d'atteindre le résultat plus rapidement ? Il met donc du camp l'ensemble de learnings et je lui demande ensuite, est-ce que tu peux éditer le prompt initial pour inclure ses enseignements. Je passe à la deuxième vulnérabilité et je mets le prompt. Et je recommence. Et la troisième et je mets le prompt. Et je recommence. Et je fais ça de façon continue. Et ce que j'ai observé c'est qu'effectivement l'agent il va beaucoup plus vite pour résoudre le problème. C'est-à-dire qu'il va savoir où chercher dans la code base, il va mieux comprendre comment utiliser le package manager pour déterminer quelles sont les bonnes versions, pourquoi est-ce que le truc est là, il va mieux naviguer le graph de dépendance. Par contre, lorsqu'il y a un os. Alors, il va essayer d'appliquer un peu toujours les mêmes méthodes de façon un peu bête. Et il a beaucoup plus de difficultés à déterminer, finalement, la solution créative qui est lui permettre de dépasser le problème. Et donc, c'est là où, quand j'ai ce problème, je lui demande de venir condenser l'initial, d'enlever les trucs qui sont trop spécifiques, les généraliser avantages, et ensuite, je reprends. Donc ça, ça avait plutôt bien marché. Je n'ai pas fait d'expérience encore plus à l'échelle où j'ai vu ça ne pas fonctionner. Mais par contre, j'ai eu des témoignages, notamment d'un candidat qui m'avait exprimé ce phénomène de processus sans limite, processus divergent. Il n'y a pas de condition d'arrêt qui peut amener l'agent vers une solution optimale. Ça fait que s'accumuler, et donc on finit avec un blougie-blouga non exploitable. C'est là où l'être humain, il a toujours cette capacité de nuance, de savoir où se trouve la limite pour finalement pas continuer et faire n'importe quoi.
Bruno:
Quand je repense à l'analogie que tu as faite avec le tuyau tout à l'heure, où effectivement aujourd'hui on a ce tuyau de capacité de production de code qui est devenu absolument énorme mais que la capacité à contrôler derrière l'est pas du tout tu nous as évoqué aussi sur ce Lean les 5 ou 6 principes fondamentaux sécurité.
Yacine:
Qualité oui c'est ça les axes en fait ça va dépendre des entreprises mais globalement c'est sécurité, qualité délai, productivité.
Bruno:
Ce qui était intéressant aussi dans ce que tu disais c'est que de manière assez traditionnelle le management en occident place la productivité en premier alors que le Lean t'explique que c'est le critères. Est-ce que c'est pas justement l'illustration que la génération de code par de l'IA, en fait, c'est qu'on a appliqué l'IA sur le mauvais maillon de la chaîne, et qu'il faudrait peut-être d'abord utiliser les LLM pour faire de la review de code, pour qu'en fait on puisse, on lui donne nous le code qu'on écrit et il le review jusqu'à ce qu'on arrive à être d'accord sur la bonne manière de le faire en review, pour après le remonter petit à petit dans la chaîne donc on commencerait par la sécurité puis la qualité puis tu as remonte la chaîne jusqu'à arriver à la productivité où là on produit massivement du code.
Yacine:
Oui, c'est un moyen. En tout cas, c'est le bon angle d'attaque. En tout cas, c'est ma conviction personnelle. C'est le bon angle d'attaque. Et de la même façon où on va avoir un angle de productivité, on va commencer par la productivité avant de s'occuper de la qualité, souvent quand on essaie d'attaquer le problème de façon plus frontale, on a aussi la même problématique lorsqu'on va plutôt traiter des questions de… lorsqu'on va plutôt traiter en amont du flux, justement. Il y a une mode en ce moment qui est le spec driven development qui consiste à dire en fait je vais itérer, itérer, itérer sur une spec, je vais faire la spec la plus complète possible et quand je vais donner à l'agent il va me produire le bon code, oui bah non en fait, ça ça s'appelle du waterfall automatisé, alors ça veut pas dire qu'il faut pas faire de la conception en amont ça veut pas dire qu'une spec c'est inutile encore une fois je veux pas avoir une position. Caricaturale mais ce qui est important c'est de créer les boucles de rétroaction qui permettent l'apprentissage, et donc dans ce que tu dis lorsque tu proposais, c'est-à-dire qu'on devrait plutôt orienter nos AI coding agents pour optimiser la review, oui à la condition que c'est le boucle d'apprentissage c'est-à-dire que c'est pas seulement l'AI qui va review le code, c'est on va considérer qu'une review c'est une pièce, et on va essayer de, nous humains déterminer qu'est-ce qui fait une bonne review, et on va observer ce que l'AI produit donc il produit une review, on va regarder où est-ce qu'on a les problèmes de qualité et on va changer la façon dont il est codé ou paramétré pour que la prochaine fois on a une meilleure qualité, et on avance comme ça au fur et à mesure, jusqu'au moment où il sera capable de bien review du code, Et on peut appliquer ça à peu près n'importe quelle pièce. C'est là aussi la force, je pense, et j'aurais peut-être dû le dire dès le début, la force de cette mode de pensée. C'est de prendre chaque activité, chaque chose qu'on produit comme étant un vrai artefact, quelque chose de palpable qu'on peut voir et qu'on peut évaluer.
Bruno:
Est-ce que du coup, tu as des exemples d'applications du Lean qui portent réellement des fruits qui sont probants dans des contextes augmentés par l'IA ?
Yacine:
Ah ouais, alors j'en ai un, il est assez frais et je ne suis pas encore allé jusqu'au bout de la démarche, mais ce qui est important pour répondre ici, c'est que ce n'est pas l'application de Lean en tant que méthode, c'est vraiment juste la grille de lecture. Mettons, et j'ai cité cet exemple avant qu'on cherche à résoudre un bug ce que je vois beaucoup, ce qui est beaucoup fait dans nos équipes c'est l'ingénieur il va ouvrir son assistant il va lui copier-coller le bug enfin le report de bug et puis il va laisser l'agent mouliner et puis après si l'agent fait un peu n'importe quoi il va le diriger ailleurs et puis à la fin il va faire un fixe il a gagné du temps, c'est bien et ça, ça marche bien en tout cas avec les modèles qu'on a aujourd'hui c'est pas trop mal. Mais avec un Aileen, on se pose la question, mais c'est quoi la pièce, déjà, pour commencer ? Donc la pièce, c'est correctif. Mais en fait, il y a des sous-pièces, tous correctifs. Il y a d'autres choses qu'on produit avant. Avant de produire un correctif, déjà, la première chose qu'on produit, c'est une reproduction. Les étapes de reproduction du bug, c'est une pièce. La reproduction elle-même, c'est une pièce. Une fois qu'on a reproduit le bug, l'investigation, c'est-à-dire que l'explication de quelle est la cause, c'est une pièce. La correction elle-même, c'est une pièce. et ensuite l'analyse qui consiste à dire mais en fait là j'ai fait un correctif rapide mais il y a potentiellement d'autres problèmes sous-jacents il y a peut-être une rachitecture à faire, ça aussi ça peut être une pièce, et donc c'est avec cette grille de lecture que je me suis posé et je me suis dit comment est-ce que je peux crafter un prompt qui va me corriger des bugs tout seul, et bah c'est simple je lui demande, voici le ticket, est-ce que tu peux d'abord s'il te plaît m'écrire un document ou tu vas faire les adeptes de reproduction ensuite une fois que tu as fait les adeptes de reproduction tu vas reproduire le bug et tu vas t'enregistrer et le faire avec une vidéo. Une fois que tu as fait ceci, je te demande, s'il te plaît, d'investiguer et de m'écrire un document dans lequel tu expliques la cause du bug et pourquoi ça cause le problème. Ensuite, je te demande de produire, en utilisant le document précédent des étapes de reproduction, de produire une vidéo de toi qui montre que le code a effectivement été résolu. Puis enfin, je te demande de faire une analyse pour déterminer potentiellement des bugs adjacents, donc similaires, qui auraient des causes les mêmes ou alors à côté, pour voir s'il n'y a pas un correctif plus intéressant qui peut être effectué. Le prompt, il fait une trentaine de lignes. Je l'ai plugué à un serveur MCP linéaire pour aller chercher le bug. Serveur MCP, Chrome DevTools pourrait marcher avec Playwright aussi pour utiliser notre application et enregistrer. Et les résultats sont bluffants. Les résultats sont bluffants, et la façon dont je l'utilise, c'est que pendant qu'il est en train de résoudre le bug, je vais regarder les pièces les unes après les autres. Et donc ça, c'est un premier angle du Lean. Le fait simplement d'avoir fait ça, ça guide l'agent vers la bonne méthodologie. Et après, on peut aller encore plus loin, si on veut. On peut se dire, bon, c'est bien, on a fait des pièces. Alors les pièces, pour juger les qualités, on peut avoir des standards. Donc peut-être la deuxième étape derrière, c'est de produire des skills qui vont documenter c'est quoi une bonne reproduction, c'est quoi un bon correctif, c'est quoi une bonne explication de cause. Après, encore une fois, l'angle Lean, on peut commencer à faire de la mesure. Donc je peux commencer à mesurer déjà la sécurité. Combien est-ce que je suis en train de fournir à ce LLM des éléments qui peuvent compromettre la sécurité de mon système ? Puis la qualité, donc je viens de l'évoquer avec les standards. Donc je peux juger la qualité des pièces littéralement ensuite le lead time le délai, je peux mesurer le temps que prend toute cette étape mais également chacune des étapes et venir les optimiser individuellement et enfin la productivité donc c'est l'idée de coût, je peux mesurer si je plug mon, harness à un système d'observabilité, je pourrais commencer à calculer chaque étape le coût en token, et me poser la question mais du coup comment est-ce que je fournis le bon contexte pour optimiser le coût en token Donc on ouvre sur un truc aussi bête que corriger un bug un univers, et là on pourrait y passer des semaines, des mois à travailler, juste à venir crafter savamment comment est-ce qu'un agent va corriger un bug.
Bruno:
J'ai jusqu'à avoir un système qui est capable de s'auto-corriger, dès que tu as un bug qui est détecté, il est capable automatiquement de travailler sur tous les bugs que tu détectes.
Yacine:
Absolument, sachant que de toute façon, il y aura toujours des erreurs. Et c'est là où l'humain est important. C'est là où l'humain doit venir de façon régulière au minimum échantillonner ce que l'IA produit pour déterminer est-ce qu'il y a des opportunités d'amélioration ou des erreurs qui ont été effectuées qu'on n'aurait pas observées. Et le parallèle que je viens de donner ici, je pense qu'on est potentiellement en train de vivre dans notre métier ce qu'a vécu l'industrie il y a de cela un siècle, c'est-à-dire que cette automatisation cette mécanisation a transformé l'artisanat qui était quelque chose de la production de pièces de façon très personnelle individuelle et complète en quelque chose de beaucoup plus répétable. Systématisable alors ça a eu plusieurs effets premièrement ça a vraiment créé cette classe d'ingénieur, industriel, un ingénieur industriel quand on est ingénieur on peut effectivement s'occuper de concevoir la pièce qui va être produite mais la majeure partie de l'effort c'est pas dans la conception de la pièce c'est dans la conception du système de production qui est autour, et nous développeurs aujourd'hui on est préoccupé que par la pièce, on passe assez peu de temps à se poser la question du système de production qui va générer la pièce et je pense qu'un de nos futurs potentiels c'est d'avoir beaucoup plus de matière grise qui est dépensée, pour résoudre ce problème. Et la deuxième chose que ça fait aussi, c'est une standardisation de nos produits. C'est-à-dire qu'on a beaucoup moins cette idée de l'unicité du produit, cette idée de crafter la pâte personnelle, etc. La question typique de la fin de ce podcast, est-ce qu'on préfère les espaces ou les tabulations ? Est-ce que c'est une question qui va être pertinente dans une ère des agents ou nous, en tant qu'ingénieurs ? Est-ce qu'on est là pour venir imprimer nos de préférence sur la pièce qui est produite, on est là pour faire la production de masse. Peut-être que c'est un futur dystopique pour certains, mais c'est peut-être la voie qu'on est en train de prendre.
Bruno:
Donc ce que tu dis, c'est qu'on doit petit à petit se détacher du code, donc arriver à une époque où on n'aura plus d'humains ou très peu d'humains qui produisent du code. Et qu'on aura encore quelques artisans qui iront faire du code mais la majorité, ne sera aucunement écrit par des humains mais qu'on aura des humains qui seront là en fait pour concevoir la chaîne de production qui génère ce code j'en.
Yacine:
Suis convaincu après c'est le début je ne suis pas.
Bruno:
Devant.
Yacine:
Ce sont des croyances mais j'en suis convaincu juste pour des raisons économiques et on commence déjà à rentrer dans ce territoire tu le dis toi même on se retrouve avec, trop de comites et trop de codes produits pour pouvoir le review c'est déjà un peu la voie qu'on est en train de prendre et comme par le passé il y a des personnes qui vont être très attachées à l'artisanat et ça va continuer d'exister et ça doit exister si on veut vraiment avoir des belles choses des choses vraiment, des belles choses au sens, Une patte unique, une patte authentique.
Bruno:
Mais le code peut être beau, là-dessus on est aligné.
Yacine:
Voilà, exactement. Il y a une part d'esthétique dans notre travail et je pense que ça va être très obéiste ou alors très cher. Mais en tout cas, dans l'âge économique, le coût de production du code étant diminué, il me paraît assez irréaliste que le marché ne se situe pas de cette occasion pour produire à minima le même software qu'aujourd'hui, mais pour moins cher. Mais en tout cas l'effet qu'on a vu c'est que les chaises qu'on produit aujourd'hui ne sont pas les chaises d'antan elles sont beaucoup plus simples, elles sont beaucoup plus systématisées, elles ne sont pas forcément de meilleure qualité, mais par contre on peut les produire en très très grande quantité et elles sont fiables.
Bruno:
Donc en fait on va avoir les les développeurs Rolex qui seront effectivement les orfèvres qui vont faire de l'ingénierie de très haut niveau, de l'orfèvrerie vraiment de code et puis Swatch à côté qui va, enquiller des lignes de code et produire de la features pour tout le monde.
Yacine:
Donc il va y avoir cette segmentation, je pense, en tout cas pour le logiciel final. Mais après, on peut avoir les deux types d'ingénieurs qui vivent dans la même boîte, parce que dans une même entreprise, le même type de production plutôt, dans une entreprise industrielle, il faut bien que des gens produisent les machines qui vont produire le code. Et donc là, pareil, il y a un travail d'orfèvre ici. Il n'y a pas une... En tout cas, il y a rarement pour l'ingénierie de pointe, des chaînes de production, extrêmement automatisées pour produire ce genre de choses. Ne serait-ce que dans l'aéronautique, dans l'aéronautique, il y a énormément d'humains, il y a beaucoup de compétences, de sciences, les techniciens sont des gens qui sont très savants de leur métier. Et je pense que ça, ça ne va pas forcément disparaître.
Bruno:
J'ai eu la chance de visiter une usine Airbus. C'est une folie à voir. C'est complètement incroyable. Et en fait, on découvre qu'il y a autant d'ingénierie qui est mise dans l'avion que dans la chaîne de production de l'avion. Parce que du coup, il y a une usine qui est créée spécifiquement pour chaque type d'avion avec des outils spécifiques, avec tout un outillage qui est construit, pour cette production d'avions. Donc effectivement, la génération du code, c'est de l'outillage qu'on sera amené à concevoir en fait.
Yacine:
Je le pense, c'est un des futurs possibles.
Bruno:
Pour terminer, parce que du coup, j'ai évoqué à un moment les agents comme étant des collègues à qui on laisserait une certaine autonomie. Et tu m'as dit, c'est le cas si on veut humaniser nos agents. Mais toi, de ce que je comprends, tu les vois plus effectivement comme une machine-outil, comme un outil qu'on va manipuler, qui va produire une pièce.
Yacine:
Oui.
Bruno:
Donc, parce qu'effectivement, on entend parfois des gens parler de ces nouveaux collègues, des managers d'agents. Mais donc, toi, tu es sur une approche de se dire non, on n'est pas manager, on est technicien qui manipulons des outils, certes modernes, mais des outils quand même.
Yacine:
Oui, on n'est pas manager. Après, il y a des similarités forcément avec le métier de manager parce que ce sont des entités qui manipulent la connaissance et du langage. Donc ça le parallèle il est utile à la réflexion mais non, après c'est encore une fois de la croyance, c'est un principe que j'établis, je pense pas qu'on verrait d'un bon oeil typiquement dans l'industrie que les bras robots qui font nos voitures qu'on considère qu'ils doivent prendre une pause on leur file un café et puis on les humanise on leur donne des petites moustaches, non ce sont des outils et il faut continuer de les considérer comme tels, sinon ça fait de la psychosia que certains ont été victimes je pense qu'il faut les considérer pour ce que c'est donc une technologie merveilleuse mais une technologie.
Bruno:
Top, c'était passionnant. Merci beaucoup, Yacine, pour cette discussion.
Yacine:
De rien, merci de m'avoir invité.
Bruno:
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 souhaiterais partager avec l'ensemble des auditeuristes ?
Yacine:
Alors, dans la lignée de ce que je dis, moi, je suis un apprenant du Lean assez récemment. J'ai découvert ça chez Fabrique et j'ai été formé par Régis Médina. Alors, Régis Médina, il a été l'auteur de Learning to Scale. Il a accompagné des entreprises comme Konto et Theodo dans leur transformation Lean, avec son fils il développe un jeu vidéo et il partage des vidéos en ligne sur ce qu'il a appris justement de l'usage de l'IA appliqué au Lean donc si vous voulez écouter quelqu'un qui est plus, sachant que moi sur la question du Lean et de son usage dans l'IA, je vous invite à regarder du coup Learning to Scale ou Régis Medina sur internet canon.
Bruno:
On mettra bien évidemment quelques liens en description dernière question qui est la plus importante de ce podcast Yassine, est-ce que tu es plutôt espace ou tabulation ?
Yacine:
Quand j'ai le choix.
Bruno:
Espace merci beaucoup Yassine merci à tous d'avoir suivi cet épisode de la conversation passionnante le link est une stratégie, hyper intéressante et hyper riche qui donne des organisations d'équipe qui sont toujours extrêmement intéressantes et je trouve dans une démarche d'autonomisation des individus qui est toujours. Pertinente et beaucoup plus agréable pour les individus et comme le dit Yacine, considérez bien vos IA comme des machines, et c'est à vous de les fine-tuner de les utiliser pour qu'elles produisent des pièces de qualité, n'hésitez pas à aller surveiller tout ça un petit peu sur le net pour voir aussi les best practices et aussi tout ce que Yacine partage pour apprendre la meilleure façon de faire tout ça, de mon côté je vous remercie comme toujours de partager ce podcast autour de vous je vous souhaite une très bonne fin de semaine je vous donne rendez-vous la semaine prochaine et d'ici là codez bien.
